离线 Agent 搭建实录Bonsai 27B 262K 上下文断网环境下干活的完整姿势【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit断网环境下的真·Agent一直是个伪命题你要的推理能力、工具调用、长文档理解统统依赖云端 API一旦断网助手立刻退回查字典模式。PrismML 在 2026 年 9 月发布的 Bonsai 2 27B 把这个问题向前推了一大步——270 亿参数的三值量化模型被压到 7.67 GB含视觉塔共 8.60 GB在一台普通笔记本上就能跑出约 47 tok/sM5 Max的推理速度同时保留了 98.2% 的 FP16 基准性能还完整继承了 262K token 的超长上下文。IT之家、金融界等多家媒体的报道口径高度一致它足以在本地承担编程智能体循环、私有文档解析、多模态调试等真正的知识工作仅在必要时才调用云端。本文不从跑个 demo的层面重复社区教程而是直接下到仓库源码层回答三个实操问题262K 上下文在离线 Agent 场景里为什么是命门断网环境下任务编排和提示词应该怎么设计以及在这个 MLX 包里资料总结、长文档问答、本地工具调用这三类任务到底能推到什么程度、边界在哪。为什么 262K 上下文对离线 Agent 是关键离线 Agent 的第一个死穴是放不下。云端 Agent 可以靠 RAG、摘要、滑动窗口这些外围手段兜底但断网环境里你的工作集working set就是那几份本地文档、整仓代码、若干轮工具调用结果全部要一次性装进上下文。上下文窗口小了Agent 就得靠截断—重述—再截断的笨办法维持状态长程任务基本没法做。262K token 意味着可以把一份几万字的技术文档、一整个中型代码仓库的索引结构、或者十几轮工具调用历史全部留在上下文里Agent 才能跨轮次记得住。但端侧模型最怕的恰恰是长上下文——传统全注意力架构的 KV cache 随序列长度平方级膨胀262K 窗口在手机和笔记本上根本是奢侈品。Bonsai 2 27B 的解法藏在 config.json 里它继承自 Qwen3.8-27B 的混合注意力骨架layer_types数组中每 4 层里前 3 层是linear_attention、第 4 层是full_attention64 层里只有 16 层走完整注意力约 75% 的注意力是线性注意力状态压缩进固定大小的 recurrent stateKV cache 压力与序列长度解耦max_position_embeddings为 262144tokenizer_config.json 中model_max_length同样为 262144模型从架构层面就支持 262K线性注意力层的 recurrent state 路径与归一化权重共 26.2M 参数约占语言模型的 0.0976%保持高精度这正是长序列下状态稳定性的来源——README 在 README.md 中明确说明这部分remain in higher precision。换句话说262K 不是靠堆显存堆出来的宣传参数而是靠把绝大部分注意力换成固定成本的状态机换来的。社区实测也印证了这一点有用户反馈小任务封神、大任务翻车翻车点几乎都集中在长上下文高负载组合下的吞吐而非能力本身——这正是线性注意力骨架的典型画像长提示词时 prefill 速度M4 Pro 上约 125 tok/s比 decode 更早成为瓶颈提示词处理是计算密集型的。理解了这一点离线 Agent 的任务设计就应该长输入、短输出把大量材料一次性灌入让模型产出精炼结果而不是靠多轮闲聊去挤信息。断网环境下 Agent 任务的编排与提示词设计离线 Agent 与在线 Agent 的编排差异本质上是一个工具纪律问题没有 API 兜底每一步都要在本地闭环。这个包把闭环需要的三样东西都带齐了。采样参数是 Agent 行为的底盘。generation_config.json 直接写明了该模型官方推荐的采样temperature1.0、top_p0.95、top_k20并开启do_sample。注意一个容易被坑的点mlx-lm / mlx-vlm 并不会读取generation_config.json不显式传采样参数时生成是贪心解码。仓库自带的 quickstart.py 里sampler_settings()专门做了这件事——从generation_config.json读温度、top_p、top_k并处理do_samplefalse和重复惩罚参数再显式传给采样器。离线搭建时任何调用路径都要复刻这一步否则 Agent 输出的多样性和稳定性都会跑偏。思维模式控制着想多久再动手。推理模型的 Agent 循环里最怕的是每步都 full thinking 导致延迟爆炸。chat_template.jinja 支持reasoning_effort参数xhigh/medium/low默认xhigh。离线场景的实操建议是规划阶段用xhigh想清楚任务分解工具调用阶段切到medium压缩思考开销——这是源码给出的显式调优杠杆而不是玄学调参。工具调用协议是全本地闭环的关键。该模型的工具格式不是 JSON function calling而是 XML 风格的标签协议定义在 chat_template.jinja 中tool_call functionexample_function_name parameterexample_parameter_1 value_1 /parameter /function /tool_call模板对模型行为的约束写得很死函数调用必须嵌套在tool_call内、参数可以跨多行、允许在函数调用前给出自然语言推理但调用后不允许追加说明工具返回结果则包裹在tool_response标签里作为 user 消息回灌。这个协议意味着你可以用最朴素的字符串解析实现工具循环——不需要引入任何 Agent 框架在断网环境里少一个依赖就少一个故障点。系统提示词方面README 给出的基线足够简单You are a helpful assistant。真正影响 Agent 表现的是把离线约束写进上下文告诉模型工具不可用时的降级策略、明确所有回答只能基于已提供的材料。值得留意的是分词器对工具标签做了专门处理tokenizer_config.json 的added_tokens_decoder中tool_call、/tool_call、tool_response、/tool_response都有独立 token id模型对工具协议的表达是被 tokenizer 直接支持的不是靠纯文本碰运气。实测场景资料总结、长文档问答、本地工具调用先把话说在前面这三类任务的能力边界仓库用 14 项 thinking-mode 基准给了硬数据见 README.md 的 Benchmarks 小节我可以把这些数据对应到具体场景而不是拍脑袋断言效果很好。资料总结与长文档问答这是 262K 上下文的甜区。知识类基准 MMLU-Redux 89.09、MuSR 70.63指令跟随 IFEval 91.31、IFBench 74.00略高于 FP16 基线的 71.00——长文本理解的底子没有被三值量化打穿。更关键的是这个包还带着完整的视觉塔0.92 GB 的 FP16 视觉塔27 层、patch 16、支持图像与视频 token见 config.json 的vision_config和 preprocessor_config.json由 vision_artifact.py 加载。这意味着总结一份带图表的 PDF对着一堆截图做 OCR 问答这类纯文本模型搞不定的长文档场景Bonsai 2 27B 可以单机完成——OCR Bench v2 56.88、MMMU-Pro 75.49 就是它的视觉基线。实操时用仓库自带的入口即可import sys sys.path.insert(0, runtime) from vision_artifact import load_vl_model, chat_config from mlx_vlm import generate from mlx_vlm.prompt_utils import apply_chat_template model, processor, config load_vl_model(.) prompt apply_chat_template(processor, chat_config(config), 总结这份文档中的技术要点, num_images1) print(generate(model, processor, prompt, [doc.png], max_tokens1024, temperature1.0, top_p0.95, top_k20))纯文本场景更简单python quickstart.py 你的长文档总结指令一行跑通quickstart.py 内部会完成模板渲染、EOS 停止同时识别|im_end|与|endoftext|、最大 256 token 的生成循环。本地工具调用能力最接近全精度、但最需要小心的一环。代理工具调用基准 BFCL v3 拿到 74.92对比 FP16 基线的 76.74——这是全部 14 项基准里与全精度差距最小的类别之一说明三值权重几乎没有损伤选工具、填参数的协议能力。但社区对上一代 1-bit Bonsai 27B 的实测曾指出工具调用存在数个百分点下滑而 Bonsai 2 27B 用的正是针对 agentic 行为做了强化的三值路线README 明确写着 Retains thinking, reasoning, and agentic behavior deep in the sub-4-bit regime。实操建议是把工具调用放进受控的循环里一次只暴露 2~3 个工具、强制tool_call格式校验、失败重试上限用 BFCL 74.92 这个数字做预期管理——它能干活但不要让它在无人监督下跑无限循环。断网环境下真要落地本地文件的读写、命令行执行这类确定性工具应该由编排层拦截校验模型只负责决策和参数生成。长程能力的真相数学与代码是它最硬的两块。MATH-500 98.80、AIME25 95.00、AIME26 95.83、LiveCodeBench 90.07对比 FP16 的 90.05编码不降反升——断网环境下的代码助手或许是比通用 Agent更现实的定位长文档整仓代码在 262K 上下文里立住工具调用做受限闭环这份配置足以覆盖大多数离线写代码、离线改 bug的实战需求。部署前必须知道的四个硬事实不能拿普通 MLX 加载器直接跑。这个包声明model_type: prism_hadamard_qwen35权重存储经过 blockwise Hadamard 旋转block 1024见 hadamard.json运行时必须对激活做匹配变换、对 embedding 做逆变换。普通 MLX 加载器跳过这些变换返回的是错误输出而不是报错。必须安装并导入仓库自带的 runtimepip install -r runtime/requirements.txt版本锁定 mlx0.32.0、mlx-lm0.31.3、mlx-vlm0.6.3通过 artifact.py 或 vision_artifact.py 加载。reload-validation.json 记录了 402 个打包模块的重载校验结果reload_logits_exact: true。内存账要算清楚。MLX 容器的 2-bit 格式每个 group 同时存 scale 和 bias实际是 2.25 bits/weight语言模型 7.67 GB、含视觉塔 8.60 GB——比 GGUF 的 PTQ1_05.95 GB胖一些这是容器属性而非表示差异packed 权重解出的三值与原版逐位一致。8 GB 显存/内存起步是务实门槛16 GB 才谈得上舒适区。吞吐与能效的真实区间。128 token 生成吞吐decode内存带宽瓶颈M5 Pro 约 28 tok/sGPU 轨 27.5 W、CPUGPU 合计 34.1 WM5 Max 约 47 tok/sRTX 5090 约 130 tok/s72 W 的 L4 也有约 30 tok/s。GGUF 的 PTQ1_0 与 PQ2_0 两种打包各有胜负PTQ1_0 每步少搬 17% 权重但在 Ada 及以下更快PQ2_0 在 Hopper/Blackwell 上 decode 更快、prefill 全面占优。许可证与合规。模型以 Apache 2.0 开放权重LICENSE商用、二次发布都没有额外门槛——离线部署到客户现场、内网服务器这类场景没有法律障碍。局限与取舍Bonsai 2 27B 不是万能的。视觉类目整体 66.19 对 FP16 的 71.36 仍有差距MMMU-Pro 从 81.73 掉到 75.49——多模态知识理解是三值化的主要成本所在知识推理类目 79.86 对 85.55 也说明百科式问答不是它的主场。它的主场是推理密度数学 96.57、代码 89.42、指令跟随 82.66这三项几乎贴着全精度基线。社区那句小任务封神、大任务翻车翻译成工程语言就是把任务拆小、把输入做长、把输出做短Bonsai 2 27B 就是一台真正能带进断网环境的 27B 级推理工作站指望它一次性端到端吞掉超大任务受限于端侧算力天花板仍然会力不从心。离线 Agent 的终局不会是手机里的 ChatGPT而是笔记本里随叫随到的私人工程师——数据不出设备、推理不依赖带宽、上下文放得下整个项目。Bonsai 2 27B 把这句口号变成了可以跑起来的工程现实。【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/9 20:30:01 · 阅读 1.2k 离线 Agent 搭建实录：Bonsai 27B + 262K 上下文，断网环境下干活的完整姿势
离线 Agent 搭建实录Bonsai 27B 262K 上下文断网环境下干活的完整姿势【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit断网环境下的真·Agent一直是个伪命题你要的推理能力、工具调用、长文档理解统统依赖云端 API一旦断网助手立刻退回查字典模式。PrismML 在 2026 年 9 月发布的 Bonsai 2 27B 把这个问题向前推了一大步——270 亿参数的三值量化模型被压到 7.67 GB含视觉塔共 8.60 GB在一台普通笔记本上就能跑出约 47 tok/sM5 Max的推理速度同时保留了 98.2% 的 FP16 基准性能还完整继承了 262K token 的超长上下文。IT之家、金融界等多家媒体的报道口径高度一致它足以在本地承担编程智能体循环、私有文档解析、多模态调试等真正的知识工作仅在必要时才调用云端。本文不从跑个 demo的层面重复社区教程而是直接下到仓库源码层回答三个实操问题262K 上下文在离线 Agent 场景里为什么是命门断网环境下任务编排和提示词应该怎么设计以及在这个 MLX 包里资料总结、长文档问答、本地工具调用这三类任务到底能推到什么程度、边界在哪。为什么 262K 上下文对离线 Agent 是关键离线 Agent 的第一个死穴是放不下。云端 Agent 可以靠 RAG、摘要、滑动窗口这些外围手段兜底但断网环境里你的工作集working set就是那几份本地文档、整仓代码、若干轮工具调用结果全部要一次性装进上下文。上下文窗口小了Agent 就得靠截断—重述—再截断的笨办法维持状态长程任务基本没法做。262K token 意味着可以把一份几万字的技术文档、一整个中型代码仓库的索引结构、或者十几轮工具调用历史全部留在上下文里Agent 才能跨轮次记得住。但端侧模型最怕的恰恰是长上下文——传统全注意力架构的 KV cache 随序列长度平方级膨胀262K 窗口在手机和笔记本上根本是奢侈品。Bonsai 2 27B 的解法藏在 config.json 里它继承自 Qwen3.8-27B 的混合注意力骨架layer_types数组中每 4 层里前 3 层是linear_attention、第 4 层是full_attention64 层里只有 16 层走完整注意力约 75% 的注意力是线性注意力状态压缩进固定大小的 recurrent stateKV cache 压力与序列长度解耦max_position_embeddings为 262144tokenizer_config.json 中model_max_length同样为 262144模型从架构层面就支持 262K线性注意力层的 recurrent state 路径与归一化权重共 26.2M 参数约占语言模型的 0.0976%保持高精度这正是长序列下状态稳定性的来源——README 在 README.md 中明确说明这部分remain in higher precision。换句话说262K 不是靠堆显存堆出来的宣传参数而是靠把绝大部分注意力换成固定成本的状态机换来的。社区实测也印证了这一点有用户反馈小任务封神、大任务翻车翻车点几乎都集中在长上下文高负载组合下的吞吐而非能力本身——这正是线性注意力骨架的典型画像长提示词时 prefill 速度M4 Pro 上约 125 tok/s比 decode 更早成为瓶颈提示词处理是计算密集型的。理解了这一点离线 Agent 的任务设计就应该长输入、短输出把大量材料一次性灌入让模型产出精炼结果而不是靠多轮闲聊去挤信息。断网环境下 Agent 任务的编排与提示词设计离线 Agent 与在线 Agent 的编排差异本质上是一个工具纪律问题没有 API 兜底每一步都要在本地闭环。这个包把闭环需要的三样东西都带齐了。采样参数是 Agent 行为的底盘。generation_config.json 直接写明了该模型官方推荐的采样temperature1.0、top_p0.95、top_k20并开启do_sample。注意一个容易被坑的点mlx-lm / mlx-vlm 并不会读取generation_config.json不显式传采样参数时生成是贪心解码。仓库自带的 quickstart.py 里sampler_settings()专门做了这件事——从generation_config.json读温度、top_p、top_k并处理do_samplefalse和重复惩罚参数再显式传给采样器。离线搭建时任何调用路径都要复刻这一步否则 Agent 输出的多样性和稳定性都会跑偏。思维模式控制着想多久再动手。推理模型的 Agent 循环里最怕的是每步都 full thinking 导致延迟爆炸。chat_template.jinja 支持reasoning_effort参数xhigh/medium/low默认xhigh。离线场景的实操建议是规划阶段用xhigh想清楚任务分解工具调用阶段切到medium压缩思考开销——这是源码给出的显式调优杠杆而不是玄学调参。工具调用协议是全本地闭环的关键。该模型的工具格式不是 JSON function calling而是 XML 风格的标签协议定义在 chat_template.jinja 中tool_call functionexample_function_name parameterexample_parameter_1 value_1 /parameter /function /tool_call模板对模型行为的约束写得很死函数调用必须嵌套在tool_call内、参数可以跨多行、允许在函数调用前给出自然语言推理但调用后不允许追加说明工具返回结果则包裹在tool_response标签里作为 user 消息回灌。这个协议意味着你可以用最朴素的字符串解析实现工具循环——不需要引入任何 Agent 框架在断网环境里少一个依赖就少一个故障点。系统提示词方面README 给出的基线足够简单You are a helpful assistant。真正影响 Agent 表现的是把离线约束写进上下文告诉模型工具不可用时的降级策略、明确所有回答只能基于已提供的材料。值得留意的是分词器对工具标签做了专门处理tokenizer_config.json 的added_tokens_decoder中tool_call、/tool_call、tool_response、/tool_response都有独立 token id模型对工具协议的表达是被 tokenizer 直接支持的不是靠纯文本碰运气。实测场景资料总结、长文档问答、本地工具调用先把话说在前面这三类任务的能力边界仓库用 14 项 thinking-mode 基准给了硬数据见 README.md 的 Benchmarks 小节我可以把这些数据对应到具体场景而不是拍脑袋断言效果很好。资料总结与长文档问答这是 262K 上下文的甜区。知识类基准 MMLU-Redux 89.09、MuSR 70.63指令跟随 IFEval 91.31、IFBench 74.00略高于 FP16 基线的 71.00——长文本理解的底子没有被三值量化打穿。更关键的是这个包还带着完整的视觉塔0.92 GB 的 FP16 视觉塔27 层、patch 16、支持图像与视频 token见 config.json 的vision_config和 preprocessor_config.json由 vision_artifact.py 加载。这意味着总结一份带图表的 PDF对着一堆截图做 OCR 问答这类纯文本模型搞不定的长文档场景Bonsai 2 27B 可以单机完成——OCR Bench v2 56.88、MMMU-Pro 75.49 就是它的视觉基线。实操时用仓库自带的入口即可import sys sys.path.insert(0, runtime) from vision_artifact import load_vl_model, chat_config from mlx_vlm import generate from mlx_vlm.prompt_utils import apply_chat_template model, processor, config load_vl_model(.) prompt apply_chat_template(processor, chat_config(config), 总结这份文档中的技术要点, num_images1) print(generate(model, processor, prompt, [doc.png], max_tokens1024, temperature1.0, top_p0.95, top_k20))纯文本场景更简单python quickstart.py 你的长文档总结指令一行跑通quickstart.py 内部会完成模板渲染、EOS 停止同时识别|im_end|与|endoftext|、最大 256 token 的生成循环。本地工具调用能力最接近全精度、但最需要小心的一环。代理工具调用基准 BFCL v3 拿到 74.92对比 FP16 基线的 76.74——这是全部 14 项基准里与全精度差距最小的类别之一说明三值权重几乎没有损伤选工具、填参数的协议能力。但社区对上一代 1-bit Bonsai 27B 的实测曾指出工具调用存在数个百分点下滑而 Bonsai 2 27B 用的正是针对 agentic 行为做了强化的三值路线README 明确写着 Retains thinking, reasoning, and agentic behavior deep in the sub-4-bit regime。实操建议是把工具调用放进受控的循环里一次只暴露 2~3 个工具、强制tool_call格式校验、失败重试上限用 BFCL 74.92 这个数字做预期管理——它能干活但不要让它在无人监督下跑无限循环。断网环境下真要落地本地文件的读写、命令行执行这类确定性工具应该由编排层拦截校验模型只负责决策和参数生成。长程能力的真相数学与代码是它最硬的两块。MATH-500 98.80、AIME25 95.00、AIME26 95.83、LiveCodeBench 90.07对比 FP16 的 90.05编码不降反升——断网环境下的代码助手或许是比通用 Agent更现实的定位长文档整仓代码在 262K 上下文里立住工具调用做受限闭环这份配置足以覆盖大多数离线写代码、离线改 bug的实战需求。部署前必须知道的四个硬事实不能拿普通 MLX 加载器直接跑。这个包声明model_type: prism_hadamard_qwen35权重存储经过 blockwise Hadamard 旋转block 1024见 hadamard.json运行时必须对激活做匹配变换、对 embedding 做逆变换。普通 MLX 加载器跳过这些变换返回的是错误输出而不是报错。必须安装并导入仓库自带的 runtimepip install -r runtime/requirements.txt版本锁定 mlx0.32.0、mlx-lm0.31.3、mlx-vlm0.6.3通过 artifact.py 或 vision_artifact.py 加载。reload-validation.json 记录了 402 个打包模块的重载校验结果reload_logits_exact: true。内存账要算清楚。MLX 容器的 2-bit 格式每个 group 同时存 scale 和 bias实际是 2.25 bits/weight语言模型 7.67 GB、含视觉塔 8.60 GB——比 GGUF 的 PTQ1_05.95 GB胖一些这是容器属性而非表示差异packed 权重解出的三值与原版逐位一致。8 GB 显存/内存起步是务实门槛16 GB 才谈得上舒适区。吞吐与能效的真实区间。128 token 生成吞吐decode内存带宽瓶颈M5 Pro 约 28 tok/sGPU 轨 27.5 W、CPUGPU 合计 34.1 WM5 Max 约 47 tok/sRTX 5090 约 130 tok/s72 W 的 L4 也有约 30 tok/s。GGUF 的 PTQ1_0 与 PQ2_0 两种打包各有胜负PTQ1_0 每步少搬 17% 权重但在 Ada 及以下更快PQ2_0 在 Hopper/Blackwell 上 decode 更快、prefill 全面占优。许可证与合规。模型以 Apache 2.0 开放权重LICENSE商用、二次发布都没有额外门槛——离线部署到客户现场、内网服务器这类场景没有法律障碍。局限与取舍Bonsai 2 27B 不是万能的。视觉类目整体 66.19 对 FP16 的 71.36 仍有差距MMMU-Pro 从 81.73 掉到 75.49——多模态知识理解是三值化的主要成本所在知识推理类目 79.86 对 85.55 也说明百科式问答不是它的主场。它的主场是推理密度数学 96.57、代码 89.42、指令跟随 82.66这三项几乎贴着全精度基线。社区那句小任务封神、大任务翻车翻译成工程语言就是把任务拆小、把输入做长、把输出做短Bonsai 2 27B 就是一台真正能带进断网环境的 27B 级推理工作站指望它一次性端到端吞掉超大任务受限于端侧算力天花板仍然会力不从心。离线 Agent 的终局不会是手机里的 ChatGPT而是笔记本里随叫随到的私人工程师——数据不出设备、推理不依赖带宽、上下文放得下整个项目。Bonsai 2 27B 把这句口号变成了可以跑起来的工程现实。【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考