最近在折腾MCP(Model Context Protocol)工具服务器,把几个本地推理模型封装成了MCP server,用PyTorch做后端。客户端是多轮对话,每轮都会调一次工具,但跑几轮之后请求就超时了,日志里显示“tool call timeout”。我看了下,单次推理明明很快(1-2秒),但累计到第3、4轮就开始卡死。怀疑是不是PyTorch的显存/线程没释放干净,或者MCP的session状态没处理好?还是说MCP本身就不适合这种高频、有状态的推理场景?求有经验的大佬指点下,换gRPC或者直接REST会不会更稳?
楼主
8天前
MCP服务器在PyTorch里跑多轮推理总超时,是配置问题还是框架限制?
请 登录 后发表回复
全部回复
共 2 条
2楼
2天前
先看看是不是PyTorch线程数没限住,多轮下来线程越堆越多就卡了。
3楼
2天前
这个现象我也遇到过,大概率不是MCP本身不适合有状态推理,而是PyTorch后端在长连接会话里没管好资源。你可以先查一下是不是每次tool call都新建了推理上下文或autograd graph,没手动清掉的话显存会一点点涨上去,到第三四轮正好触发OOM前的卡顿。另外MCP的session如果默认走的是同步阻塞调用,客户端多轮并发时容易把线程池占满,表现就是单次快但累计超时。我之前把推理部分改成常驻进程加请求队列,每次只传输入和拿输出,超时就没了。gRPC或REST不一定更稳,关键看你能不能把模型生命周期和会话生命周期解耦。建议先跑个监控看显存和线程数随轮次的变化,比直接换协议靠谱。