AI Infra

条目状态与系统位置

本图覆盖 Infra / control plane / data plane，不是一个单一技术层。可点击条目是独立文章；“未单列”表示由工具或性能文章承载；“待建”表示当前没有独立实现笔记。

两条互相约束的因果链

硬件/网络/存储
→ kernel 与框架
→ 并行执行/通信
→ 训练或推理 engine
→ serving 与 LLMOps

用户 SLO/成本
→ batching、量化、并行和副本策略
→ 需要的 GPU/网络/存储
→ 集群调度与可观测性

第一条从底向上解释“能不能跑、跑多快”，第二条从上向下解释“为什么值得这样跑”。控制平面的 Ray/Kubernetes 不替代数据平面的 PyTorch、kernel 或 engine。

总览

1. 硬件与集群

GPU / HBM、CPU / RAM（未单列：作为资源账本）
NVLink、PCIe、RDMA / InfiniBand、Storage（未单列：作为通信/存储边界）
Kubernetes、Volcano、GPU scheduling（Volcano/GPU scheduling 待建）

2. 框架、Kernel 与编译器

PyTorch、torch.compile / TorchDynamo
Triton Language、FlashAttention、FlashInfer、CUTLASS、CUDA Graph（后四者待建）
注意：Triton Language ≠ NVIDIA Triton Inference Server；TorchDynamo ≠ NVIDIA Dynamo。

3. 分布式执行与通信

Ray（Ray Core / Data / Train / Serve 未单列）
Data Parallelism、TP、PP、EP
NCCL、DeepEP、KV transfer（待建；KV transfer 先见 How PD Disaggregation Transfers KV）

4. 训练与推理引擎

DeepSpeed、Megatron、FSDP、verl / OpenRLHF（后四者待建）
vLLM、SGLang、TensorRT-LLM
llama.cpp、Ollama（本地/边缘推理）
GGUF（文件容器层）
LLM Inference Optimization Map、LLM Quantization Deployment

5. Serving 与 LLMOps

API Gateway、routing、autoscaling、multi-model serving（未单列：见 MOC - Serving and LLMOps）
trace、evaluation、prompt/model version、cost、regression（未单列：见 MOC - Serving and LLMOps）
MOC - Serving and LLMOps

两个平面

数据计算平面：PyTorch、vLLM、CUDA/Triton、GPU 真正执行计算。
控制平面：Ray、Kubernetes、Serving 与 LLMOps 组织任务、资源和生命周期。

一次性能故障如何穿过七层

例如线上 TTFT 突然升高，不应直接在第 2 层换 kernel：

应用/网关：到达率、限流、租户突发
→ Serving：队列、路由、冷启动、readiness
→ Engine：prefill/decode 配额、KV block、抢占
→ 并行层：TP/PP/EP collective、rank 等待
→ Framework/kernel：shape、dtype、launch gap、带宽
→ 硬件/集群：HBM、PCIe/NVLink、RDMA、节点供给

每一层都可能把“等待”转成下一层看似的低利用率。比如 K8s 已扩容但权重未 warmup，engine 没有可用副本；GPU 利用率不高但请求在 queue 中，重写 Triton 不会改变 TTFT；TP 计算变快却被慢 RDMA rank 拖住，增加 GPU 数反而恶化 P99。

设计系统时先写跨层契约

硬件层要暴露拓扑、带宽和资源类型；调度层要保证 gang placement、rank 映射和隔离；engine 要暴露 queue/KV/抢占/取消；serving 要把这些状态映射到租户 SLO、扩缩容和回滚；LLMOps 再把模型/数据/提示版本与质量回归关联。缺一层，问题就会在边界处变成“服务偶尔慢”而无法定位。

阅读本地图时按“目标 SLO → 所需资源 → 执行机制 → 观测字段 → 故障恢复”反向走一遍，而不是把七层当作需要逐一背诵的产品清单。

资源问题要沿请求路径定位

同一条“GPU 利用率低”可能来自不同层：Kubernetes 没把 GPU 交给 Pod，Ray placement group 在等待拓扑，engine 因 KV 不足拒绝新序列，kernel 因 batch 太小无法填满 SM，或 gateway 根本没有流量。排查时先确认请求是否到达，再看 admission/queue、engine batch/KV、GPU kernel/内存带宽、节点拓扑和跨节点通信；不要从某个 dashboard 的单一百分比直接跳到换硬件。

控制平面与数据平面的交界

控制平面可以重启 worker、分配资源和记录版本，但不能替数据平面保证权重已同步、KV 布局兼容或 checkpoint 是最新的。数据平面吞吐提升也可能让控制平面的队列、网络和成本超预算。部署一个训练或服务系统时，明确写出资源声明、权重版本、checkpoint、任务幂等和可观测字段，才能在 Ray/Kubernetes 重启后恢复业务语义，而不只是恢复进程。