到目前为止，我的笔记本电脑（CPU 是 Ultra X7 358H）已经部署了三个本地大模型：
- Qwen3.8-27B
- Qwen3.6-35B-A3B
- Bonsai 2 27B
我平时使用大模型的场景，最多的就是用来编程，所以，我想知道，在这三个模型中，哪个最合适。同时也想看一下这三个模型的对比情况。这件事同样交给 AI。
以下是 AI 给我的分析数据和结论（使用 Deepseek Harness Desktop + Deepseek V4.1 Flash）。
结论：本地编程首选 Qwen3.6-35B-A3B
三个模型的编码跑分几乎持平 （SWE-bench Verified 73.4 / 72.4 / ≈71.9，差距不到 2 分），
所以决定因素不是"谁更聪明"，而是速度、上下文经济性与稳定性 ------
这三项上 Qwen3.6-35B-A3B 全面领先：生成速度是 Bonsai 的 2.2 倍、Qwen3.8 的 6.4 倍，KV cache 便宜 3.2 倍（因此能真正用上 256K 上下文），且在内存压力下不崩。
排序：① Qwen3.6-35B-A3B（主力）→ ② Bonsai 2 27B（常驻/视觉备选）→ ③ Qwen3.8-27B（不建议用于交互式编码）
- 机器：Intel Core Ultra X7 358H / Intel Arc B390 iGPU（SYCL）/ 31.55 GiB 内存
- 引擎：llama.cpp 0.5.0-dev（SYCL）；Bonsai 用 PrismML
prism分支 @2459f68 - 本文的"实测"均为本机本次（或本工作区既有报告）亲自测得，"官方"另标注
摘要
| 维度 | Qwen3.6-35B-A3B | Bonsai 2 27B | Qwen3.8-27B |
|---|---|---|---|
| 综合推荐 | 🥇 首选 | 🥈 备选（常驻/视觉） | ❌ 不建议交互式编码 |
| 架构 | MoE 35B / 激活 ~3B | dense 27B（三元 1.76 bpw） | dense 27B（Q4_K_M） |
| 权重体积 | 15.45 GiB | 5.53 GiB | 15.32 GiB |
| 生成速度（实测） | 25.32 tok/s | 11.25 tok/s | 3.93 tok/s（方差极大） |
| 提示处理 pp512/pp4096 | 335 / 340 tok/s | 122 / 124 tok/s | 96 / 94 tok/s |
| 首字延迟（实测） | 0.8~1.8 s | 1.0~1.6 s | 6.6~7.3 s |
| 加载耗时 | 46~65 s | 约 10~15 s | 80~90 s |
| 原生上下文 | 262144 | 262144 | 262144 |
| KV 成本 / token | ≈10.6 KiB | ≈34 KiB | ≈34 KiB |
| 256K 上下文可行性 | ✅ 非权重仅 3.88 GiB | ❌ 装不下 | ❌ 装不下 |
| 编程跑分（官方） | SWE-bench Verified 73.4 | ≈71.9（估算） | SWE-bench Verified 72.4 |
| 工具调用可靠性 | ✅ 好 | ⚠️ 官方承认有缺陷 | ✅ 好 |
| 内存压力下稳定性 | ✅ 稳 | ✅ 稳 | ❌ 崩到 0.6 tok/s |
| 视觉输入 | ❌ 纯文本 | ✅ 支持（可选 mmproj） | ✅ 原生视觉语言模型 |
编程能力对比
官方跑分：三者几乎持平
| 基准 | Qwen3.6-35B-A3B | Qwen3.8-27B | Bonsai 2 27B |
|---|---|---|---|
| SWE-bench Verified | 73.4 | 72.4 | ≈71.9（估算） |
| LiveCodeBench v6 | --- | 80.7 | --- |
| SWE-bench Multilingual | 67.2 | --- | --- |
| SWE-bench Pro | 49.5 | --- | --- |
| Terminal-Bench 2.0 | 51.5 | --- | --- |
| 编码项综合（厂商口径） | --- | 82.17 | 81.58 |
数据来源：
- Qwen3.6-35B-A3B 的 SWE-bench / Terminal-Bench 数字取自官方模型卡，已记录在 Qwen3.6-35B-A3B-编码部署报告.md。
- Qwen3.8-27B 的 SWE-bench Verified 72.4、LiveCodeBench v6 80.7 来自 Qwen3.8-27B 开源报道（hub.baai.ac.cn）。
- Bonsai 2 27B 的 ≈71.9 是推算值 ：PrismML 官方称其为 Qwen3.8-27B 的编码能力保留 99.3%（81.58 / 82.17）， 总体保留 98.2%（83.9 / 85.4）。推算方法为 72.4 × 0.993，不是实测 ，仅供参考 （prismml.com）。
⚠️ 注意不要混淆：PrismML 对比表里的 "Qwen3.6 27B" 是稠密 27B ，与本机的 Qwen3.6-35B-A3B（MoE）不是同一个模型。表中 Qwen3.6-27B 编码项 82.57 不能套用到本机模型。
实操验证：执行层面三者满分
用同一套提示词、同一参数（关闭思考、temperature 0.2、max_tokens 900）向三个模型各问三道题， 再把模型生成的代码抽出来实际执行 判分（脚本：compare_coding.py、grade_coding.py）。
| 题目 | 判分方式 | Qwen3.6 | Bonsai 2 | Qwen3.8 |
|---|---|---|---|---|
parse_duration 严格校验 |
6 组合法输入 + 8 组非法输入 | 14/14 | 14/14 | 14/14 |
merge_intervals 找 bug |
5 组区间用例 | 5/5 | 5/5 | 5/5 |
| 结构化 JSON 输出 | 4 项字段校验 | ✅ 全对 | ✅ 全对 | ✅ 全对 |
三道题在"代码能否运行"这一层完全没有区分度 ------三个模型都给出了正确、可运行、 带边界校验的解答。区别只出现在解释质量上，而这恰恰是编码助手最容易误导人的地方：
| 模型 | 对"这段 merge_intervals 有 bug"这一陷阱的回答 |
判定 |
|---|---|---|
| Qwen3.6-35B-A3B | "代码本身逻辑上是正确的......实际上没有 bug" | ✅ 正确（但行文反复摇摆） |
| Qwen3.8-27B | 逐步 trace 两个用例，明确"没有 bug "，并正确说明 LeetCode 语义下相邻区间应当合并 | ✅ 正确且最严谨 |
| Bonsai 2 27B | 断言"存在边界条件处理错误 "，把 <= 改成 >，并援引"LeetCode 56 要求严格重叠"作为依据 |
❌ 误判 + 虚假引用 |
Bonsai 这一题的问题值得展开，因为它是可被客观证伪的：
- 那段代码本来就正确（
[[1,4],[4,5]]→[[1,5]]是 LeetCode 56 的标准行为）。 - Bonsai 声称改成
>之后"输出应该是[(1,4),(4,5)]"------但把它自己写的代码 抽出来执行， 实际打印的仍是[(1,6),(8,10)]和[(1,5)]。它的解释与自己给出的代码自相矛盾 （start > prev_end时追加，与start <= prev_end时合并，逻辑等价）。 - 它援引的 "LeetCode 56 要求严格重叠" 是反的。
也就是说：Bonsai 的代码能跑对，但它不知道自己为什么对，并且会用错误的权威引用来支撑错误结论。 对编码助手而言，这种"自信的错误解释"比直接答错更危险。
速度对比（同参数 llama-bench）
统一参数：-ngl 99 -p 512,4096 -n 128 -r 3 -ctk q8_0 -ctv q8_0 -fa on，即与服务端实际配置一致。
| 模型 | 权重 | pp512 | pp4096 | tg128（生成） | 相对速度 |
|---|---|---|---|---|---|
| Qwen3.6-35B-A3B | 15.45 GiB | 335.09 ± 7.00 | 339.69 ± 5.39 | 25.32 ± 0.04 | 1.00×（基准） |
| Ternary-Bonsai-2-27B | 5.53 GiB | 121.98 ± 0.22 | 124.03 ± 0.06 | 11.25 ± 0.04 | 2.25× 慢 |
| Qwen3.8-27B | 15.32 GiB | 96.10 ± 0.44 | 94.45 ± 0.09 | 3.93 ± 3.36 | 6.44× 慢 |
为什么差距这么大 ：Qwen3.6-35B-A3B 是 MoE，350 亿参数里每 token 只激活约 30 亿； Bonsai 与 Qwen3.8 都是稠密 27B，每个 token 都要跑满全部 270 亿参数。 在算力受限的集成显卡上，激活参数量的差异被直接放大成 2~6 倍的速度差。
Qwen3.8 的两个危险信号
(a) llama-bench 方差 3.93 ± 3.36 ------ 标准差几乎等于均值，说明测量期间性能剧烈波动， 不是"稳定地慢"，而是"时快时慢"。
(b) 实操中直接崩塌 。三道编程题里，debug 那题（650 token 输出）耗时 1082 秒（18 分钟） ， 吞吐掉到 0.6 tok/s------比它自己正常水平（3~5 tok/s）慢了 5~8 倍。同一批测试里 Qwen3.6 只用了 35.3 秒、Bonsai 用了 73.4 秒。
这与工作区实测报告的内存结论吻合：本机 31.55 GiB ，而 系统内存占用 ≈ 权重 × 1.6 + 5.8 GiB（Windows 基线）。 Qwen3.8 与 Qwen3.6 权重都是约 15.4 GiB → 加载后系统占用约 30.5 GiB，只剩约 0.7 GiB 空闲。 此时任何一个浏览器标签、后台索引或编辑器都会把模型推进页面文件，速度断崖式下跌。 Bonsai 权重仅 5.53 GiB，留出大量余量，因此不受此影响。
真实会话中的速度衰减
从一次真实的 agentic 编码会话（Qwen3.8 在 DSH 里跑了约 40 分钟、上下文累积到 3.4 万 token）的服务端日志：
| 上下文规模 | 生成速度 |
|---|---|
| 会话初期（约 6k prompt） | 5.15 tok/s |
| 中期（734 token 连续生成） | 4.80 tok/s |
| 后期（3.4 万 token 上下文） | 3.08~3.15 tok/s |
即长会话下还会再降约 40%。对照 Qwen3.6 服务端日志（32768 上下文）： eval time = 33930 ms / 835 tokens = 24.58 tok/s，全程稳定在 24~25 tok/s，几乎不随上下文衰减。
首字延迟（交互手感）
| 模型 | write-fn | debug | structured |
|---|---|---|---|
| Qwen3.6-35B-A3B | 1.8 s | 1.4 s | 0.8 s |
| Bonsai 2 27B | 1.0 s | 1.6 s | 1.0 s |
| Qwen3.8-27B | 7.3 s | 7.2 s | 6.6 s |
Qwen3.8 的 7 秒首字延迟意味着：每次提问都要先盯着空白等 7 秒， 而它的完整回答还要再等 45 秒到 18 分钟。作为交互式编码助手，这个手感是不可接受的。
端到端：同一个 DSH agent 任务
在 DSH 里跑同一个任务（Reply with exactly: PONG，含完整系统提示词与工具 schema）：
| 模型 | 耗时 |
|---|---|
| Qwen3.6-35B-A3B | 39.4 s |
| Qwen3.8-27B | 106.9 s |
真实编程负载下的吞吐（三道题实测）
这是比合成 bench 更有代表性的数字------真实编码任务的提示词与输出长度，同一参数（关思考、temp 0.2）：
| 模型 | write-fn（270 tok） | debug（783~834 tok） | structured（50 tok） | 平均吞吐 |
|---|---|---|---|---|
| Qwen3.6-35B-A3B | 12.9 s / 20.96 t/s | 35.3 s / 23.62 t/s | 2.9 s / 17.54 t/s | ≈20.7 t/s |
| Bonsai 2 27B | 16.6 s / 10.46 t/s | 73.4 s / 10.66 t/s | 5.5 s / 9.07 t/s | ≈10.1 t/s |
| Qwen3.8-27B | 44.7 s / 4.99 t/s | 1082 s / 0.6 t/s | 15.3 s / 3.27 t/s | ≈4.1 t/s（不含崩塌样本） |
读法 ：一道普通的代码生成题（约 270 token 输出），Qwen3.6 用 13 秒，Bonsai 用 17 秒， Qwen3.8 用 45 秒；一旦输出变长（debug 题 800 token），差距会拉大到 35 秒 / 73 秒 / 最坏 18 分钟。输出越长，MoE 的优势越明显------这正是编码任务的特征。
上下文对比
原生窗口：三者相同
从 GGUF 头部读出，三个模型的原生上下文上限都是 262144（256K）：
| 模型 | 架构 | 层数 | 原生上下文 | 注意力头 (Q/KV) | 参数 |
|---|---|---|---|---|---|
| Qwen3.6-35B-A3B | qwen35moe |
40 | 262144 | 16 / 2 | 34.66 B（专家 256，激活 8） |
| Ternary-Bonsai-2-27B | qwen35 |
64 | 262144 | 24 / 4 | 26.90 B |
| Qwen3.8-27B | qwen35 |
65 | 262144 | 24 / 4 | 27.32 B |
真正决定可用性的是 KV cache 成本
窗口一样大，但装不装得下是另一回事。KV cache 单价（每 token 占用）：
| 模型 | KV 成本 / token | 来源 |
|---|---|---|
| Qwen3.6-35B-A3B | ≈10.6 KiB | llama.cpp 运行时日志实测（-lv 5） |
| Bonsai 2 27B | ≈34 KiB | 既有报告的本机对比实测（同架构，与 Qwen3.8 近似） |
| Qwen3.8-27B | ≈34 KiB | 同上 |
按该单价推算（仅 KV，不含计算缓冲与 RS buffer）：
| 模型 | 32768 | 65536 | 262144（原生满窗） |
|---|---|---|---|
| Qwen3.6-35B-A3B | 340 MiB | 680 MiB | 2720 MiB（非权重合计 3875 MiB）✅ |
| Bonsai 2 27B | ≈1.06 GiB | ≈2.13 GiB | ≈8.5 GiB ❌ |
| Qwen3.8-27B | ≈1.06 GiB | ≈2.13 GiB | ≈8.5 GiB ❌ |
注：Qwen3.6 那一行是 llama.cpp 自己打印的 KV buffer 实测值，且其"非权重合计"包含 RS buffer 与计算缓冲（262144 时共 3875 MiB）------这些额外开销在稠密模型上更大， 所以稠密模型的实际占用高于上表推算的 KV 值。
Qwen3.6 便宜 3.2 倍的原因写在 llama.cpp 的日志里： 40 层里只有 10 层带 KV cache （full_attention_interval = 4），其余 30 层是线性/循环状态 （ssm.state_size = 128）；而稠密 27B 是 65 层里 16 层全注意力。
实际含义：
- Qwen3.6-35B-A3B 在本机能真正跑满 256K 上下文（非权重合计仅 3.88 GiB）。
- Bonsai 与 Qwen3.8 在 31.55 GiB 里实际最多用到约 64K：本机实测 64K 时系统已只剩约 0.8 GiB 空闲， 再大就必然换页（这也是 Qwen3.8 出现 0.6 tok/s 崩塌的直接原因）。
- 但要注意"装得下 ≠ 等得起"：按 Qwen3.6 实测 pp 约 97~340 tok/s， 填满 256K 提示词要约 45 分钟。日常编码仍建议 32K~64K。
⚠️ 方法学提醒：
unsloth/scripts/gguf_info.py的 KV 估算对这种混合 SSM 架构高估约 7 倍 （它对 Qwen3.6 算出 80 KiB/token，而 llama.cpp 实际是 10.6 KiB/token）。 本文一律采用 llama.cpp 运行时打印的 buffer 明细，不采用该估算，也不采用"系统空闲内存"这类不可靠指标。
工程适配性（对 DSH / 编辑器而言）
| 项目 | Qwen3.6-35B-A3B | Bonsai 2 27B | Qwen3.8-27B |
|---|---|---|---|
| 工具调用（OpenAI function calling） | ✅ 实测正常 | ⚠️ 能用但有坑 | ✅ 实测正常 |
| DSH 端到端 agent 回合 | ✅ 39.4 s | ✅ 通过 | ✅ 106.9 s |
| 思考开关 | enable_thinking=false 有效（实测思考 0 token） |
有效 | 有效 |
| 是否需重新编译 llama.cpp | 否 | 是（PrismML 分支，PTQ1_0 类型上游没有） | 否 |
Bonsai 的工具调用已知缺陷 （来自 Bonsai-2-27B-部署报告.md，官方标注）： 偶尔格式错误或死循环；arguments 为空会返回 400/500（必须发 "{}"）； 系统消息必须只有一条且在开头。做 agent 要特别留意------本次 DSH 实测虽然通过了， 但那次只调用了一次工具。
选型建议
🥇 首选：Qwen3.6-35B-A3B ------ 日常本地编程的唯一合理主力
选它的理由按重要性排序：
- 速度压倒性：25.32 tok/s，是 Bonsai 的 2.25 倍、Qwen3.8 的 6.44 倍。 编码是"长输出 + 多轮工具调用"的任务，速度直接决定可用性。
- KV 最便宜：10.6 KiB/token，比另外两个省 3.2 倍，是本机唯一能真正用上 256K 上下文的模型。
- 跑分最高 ：SWE-bench Verified 73.4，三个模型里第一，且有 Terminal-Bench 2.0（51.5） 这种终端/agent 场景的跑分------这正是本地编码助手的实际使用形态。
- 工具调用可靠：DSH 端到端实测通过，且是官方定位的 agentic coding 模型。
- 速度不随上下文衰减：实测在 32K 上下文下仍稳定 24~25 tok/s； Qwen3.8 在 3.4 万 token 时会掉到 3.1 tok/s。
它的唯一代价 ：权重 15.45 GiB，加载后系统只剩约 0.7 GiB 空闲， 跑之前要关掉浏览器；且一次只能驻留它一个。
🥈 次选：Bonsai 2 27B ------ 需要常驻、需要视觉、或内存紧张时的选择
它的优势是另外两个都没有的：
- 只占 5.53 GiB （1/3 体积），留出 20+ GiB 内存余量， 可以长期常驻而不影响你正常开浏览器、开编辑器------这是它最大的实用价值。
- 加载只要约 10~15 秒（Qwen3.6 要 46~65 秒），随用随起。
- 支持图像输入 （可选加载 mmproj，0.59 GiB），是三者中唯一能读图的在跑模型 （Qwen3.8 虽原生支持视觉，但本机权重与速度都不实用）。
- 编码跑分与 Qwen3.8 几乎持平（厂商口径 81.58 vs 82.17）。
但要清楚它的两个短板：
- 工具调用有官方承认的缺陷，做多轮 agent 有风险。
- 本次实测发现它会自信地给出错误解释 + 虚假权威引用 （见 2.2 节）。 它写的代码能用，但它的讲解不能全信------把它当"能干的哑巴"用，别当"能讲解的老师"。
❌ 不推荐用于交互式编程：Qwen3.8-27B
不是因为它笨------它在本次调试题上的解释质量其实是三者中最好的， SWE-bench Verified 72.4 也与另两个持平。问题纯粹在工程可用性：
| 致命问题 | 实测数据 |
|---|---|
| 生成太慢 | 3.93 tok/s（且方差 ±3.36） |
| 首字太慢 | 6.6~7.3 s，每次提问都要干等 |
| 内存压力下崩塌 | 单题耗时 1082 s、吞吐掉到 0.6 tok/s |
| 长上下文衰减 | 3.4 万 token 时降到 3.08 tok/s |
| 端到端最慢 | 同一 DSH 任务 106.9 s（Qwen3.6 只要 39.4 s） |
什么时候还值得用它：如果某天你把它换到 8K~16K 小上下文、且不打算同时开别的程序， 它的解释质量确实最好；但对"本地编程助手"这个用途，速度劣势无法接受。
一句话流程建议
less
日常编程 -> chat-q36.cmd (Qwen3.6-35B-A3B @8081, 32K) ← 默认选这个
要读图/要常驻 -> chat-bonsai.cmd (Bonsai 2 27B @8082, 64K)
需要极高质量解释 -> chat-27b.cmd (Qwen3.8-27B @8080) ------ 但请先关掉所有浏览器三者一次只能跑一个（31.55 GiB 内存限制），启动脚本自带互斥守卫，会拒绝加载第二份权重。
复现方法
| 想复现什么 | 命令 |
|---|---|
| 同参数速度对比 | llama-bench -m <gguf> -ngl 99 -p 512,4096 -n 128 -r 3 -ctk q8_0 -ctv q8_0 -fa on -o md |
| 编程能力对比（同题同参数） | D:\AI_Tools\unsloth\run.cmd scripts\compare_coding.py <port> <label> |
| 对生成代码执行判分 | D:\AI_Tools\unsloth\run.cmd scripts\grade_coding.py |
| GGUF 架构与原生上下文 | D:\AI_Tools\unsloth\run.cmd scripts\gguf_info.py <gguf> |
本次产出的原始答卷：D:\AI_Tools\coding-compare\{qwen36-35b-a3b,bonsai-2-27b,qwen38-27b}.json （含每题正文、token 数、首字延迟、耗时、吞吐，可直接复核判分）。
附：数据来源与可信度分级
| 数据 | 来源 | 可信度 |
|---|---|---|
| 速度（pp/tg）、首字延迟、耗时、内存结论 | 本次 llama-bench + 服务端日志 + 本机实测 | 实测 |
| 生成代码的判分（14/14、5/5） | 本机执行模型生成的代码 | 实测（可复现） |
| Qwen3.6-35B-A3B SWE-bench 73.4 等 | 官方模型卡，见既有部署报告 | 官方 |
| Qwen3.8-27B SWE-bench 72.4、LiveCodeBench 80.7 | hub.baai.ac.cn | 官方（转述） |
| Bonsai 2 27B 各分项与 98.2% 保留率 | prismml.com | 厂商自评 |
| Bonsai ≈71.9 的 SWE-bench | 本文由 72.4 × 0.993 推算 | 推算，非实测 |
| 工具调用缺陷 | Bonsai-2-27B-部署报告.md（官方标注） | 官方 |