总体架构解剖

一个"推理系统"到底由什么组成？多数初学者的想象是"加载模型、跑 forward"，但真实的生产级 LLM 服务远不止于此。本文把一套完整的推理系统拆成六层，每层一句话讲清"干什么、为什么、坑在哪"，并链接到全站对应页面。这一页是全站的地图——读完它，你对整个领域的骨架就有了。

一、全景图

┌─────────────────────────────────────────────────────────────────────┐
│ ⑥ 应用层   │ API 网关 · 流式 · Function Calling · RAG · Agent       │
│            │ 用户与模型的边界：把 token 流变成产品体验              │
├────────────┼──────────────────────────────────────────────────────┤
│ ⑤ 编排层   │ 请求调度 · Batching · 路由 · 多模型路由 · 缓存        │
│            │ 多请求与多模型的调度器：让 GPU 喂饱、让请求各走各路    │
├────────────┼──────────────────────────────────────────────────────┤
│ ④ 引擎层   │ vLLM · TensorRT-LLM · SGLang · TGI · Triton · llama.cpp│
│            │ 把模型权重变成可调用的服务：执行 forward、管 KV cache  │
├────────────┼──────────────────────────────────────────────────────┤
│ ③ 算子层   │ FlashAttention · FlashInfer · 算子融合 · 自定义核     │
│            │ 单算子的极致优化：把访存与算力的差距压平               │
├────────────┼──────────────────────────────────────────────────────┤
│ ② 模型层   │ 量化 · 剪枝 · 蒸馏 · 稀疏化                           │
│            │ 把模型本身变小：降显存、降访存、提算力密度             │
├────────────┼──────────────────────────────────────────────────────┤
│ ① 硬件层   │ GPU (H100/A100/L40) · NPU (昇腾/ANE) · CPU (AMX/AVX)   │
│            │ 物理算力与带宽：一切优化的天花板                       │
└────────────┴──────────────────────────────────────────────────────┘
        ▲ 越上层越接近用户、越偏工程；越下层越接近硬件、越偏算法 ▼

六层不是孤立的——上层依赖下层的能力，下层通过上层变现。一个真实的生产 LLM 服务（如 ChatGPT、Claude API）通常是六层全部叠加优化的结果。下面逐一解剖。

二、六层解剖

① 硬件层：物理算力与带宽

一切优化的天花板。推理硬件分三大类：

• GPU：LLM 推理的事实标准。NVIDIA H100（80GB HBM3、2TB/s 带宽、FP8 Tensor Core）、A100（80GB HBM2e、1.5TB/s）、L40/L40S（48GB，性价比卡）、消费级 RTX 4090（24GB，社区部署常用）。详见GPU 优化与硬件入门。
• NPU：国产化与端侧场景的替代。华为昇腾 910B、Apple Neural Engine（M 系列芯片）、寒武纪 MLU 等，对推理友好但对训练支持弱。
• CPU：边缘部署与极端低成本场景。Intel AMX（Sapphire Rapids 起）、AVX-512/VNNI，配合 OpenVINO 与 llama.cpp 可在服务器 CPU 上跑 7B 模型。

为什么硬件层是优化的天花板

任何上层优化都受限于硬件的物理参数。LLM 推理最关键的两个硬件指标：HBM 带宽（决定 decode 阶段 token/s 上限）和显存容量（决定能装多大模型、多少 KV cache）。A100 80GB 带宽 1.5TB/s，单请求跑 Llama-2-70B FP16 的 token/s 上限约 1.5TB/s ÷ 140GB ≈ 10.7 tokens/s——这就是为什么单请求 LLM 推理的"快"不能靠优化算力，只能靠降显存（量化）或抬并发（batching）。详见访存与带宽与Roofline 模型。

② 模型层：把模型变小

模型层优化不改变推理引擎，只改变模型本身。三大手段：

• 量化（Quantization）：FP16 → INT8/INT4/FP8，降显存 + 降访存 + 提算力，是性价比最高的优化。LLM 主流量化方案见模型量化基础与权重 only 与混合精度。
• 剪枝（Pruning）：去掉不重要的权重/通道/头。结构化剪枝（去整行整列）能真省算力，非结构化需要稀疏核支持，LLM 上工程化难度大。详见剪枝。
• 蒸馏（Distillation）：用大模型教小模型，让小模型逼近大模型质量。对 LLM 而言蒸馏成本高，但在分类/检索等任务上仍是重要手段。详见知识蒸馏。

模型层是上层引擎能否跑得动的先决条件——70B 模型不量化到 INT4，单卡 80GB A100 装不下；而装不下就要走张量并行，复杂度立即上升一个量级。

③ 算子层：把单算子写快

算子层是"针对单个最热算子写优化 kernel"，是推理工程的技术深水区。

• FlashAttention-2/3：把 attention 的中间 QK^T 矩阵分块到 SRAM 计算，避免 HBM 来回读写——单算子 2-4x 加速，是 LLM 推理的绝对标配。详见算子融合。
• FlashInfer：UC Berkeley 出的算子库，统一 prefill/decode 的 attention 实现，被 vLLM/SGLang/TensorRT-LLM 大量采用。
• 手写 CUDA/Triton kernel：vLLM、SGLang 的核心竞争力之一就是自家特制的 attention/rmsnorm/rope kernel。

算子层的关键判断：当 GPU 利用率 < 30% 时，瓶颈在算子，需要手写核；当 GPU 利用率 > 60% 时，瓶颈在调度，需要靠 batching。这个判断决定了你应该优化哪一层。

④ 引擎层：把权重变成服务

引擎层是推理工程师日常打交道最多的一层——它把"模型权重 + 硬件 + 算子 + 调度"打包成一个可调用的服务。

引擎	主场	强项	弱项
vLLM	开源 LLM 服务	PagedAttention、continuous batching、易用	算子极致性不如 TensorRT-LLM
TensorRT-LLM	NVIDIA 闭源极致	H100 上最快、FP8/FP4 支持最好	部署复杂、社区小
SGLang	结构化生成、Agent	RadixAttention（前缀共享）、compressed FSM	通用对话场景优势小
TGI	HuggingFace 生态	与 HF 模型库无缝	性能略逊 vLLM
Triton Server	多模型多框架	多模型管理、企业级	对 LLM 优化不如专用引擎
llama.cpp	CPU/边缘	极致跨平台、量化好	大流量场景性能不足
ONNX Runtime	非 LLM 模型	跨硬件、生态成熟	LLM 支持弱
OpenVINO	Intel 硬件	CPU/iGPU 优化好	仅 Intel 生态

引擎选型的核心逻辑见引擎对比。一句话总结：NVIDIA GPU + 大流量 → vLLM/TensorRT-LLM；CPU/边缘 → llama.cpp/OpenVINO；多模型混合 → Triton Server。

⑤ 编排层：把多请求喂饱

编排层是 LLM 推理工程化的核心创新层，也是 2023 年后推理工程师最关心的层。

• Continuous batching：让长短不一的请求动态加入和退出 batch，把 GPU 利用率从 <5%（单请求 decode）拉到 60%+。详见批处理与调度。
• KV cache 管理：PagedAttention 把 KV cache 分页，消除碎片，把并发数从个位数拉到几十。详见vLLM 案例。
• 请求路由：简单请求走小模型、复杂请求走大模型，整体成本下降 50%+。详见模型服务。
• 投机解码：用草稿头先猜几个 token、大模型并行验证，2-6x 加速且不改输出分布。详见投机解码案例。
• 多模型路由：A/B 测试、金丝雀发布、按流量切流。

编排层的价值在于：在不改变模型权重、不更换硬件的前提下，把吞吐提升 10-100 倍。这是 vLLM、SGLang 的核心竞争力所在。

⑥ 应用层：把 token 流变成产品

应用层是用户与模型的边界，决定了推理系统的产品形态：

• API 网关：鉴权、限流、计费、日志——把推理引擎包装成稳定 API。
• 流式输出：SSE/WebSocket 让用户看到 token 一个个出来，首 token 延迟（TTFT）比末 token 延迟更重要。详见延迟与吞吐。
• Function Calling / Tool Use：模型生成结构化调用，应用层执行后回填——这要求引擎支持结构化输出加速（如 SGLang 的 compressed FSM）。
• RAG（检索增强生成）：检索 → 拼 prompt → 推理，prompt 前缀可被 RadixAttention 共享缓存，详见vLLM/SGLang。
• Agent：多轮推理 + 工具调用 + 循环，对推理引擎的延迟与并发提出新要求。

应用层决定了优化的方向：流式场景优先 TTFT；批处理场景优先总吞吐；Agent 场景优先前缀共享与并发数。脱离应用形态谈"哪个引擎最快"是耍流氓。

三、六层的权重与岗位画像

不同岗位在这六层上的精力分布差别很大，直接对应求职与 JD 分析的岗位版图：

层	推理工程师	算法工程师	基础设施工程师	应用工程师
⑥ 应用层	★★	★	★★	★★★★★
⑤ 编排层	★★★★★	★★	★★★★	★★
④ 引擎层	★★★★★	★★★	★★★★	★
③ 算子层	★★★★	★★★★	★★	—
② 模型层	★★★★	★★★★★	★	★
① 硬件层	★★★	★★★	★★★★★	—

给入门者的建议：⑤ 和 ④ 是推理工程师的"主战场"——⑤ 决定吞吐上限、④ 决定单请求延迟下限。② 是算法背景强的人最易上手的入口（量化/剪枝），③ 是硬核系统工程师的护城河，① 是基础设施工程师的加分项。按学习路径的三条路线对号入座。

四、贯穿全站的四个视角

• 概念视角：核心知识 系列把六层背后的原理讲透；
• 案例视角：经典案例 八篇看真实引擎怎么落地；
• 论文视角：论文精读 回到底层文献；
• 实践视角：实践指南 带你亲手搭出这几层。

这一页怎么用

• 想快速建立全局观：通读本文即可；
• 想深入某一层：点链接进对应页面；
• 想动手：直接去从零构建推理服务，对照本文六层看 demo 覆盖了哪些、缺了哪些——缺的正是你该补的。

五、一张总图：六层叠加的真实生产栈

把今天一个典型的 Llama-3-70B 生产服务（vLLM on H100）摆开看，六层叠加是这样的：

应用层:   OpenAI 兼容 API + 流式 SSE + Function Calling
编排层:   vLLM continuous batching + PagedAttention + EAGLE-3 投机解码
引擎层:   vLLM 0.6+ (含 RadixAttention 前缀共享)
算子层:   FlashAttention-3 + FlashInfer + RMSNorm/RoPE 融合核
模型层:   AWQ INT4 权重量化 + FP16 激活 (混合精度)
硬件层:   8×H100 80GB + NVLink + IB

这套组合在 Llama-3-70B 上单节点聚合吞吐可达 5000-10000 tokens/s——相比 HuggingFace Transformers 单请求 ~20 tokens/s，约 250-500 倍提升，且模型权重一字未改。这就是六层叠加的威力，也是推理工程作为独立学科存在的理由。

延伸阅读

• 什么是推理加速——本文的起点定义
• 演进简史——六层架构是怎么一步步长出来的
• 推理 vs 训练 vs 微调——推理工程的独特性
• 学习路径——按六层选一条路线
• 延迟与吞吐——推理性能指标族
• 访存与带宽——为什么 LLM 推理是访存瓶颈
• 模型量化基础——模型层的核心手段
• vLLM 与 PagedAttention——编排层的标杆
• 从零构建推理服务——把六层亲手搭出来

参考资料

• Kwon et al. Efficient Memory Management for LLM Serving with PagedAttention (SOSP 2023) —— 编排层的标杆论文
• Dao et al. FlashAttention (NeurIPS 2022) —— 算子层的代表
• Lin et al. AWQ: Activation-Aware Weight Quantization (MLSys 2024) —— 模型层的 INT4 工程化
• NVIDIA. TensorRT-LLM —— 引擎层的工程参考
• NVIDIA. H100 Tensor Core GPU Architecture White Paper —— 硬件层的基础
• Zheng et al. SGLang: Efficient Execution of Structured Language Model Programs (NeurIPS 2024) —— 编排层的前缀共享与结构化加速