学术工具 / 本地部署大模型 / 进阶:Bonsai 2 27B

进阶:部署 Bonsai 2 27B

这一页只讲一件事:显存不大,却想跑 27B。Bonsai 用 2 bit / 1 bit 的极低比特把 27B 压到 6–7 GB, 代价是文件版本和你用的构建必须配对——配错会"能连上、却输出乱码"。 8B / 4B 这类标准模型怎么装、Ollama 与 LM Studio 怎么用,都在主线页讲过了,这页不重复。

第一次部署本地模型?先回主线页。 这页默认你已经会:下载压缩包并解压到同一目录、在 PowerShell 里执行命令、知道 -ngl 和 -c 是什么。这些都在主线教程的第 1–4 节,那里还有一个自动检查硬件与文件的脚本。 如果你只是想要一个能用的本地模型,主线页的 8B / 4B 方案更省事,也不需要这页的任何额外步骤。

1 · 动手前必须知道的三件事

① Bonsai 2 27B 在官方版 llama.cpp / Ollama / LM Studio 上"能加载成功,然后输出乱码"。 说白了:程序读到这个文件时不认为自己读错了,于是照常往下跑,只是每句话都是胡言。 原因是它自带的 group-64 Q2_0 文件用的类型号已经被上游占用,官方构建认得这个号、 却不认得这个模型需要的 Hadamard 变换。官方为此把这条权重单独发在 …-gguf-dev 仓库, 并把 "prism-fork-required"(必须用 PrismML 改过的构建)写进了文件名。 结论:Bonsai 2 只能用 PrismML 自己的 llama.cpp 构建跑,没有"到处都能用"的选项。
② 想要 27B 又完全不想碰特殊构建,是有这条路的:上一代 Ternary-Bonsai 27B 的 _g64 文件。 文件名是 *-Q2_g64.gguf,它就是 llama.cpp 官方的 Q2_0 格式, 上游构建和 fork 构建都能读,因此可以像主线页那样丢给 Ollama / LM Studio。 差在哪:它是上一代模型,没有 Bonsai 2 27B 的原生工具调用与视觉能力。 本页主线(第 3–5 节)走的是 Bonsai 2 27B + fork 构建;只想跑通 27B 的话,选 _g64 那条文件即可,其余步骤照样能用。
③ 别用仓库里没有 g64 后缀的旧 *-Q2_0.gguf。 那是格式统一之前的遗留布局(group-128 存成类型号 42),现在官方 Q2_0 已定义为 group-64, 新构建会明确拒绝并提示 legacy layout。要用遗留文件只能退回冻结的旧版构建,不建议。

一张表看懂文件后缀

文件后缀是什么哪些程序能读
*-Q2_g64.gguf(上一代 27B)
*-Q2_0_g64.gguf(其余尺寸)
官方 group-64 Q2_0,2.25 bpw(每权重 2.25 比特),后端覆盖最广(含 Vulkan/SYCL) 上游 llama.cpp + fork 构建都能读 → 可进 Ollama / LM Studio
*-PQ2_0.gguf fork 自己的打包,group-128,2.13 bpw,磁盘和内存小约 6% 仅 fork 构建(CUDA/Metal/CPU/ROCm 有内核;Vulkan、SYCL 还没有)
*-PTQ1_0.gguf / *-Q1_0.gguf 更低比特(Bonsai 2 的 1-bit 档、上一代 1-bit Bonsai) 仅 fork 构建;类型号在上游范围之外,读不了时会明确报错
*-Q2_0.gguf(没有 g64) ⚠️ 已废弃的遗留布局 只有旧版 fork 能用,新构建直接拒绝
Bonsai 2 的 Q2_0 ⚠️ 仅供测试,单独发布在 -gguf-dev 仓库 仅 fork 构建。在上游构建上会静默输出乱码

2 · 先看这台机器跑不跑得动 27B

27B 的权重就要 6–7 GB,加上上下文缓存和运行开销,下载之前先算这一笔, 比下完 7 GB 才发现跑不动要划算得多。官方给的峰值内存估算(权重 + 激活 + FP16 KV 缓存 + 约 1.2 GB 运行缓冲,纯文本; 要图片能力再加约 0.9 GB 的视觉投影器):

模型格式权重4K 上下文10K100K
Bonsai-27B(1-bit)llama.cpp Q1_03.53 GiB4.8 GiB5.2 GiB10.8 GiB
Ternary-Bonsai-27Bllama.cpp Q2_06.66 GiB7.8 GiB8.1 GiB13.7 GiB
参照:27B 16-bitGGUF BF1647.73 GiB49 GiB49.6 GiB55.2 GiB
参照:27B "4-bit"UD Q4_K_M15.73 GiB17.2 GiB17.6 GiB23.2 GiB

27B 档的 FP16 KV 缓存约 64 KiB/token(10 万 token 约 6.3 GB),所以 -c 定多高, 直接决定你要不要再多花几 GB 内存。

速度现实:请先接受这一段。 8 GB 显存跑 27B 一定会溢出到内存,而内存逐层执行比显存慢一个数量级:一个 4 token 的回答也要百秒级。 这不是部署失败,是物理限制。纯 CPU 模式下 27B 每个 token 更慢,只适合"挂着等"的一次性任务。

因此,本地模型在论文助手里请这样用:离线润色、改写、摘要、翻译用它; 长文档评审、多步工具调用、联网检索用平台托管模型。 把 -c 调小、关掉占显存的程序,是这台机器上唯二真正有效的提速手段。
27B 不是 MoE,是 dense 混合线性注意力。所以社区里常见的 --cpu-moe / --n-cpu-moe(把专家权重留在内存)对它没有任何作用——它没有 expert 张量。 "部分内容放内存"本来就是 -ngl 99 的默认行为:能塞进显存的层塞进去,塞不下的自动留在内存执行, 不会失败,只是慢。只有多张卡时 --tensor-split / --main-gpu / --split-mode 才有意义。

3 · 下构建包

构建包只能自己从 GitHub Releases 获取: https://github.com/PrismML-Eng/llama.cpp/releases。本页只给链接,不自建镜像、不代转文件。 GitHub 在国内可达性差,需要代理请提前准备。 另外:论文助手不托管这个进程——它由你自己启动、自己关闭,应用只负责连上它。

发布标签 prism-b10743-adfffbe。Windows x64 的包与体积(请以发布页当前数值为准):

文件体积什么时候选
llama-prism-b10743-adfffbe-bin-win-cuda-13.3-x64.zip约 149 MB nvidia-smi 报的 CUDA Version ≥ 13.3
…-bin-win-cuda-12.4-x64.zip约 257 MB CUDA Version ≥ 12.4 且 < 13.3
跑 27B 首选这一类
cudart-llama-bin-win-cuda-13.3-x64.zip / …-12.4-x64.zip各约 391 MB 选 CUDA 包时必须一起下,解压到同一目录,否则缺 CUDA 运行库 dll
…-bin-win-hip-radeon-x64.zip约 328 MB AMD 显卡(装有 HIP SDK)。该构建有 PQ2_0 内核
…-bin-win-vulkan-x64.zip(约 31 MB,需再配 CPU 包)— 没有 CUDA/HIP 时的兜底。注意:Vulkan 后端还没有 PQ2_0 内核,只能用 _g64 文件
…-bin-win-cpu-x64.zip(约 19 MB)— 纯 CPU。27B 在这个模式下慢到基本不可用,见第 2 节的速度现实
…-bin-win-cuda-13.4-arm64.zip / …-bin-win-cpu-arm64.zip— ARM64 的 Windows(骁龙本)

该拿哪个包,只看这一条命令的输出:nvidia-smi(不带任何参数)。表头 CUDA Version: x.y 是驱动支持上限,它常常低于你装的 CUDA 工具链版本,以它为准选包就行。 完全读不到 nvidia-smi(没有 NVIDIA 显卡或驱动异常)才会落到 HIP / Vulkan / CPU。

和主线页一样:exe 和所有 dll 必须在同一个目录,否则启动直接失败。 建议单独开一个目录(例如 D:\llm\bin\bonsai-cuda\),别和主线页那套官方构建混在一起—— 两套构建的 dll 混放,跑错的那个只会报一堆看不懂的错。

4 · 下权重

仓库:https://huggingface.co/prism-ml/Ternary-Bonsai-2-27B-gguf。 这一档有两个文件必须一起拿:主权重(PQ2_0 约 7.2 GB,或 PTQ1_0 约 6.0 GB) 和视觉投影器 mmproj(Q8_0,约 0.6 GB——没有它就只剩文本能力)。

# 文件名用通配,避免手写错具体后缀;多个 pattern 之间用空格分隔
hf download prism-ml/Ternary-Bonsai-2-27B-gguf --include "*PQ2_0.gguf" "*mmproj*Q8_0.gguf" --local-dir D:\llm\models\bonsai2-27b

hf 命令随 pip install -U huggingface_hub 一起来;国内网络先设镜像 $env:HF_ENDPOINT = "https://hf-mirror.com",或者直接在网页上手动下这两个文件,效果一样。 不要整仓库拉——一个仓库里躺着十几个量化版本,全拉是几十 GB。

5 · 启动

# 解压后:llama-server.exe 要和 ggml-*.dll、cudart64_*.dll 放在同一目录
cd D:\llm\bin\bonsai-cuda

.\llama-server.exe `
  -m "D:\llm\models\bonsai2-27b\Ternary-Bonsai-2-27B-PQ2_0.gguf" `
  --host 127.0.0.1 `
  --port 18080 `
  -ngl 99 `
  -fa on `
  -c 16384 `
  --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.05 `
  --jinja `
  --mmproj "D:\llm\models\bonsai2-27b\mmproj-Ternary-Bonsai-2-27B-Q8_0.gguf"
这几类开关不建议默认打开,官方文档里有、但质量或副作用要你自己验收: 4-bit KV 缓存(--cache-type-k/v q4_0,KV 从 64 降到约 18 KiB/token;官方明说它是省内存工具而不是提速工具, 且质量要靠 make_kv_bias.sh 校准的均值偏置)、投机解码(dspark drafter,官方称 decode 提速约 1.8–2×, 代价是关掉 prompt cache 并强制单 slot;Bonsai 2 27B 目前没有官方 drafter)、 以及 -ot/--override-tensor(能把指定大张量钉在内存换显存,但填错模式只会让加载失败)。

6 · 验证与接回论文助手

  1. 另开一个 PowerShell 窗口(跑服务那个别关):
    curl http://127.0.0.1:18080/health
    curl http://127.0.0.1:18080/v1/models
    第一条返回 ok 或空响应;第二条要返回一段带模型名的 JSON。 如果第二条返回的是 HTML 页面,说明这个端口被本机别的程序占了,换端口重来。
  2. 在模型服务设置 → 模型来源 → 🔌 我的模型服务(自定义)→ ① 本机部署点 🔍 检测本机服务。 注意应用只自动扫 8080 / 11434 / 1234 三个端口,你用 18080 的话要点 ② 已配置的服务 → +新增服务,地址填 http://127.0.0.1:18080/v1。
  3. 连上后应用会在后台做一次真实请求,把工具/图片/思考能力和 n_ctx 实测回填。 第一次连接会等得久,因为那本身就是一次生成,27B 可能要几分钟。
  4. 如果服务加了 --api-key,/v1/models 会返 401,检测会直接告诉你"要求密钥", 在+新增服务的密钥栏填同一个 Key 即可(应用同时发 Authorization: Bearer 与 x-api-key)。
  5. 如果提示"端口开着但几秒内没回应",是服务正在长时间生成、单 slot 把请求排队了,等它空闲再点一次。 已经登记好的服务不受影响,可以照常继续用。
能力显示"未探测到工具调用"时先看这两处:命令里有没有 --jinja,以及你用的是不是 27B 这一档 (只有 27B 在官方脚本里开了工具调用)。都不是问题的话,那就是模型能力边界,不是配置没勾对—— 纯文本改写、润色、摘要照常可用。
只监听 127.0.0.1。上面每条命令都写死了本机地址。OpenAI 兼容接口默认无鉴权, 改成 0.0.0.0 暴露到校园网或公网,等于把模型和显卡交给同网段任何人。 需要远程访问请用 Tailscale 一类虚拟组网,或反向代理 + HTTPS + 鉴权与轮换密钥。 也不要把论文发给来路不明的公网接口——那等同于把论文发到网上。

7 · 许可与来源

本页只提供官方链接:模型权重在 Hugging Face(prism-ml 组织), 推理构建在 PrismML 的 llama.cpp 仓库 GitHub Releases,示例脚本来自 PrismML-Eng/Bonsai-demo。论文助手不下载、不缓存、不转发任何第三方权重或二进制, 也不自建镜像——分发与许可以各上游仓库的 LICENSE 为准,需要二次分发请先自行确认。

页面内容最后核对时间:2026-10-21。发布标签、文件名与体积会随上游更新变化,动手前请对照 Releases 页与 模型仓库的当前内容。 标准模型(8B / 4B / 1.7B)与 Ollama、LM Studio 的装法见本地部署主线教程。