Prefill 与 Decode 分工：前段卡算力后段卡带宽

缓存怎么用，答案是把一次生成劈成两半。 上回理清了 KV Cache 的存法，接着就是加载和更新。一次生成正好拆成两段，一段叫 Prefill，一段叫 Decode，一个建存储，一个更新存储。 Prefill 吃的是整个 prompt，长度 T。T 个位置的 K/V 一口气全写进去，这活只干一次。动作是大矩阵乘法，瓶颈压在算力上。 Decode 完全不同。每生成一个 token 走一轮，只碰一个新位置，历史的 K/V 却要整批读出来，然后再把新位置接上。动作换成了小矩阵，瓶颈挪到了读权重和读缓存的带宽上。 这两段的分工让我看东西的角度变了。以前我觉得推理慢就是算力不够，现在明白前段卡在算力、后段卡在带宽，瓶颈会换地方，优化的招也得跟着换。 这解释了不少现象。为什么长 prompt 首字出得慢，是 Prefill 在啃；为什么输出越到后面越吃显存带宽，是 Decode 每步都要翻全部历史。买显卡时算力和带宽哪个更要紧，得看自家负载偏哪一段。 保留的地方是，我只读到理论还没实测。Prefill 和 Decode 的实际占比随任务变化很大，短问答和长文档场景肯定不是一回事。 下一步我会用手头的推理框架压一条长文档请求，看两段各占多少时间。数字出来，才知道该优先加算力还是换更宽的带宽。