vLLM 推理性能深度分析：阶梯并发实验、Roofline 模型与调度瓶颈验证

环境：AutoDL | 2×RTX 4080 | Qwen/Qwen2.5-7B-Instruct 涵盖 TP=1 与 TP=2 两组阶梯并发实验，以及调度瓶颈深度分析

一、实验环境与基础配置

1.1 服务启动（TP=2）

vllm serve /root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct --tensor-parallel-size 2

显存状态（冷启动后）

GPU 0: 30356MiB / 32760MiB  —  VLLM::Worker_TP0
GPU 1: 30356MiB / 32760MiB  —  VLLM::Worker_TP1
功耗：GPU0 37W / GPU1 39W（冷启动空载，P2 状态）

1.2 统一压测参数

所有压测使用相同的参数口径：

./vllm-bench --backend vllm --base-url http://127.0.0.1:8000 \
  --model /root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct \
  --dataset-name random \
  --random-input-len 1024 --random-output-len 128 \
  --num-prompts 1000 --max-concurrency 200

1.3 GPU 裸算力基线（并发=1）

将并发度调为 1，消除 prefill 与 decode 的互相抢占，得到 GPU 纯算力基线。

TP=1 基线（单卡）

./vllm-bench --backend vllm --base-url http://127.0.0.1:8000 \
  --model /root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct \
  --dataset-name random \
  --random-input-len 1024 --random-output-len 128 \
  --num-prompts 1000 --max-concurrency 1

TP=2 基线（双卡）

TPOT 增量对比

TPOT 增量 = 实际 TPOT − conc=1 裸算力 TPOT。注意：高并发下 decode step 同时处理多个 token（GEMM），FLOPs 远高于 conc=1 的 GEMV 操作。因此 TPOT 增量中同时包含了合法计算增长与调度/同步开销，不应全部归为"空闲时间"。

二、TP=2 冷启动 vs 热启动

首次发现：冷启动后第一次压测的吞吐明显低于紧接着的第二次，差异约 13%。

2.1 整体概览

2.2 延迟指标

2.3 Steady-State 对比

2.4 实验结论

现象总结

核心推论

• Warmup 很重要：第一次压测触发了 scheduler 和 attention 后端的初始化，第二次直接受益
• 当前瓶颈在 CPU/调度侧：GPU-Util 两次均为 99%，说明 GPU 持续有 kernel 在执行，TPOT 差异来自 scheduler 排队优化（注：GPU-Util 仅表示非空闲，不直接反映 SM 饱和度）
• 单请求的 TTFT/TPOT 没变，但整体吞吐提升 → 请求之间重叠度更高，空闲时间更少

E2EL 验算公式

E2EL ≈ TTFT + (output_len - 1) × TPOT

第一次: 4105 + 127 × 255 = 36490 ≈ 36520 ✅
第二次: 4076 + 127 × 222 = 32270 ≈ 32294 ✅

2.5 原始日志

================= Serving Benchmark Result =================
Successful requests:                     1000      
Failed requests:                         0         
Maximum request concurrency:             200       
Benchmark duration (s):                  184.06    
Total input tokens:                      1021847   
Total generated tokens:                  128000    
Request throughput (req/s):              5.43      
Output token throughput (tok/s):         695.43    
Peak output token throughput (tok/s):    3683.00   
Peak concurrent requests:                210.00    
Total token throughput (tok/s):          6247.13   
--------------------Time to First Token---------------------
Mean TTFT (ms):                          4105.63   
Median TTFT (ms):                        1316.94   
P99 TTFT (ms):                           28579.09  
P90 TTFT (ms):                           13852.11  
----------Time per Output Token (excl. 1st token)-----------
Mean TPOT (ms):                          255.23    
Median TPOT (ms):                        281.67    
P99 TPOT (ms):                           288.21    
P90 TPOT (ms):                           285.97    
--------------------Inter-token Latency---------------------
Mean ITL (ms):                           255.23    
Median ITL (ms):                         325.15    
P99 ITL (ms):                            335.78    
P90 ITL (ms):                            329.41    
---------------------End-to-end Latency---------------------
Mean E2EL (ms):                          36520.30  
Median E2EL (ms):                        37314.13  
P99 E2EL (ms):                           62661.13  
P90 E2EL (ms):                           47221.33  
============================================================
============ Steady-State Metrics =============
Concurrency threshold:              >= 0.95 * 200 = 190
Window:                             0.1s -> 180.7s  (180.6s)
Observed peak concurrency:          200
Requests started in window:         811 / 1000 (81.1%)
Requests completed in window:       810
-----------------------------------------------
Request throughput (req/s):         4.48
Output token throughput (tok/s):    653.02
Input token throughput (tok/s):     4588.30
Total token throughput (tok/s):     5241.31
-----------------------------------------------
Mean TTFT (ms):                     1888.12
Median TTFT (ms):                   1315.00
P99 TTFT (ms):                      28543.14
P90 TTFT (ms):                      2914.28
-----------------------------------------------
Mean TPOT (ms):                     254.27
Median TPOT (ms):                   282.80
P90 TPOT (ms):                      286.04
P99 TPOT (ms):                      288.31

================= Serving Benchmark Result =================
Successful requests:                     1000      
Failed requests:                         0         
Maximum request concurrency:             200       
Benchmark duration (s):                  162.91    
Total input tokens:                      1021847   
Total generated tokens:                  128000    
Request throughput (req/s):              6.14      
Output token throughput (tok/s):         785.70    
Peak output token throughput (tok/s):    3800.00   
Peak concurrent requests:                217.00    
Total token throughput (tok/s):          7058.06   
--------------------Time to First Token---------------------
Mean TTFT (ms):                          4076.72   
Median TTFT (ms):                        1941.42   
P99 TTFT (ms):                           22938.96  
P90 TTFT (ms):                           13225.27  
----------Time per Output Token (excl. 1st token)-----------
Mean TPOT (ms):                          222.19    
Median TPOT (ms):                        222.21    
P99 TPOT (ms):                           282.03    
P90 TPOT (ms):                           277.71    
--------------------Inter-token Latency---------------------
Mean ITL (ms):                           222.19    
Median ITL (ms):                         318.70    
P99 ITL (ms):                            333.32    
P90 ITL (ms):                            328.38    
---------------------End-to-end Latency---------------------
Mean E2EL (ms):                          32294.56  
Median E2EL (ms):                        33904.32  
P99 E2EL (ms):                           47541.62  
P90 E2EL (ms):                           39384.57  
============================================================
============ Steady-State Metrics =============
Concurrency threshold:              >= 0.95 * 200 = 190
Window:                             0.1s -> 159.6s  (159.5s)
Observed peak concurrency:          200
Requests started in window:         811 / 1000 (81.1%)
Requests completed in window:       810
-----------------------------------------------
Request throughput (req/s):         5.08
Output token throughput (tok/s):    739.41
Input token throughput (tok/s):     5195.51
Total token throughput (tok/s):     5934.91
-----------------------------------------------
Mean TTFT (ms):                     2168.68
Median TTFT (ms):                   1639.29
P99 TTFT (ms):                      22938.77
P90 TTFT (ms):                      3541.12
-----------------------------------------------
Mean TPOT (ms):                     228.32
Median TPOT (ms):                   254.46
P90 TPOT (ms):                      278.01
P99 TPOT (ms):                      282.53

三、Warmup 验证

目标：找到最小成本的预热方式，消除冷启动后首次压测的性能劣化（~13% 吞吐差距）

3.1 方案一：短请求 curl（❌ 无效）

for i in {1..10}; do
  curl -s http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model":"/root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct","messages":[{"role":"user","content":"hello"}],"max_tokens":10,"temperature":0}' \
    > /dev/null && echo "✅ $i/10"
done

结果：预热后第一次压测的吞吐仍明显低于第二次。

原因分析：短请求（max_tokens=10）不会触发和正式压测相同规模的 KV cache 分配和 scheduler 调度路径，预热不充分。

3.2 方案二：长文本 curl（❌ 仍不足）

for i in $(seq 1 10); do
  echo "=== Warmup $i/10 ==="
  curl -s http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
      "model": "/root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct",
      "messages": [{"role": "user", "content": "请详细解释机器学习中的注意力机制是如何工作的，包括自注意力和多头注意力的原理。"}],
      "max_tokens": 128,
      "temperature": 0
    }' > /dev/null
  echo "   ✅ done"
done

结果：预热后两次压测仍有明显差距，第二次吞吐显著高于第一次。

原因分析：虽然输出长度匹配了（128 tokens），但 curl 是串行请求，无法模拟压测时的高并发调度压力。

3.3 方案三：低并发 vllm-bench（✅ 有效）

./vllm-bench --backend vllm --base-url http://127.0.0.1:8000 \
  --model /root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct \
  --dataset-name random \
  --random-input-len 1024 --random-output-len 128 \
  --num-prompts 50 --max-concurrency 10

结果：预热效果明显，第一次正式压测的吞吐接近第二次。

3.4 方案四：高并发 vllm-bench（✅✅ 更优）

./vllm-bench --backend vllm --base-url http://127.0.0.1:8000 \
  --model /root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct \
  --dataset-name random \
  --random-input-len 1024 --random-output-len 128 \
  --num-prompts 50 --max-concurrency 50

结果：预热后第一次正式压测的吞吐几乎等同于第二次，冷热差距基本消除。

3.5 Warmup 小结

关键结论：

• 并发是 warmup 的关键变量，串行请求即使输出长度匹配也无法预热 scheduler
• 输出长度要匹配线上口径，太短不会触发足够的 decode 路径
• 推荐 warmup 策略：用与线上相同的 input/output 长度 + 中等并发（正式并发的 25%50%），跑 50100 个 prompt 即可

四、单卡计算受限实验（TP=1 阶梯并发）

背景：冷热对比发现 TP=2 场景下瓶颈在 CPU 调度侧，但缺少数据证明 tensor core 是否真正饱和（GeForce 卡不支持 DCGM PROF 指标，无法区分 compute-bound 与 memory-bound）。

目标：改用单卡（TP=1），通过逐步提高并发度，找到 GPU 从 memory-bound → compute-bound 的拐点。

4.1 实验设计

思路：decode 阶段在低并发下是 GEMV（矩阵×向量），天然 memory-bound。提高并发后 continuous batching 将多个 decode 请求合并成 GEMM，batch size 越大，tensor core 越饱和。

方法：单卡启动服务，用 vllm-bench 阶梯式提高并发，记录每轮的关键指标。

# 服务端（TP=1）
vllm serve /root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct --tensor-parallel-size 1

# 阶梯压测脚本
for conc in 8 16 32 64 128 200; do
  if [ $conc -le 32 ]; then N=300; else N=500; fi

  echo "======================================"
  echo "  并发度 = $conc  (num-prompts=$N)"
  echo "======================================"
  nvidia-smi --query-gpu=power.draw,temperature.gpu,\
    utilization.gpu,utilization.memory --format=csv -l 1 \
    > /tmp/gpu_monitor_conc${conc}.csv &
  MONITOR_PID=$!

  ./vllm-bench --backend vllm --base-url http://127.0.0.1:8000 \
    --model /root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct \
    --dataset-name random \
    --random-input-len 1024 --random-output-len 128 \
    --num-prompts $N --max-concurrency $conc

  kill $MONITOR_PID 2>/dev/null
done

4.2 采集指标

4.3 实验结果

TP=1, Qwen2.5-7B-Instruct, input=1024, output=128（2026-07-02 实测）

整体指标

Steady-State 指标

GPU 监控（nvidia-smi 实测）

4.4 结果分析

TPOT 随并发增长趋势

关键观察：

• conc=8 时 TPOT 几乎无变化（25→26ms），TPOT 增量几乎为零
• conc=16 开始 TPOT 明显抬头（26→36ms，+38%），batch 开始积累
• conc=32 时 TPOT 翻倍（26→52ms），continuous batching 形成有效 GEMM
• conc=64 时 TPOT 加速增长（52→90ms，+73%），TPOT 增量 65ms（含合法计算增长 + 调度开销）
• conc=128 时 TPOT 继续恶化（90→163ms，+81%），TPOT 增量 138ms
• conc=200 时已过饱和（163→263ms，+61%），吞吐反而下降

吞吐拐点分析

吞吐在 conc=128 达到峰值，conc=200 反而下降 9%，说明系统已过饱和。排队延迟 > 新增并发带来的收益。

状态判定

4.5 结论：最佳性价比拐点 = conc=64

GPU 功耗与 Mem-Util 证据链

关键判据：

1. ✅ Mem-Util 从 100% 降至 46% — 显存带宽不再是瓶颈
2. ✅ GPU 功耗 ≥ 300W（94% TDP） — conc≥64 时功耗持续 298W+
3. ✅ GPU-Util 始终 ~99% — GPU 持续有 kernel 在执行
4. ✅ TPOT 在 conc≥32 后近似线性增长 — 并发翻倍，TPOT 也翻倍

结论：单卡 RTX 4080 在 conc=64 时达到最佳性价比拐点。此时 GPU 功耗 298W（93% TDP）、Mem-Util 降至 46%，硬件接近饱和。但算术强度 OI=55 仍低于 Ridge Point（135），纯 Roofline 意义上仍处于带宽区——硬件虽接近饱和，但 scheduler 开销已占主导，继续提高并发的边际收益急剧递减。

4.6 Roofline Model 分析

理论天花板

OI 定量计算（以 Qwen2.5-7B 为例）：

• 权重读取：~14 GB（每步固定，跨 batch 共享）
• KV cache 读取：2 × B × seq_len × d_model × (n_kv_heads / n_heads) × 2 bytes，随并发 B 增长
• FLOPs：2BN（Attention）+ 6B·d_model·ffn_dim（SwiGLU FFN），随 B 线性增长
• OI = FLOPs / (weight_bytes + kv_bytes)，由于 KV cache 读取随 B 增加，OI 略低于并发度（低约 15~19%）

各并发度在 Roofline 上的位置

注：「天花板达成率」的计算方式取决于 OI 所处的区域：

• OI < Ridge（带宽区）：实测 TFLOPS / (OI × 显存带宽)，表示离带宽天花板的距离。例如 conc=64 达成率 22%（带宽天花板 39.4 TFLOPS）。
• OI > Ridge（计算区）：实测 TFLOPS / 算力峰值，表示离算力天花板的距离。例如 conc=200 达成率 11%（算力天花板 97 TFLOPS）。

它与 nvidia-smi 的 Mem-Util 是两回事（后者是显存控制器繁忙程度），例如 conc=64 达成率 22%，但 Mem-Util 为 46%。

关键发现

1. conc=1 贴着带宽天花板跑（78%） → 符合预期，GEMV 天然 memory-bound，OI=1 远低于 Ridge Point（135）
2. conc≥16 后逐渐偏离带宽天花板 → continuous batching 开始形成 GEMM，OI 增长但达成率下降
3. conc≥64 后 OI 仍低于 Ridge Point（55 < 135） → 理论上仍处于 Roofline 的带宽区，但并非 memory-bound，因为天花板达成率仅 22%，远未触及带宽天花板。scheduler 开销是主要原因
   • OI=55 时带宽天花板：0.717 × 55 = 39.4 TFLOPS
   • 实测：9.93 TFLOPS，仅达到带宽天花板的 25%
4. conc=200 首次越过 Ridge Point（OI=168 > 135） → 进入计算区，天花板达成率切换为算力天花板（97 TFLOPS），实测仅达到 11%，说明 scheduler 问题同样锁死了算力利用率，且吞吐下滑

带宽天花板 (conc=1):    ████████████████████████░░░ 78%  (OI=1, 纯 GEMV)
非 GPU 时间 (conc=64):   ██████░░░░░░░░░░░░░░░░ 25%  (OI=55, scheduler-bound)
非 GPU 时间 (conc=200):  ███░░░░░░░░░░░░░░░░░░░ 11%  (OI=168, 过饱和)

TP=1 最优并发度推荐

4.7 Nsight 实时监控命令

# 方案 B：先启动服务，然后 attach profile
vllm serve /root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct --tensor-parallel-size 1 &

# 找到 PID，attach profiling 30s
nsys profile -t cuda,nvtx,osrt -o decode_profile --duration 30 -p $(pgrep -f "vllm serve")

五、双卡计算受限实验（TP=2 阶梯并发）

用 TP=2 复现 TP=1 的阶梯并发实验，对比 TP Scaling Efficiency 与调度开销差异。

5.1 实验设计

# 服务启动
vllm serve /root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct --tensor-parallel-size 2

# 阶梯压测
for conc in 1 64 128 200; do
  if [ $conc -le 32 ]; then N=300; else N=500; fi

  nvidia-smi --query-gpu=power.draw,temperature.gpu,\
    utilization.gpu,utilization.memory --format=csv -l 1 \
    > /tmp/gpu_monitor_tp2_conc${conc}.csv &
  MONITOR_PID=$!

  ./vllm-bench --backend vllm --base-url http://127.0.0.1:8000 \
    --model /root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct \
    --dataset-name random \
    --random-input-len 1024 --random-output-len 128 \
    --num-prompts $N --max-concurrency $conc

  kill $MONITOR_PID 2>/dev/null
done

5.2 整体性能

注：conc=64/128/200 为同一轮连续压测（conc 递增，服务持续运行），conc=1 为单独一轮。conc=200 本次实测数据与第二章 conc=200 存在差异（本次 500 样本、20.66s，第二章 1000 样本、162.91s），推测因第二章数据为独立测试而本次为阶梯序列末轮，scheduler 已充分预热。

Steady-State 指标

性能分析

TPOT 异常下降（conc=128 反而比 conc=64 低）：

conc=128 的 TPOT 比 conc=64 更低，说明 TP=2 场景下 scheduler 需要更高的并发才能进入高效 batch 模式。这与 TP=1 的行为完全不同（TP=1 中 TPOT 随并发单调递增）。

吞吐增长趋势：

吞吐在 conc=128 达到接近峰值（2964 tok/s），conc=200 仅增长 4.5%，已近饱和。

5.3 GPU 监控数据（nvidia-smi）

nvidia-smi 采样间隔 1s，过滤空闲期（GPU-Util=0%），双卡单独统计。

与 TP=1 的 Mem-Util 对比

关键观察：TP=2 的 Mem-Util 在 conc=64 降至 46%（与 TP=1 一致），但 conc=128 反而回升至 71%，与 TP=1 持续下降的趋势相反。这解释了 conc=128 TPOT 比 conc=64 更低的异常现象。

功耗分析

TP=2 单卡功耗远低于 TP=1（205226W vs 250306W），每卡只处理 3.5B 参数，算力远未饱和。两张卡合计功耗 410~451W，而 TDP 合计 640W，利用率仅 64%~70%。

5.4 TP=1 vs TP=2 对比

5.5 图表分析

5.6 关键发现

1. TP=2 吞吐远超 TP=1：峰值 3097 tok/s vs 660 tok/s（+369%），但这是两张卡合计
2. TPOT 异常下降（conc=128 < conc=64）：与 TP=1 单调递增完全不同，TP=2 需要更高并发才能进入高效 batch 模式
3. conc=128 是 TP=2 的最佳性价比点：吞吐 2964 tok/s（峰值的 96%），TPOT 仅 35.66ms（最低点）
4. TPOT 增量占比反而降低：conc=200 的 TPOT 增量占比约 77%，低于 TP=1 的 90.5%（注意：该增量包含 batch 增大带来的合法计算增长，不全是调度开销）

5.7 原始日志

================= Serving Benchmark Result =================
Successful requests:                     300      
Failed requests:                         0         
Maximum request concurrency:             1         
Benchmark duration (s):                  478.66    
Total input tokens:                      306592    
Total generated tokens:                  38400     
Request throughput (req/s):              0.63      
Output token throughput (tok/s):         80.22     
Peak output token throughput (tok/s):    83.00     
Peak concurrent requests:                2.00      
Total token throughput (tok/s):          720.74    
--------------------Time to First Token---------------------
Mean TTFT (ms):                          62.17     
Median TTFT (ms):                        44.10     
P99 TTFT (ms):                           160.71    
P90 TTFT (ms):                           155.20    
----------Time per Output Token (excl. 1st token)-----------
Mean TPOT (ms):                          12.07     
Median TPOT (ms):                        12.07     
P99 TPOT (ms):                           12.11     
P90 TPOT (ms):                           12.09     
--------------------Inter-token Latency---------------------
Mean ITL (ms):                           12.07     
Median ITL (ms):                         12.08     
P99 ITL (ms):                            12.70     
P90 ITL (ms):                            12.36     
---------------------End-to-end Latency---------------------
Mean E2EL (ms):                          1595.33   
Median E2EL (ms):                        1576.75   
P99 E2EL (ms):                           1696.40   
P90 E2EL (ms):                           1689.94   
============================================================
============ Steady-State Metrics =============
Concurrency threshold:              >= 0.95 * 1 = 1
Window:                             0.0s -> 478.7s  (478.7s)
Observed peak concurrency:          1
Requests started in window:         300 / 300 (100.0%)
Requests completed in window:       299
-----------------------------------------------
Request throughput (req/s):         0.62
Output token throughput (tok/s):    80.22
Input token throughput (tok/s):     640.52
Total token throughput (tok/s):     720.74
-----------------------------------------------
Mean TTFT (ms):                     62.17
Median TTFT (ms):                   44.10
P99 TTFT (ms):                      160.71
P90 TTFT (ms):                      155.20
-----------------------------------------------
Mean TPOT (ms):                     12.07
Median TPOT (ms):                   12.07
P90 TPOT (ms):                      12.09
P99 TPOT (ms):                      12.11

================= Serving Benchmark Result =================
Successful requests:                     500      
Failed requests:                         0         
Maximum request concurrency:             64        
Benchmark duration (s):                  50.81     
Total input tokens:                      511016    
Total generated tokens:                  64000     
Request throughput (req/s):              9.84      
Output token throughput (tok/s):         1259.48   
Peak output token throughput (tok/s):    2752.00   
Peak concurrent requests:                127.00    
Total token throughput (tok/s):          11315.95  
--------------------Time to First Token---------------------
Mean TTFT (ms):                          782.36    
Median TTFT (ms):                        392.59    
P99 TTFT (ms):                           3219.09   
P90 TTFT (ms):                           1879.11   
----------Time per Output Token (excl. 1st token)-----------
Mean TPOT (ms):                          44.28     
Median TPOT (ms):                        24.39     
P99 TPOT (ms):                           83.53     
P90 TPOT (ms):                           77.89     
--------------------Inter-token Latency---------------------
Mean ITL (ms):                           44.28     
Median ITL (ms):                         23.69     
P99 ITL (ms):                            270.11    
P90 ITL (ms):                            55.51     
---------------------End-to-end Latency---------------------
Mean E2EL (ms):                          6406.35   
Median E2EL (ms):                        3588.75   
P99 E2EL (ms):                           12414.67  
P90 E2EL (ms):                           11486.00  
============================================================
============ Steady-State Metrics =============
Concurrency threshold:              >= 0.95 * 64 = 61
Window:                             0.0s -> 47.6s  (47.6s)
Observed peak concurrency:          64
Requests started in window:         440 / 500 (88.0%)
Requests completed in window:       439
-----------------------------------------------
Request throughput (req/s):         9.22
Output token throughput (tok/s):    1219.27
Input token throughput (tok/s):     9449.77
Total token throughput (tok/s):     10669.04
-----------------------------------------------
Mean TTFT (ms):                     830.52
Median TTFT (ms):                   392.43
P99 TTFT (ms):                      3219.63
P90 TTFT (ms):                      2102.67
-----------------------------------------------
Mean TPOT (ms):                     47.08
Median TPOT (ms):                   43.22
P90 TPOT (ms):                      77.93
P99 TPOT (ms):                      83.60

================= Serving Benchmark Result =================
Successful requests:                     500      
Failed requests:                         0         
Maximum request concurrency:             128       
Benchmark duration (s):                  21.59     
Total input tokens:                      511016    
Total generated tokens:                  64000     
Request throughput (req/s):              23.15     
Output token throughput (tok/s):         2963.84   
Peak output token throughput (tok/s):    3712.00   
Peak concurrent requests:                247.00    
Total token throughput (tok/s):          26628.96  
--------------------Time to First Token---------------------
Mean TTFT (ms):                          524.91    
Median TTFT (ms):                        468.75    
P99 TTFT (ms):                           1131.63   
P90 TTFT (ms):                           903.48    
----------Time per Output Token (excl. 1st token)-----------
Mean TPOT (ms):                          35.66     
Median TPOT (ms):                        36.20     
P99 TPOT (ms):                           37.21     
P90 TPOT (ms):                           36.93     
--------------------Inter-token Latency---------------------
Mean ITL (ms):                           35.66     
Median ITL (ms):                         34.41     
P99 ITL (ms):                            98.15     
P90 ITL (ms):                            39.61     
---------------------End-to-end Latency---------------------
Mean E2EL (ms):                          5053.58   
Median E2EL (ms):                        5058.74   
P99 E2EL (ms):                           5706.48   
P90 E2EL (ms):                           5519.99   
============================================================
============ Steady-State Metrics =============
Concurrency threshold:              >= 0.95 * 128 = 122
Window:                             0.0s -> 15.9s  (15.9s)
Observed peak concurrency:          128
Requests started in window:         379 / 500 (75.8%)
Requests completed in window:       378
-----------------------------------------------
Request throughput (req/s):         23.80
Output token throughput (tok/s):    3131.35
Input token throughput (tok/s):     24395.32
Total token throughput (tok/s):     27526.67
-----------------------------------------------
Mean TTFT (ms):                     454.58
Median TTFT (ms):                   449.21
P99 TTFT (ms):                      1129.99
P90 TTFT (ms):                      547.26
-----------------------------------------------
Mean TPOT (ms):                     35.53
Median TPOT (ms):                   36.47
P90 TPOT (ms):                      36.98
P99 TPOT (ms):                      37.31

================= Serving Benchmark Result =================
Successful requests:                     500      
Failed requests:                         0         
Maximum request concurrency:             200       
Benchmark duration (s):                  20.66     
Total input tokens:                      511016    
Total generated tokens:                  64000     
Request throughput (req/s):              24.20     
Output token throughput (tok/s):         3097.15   
Peak output token throughput (tok/s):    3800.00   
Peak concurrent requests:                299.00    
Total token throughput (tok/s):          27826.71  
--------------------Time to First Token---------------------
Mean TTFT (ms):                          776.69    
Median TTFT (ms):                        625.87    
P99 TTFT (ms):                           1731.52   
P90 TTFT (ms):                           1495.49   
----------Time per Output Token (excl. 1st token)-----------
Mean TPOT (ms):                          52.70     
Median TPOT (ms):                        57.56     
P99 TPOT (ms):                           59.60     
P90 TPOT (ms):                           58.86     
--------------------Inter-token Latency---------------------
Mean ITL (ms):                           52.70     
Median ITL (ms):                         52.13     
P99 ITL (ms):                            154.89    
P90 ITL (ms):                            62.60     
---------------------End-to-end Latency---------------------
Mean E2EL (ms):                          7469.61   
Median E2EL (ms):                        8025.32   
P99 E2EL (ms):                           8968.65   
P90 E2EL (ms):                           8877.64   
============================================================
============ Steady-State Metrics =============
Concurrency threshold:              >= 0.95 * 200 = 190
Window:                             0.0s -> 16.6s  (16.5s)
Observed peak concurrency:          200
Requests started in window:         311 / 500 (62.2%)
Requests completed in window:       310
-----------------------------------------------
Request throughput (req/s):         18.75
Output token throughput (tok/s):    3102.84
Input token throughput (tok/s):     19228.31
Total token throughput (tok/s):     22331.15
-----------------------------------------------
Mean TTFT (ms):                     605.99
Median TTFT (ms):                   571.66
P99 TTFT (ms):                      1731.22
P90 TTFT (ms):                      769.80
-----------------------------------------------
Mean TPOT (ms):                     50.22
Median TPOT (ms):                   57.64
P90 TPOT (ms):                      58.86
P99 TPOT (ms):                      59.60

六、调度瓶颈深度分析

6.1 Nsight Systems Profiling

使用 Nsight Systems 对 TP=1、conc=64 场景进行 GPU timeline 采集，精确定位 decode step 中的时间分布。

采集方法

# 方案 B（attach 模式）
vllm serve /root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct --tensor-parallel-size 1 &
nsys profile -t cuda,nvtx,osrt -o decode_profile --duration 30 -p $(pgrep -f "vllm serve")

# 另一终端发起压测
./vllm-bench --backend vllm --base-url http://127.0.0.1:8000 \
  --model /root/autodl-tmp/models/Qwen/Qwen2.5-7B-Instruct \
  --dataset-name random \
  --random-input-len 1024 --random-output-len 128 \
  --num-prompts 200 --max-concurrency 64

Timeline 整体视图（200ms 窗口）

截图对应约 200ms 时间窗口，完整覆盖约两个 decode step 周期。

CUDA Stream 与 Kernel 分布

Stream 分工

GPU 时间分布（所有 Stream 合计）

识别的主要 Kernel

注：CUTLASS kernel 的模板参数 bf16_256x128_32x3 表示 tile size 256×128，stages=3，这是针对 RTX 4080 (sm_86) 优化过的配置。

生成时间分布图

截图显示约 200ms 窗口内 GPU 活动与 CPU 同步事件的对应关系。

分析结论

解码后的执行模式

约 90~100ms（一个完整 decode step 周期）
┌──────────────────────────────────────────┐
│ GPU kernel 序列（连续执行）                │
│ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐          │
│ │ K │ │ K │ │ K │ │ K │ │ K │  ...      │
│ └───┘ └───┘ └───┘ └───┘ └───┘          │
│                                          │
│ ▼ cudaEventSynchronize（CPU 等 GPU）     │ ← 🟩 绿色条
│                                          │
│ 调度间隔（~10-20ms）                      │
│   ├─ epoll_wait（I/O 等待）               │
│   └─ sem_wait（线程同步）                 │
│                                          │
│ 下一轮 decode kernel 序列开始              │
└──────────────────────────────────────────┘

核心发现

发现一：CPU-GPU 同步开销

cudaEventSynchronize 的存在表明 vLLM 的异步调度中存在残留的 CPU-GPU 同步点。vLLM V1 默认启用了异步调度（async_scheduling=True），允许 CPU 准备第 N+1 步时 GPU 执行第 N 步。但实际 Nsight 数据中仍可见 cudaEventSynchronize 阻塞，说明异步重叠不彻底：

• GPU 执行当前 batch 的 kernel
• CPU 在 cudaEventSynchronize 处等待 GPU 完成部分操作（如准备下一批输入数据）
• 此后 CPU 执行调度逻辑（epoll_wait + sem_wait）
• GPU 开始下一批 kernel

vLLM 官方也承认 V1 的异步支持是 “retrofitted behavior and hacks”，MRV2（新一代 Model Runner）才真正以异步流水线为原生设计。

发现二：混合执行方式（CUDA Graph + 传统 Launch）

GPU 执行时间中：

• 23.0% 来自 CUDA Graph（预编译的 kernel 序列）
• 70.9% 来自传统单个 kernel launch

vLLM 已在使用 CUDA Graph 优化 attention 等固定路径，但大部分 GEMM 和 element-wise 操作仍以传统方式 launch。

发现三：算子组成

可能的开销来源

与实验结果交叉验证

6.2 Grafana 监控截图

TP=2 conc=200 压测过程中的实时监控数据：

七、总结与下一步

7.1 TP=1 vs TP=2 瓶颈性质对比

TP=1 经过足够并发可以压满单卡算力。TP=2 则永远无法压满 GPU——每卡只处理 3.5B 参数，scheduler 开销增长始终快于 batch 合并带来的算力收益。

7.2 根本原因

从 Nsight Systems profiling 确认，vLLM V1 的异步调度中存在残留的 CPU-GPU 同步点（cudaEventSynchronize）。虽然 vLLM 默认启用异步调度让 CPU 和 GPU 部分重叠，但实际执行中仍有明显的同步等待：

提交 kernel → cudaEventSynchronize（CPU 等 GPU 完成部分操作）→ CPU 调度 → 提交下一批
                                                              ↑
                                                      GPU 空闲，等 CPU

这导致 CPU 和 GPU 无法完全流水线化，是当前系统性能瓶颈的根本原因。官方也在新一代 Model Runner（MRV2）中将异步流水线作为原生设计来彻底解决此问题。

7.3 优化方向评估

7.4 最终结论

当前系统的性能天花板来自 GPU 利用率不足，根因是 vLLM V1 异步调度中的残留同步开销，而非 GPU 硬件瓶颈。

TP=2 虽然能将吞吐推到 TP=1 的 4.7×，但这只是双卡硬件翻倍的物理红利。每张 GPU 的实际利用率仅 64%~71%，算力远未饱和。在不改变推理框架的前提下，通过调参最多只能获得 5%~10% 的边际提升。要突破这个天花板，需要更彻底的异步流水线架构（SGLang / TensorRT-LLM 或 vLLM 新一代 MRV2）从执行模型层面解决 CPU-GPU 串行化问题。

7.5 待办事项清单

• Warmup 验证：并发是关键，推荐 vllm-bench --num-prompts 50 --max-concurrency 50（见第三章）
• DCGM 监控完善：GeForce 卡不支持 PROF 指标
• 低并发对比：并发=1 下 TPOT=25ms（见第一章）
• Nsight Systems profiling：发现 cudaEventSynchronize 残留同步开销，CPU 与 GPU 无法完全流水线化（见第六章）
• 单卡计算受限实验：TP=1 阶梯并发，找到最佳性价比拐点 conc=64，Roofline 验证 GPU 硬件不是瓶颈（见第四章）
• 双卡计算受限实验：TP=2 阶梯并发，发现 TPOT 异常下降和 Mem-Util V 型走势（见第五章）