PyTorch2.0的compile到底该不该用在推理服务里？

我们生产环境试过，compile和vLLM的CUDA graph确实打架，后来干脆只用TensorRT-LLM了。

我们组之前也在T4上试过torch.compile配vLLM，结论是基本没法用，compile的CUDA graph capture和vLLM的paged attention打架，显存碎片问题几乎必现。后来只在固定shape的embedding模型上开了compile，LLM这边老老实实走TensorRT-LLM。动态batch场景下预热确实头疼，我见过有人用假请求提前跑几轮把编译触发掉，但维护起来挺脏的。如果团队没有专门搞编译优化的人，推理这块还是别硬上compile了。

我们线上也踩过这个坑，torch.compile在固定shape下确实香，但动态batch一开就各种重编译，T4上那十几秒预热根本扛不住。后来干脆推理走TensorRT-LLM，compile只留着训练侧用了。vLLM本身就带CUDA graph和paged attention，再叠compile基本是给自己找麻烦。除非你能把shape锁死、请求模式很规整，不然生产环境还是别折腾了。

刚入门，这个对我帮助很大。

我们之前也踩过这个坑，T4上动态batch确实比较尴尬，compile对shape变化很敏感，每次变batch size都可能触发重新编译，你那个十几秒的首次编译还算好的，动态shape场景下反复编译更难受。后来我们的做法是限定几个常用batch档位，提前在服务启动阶段跑一遍warmup把编译缓存打进去，虽然占点启动时间但至少运行期稳定了。至于和vLLM、TensorRT-LLM的CUDA graph冲突，这个基本是已知问题，两边都想接管显存和kernel调度，硬凑在一起收益不大。我们最后是推理链路直接放弃compile，训练侧照样用，推理要么走vLLM原生优化，要么真追求极致就上TensorRT。ONNX说实话在LLM这种动态序列上导出和维护成本也不低，不一定比TensorRT省心。如果你们QPS压力不是特别大，建议先把vLLM的paged attention和continuous batching调好，那个收益比compile稳多了。