训练、推理与分离式系统：工作负载的系统观
更多 GPU 缩短计算时间的前提，是通信、输入和同步跟得上；工作负载的形状决定平台的形状。
训练是一个同步问题
训练不只是前向传播，它是一个不断循环的链条：输入准备、前向计算、反向计算、梯度同步、优化器更新、检查点、评估，任何一个环节都可能成为主导。这正是互连与集合通信中扩展效率方程的应用场景：先测单卡、再测单机、最后测多机，才知道瓶颈在哪一环。
检查点不是事后想法。如果一个作业要跑一周，恢复契约就是硬件决策的一部分。
推理是一个尾延迟问题
推理服务关心排队、批处理、token 生成、上下文长度、预热、模型加载和尾延迟。GPU 可能利用率很高，而用户可感知的延迟已经违反 SLO，仅按平均利用率自动伸缩，可能反应太迟或太早。
| 信号 | 回答什么 |
|---|---|
| 队列深度 | 请求在等什么 |
| 首 token 时间（TTFT） | 用户等多久看到第一个字 |
| token 间延迟（ITL） | 生成过程是否流畅 |
| 活跃序列数 | 批处理压力 |
| KV 缓存压力 | 上下文容量还剩多少 |
| 模型加载时间 | 扩容/故障恢复的速度 |
这些信号的物理根因展开见LLM 推理的物理层，指标口径见GPU 指标语义。
模型、数据与控制平面
一个生产 AI 平台把模型工件和缓存与请求服务的 Pod 分开：它定义模型如何到达、如何校验、引擎在哪里构建、权重如何缓存、版本如何滚动、故障节点如何预热。这正是 Kubernetes 开始像 AI 应用平台而非通用容器调度器的地方。
| 平面 | 主要关切 | 有用信号 |
|---|---|---|
| 模型 | 权重、画像、引擎、版本 | 缓存命中、加载时间、摘要 |
| 服务 | 流量、批处理、副本、延迟 | TTFT、ITL、队列深度、吞吐 |
| 加速器 | GPU 分配、内存、拓扑 | 利用率、余量、错误 |
| 数据 | 数据集搬运与局部性 | 读带宽、缓存命中、I/O 等待 |
| 控制 | 发布、策略、自动伸缩、恢复 | 调谐与准入状态 |
这张表与生产架构的平面划分互补：那里讲集群治理平面，这里讲工作负载侧平面。
多节点推理
超大模型可能被切分到多块 GPU 或多个节点。系统因此继承训练同样的互连与拓扑问题，但 SLO 是请求路径而非批次时间。一个吞吐上看起来不错的设计，如果同步或网络抖动出现在关键路径上，仍可能有不可接受的尾延迟。预填充/解码分离（PD 分离）正是这一约束下的产物，见Kthena与LLM 推理物理层的讨论。
总结
训练问“每步同步花了多少”，推理问“第 99 个百分位的请求等了多久”，多节点系统问“关键路径上有几次跳变”。用这三问审视工作负载，再选平台组件，顺序不能反。本章是工作负载实践部分的序章：接下来三章（vLLM、PyTorch、Ray）分别把这三种系统观落到具体引擎。