低显存跑大模型：量化、KV Cache压缩与Agent实战优化全解

很多人看到“5.9GB 模型只占 2.7GB 显存”这种日志记录，第一反应通常是“量化了吧”。但真正跑过自养 Agent 的人都知道，事情远没那么简单。模型文件多大是一回事，推理时显存实际吃多少是另一回事，中间还隔着 KV Cache、激活值、推理框架的显存管理策略，甚至你日志里那行显存统计本身的统计口径。

我手上这台机器是张 8GB 显存的卡，Agent 要跑的模型是从开源社区拉下来微调过的一个 8B 级模型。未量化权重 fp16 大概是 16GB 左右，装不下。于是走了一条“量化权重 + 显存按需加载 + KV Cache 压缩”的路子，最后在 Agent 日志里记下来的显存峰值只有 2.7GB。这篇就把这套思路和实测过程完整拆出来，给同样想用低显存跑自养 Agent 的朋友做个参考。

1. 先把显存账算明白：模型为什么天生“吃”显存

1.1 显存到底被谁吃掉了

很多人一说到显存占用，第一反应就是“模型权重”。权重确实是最大头，但它远不是全部。一次正常的 LLM 推理过程中，显存里同时站着三部分：权重参数、KV Cache、激活值，另外还有 CUDA context 这类固定开销。

权重参数好理解，就是模型的全部参数按精度存下来。KV Cache 是推理过程中生成每个 token 时都要保存的历史信息的键值缓存，它随序列长度线性增长。激活值则是每个 layer 计算过程的中间产物，它跟 batch size 和序列长度强相关。

这三者的分配比例，我在实测中大概是这样：8B 模型 fp16 权重 16GB，如果你们直接用默认配置跑，输入上下文到 4096 时 KV Cache 吃掉 2-4GB 也是常态，激活值再吃掉一部分，这就解释了为什么很多人“明明模型只有十几个 GB，装上卡就满”。

1.2 显存的计算公式和直观估算

权重占多少，本质上是一个小学数学公式：

显存 = 模型参数量 × 每个参数的字节数

以 7B 模型为例，fp16 精度时每个参数占 2 字节，所以大概是 (7 \times 10^9 \times 2 = 14GB)。如果换成 int8 精度，每参数 1 字节，变成 7GB。int4 精度时，每参数约 0.5 字节，变成 3.5GB 左右。

KV Cache 的估算稍微麻烦一点：

KV Cache = 2 × layers × seq_len × hidden_size × 每个缓存值的字节数 × batch_size

这个公式里的 2 是 K 和 V 两份。模型层数动辄 30 到 60 层，hidden_size 在 4096 上下，乘起来之后数字很快就不小。比如 8B 模型，4096 上下文，fp16 的 KV Cache 大约是单序列 1-2GB。如果多个并发请求，这个数会线性翻倍。

所以“5.9GB 模型只占 2.7GB 显存”这个结果，不是单一手段的功劳，必须把三块全都压到最低，还要配合推理框架的显存复用机制。想清楚这笔账，后面做选型才不会误判。

1.3 低显存跑模型的常见路线对比

我梳理了自己调研过的三条路线，给各位做个对比：

我最终采用的是第三种方案的变体，在量化基础上配合 KV Cache 优化和推理框架的显存管理，最终把峰值压到 2.7GB。这不是玄学，是把每一块都算到极致后的自然结果。

2. 核心优化拆解：从 5.9GB 到 2.7GB 的链路是怎么走的

2.1 权重量化：模型文件如何从 5.9GB 再缩小

要解释“5.9GB 模型”和“2.7GB 显存”的关系，先把概念对齐。我说的 5.9GB，是量化后落盘的模型文件大小。这个文件是 int8 和 int4 混合量化的结果，对于 8B 模型来说，如果全量 int8 大概 8GB，int4 大概 4GB 出头，5.9GB 说明一部分结构用了 int8，一部分用了 int4。

实际操作中，embedding 层和最后的 lm_head 层通常保留更高精度，因为这两部分对量化误差最敏感。其余 transformer 层的 attention 权重和 MLP 权重用 int4 group quantization 压缩。group size 我用的是 128，也就是说每 128 个参数共享一组缩放因子，算是一个精度和体积的平衡点。

很多做过量化的朋友可能听说过 AWQ 或者 GPTQ，这两种方法比简单的 round-to-nearest 量化好不少。简单说就是通过分析激活值的分布，给重要的权重通道保留更高的量化精度，把误差集中在不重要的通道上。实测下来，相同比特数下困惑度损失能比朴素量化低 0.3-0.5 个点。

不过这里要提醒一句：量化不是万能的。如果你的应用场景对模型的数学推理、代码生成能力要求特别高，建议 int8 起步，int4 需要配合足够量的校准数据来评估。我在自养 Agent 的场景里主要做信息抽取、工具调用和分类，对精度容忍度较高，int4 是个划算的选择。

2.2 KV Cache 瘦身方案：把“内存账本”做小

权重压完之后，下一个大头就是 KV Cache。我在 Agent 的自养环境里，上下文长度大多在 2048 到 4096 之间。但即便如此，并发处理多个会话时，KV Cache 累计起来非常惊人。

这里用了三层手段。第一层是 KV Cache 量化，把缓存从 fp16 压到 int8。实测下来，int8 的 KV Cache 对生成质量的影响很小，但显存占用能直接减半。第二层是 PagedAttention，这是从操作系统虚拟内存分页里借鉴的思路。它把 KV Cache 划分成固定大小的块，按需分配，而不是给每个序列一次性预留最大空间。这解决的是“内存碎片化”问题，能显著提升显存利用率。

第三层是滑动窗口注意力（sliding window attention），这跟热搜词里的“滑动窗口滤波模型”不是一回事，但思路类似——只对最近的若干个 token 做完整注意力计算，更早期的历史信息通过其他机制保留。我把窗口设成 1024，对 Agent 这种需要长时间多轮对话的场景来说，效果非常明显。超过窗口的早期信息虽然不再直接参与注意力计算，但 Agent 的工具调用结果通常会通过摘要机制压缩进新的轮次里，对效果影响很小。

这三层下来，KV Cache 单序列占用从接近 2GB 降到了几百 MB 级别，服务端跑多路并发时才不会频繁触顶。

2.3 推理框架的显存复用与按需加载

除了量化之外，推理框架本身的显存管理策略同样关键。我之前试过直接用原始 PyTorch 代码推理，显存占用极度不可控，因为默认的反向传播图虽然推理模式下不会保留梯度，但 CUDA 的显存分配器还是会预留大量缓存块。

好的推理框架会显式预分配显存池，并对权重做张量级调度。举例来说，模型的多层 transformer 结构里，并不是每一层都要常驻显存。框架可以只保留当前正在计算的几个 layer 的权重在显存里，其余 layer 的权重留在内存，靠计算前异步拷贝拉进来。这就是“层间调度”的思路，它的代价是如果 PCIe 带宽不够，会拖慢首 token 生成速度，但在 8GB 显存的场景里完全是拿来换命。

现在我使用的方案是 GPU 和 CPU 混合推理模式，把 5.9GB 的模型文件通过 mmap 方式映射进内存。模型文件本身在磁盘上，通过操作系统的页缓存机制按需读入。显存里只保留最近使用的中间层和关键的量化解码参数，2.7GB 就是这个状态下的实测峰值。

3. Agent 实战部署：这套方案具体怎么落地

3.1 自养 Agent 的整体架构规划

在讲部署细节之前，先交代一下这个 Agent 是干什么的。我自己养的 Agent 主要负责三件事：定时抓取订阅源里的信息、调用外部工具 API 做数据处理、按照预设规则生成摘要或触发提醒。

整个跑在一台只有 8GB 显存的机器上，没有多余的 GPU 资源。这个定位决定了它不需要超长上下文，不需要极高的吞吐，但需要稳定、可持续运行，并且能在日志里看到每次任务执行的情况。

所以架构上，我把 Agent 的调度逻辑和模型推理拆成了两个进程。调度进程用纯 Python 写成，负责定时任务调度、工具调用、会话状态管理。推理进程则是独立的模型服务，通过 HTTP 接口和调度进程通信。这样模型服务崩了不会拖垮整个 Agent，日志也能分开收集。

3.2 关键部署步骤与参数配置

第一步是准备模型。原始模型从开源社区下载 fp16 权重后，先用量化脚本转成混合精度的量化格式。这一步不要在目标机器上做，我在一台内存比较大的工作站上完成，量化过程本身耗时不长，但需要加载原始模型，16GB 显存或 32GB 内存是底线。

第二步是配置推理服务。核心参数有几个，逐个说：

• n_gpu_layers：决定多少层放进显存。我设了 26 层里的 20 层驻留显存，剩余层跑在 CPU 上
• n_ctx：上下文长度设成 4096，这是服务能接受的最大长度，实际运行中多数会话在 1500 左右
• n_batch：批处理大小设成 512，影响 prompt 预处理的并发度
• KV Cache 量化开关：开启 int8 量化，配合上面的滑动窗口机制

第三步是起服务和配日志。日志系统用的是 filebeat 做采集，统一往本机的日志服务里送。Agent 的每一轮决策、每次工具调用的入参出参、每次模型推理的 token 数和耗时，全部结构化输出。这样后续排查问题的时候不用去翻乱七八糟的 stdout，直接查日志就行。

3.3 显存观测和日志采集的配置

显存数据不是靠肉眼盯出来的，我每隔几秒采样一次，把nvidia-smi查到的显存使用量写入日志文件，再连同 Agent 运行日志一起发到集中式日志平台里。

*/1 * * * * nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu --format=csv >> /var/log/agent/gpu_usage.log 2>&1

这里有一个容易踩的坑：直接看nvidia-smi查出的显存占用并不完全等于模型实际使用的显存。CUDA 的显存池会预留一部分空间来避免频繁分配，所以观测到的数字可能高于实际需要。后来我在日志里同时记录推理服务自身输出的内存指标，两个数据互相印证，才得到准确的占用曲线。

另外，crontab的执行日志也要单独留一份。自养 Agent 里很多任务是定时触发的，crontab 执行失败经常是因为环境变量没加载，这类问题不查执行日志根本定位不到。

4. 实测记录：Agent 日志里的显存和性能轨迹

4.1 显存实测数据：峰值 2.7GB 是怎么来的

我翻出一段真实的运行日志，把关键指标列出来：

[12:04:15] init memory: 1.84GB [12:04:22] prompt processed, tokens=286, peak memory=2.31GB [12:04:26] generation started, tokens=0 [12:05:14] generation done, tokens=412, peak memory=2.63GB [12:05:16] request finished, releasing cache, memory drop to 2.01GB

模型加载初始占用约 1.8GB，prompt 预处理阶段会涨到 2.3GB，因为要缓存输入序列的中间状态。生成阶段一路爬到 2.63GB，这是整个周期里最高的点。等请求结束，KV Cache 释放后，回落到 2GB 左右。

从这条日志可以看出来，2.7GB 是一个峰值，不是平均值。很多人看到“模型 5.9GB 只占 2.7GB 显存”会以为是全程这么多，其实它是有明显波动曲线的。如果你要评估自己的机器够不够跑，一定要看峰值，别看平均值。

4.2 从日志定位一次“显存突然暴涨”的问题

有一次 Agent 在跑一个长文档摘要任务时，显存突然从 2.0GB 一路干到 5.8GB，离 OOM 就差一步。当时第一反应是上下文超长了，但查日志发现输入 token 只有 2400，远没到上限。

最后定位到的原因是：那次任务的系统提示词里塞了完整的历史工具调用记录，导致每个 transformer 层都额外缓存了大量中间激活值。这暴露了一个容易忽略的问题——显存峰值不仅取决于 KV Cache，还取决于输入序列的瞬时激活值，后者跟输入长度直接相关，而且不会像 KV Cache 那样有现成的日志指标可查。

解法是给 Agent 加一个输入压缩层，超长历史先通过摘要模型压成 500 token 以内的摘要再进入主模型。这样既保留了必要信息，又把激活值峰值压了下去。这个经验让我在后面的 Agent 设计里，一直在强调“给模型吃精粮，别给它吃草”。

4.3 自养 Agent 日志系统里应该至少有的指标

跑了一段时间后，我总结出这些日志核心指标，你可以对照自己的 Agent 检查一下是不是都有：

这些指标不需要全部做成复杂面板，先在日志里完整记录，后面排查问题时能省大量时间。我见过太多 Agent 项目，跑起来能用、一挂就抓瞎，本质上就是日志指标不够。

5. 常见问题速查与避坑清单

5.1 高频问题整理

把这段时间踩过的坑和网上高频问题汇总成一张表，方便各位直接对号入座：

5.2 自养 Agent 长期运行的经验总结

如果只能给一条建议，我会说：不要把所有东西都塞进显存，而是要把每一块显存都当成稀缺资源来调度。量化、KV Cache 压缩、层间调度这三件事在工程上缺一不可，少一件你的峰值就会立刻蹿上去。

另外，日志系统的价值被很多人低估了。我在这个 Agent 项目里花的优化时间，有一大半是在查日志而不是改代码。像显存这种资源，你不给它建立持续的观测曲线，就永远只能靠“感觉快满了”来猜测。一条靠谱的日志链路，能帮你提前发现“上下文长度在涨、KV Cache 在涨、最终会导致崩溃”这类温水煮青蛙式的问题。

最后分享一个实用小技巧：Agent 的会话管理里，我强制每个会话最多保留最近 20 轮对话。超过之后，不是简单的丢弃，而是用模型生成一个 200 token 以内的摘要作为前置信息。这意味着每次请求的 KV Cache 上限都是可预估的，显存占用曲线因此非常稳定。自养 Agent 跑起来省心，靠的就是这种“把上限锁死”的设计思路。