英伟达称NIM全栈优化让Nemotron 3 Ultra在 4 张B200上吞吐提升 2.5 倍
英伟达技术博客给出的一组基准数据：在 4xB200、64K输入、76% KV复用、每用户 50 TPS的agentic负载下，开启NIM 2.0.12优化后系统吞吐从 718 tok/s升到 1997 tok/s，官方称这意味着同等交互性下可服务 2.5 倍以上并发用户。
AI解读：这条新闻的核心是一个吞吐数字：在英伟达自己设定的agentic基准下，同一套 4 张B200硬件，关掉NIM优化时系统输出 718 tok/s，开启NIM 2.0.12后是 1997 tok/s。官方给出的换算结论是，在保持每用户 50 TPS交互速度的前提下，可服务的并发用户数超过 2.5 倍。
真正受影响的是已经在生产环境部署大模型推理的团队：他们关心的不是单次生成本身快不快，而是同样几张GPU能同时服务多少人、延迟是否还守得住。英伟达给出的路径不是让人从零调参，而是用打包好的NIM推理微服务，把经过验证的配置、内核和调度策略直接跑起来。
NIM 2.0.12的优化来自几层相互作用的配置：面向Blackwell自动调优的MoE和Mamba内核、张量并行、前缀缓存与部分前缀匹配、Mamba状态缓存、调度与批处理参数、显存分配，以及MTP投机解码。英伟达明确说这些收益是组合产生的，不能把各项百分比简单相加。
一个容易被忽略的限制是：这组曲线只是起点。英伟达建议团队用自己真实的流量回放，画出延迟-吞吐的帕累托曲线，再选满足SLO的那个点。MTP的增量收益也取决于接受率和显存余量，并非所有负载都能拿到同样的倍数。
对普通读者来说，这件事不需要立刻行动。它的意义更像一个行业信号：推理部署的竞争正在从“模型强不强”延伸到“同一张卡能稳定服务多少人”，而这个环节的默认值正在被厂商打包成产品。
英伟达在技术博客中公布了一组Nemotron 3 Ultra的推理基准：在 4 张B200的系统上，面对 64K输入、400 输出、76% KV复用、每用户 50 TPS（约 20 毫秒ITL）的agentic负载，开启NIM 2.0.12优化后的系统输出吞吐为 1997 tok/s，关闭NIM优化的基线为 718 tok/s，官方称提升超过 2.5 倍，并把这解读为“同等交互性下可服务更多并发用户”。
这组数据来自英伟达自家的NIM优化栈及其基准口径，属于厂商自测结果，不是第三方独立复现。英伟达同时说明，公布的曲线是起点而非承诺，不同应用未必得到相同结果。
基准的具体口径：4 张B200、50 TPS/用户、76% KV复用
英伟达在文中固定了一套基准定义：硬件为 4xB200；agentic负载为 64K输入 / 400 输出 / 76% KV复用 / 每用户 50 TPS（对应 20 毫秒ITL）；模型支持 256K原生最大上下文。
在这个口径下，NIM Off基线为 718 tok/s，NIM On（2.0.12 优化服务栈）为 1997 tok/s，官方标注为基线的 2.5 倍。文章称，在每用户 50 TPS下，NIM开启后的曲线提供超过基线 2.5 倍的系统吞吐，直接对应相同交互性下更多并发用户。
- 硬件：4 张B200
- 负载：64K输入 / 400 输出 / 76% KV复用 / 50 TPS每用户（20 毫秒ITL）
- NIM Off基线：718 tok/s
- NIM On（2.0.12）：1997 tok/s，官方称 2.5 倍于基线
- 原生最大上下文：256K
2.5 倍由哪些优化叠加而成
英伟达强调，测得的增益来自相互作用的配置组合，而不是可以简单相加的独立开关。文章列出的主要优化层包括：面向Blackwell GPU自动调优的MoE和Mamba内核；张量并行把模型分布到四张GPU，专家感知执行提升MoE层利用率；前缀缓存避免重复计算已有上下文，部分前缀匹配在只有部分前缀命中时仍能复用，Mamba状态缓存按模型架构调优。
调度、批处理和显存方面，NIM调整了并发序列上限、批量token上限、块大小和GPU显存分配，目标是在不越过延迟目标的前提下让更多工作同时进行。此外，2.0.12 在同一优化栈上加入了MTP投机解码及其相关修复，英伟达说明其增量收益取决于接受率和可用显存余量。
- 精度与自动调优的模型感知内核（MoE、Mamba，面向Blackwell）
- 并行执行：张量并行 + 专家感知执行
- 前缀与模型状态复用：前缀缓存、部分前缀匹配、Mamba状态缓存
- 调度、批处理与显存：并发序列上限、批量token上限、块大小、显存分配
- MTP投机解码（2.0.12 新增，收益取决于接受率与显存余量）
官方建议的自测路径与已知限制
英伟达明确表示，公布的曲线不能保证每个应用都得到相同结果。它给出的做法是回放代表性流量，针对团队关心的延迟指标画出帕累托曲线，再在满足SLO的点中选择。文章建议固定镜像标签或摘要，使用NIM 2.0.12或更新版本；流量可用Mooncake格式的JSONL trace，或用受控的NIM请求捕获，并注意访问控制与敏感数据清洗；测量工具为NVIDIA AIPerf，示例给出了从并发 1 到 64 的扫描脚本。
对于 4 卡B200上的agentic负载，文章给出的示例配置是NIM_MODEL_PROFILE=vllm-nvidia-b200-nvfp4-tp4-pp1-throughput-90.0，并通过NIM_SPECDEC_ENABLE=1 开启投机解码。这些是官方推荐值，实际选择仍需按自己的延迟目标决定。
- 用NIM 2.0.12或更新版本，并固定镜像tag/digest
- 用Mooncake格式JSONL trace或受控捕获的NIM请求做代表性流量
- 用NVIDIA AIPerf回放流量并做并发扫描（示例为 1 至 64）
- 在满足SLO的点中比较输出吞吐，再决定部署配置
- 示例profile：vllm-nvidia-b200-nvfp4-tp4-pp1-throughput-90.0，并设置NIM_SPECDEC_ENABLE=1