上个月我终于把自养Agent的算力从云端API换成本地部署理由是日志、对话记录和工具调用过程都留在自己手里不用再担心隐私和限流。当时手头只有一块6GB显存的RTX 3050而目标模型文件足有5.9GB。折腾两天之后模型不但跑起来了nvidia-smi里显示的主模型显存占用只有2.7GB。这篇日志就是想把这个过程完整记录下来为什么5.9GB的模型不一定要占5.9GB显存怎么把大模型塞进小显存以及自养Agent这种场景到底能从“低显存运行模型”里得到什么。我假设读这篇日志的你可能跟我一样手头没有A100但也想跑一个本地Agent不想为每次工具调用付API钱。那么这篇内容很适合你。如果你已经有3090这类大显存卡也可以看一眼因为“模型文件大小”和“运行显存占用”之间并不是一回事理解了之后调起参来会更有的放矢。1. 项目背景一台旧机器和它要养活的Agent1.1 我所谓“自养Agent”到底在跑什么先交代一下我这边Agent的构成。我的自养Agent不是简单套一个Chat接口完事它要完成三件事理解用户的自然语言指令、规划要不要调用工具、把工具返回结果组织成最终回复。所以Agent主进程旁边还挂了两个常驻小模型一个用来做文本向量化把每轮对话和工具文档都转成向量存进本地知识库另一个用来做语音转文字方便我偶尔用语音发指令。主模型、向量模型、语音模型这三个东西要同时在一台机器上活下来显存分配就成了硬约束。最开始我想的是“反正模型文件是5.9GB这张6GB卡应该刚好放下”。结果第一次启动就给我表演了一次OOM那个报错现在想起来都觉得丢人。后来我把主模型压到2.7GB显存之后整台机器的显存占用大概是主模型2.7GB向量模型0.4GB语音模型0.5GB加上系统桌面和浏览器占用整体还有一小半余量。这体验比我想象中舒服太多。这里要说明白5.9GB是模型文件在磁盘上的大小不是模型“原始”权重的大小。我用的是一个7B参数级别的开源Dense模型它的FP16原始权重大概是13到16GB磁盘上那个5.9GB文件是经过GGUF量化之后的版本具体量化档位是Q5_K_M。这个量化档位在质量与体积之间比较平衡也是很多人跑本地模型的首选。模型格式文件体积约说明FP16/BF16原始权重13-16GB精度最高显存压力最大Q8_07-8GB损失极小文件还是偏大Q5_K_M5.9GB左右我用的档位质量损失很小Q4_K_M4.3-5GB更小但复杂任务偶有掉点所以不要一看到“5.9GB的模型”就默认它是原始大小。量化这件事本质上是把模型里每个权重参数用更少的bit去存就像一张照片从无损PNG转成高质量JPG肉眼看不太出来但文件确实小很多。1.2 为什么不能把5.9GB全塞进显存很多人有一个朴素念头模型文件5.9GB那运行时不就得占5.9GB显存吗如果显卡是6GB那不是刚好能放下吗我刚入坑时也这么想然后被现实教育了一顿。原因很简单模型推理时显存里不只有权重。权重之外还有KV Cache、临时激活值、CUDA上下文、碎片整理余量这些东西加起来往往有好几百MB甚至1GB以上。我用6GB卡跑这个5.9GB的Q5_K_M模型如果全部层都塞进GPU权重本身就是5.9GB还没等推理KV Cache一申请直接就“CUDA error: out of memory”了。所以核心问题不是“能不能放下”而是“需要在显存里放多少”。推理引擎完全可以只把一部分层放到GPU另一部分层扔给CPU跑。这让“文件有5.9GB显存只占2.7GB”成为可能2.7GB意味着模型权重并没有全部进入显存大约只有一部分层真正跑在GPU上剩下的层由CPU和内存接住。这个方案的代价是速度变慢但对我这个自养Agent场景来说速度慢到某个程度以内其实无所谓。Agent不是高频实时对话它更多时候是在后台分析任务、调工具、写摘要可以容忍每秒几个token的生成速度。省下显存给另外那两个小模型反而更重要。2. 显存到底被模型吃了多少5.9GB文件如何变成2.7GB占用2.1 从两个维度看显存权重、KV Cache与激活值要搞清楚2.7GB是怎么来的得先拆一下模型运行时的显存去哪了。拿我这个7B模型、4K上下文、Q5_K_M量化来举例主要开销有四大块。第一块是模型权重。Q5_K_M量化后所有层权重加起来约5.9GB这部分如果全部放进显存就等于磁盘文件大小。这是最直观的一块也是绝大多数人以为“模型占显存”的唯一一块。第二块是KV Cache。Transformer模型在生成每个token时要把历史token的Key和Value缓存下来方便后续注意力计算。这个缓存的大小跟层数、注意力头数、上下文长度直接相关。7B模型在4K上下文下FP16的KV Cache通常在400MB到800MB之间如果开了GQA分组查询注意力会小一些。关键点是KV Cache可以量化。我用q8_0量化KV Cache之后这部分体积再砍一半4K上下文下可能只剩200MB上下。第三块是激活值。推理过程中每一层的中间结果都要暂存这个跟batch size和seq len有关。好在现代推理引擎大多支持FlashAttention它能把注意力计算的中间矩阵压得很小我实际把FlashAttention打开后激活值带来的显存压力可以忽略不计。第四块是CUDA上下文和运行库开销。只要你调用GPUCUDA都会预占一部分显存llama.cpp这类引擎通常吃300MB左右vLLM这种更重的框架可能吃更多。这块省不掉但也不能无视。把这些加在一起就明白为什么6GB不够了权重5.9GB KV Cache 0.2GB CUDA 0.3GB已经超出6GB。就算运气好勉强启动一长对话或者并发一高直接爆。所以必须让一部分权重“不进显存”。2.2 核心思路让GPU和CPU合伙推理llama.cpp这类GGUF推理引擎有一个关键参数叫--n-gpu-layers可以理解成“把模型的前多少层放到GPU上跑”。实操里经常缩写为-ngl或者-ngl。这个参数直接决定权重的分配比例如果总共有28层你设置-ngl 12那么GPU就只负责前12层剩下16层由CPU接管。为什么不是从最后几层开始放这跟模型的推理结构有关。自回归模型生成时是从前到后逐层计算所以前几层放GPU能覆盖最频繁的数据搬运路径。llama.cpp默认就是按层序从头开始放实测效率也最高。我用一个不严谨但好理解的类比GPU是效率高的老员工CPU是实习生。模型是一个28步的流水线。如果你把前12步都交给老员工后16步交给实习生速度会慢但活能干完。反过来如果把中间的某几段拆开穿插分配数据搬运次数反而变多整体更慢。所以最简单可靠的做法就是连续分配前N层。这里还要强调不是模型文件多大就必须让权重全部进显存。进显存的比例由-ngl决定文件大小只决定“如果全部进显存会占多少”。2.7GB这个数字本质上就是“12层权重 KV Cache CUDA上下文 激活值”加在一起的结果。2.3 一组对照数据不同分层下显存和速度的权衡为了找到2.7GB这个甜点我做了几轮测试把结果整理成一张表。测试环境是RTX 3050 6GBCPU是i5-12490F内存32GB上下文固定为4096KV Cache量化开启。-ngl设置显存占用生成速度能不能跑99全部进GPU启动即OOM无不能20约3.6GB约11 token/s能但会挤压其他模型14约3.0GB约8.5 token/s能余量一般12约2.7GB约7.2 token/s能余量充足8约2.2GB约5.1 token/s能速度偏低你可以看到从14层降到12层显存只省了0.3GB速度降了1个多token/s。从12层再降到8层显存又省0.5GB但速度掉到了5 token/s左右这个速度对Agent来说已经开始有点难受了。所以我最后选了12层既保证主模型余量又给同机的向量模型和语音模型留了位置。有一个细节容易踩坑不同引擎打印的“offloaded层数”可能口径不一致。llama.cpp启动日志里会写offloaded 12/28 layers这句话才是准的。别只看命令行传了什么参数要以日志为准。后面我会专门说日志这块。3. 实操过程从“默认加载爆显存”到“稳定占2.7GB”的调参记录3.1 第一轮直接全量加载翻车现场第一次启动时我没想太多直接把所有层丢给GPU命令长这样llama-server \ -m /models/qwen2.5-7b-instruct-q5_k_m.gguf \ -ngl 99 \ -c 4096 \ --host 127.0.0.1 \ --port 8080结果启动日志还没刷几行就出现了经典的分配失败ggml_cuda_allocate_buffer: CUDA error: out of memory当时我第一反应是“模型文件不是5.9GB吗6GB卡怎么不够”然后看了眼nvidia-smi发现CUDA已经预占了300多MB再加上KV Cache剩余显存根本填不满全部权重。这种时候硬调-ngl 99没有任何意义。翻车之后我学乖了不再凭感觉猜而是先看日志、再逐步压参数。这也是我后来反复强调的一个习惯——显存问题不能拍脑袋要看日志说话。3.2 第二轮二分法试层数找到2.7GB甜点定位显存问题的标准做法是先把上下文调小、KV Cache量化关掉用最小配置把模型跑起来再逐步加回去。因为如果一开始就叠加太多变量出了问题根本不知道是哪一项导致的。我建议按这个顺序来第一步先确认模型能不能启动。把-ngl设成16上下文降到2048不开FlashAttention先看整体吞吐和显存基线。 第二步再把上下文拉回4096打开KV Cache量化观察显存增量。 第三步逐个加层数每加2层看一次nvidia-smi直到出现OOM或逼近你的显存预算。 第四步确定层数后调整其他参数让显存踩在你的目标值附近。我最开始从16层开始试显存约3.3GB。随后加FlashAttention稍微降了一点。接着把KV Cache从FP16改成q8_0显存又掉了约0.2GB。然后我减到14层显存约3.0GB再减到12层就得到2.7GB。整个过程不超过二十分钟因为每次重启服务只需要一次参数变更。最终稳定运行的服务启动命令如下llama-server \ -m /models/qwen2.5-7b-instruct-q5_k_m.gguf \ -ngl 12 \ -c 4096 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --flash-attn \ --host 127.0.0.1 \ --port 8080这里有几个参数值得说明。--cache-type-k和--cache-type-v是KV Cache量化开关把它们设成q8_0能在几乎不掉效果的情况下把KV Cache体积减半。如果你的显存更紧张还可以试试q4_0效果损失会稍微明显一点但胜在更小。--flash-attn是FlashAttention开关RTX 3050是Ampere架构支持得很好如果你是Turing架构如GTX 16系可能不支持需要关掉。启动后llama-server日志里会出现类似下面这样的关键行load_tensors: offloaded 12/28 layers to GPU看到这句话说明你的层数配置真的生效了不是只看命令行参数。3.3 第三轮Agent全家桶一起跑显存还够用主模型稳定在2.7GB之后我把Agent系统的其他组件也都拉起来。向量模型我用的是一个384维的embedding模型显存占用约0.4GB语音转文字模块用了whisper的小型版本占用约0.5GB。三个进程叠加整体显存大约3.6GB在6GB卡上还有差不多2GB余量。可能有人会问既然还有余量为什么不把主模型多放几层到GPU跑快一点这个问题我也想了一下。Agent有一个特点它的峰值负载不可控。用户可能在主模型还在生成的时候突然让语音模型处理一段长录音或者让向量模型批量索引几十个文档。如果主模型把显存吃到5GB其他任务一来就很容易把显存打满。留出2GB余量是给“Agent多任务并发”上保险。另一个不太容易发现的收益是显存占用低意味着掉到CPU上的层多功耗和发热也低。我的机器长期挂机跑Agent之前全量加载模型时风扇一直狂转现在降到2.7GB之后GPU温度低了差不多8度。这对需要7x24小时运行的本地Agent来说很重要。4. 日志设施与排查别让Agent变成一个“黑盒”4.1 给Agent配一套日志落地方案说到自养Agent很多人只顾着调模型参数“日志设施”四个字完全没放在心上。但我的体会是Agent只要跑上几天你一定会想翻日志。它半夜调了什么工具、为什么突然卡住、某个任务的输入输出长什么样这些信息全都得靠日志才能回答。我目前的做法是把Agent主进程和三个模型服务全部托管在systemd下日志统一落盘。下面是其中一个服务的unit配置片段[Service] ExecStart/home/agent/run_agent.sh WorkingDirectory/home/agent Restartalways StandardOutputappend:/var/log/agent/agent.log StandardErrorappend:/var/log/agent/agent.log这里的关键是StandardOutput和StandardError都指向同一个文件这样程序的所有输出都留在了同一个日志里。别小看这件事之前我遇到过一个问题Agent主进程在凌晨调工具失败但因为没把stdout收集起来第二天完全找不到原因。加了落盘之后随便用journalctl -u agent --since today或者tail -f /var/log/agent/agent.log就能回溯现场。我还建议给日志加logrotate轮转防止日志文件无限膨胀。Agent跑业务的时候日志增长很快尤其是打开了调试级别输出的话一天几百MB都不奇怪。我的配置是每天切割一次保留7天超过就自动删除。这样即使日志写得多也不会把磁盘挤爆。4.2 排查显存问题时到底要看哪些日志自养Agent最麻烦的一类问题就是显存相关。这类问题有一个特点现象经常是“服务挂了”或“响应特别慢”但原因藏在底层日志里。如果你不养成看日志的习惯就只能反复重启永远不知道根因。我自己总结了一套排查顺序。第一步看GPU实时状态命令是nvidia-smi。如果连续盯几秒能看出显存和利用率有没有异常波动。第二步看模型服务的启动日志重点找offloaded和CUDA error这两个词。第三步看系统日志确认有没有OOM killer把进程杀掉这通常是整机内存不足的锅跟显存没有直接关系。这里有一个真实踩过的坑我一开始只看Agent主进程日志觉得调工具正常但服务还是时不时卡住。后来才发现竟然是语音模型进程的batch size设得太大导致显存吃紧触发了系统内存换页。那个问题在Agent日志里完全看不出来只有看了nvidia-smi和语音模型自己的日志才发现。Agent是个系统不是单个模型排查时一定要把所有组件的日志都纳入视野。现象先看哪条日志可能原因处理方向启动报CUDA out of memoryllama-server启动日志权重全部或过多进显存降低-ngl、开KV量化运行中显存缓慢上涨nvidia-smi Agent日志上下文长度无上限限制-c、加KV量化输出速度突然下降systemd日志CPU承担层数过多提升-ngl或减小并发进程被莫名杀掉dmesg journalctl整机内存OOM关掉部分小模型或加swap日志文件无限膨胀logrotate状态没配轮转策略配置日志切割与清理这个表格里的每一条我基本都亲历过。尤其“输出速度突然下降”这条经常被误以为是网络问题其实只是某层被换到CPU之后负载不均。看日志能看到具体是哪个进程占了资源省去很多瞎猜。4.3 Agent日志的“关键时刻”记录除了常规日志我还给Agent加了一个小功能每次工具调用前后都往日志里写一条结构化记录包括调用时间、工具名、输入参数摘要和输出结果摘要。这东西单独拎出来说是因为它对我调参帮助极大。比如有一次我发现Agent在检索知识库时特别慢从Agent日志一看好家伙它同一轮对话里连续调了8次向量检索每次都把几千个文档片段拼进上下文。这根本不是模型能力问题而是提示词里没有限定“先查一次不够再查”。修了提示词之后速度立刻恢复。没有这些关键日志我只能靠猜是模型太笨还是向量库太大其实都不是。5. 从2.7GB出发自养Agent这条路还能怎么省5.1 再往下压的三个方向如果你看完前面内容也想把显存压得更狠那还有三个方向可以继续。一是换更低的量化档位。把Q5_K_M换成Q4_K_M文件会从5.9GB降到4.3GB左右全部层进显存的压力更小相同层数下显存占用也会明显下降。代价是模型在生成长文本、数学计算这类任务上偶发掉点。对Agent工具调用场景来说掉点通常可以接受但如果Agent要做复杂代码推理我还是建议留在Q5_K_M。二是量化KV Cache更激进。我目前用的是q8_0如果换q4_0KV Cache还能再小一半。上下文比较长的时候比如-c 8192这个收益会更明显。但KV Cache量化太狠会让模型在长上下文下产生更多遗忘需要根据实际效果权衡。三是缩小上下文长度。Agent场景的常规对话其实不太需要8192这种长上下文大多数任务在2048到4096之间就够用了。上下文缩短KV Cache大幅缩小显存又能省下几百MB。这个方向是最便宜的优化但要注意如果你经常让Agent处理长文档就别盲目砍上下文否则功能会明显退化。5.2 两个更进阶的优化思路自养Agent跟单模型部署有一个隐藏区别Agent里面通常可以拆出多个“小模型”协作。我的下一步计划是加一个“意图路由”层用一个几百MB的小模型判断用户当前是想闲聊、查资料还是调用工具。如果只是闲聊就把它分流给更小更快的模型如果是调工具再让主模型接手。这样大部分时间主模型甚至可以“休眠”显存占用会更低。另一个思路是把Agent的每个模型按“常驻优先级”分开。主模型用2.7GB常驻向量模型用0.4GB常驻语音模型按需加载。如果语音使用频率不高可以让它在空闲时退出显存等有音频输入再加载。这个做法虽然会让语音唤醒多等一两秒但对显存紧张的机器非常友好。我的经验是自养Agent的显存优化不是把一个模型压到极限而是把所有模型放在一起统一调度。写到这里我其实想强调的是5.9GB模型只占2.7GB显存这件事并不是什么魔法也不是牺牲巨大性能换来的畸形方案。它就是一个分层调度、KV Cache量化和日志排查结合的正常结果。如果你也在自养Agent我建议你把“模型文件多大”和“显存该占多大”当成两件事来对待先从日志里看清楚offloaded层数再一步步调。这样踩坑会少很多。