解析英伟达混合架构如何应对代理长任务

Nvidia 把 Mamba 和 Attention 放进同一个模型，瞄准的是编程 Agent 的长期运行成本：一轮轮读取文件、执行命令之后，历史上下文越来越长，GPU 可能先被缓存占满，计算能力却还没用尽。

原文围绕 Nemotron 3.5 Super 和 Lightning，串起了模型架构、推理引擎和 Agent 评测三个问题。最值得程序员带走的判断是：长任务能否跑得快、跑得稳，既取决于模型，也取决于缓存怎样复用、工具怎样接入。

为什么 Agent 会先撞上缓存墙

Nemotron 3.5 Super 是一个混合专家模型（Mixture-of-Experts，MoE），总参数为 1200 亿，每个 token 激活 120 亿参数；Lightning 总参数为 300 亿，每个 token 激活 30 亿参数。Super 在 SWE-bench Pro 上达到 51.78%，超过 Nemotron 3 Ultra，激活参数量约为后者的 1/4.6。

这些数字之外，原文更关心两款模型共同采用的交错混合架构：Mamba-2 状态空间层、稀疏 Attention 层和 MoE 路由。

编程 Agent 的输入与普通聊天不同。一个任务经常持续 15 到 30 轮，每轮都可能带上系统提示、工具定义、仓库目录、编译输出和 git diff。Nvidia 用一个代理负载做评估：共 20 轮，每轮输入 2,048 tokens、输出 1,024 tokens。纯 Transformer Attention 要为不断增长的历史保存键值缓存（KV cache），多名开发者同时使用时，显存容量和内存带宽就可能先成为瓶颈。

Mamba 用固定大小的循环状态压缩历史，序列处理复杂度随长度线性增长，其循环状态占用不会跟着历史长度持续增加。但压缩有代价：查找前面某个函数签名、复制变量名，或者定位 50 行之前的信息，需要精确检索，Attention 通常更擅长。

两者交错的目的，就是让 Mamba 承担部分历史处理，让 Attention 保留精确访问上下文的能力。这里的固定内存指 Mamba 的循环状态，不能理解为整个混合模型的缓存恒定不变。

为什么换了架构，还得修改 vLLM

生产服务通常需要前缀缓存（prefix caching）：系统提示和共享仓库上下文已经算过，就尽量复用。

纯 Attention 模型比较容易处理。vLLM 可以把 KV cache 切成小块，新请求命中已有前缀时，直接挂上对应缓存块。混合模型要从某个位置继续执行，却必须同时拿到该位置的 Attention KV cache 和 Mamba 循环状态。

后者保存的是整层累计下来的历史摘要，远大于单个 token 的 KV 条目。原文称，在 vLLM 对齐两类缓存组的字节大小时，一个 Mamba 缓存页约相当于 4,000 tokens 的 Attention KV cache。因此，引擎不能在每个细小位置都保存循环状态，只能选择较粗的边界设置检查点。

麻烦出在回退。推测解码拒绝草稿 token，或者 Agent 分支需要回到先前位置时，落点未必刚好有 Mamba 检查点。引擎可能需要拆分预填充（prefill），先运行到边界，再为剩余 token 增加一次前向计算，重复承担 kernel 启动和张量并行通信开销。

原文提到，Nvidia 为此在 vLLM 的 PR 57329 中加入内部 prefill 检查点。

混合架构能否兑现吞吐收益，取决于推理引擎是否处理好了状态复用和回退。

同一套权重，为什么跑分还会变

报告第 3.10 节用六套 Agent 执行框架（harness），测试 Nemotron 3.5 Super 在 SWE-bench Pro 和 Terminal-Bench 2.1 上的表现。

这里的 harness 可以理解为包在模型外面的执行程序：它负责组织提示、调用工具、解析输出、重试和处理错误。同一套权重放进不同执行程序，成绩会变化，而且六套框架在两个基准上的排名顺序发生了翻转。

原文列出的两个结果是：Claude Code 在 SWE-bench Pro 上取得 49.45%，Codex 在 Terminal-Bench 2.1 上取得 61.80%。它们对应不同测试集，不能直接拿来判断哪套框架更强，也不能与前面的 51.78% 混在一起比较。

原文还举例称，工具输出分隔符不符合模型预期，可能影响调用；清理命令之间的上下文，可能让普通模型的成绩提高十个百分点。但文中没有给出这个十个百分点对应的具体实验，应把它视为作者的经验性说明。

对日常使用 AI 编程工具的人，这个区分很实际：Agent 失败时，问题可能出在提示组织、工具反馈或上下文管理，不能只靠换模型排查。

我的判断

我认同原文把关注点从参数量移到完整运行链路。编程 Agent 会持续积累历史，显存占用、缓存命中和回退开销确实应该进入部署评估。

但它还不足以证明混合架构在一般团队里更划算。Nvidia 报告的是 GB200 系统上的结果：每 GPU 输出吞吐达到 4,856 tokens/s，同时单用户生成速度保持在 50 tokens/s 以上。原文没有交代足够的并发、精度和成本条件，也没有提供普通显卡上的对应数据，不能直接据此估算本地部署收益。

纯 Attention 配合上下文裁剪、摘要或检索，也能控制历史长度。这些做法可能丢失信息，却不要求更换模型架构。原文没有提供同条件对照，因此尚不能判断哪条路线更适合具体团队。

另外，单用户生成速度并不等于整轮任务耗时。预填充、排队和工具执行都会影响等待时间。作者用「开发者不愿等两分钟检查目录」解释交互门槛，但 50 tokens/s 本身无法保证这一点。

能拿来做什么

• 评估编程 Agent 时，加入连续多轮任务。可以参考原文的 20 轮负载，记录上下文长度、显存增长、首 token 等待时间和完整任务耗时。
• 比较模型时，固定工具定义、输出格式、重试策略和上下文裁剪规则，并记录 harness 配置，避免把执行框架差异算成模型能力差异。
• 部署混合模型前，核对推理引擎对前缀缓存、循环状态检查点和回退的支持；使用 vLLM 时，可以从原文提到的 PR 57329 追查相关实现。
• 排查 AI 编程工具失败时，先保留工具调用与输出记录，检查模型是否误读编译日志、命令结果或被裁剪的上下文，再决定是否更换模型。