用基础模型构建应用（第九章）AI Engineering: Building Applications with Foundation Models学习笔记

在 AI 技术飞速发展的今天，新模型层出不穷，但让模型在保持性能的同时变得更快、更经济始终是核心需求。本章（Inference Optimization 推理优化）就聚焦这一关键问题，深入探讨了 AI 推理过程中可能遇到的瓶颈，以及从模型、硬件和服务三个层面进行优化的技术与方法。无论是模型运行速度过慢导致用户流失，还是成本过高影响投资回报，本章都能剖析原因并提供切实可行的解决方案，帮助读者更好地理解和优化 AI 推理过程。

目录

1 Understanding Inference Optimization（理解推理优化）

1.1 Inference Overview（推理概述）

1.2 Inference Performance Metrics（推理性能指标）

1.3 AI Accelerators（AI 加速器）

2 Inference Optimization（推理优化）

2.1 Model Optimization（模型优化）

2.2 Inference Service Optimization（推理服务优化）

---

1 Understanding Inference Optimization（理解推理优化）

AI模型生命周期的两个核心阶段：①训练（Training）：构建/开发模型的过程。②推理（Inference）：使用训练好的模型，根据输入数据计算输出结果的过程。

1.1 Inference Overview（推理概述）

在生产环境中，运行模型推理的组件是推理服务器，它是更广泛的推理服务的一部分。模型 API（如 OpenAI 和 Google 提供的）就是推理服务，若自行托管模型，则需负责构建、优化和维护其推理服务。

• 推理服务器（inference server）：负责托管可用模型，并能访问必要的硬件资源。接收应用程序的请求（如用户提示）后，分配资源执行相应模型，再将结果返回给用户。

• 推理服务（inference service）的范围：还需承担接收请求、路由请求，以及可能在请求到达推理服务器前对其行预处理等任务。下图展示了简单推理服务的结构。

1.1.1 Computational bottlenecks（计算瓶颈）

1. 计算瓶颈的本质与分类

瓶颈类型	定义	关键特征	典型案例
计算受限 (Compute-Bound)	任务耗时由计算量决定，硬件算力（FLOP/s）是瓶颈	密集数学运算需求	密码解密、图像生成（如Stable Diffusion）
内存带宽受限 (Memory Bandwidth-Bound)	任务耗时由数据搬运速度决定，内存与处理器间带宽是瓶颈	大规模数据加载需求	LLM解码阶段、CPU-GPU数据传输

💡 术语澄清：Memory-Bound（内存受限） vs Bandwidth-Bound（带宽受限）

• 内存容量不足（OOM错误） 本质是带宽受限的子问题（需拆分任务缓解）。如内存不足无法存储全部数据，可将模型拆分到 GPU 和 CPU 内存，但会因数据传输增加耗时，本质仍与内存带宽相关。

• 业界常将"内存带宽受限"简称为"内存受限"。

 2. 瓶颈诊断工具：屋顶线模型（Roofline Model）

• 识别工具：Williams et al. (2009) 论文提出，通过算术强度（Arithmetic Intensity） 量化瓶颈：$$\text{算术强度} = \frac{\text{浮点运算次数}}{\text{内存访问字节数}} $$
• 可通过性能分析工具（如 NVIDIA Nsight）生成 “Roofline 图表” 判断任务是计算密集型还是内存带宽密集型。

• 输出：对数坐标下的屋顶线图（Roofline Chart）；X轴：算术强度；Y轴：可达性能（FLOP/s）；屋顶线：硬件算力上限（水平线）与带宽上限（斜线）的交界。

• 判定规则：①任务点位于水平线下方 → 计算受限；②任务点位于斜线下方 → 内存带宽受限。

3. 瓶颈优化方向：①计算密集型：通过增加芯片数量或使用计算能力更强的芯片（如更高 FLOP/s 的硬件）加速。②内存带宽密集型：使用更高带宽的芯片提升数据传输速度。

4. LLM 推理的瓶颈细分（以 Transformer 为例）

语言模型推理分为预填充（prefill） 和解码（decode） 两步，瓶颈不同：

• 预填充（prefill）：并行处理输入 token，一次处理的 token 数量受硬件单位时间内的计算能力限制，属于计算密集型。
• 解码（decode）：逐一生成输出 token，需加载大型矩阵（如模型权重）到 GPU，受数据加载速度限制，属于内存带宽密集型。

影响LLM推理瓶颈的因素：①上下 文长度（Context Length）：长上下文加剧内存带宽压力 → 需专用优化技术（如本章后续介绍的KV Cache优化）。②输出长度（Output Length）：解码阶段占比随输出长度增加 → 带宽瓶颈放大。③请求批处理策略（Batching）：动 态批处理可提升吞吐但增加内存压力 → 需权衡带宽限制。

5. 现状与未来趋势：Transformer架构+现有硬件 → 当前多数 AI 和数据工作负载是内存带宽密集型。软硬件进步可能使 AI 和数据工作负载转为计算密集型。

1.1.2 Online and batch inference APIs（在线和批量推理 API）

1. 两种推理 API 的核心差异与特点

1）在线推理 API（Online APIs）注重延迟，请求到达后立即处理。低延迟，同时兼顾一定吞吐量。

• 批处理特性：可在不显著影响延迟的前提下对请求进行批处理。

• 适用场景：面向客户的场景，对低延迟要求高，如聊天机器人、代码生成等实时交互场景。

2）批量推理 API（Batch APIs）注重成本，适用于对延迟要求不严格的场景。高吞吐量，以成本换延迟。

• 优势来源：更高延迟允许更广泛的优化（如请求批量处理、使用更便宜的硬件），从而降低成本（例如 Google Gemini 和 OpenAI 的批量 API 成本降低 50%，但响应时间从秒 / 分钟级延长至小时级）。
• 适用场景：延迟要求宽松的场景，如合成数据生成、周期性报告（如 Slack 消息总结、社交媒体品牌情感分析、客户支持工单分析）、为大量客户生成个性化推荐或新闻通讯、迁移到新模型时重新处理所有数据、通过重新索引组织数据更新知识库。

特性	在线推理API (Online)	批量推理API (Batch)
优化目标	低延迟（毫秒-秒级响应）	低成本（50%+成本节省）
处理机制	实时处理请求（流式优先）	积攒请求批量处理
硬件策略	高性能硬件（如GPU）	廉价硬件（如CPU集群）
典型延迟	秒级/分钟级（如ChatGPT实时交互）	小时级（Gemini/OpenAI批处理API）
技术灵活性	支持流式输出（逐token返回）	仅返回完整结果

2. 在线 API 的流式传输模式（Streaming Mode）

• 背景：自回归解码中，模型生成完整响应耗时较长，用户等待耐心有限。
• 流式模式特点：生成每个 token 后立即返回，减少用户等待首个 token 的时间。
• 优势：消除用户等待焦虑（尤其长文本生成场景）。
• 风险：无法前置过滤违规内容 → 增加用户看到不良内容的风险，但可在检测到风险后追溯更新或删除响应。

3. 基础模型批量 API vs 传统机器学习批量推理的区别

维度	传统机器学习批量推理	基础模型批量 API
计算时机	预计算（请求前生成结果，离线完成）	延迟计算（收到请求后处理）
输入可预测性	输入有限且确定（如用户ID列表）	输入开放不可预测（任意用户prompt）
请求处理逻辑	请求到达时直接调取预计算结果	接收请求后批量处理，无预计算环节

例：传统电商推荐可预生成所有用户的推荐列表；但GPT类模型无法预知用户将输入的提问内容。

1.2 Inference Performance Metrics（推理性能指标）

1.2.1 Latency, TTFT, and TPOT（延迟、首 token 生成时间和每个输出 token 生成时间）

1. 延迟核心指标解析

延迟（latency）是从用户发送查询到收到完整响应的时间。在自回归生成（尤其流式模式）中，延迟可细分为以下关键指标：

指标	定义	影响因素	用户体验关联
TTFT	用户发送请求到收到首个输出token的时间	预填充阶段耗时 （与输入长度强相关）	决定“系统响应感” （聊天场景需<500ms）
TPOT	首个token后每个输出token的生成间隔	解码阶段效率 （权重加载速度）	影响“输出流畅度” （需匹配人类阅读速度）
总延迟	TTFT + TPOT × 输出token数	两阶段叠加效应	决定任务完成时间

• 其他衍生指标：token 间隔时间（Time Between Tokens, TBT）、token 间延迟（Inter-Token Latency, ITL），均衡量输出 token 之间的时间间隔。

2. 用户体验与指标平衡：总延迟相同的情况下，TTFT 和 TPOT 的不同组合会带来不同用户体验：是 “首 token 即时生成，但后续 token 间隔长”，还是 “首 token 稍慢，但后续 token 生成更快”？需通过用户研究确定最优方案。

• 可通过资源分配调整两者平衡（如将更多计算资源从解码转向预填充，或反之）。

3. 用户感知与模型实际指标的差异：在涉及思维链（CoT）或智能体（agentic）查询的场景中，用户感知的 TTFT 可能远长于模型实际的 TTFT。

• 模型视角：首 token 可能在内部步骤（如生成计划、执行动作）中已产生。
• 用户视角：仅能看到最终响应的首 token，因此感知的 TTFT 是从查询发送到最终响应首 token 生成的时间。

4. 延迟的统计与分析方法：延迟是一个分布，平均值可能有误导性（受异常值影响，如 10 个请求中 1 个耗时 3000ms，会使平均 TTFT 从约 100ms 升至 390ms），通常看分位数（能反映多数请求的性能）。

• 常见分位数包括：p90、p95、p99分别代表 90%、95%、99% 的请求性能优于该值，可用于发现异常值（可能暗示系统问题）。
• 辅助分析方式：将 TTFT 与输入长度关联绘图，便于观察输入长度对首 token 生成时间的影响。

1.2.2 Throughput and goodput（吞吐量和有效吞吐量）

吞吐量反映系统的整体处理能力，而有效吞吐量反映系统满足质量标准的实际能力，两者结合可全面评估推理服务的性能与用户体验。

1. 吞吐量（Throughput）核心定义与计算

• 定义：吞吐量是推理服务在所有用户和请求中每秒生成的输出 token 数量（单位通常为 tokens/s，即 TPS）。也可用每秒请求数（RPS）或每分钟完成请求数（RPM）衡量。
• 其他衡量维度：①按用户维度：tokens/s/user（评估系统随用户量增长的扩展性）。②按请求数量：每秒完成的请求数（RPS）或每分钟完成的请求数（RPM，因基础模型请求可能耗时数秒，RPM 更常用），用于衡量并发处理能力。
• 计算争议：部分团队会将输入 token 和输出 token 一同计入，但由于处理输入（预填充）和生成输出（解码）的计算瓶颈不同，通常建议分开统计；未加说明时，吞吐量默认指输出 token 的吞吐量。

2. 吞吐量与成本的关联：吞吐量越高，单位 token / 请求的成本越低。

• 示例：硬件成本$2/小时，若吞吐量为100 tokens/s，每100万输出token成本约$5.556；若每请求平均生成 200 个输出 token，1000 个请求的解码成本约 $1.11。
• 预填充成本可单独计算（如$2/小时硬件，每分钟预填充100个请求，1000个请求的预填充成本约$0.33），总请求成本为预填充成本 + 解码成本。

3. 影响吞吐量的因素

因素	影响规律	优化空间
模型规模	模型越小 → 吞吐量↑	小型化模型（蒸馏/量化）
硬件性能	高端芯片（H100 vs A100）→ 吞吐量↑	硬件升级
请求一致性	输入/输出长度稳定 → 批处理效率↑，吞吐量更可控	请求分组调度

• 局限性：不同模型的 tokenizer（分词器）不同，token 定义有差异，直接对比吞吐量可能不够准确，建议结合 “每请求成本” 等指标评估。 

4. 吞吐量与延迟的权衡：提升吞吐量的技术（如批处理）可能增加延迟（牺牲 TTFT 和 TPOT）。

• 案例：LinkedIn 实践显示，若能接受延迟上升，吞吐量可能提升 2-3 倍。

5. 有效吞吐量（Goodput）：用户体验导向的核心指标

• 定义：从网络领域适配到 LLM 应用的指标，衡量每秒满足服务等级目标（SLO）的请求数量（即符合 latency、token 生成速度等预设标准的请求量）。
• 与吞吐量的区别：吞吐量仅统计 “完成的请求”，而有效吞吐量只统计 “达标（满足 SLO）的请求”，更贴近用户体验和实际服务质量。有效吞吐量避免单纯追求高吞吐量和低成本而牺牲用户体验，强调 “达标请求” 的效率，更适合作为推理服务的核心评估指标。
• 示例：若应用 SLO 为：TTFT≤200ms 且 TPOT≤100ms。如下图，若服务每秒完成 10 个请求（10 RPS），但仅 3 个符合 SLO，则 goodput 为 3 RPS。

1.2.3 Utilization, MFU, and MBU（利用率、模型 FLOP/s 利用率和模型带宽利用率）

利用率指标衡量资源的使用效率，通常表示资源实际使用量占总可用容量的比例。跟踪利用率可评估系统效率，相同硬件和工作负载下，更高的利用率通常意味着服务更高效。

• 局限性：高利用率并非唯一目标，需结合成本和延迟综合评估。例如，利用率提升但成本和延迟同时增加，则无实际价值。

1. 常见利用率指标及区别

1）GPU 利用率：由 NVIDIA 工具 nvidia-smi 提供，反映 GPU活跃处理任务的时间占比（如 10 小时内 5 小时活跃，利用率为 50%）。

• 局限性：仅体现 “是否活跃”，不反映 “效率高低”。例如，一台每秒可处理 100 次操作的 GPU，即使每秒只处理 1 次操作，仍可能显示 100% 利用率，无法体现资源浪费。

2）模型 FLOP/s 利用率（MFU）：衡量系统实际吞吐量（tokens/s）与理论最大吞吐量（芯片峰值 FLOP/s 对应的 tokens/s）的比例，反映计算资源的实际效率。

• 计算公式：MFU = 实际吞吐量（tokens/s） / 理论最大吞吐量（tokens/s）
• 示例：芯片峰值性能下可生成 100 tokens/s，实际生成 20 tokens/s，则 MFU 为 20%。

3）模型带宽利用率（MBU）：衡量内存带宽的实际使用效率，即实际数据传输速率（实际内存带宽）占硬件理论最大带宽的比例。

• 计算公式：实际带宽使用量 = 模型参数数量 × 每个参数的字节数 × 吞吐量（tokens/s）；MBU = 实际带宽使用量 / 硬件理论最大带宽。

吞吐量（tokens/s）与 MFU、MBU 呈线性关系，因此有时可用吞吐量间接反映后两者。

2. 影响 MFU 和 MBU 的因素

1）工作负载类型：①计算密集型任务：MFU 较高，MBU 较低（受计算能力限制）。②内存带宽密集型任务：MFU 较低，MBU 较高（受数据传输速度限制）。

2）场景差异：①训练 vs 推理：训练因工作负载更可预测（如更好的批处理），MFU 通常高于推理。②推理内部：预填充（compute-bound）阶段 MFU 高于解码（memory bandwidth-bound）阶段。

3）参考标准：MFU 超过 50% 通常被认为是较好的水平（但受硬件限制可能难以实现）。但具体数值需结合模型、硬件和工作负载判断（如下表列举了不同模型和加速器的 MFU 示例）。

• 示例（下图）：Llama 2-70B 模型（FP16）在不同硬件上的 MBU 随并发用户数增加而下降，原因是用户增多导致计算负载上升，工作负载从带宽密集型转向计算密集型。

1.3 AI Accelerators（AI 加速器）

AI 加速器（尤其 GPU）是 AI 发展的硬件基础，其设计需匹配任务特性（如推理 vs 训练、模型架构），而多样化的专用芯片正成为趋势。

1. What’s an accelerator?（什么是加速器？）：

• 加速器是为特定计算工作负载设计的芯片，AI 加速器专为 AI 工作负载设计，主流是 GPU。CPU 和 GPU 的主要区别是 CPU 为通用用途设计，GPU 为并行处理设计。

1）CPU vs GPU

维度	CPU（中央处理器）	GPU（图形处理器）
设计目标	通用计算，擅长单线程高性能任务	并行处理，优化多任务并行计算
核心特点	核心数量少（高端消费级机器通常≤64 核），核心功能强	核心数量多（数千个），单个核心功能较弱但适合并行任务
擅长场景	操作系统运行、I/O 管理、复杂顺序流程等	图形渲染、机器学习（尤其矩阵乘法等高度并行操作）

2）推理专用加速器的兴起：推理成本可能超过训练成本，在部署的 AI 系统中，推理成本占比可达 90%，催生了推理专用芯片。

需求	训练	推理
内存	需求更高（因反向传播）	更注重内存访问速度，而非大容量
精度	难以用低精度，对精度要求更高	可优化为低精度（如量化）
核心目标	强调吞吐量	以最小化延迟为目标

• 推理专用芯片示例：①数据中心级：AWS Inferentia、Meta MTIA（兼顾训练与推理）。②边缘设备级：苹果 Neural Engine、谷歌 Edge TPU、NVIDIA Jetson Xavier（适配手机、笔记本等消费设备）。

3）加速器的细分与硬件适配：①按模型架构：出现针对特定架构（如 Transformer）的专用芯片。②按计算单元：不同芯片优化不同数据类型（标量、向量、张量），例如传统 GPU 擅长向量操作，现代 GPU 新增张量核心。

• 高效运行前提：需匹配芯片的内存布局和计算单元特性。

4）评估芯片的核心指标：尽管芯片规格复杂，但跨场景通用的关键特性包括：①计算能力、②内存大小与带宽、③功耗。

2. Computational capabilities（计算能力）

• 通常以每秒浮点运算次数（FLOP/s）衡量，常写作 FLOPS，实际应用很难达到理论峰值 FLOP/s。
• 芯片在不同数值精度下的运算能力不同，精度越高，每秒能执行的运算越少（例如，32 位数值的加法运算通常比 16 位更复杂）。但不同精度的操作数量并非严格成比例（如 32 位操作数不一定是 16 位的一半），因芯片对不同精度的优化程度不同。下表展示了 NVIDIA H100 SXM 芯片在不同精度格式下的 FLOP/s 规格，可直观体现精度对峰值计算能力的影响。

3. Memory size and bandwidth（内存大小和带宽）

GPU 因包含大量并行核心，数据需频繁从内存传输到核心，因此数据传输速度（带宽） 至关重要。对于涉及大型权重矩阵和训练数据的 AI 模型，快速的数据移动是保证核心高效运行的前提。

• GPU 内存需要比 CPU 内存更高的带宽和更低的延迟，依赖更先进的内存技术，成本也更高。

1）CPU 与 GPU 的内存技术差异

• CPU：通常使用 DDR SDRAM（双倍数据速率同步动态随机存取存储器），采用 2D 结构。
• GPU（高端型号）：多使用 HBM（高带宽存储器），采用 3D 堆叠结构，能提供更高带宽。

2）加速器的内存层级结构（以 GPU 为例）

加速器 GPU 通常涉及 CPU 内存、GPU 高带宽内存（HBM）和 GPU 片上 SRAM 三级内存，从外到内速度递增、容量递减，具体如下：

内存类型	位置	功能	带宽范围	容量范围
CPU 内存（DRAM）	与 CPU 关联的系统内存	供加速器访问的外部内存	25–50 GB/s	笔记本 16–64 GB；高端工作站可达 1TB 以上
GPU 高带宽内存（HBM）	GPU 专用，靠近芯片	存储模型数据，支持高吞吐量任务	256 GB/s–1.5 TB/s	消费级 GPU 24–80 GB
GPU 片上 SRAM	集成在芯片内部	存储频繁访问的数据和指令（如缓存）	超过 10 TB/s	通常 40 MB 以下

• 细节补充：GPU 片上 SRAM 包括 L1、L2 缓存（部分架构含 L3 缓存），还包含寄存器文件、共享内存等组件，访问速度极快。

3）内存优化的现实挑战

• 框架限制：GPU 优化的核心是充分利用内存层级结构，但目前主流框架（如 PyTorch、TensorFlow）对内存访问的控制不够精细。

  • 核心矛盾：AI模型对内存带宽的极致需求 ↔ 现有框架无法直接优化内存访问

• 解决方案：①CUDA（NVIDIA专有）：主流GPU编程语言；②Triton（OpenAI开源）：面向AI计算优化；③ROCm（AMD开源）：对抗CUDA的开放生态。

4. Power consumption（功耗）

1）功耗的产生原因：芯片依靠晶体管进行计算，会消耗大量能量并产生热量。产生的热量需要冷却系统处理，而冷却系统本身也耗电，进一步增加数据中心的总能耗。

2）功耗的衡量指标：加速器通常会标明最大功耗或热设计功耗（TDP）。

• 最大功耗（Maximum power draw）：芯片满负荷运行时的峰值耗电量。
• 热设计功耗（TDP, thermal design power）：表示芯片在典型工作负载下，冷却系统需要消散的最大热量。TDP 并非精确的功耗值，而是预期功耗的参考指标。
• 关系：CPU 和 GPU 的最大功耗通常是 TDP 的 1.1-1.5 倍（具体因架构和工作负载而异）。

3）云服务场景下的功耗关注点：使用云服务时，用户无需担心冷却或电力供应，但了解这些功耗数据有助于理解加速器对环境的影响及整体电力需求。

5. Selecting Accelerators（选择加速器）

• 加速器选择取决于工作负载，计算密集型工作负载适合 FLOP/s 更高的芯片，内存密集型工作负载适合带宽更高、内存更大的芯片。
• 评估芯片的关键问题：需考虑硬件能否运行工作负载、运行时间和成本。
• 前两个问题的判断依据：FLOP/s（计算能力）、内存大小、内存带宽是核心指标，直接影响工作负载的可行性和运行效率。
• 成本计算方式：①使用云服务：按使用量计费（提供商定价）。②自行购买硬件：成本需结合初始购置价和持续的功耗费用综合计算。

2 Inference Optimization（推理优化）

1）推理优化可在三个层面进行（本章重点讨论模型层面和服务层面的优化技术）：

• ①模型层面优化：如同打造更好的箭（聚焦模型本身的改进）。
• ②硬件层面优化：如同训练更强、更优秀的弓箭手（聚焦硬件性能提升）。
• ③服务层面优化：如同改进整个射击流程（包括弓和瞄准条件等，聚焦系统级流程优化）。

2. 推理优化的理想状态是优化模型的速度和成本时，不改变模型的质量。现实问题是许多优化技术可能导致模型性能下降。 下图展示了不同推理服务提供商在不同基准测试中运行相同 Llama 模型的表现，服务提供商采用的优化技术可能改变模型行为，导致不同提供商的模型质量存在细微差异。

2.1 Model Optimization（模型优化）

• 模型优化的目标：通过修改模型本身，提升模型的运行效率。
• 潜在影响：优化过程可能改变模型行为（如性能、输出特性等）。

• 基础模型推理资源密集的原因：当前多数基础模型基于 Transformer 架构，且包含自回归语言模型组件，其推理消耗大量资源主要源于三个特征：①模型规模：模型参数数量庞大，导致存储和计算需求高。②自回归解码：逐 token 生成输出，过程串行化，耗时较长。③注意力机制：计算复杂度高（尤其长序列场景），对内存和计算资源需求大。

2.1.1 Model compression（模型压缩）

模型压缩是通过特定技术减小模型规模的方法。模型变小通常能提升运行速度。包括量化（降低模型精度）、蒸馏（训练小模型模仿大模型）和剪枝（移除神经网络节点或设置部分参数为零）等技术，可减小模型大小、提高速度。

1. 已讨论的两种模型压缩技术：量化（见第七章）、模型蒸馏（见第八章）。

2. 剪枝（Pruning）：另一种模型压缩技术

1）思路：假设大模型中存在一个参数子集，可捕获整个模型的行为，剪枝即基于此思路，通过移除冗余参数实现压缩。

2）剪枝方式：①移除神经网络中的整个节点，改变模型架构并减少参数总量。②将对预测最无用的参数设为 0，不减少总参数数量，但增加模型稀疏性（非零参数减少），从而节省存储空间并加速计算。

3）剪枝后的处理：剪枝后的模型可直接使用，或通过微调调整剩余参数，恢复剪枝可能导致的性能下降。

4）延伸应用：剪枝可用于发现更优的小型模型架构，这些架构可从零开始重新训练。

5）剪枝局限性：①实施难度高，需深入理解原模型架构。②性能提升常不及其他压缩技术。③剪枝导致模型稀疏化，但并非所有硬件都能适配稀疏模型的加速需求。

3. 主流模型压缩技术的对比

• 量化：最受欢迎，易于使用，对多数模型开箱即用，效果显著，但精度降低存在极限（最低 1 位）。
• 蒸馏：应用广泛，可生成小规模模型，满足特定场景下与大模型相当的性能需求。
• 剪枝：实际应用较少，受限于实施难度和硬件适配性。

2.1.2 Overcoming the autoregressive decoding bottleneck（克服自回归解码瓶颈）

自回归语言模型通过逐 token 生成输出，速度慢，成本高（输出 token 成本是输入的 2-4 倍，延迟影响显著）。通过①推测性解码（用更快但较弱的模型生成 token 序列，再由目标模型验证）、②带参考的推理（从输入中选择 token 作为候选）、③并行解码（同时生成多个 token）等技术优化提升生成效率。

1. 推测解码（Speculative Decoding / Speculative Sampling）

• 思路：用一个更快但能力较弱的 “草稿模型（draft model）” 生成候选 token 序列，再由目标模型（需使用的模型）并行验证，减少目标模型的串行生成步骤。（用小模型预生成 → 大模型并行验证）。

• 流程：①草稿模型基于输入 token（x₁, x₂,…,xₜ）生成 K 个候选 token（xₜ₊₁,…,xₜ₊ₖ）；②目标模型并行验证这 K 个 token，接受从左到右最长的一致子序列（假设接受 j 个，即 xₜ₊₁,…,xₜ₊ⱼ）；③目标模型额外生成 1 个 token（xₜ₊ⱼ₊₁），然后重复步骤 1（基于更新后的序列继续生成）。

• 优势：①验证过程并行化，将串行解码转为类预填充的并行计算，提升效率；②易实现（如 PyTorch 中 50 行代码即可），不影响模型质量；

• 应用：已集成到 vLLM、TensorRT-LLM、llama.cpp 等主流推理框架。

• 案例：DeepMind 用 4B 参数草稿模型加速 Chinchilla-70B，生成速度提升 8 倍，总延迟减少一半以上。

2. 带参考的推理（Inference with Reference）

• 思路：当输出中存在与输入重复的 token（如问答中引用文档内容、代码修复中复用原代码），直接从输入复制这些 token，而非让模型重新生成，减少生成步骤。

• 流程：①识别输出与输入的重复模式（如代码/文档引用）；②从输入中提取匹配文本跨度（text span）；③目标模型验证跨度的适用性。

• 特点：①类似推测解码，但候选 token 来自输入而非草稿模型，无需额外模型，零训练成本；②仅适用于 “输出与输入有大量重叠” 的场景（如检索系统、代码生成、多轮对话）。

• 示例（下图）：从输入中成功复制的文本片段分别用红色和绿色表示。在适用场景中，生成速度可提升 2 倍（Yang et al., 2023）。

3. 并行解码（Parallel Decoding）

• 思路：打破自回归的序列依赖，基于现有序列（x₁,…,xₜ）同时生成多个未来 token（xₜ₊₁,…,xₜ₊ₖ），再通过验证确保连贯性。

• 两类实现路径：

方法	Lookahead解码	Medusa架构
核心机制	单解码器多token并行	添加专用预测头（多头并行）
验证方式	Jacobi迭代验证	树状注意力选择最优路径
训练要求	无需微调	需训练新增预测头（原模型冻结）
复杂度	中等	高（需修改模型结构）

• Lookahead 解码：①并行生成 K 个未来 token；②验证其与上下文的一致性，若部分 token 失败，仅重新生成或调整失败 token，直至全部通过验证。

• Medusa：①在原模型基础上扩展多个解码头（小型神经网络层），每个头预测特定位置的未来 token（如第 k 个头预测 xₜ₊ₖ₊₁）；②用树状注意力机制验证 token 组合，从候选中选择最优序列。

• 效果：NVIDIA 称 Medusa 在 HGX H200 GPU 上可将 Llama 3.1 的 token 生成速度提升 1.9 倍（Eassa et al., 2024）。

• 挑战：需复杂的验证与整合步骤，实现难度较高。

技术总结：三种技术均旨在减少自回归解码的串行开销，其中推测解码因易实现、不影响模型质量而被广泛采用；带参考的推理适用于输入输出重叠场景；并行解码通过打破序列依赖提速，但实现复杂度较高。

维度	推测解码	参考推理	并行解码
加速原理	计算负载转移	避免重复生成	打破顺序依赖
额外资源	需草稿模型	无需	Medusa需训练新头
最佳场景	通用文本生成	高输入-输出重叠场景	长文本生成
加速比	2-3倍	~2倍	~2倍
实现难度	★★☆	★☆☆	★★★ (Medusa)

2.1.3 Attention mechanism optimization（注意力机制优化）

注意力机制的优化核心是解决长序列下的计算量与内存需求问题，通过 KV 缓存减少重复计算是基础，进一步可通过重新设计注意力机制、优化缓存管理、编写高效计算内核等方式，在保证性能的同时提升推理效率。

1. 注意力机制在推理中的核心挑战与 KV 缓存的引入

生成下一个 token 时，模型需要所有先前 token 的键（key）和值（value）向量（例如生成  需  至  的 K/V 向量）。为避免重复计算这些向量，推理中引入KV 缓存（KV cache），来存储这些向量以便复用（如下图）。

• 存储内容：每层所有历史token的Key/Value矩阵
• 作用：存储已生成 token 的 K/V 向量，生成新 token 时仅需计算最新 token 的 KV 向量并添加到缓存中，大幅减少重复计算。
• 适用场景：仅用于推理（训练时序列已知，可一次性计算所有 token 的 KV 向量，无需缓存）。

2. KV 缓存的规模与瓶颈

• 增长规律：①注意力计算量随序列长度指数增长（需与所有先前 token 计算注意力分数）；②KV 缓存大小随序列长度和批次大小线性增长（存储所有 token 的 KV 向量）。
• 规模示例：KV缓存大小 = 2×B×S×L×H×M，其中 B = 批大小、S = 序列长度、L = Transformer层数、H = 隐藏层维度、M = 数值精度。
  • 500B + 参数模型（多头注意力）在批次大小 512、上下文长度 2048 时，KV 缓存达 3TB（是模型权重的 3 倍，Pope et al., 2022）；
  • Llama 2 13B（40 层，模型维度 5120）在批次 32、序列长度 2048、FP16（2 字节 / 值）下，KV 缓存为 54GB。
• 瓶颈：受硬件存储限制，大缓存会限制长上下文应用，且加载耗时可能影响低延迟需求。
  • 缓存大小 ∝ 序列长度 × 批大小 → 长上下文场景内存爆炸

3. 注意力机制的优化技术

优化技术主要分为三类，分别从机制设计、缓存管理、计算效率入手：

（1）重新设计注意力机制（需在训练 / 微调时应用）

通过改变注意力的工作方式，减少计算量和缓存需求。

1）局部窗口注意力

• 原理：限制每个token仅关注固定窗口内的邻近token（如1,000 token窗口）。

• 效果：序列长度10k时缓存减少10倍（Beltagy et al., 2020）。

• 变体：局部+全局注意力混合（关键位置保留全局注意力）。

2）键值共享技术

技术	共享方式	缓存缩减比
多查询注意力 MQA	所有查询头共享同一组K/V	N_head倍
分组查询注意力 GQA	查询头分组，组内共享K/V	2-8倍
跨层注意力 CLA	相邻层共享K/V向量（如3层共享一组）	层数倍数（如减少至1/3）

3）案例：Character.AI 通过 MQA + 局部/全局注意力 + CLA → KV缓存减少20倍以上。180轮对话历史下，批处理能力不再受内存限制。

（2）优化 KV 缓存大小（聚焦缓存管理）

通过改进 KV 缓存的存储与管理，缓解内存瓶颈，支持更长上下文和更大批次。

• PagedAttention（vLLM 框架提出）：将 KV 缓存划分为非连续块，减少内存碎片，支持灵活的内存共享，提升 LLM 服务效率。
• 其他技术：KV 缓存量化、自适应 KV 缓存压缩、选择性 KV 缓存（仅保留关键 token 的缓存）等。

（3）编写注意力计算内核（优化计算过程）

针对硬件特性优化注意力分数的计算代码（称为 “内核”），提升计算效率。

• FlashAttention（下图）：将 Transformer 中多个常用操作融合为一个内核，减少数据在内存中的移动，显著加速注意力计算。

2.1.4 Kernels and compilers（内核和编译器）

• 内核：针对特定硬件编写的底层优化代码，通过向量化、并行化等技术提升计算效率。
• 编译器：将高层模型代码转换为硬件可执行的优化内核，是连接模型与硬件的桥梁。
• 协同作用：新硬件需配套新内核，而编译器可自动生成或选择适配的内核，两者共同推动 AI 推理性能的提升。

1. 内核（Kernels）：专门为特定硬件加速器（如 GPU、TPU）优化的代码片段，通常针对需反复执行的计算密集型任务（如矩阵乘法、注意力计算）进行并行优化。用于充分发挥硬件性能，提升计算效率。

• 编写内核的挑战：硬件知识要求高、编程语言门槛高（使用低级语言，如 CUDA、OpenAI Triton、AMD ROCm，难度高于 Python）、人力成本（需专业工程师）。

• 常见优化技术

技术	核心思路
向量化	将循环中逐个处理的数据改为同时处理内存连续的多个数据，减少 I/O 操作延迟。
并行化	将输入数组分割为独立块，分配给不同核心或线程同时处理，加速计算。
循环分块	根据硬件内存布局和缓存特性优化循环中的数据访问顺序（CPU 与 GPU 的优化模式可能不同）。
算子融合	将多个操作合并为单次执行，避免冗余内存访问（如合并对同一数组的多次循环操作）。

• 内核与硬件的绑定关系：新硬件架构需开发新内核（如 FlashAttention 最初针对 A100 GPU，后推出适配 H100 的 FlashAttention-3）。

2. 编译器（Compilers）：将模型代码转换为硬件兼容语言的工具，通过 “降低（lowering）” 过程将操作转换为硬件特定的优化内核。连接机器学习模型与硬件，提升执行效率。

• 常见编译器

编译器	所属生态	硬件支持	特点
torch.compile	PyTorch	多后端(NVIDIA/AMD)	动态图即时编译
XLA/OpenXLA	TensorFlow/JAX	TPU/GPU/CPU	静态图优化
TensorRT	NVIDIA	NVIDIA GPU	极致GPU优化
Apache TVM	开源跨平台	全平台	自动内核生成
MLIR	LLVM生态	全平台	多级中间表示统一框架

3. PyTorch 优化案例研究

• 实验背景：硬件：NVIDIA A100 80GB GPU；模型：Llama-7B。
• 优化目标：通过多轮优化提升吞吐量（tokens / 秒）。

优化步骤与效果

步骤	优化技术	吞吐量提升
1. 基础优化	torch.compile（编译为高效内核）	~2 倍
2. 量化	权重量化至 INT8	进一步提升
3. 深度量化	权重量化至 INT4	继续提升
4. 算法优化	增加推测解码（Speculative Decoding）	最终提升至～4 倍

2.2 Inference Service Optimization（推理服务优化）

推理服务优化以资源管理为核心，在固定资源（计算能力、内存）和动态工作负载（用户的推理请求，可能涉及不同模型）的约束下，通过高效的资源分配策略，实现延迟和成本的优化。

• 与模型层面优化的区别：服务层面的优化技术不修改模型，因此也不会改变模型的输出质量。

2.2.1 Batching（批处理）

• 批处理通过同时处理多个请求，降低推理服务成本，提升吞吐量。

• 类比：单独处理请求 → 每人开私家车（资源利用率低）。批处理请求 → 乘客共乘巴士（资源利用率高，但可能增加延迟）。

三种批处理技术对比：静态批处理追求资源利用率但可能牺牲延迟；动态批处理通过时间窗口控制延迟但可能浪费资源；连续批处理则通过实时更新批次，兼顾延迟与利用率，尤其适合 LLM 等请求长度差异大的场景。

技术	工作原理	优势	缺点	类比
静态批处理 (Static Batching)	等待固定数量的请求填满批次后执行。 （如：批次大小=4，需等满4个请求）	计算效率高（批次满载）	延迟不可控：首个请求需等待最后一个请求到达	巴士必须坐满才发车
动态批处理 (Dynamic Batching)	设置最大等待时间窗口和批次大小。 （如：批次大小=4，时间窗=100ms； 满4个或超时即执行）	延迟可控：避免早期请求被长期阻塞	计算效率可能较低（批次未满载时执行）	巴士定时发车或坐满即走
连续批处理 (Continuous Batching)	动态替换已完成请求： 1. 批次中请求完成后立即返回结果； 2. 空位立刻加入新请求持续处理。	延迟最低，资源利用率最高； 避免短请求被长请求阻塞	实现复杂度较高	巴士边下客边上客，持续载客运行

• 下图为静态批处理与动态批处理（使延迟可控，但计算效率可能较低）。 

 

• （下图）通过连续批处理，已完成的响应可以立即返回给用户，新的请求可以接替处理。 

2.2.2 Decoupling prefill and decode（分离预填充和解码）

预填充与解码的解耦通过分离计算密集型和内存带宽密集型任务，避免资源竞争，提升推理服务的吞吐量和延迟控制能力，实际部署中需根据输入长度和延迟优先级动态调整设备比例。

1. 解耦的必要性：LLM 推理包含预填充和解码两个步骤，二者的计算瓶颈不同：预填充依赖计算能力；解码是依赖数据传输速度。若在同一设备上执行两者，会导致资源竞争，显著拖慢 TTFT 和 TPOT。

• 示例：当GPU满载运行时，新增请求的预填充阶段（高算力需求）会抢占正在进行的解码任务资源 → 导致 TPOT显著恶化。

2. 解决方案：预填充与解码解耦

• 思路：将预填充和解码阶段分配到不同硬件实例（如独立GPU）执行，避免资源竞争。

• 优化效果（论文实证 DistServe 与 Inference Without Interference）：①请求吞吐量提升：相同延迟约束下处理更多请求。②延迟指标优化：TTFT与TPOT同时改善。

3. 资源配置策略：实例配比（预填充:解码）需动态调整，关键因素如下。

影响因素	倾向更高预填充实例 (e.g., 2:1 ~ 4:1)	倾向更高解码实例 (e.g., 1:1 ~ 1:2)
输入序列长度	长输入（预填充算力需求高）	短输入（预填充负载低）
延迟优化目标	优先降低TTFT （加速首响应）	优先降低TPOT （提升输出吞吐效率）
请求分布特征	突发新请求多（预填充任务密集）	持续生成请求多（解码任务密集）

2.2.3 Prompt caching（提示缓存）

提示缓存通过存储不同提示（prompt）中重叠的文本片段，实现重复利用，避免重复处理，从而降低延迟和成本。目前已被主流模型 API（Google Gemini、Anthropic）采纳，平衡了成本、延迟与存储开销。

• 核心机制：对多次出现的重叠文本（如系统提示、长文档片段、对话历史），仅首次处理并缓存，后续直接复用缓存结果。如下图使用提示缓存，不同提示中的重叠片段可以被缓存并重复使用。

1. 适用场景（常见重叠文本片段）

• 系统提示（system prompt）：多数查询会包含相同的系统提示，缓存后无需每次重复处理。
• 长文档相关查询：若多个用户查询涉及同一长文档（如书籍、代码库），可缓存文档内容供跨查询复用。
• 长对话场景：缓存早期对话消息的处理结果，用于预测后续消息时复用。
• 案例：若系统提示为 1000 token，应用每日产生 100 万次 API 调用，缓存可减少 10 亿次重复 token 处理，大幅降低成本和延迟。

2. 局限性与成本：①内存占用：提示缓存需占用存储空间，规模可能较大（类似 KV 缓存）。②工程门槛：除非使用支持该功能的模型 API，否则自行实现需大量工程投入。

2.2.4 Parallelism（并行性）

并行化是高性能计算的核心策略，通过多设备协同处理任务提升效率。主要分为两类：

• 通用策略：适用于所有模型，包括数据并行（以副本并行为代表）和模型并行（如张量并行、流水线并行）。
• LLM 专用策略：针对长输入序列优化，包括上下文并行和序列并行。

1. 通用并行化策略

（1）副本并行（Replica Parallelism）：创建模型的多个副本，每个副本独立处理部分请求（数据并行的一种简单形式）。

• 实现：通过增加副本数量提升并发处理能力（如 1 个模型副本→10 个副本，可同时处理 10 倍请求）。
• 优缺点：实现简单，直接提升吞吐量（支持更多并发请求）。但消耗更多芯片资源（每个副本需独立占用硬件）。
• 适用场景：需处理大量并发请求，且模型可在单设备上运行（无需拆分）。

（2）模型并行（Model Parallelism）：针对单设备无法容纳的大模型，将模型拆分到多设备运行，主要有两种拆分方式：

1）张量并行（Tensor Parallelism / Intra-operator Parallelism）：将模型中算子（如矩阵乘法）涉及的张量（多维数组）拆分到多设备，使算子被拆解为并行执行的子任务。

• 实现：例如矩阵乘法时，将其中一个矩阵按列拆分，多设备分别计算子矩阵乘法，再合并结果（如图 9-18）。

• 优缺点：支持单设备无法容纳的大模型；减少延迟（并行计算加速）。但增加设备间通信开销，可能抵消部分延迟优势。
• 适用场景：推理中部署大模型（如 70B + 参数模型），需平衡大模型运行与低延迟需求。

2）流水线并行（Pipeline Parallelism）：将模型拆分为多个连续 “阶段”，每个阶段分配到不同设备，数据按顺序流经各阶段，实现计算重叠。

• 实现：例如将模型拆分为 4 个阶段，分配到 4 台设备，输入数据被拆分为 “微批次”，前一设备处理完一个微批次后立即传递给下一设备，各设备同时处理不同微批次（如图 9-19）。

• 优缺点：支持大模型部署；提升训练吞吐量（计算重叠）。但增加请求总延迟（设备间通信开销）。
• 适用场景：训练（更注重吞吐量）；推理中仅用于对延迟不敏感的场景（因延迟增加，推理中较少用）。

2. LLM 专用并行化策略（针对长输入序列）

（1）上下文并行（Context Parallelism）：将输入序列本身拆分到多设备，各自处理部分序列（如前半段输入由设备 1 处理，后半段由设备 2 处理）。

• 目的：优化长输入序列的处理效率，避免单设备处理过长序列的内存压力。

（2）序列并行（Sequence Parallelism）：将处理输入序列所需的算子拆分到多设备（如设备 1 处理注意力计算，设备 2 处理前馈网络计算）。

• 目的：通过算子拆分分担长序列处理的计算压力，提升效率。

3. 关键权衡与实践考量

• 模型部署的 “装箱问题”：将不同大小的模型（如 8B、13B、70B 参数）部署到不同内存能力的芯片（24GB、80GB GPU）时，需平衡副本数量、模型拆分方式，以最大化资源利用率。
• 通信开销与延迟的权衡：所有并行化策略均涉及设备间通信，需在 “支持大模型”“提升吞吐量” 与 “控制延迟” 间取舍（如张量并行减少延迟但有通信开销，流水线并行增加推理延迟）。

总结：并行化是解决大模型部署、提升计算效率的核心技术：①副本并行简单高效，适合并发请求多且模型可单设备运行的场景；②张量并行是推理中拆分大模型的主流方式，兼顾容量与延迟；③流水线并行更适合训练；④上下文 / 序列并行专为 LLM 长输入优化。实际应用中需根据模型大小、延迟需求、硬件资源选择合适策略，或组合使用多种策略。