Intel Arc B60 × 2（4 Tile）vLLM-XPU
Qwen3-Omni-30B-A3B Thinking vs Instruct 横向对比测试报告
测试日期：2026-05-25 报告版本：V1.1（硬件描述修正版）
一、测试概述
本次测试在同一台 2卡 Intel Arc B60 服务器 （每卡双 Tile，共 4 Tile）上，使用完全一致的硬件配置、软件环境和 vLLM 启动参数，对 Qwen3-Omni-30B-A3B-Thinking 和 Qwen3-Omni-30B-A3B-Instruct 两个变体进行极限并发压测，测试方法严格对齐《Intel Arc B60 vLLM-XPU Qwen模型测试报告 V1.6》。
核心目标：在控制变量的前提下，量化 Thinking（带推理过程）与 Instruct（纯指令遵循）两个版本在吞吐、延迟和扩展性上的差异。
二、测试环境（完全一致）
|---------|--------------------------------------------------------------------|
| 项目 | 规格 |
| GPU 型号 | Intel Arc Pro B60 Graphics (Dual-Tile) × 2 张 |
| 物理卡数 | 2 张 |
| Tile 数 | 4 个（每卡 2 Tile） |
| 总显存 | 96GB（4 Tile × 24GB） |
| 互联方式 | PCIe 4.0 x16（卡间），EMIB/MDFI（卡内 Tile 间） |
| vLLM 版本 | 0.14.1.dev0+gb17039bcc.d20260430（llm-scaler 下游） |
| 并行配置 | Tensor Parallel = 4（4 Worker 分布在 2 张卡上） |
| 启动参数 | --max-model-len 2048 --block-size 64 --gpu-memory-utilization 0.75 |
| 输入长度 | Prompt ≈ 472 tokens |
| 输出限制 | max_tokens = 256 |
| 超时 | 600s |
| 测试矩阵 | 并发度 1/5/10/15/20/30/50/100/150/200 |
三、完整数据对比表
|-------------|-------------|-----------------------|-----------------------|-----------------|----------------|-----------------|
| 并发度 | 请求数 | Thinking Output tok/s | Instruct Output tok/s | 差异 | 差异率 | 状态 |
| 1 | 20 | 18.05 | 17.88 | -0.17 | -0.9% | 串行基准 |
| 5 | 50 | 84.59 | 85.57 | +0.98 | +1.2% | 轻度负载 |
| 10 | 50 | 164.38 | 167.65 | +3.27 | +2.0% | 轻度负载 |
| 15 | 50 | 202.83 | 207.14 | +4.31 | +2.1% | 中度负载 |
| 20 | 50 | 262.89 | 271.42 | +8.53 | +3.2% | 中度负载 |
| 30 | 50 | 376.04 | 394.07 | +18.03 | +4.8% | 中度负载 |
| 50 | 50 | 642.93 | 711.73 | +68.80 | +10.7% | 接近饱和 |
| 100 | 100 | 970.87 | 1171.27 | +200.40 | +20.6% | 吞吐上升 |
| 150 | 150 | 1064.69 | 1292.43 | +227.74 | +21.4% | ⭐ 双版本峰值 |
| 200 | 200 | 1042.13 | 1255.55 | +213.42 | +20.5% | ⚠️ 性能拐点 |
四、关键发现
4.1 单线程性能几乎相同
- Thinking：18.05 tok/s
- Instruct：17.88 tok/s
- 差异：-0.9%（可忽略）
解释：单线程场景下，两个版本的模型权重、激活参数量（3B）、KV Cache 占用完全一致。Instruct 不输出 reasoning content，但输出 token 上限同样是 256，因此单请求的总计算量差异极小。
4.2 高并发下 Instruct 显著领先，且差距随并发扩大
差异率曲线
│
25%┤ ★ +21.4% (并发150)
20%┤ ★ +20.6% (并发100)
15%┤
10%┤ ★ +10.7% (并发50)
5%┤ ★ +4.8% (并发30)
3%┤ ★ +3.2% (并发20)
2%┤★ +2.0% (并发10)
1%┤★ +1.2% (并发5)
0%┤★ -0.9% (并发1)
0└────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬
1 5 10 15 20 30 50 100 150 200
并发度
核心规律 ： - 并发 ≤ 30 时，差异 < 5%，两版本几乎持平。 - 并发 ≥ 50 时，差异迅速拉大，Instruct 领先 10% 以上。 - 并发 100~200 时，差异稳定在 +20%~+21% 平台期。
4.3 峰值吞吐对比
|--------------|------------------------|------------------------|--------------------------------|
| 指标 | Thinking | Instruct | Instruct 领先 |
| 峰值吞吐 | 1,064.69 tok/s | 1,292.43 tok/s | +227.74 tok/s (+21.4%) |
| 峰值并发 | 150 | 150 | 相同 |
| 单线程吞吐 | 18.05 | 17.88 | -0.9% |
| 峰值加速比 | 59.0x | 72.3x | +22.5% |
| 零失败极限 | 200 | 200 | 相同 |
4.4 拐点行为一致
|----------|--------------------|--------------------|
| 指标 | Thinking (150→200) | Instruct (150→200) |
| 吞吐变化 | -2.1% | -2.9% |
| P90 延迟变化 | +36.3% | +37.5% |
| 结论 | 拐点明确 | 拐点明确 |
两个版本在并发 150 处同时达到饱和峰值，200 处同时出现性能拐点，说明 vLLM V1 调度器和 KV Cache 容量是共同的瓶颈，与模型变体无关。
五、根因分析：为什么 Instruct 高并发领先 21%？
5.1 原因一：Thinking 的 Reasoning Content 增加了有效序列长度
虽然两个版本的 --max_tokens=256 相同，但 Thinking 模型会先生成一段 reasoning content（思考过程），再生成最终回答。这段思考过程： - 占用 KV Cache 空间，挤占并行请求的可用容量； - 增加每次迭代的计算量（attention 需覆盖更长的历史 token）； - 在 continuous batching 场景下，长序列请求会拖慢整个 batch 的调度效率。
Instruct 模型直接输出最终答案，无中间 reasoning 步骤，KV Cache 利用更紧凑，batching 效率更高。
5.2 原因二：MoE 专家路由差异
Qwen3-Omni 的 MoE 架构中： - Instruct ：输入意图明确，专家路由（expert routing）更稳定、更可预测，减少了动态路由的计算开销； - Thinking：需要"思考"，路由决策更复杂，可能激活更多专家或更频繁切换，增加了 allreduce 通信频次。
在 TP=4 的分布式场景下，任何额外的 allreduce 都会被 PCIe 互联放大，高并发下累积效应显著。
5.3 原因三：Tokenizer 与生成策略的微观差异
虽然输出 token 数统计同为 256，但： - Thinking 的 reasoning content 通常包含大量短句、换行和标记符，实际生成步数可能略多； - Instruct 的生成更紧凑，decoder 步骤的 cache hit 率更高。
六、生产部署建议
6.1 模型选型决策树
是否需要模型展示思考过程？
├── 是（教育、调试、科研场景）
│ └── 选 Thinking 版本
│ 峰值吞吐: 1,064 tok/s
│ 适合: 需要可解释性的场景
│
└── 否（生产 API、客服、内容生成）
└── 选 Instruct 版本
峰值吞吐: 1,292 tok/s (+21.4%)
适合: 追求极致吞吐和性价比的场景
6.2 单实例部署推荐（2卡 TP=4）
|-----------------|------------------|-----------------|---------------------------|----------------|
| 场景 | 推荐版本 | 推荐并发 | 预期吞吐 | P99 延迟 |
| 实时对话 (< 20s) | Instruct | 10-20 | 168-271 tok/s | < 16s |
| 在线 API (< 30s) | Instruct | 30-50 | 394-712 tok/s | < 18s |
| 批处理 (< 40s) | Instruct | 100-150 | 1,171-1,292 tok/s | < 30s |
| 可解释性要求 | Thinking | 100-150 | 971-1,065 tok/s | < 36s |
6.3 单台 8卡服务器负载均衡架构（Instruct 版）
基于 Instruct 版本的峰值数据，单台 8卡 B60 服务器 可部署 4 个独立的 2卡 TP=4 实例：
- 单实例峰值：1,292.43 tok/s @ 并发 150
- 4 实例合计峰值 ：5,169.72 tok/s
- 单实例极限并发：200（零失败）
- 4 实例合计极限并发：800
- 批处理场景（并发 150/实例） ：可同时服务 600 客户，总吞吐 5,170 tok/s
对比 Thinking 版本同架构： - Thinking 4 实例合计峰值：4,258.76 tok/s - Instruct 领先 910.96 tok/s (+21.4%)
与 V1.6 文档结论一致 ：单台 8卡 B60 服务器可同时服务 600 客户，总吞吐 ~5,170 tok/s（Instruct 版）。
七、结论
- Instruct 版本是 2卡 B60 上的更优选择 ：在完全相同的硬件和配置下，峰值吞吐领先 Thinking 21.4%（1,292 vs 1,065 tok/s），零失败极限相同（200 并发）。
- 差异主要来自 reasoning content 的隐性成本：Thinking 的思考过程增加了有效序列长度和 KV Cache 压力，在高并发 continuous batching 下被放大。
- 单线程差异可忽略（-0.9%）：两个版本的基础计算能力相同，差异仅在并发扩展后显现。
- 拐点行为一致：两个版本均在并发 150 达峰、200 拐点，说明瓶颈在调度器和 KV Cache，与模型变体无关。
- 生产建议 ：除非业务需要可解释性（展示思考过程），否则优先部署 Instruct 版本，同等硬件可多服务21% 的客户。
附录 A：双版本启动命令
A.1 Thinking 版本
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
A.2 Instruct 版本
vllm serve /llm/models/Qwen3-Omni-30B-A3B-Instruct \
--served-model-name qwen3-omni-30b-a3b-instruct-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
报告生成时间：2026-05-25 版本：V1.1（硬件描述修正版：2卡 B60 × 4 Tile）