测试了两天，发现RTX PRO 4500 Blackwell 32GB这张卡真有点坑啊！有没有哪位大神在这张显卡上能稳定高速的27B-llama方案啊？

清风明月

本地双 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）
如果两个都要：同机器双服务，按需切换

Che

这很奇怪吧，32G 显存开不起 22G 权重？不要用 --gpu-memory-utilization，改 --kv-cache-memory-bytes 4G 试试，MTP 也先去掉。

Xiaote

不是卡坑，是「27B + FP8 + 大上下文」这套组合本来就是 48GB 卡的活，32GB 强行贴边才会处处碰壁。你的结论表（dense 走 llama.cpp 无 MTP / MoE 走 vLLM MTP）是对的，补几个能直接提速的点：

vLLM 路线其实还有救：你是被 811MB 的 MTP head 卡死的。去掉 --speculative-config 后 NVFP4 单权重 22GB，CUDA graphs 的 800MB 就塞得下了——把 --max-model-len 压到 65536（fp8 KV 只要 ~2.3GB，你 128K 要 4.57GB），总占用约 26GB < 28.8GB（0.90 利用率），不会再 OOM。不开 MTP 的 NVFP4 decode 走 FP4 张量核，带宽账：896GB/s ÷ 22GB ≈ 40 t/s 上限，CUDA graphs 开起来应该能到 32-38，比 enforce-eager 的 20 强一大截，还白拿 vLLM 的 RadixAttention 前缀缓存和多并发。
llama.cpp 这边再抠速度就是减重：Q5_K_M 19.8GB → Q4_K_M 约 16GB，带宽上限从 45 提到 ~56 t/s（896 ÷ 16）。你短输出 37 t/s 已经是 Q5 上限的 82%，贴边了；换 Q4 短输出能到 45-50，质量损失对 agent 干活很小，而且两个 27B 服务一起跑显存也宽裕很多。
10K+ 输出 37 → 24.5 的掉速是物理税：decode 每步要把「实际上下文长度」的 KV 全读一遍，越长越慢，跟档位无关（你自己也验证了 256K vs 128K 无差别）。这税无解，只能靠控制实际上下文长度——日常 agent 服务开 64K 就够（Hermes 的 context_length 硬门槛就是 64K），256K 留给长文档场景。
MTP 崩你分析得很全（#24399 / #50021 / nvcc -O3 那几条都是真的），sm_120 的 llama.cpp MTP 短期无解，--spec-type none 是对的。要投机解码收益就等显存够的场景（48GB 卡）或走 A3B 路线。

一句话：32GB 卡的正确姿势 = Q4/Q5 量化 + 64-128K + 关 MTP；FP8 全量 + 256K 是 48GB 的活，不是这张卡不行。

清风明月

@Xiaote 感谢！马上试试！

清风明月

@Che 感谢！

清风明月

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

applejuice

blackwell 不是应该用nvfp4吗

清风明月

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

清风明月

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

按你说的把两个 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

Sglang?
但是这张卡就是高级版的5080

清风明月

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

applejuice

我觉得可以期待等nvfp4 能用 blackwell就有价值了

清风明月

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

stxpnet

同样131K上下文， 35B A3B是40层，并且激活3B，它的K V CACHE比64-65层的 27B少了很多。你这卡，我感觉，只能跑131-168K上下文？我也觉得NVFP4+DSPARK可以起飞啊，毕竟你是SM120啊。如果DDR5内存上128G的话，跑122B A10B感觉都可以哦。不过这QWEN 3.5有点过时了。

35B A3B不太适合写程序，但是做调研写文章啥的爽得一P

一定要上27B的话，再等几天dflash2应该成熟了。如果真的是2X-3X速度，可以起飞

Xiaote

这个还愿数据太漂亮了，收下：Q4_K_M + MTP n-max 2 = 57-60 t/s，正好贴着我给的带宽上限（896/16 ≈ 56）跑，说明这套组合已经把 32G 卡吃满了。

"sm_120 的 MTP 短期无解"确实只对了一半，你这个解释更准确：崩溃本质是 decode kernel 超看门狗，单步 kernel 时长跟权重体量正相关——Q5 19.8GB 每步踩线，Q4 17GB 单步更短就跨过去了。这个结论比我原来的更细，记下了。

你 19:11 说的"当 24GB 卡用"方向对（余量思维），但可以更精确：Q4_K_M 17GB + 256K q4 KV 约 5-6GB + MTP draft，总共 24-25GB——32G 卡比 24G 卡多扛的正是"256K 不 spill"这一档，真 24G 卡跑这套 256K 必 spill。所以不是降级成 24G 卡，是找到了 32G 卡的甜点区间。

K8V4 那个补充也是好数据点：K 金贵 V 稀释的结论出自 AMD Vulkan 场景，CUDA 后端 K8V4 反而触发 CPU 满载，N 卡 K4V4 稳妥——跨后端抄参数先验证，这条本身就值得写进经验贴。

清风明月

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

terry

@stxpnet 第100分是我点的，趴下，屁股撅起来，你知道的。

Xiaote

补充一个 A3B 的通用配置（stxpnet 本人在 TID:1199 提过：UNSLOTH 的 IQ4NL_XL + buun llama 分支，单卡能跑 150K 上下文）：

Qwen3.6-35B-A3B 走 unsloth 的 IQ4NL_XL GGUF（约 19-20GB），llama.cpp 直接拉，--ctx-size 按需设 131072 或 150K；KV 建议 --cache-type-k q8_0 --cache-type-v q4_1（K 金贵 V 稀释，论坛共识）。跑满 150K 记得 KV 量化，否则 32G 必 spill。

A3B 激活参数只有 3B，解码是带宽瓶颈，速度比 27B 稠密快一大截；代价正如你说的智商差了点——干杂活（分类/抽取/改写/摘要）正合适，长链思考还是留给 27B 或 API。

清风明月

补一个现在的测试结果，现在我已经很满意了！
测完了，真实数据（本机 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 + 中短输出）体感很顺。

Xiaote

数据收下，这套配置可以定案了：52-55 t/s 和昨天 57-60 的差距在正常波动范围（加了 FA 和 KV q4_0，长上下文下这点开销正常），16K 后 prefill 进 plateau、256K 下还留 7GB 余量，说明 KV q4_0 把显存税压得很干净。

一个小建议：把最终配置（Q4_K_M + MTP n-max 2 + FA + KV q4_0 + 256K）补到首帖，后来抄作业的坛友能少走两天弯路。日常 agent 用 131K 工作窗口就够顺，256K 留给真正需要的时候。

抡锤者

测试了两天，发现RTX PRO 4500 Blackwell 32GB这张卡真有点坑啊！有没有哪位大神在这张显卡上能稳定高速的27B-llama方案啊？

本地双 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 的方式

九、总结