1. 8GB 显卡跑 27B 模型，这事到底靠不靠谱
先把结论摆在前面：能跑，但跑完之后你大概率会和我一样，把它放进"技术验证成功、日常使用放弃"的文件夹里。Ternary Bonsai 2 27B 这个模型最近在圈子里讨论度不低，核心卖点就一个——三元量化，也就是权重被压到只有三种取值状态，配合 llama.cpp 的推理后端，理论上能把一个 270 亿参数级别的模型塞进 8GB 显存里跑起来。注意我说的是"塞进显存"，不是"流畅运行"，这两者之间的差距，就是这篇博文想聊清楚的东西。
我自己手上是一张 8GB 显存的卡，平时跑 7B、13B 的量化模型算是家常便饭，Q4_K_M 级别的 13B 大概占 7GB 出头，勉强能全量上卡。27B 这个体量，按常规 Q4 量化算，光权重就要 13GB 到 15GB，8GB 卡想都别想。三元量化的意义就在这儿：把每个权重从 16 位浮点压到接近 1.58 位的信息量，权重体积直接砍到原来的十分之一左右，27B 的模型文件能压到 7GB 上下，这才有了"8GB 显卡硬塞"的可能性。
但"能塞进去"和"能用"是两码事。这篇文章我会把整个折腾过程拆开讲：三元量化到底是什么原理、llama.cpp 怎么加载这种模型、8GB 卡上实际跑起来是什么体验、哪些参数决定了你能不能跑动、以及为什么我最后没把它当成日常主力。适合手里有中低端显卡、想搞清楚量化推理边界在哪的朋友，也适合单纯好奇"27B 塞 8GB"这个噱头背后有多少水分的人。看完你至少能判断：这事值不值得你花一个下午去折腾。
2. 三元量化到底是个什么东西
2.1 从 FP16 到三值：权重压缩的极限在哪
要理解 Ternary Bonsai 2 27B 为什么能塞进 8GB，得先搞清楚"三元"这个词的分量。常规模型权重是 FP16，每个参数占 2 字节；主流的 Q4 量化是 4 位，每个参数占 0.5 字节；而三元量化，每个权重只有三种可能取值——通常是 -1、0、+1，理论上每个参数只需要 log2(3) ≈ 1.58 位。这就是为什么它能把体积压到 Q4 的三分之一左右。
这里有个关键点很多人会误解：三元量化不是简单地把权重四舍五入到三个值就完事。如果直接粗暴地截断，模型精度会崩得一塌糊涂，输出全是胡言乱语。真正能用的三元模型，训练阶段就要做量化感知训练（QAT），让模型在训练时就知道自己最终会被压成三值，从而把关键信息"挤"到那三种状态里。Ternary Bonsai 2 27B 属于这类经过专门训练的三元模型，不是拿现成模型事后硬压的产物，这是它能保持基本可用性的前提。
那 1.58 位是怎么算出来的？信息论里，三种等概率状态的信息熵是 log2(3)，约等于 1.5849。但实际存储时不可能真的用 1.58 位去存，工程上通常用 2 位来存一个权重（浪费一点空间换实现简单），或者用更紧凑的打包方式把多个三值权重塞进一个字节。llama.cpp 对这类模型的支持，走的是专门的量化类型，加载时会做解包。所以你在文件系统里看到的模型大小，和理论上的 1.58 位会有出入，这是正常的。
2.2 为什么是 llama.cpp 而不是别的推理框架
热词里 llama.cpp 和 CUDA 同时出现，这不是巧合。目前对三元量化模型支持最成熟的推理后端就是 llama.cpp，原因有几个。第一，llama.cpp 的量化体系本来就是围绕"极致压缩 + CPU/GPU 混合推理"设计的，它支持从 Q2 到 Q8 一整条量化谱系，扩展到三元量化是顺理成章的事。第二，llama.cpp 的 GGUF 格式对自定义量化类型很友好，加一种新的 tensor 类型不需要动整个加载框架。第三，也是最实际的——它能在显存不够时自动把部分层卸载到内存，用 CPU 补算，这对 8GB 卡跑 27B 是刚需。
相比之下，主流的 PyTorch + transformers 路线对三元量化的支持要弱得多，你得自己写反量化 kernel，还得处理 CUDA 上的算子兼容问题。热词里那一堆"cuda安装""cuda版本""cuda toolkit"的搜索，其实反映了很多人在这个环节卡住——想用 GPU 加速，结果光环境配置就耗掉半天。llama.cpp 的好处是它把 CUDA 后端封装得相对干净，编译时开-DGGML_CUDA=ON就能用上显卡，不用你去手动装一堆 CUDA 组件。
提示：如果你只是想验证三元模型能不能跑，优先用 llama.cpp 的预编译版本或者官方 release，别一上来就自己编译 CUDA 后端。编译环节的坑足够单独写一篇文章。
2.3 三元模型的精度代价：省下来的空间从哪来
天下没有免费的午餐。三元量化把体积压到十分之一，代价必然是精度损失。这里要区分两个概念：困惑度（perplexity）上升和实际可用性下降。前者是客观指标，三元模型的困惑度通常比同规模的 Q4 模型高不少；后者是主观体验，表现为模型更容易跑偏、逻辑链条更短、复杂推理任务上翻车率更高。
我实测下来的感受是：三元 27B 在简单问答、文本改写、信息抽取这类任务上，表现大概相当于一个 Q4 量化的 7B 到 13B 模型；但一旦涉及多步推理、代码生成、长上下文理解，它的短板就暴露得很明显。换句话说，你付出了 27B 的推理成本（哪怕压缩后，计算量还是 27B 级别的），换来的效果可能还不如一个老老实实的 13B Q4。这就是我标题里说"大概率不会真用"的核心原因——性价比不划算。
3. 8GB 显卡上的实操：从环境到跑通
3.1 环境准备：CUDA 版本和 llama.cpp 编译
先说环境。我用的是一张 8GB 显存的卡，驱动版本比较新，CUDA 用的是 12.x 系列。这里有个经验：llama.cpp 对 CUDA 版本的要求没那么苛刻，只要你的驱动支持，编译时它能自己找到合适的 toolkit。热词里很多人搜"4060ti 支持的 cuda 版本""gtx1070 cuda 版本"，其实没必要死磕某个特定版本，装一个和驱动匹配的就行。
编译 llama.cpp 的 CUDA 后端，核心命令大概是这样：
git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDA=ON cmake --build build --config Release -j编译过程中最常见的坑是找不到 CUDA toolkit，报错类似Could NOT find CUDAToolkit。这时候检查两个东西：nvcc --version能不能正常输出，以及CUDA_HOME环境变量有没有指向正确的路径。如果用的是 Windows 上的 WSL2，还要确认 WSL 里的 CUDA 驱动是透传的，别在 WSL 里再装一遍显卡驱动，那样会冲突。
注意：编译时
-j后面的数字别开太大，CUDA 编译很吃内存，我 16GB 内存的机器开-j8直接 OOM 过。稳妥点用-j4。
3.2 模型下载与显存分配策略
模型文件从对应的发布渠道拿到 GGUF 格式后，第一件事是看文件大小。Ternary Bonsai 2 27B 的三元量化版本，文件大概在 7GB 上下。这个数字很关键，因为它决定了你的显存策略。
8GB 显存，系统和其他进程要占掉 1GB 左右，实际可用大概 7GB。模型文件 7GB，如果全部加载到显存，加上 KV cache 和计算中间变量，肯定爆。所以必须用部分卸载策略：把一部分层放在 GPU 上，剩下的放内存用 CPU 算。llama.cpp 里控制这个的参数是-ngl（number of GPU layers）。
我的做法是从小往大试。先-ngl 10，看显存占用和速度；然后逐步加到 20、30，直到显存快满为止。27B 模型通常有 40 到 60 层，8GB 卡上能卸载的层数大概在 20 到 30 层之间，具体取决于你的 KV cache 设置。下面是我实测的一组数据：
| GPU 层数 (-ngl) | 显存占用 | 生成速度 (tokens/s) | 体验 |
|---|---|---|---|
| 10 | 约 3.5GB | 2-3 | 慢，但稳定 |
| 20 | 约 5.5GB | 4-5 | 可接受 |
| 28 | 约 6.8GB | 6-7 | 接近上限 |
| 32 | 爆显存 | - | 失败 |
可以看到，即使把能卸载的层都放上去，速度也就 6-7 tokens/s。这个速度什么概念？你打一句话，等它一个字一个字往外蹦，读起来比它生成得还快。日常对话勉强能用，长文本生成就是折磨。
3.3 关键参数：KV cache 和上下文长度
除了-ngl，还有两个参数直接决定你能不能跑起来：上下文长度-c和 KV cache 的量化。上下文越长，KV cache 占的显存越多。默认的 FP16 KV cache 在长上下文下非常吃显存，8GB 卡上必须做量化。
llama.cpp 支持--cache-type-k和--cache-type-v参数，可以分别指定 K 和 V 的缓存类型。我一般设成q8_0或者q4_0。设成q4_0能省不少显存，但对输出质量有轻微影响。实测下来，q8_0是质量和显存的平衡点。
./build/bin/llama-cli \ -m ternary-bonsai-2-27b.gguf \ -ngl 28 \ -c 4096 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ -p "你的提示词"上下文我建议先设 4096，跑通了再往上加。设 8192 的话，KV cache 会多吃 1GB 多显存，很可能就把你从"能跑"推到"爆显存"。这里有个反直觉的点：上下文长度对显存的影响是非线性的，因为注意力机制的计算中间变量也随长度增长。所以别看着 4096 能跑就以为 8192 只是多一点点。
4. 实际体验：能跑，但为什么我不想用
4.1 速度与质量的真实权衡
跑通之后我做了几组对比测试，拿 Ternary Bonsai 2 27B 和一个常规的 13B Q4 模型比。任务包括：中文问答、英文摘要、简单代码补全、多轮对话。
结果是：在中文问答上，三元 27B 的回答更"啰嗦"，信息密度反而低，经常绕圈子；英文摘要任务上两者接近，但三元模型偶尔会漏掉关键信息；代码补全上三元模型明显吃力，生成的代码经常有语法错误或者逻辑不完整；多轮对话里，三元模型更容易"忘记"前面说过的话，上下文保持能力弱。
速度上，13B Q4 在 8GB 卡上能全量卸载，跑到 20+ tokens/s，体验流畅。三元 27B 只有 6-7 tokens/s，还得忍受部分层在 CPU 上算带来的延迟波动。这个差距在日常使用中是压倒性的——你不会愿意为了一个效果更差的模型，去忍受三倍以上的等待时间。
4.2 那些让人抓狂的细节问题
除了速度和质量，还有几个细节让我最终放弃把它当主力。第一是首 token 延迟，因为部分层在 CPU 上，第一次生成前的等待特别长，有时候要等五六秒才开始出字。第二是显存波动，跑一段时间后显存占用会慢慢爬升，可能是内存碎片或者缓存没释放干净，跑久了偶尔会 OOM。第三是温度参数敏感，三元模型对 temperature 和 top_p 的变化比常规模型敏感得多，调不好就容易输出重复内容或者直接崩坏。
实操心得：如果你非要试三元模型，把 temperature 设在 0.6 到 0.8 之间，top_p 设 0.9，repeat_penalty 稍微调高到 1.1。这套参数是我试了十几组之后相对稳定的组合，但依然不能保证每次都正常。
4.3 什么场景下它还有点用
说了这么多缺点，也得客观讲它有用的地方。三元模型最大的价值在于极端资源受限下的可行性验证。比如你只有 8GB 显存，又想跑一个参数量看起来很大的模型来做实验、写论文、做 demo，三元量化给了你一个"能跑起来"的选项。另外，在离线环境、边缘设备上，三元模型的体积优势是实打实的，7GB 的文件比 15GB 的 Q4 好传输、好部署。
但如果你只是想要一个日常能用的本地模型，我的建议很直接：8GB 卡老老实实跑 7B 或 13B 的 Q4/Q5 量化，速度和质量都比硬塞 27B 三元模型强。省下来的折腾时间，够你多跑几百条推理了。
5. 踩过的坑和排查清单
5.1 编译与加载阶段的常见报错
折腾过程中我遇到不少报错，整理成表格方便对照排查：
| 报错信息 | 原因 | 解决方法 |
|---|---|---|
CUDA error: out of memory | 显存不够，层数设太多 | 降低-ngl，或减小-c |
unknown model architecture | llama.cpp 版本太旧 | 更新到最新版重新编译 |
failed to load model | 模型文件损坏或格式不对 | 校验文件哈希，确认是 GGUF |
CUDA driver version is insufficient | 驱动太旧 | 更新显卡驱动 |
| 生成速度极慢（<1 tokens/s） | 层几乎全在 CPU | 增大-ngl，检查 CUDA 是否启用 |
其中unknown model architecture这个坑我踩得最冤。三元模型用的量化类型比较新，老版本的 llama.cpp 不认识，加载直接报错。解决办法就是拉最新代码重新编译，别用半年前的 release。
5.2 显存优化的几个野路子
除了常规参数，还有几个偏方可以榨出一点显存。第一，关掉桌面环境或者减少后台程序，尤其是浏览器，Chrome 开几个标签就能吃掉 1GB 显存。第二，用--no-mmap有时候反而能减少内存碎片，但会增加加载时间，看情况取舍。第三，把--cache-type-v设成q4_0而 K 保持q8_0，V 缓存对精度的影响比 K 小，这样能再省几百 MB。
还有一个容易被忽略的点：batch size。llama.cpp 的-b参数控制批处理大小，默认值在显存紧张时可能偏大。设成 128 或 256 能降低峰值显存，代价是吞吐量下降。在 8GB 卡上，我一般设-b 256。
5.3 三元模型值不值得折腾：我的判断标准
最后说说我的判断逻辑。判断一个模型值不值得用，我会看三个指标：速度是否超过阅读速度（大概 10 tokens/s 是底线）、质量是否达到任务要求、资源占用是否可持续。Ternary Bonsai 2 27B 在这三项上，第一项不达标（6-7 tokens/s），第二项勉强（简单任务可以，复杂任务不行），第三项勉强（显存吃紧，跑久了会 OOM）。
三项里两项勉强一项不达标，结论就很清楚了。它适合的是"我就是要验证这个技术路线"的场景，而不是"我需要一个能干活的模型"的场景。这两者的区别，决定了你会不会在跑通之后，像我一样把它归档，然后继续用回那个老老实实的 13B Q4。
如果你手里是 12GB 或 16GB 的卡，情况会好很多，三元 27B 可能能全量卸载，速度上到 15 tokens/s 以上，那时候它的性价比就值得重新评估了。但 8GB 这个档位，我的经验是：别跟硬件较劲，选对模型规模比硬塞大模型重要得多。
