Intel Arc B60 Qwen3-Omni-30B-A3B 压测报告
测试严格遵循《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 的完整曲线。：MoE 模型每次前向传播仅激活约 3B 参数，计算量远低于同规模的 Dense 模型（如 Qwen
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） 审核状态：待审核
免费领 100 小时云算力，进群参与显卡、AI PC 幸运抽奖
更多推荐
2
0- 0
已为社区贡献3条内容
所有评论(0)