4080S 32G 跑 Qwen3.8-27B:llama.cpp 优化全记录 + SGLang 探索踩坑

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

上一篇篇幅所限只给了结论,这篇按 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 原始数据和踩坑日志都在手边,有问必答。

ydszc11

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

neo

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

jingy yi

@ydszc11 说:

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

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

jingy yi

@neo 说:

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

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

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

terry

挺好的，其实4080S 32G是个黄金卡，就是现在坑比老板太多，板子做的不扎实，售后也不好，不然这张卡真的挺好的。

抡锤者