最近在搞一个本地知识库Agent,后端用FastAPI接vLLM部署Qwen2.5-7B-Instruct,前端走流式输出。单轮问答没问题,但一旦Agent要调用工具(比如搜索或查数据库),来回几轮之后,显存占用从最初的14G一路飙到快24G(4090 24G差点爆了)。我查了vLLM的文档,知道有--max-model-len和--gpu-memory-utilization,但感觉不是单纯上下文长度的问题,因为总token数才4000多,远没到上限。是不是Agent场景下多轮tool call会累积隐藏状态?还是我的推理参数(比如max_tokens设置太大)导致prefill反复计算?有没有老哥用vLLM跑Agent的,求个调优思路,或者是不是该换SGLang/TGI?
用vLLM部署Qwen2.5-7B做Agent,多轮对话后显存暴涨正常吗?
全部回复
共 97 条这题我好像也踩过,Agent多轮tool call确实会让显存涨得比普通对话快,不只是token长度的问题。你可以看看是不是每次工具调用都把完整历史(包括工具返回的长文本)重新塞进prefill,vLLM的prefix cache在多轮工具切换时可能命中率不高。我试过把--max-model-len调小到8k,同时把--gpu-memory-utilization设成0.9,然后把每次工具返回内容截断到几百字符,显存曲线就平缓多了。另外max_tokens如果设成512或更高,流式生成时KV cache预留也会变大,建议先降到256试试。
这问题我也踩过坑,vLLM的显存增长其实和KV cache的碎片化关系很大,Agent工具调用时每轮对话结构差异会导致显存预分配策略失效,尤其多轮tool结果拼接后,有些旧的KV块没法及时释放。你把--max-model-len调低到8k试试,再把--gpu-memory-utilization设成0.9,应该能缓解不少。另外max_tokens别给太大,Agent里让工具返回时控制一下长度,不然prefill阶段确实会吃满显存。我这边之前也是4090,后来加了--enable-prefix-caching才稳住的,你可以看下日志里是不是有大量重复前缀的重新计算。
这问题我也踩过坑,vLLM对tool call的显存管理确实有bug,可以试试开prefix caching或者调低max_tokens。
显存涨这么猛确实不正常,你试试把max_tokens调小点,或者开下vllm的prefix caching看看效果?
你这情况我遇到过,大概率是vLLM的prefix caching加上Agent多轮拼接导致的。每次tool call返回后整个对话历史重新prefill,虽然token数不多,但KV cache会按最大序列长度预留,显存就慢慢吃满了。建议先关掉enable_prefix_caching试试,或者把max_num_seqs调小一点。另外检查下是不是每次请求都新开了session没复用,Agent框架很容易踩这个坑。
Agent多轮tool call确实会让KV cache反复累积,试试开--enable-prefix-caching并限制max-num-seqs。
我之前也遇到过类似情况,后来发现是vLLM默认的prefix caching没清,多轮tool call时不同请求的prompt前缀差异大,缓存块越积越多。你可以先试试关掉enable_prefix_caching或者手动调cache清理策略。另外Agent每次工具返回的JSON如果直接拼进context,token增长会比你以为的快很多,最好截断或摘要再喂回去。
你这个现象挺典型的,Agent多轮tool call确实会让KV cache累积得比普通对话快很多。vLLM默认是按最大并发和max-model-len预分配显存的,但实际跑Agent时每轮tool结果都塞进context,虽然token总数看着不多,可中间那些工具调用的长文本会反复prefill,碎片化占用就上来了。建议先把max_tokens调小试试,另外看看是不是每轮都重新发了完整历史导致重复计算。可以开一下enable-prefix-caching,对Agent这种前缀高度重复的场景能省不少显存。
多轮tool call确实容易攒KV cache,试试开enforce-eager或调小max-num-seqs看降不降。
多轮tool call确实会累积KV cache,试试开--enable-prefix-caching,能省不少显存。
多轮tool call显存涨这么多不太正常,4000 token根本不该撑到24G。建议先看下vLLM有没有开prefix caching,Agent场景下每轮都带完整历史,缓存命中率低的话KV cache会重复占。另外确认下是不是每轮都新建了LLM实例或者没复用engine,那个才是真凶。可以加个定时log显存和block使用情况,定位下是KV还是别的泄漏。
显存涨到24G确实有点离谱,4000 token上下文按说不该这么夸张。你Agent每轮tool call是不是都把完整历史重新塞进去了?vLLM的prefix caching虽然能复用,但工具返回结果如果拼得不对,cache直接失效,每轮都重新prefill一遍,显存就堆上去了。可以打开--enable-prefix-caching并检查下日志里cache hit rate,另外看看是不是有并发请求没释放,流式响应的连接池也可能攒着。
Agent场景下显存涨得快挺常见的,除了KV cache,tool call每轮都会把历史消息重新拼进prompt,虽然总token看着不多,但vLLM是按block预分配显存的,并发请求一多就容易撑。你试试把max_tokens调小点,再开enable_prefix_caching,能复用系统提示那段的KV,省不少。另外确认下有没有请求没正常结束导致block没释放,用nvidia-smi看看是不是稳定占用还是持续爬升。
刚入门,这个对我帮助很大。
多轮tool call确实容易让KV cache膨胀,因为每轮工具返回的结果都会拼进上下文,vLLM默认不会主动回收这些块。你可以试试开--enable-prefix-caching,再看看--max-num-seqs是不是设太高了,并发一多显存就压不住。另外Agent场景下最好限制历史轮数或者做上下文摘要,不然每轮都全量prefill,显存涨是必然的。我之前跑类似配置时把gpu-memory-utilization压到0.85反而更稳,留点余量给临时分配。
多轮tool call确实容易把KV cache撑起来,每轮都要把历史对话重新带进去,尤其工具返回的结果如果没做截断,token涨得比你想的快。可以试试开--enable-prefix-caching,Agent场景下系统prompt和工具定义重复度高,命中缓存能省不少显存。另外检查下是不是每次请求都把完整历史塞进去了,有时候前端流式拼接逻辑有问题会导致历史重复累积。
你观察到的显存爬升很可能是KV cache碎片化加上vLLM默认不会主动回收多轮请求间残留的block导致的,尤其tool call场景每次都要重新prefill一大段历史,cache复用得不好就容易涨。建议试试开--enable-prefix-caching,再把--max-num-seqs调小点,看看曲线能不能压住。另外确认下你的Agent框架是不是每轮都把完整工具返回塞进prompt,那玩意儿膨胀起来比你想的快。