1. 5.9GB 模型跑到 2.7GB 显存，这个数据是怎么来的

先交代一下背景，这个项目是我自己一直在维护的一个 Agent 框架，跑在本地工作站上，显卡是一张 8GB 显存的卡。标题里说的这个 5.9GB 模型，是一个基于 Mistral 架构裁剪出来的中尺寸模型，FP16 精度下文件大小就是 5.9GB。

按照很多人的第一反应，5.9GB 模型怎么也得准备 6GB 以上的显存才能跑起来，算上 KV Cache 和激活值，通常建议是 8GB 起步，12GB 才舒服。但实测下来，在 Agent 场景里跑这个模型，显存占用峰值只有 2.7GB，而且还跑得挺稳，单次推理响应时间在可接受范围内。这里面的核心不是"硬塞进去"，而是把显存占用的三个大头分别做了处理。

先说一个基本概念：模型跑起来的时候，显存主要吃在三个地方。

• 第一是模型权重本身，这是最大的固定开销。
• 第二是 KV Cache，就是 Transformer 在生成每个 token 时缓存的 Key 和 Value 张量，它随上下文长度线性增长，长对话里经常比权重还吃显存。
• 第三是激活值和临时张量，这部分在推理过程中动态产生，batch size 越大、序列越长，占用越高。

普通情况下，光权重这 5.9GB 就已经逼近 8GB 显卡的物理极限了，还要给 KV Cache 和激活值留空间，所以第一反应肯定是"跑不动"。但实际做 Agent 项目，我们对响应速度的容忍度更高，对"模型一次要同时处理多少内容"的约束也更强，这就有机会通过一系列手段把显存压下来。

这个 2.7GB 的数据，是在关闭 Flash Attention（因为老卡不支持）、开启 4bit 量化、限制单轮上下文 2048、加上滑动窗口 KV Cache 的情况下测得的。需要注意的是，显存占用和任务类型强相关，Agent 的思考链路通常比较短，不需要像写作任务那样生成上千个 token，这给显存优化留出了很大的操作性空间。

2. 三层压缩思路：权重、缓存、执行路径各让一步

2.1 权重层：4bit 量化不是简单砍精度

先说最直观的部分，模型权重从 5.9GB 降到大约 1.7GB，用的是 4bit 量化。这里必须澄清一个很多人误解的地方：4bit 量化不是把每个数字四舍五入到 4 位就完事，而是分块做缩放映射。

我用的方案是 GPTQ 的 4bit 版本，它会把权重矩阵分成 128 个一组的小块，每个块单独计算最大值，然后把这 128 个数统一缩放到 4bit 范围。这样做的精度损失比纯均匀量化小得多，但因为每一组都需要额外存一个缩放因子（scale）和一个零点（zero point），实际压缩比达不到刚好 50%，5.9GB 降到 1.7GB 这个数字是符合理论预期的。

有人可能会问：为什么不直接加载 FP16 然后靠显存不够时往内存溢出？理论上也可以跑，但 ollama 的 CPU offload 策略在这个场景下会导致推理速度大幅下降，Agent 交互一卡顿，整体体验就崩了。量化之后整个模型核心可以完全留在显存里，只在加载的时候短暂触及内存。

实测下来，4bit 量化对一个主要用来做工具调用和简短回复的 Agent 模型来说，输出质量下降可以接受。但如果你的 Agent 需要长文本生成、复杂代码理解或多步数学推理，4bit 会让错误率明显上升，这时候 5bit 或 6bit 是更稳妥的折中。这个我后面会再提。

2.2 缓存层：滑动窗口直接砍掉上下文扩展开销

权重降下来之后，KV Cache 成了新的显存大户。传统的 KV Cache 会随着上下文长度线性增加，2048 上下文时可能只占几百 MB，但如果 Agent 的对话历史累积到 4096 甚至 8192，Cache 大小可以轻松超过 1GB。

这个项目里解决方案是滑动窗口 KV Cache。思路很简单：只保留最近 N 个 token 的 Key 和 Value，更早的直接丢弃。N 我设置为 512，加上原始模型的 2048 上下文限制，显存里 KV Cache 峰值控制在 300MB 左右。

效果直接反映在长期运行的 Agent 场景里。一个 Agent 跑一天，每轮对话都要重新加载历史记录——如果每次都从头计算整段上下文的 KV Cache，显存会持续走高；用了滑动窗口之后，显存曲线变得非常平稳，没有随对话轮数增长的趋势。

代价是模型有时候会"忘记"比较早的对话内容。我的处理方式是把关键约束通过 system prompt 反复强调，而不是依赖模型从历史对话中自己提炼。这算是一种让步，但对工具型 Agent 影响不大。

2.3 执行路径：Flash Attention 和 Batch Size 的选择

前面说了我这张卡不支持 Flash Attention，所以注意力计算走的是标准路径，这会让激活值在长序列时有所上涨。实测 2048 上下文时激活值大约多占了 200~300MB。

另一个关键参数是 batch size。在做 Agent 项目时，我坚持 batch size = 1，也就是一次只处理一个请求。很多人觉得这样浪费硬件，但 Agent 场景的并发本来就低，而 batch size 增大对显存的需求是指数级上升的。batch = 1 时激活值占用的显存是最小的，这是 2.7GB 能压下来的重要原因之一。

之前用 vLLM 跑同一个模型做实验，vLLM 自己管理显存的方式比较激进，默认会预分配很大一块缓存，结果 8GB 卡上 OOM 了几次。后来我把 gpu_memory_utilization 调到 0.3，才勉强跑通，但吞吐提升完全体现不出来——单个 Agent 请求根本吃不满多 batch 的好处。所以在低显存 Agent 场景下，用更轻量的推理框架反而更合适。

3. Agent 场景的独特优势：为什么能比通用对话省这么多

纯粹跑一个 5.9GB 模型做通用对话，你很难在 8GB 显存上压到 2.7GB，但在 Agent 项目里确实做到了。这不是魔法，是 Agent 任务本身的特点给了优化空间。

Agent 和普通聊天机器人最大的区别在于：它不需要很长很完整的回复，而是需要多轮"短思考 + 工具调用"的循环。比如让 Agent 查天气，它可能先调用工具接口拿数据，然后生成一句话总结。这个生成过程只需要几十个 token，KV Cache 根本来不及涨起来。而普通聊天或写作任务会连续生成几百几千个 token，显存压力完全不同。

所以我在设计这个 Agent 时做了一件很关键的事：把模型的生成长度上限硬限制为 512 token。对于授信、校验、调接口这类操作，512 完全够用；即使要让模型写一段汇总报告，我拆成多个小步骤分批生成，而不是让它一口气写。这个设计直接让 KV Cache 的最大值变得可控。

另外，Agent 框架里还有一个我后来才意识到的好东西——结构化输出。我们不是让模型自由发挥，而是要求它先输出 JSON，包含工具名和参数，再由代码解析后执行。这种模式天然限制了模型的输出空间，它不需要在生成过程中反复"思考"一个字一个字往下写，而是快速定位到已经见过的 JSON 模板上。实测下来，结构化输出比自由文本生成需要的激活值更少，显存占用也更平稳。

还有一个容易被忽略的点：Agent 框架本身可以替模型承担记忆职责。普通多轮对话里，你要把完整的对话历史塞给模型，它才知道前面聊了什么。但 Agent 框架可以把对话历史转成更紧凑的摘要——不是原始文本，而是用 embedding 向量保存的索引，真正喂给模型的只有最近几轮加上系统指令。相当于把原本在显存里的上下文压力转移到了向量数据库和普通内存里。

这三点叠加起来，让一个 5.9GB 的模型在推理时表现得比"同样大小模型跑通用任务"更省显存。换个更直白的说法：Agent 是显存敏感型应用里最容易被优化的场景，因为它天然不需要长上下文和长输出。

4. 实测配置与关键参数：可以直接抄作业的版本

看到这里，你大概想知道具体该配什么参数。我直接贴一份当前工作环境的配置，这张卡是 8GB 显存的老卡，跑的模型就是那个 5.9GB 的 FP16 模型。

量化与加载配置

• 量化方式：GPTQ 4bit，group size 128
• 加载框架：llama.cpp 兼容的 GGUF 格式，配合自写加载脚本
• 上下文窗口：2048（模型本身支持 4096，但显存不够，2084 是折中）
• 滑动窗口大小：512
• 生成上限：512 token

KV Cache 相关

• 是否使用 Flash Attention：否（老卡不支持）
• Cache 数据类型：8bit（q8_0 量化）
• Cache 显存占用实测：峰值约 320MB

推理参数

• batch size：1
• 采样温度：0.2（Agent 需要确定性，这个值非常低）
• top_p：0.9
• repeat_penalty：1.1

显存实测数据（单次工具调用场景）

这份配置在跑一次"调用天气接口 + 给出简短回复"的完整 Agent 循环时，峰值显存就是 2.7GB 附近。如果任务是连续多次调用工具、每次中间还有一段分析文本，峰值会到 3.1~3.4GB，但依然远低于 8GB 上限。

还有一个值得一提的细节：如果量化精度从 4bit 提到 5bit，权重会从 1.7GB 涨到约 2.2GB，总显存约 3.3GB；降到 3bit 则可以跑到 2.2GB 左右，但输出质量下降非常明显，Agent 经常无法正确输出 JSON 格式。我的结论是 4bit 是低显存 Agent 场景的最优平衡点。

5. 三个真正的坑：量化失效、重复上下文、多 Agent 并发

纸上谈兵的参数是一回事，真正在项目里落地是另一回事。这三个月里我踩了三个印象深刻的坑，每个都值得单独拿出来说。

5.1 量化模型的输出格式稳定性

第一个坑出在工具调用的稳定性上。一开始我用 3bit 量化跑，模型有一半概率在生成工具参数时丢掉 JSON 中的某个字段，比如"city"被省略，代码层解析直接报错。后来排查发现，3bit 量化对数值相近的 token（比如"city"和"city1"）区分度变差，模型容易在两者之间摇摆。

换到 4bit 之后，这个概率从 40% 以上降到了 2% 左右，还是偶尔会出现不完整 JSON 的情况。最终的解决方案是在系统提示词里强制规定输出格式，并附带一个 JSON Schema 示例，同时把温度降到 0.2。这一套组合拳下来，失败率降低到千分之几，已经很可用了。

5.2 重复上下文拖慢加载速度

第二个坑是关于 llama.cpp 加载模型的。我最初每次调用 API 都会重新新建一个模型实例，这会导致 5.9GB 的模型文件反复从磁盘读取到内存再加载到显存，整个过程耗时接近 8 秒。Agent 一次任务要多次调用模型，累计等待时间非常痛苦。

解决办法是让模型实例常驻内存，通过一个进程内队列接收请求。这样模型只要加载一次，后续响应时间直接缩短到百毫秒级别。显存占用也因此更为可控——不再有同一时间多个模型实例同时存在的可能。

5.3 多 Agent 并发时的显存复用

第三个坑跟多 Agent 并发有关。我最初设计了三个不同的 Agent 角色，分别处理不同任务，各自加载一份模型。结果三个实例就占了 5GB 多显存，加上缓存直接 OOM。

后来把多 Agent 的设计改成共享同一个模型实例，只通过不同的 system prompt 区分角色。因为 Agent 框架本身在切换角色时只需要替换 prompt，不需要重新加载权重，显存占用不打折地省了下来。如果你在设计一个类似项目，我建议一开始就确认好 Agent 数量这么多是不是必须的——大多数情况下根本不是。

6. 后续扩展：这套方案还能往哪些方向走

项目做到这一步，显存问题基本解决了，但优化空间还很多。最近在尝试的三个方向，都跟"低显存 + Agent"这个核心有关。

第一个方向是离线批处理优化。虽然 Agent 主流程是 batch = 1，但在日志分析、历史会话摘要这类批任务上，可以临时把 batch size 提到 4 或 8，显存会在短时间内上涨，但通过时间片轮转避开主流程的推理请求，整体吞吐能提升不少。

第二个方向是模型蒸馏。我用这个大模型给一个小模型（参数量约 1.2GB）生成训练数据，让小的专门做工具调用场景。小模型在工具选择上的准确率能达到大模型的 95%，但显存占用只有 0.8GB。如果以后 Agent 场景固定，这会成为首选方案。

第三个方向是缓存复用。同一个 Agent 在多次会话中会重复调用一些工具，比如查询同一个城市的天气。目前我的做法是把工具返回结果按参数哈希缓存到内存里，如果模型请求同样的参数就直接返回缓存，不走模型推理。这样既能减少响应时间，又能进一步压低模型调用频次，显存占用自然更稳。

我实际测试下来，第三个方向的效果最明显，因为它直接减少了模型推理次数，而显存占用的大头毕竟还是发生在推理过程中的。

7. 日志复盘：从最初 OOM 到现在稳定运行的路径

回头看整段经历，从最初"装完模型一跑就 OOM"到现在稳定运行在 2.7GB，中间大概经历了四个阶段。如果你也打算跑类似的项目，不妨按这个顺序排查。

阶段一：模型装不进显存。最初我直接用 FP16 加载，5.9GB 模型，显卡 8GB，看起来勉强放得下，但一推理就 OOM。核心原因是没算上 KV Cache 和激活值，权重本身已经不是大头，动态部分才让人措手不及。这时候第一件事不是换显卡，而是先量化。

阶段二：量化之后能跑，但速度慢。4bit 之后权重降到 1.7GB，显存完全放得下，但推理速度很慢，因为加载时整个模型在 FP16 和 4bit 之间反复转换，产生了大量临时内存拷贝。后来改用 GGUF 格式，加载时就加载 4bit 权重，不再动态转换，速度改善明显。

阶段三：长对话后显存逐渐被吃满。量化解决的是权重问题，但跑了一小时后，KV Cache 持续增长，直到把显存塞满。这就是滑动窗口 KV Cache 出场的时机，显存曲线从此拉平。

阶段四：多实例并发导致 OOM 复发。最后是共享模型实例，从架构上消灭了多实例问题。

这四个阶段听起来都不复杂，但每个阶段都需要对显存构成有具体的感知，而不是单纯试参数。我的建议是：任何时候遇到 OOM，先把nvidia-smi的输出和模型加载日志放在一起看，搞清楚是权重、缓存还是激活值超限，再决定动哪一块。

从项目启动到稳定运行，花了差不多三周时间。大部分时间不是花在调参上，而是花在理解每个参数背后到底在改哪部分显存。如果一开始就带着"显存 = 权重 + KV Cache + 激活值"这个框架去调，几天就能跑通。