让你们看看垃圾魔改卡2080ti 的威力 qwen3.6-27b fp8 精度速度能到 60tokens/s nvlink 连接

yu zhengyang

1. 硬件环境

项目	规格
GPU	2 × NVIDIA GeForce RTX 2080 Ti（SM75 / Turing）
GPU 显存	22,528 MiB / 卡（共 ~44 GB）
GPU 驱动	580.159.03
NVLink	2 Link/GPU，双向 25.781 GB/s/Link（NV2）
GPU 最大时钟	GPU0: 2160 MHz / GPU1: 2175 MHz；显存: 7000 MHz
CPU	AMD Ryzen 7 5700X 8 核 16 线程
内存	47 GiB DDR4
操作系统	Ubuntu 24.04.4 LTS（Kernel 6.17.0-29-generic）
CUDA Toolkit	12.9

2. 软件环境

组件	版本
Python	3.12.3
vLLM	0.24.0
PyTorch	2.11.0
FlashInfer	0.6.12（flashinfer-python + flashinfer-cubin，含 PR3621 SM75 patch）
Triton	3.6.0
Transformers	5.12.1
NumPy	2.3.5

vLLM 源码路径：/home/zyyuc/vllm-2080ti-0.24.0-qwopus
Python venv 路径：/home/zyyuc/vllm-env-0240-qwopus
FlashQLA 路径：/home/zyyuc/FlashQLA-SM70-SM75

3. 模型信息

项目	值
模型名称	Qwen3.6-27B-DSV4Pro-Thinking-FP8
模型路径	`/home/zyyuc/models/Qwen3.6-27B-DSV4Pro-Thinking-FP8`
服务名称	`qwen-local`
架构	`Qwen3_5ForConditionalGeneration`
model_type	`qwen3_5`
Hidden layers	64
Hidden size	5120
Attention heads	24
KV heads	4（GQA）
Vocab size	248,320
最大位置编码	262,144
量化方式	FP8（Marlin weight-only，block_size=128×128）
模型总大小	~29 GB（12 个语言模型 shard + 879 MB vision + 456 MB MTP）
多模态	支持图片输入（Qwen3VL Processor，vision_config hidden_size=1152）
MTP	支持（MTP3 投机解码，3 个 speculative tokens）

混合架构说明

该模型为 Mamba + Attention 混合架构：

Attention 层：使用 KV cache，O(n) 随上下文增长
Mamba 层（linear_attn）：固定递归状态，O(1) 不随上下文增长
Mamba cache mode：align（与 prefix caching 兼容）

4. 服务加载参数

4.1 systemd unit 完整配置

[Unit]
Description=Qwopus3.6 27B FP8 vLLM 0.24.0 stable server FP8 KV 100K
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=zyyuc
WorkingDirectory=/home/zyyuc/vllm-2080ti-0.24.0-qwopus

# ===== 环境变量 =====
Environment=CUDA_HOME=/usr/local/cuda
Environment=PATH=/usr/local/cuda/bin:/home/zyyuc/vllm-env-0240-qwopus/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Environment=LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/local/cuda/lib64/stubs
Environment=PYTHONPATH=/home/zyyuc/FlashQLA-SM70-SM75
Environment=HF_ENDPOINT=https://hf-mirror.com
Environment=VLLM_USE_DEEP_GEMM=0
Environment=OMP_NUM_THREADS=8
Environment=VLLM_USE_FLASHINFER_SAMPLER=0
Environment=VLLM_QWOPUS_MTP_BF16_DRAFT=1
Environment=VLLM_SM75_SPEC_SYNC_MODE=safe

# ===== 启动前校验 =====
ExecStartPre=/home/zyyuc/check-flashinfer-pr3621-sm75.sh

# ===== 启动命令 =====
ExecStart=/home/zyyuc/vllm-env-0240-qwopus/bin/python -m vllm.entrypoints.openai.api_server \
  --host 0.0.0.0 \
  --port 8000 \
  --model /home/zyyuc/models/Qwen3.6-27B-DSV4Pro-Thinking-FP8 \
  --served-model-name qwen-local \
  --dtype half \
  --tensor-parallel-size 2 \
  --device-ids 0,1 \
  --quantization fp8 \
  --kv-cache-dtype fp8_e4m3 \
  --max-model-len 100000 \
  --enable-prefix-caching \
  --max-num-seqs 1 \
  --max-num-batched-tokens 4096 \
  --enable-chunked-prefill \
  --no-async-scheduling \
  --skip-mm-profiling \
  --reasoning-parser qwen3 \
  --reasoning-config '{"reasoning_start_str":"<think>","reasoning_end_str":"</think>","default_thinking_token_budget":4000}' \
  --default-chat-template-kwargs '{"enable_thinking":true}' \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --chat-template-content-format string \
  --gpu-memory-utilization 0.92 \
  --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}' \
  --override-generation-config '{"temperature":0.6,"top_p":0.95,"top_k":20,"min_p":0.0,"presence_penalty":0.0,"repetition_penalty":1.06}' \
  --cpu-offload-gb 0 \
  --disable-uvicorn-access-log

Restart=always
RestartSec=10
TimeoutStartSec=900
StandardOutput=append:/home/zyyuc/vllm-0240-main-8000.log
StandardError=append:/home/zyyuc/vllm-0240-main-8000.log

[Install]
WantedBy=multi-user.target

4.2 关键参数说明

参数	值	说明
`--dtype half`	FP16 计算	SM75 无 BF16 Tensor Core，FP16 最快
`--tensor-parallel-size 2`	TP2	双卡并行，单卡 11GB 装不下 27B
`--device-ids 0,1`	GPU 0+1	明确选卡，不设 CUDA_VISIBLE_DEVICES
`--quantization fp8`	Marlin FP8	Weight-only 量化，节省显存
`--kv-cache-dtype fp8_e4m3`	FP8 KV Cache	KV cache 容量 +79.5%（115K→207K tokens）
`--max-model-len 100000`	100K 上下文	经 95K smoke 验证通过
`--enable-prefix-caching`	开启	重复前缀加速，Mamba align 模式
`--max-num-seqs 1`	单请求	保证长上下文和显存稳定
`--max-num-batched-tokens 4096`	4K	Chunked prefill 分块大小
`--enable-chunked-prefill`	开启	长上下文必须，否则 prefill OOM
`--no-async-scheduling`	关闭	max_num_seqs=1 时无收益
`--skip-mm-profiling`	跳过	不为多模态预留显存 profiling
`--reasoning-parser qwen3`	Qwen3 thinking	匹配 `<think></think>` 格式
`--tool-call-parser qwen3_coder`	coder parser	兼容 Claude 等客户端工具调用
`--gpu-memory-utilization 0.92`	92%	留 8% 余量防止 OOM
`--additional-config gdn_prefill_backend=flashqla_legacy`	FlashQLA	SM75 GDN prefill 必须用 legacy 后端
`--speculative-config mtp,num_speculative_tokens=3`	MTP3	投机解码，3 个 draft tokens
`--compilation-config cudagraph_capture_sizes=[4]`	仅 size 4	max_num_seqs=1 + MTP3 = 4 token slots
`--override-generation-config`	采样参数	temperature=0.6, top_p=0.95, top_k=20, repetition_penalty=1.06

4.3 环境变量说明

环境变量	值	说明
`VLLM_USE_DEEP_GEMM=0`	关闭	SM75 不支持 DeepGEMM
`VLLM_USE_FLASHINFER_SAMPLER=0`	关闭	SM75 上 FlashInfer sampler 有 bug
`VLLM_QWOPUS_MTP_BF16_DRAFT=1`	BF16 draft	MTP draft 模型用 BF16 精度
`VLLM_SM75_SPEC_SYNC_MODE=safe`	safe 模式	SM75 投机解码安全同步
`OMP_NUM_THREADS=8`	8 线程	CPU 端 tokenizer 并行
`PYTHONPATH=.../FlashQLA-SM70-SM75`	FlashQLA	SM75 GDN kernel 路径
`HF_ENDPOINT=hf-mirror.com`	镜像	国内 HuggingFace 镜像

5. 运行时状态

5.1 KV Cache 配置

指标	值
cache_dtype	`fp8_e4m3`
block_size	1600（自动对齐）
num_gpu_blocks	162
kv_cache_size_tokens	207,692
kv_cache_max_concurrency	2.077
mamba_cache_mode	`align`
mamba_ssm_cache_dtype	`float32`
enable_prefix_caching	True

5.2 GPU 显存占用

GPU	已用	总量	利用率
GPU0	21,720 MiB	22,528 MiB	96.4%
GPU1	21,752 MiB	22,528 MiB	96.5%

5.3 显存分配估算

模型权重 (27B FP8 / TP2):  ~19,500 MiB/卡  （固定不可变）
CUDA context + PyTorch:    ~1,700 MiB/卡   （固定开销）
KV cache (162 blocks):       ~507 MiB/卡   （很小）
剩余空闲:                     ~280 MiB/卡

6. 性能测试结果

6.1 测试方法

测试脚本：/home/zyyuc/fp8_vs_fp16_ab_test.py
每个 prompt 使用 64 字符随机 UUID + 随机词库生成，确保 prompt_tokens_cached=0
JIT 暖机：短请求 ×2 + 20K 暖机 + 60K 暖机
正式测试：20K ×3（max_tokens=256）+ 60K ×2（max_tokens=128）
流式请求，记录 TTFT、decode tok/s、prefill tok/s、MTP acceptance

6.2 FP8 KV Cache 测试结果（当前生产配置）

Run	上下文	TTFT (s)	Prefill (tok/s)	Decode (tok/s)	MTP Acceptance
run1	17,042 tok	13.090	1,301.9	88.0	78.9%
run2	17,052 tok	13.138	1,297.9	77.6 ️	68.3%
run3	17,041 tok	13.182	1,292.7	87.8	78.9%
run1	50,983 tok	45.587	1,118.4	87.1	63.6%
run2	51,109 tok	46.039	1,110.1	105.6	76.1%

️ run2 受 Triton JIT 编译干扰，decode 偏低

6.3 FP16 KV Cache 基线对比

Run	上下文	TTFT (s)	Prefill (tok/s)	Decode (tok/s)	MTP Acceptance
run1	17,131 tok	13.180	1,299.8	87.0	77.5%
run2	17,129 tok	13.236	1,294.1	87.0	77.1%
run3	17,054 tok	13.162	1,295.7	81.5	71.6%
run1	51,036 tok	45.733	1,116.0	117.7	81.1%
run2	51,036 tok	46.042	1,108.5	94.9	68.3%

6.4 汇总对比

指标	FP16 均值	FP8 均值	差异	结论
20K TTFT	13.193s	13.137s	-0.4%	持平
20K Prefill	1,296.5 tok/s	1,297.5 tok/s	+0.1%	持平
20K Decode	85.2 tok/s	84.5 tok/s	-0.8%	持平
20K MTP	75.4%	75.4%	0%	持平
60K TTFT	45.888s	45.813s	-0.2%	持平
60K Prefill	1,112.3 tok/s	1,114.2 tok/s	+0.2%	持平
60K Decode	106.3 tok/s	96.3 tok/s	-9.4%	持平*
60K MTP	74.7%	69.8%	-4.9pp	持平*
KV cache 容量	115,714 tok	207,692 tok	+79.5%	FP8 优势

*60K 仅 2 次采样，方差大，不具统计显著性

6.5 关键结论

FP8 KV Cache 不带来 decode/prefill 性能提升：与 FP16 基本持平，符合 SM75 架构预期（无原生 FP8 Tensor Core，KV 需反量化为 FP16 计算）
FP8 KV Cache 的唯一真实收益是容量 +79.5%：从 115K tokens 提升到 207K tokens
性能瓶颈是 GPU 计算饱和：SM 利用率 96-100%，功耗接近 200W 限制
MTP3 投机解码有效：acceptance ~75%，decode 速度显著高于无投机解码（~85 vs ~29 tok/s）

566656661

以前手上有2080ti 22gb的時候只用過llama.cpp混合其他卡使用

那個時候還沒有mtp, FA 2不支援(現在好像也是)

GEMM運算搭配4070 Ti Super偶爾會掛, 所以玩了幾個月就賣掉了

williamlouis · Ubuntu 24.04.4 LTS（Kernel 6.17.0-29-generic）

@yu-zhengyang 很好的实践。主板的型号能介绍一个下吗？

yu zhengyang

华硕的x570 pro 很普通的板子不过可以自动拆分 pcie 8*8

terry

很好，实践是检验真理的唯一标准

vosrock

又多了一个性价比之选，显存大还是硬道理

seabass

谢谢分享，我也要试试

seabass

NVlink 重要吗？没有会慢吗？

Metal Zhao

这个测试非常详尽，效果非常理想，甚至超过了双3090的速度。会不会导致2080ti魔改卡再涨价 lol

williamlouis

@Metal-Zhao 不会的。驱动就会慢慢淘汰这些老卡。技术上我点赞，现有的就跑跑是好事。没有的选择入手就是被降智了。4系都站在生命周期上了。价格下来后。游戏卡=算力卡的事会慢慢分开。

llchen

那双3080 20G魔改效果不是更好吗

applejuice

@Metal-Zhao 为什么超过双3090？的确是便宜过3090好多

stormaround

这么装不改水，温度能压住吗？

terry

@llchen 是的，有人发过，老帖子里找下。

jingy yi

很好的经验，谢谢，但我没有复现成功，请教下：

模型的确切下载来源(HF repo 名),和 Distill 版是什么关系（我下载的是Qwen3.6-27B-DSV4Pro-Thinking-Thinking-Distill-FP8）
VLLM_QWOPUS_MTP_BF16_DRAFT=1 具体做了什么——是运行时把 FP8 MTP 权重 cast 成 BF16,还是加载外部 BF16 shard?对应 fork 里哪个 commit/文件?
这个 patch 能否在主线 vLLM 0.24 上单独应用(他们既然在 0.24 base 上改的,patch 大概率能摘出来)
你是否试过不开这个开关的接受率——如果他们 FP8 draft 也是 ~46%,开了到 75%,就是你缺的那块拼图的完整对照数据

566656661

@jingy-yi

應該就是nerkyor/Qwen3.6-27B-DSV4Pro-Thinking-Distill-FP8, 不過我看不懂為什麼你這個有2個Thinking...
前者, 至少我看完Model Card之後理解是FP8 Scale up到BF16, 對應mtp.safetensors
可以, 但是不要用cu129 nightly, 目前ffmpeg有bug, vllm的container會起不來
Draft的接受率很看工作性質, 如果是編程或者輸出為Structured Output接受率會很高, 如果內容很飄忽跟沒有固定形式則會很低, 不能直接比較

terry

@jingy-yi
1，基础底座（Base）：Qwen3.6-27B。
2, “DSV4Pro-Thinking-Distill”（逻辑思维蒸馏）这是民间技术大神（Nerkyor 等人）做的核心魔改。
老师是谁：DeepSeek-V4-Pro（具有极强的推理、多轮对话和 Agent 思考能力）。
3, 怎么蒸馏的：开发者使用 LoRA 技术（$r=64, \alpha=128$），把 DeepSeek-V4-Pro 在思考、推理以及对抗“长文本无限复读”时的思考方式与收敛习惯（Thinking Style），硬生生蒸馏灌输进了 Qwen3.6-27B 里面。
4, 带来的改变：普通 Qwen 在面对极其复杂的 Agent 任务或硬核推理时，有时会陷入死循环或冲破 32K 窗口崩溃；而这个“DSV4Pro 蒸馏版”极大地压缩了无效思考的废话，学会了“如何高效、正确地收敛出答案”，其 GPQA 和长文本 Agent 稳定性直接暴涨。
以上为AI回答，下面这句话是我写的：
就是蒸馏Deepseek的思维方式去提升Qwen3.6

jingy yi

感谢两位回复,补充说明一下,我的问题可能没表达清楚:

先澄清:双 Thinking 是我打错了,就是 Nerkyor 的 Qwen3.6-27B-DSV4Pro-Thinking-Distill-FP8,模型背景我了解,不需要科普。我卡住的是复现的工程细节,收窄成三个具体问题:

patch 具体位置:#16 说这个 patch 可以摘到主线 0.24 上用——那具体是 fork 里哪个 commit / 哪个文件?求 diff 链接。我知道它是把 mtp.safetensors 的 FP8 scale 到 BF16,但不知道改动在哪,没法摘。
同机同负载的开关对照:#16 说 acceptance 看工作性质不能直接比——完全同意,所以我要的恰恰不是跨环境比较,而是楼主自己同一台机、同一批 prompt 下,VLLM_QWOPUS_MTP_BF16_DRAFT 开/关各跑一次的 acceptance。只有这个对照能证明提升来自 BF16 draft 本身,而不是工作负载差异。如果楼主还留着环境,跑一把关掉的数就够了。
75% 是什么采样条件下测的:greedy(temp=0)还是带温度采样?这个变量比想象中大得多,见下面我们的数据。

作为交换,附上我们的实测(A800 / vLLM 0.24 主线 / MTP3 / FP8 draft 未打 patch,acceptance 用 /metrics 前后差分):

greedy,10K 上下文:acceptance 52.8%,decode 75.7 tok/s
greedy,长短上下文合并(278/10K/53K):~46%
temp=1.0(生产配置,gen_config 默认):acceptance 32.8%,decode 55.7 tok/s

也就是说光温度一个变量就能把 acceptance 从 53% 打到 33%,20 个点。所以楼主的 75% 里,BF16 draft、greedy、编程类负载各贡献多少,不做开关对照 + 对齐采样条件是拆不开的。如果 patch 真有净贡献,我这边 33% 的生产口径能提多少,非常想对齐一下。

jingy yi

再补一个关键数据点:我另外下载了 BF16 主仓(全模型高精度、含原生 MTP 头)做对照,同条件(greedy / 10K / MTP3 / metrics 差分)实测 acceptance 也只有 ,46%,和 FP8 版基本持平。这说明精度不是 acceptance 的瓶颈——而这个 patch 的机制如果只是把 FP8 draft cast 成 BF16,那全 BF16 就是它的效果上限,上限都到不了 75%。所以我现在更倾向于:要么 patch 里还有 cast 之外的改动(那就更需要 diff 了),要么 75% 主要来自采样条件和负载类型。楼主给一把开关对照数据,这事就能一锤定音。

566656661

@jingy-yi

如果我沒理解錯的話vLLM自己就是這個Patch, FlashInfer裏面的話應該就是這個3620跟3621

Temperature本身就是用來控制模型的隨機程度, 越高代表越不可控, 自然會讓MTP Acceptance Rate大大降低啊, 詳情可以看這份期刊的7.4點

雖然我個人更加相信這個是來自工作内容差異, 而不是關於FP8跟BF16的分別, 畢竟兩者本體27B (FP8對上BF16) 的KLD也小於0.05, MTP估計也會維持在這附近

抡锤者

让你们看看垃圾魔改卡2080ti 的威力 qwen3.6-27b fp8 精度 速度能到 60tokens/s nvlink 连接

1. 硬件环境

2. 软件环境

3. 模型信息

混合架构说明

4. 服务加载参数

4.1 systemd unit 完整配置

4.2 关键参数说明

4.3 环境变量说明

5. 运行时状态

5.1 KV Cache 配置

5.2 GPU 显存占用

5.3 显存分配估算

6. 性能测试结果

6.1 测试方法

6.2 FP8 KV Cache 测试结果（当前生产配置）

6.3 FP16 KV Cache 基线对比

6.4 汇总对比

6.5 关键结论

1. 硬件环境

2. 软件环境

3. 模型信息

混合架构说明

4. 服务加载参数

4.1 systemd unit 完整配置

4.2 关键参数说明

4.3 环境变量说明

5. 运行时状态

5.1 KV Cache 配置

5.2 GPU 显存占用

5.3 显存分配估算

6. 性能测试结果

6.1 测试方法

6.2 FP8 KV Cache 测试结果（当前生产配置）

6.3 FP16 KV Cache 基线对比

6.4 汇总对比

6.5 关键结论

让你们看看垃圾魔改卡2080ti 的威力 qwen3.6-27b fp8 精度速度能到 60tokens/s nvlink 连接