折腾了几天，把实测数据和踩坑记录整理一下，都是 8GB 卡上的真实数字。最大的感受：

8GB 上卡你的不是解码速度，是上下文。

-c 从 32768 提到 40960，agent 类任务就从"全部撞墙"变成"全部跑通"。差这 8K，
就是能干活和不能干活的分界。

仓库（预编译二进制 + 完整配方 + 编译踩坑）：
https://github.com/snailium/bonsai2-8gb

一、模型背景：Ternary Bonsai 2 27B 是什么

先说清楚这是个什么东西，不然下面的数字没有参照。

一句话：Qwen3.8-27B 的三值量化版。权重被压到 {−1, 0, +1} 三个值（1.58-bit 那一类做法），
配合 group size 128 的缩放因子，实际是 1.75 bpw。

为什么 8GB 能塞下 27B：就是靠 1.75 bpw。同一个基座，常规量化的体积对比：

量化	体积	8GB 能装?
Bonsai 2 PTQ1_0（三值）	5.54 GiB
Unsloth UD-IQ1_S	5.77 GiB
Unsloth UD-IQ2_XXS	6.77 GiB
Unsloth UD-Q2_K_XL	9.15 GiB
Unsloth UD-Q4_K_M	15.33 GiB

也就是说：同一个 27B，4-bit 量化是 15.33 GiB，8GB 的卡连边都摸不到。
能跑起来完全是三值量化的功劳。

那个"只有 16 层是 full attention"很关键：KV cache 只在这 16 层上产生，
所以 KV 的增长比同规模的稠密模型小得多——这是能用 q4_0 量化 KV 开到 40K 的前提。

一个必须知道的坑：不能换 stock llama.cpp

三值量化需要旋转过的权重基底（Hadamard 变换），这些在 mainline llama.cpp 里
完全没有（PrismML 的三值类型是 fork 独有的；有人提过 Q2_0 的移植 PR，
2026-07 关掉了没合）。

后果：

• stock llama.cpp 直接拒绝加载 PTQ1_0 / PQ2_0
• 更坑的是旧版 Q2_0 文件能加载但不报错，输出是乱码

所以必须用 PrismML 那条 fork 线（我们用的是 sudoingX/llama.cpp 的 bonsai2 分支，
在 PrismML fork 基础上叠了三个还没合入的 PR）。模型卡上也写了这一点。

MTP 是什么，为什么要它

Qwen3.8-27B 自带一个 nextn 头（多 token 预测），可以拿来做投机解码：
草稿头一次猜几个 token，主干批量验证。

8GB 上要它的理由有两层：

1. 提速：短 prompt 下 decode 从 54 提到 65–73 tok/s，接受率 0.85 左右
2. 更重要的：MTP 会影响显存布局。这个我们踩坑了——关掉 MTP 反而没法用
   （见下面"坑 2"）

另外 MTP 头有两种装法：单独一个 sidecar 文件，或者嫁接进同一个 GGUF（作为 blk.64）。
单独装会重复一份词表 embedding，代价可以直接从文件大小看出来：

fat − lean = 682 MiB，就是那份重复的 embedding；lean − orig = 335 MiB，
是 MTP 头本身。8GB 的卡上 682 MiB 很值钱，所以我们用 lean 版。

（代价：lean 版需要 build 里有 Hadamard 修复，也就是 bonsai2 分支带的那几个 PR。
官方预编译的 release 二进制起不来 draft 图。）

二、平台

GPU      RTX 5060 8GB     8151 MiB - 447 driver reserved = 7704 可用
         sm_120 (Blackwell) —— 不是 Ampere/Ada，坑不太一样
模型      Ternary-Bonsai-2-27B-PTQ1_0-mtp-lean.gguf   5.87 GiB
后端      sudoingX/llama.cpp  branch bonsai2 @ dcc3be7
          (含 #218 专用 mat-vec + #217/#205 Hadamard 修复 + #220 GDN gather)

三、启动参数，逐条说一下为什么

GGML_CUDA_BATCH_INVARIANT=1

llama-server \
  -m Ternary-Bonsai-2-27B-PTQ1_0-mtp-lean.gguf \
  -ngl 99 -fa on -np 1 \
  -c 40960 \
  -ctk q4_0 -ctv q4_0 --kv-mean-center kv-mean-center.gguf \
  --spec-type draft-mtp --spec-draft-n-max 1 \
  --reasoning-effort low --reasoning-budget 4096 \
  --jinja \
  --temp 0.7 --top-p 0.80 --top-k 20 --presence-penalty 1.5

显存占用：7508 MiB used / 198 free。

四、实测

llama-bench tg128：54.31 tok/s（官方 release 二进制同卡 39.56 → +37%）。

短 prompt 服务端解码：code 70.7 / bash 68.9 / prose 64.6 tok/s，MTP 接受率 0.85 / 0.78 / 0.67。

40960 上下文下跑一整套 agent 任务：

同样的配置在 32K 下，后两个任务全部撞墙：研究任务每轮要 7–25 次 compaction
（其中 1–4 次失败，报 summary is not smaller than the shadowed content），审计任务
根本跑不完。只多 8K，就是"全挂"到"全过"。

agent 任务的 decode（33–45）明显低于生成任务（66–67），是上下文深度造成的——
这些 run 的 prompt 有 9–15K tokens。另外每轮对话都要完整重算 prefill
（上下文裁剪会打断前缀缓存），约 72 秒/次工具调用，这是长任务的真实墙钟成本。

五、两个坑，踩过的可以直接跳过

坑 1：带 MTP 的上下文上限是 40960，不是 64K。 同一张卡上逐档试出来的：

-c	带 MTP	无 MTP
32768	7284 MiB	—
40960	7508 MiB	—
49152	cudaMalloc OOM	—
65536		7268 MiB
81920	—	7636 MiB
90112	—

坑 2：这个 build 关掉 MTP 之后，模型输出会坍缩成 /。

上面那张表里"无 MTP"一列看着很诱人——能把窗口开到 80K，省显存也是真的
（7268 MiB，跟文档里的 7,266 几乎分毫不差）。但代价是模型直接不会写字了：

32K + MTP             -> 正常
32K 无 MTP            -> 全是 "/"        (多次复现)
64K 无 MTP            -> 全是 "/"        (3/3)
无 MTP + 关 thinking  -> 正文直接是 200 个连续 "/"
无 MTP + 原版 PTQ1_0  -> 同样坍缩

不是 -mtp-lean 文件的问题（原版 GGUF 一样），也不是 reasoning 路径的问题。
所以"拿 MTP 换上下文"这条路，至少在这个 build 上走不通。

六、能跑通还有一半功劳在 harness：dsh + 我们自己写的两个小插件

上面那些 agent 任务不是我手动盯着一步步喂的，是模型自己调工具、自己决定下一步，
跑在 DeepSeek Harness (dsh)
的 headless 容器里。

速度这块已经很多人卷了，但**"小窗口下 agent 怎么不把自己搞死"讲的人不多**——
而 8GB 卡上这就是生死线。我们前后写了两个 dsh 插件来治这个，都有点用：

插件一：一个不花模型调用的"后悔药" —— context-trim

上下文满了怎么办？常规操作是让模型自己压缩历史。问题是压缩本身也要跑一次模型，
而且它得把"要压缩的那段"塞进已经快满的窗口里——于是就经常压不动。我们实测撞到的：

summary is not smaller than the shadowed content (1180 >= 1180)

翻译一下："我想把它变小，但变小之后还是一样大。" 32K 的卡上，到这一步基本就死了。

我们这个小东西的思路特别土：一次模型都不调，纯记账。 把最老最没用的那段对话
直接换成一行标记，或者把超长的工具输出掐头去尾留一段。腾地方不要钱，所以
它在所有请求都快挂掉的时候反而最管用。

效果：那次 27 个文件的安全审计，它出手 11 次，一共腾出约 3.7 万 tokens。
没它的话，这个任务在 40K 窗口里根本走不到"开始写报告"那一步。

一句话总结：别指望模型自己管上下文，裁剪这种事应该是 harness 的零成本杂活。

插件二：它钻牛角尖的时候，得有人踹一脚 —— repeat-tool-breaker

小模型 + 低显存，"原地打转"是高频死法。我们碰到的真实案例：
同一个 API 打了 29 次，每次参数都不一样，跑满一小时没结果。

最阴险的地方在于——从字面上看它每次都在做不同的事。所以任何"检测重复调用"的
工具都抓瞎，你只能干看着它烧时间。

我们的做法是不看字面、看语义：比如"往 weather.gc.ca 这个域名一共打了多少次"
单独计数。不管你 URL 参数怎么变，同一个目标的调用会攒起来，钻牛角尖就现形了。

喊停也不是一上来就拦死，分三级：

T5 那次的效果：模型连着 7 次 curl 同一个天气 API、5 次失败，第 7 次触发提醒，
下一次调用它就换思路了——从"怎么调通这个端点"变成去搜气象局官网数据，
最后算出正确答案。

一句话总结：小模型本来就更容易钻牛角尖，而且钻起来更慢更烧时间。
与其调 temperature / penalty 试图让它别钻，不如在 harness 层给它一句
"你该换个思路了"。 后半句是我们反复验证过的：光调采样参数，救不回来。

顺手记一个 bug：判断"失败"不能只看 isError。curl ... | python3 ... | head
的退出码是 0，脚本里把 HTTP 400 吃掉了也是 0——我们那次 7 个调用里 5 个失败，
全被判成了成功，所以提醒一直不吭声。最后得去读文本里的报错特征才行。

七、thinking 也有个方向性的坑

模板里 reasoning_effort 只接受 xhigh / medium / low 三个值。默认 xhigh 会注入
一段"仔细思考、验证假设、考虑替代方案"的系统提示，在量化模型上会失控——我们实测过
一次 24508 token 的回复里 86% 烧在 thinking，正文一个字没出来。

low 注入的是相反指令（"Keep your thinking brief and focused"），配
--reasoning-budget 4096 在 agent 任务上表现最好；纯生成任务直接 --reasoning off。

方向性坑：服务端设了 --reasoning off 之后，客户端发 reasoning_effort: high
是压不过它的（实测 0 个 reasoning frame）。想两种模式共用一个 server，要反过来做：
服务端开着 thinking，需要关的请求带 chat_template_kwargs: {"enable_thinking": false}。

八、复现入口

仓库：https://github.com/snailium/bonsai2-8gb

• bonsai2-universal.tar.gz — 预编译二进制，sm_75 → sm_120 全架构
  （我们从源码编的：官方预编译包只含 Ampere/Ada，而 CUDA 12.4 编不了 sm_120）
• RECIPE.md — 完整配方、每个参数的依据、各项实测数据、12 条注意事项
• BUILD.md — 编译三个坑：CUDA 12.4 编不了 Blackwell、glibc 2.43 的 rsqrt
  声明冲突、cmake 会静默选错 nvcc（报 ptxas fatal: Value 'sm_52' is not defined）

这两个插件是我们自己写的，源码和设计说明都公开：

• snailium/dsh-command-context-trim
  —— 零模型调用的上下文裁剪
• snailium/dsh-repeat-tool-breaker
  —— 语义指纹的重复/失败检测

写它们的原因很直接：8GB 这种小窗口跑 agent，光靠调模型参数是救不回来的，
必须在 harness 层动手。如果有人在别的低显存场景做 agent，这两个的思路应该能照搬——
插件的阈值和开关都是可配的，不绑定任何特定模型。