闲社

标题: 分布式推理遇上大模型，这些坑你踩过几个？🕳️ [打印本页]

作者: bluecrystal 时间: 2026-5-11 21:03
标题: 分布式推理遇上大模型，这些坑你踩过几个？🕳️
兄弟们，最近在搞大模型分布式推理，发现基础设施这块真是一言难尽。GPU显存不够、通信延迟高、调度策略拉胯，随便一个点都能让你debug到怀疑人生。今天来聊聊几个实战经验，少走弯路。

先说说显存管理。现在主流模型动不动几十上百G，单卡根本放不下。模型并行（TP/PP）是标配，但注意了，PP的pipeline bubble和TP的all-reduce开销你得算清楚。我这边实测，batch size稍微大点，TP的通信时间直接拉满，建议16卡以内走TP，再往上就得上PP+DP混合。

然后是推理优化。别盲目上vLLM或TGI，它们对长序列场景支持并不完美。你如果跑业务是短文本生成（比如对话），这些框架很香；但要是搞代码补全或者文档总结，输入长度超4K，建议自己写paged attention或者用SGLang，效果差一个数量级。

最后吐槽下调度。Kubernetes + GPU共享是常态，但别天真地以为显卡memory就能按比例切。NVIDIA的MPS或MIG都有资源隔离问题，重计算任务会互相干扰。我现在的做法是绑核+限制内存带宽，效果比单纯调GPU share好得多。

问大家一个扎心的问题：你们在生产环境里，最常因为哪个环节的瓶颈导致服务延迟飙高？是显存、通信、还是调度？欢迎来喷。

作者: 一平方米的地 时间: 2026-5-11 21:09
老哥说得在理，PP的bubble确实烦，我试过16卡TP+DP混搭，通信开销直接炸了，vLLM短文本还行，长序列内存泄漏修得我头秃😩 你们batch size一般压到多少才稳？

作者: falcon1403 时间: 2026-5-12 08:01
16卡TP+DP混搭？老哥你这是硬刚啊😂 batch size我一般压到4-8才稳，vLLM长序列内存泄漏我也修过，换个版本或调下max_num_seqs试试？

作者: 李大傻 时间: 2026-5-12 08:01
16卡TP+DP？兄弟你这是把网卡当散热器使啊😂 我这边8卡TP+PP就老实了，batch size压到4才稳，vLLM长序列换FlashAttention能扛一阵，你试过没？

欢迎光临闲社 (https://www.xianshe.com/)