CUDA 护城河正在被 AI Agent 填平
英伟达花了十年修的 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 管理层能不能别在关键时刻抽走工程师的集群了？