以下是AI总结：

硬件

软件栈

为什么用这个 fork

RTX 2080 Ti 是 Turing 架构（SM75），官方 vLLM 的 FP8 kernel 只支持 SM89+（Ada Lovelace）。vLLM-2080Ti-Definitive 是社区维护的 fork，专门适配了 Turing 的 FP8 量化推理，同时支持 MTP（Multi-Token Prediction）投机解码、GDN（Gated DeltaNet）混合架构等 Qwen3.8 的特性。

启动命令

python -m vllm.entrypoints.openai.api_server \
  --host 0.0.0.0 \
  --port 8000 \
  --model /path/to/models/Qwen3.8-27B-FP8 \
  --served-model-name qwen38-27b \
  --dtype half \
  --tensor-parallel-size 2 \
  --generation-config vllm \
  --max-model-len 131072 \
  --enable-chunked-prefill \
  --max-num-seqs 1 \
  --max-num-batched-tokens 2048 \
  --override-generation-config '{"temperature":0.1}' \
  --quantization fp8 \
  --gpu-memory-utilization 0.92 \
  --mamba-cache-mode align \
  --enable-prefix-caching \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_xml \
  --enable-auto-tool-choice \
  --additional-config '{"gdn_prefill_backend":"flashqla_legacy"}' \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3}' \
  --compilation-config '{"cudagraph_mode":"PIECEWISE","cudagraph_capture_sizes":[4],"max_cudagraph_capture_size":4}'

关键参数说明

显存分布

KV cache 总容量：144,252 tokens。单条 128K 请求占 91%，并发上限 1.10x——放得下一条完整的 128K 请求，但没有余量给第二条。

性能实测

数据来源：vLLM 日志 Avg generation throughput（10 秒窗口平均），2026-08-19 实测。

Prefill 吞吐（prompt 处理）：短 prompt 约 200–400 tok/s，长 prompt 有前缀缓存时可达 2000–3000 tok/s。

踩坑记录

1. MTP 是刚需，不能关

Qwen3.8-27B 是 GDN（Gated DeltaNet）混合架构，不开 MTP 推理会出问题：

• MTP_K=0（无投机解码）：输出退化（反复输出 !!!!、乱码），benchmark 看着正常但实际不可用
• FULL cudagraph（不开 PIECEWISE）：输出同样退化
• eager mode（不开 cudagraph）：能用但速度极慢

结论：这个模型在 Turing 双卡上必须开 MTP + PIECEWISE cudagraph，三者缺一不可。

2. INT8 KV + MTP3 长上下文崩溃

曾经试过 INT8 KV cache（压缩 KV cache 省显存），短上下文正常（~48 tok/s），但 16K 上下文直接崩到 12 tok/s——MTP 接受率从正常水平暴跌到接近 0。

结论：FP16 KV 是必须的，INT8 KV + MTP3 在 Turing 上有兼容性问题。

3. no-MTP 的三种死法

4. NVLink 的坑

nvidia-smi -q 输出里的 Bridge Chip: N/A 是 PCIe 桥字段，不代表没有 NVLink！验证 NVLink 是否正常要看：

nvidia-smi nvlink -s          # 看链路数
nvidia-smi nvlink -g          # 看带宽

或者跑 P2P bandwidth test（p2pBandwidthLatencyTest）看实际带宽。2080 Ti + NVLink bridge 实测 P2P copy 40 GB/s、NCCL all_reduce 72.6 GB/s，NCCL 自动走桥，零配置。

5. 首次请求 0 tok/s 是假象

vLLM 首次推理会触发 Triton JIT 编译（日志里会看到 torch.compile took Xs），第一次请求的延迟不代表真实性能。等 Triton 编译完成后（几十秒），后续请求才是正常速度。

6. 测速方法

• 日志 Avg throughput：10 秒窗口平均值，会混入 prefill 阶段（prompt 吞吐高、generation 吞吐低）和空闲期，偏低
• 墙钟时间：发一个固定长度 prompt，计时从请求发出到收到完整回复，最准
• 增量法（数 token / 时间差）：会被前缀缓存污染，虚高到 200+ tok/s，不靠谱

推荐：用 vLLM 的 /metrics Prometheus 端点或日志里的 Avg generation throughput，取纯 decode 阶段的值。

和其他方案的对比（个人体感）

小结

双卡 2080 Ti 跑 27B FP8 模型，关键在于：

1. 用社区 fork（官方 vLLM 不支持 Turing FP8）
2. 必须开 MTP + PIECEWISE cudagraph（Qwen3.8 GDN 架构的硬性要求）
3. 用 FP16 KV（INT8 KV + MTP3 在 Turing 上有 bug）
4. max-num-seqs=1（显存只够单并发，但这对个人/agent 用途完全够用）

128K 上下文能跑，但 KV cache 余量薄（91%）。实际使用中 20-60K 上下文是常态，速度 35-75 tok/s，足够日常对话和 agent 任务。

硬件成本约 ¥4300（二手 2080 Ti × 2 + NVLink bridge），日均电费约 ¥1.5-2（175W 限制功耗），零 API 费用，性价比拉满。