Ultra X7 358H 笔记本电脑，本地三个大模型编程能力、速度、上下文全面对比与选型报告
AI
2026-10-05
3801 字
19 分钟

到目前为止，我的笔记本电脑（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（不建议用于交互式编码）

  • 记录日期：2026-10-05
  • 机器：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-A3BBonsai 2 27BQwen3.8-27B
综合推荐🥇 首选🥈 备选（常驻/视觉）❌ 不建议交互式编码
架构MoE 35B / 激活 ~3Bdense 27B（三元 1.76 bpw）dense 27B（Q4_K_M）
权重体积15.45 GiB5.53 GiB15.32 GiB
生成速度（实测）25.32 tok/s11.25 tok/s3.93 tok/s（方差极大）
提示处理 pp512/pp4096335 / 340 tok/s122 / 124 tok/s96 / 94 tok/s
首字延迟（实测）0.8~1.8 s1.0~1.6 s6.6~7.3 s
加载耗时46~65 s约 10~15 s80~90 s
原生上下文262144262144262144
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-A3BQwen3.8-27BBonsai 2 27B
SWE-bench Verified73.472.4≈71.9（估算）
LiveCodeBench v6—80.7—
SWE-bench Multilingual67.2——
SWE-bench Pro49.5——
Terminal-Bench 2.051.5——
编码项综合（厂商口径）—82.1781.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.6Bonsai 2Qwen3.8
parse_duration 严格校验6 组合法输入 + 8 组非法输入14/1414/1414/14
merge_intervals 找 bug5 组区间用例5/55/55/5
结构化 JSON 输出4 项字段校验✅ 全对✅ 全对✅ 全对

三道题在”代码能否运行”这一层完全没有区分度——三个模型都给出了正确、可运行、 带边界校验的解答。区别只出现在解释质量上，而这恰恰是编码助手最容易误导人的地方：

模型对”这段 merge_intervals 有 bug”这一陷阱的回答判定
Qwen3.6-35B-A3B”代码本身逻辑上是正确的……实际上没有 bug”✅ 正确（但行文反复摇摆）
Qwen3.8-27B逐步 trace 两个用例，明确”没有 bug”，并正确说明 LeetCode 语义下相邻区间应当合并✅ 正确且最严谨
Bonsai 2 27B断言”存在边界条件处理错误”，把 <= 改成 >，并援引”LeetCode 56 要求严格重叠”作为依据❌ 误判 + 虚假引用

Bonsai 这一题的问题值得展开，因为它是可被客观证伪的：

  1. 那段代码本来就正确（[[1,4],[4,5]] → [[1,5]] 是 LeetCode 56 的标准行为）。
  2. Bonsai 声称改成 > 之后”输出应该是 [(1,4),(4,5)]”——但把它自己写的代码抽出来执行， 实际打印的仍是 [(1,6),(8,10)] 和 [(1,5)]。它的解释与自己给出的代码自相矛盾 （start > prev_end 时追加，与 start <= prev_end 时合并，逻辑等价）。
  3. 它援引的 “LeetCode 56 要求严格重叠” 是反的。

也就是说：Bonsai 的代码能跑对，但它不知道自己为什么对，并且会用错误的权威引用来支撑错误结论。 对编码助手而言，这种”自信的错误解释”比直接答错更危险。

速度对比（同参数 llama-bench）#

统一参数：-ngl 99 -p 512,4096 -n 128 -r 3 -ctk q8_0 -ctv q8_0 -fa on，即与服务端实际配置一致。

模型权重pp512pp4096tg128（生成）相对速度
Qwen3.6-35B-A3B15.45 GiB335.09 ± 7.00339.69 ± 5.3925.32 ± 0.041.00×（基准）
Ternary-Bonsai-2-27B5.53 GiB121.98 ± 0.22124.03 ± 0.0611.25 ± 0.042.25× 慢
Qwen3.8-27B15.32 GiB96.10 ± 0.4494.45 ± 0.093.93 ± 3.366.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-fndebugstructured
Qwen3.6-35B-A3B1.8 s1.4 s0.8 s
Bonsai 2 27B1.0 s1.6 s1.0 s
Qwen3.8-27B7.3 s7.2 s6.6 s

Qwen3.8 的 7 秒首字延迟意味着：每次提问都要先盯着空白等 7 秒， 而它的完整回答还要再等 45 秒到 18 分钟。作为交互式编码助手，这个手感是不可接受的。

端到端：同一个 DSH agent 任务#

在 DSH 里跑同一个任务（Reply with exactly: PONG，含完整系统提示词与工具 schema）：

模型耗时
Qwen3.6-35B-A3B39.4 s
Qwen3.8-27B106.9 s

真实编程负载下的吞吐（三道题实测）#

这是比合成 bench 更有代表性的数字——真实编码任务的提示词与输出长度，同一参数（关思考、temp 0.2）：

模型write-fn（270 tok）debug（783~834 tok）structured（50 tok）平均吞吐
Qwen3.6-35B-A3B12.9 s / 20.96 t/s35.3 s / 23.62 t/s2.9 s / 17.54 t/s≈20.7 t/s
Bonsai 2 27B16.6 s / 10.46 t/s73.4 s / 10.66 t/s5.5 s / 9.07 t/s≈10.1 t/s
Qwen3.8-27B44.7 s / 4.99 t/s1082 s / 0.6 t/s15.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-A3Bqwen35moe4026214416 / 234.66 B（专家 256，激活 8）
Ternary-Bonsai-2-27Bqwen356426214424 / 426.90 B
Qwen3.8-27Bqwen356526214424 / 427.32 B

真正决定可用性的是 KV cache 成本#

窗口一样大，但装不装得下是另一回事。KV cache 单价（每 token 占用）：

模型KV 成本 / token来源
Qwen3.6-35B-A3B≈10.6 KiBllama.cpp 运行时日志实测（-lv 5）
Bonsai 2 27B≈34 KiB既有报告的本机对比实测（同架构，与 Qwen3.8 近似）
Qwen3.8-27B≈34 KiB同上

按该单价推算（仅 KV，不含计算缓冲与 RS buffer）：

模型3276865536262144（原生满窗）
Qwen3.6-35B-A3B340 MiB680 MiB2720 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-A3BBonsai 2 27BQwen3.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 —— 日常本地编程的唯一合理主力#

选它的理由按重要性排序：

  1. 速度压倒性：25.32 tok/s，是 Bonsai 的 2.25 倍、Qwen3.8 的 6.44 倍。 编码是”长输出 + 多轮工具调用”的任务，速度直接决定可用性。
  2. KV 最便宜：10.6 KiB/token，比另外两个省 3.2 倍，是本机唯一能真正用上 256K 上下文的模型。
  3. 跑分最高：SWE-bench Verified 73.4，三个模型里第一，且有 Terminal-Bench 2.0（51.5） 这种终端/agent 场景的跑分——这正是本地编码助手的实际使用形态。
  4. 工具调用可靠：DSH 端到端实测通过，且是官方定位的 agentic coding 模型。
  5. 速度不随上下文衰减：实测在 32K 上下文下仍稳定 24~25 tok/s； Qwen3.8 在 3.4 万 token 时会掉到 3.1 tok/s。

它的唯一代价：权重 15.45 GiB，加载后系统只剩约 0.7 GiB 空闲， 跑之前要关掉浏览器；且一次只能驻留它一个。

🥈 次选：Bonsai 2 27B —— 需要常驻、需要视觉、或内存紧张时的选择#

它的优势是另外两个都没有的：

  1. 只占 5.53 GiB（1/3 体积），留出 20+ GiB 内存余量， 可以长期常驻而不影响你正常开浏览器、开编辑器——这是它最大的实用价值。
  2. 加载只要约 10~15 秒（Qwen3.6 要 46~65 秒），随用随起。
  3. 支持图像输入（可选加载 mmproj，0.59 GiB），是三者中唯一能读图的在跑模型 （Qwen3.8 虽原生支持视觉，但本机权重与速度都不实用）。
  4. 编码跑分与 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 小上下文、且不打算同时开别的程序， 它的解释质量确实最好；但对”本地编程助手”这个用途，速度劣势无法接受。

一句话流程建议#

日常编程          -> 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.7hub.baai.ac.cn官方（转述）
Bonsai 2 27B 各分项与 98.2% 保留率prismml.com厂商自评
Bonsai ≈71.9 的 SWE-bench本文由 72.4 × 0.993 推算推算，非实测
工具调用缺陷Bonsai-2-27B-部署报告.md（官方标注）官方
#LLM #本地部署

这篇文章是否对你有帮助？

赞助

发现错误或想要改进这篇文章？

在 GitHub 上编辑此页
Ultra X7 358H 笔记本电脑，本地三个大模型接入 DeepSeek Harness 桌面版的过程与方法
Ultra X7 358H 笔记本电脑，本地部署 Bonsai-2-27B，实测生成速度 11.6 tok/s

Copyright ©2026 bigfox.me. All Rights Reserved