把大模型推理拆成两台机器跑,这两年从论文走进了生产线。但真上手的团队很快发现:每加一个新硬件、每换一种量化格式,配置项就多出一维,而这些决定往往各管一摊,缺一张全局的账。这篇论文想做的,就是把这张账理清楚。 先说为什么要拆。一次推理其实是两段性格相反的活。第一段 prefill 要把你输入的整段提示词一次读进去,并行度高、几乎榨干算力;第二段 decode 是一个字一个字往外吐,每吐一个都要把前文的全部中间状态重新过一遍,卡的是显存带宽而不是算力。放在同一张卡上,总有一段在干等另一段。于是业界的做法是分开:prefill 放性价比高的算力卡,decode 放带宽大的卡,中间那份记录了前文、用来避免逐字重算的 KV 缓存,再跨机器传过去。 拆开容易,协调难。作者把散落的决策收进四条轴:加速器选型、计算精度、互联方式、KV 缓存驻留在哪。真正反复出现的摩擦点有三个:算力具体落在哪一侧、KV 用什么格式表示、以及 KV 到底归谁所有——包括谁负责申请、谁负责释放、出故障了谁来兜底。这三点都骑在 prefill 和 decode 的交界线上,一旦定错,两边就会互相拖累。 最值得拎出来的是精度这条轴。直觉上,一个系统一旦选定 FP8 或 INT8,就该从头用到尾。论文的观察恰好相反:同一种低位格式,放在 prefill 那头缓解的是算力瓶颈,放在 decode 那头缓解的却是带宽和显存占用,两边要解的问题不一样,自然不该由一个全局开关一锤定音。精度应该跟着"角色"走,prefill 一套策略、decode 另一套,交界处再单独管好 KV 传过去时用几位表示。 这不是一篇刷榜论文。作者把结论建立在工业部署的实际观察和对推理框架源码的逐行走读上,而不是一组对比实验,所以文里几乎看不到"提速百分之多少"的数字。它给的另一个判断是:prefill 和 decode 之间可能的交叉影响很多,但真正会变成硬约束、非协调不可的只是其中一小撮,其余大多可以各自独立决定,这等于告诉工程师别把每一维都当成必须联调的死结。 放到更大的背景看,过去一年推理这块的热闹几乎都在单点上:某个量化把显存砍到几分之一,某个调度把延迟压到几毫秒。这篇偏偏往回退了一步,不加新招,而是给已经堆起来的这堆招数排了个座次,说清哪些必须一起调、哪些可以分头管。对手里已经有一套 prefill-decode 分离集群、正被配置项淹没的团队,它的价值不在跑分,而在于把"该协调什么"从一团乱麻里挑出来。论文自己也留了两处交界暂时没下定论;至于换到混合专家 MoE、超长上下文这些新形态下这套划分还稳不稳,更是没展开,得后面的人接着填。