Intel Arc B60 × 2（4 Tile）vLLM-XPU
Qwen3-Omni-30B-A3B-Thinking 极限并发压测报告
测试日期：2026-05-25 报告版本：V1.1（硬件描述修正版）
一、测试概述
本次测试基于 Intel Arc Pro B60 GPU × 2 张物理卡 （每卡双 Tile，共 4 Tile），针对 Qwen3-Omni-30B-A3B-Thinking 模型在 vLLM-XPU 后端上的极限并发性能进行完整验证。测试严格遵循《Intel Arc B60 vLLM-XPU Qwen模型测试报告 V1.6》的 Benchmark 方法：输入约 472 tokens，输出 max_tokens=256，timeout=600s，覆盖并发度 1/5/10/15/20/30/50/100/150/200 的完整曲线。
二、测试环境
|-----------------------------|--------------------------------------------------------------------|
| 项目 | 规格 |
| GPU 型号 | Intel Arc Pro B60 Graphics (Dual-Tile) × 2 张 |
| 架构 | Xe2-HPG (Battlemage)，双 Tile 封装 |
| 单 Tile 显存 | 24GB GDDR6 |
| 单卡显存 | 48GB GDDR6（2 Tile × 24GB） |
| 物理卡数 | 2 张 |
| Level Zero 设备（Tile） | 4 个 |
| 总显存 | 96GB（4 Tile × 24GB） |
| 互联方式 | PCIe 4.0 x16（卡间），EMIB/MDFI（卡内 Tile 间） |
| 服务器 | x86 平台，Ubuntu 22.04 |
| vLLM 版本 | 0.14.1.dev0+gb17039bcc.d20260430（llm-scaler 下游） |
| IPEX 版本 | intel_extension_for_pytorch XPU |
| 测试模型 | Qwen3-Omni-30B-A3B-Thinking |
| 模型格式 | BF16，语言模型部分（--language-model-only） |
| 并行配置 | Tensor Parallel = 4（4 Worker 分布在 2 张卡上，每卡 2 Worker） |
| 启动参数 | --max-model-len 2048 --block-size 64 --gpu-memory-utilization 0.75 |
三、关键参数说明
3.1 模型特性：MoE 架构
Qwen3-Omni-30B-A3B-Thinking 为 Mixture-of-Experts (MoE) 架构： - 总参数量 ：30B - 激活参数量 ：3B（A3B = Activated 3 Billion） - 每 Tile 权重占用 ：15.82 GiB（BF16） - 每 Tile Peak Allocated ：16.95 GiB - 每 Tile Reserved：18.71 GiB
重要提示：MoE 模型每次前向传播仅激活约 3B 参数，计算量远低于同规模的 Dense 模型（如 Qwen3.5-27B 需激活全部 27B 参数）。这是本次测试吞吐显著高于 V1.6 文档中 Qwen3.5-27B 数据的核心原因。
3.2 KV Cache 容量约束
当前启动参数 --max-model-len 2048 导致： - GPU KV Cache 总量 ：42,816 tokens - 单请求 KV Cache 占用 ：约728 tokens（Prompt 472 + Completion 256） - 理论并行上限 ：42,816 / 728 ≈ 58.8x
这意味着并发 > 58 时，vLLM V1 调度器会将超出 KV Cache 容量的请求放入队列排队等待，而非并行执行。实测中并发 200 全部成功但耗时显著增加，验证了此行为。
四、完整 Benchmark 数据
|-------------|-------------|---------------|----------------|----------------|----------------|----------------|---------------|-----------------|----------------|----|
| 并发度 | 请求数 | 成功 | 失败 | 总耗时(s) | 平均延迟(s) | P90(s) | P99(s) | QPS | Output tok/s | 状态 |
| 1 | 20 | 20/0 | 283.614 | 14.180 | 14.287 | 14.342 | 0.071 | 18.05 | 串行基准 | |
| 5 | 50 | 50/0 | 151.313 | 15.127 | 15.165 | 15.173 | 0.330 | 84.59 | 轻度负载 | |
| 10 | 50 | 50/0 | 77.867 | 15.571 | 15.596 | 15.598 | 0.642 | 164.38 | 轻度负载 | |
| 15 | 50 | 50/0 | 63.107 | 15.917 | 16.051 | 16.055 | 0.792 | 202.83 | 中度负载 | |
| 20 | 50 | 50/0 | 48.690 | 16.355 | 16.614 | 16.622 | 1.027 | 262.89 | 中度负载 | |
| 30 | 50 | 50/0 | 34.039 | 17.115 | 17.551 | 17.557 | 1.469 | 376.04 | 中度负载 | |
| 50 | 50 | 50/0 | 19.909 | 19.880 | 19.897 | 19.900 | 2.511 | 642.93 | 接近饱和 | |
| 100 | 100 | 100/0 | 26.368 | 26.282 | 26.300 | 26.313 | 3.792 | 970.87 | 吞吐上升 | |
| 150 | 150 | 150/0 | 36.067 | 34.293 | 35.891 | 35.953 | 4.159 | 1064.69 | ⭐ 吞吐峰值 | |
| 200 | 200 | 200/0 | 49.130 | 42.321 | 48.909 | 48.973 | 4.071 | 1042.13 | ⚠️ 性能拐点 | |
关键指标汇总 ： - 峰值吞吐 ：1,064.69 tok/s @ 并发 150 - 单线程吞吐 ：18.05 tok/s - 峰值加速比 ：59.0x - 零失败率：全部 1,090 个请求成功，零 OOM、零 Worker 崩溃
五、性能曲线深度分析
5.1 拐点定位：并发 150 → 200
|--------------|----------|----------|----------------|
| 指标 | 并发 150 | 并发 200 | 变化幅度 |
| Output tok/s | 1,064.69 | 1,042.13 | -2.1% |
| QPS | 4.159 | 4.071 | -2.1% |
| 平均延迟 | 34.29s | 42.32s | +23.4% |
| P90 延迟 | 35.89s | 48.91s | +36.3% |
| P99 延迟 | 35.95s | 48.97s | +36.2% |
| 总耗时 | 36.07s | 49.13s | +36.2% |
结论：并发 150 为吞吐饱和峰值点；并发 200 出现明确性能拐点。虽然吞吐仅下降 2.1%，但 P90/P99 延迟暴涨 36%+，说明 vLLM V1 调度器在 200 并发下出现请求饥饿和队列堆积，batching 效率下降。
5.2 并行上限验证
理论 KV Cache 并行上限约 58.8x。实测数据验证：
|-----|--------|---------|--------|-------|
| 并发度 | 总耗时 | 单请求理论耗时 | 理论最小耗时 | 实际/理论 |
| 50 | 19.91s | ~15s | 15s | 1.33x |
| 100 | 26.37s | ~15s | 15s | 1.76x |
| 150 | 36.07s | ~15s | 15s | 2.40x |
| 200 | 49.13s | ~15s | 15s | 3.28x |
并发 50 时总耗时 19.9s ≈ 单请求延迟 19.9s，说明 50 并发已接近并行上限（因 KV Cache 限制，部分请求已开始轻微排队）。并发 100/150/200 时总耗时显著高于单请求延迟，确认超出并行上限后进入排队模式。
六、与 V1.6 文档对比分析
6.1 数据对比表
|--------------------|-----------------------------|------------------------------|---------------|
| 对比项 | V1.6 文档 (Qwen3.5-27B) | 本次测试 (Qwen3-Omni-30B-A3B) | 差异分析 |
| 模型架构 | Dense (27B 全激活) | MoE (30B 总参 / 3B 激活) | 核心差异 |
| 硬件配置 | 2卡 B60 TP=4（4 Tile） | 2卡 B60 TP=4（4 Tile） | 完全一致 |
| 峰值吞吐 | 336.34 tok/s | 1,064.69 tok/s | +216% |
| 峰值并发 | 150 | 150 | 相同 |
| 单线程吞吐 | ~11.4 tok/s | 18.05 tok/s | +58% |
| 零失败极限 | 200x | 200x | 相同 |
| 拐点 | 150→200 (-18.5%) | 150→200 (-2.1%) | 拐点更平缓 |
| P99 延迟(峰值) | 112.1s | 35.95s | -68% |
6.2 核心差异解释
1. MoE vs Dense：计算量决定吞吐
- Qwen3.5-27B (Dense)：每次前向传播激活 27B 参数，计算密集度高，单线程约 11.4 tok/s。
- Qwen3-Omni-30B-A3B (MoE)：每次前向传播仅激活 3B 参数，计算量约为 Dense 的 1/9，单线程达 18.05 tok/s。
虽然总参数量 30B > 27B，但 MoE 的稀疏激活特性使实际 FLOPs 大幅降低，GPU 计算单元利用率更高，因此并发扩展后的总吞吐远超 Dense 模型。
2. 硬件配置一致，模型差异主导
本次测试与 V1.6 文档均采用 2卡 B60 TP=4（4 Tile） 的相同硬件配置。吞吐差异 3.17 倍完全来自模型架构差异（MoE vs Dense），而非硬件扩展。
七、关键结论
- Qwen3-Omni-30B-A3B-Thinking 在 2卡 B60 上表现优异 ：峰值吞吐 1,064.69 tok/s，是 V1.6 文档中同配置 Qwen3.5-27B（336 tok/s）的 3.17 倍。
- MoE 架构是 B60 的绝配：激活参数仅 3B，计算量低，GPU 利用率更高，在 PCIe 互联的 B60 上通信瓶颈被显著弱化。
- 并发 150 为最佳甜点：吞吐峰值 1,064.69 tok/s，P99 延迟 35.95s，零失败。
- 并发 200 为性能拐点：吞吐微降 2.1%，但 P90 延迟暴涨 36.3%，不建议生产环境使用。
- KV Cache 是主要瓶颈：当前 42,816 tokens 仅支持约 58x 真并行。若提升 --max-model-len 至 4096 或 8192，并发上限可翻倍，但需验证显存是否足够（当前每 Tile Reserved 18.71GB / 24GB，余量约 5GB）。
- 全部零失败：1,090 个请求 100% 成功，系统稳定性优秀。
八、生产环境部署建议
8.1 单实例并发推荐（2卡 TP=4）
|-------------------|-----------------|-------------------------|----------------|-------------------|
| 业务场景 | 推荐并发 | 预期吞吐 | P99 延迟 | 适用业务 |
| 实时对话（延迟 < 25s） | 5-10 | 85-164 tok/s | < 16s | 客服机器人、即时问答 |
| 在线 API（延迟 < 40s） | 20-50 | 263-643 tok/s | < 20s | 内容生成、代码补全 |
| 批处理（延迟 < 40s） | 100-150 | 971-1,065 tok/s | < 36s | 文档生成、批量翻译 |
| 后台任务（延迟 < 50s） | 150-200 | 1,042-1,065 tok/s | < 49s | 离线分析、数据标注 |
8.2 单台 8卡服务器负载均衡架构建议
基于本次 2卡 TP=4 的实测数据，在单台 8卡 B60 服务器 上可部署 4 个独立的 2卡 TP=4 实例（每实例绑定 2 张物理卡的 4 个 Tile）：
- 单实例峰值吞吐：1,064.69 tok/s @ 并发 150
- 4 实例合计峰值吞吐 ：4,258.76 tok/s
- 单实例极限并发（零失败）：200
- 4 实例合计极限并发：800
- 在批处理场景下（并发 150/实例） ：可同时服务 600 个客户
实例隔离方式（通过环境变量绑定 Tile）：
# 实例 1（卡 0,1 = Tile 0,1,2,3）
export ZESYCL_DEVICE_FILTER=level_zero:0,1,2,3
vllm serve /llm/models/Qwen3-Omni-30B-A3B-Thinking \
--served-model-name qwen3-omni-tp4-inst1 \
--tensor-parallel-size 4 --port 8000 ...
# 实例 2（卡 2,3 = Tile 4,5,6,7）
export ZESYCL_DEVICE_FILTER=level_zero:4,5,6,7
vllm serve ... --port 8001 ...
# 实例 3（卡 4,5 = Tile 8,9,10,11）
export ZESYCL_DEVICE_FILTER=level_zero:8,9,10,11
vllm serve ... --port 8002 ...
# 实例 4（卡 6,7 = Tile 12,13,14,15）
export ZESYCL_DEVICE_FILTER=level_zero:12,13,14,15
vllm serve ... --port 8003 ...
与 V1.6 文档结论一致 ：单台 8卡 B60 服务器可同时服务 600 客户 ，总吞吐 ~4,259 tok/s。
8.3 参数优化建议
若业务需要更高并发，可尝试： 1. 提升 --max-model-len 至 4096 ：KV Cache 翻倍至 ~85,000 tokens，理论并行上限提升至 ~116x。 2. 提升 --gpu-memory-utilization 至 0.85 ：释放更多显存给 KV Cache（当前 0.75 较保守）。 3. 注意：提升 max-model-len 后需重新验证 block_size=64 的兼容性和显存占用。
附录 A：启动命令
vllm serve /llm/models/Qwen3-Omni-30B-A3B-Thinking \
--served-model-name qwen3-omni-30b-a3b-thinking-tp4 \
--dtype bfloat16 --enforce-eager \
--port 8000 --host 0.0.0.0 --trust-remote-code \
--disable-sliding-window \
--gpu-memory-utilization 0.75 \
--max-num-batched-tokens 4096 \
--max-model-len 2048 \
--block-size 64 \
--tensor-parallel-size 4 \
--language-model-only
附录 B：压测脚本
见 /tmp/bench_qwen3_omni_tp4_full.py
附录 C：监控命令
# 显存与 GPU 利用率（2卡场景）
watch -n 2 'xpu-smi dump -d 0,1 -m 0,1,2,3,4,5'
# 进程监控
watch -n 3 'ps aux | grep -E "vllm serve|EngineCore|Worker" | grep -v grep'
报告生成时间：2026-05-25 版本：V1.1（硬件描述修正版：2卡 B60 × 4 Tile） 审核状态：待审核