共计 1392 个字符，预计需要花费 4 分钟才能阅读完成。
微软与 NVIDIA 近日发布了双方在 Azure Kubernetes 服务上运行 NVIDIA Dynamo 进行大语言模型推理合作的第二部分成果。首次发布聚焦于在分布式 GPU 系统上实现每秒 120 万个令牌的原始吞吐量。而此次更新则旨在帮助开发人员提升工作效率与运营效能，核心是通过自动化资源规划与动态扩缩容能力来实现的。
新功能主要围绕两个集成组件：Dynamo Planner Profiler 与基于服务级别目标（SLO）的 Dynamo Planner。这两项工具共同应对解耦式服务中的“速率匹配”难题——该术语在团队拆分推理工作负载时使用，指将处理输入上下文的预填充操作与生成输出令牌的解码操作分离，并安排在不同 GPU 池上执行。若缺乏合适工具，团队常需耗费大量时间手动确定各阶段最佳的 GPU 分配方案。
Dynamo Planner Profiler 是一款部署前模拟工具，可自动搜索最优配置。开发人员无需手动测试多种并行化策略与 GPU 数量，从而节省数小时 GPU 使用时间。他们只需在 DynamoGraphDeploymentRequest 清单中定义需求，性能分析器便会在配置空间内自动扫描，测试预填充与解码阶段的不同张量并行规模，从而找出在延迟限制内提升吞吐量的最佳设置。
性能分析器还包含 AI 配置器模式，能基于预先测量的性能数据，在约 20 至 30 秒内模拟运行表现。该功能允许团队在分配实际 GPU 资源前快速迭代配置，其输出可提供优化设置，以提升所谓“有效吞吐量”——即在满足首令牌时间与令牌间延迟限制的前提下，所能达到的最高吞吐量。
当系统进入生产环境后，基于 SLO 的 Dynamo Planner 将作为运行时编排引擎接管工作。该组件具备“LLM 感知”能力，与传统负载均衡器不同，它能密切追踪集群状态，例如解码池中的键值缓存负载与预填充队列深度等。Planner 借助性能分析器得出的性能边界，对预填充与解码工作节点进行扩缩容，从而在流量模式变化时仍能满足服务级别目标。
本次发布通过一个详细的航空公司助手场景演示了上述功能。在该场景中，一个 Qwen3-32B-FP8 模型为航空公司移动应用提供支持，并需遵循严格的服务级别协议：首令牌时间 500 毫秒，令牌间延迟 30 毫秒。在乘客查询简短的正常运行期间，系统仅运行一个预填充工作器与一个解码工作器。当天气干扰导致 200 名用户同时发送复杂的改签请求时，Planner 会检测到流量激增，随即把预填充工作器扩展至两个，而解码工作器保持一个。团队表示，新增工作器可在几分钟内上线，使系统在流量高峰期间仍能保持延迟目标。
此次发布基于原始 Dynamo 公告中提出的框架，InfoQ 在 2024 年 12 月曾作相关报道。在上篇文章中，Azure 与 NVIDIA 解释了 Dynamo 如何将计算密集型与内存密集型任务拆分至不同 GPU，使团队能独立优化各阶段，让资源更贴合工作负载需求。例如，电商应用的预填充任务可能处理数千个令牌，而其解码任务仅需生成简短描述。
从手动配置转向自动化、SLO 驱动的资源管理，体现了团队在 Kubernetes 上部署大语言模型方式的进步。Planner 组件提供了将延迟需求转化为 GPU 分配与扩缩容决策的工具，旨在降低解耦推理架构的运营负担。这类自动化工具尤其适合推理密集型或长上下文 LLM 的应用组织，不仅能简化复杂的多节点 GPU 管理，还能在动态变化的流量模式中持续满足服务级别目标。
