最近在折腾MCP(Model Context Protocol),想把它接到我们现有的PyTorch训练流程里,主要是想让外部工具能动态调用模型推理接口,避免每次都要重启服务。
但看了一圈文档和开源项目,发现有人用JSON-RPC直接封装,也有人用gRPC做传输层,还有直接改FastAPI的。我有点懵——MCP本身不是规定了消息格式和交互流程吗?那传输层是不是可以随便换?还是说必须严格走SDK默认的stdio/HTTP?另外,如果模型服务是分布式的(比如多卡推理),MCP这边需要自己做负载均衡吗,还是框架层面(比如Ray Serve)能直接兼容?
希望各位大佬给点实际经验,别只丢论文链接,谢谢!
楼主
2026-08-04
MCP和深度学习框架结合,到底该怎么选协议?
请 登录 后发表回复
全部回复
共 124 条
2楼
5天前
我之前也遇到过类似问题,后来换了方案。
3楼
4天前
学到了,感谢分享!
4楼
1天前
MCP 本身确实只定义了消息格式和交互语义,传输层是可以换的,SDK 默认的 stdio/HTTP 只是参考实现,不是强制绑定。我们之前也是 PyTorch 训练流程里要动态调推理,试过 JSON-RPC 裸封装,短平快但错误处理和流式响应得自己补;后来换 gRPC 做传输,主要是看中双向流和多路复用,跟 MCP 的 message 层其实不冲突,就是得自己写个 adapter 把 MCP 的 request/response 映射到 proto 上。FastAPI 那条路适合已有 HTTP 服务想低成本接进来,但要注意 MCP 的会话状态和工具发现流程别被 REST 的无状态习惯带偏。分布式多卡这块,MCP 协议层不该背负载均衡的锅,它更像是一个工具调用的路由约定,真正做副本调度还是交给 Ray Serve 或 KServe 这类框架,MCP 端只要保证请求能打到正确的 endpoint 就行。不过有个坑提醒下,如果走 stdio 做本地进程通信,多卡场景下子进程管理和日志聚合会比较难受,建议优先考虑 HTTP/gRPC 传输。你们现在推理接口是单进程还是已经有 serve 层了?这个会直接影响选型。
5楼
11小时前
传输层随便换,MCP只管消息语义,我们直接gRPC封的。分布式那块交给Ray Serve就行,别自己造轮子。