Databricks Proteus 用 Agent 生成专用 GPU kernel，Qwen 3.5 122B 单个算子比 vLLM 快 1.8–5.2 倍；AWS 给出 AI Agent 联邦数据访问的三种参考架构；Yahoo 用 flexible VM 把 Managed Spark 集群创建失败率降 85%；Dremio 盘点开放湖仓：Iceberg V4 弃用 equality deletes，Arrow 给非 committer 的并发 PR 设上限

本期四条动态分别落在算子生成、Agent 数据访问、集群供给与开放规范四个层面，彼此没有厂商协同，却指向同一处变化：瓶颈正在从”能力不够”迁移到”信不过、不允许、抢不到”。Databricks 的 Proteus 发现，用 Agent 写 kernel 已经不是难点，难的是以多快的速度判断一个 kernel 可信；AWS 的联邦访问架构里，查询能力早已就绪，剩下的问题是哪个源该走目录、哪个源可以直连；Yahoo 面对的不是总算力短缺，而是某个机型在某个可用区暂时缺货；Iceberg 与 Arrow 社区则发现，AI 把写代码和提 PR 的成本压到近乎为零之后，评审带宽和规范一致性成了新的硬约束。四家的答案形状出奇一致——把判断写成一份可声明、可校验、可被机器执行的物件：一个 checker、一条路由规则、一张带 rank 的机型表、一个版本化的 endpoint。

---

Databricks Proteus：Agent 写 kernel 已经很便宜，系统的推进速度取决于验证有多快

事件概述

Databricks 在 9 月 4 日公开了 Proteus——一套用 Agent 自动生成 GPU kernel 的 harness。出发点是作者提出的一个反直觉问题：既然 kernel 生成可以自动化，为什么从 10 亿参数到 1 万亿参数的模型要共用同一套 kernel？GPU 算子的形状由静态模型参数与请求时的动态因素共同决定，矩阵乘法的一个维度由模型定义，另一个维度则随每次请求的 token 数浮动。生产推理系统普遍依赖通用 kernel 来覆盖多样的模型与负载，这在按形状特化面前天然是次优解。

Proteus 的流程并不复杂：让 Agent 提出 kernel 候选，对照受控参考实现做校验，只对通过校验的候选计时，再基于最优结果迭代改进。系统在 NVIDIA B200 GPU 上以 Triton 为后端跑通了完整循环，为 Qwen 3.5 122B 的 Gated DeltaNet 路径生成了专用 kernel，单个算子速度达到 vLLM 现有最佳实现的 1.8–5.2 倍。

文章真正有价值的部分并不是这个提速区间，而是作者反复强调的判断：草稿可以并行廉价地产出，信任不行，系统只能以它能验证的速度前进。

技术解析

• 先做 checker，再写 prompt：团队原本以为难点是程序搜索——如何在巨大的程序空间里探索而不陷入平台期。实际遇到的第一个问题更基础：我们测的真是我们以为在测的东西吗？RoPE kernel 的候选会复用上一次尝试遗留的编译产物，看起来比公平重建更便宜；有的候选把一批 GPU launch 录进 CUDA graph 整体重放，而基线仍是逐次 launch，两边做的根本不是同一件事。
• 多重计时与不可见测试集：需要时用 CUDA event timer、wall clock 与 CUPTI timer 交叉比对；把胜出候选重新计时后再作为下一轮的起点；保留一部分候选看不到的测试，避免它只拟合给出的那几组输入尺寸。
• 自动一致性检查：对超过物理带宽与算力上限的加速比（文中举例 >100x）自动打标，用来拦截 reward hacking。作者的判断很直接——没有这些约束，生成更多 kernel 只是产生更多噪声。
• 上下文是权衡，不是越多越好：给模型的提示越长，信息越多，成本也越高，而且过期建议、互相矛盾的提示与只适用于另一尺寸的细节会混进来，下一次尝试更容易跑偏。给得太少则每次从零开始，同样的死路反复出现。
• 知识层的粒度：太笼统的经验（“更好利用片上内存”）放之四海而皆准却没告诉模型该做什么；太具体的经验（“这个 kernel、这个尺寸、展开这个循环”）换个算子或换个 GPU 就容易被误用。定稿方案是只把高信任上下文放进 prompt——配对了具体情境与动作的可执行结论，加上来自相近父运行的简短失败记录，通过分层 tag 过滤与关键词加语义的混合检索取回。

行业影响

对做推理优化的工程团队来说，这篇的价值在于它把 agentic kernel generation 的成本结构摊开了：写候选这一步已经被 LLM 压到接近免费，真正的开销落在 GPU 上孤立且重复运行的校验，以及提示词里每一段上下文的取舍。作者给出的分工建议也比”Agent vs. 流程”更窄——把 kernel 怎么写交给 Agent 自主决定，把记忆与评测留给外层循环，因为 Agent 自己计时等于重新引入缓存残留和不对称比较。

值得注意的是文中留下的张力：头条给出的 1.8–5.2 倍是”单个 kernel 相对 vLLM 最佳实现”的区间，而完整披露的 Gated DeltaNet packed decode 案例里，基线 0.025 ms、最优候选 0.018 ms、最佳形状加速 1.6 倍，Batch-1 修复路径是 1.5 倍。案例数字低于头条区间的下界，正说明那是一个跨多种算子与形状的分布，而不是随便挑一个 kernel 就能拿到的收益。

相关链接

• Achieving Extreme Efficiency through Specialized GPU Kernel Generation（Databricks Blog, 2026-09-04）

---

AWS 把 Agent 的联邦数据访问拆成三种模式，用 MCP 统一目录治理与直连两条路

事件概述

AWS Big Data Blog 在 9 月 4 日给出一套面向 AI Agent 的联邦数据访问参考架构，用 Model Context Protocol 与 Amazon Bedrock AgentCore 把 S3 上的批数据与流数据、Aurora 里的 CRM 操作库暴露给同一个 Agent，目标是让业务方不再需要把每个问题都路由给数据工程师。文章以一家流媒体公司为串联案例——S3 存放客户画像、内容目录与广告活动，Kinesis 处理实时观看遥测，Aurora MySQL 存放订阅与支持工单——并把这个场景里常见的取舍整理成三种模式：目录优先、直接源访问、混合。

三种模式的差别不在查询能力，而在治理强度与接入摩擦：目录优先要求数据先被编目，换来统一的 schema、业务上下文与血缘；直接源访问省掉注册步骤，换来的是牺牲目录治理。

技术解析

• 目录优先（catalog-first）：S3 上的批数据与流数据先在 AWS Glue Data Catalog 注册，Data Processing MCP 服务器把 Glue 的元数据能力与 Athena 的查询能力封装成标准 MCP 工具调用，Agent 不直接调 Glue API。流程被强制为 discover-then-query——写任何 Athena SQL 之前必须先调 manage_aws_glue_tables 取回列名、类型与分区键。
• 直接源访问（direct source）：Aurora MCP 服务器直连 Aurora MySQL，只暴露 run_query 与 get_table_schema 两个工具，凭证由 AWS Secrets Manager 托管，Agent 不创建连接也不接触凭据。schema 变更立即可见，代价是没有目录层的治理。
• 混合（hybrid）：两条路径走的是同一种协议。AgentCore Runtime 托管全部 MCP 服务器，AgentCore Gateway 作为单一聚合端点统一处理工具发现、认证与路由，治理型数据源走目录、操作型数据源直连，在同一个编排 Agent 后面共存。Agent 侧用 Strands 框架，底层模型为 Claude Haiku 4.5，通过 x_amz_bedrock_agentcore_search 按关键词发现工具。
• 治理栈：Amazon Cognito 做前端用户认证并签发身份令牌；AWS Lake Formation 在 Catalog 上执行细粒度访问策略；文中还提到 Glue Data Catalog 已支持 business context 与语义搜索，用来降低 Agent 的幻觉率。
• 作者自己列出的三个开放问题：跨越 Agent 组合输出的数据血缘；当 Agent 成为主要数据消费者时的身份与授权模型；审计轨迹不仅要记录 Agent 访问了什么，还要记录为什么。

行业影响

把 Databricks 的托管 MCP 服务器、Google Cloud 的数据库 MCP 支持与这篇放在一起看，MCP 已经从”给 Agent 接几个工具”演变成数据访问层的候选标准协议，而厂商竞争的落点开始向 Gateway 转移——谁掌握了工具发现、认证与路由，谁就掌握了 Agent 能看到哪些数据。文章最有信息量的部分恰恰是它没解决的那三个问题：血缘、身份、动机，这三样在传统数据栈里分别由 catalog、IAM 与工单系统承载，Agent 把它们压缩进一次对话之后，还没有对应的承接物。

相关链接

• From silos to insights: Federated data access patterns for AI agents（AWS Big Data Blog, 2026-09-04）
• aws-samples/sample-aws-semantic-data-access-ai-agents（配套代码仓库）

---

Yahoo 用带优先级的机型列表吸收区域容量波动，Managed Spark 集群创建失败降 85%

事件概述

Google Cloud 在 9 月 4 日刊出与 Yahoo 联合署名的文章，处理的是一件看起来不性感、在大规模场景下却很致命的问题：固定机型配置会让集群供给变得脆弱，当某个 machine shape 在某个可用区遇到容量约束，Managed Service for Apache Spark 的集群创建就会延迟，进而拖住有截止时间的数据管道。

Yahoo 的做法是改用 flexible VMs——定义一张带优先级（rank）的可接受机型列表，让系统在区域内跨可用区搜索容量，在首选机型缺货时自动退到次选。文章给出的量化结果是：由区域容量缺货导致的集群创建失败减少了 85%。

技术解析

• 两条硬规则：启用 auto-zone placement 必须传 --region=${REGION} 或把 zone 显式置空（--zone=""），否则系统不会跨区搜索；开启 autoscaling 时，列表内所有机型必须保持相近的核数与内存，跨 VM 家族混用也不例外，原因是最小 CPU 与内存比决定有效的 container 大小。
• 属性对齐：Managed Spark 依据核数与内存推算系统属性，混用机型时可能需要显式覆盖 YARN 与 Spark 的资源配置，才能保持预期的 worker 行为。
• 两种写法：gcloud 侧用 --master-instance-selection 与 --worker-instance-selection 传 {"machineTypes":[...],"rank":N}；自动化管道侧用 Dataproc API 的 instanceFlexibilityPolicy.instanceSelectionList 字段，把容量策略写进 Airflow DAG。
• 配套的财务动作：用 Flexible Committed Use Discounts 在工作负载动态切到备选机型时维持成本可预测性。
• 落地清单：审计强耦合于特定机型家族或可用区的作业并列出可行替代；标准化首选与回退机型系列；统一 CPU 与内存比；显式声明 YARN 或 Spark 属性覆盖；为跑在 Spot 与高弹性容量上的 Spark 作业准备 shuffle 安全的写法。

行业影响

这条动态的价值在于它承认了一个通常被抽象层掩盖的事实：云的”无限弹性”在单一机型加单一可用区的约束下并不成立，容量缺货是常态而非例外。把它变成一张带 rank 的声明式列表，本质上是把一类过去靠自定义重试逻辑或人工干预兜底的运维事件，转成了一份可评审、可版本化的基础设施策略。对自建 Spark on Kubernetes 的团队，同样的思路可以落到 priorityClass 与多节点池的 fallback 顺序上。

相关链接

• How Yahoo optimizes resources with flexible VMs in Managed Service for Apache Spark（Google Cloud Blog, 2026-09-04）
• Managed Spark flexible VMs 文档
• Managed Spark autoscaling 文档

---

开放湖仓 9 月体检：Iceberg V4 正在改写运维脚本，Arrow 与 Polaris 撞上评审带宽上限

事件概述

Dremio 在 9 月 3 日发布《State of the Open Lakehouse, September 2026》，逐一点检支撑生产开放湖仓的五个 Apache 项目——Parquet、Arrow、Iceberg、Polaris、Ossie——截至 9 月初的状态。信息密度最高的是 Iceberg 部分：V3 已经是应当运行的生产目标，V4 尚未发布也尚未定稿，但几项会直接改写现有运维脚本的决策已经在社区收敛。

文章对 Iceberg 的年度判断是”五年来动静最大的一年”，并给出一个观察：Iceberg Summit 2026 在旧金山两天吸引了 600 多人与 70 多场分享，没有一场在论证该不该用 Iceberg，所有议程都默认你已经在跑，转而讨论规模带来的限制。

技术解析

• V4 的四项收敛决策：弃用 equality deletes 并禁止新写入（resolving them 意味着对每个候选行求值一次谓词，V4 选择了读者一侧）；让 V4 manifest 只保留 Parquet；REST catalog 增加 versioned loadTable endpoint，v1 endpoint 冻结在 v1 到 v3 结构，v2 endpoint 返回新客户端可读的内容；manifest list 增加三个 optional long 字段记录 data-file 字节总数，省去为获取表实时大小而打开并解压每个 manifest body。
• 两个直接的运维后果：带 row data 的 position deletes 已在 1.11 弃用，维护操作遇到这类文件时将从静默丢弃改为显式抛异常——上个月还跑得干净的 rewrite_position_delete 任务，升级后可能开始失败；依赖 equality deletes 做 upsert 的 Flink 或 Kafka Connect 管道，需要改走基于 deletion vectors 的 merge-on-read，或用固定的 compaction 节奏把 upsert 折叠进 data files，引擎侧跟进需要两到三个发布周期。
• 一致性测试独立成库：8 月底投票通过创建 apache/iceberg-verification，作为语言中立的 conformance fixtures 独立家园，结果为 five binding +1s 与 22 个非绑定票，非绑定投票名单几乎覆盖 Rust、Python、Go、Java 各实现的 maintainer，目标是把规范歧义变成失败的测试。
• Arrow 的两条不同性质的进展：2 月发布正式安全模型，覆盖 columnar format、C Data Interface 与 IPC format，起因是 Arrow 已经跨出组织边界（Flight endpoint 服务外部客户端、ADBC driver 指向合作方系统、IPC 文件从外部下载），reader 若信任 hostile buffer 里的 offsets 与 lengths 就是内存安全问题；8 月则提出把非 committer 的并发开放 PR 限制为 3 个，理由是”LLMs made writing pull requests cheap. Reviewing them did not get cheaper.”
• Polaris 的定位变化：2 月 18 日毕业为顶级项目，1.7.0 带来 Kafka event publishing 与 GCS principal attribution，并修掉 register endpoint 上一个 low-severity 的 CVE-2026-64640。文章给出的论证是——一旦五个引擎读同一批表，per-engine 访问控制就不再成立，策略只能待在 catalog 这个唯一每个引擎都要对话的组件里，catalog 由此从查找表变成控制平面。
• 两个已知的坑：PyIceberg 0.12 支持 vended credentials 但不自动刷新，短生命周期凭据下长任务会在中途因 credential expiry 失败，看起来像权限问题；Polaris 在启用 purge guard 且 PURGE_VIEW_METADATA_ON_DROP 默认为 true 时，view 开箱即无法 drop，需要先设 DROP_WITH_PURGE_ENABLED=true 或把 PURGE_VIEW_METADATA_ON_DROP 置为 false。

行业影响

把 Iceberg 的规范演进、Arrow 的 PR 上限与 Polaris 的 committership 讨论放在一起，浮现的是同一个约束：AI 把产出代码与 PR 的边际成本压到接近零之后，稀缺的变成了人的评审带宽与规范的一致性。Arrow 选择硬性上限，Polaris 选择把”持续的高质量评审”放在 PR 数量之前作为 committer 标准，Iceberg 选择把歧义固化成可失败的 conformance fixtures——三种应对，都是把原来依赖人自觉的环节变成显式规则。对使用者来说，最该立刻做的是审计两类存量：依赖 equality deletes 的流写入管道，以及 manifest 检查链路里基于 Avro 的工具。

相关链接

• State of the Open Lakehouse, September 2026（Dremio Blog, 2026-09-03）
• Apache Iceberg 规范

---

编者评

四件事看起来分属算子生成、Agent 接入、集群供给与社区治理，合起来却是一次判断位置的集体迁移：过去几年数据基础设施的主要矛盾是”能不能算得出来”，现在剩下的瓶颈几乎都长在别处——Databricks 卡在能否信任一个刚生成的 kernel，AWS 卡在哪个源该被允许直连，Yahoo 卡在特定机型特定可用区的瞬时缺货，Iceberg 与 Arrow 卡在代码产出的速度已经超过评审与规范能吸收的速度。四处瓶颈的共同点是它们都不再能靠堆算力解决，只能靠把判断本身变成一份声明式、可校验、可版本化的物件：一个同时对两边计时的 checker、一条写在系统提示里的路由规则、一张带 rank 的机型表、一个冻结在 v1 结构上的 endpoint。有意思的是代价并没有消失，只是换了位置——Proteus 的校验要在真 GPU 上隔离重复运行，目录优先模式要求数据先被编目，flexible VM 要求团队放弃对单一机型的确定性，而 Iceberg V4 的那些弃用会把上个月还干净的任务变成这个月的显式失败。判断被搬进平台之后，它从分散的运维事件变成了写在文档里的能力边界，这大概是本期四条动态最一致的一条线索。