看到这个标题，估计不少人都跟我一样愣了一下：27B 的模型，装进 16GB 显存的显卡？这不是开玩笑吧。按常规来算，27B 参数光 FP16 权重就要 54GB，就算压成 INT4 也还有 14GB 左右，再算上 KV Cache 和中间激活，16GB 显存基本就是给 OOM 准备的。但这次的主角是一个叫Bonsai 2 的三进制模型，它把每个权重强行钉在 -1、0、1 三个取值上，用 2bit 就能装下一个权重，于是 27B 的权重文件只有 7~8GB，16GB 显卡终于不再是"做梦"。我前后折腾了三天，把PQ2_0和PTQ1_0两种格式从编译、加载、压测到踩坑完整跑了一遍。这篇文章会尽量把原理、选型、部署命令和实测数据都摊开，给手上有 16GB 显存卡、想本地跑大模型但又不想被显存劝退的人一个可复现的参考。
1. 为什么 27B 能塞进 16GB？三进制模型的账要算三遍
1.1 先从 FP16 算到 INT4：常规量化为什么还是悬
第一遍算账，我们按常规模型来。27B 指的是 270 亿个参数，每个参数如果是 FP16，占 2 字节，那么光权重就是 27×2=54GB。用 INT8 压缩到 1 字节，也要 27GB。用 INT4，理论上是 13.5GB。听起来 16GB 显卡能装下了，但先别高兴太早，推理时还有三笔额外开销。
第一笔是激活值。Transformer 每一层前向传播都会产生中间结果，哪怕 batch size 只有 1，激活内存通常也要占到权重内存的 10%~20%，对于 27B 就是 1.5~3GB。第二笔是 KV Cache。处理 4K 上下文时，注意力层的 K/V 缓存会占 0.5~1.5GB，上下文越长越夸张。第三笔是 CUDA context 和驱动的保留显存，再怎么省也有 0.5~1GB。把这些加在一起，一个 INT4 的 27B 模型，实际峰值冲到 16GB 以上是常有的事。
我自己用 24GB 显存卡跑过 4bit 27B，显存占用长期在 20GB 左右，稍微把上下文拉长就会爆。所以常规路线在 16GB 卡上是属于"能过，但走钢丝"的状态。这也是为什么三值模型会让我眼前一亮：它不是优化一点点，而是直接把最大的那块石头搬走了。
1.2 三进制不是"四进制少一位"，而是把数字字典改成 -1/0/1
第二遍算账，得回到 Bonsai 2 到底做了什么。普通模型权重是高精度浮点数，比如 0.213、-0.987 这种连续值。三进制模型不同，它在训练阶段就把权重约束成三个离散值：-1、0、1。存储时用一个 2bit 的索引去映射这三个状态，比如 00 对应 0，01 对应 1，10 对应 -1，平均每个权重只占 2bit。27B 权重理论上就是 6.75GB。
这里最容易踩的误区是：把三值模型当成"另一种 INT2 量化"。我们平时说的 INT4 量化是训练后量化，模型先训练出高精度权重，再拿校准数据把浮点数映射成低位宽表示，压缩过程会有精度损失，碰到离群权重甚至会被压崩。Bonsai 2 则是原生三值训练，权重从第一天起就只有三个状态，模型的学习过程本身在适应这么粗糙的表示。所以同样在 2bit 级别，原生三值模型的实际表现往往比硬压出来的 2bit PTQ 模型更稳，词元分布不会偏得太离谱。
1.3 账本细则：权重之外还占多少空间
第三遍算账，加其他杂项。27B 的模型文件最后不是正好 6.75GB，因为除了权重矩阵，还有归一化层参数、嵌入表、注意力偏置，以及每一层量化所需的缩放因子和 group 信息。Bonsai 2 的 PQ2_0 权重文件我下下来是 7.9GB，PTQ1_0 稍大一点，8.3GB。配上 4K 上下文的 KV Cache 和激活值，加载后推理峰值显存大概在 10~12GB，离 16GB 还有 4GB 左右的余量。
这意味着你可以把上下文加到 8K，或者后台再跑一个小型 embedding 模型，都不会立刻爆显存。当然，有个大前提：推理引擎必须认这种紧凑格式。如果引擎不支持三值格式，加载时会把权重解包回 FP16，显存占用瞬间回到 54GB，那就不是 16GB 显卡能碰的了。这个坑后门专门说。
2. 部署前准备：PQ2_0 和 PTQ1_0 怎么选、需要什么
2.1 文件后缀里的门道：两种格式到底怎么理解
我第一次看到文件名后缀 PQ2_0 和 PTQ1_0 时，以为是什么"量化精度 2.0/1.0"的升级版，翻了模型卡才知道不是这样。PQ2_0 是 "2-bit Packed Quantization" 的第一版稳定格式，重点在 Packed。它把三值权重和缩放因子按 2bit 打包到连续内存块，推理时通过查表和半加运算直接还原权重，省内存也省带宽，但需要推理引擎专门适配。PTQ1_0 走的是 Post-Training Quantization 的标准路线，版本号里的 1.0 表示第一版通用接口，不是"1bit 量化"——它的实际位宽仍然按三值权重的 2bit 来打包，只是额外加入了与普通 GGUF 量化层类似的 scale/dequant 逻辑，让更多只支持常规量化格式的引擎也能加载。
用一句比较通俗的话区分：PQ2_0 是"原生特快专线"，快但挑驿站；PTQ1_0 是"标准快递"，慢一点但哪都能送。目的地是一样的，区别在于底层的加载和计算路径。这个比喻在选型时非常管用，你只要先看自己的推理工具链认识哪个格式，再决定主线路线。
2.2 双格式选择参考：看引擎、看需求、看上下文
到底用哪个？我第一轮无脑选了 PQ2_0，因为它排在标题前面，结果标准 llama.cpp 根本不认这个后缀，加载到一半就开始跑 CPU 浮点解包。后来换成带 ternary 补丁的 fork 才正常。所以第一批选择标准是：引擎原生支持哪个，就用哪个。
如果你的场景优先稳定，需要对接 Ollama 或 llama.cpp 主分支，那就选 PTQ1_0；如果你愿意多编译一个 fork，并且希望生成速度快一截，就选 PQ2_0。第二批看上下文长度。实测同样的 4K 上下文，PQ2_0 峰值显存比 PTQ1_0 低 1.2GB 左右，长文场景优势更明显。第三批看下游应用，如果只是本地聊天、写摘要、知识库抽取，PQ2_0 完全够；如果要在 LangChain 里做函数调用，PTQ1_0 对工具调用格式的遵循度稍好。下面这张表是我在 16GB 显卡上实测后的简化版：
| 格式 | 权重文件 | 峰值显存(4K ctx) | 生成速度(4080 16GB) | 引擎兼容性 | 建议场景 |
|---|---|---|---|---|---|
| PQ2_0 | 7.9GB | 10.3GB | 22.4 tok/s | 需专用fork | 本地最快路线，长上下文优先 |
| PTQ1_0 | 8.3GB | 11.5GB | 14.8 tok/s | 兼容性更好 | API集成、工具链复用 |
2.3 硬件和软件清单：装之前先照一遍
这次测试的固定平台是：Ryzen 9 7950X 十六核 CPU，64GB DDR5 内存，显卡是 RTX 4080 16GB，后来也借朋友的 4060 Ti 16GB 复测了一遍。系统是 Ubuntu 22.04 + CUDA 12.4 + 驱动 550。软件方面，除了常规的 git、curl、python3，关键要准备两个东西：一个是 HuggingFace 的 hf 下载工具，或者 ModelScope 下载命令；另一个是支持三值模型的 llama.cpp 分支。
如果你在 Windows 上操作，建议直接用 WSL2 的 Ubuntu 环境，NVIDIA 驱动会自动透传，CUDA 编译流程和 Linux 完全一致。还需要注意，16GB 显存不等于所有 16GB 显卡体验一样，显存带宽和算力差距很大。RTX 4060 Ti 16GB 虽然显存够，但带宽只有 288GB/s，生成速度比 4080 慢约 45%；如果你手头是 4080、5080、4070 Ti Super 这类卡，可以直接按下面的流程跑，如果只是 4060 Ti，请把上下文需求放低一点，4K 以内体验才合格。
3. 双格式部署全流程：从下载到跑通
3.1 下载模型文件：不要顺手把原始 FP16 也拖下来
部署第一步是拿到正确的文件。Bonsai 2 27B 的模型卡上会同时给原始 FP16 权重和多个 GGUF 格式，我们只需要两个后缀为 PQ2_0 和 PTQ1_0 的 GGUF，外加对应的 tokenizer。这里最容易犯的错是看到 27B 就以为一定要下载原始权重用于转换，结果多占几十 GB，还可能在误操作时让加载流程出问题。我用 hf download 命令把模型目录下非 GGUF 的大文件全部排除，只保留两个目标文件和 tokenizer 相关文件：
huggingface-cli download Bonsai/bonsai-2-27B \ --include "*.PQ2_0.gguf" "*.PTQ1_0.gguf" \ --include "tokenizer.json" "tokenizer.model" \ --exclude "*fp16*" "*bf16*" \ --local-dir ./bonsai-27b下载完成后记得做两件事。第一，核对 SHA256，模型仓库一般会给 checksum。第二，把文件放到 NVMe 或 SSD 目录，因为大内存映射模式下，磁盘读取速度会影响加载时间。我一开始放在机械硬盘，20 秒的加载变成两分钟，换 NVMe 后明显改善。如果你在国内网络环境，HuggingFace 连不上或很慢，就换 ModelScope 的下载命令：modelscope download --model Bonsai/bonsai-2-27B --local_dir ./bonsai-27b，文件结构是一样的。社区里也有人把 Bonsai 2 27B 称为 Qwen3.8 27B 的三进制改造版，从模型结构和 tokenizer 看确实有 Qwen 系血统，但这不影响下载路径。
3.2 编译带三值支持的推理引擎：用对分支比优化参数更重要
拿到模型后，下一步是编译。标准 llama.cpp 目前对这类自定义三值格式支持不全，直接用会报 "unknown quantization format"，或者把权重解包成 FP16。我在社区论坛里找到维护者提供的 fork 分支，拉下来编译：
git clone https://github.com/example/bonsai-llama.cpp.git cd bonsai-llama.cpp git checkout support-pq2 cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release cmake --build build --config Release -j 16编译时注意两点。CUDA 编译器版本要和服务端驱动匹配，我一开始驱动 535 配 CUDA 12.4，编译过程报nvcc fatal，升级到 550 后通过。另外，显存不够大的机器别用-j 16，编译时把所有核心同时拉满可能吃 20GB 内存，16GB 内存的机器容易 OOM，改成-j 8更稳。编译完成后./build/bin/llama-cli --version能看到 commit 号，确认是带 ternary 支持的那个版本。这个分支也支持 PTQ1_0，所以我只编译一次，两个格式都能测。
3.3 PQ2_0 部署：先跑通原生特快专线
启动指令看起来跟普通 llama.cpp 很像，但参数选择要更小心。我最后稳定运行的是这一条：
./build/bin/llama-cli \ -m ./bonsai-27b/bonsai-2-27B.PQ2_0.gguf \ -ngl 99 \ -c 4096 \ --temp 0.6 \ --top-p 0.9 \ --repeat-penalty 1.05 \ -p "给我解释一下什么是三进制模型，并写一段部署心得"-ngl 99表示尽可能把层全部放到 GPU，对 16GB 显存且权重只有 7.9GB 的情况，放满是对的。但要注意，不是所有层都支持 GPU offload，日志里如果看到某个算子回到 CPU，不要慌，先检查是不是 fork 里自带的新内核没被触发。-c 4096我试过可以稳定跑到 8K，只是首次加载时 KV Cache 从 0.8GB 跳到 1.6GB，16GB 卡仍然有余量。加载完成后nvidia-smi看到的显存占用约 10.3GB，这比文件大小更能反映真实峰值。
生成速度方面，RTX 4080 上实测 22.4 tokens/s，比我预想的好。这不是普通 2bit 量化，而是原生三值矩阵乘，算子层面可以把很多浮点乘加变成查表和加法，省了不少带宽。实际使用中，这个速度写文案和翻译已经几乎感觉不到延迟了。
3.4 PTQ1_0 部署：用标准接口跑通一个"稳"字
PTQ1_0 的部署流程完全一样，只换文件名：
./build/bin/llama-cli \ -m ./bonsai-27b/bonsai-2-27B.PTQ1_0.gguf \ -ngl 99 \ -c 4096 \ --temp 0.6 \ --top-p 0.9 \ --repeat-penalty 1.05 \ -p "请给我写一段关于模型部署的注意事项"换成 PTQ1_0 后，加载日志里会出现更多 scale 相关的反量化信息，说明它走的是训练后量化兼容层，没有 PQ2_0 那么多专用查表 kernel。显存占用 11.5GB，速度 14.8 tokens/s。这个速度仍然比同级别 INT4 27B 在 16GB 卡上跑要舒服，因为 INT4 版本根本塞不满全部层到 GPU，会有不少层在 CPU 上龟速跑；而 PTQ1_0 好歹能把 99 层 GPU offload，只是算子效率低一点。
如果你想对外提供 API，就改用llama-server启动，监听0.0.0.0:8080，之后用 curl 发消息。实测两条路线都能用，但本地聊天和脚本调用用 CLI 就够了。这里多说一句：跑 PTQ1_0 时不要和 PyTorch 训练任务同时开，虽然显存只剩 11.5GB，但 PyTorch 的 CUDA context 一上来就会把剩下的 4GB 吃光，生成速度会雪崩到 3 tokens/s。
4. 实测数据与对比结论
4.1 测试方法：别被瞬间速度骗了
测双格式不能光看某一次输出。我用同一份 2000 字中文文档做 prefill，随后让模型生成 300 字点评，每个格式测三轮取中位数，同时记录三组数据：加载后空闲显存、prefill 期间峰值显存、稳态生成速度。为什么测三轮？因为第一次运行时 GPU 还没有算子预热，尤其是 PQ2_0 的查表 kernel，冷启动经常会慢 5% 左右，取第二次第三次的中位数才有代表性。
还要特别留意，--temp 0.6和--repeat-penalty 1.05必须固定，否则生成质量不一致，速度也会被采样路径差异带偏。有人只看首 token 很短就以为速度飞快，实际模型可能把大部分层放到了 CPU。这套测试里我会盯着nvidia-smi -l 1的实时占用，确认 GPU 没有偷懒，这比任何 benchmark 脚本都直观。
4.2 最终数据表和环境差异
下面是 4080 16GB + Ryzen 9 7950X + 64GB 内存环境下的中位数：
| 指标 | PQ2_0 | PTQ1_0 |
|---|---|---|
| 模型文件大小 | 7.9GB | 8.3GB |
| 加载后空闲显存 | 10.3GB | 11.5GB |
| 4K prefill 峰值显存 | 10.8GB | 12.1GB |
| prefill 速度 | 约 350 tok/s | 约 280 tok/s |
| 生成速度 | 22.4 tok/s | 14.8 tok/s |
| 通用生成质量（主观） | 逻辑连贯、偶尔缺字 | 更稳、但长文偶有重复 |
我又在 4060 Ti 16GB 上复测一轮，结论不变但数值大幅下降：PQ2_0 只有 12.6 tok/s，PTQ1_0 是 8.9 tok/s。这说明三值格式省下的是显存和带宽需求，不是算力魔法。如果你的显卡带宽吃亏，格式优势会被抵消。16GB 不是万能药，显卡算力等级是另一个变量。
4.3 质量与速度怎么平衡：我的选择公式
如果只让我推荐一个格式，我会按照用途来。日常写文案、总结网页、知识库问答，PQ2_0 的 22 tok/s 明显更舒服，人更有耐心用得久；接入脚本、做服务、需要反复调整推理参数，PTQ1_0 的兼容性更省心。
质量上两者大差不差，但有个规律我试了好几次：PTQ1_0 在指令遵循和结构生成上略好，PQ2_0 在自由文本生成上更鲜活。这可能是因为 PQ2_0 的原生三值训练保留了更多低秩表示，而 PTQ1_0 在后量化时把一些细节抹平了。如果你动手能力强，可以把两个模型都放在 SSD 上，按任务切换使用。反正文件加载只需要十几秒，比重新下载快得多，只是切换前一定要记得让旧进程退干净。
5. 踩坑实录与可用性建议
5.1 OOM 的三种情况和解法
我把 16GB 卡上的 OOM 见闻分成三类。第一种是模型文件搞混了，有人把原始 FP16 也放进目录，llama.cpp 的 mmap 会把内存文件映射出去，显存不够就报 CUDA out of memory。解法是把模型目录清理干净，只留 GGUF。第二种是上下文长度开过头，16GB 卡上跑 PTQ1_0 时把-c 8192直接拉满，KV Cache 峰值到 2.5GB 以上，再加上 CUDA context，就容易爆。解法是-c 4096起步，实在要 8K 就关掉同时运行的其他进程。
第三种是引擎不认格式，不支持的引擎会尝试把权重复原成 FP16，加载日志里出现大量 "dequantize to f16" 字样，紧接着显卡爆满。这种情况不是显存不够，而是引擎不支持。先换 fork，而不是一味调小上下文。
5.2 输出乱码和质量差：先查两处配置
三值模型的输出乱码大概率不是模型的锅，而是 tokenizer 不配套。我一开始只下载了 GGUF 文件，没放 tokenizer.json，跑起来生成的中文里夹杂�乱码，换了对应版本的 tokenizer 后立即恢复。下载时一定把仓库里的 tokenizer 相关文件一起拉下来，别偷懒。
另一个常见问题是生成内容"复读机"严重。三值模型的表达能力本身比高精度模型更依赖上下文，采样参数要温和一点。temp 0.7以上会明显看到句子碎掉，temp 0.6 + top_p 0.9 + repeat_penalty 1.05是我压测下来最稳的组合。如果还乱，就把--repeat-last-n从默认 64 调到 128，强制它不要再重复长串。这个组合在双格式上都适用，建议直接存成 alias。
5.3 显存占用比预期高：可能是内存映射和批处理大小
我遇到过加载完成后nvidia-smi显示 12.5GB，比预期多 2GB。排查后是两个原因：一是--mmap 1时文件本身映射到内存，llama.cpp 会额外保留一段 CPU 写缓冲；二是默认 batch size 512，在 prefill 阶段一次性处理太多 token，激活值峰值很高。
解法是加--batch-size 256，并在确定-ngl为 99 的情况下把--mmap 0关掉，速度没降多少，显存反而更可控。这里我想强调一点：三值模型不是完全不吃资源，它只是把过去卡住 16GB 显卡的那块最大石头挪开了，剩下的边边角角还是要自己调。
5.4 不想编译源码的可行捷径
如果你实在不想编译，两个路径可以降低门槛。一是直接用维护者提供的 release 包，前提是版本对得上，Windows 下也有 exe。二是把模型丢给标准 llama.cpp 的llama-quantize重新转换成普通 INT4 格式，但这样做等于丢掉三值原生优势，速度和质量都会回落，不太推荐。
我的实际经验是，编译一次 fork 大概花 15 分钟，之后一切都顺了，不要因为怕编译而选择残血路线。最后分享一个部署小技巧：双格式都保留，但切换前先nvidia-smi确认没有其他进程占用显存，再执行新的llama-cli，否则旧进程没退干净，新进程很容易在 16GB 卡上触发 OOM。这个坑我踩了两次，写出来给大家省点时间。
