Bonsai 2 27B压小9倍

27B 模型，开始进入个人设备的内存区间

PrismML 近日发布 Bonsai 2 27B，将一款 270 亿参数模型压缩至原始体积的约九分之一，同时宣称模型能力几乎没有损失。Bonsai 2 27B 是 PrismML 面向端侧推理打造的第二代低比特模型，核心目标不是刷新云端跑分，而是让原本需要工作站显存的 27B 模型进入手机、高配笔记本和消费级显卡的可部署范围。

这次升级的重点不是把模型做得更小，而是在激进压缩后把能力损失继续压低。第一代 Bonsai 27B 已经展示过 1-bit 和三值权重路线，其中 1-bit 版本约为 3.9GB，三值版本约为 5.9GB；Bonsai 2 更值得关注的地方，是 PrismML 开始用“near-lossless”，即“近乎无损”，描述压缩模型与原始 27B 基线之间的差距。

低比特模型是将神经网络权重从 FP16、BF16 等高精度格式压缩到 4-bit、2-bit、1-bit或三值表示的模型。它与压缩 ZIP 文件不同：ZIP 只是减少下载体积，运行时仍需解压；低比特模型则直接以更紧凑的权重参与计算，因此能够同时减少存储空间、内存带宽和部分推理能耗。

“缩小9倍”究竟意味着什么

“缩小9倍”首先是权重存储口径，而不是整套应用的内存占用。一个 270 亿参数模型如果使用 FP16 或 BF16，每个参数需要 2 字节，仅权重理论体积就是约 54GB；按九分之一计算，Bonsai 2 27B 的对应权重规模大约落在 6GB 区间。

这笔账可以解释 Bonsai 2 的部署价值：54GB 已经超过多数消费级显卡的显存，甚至让 64GB 统一内存设备也没有多少余量；约 6GB 则能装进高端手机和主流笔记本的内存预算。模型没有因为压缩变成“小模型”，它仍保留 27B 级参数容量，只是每个参数占用的比特数显著减少。

实际文件大小通常不会严格等于参数量乘以平均位宽。量化模型还需要保存缩放因子、分组参数、词表、元数据，以及部分未量化层；运行时还要额外分配 KV cache、激活值、临时计算缓冲区和推理框架本身占用的内存。因此，“约 6GB 权重”不能直接理解为“6GB 内存的手机就能运行”。

| 模型形态 | 权重精度或压缩方式 | 27B 权重理论或公开体积 | 主要部署设备 | 关键取舍 | |---|---:|---:|---|---| | 原始 27B 基线 | FP16／BF16 | 约 54GB | 数据中心 GPU、工作站 | 能力基线稳定，内存需求最高 | | 常规 4-bit 量化 | 4-bit 加分组元数据 | 理论约 13.5GB，实际常见更高 | 16GB 至 24GB 显存设备 | 生态成熟，但很难进入手机内存预算 | | 第一代 Ternary Bonsai 27B | 三值低比特权重 | 约 5.9GB | 高配笔记本、桌面端 | 更重视推理能力与运行效率 | | 第一代 1-bit Bonsai 27B | 约 1.125 有效比特 | 约 3.9GB | 高端手机、统一内存设备 | 体积最小，对内核适配要求更高 | | Bonsai 2 27B | 约九分之一压缩体积 | 按 BF16 基线估算约 6GB | 手机、笔记本、消费级 GPU | 优先追求近乎无损的能力保留 |

Bonsai 2 的“9倍压缩”反而没有第一代 3.9GB 版本那么激进，这很可能是一种主动取舍。对低比特模型来说，从 54GB 压到 6GB 与压到 3.9GB，看起来只差约 2GB，但多出来的位宽和校正信息可能明显改善长文本、数学推理、工具调用以及少见知识上的稳定性。第二代产品的价值因此不应只看谁更小，而应看每一 GB 内存能够换来多少可用能力。

“能力几乎无损”比体积数字更重要

“近乎无损压缩”是指压缩模型在标准评测和真实任务中的输出质量接近原始模型，而不是参数能够被逐位还原。神经网络具有较高冗余度，许多权重不需要 16-bit 精度也能表达有效信息，但当位宽下降到 2-bit 甚至 1-bit 附近时，量化误差会迅速累积，传统的训练后量化通常很难维持原模型能力。

PrismML 对 Bonsai 2 的核心主张，是在约九分之一体积下将这种误差控制到接近原模型的水平。这个说法比“模型能启动”严格得多，因为真正困难的并不是让 27B 权重装进内存，而是避免模型在压缩后出现逻辑链断裂、格式遵循下降、工具参数出错和长上下文信息遗失。

截至 2026 年 9 月 17 日，“近乎无损”仍应被视为厂商对综合能力的描述，而不是所有任务上的绝对结论。不同评测集对量化误差的敏感程度并不相同：选择题和短答案可能几乎看不出差距，代码补全、复杂数学、Agent 工具调用以及长上下文检索却更容易暴露压缩损失。

可信的近乎无损结论至少需要覆盖四类测试：通用知识与指令遵循、数学和代码推理、长上下文信息召回、结构化输出与工具调用。单一榜单即使只下降 0.5 个百分点，也不能证明模型在生产场景中等价于基线；相反，如果模型在多轮任务中的成功率保持稳定，哪怕个别学术榜单略有下降，它仍可能是更有用的本地模型。

第一代 Bonsai 27B 已经给出了颇激进的能力信号。公开资料显示，其 Math 500 成绩达到 99.2%，早期使用者还曾在 M4 Pro 上测得约 40 tokens/s；另有消费级 AMD 显卡测试在较长上下文条件下得到约 40 tokens/s。不过，这些数字来自第一代模型和特定运行环境，不能直接当作 Bonsai 2 的性能成绩，更不能跨设备横向比较。

低比特不等于一定更快

Bonsai 2 的最大优势是降低内存带宽压力，而不是保证所有硬件上的计算速度同步提升九倍。大模型逐 token 解码经常受制于内存带宽，权重越小，每生成一个 token 需要从内存搬运的数据就越少；在内核充分优化时，低比特模型通常能获得更高的解码速度和更低的能耗。

专用计算内核决定了低比特模型能否兑现速度优势。主流 GPU、Apple Silicon 和移动端 NPU 对 FP16、INT8、INT4 的支持已经较成熟，但 1-bit、1.58-bit 或三值权重往往需要定制 kernel、特殊打包方式和融合算子。如果运行时先把低比特权重解包到更高精度再计算，模型虽然节省了存储空间，却未必更快，甚至可能被解包开销拖慢。

Bonsai 2 的真实表现因此需要分别观察首 token 延迟和持续生成速度。首 token 延迟主要受提示词长度、预填充计算和数据加载影响；持续生成速度则更容易受权重带宽影响。一个模型即使能以 40 tokens/s 解码，在处理 10 万 token 文档时仍可能需要较长预填充时间。

长上下文也会重新抬高端侧内存门槛。模型权重可以压到约 6GB，但 KV cache 会随着上下文长度和并发会话数量持续增长；当用户把上下文从 8K 提升到 128K 甚至 262K 时，额外内存可能达到数 GB。手机上“模型能够加载”和“模型能够使用完整上下文”是两件不同的事。

为什么27B低比特模型不是普通小模型

27B 低比特模型与原生 7B 小模型解决的是不同问题。低比特 27B 保留了更多参数和表示容量，通常更适合复杂推理、知识密集任务与多步骤 Agent；原生 7B 或 8B 模型则拥有更少计算量，往往在首 token 延迟、预填充速度和低端设备兼容性上更占优势。

| 本地模型路线 | 权重占用 | 计算量 | 能力上限 | 适合场景 | |---|---:|---:|---|---| | 原生 3B—8B 小模型 | 最低 | 最低 | 中等 | 摘要、改写、简单问答、离线助手 | | 常规 4-bit 14B—32B | 中等 | 较高 | 较高 | 桌面知识库、代码辅助、研究任务 | | Bonsai 2 类超低比特 27B | 接近小模型体积 | 仍是 27B 计算规模 | 接近原始 27B | 高质量本地 Agent、隐私任务、复杂推理 | | 云端大型模型 | 本地权重为零 | 由云端承担 | 通常最高 | 高并发、超长上下文、前沿能力需求 |

参数体积下降并不会等比例减少乘加运算数量。Bonsai 2 仍然是一款 27B 模型，其每个 token 需要处理的网络规模并没有变成 7B；只有当硬件能够直接利用低比特稀疏性或位运算优势时，计算成本才会跟着明显下降。因此，它更像是“把大脑装进更小的行李箱”，而不是把大脑本身缩成四分之一。

这种路线最适合内存受限、但仍有较强计算能力的设备。统一内存 Mac、高端独立显卡笔记本和旗舰手机都可能受益，因为它们缺的往往不是基础算力，而是容纳 27B 模型权重的连续可用内存。对只有入门级 CPU 和低内存的设备来说，原生小模型依旧更实际。

Agent 是 Bonsai 2 更值得关注的落点

本地 Agent 是能在设备上循环调用模型、工具和本地数据完成多步骤任务的软件系统。它与一次性聊天不同：一个研究、整理或自动化任务可能触发几十次甚至几百次模型推理，每一步都要读取上下文、生成结构化参数并根据工具结果继续决策。

本地运行会放大低比特模型的经济价值。云端模型按 token 计费，一次复杂 Agent 任务可能反复处理相同上下文；端侧模型虽然需要占用用户设备，但边际调用成本接近于电力和硬件折旧，而且敏感文件不必离开本机。

27B 级能力也比极小模型更适合工具调用。Agent 最怕的不是回答略显普通，而是 JSON 字段写错、函数选错、遗漏约束或在长任务中偏离目标；如果 Bonsai 2 确实能将原始 27B 的结构化输出和推理能力保留下来，它会比单纯追求 3GB 以下体积的模型更有生产价值。

隐私并不是本地模型的唯一卖点。弱网环境、离线工作、固定成本和低交互延迟同样重要，例如在手机上分析本地照片与文档、在笔记本中检索私有代码仓库、在企业终端处理不能上传的合同，都比通用聊天更能体现 Bonsai 2 的优势。

这次发布还需要验证什么

Bonsai 2 当前最需要补齐的是可复现数据，而不是更多演示视频。开发者应重点关注完整模型卡、量化方法、权重许可、运行时支持范围，以及同一硬件上相对于原始基线和常规 4-bit 量化的质量、速度和峰值内存对比。

以下四项数据将决定 Bonsai 2 是技术演示还是可用产品：

• 独立能力评测必须覆盖长链任务。 MMLU 类选择题只能反映一部分能力，代码修复、数学证明、长文档问答和多轮工具调用更容易测出低比特损失。
• 设备实测必须标明上下文长度。 只报告模型加载后的内存没有意义，8K、32K 与 128K 上下文的峰值内存和速度可能完全不同。
• 吞吐数据必须标明运行时和内核。 同一份权重在 CPU、Metal、CUDA、Vulkan 和移动 NPU 上的表现差异可能达到数倍。
• 多模态能力必须单独核验。 如果底座包含视觉能力，视觉编码器、图像 token 和投影层是否完整保留，会直接影响最终体积与端侧体验。

模型许可同样会影响 Bonsai 2 的实际采用速度。权重可下载不等于可以任意商用，企业还需要确认底座许可、压缩权重许可、再分发条件和生成内容政策；如果专用运行时没有成熟开源实现，部署成本也可能抵消体积优势。

判断：这是部署拐点，不是性能终局

Bonsai 2 27B 最有价值的地方，是把“27B 模型能否在个人设备上运行”从硬件问题转化成软件优化问题。过去，54GB 权重直接把手机和多数笔记本挡在门外；现在，约九分之一的权重体积意味着模型至少能进入这些设备的内存区间，剩下的问题变成内核是否成熟、上下文能开多大、速度是否可接受。

“能力几乎无损”仍需要第三方复现，但这一路线已经比单纯追求极限压缩更成熟。第一代 Bonsai 证明了 27B 可以被压到 3.9GB，第二代则试图证明低比特模型不必以明显变笨为代价；如果后者成立，本地模型竞争的指标会从“能不能塞进去”升级为“每 GB 能保留多少智能”。

Bonsai 2 不会取代云端前沿模型，也不会让所有手机立刻变成 AI 工作站。它更现实的意义，是为需要隐私、离线运行和高频调用的开发者提供一个新的平衡点：体积接近小模型，计算规模仍是 27B，能力目标则尽量靠近未压缩基线。

截至 2026 年 9 月 17 日，Bonsai 2 27B 值得关注，但还不适合只凭“9倍压缩”和“近乎无损”两个标签下结论。真正决定它能否进入日常工作流的，将是开放权重后的独立评测、主流推理框架适配，以及在真实手机和笔记本上连续运行一小时后的速度、内存与功耗数据。

参考来源

• Hugging Face：Bonsai 2 27B 模型检索页：用于核对公开模型卡、权重文件、许可和社区评测状态。
• GitHub：llama.cpp：主流本地推理框架，可用于了解低比特{ "title": "Bonsai 2把27B压小9倍", "summary": "PrismML 发布 Bonsai 2 27B，以约九分之一的权重体积保留接近原模型的能力。它真正改变的不是跑分排名，而是 27B 模型在消费级设备上的部署门槛。", "content": "## 27B 模型，开始摆脱大显存依赖

PrismML 近日发布 Bonsai 2 27B，核心卖点是把一个 270 亿参数模型压缩到约九分之一的体积，同时将能力损失控制在较低水平。按照 27B 模型以 FP16 保存时约 54GB 的理论权重体积计算，九倍压缩对应约 6GB；这意味着模型有机会完整放进高配手机、统一内存笔记本或主流消费级显卡，而不再依赖工作站级硬件。

截至 2026 年 9 月 17 日，Bonsai 2 27B 最值得关注的标签不是“又一个低比特模型”，而是“近乎无损的九倍压缩”。低比特量化早已不新鲜，真正困难的是在压到 1～2 bit 附近后，仍然保住数学推理、指令遵循、工具调用和长上下文稳定性——这些能力通常比闲聊质量更早崩掉。

Bonsai 2 27B 是 PrismML 面向本地推理推出的 270 亿参数低比特模型，目标是在约九分之一权重体积下保留接近全精度基线的综合能力。

这次发布也可以看作 7 月 Bonsai 27B 路线的继续推进。上一代产品已经提供过两个激进版本：面向笔记本的 Ternary Bonsai 27B 约为 5.9GB，每个权重平均占用 1.71 个有效比特；面向手机的 1-bit Bonsai 27B 约为 3.9GB，每个权重平均占用 1.125 个有效比特。Bonsai 2 的重点则从“能不能装进去”转向“压缩后还剩多少能力”。

九倍压缩到底意味着什么

九倍压缩首先解决的是权重常驻内存问题，而不是简单缩短下载时间。一个 27B 稠密模型使用 FP16 权重时，理论体积为 270 亿 × 2 字节，约合 54GB；即使采用常见的 4-bit 量化，裸权重也约为 13.5GB，算上量化元数据、对齐、运行时缓冲区和其他组件，实际占用通常还会更高。

模型权重体积是存放参数所需的空间，但它不等于模型运行时的全部内存占用。 推理过程中还需要为 KV cache、激活值、图像编码器、系统运行时和应用本身留出内存，因此“模型文件能下载到手机”与“模型能在手机上稳定跑起来”是两件不同的事。

下面这张表展示了不同精度下 27B 模型的理论权重规模，以及 Bonsai 系列已披露版本所处的位置：

| 方案 | 理论或披露体积 | 相对 FP16 压缩倍数 | 典型部署范围 | 主要代价 | |---|---:|---:|---|---| | FP16 27B | 约 54GB | 1 倍 | 多卡或大内存工作站 | 体积最大，精度基线 | | INT8 27B | 约 27GB | 2 倍 | 32GB 级统一内存设备、专业显卡 | 能力损失通常较小，但端侧门槛仍高 | | INT4 27B | 裸权重约 13.5GB | 约 4 倍 | 16GB 以上显存或较大统一内存 | 部分推理与长尾知识可能退化 | | Bonsai 2 27B | 按九倍压缩折算约 6GB | 约 9 倍 | 高配手机、笔记本、消费级 GPU | 依赖专用低比特内核与格式支持 | | 上一代 Ternary Bonsai 27B | 5.9GB | 约 9.2 倍 | 笔记本、本地 Agent | 1.71 有效 bit，运行时兼容性有限 | | 上一代 1-bit Bonsai 27B | 3.9GB | 约 13.8 倍 | 内存受限的移动设备 | 压缩最激进，对算子和硬件要求更特殊 |

表中的 6GB 是依据“九倍于 FP16 的压缩比例”计算出的量级，不应直接当作所有发布文件和运行环境下的精确占用。模型包是否包含视觉编码器、词表、校准数据，以及运行时如何保存缩放因子，都会让最终数字出现差异。

九倍压缩真正跨过的是消费设备的内存分界线。54GB 权重无法放入常见的 16GB、24GB 或 32GB 设备，13.5GB 的 4-bit 权重又会与 KV cache 争抢空间；约 6GB 的权重则能给上下文缓存和系统留出更多余量，在 12GB～16GB 统一内存设备上开始具备现实可用性。

“近乎无损”比“1-bit”更重要

近乎无损压缩是指模型体积明显下降，但在一组代表性任务上的能力与原始模型保持接近，而不是指每个输出都与原模型完全相同。对于生成模型，哪怕使用相同权重，只要采样设置不同，答案也可能发生变化，因此“无损”更应该由多项基准、任务成功率和输出稳定性来定义。

PrismML 给 Bonsai 2 27B 的定位是 near-lossless，也就是“接近无损”，这比直接宣称无损更合理。模型量化后最容易保住的是常识问答和简单摘要，最容易受伤的则是多步数学、代码生成、结构化输出、少数语言能力以及长链工具调用；如果评测只覆盖短问答，结论很可能过于乐观。

上一代 Bonsai 27B 曾披露在 MATH-500 上取得 99.2% 的成绩，这说明极低比特模型未必必然牺牲数学能力。MATH-500 是一个包含 500 道数学题的推理评测集，常用于衡量模型能否完成多步数学求解。 不过，这一成绩不能直接移植到 Bonsai 2，也不能单独证明新模型已经全面追平原始 27B 基线。

Bonsai 2 是否真的“几乎无损”，至少需要同时观察以下五组指标：

1. 推理能力：数学、代码与多步逻辑任务的准确率是否接近基线。
2. 指令遵循：复杂格式约束、JSON 输出和拒答边界是否稳定。
3. 长上下文：上下文拉长后，信息召回率和推理一致性是否下降。
4. 工具调用：函数选择、参数填充以及连续调用的成功率是否退化。
5. 生成质量：重复、乱码、事实漂移和异常截断的比例是否上升。

现阶段更稳妥的判断是：PrismML 已经证明 27B 模型可以被压到移动设备可接受的体积，但 Bonsai 2 的“近乎无损”仍应以完整模型卡、逐项基准和第三方复测为准。官方汇总分数适合判断方向，却不足以替代真实工作负载。

它不是普通的量化文件

低比特模型的难点不只是把 16-bit 数字改成 1-bit 或 2-bit 数字，而是重新设计权重表示、缩放策略和计算内核。常规 INT4 量化仍能为每个权重保留 16 种离散取值，而二值权重通常只有两个主要状态，三值权重则常见为负、零、正三个状态；可表达范围越小，模型越容易丢失细微但重要的信息。

有效比特数是将权重、缩放因子和辅助元数据平均到每个参数后得到的存储成本。 因此，1.125 有效 bit 并不意味着文件里每个参数都严格只占 1 bit，而是整个权重表示系统平均下来接近这一水平。

近乎无损的低比特压缩通常需要模型本身参与适配，而不是对成品权重进行一次粗暴转换。开发者可以把普通后训练量化理解为“把一张高动态范围照片压成低色深图片”，而更深入的低比特训练则像是“让画师从一开始就只用有限颜色作画”：两者文件都更小，但后者更有机会保住关键边缘和结构。

这也解释了为什么 Bonsai 2 不能只用“多少 bit”来评价。决定效果的还有分组大小、异常值处理、层间敏感度、激活精度、校准数据和内核实现；两个同为 2-bit 的模型，实际能力和速度可能相差很远。

体积变小，不代表一定跑得更快

Bonsai 2 27B 的直接收益是降低内存带宽压力，但实际生成速度取决于硬件有没有高效支持其权重格式。现代大模型推理往往受内存带宽限制，权重从 54GB 降到约 6GB，理论上可以显著减少每生成一个 token 所需搬运的数据；但如果运行时需要频繁解码、反量化或回退到通用算子，压缩收益就会被额外计算抵消。

上一代 Bonsai 27B 的第三方测试曾在 Apple M4 Pro 上报告约 40 tokens/s，也有人在 AMD RX 7800 XT 上以约 13GB 显存运行较长上下文，并达到约 40 tokens/s。这些数字说明低比特 27B 已具备交互式体验，但硬件、上下文长度、批量大小、提示词处理速度和生成速度不同，结果不能直接横向相加。

首 token 延迟是用户提交请求到模型输出第一个 token 的时间，而生成速度是模型随后每秒输出的 token 数。 对本地 Agent 来说，前者往往比峰值生成速度更重要，因为 Agent 会进行大量短调用，每次都要重新处理部分上下文和工具结果。

Bonsai 2 对 Agent 场景的价值尤其明显。传统聊天可能只调用模型一次，而一个深度研究或自动化 Agent 可能连续调用几十次甚至数百次，每一步都涉及上下文读取、结构化输出和工具选择；如果模型可以长期驻留在本地内存中，延迟、隐私和边际调用成本都会更可控。

与小模型相比，27B 压缩模型仍有自己的位置

压缩后的 27B 模型不等于一个原生 3B 或 7B 小模型，因为它们的计算量和知识容量仍然不同。Bonsai 2 虽然文件体积接近部分小模型，但每次前向传播仍要处理 270 亿参数；它节省的是存储和带宽，不会凭空把计算复杂度降到 3B 水平。

| 路线 | 主要优势 | 主要短板 | 更适合的场景 | |---|---|---|---| | 原生 3B～7B 模型 | 速度快、生态成熟、功耗较低 | 推理深度和知识容量有限 | 摘要、分类、简单助手 | | 常规 4-bit 14B～32B | 工具支持广，质量与体积平衡 | 仍需较大内存 | 桌面端编程与知识问答 | | Bonsai 2 27B 类极低比特模型 | 以较小体积保留 27B 级能力 | 依赖专用内核，计算量仍高 | 本地 Agent、复杂推理、隐私任务 | | 云端旗舰模型 | 综合能力强，维护成本低 | 数据需离开设备，持续调用有成本 | 高难度任务和弹性工作负载 |

Bonsai 2 最合理的使用方式不是取代所有小模型，而是填补“设备装得下，但又需要中型模型推理能力”的空档。对于电量敏感、只做简单分类的应用，原生小模型依然更合适；对于需要多步规划、代码理解和长链工具调用的本地助手，压缩 27B 才更有吸引力。

现在还不能忽略三个问题

运行时兼容性是 Bonsai 2 从演示走向普及的第一道门槛。上一代模型需要特定的 llama.cpp 分支或对应低比特内核才能发挥效果，而主线推理框架是否支持模型格式、CPU 与 GPU 后端是否都有优化，将直接决定普通开发者能否使用。

长上下文内存是第二道门槛。权重压到约 6GB 后，KV cache 可能成为新的内存大户；上下文越长、并发越高，缓存占用越明显，因此“支持 262K 上下文”不代表手机上可以低成本跑满 262K。

许可和可复现性是第三道门槛。开发者需要分别核对基础模型许可、压缩权重许可、商用限制、视觉组件授权以及运行时实现，不能仅凭“可以下载权重”就默认它满足严格意义上的开源定义。

结论：这是一场智能密度竞赛

Bonsai 2 27B 的核心贡献，是继续提高单 GB 存储能够承载的模型能力。PrismML 将这一方向概括为“智能密度”：如果能力接近的模型从 54GB 降到约 6GB，那么同一块设备能够容纳的模型规模、上下文空间和应用数量都会发生变化。

这次发布还没有证明云端大模型会被手机取代，但它已经让 27B 级本地模型从硬件展示走向更现实的产品选择。对于普通用户，变化可能是一款不联网也能工作的研究助手；对于开发者，变化则是推理架构从“所有任务都发往云端”变成“高频、隐私和低延迟任务留在设备，最困难的任务再交给云端”。

Bonsai 2 27B 是否真正成功，最终不会只由压缩倍数决定。更关键的标准是：它能否在主流推理框架中稳定运行，能否在长上下文和 Agent 调用中保持成功率，以及第三方能否复现官方所说的近乎无损。如果这三点成立，九倍压缩就不只是一个漂亮数字，而会成为 20B～30B 模型进入个人设备的关键节点。

参考来源

• Hugging Face 模型检索：Bonsai 2 27B：用于核对公开模型卡、权重文件、许可和社区版本。
• llama.cpp GitHub 仓库：主流本地大模型推理项目，可用于跟踪低比特格式、硬件后端与运行时支持情况。