测试了两天，发现RTX PRO 4500 Blackwell 32GB这张卡真有点坑啊！有没有哪位大神在这张显卡上能稳定高速的27B-llama方案啊？
-
不是卡坑，是「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 的活，不是这张卡不行。
-
-
不是卡坑，是「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 的活，不是这张卡不行。
-
-
不是卡坑，是「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 的活，不是这张卡不行。
-
-
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 的最终答案。
-
Sglang?
但是 这张卡就是高级版的5080@applejuice 是的，sglang也失败了，唯一能成功的是vllm+qwen3.6-35B-A3B，其它27B只能llama来跑
-
我觉得可以期待 等nvfp4 能用 blackwell就有价值了
@applejuice 是的，感觉这个架构刚出没多久，问题还很多，稳定能用的应该还是4090 48GB更靠谱，但入这张显卡，功耗太高，很多硬件都要换，我想省点事，就换了这张，之前是200多瓦的4070ti，换这张卡就简单多了。
-
同样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速度，可以起飞
-
这个还愿数据太漂亮了，收下：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 稳妥——跨后端抄参数先验证，这条本身就值得写进经验贴。
-
同样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速度，可以起飞
-
同样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速度，可以起飞
-
补充一个 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 + 中短输出）体感很顺。
