同一颗 27B两条路线MLX 2bit 版 vs GGUF 版苹果生态和跨平台你站哪边【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit2026 年 9 月PrismML 发布三值量化模型 Bonsai 2 27B基于 Qwen3.8 27B以不到 1/9 的内存占用保留基础模型 98.2% 的基准分数。这款模型同时以MLX 2-bit 版即本仓库Ternary-Bonsai-2-27B-mlx-2bit和GGUF 版Ternary-Bonsai-2-27B-ggufPTQ1_0 / PQ2_0 两种打包双轨发布——同一组三元权重却分别落在苹果生态MLX Metal与跨平台生态llama.cpp 的 CUDA/Metal/CPU两套推理栈上。本文从仓库源码出发拆解两种格式在存储编码、运行时契约、实测性能与生态定位上的真实差异帮助你在苹果生态与跨平台之间做出有依据的选择。一、同一个三元权重两种容器推理栈差异的本质先说结论MLX 版和 GGUF 版不是两个模型而是同一组权重在两种容器里的两次打包。模型本身是端到端三值化ternary g128的 Qwen3.8-27B每个权重取{-1, 0, 1}三值每 128 个权重共享一个 FP16 缩放因子有效位宽仅约 1.72 bits/weightREADME.md 的 Weight Representation 一节给出了完整推导。差异发生在容器层——同样一组{-1, 0, 1}三种打包方式各自的实际开销截然不同格式真实位宽体积语言模型压缩比 vs FP16FP16 基线16.0 bpw~54 GB1.0xGGUF PTQ1_0稠密三值1.75 bpw5.95 GB~9.0xGGUF PQ2_02-bit 槽位2.13 bpw7.21 GB~7.5xMLX 2-bit本仓库2.25 bpw7.67 GB~7.0xMLX 版多出的 0.5 bits/weight 是容器属性而非表示差异MLX 的分组低比特格式affine2-bit group_size128每组要存一个 scale 和一个 bias而原生三值格式每组只需一个 scale。runtime/codec.py 第 28–30 行清楚地展示了这一对应关系——解码时biases -scales用{0,1,2}三个码值精确复现{-s, 0, s}。bias 不携带任何新信息纯属容器开销。README 中特别说明两组打包解出的三值逐位一致group scale 逐位比对验证只是 MLX 容器在每组 128 权重上多存了一个 FP16。其次是旋转基Hadamard rotation与运行时契约。为了把三值化造成的信息损失压到最低Bonsai 2 的每个权重矩阵都先在块级block1024做正交 Hadamard 旋转再赋三值旋转已折进存储权重里不额外占位hadamard.json 声明prism.hadamard.block_size: 1024、transform: normalized-sylvester-walsh-hadamard。代价是运行时必须在激活上施加配套变换否则推理结果错误。这正是本仓库要把加载器随包分发的根本原因——config.json 声明model_type: prism_hadamard_qwen35runtime/runtime.py 中的Packed模块对每个量化矩阵先做fwht快速 Walsh-Hadamard 变换再走quantized_matmulbits2, group_size128embedding 侧还要做逆变换查表。README.md 直言普通 MLX 加载器不施加激活变换与逆 embedding 查找会返回错误输出而不是报错。最后是内核与平台绑定。MLX 版依赖 PrismML 定制的 MLX forkPython/Swift与 mlx-swift forkiOS/macOS打包权重被内核直接消费、从不展开回 FP16GGUF 版则依赖定制的 llama.cpp fork一套二进制同时覆盖 CUDA、Metal、CPU。两者在低比特原生内核这一点上殊途同归——无论哪条路线官方都明确表示原版 llama.cpp 与普通 MLX 运行时都无法直接运行这批权重。二、Apple Silicon 上的两个入口MLX 原生栈 vs llama.cpp Metal对苹果用户而言选择不是能不能跑而是用哪套栈跑。同一台机器上两条路线的体验差异相当具体MLX 版是面向 Apple 生态的一体化方案。本仓库的 model.safetensors 共 8.60 GB除 7.67 GB 语言模型外还内嵌 0.92 GB 的官方 Qwen3.8-27B 视觉塔FP16、未旋转未量化config.json 的vision_config与 runtime/vision_artifact.py 均可印证因此一个包就能走通 mlx-vlm 的多模态链路quickstart.py 提供一行式启动采样参数自动取自 generation_config.jsonthinking 模式temperature 1.0、top_p 0.95、top_k 20。reload-validation.json 记录了 402 个打包模块的序列化校验重载后 logits 与保存前逐位一致checked 248320 个 logits。GGUF 版则提供另一个入口同一颗 M 系列芯片可通过 llama.cpp Metal 后端跑同权重的 PTQ1_0/PQ2_0 打包。仓库 README 的 Cross-Platform Throughput 表给出了同权重、同测量口径下的跨平台吞吐TG128 生成 128 token 的交互阶段吞吐PP512 512 token 的 prefill 吞吐平台TG128 (tok/s)PP512 (tok/s)说明RTX 5090PQ2_0129.93893CUDAllama.cppRTX 4090PTQ1_091.11645CUDAllama.cppL4 72WPTQ1_032.1467低功耗数据中心卡Apple M5 ProMetal, PQ2_028.1387笔记本实测Apple M5 MaxMetal, 早期构建47.0765待当前栈复测Apple M4 ProMetal, 早期构建18.0125长提示以 prefill 为瓶颈数据里藏着两个容易被忽略的事实。其一在苹果芯片上 27B 模型首次进入交互可用区间54 GB 的 FP16 基线在笔记本上根本不装不下M5 Pro 以 ~204 GB/s 的权重解码带宽把 27B 推理拖进了日常笔记本吞吐随后台负载仅波动约 4%。其二能效是这批数字真正颠覆性的部分M5 Pro 解码时 GPU 轨功耗 27.5 W、CPUGPU 合计 34.1 W而表中 NVIDIA 显卡整板功耗是 300–455 WREADME 特别注明两边测量口径不同——nvidia-smi包含显存、Applepowermetrics不含 DRAM 轨跨平台每 token 能耗不能直接横比。IT之家对白皮书的转述补充了官方口径RTX 5090 词元吞吐 143 TPS、M5 Max 46.8 TPS、RTX 4090 每 token 能耗 0.714 mWh较 FP16 8B 模型低 40%。两条路线的运维差异同样关键。MLX 版要求安装随包分发的 runtime/requirements.txtmlx 0.32.0、mlx-lm 0.31.3、mlx-vlm 0.6.3、transformers 5.5.0 等精确锁定版本并严格遵循 PACK-RUNTIME.md 描述的加载契约GGUF 版则要求自行编译定制 llama.cpp fork。换句话说MLX 版换来的是苹果生态的原生集成Python/Swift/iOS 三端、视觉塔内嵌、一行启动代价是生态被锁在 MLX 容器里GGUF 版换来的是 llama.cpp 庞大的周边工具链llama-server、Open WebUI、Docker、Brave Search 集成等和 CUDA/CPU 兜底代价是需要维护一个 fork 构建。三、双格式共存的生态意义与选型建议双格式发行不是简单的多给一份下载而是一个刻意设计的工程策略背后有三层考量。第一层不同硬件对打包格式的敏感度不同连 GGUF 内部都要双打包。README 的跨平台表显示PTQ1_0 与 PQ2_0 不存在严格的优劣排序PTQ1_0 每步少搬 17% 权重数据但稠密三值解包消耗更多算术于是在 Ada 代显卡与 L4显存/内存受限场景上胜出在 H100/A100/Blackwellbatch-1 解码受指令吞吐与启动开销限制上反而落败而 prefill 是计算受限的PQ2_0 在所有平台上 prefill 都快。MLX 2.25 bpw 的 affine 容器则正好把三值权重映射进 MLX 现有内核的高效路径。这说明低比特模型的时代位宽数字只是起点容器与内核的匹配度才是吞吐的胜负手。第二层模型质量完全解耦于容器选格式就是选生态。无论哪个容器Bonsai 2 27B 都是同一组权重、同一份基准成绩14 项 thinking 模式基准平均 84.78对 FP16 保留率 98.2%其中数学 96.57基线 97.06、编程 89.42基线 89.07甚至反超、指令遵循 82.66略超基线智能密度达 0.469 (1/GB)是常规 2-bit 构建 IQ2_XXS0.199的 2.3 倍、FP16 的约 9 倍。尤为关键的是常规低比特构建的退化集中在需要持续推理链的基准上IQ2_XXS 在 AIME26 跌到 57.5、LiveCodeBench 跌到 56.4而 Bonsai 2 分别是 95.83 和 90.07这正是社区实测中小任务封神、长链任务翻车现象的根源三值模型在 sub-4-bit 区间保住了 reasoning 与 agentic 行为与社区对 Bonsai 家族的定位离线 Agent、工具调用、长上下文工作流一致。第三层双格式本身就是对生态位的一次卡位。社区情报勾勒出的画面相当清晰Bonsai 27B 一代发布时被 AnythingLLM 创始人称作手机 AI 的 DeepSeek 时刻iPhone 17 Pro 可跑 12GB 内存的 27B随后 PrismML 与高通合作推出 1-bit 版端侧推理方案AI 眼镜离线识图问答、被 MIT 科技评论以功耗省掉 80%报道、被 36Kr 以智能密度叙事解读。到 Bonsai 2 这一代MLX 版承接苹果设备Mac 笔记本 iOSGGUF 版承接 NVIDIA GPU、x86 服务器与手机端llama.cpp 定制内核 后续移动端适配Apache 2.0 开源协议则把两套栈都留给了社区自取。格式双轨 生态双轨这是端侧大模型公司必须做的选择题。落到选型可以给出一张足够决策用的清单主力设备是 Apple Silicon 笔记本/Mac选 MLX 版。原生 mlx-vlm 多模态、一行 quickstart、Swift/iOS 三端通吃视觉塔白送但要接受 2.25 bpw 的容器开销语言模型 7.67 GB vs PQ2_0 的 7.21 GB和必须用随包运行时的约束。主力设备是 NVIDIA GPU消费级到数据中心只能选 GGUF 版CUDA。RTX 5090 上 PQ2_0 解码 129.9 tok/s单卡即可承担 27B 级服务的批量推理。追求极致体积5.95 GB或 CPU/边缘设备兜底选 GGUF PTQ1_0同时接受其解包算术开销在高端卡上不占优的事实。手机/移动端路线两条线都还不是终点——1-bit 版3.9 GB才是为 iPhone 级内存优化的那一档本仓库的 MLX 2-bit 版定位是笔记本级质量README 中 Ternary vs 1-bit 的定位表述与此一致。只关心质量、不在乎哪条栈两版权重逐位等价直接按工具链成熟度选——要 Open WebUI/Docker/搜索集成选 GGUF要苹果原生体验选 MLX。同一个 27BMLX 给苹果生态一个开箱即用的答案GGUF 给跨平台一个到处能跑的答案。两者共享同一组 1.72 bits/weight 的三值权重、同一份 98.2% 的基准成绩分歧只在于容器、内核与生态绑定。这或许就是端侧 AI 时代最务实的选择逻辑模型已经小到装得进设备剩下的问题从来不是模型而是你手里的硬件和你想站队的那条生态。【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
