接手这台 RTX 4090 时，我本来只想老老实实跑个 13B 量化模型交差。结果同事甩过来一个 Ternary-Bonsai-2-27B，还说权重是 PTQ1_0 版本的，让我在这张 24GB 显存的卡上完成部署与调优。第一反应是"疯了吧"——27B 模型 FP16 满精度光权重就要 54GB，24GB 的 4090 怎么塞？但翻完模型仓库的技术说明之后，我发现这事还真有得聊。三值化（Ternary）把每个权重压到只需要三种取值 {-1, 0, 1}，配合 PTQ 训练后量化方案，模型本体的存储直接从几十 GB 掉到个位数。这篇实录就是我在这张卡上从加载到调优的完整过程，包括环境怎么配、算子怎么选、采样参数怎么调，以及几个网上搜不太到的坑。
1. 为什么 27B 模型能塞进 24GB 显存：PTQ1_0 拆解
先解决那个最反直觉的问题：27B 参数到底是怎么塞进 24GB 显存的？答案全在"PTQ1_0"这套量化方案里。
1.1 三值化的本质：{-1, 0, 1} 与 1.58 比特
传统量化里，我们最常接触的 4bit（GPTQ、AWQ）是把一个 FP16 权重映射到 16 个离散档位。三值化更狠：直接要求每个权重只属于 {-1, 0, 1} 三个值。为什么是三值而不是二值？因为如果只用 {-1, 1}，模型中间大量接近 0 的冗余权重被强行拉到 ±1，信息损失不可控。引入 0 之后，等于给权重加了一个"剪刀层"，让真正不重要的连接直接归零。
从信息量看，三个取值理论上只需要 log2(3) ≈ 1.58 bit 来表达。但实际做存储时，你要么用 2bit 编码三个状态（01、10、11，外加一个 00 表示 0），要么直接用一个 int8 数组存放被量化后的索引值。PTQ1_0 这个版本我看了下仓库设计，走的是 2bit 紧凑存储路线，只是因为对齐和算子效率，最终 safetensors 文件里看到的大小往往是"27B × 2bit ÷ 8 ≈ 6.75GB"，外加每层一个 FP16 的 scale 参数，上下浮动一点。
所以，27B 模型的三值化权重，在显存里只占 7GB 左右。RTX 4090 的 24GB 减去这 7GB，剩下 17GB 给激活值、KV Cache 和推理框架开销，这就完全可行了。
1.2 PTQ1_0 和 GPTQ / AWQ 到底差在哪
先说结论：PTQ1_0 不追求"接近原模型"，它追求的是"可用的极端压缩"。GPTQ 和 AWQ 是 4bit 量化的代表，它们保留的精度远高于三值化，但压缩率摆在那。27B 的 4bit 版本大约 14GB 权重，放进 4090 也不是不行，可一旦开启长上下文，KV Cache 一涨就很容易撞显存上限。
PTQ1_0 的"1_0"我特意确认过，是量化 schema 的版本号，不是"1.0 bit"的意思。整个流程属于 Post-Training Quantization：不需要重新训练模型，只需要一小批校准数据，统计各层激活分布，然后拿一个 scale scaler 把所有权重映射到 {-1, 0, 1}。这比 QAT（量化感知训练）省事太多，但代价是精度损失更明显，后面我会专门讲效果差异。
1.3 显存账本：一张 4090 怎么分钱
按照我的实际部署惯例，推理时的显存占用主要来自四块：
- 模型权重：约 6.8~7.2GB，PTQ1_0 紧凑格式。
- 激活值：单条短序列（512 tokens）通常不到 1GB。
- KV Cache：取决于总序列长度，7B 模型下每 1K token 大约几十到一百多 MB，27B 三值模型层数多，这个数字会偏高一些，我实测在 100~150MB / 1K token 级别。
- CUDA context 和框架缓冲：1~2GB 固定开销。
大头其实是权重和固定开销。只要不贪心把 max sequence length 拉满，解码阶段 24GB 完全够用。这也是我这次敢直接上 4090 的底气所在。
2. 部署前的环境准备与依赖选型
部署任何带自定义量化格式的模型，环境版本搭配都值得单独拿出来说。三值模型不是 PyTorch 原生的量化格式，依赖社区自定义算子，所以版本组合很容易栽跟头。
2.1 我最终锁定的版本组合
这次我踩了几次坑之后固定下来的环境是：
- Python 3.10
- CUDA 12.1（驱动版本 535+）
- PyTorch 2.1.2，torchvision 不装
- transformers 4.37.2
- triton 2.2.0
- safetensors 0.4.3
- 可选：flash-attn 2.5.8（但只对长序列有效果，短句子没那么明显）
为什么要卡 transformers 4.37.2？因为模型仓库的modeling_bonsai.py是照着这一代 API 写的，cache_position、attention_mask的处理方式在 4.38 之后有小改动。如果你直接用 4.40，轻则 warning 刷屏，重则因为padding_side推断逻辑变化导致生成结果异常。如果你已经装了新版也不用卸载，我建议用虚拟环境单独隔离，别污染日常工作环境。
2.2 加载路径：如何让 PyTorch 认下三值权重
模型仓库里通常是一大堆model-00001-of-0000N.safetensors，但你绝对不能直接当成 FP16 模型加载。PTQ1_0 的权重大概率被保存为量化前的 FP16 外观，实际上值域已经全部落在三个离散档位上；或者干脆是自定义二进制格式，需要仓库自带的quantize_utils.py做解码。
我用的加载方式是加trust_remote_code=True，让模型代码里的from_pretrained逻辑自己解析：
from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name = "your-local-path/Ternary-Bonsai-2-27B-PTQ1_0" model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype=torch.float16, trust_remote_code=True, device_map="cuda:0" ) tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True) model.eval()注意torch_dtype不要因为模型是三值就想着用torch.int8。自定义 forward 里一般会先把三值索引映射成 FP16 的 -1.0 / 0.0 / 1.0，再乘上 layer-wise 的 scale。你外层指定 int8，反而会让数值比较逻辑出问题。
2.3 首次加载的典型报错排查
加载阶段最容易遇到三个报错，我都遇到过，直接把排查链路写出来：
第一类：KeyError: '...layers.0.attention.qkv.qweight'之类。这通常是模型的 shard 格式和代码里预期的权重名对不上。优先检查你是否把两个文件夹混在一起，或者仓库的 revision 分支不对。我当时的解决方法很笨但也最有效：下载前先git lfs pull完整仓库，不要去网盘找"精简版"。
第二类：ValueError: Cannot load weight with attention mask ...。来自于 transformers 版本不一致。建议直接创建 conda 环境，按上面版本装一遍，比在旧环境里"凑合升级"省一小时。
第三类：加载成功但显存瞬间吃满 24GB，然后 OOM。这个大概率是你没指定device_map="cuda:0"，导致权重先加载到 CPU，forward 时 CPU 侧某个地方把它转成了 FP32 再搬运到 GPU。三值模型自定义代码里往往有一个.half()之后才进算子的路径，你如果不显式给torch_dtype=torch.float16，可能会被默认的 FP32 吃掉两倍显存。
3. 推理速度调优：从"能跑"到"跑得动"
能加载只是第一步。真正上生产或者说做实验，还得让人等得起。三值模型最大的优势在于，理论计算强度比 FP16 小得多——乘法可以拆成加法/减法，和 0 相乘更是可以直接跳过。但这块理论收益能否兑现，完全取决于算子选型。
3.1 三值 GEMM 算子选择
三值矩阵乘法的本质是：输入激活 x 是 FP16，权重 W 是离散三值。那么x @ W可以拆成(x[:, p] @ W_p) - (x[:, n] @ W_n)，其中 p/n 分别是权重为 +1 和 -1 的列索引。这样乘 0 的部分就不需要参与 FP16 的乘法累加，内存带宽和计算量都能省一大截。
模型仓库如果带 kernel，一般有三种实现路径：
- 纯 PyTorch 实现（用
masked_select或者gather）：正确但慢，只适合验证逻辑。 - CUDA kernel / Triton 实现：推荐。我用的 Triton 版本，核心逻辑是把三值权重预切成
positive_idx和negative_idx两个索引表，forward 时直接对激活做 index_select 再做减法聚合。 - 混合精度路径：部分层保留 FP16，部分层三值化。PTQ1_0 如果带"敏感层保护"，那算子要兼容两种格式。
如果你跟我一样用 Triton kernel，注意num_warps和block_M / block_N这两个参数。我实测在 4090 上block_M=128, block_N=128, num_warps=4比默认配置快了约 15%。分辨率再往上调反而变慢，因为 L2 缓存命中率下降，看起来像是在做无用功。
3.2 批大小与 KV Cache 的显存博弈
因为 4090 只有 24GB，我不建议把 batch size 拉高。解码阶段batch_size=1通常能保证稳定；如果硬上 4，KV Cache 和激活值会跟权重抢显存，长序列下确实会发生莫名其妙的 OOM。
更实际的做法是控制总序列长度。PTQ1_0 模型自身支持最多 32K 上下文，但 4090 上你未必真的喂得下去。我自己试过，输入 2K prompt、单轮生成 2K，KV Cache 大概占 2.5GB 左右；升到 8K 就逼近 8GB。所以如果业务上不需要超长文档分析，建议在推理服务里把max_seq_len限制在 4096 到 8192 之间，别被"支持 32K"的宣传冲昏头。
3.3 生成参数对速度的影响
很多人忽略这一点：采样参数也会影响吞吐。比如temperature调低、top_p收紧后，解码时虽然 token 数量不变，但如果你开了repetition_penalty，会在每一步对候选词的 logits 做修正，这一步对三值模型的自定义 kernel 来说可能触发额外的 CPU-GPU 同步。
我的建议是：快速验证阶段用do_sample=False（greedy），等确认效果 OK 了再开采样。实测 greedy 模式比do_sample=True, top_p=0.9快 8% 左右。另外，max_new_tokens不要设置成"无限"，因为这会影响 PyTorch 的图分配策略，流式生成时如果没有提前预留 buffer，会频繁触发缓存重分配，体感就是一顿一顿的。
4. 效果与稳定性：三值模型的压缩代价
把 27B 压到 2bit 不是没有代价的。这部分我用同一台 4090、同一个测试集，对比了 PTQ1_0 版本和同一模型族某个 FP16 参考版本的效果差异。
4.1 与 FP16 参考版的效果对比
我用了三组 prompt 做定性比较：中文常识问答、代码生成、长文本摘要。结论比较明显：
- 常识问答：三值版能给出正确框架，但措辞更像"初稿"，偶尔丢掉一个限定条件。比如问"为什么天空是蓝色的"，它能说出瑞利散射，但"波长越短散射越强"这个细节经常被压缩成"蓝光散射最强"。
- 代码生成：函数签名和主流程靠谱，边界条件处理容易敷衍。让它写一个二分查找，主循环没问题，但
lo <= hi这种边界判断偶尔会写成lo < hi，导致死循环。 - 长文本摘要：框架保留得不错，但细节数字容易失真。有一篇包含"30%提升"的新闻，它摘成"显著提升"。
这份结果其实符合我对三值量化的预期：模型保留了常识和结构能力，牺牲的是精确性和细腻度。用行话说，这属于"高熵知识保留得较好，低熵细节容易糊掉"。
4.2 采样参数怎么调才能救回一点质量
如果你一定要用这个模型做内容生成，采样参数别照搬 7B/13B 模型的常用配置。我自己跑出来的经验是：
temperature = 0.8~0.9：太低会退化到反复说同一句，太高会让本就不稳定的概率分布更散。top_p = 0.9，不要更小。PTQ1_0 的 logits 分布尾部比 FP16 模型更厚，强行 top_p=0.8 会让输出突然"断片"。repetition_penalty = 1.05~1.10：三值模型在长上下文里更容易陷入重复循环，这个惩罚值要调得比普通模型激进一点。- 随机种子影响很大。同一个 prompt 换 seed，输出差异能比 FP16 模型大不少。这是因为量化后的 logits 锐度不够，采样时更容易在几个候选词之间横跳。如果你需要稳定的演示效果，固定 seed 是合理选择。
4.3 长上下文下的稳定性问题
三值模型的长依赖能力是明显短板。当输入超过 2K token 时，注意力分布容易"漂移"，后面的生成会逐渐忽略前面出现过的关键信息。我的实测是：输入 4K token 的合同，让它回答"第二页第七条如何约定违约金"，它经常只引用最后一段的信息。
这个问题的根源不完全在于量化，也与模型本身的训练数据长度有关，但 PTQ 三值化会放大长尾注意力权重的失真。如果业务里确实需要长上下文，我建议配合 RAG 使用：把文档切成 512~1024 token 的块，把被忽略的风险降到最低。别硬撑长距离记忆。
5. 实测数据与踩坑记录
最后这部分是纯经验输出。我把自己在 4090 上跑出来的数据和一个晚上踩出来的坑都放在这里，给后面接手的人省点时间。
5.1 不同配置下的实测数据
测试环境：RTX 4090 24GB，CPU 为 7950X，系统内存 64GB，PyTorch 2.1.2 + Triton 2.2.0，输入长度 512 token，生成 512 token。
| 配置 | 显存占用 | 生成速度 | 备注 |
|---|---|---|---|
| batch=1, greedy, 三值Triton kernel | 13.2GB | 18.7 token/s | 推荐日常使用 |
| batch=1, sampling(top_p=0.9), 三值Triton kernel | 13.5GB | 17.1 token/s | 采样有少量额外开销 |
| batch=4, greedy, 三值Triton kernel | 18.9GB | 12.3 token/s | 显存还行，但吞吐没提升 |
| batch=1, greedy, 纯PyTorch gather实现 | 13.0GB | 6.4 token/s | 算子没优化，明显拉胯 |
18.7 token/s 在 27B 模型里算不错了。对比同一张卡上跑 7B FP16 动辄 50~60 token/s 的成绩，这个速度确实谈不上快，但考虑到参数规模是 27B、普通 FP16 推理根本放不下，这个速度已经具备可用性。
5.2 三个容易翻车的细节
第一，transformers自动把模型转到float32。这个问题最隐蔽。某些自定义代码在加载时没有显式.half()，如果你的torch_dtype没传对，权重会在第一次 forward 时被转到float32。表现就是显存从 13GB 瞬间冲到 23GB，然后 OOM。遇到这情况先检查加载日志里有没有 "fp32" 字样。
第二，Triton kernel 的 JIT 编译时间。首次请求会慢到让你以为卡死了，我的记录是最慢一次 4 分钟才出第一个 token。这不是 bug，是 Triton 在编译 cache。建议部署时先跑一个短 prompt（比如"你好"）做 warm-up，把编译缓存落盘，后续请求就正常了。
第三，模型仓库里带的不同 shard 权重文件别用torch.load手动合并。三值模型的.bin文件往往经过了自定义打包，直接 load 出来是一堆乱糟糟的 tensor，没有任何weight键名。正确姿势永远是走模型的from_pretrained逻辑，让它自己裁剪、解码、按层加载。
5.3 硬件层面的使用建议
三值模型在推理时对显存带宽的需求还是很高，毕竟要反复读权重和 KV Cache。4090 的 GDDR6X 带宽在 4bit 量化模型上已经能跑得很欢，但 PTQ1_0 这种极限压缩模型，瓶颈往往不在带宽，而在算子的指令调度效率。所以我把功耗上限稍微拉低到 350W 跑，实测性能损失不到 3%，温度却掉了 8 到 10 度。如果你在机房或宿舍跑长时间推理，这个设置值得参考。
另外，如果你的 4090 是涡轮卡或者被动散热版本，注意 VRAM 温度。三值 kernel 的随机索引访问模式会让显存控制器比普通推理更热，温度超过 92 度时容易触发降频。用nvidia-smi dmon盯着看，如果发现 memory temp 异常，优先调整机箱风道，而不是盲目加风扇转速。
这次部署下来，我最深的体会是：大模型的显存焦虑，并不是只有"买更大显存"这一条解。27B 模型用三值化塞进一张 24GB 的 4090，跑起来效果还不能算差，这在一年前是不敢想的事。当然，PTQ1_0 也绝不是万能药，精度损失摆在那里，适合的场景应该是高并发、低显存成本、对输出细腻度要求不高的方向。如果你正打算在 4090 上跑同类三值模型，希望这份实录能让你少走几个我走过的弯路。
