-ngl 和 -c
是什么。这些都在主线教程的第 1–4 节,那里还有一个自动检查硬件与文件的脚本。
如果你只是想要一个能用的本地模型,主线页的 8B / 4B 方案更省事,也不需要这页的任何额外步骤。
1 · 动手前必须知道的三件事
Q2_0 文件用的类型号已经被上游占用,官方构建认得这个号、
却不认得这个模型需要的 Hadamard 变换。官方为此把这条权重单独发在 …-gguf-dev 仓库,
并把 "prism-fork-required"(必须用 PrismML 改过的构建)写进了文件名。
结论:Bonsai 2 只能用 PrismML 自己的 llama.cpp 构建跑,没有"到处都能用"的选项。
_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 上下文 | 10K | 100K |
|---|---|---|---|---|---|
| Bonsai-27B(1-bit) | llama.cpp Q1_0 | 3.53 GiB | 4.8 GiB | 5.2 GiB | 10.8 GiB |
| Ternary-Bonsai-27B | llama.cpp Q2_0 | 6.66 GiB | 7.8 GiB | 8.1 GiB | 13.7 GiB |
| 参照:27B 16-bit | GGUF BF16 | 47.73 GiB | 49 GiB | 49.6 GiB | 55.2 GiB |
| 参照:27B "4-bit" | UD Q4_K_M | 15.73 GiB | 17.2 GiB | 17.6 GiB | 23.2 GiB |
27B 档的 FP16 KV 缓存约 64 KiB/token(10 万 token 约 6.3 GB),所以 -c 定多高,
直接决定你要不要再多花几 GB 内存。
因此,本地模型在论文助手里请这样用:离线润色、改写、摘要、翻译用它; 长文档评审、多步工具调用、联网检索用平台托管模型。 把
-c 调小、关掉占显存的程序,是这台机器上唯二真正有效的提速手段。
--cpu-moe / --n-cpu-moe(把专家权重留在内存)对它没有任何作用——它没有 expert 张量。
"部分内容放内存"本来就是 -ngl 99 的默认行为:能塞进显存的层塞进去,塞不下的自动留在内存执行,
不会失败,只是慢。只有多张卡时 --tensor-split / --main-gpu / --split-mode 才有意义。
3 · 下构建包
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。
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"
- 只有 27B 加
--jinja:官方脚本只给 27B 开了--jinja,也就是只有它有原生工具调用; 其余尺寸保持--temp 0.5 --top-p 0.85 --top-k 20 --min-p 0并关掉思考输出 (--reasoning-budget 0 --reasoning-format none --chat-template-kwargs {"enable_thinking": false})。 在 PowerShell 里传--chat-template-kwargs要用Start-Process -ArgumentList数组, 否则内层引号会被吃掉。 --mmproj的文件名以你实际下到的为准,上面只是常见写法。- 不是 CUDA/HIP 构建时再加
--image-max-tokens 1024:大图在这类后端上预填充要几分钟, 官方默认给图片 token 设了上限。 - 上下文按内存分层取(官方脚本的默认口径):内存 ≤11 GB →
-c 8192;≤23 GB → 16384; ≤35 GB → 32768;≤71 GB → 65536;再往上 27B 可到 131072。不要用-c 0(那会取模型训练时的全长,直接把内存撑爆)。 - 端口这里写
18080:8080太容易被本机别的程序(尤其是 Docker / WSL 的端口转发)占走, 占了还看不出来。用哪个端口都行,但论文助手里填的地址要跟着一致。 - 运行目录必须能找到 dll:在该目录里执行
llama-server.exe,或者把这个目录加进PATH。 - 首次很慢:载入权重 + 建 CUDA graph,27B 可达数分钟,这期间所有请求都会超时。窗口停住别关。
--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 · 验证与接回论文助手
- 另开一个 PowerShell 窗口(跑服务那个别关):
第一条返回curl http://127.0.0.1:18080/health curl http://127.0.0.1:18080/v1/modelsok或空响应;第二条要返回一段带模型名的 JSON。 如果第二条返回的是 HTML 页面,说明这个端口被本机别的程序占了,换端口重来。 - 在模型服务设置 → 模型来源 → 🔌 我的模型服务(自定义)→ ① 本机部署点 🔍 检测本机服务。
注意应用只自动扫
8080 / 11434 / 1234三个端口,你用18080的话要点 ② 已配置的服务 → +新增服务,地址填http://127.0.0.1:18080/v1。 - 连上后应用会在后台做一次真实请求,把工具/图片/思考能力和
n_ctx实测回填。 第一次连接会等得久,因为那本身就是一次生成,27B 可能要几分钟。 - 如果服务加了
--api-key,/v1/models会返 401,检测会直接告诉你"要求密钥", 在+新增服务的密钥栏填同一个 Key 即可(应用同时发Authorization: Bearer与x-api-key)。 - 如果提示"端口开着但几秒内没回应",是服务正在长时间生成、单 slot 把请求排队了,等它空闲再点一次。 已经登记好的服务不受影响,可以照常继续用。
--jinja,以及你用的是不是 27B 这一档
(只有 27B 在官方脚本里开了工具调用)。都不是问题的话,那就是模型能力边界,不是配置没勾对——
纯文本改写、润色、摘要照常可用。
0.0.0.0 暴露到校园网或公网,等于把模型和显卡交给同网段任何人。
需要远程访问请用 Tailscale 一类虚拟组网,或反向代理 + HTTPS + 鉴权与轮换密钥。
也不要把论文发给来路不明的公网接口——那等同于把论文发到网上。
7 · 许可与来源
本页只提供官方链接:模型权重在 Hugging Face(prism-ml 组织),
推理构建在 PrismML 的 llama.cpp 仓库 GitHub Releases,示例脚本来自
PrismML-Eng/Bonsai-demo。论文助手不下载、不缓存、不转发任何第三方权重或二进制,
也不自建镜像——分发与许可以各上游仓库的 LICENSE 为准,需要二次分发请先自行确认。