低显存跑大模型Agent：量化与混合卸载把5.9GB压到2.7GB

如果只给我一张6GB显存的老显卡，一个5.9GB体积的模型权重，还要拿来跑自养Agent，八成的人第一反应是：没戏。但这周我把这事干成了——模型照常跑，Agent照常用，推理峰值显存只有2.7GB，生成速度还稳定在25 tokens/s以上。整个过程最值钱的不是那个结果，而是我把“模型体积=显存占用”这个刻板印象拆掉的过程。这篇日志会把这个结论怎么来的、我踩了哪些坑、修了哪些参数讲清楚，特别适合卡在6GB或8GB显存边缘、又想搞Agent开发的同学。说白了，低显存不是不能玩大模型，只是你得学会算账。

1. 项目起底：5.9GB 是模型体重，2.7GB 是运行时身位，两码事

1.1 为什么模型体积5.9GB运行显存只有2.7GB

先说结论：5.9GB通常指的是模型权重文件的磁盘体积，而且是FP16精度下的原始体重。2.7GB则是推理时的峰值显存占用，它不是“模型文件的大小”，而是“模型运行时在GPU上占的床位”。这两个数字用的根本不是同一把尺子，所以看起来矛盾，其实完全说得通。

我当时拿到的模型是个3B左右的对话模型，社区里有人叫它JEV-3B，也有人喊Laya-3B，反正就是那种适合拿来做本地Agent底座的小模型。FP16权重算下来，30亿个参数，每个参数占2字节，大概就是5.9GB。可推理的时候，权重完全可以量化为4bit，每个参数只用0.5字节，一下子就从5.9GB缩到1.5GB左右。再加上KV cache、激活值和CUDA运行时，凑出2.7GB，账目刚好对得上。所以不是模型变“小”了，而是运行形态变了。

1.2 显存大头到底在哪：权重、KV cache、激活、运行时

如果你只盯着模型文件看，永远算不清显存。真正吃显存的其实是四个部分。

第一部分是权重参数，这是最大的一块，但也是压缩空间最大的一块。第二部分是KV cache，也就是Transformer推理时中间生成的Key和Value缓存，它随上下文长度线性增长，上下文越长，这玩意越肥。第三部分是激活值，推理过程中每一层算出来的中间结果，这个跟batch size和序列长度都有关系。第四部分是CUDA context、推理框架自己的buffer、临时张量，这些零零碎碎加起来也有几百MB，很多人算账时容易漏掉。

我做过一张自用表，就是照着这张表去逐项压显存的：

这样一拆，思路就清楚了：权重做量化，KV cache做控制，上下文长度做限制，临时buffer靠换框架。2.7GB不是天上掉下来的，是一笔一笔省出来的。

1.3 手算账本：从5.9GB到1.5GB再到2.7GB

我习惯把账算到具体数字，不然心里不踏实。假设这个3B模型有32层，用GQA结构，KV头数是8，每个头的维度是128。这些参数不是拍脑袋，是从模型配置文件里真实读出来的。

第一步算原始权重：30亿参数乘以FP16的2字节，等于60亿字节，约等于5.9GB，这就是磁盘上那个体积。第二步算4bit量化后的权重：30亿参数乘以0.5字节，约等于1.5GB。第三步算KV cache，假设我把上下文长度限制在4096，KV cache用8bit量化，那么KV cache占用约等于2乘以32层乘以4096长度乘以8个KV头乘以128维乘以1字节，算下来256MB左右。如果不用量化KV cache，就翻倍到512MB。第四步是激活值，3B模型在单请求、4K上下文下实测大概300MB到400MB。再加上CUDA context和框架buffer，保守按600MB算。

四项加起来：1.5GB加0.25GB加0.35GB加0.6GB，约等于2.7GB。你看，数据和实测对上了。这个账本的好处是，参数改一个，结果马上能预测。比如你想把上下文改成8192，KV cache直接翻倍，总显存就会冲过3GB。

2. 方案选型：自养Agent为什么选了“Q4量化+混合卸载”

2.1 低显存跑模型的3条路线对比

低显存环境下跑模型，无非三条路。第一条是FP16原封不动全部塞进GPU，对6GB卡来说，光权重就快6GB，再加上KV cache和激活值，必炸，直接不选。第二条是纯4bit量化，权重压到1.5GB，但全部层留在GPU上，加上各种运行时开销，实测峰值在4.5GB到5GB之间，6GB卡勉强能跑，但没余量撑Agent的长对话和工具调用。第三条是4bit量化加CPU和GPU混合推理，GPU只承载一部分层，剩下层丢给CPU，再把上下文长度压住，实测峰值可以控制在2.7GB。

三条路线我用一张表对比过：

混合卸载听起来像“又要马儿跑又要马儿不吃草”，实际上它的逻辑很简单：GPU显存不够，就让CPU和内存帮忙兜底。代价是部分层走CPU计算，速度会打折，但换来的是显存水位大幅下降。

2.2 Agent场景比单轮对话多出的那几座大山

本来跑个单轮对话，2.7GB完全够，但Agent不一样。自养Agent意味着模型要反复调用工具、处理工具返回结果、维护多轮对话，还要把系统提示词和工具定义一直放在上下文里。这些场景对显存构成了三座大山。

第一座是大系统提示词。Agent的系统提示词通常会包含角色设定、工具列表、使用规范，很轻松就能写到1000到2000个token。工具越多，定义越长。第二座是工具调用结果。Agent调用一个搜索接口或者读取一个日志文件，返回内容动不动就是几千个token，而且这些内容全部要进入上下文，撑爆KV cache就是分分钟的事。第三座是多轮历史。Agent任务很少一轮结束，它要反复推理、观察、再推理，历史消息越积越长，KV cache也跟着越长。

这就是为什么很多人跑普通对话好好的，一上Agent就爆显存。普通对话你只关心“这一轮回答”，Agent关心的是“整个上下文怎么活着”。

2.3 我的选择：Q4_K_M + GGUF + 部分层卸载

最终我选了Q4_K_M量化格式的GGUF文件，配合llama.cpp系的推理后端，再做部分层卸载。这个组合不是随便定的，每个环节都有原因。

Q4_K_M是llama.cpp社区里的4bit量化方案，它在4bit量化里属于均衡派，压缩比不错，质量损失控制得也好。选GGUF而不是直接加载HF格式，是因为GGUF天然支持mmap内存映射，加载模型时可以减少重复内存占用，还能方便地只加载部分层到GPU。部分层卸载是控制显存的核心操作，GPU和CPU各分一部分层，显存水位就可以精确调节。既然目标是2.7GB，那我就不用“全部加载”这种粗暴方式，而是用引擎参数把层数一块一块数着加载。

3. 实操全记录：从原始权重到稳定2.7GB显存

3.1 第一步：把FP16原始权重换成Q4_K_M量化格式

实际操作时，我没有直接拿FP16的原始权重去跑，而是先把模型转成GGUF格式，再做Q4_K_M量化。如果你用的是Ollama，可以直接拉官方社区做好的量化包，省掉自己量化的工序。我当时的命令很简单：

ollama pull jev-3b:q4_K_M ollama show jev-3b:q4_K_M --modelfile

这里Q4_K_M表示量化类型，K指的是K-quant算法，M是中间档位尺寸。为什么不用Q2或者Q8？Q2省显存但质量下降太明显，Agent要反复读工具调用结果，质量差了很容易理解错；Q8质量好但体积接近FP16，显存压力小不了多少。Q4_K_M是我试了一圈后觉得“省显存和质量平衡”最好的一档。

如果你不想依赖Ollama，直接用llama.cpp的量化工具也行。先把原始权重转成FP16的GGUF，然后执行量化命令，原理是一样的：把FP16的2字节权重压缩成4bit的0.5字节权重。量化之后，模型文件从5.9GB直接变成1.5GB左右，这一步就把大头解决了。

3.2 第二步：用GPU层数参数把显存“锁”在2.7GB附近

光量化还不够，还要控制“多少层交给GPU跑”。如果用llama.cpp的llama-cli，关键参数是-ngl，也就是--n-gpu-layers。Ollama里对应的环境变量是OLLAMA_GPU_LAYERS。

我一开始贪心，想全部层都塞进GPU，结果一加载就OOM。然后我改成-ngl 40，显存依然冲过3.5GB。最后我从-ngl 16开始往上试，每加5层看一次峰值显存，最终锁定在28层。这时候模型权重和KV cache的显存加起来约2.7GB，余量刚好。

OLLAMA_GPU_LAYERS=28 OLLAMA_CTX_SIZE=4096 ollama serve

这个28不是玄学，是试出来的。每一层被放到GPU上，大约会增加50MB左右的显存占用，28层乘以50MB，加上量化权重和KV cache，刚好落在目标区间。如果你换一个模型，层数、GQA配置不一样，这个数字一定得重新试。死记配置不如掌握方法。

3.3 第三步：限制上下文长度，顺手给KV cache也降一档

权重量化到了1.5GB，接下来要管住KV cache。我把上下文长度从默认的8K降到了4K，配合KV cache量化，把这部分占用从500MB左右压到250MB左右。

./build/bin/llama-cli \ -m jev-3b.Q4_K_M.gguf \ -ngl 28 \ -c 4096 \ --cache-type-k q8_0 \ --cache-type-v q8_0

--cache-type-k和--cache-type-v分别指定Key和Value缓存的精度，用q8_0表示8bit量化。KV cache量化的实际损失很小，但显存能砍一半。对Agent来说，牺牲一点点缓存精度换来更大的上下文余量，这笔账非常划算。

可能有人会问：自养Agent需要长上下文，4K够用吗？够不够用看你怎么设计Agent。如果你不做工具结果截断、不做滑动窗口，8K也不够用。我把这一步和后面Agent层的上下文治理配合起来，4K不但够用，还很稳。

3.4 第四步：用数据说话，监控峰值显存

显存优化不能靠感觉，必须盯数据。我用一个简单的命令实时监控GPU显存：

watch -n 1 nvidia-smi --query-gpu=memory.used,memory.total --format=csv

启动推理进程后，我观察到的变化很典型：模型刚加载完，显存大概1.8GB；开始生成token后，激活值堆起来，显存升到2.3GB；多轮对话进行到第三轮，KV cache长大，显存慢慢爬到2.7GB；继续对话到第六轮，显存还会继续上涨，但因为我设置了4K上下文上限，涨到2.7GB左右就会触发上下文截断回收，没有再爆过。

这里有个关键经验：显存看的是峰值，不是启动时的静态值。很多人只看加载完成那一刻的显存，发现才1.8GB就以为稳了，结果对话到第五轮直接OOM。最低水位和峰值水位之间的差值，就是KV cache长大的空间，必须把这个余量提前算进去。

4. Agent场景下的显存治理：四个容易爆显存的细节

4.1 工具调用结果不截断，上下文就是无底洞

底模型稳定跑起来之后，真正的坑才开始显露。自养Agent最容易把显存吃爆的地方，不是模型本身，而是工具调用结果。

举个例子，我让Agent去扫描一个项目目录，它返回了一个完整的JSON文件列表，里面几千个文件的路径和大小全塞进了上下文。这一下，KV cache直接涨了几百MB。从那之后我写了个工具结果截断函数：

def trim_tool_result(text: str, max_chars: int = 800) -> str: if len(text) <= max_chars: return text return text[:max_chars] + "\n...[truncated]"

所有工具返回的结果都先过一道截断，再交给模型继续推理。很多Agent框架默认不做这件事，结果就是工具越强大，上下文爆得越快。截断的副作用是要接受模型看不到完整结果，但对绝大多数工具场景来说，800字以内已经包含关键信息了。

4.2 滑动窗口上下文：给多轮记忆“减肥”

Agent跑多轮任务时，历史对话会像滚雪球一样越滚越大。我的解决办法是给上下文做一个滑动窗口：系统提示词和工具定义始终保留，但历史对话只保留最近六轮，更早的内容用一个由模型生成的摘要代替。

这样做的逻辑很简单，KV cache的增长和上下文长度直接挂钩，限制上下文长度就是限制显存涨幅。用一种类似滑动窗口的机制，让上下文永远固定在一个稳定长度，KV cache就不会无限膨胀。

我在代码里用了一个固定长度的消息队列：

context_messages = [sys_prompt, tool_defs] + recent_history[-12:]

超过窗口的消息直接丢出去，窗口内的消息保留。这种设计牺牲了一定的长期记忆能力，换来的是显存稳定和响应速度稳定。对自养Agent来说，长期记忆本来就该交给外部存储去做，而不是全塞在模型上下文里。

4.3 并发和常驻进程：自养Agent的显存回收策略

另一个容易忽略的地方是并发。自养Agent如果同时开了多个推理进程，或者让Ollama常驻多个模型，内存账单会非常难看。我遇到过一次，模型A和模型B同时在内存里待着，显存直接飙到5GB，整个系统卡到没法用。

解决方法是设置单模型常驻、用完即走：

OLLAMA_MAX_LOADED_MODELS=1 OLLAMA_KEEP_ALIVE=2m ollama serve

OLLAMA_MAX_LOADED_MODELS=1保证同一时刻只加载一个模型，OLLAMA_KEEP_ALIVE=2m表示模型空闲2分钟后自动卸载。对Agent这种“想一下、调个工具、再想一下”的节奏，2分钟的空闲窗口足够覆盖思考间隙，又不会让模型无限霸占显存。

4.4 加一道保险：自动监控显存并重启推理进程

就算前面都做了，长跑环境下还是可能出现显存泄漏。我的最后一道保险是写了一个简单的监控脚本，每隔30秒查一次显存，如果超过3.2GB就自动重启推理服务。

#!/bin/bash while true; do mem=$(nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits | head -n 1) if [ "$mem" -gt 3200 ]; then echo "显存超过3.2GB，重启推理服务" systemctl restart my-agent-llm fi sleep 30 done

这个脚本很土，但很管用。自养Agent最难的地方在于它不是跑一次就结束，而是长时间、循环式地处理任务。任何一点上下文管理漏洞都会在长时间运行中被放大，自动重启兜底不是偷懒，是务实。

5. 常见问题排查与避坑实录

5.1 低显存跑Agent常见报错速查表

这一路踩坑不少，我把常见问题整理成了一张速查表，遇到问题直接对号入座：

每条都是我真实遇到过的坑。比如“越来越慢”这个现象，很多人以为是显卡不行，其实是上下文快满了，模型每生成一个token都要处理越来越多的KV cache，速度自然下降。

5.2 三个真实排查案例：OOM、首token慢、量化后变笨

第一个案例是OOM。一开始我图省事，把上下文设到了32K，想着Agent能记住更多东西。结果第四轮对话直接炸了。排查之后发现，32K上下文下KV cache按FP16算要2GB以上，再加上1.5GB权重，6GB显存根本兜不住。把上下文降到4K并做了KV cache量化之后，问题立刻消失。

第二个案例是首token特别慢，生成速度只有8 tokens/s。我一开始怪模型，后来查了引擎日志才发现，-ngl只设了16层，剩下16层全在CPU上跑，计算瓶颈在CPU不在GPU。把GPU层数从16调到28之后，速度直接翻了三倍。这个案例说明，速度慢不一定就是量化的问题，很可能是层分配不合理。

第三个案例是量化后模型“变笨”。我一开始用Q2_K，显存确实压下来了，但Agent在工具调用时经常理解错参数，该传数字的时候传了个字符串。换成Q4_K_M之后，这种低级错误明显减少。量化是有代价的，代价大小取决于档位。Agent对语义理解要求比普通聊天高得多，不建议为了省那几百MB去用太激进的量化档。

5.3 我的避坑清单：上车前先过一遍

我把这次实践沉淀成一份检查清单，每次换模型或者换环境都会过一遍。

• 先算峰值，再跑实测。不要看到启动时显存低就以为稳了，KV cache会在对话中持续长大。
• 权重量化是第一优先级的显存压缩手段，Q4_K_M是我认为的Agent场景底线。
• GPU层数不是越多越好，够用就行，留出200MB到400MB的余量给KV cache增长。
• 上下文长度宁可短一点，也别让它接近显存上限。4K起步，不够再换更大的GPU。
• 工具调用结果一定要截断，这是Agent场景独有的坑，单轮对话完全遇不到。
• Agent系统提示词要精简。工具定义写太长，等于提前把显存预算烧光了。
• 定时重启推理进程。自养Agent长跑场景下，定期重启比优化所有参数都省心。
• 重要数据记录下来。每次调整都记下显存、速度、质量，后面排查问题能少走一半弯路。

这份清单看起来简单，但每一条背后都有一到两次OOM的教训。

6. 实测数据与后续扩展方向

6.1 不同配置下的显存、速度与质量实测

我把这次调参过程中的几组关键配置记录下来，方便对比。测试环境是一张6GB显存的显卡，模型是JEV-3B量化后的GGUF文件，上下文长度固定为4096，任务是同一个：让Agent完成一次带工具调用的信息查询。

最后一行的峰值显存最低，但速度太慢，工具调用过程中等待时间过长，整体体验反而不如2.7GB那行。这告诉我们，显存不是越低越好，低到影响速度就得不偿失了。2.7GB和2.2GB之间只差0.5GB，速度却差了三倍，这笔交易我坚决不做。

6.2 一个完整Agent任务的显存走势

为了让数据更有说服力，我跑了一个完整的Agent任务：让Agent查询本地服务日志，找出最近三次异常，并生成一份摘要。

这个任务里，Agent分了三步走：第一步读取日志，显存从初始的1.8GB升到2.3GB；第二步调用工具做异常检测，工具返回结果截断后，显存峰值爬到2.7GB；第三步生成摘要，显存稳定在2.5GB左右。整个过程中，显存在2.3GB到2.7GB之间波动，始终没有超过我设置的3.2GB保险线。

这个走势非常典型。工具调用是显存最紧张的时刻，因为工具结果会临时塞进上下文；摘要生成阶段反而是下降的，因为上下文里的工具结果已经被裁剪掉了。如果你发现Agent跑到一半显存突然飙升，八成是在等着处理一个特别大的工具返回结果。

6.3 这个思路后续还能怎么玩

这套“算清楚+压权重+控上下文”的方法论，后续还有很多扩展空间。比如，可以进一步实验投机采样，用一个小模型做草案生成，大模型只做验证，生成速度还能再往上提。也可以试试官方支持的并行解码，让多个候选token同时推进，延迟会明显下降。

从Agent角度，我打算下一步给自养Agent加一个语义缓存层：同类问题在窗口内直接走缓存，不再触发模型推理。显存省下来的部分，全部让给KV cache去做更长的工具结果分析。低显存的限制反而逼着我把Agent架构做得更干净，这算是意外收获。

这次跑完我最深的体会是：显存不够用，很多时候不是硬件不行，而是你在用“想当然”的方式跑模型。当你被迫把每一笔显存账都算清楚，被迫给工具结果做截断，被迫做上下文窗口治理，你会发现自己对模型运行机制的理解比那些“显存自由”的人反而更扎实。

最后再分享一个我的日常习惯：每次让Agent执行完工具调用之后，我都会在代码里强制把旧的大段工具输出从上下文队列里pop掉，再用新请求重发。这个习惯帮我少吃了至少十次OOM。希望你在低显存环境下，也能找到属于自己的那个平衡点。