L0.1 AI 系统工程端到端全景

三维坐标　layer: L0（基础）｜level: Engineer｜pillar: 硬件架构 + 训推框架

本文是全站「新手村指引」的第一篇。目标不是讲透任何单点技术，而是把整张技术栈地图铺开，让你知道后续 L1–L6 每一层在解决「从硅到智能」这条链路上的哪一段问题。

学习目标

前置知识：无。这是全站第一篇，只要你写过代码、知道「GPU 比 CPU 算得快」即可上手。
学完产出：① 能在脑中画出 L0–L6 七层技术栈，并说清每层解决什么问题；② 能把自己手头的业务对号入座到「三大落地版图」；③ 理解「三大支柱」为什么是这三个、它们当前最新的技术方案是什么；④ 跑通一段 GEMM profile，第一次亲眼看到「一行 Python → 一个硬件 kernel」。
阅读姿势：先建立「全局地图感」，不必纠结任何术语细节——每个名词后续都有独立章节展开。

背景与现状

AI Infra（人工智能基础设施） 的本质，是把一块块物理芯片的裸算力，工业化地转化为「可调度、可观测、可计费」的智能服务。它向下屏蔽硬件异构（NVIDIA GPU / 华为昇腾 NPU / Google TPU），向上为训练框架与推理服务释放极限算力——这就是它作为 「大模型工业化桥梁」 的定位。

从产业视角看，过去五年的演进可以概括为三句话：

2020 前：算法主导，infra 是「能跑就行」的附属品。
2020–2023：模型规模指数膨胀（GPT-3 175B → 万亿 MoE），单卡装不下、单机训不动，分布式与显存优化（如 Megatron-LM、DeepSpeed/ZeRO）成为硬通货。
2023 至今：推理成本压倒训练成本成为主要矛盾，Serving 引擎（vLLM 的 PagedAttention、SGLang 的 RadixAttention、TensorRT-LLM）与 FinOps 成本治理 走到台前。

业界信号：vllm-project/vllm 在两年内冲到数万 Star，Megatron-LM / DeepSpeed 成为几乎所有大模型团队的训练底座——这说明「infra 能力」已是大模型竞争的胜负手，而非辅助项。

原理与架构

理解 AI Infra，最有效的方式是沿着 「一次请求 / 一次训练 step」的数据流，自底向上看它穿过了哪些层。

2.1 七层技术栈的端到端位置

L0/L1硬件层

GPU·NPU·HBM·NVLink·RDMA·NVMe

L2数据与算子层

ETL·Vector DB·CUDA/Triton/MLIR 编译

L3训练层

DP/TP/PP·ZeRO·DeepSpeed/Megatron/FSDP

L4推理与 Serving 层

vLLM·TensorRT-LLM·PagedAttention·量化

L5MLOps/LLMOps 层

Registry·CI/CD·可观测·FinOps

L6应用架构层

RAG·Agent·多模型路由

USER终端用户 / 业务

产品交付与业务价值

自底向上：硅晶片提供算力 → 数据与编译喂入 → 训练产出模型 → 推理服务化 → MLOps 保障 → 应用交付用户

自底向上读这张图：硅晶片（L0/L1）提供 FLOPS 与带宽 → 数据与算子层（L2）把数据喂进去、把算子编译到硬件 → 训练层（L3）用上千卡把模型练出来 → 推理层（L4）把模型以极限性价比服务化 → MLOps 层（L5）保证整条链路可发布、可观测、可计费 → 应用层（L6）把模型能力组装成 RAG / Agent 产品交付给用户。

2.2 「终端用户 / 业务」到底是谁？——AI Infra 的三大落地版图

上图末端那个抽象的「终端用户 / 业务」节点，落到现实里并不是铁板一块。不同业务对 Infra 的诉求差异极大——有的要「万卡训练吞吐」，有的要「端侧 10ms 实时」，有的要「数据不出内网」。把整个产业精简后，可以划分为三大核心类别，每一类压在七层图上的「主战场」都不同：

类别一：核心算力与通用模型基座（Model-Centric Infra）

大模型的**「生产端」与「云端主力消费端」**，对高性能计算、超大规模分布式通信、极致算子优化要求最高，吸纳主力资金。

中心化超大规模训推（大厂 / 模型厂商）
- 场景特征：万卡 / 十万卡级集群、长周期训练、极高容错与 Checkpointing、高并发低延迟推理集群（LLM / 多模态 / Video Generation）。
- 典型代表：OpenAI、Anthropic、字节跳动、腾讯——迭代 GPT、Claude、豆包等前沿基座，支撑海量 C 端日常调用。
AI-Native 生产力与数字内容平台（GenAI Apps）
- 场景特征：强依赖高吞吐多模态推理基础设施，高密度显存吞吐 + 长文本 / 长视频处理。
- 典型代表：Midjourney（文生图）、Runway（文生视频）、Character.ai（AI Agent 伴侣平台）。
主要压在七层图：L1 通信/HBM + L3 训练并行 + L4 高并发推理。

类别二：物理世界与具身智能（Physical-World & Embodied AI Infra）

Infra 痛点从「纯算力吞吐」转向**「实时性（Low-Latency）、边缘计算、端侧异构芯片（NPU/DSA/GPU）泛化、多模态仿真与时空数据处理」**。

具身智能与机器人（Embodied AI）
- 场景特征：依赖超大规模物理仿真（Simulation Infra）生成合成数据；端侧极严苛的低延迟、低功耗异构算子推理。
- 典型代表：特斯拉 Optimus、Figure AI、宇树科技（Unitree）；底层依赖 NVIDIA Isaac Sim、端侧边缘推断框架。
自动驾驶与端到端智驾（Autonomous Driving）
- 场景特征：典型「车端弱推理 + 云端强训练」双回路；云端处理海量视频 / 激光雷达等多模态时空数据，训练端到端（End-to-End）大模型。
- 典型代表：特斯拉 FSD、华为乾崑智驾、小鹏 XNGP。
智能终端与端侧 AI（Edge & On-Device AI）
- 场景特征：手机 / AI PC / XR；受限功耗散热，极度依赖轻量化量化（INT4/INT8）、异构编译（手机 NPU 模型切片与动态 Shape 优化）。
- 典型代表：苹果 Apple Intelligence、高通 / 联发科端侧芯片平台、各类 AI PC 软硬件生态。
主要压在七层图：L2 编译/异构算子 + L4 量化/低延迟 + L1 端侧芯片。

类别三：垂直行业与企业级落地（Enterprise & Vertical Industry AI Infra）

私有化 / 混合云场景，核心诉求是**「隐私安全（Data Privacy）、低成本（ROI）、敏捷定制（Fine-tuning/RAG）、多模型混合调度」**。

AI for Science（科研基础设施）
- 场景特征：高度定制化数据结构与非标准算子，对高精度（FP64/FP32）与混合精度（BF16/FP8）切换有独特要求。
- 典型代表：生物医药（AlphaFold 3 驱动的蛋白质结构与药物靶点预测）、气象预测（盘古气象大模型）、新材料研发。
工业制造与高精尖工业软件（Industrial AI）
- 场景特征：结合物理规律的 AI 模拟（PINN）、智能工厂机器视觉与缺陷检测，对高可用与现场边缘算力要求极强。
- 典型代表：西门子工业 AI、台积电 / 英伟达计算光刻（cuLitho）及半导体良率预测。
企业级混合应用（Enterprise RAG & Agentic Workflow）
- 场景特征：金融 / 法律 / 医疗 / 政务；通过向量数据库（Vector DB）、知识库（RAG）、Agent 编排框架配合小规模微调（LoRA 等），将大模型能力安全嵌入企业内网。
- 典型代表：彭博社（BloombergGPT）、数字化政府服务、大型银行智能投研与风控。
主要压在七层图：L6 RAG/Agent + L2 向量库 + L5 多模型调度与合规。

怎么用这三类：先找到你所在的版图，再回到 2.1 的七层图——你会发现自己日常的「痛点层」正是这一类的主战场。Infra 没有银弹，选型永远跟着业务版图走。

2.3 一次推理请求的真实流向

把抽象的「七层」落到一次 chat/completions 请求上：

值得注意的是：请求的延迟与成本，绝大部分由 L1（显存带宽 / KV Cache 容量）和 L4（调度策略）决定，而非业务代码。这就是为什么 AI Infra 工程师必须「向下看到硬件」。

2.4 三大支柱：为什么是这三个？

「三大支柱」不是拍脑袋凑出来的口号，而是**「裸算力 → 智能服务」这条转化链路的三个必经环节**，缺一不可：

①

物理算力

芯片能算多快

支柱：基础硬件架构

②

让代码用上算力

编程语言 → 编译 → kernel

支柱：编程与编译

③

把算力组织成产能

训练/推理框架

支柱：训推框架

来源逻辑：芯片（硬件）决定算力的物理上限 → 编程与编译决定你能否触达这个上限（一行 a@b 怎么变成 SM 上的 kernel）→ 框架决定多少人、多大规模能用到这个上限（DeepSpeed 管训练显存、vLLM 管推理吞吐）。
三者也对应业界三类核心岗位与三类开源生态：硬件 / 驱动 → CUDA / Triton / MLIR 编译器 → PyTorch / vLLM 框架，构成经典的「软硬协同」分层。
可以记住这条主线：芯片决定上限，编译决定能否触达上限，框架决定多少人能用到这个上限。

2.5 三大支柱在端到端图里的位置 + 当前最新技术方案

下表把每个支柱「在链路中的体现」与「当前（截至 2026 年）最新技术方案」并列，方便你建立「概念 → 落地」的映射：

支柱	在端到端链路中的体现	重点层	当前最新技术方案（截至 2026）
基础硬件架构	HBM 带宽决定 KV Cache 能放多少；NVLink 决定多卡 All-Reduce 快不快	L1	NVIDIA Blackwell B200（192 GB HBM3e、8 TB/s 带宽，约为 H100 的 2.4×）/ GB200 NVL72 机柜级 72 卡互联；Blackwell Ultra（GB300，288 GB HBM3e）；NVLink 5（1.8 TB/s/GPU）+ 第四代 NVSwitch；FP8/FP4 低精度。华为昇腾 910B/910C + CloudMatrix 384（384 卡光互连超节点，对标 NVL72）。下一代 Rubin + HBM4 已于 2026 年中官宣进入量产、2026 H2 起交付（精确规格以官方发布为准）。
编程与编译	模型代码经 `torch.compile`/Triton/MLIR 编译成 kernel 才能跑在硬件上	L2	Triton 已成为 `torch.compile`/TorchInductor 在 GPU 上生成 kernel 的默认后端（事实标准）；torch.compile + Inductor（PyTorch 2.13，2026-07 稳定线）生产可用，支持动态 Shape；CUDA 13.3（12.x 仍广泛使用）；华为 CANN + Ascend C（类比 CUDA / CUDA C）；新兴：Mojo、JAX Pallas（TPU 场景较成熟）。
训推框架	DeepSpeed 管训练显存，vLLM 管推理吞吐——选型决定上限	L3 / L4	训练：Megatron-Core（工业级并行底座）、DeepSpeed/ZeRO、PyTorch FSDP2（新基线）、TorchTitan（官方原生 4D 并行参考）；推理：vLLM V1 引擎（v0.25 线，V1 已是唯一路径、V0 已移除）、SGLang（RadixAttention + PD 分离）、TensorRT-LLM、LMDeploy；长序列：Ring Attention、DeepSpeed-Ulysses 上下文并行。

⚠️ 时效提示：上表版本号与量产状态（尤其未发布的 Rubin / HBM4、昇腾低精度细节）变动较快，选型前请以官方文档 / GitHub Releases 为准二次核对。

动手实践：极简代码实操

实验目标：用一段极简代码，亲手观测「同一次矩阵乘法穿过软件栈到达硬件」的过程，建立对「代码 → 编译 → 设备执行」链路的第一手感知。产出物：一张设备执行的 profile timeline 截图 + 一段对照说明。

3.1 环境准备

# 推荐 Python 3.11；用 uv 或 venv 隔离
python3 -m venv .venv && source .venv/bin/activate
pip install torch --index-url https://download.pytorch.org/whl/cpu  # CPU 路径默认
# 若有 NVIDIA GPU，改用官方 CUDA wheel：
# pip install torch  # 自动选 CUDA 版

3.2 代码：观测一次 GEMM 的设备执行

import torch
from torch.profiler import profile, ProfilerActivity

# 选择设备：有 GPU 走 cuda，否则 cpu
dev = "cuda" if torch.cuda.is_available() else "cpu"
print(f"[device] {dev}")

a = torch.randn(2048, 2048, device=dev)
b = torch.randn(2048, 2048, device=dev)

# 预热（首次会触发 kernel JIT / cuBLAS handle 初始化）
for _ in range(3):
    _ = a @ b
if dev == "cuda":
    torch.cuda.synchronize()

acts = [ProfilerActivity.CPU] + ([ProfilerActivity.CUDA] if dev == "cuda" else [])
with profile(activities=acts, record_shapes=True) as prof:
    c = a @ b
    if dev == "cuda":
        torch.cuda.synchronize()

# 打印按设备耗时排序的算子，看 matmul 落到了哪个底层 kernel
key = "cuda_time_total" if dev == "cuda" else "cpu_time_total"
print(prof.key_averages().table(sort_by=key, row_limit=8))

3.3 运行与观察

python gemm_profile.py

NVIDIA GPU 路径：你会在表格里看到形如 ampere_sgemm_* / cutlass_* 的 底层 kernel 名——这就是 a @ b 这行 Python 经 cuBLAS/CUTLASS 编译选择后，真正在 SM 上执行的算子。
Mac / CPU 替代方案：无 GPU 时同样能跑，会看到 aten::mm 落到 MKL/OpenBLAS 的 CPU kernel。目的一致——理解「一行算子表达式 → 一个具体后端 kernel」的映射，这正是 L2「编程与编译」支柱的起点。

踩坑预警 (Gotchas)

不 synchronize 就计时 = 测了个寂寞：CUDA kernel 是异步下发的，不同步会把 kernel 耗时算成接近 0。GPU 路径务必 torch.cuda.synchronize()。
首次调用极慢别误判：第一次 matmul 包含 cuBLAS handle 初始化与 JIT，必须预热后再测。
CPU OOM：2048×2048 在低内存机器上把维度调小到 1024 即可。

深入思考

下面三题每题先给题干，再用 <details> 折叠一份图文并茂的参考答案。建议先合上答案自己想 3 分钟，再展开对照。

思考题 1：成本归因

一个线上 7B 模型推理服务，P99 延迟突然从 80ms 涨到 300ms。结合本文的「七层端到端图」，列出你的自底向上排查清单——哪些是 L1（硬件/显存）问题，哪些是 L4（调度/batching）问题，如何用一次 profile 快速分层定位？

展开参考答案（含排查决策树图）

核心思路：自底向上分层，先排除「物理墙」，再看「调度策略」，最后才怀疑业务代码。

分层 checklist：

层	检查项	工具/指标	典型根因
L1 硬件	显存是否吃满、是否触发抢占、有无降频/ECC	`nvidia-smi`、`num_preemptions`、KV 命中率、`clocks`	KV Cache 不够→重算；GPU 降频/温度墙
L4 调度	等待队列、running batch、是否被长请求堵	vLLM `waiting/running`、调度延迟直方图	batch 攒不起来、长 prompt 阻塞短请求
L5/L6	网关限流、RAG 检索/外部 API 延迟	网关 P99、检索耗时、依赖超时	检索变慢被算进端到端延迟

一次 profile 怎么快速定位：用 torch.profiler / Nsight 抓一段 trace——若时间花在 kernel 执行（SM 忙） → 多半是 L1（算力/显存）或模型本身；若时间花在 kernel 之间的空隙（SM 闲、CPU 在等） → 多半是 L4 调度/排队或 host 侧瓶颈。这条「忙 vs 闲」的判据能在一张 timeline 上一眼分层。

思考题 2：异构移植

若要把这套服务从 NVIDIA GPU 迁到华为昇腾 NPU，这张端到端图的哪几层需要改动、哪几层基本不变？为什么「编程与编译」支柱是迁移成本的核心？

展开参考答案（含七层「改动 vs 不变」染色图）

染色解读（红=大改 / 黄=适配 / 绿=基本不变）：

🔴 L0/L1 + L2（核心成本）：底层从 CUDA 生态切到 CANN，所有手写 / 编译产出的 CUDA / Triton kernel 必须用 Ascend C 重写或重新编译；通信库 NCCL → HCCL。
🟡 L3/L4（适配层）：训练/推理框架本身大多有昇腾后端（如 PyTorch + torch_npu、MindIE），但算子覆盖度、性能调优、量化路径需要逐一适配验证。
🟢 L5/L6（基本不变）：MLOps 流水线、可观测、以及 RAG/Agent 业务代码运行在框架之上，对底层硬件基本无感知，终端用户更是完全无感。

为什么「编程与编译」是迁移成本核心：模型的算力最终都要落成针对特定硬件指令集的 kernel。换硬件 = 换指令集 = 之前所有「贴着 CUDA 优化」的 kernel 与编译产物全部作废，必须在新编译栈（CANN/Ascend C）上重新生成并调优。上层框架可以抽象，但「代码 → 硬件指令」这一跳无法抽象掉——这正是 L2 支柱决定移植成本的根本原因，也是为什么「一次编译、多端运行」（如 MLIR 统一 IR）是业界长期追求的圣杯。

思考题 3：新人陷阱

很多算法同学认为「infra 就是运维 K8s」。用本文的端到端视角，向他解释为什么「不懂 HBM 带宽就调不好 vLLM 的 batch」——即上层调优为何强依赖底层硬件认知。

展开参考答案（含「HBM → 吞吐」因果链图 + 算一遍）

这条因果链可以串成一句话：HBM 决定能塞多少 KV Cache → KV Cache 决定能并发多少请求 → 并发决定 batch 能攒多大 → batch 决定吞吐与成本。调 vLLM 的 batch 参数，本质是在「HBM 这块固定大小的桌子」上摆盘子。

用具体数字算一遍（以一张 80 GB HBM 的卡跑 7B 模型为例，数量级估算）：

权重占用：7B × 2 byte（FP16）≈ 14 GB。
留给 KV Cache 的空间 ≈ 80 − 14 − 框架开销 ≈ ~60 GB。
单 token KV 大小 ≈ 2 × 层数 × 隐藏维 × 2 byte，7B 模型约 ~0.25–0.5 MB/token（随模型结构变化）。
可缓存 token 数 ≈ 60 GB ÷ 0.5 MB ≈ ~12 万 token。
若平均上下文 2K token，则理论并发 ≈ 12 万 ÷ 2K ≈ ~60 路并发——这就是你 max-num-seqs 的物理天花板。

结论：如果你不知道「HBM 还剩多少、单 token KV 多大」，就会把 max-num-seqs / max-model-len 拍得过大 → 触发 KV 抢占与重算，P99 反而暴涨；拍得过小 → 吞吐上不去、成本高。所以「调 batch」从来不是纯软件参数游戏，而是一道戴着 L1 硬件镣铐跳舞的约束优化题——这就是 infra 工程师必须「向下看到硬件」的原因，也是它远不止「运维 K8s」的根本所在。

学习目标​

背景与现状​

原理与架构​

2.1 七层技术栈的端到端位置​

2.2 「终端用户 / 业务」到底是谁？——AI Infra 的三大落地版图​

类别一：核心算力与通用模型基座（Model-Centric Infra）​

类别二：物理世界与具身智能（Physical-World & Embodied AI Infra）​

类别三：垂直行业与企业级落地（Enterprise & Vertical Industry AI Infra）​

2.3 一次推理请求的真实流向​

2.4 三大支柱：为什么是这三个？​

2.5 三大支柱在端到端图里的位置 + 当前最新技术方案​

动手实践：极简代码实操​

3.1 环境准备​

3.2 代码：观测一次 GEMM 的设备执行​

3.3 运行与观察​

踩坑预警 (Gotchas)​

深入思考​

思考题 1：成本归因​

思考题 2：异构移植​

思考题 3：新人陷阱​

延伸阅读​