AI 工程链总览:从一张 GPU 到一个上线的 Agent
aiLearning 41 篇把模型一侧讲透了——Transformer 怎么搭、loss 怎么算、SFT/RLHF 怎么调、RAG 怎么接。但有几个问题始终没回答:一张 H100 单卡 80GB,凭什么能跑 70B 推理而不是连 13B 也跑不动?一次预训练几千张卡,前 80% 时间不是在算而是在等通信,这块怎么压?推理服务上线后,vLLM 比 transformers.generate 吞吐高 10 倍,代价是什么? 这些不是「模型问题」,是「工程问题」——本系列 30 篇都在回答这一类。
一句话先记住:aiLearning 讲「模型一侧」——模型是什么、怎么训、用来做什么;本系列讲「生产一侧」——一张 GPU 怎么榨干、一个集群怎么调度、一个推理服务怎么扛住 QPS。两边交集只在 KV Cache、FP8、LoRA 服务化几个必要点名处,其他不重复。
一、一条数据 → 一个上线 Agent 的全景
设想一家公司要训练并上线一个 70B 的代码助手。从原始语料到用户敲键盘看到补全,中间发生了什么?
[语料采集]
GitHub repos + Stack Overflow + 内部代码 + 公开数据集
原始 ~5 TB → 清洗去重后 ~1.2 TB → tokenize 后 ~3000 亿 token
│
▼
[数据工程层] (dataEngineering 系列)
Spark 清洗 / MinHash 去重 / 质量过滤 / 配比
落对象存储 (S3 + Parquet),Iceberg 表管 schema
训练时流式拉取,避免一次性载入
│
▼
[预训练] (本系列 13-19)
2048 张 H100,8000 亿 token,FP8 训练
Megatron-LM 张量并行 × DeepSpeed ZeRO × Pipeline
Ring-AllReduce 在 InfiniBand 上,NCCL 调度通信
持续 ~3 周,Checkpoint 落 PFS,故障恢复算分钟级
│
▼
[SFT / 对齐] (本系列 24)
SFT(代码补全示例) → DPO / RLHF
8 张 H100,LoRA 微调,1-2 天
│
▼
[评测] (本系列 29 顺带)
HumanEval / MBPP / SWE-bench / 内部业务集
评测集自动跑批,模型选 best checkpoint
│
▼
[量化 / 压缩] (本系列 20-23)
FP8 权重 / AWQ-INT4 / KV Cache FP8
离线一次性,出多个版本权重供不同 SLA
│
▼
[推理服务] (本系列 06-12, 25-26)
vLLM / SGLang on Ray Serve
8 张 H100 跑一个副本,Continuous Batching + PagedAttention
TTFT < 500ms,输出 50 tok/s/请求,峰值 1000 QPS
│
▼
[Agent 编排] (aiLearning 已讲)
API gateway → 路由 → 推理引擎
多 LoRA 路由(不同语言切不同 adapter)
评测信号 / 日志 / Trace 回流监控
│
▼
[用户敲键盘看到补全]一条数据从原始语料到上线,跨过六个工程领域、十几种工具、三个数量级的延迟尺度(月级训练 / 小时级评测 / 毫秒级推理)。本系列就是搭起这条管道、保证它跑得起、跑得动、出问题能修的那群人。
二、四类 AI 工程师:你大概率是某一个
「AI 工程师」太宽,日常做什么、看什么指标、用什么工具,四类人差得很远:
| 角色 | 主要负责 | 时间尺度 | 工具栈 | 评价标准 |
|---|---|---|---|---|
| 模型工程师 / 研究员 | 架构调整、损失函数、训练曲线 | 周-月级 | PyTorch、Megatron、wandb、HuggingFace | 模型指标(loss、benchmark) |
| 数据工程师 | 语料管道、清洗、配比、评测集 | 天-周级 | Spark、Iceberg、Airflow、dbt | 数据吞吐、新鲜度、质量 |
| AI Infra / 推理工程师 | 显存、吞吐、延迟、成本 | 分钟-小时级 | vLLM、SGLang、TRT-LLM、CUDA profiler | TTFT、TPOT、QPS、$/Mtok |
| ML 平台工程师 | 集群调度、多租户、CI/CD、可观测 | 小时级在线 + 长期演进 | Ray、K8s、Slurm、Prometheus、KubeRay | 集群利用率、SLO、故障恢复 |
边界不是死的——小公司一个人兼三个,大公司细分到每个 SM 利用率有专人盯。但核心区别是看什么数字:模型工程师盯 loss 曲线,Infra 工程师盯 nvidia-smi 和 NCCL profile,数据工程师盯管道延迟,平台工程师盯节点故障率。
本系列服务的画像:Infra / 推理 / 平台工程师,以及想从「调 API」往下走一层的应用工程师。默认你能读懂 model.generate 这一行,但搞不清「为什么 vLLM 把这一行重写一遍能快 10 倍」。
三、aiLearning 教什么,本系列教什么:边界在哪
把「AI 工程链」按模型生命周期切一刀,清晰看到分工:
┌─────────────────────────────────┐
│ 模型一侧 (aiLearning 41 篇) │
│ │
│ - 感知机 → MLP → CNN → RNN │
│ - Attention / Transformer 算子 │
│ - 预训练损失 / SFT / RLHF │
│ - LoRA / Prefix Tuning 算法 │
│ - RAG / Embedding / 向量检索 │
│ - Prompt / 采样 / 解码策略 │
│ - Agent / 工具调用 / 多模态 │
└─────────────────────────────────┘
↕
┌───────────────┐
│ 交集 (5 处) │ ← 本系列必要时点名,不展开
│ KV Cache │
│ FP8 / 量化 │
│ LoRA 服务化 │
│ RAG 推理路径 │
│ Agent 推理负载│
└───────────────┘
↕
┌─────────────────────────────────┐
│ 生产一侧 (本系列 30 篇) │
│ │
│ - GPU / HBM / Tensor Core 心智 │
│ - 推理引擎 (vLLM / SGLang) │
│ - 训练并行 (DDP / ZeRO / TP/PP) │
│ - 量化服务化 (GPTQ / FP8 / KV) │
│ - 调度平台 (Ray / K8s / Slurm) │
│ - 成本 / SLO / 选型 / 排错 │
└─────────────────────────────────┘具体哪些不重复:
| 内容 | 已在 aiLearning | 本系列做什么 |
|---|---|---|
| Transformer / Attention 算子 | 13、14 篇讲透 | 只在 07-08 讲 KV / PagedAttention 时点名 |
| 预训练 / SFT / RLHF 算法 | 22-28 讲过 | 不重复,只讲怎么把训练跑得动 |
| LoRA / PEFT 算法 | 30 篇讲过 | 只讲 LoRA 服务化(24 篇 Multi-LoRA 路由) |
| RAG / Embedding | 36-38 讲过 | 不重复,29 谈推理负载特征时点名 |
| Prompt / 采样 / decoding | 32 篇讲过 | 不重复 |
| Agent / Tool use | 39-41 讲过 | 不重复,30 谈未来推理负载时点名 |
站在 2026 看:模型一侧已经从「研究」变成「工程」,真正的护城河早就不在算法纸面,而在「怎么把一个 70B 模型用一半显存跑出两倍吞吐」这一类工程问题上——这就是本系列的命题。
四、现代 AI Infra 一张图
把第一节那条全景压缩成分层架构,这张图你要能默写——30 篇都在填它的每一格:
┌──────────────────────────────────────────────────────────────────┐
│ 应用层 (Application) │
│ AI Agent 代码助手 RAG 问答 多模态 企业搜索 数字员工 │
│ LangGraph / LlamaIndex / 自研编排 │
└──────────────────────────────────────────────────────────────────┘
▲ ▲ ▲ ▲
│ │ │ │
┌──────────────────────────────────────────────────────────────────┐
│ 推理服务层 (Serving) │
│ vLLM / SGLang / TensorRT-LLM / TGI / llama.cpp / MLC │
│ PagedAttention + Continuous Batching + 投机解码 + Prefix Cache │
│ Ray Serve / KubeRay 路由、自动扩缩容、多 LoRA │
└──────────────────────────────────────────────────────────────────┘
▲ ▲
│ │
┌──────────────────────────────────────────────────────────────────┐
│ 训练框架层 (Training) │
│ PyTorch + Megatron-LM + DeepSpeed │
│ 3D 并行 (TP × PP × DP) / FSDP / ZeRO-3 │
│ Transformer Engine (FP8) / TRL (RLHF) / 数据流水 │
└──────────────────────────────────────────────────────────────────┘
▲ ▲
│ │
┌──────────────────────────────────────────────────────────────────┐
│ 调度与编排层 (Orchestration) │
│ Slurm (HPC 训练) K8s + KubeRay (推理 / 微调) │
│ Ray (Actor / Task / Object Store) MIG / Volcano │
│ 拓扑感知调度 / 弹性恢复 / 多租户隔离 │
└──────────────────────────────────────────────────────────────────┘
▲ ▲
│ │
┌──────────────────────────────────────────────────────────────────┐
│ 硬件与通信层 (Hardware) │
│ GPU: H100 / H200 / B200 主流 + A100 存量 + 4090 单卡场景 │
│ NVLink (节点内 900 GB/s) + IB / RoCE (节点间 400 Gbps) + NCCL │
│ HBM3/3e + L2 Cache + 共享内存 + Tensor Core (FP8/FP16/BF16) │
└──────────────────────────────────────────────────────────────────┘
▲ ▲
│ │
┌──────────────────────────────────────────────────────────────────┐
│ 数据 / 评测层 (Data & Eval) │
│ 对象存储 + Parquet/Iceberg PFS (训练 checkpoint) │
│ Tokenized 数据集流式读取 lm-eval-harness / 业务评测自动化 │
└──────────────────────────────────────────────────────────────────┘横切贯穿所有层的工程纪律:
┌─────────────────────────────────────────────────────┐
│ 监控 / Profile (Prometheus + Grafana + nvtop) │
│ 成本 / FinOps (GPU 小时计费 / $/Mtok / 利用率) │ 贯穿所有层
│ 可观测 (Trace / TTFT-TPOT 分位 / NCCL profile) │
│ 权限 / 多租户 (K8s namespace + GPU quota) │
└─────────────────────────────────────────────────────┘每一层都有「上一代」和「下一代」——本系列每一篇就是回答「上一代死在哪、这一代靠什么解决、什么时候是过度工程」。
五、本系列 30 篇怎么组织
按 AI 工程链从下往上,六层结构:
第一层 心智底座 (01-05) 硬件 / 浮点 / 算力账,看完知道"为什么是这样"
第二层 推理引擎 (06-12) vLLM / SGLang / TRT-LLM,生产推理的全部主战场
第三层 训练并行 (13-19) DDP / ZeRO / TP / PP / NCCL,千卡训练靠这套
第四层 量化压缩 (20-24) GPTQ / AWQ / FP8 / KV 量化 / LoRA 服务化
第五层 调度平台 (25-28) Ray / KubeRay / Slurm,把卡和服务编排起来
第六层 端到端 (29-30) 成本 / 吞吐 / SLO / 未来方向节奏判断:
- 06-12 推理 7 篇:当下最热,vLLM / SGLang 是生产硬通货,招聘必考
- 13-19 训练 7 篇:真正的工程难点,千卡训练 80% 时间在打通信
- 20-24 量化 5 篇:降本关键,FP8 + KV 量化是 2026 上线必备
- 25-28 调度 4 篇:平台一侧,决定团队上限
- 29-30 端到端 2 篇:算账与下一站
六、几条阅读路径
按需跳读,不用顺着读 30 篇:
路径 A:零起点(最少 9 篇)
01 (你正在读) → 02 GPU 心智 → 03 训练 vs 推理 → 04 浮点格式
│
▼
06 推理引擎景观 → 07 KV Cache → 09 Continuous Batching
│
▼
13 数据并行 → 22 FP8读完能在白板讲清:为什么 LLM 推理是显存受限,vLLM 凭什么吞吐高,FP8 何时切。
路径 B:推理工程师(13 篇)
01 → 02 → 03 → 04 → 05 算力账
▼
06 → 07 → 08 PagedAttention → 09 Continuous Batching
▼
10 SGLang → 11 投机解码 → 12 TRT-LLM
▼
22 FP8 → 23 KV 量化 → 24 Multi-LoRA → 29 成本读完能上线一个生产级 LLM 推理服务,知道每个旋钮在调什么。
路径 C:训练 / 分布式向(11 篇)
01 → 02 → 03 → 04 → 05
▼
13 DDP → 14 ZeRO → 15 FSDP → 16 TP → 17 PP → 18 3D 并行 → 19 NCCL
▼
22 FP8读完能在 H100 集群上把 70B 训起来,知道哪里是瓶颈、什么时候切并行策略。
路径 D:平台 / SRE 向(8 篇)
01 → 02 → 06 → 09
▼
25 Ray → 26 Ray Serve → 27 K8s GPU → 28 Slurm → 29 成本读完能搭一个支撑多团队的 AI 平台,推理 / 训练 / 评测都跑得起来。
路径 E:面试 / 体系打底
整 30 篇按顺序,30-40 小时,辅以 06、07、08、09、13、14、16、22 反复读 + 在本地跑 vLLM / DeepSpeed 各一次。
七、几条反直觉的事
刚入 AI Infra 最容易踩的认知误区:
7.1 LLM 推理瓶颈不在算力,在显存
H100 单卡 FP16 算力 989 TFLOPS,HBM 带宽 3.35 TB/s。decode 阶段每生成 1 个 token,要把整个模型权重读一遍——70B 模型 FP16 是 140 GB,单卡装不下;就算装下,每 token 至少要 140/3.35 ≈ 42ms 才能读完,跟算力关系不大。算力大部分时间在空转。02-03 篇会展开。
7.2 千卡训练 80% 时间在等通信
训练 step 时间 = forward + backward + AllReduce,在 70B + 2048 卡的规模上,AllReduce 一次几 GB 梯度,跨节点跑 InfiniBand,通信时间和计算时间一个量级。所以才有 ZeRO、TP、PP 这套并行——本质是把通信切碎、和计算重叠。13-19 篇展开。
7.3 vLLM 不是"代码写得好",是换了算法
朴素 transformers.generate 用静态 batch + 显存连续分配——一个长请求拖垮整个 batch,显存碎片让 batch size 上不去。vLLM 的 PagedAttention 把 KV 切成块 + Continuous Batching 让请求随到随走,算法层换了一套才有 10 倍吞吐。08-09 篇展开。
7.4 不是"花钱买卡就能跑"
公司买了 8 张 H100 不等于能跑 70B 训练——你还需要 NVLink + InfiniBand 网络 + Slurm/K8s 调度 + Megatron/DeepSpeed 配置 + Checkpoint 存储。硬件只是 1/3,中间件 + 工程能力是 2/3。25-28 篇展开。
7.5 推理便宜 ≠ 训练便宜
一个常见误区:看到 API 每 1M token $1 就觉得推理已经"白菜价"。这个价格的前提是每张 H100 利用率 70%+、批量足够大、Prefix Cache 命中率高。自己起一个服务跑得不好,$/Mtok 可以是 API 价格的 10 倍。29 篇展开。
八、立场声明
这个系列服务工程视角:能选型、能调优、能排错、能算账。
写:
- 心智模型 + 一张图 + 最小可跑代码 + 替代方案
- "上一代死在哪 / 这一代靠什么 / 下一代往哪走"
- 一手数字:H100 多少 TFLOPS、HBM 多少带宽、70B 多大显存
不写:
- CUDA Kernel 编程教程(那是 Kernel 工程师的事,本系列读者是"调度 Kernel 的人")
- Volta → Ampere → Hopper → Blackwell 编年史(直接进重点)
transformers/pytorch入门 API(aiLearning 已讲)- 罗列 vLLM / DeepSpeed 全部 flag(官方文档在那)
- 「面试必考」「字节面试题」式标题党
- 「vLLM vs TRT-LLM 谁更牛」(只讲各自擅长场景)
面向 2026:
- 默认 H100 / H200 / B200 为主线,A100 作为存量,消费卡(4090)只在单卡量化场景点名
- FP8 在 Hopper 上已是生产标配,不再当作"实验性"
- 默认主流栈是 PyTorch + vLLM/SGLang + DeepSpeed/Megatron + Ray
- 默认你已读完 aiLearning,会用 Docker / K8s 基础
九、看完这一篇,你应该能
- 在白板上画第四节那张「现代 AI Infra 分层图」,讲清楚每一层在解决什么
- 区分模型 / 数据 / Infra / 平台四类工程师的职责边界
- 说清 aiLearning 和本系列的分工:模型一侧 vs 生产一侧
- 选一条阅读路径继续往下读
- 大致知道 LLM 推理瓶颈在显存、训练瓶颈在通信、$/Mtok 怎么算(留待 29 篇)
下一篇:02 GPU 与显存心智 — 为什么 LLM 推理是「memory-bound 而非 compute-bound」。SM / Tensor Core / HBM / Roofline 模型,从 GPU 解剖图到一张 A100/H100/H200/B200 的对比表,看完知道为什么 70B 推理对显存比算力敏感得多。