从手工调参到 AI Systems Optimizer：LLM Infra 联合优化的学术脉络

整理日期：2026-09-16。问题起点是：当推理、训练、RL 同时引入 TP/DP/EP/PP/CP、KV/activation/optimizer state、offload、阶段分离、通信 overlap、动态调度以后，系统变量会相互耦合。学术界是否正在形成更统一的方法，而不是继续依赖工程师手工拼装策略？

核心判断

当前研究趋势已经从“继续发明单点机制”逐渐转向三个更高层的问题：

自动选择并行与布局策略；
用性能模型/模拟器预测复杂执行计划的成本；
在运行时根据 workload、拓扑和系统状态动态调整计划。

因此，未来 LLM Systems 很可能出现类似数据库 Query Optimizer 的 AI Systems Optimizer：用户给出模型、硬件、workload 与 SLO，系统自动生成 parallelism、placement、memory、communication、kernel 和 scheduling plan。

这个判断属于趋势推演，不代表今天已经存在一个统一成熟的“LLM 查询优化器”。

一、为什么人工组合会失控

不同优化维度并不是正交的。

例如：

TP 增大可降低单卡参数/计算压力，但会增加 collective 通信并改变 GEMM shape；
PP 增大可降低单 stage 模型规模，但会引入 pipeline bubble；
CP/DCP 可分摊长上下文状态，却会增加跨卡 Attention/KV 通信；
EP 可分散专家参数，却会把瓶颈转向 All-to-All 与负载均衡；
activation checkpoint 用计算换显存，会改变 forward/backward 时间比例；
quantization 改变 bandwidth、kernel availability 和通信 payload；
disaggregation 改善资源隔离和独立扩缩容，却把本地状态访问变成网络传输。

因此真正的问题不是“哪个策略最好”，而是：

给定模型结构、输入长度分布、显存、算力、网络拓扑与目标函数，哪组策略的组合最优？

这已经是一个典型的高维组合优化问题。

二、第一条脉络：自动并行化

Alpa：把并行策略变成编译问题

Alpa 将大模型并行抽象成两层：intra-operator parallelism 与 inter-operator parallelism，自动生成涵盖数据、算子和 pipeline 并行的执行计划。

它的重要意义不只是某一种具体搜索算法，而是提出了一个方向：

Model Program
    ↓
Parallelization Search Space
    ↓
Compiler / Cost Model
    ↓
Distributed Execution Plan

即并行不一定应该由用户直接写死。

Galvatron：在 Transformer 上搜索混合并行

Galvatron 针对 Transformer 的多种 parallelism 组合进行自动搜索，并利用剪枝/动态规划在巨大搜索空间中寻找高吞吐方案。

其研究意义可以概括为：DP/TP/PP 等不再是互相独立的命令行参数，而是一个统一优化空间中的变量。

三、第二条脉络：Performance Model 与 Simulator

要自动选策略，系统必须先能回答：

如果选择方案 A，它到底会比方案 B 快多少？

这推动了性能建模和模拟器研究。

Proteus：把复杂并行策略编译成执行图再模拟

Proteus 使用统一的 Strategy Tree 表达复杂并行策略，再生成 distributed execution graph，并模拟：

compute；
communication；
compute-communication overlap；
bandwidth sharing；
topology。

论文报告在其评估范围内约 3.0% 平均预测误差。更重要的是，它展示了一个未来 optimizer 必需的基础设施：不是只估 FLOPs，而是模拟实际分布式运行行为。

ASTRA-sim：进一步走向软硬件协同设计

ASTRA-sim 将 workload、collective、network、compute/memory 等层次分开建模，适合探索网络拓扑、collective 算法和 accelerator cluster 的 co-design。

这意味着未来 optimizer 不只优化软件参数，也可能同时回答：

当前模型更适合哪种网络拓扑？
哪种 collective algorithm 更适合当前层？
增加 HBM、带宽还是更多芯片更有效？

四、第三条脉络：从静态配置走向阶段化、动态化

DistServe：Prefill 与 Decode 不应该共享同一套资源计划

LLM serving 中 Prefill 更偏 compute-bound，Decode 往往更受 memory/KV 和 latency 影响。DistServe 的核心思想之一就是对 P/D 阶段分别进行资源配置和并行规划。

这代表一个重要转变：

过去：一个模型 = 一套 parallel config
未来：一个模型的不同阶段 = 不同 physical plan

这也是 PD 分离背后的更一般思想。

ByteScale：Parallelism 可以成为数据相关的 Runtime 决策

长上下文训练中，样本长度高度不均匀。ByteScale 指出静态 DP × CP mesh 会造成短样本的冗余通信和长样本的负载失衡，因此提出 Hybrid Data Parallelism 与 dynamic mesh，根据数据特征动态组织设备。

其论文在最长 2048K context、超过 12,000 GPU 的生产集群上进行评估。

更值得记住的不是这个具体数字，而是结论：

并行策略可能从“模型静态配置”演变为 workload-aware runtime decision。

以后 TP=8, CP=4 这种配置未必应该在进程启动后永久不变。

五、推理系统正在出现 OS 式抽象

LLM Serving 也在逐渐长出传统操作系统的概念映射：

OS concept              LLM runtime
process                  request / sequence
virtual memory           paged KV cache
page migration           KV migration / offload
scheduler                request scheduler
NUMA/topology            accelerator placement
swap/tiering             KV offload / remote cache

这解释了为什么 PagedAttention、KV Pool、Mooncake、live migration 等方向会越来越像“为模型状态建立虚拟内存与分层存储系统”。

长期看，被 runtime 管理的对象可能不止 KV，还包括：

weights；
activations；
gradients；
optimizer states；
LoRA/adapters；
rollout trajectories；
prefix state。

对应的存储层级可能跨越 HBM、host DRAM、CXL/remote memory、NVMe 与 distributed store。

六、RL Infra 是 Algorithm-System Co-design 最明显的试验场

RL 系统不只是“训练系统再加一个 PPO”。它同时包含：

Rollout / Inference
       ↓
Reward / Verifier
       ↓
Training
       ↓
Weight Sync
       ↓
New Rollout

因此同时继承推理和训练的系统问题，并新增：

rollout/train placement；
weight synchronization / resharding；
policy staleness；
async pipeline；
backpressure；
environment/tool latency；
trajectory scheduling。

HybridFlow：为 RLHF 建立分层系统抽象

HybridFlow 观察到 RLHF dataflow 中，每一个逻辑节点本身已经是一个分布式训练或生成程序，每条边也可能是 many-to-many communication。因此它用 hierarchical APIs 解耦逻辑计算、数据依赖与物理映射，并设计 3D-HybridEngine 处理 actor 在 training/generation layout 之间的 resharding。

这个方向与数据库中的：

Logical Plan
    ↓
Physical Plan

非常类似。

AReaL：异步提高利用率，但会反过来改变 RL 算法

AReaL 将 generation 和 training 完全异步化，以减少同步 rollout 中等待最长样本造成的 GPU 空转；同时必须控制 data staleness，并使用适配 stale samples 的 PPO 变体。

这揭示了一个非常重要的事实：

在 RL 中，系统优化可能改变样本新鲜度和数据分布，因此系统设计会反过来影响优化算法本身。

这就是典型的 Algorithm-System Co-design。

七、未来的统一 AI Systems Optimizer 可能长什么样

下面是对未来 3～5 年研究方向的推演，而非已经完成的标准架构：

           Model / RL Program
                   │
                   ↓
            Declarative IR
                   │
       ┌───────────┼────────────┐
       │           │            │
   Hardware     Workload       SLO
   topology      profile      target
       │           │            │
       └───────────┼────────────┘
                   ↓
               Optimizer
                   │
    ┌──────────────┼──────────────┐
    │              │              │
Parallelism     Placement       Memory
TP/DP/EP/...    GPU/node       KV/state
    │              │              │
    ├──── Communication ──────────┤
    └──── Scheduling / Kernel ────┘
                   │
                   ↓
            Execution Plan
                   │
                   ↓
               Runtime
                   │
                   ↓
              Telemetry
                   │
                   └──── feedback → Optimizer

单纯的 offline optimizer 很可能不够，因为真实 workload 会动态变化：sequence length、output length、expert load、network congestion、GPU failure、RL environment latency 都不是常数。因此更现实的终局可能是：

cost-based optimizer + online adaptive scheduler + telemetry feedback loop。

八、尚未解决的核心研究问题

1. Unified IR

如何统一表示推理、训练和 RL 中的 compute、state、communication、placement 与 synchronization，而又不过度抽象掉硬件关键差异？

2. Cost Model

如何同时预测 compute、HBM、network、contention、overlap、kernel shape 与动态 workload？仅用 FLOPs 或理论带宽显然不够。

3. Search Space Explosion

TP × DP × EP × CP × PP × quantization × placement × kernel × cache × scheduler 的组合空间极大，需要 decomposition、heuristic、dynamic programming、learning-based search 或在线 adaptation。

4. Disaggregation Boundary

P/D、Attention/FFN、Rollout/Train 都能拆，但每次拆分都把 local memory access 变成网络传输。真正需要求解的是：哪条 boundary 的资源解耦收益大于 state movement 成本？

5. Dynamic Parallelism

并行配置能否随 batch、序列长度和网络状态动态改变，同时保证切换代价足够低？

6. Algorithm-System Co-design

尤其在 RL 中，async、staleness、sample selection、weight lag 会直接影响学习动态。未来系统论文和算法论文的边界可能继续模糊。

九、适合当前阶段的研究实践

不需要立即实现一个完整 optimizer。可以从一个小问题建立研究能力：

选一个固定模型和硬件拓扑；
只研究 TP/CP 或 TP/EP 两个维度；
测量 compute time、collective time、HBM 占用、通信 overlap；
建一个简单 analytical cost model；
用真实 profiling 验证误差；
再加入 sequence length distribution、quantization 或 placement；
最后比较 CUDA 与 Ascend 上 cost model 哪些假设失效。

这条路线能把“会配置 vLLM”升级成“能解释和预测一个执行计划为什么快”，是走向系统研究更关键的能力。

知识联系

学习路线：如何分层学习推理 Infra：从 CUDA 基线到昇腾，再到训练与 RL
RL 系统入口：verl 入门：连接大模型强化学习后训练与推理系统
多硬件抽象：vLLM 多硬件后端抽象：为什么 PyTorch 支持设备还不等于推理框架支持设备