# 双卡 RTX 2080 Ti + vLLM 跑 Qwen3.8-27B-FP8 实测分享

[rock shi]

备注：搞了两张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 模型，关键在于：

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 费用，性价比拉满。

[rock shi]

[rock shi]

话外：这台副电脑，因deepseek涨价购置，整机价格约6500左右。

24/7开机，显卡限制功耗170w（甜点功耗：声音小+损失很低），算上外包的上下文压缩和维护，平均每天2.5元左右。按照现在依然用deepseek的话平均得一天30块钱。综合算8个月回本。

副电脑配置刚刚好跑fp8 kv16 128k上下文，用了三五天感觉质量非常高。网上说的工具调用出错的情况确实有、但是很少很少，昨天顺便让它自己修复了一下，即便调用空了会返回来继续。

[rock shi]

长代码任务、复杂任务依然不推荐纯本地算力当做主力，不是qwen3.8做不了，是效率低，基本上卡知识储备和上下文这两点，迂回几下大概率也能回来。

这套副电脑适合喜欢折腾的，把AI当做玩具而不是生产力工具的。他只能跑llm，并且恰恰好，视频模型跑不了，所以说性价比需要个人衡量。

[stxpnet]

温度0.1？ 那96K上下文时的速度还有多少呢？

[franklee006]

我也在用, 不過我用的是 AWQ Q4 再加 FP16 KV 有 256k 已經用了2星期左右. 現在再買多一台

[rock shi]

@stxpnet 40-60tok/s

[terry]

@franklee006 愿闻其详，分享下。

[rock shi]

@stxpnet 温度0.1的话工具调用比较稳，有利有弊吧(8月22日)

23日感觉0.1不太对劲，调回了1.0，感觉能力又提升了一大截。0.1实测确实太低了，非常影响长任务。(8月24日)

[lysen963]

看到楼主限制功率170W，请问是三风扇还是涡轮卡？因为我想买个准系统，如果限制了功率，是不是1300W就能启动四卡。

[rock shi]

@lysen963 是涡轮卡。主要是满功率太吵了，再就是怕温度太高这种魔改卡也受不了

[lysen963]

@rock-shi 是的，我想办公使用，所以也害怕声音太大，吵到别人。