Qwen3-ASR-1.7B 在 A100 上：SGLang-Omni 与 vLLM-Omni 的一次可审计对比
Qwen3-ASR-1.7B 在 A100 上：SGLang-Omni 与 vLLM-Omni 的一次可审计对比
这不是一篇“跑个数字然后选边站”的文章。多模态推理 benchmark 最容易犯的错，是把不同输入、不同缓存状态、不同服务配置跑出的吞吐放在一起，再给出一个很确定的引擎结论。
这次测试的目标更窄：在同一台 A100 主机上，让 SGLang-Omni 与 vLLM-Omni 服务同一个 Qwen/Qwen3-ASR-1.7B，对同一段音频走 OpenAI 兼容的 /v1/audio/transcriptions API，并保留足以复核结果的原始 JSON、服务启动日志、输入哈希和客户端脚本。
结论先说：在这次实际服务配置下，SGLang-Omni 在 C1、C32、C64、C128 的吞吐更高；C16 的两次重复有重叠，差距不宜夸大。 这不是“引擎本体绝对更快”的证明，因为两侧的并发上限并不相同。
测试对象与相同口径
- 主机：
coder-a100-01，8 × NVIDIA A100-SXM4-80GB，driver580.126.16 - 模型：
Qwen/Qwen3-ASR-1.7B - API：
POST /v1/audio/transcriptions - 输入：
rt_test_16k.wav，16 kHz、单声道、PCM-16、6.480 秒，SHA-256：2c78a3c40a4f9fb1eaf07a7c66e31319191083034595fe3b2b28073863936cd0 - 并发矩阵：C1 / C16 / C32 / C64 / C128；分别发起 12 / 48 / 96 / 192 / 384 个请求
- 预热：每个 run 先做 4 个 warm-up
- 成功判据：HTTP 200 且
text非空
每一个 warm-up 和测量请求都会把原始 PCM 的一个采样点扰动 1 LSB。这使每份请求的字节串不同，但不改变可听语音内容和时长。换言之，它防止了“所有请求恰好命中同一份音频缓存”而把缓存收益误报成引擎吞吐。
两侧的直接单请求转写均为：
简单的说，这相当于惠普把消费领域市场拱手相让了。
所有测量 run 的成功请求也都得到 24 个字符的同一文本。
配置差异：为什么不能过度归因
SGLang-Omni 使用 lmsysorg/sglang:latest，其中 sglang==0.5.18、
sglang-omni==0.1.4；服务在 GPU 4 上运行，mem-fraction-static=0.70，
配置中的 max_running_requests=64、max_new_tokens=128。
vLLM-Omni 使用 vllm/vllm-openai:v0.28.0，vllm==0.28.0，实际 editable
checkout 为 651b03225b69fe825525e1cfa00300fe856fcea0；服务在 GPU 5 上运行，
gpu-memory-utilization=0.70、max-num-seqs=128、
max-num-batched-tokens=2048、max-model-len=512，开启 async scheduling，
并显式关闭 prefix caching。
所以这里能回答的是“这两套已记录配置下，谁给出了怎样的端到端 ASR 服务表现”；不能回答“如果把所有调度、批处理和资源约束完全对齐，哪个引擎内核必然更快”。
结果
吞吐单位为成功请求数 / 秒；C1 和 C16 各做两次独立重复，表中的吞吐取两次中位数。C32、C64、C128 各只有一次重复，必须按单次观测阅读。
| 并发 | SGLang-Omni 吞吐 (req/s) | vLLM-Omni 吞吐 (req/s) | SGLang 相对优势 |
|---|---|---|---|
| C1 | 9.07 | 7.17 | 26.5% |
| C16 | 43.80 | 39.57 | 10.7% |
| C32 | 68.95 | 50.84 | 35.6% |
| C64 | 72.37 | 64.02 | 13.0% |
| C128 | 72.64 | 67.18 | 8.1% |
端到端延迟的 p50 如下。注意 C128 的 p50 包含排队等待，因此它不是单次模型计算耗时。
| 并发 | SGLang-Omni p50 | vLLM-Omni p50 |
|---|---|---|
| C1 | 106.2 ms | 136.4 ms |
| C16 | 325.1 ms | 390.1 ms |
| C32 | 434.7 ms | 618.4 ms |
| C64 | 832.0 ms | 973.6 ms |
| C128 | 1499.8 ms | 1728.2 ms |
两边都会在高并发时接近饱和：SGLang 从 C64 到 C128 基本维持在约 72.5 req/s；vLLM 从 C64 的 64.0 增至 C128 的 67.2 req/s，但每个请求的排队延迟继续上升。这里最值得带走的不是某个百分比，而是：吞吐平台出现后，再继续推高客户端并发主要是在交换更长的尾部等待时间。
原始 evidence 与可复核边界
以下文件已保存在对应实验仓库的 bench/results/ 下：
- SGLang-Omni：原始 JSON、实际 benchmark client、环境与模型 ready 记录、SHA-256 清单
- vLLM-Omni：原始 JSON、服务启动脚本、矩阵脚本、完整服务日志、SHA-256 清单
原始客户端输出保存了每个 run 的请求总数、成功/失败计数、延迟分位数、文本长度分布、warm-up 数量、输入变体数量及变体 offset。它没有序列化每个成功请求的逐条延迟；因此本文不声称有未记录的 tail-latency 分布，也不从单次 C32/C64/C128 run 推导置信区间。
下一轮要把结论从“可审计的实际配置对比”推进到“更强的因果判断”，最小改动是：
- 对齐
max_running_requests/max-num-seqs和批处理限制； - 每个并发档至少重复三次，报告中位数和离散度；
- 记录 GPU utilization、显存、服务端 queue time 与分阶段时间；
- 用同一协议补齐 Qwen3-TTS 的吞吐、首音频延迟、音频时长和非静音产物校验。
这次真正做对的判断不是“谁赢了”，而是没有让相同文本、0 失败和一串漂亮吞吐掩盖配置差异与证据边界。