Prefill、Cache、Sample 与 Train

时钟周期解释请求什么时候被调度执行，本文解释一次请求的远端计算花在哪里。一次典型的「采样 + 训练」循环中，远端 GPU 时间可以拆成 prefill、sample、train 三类；prefilling cache 是服务端对 prefill 的复用优化。理解这四个概念后，可以更准确地估算任务成本、定位性能瓶颈。

与时钟周期一样，这些概念描述的是服务端的计算行为，不对应某个具体的 SDK 参数。具体计费口径以模型列表为准。

一条流水线上的四类计算

一次典型的 agentic RL 迭代包含以下阶段：

Prefill：模型处理整条 prompt，构建 KV cache，为生成第一个 token 做准备。
Sample：逐 token 解码，直到产生完整 completion。
本地把轨迹组装成 trio.Datum，提交训练请求。
Train：forward_backward 前向/反向计算梯度，optim_step 应用优化器更新。

prefilling cache 主要出现在 prefill 阶段：当新采样请求的 prompt 前缀已经被计算过，共享部分不再重复计算。

Prefill：处理 prompt

生成第一个 token 之前，模型必须把整条 prompt 完整过一遍，为每个位置建立 KV cache。这一阶段的耗时与 prompt 长度正相关，与后续生成多少 token 无关。

单轮对话中 prefill 占比通常不大。但在多轮 agentic 轨迹中，每一轮的 prompt 都包含此前的完整历史，同一段前缀会被反复 prefill。轨迹越长、轮次越多，重复 prefill 越容易成为主要开销——评估长轨迹任务的预算时，不能只统计进入 loss 的 token。

Prefilling cache：复用前缀的 KV

服务端会保留已计算过的 prompt 前缀 KV。新请求的 prompt 与缓存中的前缀完全一致时，共享部分跳过 prefill，直接从未命中位置继续计算，从而降低首 token 延迟和重复计算开销。

命中的前提是 token 级前缀严格一致：只要开头有一个 token 不同，后面再长的相同内容也无法命中。以下实践都服务于同一个目标——让更多请求共享同一段可缓存的前缀：

多轮 prompt 在真实 sampler 返回的 token 之后追加新内容，不要把历史文本重新 tokenize 再拼接，避免同一文本编码出不同 token 序列。
系统提示词、工具定义等固定内容放在 prompt 最前面，变化的内容放在后面。
同一 group 的多条采样（如 GRPO 的同题候选）共享同一 prompt 前缀，一次 prefill 即可覆盖整组。

prefilling cache 只在采样时生效，且由服务端自动管理，不需要在代码中显式开启。你只需要保证前缀构造方式对缓存友好。以下两种情况不走缓存，prompt 会被完整 prefill：

采样请求设置了 include_prompt_logprobs=True：需要为 prompt 的每个位置计算 logprob，无法复用前缀 KV；
compute_logprobs 请求：同样需要对整条序列重新计算，不命中缓存。

Sample：逐 token 生成

prefill 完成后进入 decode 阶段：模型每步生成一个 token 并追加进 KV cache，直到产出停止符或达到长度上限。这一阶段的成本取决于 completion 的 token 数和采样条数——例如 GRPO 中每个 prompt 的 group size 会直接放大 sample 开销。

采样 API 的用法见推理。

Train：前向、反向与优化器更新

训练阶段由 forward_backward 和 optim_step 组成：前者对整段序列做前向和反向传播、累积梯度，后者应用一次优化器更新。

估算训练开销时要区分两类 token：

进入 loss 的 token：weights 非零的位置，通常是 assistant 生成的部分；
实际参与计算的 token：整段序列。无论某个位置是否计入 loss，前向/反向都要为它付出计算。

训练预算应按后者估算。训练请求在共享 worker pool 上的调度时机，以及如何用流水线填满周期，见时钟周期；训练 API 的用法见训练。

估算成本时分开统计

阶段	由什么触发	规模取决于	优化方向
Prefill	每次采样请求的 prompt 处理	prompt token 数 × 请求数；命中缓存后大幅下降	前缀保持 token 级连续，固定内容前置
Sample	`SamplingClient` 生成 completion	completion token 数 × 采样条数	限制生成长度，选择合理的 group size
Train	`forward_backward` + `optim_step`	序列 token 数 × 批次数	批次流水线，见时钟周期

报告一次训练任务的成本时，建议分开列出 prefill、sample、train 三类 token 的用量，而不是只统计进入 loss 的 assistant token——长轨迹任务中，重复前缀的 prefill 和多条采样的 decode 往往才是开销主体。

关于异步请求的提交时机，请继续阅读异步指南。