抡锤者

清

RTX PRO 4500 32G 跑 Qwen3.8-27B：Unsloth Desktop 默认参数 + MTP，2 槽位 × 150K，短上下文 54–64 t/s（GSP 篇续集，附完整配置）

平台：Linux（Ubuntu）/ llama.cpp（Unsloth Desktop 0.1.801 生成参数）/ NVIDIA RTX PRO 4500 Blackwell 32GB
模型：Qwen3.8-27B-UD-Q4_K_XL（Unsloth Dynamic v3.0，17.56GB）+ mmproj-F16（0.88GB）
配置：2 并行槽位 / 153856 ctx / MTP n-max 2 / Flash Attention / KV unified（q8_0：K=Q8_0 + V=Q8_0）
日期：2026-08-21（含全天 MTP 接受率统计 195 次请求 + 高上下文压测）
上一篇：《Qwen3.8-27B llama.cpp 部署实测与 Blackwell GSP 崩溃分析》（topic/1222），本篇是同一张卡的另一套日常配置，两篇对照着看。

这张 RTX PRO 4500 买来就是为了跑本地 LLM，上篇踩了 GSP 崩溃的坑，折腾了不少。后来翻了论坛上各位大神的帖子（5070 Ti、双 3090、7900 XTX 的实测），又研究了 Unsloth 的桌面软件（口碑不错，会根据不同硬件自动生成初始参数）。拿到它的默认参数后，在实机上慢慢调，先加 MTP，再调 KV 量化，一步一步来。现在这套配置跑了一段时间，貌似不怎么崩了，分享给大家参考。

一、先说结论

上一帖是「单槽位 + 128K + K4V4」的稳定性向配置（67.2 t/s 压测均速）。这次换了 Unsloth Desktop 0.1.801 自动生成的默认参数 + 手动加 MTP，2 槽位 × 150K 日常向配置：短上下文平均 54.6 t/s（45.4–64.1），71K 上下文 18.6–41.1 t/s。
MTP 接受率 72.87%（195 次请求全天统计），平均每次验证步骤实际产出 2.55 个 token，理论加速上限 ~2.5×，实测相对关 MTP（24.5 t/s）加速 2.2–2.6×，效率约 89%。
Unsloth Desktop 的自动参数直接可用，我只手动加了 2 行（MTP 开关 + n-max），没手调其它参数。32GB 卡跑 2 槽位 × 150K 全层 GPU，显存 ≈25.4GB，余量 ~6.6GB（q8_0 KV）。
白话：MTP = 模型自带的「草稿头」先猜 2 个 token，主模型一次前向全部验证，猜中就白拿。猜中率 72.87%，等于每步白捡 1.5 个 token，速度直接翻 2 倍出头。
注意：2 小时 0 崩溃 ≠ 长期稳定，Blackwell GSP 固件 bug（Xid 62/8/154）还在，根因分析与规避手段见上一篇，本篇不重复。

二、模型参数卡（官方 config.json × GGUF 头双重核对）

以下数据来自 HuggingFace 官方 Qwen/Qwen3.8-27B 的 config.json，并与本地 GGUF 头部元数据逐项核对一致：

| 项 | 值 |
| 架构 | Qwen3_5ForConditionalGeneration（model_type: qwen3_5），原生多模态：文本 + 图像 + 视频 |
| 参数量 | 27B（dense，非 MoE），BF16 原生 |
| 层数 | 64 主层 + 1 MTP 层（GGUF block_count=65） |
| 注意力 | 混合式：48 层线性注意力（Gated DeltaNet：conv k=4，16 key heads × 128 / 48 value heads × 128，SSM fp32）+ 16 层全注意力（full_attention_interval=4） |
| 全注意力细节 | 24 heads / 4 KV heads（GQA 6:1），head_dim 256，partial rotary 0.25，rope_theta 1e7，mRoPE 交错（多模态 RoPE） |
| 隐层 / FFN | hidden 5120 / FFN 17408（SiLU + 输出门） |
| 上下文 | 原生 256K（max_position_embeddings 262144） |
| MTP | mtp_num_hidden_layers=1，共享 embeddings（无独立 embed 表），即 llama.cpp 的 --spec-type draft-mtp |
| 词表 | 248,320 |
| 视觉塔 | ViT depth 27 / hidden 1152，image_token 248056 / video_token 248057 |
| 量化（本卡） | UD-Q4_K_XL（Unsloth Dynamic v3.0 混合精度，imatrix 校准），17.56GB，≈5.2 BPW；mmproj-F16 0.88GB |
| 仓库 | 官方 Qwen/Qwen3.8-27B（apache-2.0）/ 量化 unsloth/Qwen3.8-27B-GGUF |

两个和本篇速度直接相关的点：只有 16 层全注意力存 KV cache（线性注意力层只占固定大小状态），所以 150K 上下文的 KV 在 f16 下 ~10GB、q8_0 下 ~5.4GB，2 槽位才塞得下；MTP 头共享 lm_head，不额外占权重。

三、硬件 / 软件环境

| 项 | 配置 |
| 显卡 | NVIDIA RTX PRO 4500 Blackwell 32GB（sm_120，GB202，显存带宽 896 GB/s） |
| 系统 | Ubuntu（Linux） |
| 框架 | llama.cpp，Unsloth Desktop 0.1.801 安装并生成启动参数 |
| 模型 | Qwen3.8-27B-UD-Q4_K_XL.gguf（17.56GB）+ mmproj-F16.gguf（0.88GB） |
| 服务方式 | systemd 服务 llama-qwen-27B.service，端口 8000 |

四、完整配置（可直接复制）

Unsloth Desktop 自动生成基础参数，我手动只加了 MTP 两行（--spec-type / --spec-draft-n-max）：

# systemd service: llama-qwen-27B.service
llama-server \
  -m ~/models/Qwen3.8-27B/Qwen3.8-27B-UD-Q4_K_XL.gguf \
  --mmproj ~/models/Qwen3.8-27B/mmproj-F16.gguf \
  --alias Qwen3.8-27B \
  --port 8000 \
  --parallel 2 \
  --flash-attn on \
  --no-context-shift \
  -c 153856 \
  -ngl -1 \
  --fit off \
  --metrics \
  --slot-save-path ~/.unsloth/studio/cache/llama-slots \
  --kv-unified \
  --jinja \
  --spec-type draft-mtp \
  --spec-draft-n-max 2 \
  --reasoning on --reasoning-preserve

关键参数说明

五、实测数据

测法：短上下文 = 日常真实请求，speed 取自 systemd journalctl 实时日志（llama-server 每请求一条 prompt eval + eval 统计）；高上下文 = 预置 ~71K token 填充后生成 4096 token；接受率 = journalctl 的 Draft Acceptance 行，全天 195 次请求全量统计，非抽样。

5.1 短上下文（日常交互，2026-08-21 14:33–14:36）

| 时间 | 生成 tokens | 耗时 (ms) | 速度 (t/s) |
| 14:33:42 | 2588 | 45254 | 57.17 |
| 14:34:06 | 1160 | 23092 | 50.19 |
| 14:34:29 | 1140 | 21017 | 54.19 |
| 14:34:45 | 873 | 14390 | 60.60 |
| 14:34:57 | 488 | 10242 | 47.55 |
| 14:35:06 | 394 | 7984 | 49.22 |
| 14:35:21 | 838 | 13048 | 64.14 |
| 14:35:35 | 811 | 12853 | 63.02 |
| 14:35:56 | 752 | 16555 | 45.36 |
| 14:36:07 | 525 | 9589 | 54.65 |

平均 54.6 t/s，范围 45.36–64.14。 波动主要来自 2 槽位偶发并发与请求长度分布，非性能衰减。（注：本表为 f16 KV 时代数据，切换 q8_0 后短 ctx 实测更高，见 5.5）

5.2 高上下文压测（~71K ctx 填充 + 4096 生成，2026-08-21 13:14–13:30）

| 请求 | 上下文 tokens | 生成 tokens | 耗时 (s) | 速度 (t/s) |
| req 1 | 71280 | 4096 | 220.5 | 18.6 |
| req 2 | 71764 | 4096 | 99.5 | 41.1 |
| req 4 | 71791 | 4096 | 380.6 | 10.8（离群，见踩坑 #4） |

71K 上下文下 18.6–41.1 t/s，衰减明显但可用。高 ctx 下 MTP 收益缩小（验证步骤变贵），这是混合注意力模型的通性，不是配置问题。

5.3 MTP 接受率（全天 195 次请求）

平均接受率 72.87%，范围 62.7%–97.6%
平均每次验证步骤产出 2.55 token（1 个主模型 bonus + 1.55 个被接受的草稿）
接受率与内容强相关：结构化输出（JSON/代码/固定格式）常 93%–97.6%，自由长文本 62.7%–77%

抽样 10 次：

| 时间 | 接受率 | 接受/生成 | 每步 token |
| 14:33:42 | 87.57% | 1648/1882 | 2.75 |
| 14:34:06 | 71.95% | 685/952 | 2.44 |
| 14:34:29 | 76.28% | 688/902 | 2.53 |
| 14:34:45 | 93.42% | 568/608 | 2.87 |
| 14:34:57 | 62.73% | 271/432 | 2.25 |
| 14:35:06 | 67.26% | 226/336 | 2.35 |
| 14:35:21 | 96.33% | 551/572 | 2.93 |
| 14:35:35 | 97.64% | 537/550 | 2.95 |
| 14:35:56 | 67.71% | 432/638 | 2.35 |
| 14:36:07 | 92.94% | 342/368 | 2.86 |

5.4 上下文衰减阶梯（8K–128K，2026-08-21 补测）

上下文	实际 token	Prefill (t/s)	生成速度 (t/s)	相对基线
~2K（日常对话）	37–49	~220	72.4	100%
8K	8,222	1,498	70.7	97.7%
16K	16,414	1,455	67.8	93.6%
32K	32,798	1,330	64.2	88.7%
64K	65,556	1,189	58.3	80.5%
128K	131,076	873	51.7	71.4%

测法：slot 0、MTP n2、reasoning off（纯速度测量）、每级预热后取稳态值（f16 KV 下测得）。衰减是渐进的，32K 以内基本无感（<12%），64K 起有感（~20%），128K 掉 ~29% 仍有 52 t/s。"明显变慢"的分水岭约在 64K–100K。

5.5 q8_0 KV 量化实测（2026-08-21 切换后）

指标	f16（之前）	q8_0（现在）	变化
VRAM 占用	~29 GB	~25.4 GB	-3.6 GB
显存余量	~3 GB	~6.6 GB	+3.6 GB
32K 上下文生成速度	64.2 t/s	68.4 t/s	+6%
GPU 利用率（生成时）	高	93-100%	正常
CPU 占用	正常	~100%（单核）	正常

q8_0 全 8bit KV 切换后 VRAM 从 ~29GB 降至 ~25.4GB（省 3.6GB），32K 生成速度 68.4 t/s 比 f16 还快 6%。踩坑记录：先试过 q8v4（K=Q8+V=Q4）不对称方案，但 llama.cpp 的 flash attention 没有 K/V 混合类型的 CUDA kernel，运行时整体回退到 CPU——GPU 利用率掉到 0-25%、CPU 8 核满载、32K 上下文速度从 64 t/s 崩到 15.8 t/s。关键结论：K/V cache 必须对称——K4V4（Q4+Q4）实测 32K=59.1 / 64K=44.4 t/s 完全正常，q8_0（Q8+Q8）也正常。切换 KV 量化后务必跑长上下文验证（短 ctx 测不出来）。

5.6 DFlash2 块扩散投机解码对比实测（2026-08-21）

DFlash2 是 Z-Lab 的块扩散草稿模型（Inco 发布 Qwen3.8-27B 专用草稿头），llama.cpp 支持 --spec-type draft-dflash（本机 commit 5ecbe1a）。用独立测试服务（端口 8001，q8_0 KV 与生产一致）实测对比：

上下文	MTP n2（生产）	DFlash2（测试）	胜者
短 ctx	72.4 t/s	47.3 t/s	MTP（快 53%）
32K	64.2 t/s	54.0 t/s	MTP（快 19%）
64K	58.3 t/s	45.9 t/s	MTP（快 27%）
64K 衰减	19%	37%	MTP 更平缓
GPU 利用率	93-100%	93-97%	平

结论：本卡上 DFlash2 全面落后 MTP n2，不值得切换。 根因：Q4_K_M 草稿接受率仅 26.8%（vs MTP 72.87%），块扩散每步验证 8 个 token 的前向开销没被低接受率赚回来；短 ctx 下验证成本占比更高所以最慢。DFlash2 官方说明为无损投机（greedy 输出与主模型一致），质量无虞，只是速度不划算。

备注：--hf-repo-draft 在本构建有 bug（草稿路径解析为空），需用 --model-draft 指定本地 GGUF 路径。

六、MTP 加速账：从接受率到 2.2×

n-max 2 时每步产出 = 1 + p₁ + p₁·p₂（p₁、p₂ 为两个草稿位置的条件接受概率），实测均值 2.55 token/步。验证 3 个 token 的前向比单 token 略贵，理论上限约 2.5×。

| 配置 | 短上下文速度 | 相对无 MTP |
| MTP n-max 2（本篇，2 槽位 150K） | 54.6 t/s（均值） | 2.23×（范围 1.85–2.62×） |
| MTP 关闭（同卡实测 2026-08-19） | 24.5 t/s | 1× |
| 理论上限（2.55 token/步） | — | ~2.5× |

实测 2.23× 达到理论上限的 ~89%，剩余 11% 就是验证开销 + 偶尔的整组拒绝。这个效率对 dense 模型来说很健康（社区 MoE 模型 MTP 常见 1.5–1.7×，见 topic/1207 注）。

七、社区跨卡对照（同模型 Qwen3.8-27B，均为本版论坛实测帖）

ctx、量化、框架、槽位数都不同，这张表只给量级感：32GB 卡单卡 llama.cpp 路线，短上下文 50–67 t/s 是这个模型在 Blackwell 专业卡上的正常水位。

关于 topic/100（7900XTX + K4V4）的补充：该帖的 K4V4（Q4+Q4 对称）跑满 256K 正常，与本篇结论互相印证——llama.cpp 对对称 KV 类型（K4V4 或 q8_0）的支持与显卡无关，NVIDIA CUDA 下对称 K4V4 同样正常（本篇实测 32K=59.1 / 64K=44.4 t/s）。q8v4（K=Q8+V=Q4）混合类型回退 CPU 是 llama.cpp 通病，AMD Vulkan 后端同样不应混用。

八、踩坑与经验

MTP 参数名：--spec-type draft-mtp，写旧名 mtp 直接启动失败（日志里一句 spec 相关行都没有就是没启用）；n-max 2 是 Blackwell 甜点位，n≥3 验证开销追上接受率收益。
Unsloth Desktop 自动参数直接可用：0.1.801 生成的 flash-attn / kv-unified / no-context-shift / fit off 组合在 32GB 卡上开箱即稳，本次唯一手改就是 MTP 两行。桌面端小白流和手搓 systemd 流殊途同归。
2 槽位 × 150K 的显存红线 ≈29GB：再往上（200K 或 3 槽位）就吃紧。优先 q8_0（--cache-type-k q8_0 --cache-type-v q8_0，质量几乎无损，省 ~3.6GB）；q4_0（K4V4）不建议（8.3% 输出相似度质量悬崖 + CPU 回退风险）。
req4 的 10.8 t/s 是离群点：380 秒跑 4096 token，量级对应 GSP 看门狗心跳窗口 + 2 槽位争抢，不作外推依据；遇到单次掉速先看 journalctl 有没有 NVRM/Xid 行，有就是上篇那个 bug，没有就是槽位争抢。
稳定性预期管理：本篇 08-21 13:45 启动、0 崩溃、稳定 2 小时——但 GSP 固件 bug（Xid 62/154/79 或静默硬挂，需断电恢复）没修，无人值守批量推理必须挂看门狗 + 断电恢复（或留请求间隔 / 关 GSP），详见上篇根因章节。
接受率是内容函数不是配置函数：JSON/代码类结构化输出接受率 93%+，自由文本 63% 上下。如果你的 agent 负载以结构化为主，MTP 收益只会比本篇更高。
K/V cache 必须对称（重要）：llama.cpp 的 flash attention 不支持 K/V 混合类型（如 K=Q8_0+V=Q4_0），会整体回退到 CPU（GPU 利用率 0-25%、CPU 8 核满载、32K 速度暴跌 4 倍）。对称组合 K4V4（Q4+Q4）和 q8_0（Q8+Q8）都正常。切换 KV 量化后务必跑 32K/64K 长上下文验证（短 ctx 测不出来）。

九、KV 量化质量对比与下一步

质量影响（网测数据）

InventiveHQ 在同模型上做了 f16 / q8_0 / q4_0 KV cache 直接对比（8K 上下文）：

KV 类型	输出相似度（vs f16）	评价
f16（基准）	100%	—
q8_0	81.6%	安全交易，质量损失可控
q4_0	8.3%	质量悬崖，回答完全不同

Particula.tech 补充：Qwen 系列在 q8_0 下 KL 散度 < 0.04（极低），q4_0 损失真实且模型相关。来源：InventiveHQ / Particula

对本模型的特殊考虑：Qwen3.8-27B 只有 16/65 层存 KV（48 层线性注意力是 fp32 无损状态），质量影响理论上比同参数纯 Transformer 小得多。

社区实际使用反馈：有用户在 7900XTX 24G 上用 K4V4（Q4_0 KV）跑满 256K 上下文做代码生成，评价"质量不比在线 API 差"（topic/100）。这与 InventiveHQ 的 8.3% 相似度数据存在张力——可能的原因：(1) 8.3% 是文本相似度指标，捕捉到了措辞/表述差异，但代码功能正确性不受影响；(2) Qwen3.6-27B 与 Qwen3.8-27B 架构不同，质量衰减可能不同；(3) 主观感受难以捕捉长上下文末尾的细微召回丢失。结论：K4V4 对代码生成可能"够用"，但对长文档精确召回（如 needle-in-haystack）仍有风险，q8_0 是更稳妥的选择。

q8_0（K=Q8, V=Q8）分析（q8v4 已弃用）

q8_0 全量 8bit KV：每 token 34KB（vs f16 64KB / q4_0 18KB）。曾试过 q8v4（K=Q8+V=Q4）不对称方案，但 llama.cpp 的 flash attention 不支持 K/V 混合类型，整体回退 CPU（GPU 0-25%、CPU 8 核满载、32K 崩到 15.8 t/s），不可用。对称组合都正常：K4V4（Q4+Q4）32K=59.1 / 64K=44.4 t/s，q8_0（Q8+Q8）32K=68.4 t/s。

方案	每 token KV	150K 池	总显存	余量
f16（现状）	64KB	9.9GB	~29GB	~3GB
q8_0（已上线）	34KB	5.4GB	~25.4 GB（实测）	~6.6 GB
q4_0（K4V4）	18KB	2.8GB	~21.8GB	~10.2GB

为什么不推荐 q8v4 不对称方案：理论上 Key 用 Q8 保留注意力模式精度、Value 用 Q4 省显存很诱人，但 llama.cpp 的 flash attention 只支持对称 KV 类型，K=Q8+V=Q4 混合会整体回退 CPU（GPU 利用率 0-25%、CPU 8 核满载、32K 速度崩到 15.8 t/s），实际不可用。K/V 类型必须对称（K4V4 或 q8_0 均可，速度都正常）。

（补充：q8v4 在非 Unsloth 配置下崩过，但归因是 GSP 固件 bug 的负载模式触发，与量化格式无因果。）

下一步建议

日常已切换 q8_0（K=Q8_0 + V=Q8_0）：VRAM ~25.4GB / 余量 ~6.6GB / 32K 上下文 68.4 t/s，标准版与免审查版均已生效。
需要省显存时首选 q8_0（--cache-type-k q8_0 --cache-type-v q8_0），质量几乎无损，多 ~4.7GB 余量，够冲 200K 或第 3 槽位。
q8v4 已弃用：K/V 混合类型（Q8+Q4）触发 CPU 回退（GPU 闲置、CPU 满载、速度暴跌 4 倍），不要用；K/V 类型保持对称（K4V4 或 q8_0）。
q4_0（K4V4）仅在"塞不下"时考虑：8.3% 输出相似度是质量悬崖，即使本模型有 16 层优势也不建议轻易尝试。
待验证：q8_0 日常使用质量观察；n-max 3 在 2 槽位下的接受率/速度拐点（DFlash2 已实测淘汰）；GSP 修复（等 NVIDIA）后再谈 200K+。

数据来源：systemd journalctl（MTP 接受率 195 次请求全量）+ 高 ctx 压测脚本 + 长上下文 CPU 回退验证；模型参数来自官方 config.json 与 GGUF 头部元数据双重核对。

清

平台：Linux（Ubuntu）/ llama.cpp b10488 / NVIDIA RTX PRO 4500 Blackwell 32GB
模型：Qwen3.8-27B-UD-Q4_K_XL（Unsloth Dynamic v3.0，17.92GB）
用途：Hermes Agent 后端主力模型
日期：2026-08-20（含 1 小时压力测试 + 社区崩溃根因调研）

一、先说结论

32GB Blackwell 卡跑 Qwen3.8-27B UD-Q4_K_XL，128K 上下文 + MTP 投机解码，稳定可用。
性能：正文吐词 67 t/s（1 小时压测 avg_tps=67.2）。
崩溃根因已定位：不是量化问题、不是 llama.cpp 问题——是 NVIDIA Blackwell GSP 固件已知 bug（GB202 die 通病），社区多卡实证。
128K 上下文是工程折中：200K 实测 59 分钟崩溃，128K 有长期零崩记录。降 ctx 缩短 kernel 耗时→降低 GSP watchdog 触发概率，非根因修复。
根因修复等 NVIDIA：上游已跟踪（NVIDIA/open-gpu-kernel-modules #1080、#1111），无公开 ETA。595-open 是当前唯一可用驱动路径。

二、硬件 / 软件环境

项	配置
显卡	NVIDIA RTX PRO 4500 Blackwell，32 GB（32623 MiB），sm_120，GB202 die
CPU	AMD Ryzen 7 3700X（8C/16T）
内存	60 GB
系统	Ubuntu（Linux 7.0.0-29-generic）
推理框架	llama.cpp b10488（源码编译，CUDA 12.8+）
驱动	nvidia-open 595.91.07
服务方式	systemd 用户服务，8000 端口互斥，llm-switch.sh 一键切换

三、模型来源

项	值
仓库	`unsloth/Qwen3.8-27B-GGUF`
文件	`Qwen3.8-27B-UD-Q4_K_XL.gguf`（17.92 GB，4.97 BPW）
量化	Unsloth Dynamic v3.0，Q4_K 混合精度（359×Q4_K + 96×Q5_K + 43×Q6_K + 353×F32）
视觉塔	`mmproj-F16.gguf`（885 MB）
特点	kingy.ai 首推量化源，同精度比其它 Q4 高 10%+；BPW 4.97（比 Q4_K_M 的 4.84 略高）

通过 hf download 直连 HuggingFace 下载，SHA256 校验通过。

四、部署配置

systemd 用户服务 ~/.config/systemd/user/llama-qwen-27B.service：

[Unit]
Description=llama.cpp Qwen3.8-27B UD-Q4_K_XL Service (128K, effort=medium, MTP n-max 2)

[Service]
ExecStart=%h/llama.cpp/build/bin/llama-server \
  -m %h/models/Qwen3.8-27B/Qwen3.8-27B-UD-Q4_K_XL.gguf \
  --mmproj %h/models/Qwen3.8-27B/mmproj-F16.gguf \
  --alias qwen3.8-27B \
  --host 127.0.0.1 --port 8000 \
  --ctx-size 131072 \
  --n-gpu-layers 99 \
  --flash-attn on \
  --parallel 1 \
  --jinja \
  --no-mmap \
  --ubatch-size 512 \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --cache-ram 32768 \
  --chat-template-kwargs '{"reasoning_effort": "medium", "preserve_thinking": true}' \
  --reasoning-preserve \
  --temp 0.6 --top-k 20 --top-p 0.95 --min-p 0.0 \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

Environment=CUDA_VISIBLE_DEVICES=0
Restart=on-failure
RestartSec=10

管理命令：

systemctl --user start llama-qwen-27B    # 启动
systemctl --user stop llama-qwen-27B     # 停止
systemctl --user status llama-qwen-27B   # 查看状态
journalctl --user -u llama-qwen-27B -f   # 实时日志

五、1 小时压力测试结果

测试配置

项	值
模型	Qwen3.8-27B-UD-Q4_K_XL（标准版）
上下文	200K（204800），MTP n-max 2，K4V4 KV cache
压测方式	每轮 512 token 生成，连续 60 分钟，守护进程独立运行
总 token	226,816

结果

指标	值
总轮数	446
成功	443
失败	3（均为第 444 轮崩溃后的连接拒绝，实为 1 次崩溃事件）
平均 t/s	67.2
最低 t/s	10.3（崩溃窗口期）
最高 t/s	74.2
崩溃时间	第 444 轮（约 18:38:42，59 分钟处）

崩溃现场

18:38:42 NVRM: krcWatchdog_IMPL: RC watchdog: GPU is probably locked! Notify Timeout Seconds: 7
18:38:42 NVRM: Xid (PCI:0000:09:00): 8, pid=25546, name=llama-server, channel 0x00000012
18:38:42 CUDA error: the launch timed out and was terminated
18:38:45 systemd: llama-qwen-27B.service: Main process exited, code=dumped, status=6/ABRT

崩溃后 systemd 自动拉起新进程，服务自动恢复。

六、崩溃根因：Blackwell GSP 固件 Bug

这不是什么

不是量化模型的问题（Q4_K_M、UD-Q4_K_XL、Q4_K_P 均崩）
不是 llama.cpp 的 bug（b8679 之前/之后均有报告）
不是驱动版本问题（580/590/595 均复现）
不是散热/供电问题（室温 28°C、1600W 铂金电源均有人复现）

这是什么

NVIDIA Blackwell 架构（GB202 die）的 GSP 固件心跳超时 bug。GSP（GPU System Processor）是 Blackwell 上强制启用的固件处理器，在持续高负载下会心跳超时死锁，导致 GPU 进入不可恢复状态。

社区证据

来源	GPU	工作负载	结果
NVIDIA/open-gpu-kernel-modules #1080	RTX 5090 (GB202)	Vulkan 游戏	GSP heartbeat timeout → Xid 8，与我们完全一致
NVIDIA/open-gpu-kernel-modules #1111	RTX PRO 6000 (GB202, sm_120)	llama.cpp 持续推理	45 分钟必崩；同机 RTX 3090（sm_86）跑 20+ 小时零崩
NVIDIA/open-gpu-kernel-modules #1247	RTX 5060 Ti (Blackwell)	Ollama/llama.cpp	CUDA 分配时硬锁
NVIDIA Forums #371272	RTX 5080 (Blackwell)	高上下文 LLM 推理	Xid 62 GSP Watchdog Timeout
gengchaogit/blackwell-xid-wpr2-gsp-crash-recovery	多款 Blackwell	通用	专门为此 bug 写的恢复脚本

关键对比（#1111 报告者）：同机 RTX PRO 6000 Blackwell + RTX 3090×2，跑相同 llama.cpp 持续推理——Blackwell 45 分钟必崩，Ampere（sm_86）20+ 小时零崩。确认是 Blackwell 特有。

崩溃链

decode kernel 执行（随上下文长度增长）
    ↓ 超过 ~7 秒
GSP watchdog 判定 GPU 锁死
    ↓
krcWatchdog_IMPL: RC watchdog: GPU is probably locked!
    ↓
Xid 8（launch timeout）→ CUDA error: the launch timed out
    ↓
驱动尝试恢复 → WPR2 安全区无法清除 → 恢复失败
    ↓
GPU 死锁，需要重启/Secondary Bus Reset

为什么不同量化源崩溃频率不同

权重分布 → CUDA kernel 执行时间不同 → 超 7 秒看门狗阈值的概率不同：

UD-Q4_K_XL 更稳定：权重分布让 kernel 执行时间更短，更不容易触发阈值
Q4_K_P 更频繁：权重分布导致 kernel 执行时间更接近阈值
128K 比 200K 更稳定：上下文更短→KV cache 更小→kernel 耗时更短

上游状态

NVIDIA 内部已跟踪（#1080 标记为 Open，#1111 标记为 Bug）
580-open / 595-open 是当前唯一可用驱动路径（Blackwell 不支持闭源驱动）
恢复路径在 Blackwell 上根本性损坏（WPR2 安全区无法清除）
无公开修复 ETA

七、为何选择 128K 上下文

背景

Qwen3.8-27B 模型支持 256K 上下文，最初我们也想用 200K（实用性与显存的平衡点）。但实测发现：

配置	压测结果
256K + MTP	08-19 凌晨连崩 2 次（6万/11万 token 处）
200K + MTP	1 小时压测 59 分钟崩 1 次（22万 token 处）
128K + MTP	长期使用零崩（08-18/19 已验证）

原理

GSP 固件 bug 的触发条件是任何单次 CUDA kernel 超过 ~7 秒。上下文越长→KV cache 越大→attention kernel 扫描的数据量越多→执行时间越长→越容易超 7 秒阈值。

降 ctx 不是根因修复（阈值不固定，6万 token 处也曾崩过），但能把概率压到工程可接受水平。

关 MTP 的考量

MTP（Multi-Token Prediction）通过扩大单步 batch（draft n=2）提升吞吐，但也增大了 kernel 负载。关 MTP 可进一步降低崩溃概率，但代价：

配置	预估 t/s
128K + MTP n-max 2	~67 t/s（已验证）
128K + 无 MTP	~30 t/s（推算，未实测）
256K + 无 MTP	~25 t/s（推算，未验证零崩）

最终选择 128K + MTP：性能与稳定性的工程最优解。等 NVIDIA 修 GSP 固件后再考虑升 ctx。

八、踩坑与经验

MTP 参数名：--spec-type draft-mtp（旧名 mtp 会启动失败），--spec-draft-n-max 2（推荐值，n=3+ 在 Blackwell 上收益递减）。
KV cache 用 Q4：--cache-type-k q4_0 --cache-type-v q4_0，128K 上下文 KV 约 32GB RAM（--cache-ram 32768），显著降低显存占用。
--no-mmap：Blackwell 上 mmap 有兼容性问题，关掉更稳。
--flash-attn on：必须开启，关闭后 kernel 执行时间更长，更容易触发 GSP watchdog。
崩溃后自动恢复：systemd Restart=on-failure + RestartSec=10，崩溃后 10 秒自动拉起。实际影响仅当轮请求丢失。
量化源选择：UD-Q4_K_XL（Unsloth Dynamic）在 Blackwell 上比其它 Q4 量化源更稳定——不是量化质量差异，是权重分布→kernel timing 差异。
Blackwell GSP bug 通用性：RTX 5090/5080/5070/5060Ti/PRO 6000/PRO 4500 均受影响（同一 GB202/G200 die），不是个例。社区已有恢复脚本（sbr_recover.sh）但需要 root 权限。

清

本地双 Qwen3.8-27B 部署实测：vLLM vs llama.cpp 全路径踩坑实录

平台：Linux（Ubuntu 26.04 LTS）/ RTX PRO 4500 Blackwell 32GB / systemd 用户服务
日期：2026-08-19（模型 8-14 发布后 5 天，含 vLLM + llama.cpp 双框架全路径实测）

一、结论

硬件环境下的模型选型铁律

模型类型	推荐框架	理由
MoE 模型（A3B）	vLLM + MTP	显存充裕，MTP 稳定，速度快（144 t/s）
Dense 模型（27B）	llama.cpp（无 MTP）	显存贴边，MTP 在 Blackwell 上必崩

27B dense 模型在本机的最终定案

vLLM 路线已废弃：32GB 卡跑 NVFP4 显存贴边（22GB 权重 + 811MB MTP head），CUDA graphs 开不了（需额外 800MB），只能 enforce-eager，速度 ~20 t/s
llama.cpp 路线是唯一稳定选择：256K context + 无 MTP，速度 ~24.5 t/s，零崩溃
MTP 在 Blackwell sm_120 上是崩溃根源：实测 128K/256K × mmproj 有无全组合，decode 阶段必崩（CUDA launch timed out，ggml-cuda.cu:106），升级到最新 llama.cpp 9731ad3 仍崩

本机现役三服务架构

vllm-qwen-A3B.service      → Qwen3.6-35B-A3B NVFP4 (200K, ~144 t/s)
llama-qwen-27B.service     → Qwen3.8-27B Q5_K_M (256K, ~24.5 t/s)
llama-qwen-27B-uc.service  → Qwen3.8-27B-Uncensored Q5_K_M (256K, ~24.5 t/s)

二、硬件 / 软件环境

项	配置
显卡	NVIDIA RTX PRO 4500 Blackwell，32 GB（sm_120），驱动 595.91.07
CUDA	13.1（nvcc）/ 13.2（驱动最大支持）/ PyTorch CUDA 13.0
CPU	AMD Ryzen 7 3700X（8C/16T）
内存	60 GB
系统	Ubuntu 26.04 LTS
推理框架	llama.cpp 源码编译（ggml 0.20.2，commit 98d1e92）+ vLLM 0.26.0
服务方式	systemd 用户服务（`systemctl --user`），8000 端口互斥

三、模型来源

1. 官方原版 Qwen3.8-27B（默认主力）

仓库：https://huggingface.co/unsloth/Qwen3.8-27B-GGUF
底模：https://huggingface.co/Qwen/Qwen3.8-27B（官方，27.78B dense 混合注意力，64 层 = 48 Gated DeltaNet + 16 full-attn，262144 原生上下文，Apache 2.0）
文件：Qwen3.8-27B-Q5_K_M.gguf（19.8GB）+ mmproj-F16.gguf（885MB）

2. 去拒答版 Qwen3.8-27B-Uncensored

仓库：https://huggingface.co/JonathanColetti/Qwen3.8-27B-Uncensored-GGUF
加工：JonathanColetti 做 abliteration（正交化消解除拒答方向），拒答率 98/100 → 12/100
文件：Qwen3.8-27B-Uncensored-Q5_K_M.gguf（19.5GB）+ Qwen3.8-27B-Uncensored-vision-f16.gguf（885MB）

3. vLLM 版本（已废弃）

仓库：https://huggingface.co/unsloth/Qwen3.8-27B-NVFP4（22GB）
32GB 卡实测上限 100K context，CUDA graphs 不可用

四、vLLM 路线实测（已废弃）

部署参数

vllm serve ~/models/Qwen3.8-27B-NVFP4 \
  --served-model-name qwen3.8-27b \
  --tensor-parallel-size 1 \
  --max-model-len 100000 \
  --gpu-memory-utilization 0.90 \
  --kv-cache-dtype fp8 \
  --enforce-eager \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}' \
  --reasoning-parser qwen3 \
  --host 127.0.0.1 --port 8000

失败原因

尝试	结果
max-model-len=131072 (128K)	KV cache 需 4.57GB，仅 3.9GB 可用 → OOM
max-model-len=110000	KV cache 需 3.9GB，可用 3.69GB → OOM
max-model-len=100000	成功启动，可用 3.69GB KV cache
CUDA graphs 开启	模型占 29.7GB，CUDA graphs 需额外 800MB → OOM
FlashInfer + enforce-eager	速度反而降到 13.7 tok/s

最终速度

吐词速度：~20 tok/s（enforce-eager 模式）
对比 llama.cpp：24.5 t/s（无 MTP）→ vLLM 反而更慢

结论

32GB 单卡跑 27B NVFP4 显存贴边，vLLM 的 MTP + CUDA graphs 优势完全发挥不出来。vLLM 适合 MoE 模型（A3B），不适合 dense 模型（27B）。

五、llama.cpp 路线实测（稳定方案）

部署参数

llama-server \
  -m ~/models/Qwen3.8-27B/Qwen3.8-27B-Q5_K_M.gguf \
  --mmproj ~/models/Qwen3.8-27B/mmproj-F16.gguf \
  --alias Qwen3.8-27B \
  --host 127.0.0.1 --port 8000 \
  --ctx-size 262144 \
  --n-gpu-layers 99 \
  --flash-attn on \
  --parallel 1 \
  --jinja \
  --no-mmap \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --chat-template-kwargs '{"reasoning_effort":"medium","preserve_thinking":true}' \
  --reasoning-preserve \
  --spec-type none \
  --temp 1.0 --top-k 20 --top-p 0.95

实测结果

场景	速度
短输出（<1K token）	~37 t/s
中等输出（1K-10K token）	~30 t/s
长输出（10K+ token）	~24.5 t/s
100K 预填 + 6000 token 长生成	零崩溃

显存占用

项	占用
Q5_K_M 权重	19.8GB
mmproj	885MB
256K ctx q4 KV	~5GB
总计	~26GB / 32GB

256K context 的关键

KV cache 全 4bit（--cache-type-k/v q4_0）是 32GB 卡跑 256K 的唯一正解。换成 fp8/fp16 直接放不下。

六、MTP 在 Blackwell 上的崩溃分析

崩溃现象

CUDA error: the launch timed out and was terminated（ggml-cuda.cu:106）
崩溃点随机：366/771/2346/3208/5904 token（非上下文满导致）
128K/256K × mmproj 有无全组合实测全部崩溃

已知 Blackwell + MTP 的 bug

Issue #24399：mul_mat_q<Q8_0,128> 在 Blackwell 上 shared-memory out-of-range 崩溃
CUDA 13.2 乱码：Reddit 警告不要用 CUDA 13.2 编译 llama.cpp
MTP × hybrid-GDN crash class (#50021)：RTX 5090 上 NVFP4 和 W4A8 都崩
nvcc 编译器 bug：Blackwell SM_120 MMQ kernels at -O3 生成错误机器码

为什么 vLLM 的 MTP 能跑

vLLM 的 MTP 实现路径与 llama.cpp 不同，避开了上述 CUDA kernel bug。但 32GB 卡显存不够，只能 enforce-eager 模式，速度优势被抵消。

七、踩坑与经验

必须知道的

--jinja 必须加：3.8 官方 jinja 模板会把空 thinking 块包进输出，破坏多轮 agent 会话
过思考是 3.8 的祖传毛病：用 reasoning_effort=medium 压住，medium 下实际思考量很小
256K 是 32GB 卡的极限：288K 超预算（总显存 30GB 封顶，留 ~4GB 给桌面）
256K vs 128K 速度无差别：速度只与实际上下文长度相关，与档位无关（1K-12K 负载 tg≈37 持平）

MTP 相关

Blackwell 上 MTP 必崩：与驱动版本无关（595.91.07 不救 MTP），与 llama.cpp 版本也无关
MTP acceptance rate 低：实测仅 45%（社区正常 80%+），Blackwell 上收益有限
关 MTP 正确参数：--spec-type none（新版无 --no-speculative）

下载验证

字节级核验：HF 仓库 ?blobs=true 拿每个文件 size，与本地 stat 对比
别下错版本：同名量化可能差几百万字节（带不带 MTP、带不带 vision）

服务管理

切模型 = 切服务：8000 端口互斥，切换前先停另一个
全部 disabled：按需手动 start，不开机自启

八、接入 Agent 的方式

llama.cpp 自带 /v1/chat/completions，标准 OpenAI 协议。

# 文本测试
curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen3.8-27B","messages":[{"role":"user","content":"Hello"}],"max_tokens":128}'

# 视觉测试（base64 内联）
curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen3.8-27B","max_tokens":500,
       "messages":[{"role":"user","content":[
         {"type":"image_url","image_url":{"url":"data:image/png;base64,..."}},
         {"type":"text","text":"描述这张图"}
       ]}]}'

九、总结

一句话：dense 27B 质量换速度（llama.cpp，24.5 t/s，无 MTP），MoE A3B 速度换质量（vLLM，144 t/s，MTP 稳定），同机器双方案按场景切。

Blackwell sm_120 的现实：

llama.cpp MTP 有已知崩溃 bug，短期内无法修复
vLLM MTP 能跑但显存不够，32GB 卡只能 enforce-eager
速度最优解是 MoE 模型（A3B）+ vLLM + MTP

如果要速度：用 A3B（144 t/s）
如果要质量：用 27B 无 MTP（24.5 t/s）
如果两个都要：同机器双服务，按需切换

清

本地跑双 Qwen3.8-27B 实践实录：官方原版 + 去拒答版，200K 上下文全量部署与实测数据

平台：Linux（Ubuntu 26.04 LTS）/ llama.cpp 源码编译 / systemd 用户服务
用途：本地多模态 LLM（文字 + 视觉），日常 Hermes Agent 主模型
日期：2026-08-18（模型 8-14 发布后 4 天内的完整实践）

一、先说结论

截图 2026-08-18 17-01-13.png

一台 32GB 显存卡可以同时把 Qwen3.8-27B 官方原版和社区去拒答版都部署起来跑 200K 上下文，全 GPU 加载，KV cache 4bit，每个服务实测占用约 25 GB 显存，32GB 卡还有 6GB 余量。
实测吐词：API 端到端 58-60 t/s（含思考 token 计数）；长续写工作负载 46-51 t/s；短输出配合 MTP 投机解码能冲到 83 t/s（draft 接受率 0.995）。
视觉可用：一张真实截图发进去，4.5 秒内带思考返回，描述基本准确。
最大坑在官方 chat template 会把空的 thinking 块嵌进多轮对话，禁 multi-turn agent——必须 --jinja 覆盖；另一个坑是 3.8 系过思考，用 reasoning_effort=medium 压住。

二、硬件 / 软件环境

项	配置
显卡	NVIDIA RTX PRO 4500 Blackwell，32 GB（实测 32623 MiB），驱动 595.84
CPU	AMD Ryzen 7 3700X（8C/16T）
内存	60 GB
系统	Ubuntu 26.04 LTS
推理框架	llama.cpp 源码编译（0.1.0-dev，build 1，commit 6509138，GCC 13.4.0）
服务方式	systemd 用户服务（`systemctl --user`），8000 端口互斥

三、模型来源（两个 27B 分别来自哪）

Qwen 官方只发布 BF16 / FP8 权重，没有官方 GGUF，本地 GGUF 一律第三方转换。我实测字节级比对（本地文件 size 与 HF 仓库完全一致）确认了两份来源：

1. 官方原版 Qwen3.8-27B（默认主力，llama.cpp Q5_K_M）

仓库：https://huggingface.co/unsloth/Qwen3.8-27B-GGUF
底模：https://huggingface.co/Qwen/Qwen3.8-27B（官方，8-14 发布，27.78B dense 混合注意力 VLM，262144 原生上下文，Apache 2.0）
文件：Qwen3.8-27B-Q5_K_M.gguf（19,834,055,648 B）+ mmproj-F16.gguf（927,607,488 B）

2. 去拒答版 Qwen3.8-27B-Uncensored（低拒版，专职"有问必答"）

仓库：https://huggingface.co/JonathanColetti/Qwen3.8-27B-Uncensored-GGUF
加工：JonathanColetti 做 abliteration（正交化消解除拒答方向），拒答率 98/100 → 12/100，四种基准均值仅掉 0.5 分（噪声级），保留 MTP 投机解码头
文件：Qwen3.8-27B-Uncensored-Q5_K_M.gguf（19,535,701,408 B）+ Qwen3.8-27B-Uncensored-vision-f16.gguf（927,606,912 B）
️ 注意别下错：Reddit 上推的 vcruz305/Qwen3.8-27B-AEON-ULTIMATE-UNCENSORED-GGUF（AEON 系）是 --no-mtp，不带 MTP 头，同类 Q5_K_M 只有 19,231,099,968 B，明显小一截。要 MTP 提数选 JonathanColetti 版。

四、部署步骤（llama.cpp 源码 + systemd 服务）

1. 编译 llama.cpp

llama.cpp 需要足够新的版本才认识 qwen35 架构，建议直接源码编最新：

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j$(nproc)

2. 下载模型（HF 直连，直接落到最终目录）

hf download unsloth/Qwen3.8-27B-GGUF --local-dir ~/models/Qwen3.8-27B \
  --include "Qwen3.8-27B-Q5_K_M.gguf" "mmproj-F16.gguf"
hf download JonathanColetti/Qwen3.8-27B-Uncensored-GGUF \
  --local-dir ~/models/Qwen3.8-27B-Uncensored \
  --include "Qwen3.8-27B-Uncensored-Q5_K_M.gguf" "Qwen3.8-27B-Uncensored-vision-f16.gguf"

3. systemd 用户服务（两个服务参数完全一致，仅模型路径不同）

~/.config/systemd/user/llama-qwen-27B.service：

[Unit]
Description=llama.cpp Qwen3.8-27B Q5_K_M Service (200K, effort=medium)

[Service]
ExecStart=%h/llama.cpp/build/bin/llama-server \
  -m %h/models/Qwen3.8-27B/Qwen3.8-27B-Q5_K_M.gguf \
  --mmproj %h/models/Qwen3.8-27B/mmproj-F16.gguf \
  --alias Qwen3.8-27B \
  --host 127.0.0.1 \
  --port 8000 \
  --ctx-size 200000 \
  --n-gpu-layers 99 \
  --flash-attn on \
  --parallel 1 \
  --jinja \
  --no-mmap \
  --ubatch-size 512 \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --cache-ram 32768 \
  --chat-template-kwargs '{"reasoning_effort": "medium", "preserve_thinking": true}' \
  --reasoning-preserve \
  --temp 1.0 \
  --top-k 20 \
  --top-p 0.95 \
  --min-p 0.0 \
  --spec-type draft-mtp \
  --spec-draft-n-max 2
Environment=CUDA_VISIBLE_DEVICES=0
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=default.target

启用高开一体，服务管理：

systemctl --user daemon-reload
systemctl --user enable --now llama-qwen-27B.service     # 官方版
systemctl --user enable --now llama-qwen-27B-uc.service  # 去拒答版（同参数改模型路径）
# 端口 8000 互斥：开一个前先停另一个
systemctl --user start/stop/restart llama-qwen-27B.service

五、实测结果（均为本机真实跑出的数字）

吐词速度（llama-server 日志 + API 客户端实测）

场景	数据	说明
API 端到端（纯解码 300 token 全吐出）	60.1 t/s，TTFT 0.28s	httpx 客户端计时，含网络开销
API 端到端（带思考问答）	58.8 t/s，TTFT 0.16s	思考 279 token + 正文 189 token
长续写工作负载（n_gen 418→1861 持续生成）	tg 46-51 t/s	真实 agent 会话下的稳速
短输出 + MTP 高命中	83.4 t/s	draft acceptance 0.995，mean len 2.99

MTP 投机解码统计（journal `draft acceptance`）

长上下文会话：acceptance 0.615，mean len 2.23
一般任务：acceptance 0.65 ~ 0.995，mean len 2.3 ~ 2.99
结论：MTP 在长输出/低重复性文本收益浮动，短输出命中很高，白捡速度，显存代价可忽略，建议一直开着。

视觉（多模态）实测

输入真实截图（PNG, ~718 prompt token）+ 提问"描述这张截图"
返回：4.5 秒，其中思考 107 token，正文准确描述了页面是各模型 API 请求配额表格（Grok/GPT/GLM/Kimi/Qwen/DeepSeek 各周期次数）
结论：vision 走 --mmproj/vision-f16 正常，识别准确度够用

显存占用（32GB 卡）

项	占用
llama-server（Q5_K_M 19.5GB 权重 + mmproj + 200K ctx q4 KV）	25,318 MiB ≈ 24.7 GB
全卡总占用	26.0 / 32 GB（其余为桌面等）
剩余余量	~6 GB

200K 上下文能塞进 32GB 的三个关键：KV cache 全 4bit（--cache-type-k/v q4_0）、全 GPU offload（-ngl 99）、--no-mmap 避免大文件映射把内存和随机 IO 拉爆。KV 换成 fp16 的话 200K 直接放不下。

与 A3B（MoE）的参照对比

同机还部署了 Qwen3.6-35B-A3B（vLLM NVFP4，MoE 3B 激活）作对照：

指标	Qwen3.8-27B (dense)	Qwen3.6-35B-A3B (MoE)
纯解码	46-60 t/s	144 t/s
往返延迟（纯文本问答）	TTFT ~0.2s	1.2s
定位	dense 全参，编码/深度推理/长文写作更强	速度翻倍余，工具调用/Hermes agent 首选

一句话：dense 质量换速度，MoE 速度换质量，同机器双方案按场景切。

六、踩坑与经验（给后面的人）

必须 --jinja：3.8 官方 jinja 模板会把空的 thinking 块包进输出，直接破坏多轮 agent 会话（llama.cpp 下实测）。GGUF 包里若烤了固定模板也要用 --jinja。
过思考是 3.8 的祖传毛病：简单 prompt 都能吐几千 token 思考（Reddit 上戏称"史上最 overthinking"）。用 --chat-template-kwargs '{"reasoning_effort": "medium"}' + --reasoning-preserve 可控档，medium 下实际思考量很小。
官方 benchmark 别全信：SWE-bench Pro 61.7 之类是 Qwen 自报（且对比项直接复用别家成绩），发布当天没有独立复现。release 当天 Reddit 实测反馈一致好评（双 5080 Q6 能到 100 t/s、2080Ti 22GB Q8 也能 40 t/s），本机体验同样"明显强于 3.6-27B"——但"强"是有依据的主观体验，不是官方数字背书。
量化选 Q5_K_M 是甜点：Q4 能用、Q5 几乎无损、Q6/Q8 32GB 全 offload 放不下（Q8 是 26.63 GB + KV 直接爆卡）。14 层 hybrid attention 的 KV 天然小，配合 4bit KV 是 32GB 卡跑 200K 的唯一正解。
下载后务必字节级核验：HF 仓库 ?blobs=true 拿每个文件 size，与本地 stat 对比。不同仓库同名量化可能差几百万字节（带不带 MTP、带不带 vision），网上吹的"best one"未必是你要下的那个。
切模型 = 切服务：8000 端口互斥，切换脚本负责停旧起新，不要把服务常驻两个。

七、接入 agent 的方式（OpenAI 兼容）

llama.cpp 自带 /v1/chat/completions，标准 OpenAI 协议，视觉直接 image_url base64。接入任何 agent 框架只需把 base URL 指到 http://127.0.0.1:8000/v1：

# 视觉测试（base64 内联）
curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen3.8-27B","max_tokens":500,
       "messages":[{"role":"user","content":[{"type":"image_url","image_url":{"url":"data:image/png;base64,..."}},
       {"type":"text","text":"描述这张图"}]}]}'

帖子里的所有速度、显存、延迟、MTP 统计均为本机（8-18）实测；模型来源均做过字节级比对。硬要说缺点：dense 27B 的算力开销比同机 MoE 大，长 agent 会话的思考 token 消耗要心里有数——这也是很多人对 3.8 的真实槽点。

以上部署实测均由hermes调用opencodego套餐模型deepseek-v4-flash负责，本人只负责在旁边喝茶，静静地看着就行了。所以有问题也别问我，问你机器上的hermes或deepseek harness！

抡锤者

清风明月

帖子

RTX PRO 4500 32G 跑 Qwen3.8-27B：Unsloth Desktop 默认参数 + MTP，2 槽位 × 150K，短上下文 54–64 t/s（GSP 篇续集，附完整配置）

一、先说结论

二、模型参数卡（官方 config.json × GGUF 头双重核对）

三、硬件 / 软件环境

四、完整配置（可直接复制）

关键参数说明

五、实测数据

5.1 短上下文（日常交互，2026-08-21 14:33–14:36）

5.2 高上下文压测（~71K ctx 填充 + 4096 生成，2026-08-21 13:14–13:30）

5.3 MTP 接受率（全天 195 次请求）

5.4 上下文衰减阶梯（8K–128K，2026-08-21 补测）

5.5 q8_0 KV 量化实测（2026-08-21 切换后）

5.6 DFlash2 块扩散投机解码对比实测（2026-08-21）

六、MTP 加速账：从接受率到 2.2×

七、社区跨卡对照（同模型 Qwen3.8-27B，均为本版论坛实测帖）

八、踩坑与经验

九、KV 量化质量对比与下一步

质量影响（网测数据）

q8_0（K=Q8, V=Q8）分析（q8v4 已弃用）

下一步建议

一、先说结论

二、硬件 / 软件环境

三、模型来源

四、部署配置

五、1 小时压力测试结果

测试配置

结果

崩溃现场

六、崩溃根因：Blackwell GSP 固件 Bug

这不是什么

这是什么

社区证据

崩溃链

为什么不同量化源崩溃频率不同

上游状态

七、为何选择 128K 上下文

背景

原理

关 MTP 的考量

八、踩坑与经验

本地双 Qwen3.8-27B 部署实测：vLLM vs llama.cpp 全路径踩坑实录

一、结论

硬件环境下的模型选型铁律

27B dense 模型在本机的最终定案

本机现役三服务架构

二、硬件 / 软件环境

三、模型来源

1. 官方原版 Qwen3.8-27B（默认主力）

2. 去拒答版 Qwen3.8-27B-Uncensored

3. vLLM 版本（已废弃）

四、vLLM 路线实测（已废弃）

部署参数

失败原因

最终速度

结论

五、llama.cpp 路线实测（稳定方案）

部署参数

实测结果

显存占用

256K context 的关键

六、MTP 在 Blackwell 上的崩溃分析

崩溃现象

已知 Blackwell + MTP 的 bug

为什么 vLLM 的 MTP 能跑

七、踩坑与经验

必须知道的

MTP 相关

下载验证

服务管理

八、接入 Agent 的方式

九、总结

本地跑双 Qwen3.8-27B 实践实录：官方原版 + 去拒答版，200K 上下文全量部署与实测数据

一、先说结论

二、硬件 / 软件环境

三、模型来源（两个 27B 分别来自哪）

1. 官方原版 Qwen3.8-27B（默认主力，llama.cpp Q5_K_M）

2. 去拒答版 Qwen3.8-27B-Uncensored（低拒版，专职"有问必答"）

MTP 投机解码统计（journal `draft acceptance`）