三进制量化实测：8G显存跑27B模型，速度23 token/s

先把结论放前面一张8GB显存的RTX 4060 Laptop跑27B参数规模的Qwen3.8-27B三进制量化版实测生成速度稳定在23 token/s左右峰值显存占用约7GB。这个数字放在一年前我自己都不信——27B模型的FP16权重要50多GB就算用常见的Q4量化也得压到16GB上下怎么算都不该出现在8G卡上。直到我拿到这个专门针对三进制量化做了适配的便携包才意识到问题出在“权重取值范围”这个根子上。这篇不是纯理论科普我直接把这个便携包里到底有什么、怎么跑起来、23 tok/s是怎么测出来的、以及这几天实测踩过的坑一起讲了。对刚接触量化模型部署的读者顺便也能把三进制量化是什么、和4-bit/8-bit量化差在哪看清楚。我自己是拿它当本地私有化文本处理工具用的如果你也是想在低显存机器上跑一个大模型这篇应该能帮你省不少折腾时间。1. 三进制量化凭什么能把27B压进8G显存1.1 权重不再是浮点数只有-1、0、1三种取值先解释一下传统量化在干什么。普通神经网络里权重是FP16或者FP32浮点数每个参数要占2到4个字节。4-bit量化把权重映射到16个离散档位每个参数占4bit8-bit量化就是256个档位8bit一个参数。不管档位怎么分本质上还是在“一定精度内近似原权重”。三进制量化走的路子更极端权重只能取-1、0、1这三个值。也就是说一个参数不是用数值大小表示而是用“方向”和“是否激活”来表示。这样做的好处非常直接——三种状态只需要log2(3)1.585bit来表达。如果用位压缩方式存储27B参数的三进制权重大约只需要5GB空间。我常用一个快递单的类比传统浮点权重相当于每件快递都填上精确到克的小数重量4-bit量化相当于把重量分成十来个档位三进制量化则直接只标“轻、中、重”三个标签。快递单本身小了一大截分拣规则也简单了一大截。1.2 显存账本算清楚8G不是标题党很多人听到“27B模型”第一反应是显存不够但这个判断通常基于标准权重体积。把几种存储方式放在一起算一下就有数了存储方式每参数占位27B模型估算体积8G显存能否运行FP1616bit54GB否Q8_08-bit约8.5bit29GB否Q4_K_M4-bit约4.5bit16GB否三进制1.58bit约1.585bit5.1GB能运行具体算法不复杂27e9个参数每个占1.585bit总计约428亿bit除以8得到5.35GB再算上GGUF格式自身的少量头信息和分块对齐实际权重文件显示为5.1GB左右。但模型能塞进显存不等于能跑。此时还需要给KV Cache和推理框架的中间缓冲留空间。我实测8K上下文时KV Cache大约占1GB推理引擎的激活值和临时缓冲区又占掉1GB出头峰值总占用约7GB。也就是说8G卡在8K上下文下还有约1GB余量属于“能跑但别乱加东西”的状态。1.3 这不是“训练完再硬压”而是专门适配过的权重三进制量化有一个很反直觉的门槛你不能把普通FP16模型下载下来直接写成“大于0.5就是1、小于-0.5就是-1”的截断逻辑那样模型会彻底崩掉。原因在于神经网络训练时权重分布是连续且相互补偿的。强行三值化等于把大量信息直接丢弃模型输出的质量会退化到没法看。真正可用的三进制模型通常要在预训练阶段就融入低bit约束或者在后训练阶段用专门的校准流程去适配三值分布让模型学会在“只有三种取值”的条件下组织表达能力。这个便携包里的Qwen3.8-27B权重就是按这套逻辑来的。GGUF文件的头部会标注特殊的量化类型标记常见的叫法是“三进制/TERN”有时候也写成1.58bit。这也是为什么你拿原版llama.cpp直接加载时会报错它根本不认识这种类型我在第五章会再展开说。2. 便携包里到底装了些什么2.1 解压后的文件结构这个便携包解压后不到6GB其中大头是模型权重。整个目录结构很干净qwen3-ternary-pack/ ├── models/ │ ├── config.json │ ├── tokenizer.model │ ├── tokenizer.json │ └── qwen3.8-27b-ternary.gguf # 约5.1GB ├── bin/ │ ├── llama-cli │ ├── llama-server │ └── quantize-stats ├── scripts/ │ ├── start_cli.sh │ ├── start_server.sh │ └── benchmark.sh ├── checksums/ │ └── sha256.txt └── README.mdmodels目录放权重和分词器bin目录放编译好的推理引擎scripts目录是启动脚本checksums里是校验文件。这种分工对我这种喜欢折腾的用户很友好——模型权重可以单独换成更新版本引擎也可以单独升级互不干扰。2.2 推理引擎为什么不能用原版三进制权重在计算上和普通量化模型有个本质区别普通量化模型矩阵乘法仍然在算“数值乘积”只是精度低三进制模型里权重只有-1、0、1乘法操作可以大幅简化——乘以1直接取原值乘以-1取反乘以0直接忽略。听起来简单但底层kernel实现并不轻松。GPU上要利用这种特性需要把三值权重做位打包然后在矩阵乘时用查表、加法树之类的技巧去还原结果。原版llama.cpp和大多数llama-cpp-python wheel都不带这个kernel所以直接用就会报“unknown quantization type”或者根本没走加速路径。便携包里bin目录下的llama-cli和llama-server是针对三值kernel单独编译过的CUDA版本。这个版本不只认得TERN类型还内置了显存控制逻辑能把三值权重按位解包后直接丢给GPU计算。如果你要自己编译需要在源码里打开对应的三进制量化开关并且锁定和模型匹配的引擎版本不要随手拿最新版编很容易不兼容。2.3 校验和版本信息别嫌麻烦这一步很重要现在很多朋友会去网盘或社区下载这类便捷包但5GB级别的大文件很容易在传输过程中损坏。我习惯先把checksums/sha256.txt里的哈希值跑一遍再决定要不要解压sha256sum models/qwen3.8-27b-ternary.gguf然后和sha256.txt里记录的对比一致才继续。之前有几次偷懒跳过这一步后面跑起来要么秒退、要么生成到一半乱码排查半天才发现是权重文件坏了。README里还会写清引擎对应的CUDA计算能力要求。简单说支持CUDA的NVIDIA显卡基本都能跑但比较旧的Maxwell架构卡没有经过专门优化速度会差很多。便携包发布者不把下载链接直接贴在正文里一般也是因为包更新太快链接放出来容易失效我建议关注发布页和更新记录按版本号去找对应文件。3. 一键启动从解压到跑出23 tok/s3.1 准备工作驱动、显存、上下文Windows系统下建议先把NVIDIA驱动更新到近期版本。这个便携包的引擎把CUDA运行时静态链接进二进制了所以不需要额外安装CUDA Toolkit这一点对新手很省事。跑之前打开任务管理器看一眼显存状态浏览器开一堆标签页都可能占用不少专用GPU显存8G卡本身余量就小能关就关。如果要用长上下文先想清楚KV Cache的代价——8K上下文的KV Cache大约要吃1GB显存16K就直接翻倍8G卡基本到了临界点。3.2 CLI模式一条命令跑起来进入解压目录后CLI模式命令如下cd qwen3-ternary-pack ./bin/llama-cli \ -m models/qwen3.8-27b-ternary.gguf \ -p 用一句话解释三进制量化 \ -n 256 \ -t 8 \ -ngl 99 \ --temp 0.7几个参数说一下-m指定模型路径这个不用多讲。-n 256表示最多生成256个token。-t 8是CPU线程数主要影响prompt处理阶段生成阶段基本由GPU接管。-ngl 99表示把98层以上的计算层全部放到GPU上执行。这个参数是最重要的漏掉的话模型会走CPU解码速度会从23 tok/s掉到3 tok/s左右体感天差地别。--temp 0.7是生成温度调低一点输出更稳定调高一点更发散。第一次跑的时候建议把-n设小一点比如64先确认链路是通的再放开生成长度。3.3 服务器模式OpenAI兼容接口对接脚本很方便CLI适合临时测一测真正融入工作流我还是推荐开服务器模式./bin/llama-server \ -m models/qwen3.8-27b-ternary.gguf \ -ngl 99 \ --host 127.0.0.1 \ --port 8080 \ -c 8192启动后它会监听本机8080端口并提供/v1/chat/completions和/v1/completions接口。用Python对接非常自然from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8080/v1, api_keysk-local ) resp client.chat.completions.create( modelqwen3.8-27b-ternary, messages[{role: user, content: 把下面这段邮件总结成三个要点}], max_tokens256, temperature0.3 ) print(resp.choices[0].message.content)这样跑起来之后模型变成一个本地服务其他脚本、自动化流程都可以通过HTTP接口调用不用每次重复加载模型。对8G卡来说服务器模式只接受单并发请求时最稳并发太高KV Cache会暴涨显存很容易撑不住。3.4 benchmark脚本与23 tok/s的实测环境便携包scripts/benchmark.sh是固定测速脚本做的事情很简单加载模型给一段固定prompt生成固定长度最后统计耗时并算出平均token/s。我这次实测环境是RTX 4060 Laptop 8G驱动版本较新室温空调房生成阶段稳定在23 tok/s左右。需要注意23 tok/s通常指解码decoding阶段速度也就是“已经看到prompt之后逐个生成token”的速度。prefill阶段处理长prompt时速度会更快因为一次可以并行处理很多token但讨论“生成速度”时大家默认还是看decoding。你测出来不是23也正常不同显卡、不同上下文长度、甚至不同驱动版本都会影响这个数关键是先跑通再谈优化。4. 23 tok/s背后的速度瓶颈与调参空间4.1 瓶颈主要在显存带宽而不是计算量很多人以为量化模型速度快是因为“计算量变小了”这只说对了一半。三进制量化让计算确实变简单了但在GPU解码阶段真正卡脖子的通常是显存带宽。解码是逐token进行的每生成一个token理论上都需要把模型权重从显存里完整读一遍。权重越小每token需要搬运的数据越少速度就越快。5.1GB的三进制权重一张显存带宽约256GB/s的显卡理论极限大概是50 token/s。实际跑23 tok/s很正常因为还要算KV Cache读写、激活值搬运、kernel启动开销这些都会吃掉带宽。我拿不同档位显卡简单推演过8G显存范围内的参考值如下显卡显存带宽理论极限参考实测参考RTX 4050 Laptop 8G约192GB/s35 token/s左右16-20 token/sRTX 4060 Laptop 8G约256GB/s47 token/s左右23 token/sRTX 3060 12G约288GB/s53 token/s左右25-30 token/s所以如果你换了更高带宽的卡感觉速度没有翻倍不用太奇怪因为带宽只是决定性因素之一模型权重从5GB降到更低已经不太现实剩下的优化空间主要在kernel效率和显存带宽利用率上。4.2 和4-bit、8-bit、MLX量化放在一起看把三进制量化放到整个量化谱系里看会更清楚方案27B模型体积8G卡可跑适合场景三进制1.58bit5.1GB可以低显存本地部署、批量文本处理4-bitGGUF Q4_K_M16GB否精度要求中等、显存16G以上8-bitGGUF Q8_029GB否精度优先、显存充裕MLX 4-bit15GB左右看平台Apple Silicon统一内存机型MLX是Apple生态的推理框架和Windows/Linux下的CUDA路径不冲突。你如果是Mac用户走MLX 4-bit是顺理成章的但8G显卡跑不了这套反过来三进制便携包主要面向NVIDIA显卡环境。vLLM那边也有Q8_0量化版的部署惯例走OpenAI兼容服务生产环境吞吐量有优势但那是给服务器多卡场景准备的。8G单卡直接跑三进制便携包胜在“体积小、装得下、可离线”并不是要全面替代高bit方案。4.3 上下文长度和并发参数怎么调便携包默认上下文长度是8192这个值对8G卡来说是安全和极限的边缘。如果启动后直接CUDA out of memory优先把-c降到4096能看到显存占用立刻少一小截。服务器模式下--parallel参数控制并发请求数。8G卡老老实实设1就行设2会让KV Cache翻倍模型权重本身5GB再翻倍缓存很容易爆。想提高吞吐不如把请求排队处理而不是用并发。还有一个容易忽略的配置--cont-batching这类连续批处理开关默认一般开着对处理多个短请求有帮助但对单请求场景影响不大不用刻意去调。5. 实测一周踩过的坑与解决方案5.1 最反直觉的坑没设-ngl速度只有3 tok/s第一次启动时我用的命令漏掉了-ngl参数模型直接跑到了CPU上生成速度惨不忍睹一个token要三百毫秒体感就是连续打字四五个字才能蹦出一个词。排查过程其实很基础先看任务管理器发现GPU占用不到10%CPU却满载。一看进程命令行发现自己没显式指定GPU层数引擎默认把模型放在CPU计算。解决方式就是在启动命令里加-ngl 99把几乎所有计算层都放到GPU速度立刻回到20多token/s。这个坑对老手来说不算问题但便携包面向的很多用户是第一次接触llama.cpp系引擎特别容易踩中。启动脚本里我后来直接把-ngl 99写死省得每次手输。5.2 显存溢出把上下文窗口设到16384的教训为了追求长文档处理我一开始把-c设成16384结果模型加载完prompt还没开始处理就报了CUDA out of memory进程直接被系统杀死。原因不复杂上下文窗口是按倍数吃显存的。同一个模型8K环境的KV Cache约1GB16K就是2GB。三进制权重5GB加上KV Cache和推理中间缓冲16384的配置峰值轻松超过8GB。解决方式是降级到8192稳定运行。后来为了再省一点显存我把-c设4096显存占用能压到6.5GB左右给系统留出更多余量。我的建议是日常问答用8192做长文档归纳还是切4096保稳。5.3 模型文件损坏校验SHA256不能省有一次我从网盘下载便携包后直接解压启动时模型能加载但生成内容从第几十个token开始变成无意义乱码甚至中间直接中断。仔细看日志加载阶段就有一堆“mismatch”之类的警告检查后发现是压缩包传输过程中数据损坏。大文件下载损坏概率其实不低尤其是走网盘客户端、断点续传、或者下载工具多线程并发时。从那以后我每次都先跑sha256sum和发布页的哈希对比确认一致再解压。多花一分钟能省后面两小时的排查时间。5.4 三进制权重加载报“unknown quantization type”这个坑比较有代表性。三进制量化属于较新的量化类型原版llama.cpp发布节奏还没完全跟上所以如果你不是用便携包里的bin目录而是换了原版llama-cli或者用pip新装的llama-cpp-python加载模型时大概率会报类似“unknown quantization type”的错误。一开始我还以为是模型文件坏了后来对比发现引擎版本和量化类型不匹配。解决方式就是确保使用便携包自带的引擎版本如果你确实需要在Python环境里跑优先通过llama-server启动HTTP服务然后从Python端用OpenAI接口访问避免直接加载GGUF文件。这也是我后来一直推荐服务器模式的原因——部署一次后面所有脚本对接HTTP不需要反复处理底层加载兼容问题。6. 跑了半个月后的几点个人心得这套三进制便携包我用下来最大的感触是“本地大模型”的准入门槛真的被拉低了。8G显卡原本是很多入门笔记本和mini主机的标配现在也能扛起27B级别的模型离线跑摘要、分类、信息抽取这些任务完全够用。我日常的习惯是把llama-server挂后台然后写一组Python脚本去批量调用。做邮件摘要、会议纪要整理、日志分类这类对“精确复述事实”要求没那么高的任务三进制模型输出质量完全能接受。但如果你要做代码生成、多步推理、或者对输出事实准确性极敏感的活我还是建议升级到16G以上显存去跑4-bit或更高bit版本——低bit方案不是万能的。最后分享一个小技巧便携包更新频率不慢我每两周会去看一眼发布页有没有新版本只下载模型权重文件引擎则可以继续用旧版只要README里没特别说明不兼容。这样既不用重复下载几个GB又能及时用上社区调优后的新权重。把模型和引擎版本谨慎锁定是这类便携包长期用下来最省心的做法。