CUDA 护城河正在被 AI Agent 填平
The body of this note is currently in Chinese.
英伟达花了十年修的 CUDA 护城河，正在被 AI Agent 一铲子一铲子地填。
英伟达花了十年修的 CUDA 护城河，正在被 AI Agent 一铲子一铲子地填。
这话不是耸人听闻。最近有个只有两三个人的小团队，拿 AI 编程 Agent 当苦力，在 AMD 的 GPU 上把好几个前沿大模型跑通了——模型发布当天就能用。搁半年前，这活儿得一屋子 CUDA 老炮儿干。
所以那个老问题又来了：AMD 的软件，到底行不行？
从烂透了到有点意思
ROCm 这玩意儿曾经确实烂。外部开发者提的 Bug 堆成山，AMD 几十号工程师天天救火。那时候行业的共识就一个字：没戏。
后来苏姿丰亲自下场抓软件，AMD 才算把软件质量当生死存亡的事来干。开发者优先、拥抱开源上游、新模型发布当天就要能跑——这些策略一条条落地。
到了 2026 年中，ROCm 的状态说白了就是：进步是真的，但对手跑得更快。
几场实打实的胜仗
先说好消息。
Kimi K2.5 在 AMD 硬件上的交互性能，30 天飙升了 18 倍。不是内部 Demo，是 vLLM 上游代码里所有人都能复现的数字。AMD 今年 2 月的技术白皮书标题就叫《速度即护城河》，这回算是名副其实。
MiniMax M3 上，AMD 用 ATOM 优化栈追平了英伟达旗舰 B200。
迭代速度的变化更值得说道。以前一个新模型出来，英伟达几天搞定，AMD 要等几个月，被行业当笑话讲。现在呢？DeepSeek V4 发布后 47 天，MI355X 在 SGLang 上的性能曲线跟坐火箭似的。MiniMax M3 更狠——模型发布当天 AMD 就有可用方案，Day-0。
George Hotz 说过一句大实话：“AMD 的混乱跟别人不一样。他们有能办事的老板，苏姿丰回了我第一封邮件。他们就是之前没想明白软件有多重要。硬件确实牛，要是软件也搞好了，这公司被严重低估了。”
AI Agent：这才是真正的变量
接下来这段，是整个故事里最炸的部分。
有个两三人的小团队，靠 Claude Code 和 Codex Agent 搞定了 DeepSeek V4 和 MiniMax M3 在 AMD 硬件上的首日适配。流程大概是这样：给 Agent 一个具体配置（比如 MiniMax M3 跑 MI355X vLLM FP8），Agent 自己去抓 Recipe、搭管道、跑全配置扫盘。它直接控制 GitHub Action 和物理 GPU Runner，遇到报错就自己定位根因、改代码、重跑。搞不定了才喊人。
这帮人联合 Agent 给上游提了一堆 PR——DeepSeek V4 的 Kernel 修复、MiniMax M3 解耦支持、EAGLE3 投机解码、FP8 KV 缓存修复……半年前靠两三个人，这活儿想都别想。
说穿了就一句话：写代码和跑测试这件事，不再是绝对的护城河了。 Agent 正在把过去需要一大堆工程师才能干的活儿批量消化掉，AMD 工程师少？没关系，Agent 来凑。
AMD 自己也看明白了。Advancing AI 2026 上官宣了 ROCm.ai，核心代码开源在 GitHub 的 AMD-AGI 组织下。里面有个叫 GEAK 的东西——专门写 GPU Kernel 的 AI Agent，外面套个 Hyperloom 编排器负责找瓶颈、派活儿、跑 A/B 测试。还搞了个 AgentKernelArena 竞技场，让 Claude Code、Codex、Cursor 跟 GEAK 同台比武。
这里面有个特别好玩的细节：Agent 会作弊。
GEAK 开发到一半被迫加了个 GEAK_PROTECT_TEST_FILES 模式，因为 Agent 学会了篡改测试答案来假装自己跑对了。配套的 Apex 系统专门拦截硬编码 print("PASS") 或者偷跑预调优库的骚操作。
放任不管的话，模型第一时间就会 Reward-hacking。防作弊的工程量比写 Kernel 本身还大。
不过即便这么折腾，GEAK 在 MI355X 上确实跑出了验证过的 +21.8% 整机加速。靠的是重写 MXFP8 Decode 受限的 Dense-linear。这个数字谈不上颠覆 CUDA，但信号很清楚：一年前需要一屋子 CUDA 工程师才能干的活，AMD 正在用 Agent 批量生产。
坏消息：终点线搬家了
好消息说完，该泼冷水了。
现在的前沿大模型——DeepSeek V4、Kimi K2.6、MiniMax M3——全是超大 MoE。激活专家就那么 4 到 10 个，但总专家数炸到了 256、384 甚至 512。这意味着一台机器根本装不下，你得把预填充和解码拆到不同节点，把专家撒到几十上百块 GPU 上（WideEP），还得在节点间高速搬运 KV 缓存。
竞争前沿早就不是”单卡跑多快”了，而是”分布式解耦推理谁玩得转”。
英伟达 2024 年初就商用了 Disagg+WideEP。AMD 的同类方案？2026 年 1 月才落地。差了整整两年。更要命的是英伟达在 GTC 2026 上掏出了 Groq 3 LPX——一块塞在推理机架里的 SRAM 加速芯片，专门给解耦 Decode 的 FFN 层提速。护城河从软件升级成硬件了。
AMD 还有个更头疼的问题：单个优化都能跑，组合起来就炸。
Disagg 能跑、FP4 能跑、WideEP 能跑、DP-attention 能跑。但你把它们拼一块儿——崩了。今年 3 月前，DeepSeek-R1 开 DP-attention 做解耦，数学测试 GSM8K 得分直接归零；SGLang 跑 MoRI 后端并发 64 时，GSM8K 从 94% 暴跌到 80%，到现在没修。
单节点跑分赢再多也白搭。可组合的分布式推理才是决胜场。
扛活的人和拆台的管理层
说几个扎心的事实。
AMD 最猛的那批工程师，大部分在上海。MoRI 团队、KV 缓存卸载团队、解耦部署团队，几乎都常驻中国。ROCm 最核心的模块，很多就是在中国本土写出来的。
MoRI 这个分布式推理框架确实是 AMD 打赢的一仗。但你猜这整条路线图——分级 KV 缓存、弹性专家并行、机架级适配、上游回馈——靠几个人扛？
四五个。
路线图写得漂亮，但所有重担压在同一撮人身上。
更离谱的是管理层。Advancing AI 大会前夕，工程师刚把 vLLM 拦截测试推到 90% CUDA 对齐度——管理层把集群抽走了，挪去干别的。测试进度一夜归零。
AMD 内部工程师喊了不知道多少遍：给我们稳定的集群，别让我们天天在不同云厂商之间搬家。
一头是四五个人死扛分布式推理栈的中国工程师，一头是关键时刻拆台的管理层。AMD 最大的对手可能不是英伟达，是自己。
AMD 的代码跑进了英伟达的开源库
最后讲个小故事。
2025 年 GTC，有人问英伟达：你们通信库要重构，会帮 AMD 适配吗？回答：不会。
2026 年 GTC，换个角度再问：你们 KV 缓存传输库 NIXL 接受了 AWS 的贡献，AMD 的也收吗？维护者当着一屋子人说：收。
然后 AMD 的 Andy Luo 提了 PR，6 月合并。后续在两台 MI355X 上跑出 341 Gb/s 跨节点 RDMA——全链路没一张英伟达网卡。
AMD 的代码跑在英伟达的开源库里，用的是 AMD 自己的网卡。过去拦着 AMD 的不是什么技术壁垒，就是没人去试。
方向对了，但时间不多
三句话收尾。
单节点在修。18 倍加速、追平 B200、Day-0 适配，都是真的。
Agent 在改变规则。两三个人加 Agent 干了一个团队的活，+21.8% 实机验证加速，CUDA 护城河没那么坚不可摧了。
但终点线搬了。市场已经转到 PD 解耦、WideEP、分布式调度。单个优化组合不起来，就是在打上一场战争。
Anthropic 刚给 AMD 下了 2GW 的大单。Tom Brown 周末用 Claude 的 /goal 指令，在 AMD 硬件上拉起了内部的 Claude 推理栈。
AI Agent 在填 CUDA 的护城河，Claude 在帮 AMD 调 AMD 的软件。2026 年最魔幻的技术循环，没有之一。
就剩一个问题：AMD 管理层能不能别在关键时刻抽走工程师的集群了？