Bonsai-27B 和 Ternary-Bonsai-27B 的更新（PR 相关）

以下上游状态部分来自 https://github.com/PrismML-Eng/Bonsai-demo 上游状态 二进制 Q1_0 已在 llama.cpp 上游多个后端中原生支持：CPU（通用、NEON 和优化的 x86）、Metal、CUDA 和 Vulkan。 运行时状态 - llama.cpp（CPU、Metal、CUDA、Vulkan）✅ 已合并到上游，开箱即用 - MLX（1-bit）⏳ 等待上游合并：mlx#3161；合并前请使用 PrismML-Eng/mlx（分支 prism，由 setup.sh 自动构建） 三进制上游状态 三进制支持正在逐步迁移到 llama.cpp 主线版：后端逐个落地，因此目前是主线版和我们分支的混合。实际后果是：我们目前提供三个三进制 GGUF 变体，每个需要在合适的环境中运行。 | 文件格式 | 运行环境 | |----------|----------| | *-Q2_0.gguf | 分组大小 128。本演示使用的格式，与我们的分支兼容。一旦 llama.cpp 迁移完成，这些文件将被弃用并替换为 PQ2_0 gguf。本演示/分支二进制文件。无法在主线版上加载（类型 ID 相同，但块大小不同） | | *-Q2_0_g64.gguf | 分组大小 64（2.25 bpw）。官方 llama.cpp 格式；这些文件将重命名为普通的 Q2_0，替换当前版本。主线版 llama.cpp（目前仅 CPU 和 Metal） | | *-PQ2.gguf | 尚未支持。计划作为未来的分支格式：与当前 group-128 Q2_0 格式相同，但拥有自己的 ggml 类型 ID，以便与上游 Q2_0 共存。尚无支持（计划在分支中支持） | 各后端迁移状态： | 后端 | 状态 | 位置 | |------|------|------| | CPU（ARM NEON + 通用标量） | ✅ 已合并到 llama.cpp 主线版 | ggml-org/llama.cpp#24448 | | Metal | ✅ 已合并到 llama.cpp 主线版 | ggml-org/llama.cpp#25419 | | Vulkan | 🔄 正在上游推进（独立 PR，非我们提交） | ggml-org/llama.cpp#25430 | | CUDA | 🔄 正在上游审查中 | ggml-org/llama.cpp#25707 | | x86（AVX-512-VNNI） | ⏳ 待定 | TBD | 上述 Vulkan PR 已获得批准✅，预计将在今天晚些时候/本日结束前合并。 llama.cpp 上其他与 Bonsai 相关的待合并 PR： - cuda: extract Q1_0 elements via __byte_perm #25628（t/s +5-10%，pp +1-2.5%） - ggml-cpu: ARM Repack kernels for Q1_0 #23492（请查看内部的 t/s 基准测试） - ggml-cpu: Optimized Arm NEON cpu q1_0 dot（with plain/DP/I8MM） #23358（请查看内部的 t/s 基准测试） 希望未来能看到更多关于 Bonsai 和 Ternary-Bonsai 模型优化的 PR。 昨天我看到一些人（来自其他 Bonsai 讨论串）提到这些模型在代理编码等方面表现不佳。我认为这是对 1-bit 版本模型的过高期待。但模型创建者在模型卡中记录了相关说明。分享如下。 Bonsai-27B 局限性 - 质量与体积的权衡：二进制模型保留了全精度平均性能的 89.5%，差距适中且可预测——推理核心（数学、编码）与基线相差仅几个百分点，差异集中在要求最高的类别；如果质量优先，请考虑三进制 GGUF 构建（94.6%） - 代理编码（长周期、多文件、运行测试并修复的工作流）目前不是本次发布的主要目标；针对代理编码调优的 Bonsai 27B 变体是路线图上的下一步 - KV 压缩空间：本次发布标配 4-bit KV 缓存；Bonsai 对 KV 缓存误差的容忍度随上下文长度增加，早期结果表明关键缓存可以推向 sub-2-bit 范围——这是在固定设备内存预算内实现更长上下文的途径 Ternary-Bonsai-27B 局限性 - 质量与体积的权衡：三进制模型保留了全精度平均性能的 94.6%，差距适中且可预测——推理核心（数学、编码）与基线相差仅几个百分点，差异集中在要求最高的类别 - 不适合手机：约 7.2 GB 的三进制构建超出了 iOS 应用约 6 GB 的内存预算；如需手机部署，请使用 1-bit 版本（通过 MLX Swift） - 当前以 2-bit 槽位提供服务：部署体积（~7.2 GB）高于表示的原始目标（~5.9 GB）；原生三进制内核是当前的工程目标，完成后将直接把剩余的带宽和体积优势转化为延迟和能效提升 - 代理编码（长周期、多文件、运行测试并修复的工作流）目前不是本次发布的主要目标；针对代理编码调优的 Bonsai 27B 变体是路线图上的下一步 - KV 压缩空间：本次发布标配 4-bit KV 缓存；早期结果表明关键缓存可以推向 sub-2-bit 范围——这是在固定设备内存预算内实现更长上下文的途径 希望下次他们能提供极致优化的模型（无上述局限性）。 我刚刚在没有设置任何参数的情况下对 Bonsai-27B 进行了 llama-bench。在我的笔记本电脑 GPU 4060（8GB VRAM）上得到 pp - 600 t/s 和 tg - 30 t/s。我没有对这款模型抱有过高期望，很高兴能在我微小的显存上运行它。将用它进行聊天和写作。等待 Bonsai 团队和 llama.cpp 社区的后续优化，以获得最佳性能。 你得到了多少 t/s？有人尝试用它进行编码、写作或其他任务吗？还有人在手机上运行吗？我无法在我的 8GB RAM 手机上加载，会太慢。请分享你对这个模型性能的反馈。