全网吹手机 DeepSeek 时刻我先泼盆冷水Tool Calling 掉点Agent 场景还没资格吹【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit7 月中旬Prism ML 发布 Bonsai 27B第三方社区立刻把它抬进手机 AI 的 DeepSeek 时刻的叙事里AnythingLLM 创始人在社交媒体上公开喊话这才是 AI 真正的 DeepSeek 时刻12GB 内存的 iPhone 17 Pro 能原生跑 27B 模型一时间端侧 27B成为流量密码。两个月后基于 Qwen3.8-27B 的 Bonsai 2 27B 带着更漂亮的数字登场——以不到 1/9 的内存占用在 14 项 thinking 模式基准上保留了基础模型 98.2% 的综合分数README.md。98.2%这个数字确实惊艳。但如果只看这个平均数你会错过真正的重点平均数掩盖了结构性掉点。把 README.md 里的逐项成绩摊开看数学、代码这些答题型能力几乎无损而 Agent 场景最核心的 Tool Calling 掉了近 2 个百分点视觉能力掉了 5 个点以上。量化模型的甜区有多甜禁区就有多刺眼。Tool Calling 掉点数据复盘到底掉了多少先看硬数据。Bonsai 2 27B 的官方评测在 NVIDIA H100 上用 EvalScope vLLM 统一跑 14 项基准BFCL v3工具调用基准的成绩是模型BFCL v3Qwen3.8-27B FP1676.74Bonsai 2 27B三值74.92Qwen3.8-27B UD-Q4_K_XL75.05Qwen3.8-27B IQ2_XXS70.28完整数据见 README.md 的 Benchmark 章节从 76.74 到 74.92掉了1.82 分保留率约 97.6%。横向看三值 Bonsai 的 Tool Calling 依然压过所有传统低比特方案——比2-bit的 IQ2_XXS 高 4.6 分逼近 Q4_K_XL——这说明端到端低比特训练而非事后量化确实保住了大部分能力。但关键事实没变BFCL v3 是 14 项基准里掉点最明显的类别之一仅次于视觉71.36 → 66.19掉 5.17 分和知识与推理85.55 → 79.86掉 5.69 分。对照第一代 Bonsai 27B 的社区实测这个结论是稳定的CSDN 多篇实测文章都记录到Math/Coding 能力保留良好但 Tool Calling 存在数个百分点下降。也就是说工具调用掉点不是 Bonsai 2 的孤立现象而是低比特模型在 Agent 维度上的系统性短板只是这一代把它压缩到了2 分以内。为什么掉点直接动摇 Agentic 场景的可靠性2 个百分点的平均掉点在单轮问答里几乎无感但在 Agent 场景里会被放大成灾难性的东西。原因在于 Agent 的错误传播模型和基准的评测模型根本不是一回事。BFCL v3 测的是单步工具调用的正确性给一个 query 和一组 schema模型选对函数、填对参数就算过。而真实的 agentic loop 是 N 步串联的——调用工具、读结果、再决策、再调用。如果每一步的失败率是 pN 步之后整体成功率约等于 (1-p)^N。BFCL 上 97.6% 的单步保留率看似可观但在一个 10 步的 agent 任务里相当于把基准掉点放大了接近一个数量级。更麻烦的是工具调用错误不像文本生成错误那样看起来还能用——参数填错、函数选错直接导致下游流程断裂且端侧本地跑通常意味着没有云端大模型兜底重试。这正是 Bonsai 2 官方 README.md 里措辞最微妙的地方它在 Highlights 里强调retains thinking, reasoning, and agentic behavior deep in the sub-4-bit regime配的数字恰恰是 agentic tool calling 74.92——一个官方自己承认低于基线的数字。而在 By Skill Category 表格里Agentic / tool calling 是除视觉外掉点最大的类别。技术文档没有说谎但保留了 agentic 行为和Agent 场景可以放心用之间隔着一整条错误累积曲线。另一个被宣传话术掩盖的技术事实是这个 MLX 包不是拿来即用的普通量化模型。它在 config.json 里声明model_type: prism_hadamard_qwen35权重经过分块 Hadamard 旋转hadamard.json 记录 block_size1024 与显式符号向量必须加载仓库自带的运行时runtime/runtime.py 中的fwht与Packed模块普通 MLX 加载器会静默返回错误输出而不是报错见 quickstart.py 顶部注释。这意味着任何想在端侧 Agent 栈里接入这个模型的团队都得先消化一套定制运行时契约而不是pip install完事。部署摩擦本身就是 Agent 场景还没资格吹的另一个注脚。量化模型的甜区与禁区如何理性划分Bonsai 2 27B 的真正成就不在手机跑 27B的营销点而在于它把低比特模型的损失结构从均匀退化变成了选择性退化。看 README.md 的 By Skill Category 表类别FP16Bonsai 2 27B差值数学97.0696.57-0.49编程89.0789.420.35指令跟随81.2582.661.41Agentic / 工具调用76.7474.92-1.82视觉71.3666.19-5.17知识与推理85.5579.86-5.69结论非常清晰甜区数学、编程、指令跟随。这几项不仅没掉指令跟随甚至反超基线。AIME26 拿了 95.83FP16 为 94.58LiveCodeBench 90.07 与基线持平——单看这些数字一个 1.72 bits/weight 的模型能保持 27B 规模的推理链完整性这在技术上是实打实的突破对照传统 IQ2_XXS 在 AIME26 上崩到 57.5 的选择性坍缩见 README.md 对常规低比特方案的描述。禁区多轮依赖型任务。工具调用、视觉理解、长链知识推理掉点从 2 到 5.7 分不等。其中视觉尤其值得警惕——README.md 自己都注明 0.92GB 视觉塔是未量化的 FP16 原版也就是说视觉掉点还不是量化权重造成的而是三值化主干对多模态对齐的连带损伤。这部分不是再优化一下量化格式能解决的需要架构层面的低比特多模态训练。理性用法是分层的单轮、确定性强的任务可以大胆本地化数学求解、代码补全与仓库级阅读262K 上下文 混合注意力约 75% 线性注意力见 config.json 的layer_types与full_attention_interval: 4、离线文档问答、隐私敏感的单发处理。这类任务的错误是可检、可重试的。Agent 场景必须带护栏要么人机回环工具调用结果人工确认后再进入下一步要么保留云端 API 作为失败分支Prism ML 官方在发布稿里也承认仅在需要时才调用云端 API要么对调用结果做 schema 级校验。不要拿它做无人值守的多步自动执行。性能账要算清楚MLX 容器每 128 权重存一份 scale bias实际存储成本 2.25 bits/weight高于 GGUF 的 PTQ1_01.75与 PQ2_02.13见 README.md 的 Memory Requirement 表。同一个权重在不同容器里尺寸差接近 2GB选后端不是选口味是选体积。最后回到那句手机 DeepSeek 时刻。一个能在 8.6GB 里装下 27B 语言模型加视觉塔、在 M5 Max 上跑到约 47 tok/sREADME.md的工程成果配得上很多溢美之词。但DeepSeek 时刻式的叙事默认了本地能跑 本地能顶替云端而 Bonsai 2 用自己公布的 BFCL 数字给出了否定的回答在真正需要多步自主性的场景里它掉的那 1.8 分恰好是可靠性生死线所在的那 1.8 分。夸它工程创新站得住吹它 Agent 已就绪数据不支持。冷水的价值不在于否定而在于把兴奋剂换成刻度尺甜区放心用禁区上护栏剩下的交给下一版架构。【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/10 12:34:15 · 阅读 1.2k 全网吹“手机 DeepSeek 时刻“，我先泼盆冷水：Tool Calling 掉点，Agent 场景还没资格吹
全网吹手机 DeepSeek 时刻我先泼盆冷水Tool Calling 掉点Agent 场景还没资格吹【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit7 月中旬Prism ML 发布 Bonsai 27B第三方社区立刻把它抬进手机 AI 的 DeepSeek 时刻的叙事里AnythingLLM 创始人在社交媒体上公开喊话这才是 AI 真正的 DeepSeek 时刻12GB 内存的 iPhone 17 Pro 能原生跑 27B 模型一时间端侧 27B成为流量密码。两个月后基于 Qwen3.8-27B 的 Bonsai 2 27B 带着更漂亮的数字登场——以不到 1/9 的内存占用在 14 项 thinking 模式基准上保留了基础模型 98.2% 的综合分数README.md。98.2%这个数字确实惊艳。但如果只看这个平均数你会错过真正的重点平均数掩盖了结构性掉点。把 README.md 里的逐项成绩摊开看数学、代码这些答题型能力几乎无损而 Agent 场景最核心的 Tool Calling 掉了近 2 个百分点视觉能力掉了 5 个点以上。量化模型的甜区有多甜禁区就有多刺眼。Tool Calling 掉点数据复盘到底掉了多少先看硬数据。Bonsai 2 27B 的官方评测在 NVIDIA H100 上用 EvalScope vLLM 统一跑 14 项基准BFCL v3工具调用基准的成绩是模型BFCL v3Qwen3.8-27B FP1676.74Bonsai 2 27B三值74.92Qwen3.8-27B UD-Q4_K_XL75.05Qwen3.8-27B IQ2_XXS70.28完整数据见 README.md 的 Benchmark 章节从 76.74 到 74.92掉了1.82 分保留率约 97.6%。横向看三值 Bonsai 的 Tool Calling 依然压过所有传统低比特方案——比2-bit的 IQ2_XXS 高 4.6 分逼近 Q4_K_XL——这说明端到端低比特训练而非事后量化确实保住了大部分能力。但关键事实没变BFCL v3 是 14 项基准里掉点最明显的类别之一仅次于视觉71.36 → 66.19掉 5.17 分和知识与推理85.55 → 79.86掉 5.69 分。对照第一代 Bonsai 27B 的社区实测这个结论是稳定的CSDN 多篇实测文章都记录到Math/Coding 能力保留良好但 Tool Calling 存在数个百分点下降。也就是说工具调用掉点不是 Bonsai 2 的孤立现象而是低比特模型在 Agent 维度上的系统性短板只是这一代把它压缩到了2 分以内。为什么掉点直接动摇 Agentic 场景的可靠性2 个百分点的平均掉点在单轮问答里几乎无感但在 Agent 场景里会被放大成灾难性的东西。原因在于 Agent 的错误传播模型和基准的评测模型根本不是一回事。BFCL v3 测的是单步工具调用的正确性给一个 query 和一组 schema模型选对函数、填对参数就算过。而真实的 agentic loop 是 N 步串联的——调用工具、读结果、再决策、再调用。如果每一步的失败率是 pN 步之后整体成功率约等于 (1-p)^N。BFCL 上 97.6% 的单步保留率看似可观但在一个 10 步的 agent 任务里相当于把基准掉点放大了接近一个数量级。更麻烦的是工具调用错误不像文本生成错误那样看起来还能用——参数填错、函数选错直接导致下游流程断裂且端侧本地跑通常意味着没有云端大模型兜底重试。这正是 Bonsai 2 官方 README.md 里措辞最微妙的地方它在 Highlights 里强调retains thinking, reasoning, and agentic behavior deep in the sub-4-bit regime配的数字恰恰是 agentic tool calling 74.92——一个官方自己承认低于基线的数字。而在 By Skill Category 表格里Agentic / tool calling 是除视觉外掉点最大的类别。技术文档没有说谎但保留了 agentic 行为和Agent 场景可以放心用之间隔着一整条错误累积曲线。另一个被宣传话术掩盖的技术事实是这个 MLX 包不是拿来即用的普通量化模型。它在 config.json 里声明model_type: prism_hadamard_qwen35权重经过分块 Hadamard 旋转hadamard.json 记录 block_size1024 与显式符号向量必须加载仓库自带的运行时runtime/runtime.py 中的fwht与Packed模块普通 MLX 加载器会静默返回错误输出而不是报错见 quickstart.py 顶部注释。这意味着任何想在端侧 Agent 栈里接入这个模型的团队都得先消化一套定制运行时契约而不是pip install完事。部署摩擦本身就是 Agent 场景还没资格吹的另一个注脚。量化模型的甜区与禁区如何理性划分Bonsai 2 27B 的真正成就不在手机跑 27B的营销点而在于它把低比特模型的损失结构从均匀退化变成了选择性退化。看 README.md 的 By Skill Category 表类别FP16Bonsai 2 27B差值数学97.0696.57-0.49编程89.0789.420.35指令跟随81.2582.661.41Agentic / 工具调用76.7474.92-1.82视觉71.3666.19-5.17知识与推理85.5579.86-5.69结论非常清晰甜区数学、编程、指令跟随。这几项不仅没掉指令跟随甚至反超基线。AIME26 拿了 95.83FP16 为 94.58LiveCodeBench 90.07 与基线持平——单看这些数字一个 1.72 bits/weight 的模型能保持 27B 规模的推理链完整性这在技术上是实打实的突破对照传统 IQ2_XXS 在 AIME26 上崩到 57.5 的选择性坍缩见 README.md 对常规低比特方案的描述。禁区多轮依赖型任务。工具调用、视觉理解、长链知识推理掉点从 2 到 5.7 分不等。其中视觉尤其值得警惕——README.md 自己都注明 0.92GB 视觉塔是未量化的 FP16 原版也就是说视觉掉点还不是量化权重造成的而是三值化主干对多模态对齐的连带损伤。这部分不是再优化一下量化格式能解决的需要架构层面的低比特多模态训练。理性用法是分层的单轮、确定性强的任务可以大胆本地化数学求解、代码补全与仓库级阅读262K 上下文 混合注意力约 75% 线性注意力见 config.json 的layer_types与full_attention_interval: 4、离线文档问答、隐私敏感的单发处理。这类任务的错误是可检、可重试的。Agent 场景必须带护栏要么人机回环工具调用结果人工确认后再进入下一步要么保留云端 API 作为失败分支Prism ML 官方在发布稿里也承认仅在需要时才调用云端 API要么对调用结果做 schema 级校验。不要拿它做无人值守的多步自动执行。性能账要算清楚MLX 容器每 128 权重存一份 scale bias实际存储成本 2.25 bits/weight高于 GGUF 的 PTQ1_01.75与 PQ2_02.13见 README.md 的 Memory Requirement 表。同一个权重在不同容器里尺寸差接近 2GB选后端不是选口味是选体积。最后回到那句手机 DeepSeek 时刻。一个能在 8.6GB 里装下 27B 语言模型加视觉塔、在 M5 Max 上跑到约 47 tok/sREADME.md的工程成果配得上很多溢美之词。但DeepSeek 时刻式的叙事默认了本地能跑 本地能顶替云端而 Bonsai 2 用自己公布的 BFCL 数字给出了否定的回答在真正需要多步自主性的场景里它掉的那 1.8 分恰好是可靠性生死线所在的那 1.8 分。夸它工程创新站得住吹它 Agent 已就绪数据不支持。冷水的价值不在于否定而在于把兴奋剂换成刻度尺甜区放心用禁区上护栏剩下的交给下一版架构。【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考