AIConfigurator: Lightning-Fast Configuration Optimization for Multi-Framework LLM Serving #

• arXiv: 2601.06288
• Authors: Tianhao Xu, Yiming Liu, Xianglong Lu, Yijia Zhao, Xuting Zhou, Aichen Feng, Yiyi Chen, Yi Shen, Qin Zhou, Xumeng Chen, Ilya Sherstyuk, Haorui Li, Rishi Thakkar, Ben Hamm, Yuanzhe Li, Xue Huang, Wenpeng Wu, Anish Shanbhag, Harry Kim, Chuan Chen, Junjie Lai (NVIDIA)
• Date: 2025-01 (v1)
• Category: framework
• Tags: serving, configuration-optimization, LLM-serving, auto-tuning, multi-framework

---

粗读 (First Pass) #

Core Contribution #

AIConfigurator 是 NVIDIA 开发的统一性能建模系统，能在 不使用 GPU profiling 的情况下，在 30 秒内完成跨框架（TRT-LLM、vLLM、SGLang）的 LLM 推理配置空间搜索。核心思路是将推理分解为可解析建模的基本算子（GEMM、attention、communication、memory），结合预先采集的 kernel-level 性能数据库，通过组合估算实现端到端性能预测。

核心三问 #

1. 解决什么问题？ LLM serving 配置空间爆炸（TP/PP/EP × batch size × 框架参数 × aggregated/disaggregated），手动调优需要数天 GPU 时间，且框架间差异巨大（vLLM vs TRT-LLM vs SGLang），现有 simulator（Vidur、APEX）依赖 roofline 模型准确度不够。
2. 怎么解决的？ 数据驱动的算子级性能建模：(a) 离线采集各硬件平台上的 GEMM/Attention/Communication 实际执行时间到 PerfDatabase；(b) 将推理 iteration 分解为算子序列，通过查表+插值估算单步延迟；(c) 在三种 serving mode（Static/Aggregated/Disaggregated）上建立数学模型，从算子延迟推导 TTFT/TPOT。
3. 效果如何？ TPOT 预测 MAPE 6-12%；TTFT 预测 MAPE 16-22%；搜索速度比 GPU benchmarking 快 170,000-427,000×；在 Qwen3-32B 上发现 disaggregated 配置可比 aggregated 提升 2× throughput。

Figure 1: Pareto Frontier — Aggregated vs Disaggregated Serving #



What it shows: Qwen3-235B 在 64×H200 上的 Throughput vs Speed Pareto 曲线。横轴为每用户生成速度 (tokens/s/user)，纵轴为系统吞吐量 (tokens/s/GPU)。每个点是一个满足 TTFT ≤ 1000ms 约束的 serving 配置，分别标注了 aggregated 和 disaggregated 模式的最优点（★）。

Why it matters: 这是论文的 headline figure。直观展示了 AIConfigurator 的核心价值——自动发现 disaggregated serving 在特定 workload 下可比 aggregated 高 53% throughput（823 vs 564 tokens/s/GPU）。这种对比在 >10,000 配置的搜索空间中无法手动发现。

逻辑故事还原 #

起点: LLM serving 配置空间太大（>10,000 permutations），手动调优不可行，现有 simulator 不够准确。

洞察: 推理 iteration 本质是重复执行少量算子类型（GEMM、Attention、Comm），这些算子的性能可以在真实硬件上预先采集并建库；框架差异可以通过分别采集各框架的 kernel 性能数据来捕捉。

方法: 构建算子性能数据库（PerfDatabase）→ 将配置空间编码为搜索问题（TaskRunner）→ 对每个候选配置，通过算子组合估算单步延迟（InferenceSession）→ 分别为 Static/Aggregated/Disaggregated 三种模式建立 TTFT/TPOT 数学模型 → Pareto 分析找最优 → 生成框架兼容的启动配置（Generator）。

关键假设: (1) 算子性能可以离线预采集并通过插值泛化；(2) 推理 iteration 的延迟可以通过算子延迟的线性叠加近似；(3) 经验修正因子（$F_{\text{corr}}$, $\beta_{\text{TTFT}}$, $\alpha$）可以捕捉调度和传输开销。

结论: 在 H100/H200 上验证，TPOT 误差 <12%，搜索时间 <1秒，找到的配置比手动调优提升 40-100%。

Key Figures #

Figure	内容	意义
Fig 1	Qwen3-235B 在 64×H200 上的 Pareto 曲线（Aggregated vs Disaggregated）	核心展示：disaggregated 在特定 workload 下可比 aggregated 高 53% throughput
Fig 2	AIConfigurator 五步 workflow	系统架构总览
Fig 3	三种 serving mode（Static/Aggregated/Disaggregated）	建模基础
Fig 4	MoE 模型推理分解为算子序列	算子级建模的核心抽象
Fig 5	Power-law $\alpha$ 对 expert 负载均衡的影响	MoE 建模的关键细节
Fig 6	Aggregated serving 预测 fidelity（TPOT/TTFT）	核心验证：预测 vs 实测散点图
Fig 7	Disaggregated serving 预测 Pareto 曲线 vs 真实值	多节点场景的验证
Fig 8	Case study: Qwen3-32B 上 Aggregated vs Disaggregated	实际价值展示

Key Tables #

Table	内容	关键数据
Table 1	搜索效率对比	Qwen3-235B: 0.84s vs 99.5 GPU-hr (427,000× speedup)；每配置 ~1.5ms
Table 2	Aggregated vs Disaggregated 最优配置	Disaggregated 648.3 tok/s/GPU vs Aggregated 321.5 tok/s/GPU (+101.6%)

Key Details & Takeaway #

1. PerfDatabase 采集成本: ~30 GPU-hours per platform-framework pair，这是一次性成本但不可忽视
2. MoE 的 power-law 建模: 70% compute 由 20% experts 处理（Qwen3-235B 观察），用 $\alpha$ 参数控制 skew
3. Aggregated mode 的 rate-matching heuristic: 当 prefill 重于 decode 时，限制 decode 并发数防止 starvation
4. Disaggregated mode 的修正因子: $\beta_{\text{TTFT}}=1.8$（KV-cache 传输开销），$\alpha_{\text{pre}}=0.9$, $\alpha_{\text{dec}}=0.92$（干扰因子）
5. TTFT 预测不如 TPOT 准确: TTFT MAPE 16-22% vs TPOT 6-12%，因为 TTFT 受调度抖动影响更大
6. 搜索时间恒定: 每配置 ~1.5ms 不随模型大小增长，因为查表复杂度与架构相关而非参数量

Takeaway: 这是一个实用的工程系统，核心价值在于把「需要 GPU 的配置搜索」变成了「CPU 上的查表+数学模型」。准确度对 TPOT 足够好，对 TTFT 还有改进空间。与 NVIDIA Dynamo 的集成使其有明确的落地路径。

Summary #

AIConfigurator 通过算子级性能数据库 + 三种 serving mode 的数学建模，将 LLM 推理配置搜索从数天的 GPU 实验缩减到 <1 秒的 CPU 计算。系统支持 TRT-LLM/vLLM/SGLang 三大框架，在 H100/H200 上验证 TPOT 预测误差 6-12%，搜索加速 17万-43万倍。实际 case study 表明系统能自动发现 disaggregated serving 配置，将吞吐量提升 2×。

Key Findings #

1. 算子级数据驱动建模比 roofline 模型更准确，TPOT MAPE 6-12%（vs Vidur/APEX 的理论估算）
2. Disaggregated serving 不总是更优，取决于 workload/hardware/interconnect 的交互，需要自动搜索
3. MoE 模型的 expert load imbalance 可用 power-law 分布建模，显著影响性能预测准确度
4. 框架间的性能差异可以通过分别采集各框架的 kernel 数据来捕捉（而非建立统一的理论模型）
5. 搜索空间可达 10,000+ 配置，手动调优不可能覆盖

Limitations #

1. TTFT 预测精度有限: 16-22% MAPE，对延迟敏感场景可能不够（TTFT SLA 通常很紧）
2. 离线采集成本: 每平台每框架 ~30 GPU-hours，新硬件/新框架需要重新采集
3. 修正因子是经验性的: $F_{\text{corr}}$（分段线性）、$\beta_{\text{TTFT}}=1.8$、$\alpha_{\text{pre}}=0.9$ 等都是 hand-tuned 常数，泛化性存疑
4. 仅支持 NVIDIA GPU: 未覆盖 AMD/Intel/自研芯片
5. 不支持 speculative decoding/sparse attention 等新技术: 论文自己承认这是 future work
6. 静态 workload 假设: 用固定 ISL/OSL 建模，未考虑动态 workload 分布变化
7. 未开源: 作为 NVIDIA 内部工具，社区可复现性差
8. Disaggregated mode MAPE 较高: 系统 throughput 25.49%，在非交互速度区域尤其不准
9. 线性算子叠加假设: 忽略了 kernel 间的 pipeline 重叠和内存争用

Infrastructure Impact #

短期影响: 对 NVIDIA GPU 上的 LLM serving 部署提供显著的调优加速，尤其是对需要频繁调整配置的云服务提供商。与 Dynamo 集成使其可以直接用于生产环境。

长期影响: 算子级性能建模的思路可以推广到更广泛的 AI workload 配置优化。如果开源，可能成为 LLM serving 领域的标准配置工具。但 NVIDIA 锁定效应明显——性能数据库绑定 NVIDIA 硬件，加深了生态依赖。

关键意义: 证明了「用数据驱动取代理论模型」在 LLM serving 配置优化中的可行性，30 GPU-hours 的一次性投入可以节省数千小时的重复调优。

---

Deep Analysis (framework) #

1. System Scope #

目标: 跨框架（TRT-LLM、vLLM、SGLang）的 LLM 推理配置自动优化。

覆盖范围:

• 模型: Dense (GPT, Qwen, Llama, Mistral) + MoE (DeepSeek-V3, Qwen3-235B)
• 硬件: NVIDIA Ampere, Ada, Hopper, Blackwell
• 框架: TensorRT-LLM, vLLM, SGLang, NVIDIA Dynamo（orchestration 层）
• 配置维度: TP/PP/EP parallelism, batch size, context chunk size, KV-cache memory fraction, CUDA graph, max token capacity
• Serving mode: Static, Aggregated (continuous batching), Disaggregated (prefill/decode split)

Scope 限制: 仅 NVIDIA GPU；不支持 speculative decoding、sparse attention、prefix caching 等新兴技术；不处理动态 workload 分布。

2. Architecture & Data Flow #

五阶段 Pipeline:

User Workload Descriptor
    ↓
[PerfDatabase] ← 离线采集（~30 GPU-hr/platform/framework）
    ↓
[TaskRunner] → 生成合法配置空间（剪枝 memory/GPU 约束）
    ↓
[InferenceSession] → 遍历配置，算子查表 + 数学模型估算 TTFT/TPOT
    ↓
[Pareto Analyzer] → 过滤/排序，输出最优配置 + 性能预测
    ↓
[Generator] → 生成框架兼容的启动配置文件
    ↓
TRT-LLM / vLLM / SGLang / Dynamo

Figure 2: AIConfigurator Workflow #



What it shows: AIConfigurator 的五阶段 pipeline 全貌——从 PerfDatabase（离线算子采集）→ TaskRunner（配置空间构建）→ InferenceSession（算子级性能估算）→ Pareto Analyzer（最优配置筛选）→ Generator（框架原生启动文件输出）。

Why it matters: 系统的关键设计决策一目了然：InferenceSession 阶段完全在 CPU 上运行（查表+数学模型，无 GPU 操作），这是实现 427,000× 搜索加速的根本原因。Generator 的框架适配层使同一套搜索逻辑可以直接输出 TRT-LLM / vLLM / SGLang / Dynamo 的启动参数。

数据流特点:

• PerfDatabase 是一次性的离线数据资产，包含 GEMM(M,N,K,dtype)、Attention(batch,seq,heads)、Comm(msg_size,gpu_count) 的实测延迟
• InferenceSession 不执行任何 GPU 操作，纯 CPU 查表 + 数学计算
• Generator 输出框架原生的启动参数（如 --enable_cuda_graph, --kv_cache_free_gpu_mem_fraction）

3. Key Innovations #

1. 算子级数据驱动建模（vs 理论 roofline）: 不依赖 FLOPs/bandwidth 的理论计算，而是直接查实测数据。这捕捉了理论模型遗漏的框架特定开销（kernel launch、memory allocator、scheduler overhead）。
1. 三种 Serving Mode 的统一数学框架:
2. Static: 简单的 prefill + decode 序列叠加
3. Aggregated: 混合阶段（prefill+decode 共存）的 rate-matching + 经验修正
4. Disaggregated: 独立 worker pool 的 rate-matching + KV-cache 传输建模

Figure 3: Three Serving Modes #



What it shows: AIConfigurator 建模的三种 serving 模式——(A) Static: 固定 batch，prefill 和 decode 严格串行；(B) Aggregated (continuous batching): 不同请求的 prefill 和 decode 混合执行，GPU 利用率更高；(C) Disaggregated: prefill 和 decode 运行在独立的 GPU pool，通过 KV-cache 传输连接。

Why it matters: 这三种模式的数学建模是 AIConfigurator 的理论基础。每种模式对应不同的 TTFT/TPOT 计算公式（Algorithm 1/2/3），框架选择哪种模式直接决定了性能特征。Disaggregated 模式引入了额外的 $\beta_{\text{TTFT}}$ 修正因子来建模 KV-cache 传输开销。

1. MoE Power-Law 负载建模: 用 $\alpha$ 参数控制的 power-law 分布生成合成 router assignment，在 profiling 时复现生产环境的 expert 负载不均，避免用均匀分布低估 tail latency。
1. 跨框架统一抽象: 通过 backend abstraction layer，同一套搜索逻辑适用于不同框架，每个 backend 只需实现 memory estimation + 框架特定约束。

批判性评价: Innovation 1 和 3 是真正的贡献；Innovation 2 的数学模型包含多个 hand-tuned 常数（$F_{\text{corr}}$, $\beta$, $\alpha$），可能在新场景下需要重新校准；Innovation 4 的抽象层深度未知——论文未说明添加新框架需要多少工作量。

4. Scheduling & Resource Management #

AIConfigurator 本身不做调度，而是 预测不同调度策略下的性能:

• Aggregated mode 调度建模: 将 continuous batching 抽象为 Mixed Phase（prefill+decode 共存）+ Generation-only Phase（纯 decode）。关键 heuristic: 当 context 处理时间 > generation 时间时，限制 decode 并发数（rate-matching），防止 decode starvation。
• Disaggregated mode 资源分配: 搜索最优的 (x)P(y)D 配置，即 x 个 prefill worker + y 个 decode worker。通过 $\min(R_{\text{pre}}, R_{\text{dec}})$ 找到系统瓶颈，最大化 per-GPU throughput。
• 内存管理: 自动估算每种配置的 GPU memory 需求（model weights + KV-cache），剪枝超出显存限制的配置。

不足: 未建模 request queuing dynamics、arrival rate 波动、priority scheduling 等生产环境的复杂调度行为。

5. Target Scenarios #

场景	适用性	说明
大规模 LLM 部署（≥8 GPU）	★★★★★	配置空间最大，自动搜索价值最高
MoE 模型部署	★★★★★	EP 引入额外维度，power-law 建模有独特优势
Disaggregated serving 设计	★★★★☆	自动搜索 (x)P(y)D 配置，但 MAPE 较高
单 GPU / 小规模部署	★★☆☆☆	配置空间小，手动调优即可
延迟极敏感场景（TTFT <100ms）	★★☆☆☆	TTFT 预测误差 16-22% 可能不够
非 NVIDIA 硬件	☆☆☆☆☆	完全不支持

6. Performance Evaluation #

Before-After Comparison #

指标	Before (手动/exhaustive)	After (AIConfigurator)	改进
配置搜索时间 (Qwen3-235B)	99.5 GPU-hours	0.84 秒 (CPU)	427,000×
配置搜索时间 (Llama3.1-8B)	24.4 GPU-hours	0.52 秒 (CPU)	171,000×
每配置评估时间	4-11.5 分钟 (GPU)	~1.5ms (CPU)	~200,000×
Qwen3-32B throughput (aggregated → disaggregated)	321.5 tok/s/GPU	648.3 tok/s/GPU	+101.6%
Dense model 性能提升潜力	baseline	+40% (Qwen3-32B)	—
MoE model 性能提升潜力	baseline	+50% (DeepSeek-V3)	—

Prediction Accuracy #

模型/框架	TPOT MAPE	TPOT r	TTFT MAPE	TTFT r
Qwen3-32B (TRT-LLM)	8.2%	0.96	22.1%	0.89
Qwen3-235B MoE (TRT-LLM)	6.8%	0.98	18.3%	0.66
Qwen3-32B (vLLM)	11.9%	0.99	16.9%	0.95
DeepSeek-V3 disagg (throughput)	—	—	25.49% MAPE	—
DeepSeek-V3 disagg (speed, interactive region)	3.35%	—	13.19% MAPE	—

Figure 6: Aggregated Serving Prediction Fidelity #



What it shows: 960+ 配置的 TPOT 和 TTFT 预测值 vs 实测值散点图，覆盖 TRT-LLM (Qwen3-32B, Qwen3-235B MoE) 和 vLLM (Qwen3-32B)。对角线表示完美预测，点越靠近对角线越准。TTFT > 1000ms 的异常值已过滤。

Why it matters: 这是 AIConfigurator 准确度的核心证据。TPOT 散点高度贴合对角线（r=0.96-0.99），验证了算子级建模对 decode 阶段的有效性。TTFT 散点更分散（r=0.66-0.95），暴露了 continuous batching 调度抖动导致的建模难度。MoE 模型的 TPOT MAPE 反而最低（6.8%），验证了 power-law expert 负载建模的价值。

Figure 8: Case Study — Aggregated vs Disaggregated Optimization #



What it shows: Qwen3-32B-FP8 在 8×H200 上的实际部署对比。左图为 aggregated Pareto frontier（AIConfigurator 预测 vs 实测），右图为 disaggregated Pareto frontier。星标 ★ 标注满足 SLA（TTFT ≤ 1200ms, speed ≥ 60 tok/s/user）的最优点。

Why it matters: 直接展示 AIConfigurator 的生产价值——disaggregated 最优配置（4×TP1 prefill + 2×TP2 decode, batch P:1/D:80）达到 648.3 tok/s/GPU，比 aggregated 最优（1×TP2, batch 8 → 321.5 tok/s/GPU）高 101.6%。预测 frontier 与实测 frontier 紧密吻合（speed 偏差 ≤11.2%, throughput 偏差 ≤17.4%），证明系统能可靠地指导生产配置决策。

7. API & Usability #

用户接口:

• 输入: Workload descriptor（ISL, OSL, SLA targets, hardware config, target framework）
• 输出: Ranked list of optimal configurations + 性能预测 + 框架原生启动文件

集成方式:

• 直接生成 TRT-LLM / vLLM / SGLang 的启动参数
• 与 NVIDIA Dynamo 集成，自动配置推理服务器

易用性评价: 从论文描述看，用户只需提供 workload 描述即可获得推荐配置，门槛较低。但 PerfDatabase 的构建需要 ~30 GPU-hours 的离线投入，且未说明是否开放预构建的数据库。

8. Infrastructure Impact #

对 LLM Serving 生态的影响:

1. 降低调优门槛: 从「需要 GPU 专家+数天实验」降为「提供 workload 描述，30 秒出结果」
2. 加速 disaggregated serving 落地: 自动搜索最优 prefill/decode 分割，消除了手动试错的障碍
3. NVIDIA 生态绑定: 性能数据库绑定 NVIDIA 硬件+框架，进一步加深了对 NVIDIA 平台的依赖
4. 可能改变 serving 框架竞争格局: 通过统一抽象比较不同框架的最优配置，用户可以基于数据选择框架而非经验

对成本的影响: 一次性 30 GPU-hours 投入，后续每次搜索 <1s CPU 时间。对频繁调整配置的场景（新模型上线、workload 变化、硬件升级）节省巨大。

9. Comparison Matrix #

维度	AIConfigurator	手动调优	Vidur/APEX (simulator)	Vizier/Morphling (black-box opt)
搜索速度	<1s (CPU)	数天 (GPU)	分钟级 (CPU)	数小时 (GPU)
准确度 (TPOT)	6-12% MAPE	ground truth	未量化（roofline 偏差）	ground truth
准确度 (TTFT)	16-22% MAPE	ground truth	未量化	ground truth
框架支持	TRT-LLM/vLLM/SGLang	单框架	框架无关（但不准）	单框架
硬件支持	NVIDIA only	任意	理论上任意	任意
Disaggregated serving	✅	✅ (手动)	部分	❌
MoE 支持	✅ (power-law)	✅	有限	✅
离线成本	~30 GPU-hr/platform/framework	0	0	0
动态 workload	❌	❌	部分	❌
开源	❌	N/A	✅ (Vidur)	✅ (Vizier)

10. Adoption & Maturity #

成熟度: 中等偏高。来自 NVIDIA 内部团队，已在 H100/H200 上进行了 960+ 配置的验证，与 Dynamo 有集成。但论文未提及大规模生产部署的案例。

采用障碍:

1. 未开源: 最大障碍。社区无法使用、验证或贡献
2. NVIDIA only: AMD/Intel 用户完全排除在外
3. PerfDatabase 维护: 每次新框架版本发布都需要重新采集数据
4. 经验常数可靠性: 修正因子在不同 workload/hardware 下是否稳定未知

与现有工具链的关系:

• 补充 Dynamo（配置优化 → Dynamo orchestration）
• 竞争 Vidur/APEX（数据驱动 vs 理论模型）
• 替代 InferenceMax/nightly benchmarks（自动化 vs 静态 lookup）

展望: 如果 NVIDIA 将其集成到 Dynamo 或 TRT-LLM 的标准工具链中，有望成为 NVIDIA 生态下 LLM serving 的标准配置工具。但封闭性质限制了社区影响力。