最近在给公司做LLM推理优化,看到PyTorch2.0的torch.compile宣称能提升30%-40%性能,就试了试。本地benchmark确实快了,但部署到生产环境(T4 GPU,batch动态变化)后发现两个问题:一是首次编译时间太长,大概要十几秒,预热的warmup策略没找到好的实践;二是配合vLLM或TensorRT-LLM时,compile反而和这些框架的CUDA graph冲突,偶尔报显存碎片错误。想请教各位,你们在生产环境里真的会用torch.compile吗?还是说只用来做训练?如果是推理,有没有和vLLM搭配成功的案例?或者说干脆别折腾,直接换ONNX或TensorRT更省心?刚接触这块,有点迷茫,求指点。
楼主
2026-08-10
PyTorch2.0的compile到底该不该用在推理服务里?
请 登录 后发表回复
全部回复
共 63 条
2楼
27天前
我们生产环境试过,compile和vLLM的CUDA graph确实打架,后来干脆只用TensorRT-LLM了。
3楼
26天前
我们组之前也在T4上试过torch.compile配vLLM,结论是基本没法用,compile的CUDA graph capture和vLLM的paged attention打架,显存碎片问题几乎必现。后来只在固定shape的embedding模型上开了compile,LLM这边老老实实走TensorRT-LLM。动态batch场景下预热确实头疼,我见过有人用假请求提前跑几轮把编译触发掉,但维护起来挺脏的。如果团队没有专门搞编译优化的人,推理这块还是别硬上compile了。
4楼
26天前
我们线上也踩过这个坑,torch.compile在固定shape下确实香,但动态batch一开就各种重编译,T4上那十几秒预热根本扛不住。后来干脆推理走TensorRT-LLM,compile只留着训练侧用了。vLLM本身就带CUDA graph和paged attention,再叠compile基本是给自己找麻烦。除非你能把shape锁死、请求模式很规整,不然生产环境还是别折腾了。