抡锤者

jingy yi

这个说法从机制上讲确实不科学。如果 DFlash2 和 DSpark 都按标准 speculative decoding 正确实现，那么：
换投机解码算法应该改变速度、接受率、GPU利用方式，但不应该系统性提高 Qwen3.8-27B 的代码能力。
vLLM/Speculators 现在对 DFlash、DFlash2、DSpark、MTP 的定义很明确：这些算法都是 lossless speculative decoding，最终输出仍来自 target model 原来的概率分布。
DSpark 多出来的东西，不是“增强模型智力”

DSpark 相比 DFlash 类方法，主要增加了两个头：
Markov head：让 block 内后面的 draft token 能参考前一个 token，提高草稿预测准确率；
confidence head：预测每个 draft token 被 target 接受的概率，决定验证多长的 block。

jingy yi

@neo 说:

感觉4080s没有比3080/3090强很多的样子呢

我也不清楚，如果单看速度，要注意是否保留视觉、模型尺寸、KV缓存尺寸、以及温度、提示词和生成内容等，一般直接看速度是很难说性能谁强。

3090是神卡与4080S比不太清楚谁强，但4080S一定比3080强

jingy yi

@ydszc11 说:

不专业，看不太懂。但结论是不是现在llama.cpp 还是N卡的最佳选择，SGLang 虽然理论性能好，还是实测在4080s的N卡上还是有bug没有解决。大佬，我这个理解是对的吗？

本贴主要是4080S（32G魔改卡）部署Qwen3.8-27B UD-Q4_K_XL的一些调优经验和结果，llama.cpp 的确是个人用户的较好选择。里面有很多踩坑教训，以及我参考了本论坛很多高手的经验，目前以个人能力能做到的最优解。目前基本上没什么重大BUG了。

jingy yi

贴主的测法纪律太有价值了,我们按同款协议在 4080S SUPER 32G(CUDA + llama.cpp + MTP n=4) 上跑了一遍完整对照,补一个 NV 平台数据点。完整优化记录见我们的帖子:1404 帖。

同题同采样(temp=0.6, top_p=0.5, top_k=15,每题 ×2 取中位):

测试项	7900 XTX(本帖)	4080S 32G
中文散文 800 字	39-47 / acc 0.31-0.47	56.9 / acc 0.313
C++ LRU cache	69.5 / 0.851	95.8 / 0.711
C++ HTTP 解析器	68.4 / 0.833	101.0 / 0.774
工具调用 4 场景平均	73.4 / 0.71-0.97	78.3 / 0.45-0.61
no-MTP 基线	38.9(llama-bench)	31.2(历史记录)

prefill(真实 agent prompt):

6.4K:587.7 vs 1805 tok/s
9.6K:591.5 vs 1841 tok/s
23.7K:我们 1753(较 6.4K 仅 -3%;你们 38.9K 掉 26%——CUDA 的 chunked prefill 路径长度衰减明显更小,供 ROCm 参考)

prompt cache 两轮:第二轮 0.2s(重读 26 tok),与你们 1.26s/19 tok 同级的 10 倍收益。

三个观察:

接受率随负载波动的结论在我们卡上完全复现:散文 acc 0.31 vs 代码 0.77,同机同参数差 78%——"测 MTP 必须用实际工作负载"完全正确;
工具调用接受率我们偏低(0.45-0.61,猜测与 draft 模板/量化组合有关),但 CUDA 单步速度仍净胜;
KV 量化的平台差异提醒:NVIDIA 的 flash-attn 内核只认 q8_0/q4_0,q4_1/q5_0 会静默 CPU fallback(速度跌 10 倍以上),所以"V 用 q4_1"在 NV 卡走不通——K4V4 是 CUDA 性价比终点(每 token KV 18KB,32G 卡开出 307K 统一池,单槽自动钳制原生 262144)。

完整优化记录(代理路由/准入设计/踩坑日志)在 1404 帖,欢迎对照拍砖。

jingy yi

上一篇篇幅所限只给了结论,这篇按 1164 帖的"数字必须带测法"纪律,把 4080S 这套的完整配置补齐。先说和 1164 的对照:AMD ROCm 和 CUDA 两条路线,结论意外地一致——我们实测 MTP 接受率随负载/时间在 0.47~0.67 之间波动,和他们 0.31~0.97 的跨度呼应,论坛上论坛数字对不上,根源都是这个。

一、llama.cpp 完整启动参数(systemd ExecStart,可直接抄)

/usr/bin/stdbuf -oL -eL /opt/llama.cpp-qwen38/build/bin/llama-server \
  --model /opt/models/Qwen3.8-27B-UD-Q4_K_XL-GGUF/Qwen3.8-27B-UD-Q4_K_XL.gguf \
  --model-draft /opt/models/Qwen3.8-27B-UD-Q5_K_XL-GGUF/MTP/mtp-Qwen3.8-27B-Q4_0.gguf \
  --mmproj /opt/models/Qwen3.8-27B-UD-Q5_K_XL-GGUF/mmproj-F16.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 4 \
  --spec-draft-ngl 99 \
  --spec-draft-type-k q4_0 \
  --spec-draft-type-v q4_0 \
  --alias "Qwen3.8-27B-Coding" \
  --port 8002 --host 127.0.0.1 \
  --ctx-size 307200 \
  --parallel 4 --kv-unified \
  --batch-size 8192 --ubatch-size 1024 \
  -ngl 99 --split-mode layer \
  --cache-ram 16384 --cache-reuse 256 \
  --slot-save-path /home/yijingu/logs/27b-slot-saves \
  --cache-type-k q4_0 --cache-type-v q4_0 \
  --flash-attn on --load-mode mlock --jinja \
  --chat-template-file .../chat_template_fixed_patched.jinja \
  --log-prompts-dir /home/yijingu/logs/27b-prompts \
  --fit on --fit-target 128 \
  --threads 12 \
  --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 \
  --reasoning on --reasoning-format deepseek

要点:

--ctx-size 307200 + --parallel 4 --kv-unified:统一池 307K,llama.cpp 自动把单槽钳制在模型原生 n_ctx_train=262144(有 warning 但行为正确)——单会话不越原生上限,多出来的池容量全部用于并发。32G 卡能开 307K 池的根本是下面这条;
K4V4(双 q4_0):每 token KV 仅 18KB,比 fp8 KV 省 44%;质量套件 19/21 + 工具调用全过 + 187K 深度检索全命中,速度与 q8_0 持平;
--cache-ram 16384:槽位被逐出时 KV 状态先进 16G 内存池再落盘,会话恢复免重算;
--fit on --fit-target 128:显存超预算时自动收缩参数,兜底用。

二、性能数据(全部附测法)

指标	数值	测法
解码中位	89 tok/s(p10≈41, 峰值105)	15 题 × 800 tok,/completion 串行,按路由温度
MTP 接受率	0.47~0.67(随负载/时段)	同上,timings.draft_n/draft_n_accepted
冷 prefill(35K tok)	~1700-1900 tok/s	cache_prompt=false ×3 取稳定值
暖 TTFT(35K 命中)	0.10~0.4s	cache_prompt=true,prompt_ms
no-MTP 基线	31 tok/s	同题集去 MTP

MTP 接受率波动范围和 1164 的 0.31~0.97 呼应:论坛数字对不上,先对测法再对硬件。另有一个实操坑:测量时本机其他 Agent 的定时任务会抢槽位,解码中位数能被砍 40%——测速时务必确认并发空闲,或加槽位监视。

三、代理层(FastAPI,8001):路由 + 准入 + 自动放行

模型前面有一层自研路由代理,核心逻辑简化后如下(完整版 900+ 行,含准入/监控/持久化):

# 六档路由:B日常/C1分析/C2代码+Agent/D深分析/A格式化/V视觉
TIER = {
    "B":  dict(max_tokens=4096, thinking=False),
    "C1": dict(max_tokens=6144, thinking=True,  budget=2048, effort="medium"),
    "C2": dict(max_tokens=6144, thinking=True,  budget=4096),
    "D":  dict(max_tokens=6144, thinking=True,  budget=2048, effort="medium"),
}

def resolve_auto_c2_max_tokens(payload, decision, cron):
    # 编码Agent零配置:客户端显式要大输出(如pi-ai默认32768)时,
    # C2自动放宽到32768+1800s超时;CRON恒锁1K/2K;普通请求不变
    if cron or decision.get("route") != "C2":
        return None
    req = payload.get("max_tokens") or payload.get("max_completion_tokens")
    if not isinstance(req, int) or req <= decision["max_tokens"]:
        return None
    return min(req, LONG_OUTPUT_MAX_TOKENS)  # 32768

def resolve_max_tokens(payload, route_limit):
    req = payload.get("max_tokens")
    if req is None:
        return route_limit
    return min(req, route_limit)  # 未命中自动C2时仍钳制,防无差别预留

准入保护:每路并发请求按 输入+max_tokens 预留预算,合计 ≤ 共享池 token 数,超了 429——这套在 ctx 扩到 307K 后同步改为 307200;
踩坑:客户端(如 pi-ai 系)默认发 max_tokens=32768,无脑尊重会让每个普通请求都按 32K 预留准入预算 → 必须用"路由命中 C2 才放宽"的条件放行,CRON 用 header 前缀识别后强制锁小预算。

四、和 1164/Xiaote 观点的两个交叉印证

K8V4 vs K4V4:Xiaote 建议显存紧时"降 V 不降 K、V 用 q4_1"。CUDA 这边有个平台差异要提醒:llama.cpp 的 CUDA flash-attn 内核只实现了 q8_0/q4_0 两格式,q4_1/q5_0 会静默掉 CPU fallback(实测速度跌 10 倍以上)——所以 NV 卡上"V 用 q4_1"这条路走不通,K4V4 就是 CUDA 的性价比终点,K8V4 是显存富余时的质量升级项,和他们的结论殊途同归;
prefill 长度衰减:1164 实测 6.4K→38.9K prefill 掉 26%,提醒"短 prompt 外推长上下文等待会严重低估"——我们同样只在 35K 口径下报 ~1900,不外推。另外 Agent 长链任务若用我们代理的软压缩(超阈值丢最老轮次),会破坏前缀缓存命中,体感 TTFT 变差,这也是"Agent 场景比单轮慢"的一个非模型因素。

配置细节、A/B 原始数据和踩坑日志都在手边,有问必答。

jingy yi

继 1329 帖的 4090D / 5090 / RTX PRO 4500 对照,补一个 4080S 32G(改装显存版) 的数据点。前半是 llama.cpp 生产链路的优化记录,后半是在同一张卡上对 SGLang+HiCache 的失败探索——负结果,但对犹豫要不要换引擎的 32G 卡兄弟应该有参考价值。

一、硬件与基线

卡:RTX 4080 SUPER 32G(改装显存版),驱动 595.84
引擎:llama.cpp b6508 后新构建(bump 0.2.0),CUDA 编译
模型:Qwen3.8-27B UD-Q4_K_XL(主)+ Q4_0 MTP 草稿 + mmproj 视觉,froggeric v22 模板
代理:自研 FastAPI 路由层(A/B/C1/C2/D/V 六档,按内容/tools 自动路由思考档位与输出预算)

二、优化过程与结论(全部实测)

1. MTP 深度:接受率不是越高越好。 n=1→4 全扫描:n=4 接受率最低(48.8%)但速度最快(2.05x,no-MTP 31 → 64 tok/s),深层 draft 摊销验证开销盖过了接受率损失。n=5/6 必崩(MTMD 初始化 ABRT)。p-min 扫描 0~0.8 全负收益,p-min=0 定稿。

2. KV 量化:K4V4(q4_0)白嫖 3.3G 显存。 这个 flash-attn 内核只认 q8_0/q4_0,其他变体会掉 CPU fallback。K4V4 对比 q8_0:质量套件 19/21 + 工具调用全过 + 长上下文检索 187K 深度全命中,速度持平。每 token KV 仅 18KB,这是 32G 卡能开大上下文的根本。

3. 上下文:绕了一圈回到原点,但姿势更好。 262144 → 200000(缩池换余量)→ 262144(余量够了恢复)→ 307200 统一池:llama.cpp 会自动把单槽钳制在模型原生 n_ctx_train=262144(启动有 warning 但行为正确),多出来的 45K 池容量正好用于并发——单会话不超原生上限(零质量风险),262K 会话 + 32K 会话可同池共存。

4. batch/ubatch:8192/1024 定稿。 batch 8192 让 35K 冷 prefill 稳定在 1690×3(4096 时波动 1160~1690);ubatch 2048 能把解码 p10 从 40 提到 78(MTP 验证批不再切分),但计算缓冲多吃 1.4G,按显存预算取舍。

5. cache-ram 16G:llama.cpp 的"迷你 HiCache"。 槽位被逐出时 KV 状态先进内存池再落盘,会话恢复免重新 prefill。机制上是槽位级保存/恢复,不是 token 级 Radix,但配合统一 KV 的公共前缀共享,日常够用。

6. Agent 输出截断修复:路由层自动放行。 编码 Agent(DSH/pi-ai 系)默认发 max_tokens=32768,路由器原会钳到档位上限(6144),大工具调用写到一半被掐、发"继续"无限循环。改为:命中 C2(代码/Agent)且客户端显式请求更大值时自动放宽到 32768 + 1800s 超时,CRON 恒锁小预算防滥用。客户端零配置。

7. 当前速度水位(全套定稿配置):35K 冷 prefill ~1900 tok/s,解码中位 ~89 tok/s(no-MTP 基线的 2.9 倍),显存 31.0/32.8G(统一池 307K token)。

三、SGLang+HiCache 探索:三连负结果,不换生产

用 Docker 完全隔离跑 SGLang(latest),对照 1329 帖的结论:

尝试	结果
NVFP4 4bit(带视觉+MTP 的理想模型)	启动即报错 `NotImplementedError: Current platform does not support w4a4 nvfp4 quantization` —— NVFP4 是 Blackwell 专属路径,Ada 没实现,无绕过
AWQ INT4(带视觉,无 MTP)	能跑:KV 池 118,569 token、HiCache host pool 245K/8G 分配正常;但 AWQ 仓库无 MTP 头,解码只有 36.9 tok/s
HiCache 跨层回捞	未生效:灌 12 万 token 强制逐出后回查最早前缀,cached=0、耗时与全新冷启动一致。疑似 hybrid(GDN) 架构与 HiCache 的兼容缺口

结论:32G Ada 卡上,SGLang 解码只有 llama.cpp+MTP 的一半、单会话上下文 256K→131K、HiCache 回捞还没兑现——维持 llama.cpp 生产。1329 帖的 SGLang 收益场景(多会话共享前缀 + 容量扩展)在 32G Ada 上三根支柱缺了两根半。

替代方案:llama.cpp 侧开 --cache-ram 16G 当"迷你 HiCache",槽位恢复免重算,成本低无风险。

四、给同款卡的建议

4080S/4090 系(Ada)别试 NVFP4,SGLang 直接不认;
混合架构(GDN)模型玩前缀缓存/分层缓存,先确认工具链对 hybrid 的 checkpoint 支持,否则会遇到"分配了但不回捞"的静默失效;
llama.cpp 路线的 MTP + K4V4 + 统一池在 32G 卡上是性价比极高的组合,欢迎对照。

配置细节、踩坑日志和 A/B 数据都在我这边,有问必答。

—— jingy yi

jingy yi

谢谢，我已经用上了，两个缺点用你推荐的都解决了

jingy yi

请教下，版主linux显卡测试的贴在哪里？我没找到，正需要

jingy yi

我用BF16的去替换FP8的，所有检查都通过，但替换后命中率为0，替换失败了。后面我直接实测开发者的原版BF16模型，发现MTP的命中率是差不多的

jingy yi

@566656661 说:

@jingy-yi

如果我沒理解錯的話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方法。

jingy yi

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

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

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

模型的确切下载来源(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%,就是你缺的那块拼图的完整对照数据