AI Infra 全景图¶

AI Infra 的目标不是“把 GPU 管起来”这么单一，而是让数据、模型和请求在给定的硬件与预算约束下，稳定地转化为可度量的训练或推理产出。

三层系统模型¶

flowchart TB
    subgraph Workload[工作负载层]
      T[预训练 / 微调] --- I[在线 / 离线推理]
      I --- E[评测 / RAG / Agent]
    end
    subgraph Platform[平台与控制面]
      O[编排与调度] --- M[模型与数据生命周期]
      M --- R[发布 / 弹性 / 可观测]
    end
    subgraph Foundation[资源与数据面]
      G[GPU / CPU] --- N[网络与互连]
      N --- S[对象 / 文件 / 本地存储]
    end
    Workload --> Platform --> Foundation

层	关键对象	主要问题
工作负载	step、batch、sequence、request、token	目标是吞吐、时延、质量还是成本？
平台	job、pod、queue、model revision、endpoint	如何调度、隔离、发布、恢复和扩缩？
资源	GPU、NIC、NVLink、内存、磁盘	哪个资源成为瓶颈，拓扑是否匹配？

两条主路径¶

训练路径推理路径

数据准备 → 加载 → 前向 → 反向 → 梯度同步 → 参数更新 → 检查点

核心单位通常是 step。关注 samples/s、tokens/s、step time、MFU、扩展效率、失败恢复时间和单位训练成本。

接入 → 排队 → 调度/批处理 → Prefill → Decode → 流式返回

核心单位通常是 request 与 token。关注 TTFT、TPOT/ITL、端到端 P95/P99、goodput、队列深度和每百万 token 成本。

必须同时看的三笔账¶

显存账：模型权重、梯度、优化器状态、激活、KV Cache、临时 workspace 分别占多少。
带宽账：每一步或每个 token 需要跨 HBM、NVLink/PCIe、网络、存储移动多少数据。
时间账：排队、计算、通信、I/O、同步与失败恢复各占端到端时间多少。

系统优化的基本顺序

先明确 SLO 和工作负载，再用观测证据定位主瓶颈；避免看到 GPU 利用率低就直接增加 batch，因为根因可能是数据等待、同步阻塞、碎片化或请求形状差异。

平台能力清单¶

资源供给：驱动、运行时、镜像、设备插件、拓扑标签、配额。
工作负载编排：队列、gang scheduling、优先级、抢占、弹性与容错。
数据模型管理：数据版本、制品仓库、模型缓存、检查点与血缘。
服务工程：网关、路由、批处理、限流、灰度、回滚与自动扩缩。
运营治理：可观测、SLO、成本归属、权限、审计、密钥与供应链安全。

判断一个设计是否成熟¶

用以下问题快速评审：

正常路径的容量上限如何计算、如何压测验证？
单 GPU、单节点、单可用区故障分别如何表现和恢复？
模型加载、扩容和滚动升级是否会冲击延迟？
多租户之间如何防止资源争抢和数据越权？
指标是否能从请求关联到模型副本、Pod、节点和 GPU？
单位 token 或训练任务的资源成本能否解释？