消除解耦服务中的不确定性

部署和优化大型语言模型（LLM）以实现高性能、低成本的推理服务，可能是一个令人望而生畏的工程难题。针对任何给定工作负载（如硬件、并行策略以及预填充/解码拆分）的理想配置，存在于一个庞大的多维搜索空间中，无法通过人工或穷举测试进行探索。AIConfigurator 是一款开源工具，旨在简化 NVIDIA Dynamo AI 推理服务栈，帮助您轻松跨越这一复杂性，在几分钟内实现最优部署。

AIConfigurator 的核心优势在于，您无需在真实硬件上逐一运行所有可能的配置来预测最佳方案。相反，它将 LLM 推理拆解为各项基础操作，并在目标 GPU 上独立测量每一项操作的性能。随后，AIConfigurator 会将这些测量数据重新组合，从而估算任意配置的端到端性能，且在整个搜索过程中完全无需占用任何 GPU 机时。

本文将简要概述 AIConfigurator 的工作原理；如何将其与 Dynamo 配合使用；以及 Alibaba 和 Mooncake 等生态贡献者如何协助将该开源项目的功能扩展至所有框架。

使用 AIConfigurator 配置分离式推理服务

借助 AIConfigurator，每项操作（包括通用矩阵乘法 (GEMM)、注意力机制、通信以及混合专家 (MoE) 调度）的延迟估算，均以在目标硬件上收集的真实内核测量数据为支撑。采集工具链会针对所有支持的量化模式、批量大小、序列长度和 GPU 数量对每个基础原语进行基准测试，并将结果记录至经芯片校准的性能数据库中。当新模型或 GPU 缺乏实测数据时，AIConfigurator 会回退至基于经验修正系数的理论极限 Roofline 估算，从而在模型尚未进行实际性能剖析的情况下，仍能提供切实可行的配置建议。

在此估算层之上，AIConfigurator 针对聚合式服务对连续批处理进行建模，针对分离式服务对预填充和解码工作池进行速率匹配，并处理 MoE 特有的问题，如专家并行和令牌路由倾斜。它不会返回单一答案，而是计算所有已评估配置的帕累托前沿，并排展示聚合模式与分离模式下吞吐量与延迟之间的权衡。整个搜索过程通常涵盖数万种候选配置，仅需数秒即可完成，避免了在 GPU 上耗费数天时间进行探索。

为了解该工具如何为开发者提供帮助，请看一个具体示例：在 64 块 NVIDIA B200 GPU 上部署采用 NVFP4 量化的 Qwen3-32B，目标 SLA 为首字延迟（TTFT）1000 毫秒和单输出词元延迟（TPOT）15 毫秒。仅需一条命令，您即可搜索数千种候选配置：

pip install aiconfigurator  # or install from source for latest

  aiconfigurator cli default \
    --model-path nvidia/Qwen3-32B-NVFP4 \
    --total-gpus 64 \
    --system b200_sxm \
    --isl 15000 --osl 500 \
    --ttft 1000 --tpot 15 \
    --save-dir ./results

数秒内，AIConfigurator 即可返回推荐结果。在本示例中，分离式服务可实现 550 tokens/s/GPU 的性能，较最佳聚合配置提升了 38%。输出内容包含可视化完整权衡空间的帕累托前沿、排序后的配置列表（best_config_topn.csv）、每种工作器类型的引擎配置，以及适用于两种服务模式的即用型部署构件。

在 Dynamo 中进行分离式服务时，部署推荐配置仅需执行一条命令：

kubectl apply -f results/disagg/top1/k8s_deploy.yaml

该工作流可泛化至不同模型与硬件。无论是在八张 NVIDIA H200 GPU 上部署 Qwen3-32B，还是在多节点 B200 集群上部署 DeepSeek-V3，均可使用相同的接口；AIConfigurator 会根据指定的模型、硬件和 SLA 约束条件，自适应调整其搜索空间与推荐配置。

扩展对多框架的支持

AIConfigurator 最初仅支持 NVIDIA TensorRT LLM，但随着 SGLang 等框架的兴起（尤其是针对 DeepSeek 等 MoE 模型），单一后端的支持已无法满足需求。我们设计了一个与框架无关的抽象层，通过统一的参数映射，在单一接口下对各后端的配置架构与术语进行了规范化。这一前期投入在 Mooncake 和阿里巴巴等社区合作伙伴落地 SGLang 支持时初见成效，他们贡献了数据采集器、验证及集成工作，具体内容将在后续章节展开。

从用户视角来看，对比不同后端只需修改一个标志参数：

# TensorRT LLM
aiconfigurator cli default \
  --model-path nvidia/Qwen3-32B-NVFP4 \
  --total-gpus 64 --system b200_sxm \
  --backend trtllm

# SGLang
aiconfigurator cli default \
  --model-path nvidia/Qwen3-32B-NVFP4 \
  --total-gpus 64 --system b200_sxm \
  --backend sglang

# vLLM
aiconfigurator cli default \
  --model-path nvidia/Qwen3-32B-NVFP4 \
  --total-gpus 64 --system b200_sxm \
  --backend vllm

为更进一步简化操作，--backend auto 可通过一条命令对比三种框架：

aiconfigurator cli default \
  --model-path nvidia/Qwen3-32B-NVFP4 \
  --total-gpus 64 --system b200_sxm \
  --backend auto

各后端的搜索流程完全一致；仅生成的部署产物有所不同，每个后端会按其预期格式接收原生配置文件、CLI 参数和 K8s 清单。AIConfigurator 目前内置了经硅片验证的 TensorRT LLM 和 SGLang 在 NVIDIA H100、H200 及 B200 系统上的性能数据，同时也在选定平台上提供对 vLLM 的支持。

SGLang 的 WideEP 推理

SGLang 在运行“宽专家并行”（WideEP）方面尤为流行，该技术通过将专家分布到大量 GPU 上，大幅提升了 DeepSeek V3/R1 等 MoE 模型的解码吞吐量。为准确建模 SGLang 的 WideEP 路径，AIConfigurator 模拟了 DeepEP All-to-All 通信、MTP、MLA 注意力机制、Attention DP、负载感知 MoE 以及专家并行负载均衡（EPLB）等关键组件。对 MoE 和 EPLB 进行建模构成了最大的挑战。

WideEP 的 MoE 路由天然存在负载不均衡问题，部分专家会接收到比其他专家更多的 token。AIConfigurator 使用 alpha 参数对此幂律工作负载分布进行建模。该 alpha 参数作为性能数据库的查找键，将分布模式与已采集的延迟特征相关联，机制与标准 MoE 路径类似。经验表明，alpha 取值为 1.01 时，能够很好地拟合 DeepSeek V3.1 在各数据集上的预填充（prefill）与解码（decode）阶段。

在 WideEP 部署中，AIConfigurator 通过调整两项因素而非直接模拟算法来对 EPLB 建模。首先，将工作负载分布的 alpha 值从 1.01 降至 0.6，以反映专家复制所带来的负载平滑效应；其次，将有效 token 数量乘以 0.8，以模拟单 GPU 最大 token 负载的经验性下降。这些调整用于匹配正确的延迟曲线，并相应地校准工作点。

初步结果令人鼓舞：AIConfigurator 识别出的最佳配置与手动调优的生产配置一致。计划开展进一步合作，以推进该方案达到生产就绪状态。

SGLang 社区的贡献方式

Mooncake：在 AIConfigurator 中初步支持 SGLang

AIConfigurator 最初仅支持 TensorRT LLM，为 SGLang 和 vLLM 预留了接口但未完全实现。随后，来自 Mooncake（Moonshot AI、Tsinghua University 及其他机构的开源协作项目）的贡献者开发了 SGLang 后端的首个版本。

他们首先完成了收集器层的开发，对核心算子（GEMM、attention、batch-GEMM）进行了建模与封装。此举实现了对 Llama、Qwen 和 DeepSeek 等模型的快速支持。该工作与后续的 SGLang WideEP 研发相结合，共同构成了 AIConfigurator 的首个 SGLang 后端。

阿里巴巴：将 AIConfigurator 集成至 AI 服务栈以实现自动化部署

基于阿里云容器服务 Kubernetes 版（ACK）构建的 AI Serving Stack 是一套面向高效、可扩展的云原生 LLM 推理的端到端解决方案。它管理全生命周期，提供部署、智能路由、自动扩缩容与深度可观测性功能。

在该技术栈中，RoleBasedGroup（RBG）是一款由 SGLang 社区孵化且阿里云深度贡献的 AI 编排引擎，它简化了 LLM 推理服务在 Kubernetes 上的部署。RBG 以“Role”为核心编排单元，将基于预填充-解码分离架构的服务划分为路由、预填充与解码角色，以协调其节点放置、弹性扩缩容与版本更新。结合基于角色的可扩展性，该设计确保了性能与稳定性的平衡。

完整的 Dynamo 服务栈可与 ACK 上的 AI Serving Stack 结合部署，以 AIConfigurator 的预测结果为输入并结合其生成器模块。ACK 团队可为 RBG 生成可部署的配置，详见此处。通过集成该流程，阿里巴巴在 Qwen3-235B-FP8 模型上实现了基线 1.86 倍的吞吐量，同时保持 TTFT <5000ms 和 ITL<40ms。

RBG 将持续跟进 AIConfigurator 的进展，并为在 ACK 中快速部署新模型提供 Day 0 支持。

阿里巴巴：基于 AIConfigurator 构建 HiSim

AIConfigurator 可优化静态工作负载，但难以对动态、突发的生产流量、复杂调度以及 KV Cache 动态变化进行建模。为克服这一问题，阿里巴巴 TAIR KV Cache 团队创建了 Tair-KVCache-HiSim，这是一个轻量级、高保真且事件驱动的系统模拟器。

HiSim 通过系统级模拟，解决了动态流量与排队问题（在可变速率及 SGLang 等复杂调度下预测 TTFT、TPOT 和吞吐量）以及高级 KV Cache 优化问题（量化多级存储与多种驱逐/预取策略之间的权衡）。

HiSim 包含工作负载生成器、全局路由器模拟器以及推理引擎模拟器（IES）。IES 采用统一的全局时钟来协调调度器模拟器（负责管理 LLM 请求：抢占与批处理）、KVCache 管理器模拟器（HiCacheController，用于对三级 KV 缓存及淘汰机制进行建模）和 BatchRunnerEstimator（AIConfiguratorTimePredictor，基于 AIConfigurator 计算批次延迟）。

该架构可快速适配多种推理引擎（vLLM、SGLang、TensorRT LLM），在无需修改引擎的前提下，精确还原真实环境中的配置、运行时参数及执行语义（并行计算、批处理、设备优化），从而确保高保真度。

HiSim 通过支持配置调优，使研发团队能够在不更改代码的情况下量化调度权衡（TTFT/吞吐量、排队/内存、缓存命中率/TTFT、重叠执行效率），进而指导 SGLang 的研发。它基于理论规格估算性能上限并定位瓶颈，为新硬件提供“oracle”级评估。此外，HiSim 还通过三级 KV 缓存设计（如 L2 容量、预取/淘汰策略、L3 带宽需求、直写与回写模式对比）辅助 HiCache 架构探索与成本/性能优化，以寻找最佳的性价比平衡点。

借助 AIConfigurator，HiSim 将静态分析扩展为面向动态流量的、具备成本感知能力的主动部署建议。其端到端模拟结果与实际性能的误差控制在 5% 以内。未来工作将进一步优化此协同机制，以构建高保真且具备生产就绪能力的系统模拟器。

AIConfigurator 的下一步规划

未来的路线图将把 AIConfigurator 从一个独立的命令行工具扩展为 Dynamo 平台的核心组件：

• 更快的模型支持。“Hybrid”模式已通过理论极限估算提供首日推荐；我们还在推进芯片数据采集流水线的自动化，以加速实现经过充分验证的支持。
• 赋能 Dynamo 部署。AIConfigurator 正通过 DynamoGraphDeploymentRequest (DGDR) CRD 成为 Dynamo Kubernetes 流程背后的配置引擎，仅需单个 YAML 文件即可生成优化后的部署。
• 动态工作负载建模。突破对静态输入序列长度/输出序列长度/并发目标的依赖，转向能够直接捕获生产环境工作负载分布的模型。

NVIDIA 计划继续与第三方合作，将 AIConfigurator 引入更多系统和工具。AIConfigurator 积极欢迎各项贡献，包括新硬件的性能数据、额外的后端支持、新功能以及 HiSim 等扩展。

请参阅 AIConfigurator 仓库开始使用，并查阅 Dynamo 项目，了解最快搭建解耦服务的方法。

如需完整的技术论述（包括形式化定义与验证结果），请阅读我们的论文：AIConfigurator: Lightning-Fast Configuration Optimization for Multi-Framework LLM Serving 。