3.9GB 里藏了什么Bonsai 的混合注意力 推测解码 262K 上下文端侧架构逐层拆【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit当27B 参数大模型能装进 12GB 内存的手机从 PPT 变成可下载的权重文件时社区给出了一个极高的评价——AnythingLLM 创始人把 Bonsai 称作AI 的 DeepSeek 时刻认为其影响比 GPT 5.6 更重要。这个判断的底气来自 Prism ML 的极端低比特路线把 16-bit 下需要 54GB 的 27B 级模型一路压到 3.9GB1-bit 手机版、5.9GB2-bit 笔记本版并且保留 90%–98% 的智能水平。数字很漂亮但真正值得技术人逐层拆解的是这些数字背后的三样东西混合注意力如何把 KV 缓存从线性增长变成近似恒定三值权重 折叠 Hadamard 旋转如何做到名实相符的低比特以及MLX / GGUF 两套打包格式如何在位级上把压缩变成可执行。本文以本仓库Ternary-Bonsai-2-27B-mlx-2bit的源码与元数据为准绳把 Bonsai 的端侧架构从外层壳到内核逐层剥开。先厘清一个数字3.9GB 是谁的体积选题标题里的 3.9GB严格说属于 Bonsai 27B 的1-bit 变体——社区报道中它的规格是3.9GB 体积、每权重约 1.125 有效位、专门为 iPhone 级别的内存与能效优化实测约 11 tok/s同时发布的 2-bitTernary变体则为 5.9GB、每权重约 1.71 有效位面向笔记本级质量。而本仓库是这条产品线的第二代Bonsai 2 27B 基于 Qwen3.8-27B 训练而来README.md 的base_model字段明确声明其 MLX 打包完整体积为8.60GB7.67GB 语言模型 0.92GB 未量化的视觉塔以 2.25 bits/weight 的 MLX 容器格式落地。比第一代更进一步的是质量账本在 14 项 thinking-mode 基准上拿到84.78 的平均分相当于 FP16 基模86.32的 98.2%——注意对比口径常规低比特路线里标称2-bit的 IQ2_XXS 构建真实位宽 2.8 bpw、体积 9.4GB只拿到 72.59 分。变体有效位宽体积定位Bonsai 27B 1-bit~1.125 bpw3.9GB手机级12GB 内存 iPhoneBonsai 27B Ternary~1.71 bpw5.9GB笔记本级Bonsai 2 27B MLX本仓库2.25 bpw8.60GB含视觉塔笔记本级 多模态3.9GB 里藏了什么这个问题答案其实横跨了这三个变体共同的技术内核。下面逐层拆。混合注意力把 262K 上下文塞进端侧的第一道闸门端侧跑长上下文第一杀手是 KV 缓存。全注意力下缓存随序列长度线性膨胀262K token 在手机上根本无从谈起。Bonsai 的解法不在量化层而在基模架构层——Qwen3.8-27B 本身就是一个混合注意力模型Bonsai 完整继承了它config.json 的layer_types数组把 64 层逐一列明每 4 层中 3 层是linear_attention、1 层是full_attention即约 75% 线性注意力 25% 全注意力full_attention_interval: 4与之对应。全注意力层24 个注意力头、GQA 下压到 4 个 KV 头num_key_value_heads: 4、head_dim: 256负责全局精确检索线性注意力层linear_num_key_heads: 16、linear_num_value_heads: 48、linear_key_head_dim: 128、linear_value_head_dim: 128、linear_conv_kernel_dim: 4通过递归状态路径mamba_ssm_dtype: float32把历史压缩进恒定尺寸的状态KV 缓存从 O(序列长度) 变成 O(1)。这正是 262K 上下文max_position_embeddings: 262144在端侧可行的根源占 75% 的层不随序列增长吃内存只有 25% 的全注意力层保留完整的键值历史。README 还披露了一个容易被忽略的细节——模型中有 26.2M 参数占语言模型的 0.0976%刻意保持高精度线性注意力层的递归状态路径与归一化权重。这批逃逸的高精度参数是长上下文递归稳定性与数值健康的关键也意味着 1.72 bits/weight 是把该量化的都量化了之后的真实数字。线性注意力头在 GGUF 源模型里有一套独特的 GDN 布局48 个 value head 与 16 个 key head 分组交错runtime/runtime.py 里的vperm()与reorder()函数专门处理这套重排——加载时按nv // nk分组做转置插回 MLX 的TextModel任何一个 head 落错槽位长上下文推理就会静默漂移。这类看不见的工程和 KV 压缩本身一样重要。三值权重 折叠 Hadamard 旋转3.9GB 的底层引擎体积能压到 3.9GB靠的是训练阶段就约束好的端到端低比特表示——这与微软 BitNet b1.58 同一条技术路线而非传统意义上的事后量化再救回。三值 g128每个权重只有 1.585 bit 的信息权重取值被硬约束在{−1, 0, 1}每 128 个权重共享一个 FP16 缩放因子README.md 的 Weight Representation 一节。一个三值携带 log₂3 ≈ 1.585 bit摊上 16-bit scale 每 128 权重摊销 0.125 bit再加上少量高精度残留张量全模型真实位宽1.72 bits/weight相对 FP16 是约 9.3 倍压缩。对比同行许多标称2-bit的构建实际平均位宽 2.8 bpw——Bonsai 强调自己是名实相符的 1.72。Hadamard 旋转把量化误差抹平的免费午餐三值化的痛点在于把权重硬截到三个电平会放大离群值带来的误差。Bonsai 的做法是先旋转、再量化每个权重矩阵按块block 1024做正交 Hadamard 变换把能量在维度间打散降低逐维截断的方差旋转后的 ±1 符号向量按宽度显式记录在 hadamard.jsonprism.hadamard.transform: normalized-sylvester-walsh-hadamardblock_size: 1024sign_mode: explicit宽度 5120 / 6144 / 17408 三档。关键设计是旋转被折叠进存储权重离线转换时权重已经处于旋转基运行时只需对激活施加匹配变换因此旋转不花额外 bit、不产生额外权重流量。代价是加载契约变严格——普通 MLX 加载器不会做激活变换和逆 embedding 查找会给出错误但不报错的输出。所以本仓库声明了model_type: prism_hadamard_qwen35并强制要求配套 runtimePACK-RUNTIME.md 明确写了这一点。旋转在推理热路径上的实现在 runtime/runtime.py 的Packed模块里逻辑非常紧凑def __call__(self, x): if self.embedding: # 逆变换embedding 查表后做反向 Hadamard ... return fwht(out, self.block, self.signs, inverseTrue) if self.block else out if self.block: x fwht(x, self.block, self.signs) # 前向激活先做 Hadamard return mx.quantized_matmul( x, self.weight, self.scales, self.biases, transposeTrue, group_size128, bits2, )fwht()用mx.hadamard_transform(..., scale1/sqrt(block))实现快速 Walsh–Hadamard 变换前向乘符号、逆向再乘符号。而量化与矩阵乘是融合的quantized_matmul直接消费打包后的 2-bit 权重永远不会展开回 FP16——这是端侧算力预算下最重要的算子级优化社区讨论中常与 GQA、线性注意力的算子融合并列为端侧部署的关键工程在 Android/JNI、QNN/Core ML 路线上同理。打包格式的工程MLX 2.25 bits 与 GGUF 的两种装箱位宽 1.72是表示层面的理论值落到具体推理框架装箱格式决定真实体积与解码成本。本仓库的 README.md 给了一张诚实的对照表格式真实 bits/weight体积语言模型压缩比FP16 基模16.0~54GB1.0x三值 g128 理想1.725.8GB~9.3xGGUF PTQ1_0稠密 trit1.755.95GB~9.0xGGUF PQ2_02-bit 槽2.137.21GB~7.5xMLX 2-bit本仓库2.257.67GB~7.0xMLX 的分组低比特容器对每组同时存scale 和 bias两个 FP16——三值电平{-s, 0, s}用scales, bias-s可精确复现2-bit 码{0,1,2}解码为-s/0/s。bias 不携带新信息但容器每 128 权重多存了一个 FP16所以有效速率是 2.25 bits/weight 而非 PQ2_0 的 2.13。README 特别说明这是容器属性而非表示差异——MLX 打包权重解码后与 GGUF 各 band 的三值完全一致组级 scale 经逐位比对验证。两个 GGUF 装箱PTQ1_0 与 PQ2_0是真正意义上的工程取舍PTQ1_0 稠密打包 trit、落在信息论目标附近但解码 trit 需要额外算术PQ2_0 每个 trit 占 2-bit 槽、解码便宜但多 21% 体积。本仓库的 runtime/codec.py 实现了从两种 GGUF 格式到 MLX affine 2-bit 的无损转码PQ2_0 每块 34 字节、PTQ1_0 每块 28 字节scale 从块头提取、bias 取负号、权重码重排进 uint32 字并带独立的unpack()反算函数做打包校验。整个加载链路的可靠性有硬证据reload-validation.json 记录了402 个打包模块的序列化往返248320 个 logits 逐位一致reload_logits_exact: truetokenizer-validation.json 确认词表 ID 与 BPE merge 完全匹配runtime/artifact.py 的load_model对 schema 版本、Hadamard 块大小、符号向量逐一校验宁可拒绝加载也不静默给错答案。视觉侧 runtime/vision_artifact.py 把语言模型的 402 个打包层注入 mlx-vlm 的qwen3_5模型而 0.92GB 的视觉塔Qwen3.8-27B 官方塔、27 层、FP16、未量化未旋转走纯透传。推测解码与 11 tok/s端侧体验的真实与边界标题把推测解码和11 tok/s并列这里必须做一次严格的事实核查因为两者都容易产生歧义11 tok/s 是 1-bit 手机版在媒体实测中的数字对应 3.9GB、12GB 内存 iPhone 的原生运行它属于上一代 Bonsai 27B 的移动端报道本仓库Bonsai 2 MLX 2-bit的实测吞吐以 README.md 的 Cross-Platform Throughput 表为准Apple M5 Pro 28.1 tok/s、M5 Max 47.0、M4 Pro 18.0CUDA 侧 RTX 5090 达 129.9PQ2_0128 token 交互式生成。推测解码在本仓库代码中没有实现。它属于运行时/部署层的可选加速是社区端侧部署方案清单与内存映射、NPU 算子融合并列中的组合拳其原理是让一个廉价草稿模型多步生成候选、大模型一次验证多条 token——对每 token 都要搬一遍全部权重的带宽受限解码阶段这是把延迟换吞吐的标准手段。为什么端侧如此需要这类技巧因为三值推理的解码是内存带宽主导的M5 Pro 上实测解码阶段以约 204GB/s 的速率流式搬运权重GPU rail 功耗仅 27.5W、CPUGPU 合计 34.1W——对比 NVIDIA 侧 300–455W 的整卡功耗。换句话说端侧不是算力不够而是权重搬运成为瓶颈推测解码恰好能把每次搬运的产出从 1 个 token 提升到多个 token这正是媒体把 11 tok/s 的端侧体验视为可用的技术语境。但对本仓库而言白皮书与 demo 未随包附送推测解码实现上述吞吐数据均为直接解码测量——读者不应把两者混为一谈。质量底线98.2% 与智能密度低比特最怕的是全面崩塌。Bonsai 2 的 14 项基准EvalScope vLLMH100thinking-mode显示降级是选择性的而非全面的技能类别FP16 基模Bonsai 2 27B数学GSM8K / MATH-500 / AIME25 / AIME2697.0696.57编码HumanEval / MBPP / LiveCodeBench89.0789.42指令遵循IFEval / IFBench81.2582.66Agentic 工具调用BFCL v376.7474.92知识推理MMLU-Redux / MuSR85.5579.86视觉MMMU-Pro / OCR Bench v271.3666.19平均14 项86.3284.78数学离全精度只差半个点、编码甚至持平、指令遵循反超——最容易在低比特下崩塌的推理链AIME26 上常规 IQ2_XXS 掉到 57.5、LiveCodeBench 掉到 56.4而 Bonsai 2 分别拿到 95.83 与 90.07被稳稳守住。代价集中在知识推理与视觉两个最难类别这也是 README 坦承的质量–体积权衡。若以智能密度D -log2(1 - score/100) / size_GB度量Bonsai 2 为0.469 1/GB——是体积相当的常规 2-bit 构建IQ2_XXS0.199的 2.3 倍是 FP160.053的近 9 倍相对上一代 Bonsai 27B0.416再提升 12.5%。在同一个 27B 基模上还没有任何常规低比特构建能把密度做到 0.2 以上。结语3.9GB 里到底藏了什么把三层拆完再回头看3.9GB 里藏的从来不只是压缩后的权重文件而是四个叠加的工程决定——架构层75% 线性注意力让 KV 缓存近似恒定262K 上下文因此可落地表示层训练期约束的三值权重 折叠 Hadamard 旋转把 27B 压到 1.72 bits/weight 且名实相符装箱层PTQ1_0 / PQ2_0 / MLX affine 三种打包在体积、解码成本、硬件适配间做显式取舍MLX 与 GGUF 双格式共享同一组三值、位级一致运行层quantized_matmul直接消费打包权重算子融合、配套 Hadamard-aware runtime 拒绝错误加载、402 模块 logits 位级往返校验。Bonsai 的意义也不在于27B 能不能塞进手机这一个噱头而在于它第一次把 1.x bits/weight 这个区间的质量账本、体积账本和功耗账本同时摆到了明面上并给出了可复现的工程链路。至于推测解码、NPU 算子融合这类部署层加速仓库内仍未兑现——这恰恰说明端侧推理的竞赛才刚刚打到第二局。【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考