部署本地大模型做Agent，模型一直卡死怎么排查？

先看vLLM日志里有没有重复的prefill，八成是Agent历史消息没截断，把max_model_len调小到2048试试。

你这配置我熟，Qwen2.5-7B用vLLM跑Agent，max_model_len设4096其实不算大，但关键是tool调用时历史消息全塞进context，每次都重新算KV cache，显存自然就爆了。建议先开vLLM的--enable-prefix-caching，再把Agent的memory改成只保留最近几轮对话，别全量传。排查的话，直接看vLLM日志里有没有OOM报错，或者用nvidia-smi盯一下显存曲线，如果每次tool调用前显存突变，那就是上下文问题；如果平稳但卡死，大概率是LangChain的循环逻辑里有死锁或工具返回格式没解析对。我之前也卡过，最后发现是工具返回的json里带了个特殊字符导致解析循环，折腾了一晚上。

遇到过，大概率就是历史对话太长把kv cache撑爆了。你max_model_len设4096看着不大，但vLLM默认会预分配显存，加上Agent每轮tool结果都塞进上下文，7B模型推理速度也会肉眼可见地掉。建议先用短对话测几个tool调用，把max_model_len降到2048看看还卡不卡，同时开vLLM的--enable-prefix-caching试试。另外可以打个日志，看卡死时到底是显存OOM还是CPU占用飙高，如果显存没满但响应慢，那多半是Agent循环里没用trim_history，把旧消息无限累积了。

这问题我熟，之前调Qwen的时候也撞上过类似的坑。你先把vLLM的日志打开看一眼，如果卡死前有“Input length exceeded”或者显存分配失败的报错，那基本就是上下文撑爆了，max_model_len=4096看着不大，但Agent每轮tool调用返回的结果加进去，几轮下来就逼近上限了，而且vLLM的显存预分配是按最大长度来的，不是按实际token数，所以哪怕历史没到4096也可能OOM。我建议先用一个固定短任务，把tool调用次数压到两三次，跑通了再逐步加轮次，这样能快速判断是不是Agent循环的问题。另外你检查下LangChain那边是不是把完整的对话历史全塞进去了，很多教程会忽略这一步，实际得自己做截断，只保留最近几轮，不然模型要处理的量是线性增长的。还有个笨办法，在每次tool调用前打印一下当前token数和显存占用，定位到具体是哪一步爆的，比瞎猜快多了。至于Agent逻辑写崩，我一般看响应是否还有规律，如果卡死前模型还在输出但越来越慢，多半是推理侧积压，如果直接无响应，那更可能是代码死循环或者工具调用没返回。你先试试把max_model_len降到2048，顺便开一下vLLM的--enable-prefix-caching，这个对重复前缀的缓存优化很明显，能省不少显存。

八成是历史对话没截断，vLLM的KV cache把显存吃满了，先查下prompt长度再决定要不要做滑动窗口。

这问题我太熟了，之前用7B模型跑Agent也踩过同样的坑。你vLLM设的max_model_len才4096，但Agent每次循环都会把历史消息、工具返回结果全塞进上下文，几个来回就顶满了，显存肯定爆。建议先把max_model_len砍到2048甚至1024试试，同时把LangChain的memory改成只保留最近几轮对话，别让历史无限累积。另外注意vLLM的continuous batching，如果同时有别的请求占显存，也会加剧OOM，确认下是不是单请求独占。排查逻辑问题有个笨办法，在工具调用前后打时间戳和显存占用日志，如果卡在模型生成阶段就是推理问题，卡在工具执行中间就是Agent代码死循环或者等待超时。还有个小细节，Qwen2.5的chat template有时候会跟LangChain的message格式冲突，导致重复生成特殊token，也会让响应越来越慢，可以检查下输出里有没有异常字符。

八成是Agent循环没截断历史，vLLM的KV cache越滚越大，试试把max_model_len调小或者手动清上下文。

先查一下vLLM的日志，看是不是有kv cache的报错，max_model_len 4096对7B来说不算大，但如果你Agent循环里每次都把完整历史塞进去，累积几轮下来实际token数很容易超，而且vLLM的prefill会吃满显存。我之前遇到过类似情况，最后是给对话历史加了裁剪，只保留最近几轮加个摘要，OOM就少多了。另外你可以在LangChain里给每个tool call加个超时和重试，卡死有时候是工具本身没返回，不是模型问题。先单独跑一个固定prompt的tool调用试试，排除Agent逻辑干扰，这样能定位到底是推理还是循环卡住。

先看下vLLM日志里有没有OOM关键字，没有的话大概率是Agent把历史塞进prompt了，建议把对话轮次截断试试。

八成是历史对话撑爆了，vLLM的KV cache本来就吃显存，试试把max_model_len调小或者手动截断几轮对话。

我之前跑类似场景也卡死过，最后发现是vLLM的prefill阶段把显存吃满了，max_model_len调到2048加上限制并发请求数就稳了。另外Agent循环里最好手动截断历史消息，只保留最近几轮对话，不然每次tool返回结果都塞进上下文，迟早爆掉。你先盯一下vLLM的日志和显存监控，区分是推理还是逻辑问题，如果OOM前有报错就是模型那边，要是响应变慢但显存没满，大概率是Agent里死循环或tool调用卡住了。

八成是历史对话越攒越多，vLLM的KV cache把显存吃满了，先给Agent加个对话裁剪试试。

我之前也踩过这坑，光看max_model_len没用，实际跑起来显存翻倍涨，把tool调用历史截断到最近几轮就稳了。

我之前跑类似的Agent也踩过这坑，vLLM其实对长上下文挺敏感的，max_model_len设4096但实际对话历史加上工具返回很容易超，建议先开下vllm的日志看有没有报context length exceeded，另外试试把历史消息做个截断或摘要再喂给模型，能省不少显存。至于Agent逻辑，可以单独写个脚本固定输入几轮tool结果，看模型还卡不卡，这样能快速排除是不是LangChain那边循环出问题。OOM的话也可以考虑把gpu_memory_utilization调低点，留些余量给推理缓存，别让KV cache吃满。

这问题我踩过坑，大概率是Agent循环把历史消息全塞进prompt了，vLLM的KV cache会随上下文长度暴涨，4096窗口看着不长但多轮tool结果拼接起来很容易爆。你先在Agent里把对话历史截断，只保留最近几轮，再看看显存曲线是不是还直线上升。另外vLLM有个–enable-prefix-caching参数可以开一下，能复用公共前缀的KV，对tool调用场景帮助挺大。如果还卡，就用–gpu-memory-utilization调低点，留出余量给推理峰值。

八成是Agent循环没截断历史，vLLM的KV cache越滚越大，先查下每次tool call后的消息列表长度吧。

日志里看下卡死前最后一次tool返回啥，多半是上下文爆了，把max_model_len调小点或者手动裁剪历史试试。

大概率就是context爆了，Qwen2.5-7B在vLLM下max_model_len设4096其实挺吃紧的，Agent每轮tool调用都会把历史+中间结果塞进prompt，几轮下来轻松超限。建议先把max_model_len降到2048，然后给LangChain加个显式的对话裁剪或摘要，别让历史无限涨。另外可以开vLLM的--enable-prefix-caching，能省不少显存。排查上，你看下卡死时vLLM的日志，如果报CUDA OOM那就是显存问题，如果没报错但响应慢，大概率是Agent循环里某个tool调用卡住了，比如网络请求没超时。我之前用类似配置跑多工具也遇到过，把tool调用的超时时间设短点，比调模型参数管用。

先看下是不是max_model_len乘上batch把显存吃满了，我遇到过类似情况，把并发调成1试试。

另外Agent循环里最好手动裁剪历史消息，不然上下文越滚越长，vLLM的显存碎片化也会卡死。

我之前跑Mistral-7B接Function Call也遇到过一模一样的现象，最后定位下来就是Agent循环里把历史消息全塞进prompt了。vLLM的max_model_len设4096看着够用，但Qwen2.5-7B实际推理时KV cache膨胀得比想象快，特别是tool调用返回的JSON一长，几个来回就顶到显存上限。建议你先在vLLM的日志里看下每个请求的prompt token数和显存占用曲线，别光盯着max_model_len，实际峰值往往比预期高30%左右。另外你试试把LangChain的memory改成只保留最近两轮对话，或者用摘要压缩历史，我这么改完基本就不卡了。至于定位问题，你可以在Agent每次tool调用前打印当前token数和显存快照，如果发现某个tool返回后显存突然飙高，那就是上下文爆炸；如果显存正常但响应变慢，大概率是vLLM的调度或者并发设置有问题，可以看看是不是max_num_seqs开太小了导致排队。还有一个坑，Qwen的tool call格式有时候会触发模型无限生成，你检查下stop token有没有设对，不然它会一直吐空白字符直到超时。先按这几个方向排查吧，大概率是上下文管理的问题，不是Agent逻辑崩了。

八成是历史对话把context撑满了，vLLM的KV cache直接炸，先看下max_model_len和实际token数。

我之前也踩过类似的坑，vLLM跑7B其实挺容易在长上下文上翻车的，max_model_len设4096看着不大，但Agent每轮tool调用都会把历史塞进去，几轮下来KV cache就能吃掉好几个G，OOM很正常。建议你先用nvidia-smi盯一下显存曲线，如果卡死前显存涨到接近上限，基本就是上下文问题，要么调低max_model_len到2048，要么在LangChain里给对话历史加个裁剪或摘要，别无限堆。另外也检查下是不是Agent里某个tool的返回结果特别长，比如网页抓取或日志读取，那才是真正的元凶，可以先手动跑一遍每个tool看耗时和内存，排除逻辑死循环的可能性。