一句话结论
在 RTX 3090 24G 上，用 Qwen3.6-27B-smol-MTP-IQ4_NL.gguf + Beellma（6月16日编译版）+ KVarN K6/V5 KV 量化 + MTP n=3 推测解码，可以稳定撑起 168K 上下文，生成速度稳在 55 T/s 左右、接受率 70–80%，显存占用 22G 出头，编程实测可用度相当能打。

🧠 关键洞察：1. MTP 头的量化等级才是 24G 的命门
折腾了一圈带内置 MTP 的模型后，我发现一个被大多数人忽略的点：

大多数内置 MTP 的模型，注意力头（draft head）的量化控制都拉胯，尤其是那些 15G 以内的版本。

很多作者为了让模型在 16G 显卡上跑 32K 上下文、刷个分、发个推，根本没考虑真实长上下文需求。这类模型一旦上下文推到 80K–90K 之后，速度就会断崖式掉到 20–30 T/s——原因正是它们的 MTP 头也是 Q4 以下量化的，长上下文下 draft 质量崩了，接受率雪崩，推测解码反而变成累赘。

而这次找到的这款模型（作者 IHaveNoClueAndIMustPost），在模型卡上明确写明了"适配 131K 上下文的 24G 显卡，根据 KV 量化等级可增减"。目测它的 MTP 头应该是 Q6 级别的，这点至关重要！

24G 显卡的尴尬就在这里：

MTP 头选 Q8 → 占用偏大 → 没地方放高质量 KV Cache
MTP 头选 Q4 以下 → 短上下文看着快，长上下文接受率崩盘
Q6 级别的 MTP 头 + KVarN 量化的 KV Cache，是我目前试下来 24G 卡上最平衡的组合。

2. 温度，温度，温度！ 笔者 端午后两天在家，24小时开着空调，据回忆，显卡的满载温度在40-55度左右。
   今天上班了，远程回家再测，HERMES满载，温度已经62-65度了。
   别小看这10多度，目测估计 至少降低了 15%-20%的token生成率。

3.beellama 后期可能会由于 显存不足而产生 将Checkpoint 在显存与内存之间疯狂腾挪，直观的感受就是速率直降，如果你不想这样，那请加--cache-ram 0 （后果就是旧的检查点被覆盖，直接“失忆”，无法很好的完成工作！）

️ 环境与启动参数
硬件/软件：

GPU：RTX 3090 24G
CUDA：12.4（nvcc --version 确认）
推理后端：Beellma 3.2 预览版，6 月 16 日自编译版本（选它唯一的原因：支持华为 KVarN KV Cache）
模型：ubergarm-Qwen3.6-27B-smol-MTP-IQ4_NL-ihavenoclue.gguf（约 17G，Q4 级）
KV Cache：K = kvarn6，V = kvarn6，统一模式开启

6-22 上午最佳编程配置：

killall llama-server 2>/dev/null; sleep 3
/data/model2/beellma616-kv.cpp/build/bin/llama-server
-m /data/model3/ubergarm-Qwen3.6-27B-smol-MTP-IQ4_NL-ihavenoclue.gguf
-ngl 9999 --props
-fa on --metrics --ctx-size 168000 -n 16000
-ctk kvarn6 -ctv kvarn6 --kv-unified
--spec-type mtp --spec-draft-n-max 3
--jinja --no-mmap --mlock -np 1 -b 2048 -ub 512
--host 0.0.0.0 --port 8025
--reasoning off
--chat-template-kwargs '{"preserve_thinking":true}'
--reasoning-format deepseek --reasoning-budget 1024
--chat-template-file /data/model2/qwen3.6-27b-gguf/chat_template-Carnice27B-MTP-opt-v2.jinja
--temp 0.62 --top-k 20 --top-p 0.95 --min-p 0.05 --repeat-last-n 128
几个关键参数的取舍说明：

参数 取值 作用与取舍
-ctk kvarn6 -ctv kvarn6 K=6bit / V=6bit 华为 KVarN 方差归一化量化，长上下文下精度接近 Q8_0，显存压缩 3–5 倍

--kv-unified on K/V 统一缓冲，减少调度开销
--spec-type mtp --spec-draft-n-max 3 MTP n=3 每步预测 3 token，实测接受率 70–80%，再高接受率掉得明显

-b 2048 -ub 512 逻辑/物理批 偏保守以保证显存稳定，后续可试 ub=1024 提升预填充
--reasoning off --reasoning-budget 1024 关思考+预算 1024 编程任务关掉思考链更稳，避免 harness 冲突
--temp 0.62 --top-k 20 --top-p 0.95 --min-p 0.05 Qwen 推荐采样

🧪 实测三连：中国象棋 / 俄罗斯方块 / opencode 长上下文
测试一：中国象棋 HTML（多文件工作流）
一上来直接挑战老项目。这几天我已经把提示词改成多文件模式，明确禁止 AI 一次性生成单文件——这项目跑 MVP 也要 1500 行左右，单文件很容易卡死。

我没指望这个 Q4 的 17G 模型有多惊喜，所以没计时间就去洗澡了。洗完回来发现它还在自动调试，工具调用依然不完美。手动停掉、修了几个 JS 错误后，双机对战还是不能用，放弃。

毕竟是 Q4 的 17G 模型，不能期望太高。之前测这套提示词，只有 Qwopus-coder 27B 的表现最完美。

测试二：俄罗斯方块单文件（TRAE）
再在 TRAE 里测俄罗斯方块单文件，两分钟就完成了。让它修复 JS 错误后基本无错运行，TRAE 版 890 行。

测试三：俄罗斯方块单文件（opencode，本地模型）
同样提示词丢给 opencode，明确让它不要用在线模型。结果它用了 10 分钟左右、耗用 50K token，直接无错运行，opencode 版 850 行。

测试四：中国象棋（opencode 长上下文压测）️

再让 opencode 跑中国象棋。此时任务 ID 已经到 19000 多了，拉到最上面只能看到 9000 多的。预填充速度已变为 1300 MB/s，说明旧的检查点已被弃用。

跑了一会儿后，opencode 的上下文到了 30 多 K tokens。约 12 分钟时，168K 上下文开始翻转，日志大量删除、重建 KV Cache——KVarN 在长上下文翻页时的表现比 Q4_0 平滑很多，没有出现明显的速度塌方。

到收尾整合阶段，opencode 思考得有点多，任务 ID 涨到 28000，速度降到 45 T/s。在这里它绕了 10 分钟才到最后一步——Qwen 这个配置的"智商"和 opencode 内置的 harness 应该产生了冲突，棋子位置都是错的。打断、让它上网查标准棋盘布局，还是做不好，只能放弃，让它做交接总结。

做完差点撞到 168K 上限，好险！这也说明这套配置的长上下文承压能力是真实的，不是跑分跑出来的。

性能与显存数据
指标 数值
显存占用 22G 出头（ub 不激进时可稳定，大胆点能压到 23G）
稳定生成速度 ~55 T/s
后期降速 ~45 T/s（上下文翻页 + 任务 ID 2.8 万时）
MTP 接受率 70–80%
预填充速度（缓存失效后） ~1300 MB/s
上下文翻转 约 12 分钟触发一次 KV Cache 重建
观察：填充率略偏低，如果把 -ub 从 512 改到 1024 应该有改善，下一步会试。

已知不足

1. raw tool marker observed while lazy grammar is enabled 紫色提示依然存在

这条提示在工具调用时会反复刷。问过 Gemini，查找的结论大概是建议用 --peg 参数处理 lazy grammar 与 raw tool marker 的冲突，但 Beellma 没有 --peg 这个参数。而我必须用 Beellma 的原因是它支持华为 KVarN KV Cache，这是硬需求，只能无奈放弃这个修复。

2. chat 模板是英文的，导致思考过程和解释都是英文

这套 chat_template-Carnice27B-MTP-opt-v2.jinja 是英文模板，IDE 里的思考过程、解释全是英文。如果能汉化就完美了。不过对我来说倒无所谓，正好练英语。有能力的同学可以基于它做个中文版 jinja 分享出来。