2026-04-22 · architecture / ai-infra
大模型基础设施工程
面向中国工程团队的大模型基础设施系列。从 GPU/CUDA/互联、训练框架与 3D 并行、vLLM/SGLang 推理引擎、量化与推测解码、RAG/Agent 到服务化、网关、可观测性与安全合规，覆盖 LLMOps 全链路。
这是【大模型基础设施工程】系列第 01 篇。系列共 25 篇，从 GPU 到 Agent，自底向上覆盖训练、推理、RAG、Agent、服务化、网关、观测与成本安全。本篇为开篇，目标是让任何一位后端 / 平台 / 算法 / SRE 工程师，在读完后对「大模型基础设施」这张地图里有哪些地标、自己在哪、要往哪走，有一个清晰的印象。
对后端工程师来说，过去二十年我们熟悉的工作负载大致是这几类：无状态 Web 服务、关系库 OLTP、分析型 OLAP、搜索引擎、消息中间件、批处理 / 流处理。这些工作负载的瓶颈、SLO、扩展模型已经被反复打磨，社区共识也稳定。
大模型不是这些负载中的任何一个。它同时具有以下特征：
这就要求把它当作一个独立的基础设施领域来对待，而不是”在 K8s 里多起一个 Deployment”。
本系列默认你已经熟悉 Linux、容器、分布式系统和常见后端中间件，但不要求你懂 CUDA kernel、不要求你读过 Attention 论文。我们会用工程化的语言把每一层讲清楚：
在深入之前先声明几条原则，方便读者判断这个系列是否值得读：
一个领域是否”工程化”，看的是是否形成了可复用、可量化、可替换的工程组件。大模型正在以非常快的速度走过这段路，时间线大致如下。
工程意义远比产品意义大：
Meta 的 LLaMA（Large Language Model Meta AI）从内部研究走向开源后：
UC Berkeley 发布的 vLLM 是推理侧第一次真正工程意义上的”范式转移”：
OpenAI o1、o3，Anthropic Claude 3.7 Sonnet，Google Gemini 2.5 Pro 共同推进了 reasoning model（推理型模型）：
DeepSeek-V2、V3、V3.1、R1 系列带来了一次系统性冲击：
如果只记四件事：
面对一整堆眼花缭乱的组件，最清晰的方式是把它抽象成五层，从底到上：硬件、系统软件、框架、应用、运营。
┌──────────────────────────────────────────────────────────────┐
│ 05 运营层 观测、计费、配额、合规、安全、灰度、成本治理 │
├──────────────────────────────────────────────────────────────┤
│ 04 应用层 RAG、Agent、工具调用、工作流、Prompt 工程 │
├──────────────────────────────────────────────────────────────┤
│ 03 框架层 PyTorch / JAX / Megatron / DeepSpeed / vLLM / SGLang │
├──────────────────────────────────────────────────────────────┤
│ 02 系统软件 CUDA / ROCm / cuBLAS / cuDNN / NCCL / Triton │
├──────────────────────────────────────────────────────────────┤
│ 01 硬件 GPU / NPU / HBM / NVLink / InfiniBand / RoCE │
└──────────────────────────────────────────────────────────────┘关键抽象：算力、显存、带宽、互联。
这一层的共性特征是”对上层框架提供数学原语和通信原语”。
这是工程师最频繁打交道的一层。
把”裸模型”变成”有用的产品”的一层。
让一个 LLM 平台能被多租户、多业务长期使用的一层。
如果把上述五层当作一个”协议栈”来看，你会发现它和经典 OSI 模型遵循相同的工程原则：
在后续每篇里，我们会反复指出：这一层把什么抽象暴露给了上层？这一层从下层拿到了什么？哪些跨层约定正在松动或固化？
训练和推理常被合称为”跑模型”，但它们是两类完全不同的工程问题。
| 维度 | 训练 | 推理 prefill | 推理 decode |
|---|---|---|---|
| 主导瓶颈 | 计算（FLOPS） | 计算（FLOPS） | 显存带宽 |
| 算术强度 | 高 | 高 | 极低（每 token 几乎扫一遍权重） |
| Batch | 大而静态 | 中等 | 必须持续拼 batch 才有吞吐 |
| 典型利用率目标 | MFU（Model FLOPs Utilization） 40–55% | 50%+ | 通过 continuous batching 提吞吐 |
decode 环节每生成一个 token
就要把整模型权重从 HBM 扫一遍（再加 KV
缓存读写），所以带宽决定吞吐。这就是为什么
H200（带宽 4.8 TB/s）在推理场景下相对 H100（3.35
TB/s）的提升远大于 FLOPS 提升。
推理典型 SLO：
训练典型 SLO：
flowchart LR
subgraph Train[训练]
A1[大而静态 batch] --> A2[FLOPS 瓶颈]
A2 --> A3[3D 并行 + 优化器分片]
A3 --> A4[TB 级 checkpoint + 容错]
end
subgraph Inf[推理]
B1[动态请求] --> B2[Prefill 计算密集]
B2 --> B3[Decode 带宽密集]
B3 --> B4[Continuous Batch + PagedKV]
B4 --> B5[TTFT / TPOT SLO]
end很多后端工程师第一次接触推理时会假设”推理就是一次函数调用”，但在工业场景里它更像一个长连接上的流式生产者：
记住这个心智模型，第 11–15 篇会用得着。
一个工程师常被问到的问题是”一张 H100 能跑多大模型”。这里给一个粗算：
2 × layers × heads × head_dim × seq_len × batch × 每元素字节；以 Qwen2.5-72B、FP8、单 H100（80 GB）为例：
如果换成 FP8 + 2 卡 TP：
这类估算会在 11–14 篇里不断出现，习惯了以后”看一眼模型就知道要几张卡”会是很有用的直觉。
把大模型的生命周期拆开，一共有 8 类核心工作负载，每一类都对应不同的工程栈。
| 工作负载 | 计算 | 显存 | 网络 | 存储 IO | 典型延迟 / 周期 |
|---|---|---|---|---|---|
| Pre-train | 极高 | 极高 | 极高（AllReduce） | 高（数据 + ckpt） | 数周~数月 |
| SFT | 高 | 高 | 中 | 中 | 小时~天 |
| RLHF | 高 | 极高（多模型） | 高 | 中 | 天~周 |
| 蒸馏 | 高 | 中 | 中 | 高（teacher 日志） | 天~周 |
| Prefill | 高 | 中 | 低 | 低 | 数十 ms~秒 |
| Decode | 中 | 高（KV） | 低 | 低 | 毫秒 / token |
| RAG 离线 | 中 | 中 | 中 | 高（文档） | 小时 |
| RAG 在线 | 低 | 低 | 中 | 中（向量 IO） | 毫秒~几十 ms |
| Agent | 取决于调用链 | 同 decode | 中（工具调用） | 中 | 秒~分钟 |
这张表的意义在于：一个完整的 LLM 平台需要同时承载性质差异极大的几类负载，平台层面的调度、配额、优先级都要考虑这些差异。
在一个成熟的 LLM 团队里，这些工作负载通常映射到不同的小组：
小团队里一个人可能身兼数职，但角色边界还是存在的，本系列的路线图也是按这些角色组织的。
几乎所有自建 LLM 平台都会用到以下其中几件：
2025–2026 年，国产 GPU / NPU 已经不再是 PPT 状态，主流选型如下：
软件栈配套：
这条栈的工程特点是：抽象层更薄，跨层调优空间更大，但生态成熟度仍低于 CUDA。本系列第 02、04、13 篇会分别展开硬件、互联和推理引擎层面的对比。
| 场景 | 推荐栈（全球） | 推荐栈（中国） |
|---|---|---|
| 从零预训练 100B+ | H100/H200 + Megatron + NCCL + IB | H800 / 昇腾 910C + MindSpeed / Megatron + HCCL |
| 自建推理平台 | H100/H200 + vLLM / SGLang | H20 / 昇腾 910B + vLLM 昇腾版 / MindIE |
| 仅调用模型做应用 | Azure OpenAI / Bedrock + LangGraph | 百炼 / 方舟 / 千帆 + Dify |
| 端侧 / 边缘 | Apple Silicon / Jetson + llama.cpp / MLC | 昇腾 Atlas 300I / 寒武纪 MLU220 |
| 科研 / 小团队 | 4090 / L40S + HuggingFace + Unsloth | 4090 / 昇腾 300V + LLaMA-Factory |
| 模型 | 年份 | 估算训练成本 | 备注 |
|---|---|---|---|
| GPT-3 175B | 2020 | ~4.6M 美元 | V100 集群 |
| GPT-4 | 2023 | 约 60–100M 美元 | 非公开，业界估算 |
| LLaMA-2 70B | 2023 | ~2M 美元 | A100 |
| LLaMA-3 405B | 2024 | ~60M+ 美元 | H100 × 16k+ |
| Gemini Ultra | 2023 | ~100M+ 美元 | TPU v4 / v5 |
| DeepSeek-V3 671B | 2024 末 | ~5.6M 美元（官方） | H800 × 2048，FP8 + MLA + MoE |
| DeepSeek-R1 | 2025 | ≈ V3 + RL 增量 | 在 V3 基础上 |
关键结论：成本从”堆硬件”转向”工程密度”。DeepSeek-V3 用 1/10 的钱训出接近第一梯队的模型，其手段几乎全部来自工程（FP8、MLA、MoE 路由、DualPipe、通信压缩、数据配比）。这就是这个系列把”工程”放在最前面的原因。
OpenAI 官方定价（美元 / 百万 token，粗略口径）：
| 时间 | 代表模型 | 输入 | 输出 |
|---|---|---|---|
| 2023.03 | GPT-4 8K | 30 | 60 |
| 2024.05 | GPT-4o | 5 | 15 |
| 2024.07 | GPT-4o mini | 0.15 | 0.60 |
| 2025 | o3 / GPT-4.1 系列 | 显著下降 | 显著下降 |
开源 / 中国模型：
| 模型 | 推理单价（元 / 百万 token，输出口径，粗略） |
|---|---|
| GPT-3.5 turbo（2023） | 约 15 |
| Qwen-Turbo（2024） | 2 |
| DeepSeek-V2（2024） | 2 |
| DeepSeek-V3（2024 末） | 8（输出） |
| DeepSeek-V3.1（2026 预估） | < 1 |
| 豆包 Pro（2024–2025） | 0.8–2 |
两年量级下降来自几处工程叠加：
成本曲线还会继续下降，但工程门槛越来越高：把单价从 10 降到 1 靠的是工程，把 1 降到 0.3 靠的是系统级协同设计，这正是本系列的主题。
对于自建推理集群，单 token 成本的近似公式是：
cost_per_token ≈ (GPU_hourly_cost × num_gpus) / (tokens_per_second × 3600)举例：一台 8×H100 机器，按云上 30 美元/小时/卡 算，共 240 美元/小时。若整机 decode 吞吐达到 20000 tokens/s：
cost = 240 / (20000 × 3600) ≈ 3.3e-6 美元 / token ≈ 3.3 美元 / 百万 token对比 API 定价，就能看出自建是否划算的交叉点。后续第 21、24 篇会把这个模型展开成包含 prefill/decode 差异、缓存命中、利用率波动的完整模型。
工程决策时常见三种口径，不要混淆：
DeepSeek-V3 公开的 5.6M 美元是第一种口径，很多媒体对比时忽略了这一点，导致对比失真。
理解整体架构最直接的方式，是跟着一次请求走一遍：
flowchart TD
U[用户 / 业务系统] -->|HTTP / WebSocket / gRPC| GW[LLM 网关<br/>鉴权 · 限流 · 计费 · 审核 · 路由]
GW -->|按模型 / 租户 / 成本策略| LB[模型路由 / 负载均衡]
LB -->|走 RAG 检索？| RAG{需要检索?}
RAG -->|否| ENG
RAG -->|是| VEC[向量 / 混合检索] --> RE[重排] --> CTX[拼接上下文] --> ENG
ENG[推理引擎<br/>vLLM / SGLang / TensorRT-LLM] --> PF[Prefill<br/>构建 KV 缓存]
PF --> DC[Decode<br/>Continuous Batch + PagedKV]
DC -->|是否调用工具?| TOOL{Tool Call?}
TOOL -->|是| MCP[MCP / Function Server] --> DC
TOOL -->|否| OUT[流式返回]
OUT --> GW
GW -->|token 计费 + 观测日志| OBS[Langfuse / Prometheus / Trace]
GW --> U几个值得记的设计要点：
假设 SLO 是 p95 TTFT < 1200 ms，我们可以给一条典型 RAG 请求的延迟预算做个粗略分解：
| 阶段 | 预算 | 典型实现 |
|---|---|---|
| 网关鉴权 / 审核 | 20 ms | 本地缓存 + 异步审核 |
| 向量 / BM25 召回 | 60 ms | Milvus / ES，预热索引 |
| 重排 | 80 ms | Cross-encoder，小模型 |
| Prompt 拼装 | 10 ms | 模板引擎 + 缓存 |
| 推理 Prefill | 800 ms | vLLM / SGLang，chunked prefill |
| 首 token 返回 | 100 ms | 流式链路 |
| 网关回包 | 30 ms | gRPC → HTTP/SSE |
| 观测埋点 | async | 异步落 Kafka / OTel |
从这张表能看出几件事：
import requests
resp = requests.post(
"https://llm-gw.example.com/v1/chat/completions",
headers={"Authorization": "Bearer $TOKEN"},
json={
"model": "qwen3-32b",
"messages": [
{"role": "system", "content": "你是后端工程师助手。"},
{"role": "user", "content": "用 100 字解释 PagedAttention。"},
],
"stream": True,
"max_tokens": 512,
},
stream=True,
timeout=60,
)
for line in resp.iter_lines():
if line:
print(line.decode())后续第 22 篇会把这条客户端路径换成经过 LiteLLM / OneAPI / Kong AI Gateway 的完整生产链路，并给出限流、鉴权、多模型路由的详细配置。
整个系列按”从底到上、从点到面”的顺序展开，对应第三节的五层模型。
本系列每一篇都会围绕三件事展开：
我们会尽量避免两件事：
系列贯穿使用的几十个术语，这里先给出高频 20 个，后续文章会在首次出现时再次注释：
| 缩写 | 全称 | 含义 |
|---|---|---|
| TP | Tensor Parallel | 张量并行 |
| PP | Pipeline Parallel | 流水并行 |
| DP | Data Parallel | 数据并行 |
| SP | Sequence Parallel | 序列并行 |
| EP | Expert Parallel | 专家并行 |
| CP | Context Parallel | 上下文并行 |
| ZeRO | Zero Redundancy Optimizer | 优化器分片 |
| FSDP | Fully Sharded Data Parallel | 全分片数据并行 |
| MFU | Model FLOPs Utilization | 模型算力利用率 |
| HFU | Hardware FLOPs Utilization | 硬件算力利用率 |
| TTFT | Time To First Token | 首 token 时间 |
| TPOT | Time Per Output Token | 每 token 时间 |
| KV Cache | Key-Value Cache | 注意力 KV 缓存 |
| MLA | Multi-head Latent Attention | 多头潜在注意力 |
| MoE | Mixture of Experts | 专家混合 |
| MTP | Multi-Token Prediction | 多 token 预测 |
| RAG | Retrieval Augmented Generation | 检索增强生成 |
| RLHF | Reinforcement Learning from Human Feedback | 人类反馈强化学习 |
| DPO | Direct Preference Optimization | 直接偏好优化 |
| MCP | Model Context Protocol | 模型上下文协议 |
为了让开篇不只停留在概念，给一个最小的 vLLM 示例，读完 11–13 篇后你会对每一行都更有感觉。
pip install "vllm>=0.6.0"from vllm import LLM, SamplingParams
llm = LLM(
model="Qwen/Qwen2.5-7B-Instruct",
tensor_parallel_size=1,
gpu_memory_utilization=0.9,
max_model_len=8192,
enforce_eager=False,
)
sp = SamplingParams(
temperature=0.7,
top_p=0.95,
max_tokens=256,
)
prompts = [
"用一句话解释 PagedAttention。",
"列出 3 个训练与推理的工程差异。",
]
outputs = llm.generate(prompts, sp)
for o in outputs:
print("===")
print(o.prompt)
print(o.outputs[0].text)或以 OpenAI 兼容方式作为服务跑起来：
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct \
--tensor-parallel-size 1 \
--max-model-len 8192 \
--gpu-memory-utilization 0.9 \
--port 8000curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen/Qwen2.5-7B-Instruct",
"messages": [{"role": "user", "content": "一句话解释 continuous batching"}],
"stream": true
}'建议你在读后续每一篇的时候，都回到这个最小示例，用它验证新学的概念：TTFT
怎么测、KV 缓存多大、改
--max-num-batched-tokens 对吞吐的影响、切到 FP8
模型后显存下降多少，等等。
把推理服务跑起来之后，用下面的脚本测自己的第一张”性能体检表”：
import time, requests, json
url = "http://localhost:8000/v1/chat/completions"
payload = {
"model": "Qwen/Qwen2.5-7B-Instruct",
"messages": [{"role": "user", "content": "讲一个 300 字的分布式系统小故事"}],
"stream": True,
"max_tokens": 400,
}
t0 = time.time()
first_token_t = None
n_tokens = 0
with requests.post(url, json=payload, stream=True) as r:
for line in r.iter_lines():
if not line or not line.startswith(b"data: "):
continue
data = line[6:]
if data == b"[DONE]":
break
chunk = json.loads(data)
delta = chunk["choices"][0]["delta"].get("content", "")
if delta:
if first_token_t is None:
first_token_t = time.time()
n_tokens += 1
t_end = time.time()
ttft = (first_token_t - t0) * 1000
tpot = (t_end - first_token_t) / max(n_tokens - 1, 1) * 1000
print(f"TTFT = {ttft:.1f} ms, TPOT = {tpot:.1f} ms, tokens = {n_tokens}")跑完后，尝试回答这几个问题：
max_num_batched_tokens 参数，吞吐和
TPOT 怎么权衡？这些问题的系统回答在第 11–13 篇。
pip install "vllm>=0.6.0" auto-gptq把模型从 FP16 换到 AWQ / GPTQ 的 INT4 版本，对比：
这正是第 14 篇会系统讲的”量化工程”的入口体验。
最后留下几条贯穿整个系列的观点，后续文章会反复回到它们：
大模型基础设施是一个独立的工程学科，套用传统后端经验会在显存、带宽、通信、故障模型上反复碰壁；
工程创新正在取代硬件堆量成为主要降本手段，FP8、MLA、MoE、PagedAttention、推测解码是过去两年最大的几处杠杆；
推理侧的重要性会继续超过训练侧：reasoning 模型让单次请求消耗的算力以 10 倍计增长，推理集群规模会成为 LLM 公司最大的基础设施；
中国和全球的工程路径正在并轨又分岔：架构上殊途同归（MoE + 长上下文 + 推理增强），生态上分化（昇腾 / 海光 / 摩尔线程 vs Nvidia，火山 / 阿里 / 百度 vs AWS / Azure / GCP）；
开源基础设施已经足够撑起一个严肃的 LLM 平台：vLLM + SGLang + LangGraph + Milvus + Langfuse + LiteLLM 这套组合在 2026 年足以覆盖绝大多数企业场景；
可观测性决定你能不能活下来：没有 token 级追踪、没有成本归因、没有评测回归，任何 LLM 平台都只是一个贵而脆的玩具。
训练与推理正在工程上再次融合：RLHF、推理时 reasoning、在线蒸馏、active learning 让”训练集群”和”推理集群”开始共享调度、共享数据通路；
RAG 不会消失：即使上下文窗口到了百万级，成本、可更新性和可解释性三个理由让 RAG 长期存在；
Agent 是下一个真正改变形态的点：它把 LLM 从”文本函数”变成”可以影响世界的进程”，对基础设施的要求是完全新的（沙箱、配额、审计、回滚）；
国产替代是一个不得不面对的工程问题：不是口号，是真实的采购约束，系列中会给出昇腾 / 海光 / 摩尔线程等栈的对比视角。
如果你是第一次认真学这套栈，建议下一步：
如果你已经在做 LLM 平台：
下一篇：GPU 计算入门：SM、Tensor Core、HBM、NVLink
把当前热点继续串成多页阅读，而不是停在单篇消费。
2026-04-22 · architecture / ai-infra
面向中国工程团队的大模型基础设施系列。从 GPU/CUDA/互联、训练框架与 3D 并行、vLLM/SGLang 推理引擎、量化与推测解码、RAG/Agent 到服务化、网关、可观测性与安全合规，覆盖 LLMOps 全链路。
2026-04-22 · architecture / ai-infra
以工程视角串联现代 LLM 的四阶段训练栈——预训练、中训、SFT 与对齐——覆盖数据、Tokenizer、优化器、精度、Scaling Law 与代表性训练框架。
2026-04-22 · architecture / ai-infra
混合专家（MoE）模型训练工程实战：从 GShard、Switch、Mixtral 到 DeepSeek-V3，覆盖门控、负载均衡、Expert Parallel、All-to-All 通信与 DeepEP / MegaBlocks 等开源栈
2026-04-22 · architecture / ai-infra
从 Prefill/Decode 两阶段、KV Cache、Continuous Batching 到 PD 分离，系统讲清楚大模型推理的工程基础。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。