微软与NVIDIA合作推出了第二阶段成果：在Azure Kubernetes Service平台上运行NVIDIA Dynamo进行大型语言模型推理。最初的公告中提到，该技术在分布式GPU系统中能够实现每秒120万个处理单元的吞吐量。而此次发布的更新版本主要旨在帮助开发者提升工作效率，并通过自动化资源规划与动态扩展功能进一步提升运行效率。
这些新功能主要由两个集成组件构成：Dynamo Planner Profiler与基于服务水平目标的Dynamo Planner。这两个工具协同工作，用于解决在分散式计算环境中“如何合理分配资源以匹配处理需求”这一问题。开发人员会将推理任务分为两类：一类是预处理操作（用于处理输入数据），另一类是生成输出结果的操作；这两类任务通常会在不同的GPU集群上运行。如果没有合适的工具，开发团队就需要花费大量时间来确定这些任务的最佳资源配置方案。
Dynamo Planner Profiler是一种部署前的仿真工具，它能自动搜索出最优的配置方案。开发者无需手动测试各种并行化策略或GPU数量，只需在DynamoGraphDeploymentRequest (DGDR)配置文件中说明自己的需求，该工具就会自动扫描所有可能的配置组合，并测试预处理阶段与结果生成阶段的性能表现，从而帮助找到能在保证延迟限制的前提下提升吞吐量的设置。
此外，该工具还提供了AI Configurator模式，根据预先测得的性能数据，可以在大约20到30秒内模拟出相应的运行效果。这一功能使开发团队能够在实际分配GPU资源之前快速调整配置方案，最终得到能够最大化吞吐量的最佳设置——这种吞吐量是指在满足“首次输出结果所需时间”及“字符间延迟”限制的前提下所能达到的最高处理效率。
一旦系统投入生产，基于服务水平目标的Dynamo Planner就会作为运行时调度引擎开始发挥作用。这个组件具备“对大语言模型有感知能力”，这意味着与传统负载均衡器不同，它会持续监控集群的状态，例如解码池中的键值缓存负载情况以及预填充队列的长度。规划器会利用性能分析工具提供的数据来调整预填充任务和解码任务的规模，从而确保在流量模式发生变化时仍能满足服务水平目标。
这一功能通过一个具体的航空助手应用场景得到了说明：在这个案例中，Qwen3-32B-FP8模型被用于支持一款航空公司的移动应用程序。该应用程序严格遵守服务水平协议，要求“首次响应时间”不超过500毫秒，“token间延迟”不得超过30毫秒。在正常情况下，当乘客查询量较小时，系统会运行一个预填充任务和一个解码任务；但当天气原因导致200名用户同时发送复杂的路线重规划请求时，规划器会自动增加预填充任务的数量至两个，而解码任务的数量保持不变。开发团队表示，新增的任务节点能在几分钟内投入运行，从而使系统在流量激增的情况下依然能够维持规定的延迟指标。
此次发布的版本是在NVIDIA之前于2024年12月发布的Dynamo框架基础上进一步发展的。在那篇报道中，Azure和NVIDIA详细介绍了Dynamo的设计原理——它如何将计算密集型任务和内存消耗较大的任务分配到不同的GPU上，从而使开发团队能够针对具体的工作负载需求来优化系统资源配置。例如，一个电商应用的预填充任务可能需要处理数千个数据项，而解码任务则只需要生成简短的描述信息。
从手动配置转向自动化、基于服务水平目标进行资源管理的做法，体现了团队在Kubernetes平台上部署大语言模型时所能取得的进步。Dynamo Planner提供的各种工具能够帮助开发人员将延迟要求转化为具体的GPU资源配置方案，从而有效降低运行分布式推理架构所带来的运营负担。对于那些需要处理复杂逻辑或需要长上下文理解的大语言模型来说，自动化工具无疑为组织提供了极大的帮助——它们使得管理复杂的多节点GPU配置变得更加容易，同时也确保了在流量模式发生变化时服务水平目标仍能得到保障。