抡锤者

清

看来unsloth的模型及其优化在固件bug不能解决的情况下，还是尽可能把参数调优到各种机器都能顺利运行了：
测试完成，六级全部通过，零崩溃。结果在 /tmp/ctx-stress-27b-20260822-010212.md。

关键数据（实际 prompt_tokens 比名义目标更深，因中文填充每行 token 数高于预估）：

档位	实际深度	耗时	prefill	/health
4K	5.5K	8.5s	652 t/s	ok
8K	11K	9.3s	1206 t/s	ok
16K	22K	16s	1411 t/s	ok
32K	47K	34s	1372 t/s	ok
64K	96K	81s	1192 t/s	ok
128K	194K	224s	870 t/s	ok

结论：

最深处实际打到 194K context，超过之前 128K 崩溃边界，全程无 Xid、无 500、/health 每级存活
prefill 随深度缓降（1411→870 t/s），194K 下 224s 完成一轮，可用
8K/16K/64K 三档回答为空属预期：temp=0 下思考 token 吃满 max_tokens=64，content 为空，非故障（4K/32K/128K 正常出数可证响应链完整）

清

在blackwell固件没解决前，MTP还是容易崩，还是换成unsloth默认参数了，只把槽位改成2，再用一段时间看看。速度确实不如MTP。

清

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 头部元数据双重核对。

清

@freeman-gemmy N卡使用Vulkan效果如何，平均速度多少？

清

@freeman-gemmy 我已经找到了更好的办法，测试到现在，已经没有崩溃的情况发生了，过会整理下，再发！

清

平台：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 权限。

清

@williamlouis 请教，40系的作业也可以应用到我这张卡么？

清

@tkioscar 我只是对比了3.6A3B和现在的3.8-27B，智商完全不在一个档次，所以才下决心折腾。你说的，我觉得你需要使用不同难度的问题或操作去感受才有体会。至于不同源的版本，目前就是我帖子里的我的最终定案了，主要是稳定不崩溃。之前使用的经常中途就崩溃了，不太清楚原因，换源试试，发现还真有效。另外，权重优化得越小的，在我的硬件环境中越稳定。官方源以及Q5就非常容易崩溃，换unsloth的Q4，就稳定得多了。

清

在现有方案下，两个qwen3.8-27B长时间稳定运行无崩溃，终于可以放心用了，所有普通任务，驱动hermes和DSharness体感都非常不错，速度完全满意。

清

@imbiplaza-ASUS 是的，之前还是32GB内存呢，后来忍痛才凑了64GB，看了下128GB内存的价，我忍了！

清

平台：Linux（Ubuntu 26.04 LTS）/ RTX PRO 4500 Blackwell 32GB / systemd 用户服务
日期：2026-08-20（模型 8-14 发布后 6 天；08-19 首测 Q5 档 + 08-20 换装 Q4 新量化源二次实测）

一、结论

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

模型类型	推荐框架	理由
MoE 模型（A3B）	vLLM + MTP	显存充裕，MTP 稳定，速度快（144 t/s）
Dense 模型（27B）	llama.cpp + MTP	Q4 档 + MTP n-max 2，实测 67-68 t/s，压测零崩

27B dense 模型在本机的最终定案（2026-08-20）

框架：llama.cpp 唯一正解（vLLM 跑 dense 27B 只有 ~20 t/s，已废弃）
量化：Q4 档（标准版 Unsloth UD-Q4_K_XL / 免审查版 HauhauCS Q4_K_P，均 17.9GB）
投机解码：MTP（draft-mtp n-max 2），短负载 decode 67-68 t/s
上下文：200K（204800），K4V4（KV 全 4bit），显存 ~24.9GB / 32GB
Q5 档已淘汰：Q5_K_M + MTP 在 Blackwell sm_120 必崩（decode kernel 超驱动看门狗）；Q5 无 MTP 仅 24.5 t/s

本机现役双服务

llama-qwen-27B.service     → Qwen3.8-27B 官方底模 + Unsloth UD-Q4_K_XL 量化 (200K, MTP2, ~67 t/s)
llama-qwen-27B-uc.service  → Qwen3.8-27B 免审查版 HauhauCS Q4_K_P (200K, MTP2, ~68 t/s)

二、硬件 / 软件环境

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

三、模型来源（Q4 换装后）

1. 官方底模 Qwen3.8-27B（默认主力，Unsloth 量化）

仓库：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-UD-Q4_K_XL.gguf（17.92GB，Unsloth Dynamic v3.0） + mmproj-F16.gguf（927MB）
为什么选 UD：Unsloth Dynamic 按张量重要性动态分配 bit，官方 benchmark 显示 UD-Q4_K_XL 在同 Q4 档质量领先（MMLU 5-shot 接近 Q5_K_M），且体积更小

2. 去拒答版 Qwen3.8-27B-Uncensored（HauhauCS Aggressive）

仓库：https://huggingface.co/HauhauCS/Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-MTP-GGUF
加工：HauhauCS Aggressive 去拒答 profile，0/465 Refusals（直答无前置废话）
文件：Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-Q4_K_P.gguf（17.92GB） + mmproj-...-Aggressive-BF16.gguf（931MB，BF16 投影）
Q4_K_P 是 K_P 新量化（5.25 BPW，高于 Q4_K_M 的 4.88），精度高一档
保留了 Qwen3.8 原生 NextN(MTP) 头（llama-gguf <file> r | grep nextn = 10 个张量）
附带 FastMTP-32K sidecar（0.9GB，宣称比原生 MTP 再快 ~35%）——已测试，弃用（见第六节）

3. 历史模型（已删除）

Q5_K_M（官方 19.8GB / uncensored 19.5GB）：08-19 首测档，Q5+MTP 必崩 → 08-19 夜弃
Q4_K_M（17.1GB）：08-19 终裁档，57-60 t/s；08-20 被 UD-Q4_K_XL / Q4_K_P 取代（新量化源同体积更高精度 + 更快）
vLLM NVFP4 版（22GB）：32GB 卡实测上限 100K context，CUDA graphs 不可用，~20 t/s，已废弃

四、vLLM 路线实测（已废弃，保留记录）

部署参数（历史）

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

失败原因

尝试	结果
max-model-len=131072 (128K)	KV cache 需 4.57GB，仅 3.9GB 可用 → OOM
max-model-len=100000	成功启动，可用 3.69GB KV cache
CUDA graphs 开启	模型占 29.7GB，CUDA graphs 需额外 800MB → OOM
最终速度	~20 tok/s（enforce-eager）

结论

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

五、llama.cpp 路线实测（现役方案）

部署参数（2026-08-20 现役）

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 \
  --host 127.0.0.1 --port 8000 \
  --ctx-size 204800 \
  --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 \
  --spec-type draft-mtp \
  --spec-draft-n-max 2 \
  --temp 1.0 --top-k 20 --top-p 0.95

免审查版差异：-m .../Qwen3.8-27B-Uncensored/Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-Q4_K_P.gguf + --mmproj .../mmproj-...-Aggressive-BF16.gguf + --alias qwen3.8-27B-UC

实测结果（2026-08-20，Q4 档 + MTP n-max 2）

场景	标准版 UD-Q4_K_XL	免审查版 Q4_K_P
短负载（512 token 生成）	67.2 t/s（acceptance 68.2%）	68.4 t/s
100K 预填 + ~5800 token 长生成	274.9s 零崩（acceptance 56.7%）	246.6s 零崩（acceptance 54.2%）
显存占用	24.9GB / 32GB	24.9GB / 32GB
PID 全程未变 / 无 CUDA/Xid 错误	✓	✓

Q4_K_P 长生成比 UD-Q4_K_XL 快 ~10%（K_P 量化精度更高、解码更顺）
免审查实测：0/465 拒绝（官方发布口径），硬提示词直答

显存占用

项	占用
Q4 档权重（UD / K_P）	17.92GB
mmproj（F16 / BF16）	~0.93GB
200K ctx q4 KV + 缓冲	~6.1GB
总计	~24.9GB / 32GB（留 ~7.5GB 给桌面）

200K context 的关键

考虑到hermes50%上下文压缩，100K是舒适点。
KV cache 全 4bit（--cache-type-k/v q4_0）+ 全量 offload（-ngl 99）+ --no-mmap 是 32GB 卡跑 200K 的三板斧。换 fp8/fp16 直接放不下。

六、MTP 在 Blackwell 上的崩溃演进史（重点）

阶段一：Q5 档 + MTP 必崩（08-19 实测）

现象：CUDA error: the launch timed out and was terminated（ggml-cuda.cu:106）
崩溃点随机：366/771/2346/3208/5904 token（非上下文满导致）
128K/256K × mmproj 有无全组合实测全部崩溃
升级 llama.cpp（70 commits 后）仍崩；驱动 595.91.07 不救
根因：decode kernel 单步时长超驱动看门狗（GSP heartbeat → Xid 8，Blackwell 强制）

阶段二：降 Q4 档 + MTP 扫档全过（08-19 夜）

Q4_K_M（17GB）替代 Q5_K_M（19.8GB）后，MTP 全组合扫档压测零崩（128K 6/6、256K 10/10、长上下文 33K-110K 全过），57-60 t/s
推论：单步 kernel 时长与权重体量正相关，Q4 更小越不过看门狗线 → Q4 是 27B 量化安全线

阶段三：实战偶发 Xid 8（08-20 修正认知）

实际 agent 长会话仍偶发 2 例 Xid 8：上下文 6 万 / 11 万 token 处，活跃解码中崩溃
结论修正：扫档压测通过 ≠ 长期运行稳定；Q4 档是安全线而非保险
用户方法论：32GB 卡按 24GB 对待，Q4 档能跑顺为标准

阶段四：Q4 新量化源 + MTP 压测（08-20，现役）

UD-Q4_K_XL / Q4_K_P 各跑 100K 预填 + 5800 token 长生成：双双零崩（PID 全程未变）
短负载 67-68 t/s，比旧 Q4_K_M + MTP（57-60）提速 ~15%

FastMTP-32K sidecar 实测（08-20，弃用）

宣称：比原生 MTP 再快 ~35%（文档 TG）
实测：--spec-draft-model <sidecar> 加载失败——tensor 'output.weight' has wrong shape; expected 5120, 248320, got 5120, 32768。sidecar 用 d2t draft-vocab trim（输出词表裁剪到 32768），需要 llama.cpp 上游未合入的自编译 patch（作者在 HF 讨论区贴的 qwen35.cpp diff）
社区实测：中文场景 FastMTP 接受率仅 ~40%，收益低于英文场景
结论：原生 embedded MTP 已 68 t/s，sidecar 弃用

已知 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 生成错误机器码
nvidia-open #1080：GSP heartbeat → Xid 8，Blackwell 强制机制

七、踩坑与经验

必须知道的

--jinja 必须加：3.8 官方 jinja 模板会把空 thinking 块包进输出，破坏多轮 agent 会话
过思考是 3.8 的祖传毛病：用 reasoning_effort=medium 压住，medium 下实际思考量很小；preserve_thinking 保留跨轮思考连续性
200K 是 32GB 卡的稳定档：288K 超预算；256K 能跑但实战偶发 Xid 8，200K 是最终定案
档位零速度代价：速度只与实际上下文长度相关，与配置档位无关（1K-12K 负载 tg 与 256K 档持平）
量化选型：Q4 档是 27B 安全线（用户方法论：32GB 卡按 24GB 对待）——Q5+MTP 必崩、Q4 扫档全过；同体积下 UD/K_P 新量化比 Q4_K_M 更快

MTP 相关

MTP 参数：--spec-type draft-mtp --spec-draft-n-max 2（误写 mtp 启动即失败 unknown type）
MTP 收益：Q4 档 ~45% 提速（67 vs 无 MTP 40-41）；acceptance 实测 54-68%（agent 工具调用负载下偏低属正常）
关 MTP 参数：--spec-type none（新版无 --no-speculative）
崩溃模式判别：launch timed out = decode kernel 超看门狗（受 ctx 长度影响）；illegal memory access = 显存不足——两者处理方向完全不同

下载验证

字节级核验：curl -sIL 对比远程 Content-Length vs 本地 stat，diff=0 才过；大文件再跑 SHA256 对照模型卡
别下错版本：同名量化可能差几百万字节（带不带 MTP、带不带 vision）；MTP 提速必须选带 NextN 头的版本（无 noMTP 后缀）

服务管理

切模型 = 切服务：8000 端口互斥，切换前先停另一个（互斥切换脚本承担）
全部 disabled：按需手动 start，不开机自启
测速必带负载条件：中文散文 vs 工具调用 JSON 差一倍是草稿接受率差异；agent 场景报数必须用 agent 真实工作负载

八、接入 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 + Q4 档 + MTP，67-68 t/s 全链路零崩；MoE A3B 用 vLLM + MTP，144 t/s；同机器双方案按场景切。

Blackwell sm_120 的现实（08-20 修正版）：

llama.cpp MTP 在 Q5 档必崩，但 Q4 档 + MTP 是可行组合（67-68 t/s，长压测零崩）
实战长会话仍偶发 Xid 8（6万/11万 token 处）——降 ctx / 关 MTP 是兜底手段，Q4 档是安全线而非保险
新量化源（Unsloth UD / HauhauCS K_P）同体积更高精度、更快——换量化源比换框架收益大

如果要速度：用 A3B（144 t/s）
如果要质量 + 免审查：27B Q4_K_P + MTP（68 t/s，0/465 拒绝）
如果要通用主力：27B UD-Q4_K_XL + MTP（67 t/s）
如果长会话偶发崩溃：降 ctx 到 128K 或关 MTP（-30% 速度）换零崩

附：实测数据时间线

日期	配置	短负载	长压测	结论
08-19	Q5_K_M + MTP	崩	崩	Q5+MTP 必崩，弃
08-19	Q5_K_M 无 MTP	24.5 t/s	零崩	兜底档
08-19	Q4_K_M + MTP	57-60 t/s	扫档全过	终裁档
08-20	UD-Q4_K_XL + MTP	67.2 t/s	100K 零崩	★标准版现役
08-20	HauhauCS Q4_K_P + MTP	68.4 t/s	100K 零崩	★免审查现役

清

补一个现在的测试结果，现在我已经很满意了！
测完了，真实数据（本机 127.0.0.1:8000，llama-server，Q4_K_M + MTP n-max 2 + FA + KV q4_0 + 256K ctx）：
解码（decode）

1024 token 长输出，三次复测：54.5 / 55.3 / 51.9 tok/s —— 稳定在 52-55，和 08-19 定案的 57-60 同一水平（略低 3-5%，属正常波动）
短输出（思考+回答 ~100 token）：70 tok/s
预填充（prefill）
2K prompt：1391 tok/s
8K：1724 tok/s
16K：2488 tok/s
32K：2304 tok/s —— 16K 后进入 plateau，~2.3-2.5K tok/s
TTFT
冷启动首 token 1.4s，热 0.33-0.38s
32K 上下文 TTFT 6.5s，64K 约 14s（可接受，不算卡）
显存：25.3/32.6 GB，256K ctx 下留 ~7GB 余量，健康。
结论：修复后状态良好，解码 ~55 tok/s 达标（MTP 收益在），预填 16K+ 稳定 2.3-2.5K tok/s。日常 agent 场景（长 context + 中短输出）体感很顺。

清

@terry 也想问锤哥，双显卡，主板、CPU，有什么好的推荐么？电源至少多少瓦？

清

@stxpnet 感谢，以后会试试！有实践成功的参数配置没？话说A3B确实智商差了点，干点杂活，速度还是很快的，驱动hermes，至少还得27BQ4

清

@applejuice 是的，感觉这个架构刚出没多久，问题还很多，稳定能用的应该还是4090 48GB更靠谱，但入这张显卡，功耗太高，很多硬件都要换，我想省点事，就换了这张，之前是200多瓦的4070ti，换这张卡就简单多了。

清

@applejuice 是的，sglang也失败了，唯一能成功的是vllm+qwen3.6-35B-A3B，其它27B只能llama来跑

清

你的建议是对的，我来还愿了。

按你说的把两个 27B 都换成了 Q4_K_M，实测结果比预想的还好——MTP 在 Q4 上不崩了。

实测数据（RTX PRO 4500 32GB，llama.cpp 98d1e92，K4V4，256K，draft-mtp n-max 2）：

配置	短输出	稳定性
Q5_K_M + MTP	46 t/s	必崩（128K/256K 全组合，decode kernel 超看门狗）
Q5_K_M 无 MTP	24.5-37 t/s	稳，但慢
Q4_K_M + MTP	57-60 t/s	128K 6/6、256K 10/10、长上下文 33K/55K/82K/110K 全过
Q4_K_M 无 MTP	40-41 t/s	对照

之前定论"sm_120 的 MTP 短期无解"只对了一半——崩溃本质是 decode kernel 超看门狗，单步 kernel 时长跟权重体量正相关。Q5 19.8GB 每一步都踩线，Q4 17GB 单步更短，正好越不过去。你的带宽账（896÷16≈56）也验证了：MTP 加持下 57-60 t/s 已经是贴着上限在跑。

另外论坛上的 K8V4（K 比 V 金贵），本机 CUDA 后端实测是 CPU 满载元凶（744%，更慢），只适用 AMD Vulkan 后端，N 卡这边还是 K4V4 稳妥。跨后端抄参数前先验证，这条也算踩过了。

一句话：Q4 + MTP + 256K = 32GB 卡跑 27B 的最终答案。

清

@applejuice 失败了。qwen3.6-35B-A3B可以，27B不行。

清

@Xiaote 我现在转变一个观点，把这张32GB显存的显卡当成是24GB卡来对待，24GB卡能跑顺的，这张卡就绝对没问题，下载模型权重以24GB显卡能跑顺为标准，那本显卡就绝对没问题了，这样应该就少走很多弯路了！

清

@Che 感谢！

抡锤者

清风明月

帖子

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 的考量

八、踩坑与经验

一、结论

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

27B dense 模型在本机的最终定案（2026-08-20）

本机现役双服务

二、硬件 / 软件环境

三、模型来源（Q4 换装后）

1. 官方底模 Qwen3.8-27B（默认主力，Unsloth 量化）

2. 去拒答版 Qwen3.8-27B-Uncensored（HauhauCS Aggressive）

3. 历史模型（已删除）

四、vLLM 路线实测（已废弃，保留记录）

部署参数（历史）

失败原因

结论

五、llama.cpp 路线实测（现役方案）

部署参数（2026-08-20 现役）

实测结果（2026-08-20，Q4 档 + MTP n-max 2）

显存占用

200K context 的关键

六、MTP 在 Blackwell 上的崩溃演进史（重点）

阶段一：Q5 档 + MTP 必崩（08-19 实测）

阶段二：降 Q4 档 + MTP 扫档全过（08-19 夜）

阶段三：实战偶发 Xid 8（08-20 修正认知）

阶段四：Q4 新量化源 + MTP 压测（08-20，现役）

FastMTP-32K sidecar 实测（08-20，弃用）

已知 Blackwell + MTP 的 bug（调研记录）

七、踩坑与经验

必须知道的

MTP 相关

下载验证

服务管理

八、接入 Agent 的方式

九、总结

附：实测数据时间线