本地 LLM 社区过去一年有一个明显分层：7B 到 12B 模型越来越快，适合聊天、摘要和轻工具；30B 级模型质量更稳，但显存和内存门槛高；70B 以上模型则更多留给高端工作站或服务器。PrismML Bonsai 27B 把这个分层搅动了一下。它把 Qwen3.6-27B 做成 1-bit 和 ternary 低比特版本，官方称 1-bit 版本约 3.9GB，ternary 版本约 5.9GB 或 7.2GB 部署占用，Hugging Face GGUF 页面也强调相对 FP16 的巨大内存下降。
这类发布很容易被两种极端声音包围。一边会说“27B 跑手机，革命来了”；另一边会说“低比特一定损失严重，不值得”。工具速评应该更具体：它对什么任务有价值，对什么任务不该赌，怎么在自己的机器上验证。
Bonsai 27B 到底改变了什么
Bonsai 27B 不是一个从零训练的新基础模型，而是 PrismML 对 Qwen3.6-27B 的低比特重构。官方新闻稿描述了两个主要变体：ternary 使用 {-1, 0, +1} 权重并配合 FP16 group-wise scaling，1-bit 使用 {-1, +1} 权重。它们的目标不是追求绝对最高质量，而是在极低内存下保留尽可能多的 reasoning、tool-calling 和 agentic capability。
这对本地开发者重要，因为很多 agent 任务不需要每次都上最强闭源模型。你可能只想在本机私有资料上做摘要，给浏览器自动化写计划，给本地代码仓库做导航，或者让助手在后台整理 transcript。这些任务要求模型足够聪明、足够便宜、足够隐私友好，并且能长时间运行。
传统 8B 小模型便宜，但在复杂工具调用和长指令里容易掉链子。完整 27B 或 35B 模型更稳，但显存压力大。Bonsai 27B 尝试给出一个中间点：用低比特牺牲一部分鲁棒性，换来接近中尺寸模型的参数结构和更低部署门槛。
先看部署形态
目前最值得关注的是 GGUF 和 MLX 两条线。GGUF 适合 llama.cpp、LM Studio、Ollama 生态；MLX 适合 Apple Silicon。Hugging Face 上有 prism-ml/Ternary-Bonsai-27B-gguf、prism-ml/Bonsai-27B-gguf 和 MLX 相关版本。LM Studio 模型页也把 Bonsai 27B 标成具备 vision、reasoning、tool use 和长上下文能力的本地模型家族。
如果你只是尝鲜，可以先用 LM Studio 或 llama.cpp。严肃测试则建议固定运行参数，避免体感误差。
llama-cli \
-m ./models/ternary-bonsai-27b.gguf \
-p "Summarize this repository structure and propose three safe refactors." \
-n 1024 \
-c 8192 \
--temp 0.2上下文窗口不要一开始就拉满。低比特模型的长上下文稳定性需要单独测，尤其是工具调用任务中，函数 schema、历史观察和用户约束会占用大量 token。先从 8K 或 16K 起步，确认稳定后再扩展。
本地 Agent 评测不要只聊几句
LocalLLaMA 讨论里既有用户反馈 ternary 版本速度和质量令人惊喜，也有独立测试指出某些任务上明显落后于更大或不同量化模型。两者并不矛盾。低比特模型的表现经常高度任务相关：聊天可以很顺，工具参数却不稳；摘要看起来很好，代码边界却错；短上下文没问题，长上下文后半段开始遗忘约束。
所以评测要围绕 agent 常见失败模式设计。建议准备五组任务：
- 工具调用：给定函数 schema，让模型选择工具、填参数、解释结果。
- 代码导航：让模型在仓库摘要中定位可能修改的文件。
- 长文压缩：输入多段会议记录，要求保留行动项和负责人。
- 多轮约束：先给禁止项，再让模型连续三轮规划，检查是否越界。
- 拒答和确认：涉及删除、支付、生产账号时，检查是否要求人工确认。
每组至少 6 到 10 个样本，记录成功率和错误类型。不要用“回答听起来聪明”当指标。
一个简单工具调用测试
下面是可运行的 Python 测试骨架，用于把模型输出和期望工具名做粗粒度比较。你需要把 call_local_model 替换成自己的 llama.cpp server、Ollama 或 LM Studio API。
from dataclasses import dataclass
@dataclass
class Case:
prompt: str
expected_tool: str
CASES = [
Case(
prompt="User asks to summarize local notes without internet. Tools: read_file, web_search, send_email.",
expected_tool="read_file",
),
Case(
prompt="User asks to send the final invoice to finance. Tools: read_file, draft_email, send_email.",
expected_tool="draft_email",
),
]
def call_local_model(prompt: str) -> str:
raise NotImplementedError("Connect this to your local inference server.")
def evaluate():
passed = 0
for case in CASES:
output = call_local_model(case.prompt)
ok = case.expected_tool in output
passed += int(ok)
print({"expected": case.expected_tool, "ok": ok, "output": output[:240]})
print(f"score={passed}/{len(CASES)}")
if __name__ == "__main__":
evaluate()这个测试很粗，但能快速暴露一个问题：模型是否理解工具边界。很多本地模型在聊天时表现好，一遇到“先 draft，不要直接 send”就会越权。对于本地 agent，这比常规知识问答重要得多。
ternary 更像严肃选择
如果目标是本地 agent，我会优先测 ternary 而不是 1-bit。原因很简单：agent 任务对小错误非常敏感。工具名错一个字符、JSON 少一个字段、权限边界理解错一次，都会导致失败。1-bit 版本的卖点是极低内存和极强演示效果，但它更适合 casual chat、摘要草稿和设备端实验。
ternary 版本保留质量更多，内存仍然远低于常规 Q4 27B。它不是免费的午餐，但更像可以进入认真评测的候选模型。PrismML 官方称其在 15 个 thinking-mode benchmark 上保留很高比例 FP16 intelligence；社区也有用户报告速度明显提升。不过你仍然应该把官方 benchmark 当参考，而不是上线证据。
和 12B、35B 的取舍
真正的竞争对手不是 FP16 27B，而是你手头已经能跑的 12B QAT、20B、MoE 35B 和云端小模型。
与 12B 相比，Bonsai 27B 的潜在优势是参数规模更大，复杂指令和多步推理可能更稳；潜在劣势是低比特损失可能让某些语言、数学、代码和格式任务不稳定。
与 35B 或 MoE 相比，它的优势是部署简单和内存占用低；劣势是质量上限可能不如更高比特或更强架构。对 16GB 显存用户来说，ternary Bonsai 27B 很值得测；对已经能舒服跑优质 35B 的用户来说，它更像速度和成本选项。
适用边界
Bonsai 27B 适合这些场景：
第一，本地隐私知识库。资料不出机器，模型做摘要、聚类、问答草稿。第二，轻量 coding assistant。它可以读片段、解释函数、提出改法，但最终 diff 需要强检查。第三，后台资料处理 agent。比如批量整理 transcript、抽取行动项、生成初稿。第四，低成本工具路由。让它判断是否需要搜索、读文件、调用本地脚本。
不适合这些场景：
无人监管地修改生产系统，自动执行支付或删除，安全敏感代码审计，复杂跨仓重构，高准确率法律医疗金融问答，以及任何一次错误代价很高的流程。
结论
Bonsai 27B 的价值在于把本地 LLM 的中尺寸选择重新打开。它不等于“27B 无损跑手机”，也不只是“低比特玩具”。更准确的定位是：在内存受限设备上，以可接受质量运行一个具备 27B 级结构的本地模型，尤其适合可复核的 agent 和工具调用实验。
我的建议是：想做本地 agent，先测 ternary；想做极低内存演示，再测 1-bit。所有结论都要回到自己的任务集，用成功率、错误类型、延迟和显存说话。低比特模型最容易制造体感惊喜，也最容易在边界任务上露出裂缝。把 Bonsai 27B 放进严肃评测，而不是只放进聊天窗口，才能判断它是不是你的下一台本地 agent 引擎。
参考来源：PrismML Bonsai 27B 发布说明、Ternary Bonsai 27B GGUF、Bonsai 27B GGUF、LocalLLaMA 讨论、Hacker News 讨论。