自养 Agent 系列写了好几期前面聊过框架编排、工具调用协议今天这篇是被后台问得最多的实际问题我本地养的这个 Agent模型文件在磁盘上占 5.9GB但真正跑推理时 GPU 显存只吃掉 2.7GB。这个 2.7GB 不是玄学也不是极限压榨而是量化精度、KV Cache 裁剪、推理引擎参数三者叠加出来的结果。这篇日志把从 5.9GB 到 2.7GB 的完整推导过程、显存账单和实操步骤都写清楚正在折腾低显存跑模型和 Agent 的朋友可以直接照着抄。1. 先把两个数字拆明白磁盘占用和显存占用不是一回事1.1 5.9GB 到底是哪来的我这次用的 Agent 后端模型是一个 3B 参数级别的开源模型。它的 FP16 权重文件放在磁盘上就是 5.9GB 左右。很多人一看到模型文件 5.9GB就下意识觉得显存也得准备 6GB 起步实际根本不是这么回事。FP16 的意思是每个参数用 16 位浮点数存储也就是 2 个字节。3B 参数乘 2 字节理论值就接近 6GB磁盘上的 5.9GB 就是这么来的。扣掉一部分权重张量格式对齐的填充开销文件大小略小于纯理论值非常正常。那显存 2.7GB 又是怎么来的关键在于我跑的不是 FP16 原版权重而是经过 4-bit 量化的 GGUF 版本。量化之后每个参数平均只需要 0.55 字节左右Q4_K_M 级别3B 参数算下来权重部分才 1.9GB。这还没算完显存里除了权重还要装 KV Cache、激活值、CUDA 运行时开销全部加一起才撑到 2.7GB。所以第一个要纠正的认知是磁盘文件大小代表存储格式的重量显存占用代表推理运行时实际驻留 GPU 的数据量。两者之间的差值就是量化压缩出来的空间。以后你看到任何模型文件大小先别急着算显存得先问一句它是什么精度1.2 显存里到底装了什么为了后面排查问题时不至于抓瞎先把显存这笔账列清楚。跑一个 LLM 推理显存主要被四块内容吃掉了权重Weights模型参数本身量化后大幅缩小是显存占比最大的一块。KV Cache缓存历史 token 的 Key 和 Value供注意力计算使用随上下文长度增长。激活值Activations前向传播过程中的中间结果和 batch size、序列长度有关。运行时开销CUDA context、推理引擎自身缓冲区、算子的临时 workspace 等。权重是最直观的但 KV Cache 往往是被忽略的隐形杀手。有些场景权重只占 2GB上下文拉到 32K 之后 KV Cache 能吃掉几个 GB直接超显存。我后面会专门算这笔账这里先记住结论Agent 场景下显存优化的一半工作是在跟 KV Cache 打交道。激活值在单请求、batch1 的 Agent 场景下通常很小几百 MB 级别但如果你用 vLLM 这类框架开大并发激活值会明显膨胀。对单机低显存跑 Agent 来说主要矛盾永远是权重的量化等级和上下文长度这两个旋钮。2. 核心功臣量化如何把模型塞进 2.7GB2.1 从 FP16 到 GGUF你损失的到底是什么量化原理说穿了就是用更少的位数表示权重。FP16 用 16 位表示一个数值INT8 用 8 位4-bit 量化用 4 位左右。位数越少模型文件越小但精度损失越大。这就像把一张照片从无损 PNG 压成高压缩率的 JPEG肉眼看着还行但放大看细节就有区别。这里有个关键点不是所有量化都叫4-bit。llama.cpp 生态里的 GGUF 格式有 Q2_K、Q3_K、Q4_K、Q5_K、Q6_K、Q8_0 等一堆档位。Q4_K_M 里的 K 代表 k-quant 算法M 代表 mixed——它对大多数权重用 4-bit对部分敏感层用 5-bit 或 6-bit 做保护整体是个混合精度方案。这也是为什么 Q4_K_M 是社区最推荐的性价比之王而不是最极端的 Q2。那 2.7GB 是怎么通过量化达成的拿我这次的实际配置算一遍账FP16 原版3B 参数乘 2 字节 6GB磁盘 5.9GBQ4_K_M 量化权重约 1.9GB1024 token 上下文的 KV Cache约 0.1 到 0.3GB模型用了 GQAKV 很小激活值和运行时开销约 0.5GB合计2.7GB 左右实测稳定这个分配不是拍脑袋是先用公式估算再上机器验证过的。权重占大头但当你把上下文调大时KV Cache 会变成第二大块甚至反超权重。2.2 量化档位怎么选Q4、Q5、Q6 的实际取舍很多朋友一上来就问哪个量化最好我的回答一直是先看你的显存余量再谈质量。给一个我自己的选择逻辑大家可以对号入座显存余量推荐档位备注8GB 以上Q8_0 或 FP16别折腾量化直接上原版4GB 到 8GBQ6_K 或 Q5_K_M质量和体积平衡得好2GB 到 4GBQ4_K_M安全牌几乎不爆显存2GB 以下Q3_K 或 Q2_K质量下降明显建议换更小模型这次踩在 2.7GB理论上 Q6_K 也装得下权重约 2.6GB但算上 KV Cache 和运行时就超了。所以选了 Q4_K_M留出余量给上下文和 Agent 的工具调用 JSON 输出。实测下来的感受是Q4_K_M 在纯文本生成上和 FP16 的差距主要体现在长尾知识和复杂推理上。日常的意图识别、工具参数抽取、函数调用这类 Agent 高频任务损失不大。但如果你要让 Agent 做数学推理或代码生成Q4 有时候会犯傻这种场景我会临时切到 Q6_K反正在同一台机器上换模型也就几秒钟的事。提示量化损失不是均匀分布的。同一模型不同量化档位的差距在中文场景往往比英文场景更明显因为中文 token 切分更细、语义密度高。做中文 Agent 的时候宁可把上下文调小也别把量化档位压到 Q3 以下。3. Agent 场景下显存优化不只是换小模型3.1 上下文长度与 KV Cache 的显存账Agent 和普通聊天不一样它天然是长上下文玩家。每一轮工具调用的结果都要填回对话里几轮下来上下文轻松破几千 token。所以 KV Cache 的账必须算清楚。简化公式以标准多头注意力模型为例KV Cache 大小约等于 2K 和 V 两份乘层数乘隐藏维度乘序列长度乘精度字节数。拿一个典型 7B 模型算28 层乘 3584 隐藏维度乘 2 乘 2 字节每产生一个 token 大约要新增 0.4MB 的 KV 数据不同结构差异很大GQA 模型能小好几倍。看起来单 token 不大但 32K 上下文就是几百 MB 到几个 GB。我这次固定了 1024 上下文跑 AgentKV Cache 只有几十 MB几乎不构成压力。但你要是在配置里把 num_ctx 改成 8192哪怕权重只有 2GB整体可能直接顶到 3GB 以上。很多人显存不够不是模型太大是上下文拉太长。这是我踩过最多次的坑。Agent 场景下我的做法是默认 1024 到 2048 上下文通过压缩历史来省显存而不是无限拉长上下文。工具调用结果返回后只保留摘要和关键字段不把完整 JSON 一直堆在对话里。这样既省了 KV Cache也帮模型聚焦最近的意图。3.2 工具调用协议对上下文的影响另一个容易被忽略的点是工具调用的格式开销。现在主流模型都支持 function calling但协议各不相同有的是 JSON schema 注入有的是特殊 token 包裹。对低显存模型来说工具定义的 token 数量会直接影响有效上下文和注意力负担。我当时对比过两种做法差距很直观把 5 个工具的完整 JSON Schema 全量塞进 system prompt大约吃掉 1.2K token。只放工具名和一句话说明参数校验放到代码层做大约 0.3K token。结果显存没差多少但响应质量和速度都有提升——模型不需要在那么多 schema 里做注意力了。而且更重要的是短 system prompt 让 Q4 模型的犯傻率明显下降。Agent 框架里那些花哨的工具描述在低显存模型下就是负担。这个点对模型选型也有启发如果你只有 2.7GB 显存别想着跑一个需要复杂工具描述的 Agent。尽量让工具保持简单、扁平、数量少把复杂度留在代码层而不是模型层。4. 实操过程5.9GB 模型压缩到 2.7GB 显存的完整步骤4.1 模型选择与 GGUF 量化版本下载先说选模型。低显存跑 Agent我建议别死磕 7B3B 级别是甜点区。我用的这个 3B 模型支持工具调用FP16 权重正好 5.9GB 左右——这就是标题里那个数字的来历。下载时直接找 GGUF 量化版本不用自己转。Hugging Face 上很多量化作者会把 Q4_K_M、Q5_K_M、Q6_K 等档位都放出来选 Q4_K_M 即可。注意看 GGUF 文件命名一般格式是模型名-量化档位-q4_k_m.gguf。下错档位比如误下了 Q8是最常见的翻车点我见过有人抱怨显存不够结果一看他下的是 Q8_0 版本。提示如果项目仓库里只有 FP16 权重可以用 llama.cpp 的 convert.py 转 GGUF再用 quantize 命令量化实际命令是./llama-quantize model-f16.gguf model-q4.gguf Q4_K_M。我这次没走这条路直接用现成的量化文件省时间也少踩环境依赖的坑。4.2 推理引擎的参数配置以 Ollama 为例我用的是 Ollama 作为推理引擎架构简单、显存管理也省心。先写一个 Modelfile把模型档位和关键参数固化下来FROM ./model-q4_k_m.gguf PARAMETER num_ctx 1024 PARAMETER temperature 0.7 PARAMETER top_p 0.9 PARAMETER stop |im_end|然后执行ollama create agent-bot -f Modelfile创建本地模型。这里最关键的就是num_ctx它直接决定 KV Cache 大小。Ollama 默认可能是 2048 或 4096自己跑 Agent 的时候按显存余量改到 1024 到 2048 比较稳妥。在 Python 侧调用时用 OpenAI 兼容接口就好import ollama response ollama.chat( modelagent-bot, messages[ {role: system, content: 你是一个工具调度 Agent只能调用提供的函数。}, {role: user, content: 帮我把今天的待办事项整理成清单。}, ], tools[ { type: function, function: { name: list_todos, description: 获取待办事项列表, parameters: {type: object, properties: {}}, }, } ], )这个接口会自动处理 tool_calls模型返回工具调用指令后你在代码里执行并把结果回填成一条新的 user 消息。整套流程就是标准的 ReAct 循环Ollama 负责模型侧Agent 逻辑自己写不依赖重型框架。4.3 显存实测与监控方法配置完别急着关先测一下真实占用。用 nvidia-smi 看整体nvidia-smi --query-gpumemory.used,memory.total --formatcsv跑起来后再用ollama ps看模型在 GPU 上的实际驻留情况它会显示每个模型占了多少显存。我当时实测的记录冷启动模型加载完成显存占用约 2.3GB跑一轮带工具调用的对话上下文累计约 800 token2.6GB连续对话半小时稳定在 2.7GB没有继续增长对比同模型 Q6_K 版本权重 2.6GB加载完就 3.1GB跑一轮工具调用直接到 3.4GB。所以 Q4_K_M 的 2.7GB 是权衡后的结果不是极限压榨余量留给了上下文波动。如果想看模型内部各块占用的比例可以用ollama ps --format json里面能看出 weights 和 kv_cache 的数据。这个信息对判断该调上下文还是该换量化档位很有参考价值。权重占大头就换更低档量化KV Cache 占大头就砍 num_ctx别两个一起乱调。5. 踩坑记录与排查速查表5.1 显存超限的常见原因把这段时间遇到的坑整理一下按出现频率排序上下文被悄悄拉长框架默认 num_ctx 太大一启动就 OOM。解决显式在 Modelfile 里设 num_ctx别依赖默认值。量化档位下错项目页面默认展示 Q8 或 Q6手滑下成高精度版本显存直接超。解决下载时确认文件名里的档位标识。多实例叠加之前跑的进程没关干净多个模型同时驻留显存。解决ollama stop model手动释放或者重启 Ollama 服务。工具返回结果太长函数返回一个超长 JSON直接吞掉几百 token 上下文。解决工具侧做截断只回传必要字段。这里有个很实用的排查思路先看ollama ps确认是模型权重占大头还是 KV Cache 占大头再对症下药。不要一看到 OOM 就急着换量化档位有时候砍一半上下文就解决了。5.2 量化后效果变差的处理Q4 模型在 Agent 场景最容易出的问题有两个工具名记错、参数格式瞎编。前者表现为模型返回一个不存在的函数名后者表现为参数里塞了 schema 里没有的字段。这类问题不是模型笨而是量化损失在低熵任务上的放大。我总结的应对办法工具名用易联想的名字别用缩写。模型对get_weather的理解远好于gw。参数 schema 尽量扁平别搞深嵌套。Q4 模型对嵌套 JSON 的生成能力会打折。温度调到 0.6 到 0.7太高容易放飞自我乱编参数。在代码层加一次参数校验模型返回的工具调用不合法就让它重新生成不要让脏数据进入执行流程。这属于低显存跑 Agent 必须付出的代价用一点点工程上的校验成本换模型质量上的容错空间。值。5.3 多轮对话后显存缓慢爬升如果显存不是一开始就爆而是跑着跑着慢慢涨大概率是 KV Cache 在累积。Ollama 默认会做上下文滚动窗口内的旧 token 被移出但如果你在代码里手动把每轮工具结果不断追加到 messages 列表整个列表会越来越长内存和显存都会跟着涨。我的处理方式在 Agent 循环里维护一个固定长度的上下文队列超过阈值就把最早的消息压缩成一句摘要。这既省显存也帮模型聚焦最近的意图。实测连续跑 50 轮对话显存占用曲线是一条平线而不是爬坡。6. 后续还能怎么榨三条进阶思路6.1 换更小的架构如果 3B 模型还不够可以考虑 1.5B 甚至 0.5B 级别的模型做 Agent。代价是工具调用能力明显下降复杂 Agent 任务基本别想。我试过 1.5B 模型跑简单查询类 Agent 勉强能用但一旦涉及多步推理就开始崩。低显存和 Agent 复杂度之间是需要明确取舍的。6.2 开启 KV Cache 量化llama.cpp 和 Ollama 都支持 KV Cache 从 FP16 降到 INT8 甚至 INT4。开启后 KV Cache 能再省一半以上代价是长上下文下的数值精度损失。对 1024 上下文这种短场景收益不大但如果你的 Agent 需要 8K 以上上下文这个选项很值得开。配置方式是在 Modelfile 里加PARAMETER cache_type_k q8_0 PARAMETER cache_type_v q8_0实测 8K 上下文场景下KV Cache 能减少 40% 左右模型质量几乎无感。短上下文下反而没必要多一层数值误差不如多留点余量。6.3 Agent 上下文精简是终极省显存方案最省显存的方式永远是别往上下文里堆垃圾。我现在的 Agent 会做三级清理工具结果只回传结构化关键字段。每 5 轮对话做一次历史摘要。system prompt 里的工具描述按需动态注入不用的工具不占用上下文。这三条落实下来比任何量化优化都管用。显存优化到最后比拼的其实是谁能更克制地把信息塞进模型。这台机器是我的日常开发机显存只有 6GB一开始所有人都说跑不了 Agent。但一套组合拳下来——3B 模型、Q4_K_M 量化、1024 上下文、工具描述精简——不仅跑起来了而且稳定跑了两周没爆过一次显存。我现在的体会是低显存环境下工程优化比模型选型更重要。不要迷信大模型把量化档位、上下文长度、工具协议这三件事调明白6GB 显存也能养一个能用的 Agent。你可以从自己的模型文件大小出发按这篇文章的公式算一遍显存账再决定该从哪里开始优化。