NVIDIA Nemotron EKS 部署让多模态智能体纳入团队掌控

AWS 于 10 月 29 日发布了 NVIDIA Nemotron EKS 部署指南，为团队提供了一条在 Kubernetes 上服务一款 1200 亿参数多模态模型的路径。Kubernetes 是用于协调容器化应用程序的系统，可提供部署控制能力。团队仍需决定，这种控制能力是否值得承担相应的基础设施责任。

该指南涵盖了在 Amazon Elastic Kubernetes Service、EKS Auto Mode 和 Amazon SageMaker HyperPod EKS 上部署 NVIDIA Nemotron 3.5 Super VL。其核心选择关乎运维责任：AWS 承担多少基础设施工作，以及多少责任仍由应用团队负责。

此前，NVIDIA 于 10 月 15 日宣布该模型，AWS 则于 10 月 16 日宣布其已在 SageMaker JumpStart 上可用。JumpStart 提供基于目录的部署路径。Kubernetes 指南面向希望更直接掌控服务架构、软件配置和工作负载放置的团队。

对开发者而言，其意义不止于又一个可用模型。多模态智能体是能够理解不同输入格式并使用工具的软件，它会对计算、网络和应用设计提出相互关联的要求。将这些组件置于受控环境中，能让工程师拥有更多选择，但也会使部署决策更具影响。

NVIDIA Nemotron EKS 部署扩展服务选项

AWS 已记录了一条额外部署路径，而非宣布新的模型发布。

在评估变化时，这一区别至关重要。10 月 29 日的多模态部署指南介绍了一个参考实现，覆盖标准 EKS、EKS Auto Mode 和 HyperPod EKS。AWS 表示，该模型的部署清单在这些编排选项中保持一致。

该架构采用 NVIDIA Dynamo——一个用于协调推理服务的框架——以及运行语言模型的引擎 vLLM。推理是指利用训练完成的模型生成输出。AWS 描述了同节点部署服务，以及将处理阶段分布到多个节点的方案。

AWS 表示，已在 p6-b200.48xlarge 和 p5en.48xlarge 实例上验证该架构，二者分别配备 NVIDIA B200 和 H200 加速器。这说明了 AWS 测试过的配置，但并不代表其在所有受支持实例、工作负载或软件版本上均具备通用性能。

对于已有 Kubernetes 团队而言，该指南为评估提供了具体起点。工程师可以在将模型引入应用之前审视部署边界，也可以明确哪些既有运维实践适用，哪些需要调整。

当组织已在计划中的模型端点附近运行应用服务时，这一点尤为相关。部署方案应说明模型如何接入该环境，并明确由谁负责发布、监控故障，以及调查跨越服务边界的请求。

参考实现的存在让这些讨论更加具体。评审者可以讨论实际架构，而不是批准一个抽象的“自托管 AI”计划。不过，原样采用示例仍会留下重要的应用决策未解决。

以读取技术文档并调用公司工具的内部研究助手为例，其模型端点只是服务的一部分。检索、权限、来源追踪和工具执行仍需明确归属。

因此，NVIDIA Nemotron EKS 部署应与模型评估一同纳入应用架构评审。关键问题在于，该部署路径是否支持预期工作流，以及负责维护它的团队。

这也厘清了它与 SageMaker JumpStart 的关系。AWS 早先的公告已通过其目录提供模型访问；更新后的指南则提供了另一条运维路径，带来不同的定制机会和责任划分。

两条路径都不会天然适合所有组织。团队应将选择关联到具体需求：服务配置、集成边界或运维实践。否则，更多控制权只会变成缺乏明确应用收益的工作。

稀疏架构改变计算资源方程

Nemotron 的活跃参数数量描述的是计算量，而部署规划还必须考虑完整模型。

NVIDIA 的量化模型卡介绍了一种混合专家架构，它会将每个 token 路由至选定的模型组件。Token 是模型处理文本的基本单位。该模型包含 1200 亿参数，每个 token 有 120 亿活跃参数。

模型卡描述了 Mamba-2 与注意力层的混合架构：Mamba-2 是一种维持循环状态的序列架构，注意力层则可连接不同输入之间的信息。视觉编码器会将视觉材料转换为语言系统可处理的表示形式。支持的输入包括文本、图像和视频，输出为文本。

NVIDIA 列出的上下文容量最高可达 100 万 token。上下文容量指模型可纳入考量的输入和对话材料。这个上限应为测试提供参考，但不应被视为对实际并发能力或响应时间的假设。

模型卡还区分了特定硬件配置。其紧凑型部署示例不同于 AWS 指南中更大的最低配置。这些文档不应被视为可以互换的容量规格。

对采购方而言，这一区别可避免一种常见的规划捷径：将稀疏计算等同于较小的部署占用。活跃参数数值有助于说明模型设计，却不能决定应用在负载下需要多少内存。

文档助手可以说明这一问题。针对单页的简短提问，与跨越长篇文档的请求，对服务提出的需求不同。两者使用相同的模型权重，但处理模式和临时内存需求仍有差异。

实际含义是，应评估工作负载分布。团队应纳入预期的文档、图像尺寸、对话长度和输出模式。仅看平均请求，可能会掩盖主导资源消耗的情况。

精度带来另一项选择。BF16 以 16 位格式存储数值，而 NVFP4 则对选定模型计算和存储采用更低精度的表示方式。NVIDIA 提供了面向不同部署需求的检查点。

较低精度值得在应用层面进行验证。收据提取工作流可能容忍部分措辞变化，但要求交易字段完全准确。研究工作流则可能更关注结论是否仍有引用证据支撑。

这些差异意味着，单一质量评分不足以覆盖每一项部署决策。评估者应在比较配置之前定义哪些错误最重要。否则，较小的内存占用可能看似很有吸引力，却无法揭示其对实际任务的影响。

对最大上下文也应保持同样谨慎。能够接受大输入的系统仍需要进行证据筛选。即使请求未超出技术限制，提供无关材料也会使审查更加困难。

对于构建可搜索知识库的工程团队而言，文档组织仍是答案质量的一部分。模型容量不能替代来源维护、访问规则或清晰的证据边界。

架构解释了为何该模型值得评估；工作负载测量则决定哪种配置适合特定服务。将这两类决策分开，有助于团队避免将模型规格当作生产容量计划。

AWS 的集群选择改变运维责任

在标准 EKS、Auto Mode 和 HyperPod EKS 之间的选择，应遵循团队的运维需求。

标准 EKS 提供了部署指南所述的熟悉 Kubernetes 路径。对于已维护专用集群配置的团队而言，其相关性很直接：他们可以在既有运维环境中评估模型。

当工程师了解现有部署流程时，这种连续性具有价值。但它也要求诚实评估可用的专业能力。熟悉应用容器并不自动解决涉及加速器容量或分布式模型服务的所有问题。

EKS Auto Mode 改变了管理边界。AWS 的集群基础设施管理文档描述了托管计算扩缩容、网络、负载均衡、存储集成和 GPU 支持。GPU 即图形处理单元，是此处用于模型计算的加速器。

AWS 还表示，客户仍需负责应用容器，包括可用性、安全性和监控。客户仍控制其网络环境和集群配置。因此，Auto Mode 会委托基础设施任务，同时保留应用责任。

对于模型服务而言，这一边界应有明确负责人。必须有人决定新的服务镜像是否可接受；也必须有人调查失败请求，并判断模型更新是否改变应用行为。

自动化基础设施管理无法回答这些问题。它能够减少围绕这些问题的工作，从而可能让团队专注于评估。其收益取决于托管配置是否满足工作负载要求。

HyperPod EKS 则处理另一组运维问题。AWS 的HyperPod 编排文档描述了连接至 EKS 控制平面的托管计算集群；控制平面是协调集群操作的组件。它支持推理与训练工作负载并行运行。

该文档还介绍了健康检查、故障节点恢复以及与监控工具的集成。当组织管理大量机器学习基础设施时，这些功能为评估 HyperPod 提供了理由；但它们并不能消除验证应用恢复能力的需要。

节点恢复与用户工作流恢复是不同结果。应用可能需要重新提交请求、重建对话状态，或避免重复执行工具操作。这些行为需要超越集群健康机制的设计。

压力会同时落在平台团队和应用所有者身上。平台团队需要能够维护的服务模式；应用所有者则需要在底层服务发生变化或不可用时仍具备可预测的行为。

因此，基础设施决策应包括预期的故障体验。评审者应询问未完成响应会如何处理，以及客户端如何识别可重试故障。他们还应明确由哪个团队调查各类事件。

对于正在评估 NVIDIA Nemotron EKS 部署的组织而言，有价值的比较重点在于责任划分，而非功能数量。最优选择是既能满足应用需求，又具有组织能够承担的运维负担的方案。

规模较小的团队可能更看重将基础设施管理委托出去。专业的平台团队可能需要更多配置控制权。已经在使用 HyperPod 的组织，则可能优先考虑与现有机器学习运营流程保持一致。

这些是决策标准，而非普适性建议。已发布的指南提供了部署选项。组织必须将某个选项与其人员配置、可靠性预期和应用架构关联起来。

Dynamo 将相互竞争资源的处理阶段分离

分布式服务带来了调优选项，而每个选项都需要来自目标工作负载的证据支持。

NVIDIA 的分布式推理框架支持解耦服务，将不同的推理阶段部署在独立资源上。其文档还介绍了路由、缓存管理和扩缩容组件。Dynamo 可与 vLLM、SGLang 和 TensorRT-LLM 配合使用，这些都是执行模型的替代引擎。

这为 AWS 示例提供了更广泛的背景。服务引擎只是更大系统中的一个组件。选择某个引擎并不能解决请求路由、保留状态、资源分配或服务如何应对需求变化的问题。

这些阶段承担着不同职责。Prefill 处理传入的提示词，而 decode 逐词元生成响应。视觉编码会在语言模型使用图像或视频输入的表征前，对其进行处理。

分离各阶段可以让工程师独立审视各自的需求，但也会引入数据必须传输、故障必须处理的边界。部署决策应说明这些边界为何有利于应用。

以拟议中的文档审查助手为例：部分请求要求从图像中提取简短字段，另一些则要求对跨文档内容作出深入解释。若将这些请求视作相同类型，容量结果将难以解读。

评估分离阶段的团队应询问请求将时间花在哪里。如果输入处理占主导，仅改变输出生成容量就无法解决真正的约束。如果生成答案占主导，增加输入容量的收益可能很小。

此时，可观测性——即通过测量理解系统行为的能力——成为架构的一部分。服务需要通过测量区分等待、输入处理、生成和外部工具活动。

面向用户的延迟可能出现在模型服务之外。研究代理可能在等待搜索服务或文档库。改进模型生成并不能消除这种延迟，因此评估应保留完整的请求时间线。

缓存同样需要结合具体场景理解。缓存会保留可复用的计算结果或数据，以避免重复工作。反复出现的系统指令，与在独立请求中到达的无关文档，创造的是不同的复用机会。

包含重复提示词的基准测试应披露这一模式。否则，读者无法判断其结果是否适用于重复性很低的工作负载。同样的原则也适用于比较预热服务与刚启动的部署。

生态系统比较仍然比一般的模型竞赛更为狭窄。Dynamo 对替代引擎的支持表明，分布式服务是一种更广泛的基础设施方法。但这并不能证明每个引擎都支持该模型的相同配置。

工程评审应保留这一区别。受支持的框架、受支持的模型和经过测试的组合，是三项不同的主张。在判断某一配置是否已准备好接受评估时，特定版本的文档至关重要。

对于 NVIDIA Nemotron EKS 部署，这形成了清晰的决策顺序：确定应用工作负载，识别约束条件，再针对该约束评估服务部署方式。只有当测量结果显示出有价值的成果时，复杂性才值得引入。

共置部署仍是合理的比较基线。分布式方案需要通过与应用相关的收益来证明其额外协调成本的合理性。这种比较除响应测量外，还应包括恢复行为和运维工作量。

模型基准测试无法解决工作流可靠性问题

供应商评估有助于识别候选方案，但企业代理需要来自自身任务的证据。

NVIDIA 的多模态推理模型公告报告了 Hermes Bench 上的 63.44% 和 LangChain 评估中的 87.05%。公告还报告了 CharXiv 上的 80.8%，后者是一项图表推理基准。这些是 NVIDIA 报告的结果，而非对 AWS 部署的独立验证。

该公告介绍了 Ramp 如何使用该模型将收据提取为结构化字段。NVIDIA 报告了该工作流预期的吞吐量和延迟改善。合作伙伴示例中的预期结果应与另一组织中的实测结果保持区分。

NVIDIA 还将较小的 Nemotron 模型定位为适用于高量文本工作，并将 Nemotron 3 Ultra 定位为适用于复杂规划。这一比较支持对模型系统进行评估，但并不能证明 Super VL 应处理所有请求。

这一区别之所以重要，是因为任务成功包含多个组成部分。收据工作流需要正确的字段、可接受的格式，以及对不确定输入的恰当处理。流畅的解释无法弥补错误的付款金额。

文档代理面临不同挑战。它可能正确读取图表，却从周边材料中得出缺乏支持的结论。评估应区分视觉提取、解释以及最终决策。

工具使用又增加了一道边界。模型能够提出工具调用，并不意味着应用应当执行它。周边系统需要具备权限、验证以及处理不完整参数的规则。

这些考虑是评估要求，而非某项特定 Nemotron 缺陷的证据。所审阅的供应商来源并未为每一种企业工作流提供普适性结论。读者不应以信心或假定的失败来填补这一空白。

有价值的评估案例包括存在歧义的文档和信息缺失的情形。模型应有明确方式表达不确定性。审查者应了解，对于该应用而言，未回答的问题是否优于缺乏依据的答案。

测试集还应区分熟悉示例与留出案例。留出案例是未被用于定制和调优的示例。没有这种区分，团队可能会将对已知示例的适应误认为更广泛的工作流可靠性。

性能比较同样需要清晰的边界。不同配置应采用相同的文档、输出要求和推理设置。否则，更快的生成速度可能只是因为所要求的答案更短，或任务更简单。

推理设置值得关注，因为它们会改变模型处理请求的方式。更深入的推理应通过更好的任务结果来证明其资源消耗的合理性。部署不应假定最复杂的设置总能使用户受益。

人工审查同样应纳入比较。持续需要修正的自动化输出，会在流程的其他环节制造工作量。评估者应记录这些工作，而不是在模型完成生成时停止测量。

因此，证据缺口是明确的。这些公告确立了模型产品、已报告的评估、合作伙伴场景和部署选项。它们仍要求每位潜在采用者在其目标服务中验证质量、性能和恢复能力。

下一步证据应将容量与已完成工作关联起来

最有价值的后续证据将展示在真实运行条件下可复现的结果。

第一个值得关注的信号是可复现的部署测量。在未来数月中，有价值的报告应明确软件版本、模型精度、硬件、请求模式和并发量。并发量是指同时处理的请求数量。

如果其他团队能够复现这些结果，这类报告将强化更广泛采用的理由。它们也会使局限性更容易解读。与狭窄配置相关的结果，只要其边界清晰，仍然具有价值。

重要结果是在既定响应要求下的服务容量。单独的峰值吞吐量数字会让读者只能猜测用户体验。报告应将生成输出与等待时间、请求完成情况和观察到的故障关联起来。

第二个信号是定制后的特定领域质量。一份可信的后续报告应在留出工作上比较初始模型与适配版本，并披露任务定义及仍然存在的错误。

若改进在训练示例之外仍能持续，这些证据将支持 NVIDIA 的专业化论点。若收益在陌生文档或真实工具交互下消失，则会削弱采用理由。无论结果如何，都能帮助买方作出更好的决定。

对于文档工作流，审查者应超越汇总准确率。他们需要了解哪些字段或结论会失败，以及这些失败是否需要人工干预。错误的相关性取决于应用执行的工作。

第三个信号是变更期间的运行行为。有价值的报告应描述服务软件更新、模型替换、节点故障和服务恢复。在日常维护期间保持稳定性能，将强化 Kubernetes 部署的理由。

这些报告还应包含应用的实际体验。如果用户丢失工作，或重复请求触发重复操作，基础设施恢复就是不完整的证据。运行成熟度体现在完整工作流的行为方式上。

这些信号结合起来，将阐明已发布指南的价值。可复现的性能证明容量；留出评估证明任务适用性；恢复证据证明团队能否以可接受的中断程度运行服务。

它们也提供了一种实用方法，可在不宣布普适赢家的前提下比较部署路径。每个组织都可以根据自身要求评估同一份证据。这使讨论始终围绕工作负载，而非平台偏好。

以边界明确的任务、具有代表性的输入和对可接受结果的清晰定义开始评估。记录配置，以便另一位工程师能够复现。纳入失败、需要审查或在服务中断期间到达的请求。

让决策始终与已完成工作相联系。询问模型是否产生可用结果、服务是否满足响应预期，以及团队能否维护它。将额外的服务复杂性视为需要证据证明合理性的事项。

NVIDIA Nemotron EKS 部署现已拥有跨 AWS Kubernetes 选项的文档化路径。利用这一路径测试具体应用，比较运维责任，并选择你的团队能够支持的配置。