问题：队列很长，活跃请求却太少
繁忙的请求队列并不保证 GPU 正在充分利用可用处理能力完成有效工作。在 vLLM 0.25.1 上运行 Qwen3-30B-A3B 时，ProsGrow 发现初始服务配置限制了短提示词批次中可同时执行的工作量。尽管队列中任务充足，输出吞吐量仍只有 17,961 token/s。
通过性能分析和调度行为调整，我们将这一速率提升至 41,651 输出 token/s，即提升 132%，达到原来的 2.32 倍。GPU、运行时、检查点、精度、请求数及提示词与输出规格均保持不变。这是相对于 ProsGrow 初始配置测得的改善，并非与已充分调优的 vLLM 基线比较。
基线 → ProsGrow 调优后
在这组受控对比中，请求延迟中位数也从 15.91 秒降至 11.70 秒。这一提升揭示了该工作负载中可释放的处理能力，并不能证明相对于其他推理引擎或充分优化的部署具有普遍优势。
调度器为何重要
ProsGrow 将提交的负载与引擎实际接纳执行的工作区分开来，然后在相同工作负载下比较已完成吞吐量和请求延迟。证据指向调度瓶颈：初始配置无法把长队列转化为足够的并发执行。该结果不能单独归因于算子内核加速。
工程工作的目标是找出这套服务栈中的限制环节，在受控条件下评估其影响，并验证一个实用的运行配置。由于模型可容纳在单张 GPU 上，独立副本提供了一种切实可行的方法，用来检验单 GPU 释放的处理能力能否延续到整个节点。
权衡：并发继续增加，最终只会带来等待
一个独立的饱和负载配置在两次单独运行中达到 45,941 和 46,701 输出 token/s，延迟中位数接近 20 秒。在同一轮扫描中，继续增加负载仅带来 0.91% 的吞吐量增长，延迟中位数却从 20.04 秒升至 29.85 秒。继续排队已无法换来有意义的处理能力提升。
显存同样限制了选择：服务开销压缩了可用于键值缓存的空间。短提示词为选定配置留下了足够余量。更长的上下文或面向交互的延迟目标，都需要独立评估。
从单 GPU 调优到八 GPU 批处理服务
使用八个独立副本时，两次同步运行分别达到 362,812 和 361,679 输出 token/s。我们采用较低值估算处理能力。每次运行均完成全部 32,768 个请求和 8,388,608 个输出 token，没有失败或输出不足的响应。
较低结果使用从首个客户端启动到最后一个请求完成的共同实际计时窗口，时长为 23.19 秒。将全部工作计入这一共享时间区间，可避免通过相加各副本独立计时的速率来夸大节点结果。
本地提升 132% 与公开对比提升 8.17% 的关系
上文的 132% 增幅测量的是对排队短请求进行调度调整的效果。能力报告中的 8.17% 对比回答的是另一个问题：在更长且明确规定的请求规格下，本地运行相对于留存的公开参考表现如何？
| 对比项目 | 基线 → 本地结果 | 该结果说明什么 |
|---|---|---|
| 本地调度器调优 | 17,961 → 41,651 输出 token/s/GPU · +132% | 同为 vLLM 0.25.1；63–66 输入 / 256 输出 token；2,048 个排队请求 |
| 留存的 NVIDIA 参考结果 | 9,938 → 10,750.04 输出 token/s/GPU · +8.17% | 相同的 RTX PRO 6000 SKU 与 1,000 输入 / 1,000 输出规格；主机和 TensorRT-LLM 版本不同 |
| 独立的整节点处理能力 | 85,409 输出 token/s/节点 | 八个并发 TP1 副本，采用 1,000 / 1,000 规格；同步扩展效率 99.31% |
公开规格测试采用排队的合成请求和 TensorRT-LLM 1.3.0rc24，而留存的 NVIDIA 参考使用 1.1 版本。在这一长队列下，平均请求延迟为 173.04 秒。9,938 这一数值来自 2026 年 8 月 17 日留存的 NVIDIA 参考页面；在后续来源复核时，该行已不再显示。我们将其保留为带日期的对比，工作负载依据公开性能测试方案定义。
+8.17% 属于独立的单 GPU 结果。无论该结果，还是节点吞吐量 85,409 与 361,679 token/s 之间的差异，都不能单独归因于纯软件改进；后者的运行时和请求长度均发生了变化。这些速率描述的是批处理能力，交互式服务需要自己的延迟目标。
这对客户意味着什么
私有生成队列和合成数据任务可以通过在既有硬件上更快完成工作而受益。ProsGrow 可以先测量服务中可释放的处理能力，再建议是否增加 GPU。
选定的吞吐量配置需要长队列，并接受约 20 秒的延迟中位数。部署验收必须使用客户自己的模型、请求长度分布、质量检查和流量轨迹。交互式助手需要独立设定延迟目标。
方法与局限
- 硬件与软件：测试于 2026 年 8 月 18 日在配备八张 NVIDIA RTX PRO 6000 Blackwell Server Edition GPU 的节点上进行。受控参数扫描使用一张 GPU。运行时为
vllm/vllm-openai:v0.25.1，采用 ModelOpt NVFP4 权重和 FP8 键值缓存。 - 模型与请求：固定的 NVIDIA Qwen3-30B-A3B-FP4 检查点使用修订版本
2538ded2a4edb247b4d2b4a8ba24e44bd4c017c3。重复使用技术指南提示词，并变更请求标识符，API 报告的输入长度为 63–66 token。温度设为零，关闭思考模式，每个响应均达到 256 token 上限。 - 测量：吞吐量等于已完成输出 token 数除以客户端观测到的耗时，包括提示词处理和本地 HTTP 开销。132% 的对比中每个配置只测量一次。选定的饱和负载配置进行了两次单独重复运行和两次同步节点重复运行；后者每次仅约 23 秒。
- 质量与运维：固定输出长度只验证生成工作量，不验证任务质量。这些是在较早的 Qwen3 检查点上进行的本地饱和负载测量，并非持续生产稳定性测试、客户 SLA 或质量等效性测试。代表性提示词、p95/p99 延迟、网络开销、失败情况及领域质量仍属于生产验收条件。
历史 vLLM 0.23 对比也未纳入标题中的增幅，因为其原始提示词请求没有留存。同版本本地对比提供了受控基线。
私有 Qwen3 部署与 vLLM 批量推理
计划私有 Qwen3 部署的团队可以用这项基准测试讨论批量推理处理能力、GPU 利用率和可接受的排队时间。每秒输出 token 数衡量已完成生成的吞吐量，请求延迟则反映任务等待和执行的总时长。vLLM 部署规模应根据客户的请求组合和交付目标确定。