LLM 强化学习中，Rollout 占耗时的相当一大部分，长尾使最早完成 GPU 约 76% 时间空闲。通过大量数据，我们发现发现相邻 epoch 有大量的token 可匹配、因而结合历史推测解码与长度调度，提出 RhymeRL 系统。系统采用离线后缀树、奖励感知选枝、动态窗口、奇偶步互补及尾部迁移，解决在线索引开销、固定窗口无效验证和异常长样本失衡，并取得相比现有系统2.6x 的性能提升。

演讲提纲：

1. 背景：强化学习后训练时代，瓶颈在 Rollout
   • RL 已成为大模型对齐与推理增强的标准手段
   • 实测 Rollout 占训练耗时 84%–91%（math/code RLVR），随训练响应从 2K 增至 11K+ token
   • 批内长尾导致最早完成 GPU大量时间空转
2. 关键观察：相邻 epoch 的 Rollout 存在“相似性”
   • 基于真实轨迹分析：大量token可精确匹配上一 epoch
   • 响应长度排序稳定
3. 设计目标
   • 不依赖额外小模型，复用 RL 已付费生成的历史响应
   • 保留 one-step-off 算法边界，避免全异步的样本丢弃与范式改变
   • 离线建索引、在线零额外开销，避免检索回到关键路径
4. RhymeRL 的系统设计
   • HistoSpec：每个提示词一棵后缀树，O(m) 前缀查询；奖励感知选枝；类 AIMD 动态草稿窗口
   • HistoPipe：奇偶 step 长短互补调度；步内/跨步尾部迁移；两级 GPU 资源分配
   • 端到端闭环：响应、奖励、长度回写历史索引，先验随训练演进
5. 实施效果与结论
   • 端到端吞吐最高为（基线版本的）的 2.6 倍；HistoSpec 单步 Rollout 吞吐最高 1.86 倍

实践痛点： 

• 当前主要针对 math 和 code 进行比较深入的实践，更复杂动态的 agent RL 场景可能需求和问题不同。

前沿亮点：

1. 不依赖于传统 speculative decoding 中对小模型能力的依赖
2. 能够充分利用空闲算力提效

听众收益：

1. 了解当前强化学习在 Rollout 阶段 Infra 侧主要开销
2. 了解如何基于历史经验来优化当前的 Rollout

MaaS 业务中的模型、硬件和请求工况变化较快。传统的部署调优和算子优化依赖人工完成需求分析、性能定位、算子开发、验证及上线，优化周期难以跟上生产负载的变化。
本次分享将介绍一套面向 MaaS 生产场景的自动优化流程：给定卡型、模型和典型工况，探索合适的部署配置；从实际运行 Trace 中识别热门算子，并结合当前工况判断是否采用已有的算子融合模式；对典型工况进行归并、清洗、脱敏和泛化，生成可复现的 Benchmark；再由 Atrex Kernel Agent 通过 Agent Loop 完成性能分析、代码生成、验证和持续优化；最后将优化结果回接推理框架，进行端到端性能回归和灰度验证。分享将重点介绍算子优化，以及各环节之间如何衔接。

演讲提纲

1. 为什么 MaaS 推理优化需要自动化
   • MaaS 场景中的模型、卡型、请求工况和部署配置持续变化  
   • 传统流程依赖人工完成需求分析、性能定位、算子开发和框架集成，整体周期较长  
   • 单算子 Benchmark 的优化结果不一定能转化为端到端收益  
   • 从部署配置探索、算子任务生成、Agent 优化到框架上线的整体流程
2. 探索推理部署配置
   • 给定卡型、模型和典型工况，探索并行策略、批处理及推理引擎配置  
   • 结合延迟、吞吐、显存和资源成本选择候选部署方案  
   • 根据实际运行 Trace 定位当前部署配置下的主要性能瓶颈
3. 从生产 Trace 到算子 Benchmark
   • 从生产 Trace 中识别热门算子，归并动态 Shape，选取典型 workload  
   • 结合卡型、模型、工况和算子 Trace，判断是否采用已有的算子融合模式  
   • 对生产工况进行去重、清洗、脱敏和泛化，形成可复现的 Benchmark  
   • 建立正确性、数值容差和性能评测标准，确定算子任务的优化优先级
4. Atrex Kernel Agent 的优化 Loop
   • Agent 循环进行 profile、瓶颈分析、方案生成、代码修改、验证和复盘  
   • 通过隔离会话、Git worktree、结构化 memory 和实验 journal 管理多轮优化 
   • 外围 Loop 负责实验预算、状态恢复、正确性门禁和终止控制，并使用完整 workload 与同卡 ABBA 测量验证性能收益  
   • 记录有效方案和失败实验，并结合代表性算子介绍一次完整的优化过程
5. 优化结果回接推理框架并上线
   • 将优化后的算子回接推理框架，检查接口、依赖和硬件兼容性  
   • 进行算子正确性与性能回归，以及模型端到端性能验证  
   • 通过灰度发布观察实际效果，并保留异常回滚能力
6. 实践成果
   • 支撑 Qwen3.8 获得 NVIDIA SOL-ExecBench FlashInfer 算子优化榜首  
   • 介绍百炼 MaaS 中面向不同卡型、模型和生产工况的优化实践  
   • 展示代表性算子的优化结果，以及回接框架后的端到端效果

实践痛点

• 生产工况变化快且存在长尾。采样过少可能遗漏重要场景，采样过多则会增加分析和评测成本  
• 线上 Trace 不能直接作为 Benchmark，需要进行数据脱敏、Shape 去重、工况归并和可复现性处理  
• Agent 可能过拟合公开 Shape，也可能将 GPU 测量波动误判为性能收益  
• Kernel 局部变快不代表端到端一定有收益，仍需在推理框架和模型层重新验证  
• 自动生成的代码在进入生产环境前，仍需经过正确性验证、性能回归、灰度发布和异常回滚

演讲前沿亮点

• 从真实生产工况中生成优化任务。 根据 MaaS 部署中的实际 Trace 识别热门算子和典型 workload，而不是只依赖人工提交优化需求  
• 衔接部署配置与算子优化。 给定卡型、模型和工况，先探索候选部署配置，再从实际运行结果中提取算子任务  
• 通过 Agent Loop 完成多轮算子优化。 Agent 负责性能分析和优化实验，外围 Loop 负责正确性检查、性能验证、状态恢复和终止控制  
• 将优化结果放回框架验证。 算子优化完成后回接推理框架，以模型端到端结果判断实际收益

听众收益

• 了解如何从 MaaS 生产工况和运行 Trace 中提取可用于优化的算子 Benchmark  
• 了解 Atrex Kernel Agent 如何通过 Agent Loop 完成多轮算子性能优化和结果验证  
• 了解算子优化结果回接推理框架并进行端到端验证的基本流程

强化学习系统的性能瓶颈不仅来自模型训练，也来自 Rollout 数据传输、经验回放和权重同步。Mooncake 面向 RL 场景提供高性能数据面：通过结构化对象、DataProto/typed-ragged、BufferPool 及 RDMA 优化 Rollout 数据流，并接入 Miles 替代 Ray Object Store，支持同步和 Fully Async 两种执行模式。在权重更新方面，Mooncake 同时支持 NCCL Broadcast、TransferEngine P2P RDMA 和 disk-delta，在 Kimi-K2 场景中 P2P 方案约实现 7 倍加速。此外，它还支持 TP/PP/EP/DP 异构 Reshard、Store 权重快照及 MoE 稀疏 Delta，为大规模 RL 训练提供高吞吐、低延迟、可扩展的数据与权重基础设施。

演讲提纲

1. 强化学习系统的整体流程
   • Rollout、数据传输、Learner 更新与权重下发
   • 同步 RL 与 Fully Async RL 的执行模式
   • RL 系统中的数据面与控制面
2. RL 场景面临的系统挑战
   • Rollout 数据规模大、结构复杂
   • Actor 与 Learner 之间的数据传输开销高
   • 权重更新频繁且容易阻塞采样
   • 不同并行策略下的权重布局不一致
   • MoE 模型权重同步成本高
3. Mooncake 的高性能 RL 数据面
   • 结构化对象与 DataProto 数据组织
   • typed-ragged 对变长序列数据的支持
   • BufferPool 降低内存分配和拷贝开销
   • RDMA 加速 Rollout 数据传输
   • 接入 Miles 替代 Ray Object Store
4. 同步与 Fully Async Rollout
   • 同步 Rollout 的数据流与权重更新流程
   • Fully Async 模式下 Actor、Rollout 与 Learner 解耦
   • 数据生产、消费和缓存的并行化
   • 吞吐、延迟与训练稳定性的权衡
5. Mooncake 的权重更新机制
   • NCCL Broadcast：适合高带宽集体通信
   • TransferEngine P2P RDMA：实现点对点高效传输
   • disk-delta：降低权重更新的数据传输量
   • Kimi-K2 场景下 P2P 约实现 7 倍加速
6. 异构并行与大模型支持
   • TP、PP、EP、DP 之间的异构 Reshard
   • Store 权重快照与快速恢复
   • MoE 稀疏 Delta 更新
   • 不同集群和硬件拓扑下的权重调度
7. 生态集成与生产实践
   • Miles 中的 RL 数据面应用
   • 与 SGLang、vLLM 等推理框架协同
   • Rollout、训练和权重服务的统一基础设施
   • 面向生产环境的稳定性、可观测性与容错
8. 未来发展方向
   • 面向 RL 的统一数据对象和传输接口
   • 更高效的异步权重同步与版本管理
   • 面向 MoE 和超大模型的稀疏更新
   • 推动 Mooncake 与更多开源 RL 项目协同优化

实践痛点

• 不同 RL 框架之间的数据结构和接口缺乏统一标准。
• Ray Object Store、网络传输和权重同步容易形成系统瓶颈。
• Fully Async 场景需要处理数据一致性、权重版本和训练稳定性。
• TP/PP/EP/DP 异构 Reshard 适配复杂，跨框架推广成本较高。
• 需要与更多开源项目共同验证性能并完成协同优化。

前沿亮点

• 面向强化学习 Rollout 数据面进行系统级优化
• 通过 DataProto、typed-ragged、BufferPool 和 RDMA 提升数据传输效率。
• 同时支持同步与 Fully Async RL 工作流。
• 基于 P2P RDMA、NCCL 和 disk-delta 构建多路径权重更新机制。
• 支持异构并行 Reshard、权重快照和 MoE 稀疏 Delta。
• 已在 Miles、SGLang、vLLM 等生产生态中得到应用。  

听众收益

• 理解大模型强化学习中 Rollout、数据传输和权重同步的关键瓶颈。
• 掌握 Mooncake 在 RL 数据面和权重更新方面的核心能力。
• 了解同步与 Fully Async RL 的系统实现思路。
• 学习如何利用 RDMA、BufferPool 和结构化数据降低传输开销。
• 了解异构并行 Reshard 及 MoE 稀疏权重更新的实践方法。
• 获得将 Mooncake 集成到其他 RL、推理和训练框架中的设计思路。

随着 Coding Agent、企业智能助手等 Agent 应用进入真实生产环境，如何让 Agent 在持续使用过程中不断提升能力，成为下一阶段的重要挑战。传统 Agent 系统产生的大量交互轨迹、工具调用记录和用户反馈通常仅用于日志分析，难以转化为模型能力提升的数据闭环。

本次分享介绍 AReaL 2.0 如何构建面向 Agent 自演进的在线强化学习基础设施。方案通过 Agent 轨迹协议、数据代理层和演进控制平面，将真实业务交互转化为可训练、可回放、可治理的数据，并通过微服务化 Agent-Compute 架构，实现无需重构原有 Agent 即可接入 Online RL。在 Hermes Agent 和软件工程 Agent 场景中，该方案支持大规模并发环境、异步训练和持续优化，使 Agent 从“一次性执行系统”逐步演进为“持续学习系统”。

演讲提纲：

1. Agent 为什么需要从执行闭环走向学习闭环
   • 分析当前 Agent 在工具调用、任务规划方面的发展，以及真实生产环境中“无法持续变强”的核心问题。
   • 介绍线上 Agent 产生的多轮交互、工具调用、用户反馈等数据为何无法直接用于训练。
2. 面向 Agent 自演进的新型 RL 基础设施设计：
   • 介绍 Agent Trajectory Data Protocol：将传统日志升级为包含状态、动作、反馈、奖励和环境信息的学习轨迹。
   • 介绍 Agentic Data Proxy：解决生产环境中的轨迹采集、权限隔离、数据治理和回放问题。
   • 介绍 Agent Evolution Control Plane：根据失败类型决定优化对象，例如 Memory 更新、Harness 调整或模型 RL 更新。
3. Online RL 微服务化实践：
   • 分享如何通过 Gateway、Router、Data Proxy 和 Agent-Compute Worker 解耦 Agent 服务与 RL 训练系统。
   • 重点介绍低侵入式接入方式：无需重写 Agent workflow，仅替换推理入口即可引入真实交互训练闭环。
4. 实践中的关键踩坑经验：
   • 线上日志不足以支撑 RL，需要设计面向学习的数据协议。
   • 直接在线更新容易造成模型回归，需要结合离线评估、灰度发布和版本回滚。
   • Agent 失败原因复杂，需要区分 Memory、Tool、Prompt、Model 等不同优化路径。

实践痛点：

• 首先，Online RL 的最大挑战是稳定性。Agent 的运行环境不断变化，包括用户行为、工具版本和任务分布变化，因此一次模型更新可能提升部分任务，同时导致已有能力退化，需要额外设计回放评估、灰度发布和快速回滚机制。
• 其次，Reward 设计仍然困难。相比传统 RL 任务，Agent 的成功往往涉及多个维度，例如任务完成率、工具调用效率、成本、安全性和用户满意度。过于简单的奖励容易导致 reward hacking，而过于复杂的奖励又增加系统建设成本。
• 第三，Agent 自演进并不是单纯更新模型参数。一个完整 Agent 包含模型、Prompt、Memory、Tool、规划策略等多个模块，如何准确定位问题来源，并决定应该优化哪一部分，是实际部署中的关键挑战。
• 此外，在线学习和生产稳定性存在天然矛盾。快速更新可以提高适应能力，但也会增加业务风险，因此需要在学习速度、系统可靠性和治理成本之间进行权衡。

演讲前沿亮点：

1. 区别于传统 RLHF 或 RLVR 系统主要关注模型训练过程，本方案关注 Agent 从生产交互到能力提升的完整闭环。核心创新在于将真实 Agent 工作流中的轨迹、工具调用和反馈转化为可学习的数据资产，使 Agent 能够基于实际使用经验持续优化。
2. 采用低侵入式 Online RL 接入方式。传统 Agent 强化学习通常需要重新构造环境或开发专门模拟器，与真实业务存在较大差距。本方案通过微服务化架构，将 Agent 服务、轨迹采集和训练系统解耦，使已有 Agent 可以较小改动接入在线学习流程。
3. 强调 Agent 演进过程中的系统治理能力。不仅关注“如何训练更好的模型”，还关注“为什么更新、更新什么、如何验证更新效果”。通过轨迹分析、失败归因和演进控制，实现更加可靠的企业级 Agent 持续优化。

听众收益：
本次分享将帮助听众理解 Agent 基础设施发展的下一阶段趋势：从传统的模型调用和工作流编排，进一步发展到能够持续学习和自我优化的智能体系统。
技术层面，听众可以了解如何构建 Agent Online RL 闭环，包括轨迹协议设计、生产数据采集、Serving 与 Training 融合、奖励反馈管理以及模型更新流程。
工程实践层面，分享将总结真实部署中的关键经验，包括为什么简单日志无法支撑强化学习、为什么在线更新容易导致系统退化、如何通过数据治理和版本管理保障生产稳定性。
对于正在建设企业级 Agent 平台的团队，本次分享能够提供一种新的系统设计思路：无需推倒已有 Agent 架构，而是通过基础设施升级，将现有 Agent 转变为具备持续优化能力的学习型系统，为未来构建“越使用越强”的 AI 应用提供参考。

RAG 场景下，主流引擎的 KV Cache 复用建立在严格前缀匹配之上，而检索结果会随查询动态重排——同样的文档块换个顺序就不再是同一个前缀。结果是块级内容冗余很高，缓存命中率却接近于零。
出路是跨块复用：允许块级 KV 直接拼接，不再考虑顺序。代价是块间 cross-attention 全部缺失，精度显著下降。已有方案用部分重计算来补救，但在 20% 这种实际可接受的重算预算下，精度相对损失普遍达到 30%~50%。我们认为根因是那些全局显著、但与用户问题无关的 token，把有限的重算预算占满了。
ProphetKV 换了一个目标：不去重建全部 cross-attention，只恢复用户问题真正会与之交互的部分。支撑它的是一个此前被忽略的观测——早在 prefill 阶段、decode 尚未开始时，用户问题自身的注意力分布就已经与后续生成 token 的注意力模式高度一致，跨模型跨数据集都很稳健。据此我们推导出以问题注意力为主因子的价值函数，并用两阶段流程在尊重层间依赖的前提下完成选择与重算。20% 重算比下保留全量 prefill 精度的 96%，prefill 耗时相比全量重算下降约 4.6 倍，且完全免训练。

演讲大纲

1. RAG 的缓存命中率为什么接近于零
   • 前缀匹配复用的适用边界：多轮对话有效，RAG 失效
   • 检索块动态重排导致的命中率塌陷
2. 跨块复用：命中率上来了，精度掉下去了
   • 大幅提升命中率
   • 块级 KV 直接拼接，丢掉的是块间 cross-attention
   • 重算名额被"看起来重要"的 token 占满了，和问题相关的一个都没排上
3. 先知：把用户问题变成调度信号
   • RAG 输入的固定拓扑：查询恒在末尾，一个免费但被忽略的先验
   • 核心观测：查询注意力分布与后续生成注意力模式的重合度
   • 挑 token 只算问题那几十行注意力，不算整张矩阵，所以选择本身几乎不花钱
4. 两阶段重计算：怎么在层依赖下高效执行
   • 死结在哪：每一层该重算的 token 不一样，但想知道深层该挑谁，得先把前面所有层都算完——而这正是我们想省掉的开销
   • 走不通的捷径：只用第一层的结果替所有层做决定，跨层 token 重合度断崖式下跌
   • 阶段一，发现：从头到尾走一遍所有层，每层只算问题对上下文的注意力，把各层信号融合成一份全局重要性排序
   • 阶段二，重建：名单已定，再走一遍完成重算。因为不必边算边选，隐藏状态可以沿层传递复用，不会走一层停一下等决策
   • 与推理引擎 prefill 流程的对接点
5. ProphetKV + ContextBox
   • 复用单位从前缀降到块，同一份 KV 能被更多请求命中。
   • 可缓存对象从会话前缀变成整个知识库，显存装不下，且需要跨实例共用——共享存储成为必需。
   • LRU 在 RAG 下会颠簸，先知信号在选择阶段已经算出，可以作为多级缓存的放置依据
6. 总结与 Q&A
   • 结论：跨块复用的瓶颈不在选择规则，而在预算分配
   • 三个数字：20% 重算预算、精度保留 96%、prefill 加速 4.6 倍（基线为全量重算）
   • 三个代价：以 I/O 换算力；无小相关子集的任务退化；引擎侧缺部分复用接口

这样的技术在实践过程中有哪些痛点?

• 拿 I/O 换算力：候选块的 KV 要全部读回显存，其中被重算的那部分读回来就作废；上下文越短、存储越慢，越不划算
• 精度并非无损：20% 预算下仍有约 4% 相对损失；摘要、全文翻译这类没有"小相关子集"的任务，以及查询不在末尾的模板，会直接退化
• 引擎侧缺接口：vLLM / SGLang 都没有"复用一部分、重算一部分"的公开接入点，落地成本不低

演讲亮点

1. 一个反直觉的观测：模型在开口回答之前，就已经"知道"答案藏在上下文的哪里——用户问题的注意力分布，提前预示了后续生成的注意力模式。
2. 一次目标的重定义：同行都在想办法把有限算力分得更均匀，我们证明真正该做的是放弃重建全部 cross-attention，只算用户问题关心的那部分。
3. 实测数据：20% 重算比、精度保留 96%、prefill 快 4.6 倍、免训练、可直接接入现有推理引擎。
4. 从存储侧视角说清楚，KV Cache 跨块复用之后，多级缓存的收益边界到底在哪里。

听众收益

1. 理解 RAG 场景下 KV Cache 复用的真实瓶颈：前缀匹配为什么失效，跨块复用的收益边界在哪里，以及"理论重算比"与"实际算力开销"之间为什么会差出数倍。
2. 拿到一套免训练的选择性重计算方案：如何用用户问题定位真正该重算的 token，如何在层间依赖下分两阶段执行，以及方案生效需要满足的三个前提条件。
3. 看清跨块复用之后的完整成本账：重算省下的算力、KV 回显存的 I/O 开销、精度损失三者如何权衡，多级 KV Cache 在什么条件下才真正划算。

AgentENV（AENV）是清华大学计算机系 KVCache.AI 团队与月之暗面联合研发的面向智能体的分布式执行环境，目前已在 GitHub 开源。AI Agent 在强化学习训练、模型评测与在线服务中，需要在真实的软件环境中执行复杂操作（读取代码、安装依赖、与数据库交互等），而现有沙箱平台普遍面临成本高、可扩展性有限的瓶颈。
AENV 提出了一套创新解法：通过按需镜像拉取和分层块存储实现高可扩展性；通过内存复用、页面缓存共享及 Balloon 技术大幅提升单机部署密度；通过暂停快照功能显著提升资源利用率。目前，AENV 已深度服务于 Kimi K3 的强化学习训练，在生产环境中成功支撑了超 150 万镜像与 5000 万个执行环境的并发调用，极大降低了基础设施成本。

演讲提纲

1. 为什么 AI Agent 需要专属执行环境
   • 从训练 Rollout、模型评测到在线服务，梳理 Agent 沙箱的核心应用场景
   • 拆解代码执行、测试运行、工具调用、文件读写和依赖安装等环境能力
   • 分析传统沙箱在成本、环境灵活性和镜像分发效率上的主要局限
   • 引出面向大规模 Agent 工作负载的分布式执行环境需求
2. 成本压力与环境组合挑战
   • 结合训练资源数据，量化执行环境在强化学习流程中的成本占比
   • 对比模型调用与沙箱运行开销，分析推理阶段的成本结构
   • 拆解传统沙箱平台在环境组合及模板膨胀问题
   • 分析传统 OCI 镜像全量下载、解包和高并发分发的性能瓶颈
3. AENV 的产品定位与总体架构
   • 介绍 AENV 的设计目标、生产规模及其在 Kimi K3 训练中的应用
   • 拆解 Gateway、Scheduler、Node 与 Sandbox 的核心职责
   • 通过 Firecracker、ublk 和共享存储构建计算、隔离与状态管理体系
   • 兼容 E2B、多容器环境和嵌套 Docker，降低现有 Agent 应用的迁移成本
4. 高密度部署与弹性调度技术
   • 基于 ublk + overlaybd 构建支持远程挂载和按需读取的分层块存储
   • 通过“共享只读基底 + 私有写入增量”提升镜像与磁盘复用率
   • 将 Page Cache 下沉至宿主机，并结合内存回收机制减少重复占用
   • 将低活跃 Sandbox 自动暂停并持久化，释放 CPU 和内存资源
   • 结合增量快照与懒加载，实现快速恢复和跨节点调度
5. AENV 的落地效果
   • 对比按需加载、缓存拉取与冷镜像拉取，验证启动和分发性能
   • 结合生产集群数据，评估 CPU、内存复用带来的部署密度提升
   • 对比不同沙箱平台的月度成本，分析 AENV 的规模化降本效果

实践痛点：

• 高密度与性能确定性的冲突：CPU 和内存超售能够显著降低成本，但当大量沙箱同时转为活跃状态时，容易出现资源争抢、尾延迟升高和任务超时，需要对沙箱进行精细的控制；
• 按需读取与运行时抖动的冲突：远程镜像无需完整下载即可启动，但首次访问缺失块仍依赖网络和后端存储；网络波动可能从启动等待转化为任务执行过程中的随机停顿。

前沿亮点：

• 生产规模验证：AENV 已服务于 Kimi K3 训练，并支撑约 150 万个镜像和 5000 万个执行环境。
• 将“高密度部署”和“弹性生命周期”统一起来：通过共享基底、私有增量、Page Cache 复用、冷页回收、增量快照和懒加载，既减少单个沙箱的资源占用，也能回收低活跃沙箱占用的集群资源。
• 把远程状态变成本地可用设备：基于 ublk + overlaybd 对远程镜像、磁盘和快照进行块级按需挂载，显著降级镜像分发的性能开销。
• 兼顾性能、成本与生态迁移：AENV 不仅追求启动速度，还提供 E2B 兼容、多容器组合、和多存储后端支持，降低现有 Agent 系统接入新基础设施的改造成本。

听众收益：

• 理解 Agent 执行环境为何会成为模型之外的重要成本中心，掌握训练 Rollout、模型评测和在线服务对沙箱基础设施的不同要求。
• 掌握一套可复用的分布式 Agent Sandbox 架构，包括网关、调度器、执行节点、虚拟机隔离、分层块存储、对象存储和 P2P 分发的职责划分。
• 掌握“共享基底 + 私有增量”，“增量快照 + 懒加载”，“暂停恢复 + 资源调度”等关键设计方法及其适用场景。

在大模型训练数据规模持续提升、模型迭代效率持续加快的背景下，业界在模型数据处理的 GPU 效能、任务稳定性、数据交付时效等方面面临巨大挑战。蚂蚁通过新一代大模型训练数据处理系统 Altum 的建设，尝试系统化解决这些问题。本次分享将重点介绍在性能、稳定性、效率等方面提升的关键技术策略和背后的思考与取舍，以及业务生产实践案例。

演讲提纲：

1. 背景
   • 业界、蚂蚁在大模型训练数据处理上面临的挑战；
2. 整体方案
   • 涵盖算力、引擎、平台、数据等多个层次的体系化方案；
3. 极致性能优化
   • 异构算力融合调度：向上兼容不同算子体系、向下支持多种算力类型，提升全局资源利用率；
   • 基于数据湖存储 Paimon 的端到端升级：从数据采集到模型训练消费的端到端优化，提升存储与网络 IO 性能；
   • 算子性能优化与增量计算（全局去重、样本重试、增量同步等），提升 GPU 计算性能；
4. 稳定性提升
   • 样本级重试、端到端可观测与 SLA 保障、熔断保护机制、智能运维诊断；
5. 研发效率提升
   • 端到端场景化 Pipeline：场景化研发范式、增强能力（节点、算子）、人机协同研发；
   • Agentic 数据处理：支持逐条数据的多轮 Agent 处理；
6. 生产实践与未来展望
   • 在阿福、百灵等内部场景的落地效果；
   • AI Data Infra 发展方向。

实践痛点：

• 跨引擎调度的统一抽象 vs 引擎特有能力损失：不同引擎的统一在一定程度上牺牲了各引擎的独有优化，需要在统一对齐上做 tradeoff，做不到「零损失抽象」；
• 样本级重试的降本空间 vs 幂等约束与熔断阈值的平衡难题：只重跑失败样本能根治「全量重跑烧 GPU」，但失败熔断阈值在「误杀抖动」与「无效烧卡」之间难以平衡。

前沿亮点：

• 「高失败率、低吞吐、高交付时长」三角困局下的体系化解法；
• 从全局资源利用率、存储与网络 IO、计算性能全方位的极致性能优化；
• 场景化、Agentic 方式的 AI 数据研发新范式。

听众收益：

• 了解大模型背后训练数据处理的全链路；
• 掌握全链路数据处理背后的关键技术挑战与系统性解法；
• 获得真实业务场景下的落地路径。