让你们看看垃圾魔改卡2080ti 的威力 qwen3.6-27b fp8 精度 速度能到 60tokens/s nvlink 连接
-
华硕的x570 pro 很普通的板子 不过可以自动拆分 pcie 8*8
-
这个测试非常详尽，效果非常理想，甚至超过了双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方法。
-
