两阶段拆开之后资源各归各位
一次生成分两个阶段：预填充阶段把整段提示词一次算完并建立缓存，特点是算力密集、每次处理大量 token；解码阶段逐步产出后续 token，特点是反复读取缓存、带宽密集。两阶段对硬件的要求不同，混在同一实例里会互相等待。分离部署把它们放到不同实例上，各自按自己的瓶颈扩缩容，中间通过缓存的跨实例传输衔接，代价是链路变长、调度变复杂。
基本信息
| 拆分对象 | 预填充实例与解码实例，可各自独立扩缩容 |
|---|---|
| 衔接机制 | 缓存跨实例传输与两级调度 |
| 适用规模 | 请求量大、阶段特征差异明显的大规模服务 |
| 实现参考 | 推理引擎的分离式服务方案与相应调度组件 |
| 运维成本 | 显著高于单体部署，需要独立的容量与故障管理 |
典型使用场景
- 长提示词为主：预填充占比高，单独扩容算力型实例更划算
- 长输出为主：解码占比高，带宽型实例的配比可以单独调整
- 两类流量混合：同一集群里同时有长文摘要与短问答，阶段配比差异大
- 资源配比失衡：单体部署时总有一侧资源闲置，拆分后各取所需
- 大规模弹性：按阶段分别扩缩容，避免整体放大或整体收缩
形态示意
形态示意
请求 → 调度器 → 预填充实例（算力型）
↓ 缓存传输
解码实例（带宽型）→ 流式返回
关键观察点：
- 缓存传输的耗时是否抵消了拆分收益
- 两侧实例数量比例是否随流量结构变化
- 某一侧实例故障时请求能否被重新调度两阶段特征对比
| 维度 | 预填充 | 解码 |
|---|---|---|
| 主要瓶颈 | 算力与显存带宽 | 显存带宽与缓存容量 |
| 单次处理量 | 整段提示词一次算完 | 逐个 token 推进 |
| 扩容方式 | 增加算力型实例 | 增加带宽型与缓存容量 |
| 尾延迟敏感度 | 影响首字延迟 | 影响用户看到文字的速度 |
| 故障影响 | 新请求无法开始 | 进行中的生成中断 |
复杂度和运维成本高于单体部署：没有明确的资源配比失衡或相互干扰问题时，先不要拆开，拆分本身的收益常常小于新增的调度与传输开销。
小规模集群上拆分往往得不偿失：实例数量少时两侧都跑不满，链路却多了一跳，故障面反而扩大。