让你们看看垃圾魔改卡2080ti 的威力 qwen3.6-27b fp8 精度 速度能到 60tokens/s nvlink 连接
-
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_5ForConditionalGenerationmodel_type qwen3_5Hidden 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.target4.2 关键参数说明
参数 值 说明 --dtype halfFP16 计算 SM75 无 BF16 Tensor Core,FP16 最快 --tensor-parallel-size 2TP2 双卡并行,单卡 11GB 装不下 27B --device-ids 0,1GPU 0+1 明确选卡,不设 CUDA_VISIBLE_DEVICES --quantization fp8Marlin FP8 Weight-only 量化,节省显存 --kv-cache-dtype fp8_e4m3FP8 KV Cache KV cache 容量 +79.5%(115K→207K tokens) --max-model-len 100000100K 上下文 经 95K smoke 验证通过 --enable-prefix-caching开启 重复前缀加速,Mamba align 模式 --max-num-seqs 1单请求 保证长上下文和显存稳定 --max-num-batched-tokens 40964K Chunked prefill 分块大小 --enable-chunked-prefill开启 长上下文必须,否则 prefill OOM --no-async-scheduling关闭 max_num_seqs=1 时无收益 --skip-mm-profiling跳过 不为多模态预留显存 profiling --reasoning-parser qwen3Qwen3 thinking 匹配 <think></think>格式--tool-call-parser qwen3_codercoder parser 兼容 Claude 等客户端工具调用 --gpu-memory-utilization 0.9292% 留 8% 余量防止 OOM --additional-config gdn_prefill_backend=flashqla_legacyFlashQLA SM75 GDN prefill 必须用 legacy 后端 --speculative-config mtp,num_speculative_tokens=3MTP3 投机解码,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=1BF16 draft MTP draft 模型用 BF16 精度 VLLM_SM75_SPEC_SYNC_MODE=safesafe 模式 SM75 投机解码安全同步 OMP_NUM_THREADS=88 线程 CPU 端 tokenizer 并行 PYTHONPATH=.../FlashQLA-SM70-SM75FlashQLA SM75 GDN kernel 路径 HF_ENDPOINT=hf-mirror.com镜像 国内 HuggingFace 镜像
5. 运行时状态
5.1 KV Cache 配置
指标 值 cache_dtype fp8_e4m3block_size 1600(自动对齐) num_gpu_blocks 162 kv_cache_size_tokens 207,692 kv_cache_max_concurrency 2.077 mamba_cache_mode alignmamba_ssm_cache_dtype float32enable_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)

@yu-zhengyang 很好的实践。主板的型号能介绍一个下吗?
-
华硕的x570 pro 很普通的板子 不过可以自动拆分 pcie 8*8
-
这个测试非常详尽,效果非常理想,甚至超过了双3090的速度。会不会导致2080ti魔改卡再涨价 lol
-
这个测试非常详尽,效果非常理想,甚至超过了双3090的速度。会不会导致2080ti魔改卡再涨价 lol
@Metal-Zhao 不会的。驱动就会慢慢淘汰这些老卡。技术上我点赞,现有的就跑跑是好事。没有的选择入手就是被降智了。4系都站在生命周期上了。价格下来后。游戏卡=算力卡的事会慢慢分开。
-
这个测试非常详尽,效果非常理想,甚至超过了双3090的速度。会不会导致2080ti魔改卡再涨价 lol
@Metal-Zhao 为什么超过双3090?的确是便宜过3090好多
-
这么装不改水,温度能压住吗?
-
很好的经验,谢谢,但我没有复现成功,请教下:
- 模型的确切下载来源(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%,就是你缺的那块拼图的完整对照数据
-
很好的经验,谢谢,但我没有复现成功,请教下:
- 模型的确切下载来源(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%,就是你缺的那块拼图的完整对照数据
-
應該就是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接受率會很高, 如果內容很飄忽跟沒有固定形式則會很低, 不能直接比較
-
很好的经验,谢谢,但我没有复现成功,请教下:
- 模型的确切下载来源(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%,就是你缺的那块拼图的完整对照数据
@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 -
感谢两位回复,补充说明一下,我的问题可能没表达清楚:
先澄清:双 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% 的生产口径能提多少,非常想对齐一下。
-
-
再补一个关键数据点:我另外下载了 BF16 主仓(全模型高精度、含原生 MTP 头)做对照,同条件(greedy / 10K / MTP3 / metrics 差分)实测 acceptance 也只有 ,46%,和 FP8 版基本持平。这说明精度不是 acceptance 的瓶颈——而这个 patch 的机制如果只是把 FP8 draft cast 成 BF16,那全 BF16 就是它的效果上限,上限都到不了 75%。所以我现在更倾向于:要么 patch 里还有 cast 之外的改动(那就更需要 diff 了),要么 75% 主要来自采样条件和负载类型。楼主给一把开关对照数据,这事就能一锤定音。
-
感谢两位回复,补充说明一下,我的问题可能没表达清楚:
先澄清:双 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% 的生产口径能提多少,非常想对齐一下。
-
-
如果我沒理解錯的話vLLM自己就是這個Patch, FlashInfer裏面的話應該就是這個3620跟3621
Temperature本身就是用來控制模型的隨機程度, 越高代表越不可控, 自然會讓MTP Acceptance Rate大大降低啊, 詳情可以看這份期刊的7.4點
雖然我個人更加相信這個是來自工作内容差異, 而不是關於FP8跟BF16的分別, 畢竟兩者本體27B (FP8對上BF16) 的KLD也小於0.05, MTP估計也會維持在這附近
如果我沒理解錯的話vLLM自己就是這個Patch, FlashInfer裏面的話應該就是這個3620跟3621
Temperature本身就是用來控制模型的隨機程度, 越高代表越不可控, 自然會讓MTP Acceptance Rate大大降低啊, 詳情可以看這份期刊的7.4點
雖然我個人更加相信這個是來自工作内容差異, 而不是關於FP8跟BF16的分別, 畢竟兩者本體27B (FP8對上BF16) 的KLD也小於0.05, MTP估計也會維持在這附近
这个模型的作者说后续会研究发布Patch,说明发布的模型的MTP是未Patch修改版。我实测下来,FP8和FP16的MTP命中率是一样的,就35~55%,代码类高,问题类低。而楼主的MTP命中率较高,所以我想问问是不是他有更新的模型或Patch方法。