备注：搞了两张2080 22g，遇到了很多坑，回头如果你也玩双2080可以把这个帖子丢给你的hermes，减少踩坑。目前是能正常跑起来了，再优化就要等官方的qwen3.8 27b的int4版本了。
以下是AI总结：
硬件
| 项目 | 配置 |
|---|---|
| GPU | 2× NVIDIA RTX 2080 Ti 22GB（Consumer，Turing SM75） |
| NVLink | 有桥，2 link，每 link 25.78 GB/s，实测 P2P copy 40 GB/s、NCCL all_reduce 72.6 GB/s |
| CPU | Intel i5-7500（4C4T，老古董，但推理瓶颈在 GPU） |
| 内存 | 32GB DDR4 |
| 系统 | Ubuntu 24.04 LTS，内核 7.0.0 |
| 驱动 | 595.84，CUDA 13.2 |
软件栈
| 项目 | 版本 |
|---|---|
| vLLM | vLLM 2080 Ti Definitive Edition v0.1.15（社区 fork，基于 vLLM 0.21.0，作者 github.com/weicj |
| 运行时 | CUDA 12.8 / PyTorch 2.11.0+cu128 |
| 模型 | Qwen3.8-27B-FP8（W8A16，FP8 权重，FP16 KV cache） |
| 量化 | FP8（SM75 原生不支持 FP8，该 fork 通过 kernel 适配实现） |
为什么用这个 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}'
关键参数说明
| 参数 | 值 | 说明 |
|---|---|---|
--tensor-parallel-size |
2 | 双卡 TP，权重平分到两张卡 |
--speculative-config |
MTP, 3 tokens | Qwen3.8 的 Multi-Token Prediction 投机解码，是提速的核心 |
--max-model-len |
131072 | 128K 上下文 |
--gpu-memory-utilization |
0.92 | 预分配显存比例，留了 8% 给 CUDA overhead |
--max-num-seqs |
1 | 单并发（显卡 VRAM 有限，只能同时跑一条请求） |
--max-num-batched-tokens |
2048 | 单步最大 token 数，MTP3 推荐值 |
--cudagraph_mode |
PIECEWISE | 分段 CUDA Graph，MTP 投机解码必须用 PIECEWISE 不能用 FULL |
--enable-prefix-caching |
true | 开启前缀缓存，相同系统提示词不重复计算 |
显存分布
| 组成 | 每卡占用 |
|---|---|
| 模型权重（FP8, TP=2） | ~13.5 GB |
| CUDA Graph + 激活值 | ~3 GB |
| KV Cache（FP16） | ~5.12 GB |
| 合计 | ~21.6 / 22.5 GB |
KV cache 总容量：144,252 tokens。单条 128K 请求占 91%，并发上限 1.10x——放得下一条完整的 128K 请求，但没有余量给第二条。
性能实测
数据来源：vLLM 日志 Avg generation throughput（10 秒窗口平均），2026-08-19 实测。
| 上下文长度 | decode 吞吐 | 备注 |
|---|---|---|
| 短上下文（<1K） | 75–81 tok/s | 首次回复，无前缀缓存 |
| 16K | 34–38 tok/s | 长上下文降速，但仍可用 |
| 40K（真实对话） | 55–75 tok/s | 前缀缓存命中 83%，有缓存加持速度回升 |
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 的三种死法
| 模式 | 结果 |
|---|---|
| FULL cudagraph | 输出退化（反复 !!!!） |
| PIECEWISE cudagraph | 长上下文崩溃 |
| eager mode（不开 cudagraph） | 能用但极慢，不实际 |
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 阶段的值。
和其他方案的对比（个人体感）
| 方案 | 速度 | 备注 |
|---|---|---|
| DeepSeek V4-Flash (API) | ~146 tok/s | 云端大集群，但 8/17 涨价 |
| MiMo V2.5 (API) | ~80-100 tok/s | 便宜（¥1/¥2），但功能受限 |
| 本方案（vLLM + 2080 Ti） | 35–81 tok/s | 免费、本地、零延迟、128K 上下文 |
小结
双卡 2080 Ti 跑 27B FP8 模型，关键在于：
- 用社区 fork（官方 vLLM 不支持 Turing FP8）
- 必须开 MTP + PIECEWISE cudagraph（Qwen3.8 GDN 架构的硬性要求）
- 用 FP16 KV（INT8 KV + MTP3 在 Turing 上有 bug）
- 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 费用，性价比拉满。
长上下文 / 长 prompt 场景：优先采用方案 F，prefill 速度提升极大改善首 token 延迟
