AstraFlow: Dataflow-Oriented Reinforcement Learning for Agentic LLMs

Paper: arXiv:2605.15565 Code: Infini-AI-Lab/astraflow Code reference: main @ 93517ce0 (2026-05-25)

1. Motivation (研究动机)

当前 agentic LLM 的 RL 训练不只是“把 rollout 和 training 拆到不同 GPU 上”这么简单。推理、代码、搜索、工具调用、AgentBench 环境交互等任务会产生长尾 rollout、不同角色 policy、跨服务 reward / verifier、以及动态数据筛选；如果系统仍由 trainer 的单一同步循环来控制，rollout 调度、数据选择、replay、staleness 处理和 weight sync 都会被塞进 trainer 侧逻辑，新增一个能力就要改一套系统代码。

这篇论文要解决的具体问题是：如何把 agentic RL 的 rollout execution、data management、trainer optimization 和 weight transfer 变成稳定、可替换、可组合的系统边界，使同一套 RL 系统原生支持 multi-policy collaborative training、elastic rollout pool、heterogeneous / cross-region rollout、以及可插拔 data algorithms。

这个问题值得研究，是因为 agentic RL 的成本瓶颈往往来自系统耦合，而不只来自 policy-gradient 算法本身。若系统能把 rollout service 当作服务、把 dataflow layer 当作控制面、把 trainer 当作独立消费者，就能在不重写 trainer / RaaS / orchestration 的情况下复用同一套训练系统：数学任务可做 Solver + Verifier，代码任务可做 Solver + Selector / Test-Case Generator，跨地域 rollout 可通过 sparse delta transfer 遮蔽慢链路，数据算法可在 dataflow 层组合。

2. Idea (核心思想)

核心 insight 是：agentic RL 的 disaggregation 不应只分离计算位置，还要分离控制责任。AstraFlow 把传统 trainer-centered control loop 改成 dataflow-oriented coordination：RaaS、dataflow layer、trainer 各自运行 autonomous control loop，只通过最小的 data interface 和 weight interface 协调。

关键创新可以概括为三层抽象：Dataflow layer 负责 rollout task / trajectory / training batch 的路由与策略化数据处理；Rollout-as-a-Service (RaaS) 把 trajectory generation 封装成可热插拔服务；Trainer abstraction 只消费 batch、优化 policy、发布权重。由此，multi-policy 协作、runtime scaling、cross-region rollout、GRESO / dynamic sampling / replay 等都变成 dataflow policy 或服务拓扑变化，而不是 trainer 内部 if-else。

与 AReaL / SLIME / verl 这类主要以“rollout-training disaggregation / fully async training”为中心的框架相比，AstraFlow 的根本差异是把数据路由、rollout 服务和 weight transfer 也提升为一等抽象。与 Dr. MAS 相比，它不为特定 multi-agent workflow 定制系统逻辑，而是让不同角色 policy 通过 metadata、model_id 和 dataflow routing 共享同一个系统接口。

3. Method (方法)

3.1 Overall framework：三组件 dataflow-oriented RL

Figure 1 解读：图中最重要的变化是控制中心不再是 trainer。RaaS 负责产生 trajectories，dataflow layer 接收 trajectories、维护 fresh / replay buffer、执行 data policies 并向 trainer 提供 batches；trainer 完成优化后只把新权重发布到 weight interface。多 policy 场景下，每个 policy 可以拥有独立 trainer 和 weight stream，但它们通过同一个 dataflow layer 交换带 metadata 的 trajectory / reward / version 信息。

直觉上，AstraFlow 有效的原因是把“慢、异步、长尾”的部分放在服务侧和 dataflow 侧，把“需要稳定优化语义”的部分留给 trainer。这样 trainer 不必知道某条 trajectory 来自哪个远程 rollout pool、是否经过 replay、是否被 verifier 拒绝、或者 weight 是 full sync 还是 delta pull；它只看到一个 streaming training corpus。这种隔离让系统可以在 runtime 改 rollout pool、替换 RaaS、组合数据算法，而不破坏 optimizer 后端。

论文没有提出新的 policy-gradient loss；RL optimizer 使用 M2PO / PPO-style backend，贡献在系统抽象与数据/权重流。实验配置中常见目标项是 M2PO 的 group-level reward normalization、batch-level advantage normalization、固定 KL penalty $10^{-3}$，以及 $m^2$ threshold；这些数字来自 released repo 的具体 YAML（例如 examples/math-multi-agent/qwen3-8b-actor-verifier-m2po-delta-no-ds-dapo-data/yaml/experiment.yaml），不是 base defaults。

3.2 Dataflow layer：数据算法接口 + 组件控制面

Figure 2 解读：Dataflow layer 的输入是 rollout tasks / prompts、RaaS 返回的 trajectories、reward / verifier 结果、以及 model version metadata；输出是 trainer-ready batches。图中的关键是 buffer 和 policy hooks：同一个数据通道可以先做 pre-rollout prompt selection，再做 post-rollout filtering，最后在 serving batch 时混入 replay samples。

Dataflow layer 有两个角色。第一，它是 programmable data-algorithm interface：selective rollout、curriculum scheduling、post-rollout filtering、dynamic sampling、replay、data mixing、staleness correction 都可以作为 dataflow policy 插入，而不修改 trainer 或 RaaS。第二，它是 data-driven control plane：根据 data availability、reward statistics、policy id、model version、timestamp、task type 等 metadata，决定哪些 rollout tasks、trajectories、batches 发给哪个组件。

released code 中，astraflow/dataflow/astraflow.py 把 acquisition 和 serving 组合成 AstraFlow；AstraDataAcquisition 从 rollout dataloader / RaaS 收集结果并构造 metadata；AstraDataServing 用 RolloutBuffer 管 fresh samples 与 replay storage；buffer_filters.py 中 FilterZeroAdvFilter 会丢弃 zero_adv == 1 的样本；replay_selectors.py 暴露 replay selection registry。这个实现与论文描述一致：trainer 只通过 HTTP client 请求 batch，dataflow 内部处理 filter / replay / staleness。

def dataflow_tick(rollout_service, serving, dataloader, *, filter_fn, replay_ratio, current_version):
    # acquisition side: submit prompts and ingest structured rollout results
    prompts = next(dataloader)
    trajectories = rollout_service.generate(prompts)
    for traj in trajectories:
        metadata = {
            "model_id": traj.model_id,
            "version": traj.version,
            "reward": traj.reward,
            "task_type": traj.task_type,
            "zero_adv": traj.zero_adv,
        }
        if filter_fn(metadata):              # KeepAllFilter or FilterZeroAdvFilter
            serving.put(traj.tensors, metadata)
 
    # serving side: trainer sees only a mixed training batch
    batch = serving.get_training_batch(
        model_id=None,
        expected_sample_count=256,
        replay_ratio=replay_ratio,
        current_version=current_version,
    )
    return batch

3.3 Rollout-as-a-Service (RaaS)：把 trajectory generation 变成可替换服务

Figure 3 解读：RaaS 把 agentic rollout 从 trainer 中抽出来。它接收 dataflow layer 分配的 rollout task，使用对应 model weights 和 workflow logic 与环境交互，然后把 trajectory / reward / metadata 返回给 dataflow。由于 RaaS 是服务抽象，多个 RaaS pools 可以并行存在，慢的远程 pool 只会降低自身产出，不会直接卡住 trainer。

RaaS 的直接收益是 hot-swappable 和 elastic。auto-scaling case study 中，dataflow layer 把所有 RaaS instance 视为可互换生产者；外部 agentic maintainer 只根据 balance report 启停 RaaS instance。cross-region case study 中，local / remote / lower-power GPU pools 同时贡献 rollout；trainer 不等待某一个 pool，而是消费 dataflow 层已经准备好的 batches。

3.4 Trainer abstraction 与 sparse weight transfer

Figure 4a–4b 解读：左侧表示 trainer 只做三件事：从 dataflow 取 batch、执行 optimizer step、向 weight interface 发布新版本。右侧表示 RaaS 不是被 trainer 同步推送，而是 pull-based 地选择 full 或 delta 权重更新；周期性 full sync 用来重新对齐，普通 iteration 尽量使用 sparse delta。

released code 的 trainer loop 在 astraflow/train_worker/trainer/ppo_trainer.py 中体现为 get_batch → distribute → train_step → wm.offload → save checkpoint → notify_version。AstraFlowClient 封装 batch / version / stats 的 HTTP 调用。RaaS 侧的 astraflow/raas/server/manager.py 会在 _choose_transfer_mode 中选择 full 或 delta：如果 delta 未 ready、首次 pull、周期性 full sync、或 delta base version 与本地 version 不匹配，则退回 full；否则走 _pull_delta 并把 sparse delta 应用到本地 safetensors。

def astraflow_trainer_loop(client, model, optimizer, weight_manager, total_steps):
    for step in range(total_steps):
        batch = client.get_training_batch(
            model_id=model.model_id,
            expected_sample_count=model.train_batch_size,
            current_version=step,
        )
        batch = distribute_to_fsdp_workers(batch)
        loss = model.train_step(batch, optimizer)
        weight_manager.offload(model.parameters())
        client.notify_version(model_id=model.model_id, version=step + 1)
    return loss
 
 
def choose_transfer_mode(caps, local_version, full_sync_interval):
    if "delta" not in caps["strategies"] or not caps["delta_ready"]:
        return "full"
    if local_version == 0:
        return "full"
    if full_sync_interval > 0 and (local_version + 1) % full_sync_interval == 0:
        return "full"
    if caps["delta_base_version"] != local_version:
        return "full"
    return "delta"

论文公式与 released code 实现差异：论文 appendix 的 Multi-policy Code 设置写的是 $1,000$ training iterations、评测按 $4$ generations/question；但 examples/code-multi-agent/qwen3-8b-codegen-verifier-m2po-full-2node/yaml/experiment.yaml 在 main@93517ce0 中是 trainer_base.total_train_steps: 800，且 lcb_v5 / deepcoder_codeforces 等 eval datasets 的 repeat: 2。另外，论文的 Qwen3-14B auto-scaling / cross-region 实验在 public repo 当前 commit 中没有对应 qwen3-14B launch YAML；这些数字只能从论文 appendix 记录，而不是从 released example config 复现。

3.5 Multi-policy workflows：角色 policy 通过 dataflow 协作

Figure 5a–5c 解读：数学 workflow 是 Solver 先解题，Verifier 接受或拒绝，拒绝时 Solver 根据反馈 retry；代码 Selector workflow 是 Solver 产生两个候选程序，Selector 选择提交；代码 Test-Case Generator workflow 是 Solver 写程序，Test-Case Generator 生成测试，执行失败后 Solver retry。这三种 workflow 的角色差异很大，但系统接口保持不变：不同 model_id 的 rollout 与 trainer 通过 dataflow metadata 连接。

在 released repo 中，数学 multi-policy 示例 examples/math-multi-agent/qwen3-8b-actor-verifier-m2po-delta-no-ds-dapo-data/scripts/run_*.sh 明确把 4 张 GPU 给两个 SGLang RaaS instance，另外 2+2 张 GPU 分给 solver / verifier 两个 FSDP trainer；对应 YAML 使用 Qwen/Qwen3-8B、n_samples=8、max_new_tokens=4096、train_batch_size=256、total_train_steps=1200、lr=5e-6、m2_threshold=0.01、kl_penalty_coef=0.001、ppo_n_minibatches=4、weight_transfer_strategies=delta、delta_full_sync_interval=10。

def multi_policy_actor_verifier(problem, solver_raas, verifier_raas, dataflow):
    solution = solver_raas.generate(problem, role="solver")
    verdict = verifier_raas.generate({"problem": problem, "solution": solution}, role="verifier")
    if verdict.accepted:
        reward = 1.0
        feedback = None
    else:
        retry = solver_raas.generate(problem, role="solver", feedback=verdict.feedback)
        reward = score_retry(retry)
        feedback = verdict.feedback
    dataflow.put({
        "model_id": "solver",
        "trajectory": solution,
        "reward": reward,
        "verifier_feedback": feedback,
    })
    dataflow.put({
        "model_id": "verifier",
        "trajectory": verdict.trace,
        "reward": reward,
    })

3.6 Auto-scaling controller 与 data algorithms

Auto-scaling 的唯一显式公式是根据 trainer wait fraction $w$ 调整目标 rollout GPU 数 $G$： $G_{\text{target}}=\{\begin{array}{ll}\lceil G/(1-w)\rceil & \text{if }w>{\tau }_{\mathrm{high}},\\ \min (G,\lceil G\cdot (n_c/n_p)\cdot \rho \rceil )& \text{if }w<{\tau }_{\mathrm{low}},n_p,n_c>0,\\ G& \text{otherwise}.\end{array}$ 其中 $G$ 是当前 rollout GPU count，$w$ 是 trainer waiting fraction，$n_p$ / $n_c$ 是窗口内 production / consumption，$\rho$ 是 shrink-margin factor。released code 中 astraflow/dataflow/service.py 的 balance report 也使用 rollout_wait_fraction、WAIT_HIGH=0.10、WAIT_LOW=0.05、G_target = ceil(total_gpus / (1.0 - rollout_wait_fraction)) 这类逻辑，说明论文 controller 与服务端报告接口是同一抽象。

def autoscale_rollout_pool(total_gpus, wait_fraction, produced, consumed, rho=1.10):
    WAIT_HIGH, WAIT_LOW = 0.10, 0.05
    if wait_fraction > WAIT_HIGH:
        return math.ceil(total_gpus / (1.0 - wait_fraction))
    if wait_fraction < WAIT_LOW and produced > 0 and consumed > 0:
        return min(total_gpus, math.ceil(total_gpus * (consumed / produced) * rho))
    return total_gpus
 
 
def compose_data_algorithms(batch, *, replay_buffer, replay_ratio, use_greso):
    if use_greso:
        batch = [x for x in batch if greso_submit_probability(x.bucket).sample()]
    batch = [x for x in batch if x.metadata.get("zero_adv", 0) != 1]
    replay = replay_buffer.sample(int(len(batch) * replay_ratio), max_staleness=8)
    return mix_fresh_and_replay(batch, replay)

3.7 Code-to-paper mapping

Code reference: main @ 93517ce0 (2026-05-25) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
Dataflow layer / acquisition + serving composition	astraflow/dataflow/astraflow.py	AstraFlow, get_training_batch, state_dict
Rollout ingestion and metadata construction	astraflow/dataflow/data_acquisition.py	AstraDataAcquisition, build_metadata, _ingest_structured_result, _submit_tick
Fresh / replay buffer serving	astraflow/dataflow/data_serving.py, astraflow/dataflow/rollout_buffer.py	AstraDataServing, get_training_batch, replay storage
Post-rollout filtering / dynamic sampling hook	astraflow/dataflow/buffer_filters.py	KeepAllFilter, FilterZeroAdvFilter, get_filter
Replay selection	astraflow/dataflow/replay_selectors.py	select_latest, REPLAY_SELECTION_REGISTRY
HTTP service and balance report	astraflow/dataflow/service.py	AstraFlowService, create_app, rollout wait / target GPU report
Trainer abstraction	astraflow/train_worker/trainer/ppo_trainer.py	AstraFlowPPOTrainer.prepare_batch_from_buffer, train
Trainer HTTP client	astraflow/train_worker/trainer/astraflow_client.py	AstraFlowClient batch / version calls
RaaS weight pull and delta/full choice	astraflow/raas/server/manager.py	notify_version, _do_weight_update, _choose_transfer_mode, _pull_delta
Weight-manager config	astraflow/core/weight_manager/config.py, astraflow/core/weight_manager/transfer/config.py	WeightManagerConfig, SenderAgentConfig
Multi-policy math recipe	examples/math-multi-agent/qwen3-8b-actor-verifier-m2po-delta-no-ds-dapo-data/	yaml/experiment.yaml, scripts/run_*.sh
Code multi-policy recipe	examples/code-multi-agent/qwen3-8b-codegen-verifier-m2po-full-2node/	yaml/experiment.yaml, scripts/run_*.sh
Data algorithm composition recipe	examples/math-efficient-data/qwen3-8b-m2po-full-replay03-greso/	yaml/experiment.yaml

4. Experimental Setup (实验设置)

4.1 Datasets / workloads

• Math multi-policy：Qwen3-8B Solver / Verifier，训练数据为 DAPO math set 的 no-DS 配置（repo path: examples/math-multi-agent/qwen3-8b-actor-verifier-m2po-delta-no-ds-dapo-data/yaml/experiment.yaml，dataset function dapo_filter:get_dapo_filter_rl_dataset，prompt max_length=2000）；评测 AIME24、AIME25、MATH500、Minerva，每 25 iterations，eval temperature $0.6$，repeat $4$。
• Code multi-policy：Qwen3-8B，训练数据来自 agentica-org/DeepCoder-Preview-Dataset 的 primeintellect split；评测 LiveCodeBench v5、LiveCodeBench v6、Codeforces。论文写 $1,000$ iterations，但 released code config 当前为 $800$ steps，见 §3.4 差异说明。
• System flexibility / performance vs AReaL：Qwen3-14B auto-scaling 与 cross-region 使用 DeepScaler RL math set，prompts 过滤到最多 $2,000$ tokens；AReaL comparison 使用 Qwen3-1.7B / Qwen3-8B、DeepScaler RL math set、800 iterations。
• Data algorithm flexibility：Qwen3-8B，DeepScaler RL math set 的前 $8,000$ prompts，过滤到最多 $2,000$ tokens；比较 Vanilla、DS + Replay、DS + Replay + GRESO。论文/配置没有给出 DAPO、DeepScaler、DeepCoder train split 的完整样本总数，因此这里不伪造全量 scale，只记录论文和 YAML 明确给出的 cap / repeat / batch 设置。

4.2 Baselines and metrics

Baselines 包括 Solver single-policy、Solver + Verifier (verl / Dr. MAS)、AReaL、固定 6-GPU rollout pool、固定 11-GPU rollout pool、以及 vanilla / dynamic sampling / replay / GRESO 组合。系统层比较表还把 AstraFlow 与 AReaL、SLIME、verl、RLBoost、Dr. MAS (verl)、prime-rl 在 multi-policy、substitutable trainer/RaaS、modular data algorithms、async、disaggregation、elastic rollout、cross-region heterogeneous rollout 上做 capability 对比。

主要 metrics 是 benchmark accuracy / pass@1(avg@4)、time per iteration、wall-clock hours、rollout GPU-hours、trainer GPU-hours、total GPU-hours、trainer wait fraction、generated rollouts、per-iteration transfer time、weight delta sparsity、以及 rollout / trainer downtime。对代码任务，论文报告 LiveCodeBench v5/v6、Codeforces accuracy；对 math 任务，报告 AIME24、AIME25、AMC、MATH500、Minerva 的平均 accuracy。

4.3 Training config

Math multi-policy released config：Qwen/Qwen3-8B，Solver / Verifier 两个 policies，各自 FSDP dp=2；4 GPUs serving two SGLang RaaS instances，2+2 GPUs 给两个 trainer；train_batch_size=256，n_samples=8，max_new_tokens=4096，total_train_steps=1200，M2PO m2_threshold=0.01，Adam lr 5e-6，weight decay 0.01，${\beta }_1=0.9$，${\beta }_2=0.999$，constant LR，无 warmup，gradient clipping 1.0，KL penalty 0.001，ppo_n_minibatches=4，delta transfer，delta_full_sync_interval=10。

Auto-scaling / cross-region 论文 appendix config：Qwen3-14B，DeepScaler prompts $\le 2000$ tokens，M2PO m2_threshold=0.002，lr 3e-6，batch 256，8 rollouts/prompt，4 PPO mini-batches，temperature 1.0，max_new_tokens=18000，dynamic sampling on，1200 iterations。Auto-scaling 用两台 8×NVIDIA H200 (141GB) 共 16 GPUs；trainer 固定 4 GPUs，rollout pool 在 6 到 11 GPUs 间变化。Cross-region 用三台 H200 节点：本地 4-GPU trainer + 三个 4-GPU RaaS pools；local / remote power caps 是 700W、400W、250W，远程链路模拟为 4 Gbit/s bandwidth、300 ms RTT。

Data algorithm released config：examples/math-efficient-data/qwen3-8b-m2po-full-replay03-greso/yaml/experiment.yaml 使用 Qwen/Qwen3-8B、DeepScaler first 8000 prompts、replay_size=10000、replay_ratio=0.3、max_staleness=8、filter_function=filter_zero_adv、curator=greso、max_new_tokens=14000、total_train_steps=800、FSDP dp=4、lr 5e-6、KL penalty 0.001。

5. Experimental Results (实验结果)

5.1 Capability comparison

System-level comparison 中，AstraFlow 是唯一在七项能力上全为 full support 的系统：multi-policy collaborative training、substitutable trainer and rollout service、modular data algorithm interfaces、fully asynchronous training、disaggregated rollout-training architecture、runtime elastic rollout scaling、cross-region / heterogeneous rollout。Dr. MAS 只覆盖 multi-policy，AReaL / SLIME / verl / prime-rl 更偏 async / disaggregated training，RLBoost 覆盖 disaggregation 和 elastic rollout 但不覆盖 multi-policy / data algorithm / cross-region。

5.2 Multi-policy math and code

Math matched setting（Table 1）：single-policy Solver 在 AIME24 / AIME25 / MATH500 / Minerva / Avg 上是 42.9 / 31.8 / 90.5 / 39.2 / 51.1。Solver + Verifier (verl) 是 44.6 / 41.5 / 90.7 / 40.9 / 54.4，time/iter 212.64s。Solver + Verifier (AstraFlow) 是 47.3 / 40.6 / 92.9 / 45.0 / 56.5，time/iter 77.65s。平均 accuracy 相比 Solver 提升 +5.4，并且 iteration time 从 212.64s 降到 77.65s，约 $2.7\times$ speedup。

Code multi-policy（Table 2）：Solver baseline 在 LiveCodeBench v5 / v6 / Codeforces / Avg 上是 36.83 / 32.86 / 21.20 / 30.29。Solver + Selector 提升到 38.32 / 35.43 / 22.67 / 32.14（Avg +1.85）。Solver + Test-Case Generator 提升到 41.62 / 36.29 / 25.74 / 34.55（Avg +4.26）。这说明同一套 dataflow / RaaS / trainer interface 能表达不同代码协作 workflow，而不需要为每种 agent 角色重写系统。

Figure 6 解读：曲线按训练过程展示 Qwen3-8B 在 LiveCodeBench v5/v6 与 Codeforces 上的平均 eval accuracy。Test-Case Generator workflow 的提升更强，说明“让另一个 policy 产生可执行反馈再 retry”比单纯选择候选更能提供有效学习信号。

5.3 Auto-scaling and cross-region system flexibility

Auto-scaling（Table 3）在 Qwen3-14B math job 上：fixed 6 GPUs 的 Avg Acc. 68.6、Wall 35.8h、Total GPU-h 358.0、Wait frac. 26.9%；fixed 11 GPUs 的 Avg Acc. 68.0、Wall 23.9h、Total GPU-h 359.2、Wait frac. 2.1%；auto-scaling 的 Avg Acc. 67.9、Wall 24.4h、Total GPU-h 312.0、Wait frac. 3.0%。也就是说 auto-scaling 几乎保留 11-GPU 的 wall-clock，但把 total GPU-hours 降低到 312.0，比两个 fixed baselines 约低 13%。

Figure 7a–7d 解读：Figure 7a 显示 maintainer 在 wait fraction 高时扩容、低时缩容；Figure 7b 显示不同 RaaS pools 每轮都有产出但产出比例不同；Figure 7c 展示 local / remote links 的 weight-transfer time，periodic full sync 形成尖峰；Figure 7d 表明慢链路没有让 trainer 长时间阻塞，downtime 主要被训练计算重叠掉。

Cross-region run 达到 67.6 average accuracy，与 homogeneous local baseline 的 68.0 接近。权重传输方面，Qwen3-14B 的 delta sparsity $\ge 98.9\%$，每轮 payload 从约 28GB full sync 降到约 1.5GB delta bytes；周期性 full sync 每 20 iterations 出现一次 spike。跨任务 sparsity 结论是：math Qwen3-1.7B / 8B / 14B 在 lr 固定时落在 0.989–0.993，Qwen2.5-7B 的 AlfWorld / WebShop / Search 在 lr=$1\mathrm{e}-6$ 时都 $\ge 0.996$；Search 把 lr 提到 $5\mathrm{e}-6$ 后 sparsity 降到 0.978，但仍有 $\ge 30\times$ compression upper bound。

Figure 8 解读：该图把“delta transfer 可行”从系统设计假设变成测量证据。bf16 下相邻 iteration 大部分参数 bit-exact 相同，模型规模对 sparsity 影响较小，学习率更重要；因此远程 rollout pool 可以多数时间只拉 sparse delta，而不是每次拉完整模型。

5.4 Performance vs AReaL and data algorithms

与 AReaL 对比（Table 4）：Qwen3-1.7B 上 AReaL 平均 accuracy 49.5、time/iter 81.5s、time/1M tok 70.1s；AstraFlow 是 49.3、81.1s、69.4s。Qwen3-8B 上 AReaL 是 65.4、137.0s、117.6s；AstraFlow 是 64.8、139.6s、119.6s。结论是：在 AReaL 擅长的标准 single-policy math workload 上，AstraFlow 没有为系统灵活性付明显性能税。

Figure 9 解读：横轴是 generated rollouts，纵轴是 math accuracy。Dynamic sampling 提高最终 accuracy，但 rollout 数从约 200k 增到约 700k，成本约 $3.5\times$；GRESO 和 buffer replay 走另一条路线：尽量在 rollout 前避免低价值 prompts，或在 training-batch serving 阶段复用已有 trajectories，以更少 rollouts 接近 baseline-level accuracy。

5.5 Limitations and takeaways

作者明确承认的限制是：AstraFlow 目前主要在 research / cluster setting 下验证；它证明了抽象可以统一 multi-policy、elastic、cross-region 和 data algorithms，但还没有覆盖所有生产级容错、调度器集成、成本优化策略或非常大规模多租户场景。另一个实践 caveat 是 released repo 与 paper appendix 有少量配置差异，尤其是 code multi-agent iterations / eval repeat，以及 Qwen3-14B case study 没有公开对应 launch YAML。

总体结论：AstraFlow 的价值不在于提出一个新的 reward function，而在于把 agentic RL 的系统边界重新划分。只要 dataflow layer 能稳定管理 trajectory metadata、replay/filter/staleness，RaaS 能独立扩缩容和跨地域运行，trainer 能只消费 batches 并发布权重，那么许多原本需要系统级定制的 RL workflow 就可以作为 data policy、workflow policy 或 deployment policy 组合出来。