Agent 显存需求怎样测：用上下文、并发和模型做容量实验

Agent 显存需求要在固定模型、精度和推理运行时下做容量实验，再逐步增加上下文和并发。仅看模型文件大小，无法判断实际任务能否稳定运行；首字时间与完整答复时间也必须分开。这篇帮助私有化项目确定测试口径，不给所有模型套用一张显存配置表。

先冻结能够重做的基线

记录设备型号与数量、驱动、推理运行时版本、模型标识、量化或精度、上下文设置、输出限制和加载方式。还要说明同一设备是否运行嵌入、重排或其他服务。没有这些信息，同一个“显存占用”数字很难比较，也不能解释为什么客户环境与演示环境不同。

合成实验以制度问答为例，准备短条款、较长制度和多段检索材料三类输入。正文内容固定，问题保持同一业务目标，不要在扩大上下文时顺便换成更容易回答的任务。输出要求固定为依据、结论和不足项，避免生成长度差异掩盖输入变化。

下载显存容量实验记录表，包含三条待执行的合成实验行。表中的上下文与并发是实验变量，实际取值由项目设定，未填任何性能结果。填写时区分请求接受、开始推理、首字和完整结束几个时间点。

先测单请求短上下文，确认模型已正确加载且结果符合要求；随后增加输入长度，观察资源占用、首字等待和失败；再固定输入提高并发。若同时换模型、扩大上下文又增加请求，很难确定瓶颈来自哪一项。

输入长度应按运行时实际处理口径记录，不能把中文字符数直接当成token数。还要记录检索上下文是否被截断、系统提示与历史对话是否包含在内。业务问答可能持续多轮，若只测第一轮短问题，得到的容量结论会遗漏后续累积的上下文。

Ollama 官方FAQ说明上下文设置和实际加载状态都可查看。若采用该运行时，应核对目标版本的相关设置，并记录模型是完全在GPU还是部分在CPU。部分卸载可能使任务继续运行，却改变响应时间，因此不能只用“没有报错”判断容量足够。

排队时间反映请求等待资源的情况；首字时间影响交互体验；完整返回时间取决于生成内容与速度；总任务时间还可能包括检索和工具调用。GPU实验重点记录推理阶段，但要保留端到端关联编号，避免把数据库或外部接口延迟算到显存不足上。

冷启动和预热分别记录。模型首次加载可能产生明显等待，服务长期运行时又可能因为其他任务被卸载。若业务有间歇使用场景，应把重新加载纳入体验验证，而不是只演示模型已经在设备上的连续请求。

资源记录不仅有峰值，还应包括稳定状态、请求结束后是否释放、错误日志和同设备其他进程。出现显存不足时保存失败样本与参数，不要不断重试直到偶然成功，然后只保留成功结果。容量边界恰恰需要失败证据支持。

扩大上下文后模型可能截掉关键依据；为了容纳并发而缩短输出，也可能漏掉重要限制。每轮用同一业务检查表核对来源、条件和禁止动作。资源占用下降但回答不完整，不应被算作优化通过。若选择更小模型，也要重新验证工具与结构输出能力。

合成问题“设备能否外借”在材料中有例外审批条件，预期答案必须保留这一条件。长上下文实验如果只答“可以”，即使速度很好仍然失败。这样的业务检查可防止容量讨论只剩硬件数字，忽视最终工作结果。

报告写清已验证的模型、输入分布、并发范围、输出要求与可接受等待，再指出资源不足、排队增加或质量下降从哪里开始出现。采购预留由业务增长和系统共享情况决定，不在没有负载资料时给统一倍数。也可以比较限制并发、缩小任务与增加资源几种方案的影响。

若设备上还会运行OCR或嵌入任务，应安排混合负载验证；若只测了模型服务，明确其他部分未覆盖。正式部署后用实际运行记录修正容量，不把一次实验当成永久保证。模型、运行时或上下文策略变化后，要重新执行受影响的实验。

部署背景可看私有化部署说明，知识库任务见内部知识库专题。若需要制定容量验证范围，可在联系入口提供设备信息、目标模型和脱敏任务，讨论实验设计与结果判定。