在 AWS 部署 Nemotron 多模态推理模型

Nemotron 3.5 Super VL 把推理、工具调用和视觉理解放进同一个开放模型，AWS 则给出了在 Kubernetes 上部署、验证和压测它的参考方案。对程序员来说，最有用的部分是：怎样判断一套模型服务能在延迟要求内接住多少请求。

原文的结论是，模型架构、推理部署方式和容量规划需要一起考虑。120B 参数不代表每次都做同等规模的计算，拆分推理阶段也不保证自动提速，最后还得靠并发压测曲线做决定。

只激活 12B 参数，为什么仍然需要大显存

Nemotron 3.5 Super VL 从 Nemotron 3 Ultra 蒸馏而来，总参数量为 120B，每个 token 激活 12B。它使用混合专家模型（MoE），每一步只选择部分专家参与计算，所以单个 token 的计算量可以接近更小的模型。

但这里有个容易误读的地方：激活参数少，省的是计算，不代表完整权重的显存占用也按比例缩小。 原文明确说明，GPU 显存仍需容纳全部权重，不能把它当成普通 12B 模型估算硬件。

它还交错使用 Mamba-2、attention 和专家层，并通过 RADIO 视觉编码器处理视觉输入。Mamba-2 在生成时维护固定大小的状态，其状态内存不会像注意力的 KV cache 那样随序列长度增长。这有助于控制长上下文成本，但模型仍含 attention 层，不能据此推断整个服务的内存都与上下文长度无关。

模型支持最高 1M tokens 上下文，接收文本、图片、文档和视频，提供 BF16 与 NVFP4 检查点；递归共享的 Multi-Token Prediction（MTP）头支持原生推测解码。后者可以理解为提前预测多个 token，再进行验证，用来加快生成，不过原文没有给出它单独贡献的加速数据。

NVIDIA 公布了权重、训练数据集和后训练配方，方便使用方定制并控制部署基础设施。文中引用的成绩包括 Hermes Bench 的 63.44%、LangChain 智能体评测的 87.05%，以及 CharXiv 图表推理评测的 80.8%。这些是 NVIDIA 报告的数据，不能当作 AWS 在本次部署中重新测出的结果。

部署到 EKS，实际要搭哪些东西

参考实现覆盖 Amazon EKS、EKS Auto Mode 和 Amazon SageMaker HyperPod EKS，三种编排选项使用相同的模型部署 Kubernetes 清单。EKS Auto Mode 会代管集群扩缩容、GPU 和 EFA 支持，但应用侧仍要决定服务拓扑与容量。

基础设施的职责划分很明确：控制平面承载 Kubernetes API；CPU 节点运行系统和测试 Pod；GPU 节点运行模型；Amazon ECR 保存容器镜像；共享的 Amazon FSx for Lustre 保存模型权重；Elastic Fabric Adapter（EFA）连接 GPU 节点。

模型服务使用 NVIDIA Dynamo，文章同时涉及 vLLM。Dynamo 支持两种方式：把服务聚合在单个节点上，或者把 prefill 和 decode 分散到不同节点。prefill 负责处理输入、建立生成所需的上下文状态，decode 负责逐步生成输出。对于视觉语言模型，图片和视频编码还可以独立放到另一个节点。

这样拆分的理由，是不同阶段的资源需求和负载变化可能不同。长文档输入会增加输入处理压力，长回答会持续占用生成资源，分别部署便于分别扩容。不过，跨节点通信也进入了性能账本，拆得更细是否划算，需要实测。

作者团队在 p6-b200.48xlarge 和 p5en.48xlarge 上验证了架构，前者配备 8 张 NVIDIA B200，后者配备 8 张 NVIDIA H200。尽管原文有「最低 GPU 配置」这一节，却没有在提供的正文中列出不同精度、上下文长度对应的最低配置。这里能确认的是验证平台，不能据此认定最低门槛。

容量规划要看延迟曲线，不能只看 TPS

原文把验证分成两步。

先用 NVIDIA Collective Communications Library（NCCL）的 all-reduce 微基准测试检查集群通信。测试期间观察所有 GPU 是否有利用率、所有 EFA 适配器是否有流量，可以确认通信链路是否按预期工作。这一步通过，并不代表模型接口已经满足业务延迟要求。

然后使用 NVIDIA aiperf 测量三个指标：首 token 延迟 TTFT、相邻 token 间隔 ITL，以及每秒生成 token 数 TPS。对聊天和 AI 编程界面来说，TTFT 决定用户要等多久才看到回答开始，ITL 则影响回答开始后是否持续流畅。

关键是逐步提高并发，把延迟和吞吐量一起画出来。作者报告，两节点上的聚合与拆分部署比较中，TTFT 有降低，ITL 大致相同。但提供的文字没有清楚交代较低 TTFT 对应哪种配置，也没有列出完整测试条件，不能从这一句直接得出「拆分一定更快」。

原文给出的容量规划示例，是把 TTFT 小于 600 ms、ITL 小于每 token 100 ms 画成两条预算线，找到同时满足两者的最右侧测量点。示例中是 c32，对应约 320 tokens/s。原文把 600 ms 括注为约 1 秒并不准确，实际是 0.6 秒，设置阈值时应以数值为准。

可用容量，是满足延迟目标时的吞吐量。

接着用目标 TPS 除以单副本吞吐量，估算需要多少组 prefill-decode 实例。这个结果只是起点，还需要结合负载波动验证。调整精度、张量并行／流水线并行配置（TP/PP）、部署方式，或者升级 Dynamo、vLLM 后，都应该重跑并发扫描。

作者还给出一个排查方向：ITL 上升时关注 decode 容量，TTFT 上升时关注 prefill 容量。它适合作为初步判断，具体扩容前仍要结合资源利用率定位瓶颈。

我的判断

这篇最值得借鉴的是评估方法：先确认通信正常，再用业务延迟预算约束吞吐量，最后讨论部署拓扑。它比只展示一个峰值 TPS 更接近线上服务的实际决策。

模型选型部分则需要保留判断。多模态、工具调用和开放训练材料，确实让统一处理代码、网页资料、文档图表成为可能，但原文没有给出这些业务任务的端到端对照，也没有证明它比多个专用模型组合更省钱。

同样，文章没有给出足够完整的输入输出长度、视觉输入规模、精度和成本信息，约 320 tokens/s 只能视为示例配置的结果。聚合与拆分如何选，现有数据也不足以形成普遍结论。

如果团队已经使用 AWS、Kubernetes 和多 GPU 推理，这套方案有直接参考价值。如果日常只是通过 API 给前端或 Node 应用增加 AI 功能，文章提供的证据还不足以支持迁移到自托管大模型；应先确认业务确实需要这类控制能力。

能拿来做什么

• 给聊天或 AI 编程界面制定体验指标时，把「多久开始回答」和「开始后生成多快」分开记录，分别对应 TTFT 和 ITL，再按真实请求压测。
• 评估自托管方案时，同时核算完整权重、上下文与并发所需资源，不要用每 token 激活 12B 推导显存需求；本文没有给出最低硬件配置。
• 已在 EKS 上运行模型的团队，可以先做 NCCL all-reduce 验证，再用 aiperf 扫描并发，把满足服务等级目标（SLO）的吞吐量作为容量依据。
• 对同时处理代码、文档和图表的智能体，先拿自身任务验证正确率与延迟，再决定是否合并到一个多模态模型；文中的基准分数可以作为候选依据。