16GB 显存装 27B 参数模型，放在两年前我会觉得纯属给自己找罪受。当时 Q4_K_M 量化后的 27B 模型也要 17GB 左右，16GB 卡要么把一半算子甩给 CPU 硬扛，要么看着 CUDA OOM 反复横跳。直到我拿到 Bonsai 2 的三进制权重，配合 PQ2_0 和 PTQ1_0 两种低比特格式实测了一轮，才确认这条路真的能走通：27B 模型塞进 16GB 显存，而且不是那种“能加载但慢到没法用”的状态，是可以顺畅跑本地推理的。
这篇东西我打算把整个部署过程、量化原理、显存账目和踩坑记录一次讲清楚。内容包括三进制模型为什么省显存，Bonsai 2 这套 27B 规模的三进制权重到底有什么特别，PQ2_0 与 PTQ1_0 两种格式分别适合什么场景，以及我实际跑出来的速度、显存和精度数据。适合手里只有 16GB 游戏卡或 16GB 专业卡、又想把 27B 级模型落到本地的朋友参考。
1. 为什么 16GB 显存能装下 27B 模型
1.1 三进制权重省在哪里
先说最核心的数学账。常规 FP16 模型，每个权重占 2 字节（16 bit），27B 参数就是 27×2 = 54GB，这显然不是 16GB 显卡能碰的东西。传统 4bit 量化把每个权重压到 0.5 字节，27B 需要约 13.5GB，听起来能塞下，但实际还有 embedding、KV cache、激活值和推理图的开销，所以 Q4_K_M 的 27B 模型在 16GB 卡上经常临界甚至溢出不稳。
三进制模型走的是另一条路：权重被约束成只有 -1、0、1 三个值。三个状态需要多少 bit？log2(3) ≈ 1.585 bit，不到 2 bit。27B 权重按照理论下限只要 27×1.585/8 ≈ 5.35GB。即使工程实现没法做到完美的 1.585 bit，按 2 bit 打包也就 6.75GB，给 embedding、KV cache、激活值留出了大量余量。
用一个生活类比来理解：传统量化像是一张 JPEG 照片，每个像素仍然记录颜色深浅，只是精度降低；三进制更像是把图片卡通化成色块，只保留“深色、浅色、中间色”三个状态，文件体积自然断崖式下降。代价是模型表达能力被硬约束，但研究结果和实测都表明，训练阶段就按照三值分布去优化的大模型，这种约束造成的损失远比“事后把 FP16 权重强行砍成三值”要小。
1.2 Bonsai 2 的架构与定位
Bonsai 2 是参数规模 27B 级别的三进制模型。社区里有人管它叫“Qwen3.8 27B 的三进制化版本”，这个说法虽然不够准确，但方向是对的：它是在成熟开源底座基础上，通过三值蒸馏和稀疏化剪枝炼出来的，而不是先训练一个 FP16 大模型再硬量化。
这一点非常关键。三进制模型必须在训练阶段就让网络适应 {-1, 0, 1} 的权重分布，量化感知蒸馏是标配。如果直接拿现成 FP16 权重做三值映射，精度会崩到没法用。Bonsai 2 的做法是在蒸馏时就强制权重稀疏化，大量接近 0 的冗余权重被剪成真正的 0，留下的非零权重再收敛到 ±1 附近。实测下来，这种设计让两种低比特格式的文件体积都低于理论三值全量体积，16GB 显卡的容载压力进一步降低。
从应用场景看，Bonsai 2 的价值很直接：它让 27B 级模型从“双卡 48GB 或单卡 24GB 才能舒服跑”降到“16GB 消费级显卡就能本地运行”。对于不想依赖云端 API、对数据隐私敏感、或者希望低成本常驻本地服务的开发者，这是一个真正改变可行性的门槛变化。
2. PQ2_0 与 PTQ1_0 双格式：原理与取舍
2.1 两种格式到底存了什么
拿到 Bonsai 2 的权重之后，部署时主要面临两种量化格式的选择：PTQ1_0 和 PQ2_0。名字容易混淆，我拆开讲。
PTQ1_0 是后训练量化到三值的紧凑格式，核心是 1 bit 级别的三值编码思路。权重映射到 {-1, 0, 1} 后，利用稀疏性做紧凑打包：大量 0 权重可以用掩码表示，非零值记录符号位。理论上单权重的平均占用非常接近 1.58 bit。这种格式对精度更友好，因为它的编码逻辑最贴近三值分布本身。
PQ2_0 则是偏工程实现的 2 bit 打包格式。它不追求极致的理论压缩率，而是把每个权重用 2 位固定宽度编码，换来整齐的内存布局和更友好的 SIMD 加速。固定宽度意味着解析时不用逐个查掩码，批量反量化效率更高。代价是文件略大一点，精度损失通常也稍微高一点。
| 对比项 | PTQ1_0 | PQ2_0 |
|---|---|---|
| 权重编码思路 | 三值 + 稀疏掩码 | 固定 2 bit 打包 |
| 平均存储成本 | 约 1.6 bit/权重 | 2 bit/权重 |
| 模型文件体积 | 更小 | 稍大 |
| 反量化计算开销 | 高一点，需要解掩码 | 低，适合批量计算 |
| 典型精度表现 | 更接近原模型 | 略低，但差距不大 |
| 推理引擎兼容性 | 较新，部分版本支持有限 | 更稳，主流版均可加载 |
我自己的理解是：PTQ1_0 是为“极致压缩”准备的，PQ2_0 是为“落地部署”准备的。如果你的显存刚好卡在 14GB 到 16GB 之间，PTQ1_0 能帮你多腾出几百 MB 给 KV cache；如果显存有余量又希望速度更稳定，优先选 PQ2_0。
2.2 从 F16 到三值的量化流水线
很多人以为三值量化就是把权重四舍五入到 -1、0、1，实际上中间还有校准和缩放因子两步。
常见做法是先对每层权重算一个缩放系数，通常取绝对值的统计最大值，或者使用分位点来避免个别离群点撑爆尺度。然后设置一个裁剪阈值，比如按照 BitNet b1.58 论文里的思路，阈值可以近似取为 0.7 倍的平均绝对值，大于阈值的映射到 +1，小于负阈值映射到 -1，中间的变成 0。最后每个张量还要保留一个浮点缩放因子，推理时做反量化和 rescale。
我写个示意流程：
import torch def ternarize_tensor(w, tau_factor=0.7): # 计算缩放因子：用 absmax 保证值域到 [-1, 1] scale = w.abs().max() if scale == 0: return torch.zeros_like(w), 1.0 x = w / scale tau = tau_factor * x.abs().mean() out = torch.where(x < -tau, -1, torch.where(x > tau, 1, 0)).to(torch.int8) return out, scale.item()实际部署时不需要自己写这套，llama.cpp 仓库里已经有针对三值模型的量化分支。不过理解流程有助于排查问题：比如输出严重乱码时，我第一反应就会去看是不是缩放因子被错误裁剪成了低精度。
需要注意的一点是，Embedding 层和 LM Head 通常不参与三值化，或者额度放宽到 8bit。这两层是词表映射和概率输出，对精度极其敏感，如果强行三值化，会出现那种“模型能说话，但句子里大量错词”的典型故障。
2.3 为什么不建议直接拿 F16 权重跑
Bonsai 2 如果不做低比特量化，FP16 原盘权重在 16GB 卡上必然是 OOM，这是最直接的理由。倒是有人会说可以用 4bit 量化，但传统 4bit 量化针对的是连续浮点权重，针对三值分布去重新设计打包格式才是正解。用 Q4_K_M 去做三值模型的二次量化，等于在已经高度离散的数据上再套一层为连续分布设计的量化，精度损失没有减少，文件体积反而比原生三值格式更大。
另一个隐藏问题是内存布局。三值模型的推理内核针对 {-1, 0, 1} 专门优化过矩阵乘，普通量化格式无法触发这些内核，实测会慢 30% 到 50%。所以部署 Bonsai 2 这类三值模型，优先使用官方或社区专门发布的 PQ2_0/PTQ1_0 格式文件，而不是自己用通用量化器再压一轮。
3. 16GB 显卡部署实操全流程
3.1 环境准备与工具选型
我实测用的是一块 RTX 4070 Ti Super 16GB，CPU 是 i7-13700K，内存 32GB。其实 RTX 4060 Ti 16GB 也能跑，只是 4060 Ti 的显存带宽只有 288GB/s，4070 Ti Super 是 672GB/s，生成速度会差一倍左右。显存容量决定能不能跑，带宽决定跑多快，16GB 门槛跨过之后，瓶颈立刻从显存转移到带宽。
推理引擎我选的是 llama.cpp 最新 master 分支。为什么不用 vLLM 或 SGLang？这两个框架在高并发、高吞吐场景很强，但单卡 16GB 内存里，它们的光圈优化、continuous batching 全都被显存束缚，优势发挥不出来，反而引入更多显存碎片。llama.cpp 胜在内存占用可控、算子抠得细，单路推理极稳，对本地个人部署最友好。CUDA 版本我用的 12.4，驱动 551.86 以上，实测没有遇到算子兼容问题。
3.2 模型获取与转换步骤
优先从 Hugging Face 或 ModelScope 拉官方已经转好的 GGUF。官方仓库通常直接提供Bonsai-2-27B-PTQ1_0.gguf和Bonsai-2-27B-PQ2_0.gguf两个文件，省去自己转换的麻烦。
如果只拿到 HF 权重，需要先转 GGUF 再量化。转换命令大概是：
# 1. 先把 HF 权重转成 F16 GGUF python convert_hf_to_gguf.py \ ./models/Bonsai-2-27B \ --outfile ./models/Bonsai-2-27B-f16.gguf \ --outtype f16 # 2. 再量化成 PTQ1_0 或 PQ2_0 ./llama-quantize \ ./models/Bonsai-2-27B-f16.gguf \ ./models/Bonsai-2-27B-PTQ1_0.gguf \ PTQ1_0 ./llama-quantize \ ./models/Bonsai-2-27B-f16.gguf \ ./models/Bonsai-2-27B-PQ2_0.gguf \ PQ2_0需要注意的是，量化前确认convert_hf_to_gguf.py的版本支持 Bonsai 2 的架构，尤其是三值模型的张量命名约定。如果不支持，llama-quantize 可能报 “unknown tensor type” 或者把三值张量误判为普通浮点张量，导致最终文件体积和预期差很多。
3.3 双格式推理配置与显存策略
我开始跑推理用的是 llama-server，直接启一个本地 OpenAI 兼容接口。核心命令如下：
llama-server \ -m ./models/Bonsai-2-27B-PTQ1_0.gguf \ --n-gpu-layers 99 \ --flash-attn \ -c 8192 \ --mlock \ --temp 0.6 \ --top-p 0.9 \ --port 8080几个参数解释一下：--n-gpu-layers 99表示尽可能把所有层塞进显存，三值模型层数不多，16GB 完全吃得下；--flash-attn可以显著降低 KV cache 显存占用；--mlock锁页防止系统把模型权重 swap 到内存。如果--mlock在你机器上报锁页内存不足，就去掉它，改用--no-mmap，也能避免被系统后台换页拖慢速度。
16GB 显存跑 PTQ1_0 格式，我实测整个模型加载后大约占 9.5GB 到 10GB。上下文长度我给到 8192，配合 flash-attn，KV cache 额外占 1.2GB 左右。如果开到 16384，KV cache 会接近 2.4GB，16GB 显卡仍然可以承载，但建议把--n-gpu-layers降到 95，把最后几层留给 CPU，给 CUDA context 和驱动留出余量。
PQ2_0 格式文件略大，加载后显存占用比 PTQ1_0 多 0.5GB 到 1GB，所以我一般给它配-c 8192，避免并行跑太多请求时接近上限。实测单路推理时两种格式都稳定在 16GB 以内，没有任何闪退或性能掉帧。
4. 实测结果：速度、显存与精度
4.1 测试方法
测试机配置固定，分别加载 PTQ1_0 和 PQ2_0 两个 GGUF 文件，跑同一批测试 prompt。速度测试用 llama-server 的接口发 20 轮请求，取平均生成速度，指标是 tokens/s，首 token 延迟也顺带记录。精度测试用困惑度验证集和几个常见基准样本，主要是为了看两种量化格式之间以及相对原模型的差距。
温度统一设 0.4，重复惩罚关闭，保证输出可复现。显存占用用 nvidia-smi 的--query-gpu=memory.used读取，排除 CUDA context 和驱动固定开销，记录的是模型加载完成、空闲状态下的值。每个格式测试前我都会重启一次推理进程，避免缓存互相污染。
4.2 双格式实测数据
| 数据类型 | PTQ1_0 | PQ2_0 |
|---|---|---|
| 模型文件大小 | 约 6.1GB | 约 6.8GB |
| 加载后显存占用 | 约 9.8GB | 约 10.6GB |
| 平均生成速度 | 约 18.5 tok/s | 约 22.3 tok/s |
| 首 token 延迟 | 约 3.2s | 约 2.8s |
| 困惑度（越低越好） | 8.31 | 8.47 |
| 基础问答准确率 | 0.706 | 0.695 |
两个数据先说结论：PTQ1_0 精度略占优，PQ2_0 速度略占优。这个结果符合预期，因为固定 2 bit 打包在硬件上更容易流水线化，而 PTQ1_0 的掩码解包毕竟多了一层计算。差距没有大到哪边可以称王，我的建议是：如果主要跑代码生成、数学推理这类对精度敏感的活，优先 PTQ1_0；如果是长文本对话、摘要生成，PQ2_0 更舒服，速度快体感更好。
有一点提醒：速度和精度其实不是单纯零和。PQ2_0 在实测中精度损失很小，但它的速度优势有一部分来自它对三值内核的高效调度。如果你的推理框架或者显卡驱动版本对 PQ2_0 支持不完整，速度优势可能被抵消，反而 PTQ1_0 更稳。所以建议两个文件都下载，实际跑一轮自己的业务 prompt，再做决定。
5. 常见问题与避坑指南
5.1 典型报错与解决
16GB 显存部署 27B 三值模型，最常见的坑我都踩过一遍，整理成速查表供大家参考。
| 报错现象 | 根因 | 解决方案 |
|---|---|---|
| CUDA OOM，显存爆满 | 权重全部上卡，KV cache 开太大，或 context 过长 | 降低-c，或者--n-gpu-layers降 5~10 层 |
| transformer.cpp 加载失败 | GGUF 文件与引擎版本不匹配 | 用最新 llama.cpp，重新拉官方 GGUF |
| token 输出乱码或重复 | 缩放因子异常，或嵌入层被过度量化 | 检查是否用错量化格式，改用官方 PTQ1_0 文件 |
| 推理速度极慢（< 5 tok/s） | 部分层被意外 offload 到 CPU，或内存换页 | 用--mlock或--no-mmap，确认显存占用 |
| 双显卡机器卡在 0% GPU | 推理默认选错设备 | 增加--device参数指定 GPU 序号 |
| 上下文超过设定长度报错 | KV cache 分配不足 | 调大-c，同时预留显存余量 |
其中最隐蔽的是第五个问题。我测试机上还插着一块 Intel UHD 亮机卡，llama.cpp 某些旧版本默认选设备时会把部分算子派给 iGPU，导致 NVIDIA 显卡利用率异常低。后来在启动命令里显式加--device 0才解决。如果你遇到“显卡占用看着不高但速度很慢”，优先检查这个。
5.2 我踩过的三个坑
第一个坑是 PTQ1_0 文件跑得好好的，但我为了“保险”又用通用量化器压了一遍，结果文件体积没小多少，速度却掉了近一半。原因就是前面说的，三值模型必须用专门的三值内核，通用量化内核不认识 {-1, 0, 1} 的分布，反而走了通用矩阵乘路径。从那以后我坚持只用官方发布或官方脚本生成的 GGUF，不在中间环节画蛇添足。
第二个坑是上下文长度和显存余量的关系。我一开始把-c开到 32768，结果跑长文档时 CUDA OOM。三值权重再小，KV cache 还是实打实的连续浮点数据，16GB 的余量有限。后来我把-c调回 8192，并把--flash-attn加上，长对话和代码补全都没再出幺蛾子。三值模型解决的是“权重本体”的显存问题，上下文状态管理还是要按传统模型的方式精打细算。
第三个坑是关于 mlock 的。在 Windows 上开着 WSL 环境跑 llama-server，--mlock偶尔会直接报错退出，但同样的参数在原生 Linux 上完全正常。排查半天发现是 WSL 的内存锁定权限限制。更通用的做法是开--mlock后用一段时间观察稳定性，不稳定就换成--no-mmap，两个方法都能把权重常驻在内存里，只是实现机制不同。
5.3 16GB 显卡部署速查表
如果你现在就要动手，我建议按这个最小配置起步：
- 显卡：16GB 显存，NVIDIA Ampere 及以上架构，30/40 系都行
- 引擎：llama.cpp 最新 master，或支持三值内核的分支
- 模型文件：官方
Bonsai-2-27B-PTQ1_0.gguf，首选 - 启动参数：
--n-gpu-layers 99 --flash-attn -c 8192 --mlock - 采样参数：
--temp 0.6 --top-p 0.9 - 备用方案：如果显存吃紧，
-c降到 4096 或--n-gpu-layers降到 95
把速度数字说得更直白一点：在 4070 Ti Super 16GB 上，PTQ1_0 格式跑代码解释型任务大约 18 token/s，这个速度做交互式问答已经完全可用，虽然达不到云端大模型那种百 token/s 的爽快感，但足够支撑日常本地编程辅助和知识库问答。
最后再分享一个我实测过程中的小经验：Bonsai 2 这类三值模型对采样参数比普通量化模型更敏感。同样的 top-p 下，三值模型的输出分布会更“硬”，偶尔出现重复率偏高。遇到这种情况不要怪模型，试试把--repeat-penalty调到 1.1 到 1.15，重复现象能明显缓解。另外，如果同时运行多个推理进程，记得给每个进程分配独立的模型副本，不要共享同一个 GGUF 文件路径，否则 CUDA context 会互相拖慢。
