AI Infra 六个关键方向：从分布式推理到 Agent 沙箱

AI Infra（人工智能基础设施）不是简单地把 GPU 堆得更多，也不是只围绕模型参数量做文章。大语言模型进入工程化落地阶段后，瓶颈开始分散到推理服务、通信网络、算子编译、强化学习数据流、Agent 运行环境和硬件互联结构里。

可以把 AI Infra 的演进理解成一句话：把模型的计算特征拆开看，再为不同特征匹配更合适的系统形态。

这背后有六个关键方向：

1. 分布式推理：把 Prefill、Decode、Attention、FFN、专家通信拆开优化。
2. 面向 Tile 的开发语言：让算子开发者更关注数据流，而不是手写底层线程调度。
3. RL 训推分离：把强化学习里的训练和推理数据生成解耦，同时避免算力空泡。
4. 模型-系统协同设计：模型结构在设计阶段就考虑硬件算力、带宽和网络约束。
5. Agent Infra：为 Agent 的工具调用、沙箱执行、状态保持和安全审计提供基础设施。
6. 超节点硬件：通过更大的高带宽 GPU 域支撑长上下文和大规模并行通信。

1. 分布式推理：大模型服务的核心战场

大语言模型推理的压力来自两个维度：模型越来越大，请求形态越来越复杂。尤其是 MoE（Mixture of Experts，混合专家模型）和 Decode-Only（仅解码）架构成为主流后，推理系统必须围绕它们的特点做拆分。

1.1 两个前置概念：MoE 和 Decode-Only

MoE 模型由门控网络和多个专家模型组成。每次请求进来时，门控网络不会激活全部专家，而是只选择少量相关专家参与计算，这叫稀疏激活。

flowchart LR
    T[输入 token] --> G[门控网络]
    G --> E1[专家 1]
    G --> E2[专家 2]
    G -.未激活.-> E3[专家 3]
    G -.未激活.-> E4[专家 4]
    E1 --> O[合并输出]
    E2 --> O

稀疏激活带来两个结果：

Decode-Only 架构的推理过程通常分为两个阶段：

• Prefill（预填充）：处理用户输入的 prompt，计算出首个 token，并生成后续 Decode 所需的 KV cache。
• Decode（解码）：基于已有 KV cache，一个 token 一个 token 地生成回答。

sequenceDiagram
    participant U as 用户
    participant P as Prefill 阶段
    participant D as Decode 阶段

    U->>P: 输入 prompt
    P->>P: 计算 Q/K/V，生成首个 token
    P-->>D: 传输 KV cache
    loop 逐 token 生成
        D->>D: 读取 KV cache
        D->>D: 生成下一个 token
        D->>D: 更新 KV cache
    end
    D-->>U: 返回完整输出

两个阶段关注的指标不同：

Prefill 要一次性处理大量输入 token，计算压力大；Decode 每次只生成一个 token，但需要频繁读取 KV cache，内存带宽和缓存访问效率更关键。

1.2 PD 分离：让 Prefill 和 Decode 独立扩缩容

早期推理服务常把 Prefill 和 Decode 混合部署在同一组 GPU 上，这样实现简单，但会产生两个问题。

资源互相干扰。 Prefill 是计算密集型，Decode 是访存密集型，两者混跑时很难让 GPU 同时处在理想状态。Prefill 请求太多会拖慢 Decode，Decode 队列太长又会影响首 token 响应。

并行策略被绑定。 Prefill 和 Decode 适合的并行方式不一样，混合部署时只能折中选择，很难分别优化 TTFT 和 TPOT。

PD 分离的思路是把 Prefill 实例和 Decode 实例部署到不同设备或不同 GPU 组上，中间通过高速网络传输 KV cache。常见网络包括 IB（InfiniBand）和 RoCE（RDMA over Converged Ethernet，融合以太网上的远程直接内存访问）。

flowchart LR
    R[请求入口] --> S[调度器]
    S --> P1[Prefill 实例组]
    P1 -->|KV cache| K[KV 传输层]
    K --> D1[Decode 实例组]
    D1 --> O[流式输出]

    subgraph ComputeBound[计算密集资源池]
        P1
    end

    subgraph MemoryBound[访存密集资源池]
        D1
    end

拆开之后，Prefill 和 Decode 可以分别优化：

PD 分离不是免费午餐。它引入了 KV cache 跨设备传输成本，所以网络带宽、传输时机、KV cache 布局都会影响收益。只有当 Prefill 和 Decode 的资源错配足够明显，并且网络能够承载 KV 传输时，PD 分离才会带来稳定收益。

1.3 动态 PD：解决生产者和消费者失衡

固定比例的 PD 分离在真实业务里会遇到混合长度请求的问题。短 prompt、长 prompt、短回答、长回答混在一起时，Prefill 和 Decode 的负载很容易失衡。

举个例子：

• 大量短输入、长输出请求：Prefill 很快完成，Decode 长时间忙碌。
• 大量长输入、短输出请求：Prefill 压力很大，Decode 反而空闲。
• 突发长上下文请求：KV cache 传输和显存占用突然增加。

动态 PD 的核心是根据短期负载预测和实时资源监控，自动调整 Prefill 实例和 Decode 实例的比例。

flowchart TB
    M[资源监控器] --> SCH[请求调度器]
    M --> IM[P/D 实例管理器]
    M --> RT[请求路由器]

    Req[用户请求] --> RT
    RT -->|选择 Decode 目标实例| D[Decode 集群]
    RT -->|需要远端预填充| P[Prefill 集群]

    P --> KV[KV 通信连接器]
    KV --> D

    SCH -->|分组与批处理策略| RT
    IM -->|调整实例数量与并行度| P
    IM -->|调整实例数量与并行度| D

一个动态 PD 系统通常需要具备四类能力：

动态 PD 特别适合负载波动大、请求长度差异明显的在线推理服务。它的关键不只是“扩容”，而是要在极低调度开销下做出足够好的比例判断，否则调度本身也会变成延迟来源。

1.4 AFD：把 Attention 和 FFN 也拆开

PD 分离是在推理阶段维度上拆分，AFD（Attention-FFN Disaggregation，注意力模块与前馈网络模块解耦）则是在模型模块维度上继续拆分。

大多数 Transformer 模型层可以粗略拆成两块：

• Attention（注意力模块）：参数量相对较少，但需要频繁访问 KV cache，访存和通信压力更大。
• FFN（Feed Forward Network，前馈网络）：参数量大，矩阵计算重，偏计算密集。

flowchart LR
    X[输入 hidden states] --> A[Attention 实例]
    A -->|中间激活| N[高速网络]
    N --> F[FFN 实例]
    F --> Y[输出 hidden states]

AFD 的做法是把 Attention 和 FFN 部署在不同设备上。例如 Attention 放在更适合 KV cache 访问的设备上，FFN 放在更适合大规模矩阵计算的设备上。这样可以让硬件选型更灵活，也可以降低对单一高端 GPU 的依赖。

AFD 的收益来自资源匹配，但代价是模块之间需要传输中间激活。系统设计时必须平衡三件事：

如果网络传输时间超过了计算节省，AFD 的收益会被抵消。因此 AFD 通常需要和模型结构、量化方案、网络拓扑一起设计。

1.5 跨机专家并行：MoE 通信不能只靠通用集合通信

MoE 模型里的专家数量可能非常大，单机无法容纳全部专家。专家并行 EP（Expert Parallel）会把不同专家放到不同 GPU 或不同机器上，请求中的 token 被路由到对应专家计算。

MoE 的通信模式和普通 dense 模型不一样。它不是所有 GPU 都交换全量数据，而是只把 token 发给被激活的专家。

flowchart LR
    T1[token A] --> G[门控路由]
    T2[token B] --> G
    T3[token C] --> G

    G -->|A,C| GPU1[GPU 1: 专家 1/2]
    G -->|B| GPU2[GPU 2: 专家 3/4]
    G -.无数据.-> GPU3[GPU 3: 专家 5/6]

NCCL（NVIDIA Collective Communications Library）擅长密集、规则的集合通信，例如 AllReduce、AllGather。但 MoE 的 all-to-all 更稀疏、更不均匀，只靠通用通信库容易浪费带宽。

DeepEP 是面向 MoE 专家并行的通信库，针对稀疏专家路由做了优化。它的重点能力包括：

IB 网络下的 RDMA 通常延迟和稳定性更好，但很多数据中心使用 RoCE。RoCE 对网络配置、拥塞控制、丢包更敏感，所以 MoE 通信库在 RoCE 上需要额外优化。TRMT 这类网络侧优化的价值就在于让 DeepEP 这样的稀疏通信库在 RoCE 环境里也能接近可用的高性能状态。

2. 面向 Tile 的开发语言：把算子优化从线程细节里解放出来

训练和推理性能很大程度取决于底层算子。矩阵乘法、Attention、归一化、量化、反量化这些算子如果写得不好，上层系统调度再复杂也很难跑快。

传统 GPU 算子开发需要处理大量底层细节：

• thread、block、grid 怎么组织；
• 数据如何从全局内存搬到共享内存；
• Tensor Core 如何利用；
• tile 大小怎么选；
• pipeline 怎么安排；
• 不同硬件架构怎么适配。

这些细节和性能强相关，但也让开发门槛很高。TileLang 的核心思路是：开发者描述 tiled dataflow，编译器负责调度和优化。

2.1 Tile 是什么

Tile 可以理解成把大矩阵切成一块一块的小矩阵。GPU 计算时不会一次性把整个矩阵搬进高速缓存，而是分块读取、分块计算、分块写回。

矩阵乘法 C = A x B 的 tiled 计算可以表示成：

flowchart LR
    A[A 矩阵分块] --> Load[加载 tile 到高速缓存]
    B[B 矩阵分块] --> Load
    Load --> MMA[Tensor Core / MMA 计算]
    MMA --> Acc[累加到 C tile]
    Acc --> Store[写回 C 矩阵]

TileLang 希望把“算什么”和“怎么调度”分开。开发者只需要描述计算的数据流，编译器根据硬件自动生成更合适的执行计划。

一个接近 TileLang 思路的矩阵乘法伪代码如下：

# 伪代码：表达 tiled dataflow，而不是手写底层线程调度

def matmul(A, B, C, M, N, K):
    tile_m = 128
    tile_n = 128
    tile_k = 32

    for bm, bn in grid(M // tile_m, N // tile_n):
        acc = zeros(tile_m, tile_n)

        for bk in pipeline(K // tile_k):
            a_tile = load(A, bm, bk, shape=(tile_m, tile_k))
            b_tile = load(B, bk, bn, shape=(tile_k, tile_n))
            acc += mma(a_tile, b_tile)

        store(C, bm, bn, acc)

这段代码表达了三件事：

1. 矩阵按 tile 切分；
2. 每个 tile 进入流水线；
3. 使用矩阵乘法累加后写回。

至于线程如何映射、共享内存如何分配、流水线深度如何选择，可以交给编译器或更底层的调度系统。

2.2 三种编程层级

TileLang 的设计并不是只服务初学者，它允许不同水平的开发者在不同抽象层级工作。

这种分层很重要。AI Infra 里的算子变化很快，如果每个新算子都要完全手写 CUDA，迭代成本会很高；但完全自动生成又可能达不到极致性能。TileLang 提供的是一条中间路线：简单算子快速写，关键算子可以逐层下探优化。

3. RL 训推分离：强化学习的数据管线也需要系统设计

强化学习训练里的数据通常来自模型自己推理生成。例如模型先生成回答、执行工具调用、获得奖励信号，再把这些轨迹送回训练过程。

如果训练和推理部署在同一集群里，系统搭建会简单一些，但问题也明显：

训推分离把 trainer 和 rollout/inference worker 拆开，各自独立优化。不过分离之后会出现两个新问题：数据一致性和算力空泡。

3.1 数据交互平面：记录完整轨迹

Agent 场景里的推理并不只是“输入 prompt，输出文本”。模型可能会调用工具、读取记忆、访问环境、修改中间状态，再继续生成下一步动作。训练需要的不是单次输入输出，而是完整轨迹。

一个可行的做法是在 Agent 和 LLM（Large Language Model，大语言模型）之间加入数据交互平面，由轨迹管理器记录全过程。

sequenceDiagram
    participant A as Agent
    participant T as 轨迹管理器
    participant L as LLM 推理服务
    participant E as 外部环境/工具
    participant R as 训练系统

    A->>T: 发起模型调用
    T->>L: 转发 prompt 和上下文
    L-->>T: 返回模型输出
    T-->>A: 返回结果
    A->>E: 调用工具或环境
    E-->>A: 返回观察结果
    A->>T: 继续下一步调用

    T-->>R: 输出完整轨迹数据

轨迹管理器需要记录：

• 每次模型调用的输入；
• 模型输出；
• 工具调用参数；
• 工具返回结果；
• Agent 中间状态；
• 奖励或反馈信号；
• 时间顺序和依赖关系。

这个平面对 Agent 应该尽量透明，否则 Agent 逻辑会被训练数据采集强行侵入，系统复杂度会迅速上升。

3.2 标签调度：减少训练和推理之间的算力空泡

训推一体的优势是资源可以天然复用，但代价是耦合。训推分离的优势是独立优化，但容易出现“训练等推理数据”或“推理等训练消费”的空泡。

标签调度的思路是不把资源永久绑定为训练或推理，而是给资源打标签，让一部分资源可以在不同任务之间切换。

flowchart LR
    Q[任务队列] --> TS[标签调度器]

    TS -->|train 标签| G1[训练资源池]
    TS -->|rollout 标签| G2[推理资源池]
    TS -->|flex 标签| G3[弹性资源池]

    G3 -->|训练数据不足时| G2
    G3 -->|推理数据堆积时| G1

这种机制的关键是“灵活但不混乱”。资源切换需要考虑模型权重加载、缓存状态、任务中断恢复和数据一致性。如果切换成本太高，调度收益会被抵消。

4. 模型-系统协同设计：模型结构不能脱离硬件

很多优化是在模型确定之后做系统适配，例如改推理框架、改通信库、改并行策略。模型-系统协同设计则提前一步：模型结构设计时就考虑硬件算力、显存带宽、网络带宽和部署成本。

4.1 算术强度和 Roofline

算术强度可以理解成：

算术强度 = 计算量 / 访存字节数

也就是每从显存读写 1 字节数据，平均能做多少次计算。

硬件也有一个固定比例：

硬件算力-带宽比 = 峰值计算能力 / 显存带宽

这个比例常被放在 Roofline 模型里分析。模型模块的算术强度和硬件比例之间的关系决定了瓶颈位置。

Attention 模块的设计会影响算术强度。如果模型的 Attention 算术强度能接近目标硬件的 Roofline，推理效率通常更容易做上去。

4.2 量化会改变算术强度

量化不是单纯把模型变小。不同模块采用不同精度，会改变计算量、访存量和通信量，从而改变算术强度。

例如：

因此模型设计时要考虑量化后的硬件匹配关系，而不是只在部署阶段临时套一个量化方案。

4.3 MoE 稀疏度、BatchSize 和网络带宽的权衡

对 MoE 的 FFN 模块来说，计算效率和 BatchSize、稀疏度、硬件算力、带宽都有关系。一个简化理解是：如果想让特定硬件跑得更满，可以增大 BatchSize，也可以提高 MoE 激活稀疏度。

但在 AFD 架构下，BatchSize 过大又会增加 Attention 和 FFN 之间的网络传输时间，最终拖慢 TPOT。

可以把约束关系整理成：

S / (H * L) >= FLOPs / (Net * Bandwidth * β)

其中：

这个式子表达的不是单个参数越大越好，而是模型结构和系统能力要匹配：

• 硬件算力越强，网络也要跟得上；
• 模型层数和隐藏维度越大，通信与访存压力越高；
• 稀疏度提高可以降低激活计算，但也会带来更复杂的专家路由和负载均衡问题；
• 目标 TPOT 越激进，对流水线和网络的要求越高。

模型-系统协同设计的重点就在这里：模型不是纸面上的参数集合，它最终要落在具体硬件和具体网络上运行。

5. Agent Infra：从“模型会回答”到“系统能执行”

Agent 和普通聊天机器人最大的区别在于：Agent 不只是生成文本，还会规划步骤、调用工具、执行代码、读取文件、访问外部系统，并根据结果继续决策。

这让 Agent Infra 需要处理的问题远超普通推理服务。

5.1 Workflow 和 Agent 的区别

Workflow 适合步骤确定、分支有限的任务；Agent 适合路径不固定、需要动态决策的任务。

flowchart TB
    subgraph W[Workflow]
        W1[步骤 A] --> W2{条件判断}
        W2 --> W3[步骤 B]
        W2 --> W4[步骤 C]
    end

    subgraph A[Agent]
        A1[理解目标] --> A2[选择工具]
        A2 --> A3[观察结果]
        A3 --> A4{是否完成}
        A4 -->|否| A2
        A4 -->|是| A5[输出结果]
    end

主流 Agent 框架可以按控制方式和适用场景粗略对比：

5.2 MCP：让 Agent 用统一协议连接工具

MCP（Model Context Protocol，模型上下文协议）定义了 AI 应用和外部工具、数据源之间的交互标准。它解决的是“模型怎么以统一方式调用外部能力”的问题。

MCP 里通常有三个角色：

flowchart LR
    H[MCP Host<br/>IDE/桌面应用/Agent 平台] --> C[MCP Client]
    C --> S1[MCP Server<br/>数据库]
    C --> S2[MCP Server<br/>文件系统]
    C --> S3[MCP Server<br/>企业 API]
    C --> S4[MCP Server<br/>浏览器/搜索]

MCP 和 Function Calling 的区别可以这样理解：

Function Calling 更像模型 API 的一部分；MCP 更像 Agent 生态里的工具连接层。

5.3 Skills 和 MCP：一个教方法，一个接工具

Agent Skills 和 MCP 经常一起出现，但它们解决的问题不同。

• Skills：告诉 Agent “怎么做”，封装专业知识、流程、判断逻辑。
• MCP：告诉 Agent “用什么做”，连接外部工具、数据和系统能力。

Skills 的风险容易被低估，因为它常表现为本地文本文件或脚本，看起来不像“远程服务”。但一旦 Skill 被 Agent 激活，它可能引导 Agent 执行 Bash 脚本、读取本地文件、修改配置，甚至建立后门连接。

需要重点防范三类问题：

5.4 Agent 沙箱：容器、虚拟机和 Serverless 都不完美

Agent 经常要执行模型生成的代码，而这些代码默认不可信。它可能有 bug，也可能被提示注入诱导执行危险操作。运行环境必须同时满足隔离性、启动速度、状态保持和审计能力。

传统方案各有问题：

Agent 运行环境需要具备这些能力：

一个更适合 Agent 的沙箱架构通常会接近下面这种形态：

flowchart TB
    U[用户请求] --> A[Agent 服务]
    A --> P[策略与权限控制]
    P --> S[沙箱管理器]

    S --> M1[微虚拟机/轻量沙箱 1]
    S --> M2[微虚拟机/轻量沙箱 2]
    S --> M3[微虚拟机/轻量沙箱 3]

    M1 --> FS[持久化文件系统]
    M2 --> FS
    M3 --> FS

    M1 --> OBS[日志/命令/网络审计]
    M2 --> OBS
    M3 --> OBS

可行的工程方向包括：

• 使用轻量虚拟化或独立 Guest Kernel 获得更强隔离；
• 用快照和镜像预热降低冷启动；
• 用暂停/恢复机制降低闲置成本；
• 让业务逻辑和代码执行环境物理隔离；
• 对网络访问、文件读写、命令执行做细粒度审计；
• 通过共享文件系统或挂载卷保留跨轮次状态。

Agent Infra 的难点不在单个沙箱，而在大规模、多租户、低延迟、低成本地管理这些沙箱。

6. 超节点硬件：更大的高带宽 GPU 域

训练和推理都越来越依赖跨卡通信。RDMA 能解决跨机通信问题，但 GPU 之间的专有高速互联通常延迟更低、带宽更高。超节点的目标是让更多 GPU 处在同一个高带宽域里，形成一个“超大 GPU”。

flowchart TB
    subgraph SuperNode[超节点高带宽域]
        G1[GPU] --- G2[GPU]
        G2 --- G3[GPU]
        G3 --- G4[GPU]
        G4 --- G5[GPU]
        G5 --- G6[GPU]
        G6 --- G1
    end

    SuperNode --> NET[跨节点 RDMA 网络]
    NET --> Other[其他超节点]

以 NVIDIA Vera Rubin NVL144 这类形态为例，单域可以包含 144 颗 Rubin GPU，并提供极高的域内互联带宽。它的意义不是“卡更多”这么简单，而是让大规模模型并行、长上下文推理和专家通信有更低的通信成本。

6.1 长上下文推理为什么需要超节点

上下文长度增长会显著放大推理压力：

当上下文长度达到数十万甚至百万 token，单卡或小规模节点很难同时满足显存、算力和带宽需求。PD 分离、AFD、KV cache 分层管理和高带宽超节点会组合使用。

一种长上下文推理部署可以抽象成：

flowchart LR
    Req[长上下文请求] --> P[Prefill 资源池]
    P -->|大量 KV cache| HB[超节点高带宽域]
    HB --> A[Attention 资源池]
    A --> F[FFN 资源池]
    F --> D[Decode 输出]

超节点提供的是底层互联能力，上层系统仍然需要做好：

• Prefill 和 Decode 拆分；
• KV cache 放置与迁移；
• Attention 和 FFN 的模块级解耦；
• 长短请求混部调度；
• 多租户隔离和资源配额。

硬件互联越强，系统可以采用的并行策略越丰富；但如果上层调度和模型结构不匹配，高带宽也可能被低效通信浪费掉。

六个方向之间的关系

这六个方向不是彼此孤立的点，而是一张互相影响的系统网。

flowchart TB
    M[模型结构<br/>MoE / Attention / FFN / 长上下文] --> I[分布式推理<br/>PD / AFD / EP]
    M --> C[模型-系统协同设计<br/>算术强度 / 稀疏度 / 量化]
    C --> H[硬件基础设施<br/>超节点 / 高带宽互联]
    H --> I

    K[算子与编译<br/>TileLang] --> I
    K --> C

    R[RL 训推分离] --> I
    R --> A[Agent Infra]

    A --> I
    A --> S[沙箱 / 工具协议 / 状态管理]

可以按层次理解：

AI Infra 的主线正在从“更大的集群”转向“更精细的匹配”：计算密集的模块放到适合计算的硬件上，访存密集的模块放到适合带宽的硬件上，稀疏通信用专门通信库处理，Agent 执行放进强隔离沙箱，模型结构在设计阶段就对齐目标硬件。

参考资料

1. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving
   https://arxiv.org/pdf/2401.09670

2. DOPD: A Dynamic PD-Disaggregation Architecture for Maximizing Goodput in LLM Inference Serving
   https://arxiv.org/pdf/2511.20982

3. Step-3 is Large yet Affordable: Model-system Co-design for Cost-effective Decoding
   https://arxiv.org/pdf/2507.19427

4. DeepEP: an efficient expert-parallel communication library
   https://github.com/deepseek-ai/DeepEP

5. TileLang: A Composable Tiled Programming Model for AI Systems
   https://arxiv.org/pdf/2504.17577

6. SeamlessFlow: A Trainer-Agent Isolation RL Framework Achieving Bubble-Free Pipelines via Tag Scheduling
   https://arxiv.org/pdf/2508.11553

7. NVIDIA Rubin CPX Accelerates Inference Performance and Efficiency for 1M+ Token Context Workloads
   https://developer.nvidia.com/blog/nvidia-rubin-cpx-accelerates-inference-performance-and-efficiency-for-1m-token-context-workloads/