AI Infra Seven-Layer Stack

七层地图

7. LLM Applications & Agents
6. Training paradigms & model lifecycle
5. Serving & LLMOps
4. Training & inference engines
3. Distributed execution & parallelism
2. Frameworks, kernels & compilers
1. Hardware & cluster infrastructure

这是一张“职责地图”，不是所有组件的严格上下依赖关系。

层与典型组件

层	解决什么	例子
1 硬件与集群	计算、内存、网络、容器落点	GPU/HBM、NVLink、RDMA、Kubernetes
2 框架与 Kernel	表达模型并高效执行算子	PyTorch、Triton Language、FlashAttention、CUTLASS
3 分布式执行	进程、worker、并行与通信	Ray、NCCL、TP/PP/EP、DeepEP
4 训练/推理引擎	更新模型或高效生成 token	DeepSpeed、Megatron、vLLM、SGLang、llama.cpp
5 Serving/LLMOps	路由、扩缩容、观测与版本	Ray Serve、Gateway、Langfuse、MLflow
6 训练范式	数据和目标如何塑造能力	SFT、RLHF/RLVR、Reasoning RL、Agentic RL
7 应用/Agent	如何解决用户任务	RAG、Tool Calling、Memory、Planning

重要边界

Triton Language 不是 NVIDIA Triton Inference Server。
TorchDynamo 不是 NVIDIA Dynamo。
Ray 组织 task/actor/worker；DeepSpeed/Megatron 重点解决模型和训练状态如何跨 GPU 计算。
vLLM 是推理引擎；Serving platform 在其上增加 API、路由、多模型、扩缩容和生命周期管理。
量化体系有四层：数值格式（BF16/FP8/NVFP4）、编码 recipe（K/I-quant）、动态策略（UD）、文件容器（GGUF/Safetensors）。它们不是同一维度的并列项。
llama.cpp/Ollama 是本地推理引擎/平台，与 vLLM/SGLang 是场景不同的平行选择，而非上下游。

七层如何共同决定一个上线结果

“模型能加载”只跨过了第 4 层的一小部分。一次服务上线还要经过：第 1 层提供匹配的 GPU/HBM/互联和可调度节点；第 2 层让 dtype、kernel、编译和 allocator 与硬件匹配；第 3 层决定 TP/PP/DP/EP 的 rank 与通信；第 4 层管理 batch、KV 和模型执行；第 5 层负责路由、readiness、扩缩容、灰度和回滚；第 6/7 层决定输出质量、工具/检索契约和业务 SLO。

SLO/请求形状
→ 模型与精度/上下文约束
→ engine + 并行映射
→ kernel/硬件/网络可行性
→ serving 生命周期与观测
→ 质量、成本、故障恢复验收

层间经常出现“局部正确、全局失败”：低 bit 权重满足第 1 层容量，却因第 2 层没有原生 kernel 变慢；TP 满足第 4 层容量，却因第 3/1 层跨节点通信让 P99 失控；Kubernetes 扩容满足第 5 层副本数，却因权重下载和 warmup 仍没有可服务容量。

读图的实用方法

遇到新组件，先写它修改哪一层的状态、向上提供什么契约、向下依赖什么资源，以及一个会让它失效的反例。比如 Triton Language 修改 kernel 执行，不替代 engine 调度；Ray 修改控制面角色，不定义 attention；GGUF 修改文件/metadata，不等于量化算法。这样可以避免把同名工具、容器格式、运行时和平台混成一张产品排行榜。