llamafile v0.10.5

llamafile v0.10.5

产品发布

llamafile v0.10.5 已发布！更新的 llama.cpp 核心支持让您可以在本地运行两个大型模型：压缩版 6GB 三值 Bonsai 27B 和快速的 118B Laguna-S-2.1 编码 MoE。此版本还修复了文档并添加了预构建的 transcribefile 语音转文本二进制文件。

#### Anushri Gupta

2026年8月5日

—

3分钟阅读

llamafile v0.10.5 已发布，它追踪了更新的 llama.cpp，使其能够运行近期人们常用的两个模型：Ternary Bonsai 27B 和 Poolside 的 Laguna-S-2.1。这两个模型此前已以 GGUF 权重形式存在，但旧版 llamafile 无法加载它们，因为捆绑的 llama.cpp 尚未支持它们的架构和量化方式。此版本还包含文档修复，涵盖帮助系统、不同版本的二进制文件以及 GPU 支持。

两个可在本地运行的大型模型

这两个新模型因相同原因而引人注目，但实现方式不同。它们听起来都太大无法在笔记本电脑上运行，但实际上并非如此，这取决于它们的构建方式。

Ternary Bonsai 27B 是 PrismML 的 Qwen3.6-27B 的压缩版本。其权重为三值，每个权重仅限于 {-1, 0, +1}，相当于每个权重约 1.58 位，而非 16 位。结果是一个约 6GB 的 27B 模型，可在笔记本电脑上运行，同时保留完整精度模型的大部分质量。它还是多模态模型，但视觉模块仅在实际传入图像时加载。权重和详细信息可在 Hugging Face 上找到。

Laguna-S-2.1 是 Poolside 的开源编码模型。它列出的参数为 118B，听起来像是服务器模型，但它是专家混合模型：总共有 118B，每个 token 激活 8B。生成成本基于每个 token 激活的 8B，而非全部 118B，因此量化版本可适应消费级内存并实现可用速度。它专为代理编码和长会话设计，具有大上下文窗口。值得注意的是：量化检查点配置为 256K 上下文，而非 BF16 权重支持的完整 1M。

速度取决于量化方式和硬件，但两者都足够快，可以交互使用。一年前，27B 或 118B 模型在个人电脑（笔记本或台式机）上实现交互式使用还不可想象，这意味着需要足够的 RAM，而非服务器或租用的 GPU。

为什么现在出现这些模型：平淡的部分

llamafile 只能运行其嵌入的 llama.cpp 支持的模型，而 llama.cpp 更新迅速，因此 llamafile 中模型支持的真正瓶颈是跟上上游进度。在 v0.10.5 中，我们两周内进行了三次同步，使嵌入的 llama.cpp 跨越了三个上游版本，并改进了中途起草这些同步 PR 的代理技能，因此后续同步在合并前需要更少的人工干预。这种改进将帮助我们更快地为您提供新模型，而非数月后。

这固定了一个经过测试的 llama.cpp 支持检查点，而非与持续移动的上游实现同步。我们预计未来几个版本中将有更少的修正提交和更小的差异。

对于一个价值完全在于打包的项目，这种同步工作比它恰好解锁的两个模型更重要。这些模型证明了打包机制的有效性。

打包与文档

（此处为第二段内容，根据用户要求未在本次翻译中处理）

关于打包的一个说明：transcribefile 是基于 transcribe.cpp 构建的独立语音转文本可执行文件，自六月首次推出以来，现在得益于社区贡献已作为发布产物提供。该功能本身并无新意，您只需不再自行编译二进制文件即可使用本地语音转文本功能。

在文档方面，本次发布新增了对新帮助系统的说明和 CLI 参数的覆盖。社区贡献也解决了几个长期存在的困惑：llamafile、llamafile-thin 与其他发布二进制文件的区别，以及当前 GPU 支持情况包括 Vulkan 后端。感谢所有提交并修复这些问题的社区成员。

获取方式

从发布页面下载 v0.10.5 。如果遇到问题，通过提交 issue 或参与讨论是与我们沟通最快的方式。