1-bit Bonsai 8B——端到端 1-bit 语言模型在 Apple、GPU 和移动端运行时的部署

《1-bit Bonsai 8B端到端 1-bit 语言模型在 Apple、GPU 和移动端运行时的部署》的白皮书核心内容是介绍并验证了一种真正可部署的、端到端的 1-bit 权重大语言模型旨在从根本上解决大模型在边缘设备和成本敏感场景中的部署效率问题。以下是其主要研究内容的专业总结1. 核心问题与主张核心问题大模型部署的核心瓶颈已从训练能力转向推理效率特别是在边缘设备上内存带宽而非算力是主要限制因素。传统的FP16或4-bit模型在内存占用、能耗和延迟方面存在巨大挑战。核心主张通过端到端的1-bit权重表示可以在大幅降低模型存储和带宽需求的同时保持与全精度模型相竞争的下游任务性能从而将帕累托前沿显著向左推移。2. 技术创新与模型规格模型构建1-bit Bonsai 8B 基于 Qwen3-8B 架构但将嵌入层、注意力层、MLP层和LM头的所有主要权重矩阵均量化为1-bit。量化格式采用Q1_0_g128(GGUF) 和等效的 MLX 1-bit g128 格式。每个权重用1个符号位表示1/-1每128个权重共享一个FP16缩放因子。有效存储成本为1.125 比特/权重(GGUF) 或 1.25 比特/权重 (MLX)相比FP16实现约14倍的原始压缩比。部署后端通过为llama.cpp(CUDA, Metal, OpenCL) 和Apple MLX(Python, Swift) 开发自定义内核实现了对该1-bit格式的高效原生支持而非离线解压执行。3. 主要性能评估结果存储占用模型包大小从FP16的16.38 GB 降至约 1.15 GB(GGUF) / 1.28 GB (MLX)缩减超过92%。推理吞吐量在 token 生成阶段内存带宽瓶颈相比FP16基线实现5.4倍至8.4倍的加速在M4 Pro上MLX后端达8.4倍。提示处理阶段计算瓶颈加速不明显约1.0-1.1倍。能耗每生成一个 token 的能耗降低4倍至6倍Mac/RTX 4090。在iPhone上相比4-bit模型降低约2倍。跨平台能力成功在 NVIDIA GPU (RTX 4090, L40S)、Apple Mac (M4 Pro)、iPhone (17 Pro Max) 甚至部分 Android 设备 (Samsung S25 Ultra) 上运行展示了极高的硬件适配性。4. 模型智能评估基准测试与智能密度基准性能在MMLU、GSM8K、HumanEval、IFEval、BFCL等覆盖知识、推理、数学、编码、指令遵循、工具调用的6大类基准测试中1-bit Bonsai 8B 的平均得分约70.5与 Qwen3 8B (79.4)、Llama 3.1 8B (67.1) 等全精度模型处于同一竞争梯队。智能密度 (Intelligence Density)这是本文提出的一个关键创新度量指标。定义$D -\log(1 - \text{平均分}/100) / \text{模型大小(GB)}$基于信息论中的错误指数概念更合理地反映性能提升的边际难度。结果1-bit Bonsai 8B 的智能密度高达0.792 1/GB是其同级别最接近模型的10.2倍。更小的 1-bit Bonsai 4B 和 1.7B 模型也展现出极高的智能密度分别为1.427和2.172证明了该方法在不同规模上的有效性。5. 意义与局限性意义挑战了“效率与能力不可兼得”的传统观念证明了极端压缩1-bit可以在保持实用智能水平的同时获得部署效率的巨大提升。为设备端AI提供了实用路径使得在手机、笔记本、机器人等资源受限设备上运行强模型成为可能赋能隐私保护、低延迟应用。提出了更合理的模型评估指标智能密度为衡量模型“性价比”提供了新视角。局限性加速依赖于软件和内核优化而非原生1-bit硬件。移动端能耗为估算值非硬件实测。当前实现受限于现有推理框架如MLX的格式开销未达到理论最优效率。通过扎实的工程实现和全面的评估证明了1-bit 权重大模型已从理论走向实用能够在保持强大认知能力的同时以前所未有的效率在各种主流硬件上部署是高效AI领域的一个重要进展。这里是自己的论文阅读记录感兴趣的话可以参考一下如果需要阅读原文的话可以看这里如下所示1. 执行摘要大型语言模型已迎来一个转折点。核心挑战不再仅仅是能否训练出强大的模型而在于能否可靠、经济且大规模地部署它们。在现代 AI 系统中推理过程主导了实际成本、能耗和延迟。因此部署效率——而非原始模型能力——成为了生产环境中的决定性约束。这一约束在边缘硬件上尤为严苛。手机、笔记本电脑、机器人和嵌入式系统在内存、带宽、散热、电池寿命和连接性方面都面临着硬性限制。在这些环境中瓶颈往往不是算力吞吐量而是在生成过程中将模型权重移入内存的成本。1-bit Bonsai 8B 直接解决了这一瓶颈。它是一个真正的、为实际部署而构建的端到端 1-bit 权重语言模型将 1-bit 精度应用于嵌入层、注意力层、MLP 层和 LM 头。其结果是一个 8B 级别的模型在保留实用智能水平的同时在主流通用运行时上实现了存储占用、带宽效率和能耗方面的巨大提升。智能 vs. 大小的帕累托前沿AI 中一个自然的权衡是模型大小用描述它所需的比特数衡量与其智能通过在一组基准任务上的表现衡量之间的权衡。为了理解这种权衡我们考虑了 20 个领先的 AI 指令模型大小范围从 1.2 GBQwen3 0.6B [31]到 18 GBGLM4 9B [37]并评估了它们在 6 个基准测试上的平均性能这些测试涉及知识、问题解决、数学、编码、指令遵循和工具调用。得到的散点图揭示了一个由 Qwen3 模型0.6B、1.7B、4B 和 8B以及 Ministral3 3B [24] 定义的帕累托前沿。然而1-bit Bonsai 8B 及其更小的姊妹模型 1-bit Bonsai 1.7B 和 4B显著地将帕累托前沿向左推移。图 1. 基准测试得分 vs. 模型大小GB对数尺度。Bonsai 系列将智能 vs. 大小的帕累托前沿决定性地向左推移。2. 效率AI 部署中的决定性约束推理定义了 AI 的经济性大型语言模型已进入一个新的采用阶段。核心问题不再仅仅是能否训练出高能力的模型而在于能否可靠、经济且大规模地部署它们。在生产系统中持续性的负担是推理。每一次用户交互、每一个智能体步骤和每一次应用调用都伴随着延迟、能耗和基础设施成本。因此部署效率已成为现实世界中 AI 采用的主要约束。这一约束在边缘硬件上尤为明显。手机、笔记本电脑、机器人、可穿戴设备和嵌入式系统在内存、带宽、散热、电池寿命和连接性方面都运行在固定限制内。在这些环境中模型质量是必要条件但并非充分条件。系统还必须适应其运行设备的物理和经济限制。内存带宽是真正的瓶颈在 LLM 推理中尤其是在小批量大小下限制因素通常不是峰值算术吞吐量而是内存移动。性能在很大程度上取决于系统在 token 生成过程中获取和流式传输模型权重的效率。对于部署而言这使得内存带宽和模型占用成为核心变量而非次要的实现细节。这就是权重精度之所以重要的原因。将参数以每权重 1 比特存储这是参数表示的实际下限不仅能减小模型大小。它还能减少内存流量降低每 token 能耗并提高在受限硬件上运行强大模型的可行性。1-bit 的重要性不在于抽象的压缩而在于其对真实推理系统中主要瓶颈的直接作用。为什么 1-bit 一直难以实现二元权重神经网络的吸引力已被理解数十年。原则上它们能大幅减少存储、带宽需求和计算成本。在实践中这些收益通常伴随着质量、适用性或部署复杂性方面的权衡。最近关于二元权重 Transformer [5, 6] 的工作重新点燃了对 1-bit 领域的兴趣但将精度切实推低至 4-bit 以下对于 LLM 而言仍然困难。在此水平上失败模式通常是质变而非渐变。一个模型可能保持流畅性但在多步推理、工具使用、检索和边缘案例上变得显著不可靠。在生产中这种脆弱性通常比直接的准确率下降更具破坏性因为它破坏了信任使系统行为更难预测。即使是接近 1-bit 的方法也常常引入了足够多的操作复杂性限制了采用。许多方法依赖于精心挑选的校准集、辅助元数据、自定义层处理或定制的运行时和内核这些无法干净地集成到标准推理栈中。这恰恰在效率本应发挥作用的方面制造了摩擦跨异构硬件的部署、与现有工具链的集成以及无需重构基础架构即可可靠使用。3. PrismML 的独特之处PrismML 的差异化始于使 1-bit 语言模型变得实用的方法。尽管高效推理的更广泛生态系统已有所改进但仅靠工具并不能解决核心问题。在极端压缩水平下语言模型在历史上损失了太多赋予其价值的推理质量和行为稳定性。PrismML 的方法基于数学上扎实的进展旨在在激进压缩下保留这些属性。这一基础来自 Caltech 的专有知识产权通过严谨的数学而非临时启发式方法解决了一个长期存在的研究挑战。因此1-bit Bonsai 8B 不是为受控演示而构建的狭隘例外的集合。它是一个原则性的压缩框架旨在在显著降低推理成本的同时保留有用的模型行为。这种差异化在部署的模型本身中是可见的。1-bit Bonsai 8B 在整个网络上应用端到端的 1-bit 权重精度嵌入层、注意力层、MLP 层和 LM 头。它不是一个依赖于关键路径中更高精度“逃生舱”的部分量化系统。这一点很重要因为此类例外虽然可以保留质量但也会削弱使 1-bit 在部署中有价值的存储占用和带宽削减。其结果是一个 8B 级别的模型使得强大的设备端推理变得更加实用。更低的内存需求和减少的带宽压力转化为具体的部署优势包括更低的延迟、更低的能耗、更小的存储占用以及在边缘硬件上更高的可行性。这些属性也扩展了可以在本地运行的应用范围特别是在隐私、响应性或间歇性连接使得依赖云变得不理想的环境中。Bonsai 被设计为一种部署策略而非单设备演示。它被设计为使用开发者已经在使用的主流后端跨异构硬件运行包括用于 Mac、iPhone 和 iPad 的 Apple MLX [25]以及用于 NVIDIA GPU 上 CUDA 的 llama.cpp [13]。因此该系统的意义不仅在于 1-bit 在原则上可行还在于它可以跨真实运行时、真实设备和真实产品进行部署。为了进一步展示 1-bit 模型的潜力我们还发布了 Bonsai 系列中的两个较小模型1-bit Bonsai 4B 和 1-bit Bonsai 1.7B。这些模型将相同的设计理念扩展到更小的规模表明 1-bit 量化的优势不仅限于单个模型大小。尽管占用空间非常紧凑但这两个模型在提供极强的吞吐量和能效的同时相对于其参数类别保持了有竞争力的准确性。总而言之Bonsai 系列表明 1-bit 设计不仅仅是一种压缩技术而是一种构建实用、高性能模型的可扩展方法适用于各种部署场景。从 1.7B 模型到 8B 模型Bonsai 证明了强大的能力、高效的执行和小内存占用可以同时实现而非相互权衡。在本文的其余部分我们将主要关注 1-bit Bonsai 8B而 4B 和 1.7B 的结果见附录。4. 1-bit Bonsai 8B 模型概述1-bit Bonsai 8B 基于 Qwen3-8B [31] 构建这是一个稠密的解码器专用因果语言模型。架构未变新颖之处完全在于部署栈所有主要矩阵重度组件的端到端 1-bit 权重存储主流推理引擎的显式运行时格式以及覆盖 MLX [25] 和 llama.cpp [13] 后端的优化内核。表 1. 系统规格项目规格架构模型Qwen3-8B [31] 稠密因果语言模型参数8.19 B约 6.95 B 非嵌入参数36 个 Transformer 块架构细节GQA [2]32 查询 / 8 KV 头SwiGLU [34] MLPRoPE [33]RMSNorm [32]上下文长度65,536 tokens权重格式GGUF Q1_0_g128 和 MLX 1-bit g1281-bit 权重应用嵌入层、注意力投影、MLP 投影和 LM 头后端MLX (Python, Swift) 和 llama.cpp (CUDA, Metal)许可证Apache License4.1 可部署的 1-bit 格式Q1_0_g1281-bit Bonsai 使用可部署的分组 1-bit 权重格式。在 llama.cpp [13] 中这被打包为 GGUF [12] Q1_0_g128而 MLX [25] 使用相应的 1-bit g128 表示。该格式为每个权重存储一个符号位并为每组 128 个权重存储一个共享的 FP16 缩放因子。这在保留稳定推理所需的分组幅度信息的同时保持了根本上的 1-bit 表示。在存储中权重表示为 {0,1} 中的位打包值每个权重恰好使用一个比特。在推理时这些比特被映射为带符号的值并乘以其所在组关联的 FP16 缩放因子。因此有效权重由下式给出Q1_0_g128 统一应用于模型的大型矩阵重度组件包括嵌入层、注意力投影、MLP 投影和 LM 头。归一化参数和缩放元数据为了数值稳定性保留更高精度但相对于在解码过程中主导带宽的大型权重张量这些只占内存流量中可忽略的一小部分。该格式专为直接执行而非离线扩展而设计。在推理路径中符号位在矩阵乘法内核内部内联解码而不是在内存中实例化完整的 FP16 权重张量。这在最重要的地方——即逐 token 解码路径中重复移动大型权重矩阵——保留了 1-bit 权重的存储和带宽优势。4.2 存储占用部署后的大小缩减是 1-bit 表示的一阶结果。对于同一个 8.19B 参数模型FP16 safetensors 占用 16.38 GB而 1-bit Bonsai 8B 的运行时包在 GGUF 中降至约 1.15 GB在 MLX 中降至约 1.28 GB。表 2. FP16 和 1-bit 部署的运行时包大小格式精确字节GBGiB缩减 %压缩比FP16 (HF safetensors)16,381,452,28816.3815.25—1.0×GGUF Q1_0_g1281,151,820,8641.151.0792.9%14.2×MLX 1-bit (g128)1,280,131,4241.281.1992.2%12.8×部署后的运行时占用即峰值内存需求在 GGUF 和 MLX 构建之间略有不同。运行时磁盘使用还包括辅助元数据如配置、聊天模板和分词器文件。然而对于 GGUF 和 MLX 来说总占用大约比 FP16 的峰值内存需求小一个数量级。4.3 跨平台吞吐量1-bit Bonsai 8B 设计用于在常用硬件平台上部署通过 MLX 或 Metal 在 Apple 芯片上通过 llama.cpp 中的 CUDA 在 NVIDIA GPU 上以及通过 MLX Swift 或 OpenCL 路径在移动级设备上。为了在所有目标后端上实现对 Q1_0_g128 格式的加速我们开发了自定义推理支持。更多细节请参考附录 A。下面的标准化吞吐量摘要使用了 tg128 / pp512 部署测量值其中 tg128 测量生成 128 个 token 的 token 生成吞吐量pp512 测量处理 512 个输入 token 的提示处理吞吐量。与全精度 8B 模型相比我们观察到 1-bit Bonsai 8B 模型的 token 生成加速了 5.4-8.4 倍。请注意这些值不同于用于能耗测量的较长持续运行负载。有关吞吐量测量方法的更多详细信息以及 1-bit Bonsai 4B 和 1.7B 的进一步结果请参阅附录 D。1-bit Bonsai 8B 相对于 FP16 基线使用标准化的 tg128 / pp512 部署测量值而非持续运行负载。平台后端大小TG128 (tok/s)PP512 (tok/s)基线 TG (tok/s)加速比RTX 4090llama.cpp CUDA1.15 GB36811,809596.2×RTX L40Sllama.cpp CUDA1.15 GB3279,592526.3×M4 Pro 48 GBllama.cpp Metal1.15 GB85498165.4×M4 Pro 48 GBMLX (Python)1.28 GB131472168.4×iPhone 17 Pro MaxMLX Swift1.28 GB4437713.8¹3.2×¹Samsung S25 Ultrallama.cpp OpenCL1.15 GB19.630.4—²—²RTX 3060 Laptopllama.cpp CUDA1.15 GB81118713.523.0׳¹ iPhone 基线为 4-bit因为 FP16 8B 参数模型无法在设备上运行。² 在三星设备上即使是 4-bit 8B 模型也无法装载。³ FP16 基线因内存不足需要部分 GPU 卸载。总体而言这些结果表明1-bit Bonsai 8B 在跨平台提供了显著的吞吐量提升同时将部署占用减小到足以在从高端 GPU 到移动设备的硬件上实现高效推理。4.4 每 Token 能耗接下来我们考察 1-bit Bonsai 8B 模型的能耗节约。与部署占用不同能耗曲线更为微妙。在 Apple 芯片和 NVIDIA GPU 上1-bit Bonsai 在生成期间的瞬时功耗可能等于甚至高于 FP16因为内联反量化和比特级算术将执行推向更偏计算密集型的模式。然而token 生成显著加快因此每个输出 token 消耗的总能量仍然低得多。换言之当 token 生成时间充分减少时更高的瞬时功耗不一定意味着更高的总能量。结果如表 4 所示。表 4. 测量和估计部署的每 token 生成能耗 (Etg) 摘要平台1-bit Bonsai 8B (mWh/tok)基线 FP16 (mWh/tok)优势Mac M4 Pro (MLX)0.0740.4155.6×Mac M4 Pro (Metal)0.0910.4715.1×RTX 4090 (CUDA)0.2761.1344.1×iPhone 17 Pro Max~0.0684-bit: ~0.1432.1× (vs 4-bit)Mac 功耗包括 CPU GPU ANE DRAM不包括系统开销。RTX 4090 测量仅使用 GPU 功耗。iPhone 能耗根据 Xcode Power Profiler 和电池放电观察结果估算。对于 Mac M4 Pro 和 RTX 4090我们通常观察到每生成一个 token 的能耗降低 4−6 倍而在 iPhone 上我们测量到相对于 4-bit 量化这是在设备上能装载的 8B 模型的最大尺寸大约有 2 倍的改进。5. 基准测试与智能密度我们在六个技能类别上评估了 1-bit Bonsai 8B 的性能知识、推理、数学、编码、指令遵循和工具调用。所有基准测试均使用 EvalScope [1] v1.4.2 进行评估后端为在 NVIDIA H100 GPU 上运行的 vLLM [36] 0.15.1。我们将 1-bit Bonsai 8B 与其他 11 个参数范围在 6B 到 9B 之间的领先模型进行比较。每个模型都使用相同的基础设施、生成参数和评分方法进行评估以确保公平和可重复的比较。生成使用贪婪解码温度 0top-p1.0并禁用思考模式。评分主要基于规则遵循行业标准方法并配有一个 LLM 召回回退机制该机制仅在基于规则的解析器无法提取有效答案时激活。所有模型使用相同的评判配置、数据集版本和样本集。有关方法论和公平性工作的更多细节请参阅附录 B。表 5 总结了每个技能类别一个基准测试的结果知识类 MMLU-Redux [26, 14]、推理类 MuSR [27]、数学类 GSM8K [7]、编码类 HumanEval [8, 19]、指令遵循类 IFEval [35] 和工具调用类 BFCL v3 [4]。这些类别的其他结果以及我们的 1-bit Bonsai 4B 和 1.7B 模型的结果见附录 C。表 5. 基准测试比较。1-bit Bonsai 8B 与 11 个领先的常规同规模模型进行比较。尽管 1-bit Bonsai 8B 的内存仅为表 5 中其他模型的 1/14但它在所有六个技能类别上都取得了与领先的全精度 8B 指令模型竞争的性能。这些结果表明1-bit Bonsai 8B 在保持强大的通用能力的同时极大地减少了部署时的内存需求。换句话说1-bit Bonsai 8B 挑战了效率的巨大提升必须以牺牲模型能力为代价的传统观念。5.1 智能密度上述基准测试结果激发了一种更系统的方法来表征能力与模型大小之间的权衡。我们不再单独考虑性能而是希望得到一个度量它能捕捉模型每单位内存所传递的智能量。图 1将该权衡可视化为各模型智能与大小的散点图。为了用一个标量来概括这种关系我们将智能密度定义为模型的智能与其大小以比特或等效的 GB 衡量之比。起初人们可能倾向于将模型的智能定义为一组任务上的平均基准分数例如表 5 中的平均基准分数。然而这可能有问题。如果采用这种智能定义那么得分 99 和 55 的模型分别比得分 90 和 50 的模型智能高 10%。但很明显从 90 分提升到 99 分所需的努力要比从 50 分提升到 55 分大得多。因此我们寻求一种能更好反映这种非线性标度的智能定义。为此我们将这一定义产生了比原始基准分数合理得多的标度。例如根据这个度量得分 99 的模型的智能大约是得分 90 的模型的两倍而得分 55 的模型的智能仅比得分 50 的模型高出约 15%。使用这个智能密度的定义以及表 5 中研究的基准我们在表 6 中比较了 20 个参数范围在 1.2B-9B 之间的指令模型以及 1-bit Bonsai 8B 及其姊妹模型 1-bit Bonsai 4B 和 1.7B。6. 应用场景前几节的结果表明1-bit Bonsai 模型不仅仅是更小而且在那些强模型质量必须与硬性系统约束共存的环境中具有实际部署价值。一类重要的应用是在 Mac、iPhone 和 iPad 上的设备端辅助其中本地执行可以改善响应性、减少内存压力并通过使推理靠近用户来加强隐私。同样的部署特性也适用于需要本地或严格控制推理的企业环境包括数据驻留、本地部署或减少对云基础设施依赖非常重要的场景。第二类应用是在商用 GPU 上进行成本敏感的 serving。在这些部署中带宽、VRAM 压力和每 token 能耗通常在运营成本中占据主导地位而不仅仅是峰值计算。通过减少内存占用和内存移动同时提高吞吐量1-bit Bonsai 8B 非常适合部署效率是首要考虑因素的 serving 环境。1-bit Bonsai 模型也与在更严格物理约束下运行的边缘系统相关包括机器人、自动驾驶和嵌入式推理。在这些环境中热限制、间歇性连接和有限的内存预算使得全精度部署变得困难。一个能够在异构硬件上高效执行的紧凑模型扩展了可以在本地运行有用语言模型推理的系统范围。总而言之这些应用场景指向一个更广泛的机会在常规模型通常过大、成本过高或过于依赖基础设施而难以实用的部署场景中实现有能力的语言模型。7. 局限性与发展路线图本白皮书中的结果是通过软件和内核优化在通用硬件上获得的而不是在原生主流 1-bit 硬件目标上。因此它们应被解释为在现有平台上的部署结果而不是二元权重推理在专用芯片上可能达到的上限。此外移动设备的能耗测量不如桌面设备直接因此此处报告的 iPhone 能耗数据是估算值而非硬件实测值。同时Bonsai 方法论与架构无关不局限于单一的 Transformer 系列。未来版本将把 Bonsai 扩展到更新的模型骨干网络包括新兴的非 Transformer 和混合高效架构、扩散模型以及 1-bit 以外的其他高效部署格式。在短期内该路线图包括不同比特宽度的 Bonsai 变体以及旨在改善真实硬件部署的额外效率机制。更广泛的目标不仅仅是展示一个单一的紧凑模型而是开发一个实用的低比特推理系统家族能够清晰地映射到不同的架构、运行时和硬件环境。从这个意义上说1-bit Bonsai 8B 不应被视为终点而应被视为一个更大转变的第一个指标有能力的语言模型开始进入一个部署效率本身就是主要设计目标的领域。