4080S 32G + qwen3.6-27B + vllm 参数及踩坑

Che

前几天看论坛帖子才意识到 vllm 吞吐量远大于 llama.cpp，于是转战 vllm。趁 qwen3.8-27B 还没发布，记录一下配置 vllm 踩过的坑。

配置：4080S 32G + Ubuntu 24 + qwen3.6-27B + vllm 0.26 + lmcache 0.5.3
模型。官方 safetensors 自带 MTP 权重；而 llama.cpp GGUF 经过转换，惯例是在模型名中标明 MTP。所以并不需要刻意去找 MTP 模型（我一开始是这么做的），挑热门那几个即可。
- AWQ，autoround，GPTQ 均可。不要 INT8
vllm 概述。vllm 与 llama.cpp 相比，优势在于（在一定范围内）多并发时每个会话 decode 速率不会下降（即便话题不同），这就相当于大幅提升了 decode 速率；而最终受到的制约仍是 KVCache 大小，也就是由显存决定。所有会话共享 KVCache 池子，那么高并发时，摊到每个会话的上下文就很小了。
vllm 运行参数
- --kv-cache-dtype （相当于 llama-server -ctk、-ctv）
  - qwen3.6-27B 目前选 fp8，turboquant_4bit_nc 在 vllm 0.26 有 bug，需要等主线更新或使用旧版（0.24）（我还没试过 tq）
  - fp8_e4m3 可能比 fp8_e5m2 略好
  - 关于 turboquant，官方有篇文章详细介绍：TurboQuant 首个全面研究：准确性与性能 | vLLM 博客 - vLLM 推理引擎
- --kv-cache-memory-bytes 指定 KVCache 池子大小
  - 这是比 --gpu-memory-utilization 更好的参数，不容易OOM，不管 --max-model-len 和 --max-num-seqs 怎么设，它都不受影响。
  - 可以先定个保守数值，比如 9G，稳定了再往上增，OOM 就降。
  - fp8 10G 时，GPU KV cache size 略大于 qwen3.5 原生的 262K
- --max-num-seqs 简单理解为最大并发，超过该值的进入排队（相当于 llama-server -np）
  - 在一定范围内增加并发，可以有效提高吞吐量
  - 在 32 时观察到 700 tps（MTP=2），大概是峰值了
- --max-model-len 单会话最大上下文长度（相当于 llama-server --ctx-size）
  - 虽然 --kv-cache-memory-bytes 定了 KVCache 总量，但 --max-num-seqs 和 --max-model-len 仍会影响调度，并不是越大越好，按需设置。
- --language-model-only 完全关闭视觉以降低显存占用（大概有 1G 多）。按需
- --speculative-config MTP 受实际任务影响，接受率波动非常大。按需调整。我设了2
  - 注意，MTP 还会影响其它参数的设置
- --compilation-config '{"cudagraph_capture_sizes":[]}'
  - 默认值略长，可以按 --max-num-seqs x (num_speculative_tokens+1) 设置。
    
    比如 8 并发 MTP 2，那么设为 [1,2,4,8,16,24]
- --max-num-batched-tokens 更大 prefill 更快，但也会占用更多显存（我感觉不明显）
  - 相当于 llama-server -cb
  - 同时开 MTP 和 lmcache 需要注意该值：
    1. 找到启动时的 Setting attention block size to，设该值为 N
    2. 将 --max-num-batched-tokens 设置为 2N-1
- --enable-prefix-caching qwen3.5系列必须加上才能开启前缀缓存
- --mamba-cache-mode align
  
  --kv-transfer-config '{"kv_connector":"LMCacheMPConnector","kv_role":"kv_both"}'
  
  开 lmcache 则需要这两条语句
lmcache 概述。
- lmcache 并不能增大 KVCache 池子，它的作用是把 KVCache 写入内存乃至硬盘，以增加前缀缓存命中率（相当于 llama-server --cache-idle-slots、--slot-save-path）
- 对 qwen3.5系列能够略微增加额外的前缀缓存命中率。对 KVCache 满时换出换入有帮助
- 它本身会占用一定的显存（我这是每个 vllm 900M），根据个人需求安装启用
lmcache 运行参数
- --chunk-size 设置为 N（见上）
- --separate-object-groups qwen3.5系列必需
- L2 写入硬盘在 lmcache 主线似乎还不能控制大小，按需或等更新
实战。接入 ClaudeCode
- prefill 和 decode 混合，速率是低于纯 decode 的
- 首轮输入会产生 1.5G 显存占用，要留空间
- 12 并发时接近 400 tps，然后 KVCache 满了排队。没有做太多测试
其它说明
- 以上的具体数值仅针对 4080S 32G
- 问 AI 是最佳实践
- 欢迎交流

terry

哥，这个是说明书吗？发点你的实际使用截图，参数数据，这些命令行参数不需要解释，AI会去搞定的。

Che

@terry

吞吐

无 MTP

并发       总时           平均延迟          吞吐
conc=  1  wall=  7.00s  avg_lat= 7.00s  agg=  36.6 tok/s
conc=  4  wall=  7.53s  avg_lat= 7.52s  agg= 136.0 tok/s
conc= 16  wall=  8.94s  avg_lat= 8.94s  agg= 457.9 tok/s
conc= 32  wall= 11.63s  avg_lat=11.62s  agg= 704.5 tok/s
conc= 64  wall= 23.91s  avg_lat=17.08s  agg= 685.4 tok/s
conc=128  wall= 41.63s  avg_lat=27.23s  agg= 787.1 tok/s

可以看到 32 就开始排队了，KVCache 装不下，接下来砍掉 64 和 128 挡位：

conc=  1  wall=  6.85s  avg_lat= 6.85s  agg=  37.4 tok/s
conc=  4  wall=  7.51s  avg_lat= 7.50s  agg= 136.3 tok/s
conc=  8  wall=  7.82s  avg_lat= 7.81s  agg= 262.0 tok/s
conc= 16  wall=  8.94s  avg_lat= 8.94s  agg= 458.0 tok/s
conc= 24  wall= 10.41s  avg_lat=10.40s  agg= 590.2 tok/s
conc= 32  wall= 11.63s  avg_lat=11.62s  agg= 704.5 tok/s

MTP=1

conc=  1  wall=  4.74s  avg_lat= 4.74s  agg=  54.0 tok/s
conc=  4  wall=  5.09s  avg_lat= 5.01s  agg= 201.1 tok/s
conc=  8  wall=  5.51s  avg_lat= 5.41s  agg= 371.8 tok/s
conc= 16  wall=  6.67s  avg_lat= 6.58s  agg= 613.7 tok/s
conc= 24  wall=  8.17s  avg_lat= 7.94s  agg= 752.5 tok/s
conc= 32  wall= 13.44s  avg_lat= 9.40s  agg= 609.6 tok/s

MTP=2

conc=  1  wall=  3.95s  avg_lat= 3.95s  agg=  64.9 tok/s
conc=  4  wall=  4.45s  avg_lat= 4.32s  agg= 230.2 tok/s
conc=  8  wall=  5.03s  avg_lat= 4.92s  agg= 406.9 tok/s
conc= 16  wall=  6.37s  avg_lat= 6.17s  agg= 642.9 tok/s
conc= 24  wall= 11.92s  avg_lat= 8.53s  agg= 515.3 tok/s
conc= 32  wall= 13.17s  avg_lat= 9.86s  agg= 621.8 tok/s

MTP=3

conc=  1  wall=  3.66s  avg_lat= 3.66s  agg=  70.0 tok/s
conc=  4  wall=  4.00s  avg_lat= 3.87s  agg= 255.7 tok/s
conc=  8  wall=  4.90s  avg_lat= 4.74s  agg= 418.1 tok/s
conc= 16  wall= 10.07s  avg_lat= 6.82s  agg= 406.6 tok/s
conc= 24  wall= 11.60s  avg_lat= 8.57s  agg= 529.6 tok/s
conc= 32  wall= 16.32s  avg_lat=10.36s  agg= 502.0 tok/s

可见高并发 MTP 收益下降

KVCache
- ```
  --kv-cache-memory-bytes 9G
```
  GPU KV cache size: 128,341 tokens
- ```
  --kv-cache-memory-bytes 10G
```
  GPU KV cache size: 141,994 tokens
- ```
  --kv-cache-memory-bytes 9G \
  --kv-cache-dtype fp8_e4m3
```
  GPU KV cache size: 220,013 tokens
- ```
  --kv-cache-memory-bytes 10G \
  --kv-cache-dtype fp8_e4m3
```
  GPU KV cache size: 243,419 tokens
- --kv-cache-memory-bytes 极限大概在 13G，但这意味着必须砍掉 MTP、lmcache 等功能
- 除了 --kv-cache-memory-bytes 和 --kv-cache-dtype，GPU KV cache size 实际值还受一些其它参数影响
视觉
- 关闭（--gpu-memory-utilization 0.8 仅作为测试）
```
  --language-model-only \
  --gpu-memory-utilization 0.8
```
  Free memory on device (31.08/31.47 GiB) on startup. Desired GPU memory utilization is (0.8, 25.17 GiB). Actual usage is 18.33 GiB for weight, 2.47 GiB for peak activation, 0.11 GiB for non-torch memory, and 0.51 GiB for CUDAGraph memory. Replace gpu_memory_utilization config with --kv-cache-memory=3863865754 (3.6 GiB) to fit into requested memory, or --kv-cache-memory=10206990336 (9.51 GiB) to fully utilize gpu memory. Current kv cache memory in use is 3.74 GiB.
- 开启
  
  Free memory on device (31.21/31.48 GiB) on startup. Desired GPU memory utilization is (0.8, 25.18 GiB). Actual usage is 19.2 GiB for weight, 1.89 GiB for peak activation, 0.11 GiB for non-torch memory, and 0.52 GiB for CUDAGraph memory. Replace gpu_memory_utilization config with --kv-cache-memory=3555439719 (3.31 GiB) to fit into requested memory, or --kv-cache-memory=10030697984 (9.34 GiB) to fully utilize gpu memory. Current kv cache memory in use is 3.46 GiB.
- 可见视觉权重约 0.9G
lmcache
- ClaudeCode 第二轮对话
  - 不开启
    
    Prefix cache hit rate: 44.5%
  - 开启
    
    Prefix cache hit rate: 45.1%, External prefix cache hit rate: 6.3%
- ClaudeCode 跨会话
  - 先发，首轮用时 15s
  - 后发，首轮用时 4s
    
    Prefix cache hit rate: 0.0%, External prefix cache hit rate: 77.1%
实战
- 使用 ClaudeCode workflow 并行处理不同话题。数量：
  - 8个：350 tps
  - 16个：400 tps，实际上最大并发只有 12，KVCache 就满了
暂时只测了这些