1. 起因我就想在本机跑一个能自己调工具的 Agent1.1 为什么非要本机跑不可加了几个月班之后我把日常查资料、算数据、排日程的杂活整理了一遍发现它们有个共同点流程固定、重复度高、完全可以自动化。市面上的云端助手确实能做但一打开计费页面我就冷静了——按我的调用频率一个月下来够我吃好几顿好的。更不用说涉及个人笔记和内部数据的任务全都丢到别人的服务器上心里始终不踏实。所以我决定走自养Agent这条路模型权重、推理引擎、智能体框架全部跑在自己机器上。数据不出门调用不花钱想换什么模型、改什么参数随时动手。唯一要面对的问题是硬件——我手头这张显卡只有 6GB 显存。这里先说清楚什么叫能自己调工具的 Agent。它不是普通的聊天机器人而是具备工具调用tool calling/function calling能力的智能体用户给一个目标模型自己判断需要调用哪些工具计算器、文件搜索、日程查询这类生成结构化的调用请求框架去执行工具并返回结果模型再根据结果继续推理。这套循环意味着上下文里要长期塞着系统提示词、工具定义、执行结果和多轮历史对 KV Cache 的压力比普通对话大得多。方向定了麻烦也跟着来了。1.2 硬件底子和第一次 OOM先交代一下我的机器配置方便你们对比CPU8 核 16 线程日常跑 Agent 框架和工具调度够用内存32GB DDR4不宽裕但也不至于捉襟见肘GPU6GB 显存的 N 卡Ampere 架构系统Linux方便跑 Docker 容器我一开始盯上的是一个 3B 级别的 Agent 模型BF16 精度权重文件刚好 5.9GB。看到文件大小我心凉了半截——虽然5.9GB 小于 6GB 显存听起来好像装得下但推理过程从来不是只有权重一项开销。第一次实跑进程跑起来没几秒就被系统 OOM 杀掉了一点悬念都没有。那几天我反复在想方案要么降级换更小的模型要么找出真正吃掉显存的是什么。后来证明换成更小的模型是最亏的选择——因为问题根本不在模型文件本身而在于我对显存开销的构成完全没概念。等我理清楚之后同样的模型只占 2.7GB 显存跑得还挺稳。2. 显存到底花在哪了5.9GB 文件不等于 5.9GB 显存在说压缩方案之前必须先建立一个底层认知模型文件多大和推理时占多少显存是两回事。实际运行的时候显存至少被三拨人分走模型权重、KV Cache、推理引擎的额外开销。每一笔账的优化思路都不一样。2.1 第一笔账模型权重权重文件的大小基本等于参数量 × 每个参数占的字节数。5.9GB 除以 2 字节BF16 精度大概是 2.95B 个参数也就是一个标准 3B 级别模型。这里就引出了热搜里那条显存的作用和模型参数的关系参数数量决定了模型能力的上限但显存占用还要看你怎么存这些参数。同样是 2.95B 参数BF16 精度下要 5.9GB如果换成 8-bit 量化直接减半到约 3GB换成 4-bit 量化理论上只有约 1.5GB加上 GGUF 文件的元数据、头信息和部分保留为高精度的张量实际也就 1.7GB 到 1.8GB。这就是后面文件 5.9GB、显存只占 2.7GB的第一层原因——权重本身的存储精度被大幅压缩了。很多新手以为参数多就一定占显存多这句话对但不完整。准确的公式是权重显存占用 ≈ 参数量 × 量化后每参数字节数 × 1.1GGUF 头、元数据等额外开销想省显存第一优先级永远是降低权重的字节数也就是量化。模型换小反而是最后的手段因为那是在削减能力。2.2 第二笔账KV Cache权重是固定的一坨但 KV Cache 是跑起来之后才慢慢长大的也最容易被忽视。它的作用是避免模型每生成一个新 Token 就把历史重新计算一遍模型会把已经算过的 Key 和 Value 缓存下来后续直接用。上下文越长这个缓存越大。KV Cache 的大小可以这样估算2 × 层数 × KV头数 × 头维度 × 上下文长度 × 每值字节数我用的这个模型是 36 层GQA 分组注意力结构下有 2 个 KV 头头维度 128。如果上下文拉到 16K按 FP16 算2 × 36 × 2 × 128 × 16384 × 2 603,979,776 字节 ≈ 0.58GB看着只有 0.6GB 左右但注意这是按 16K 上下文算的。Agent 场景有个特殊的地方智能体的系统提示词、工具定义、历次工具返回结果、多轮推理过程全都堆在上下文里一个带工具调用的任务轻轻松松就把上下文吃满。上下文从 2K 涨到 16KKV Cache 同步涨 8 倍。如果你的框架不会整理会话历史KV Cache 就会变成显存里最猛的一头吞金兽。另外GQA分组查询注意力本身已经把 KV 头的数量压得很低了。同样层数的模型如果用的是 MHA多头注意力而不是 GQAKV Cache 还要翻好几倍。所以选模型的时候优先选带 GQA 结构的这也是低显存玩家选型的一条隐性规则。2.3 第三笔账推理引擎的额外开销最后一类是很多人根本想不到的。无论你用 llama.cpp、Ollama 还是 vLLM只要调了 CUDA就要先给 CUDA Context 留一块固定开销通常 200MB 到 400MB 不等。再算上 KV Cache 的分配器页、计算中间结果的缓冲、生成时的 beam/search 缓存零零总总又吃掉几百 MB。这些不是某个模型的问题是任何 CUDA 程序都要交的入场费。三笔账加到一起我最初的 OOM 就完全说得通了权重 5.9GB KV Cache 0.6GB 引擎开销 0.4GB约等于 6.9GB超出了 6GB 物理显存。而同样的模型优化之后变成权重 1.8GB 量化 KV Cache 0.2GB 引擎开销 0.5GB大约 2.5GB加上分配器预留实测 2.7GB。这就是整个故事的技术基础。3. 压到 2.7GB 的四步组合拳3.1 第一拳Q4_K_M 量化权重从 5.9GB 打到 1.8GB这一步没有悬念我选了 GGUF 格式的 Q4_K_M 量化。为什么不是 GPTQ 或者 AWQ一句话生态成熟度。GPTQ 和 AWQ 通常配 vLLM、Text Generation Inference 这类服务化推理引擎性能上限更高但部署和调参成本高对 6GB 显存这种边缘配置不算友好。GGUF 是 llama.cpp 阵营的格式工具链完整、上手快还能通过其自带的 OpenAI 兼容接口直接对接各种智能体框架。对自养 Agent 来说快速迭代比极限吞吐更重要。量化等级方面Q4_K_M 是 4-bit 量化里口碑非常稳的一个档位。它把大部分张量压到 4-bit但关键的 attention 权重保留 6-bit 精度属于省显存和保质量之间不那么心疼的折中。我试过更激进的 Q4_0显存还能再省一两百 MB但工具调用时输出格式的稳定性明显变差我也试过 Q5_K_M质量更好但显存多了 300 多 MB。综合下来 Q4_K_M 是最平衡的选择。量化档位权重体积工具调用格式稳定性体感速度BF165.9GB最好最快Q5_K_M约 2.2GB良好快Q4_K_M约 1.8GB良好偶有格式漂移快Q4_0约 1.6GB一般需要重试兜底快实际操作很简单从模型仓库把官方 BF16 权重拉下来用 llama.cpp 的转换脚本转成 GGUF再跑一次量化命令。整个过程十几分钟跑完之后再看那个 5.9GB 的文件你会觉得之前的 OOM 特别不值得。3.2 第二拳KV Cache 量化把动态开销砍一半量化权重只解决了静态部分KV Cache 这个动态大头必须单独处理。我用的方法是 llama.cpp 的 KV Cache 量化参数把 Key 和 Value 的缓存从 FP16 压到 8-bit。实测下来8K 上下文场景的 KV Cache 从约 0.3GB 降到约 0.15GB16K 场景从 0.6GB 降到 0.3GB。有人会担心 KV Cache 压到 8-bit 影响生成质量。我在 Agent 场景里跑了上百轮工具调用验证结论是短上下文8K 以内几乎无感长上下文16K 往上会有轻微退化但配合第三拳的上下文管理策略影响基本可以忽略。背后的原理也不复杂KV Cache 存的是注意力计算需要的中间表示它的数值范围相对稳定8-bit 量化对它的精度损失远没有权重量化那么敏感。这是性价比非常高的一项优化属于白捡的显存。3.3 第三拳上下文窗口管理Agent 会话历史的滑动窗口这一拳最容易被忽略但其实是 Agent 场景的胜负手。很多人看到支持 16K 上下文就放心了结果 KV Cache 又悄悄涨回去。Agent 跑工具调用的时候系统提示词、工具定义、历次工具返回、模型中间推理全堆在上下文里16K 根本不够用但显存又放不下更大的 KV Cache。这时候你要做的不是硬塞而是管理。我的做法是双管齐下。第一在推理引擎层把上下文窗口锁死在 8K从物理上限上控制 KV Cache 的尺寸第二在智能体框架层做一个类似滑动窗口的会话管理只保留最近几轮的用户请求和工具结果更早的历史做一次摘要压缩再塞回上下文。也就是说模型手里始终握着最近最相关的信息而不是把完整历史一字不差地背着。这个宏观滑动窗口的思路和模型原生滑动窗口注意力是同一个哲学。如果你的模型原生支持滑动窗口注意力Mistral 那类架构推理引擎会自动控制历史范围那当然更好。如果不支持框架层的截断和摘要也完全够用关键是要设计好摘要策略——工具返回的关键结果不能被压缩丢否则模型会在下一步推理中失忆。3.4 第四拳顺带解答 MoE 架构的一个高频疑问整理热搜词的时候我看到有人问MoE 架构要全部参数进显存吗这问题跟低显存推理关系很大我顺便说说。MoE混合专家模型的特点是每一层有一堆专家子网络但单个 Token 只会激活其中少数几个。所以在推理时理论上只需要把当前被激活的专家权重放在显存里其余专家可以放在内存用到再换进来。llama.cpp 对这类 offload 策略有专门支持社区里也有人这么跑大 MoE 模型。也就是说MoE 模型的显存压力和参数总量之间不是线性关系你完全有可能用一个看起来很大的 MoE 文件却只占一小块显存。不过这是另一个话题了。我手头这个模型是 Dense 结构靠量化就把显存压下来了如果你用的是 MoE 模型别急着被文件大小劝退先查一下推理引擎支不支持专家 offload很可能有意想不到的收获。4. 实际配置、启动命令与显存实测4.1 启动命令与关键参数我的环境是llama.cpp 的 server 程序配合一个跑在本地容器里的智能体框架框架通过 OpenAI 兼容接口调用模型。核心启动参数如下./llama-server \ -m /models/agent-3b-instruct-Q4_K_M.gguf \ --ctx-size 8192 \ --n-gpu-layers 99 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --parallel 1 \ --jinja逐个解释我为什么这么设--ctx-size 8192锁死上下文上限防止 Agent 任务把 KV Cache 撑爆。记住llama.cpp 的 KV Cache 是按 ctx-size 预先分配的设多大就占多大无脑拉大会直接浪费显存。--n-gpu-layers 99把能上 GPU 的层全部上 GPU。这个 3B 模型层数不多99 就是全量 offload量化后权重就那么点体积没必要留 CPU 层拖慢速度。--cache-type-k/v q8_0KV Cache 量化第二拳的落地点。--parallel 1单请求并发。自养 Agent 一个人用不需要并行关掉可以省下并发队列的显存。--jinja强制启用模型自带的 Jinja 聊天模板确保 function calling 的格式正确。如果你用 Ollama同样的事情可以通过 Modelfile 里的参数实现比如设置num_ctx、num_gpu和 KV Cache 量化参数原理是一样的。4.2 nvidia-smi 实测数据启动之后我盯着 nvidia-smi 的进程列表看了好一会儿心里的预期是 2.8GB 左右。实际起来之后的数据如下项目数值模型文件BF16 原始5.9GB量化后权重Q4_K_M约 1.75GBKV Cache8K 上下文 8-bit 量化约 0.2GBCUDA Context 与推理缓冲约 0.45GB分配器页与运行时预留约 0.3GB实测总显存占用2.7GB也就是说显存占用从最初的 6GB 直接 OOM降到了 2.7GB 稳定运行。跑一个典型的 Agent 任务用户提问、模型判断要调工具、工具返回结果、模型总结时显存基本维持在 2.5GB 到 2.7GB 这个区间不会继续往上爬。这就是标题里5.9GB 模型只占 2.7GB 显存的来源——是实测数字不是估算。这里多说一句如果你同时还要跑 ComfyUI 这类同样吃显存的工具建议提前给它们预留显存别让两个进程互相抢。做法可以是给 Agent 的启动命令加上环境变量限制显存池大小或者干脆错峰使用。4.3 三个我踩过的坑坑一Embedding 模型偷偷抢显存。我最初在同一个容器里挂了 RAG 用的一个小 Embedding 模型结果它默默吃掉了 400MB 显存。Agent 一跑长任务就 OOM排查了好久才发现是这个不起眼的小家伙在捣乱。后来我把 Embedding 模型换成了纯 CPU 推理的小模型显存压力立刻缓解。记住Agent 系统里不只有主模型所有组件的显存都要盘一遍。坑二上下文超限时的静默失败。有一次我设置了 8K 上下文但框架把工具返回结果原样塞回去会话长度悄悄超过了 8K。结果模型开始忘记最早的指令工具调用格式也乱了。排查到最后才发现是上下文截断策略没生效。这个问题的本质是低显存环境里上下文管理不是可选项而是必选项。一定要在框架里显式配置历史摘要或滑动窗口逻辑并且在日志里打上当前 token 数超限就告警。坑三量化后忘了重测 function calling。换成 Q4_K_M 之后我拿着之前的测试集直接跑偶尔会出现模型多输出一个多余参数、或者把 JSON 格式写错的情况。不是不能用但每几十轮就会有几轮需要框架重试。后来我在系统提示词里明确加了严格输出 JSON 格式不要出现多余解释的约束再配合最大重试次数稳定了很多。量化省了显存但模型的指令遵循能力多少会打点折扣这个要有心理预期并做好兜底设计。5. 2.7GB 显存跑 Agent效果与速度的真相5.1 工具调用能力实测显存压下来之后最核心的问题变成这到底是一个能用的 Agent还是一个只能跑 demo 的玩具我用了两个维度验证一个是预置的工具调用测试集一个是连续跑一周真实任务。测试集里覆盖了计算日期、调用计算器、从本地文件读数据、按关键词搜索笔记这几类工具。Q4_K_M 量化之后工具调用的格式正确率和 BF16 相比掉了大概两个百分点。体感上常规的单工具调用基本没问题偶尔遇到模型需要在一句话里连续调用多个工具的复杂场景会多一次重试。说实话这个代价完全可以接受。一周的真实任务包括每天早上汇总备忘录里的待办事项按优先级排序输出收到一个新文件路径时自动读取并提取摘要写入指定的笔记文档每隔一段时间对某个目录下的 CSV 数据做一次简单统计把结果整理成表格整体完成率九成以上剩下的失败基本都和外部请求超时有关跟模型本身关系不大。5.2 速度数据与实际体感低显存环境里速度永远绕不开。实测生成速度在我的 6GB 显卡上大约是 25 token/s 到 35 token/s取决于上下文长度和是否处于工具调用循环中。25 token/s 是什么概念普通的你问我答体感很流畅甚至觉得挺快。但 Agent 任务不一样它的时间开销主要体现在循环上模型输出工具调用请求框架执行工具把结果塞回上下文模型继续推理。每一步都要重新处理前缀所以哪怕单 token 速度不错整个任务的墙钟时间还是会被拉长。我测了一个查资料并总结的完整任务从发起请求到最终答案大约需要 20 到 40 秒。自己用完全够但如果你想拿它做对外服务、接受并发请求那还是老实上更大的显存或者换更好的卡这条路没有捷径。5.3 低显存 Agent 适合干什么以这几天的体验我给低显存 Agent 划了一条线。适合的场景个人知识库问答、日程管理、轻量数据处理、代码片段生成、涉及隐私需要本机处理的内部工具。这类任务的特点是单次上下文可控、工具调用次数不多、对延迟容忍度较高。不适合的场景高并发的对外服务、长文档多轮深度推理上下文一长 KV Cache 就压不住、对延迟敏感的实时交互。这类任务继续用云端能力更合理没必要为难自己这张小卡。有意思的是低显存环境反而逼着我养成了一个更健康的 Agent 使用习惯原来习惯把大而全的任务一次性丢给模型现在我会先把任务拆小让 Agent 分步处理中间结果。这种拆任务的思路其实正是 Agent 开发里更推荐的编排方式——让模型专注于小决策而不是试图一口气吃掉整个复杂任务。6. 给同样在显存边缘挣扎的朋友我的建议与后续计划6.1 什么时候该量化什么时候不该如果模型对工具调用的输出格式有极其严格的要求而且你的显存刚好能放下 BF16 权重我建议先把 BF16 版本跑通整个 Agent 流程再逐步压精度。量化带来的格式漂移在 Agent 场景会被放大因为任何一步输出格式错误整条工具调用链就断了。反过来如果你的显存差那么临门一脚优先试 Q4_K_M 而不是直接降到 Q4_0。Q4_K_M 多占的那点显存换来的是指令遵循能力的明显提升在 Agent 场景里非常值得。6.2 显存不够时的排查顺序我这一周踩坑踩出来的排查顺序可以做成一个通用清单先看权重占了多少。做量化到 Q4_K_M 这个级别这是最直接的减负手段。再看 KV Cache。锁上下文长度、做 KV Cache 量化、检查会话历史是不是在无限膨胀。然后查引擎开销。关掉不需要的并行、精简加载的周边组件比如把 Embedding 模型移到 CPU。最后才考虑换更小的模型。换模型是降维打击付出的代价是能力下降应该放到最后再考虑。这套顺序的原理很简单先解决固定的权重再解决动态的KV Cache然后清理隐形的引擎和周边组件最后才削减能力的模型本身。很多人一上来就换小模型其实把量化这块最大的红利白白浪费了。6.3 后面我打算怎么继续压目前 2.7GB 距离 6GB 上限还有 3GB 多的余量足够我再折腾一轮。第一个方向是把之前移到 CPU 的小 Embedding 模型换回 GPU 跑给检索模块提速预计占用 300MB 左右完全在预算内。第二个方向是试更激进的 KV Cache 4-bit 量化如果 16K 上下文能用 3GB 以内跑下来就意味着同一张显卡上可以同时跑一个 Agent 和一个辅助的摘要模型上下文管理的自由度会大很多。最后聊聊我个人的体会。低显存玩家做 Agent拼的不是堆硬件而是把每个字节的显存都安排明白。这个思路放到更大的显卡上同样成立——显存这东西永远不嫌多提前掌握这套精打细算的方法以后换了新卡只会跑得更从容。如果你也在用 6GB 或者 8GB 的卡折腾 Agent卡在 OOM 上不知道怎么下手希望这篇日志能帮你少走几个弯。