本地部署Agent需要多少显存？主流轻量级模型硬件要求分析

“模型文件才4GB，怎么一跑Agent就爆显存？”这是很多刚接触本地大模型的朋友常遇到的困惑。问题往往出在把下载的文件大小当成了程序运行时的全部占用。聊天界面能启动，但一旦接上搜索工具、多聊几轮，资源需求就会悄然变化。

先别急着换显卡，检查这四件事：具体的模型标签、量化格式、上下文长度，以及显卡还剩多少专用显存。下面以Windows上的Ollama为例，用权重估算筛选模型，再看实际加载情况；注意，这里的估算不是跑分，也不是最低配置保证，而是帮你建立合理的心理预期。

先算权重，别把这张表当成整机需求

稠密模型的理想权重大小可以粗算为“参数量×每个参数位数÷8”。这里的7B、13B分别按70亿、130亿参数计算，GB统一指十亿字节。

理论权重与实际下载大小的差异示意

这是假设全部权重都用相同位数保存的数学结果。实际量化文件还有量化信息，部分模块可能保留其他精度；运行时又要放入上下文缓存和计算缓冲区，不能据此认定“4GB显卡就能全速跑7B”。

模型名称里的“7B”也可能是近似叫法。例如Ollama库中的qwen2.5:7b实际标注7.62B、Q4_K_M，下载大小约4.7GB，已经高于表里的理想3.5GB。Q4_K_M也不等于把每个参数简单压成四个位，它包含更复杂的分组量化策略，以平衡精度与体积。

先选小模型，把一次工具调用跑通

个人电脑第一次搭Agent，可以先看带工具调用能力的小型指令模型。例如qwen3:4b-instruct在模型库中标注Q4_K_M、约2.5GB；qwen2.5:7b约4.7GB，可作为资源允许时的另一个候选。这里比较的是下载规模，不能从中推导谁回答更准。

显存紧张时，先用4B候选做一个短输入、单工具的流程，再判断是否需要换7B。准备跑13B时，先看量化后的实际文件和预期上下文；6.5GB只是理想权重下限，不能直接当作显卡容量要求。

同时检查Ollama对具体显卡的支持。显卡有足够容量，不代表当前驱动和推理后端一定能使用它。普通对话能力也不能代替工具调用能力，Agent还要验证工具名、参数和返回结果是否正确。

Ollama模型库中的模型大小标识

聊几轮就变慢，先收住上下文和并发

Agent会把任务、工具说明、对话与工具返回一起放入上下文。检索结果整页塞回去、历史记录一直追加，都可能增加缓存需求；Ollama的并行请求也会额外分配上下文资源。

如果只验证一个很短的原型，可在PowerShell运行：

ollama run qwen3:4b-instruct

进入交互后输入/set parameter num_ctx 4096，把这次交互的上下文明确设为4096，再做短问题验证。这不是复杂Agent的通用推荐值，也不会自动修改另一个Agent客户端的设置；接入框架后还要核对它实际传入的上下文参数。

先串行处理一个请求，减少无用历史与工具返回，再逐步增加长度。若任务确实需要长文档，就应重新评估内存预算，不能靠删掉必要内容假装硬件已经够用。

在PowerShell中调整上下文长度

到Windows里看，模型究竟放在哪里

按Ctrl+Shift+Esc打开任务管理器，在“性能”中选对应GPU，观察专用GPU内存占用；共享GPU内存来自系统内存，不能和专用显存合在一起当显卡容量。再在另一个PowerShell窗口运行ollama ps。

看输出的PROCESSOR字段：100% GPU表示模型完全放在GPU中，100% CPU表示放在系统内存中，混合比例则说明两边共同承载。CPU模式可以不依赖显存加载模型，但需要足够系统内存，等待时间也要按自己的任务观察，不能仅凭CPU核心数保证速度。

通过任务管理器监控专用显存占用

先记录空闲占用，再跑同一个短任务，随后增加一次真实工具返回，观察资源与等待时间。按“模型量化和大小→上下文→并发→加载位置”的顺序调整；能加载只是第一关，工具调用正确、资源留有余量，才适合继续搭自己的Agent。