大模型infra综述

简介

• 简介
• 简介（未完成）
• 硬件演进
• 软件演进
• 模型训练的挑战
• 模型推理的挑战
• 软件栈
• 汇总

简介（未完成）

程序员必须了解的AI系统设计与挑战知识 硬件演进 ==> 软件演进 ==> 训练挑战 ==> 推理挑战。

硬件演进

从CPU为中心到GPU为中心。传统基础设施以 CPU 为核心，通过多线程和微服务构建分布式系统，处理高并发请求（如 Web 服务）。这些都有成熟的方法论了（如”海量服务之道”）。主要工作是逻辑事务的处理，瓶颈在网络 I/O 和 CPU 核心数量。而 AI Infra 以 GPU 为核心，其设计目标从逻辑事务处理转向高吞吐浮点计算。此时CPU 多线程被 GPU 并行计算替代，内存被显存替代。为什么 GPU 会成为核心？是因为 LLM 大模型每次生成一个 token，都需要读取全量的模型参数。传统的 CPU + 内存的算力和带宽无法满足如此恐怖的计算密度，计算和通信都必须转移（offload）到 GPU 内完成。CPU 成为数据搬运工和“辅助处理器”。为了更直观地理解这个计算密度，我们做一个简单的计算。不考虑计算的延时，LLM 大模型生成一个 token 的耗时公式计算为：计算耗时 = 模型参数 * 数据精度 / 显存带宽。以 DeepSeek-R1-671B-A37B-FP8 模型为例，计算一个 token 耗时，H20 为 37B × 1byte ÷ 4000GB/s = 9ms，如果是 CPU 则为 37B × 1byte ÷ 64GB/s = 578ms。传统 Infra 的分布式理念貌似在 AI 时代失效了。传统 Infra 追求横向扩展，而 AI Infra 呈现 “AI 大型机”特性，是因为传统后台服务的可以容忍毫秒级延迟，但 AI 集群不行，GPU 的算力是 CPU 的数百倍，微秒级的延时等待也会造成很大的算力损耗，需要硬件的高度集成。

软件演进

相比传统后台应用的增删查改，AI 应用的新范式是模型训练和推理。模型训练是指通过海量数据拟合出一个复杂的神经网络模型，推理就是利用训练好的神经网络模型进行运算，输入的新数据来获得新的结论。

1. 工欲善其事，必先利其器。传统后台应用依赖 tRPC 或 Spring 等微服务框架，帮助我们屏蔽负载均衡、网络通信等底层细节，我们可以把精力放在业务实现上。与之相似，AI 应用则依赖深度学习框架。如果没有深度学习框架（比如PyTorch），我们就可能陷入在茫茫的数学深渊中，挣扎于痛苦的 GPU 编程泥潭里。得益于动态计算图、自动微分和丰富的 Tensor 操作算子，PyTorch 能帮助我们快速实现模型设计。只需要描述模型结构+待学习的网络参数，不需要关心数学计算和 GPU 编程的细节。
2. GPU 编程。绝大部分的 AI 应用，的确不需要我们手写数学计算的 GPU 代码。但为了满足模型创新的需求，有必要学习 GPU 编程。例如 Meta 发布的 HSTU 生成式推荐模型，核心的 hstu_attn 计算，如果直接用 PyTorch 框架算子组合实现，则时间复杂度为 O(M * N²) ，其中 M 和 N 是一个数量级，相当于O(N³) 。但是通过自定义内核，可以优化到 O(N²)。

模型训练的挑战

PS： 类似传统infra的大数据

我们一直追求更大的模型，DeepSeek-R1 有数千亿参数，使用了数十万亿 token 的训练数据，涉及算力、存储、通信等多维度的工程挑战。有了 PyTorch 深度学习框架，只是 AI 应用落地的万里长征第一步。接下来我们将讨论深度学习框架之上的模型训练的挑战，即建设分布式 GPU 集群的原因。

1. 存得下。
   1. 显存刺客：中间激活。在前向传播结束后出现一个显存占用（中间激活）的尖峰，远大于模型参数本身。
   2. 传统后台服务使用分片（Sharding）策略解决单机存不下的问题。与之相似，AI Infra 提出“模型并行”，就是将单个大模型拆分为多个子模块，并分布到不同 GPU 上协同工作，通过通信来共享数据。
2. 算得快。简单的机器堆叠，算力不一定有线性的增长。因为分布式训练并不是简单地把原来一个 GPU 做的事情分给多个 GPU 各自做。需要协调多个 GPU 机器计算任务分配，GPU 机器之间的数据传输会引入网络IO和通信开销，降低训练速度。
   1. 通信计算重叠。传统后台服务我们通过多线程或异步 IO 避免阻塞 CPU 主线程，与之相似，AI Infra 提出通信计算重叠的方法论。GPU 编程模型中有流（stream）的概念，一个流表示一个 GPU 操作队列，该队列中的操作将以添加到流中的先后顺序而依次执行。不同流之间可以并行执行。那么通过令计算和通信操作加入不同的流中，可以做到二者的执行在时间上重叠。PS： 一个wrap阻塞了就跑另一个wrap？

模型推理的挑战

PS： 类似传统infra的高并发业务系统 主要是2个挑战：高吞吐（降本），低延时（增效，用户体验）。

1. 降低延时。传统后台服务我们使用链接复用、缓存、柔性等技术降低系统响应时间。AI Infra 也有相似的做法。
   1. 在 GPU 编程模型中，CPU 和 GPU 是异构的，CPU 通过 API（例如 CUDA API） 向 GPU 提交任务，然后异步等待 GPU 的计算结果返回。GPU 收到任务后，会执行内核启动、内存拷贝、计算等操作。这个过程中，涉及到 CPU 与 GPU 之间的通信、驱动程序的处理以及 GPU 任务的调度等环节，会产生一定的延迟。模型推理需要执行大量重复的 GPU 操作，每个的 GPU 操作都要重复执行上诉环节，这些非核心的 GPU 开销会成倍数地放大，影响最终响应时间。在传统后台服务，我们使用 Redis 的 Lua 脚本封装多个 Redis 操作和计算逻辑，一次提交，减少网络开销。与之相似，AI Infra 利用 CUDA Graph 技术将多个 GPU 操作转化为一个有向无环图（DAG），然后一次性提交整个 DAG 提交到 GPU 执行，由GPU自身来管理这些操作的依赖关系和执行顺序，从而减少 CPU 与 GPU 之间的交互开销。
   2. KV Cache：空间换时间。
   3. 流式响应
2. 提高吞吐量。实现 AI 应用的高吞吐本质上就是提高昂贵的 GPU 的利用率，让 GPU 单位时间能完成更多的任务。
   1. 传统批处理。其实传统后台服务也大量使用了批处理，例如 Redis 的 MGet 命令，单次请求就完成所有 key 的获取，将 N 次网络往返（RTT）压缩为1次。与之相似，模型推理的批处理就是将多个输入样本打包（batch），将原本串行的 N 次轻量的推理计算，合并为 1 次重量的计算，实现单位时间内处理更多的请求，提高了 GPU 利用率。传统批处理类似 “固定班次的公交车”：乘客（请求）必须等待发车时间（组建一个batch），发车后所有乘客同步前进。即使有乘客提前下车（短请求完成），车辆仍需等待所有乘客到达终点（长请求完成）才能返程接新乘客。传统批处理存在着资源浪费：GPU 要等待长请求处理完，不能处理新的请求而空闲。这个问题在 LLM 应用领域显得特别突出，因为不同用户请求 Prompt，模型的回答结果长度差异巨大，如果使用传统批处理，GPU 空闲率很高。这个本质上是个任务调度问题，传统后台服务我们使用工作窃取算法（work stealing）解决线程空闲问题，与之相似，AI Infra 提出“连续批处理”解决这个问题。
   2. 连续批处理。连续批处理类似“随时随地拼车的顺风车”，每辆车（GPU）在行程中可随时上/下客。新乘客（请求）直接加入当前车辆的空位（空闲计算单元），已完成的乘客立即下车（释放资源）。

显存管理技术的演进

1. 虚拟化与按需分配： PagedAttention在请求长度高度不均、并发持续变化的服务负载下，把“为每个请求随序列增长而扩张的KV Cache”从粗放的预分配，变成可共享、可回收、可迁移的精细化资源，从而同时改善吞吐、TTFT与显存上限。PS：就好比linux即使有内存管理，也会有tcmalloc来提高内存管理效率。
2. 结构化复用：在实际应用中，许多推理请求共享相同的前缀（Prefix），例如系统提示词（System Prompt）或多轮对话中的历史记录。SGLang框架引入的RadixAttention进一步扩展了显存管理的维度，它将KV Cache组织成一棵基数树（Radix Tree）。当新的请求到达时，系统会在树中进行最长前缀匹配。如果匹配成功，则直接复用已有的KV Cache，无需重新计算。
3. 分层与分布式扩展：尽管PagedAttention优化了单卡显存的使用，但面对超长上下文（如1M+ Token），单机显存依然不足。此时，分层存储（Tiered Storage）成为必然选择。PrisKV和InfiniGen等系统提出将KV Cache卸载（Offload）到宿主内存（Host Memory）甚至NVMe SSD上。为了解决卸载带来的高延迟问题，PrisKV利用了RDMA（Remote Direct Memory Access）技术。通过构建一个分布式的、分层的KV存储池，PrisKV允许GPU直接通过PCIe和网络读取远程节点的内存，绕过CPU的干预。

注意力计算优化演进。在Transformer架构中，Attention算子的计算复杂度随序列长度呈二次方增长（ ），且涉及大量的显存读写。

1. 单卡优化：FlashAttention系列
2. 灵活性提升：FlexAttention, 虽然FlashAttention性能强劲，但其代码实现极其复杂，且缺乏灵活性。一旦研究人员想要尝试新的Attention变体（如Sliding Window Attention, Document Masking, Tanh Soft-capping等），往往需要重新编写CUDA Kernel。为了解决这一问题，PyTorch团队推出了FlexAttention。
3. 从单卡算子到多卡并行：长上下文的边界。当上下文长度超过单卡显存与计算的可承载边界时，Attention的主要矛盾会从“单卡内核效率”转向“如何切分序列、如何通信与重叠、如何在尾延迟约束下扩展并行度”。

调度与批处理：从动态批处理到PD分离。推理服务的端到端体验不仅由单次前向计算决定，还高度依赖于请求如何切分（Batching）与调度（Scheduling）。在解码阶段，若Batch过小会导致GPU利用率不足；若Batch过大或调度不当，又会导致Token间延迟抖动与队头阻塞。

1. Static / Continuous / In-flight。
2. PD分离架构

分与合：当模型规模、上下文长度或并发量超过单卡能力边界时，必须通过多卡协同扩展。 并行策略：TP/PP/DP/SP/EP。并行维度决定了“怎么切分”，但系统能否扩展、延迟是否稳定，往往取决于“怎么通信与同步”。推理系统中常见的通信形态包括：

1. All-Reduce： TP/DP等场景常见，用于参数/激活的聚合。
2. All-to-All： MoE（EP）与部分SP场景常见，用于重分布数据（如token到专家、QKV/Head的重排与交换）。
3. 拓扑与介质： NVLink适合机内高带宽低延迟；RoCE/InfiniBand + RDMA适合跨节点直连；工程上常通过通信-计算重叠（overlap）来掩盖延迟。

软件栈

AI计算的开源技术栈：Kubernetes + Ray + PyTorch + vLLMAI计算的常见技术栈：Kubernetes + Ray + PyTorch + vLLM

1. 训练与推理框架：在GPU上高效运行模型，包括模型优化、并行策略、模型定义和自动微分。
2. 分布式计算引擎：在任务内调度作业、移动数据、处理故障、自动扩展工作负载、管理进程生命周期。
3. 容器编排器：分配节点、调度整个作业、启动容器、管理多租户资源共享。

后训练目前以强化学习为中心，因其复杂性而引人注目。与常规训练相比，后训练结合了模型训练和模型推理。推理是为了生成额外的训练数据。模型推理通常与模拟器或代理环境交互。奖励模型对生成数据的质量进行评分。模型权重需要从算法的训练部分传输到推理部分，而rollouts 需要从生成部分传输回训练部分。因此，存在许多移动部件，分布式系统挑战更加艰巨。

为什么 AI 时代值得重新讨论 OS：从 Linux Kernel 到 GPU 执行栈的系统重构 Linux kernel 的成功，不是子系统齐全，而是抽象抓对了。很多人一提 Linux kernel，脑子里想到的是那几个熟悉目录：进程调度、内存管理、文件系统、网络栈、驱动模型。这种理解当然没问题，但它更像功能清单，不是本质。Linux kernel 真正伟大的地方，在于它找到了 CPU 通用计算时代最稳定的一组资源抽象。CPU 时代的主问题是什么？本质上是大量程序并发运行，竞争 CPU 时间、内存空间、I/O 通道和设备访问权。于是内核要回答几个核心问题：

1. 程序如何作为“合法主体”使用机器？答案是 process 和 thread。进程提供资源所有权、隔离边界和故障传播边界，线程提供执行流和调度单元。用户并不是直接在“操作 CPU”，而是在通过进程和线程间接使用 CPU。
2. 物理内存如何变成一个可隔离、可复用、可延迟分配的空间？答案是 virtual memory。虚拟内存真正的价值从来不只是“地址连续”，而是把页表、缺页、共享映射、匿名页、文件映射、copy-on-write、swap 等能力统一成一个稳定框架。它让“内存”不再只是硬件条上的字节阵列，而变成了一个可以被系统组织、被进程感知、被策略优化的对象。
3. 持久化和通信如何抽象成统一接口？答案是 file 和 socket。文件把长期存在的数据组织成可命名、可权限控制、可缓存、可落盘的对象；socket 把跨边界的数据流组织成另一种一等对象。它们的意义不在于 API 是否好记，而在于把本来极其复杂的存储设备和网络设备背后差异，折叠成了上层可稳定依赖的系统接口。
4. 千奇百怪的硬件如何纳入一套统一体系？答案是驱动、设备模型、中断、DMA、内核对象以及系统调用边界。程序不需要理解网卡、磁盘、PCIe 设备、控制器寄存器这些细节，而是通过内核定义好的语义间接使用它们。 Linux围绕 CPU 主导的通用计算，形成了一套极其稳定的资源抽象：process/thread + virtual memory + file/socket + device。这些抽象既贴近硬件，又没有被硬件细节绑死；既能表达关键约束，又能给用户态留下足够自由度。这套抽象之所以延续几十年，不是历史偶然，而是因为它们精准抓住了那个时代最重要的资源和冲突。这也是我理解 OS 的起点：OS 从来不是几个固定子系统的名字集合，而是围绕主导计算范式建立起来的一套资源抽象、隔离与调度体系。

为什么 AI 计算开始让经典抽象显得“不够了”？“不够了”不等于“错了”。Linux 当然还在工作，问题在于，AI 工作负载正在把真正关键的系统矛盾，逐渐从经典 OS 抽象的中心区域，推向另一套对象。传统通用计算里，程序的关键路径通常是：线程获得 CPU，访问虚拟内存，发起系统调用，读写文件或网络，等待设备返回。内核在这条链路里处在绝对中心位置。但 AI 系统，尤其是 GPU 主导的大模型训练和推理系统，决定系统表现的，越来越不是“这个进程拿到了多少 CPU 时间片”，而是：这个计算图如何被 lowering；这个算子如何被 fusion；这个 kernel 的 tile 大小如何选；数据在 HBM、shared memory、register 之间怎么搬；不同 stream 上的执行和同步如何安排；多卡之间的 collective communication 如何与计算重叠；KV cache 如何分配、复用、回收；请求如何在 prefill 和 decode 两个阶段被不同策略调度。这些问题当然还是跑在 Linux 之上，但它们真正操作的对象已经不是 process/page/file 这一套了，而更像是：tensor、layout、graph、kernel、stream、collective、KV cache、request、session、context。换句话说，AI 系统最核心的资源不再只是 CPU 时间和普通内存，而变成了 GPU 算力、显存容量、显存带宽、片上存储、卡间互联带宽，以及围绕这些硬件资源组织起来的执行结构。很多最关键的调度和组织决策，已经不在 Linux 传统意义上的“热路径”里了。真正决定性能的事情，正在被 runtime、compiler、kernel DSL、serving system、distributed runtime 接管。工作负载变了，主语也变了。

现代 GPU 不是一个简单的“加速设备”，而是一个有自己执行模型、内存层次、同步机制和并行结构的复杂计算域。你如果真的沿着 driver -> runtime -> compiler -> kernel 这条链打 through，会很难再把 GPU 看作一个普通设备。

1. 驱动层。从 Linux kernel 的视角，驱动不是某种附属代码，而是把硬件资源纳入系统秩序的第一现场。放到 GPU 上，这层工作比一般设备要复杂得多。驱动要处理 context、地址空间映射、命令提交、同步原语、设备内存管理、DMA、peer access、中断和错误处理。GPU 不是一个“发个 ioctl 就跑一下”的设备，它背后有完整的命令队列体系、异步执行模型和多引擎协同。
2. runtime。如果只把 CUDA/HIP runtime 理解成“一个用户态库”，其实低估了它的系统地位。runtime 负责暴露 stream、event、memory allocator、kernel launch、graph execution、异步 copy、同步语义这些对象。注意，这些对象并不只是 API 层便利性设计，它们是在向用户暴露 GPU 这一类机器真正关键的执行原语。CPU 时代，POSIX 进程/线程是第一抽象；GPU 时代，stream/event/kernel launch 这类对象，实际上正在承担对应的执行抽象角色。GPU runtime 暴露出来的，不是“设备控制接口”，而是“执行组织接口”。这已经非常接近系统层问题了。
3. 编译器不再只是工具，而开始变成系统的一部分。如果只做传统应用开发，很容易把编译器想成构建工具链的一环：源码进来，二进制出去，工作完成。但在 AI 系统里，这个理解已经不成立了。从 MLIR 到 Triton，再到 CuTe 这种更贴近 kernel 构造和布局表达的体系，它们的意义都不只是“把代码变快一点”。更本质地说，它们在定义一件事：一个 tensor program 如何映射到这台 GPU 的并行层次和内存层次上。这个问题一旦说透，你就会发现 fusion、tiling、layout 根本不是纯粹的“编译优化细节”，它们其实是在做资源组织。举个最直接的例子。一个 tile 怎么选，绝不只是数学分块问题。它直接决定：
4. 多少数据驻留在 register；
5. 多少数据驻留在 shared memory；
6. warp 之间如何协作；
7. 访存是否 coalesced；
8. 是否会发生 bank conflict；
9. 一个 thread block 占掉多少片上资源；
10. 最终能有多少 occupancy；
11. 有没有空间和通信、prefetch、pipeline 重叠起来。 你把这个问题看穿之后，就很难再把 tiling 当成“只是编译器做的局部优化”。它本质上是在决定稀缺片上资源如何被切分和复用。这在系统意义上，和传统 OS 管理缓存、页、I/O 队列并没有本质区别，只是对象从 page/cache line/file buffer 变成了 tile/register/shared memory/tensor fragment。fusion 也是一样。它不是简单“把两个 op 拼起来少 launch 一次”这么朴素。fusion 改变的是中间结果是否 materialize、数据是否回写 HBM、不同 kernel 之间的边界是否保留、调度粒度是否改变。也就是说，fusion 实际上在重画运行时的数据流边界和执行边界。layout 更不用说。layout 不是格式选择题，而是整个系统性能的隐藏主轴。layout 决定访存模式，访存模式决定 kernel 写法，kernel 写法决定 launch 配置和同步方式，进一步还会影响通信切分、图编译和 runtime 调度。所以在 AI 时代，编译器和 runtime 的边界正在变模糊。编译器不再只是“离线产物生成器”，它实际上在提前定义运行时要面对的资源形态；runtime 也不再只是“执行器”，它反过来会约束编译器能做什么、该做什么。编译器正在长成系统组件。
12. 如果把近几年 GPU AI 系统里影响最大的技术工作串起来看，会发现它们有一个共同点：都不是简单在“实现某个算子”，而是在重新暴露机器约束。FlashAttention 之所以重要，从来不只是因为它让 attention 更快，而是因为它极其鲜明地揭示了一件事：在现代 AI 计算里，瓶颈往往不是 FLOPs，而是数据在不同层次内存之间如何流动。它把 attention 从一个“算术公式”问题，重新变成了一个“数据流与片上存储复用”问题。它说明 AI kernel 的核心，不再只是指令层面的优化，而是开始接近一种内存系统设计。你怎么切 tile，怎么 staging，怎么 double buffering，怎么让 Q/K/V 在片上以最合适的节奏被读取、复用和消费，这些决策本质上都在做一件事：围绕机器真实约束组织数据运动。Triton、CuTe 这类体系之所以重要，也不是因为“写 kernel 更方便了”，而是因为它们在提供一种新的表达方式，让开发者能够更直接地描述并行结构、数据布局和 memory movement。某种意义上，它们像是 GPU 时代新的“中间语言”，介于高层图编译和底层 ISA 之间，把原来埋在极深处的硬件约束显式化了。一个成熟的系统抽象，并不是把复杂性消灭，而是把最关键的复杂性用正确形式暴露出来。页、inode、socket、epoll 都是这样来的。今天 GPU 侧的 tile、layout、pipeline stage、async copy、tensor fragment，也开始承担类似角色。
13. vLLM 之类的系统，已经不只是框架，而是在长出新的“内存和调度子系统”。拿大模型 serving 来说，很多人最初会觉得推理系统无非就是“把模型 load 进来，然后高效跑 batch”。推理系统真正难的，往往不是一次 forward，而是持续不断地处理成百上千个长度不同、阶段不同、SLA 不同的请求。这些请求有的在 prefill，有的在 decode；有的上下文很长，有的马上结束；有的对延迟极敏感，有的更看重吞吐。与此同时，最稀缺的资源不是 CPU，而是显存，尤其是 KV cache 占据的那部分显存。这时，系统真正要管理的对象就变了。你管理的不是进程地址空间，而是 KV cache 的块式生命周期；你调度的不是线程时间片，而是 token 生成顺序、batch 合并策略和显存驻留策略。PagedAttention 之所以有系统味，不是因为它名字里有 page，而是因为它背后真的在做类似“页式管理”的事情：把原本容易碎片化、难以动态扩缩的 cache 空间，改造成更细粒度、更可复用的资源单元。continuous batching 之所以重要，也不是因为它更聪明地拼 batch，而是因为它已经在做一种新的请求级调度，把吞吐、显存、尾延迟三件事放进同一个决策面里。它们当然不是传统页管理和 CFS 调度的简单翻版，但它们确实有同样的系统味道：资源稀缺、生命周期复杂、局部决策会影响全局行为、策略必须和底层执行模型高度耦合。

如果把这些现象放在一起看，一条很清晰的线就出来了：

1. 驱动层在管理设备上下文、地址空间和命令执行；
2. runtime 层在暴露 stream、event、allocator、launch 和 graph；
3. 编译器层在决定 fusion、tiling、layout、lowering 和 codegen；
4. kernel DSL 在把硬件层次和数据流约束显式表达出来；
5. serving/runtime system 在管理 KV cache、request、batch 和 session；
6. distributed runtime 在协调 collective、拓扑和跨卡执行。

这些东西表面上分散在不同模块里，但本质上正在围绕同一件事收敛：为 AI 工作负载建立新的执行抽象。Linux 的经典问题是“程序如何使用机器”；那么今天 GPU 侧系统栈的新问题更像是：“tensor program 如何持续、高效、可控地使用异构算力和多层内存”。这里面最重要的变化，不是某个框架性能提升了 20%，而是系统一等对象的迁移。过去的一等对象是 process/thread/page/file/socket；今天正在冒出来的一等对象是 tensor/graph/kernel/stream/KV cache/request/session/context。AI OS 更像是建立在 Linux 之上的一层或几层新系统栈。最底层，Linux 仍然负责通用的隔离、设备管理、网络、文件系统、安全边界和基础资源控制。其上，GPU driver + runtime + compiler + communication runtime 正在形成一个新的“执行内核”。 再往上，serving system、session runtime、memory runtime 正在形成面向模型和请求的运行时。更上面，才可能是 agent、workflow、tool、policy 这一层更接近用户和组织的系统接口。

汇总

教模型做事的成本太高，任何系统的可持续性，最终都得回归到单位经济模型（UE）。如果 Agent 创造的价值覆盖不了它消耗的成本，那么无论模型多么先进，这个系统在商业上都是不可持续的。当前 Agent 的门槛主要存在于数据与设施上。在 SFT（监督微调）模式下，，我们依赖人类专家来教模型做事。但在很多场景（比如GUI Agent让 AI 操作电脑界面这种高门槛任务中），这种依赖变成了难以承受的负担。 这反向逼迫行业必须转向 RL（强化学习）——让 Agent 在虚拟环境里自己试错、自我博弈，摆脱对昂贵人工数据的依赖。只有这样，才能把数据成本从”按人头算”变成”按算力算”，实现边际成本的下降。但是，RL 的门槛也不低。传统的工业级 RL 训练往往依赖庞大的算力集群。即使是经过优化的训练流程，仍然需要 16 张显卡（8 卡采样、8 卡训练）以及大量的 CPU 资源来支撑仿真环境。破局的关键是构建高仿真环境，让 Agent 通过自主探索产生海量交互数据，再通过设计有效的奖励信号，用 RL 训练出更强的策略。

1. 光速的 GPU 算力，配上了龟速的操作系统。在传统的 RL 任务（比如下棋、打游戏）中，环境反馈是毫秒级的，步长短、速度快。但在 GUI Agent 场景下，Agent 执行一个动作——比如在虚拟机里点击 Excel 按钮——需要经历”虚拟机渲染→截屏→图像回传→视觉模型处理”的漫长链路。极高的延迟又进一步导致了计算资源的极度浪费——在传统的 RL 流程中，架构通常是紧耦合的。这意味着，当 GPU 在更新模型时，环境在等待；而当环境在采样数据时，GPU 又在空转。
2. 环境的复杂度也呈指数级上升。不同于文本生成，GUI Agent 面临的是一个像素级（Pixel-level）的动作空间，理论上它可以在屏幕上的任意坐标进行点击或拖拽，这使得动作空间接近无限。这使得奖励极为稀疏。比如”将 Excel 内容打印为 PDF”这样的任务，Agent 需要连续执行几十个步骤。在这个过程中，环境往往一片死寂，不会告诉 Agent 中间某次点击是对是错，只有最后一步才能得到结果。
3. 如何解决环境问题？
4. 横向解耦：其核心逻辑是将采样端与训练端在物理上彻底分开。这也意味着，Agent 的 Infra 必须具备处理异步数据流的能力，而非传统的同步批处理，将训练过程转变成了一个持续流动的、高吞吐的流水线。
5. 纵向解耦：降低算力门槛。开发模块化框架，将算法逻辑、模型架构与分布式引擎分离。
6. 状态管理（Long Context vs 记忆）。当前大多数 Agent 依赖自然语言进行思维链推理，但自然语言在精确计算和状态追踪上有局限。Transformer 架构虽然强大，但它缺乏可读写存储器，无法显式地存储或更新中间的推理状态，也没有循环或递归机制。在处理简单问答时，这种无状态特性不是大问题；但在面对复杂的软件开发或长程逻辑推理时，这种缺陷是致命的。单纯拉长上下文窗口既不经济也不实用。一种思路是将其设计为file system 式的分层存储。当 Agent 需要回顾时，它执行的是读取文件的操作，而非在上下文窗口中大海捞针。 我们需要全新的基础设施，不是传统的云计算，而是专门为 Agent 设计的诸如异步训练框架、解耦的采样环境和向量化记忆文件系统之类的 Agent Native Infra。