你的 LLM 服务器真的能处理多少用户？
请提供您希望翻译的完整文本（除保留的 Source: 链接外的所有内容），这样我才能为您进行准确的简体中文翻译。谢谢！
问题
基础设施工程师经常面对庞大的配置空间，并提出诸如：
- 调整 vLLM 中的
--max-num-batched-tokens或--gpu-memory-utilization能否提升吞吐量？ - 这些更改是否可能无意中降低尾部延迟？
官方 vLLM 文档解释了 如何 调优这些参数，但很少提供一种 系统化方法 来为特定工作负载、硬件架构和严格的服务水平协议（SLA）发现 最佳 配置。
Our Solution
我们开展了一项全面的容量规划工作，针对一个 1200亿参数的 Mixture‑of‑Experts (MoE) 模型（gpt‑oss‑120b），该模型部署在多个 NVIDIA H100 与 H200 集群上，用以驱动内部 AI 编码助手。
与其仅仅发布最终的容量指标，我们记录了实现这些指标的 端到端方法论。
阅读完整技术白皮书：
SPOC: a Stateful, Profile‑based Optimization for LLM Capacity Planning Methodology
该白皮书是 LLM 性能工程的综合指南，为基础设施团队提供了所需的分析工具和实证技术，帮助他们：
- 构建有状态的多轮数据集，精准模拟开发者查询共享企业 monorepo 的场景。
- 应用多目标进化算法（Optuna NSGA‑II）在数学上探索推理引擎的参数空间，用严谨的优化取代经验性的猜测。
- 部署高级遥测栈（Prometheus + DCGM Exporter），将内部推理引擎指标与物理硬件状态关联起来。
- 捕获并解析内核级 NVIDIA Nsight Systems 跟踪，识别真实的架构瓶颈——这往往与简单的理论 roofline 预测相悖。
Who Should Read This?
如果您负责 LLM 基础设施的扩展，本篇论文提供了从容量估算到 系统化测量与优化 所需的 实证蓝图。
Source:
Just Run a Benchmark 概念的问题
标准的 LLM 基准会在固定的并发下发送固定的提示，并报告平均延迟或单轮指标（MLPerf、GenAI Perf、InferenceMax）。这对排行榜比较有效，但在实际使用场景的 容量规划 中表现不足——例如，针对编码任务或日志分析的多次后续提问。在这些情形下，多轮流量模拟是必需的。
为什么真实流量如此混乱
| 流量段 | 用户占比 | 请求大小（tokens） | 对系统的压力表现 |
|---|---|---|---|
| 短请求 | 70 % | 5 k → 50 k | 为 首个 token 时间 (TTFT) 设定底线 |
| 中等请求 | 20 % | 15 k → 120 k | 在 TTFT 与计算负载之间取得平衡 |
| 大请求 | 10 % | 75 k → >128 k（触及上下文上限） | 主导 GPU 内存带宽 与 prefill 计算 |
- 短请求 主导请求速率，决定用户看到的最小延迟。
- 大请求 消耗最多的 GPU 内存和计算资源，往往成为瓶颈。
- 将所有流量都视为“平均大小”只能得到一个单一数值，无法预测系统真正会在哪儿崩溃。
结论
我们需要一种基准，能够反映生产工作负载中 请求大小的异构混合和多轮交互，而不仅仅是单轮、平均大小的测试。
我们构建的内容
白皮书描述了一个包含三个核心阶段的框架：
1. 工作负载建模
- 用户画像 – 定义了三个画像（P0、P1、P2），基于观测到的使用模式进行校准。每个画像都有自己的提示大小分布、输出预算和思考时间。
- 有状态语料库 – 基于开源轨迹构建：
- 仿真 – 使用 Locust 生成多轮流式对话，模拟真实开发者与编码助手的交互。仿真包括 Partial Common Ground 几何结构，以模拟共享企业单体仓库。
2. 进化参数搜索
我们没有采用手动调参或穷举网格搜索，而是使用 Optuna 及其 NSGA‑II 采样器 在目标并发度下探索 vLLM 参数空间。
NSGA‑II 是一种多目标进化算法，可同时优化：
- 吞吐量
- 首 token 时间（TTFT）
- Token 间延迟
该算法发现了 Pareto 前沿——即改进某一指标会导致另一指标退化的配置集合。
3. 内核级剖析
在容量上限的稳态负载下（4 × H100 上 300 并发用户，2 × H200 上 85 并发用户），捕获 NVIDIA Nsight Systems 跟踪。
将 GPU 活动时间分解为功能类别：
- Flash Attention
- MoE Expert GEMMs
- NCCL 集体通信
跟踪显示，对于大批量的稀疏 MoE 架构，系统主要受 Attention 计算 和 内存带宽 限制，这与简单的 roofline 预测相矛盾。
4. 扩展最佳配置
- 将最优配置在不同并发水平上进行扫描。
- 使用 Prometheus 和 DCGM Exporter 硬件计数器收集指标。
你将从本文中学到的内容
本文既是参考资料也是实用指南，涵盖以下主题：
- 工作负载模拟 – 设计能够反映真实用户行为和有状态上下文累积的仿真，而不是依赖无状态的合成平均值。
- 多目标优化 – 高效搜索 vLLM 参数空间，亲身体验优化循环如何显著提升 GPU 性能。
- 可观测性栈 – 部署 Prometheus 和 DCGM Exporter，同步获取推理引擎内部和 GPU 硬件状态的可视化信息。
- 内核追踪 – 在负载下从容器化的 vLLM 部署中捕获并解读 NVIDIA Nsight Systems 跟踪数据。
关键发现
分块预填是重要的权衡
- 为了保护正在生成过程中的 inter‑token latency (ITL)，防止 128k‑token 用户导致的大幅预填峰值，必须仔细调节
--max-num-batched-tokens。 - 我们发现，在 4× H100 系统上将其设为 2048，或在 2× H200 系统上设为 1024，会稍微牺牲 TTFT 速度，但能够实现平滑流式输出并防止 CUDA‑graph 编译超时。
- 为了保护正在生成过程中的 inter‑token latency (ITL)，防止 128k‑token 用户导致的大幅预填峰值，必须仔细调节
GPU 利用率不是 SLA 指标
- 在容量上限时我们测得约 37 % SM 活跃。
- 虽然看起来约 60 % 的计算能力处于空闲状态，但进一步提升利用率会填补调度空隙，却会降低每步解码延迟 (ITL)，导致 SLA 违约。
显存并非总是瓶颈
- 即使有 10 % 的用户提交了巨大的 80k–128k‑token 上下文，活跃的 KV‑cache 使用率仍保持在低水平（在 4× H100 上约 10.5 %）。
- 由于数据集模拟的是共享企业 monorepo，vLLM 的前缀缓存能够高效去重共享根部。系统的瓶颈在注意力内核和内存带宽，而非显存容量。
在尾部延迟约束下硬件扩展呈非线性
- 4× H100 系统实现了约 3.5× 于 2× H200 系统的容量（300 vs 85 用户），而非预期的 2×。
- 这源于整体内存带宽提升、Tensor‑Parallelism 的数学划分以及在较小 GPU 集群上分块预填的惩罚。
Tensor Parallelism 的热敏脆弱性
- 当 TP > 1 时，整个推理步骤的速度受最慢 GPU 限制。
- 单个 GPU 的热降频会迫使所有健康 GPU 在 NVLink 同步屏障处等待，导致全系统出现严重的延迟峰值。
硬件剖析现实与理论模型的差异
- 对量化的假设可能误导容量规划。
- 例如，gpt‑oss‑120b 将专家权重存储为 MXFP4（4‑bit），但 vLLM 在 H100 上会在 SM 寄存器中将其解包为 BF16 再进行矩阵乘法（W4A16）。
- 若假设模型完全在 FP4 中运行，会误判瓶颈所在——这一差异已通过我们的内核剖析得到验证。
阅读白皮书
我们无法声称知道您部署的最佳用户数量；每个部署都有模型、硬件、工作负载组合和延迟目标的独特组合，导致不同的目标数值。我们研究的价值体现在白皮书中详细阐述的方法论上：一种可重复的过程，帮助您自信地找到自己的答案。
完整的论文可在此处获取：SPOC: a Stateful, Profile‑based Optimization for LLM Capacity Planning Methodology。
如果您将该框架应用到自己的环境中，我们很想听听您的反馈。最好的基准测试是能够反映您真实用户的那些。
了解更多 VMware Cloud Foundation (VCF) 博客内容
订阅即可将最新文章发送到您的邮箱。