最近几天让孩子们进行各种模型运行的探索，这个过程正好简单来测试 8 种 KV Cache 量化方案，看看对于降低显存和内存占用的具体效果。
一、测试模型：OmniCoder-9B 全面解析
模型基本信息
OmniCoder-9B 是一款基于 Qwen3.5（通义千问 3.5）架构的代码专用大语言模型。
| 模型名称 | OmniCoder-9B |
|---|---|
| 基础架构 | Qwen3.5（通义千问 3.5） |
| 参数量 | 9.0B（90 亿） |
| 上下文长度 | 262,144 tokens（256K） |
| 隐藏层维度 | 4096 |
| 量化版本 | Q4_K_M（默认） |
| 训练数据 | 软件工程代码轨迹 |
为什么选择 OmniCoder-9B 进行测试？
OmniCoder-9B 是一款功能强大的代码专用大模型，具备深度代码理解与生成能力，能够阅读现有代码结构并生成最小化、正确的代码修改。它支持错误恢复，可以从编译或运行错误中学习并自我修正，同时原生支持工具调用（Function Calling）和思维链（Thinking/Reasoning），能够输出完整的推理过程。最令人印象深刻的是其 256K 超长上下文支持，可以处理整个代码库级别的长上下文任务，这使其在复杂软件工程场景中表现出色。
选择 OmniCoder-9B 作为测试模型主要基于四个考量：首先是采用 Qwen3.5（通义千问 3.5）架构，作为最新一代开源模型架构具有广泛的参考价值；其次是原生支持 256K 超长上下文，这使得 KV Cache 优化的效果在长上下文场景下更加明显；另外，作为代码专用模型，在实际编程场景中对长上下文的需求更为普遍，测试结果更具实用价值；而且 9B 的参数量适中，消费级显卡即可运行，适合进行大规模的量化方法对比测试。
二、什么是 KV Cache？
KV Cache 的作用
在 Transformer 架构的自注意力机制中，每次生成新 token 时都需要计算所有历史 token 的 Key 和 Value 向量。为了避免重复计算，KV Cache 应运而生——它将历史 token 的 K 和 V 向量缓存起来，这样每次只需计算当前 token 的 Q 向量，然后与缓存的 K、V 进行注意力计算即可。
KV Cache 的显存占用
KV Cache 的显存占用与三个因素成正比：
- 上下文长度 - 上下文越长，需要缓存的 K、V 越多
- 模型层数 - 每层 Transformer 都需要独立的 KV Cache
- 隐藏层维度 - 维度越高，每个向量的数据量越大
对于 OmniCoder-9B（Qwen3.5 架构，4096 隐藏维度）在不同上下文下的 KV Cache 占用：
KV Cache 大小 = 2 × 层数 × 4096 维度 × 上下文长度 × 16 bits / 8
| 上下文长度 | FP16 | Q8_0 | Q4_0 | TurboQuant 2-bit |
|---|---|---|---|---|
| 32K | 512 MB | 256 MB | 128 MB | 64 MB |
| 64K | 1024 MB | 512 MB | 256 MB | 128 MB |
| 128K | 2048 MB | 1024 MB | 512 MB | 256 MB |
| 256K | 4096 MB | 2048 MB | 1024 MB | 512 MB |
OmniCoder 原生支持 256K 上下文，这带来了显著的显存挑战。在 256K 全上下文下，使用 TurboQuant 2-bit 可以节省高达 3.5GB 显存！对于只有 8GB 或 16GB 显存的消费级显卡，KV Cache 量化是运行长上下文场景的必备技术。
三、KV Cache 量化技术
量化的核心思想
KV Cache 量化的本质是用更低的精度存储 K 和 V 向量，从而减少显存占用。例如，将 FP16（16-bit）量化到 INT8（8-bit），显存占用直接减半。
但量化会带来精度损失，如何在压缩率和质量之间取得平衡，就是量化技术的核心挑战。
四、TurboQuant 量化技术
TurboQuant 是 Google 在 2025 年提出的新一代 KV Cache 量化技术（论文：arXiv:2504.19874），针对传统量化方法在低比特率下精度损失大的问题，提出了一个损失比较低的压缩方案，具体过程包括：
1. 随机旋转（Random Rotation）
通过随机正交变换将激活值分布变得更加均匀，使得量化后的误差分布更加平滑，减少极端值对量化的影响。
2. Lloyd-Max 标量量化
使用 Lloyd-Max 算法设计最优量化码本，在给定比特数下最小化量化误差，实现最优的率失真平衡。
3. 无偏内积估计
通过特殊的量化器设计，保证注意力机制中的内积计算无偏，即使在小数点量化下也能保持模型输出质量的稳定性。
五、8 种 KV Cache 量化方法理论上的对比
llama.cpp 提供了多种成熟的 KV Cache 量化方案，包括传统量化方法和 TurboQuant 新技术。
8 种量化方法对照表
| 方法 | 位数 | 压缩比 | 理论 KV Cache (64K) | 精度损失 | 特点 | 推荐场景 |
|---|---|---|---|---|---|---|
| f16 | 16-bit | 1x | ~1024 MB | 无 | 原始精度，显存占用最大 | 基准测试 |
| q8_0 | 8-bit | 2x | ~512 MB | 极小 (<1%) | 精度损失极小，显存节省 50% | 日常使用 ⭐ |
| q4_0 | 4-bit | 4x | ~256 MB | 轻微 (1-2%) | 显存节省 75%，成熟稳定 | 显存受限 |
| tq4 | 4-bit | 4x | ~256 MB | 无 | TurboQuant 4-bit，Google 推荐 | 高质量需求 |
| tq3.5 | 3.5-bit | 4.57x | ~224 MB | 质量中性 | 质量中性，性价比最高 | 长上下文 ⭐⭐ |
| tq3 | 3-bit | 5.33x | ~192 MB | 轻微 | 5 倍压缩，性能均衡 | 通用长文本 |
| tq2.5 | 2.5-bit | 6.4x | ~160 MB | 可接受 | 低比特中性能最佳 | 极限场景 ⭐ |
| tq2 | 2-bit | 8x | ~128 MB | 明显 | 8 倍压缩，显存最优 | 显存极度受限 |
注：理论 KV Cache 大小基于公式计算，实测内存占用还包含模型权重和系统开销
六、实际测试一下
硬件环境
- 设备：Apple M4 MacBook
- 后端：Metal (Apple Silicon)
- 内存：系统统一内存架构
软件环境
- 框架：MoXing (llama.cpp Python 封装)
- 模型：OmniCoder-9B (Qwen3.5 架构)
- 上下文：65536 (64K)
- 生成 tokens：50
测试命令
# 获取测试模型
ollama pull carstenuhlig/omnicoder-9b
# 运行测试（以 tq3.5 为例）
moxing ollama run OmniCoder-9B -v --kv-cache tq3.5 -c 65536 -p "hi" -n 50
性能对比表
| 量化方法 | 位数 | 描述 | 加载时间 | 生成速度 | TTFT | 峰值内存 | 状态 |
|---|---|---|---|---|---|---|---|
| ✅ f16 | 16 | FP16 原始精度 | 14.0s | 6.3 tok/s | 0.79s | 11438 MB | ✅ |
| ✅ q8_0 | 8 | 8-bit 量化 | 13.5s | 5.7 tok/s | 1.16s | 11233 MB | ✅ |
| ✅ q4_0 | 4 | 4-bit 量化 | 13.1s | 6.2 tok/s | 0.93s | 10701 MB | ✅ |
| ❌ tq4 | 4 | TurboQuant 4-bit | - | - | - | - | ❌ |
| ✅ tq3.5 | 3.5 | TurboQuant 3.5-bit | 13.4s | 5.8 tok/s | 0.84s | 11069 MB | ✅ |
| ✅ tq3 | 3 | TurboQuant 3-bit | 13.1s | 6.2 tok/s | 0.92s | 10998 MB | ✅ |
| ✅ tq2.5 | 2.5 | TurboQuant 2.5-bit | 12.8s | 6.1 tok/s | 0.81s | 10926 MB | ✅ |
| ✅ tq2 | 2 | TurboQuant 2-bit | 12.9s | 6.0 tok/s | 0.94s | 10967 MB | ✅ |
注：tq4 在某些环境下可能不支持，测试中加载失败
显存节省对比（相对 FP16）
| 方法 | 显存占用 | 节省比例 |
|---|---|---|
| f16 | 11438 MB | - |
| q8_0 | 11233 MB | 1.8% |
| q4_0 | 10701 MB | 6.5% |
| tq3.5 | 11069 MB | 3.2% |
| tq3 | 10998 MB | 3.8% |
| tq2.5 | 10926 MB | 4.5% |
| tq2 | 10967 MB | 4.1% |
注：实测内存占用包含模型权重+KV Cache+系统开销，因此节省比例低于理论值
简单分析
- 生成速度差异不大 - 所有方法的生成速度都在 5.7-6.3 tok/s 范围内，差异在 10% 以内
- TTFT 表现接近 - 首 token 延迟在 0.79-1.16s 之间，q8_0 稍慢但都在误差范围内
- 内存优化有限 - 在 Apple Silicon 统一内存架构下，KV Cache 量化对总内存占用影响较小（因为模型权重占大头）
为什么实测内存节省不明显呢？
在 9B 模型 + 64K 上下文的配置下：
- 模型权重：约 5.3 GB（主要部分）
- KV Cache (f16)：约 1 GB
- 系统开销：约 5 GB
即使 KV Cache 从 1GB 压缩到 128MB，总内存占用也只减少约 8%，这与实测结果一致。
推测在更大上下文（128K、256K）场景下，KV Cache 量化的效果会更明显。
命令集合
# 1. 日常使用（推荐）
moxing ollama run carstenuhlig/omnicoder-9b --kv-cache q8_0 -c 65536
# 2. 长上下文场景（最佳性价比）
moxing ollama run carstenuhlig/omnicoder-9b --kv-cache tq3.5 -c 65536
# 3. 极限显存压缩
moxing ollama run carstenuhlig/omnicoder-9b --kv-cache tq2 -c 65536
# 4. 代码生成任务
moxing ollama run carstenuhlig/omnicoder-9b --kv-cache q4_0 -c 32768
# 5. 基准测试（无压缩）
moxing ollama run carstenuhlig/omnicoder-9b --kv-cache f16 -c 65536
KV Cache 量化是大模型推理优化的关键技术。通过合理选择量化方法，可以在保证质量的同时降低显存占用。TurboQuant 作为新技术，在保持性能的前提下提供了更高的压缩比，建议在长上下文场景中尝试！
测试工具： https://github.com/cycleuser/MoXing
模型： https://ollama.com/library/carstenuhlig/omnicoder-9b
预览时标签不可点
Close
更多
Name cleared
微信扫一扫赞赏作者
Like the AuthorOther Amount
赞赏后展示我的头像
作品
暂无作品
Like the Author
Other Amount
¥
最低赞赏 ¥0
OK
Back
Other Amount
更多
赞赏金额
¥
最低赞赏 ¥0
1
2
3
4
5
6
7
8
9
0
.
大语言模型 · 目录
大语言模型
上一篇Google 的 TurboQuant 算法如何让AI更省内存？搞定向量量化难题下一篇FanFu（凡赴 ）：把 Ollama 的 GGUF 模型转成 HuggingFace 格式，纯好玩
Close
更多
搜索「」网络结果
Close
调整当前正文文字大小
更多
100%