一文详解「AI 大模型推理」及优化技术（2025）大模型入门到精通，收藏这篇就足够了！

原创于 2025-09-23 14:26:43 发布 · 1.1k 阅读

16 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #chatgpt #llama #langchain #深度学习 #transformer #LLM

部署运行你感兴趣的模型镜像

引言

近年来，大型语言模型（LLM）在自然语言处理（NLP）领域取得了革命性的突破，以其强大的能力改变了各个行业。然而，这些模型的巨大规模和复杂性也给推理（即模型生成预测的实际应用）带来了巨大的挑战。推理成本高、延迟大、计算资源需求高，是阻碍LLM广泛应用的主要障碍。因此，对LLM推理进行优化至关重要。

本文将全面介绍主流的LLM推理优化技术，深入探讨其技术原理，帮助您理解如何为您的AI应用提速、降本、增效。

什么是推理和推理优化？
大模型推理优化技术-KV Cache及其量化
大模型推理服务调度优化技术-Continuous batching
大模型低显存推理优化-Offload技术
大模型推理优化技术-张量并行
大模型推理服务调度优化技术-Chunked Prefill
大模型吞吐优化技术-多LoRA推理服务
大模型推理服务调度优化技术-公平性调度
大模型访存优化技术-FlashAttention
大模型显存优化技术-PagedAttention
大模型解码优化-Speculative Decoding及其变体
大模型推理优化-结构化文本生成
什么是推理和推理优化？

什么是推理（Inference）？

在机器学习领域，我们通常将模型的生命周期分为两个主要阶段：训练（Training）和推理（Inference）。

训练： 在这个阶段，我们使用大量的已知数据（训练集）来训练模型，让模型学习数据中的模式和规律。这个过程通常需要巨大的计算资源和很长的时间。
推理： 当模型训练完成后，我们就得到了一个可以“举一反三”的AI模型。推理就是将这个训练好的模型部署到实际应用中，让它对新的、未知的数据进行预测或生成内容的过程。例如，当我们向ChatGPT提问时，它理解我们的问题并生成回答，这个过程就是推理。

简单来说，推理就是使用训练好的模型进行“思考”和“回答”的过程。

为什么需要推理优化？

理想情况下，我们希望AI模型的推理过程又快又准，并且成本低廉。然而，对于像GPT-3这样拥有数千亿参数的大型语言模型来说，推理过程面临严峻的挑战：

高延迟（High Latency）： 模型规模越大，计算就越复杂，生成一个结果需要的时间就越长。对于需要实时交互的应用（如在线聊天机器人、实时翻译等），过高的延迟会严重影响用户体验。
高成本（High Cost）： LLM的推理需要消耗大量的计算资源，尤其是昂贵的GPU。对于需要处理海量请求的服务来说，推理成本是一个巨大的负担。
高显存占用（High Memory Usage）： 模型本身以及在推理过程中产生的中间数据（如KV Cache）会占用大量的GPU显存。显存的限制不仅影响了模型能处理的序列长度，也限制了可以同时处理的请求数量（吞吐量）。

推理优化就是一系列旨在解决上述问题的技术和方法的总称。其目标是在不显著影响（或完全不影响）模型精度的前提下，提高推理速度、降低延迟、减少资源消耗，从而实现“降本增效”。

大模型推理优化技术-KV Cache及其量化

在众多推理优化技术中，KV Cache是 foundational 的一项，它直接解决了Transformer模型在自回归生成过程中的计算冗余问题。

什么是KV Cache？

在Transformer模型（LLM的基础架构）中，自注意力（Self-Attention）机制是其核心。在自注意力计算中，每个token都会生成一个查询（Query）、一个键（Key）和一个值（Value）向量。为了计算某个token的注意力得分，它的查询向量需要与序列中所有token（包括自身）的键向量进行点积运算。

在自回归推理（autoregressive inference）过程中，模型逐个生成token。每生成一个新的token，它都需要被添加回输入序列，然后整个新序列再次被送入模型以生成下一个token。这意味着在每一步，模型都需要为序列中的所有token重新计算键（K）和值（V）向量，即使是那些已经计算过的token。这导致了大量的冗余计算。

KV Cache 技术就是为了解决这个问题而生的。其核心思想是：对于已经处理过的token，将其计算出的键（K）和值（V）向量缓存起来，在后续生成步骤中直接复用，而无需重新计算。

KV Cache如何工作？

Prefill阶段： 当模型处理用户输入的Prompt时，它会一次性计算出Prompt中所有token的K和V向量，并将它们存储在GPU显存中，这就是KV Cache的“初始状态”。
Decode阶段： 当生成第一个新token时，模型只需要为这个新token计算其自身的K和V向量，然后将它们与缓存中已有的K和V向量拼接起来，用于计算注意力。之后每生成一个新token，都重复这个过程，不断地将新生成的token的K和V向量追加到Cache中。

通过这种方式，模型避免了对历史token的重复计算，从而显著加快了推理速度，尤其是在处理长序列时。

KV Cache的挑战：显存占用

尽管KV Cache能显著提升推理速度，但它也带来了新的挑战：巨大的显存占用。

KV Cache的大小与以下因素成正比：

批处理大小（Batch Size）： 同时处理的请求数。
序列长度（Sequence Length）： 请求的文本长度。
模型规模： 包括模型的层数、头的数量和隐藏层维度。

随着序列长度的增加，KV Cache占用的显存甚至可能超过模型权重本身，成为推理过程中的主要显存瓶颈。

KV Cache量化：为Cache“瘦身”

为了解决KV Cache的显存占用问题，量化（Quantization） 技术应运而生。

量化是一种模型压缩技术，其核心思想是用更低位数的数据类型来存储和计算原本高精度的浮点数。在KV Cache的场景下，我们通常将原本使用FP16（16位浮点数）存储的K和V向量，转换为INT8（8位整数）甚至INT4（4位整数）来存储。

优势：

显著减少显存占用： 将数据类型从FP16降为INT8，KV Cache的显存占用可以直接减半。这使得在相同的显存条件下，可以支持更大的批处理大小或更长的序列。
可能提升计算速度： 在支持低精度计算的硬件（如NVIDIA GPU的Tensor Core）上，整数计算通常比浮点数计算更快。

挑战：

精度损失： 用低位数表示高精度浮点数，必然会引入误差。这种误差可能会在模型的计算过程中累积，最终影响模型的输出质量。因此，如何选择合适的量化算法，在压缩率和模型性能之间取得平衡，是KV Cache量化的关键。

目前，许多推理框架如NVIDIA的TensorRT-LLM已经支持对KV Cache进行INT8或FP8量化，一些前沿工作也在探索更激进的量化策略。

大模型推理服务调度优化技术-Continuous Batching

在了解了单个请求如何通过KV Cache进行优化后，我们来看看在服务多个用户时，如何从“宏观”上提升整个系统的吞吐量。这就是服务调度技术要解决的问题，而Continuous Batching（连续批处理） 是其中的关键。

传统Batching的瓶颈

为了最大化利用GPU的并行计算能力，我们通常会将多个请求打包成一个批次（Batch），然后一次性送入模型进行计算。传统的批处理方式主要有两种：

静态批处理（Static Batching）： 将请求分组，当一个批次处理完成之后，就开始处理下一个批次。这种方式非常简单，但在在线服务场景下会导致请求的等待时间过长。
动态批处理（Dynamic Batching）： 在一个时间窗口内收集到达的请求，组成一个批次进行处理。这比静态批处理灵活，但仍然存在一个致命的瓶颈：批次内的所有请求必须等待最长的那个请求生成完毕后，才能一起结束并释放资源。

这个瓶颈被称为“队头阻塞（Head-of-Line Blocking）”。由于不同请求的输入长度和输出长度差异很大，导致GPU在等待最长序列完成的过程中，大部分计算单元处于空闲状态，造成了严重的资源浪费。

Continuous Batching的革新

Continuous Batching (由Orca系统首次提出) 彻底改变了游戏规则。其核心思想是在Token级别上对请求进行调度。

它不再等待整个批次完成，而是在批次中的任何一个请求（Sequence）生成完一个Token并结束时，调度器会立刻检查是否有新的请求在等待。如果有，它会立即将这个新请求插入到批处理中，填补刚刚释放出的计算资源。

工作原理：

请求入队： 新的推理请求到达后，进入一个等待队列。
迭代式调度： 推理服务器以非常小的时间步（iteration）进行工作。在每个时间步：

服务器处理当前批次中所有请求的一个Token生成步骤。
检查批次中是否有请求已经生成完毕（例如，生成了结束符 [EOS]）。
如果某个请求完成，立即将其从批次中移除。
从等待队列中选择新的请求，将其加入到批次中，开始其Prefill阶段。

通过这种方式，Continuous Batching实现了对GPU资源的“无缝”利用，确保GPU始终处于高负载、高效率的工作状态。

优势

大幅提升吞吐量： 通过消除GPU的空闲等待时间，系统在单位时间内可以处理的请求总数得到显著提升，一些研究表明可以达到数倍甚至20倍以上的吞吐量提升。
降低平均延迟： 虽然单个请求的延迟可能没有变化，但由于请求无需在队列中长时间等待，系统的平均响应延迟和p50/p99等关键指标会得到显著改善。
提高GPU利用率： 这是最直接的好处，更高的利用率意味着更低的单位请求成本。

目前，主流的LLM推理服务框架，如Text Generation Inference (TGI)、vLLM、TensorRT-LLM等，都已将Continuous Batching作为其核心调度策略。

大模型低显存推理优化-Offload技术

当模型规模大到单张GPU无法容纳，或者我们希望在消费级显卡上运行大型模型时，Offload（卸载） 技术就显得非常重要。它是一种“用时间换空间”的策略。

什么是Offload？

Offload的核心思想非常直观：将暂时不需要的数据从昂贵且有限的GPU显存中，转移到相对廉价且容量更大的CPU内存或磁盘上。当需要使用这些数据时，再将其加载回GPU显存。

这就像一个厨师在空间有限的厨房里工作。他会把当前用不到的食材和厨具先放在旁边的储物架上（CPU/磁盘），只在操作台上保留立即要用的东西（GPU显存）。

在LLM推理中，被Offload的主要有两部分数据：

模型权重（Model Weights）： LLM的权重参数是静态的，但在一次前向传播中，并非所有层的权重都需要同时参与计算。
KV Cache： KV Cache是动态增长的，在某些情况下，也可以将其部分Offload。

Offload如何工作？

典型的Offload策略按层（Layer-by-Layer）进行：

加载： 在计算第 i 层之前，系统将第 i 层的模型权重从CPU内存加载到GPU显存。
计算： GPU执行第 i 层的计算。
卸载： 计算完成后，立即释放第 i 层的权重所占用的显存（将其从GPU上卸载），为下一层腾出空间。
重复： 重复以上步骤，直到所有层计算完毕。

通过这种“随用随取、用完即删”的模式，Offload技术使得GPU显存中只需要保留当前正在计算的单层或少数几层的权重，从而极大地降低了峰值显存占用。

优势与挑战

优势：

支持超大模型： 使得在单张甚至没有高端GPU的设备上运行远超其显存容量的大型模型成为可能。
灵活性： 可以根据硬件配置（GPU显存、CPU内存、PCIe带宽）灵活地制定Offload策略。

挑战：

性能开销： 数据在GPU和CPU之间的传输（通过PCIe总线）相比于GPU内部的内存访问，速度要慢得多。频繁的数据传输会引入显著的延迟，导致推理速度变慢。
复杂的调度： 如何智能地预取（Prefetch）下一层权重，以及如何决定哪些数据应该被优先Offload，是一个复杂的调度问题。一个好的调度策略应该能够最大化计算和数据传输的重叠，以掩盖延迟。

一些先进的推理框架（如Hugging Face Accelerate）提供了对模型Offload的内置支持，允许用户通过简单的配置就在资源有限的硬件上运行大型模型。同时，研究人员也在探索更智能的Offload策略，例如将计算图中不那么关键的部分或者使用频率较低的KV Cache部分优先Offload，以在空间和时间之间取得更好的平衡。

大模型推理优化技术-张量并行

当单个GPU的计算能力和显存无法满足超大模型的推理需求时，就需要将计算任务和模型参数分散到多个GPU上协同完成。模型并行（Model Parallelism） 就是解决这个问题的核心技术，而张量并行（Tensor Parallelism） 是其中最常见和最有效的一种。

什么是张量并行？

张量并行是一种将模型中的单个张量（例如权重矩阵）切分到多个不同设备（GPU）上进行并行计算的技术。它与流水线并行（Pipeline Parallelism）不同，后者是将模型的不同层（Layers）放置在不同GPU上。

在Transformer模型中，主要的计算瓶颈在于巨大的矩阵乘法（Matrix-Matrix Multiplication, GEMM）。张量并行的核心思想就是将这些巨大的矩阵乘法分解开来，让每个GPU只负责计算其中的一部分，然后通过高效的通信机制将各个部分的结果聚合起来，得到最终的完整结果。

张量并行如何工作？

以一个典型的Transformer层中的全连接层（Feed-Forward Network, FFN）为例，其计算可以表示为 Y=GeLU(XA)B，其中 X 是输入， A 和 B 是权重矩阵。

在张量并行中，我们可以将权重矩阵 A 按列切分，将权重矩阵 B 按行切分，并将它们分布到多个GPU上。

列并行（Column Parallelism）：

将矩阵 A 沿列方向切分为 [A1,A2]，分别放到 GPU1 和 GPU2 上。
每个GPU用完整的输入 X 与自己分到的部分矩阵 [A1] 或 [A2] 进行矩阵乘法，得到 X*A1 和 X*A2。
这一步各个GPU之间无需通信，可以完全并行执行。
[Y1,Y2]=[GeLU(XA1),GeLU(XA2)]

行并行（Row Parallelism）：

将矩阵 B 沿行方向切分为 [B1;B2]（分号表示按行堆叠），分别放到 GPU1 和 GPU2 上。
每个GPU用上一步得到的中间结果 Y1 或 Y2 与自己分到的部分矩阵 B1 或 B2 进行矩阵乘法，得到 Y1*B1 和 Y2*B2。
在得到最终输出 Y 之前，需要将各个GPU上的计算结果通过 All-Reduce 操作进行相加聚合。 Y=Y1*B1+Y2*B2。 All-Reduce 是一种集合通信操作，它会收集所有GPU上的数据，进行求和（或其他操作），然后将最终结果分发回所有GPU。

通过这种方式，原本在单个GPU上无法完成的大规模矩阵乘法，被巧妙地分解到了多个GPU上，每个GPU只需要处理更小规模的计算，并存储更小部分的权重。自注意力层（Self-Attention）中的QKV矩阵和输出投影矩阵也可以用类似的方式进行并行化。

优势与挑战

优势：

突破单卡显存瓶颈： 使得运行远超单卡显存容量的巨型模型成为可能。
提升计算效率： 充分利用多GPU的并行计算能力，加速推理过程。对于计算密集型的部分，加速效果非常显著。

挑战：

通信开销（Communication Overhead）： 张量并行引入了GPU之间的通信需求（如 All-Reduce）。通信的带宽和延迟会成为新的性能瓶颈，尤其是在GPU数量增多时。因此，需要使用高速互联技术（如NVIDIA的NVLink）来降低通信开销。
实现复杂性： 相比数据并行，张量并行的实现更为复杂，需要对模型内部的计算逻辑进行侵入式修改。
并非完美线性扩展： 由于通信开销的存在，使用N个GPU并不一定能获得N倍的性能提升。

目前，像NVIDIA的Megatron-LM、vLLM和TensorRT-LLM等框架已经对张量并行提供了成熟的支持，极大简化了其在大型模型推理中的应用。

大模型推理服务调度优化技术-Chunked Prefill

在深入探讨了Continuous Batching如何优化调度后，我们再来看一个针对Prefill阶段的精细化优化技术：Chunked Prefill。这项技术旨在解决Prefill阶段计算量过大，从而阻塞后续Decode阶段请求的任务，进一步提升系统的并发和吞吐。

Prefill与Decode的“跷跷板”效应

我们知道LLM推理包含两个阶段：

Prefill阶段：处理输入的Prompt，计算其KV Cache。这个阶段是计算密集型的，可以很好地利用GPU的并行计算能力。
Decode阶段：逐个生成Token。这个阶段是访存密集型的，因为每次只处理一个Token，GPU的大部分计算单元处于空闲状态。

当一个非常长的Prompt进入系统时，其Prefill阶段会占用大量计算资源和时间。在支持Continuous Batching的系统中，虽然可以同时处理Prefill和Decode请求，但一个庞大的Prefill任务仍然会像一个“路霸”，长时间占据计算资源，导致批次中其他正在进行Decode的请求被延后，无法及时生成下一个Token。这就造成了延迟增加和吞吐量下降。

Chunked Prefill：化整为零，见缝插针

Chunked Prefill (在Sarathi等研究中被提出) 的核心思想是将一个长Prompt的Prefill过程**分解成多个小块（Chunks）**来执行。

工作原理：

分块（Chunking）： 当一个长的Prefill请求到达时，系统不一次性处理整个输入序列，而是将其切分成多个固定大小的“块”。
交错执行（Interleaving）： 系统在一个调度周期内，只处理一个“块”的计算。计算完成后，它会像Continuous Batching一样，立即转去服务批次中其他Decode请求。
“搭载”执行（Piggybacking）： 通过这种方式，一个Prefill块的计算可以和多个Decode请求的计算“打包”在一起执行。Prefill块是计算密集型的，可以“喂饱”GPU；而Decode请求是访存密集型的，计算量小，可以“搭载”在Prefill块的计算过程中，几乎不增加额外的延迟。这就形成了一个计算量均衡的微批次（micro-batch），极大提升了GPU的利用率。

简单来说，Chunked Prefill将一个庞大的Prefill任务从“一次性做完”变成了“分期付款”。在每个“分期”之间，系统都可以去处理其他更紧急、更轻量的Decode任务，实现了计算资源的“见缝插针”和高效利用。

优势

降低首Token延迟（TTFT）： 虽然将Prefill分块会稍微增加单个长请求的总处理时间，但由于系统不再被庞大的Prefill任务阻塞，新请求可以更快地被调度和处理，从而降低了平均的Time-to-First-Token。
提高吞吐量： 通过构建计算均衡的批次，并“搭载”Decode请求，Chunked Prefill显著减少了GPU的空闲时间，从而大幅提升了系统吞吐量。
支持更长的上下文： 通过将长Prompt分解，使得系统能够处理超过单次Prefill计算能力上限的超长序列。

Chunked Prefill是Continuous Batching的进一步演进，它将资源调度从请求级别和Token级别，进一步细化到了“计算块”级别，实现了对GPU资源的极致压榨，是现代高性能LLM服务框架中的一项关键技术。

大模型吞吐优化技术-多LoRA推理服务

随着模型微调（Fine-tuning）需求的增长，特别是对于需要为不同客户或任务部署定制化模型的场景，LoRA（Low-Rank Adaptation）技术因其高效性而备受青睐。然而，为每个LoRA适配器都部署一个独立的模型实例会带来巨大的资源浪费。多LoRA推理（Multi-LoRA Inference） 技术应运而生，旨在解决这个问题。

什么是多LoRA推理？

多LoRA推理是一种允许在单个基础模型实例上同时服务多个不同LoRA适配器的技术。

在传统模式下，如果要服务100个不同的微调模型，就需要加载100个完整的模型副本，这在显存和成本上都是难以承受的。而LoRA的巧妙之处在于，它将微调的知识存储在非常小的适配器（Adapter）中（通常只有几MB到几十MB），而基础模型（Base Model）的权重保持不变。

多LoRA推理服务利用了这一点，它只在GPU中加载一份共享的基础模型，然后根据收到的请求，动态地加载对应的LoRA适配器，并将适配器的权重与基础模型的权重在计算时动态结合，从而生成特定于任务的输出。

多LoRA推理如何工作？

共享基础模型： 在服务启动时，将一个通用的、未经微调的基础模型加载到GPU显存中。
动态加载适配器： 当一个带有特定LoRA适配器标识的请求到达时，系统会检查该适配器是否已经加载到内存中。如果没有，则从存储（如硬盘或对象存储）中将其加载到CPU或GPU内存。
请求批处理： 最先进的多LoRA推理系统（如LoRAX、S-LoRA）支持将来自不同LoRA适配器的请求打包到同一个批次（Heterogeneous Batching）中。
动态权重计算： 在进行前向传播计算时，对于批次中的每个请求，系统会获取其对应的LoRA适配器权重（矩阵A和B），并与共享的基础模型权重（矩阵W）进行计算。通常，这步操作在Attention层等关键层中执行，计算方式为 Y=XW+X(AB)s，其中 s 是一个缩放因子。这个计算可以通过专门的CUDA核函数（如Punica-AI提出的SGMV核）进行高度优化，以最小化计算和访存开销。
适配器管理： 系统会采用智能的缓存策略（如LRU）来管理内存中的适配器，将不常用的适配器从GPU内存中换出到CPU内存，为新的请求腾出空间。

优势与挑战

优势：

极大降低了服务成本： 通过共享基础模型，服务成百上千个定制化模型的显存成本几乎与服务单个模型相当，极大提高了硬件利用率和成本效益。
高吞吐量： 结合Continuous Batching和异构批处理，多LoRA推理系统可以保持非常高的吞吐量，不会因为适配器的数量增加而显著下降。
灵活性和可扩展性： 可以非常轻松地动态添加、删除或更新LoRA适配器，而无需重启或重新部署整个服务，极大提高了运维效率。

挑战：

复杂的调度与内存管理： 需要精密的调度器来处理异构批处理，并需要高效的内存管理器来在GPU和CPU之间动态地换入换出适配器。
计算核函数优化： 在同一个Batch中为不同请求应用不同的LoRA权重，需要高度优化的计算核函数来避免性能下降。

大模型推理服务调度优化技术-公平性调度

在多用户、多任务的大模型推理服务场景中，不同请求的计算量差异巨大。例如，一个生成短文本的请求可能只需要几秒钟，而一个分析长文档的请求则可能需要数分钟。如果采用简单的先进先出（First-Come-First-Serve, FCFS）调度策略，长请求会阻塞后续的短请求，导致短请求的等待时间过长，严重影响用户体验和系统的整体吞吐。

为解决这一问题，公平性调度（Fairness Scheduling） 技术应运而生。它旨在确保不同用户或任务能够公平地共享GPU资源，避免资源被少数长请求长时间独占。

什么是公平性调度？

公平性调度是一种资源分配策略，它不再仅仅根据请求到达的顺序，而是综合考虑请求的计算成本、优先级、已等待时间等因素来动态调整执行顺序。其核心目标是在保证服务质量（QoS）的同时，最大化系统资源的利用率。

在LLM推理中，公平性通常以处理的Token数量来衡量，而不是请求数量。这是因为不同请求的Token数量差异悬殊，基于请求数量的公平毫无意义。

主流公平性调度算法

目前，业界提出了多种针对大模型推理的公平性调度算法，其中最具代表性的是 虚拟令牌计数器（Virtual Token Counter, VTC）。

VTC算法原理：

VTC为每个客户端维护一个虚拟令牌计数器。当一个请求被调度执行时，系统会根据该请求消耗的计算资源（即处理的Token数量）增加相应客户端的计数器值。
调度器在选择下一个要执行的请求时，会优先选择计数器值最小的客户端的请求。
这种机制确保了所有客户端在一段时间内获得的计算资源（Token处理量）大致相等，即使某些客户端提交的是计算量较小的短请求，它们也不会被长请求永久阻塞。

公平性调度的优势与挑战

优势：

提升用户体验：

显著降低短请求的平均等待时间，提高系统的响应速度。
保证服务公平性：

防止个别用户通过提交大量长请求来“饿死”其他用户。
提高资源利用率：

在系统负载较低时，允许有需求的用户超出其“公平份额”，从而避免资源浪费。

挑战：

调度开销：

复杂的调度算法本身会带来一定的计算开销。
与其它优化技术的协同：

公平性调度需要与Continuous Batching、Chunked Prefill等技术紧密结合，以实现最佳的整体性能。例如，VTC通常是基于Continuous Batching机制实现的。
定义“公平”的复杂性：

在实际应用中，“公平”的定义可能需要考虑更多因素，如用户付费等级、任务优先级等，这增加了调度系统的设计复杂度。

通过实施公平性调度策略，大模型推理服务能够更好地平衡不同用户的需求，在提供高质量服务的同时，实现GPU资源的高效和公平利用。

大模型访存优化技术-FlashAttention

Transformer模型中的自注意力（Self-Attention）机制是其核心，但也是主要的性能瓶颈之一。标准的自注意力计算具有二次方的计算和内存复杂度（O(N²)），其中N是序列长度。在处理长序列时，计算过程中产生的巨大的中间注意力矩阵（N x N大小）会频繁地在GPU的高带宽内存（HBM）和片上SRAM之间进行读写，成为严重的性能瓶颈。

为了解决这个问题，FlashAttention 应运而生。它是一种IO感知（IO-Aware）的精确注意力算法，能够在不牺牲模型精度的情况下，大幅提升计算速度并降低显存占用。

什么是FlashAttention？

FlashAttention是一种经过优化的注意力算法实现，其核心思想是 减少GPU HBM的访问次数。它通过 Kernel融合 和 Tiling（分块） 技术，重新组织了注意力计算的顺序，使得大部分计算都在GPU核心旁边的、速度极快的SRAM中完成，从而绕过了读写速度较慢的HBM。

FlashAttention的工作原理

标准的注意力计算通常分为三个步骤：

计算查询（Q）和键（K）的点积，得到注意力分数矩阵S = QKᵀ。
对S进行缩放和Softmax操作，得到注意力权重矩阵P = softmax(S)。
将P与值（V）相乘，得到最终的输出O = PV。

在这个过程中，大小为N x N的矩阵S和P必须被写入HBM，然后在下一步中再被读出。当N很大时，这部分IO开销非常巨大。

FlashAttention通过以下方式优化了这一过程：

Tiling（分块）： 将输入Q、K、V沿序列长度维度切分成若干个小块（Block）。
SRAM计算： 每次只从HBM中加载一小块Q、K、V到SRAM中。
Kernel融合： 在SRAM中，用一个融合后的CUDA Kernel完成当前块的 所有计算（包括点积、Softmax和与V的乘积），并将中间结果累加到最终输出中。
迭代计算： 遍历所有的Q和K的块组合，逐步在SRAM中完成计算，并更新最终的输出结果。整个过程中，巨大的N x N注意力矩阵从未被完整地写入或读出HBM。

通过这种方式，FlashAttention将内存访问复杂度从O(N²)降低到了O(N)，极大减少了因HBM读写带来的延迟。

FlashAttention的优势

显著的速度提升： 由于大大减少了内存IO，FlashAttention能够将注意力计算的速度提升数倍，从而加速整个模型的训练和推理。
大幅降低显存占用： 无需在HBM中实例化完整的注意力矩阵，使得显存占用从O(N²)降低到O(N)，从而支持更长的序列长度。
精确计算： 与一些近似注意力算法不同，FlashAttention是精确的，它计算的结果与标准注意力完全相同，不会造成模型性能损失。

FlashAttention及其后续版本（如FlashAttention-2）的出现，是Transformer架构发展中的一个里程碑，它使得在数万甚至更长的上下文长度上训练和推理大模型成为可能，极大地扩展了LLM的应用场景。

大模型显存优化技术-PagedAttention

在大模型推理服务中，对KV Cache的管理是影响性能和吞吐量的关键。传统的KV Cache管理方式存在严重的内存浪费问题：

内存碎片化： 由于不同请求序列长度不一，动态变化的KV Cache会导致物理显存中产生大量不连续的、难以利用的微小内存碎片。
过度预留： 系统通常需要为每个请求预留一块能够容纳其最大可能序列长度的连续内存空间，而实际上大部分情况下远达不到这个长度，导致大量显存被预留但未被使用。

为了解决这些问题，vLLM项目提出了 PagedAttention 技术，它借鉴了操作系统中经典的 虚拟内存（Virtual Memory） 和 分页（Paging） 思想，实现了对KV Cache的高效管理。

什么是PagedAttention？

PagedAttention是一种将KV Cache在逻辑上划分为固定大小的“块”（Block）或“页”（Page）的内存管理技术。这些块在物理显存中可以非连续存储，从而彻底解决了内存碎片化问题。

PagedAttention的工作原理

块化存储： 系统将GPU显存预先划分为一系列固定大小的物理块。每个请求的KV Cache不再需要连续的内存空间，而是由一组逻辑块组成，这些逻辑块可以映射到物理显存中任意可用的物理块。
块表（Block Table）： 系统为每个请求维护一个“块表”，这个表记录了该请求的逻辑块到物理块的映射关系。这类似于操作系统中的页表。
动态分配与释放： 当一个请求需要生成新的Token时，系统只需为其分配一个新的物理块，并更新其块表即可。当请求结束时，其占用的所有物理块都会被回收，可以立即被其他请求使用。
高效的内存共享： PagedAttention使得在不同请求之间共享KV Cache变得异常简单和高效。例如，在并行搜索（Parallel Sampling）或Beam Search中，多个候选序列可以共享相同的Prompt部分的KV Cache。系统只需复制这些序列的块表，而无需复制实际的KV Cache数据，从而将内存开销从O(N)降低到O(1)。

PagedAttention的优势

接近零的内存浪费： 通过块化管理，PagedAttention几乎完全消除了内存碎片和过度预留问题，使得显存利用率接近100%。
更高的吞吐量： 极高的显存利用率意味着系统可以在相同的硬件上支持更大的Batch Size，从而将吞吐量提升2-4倍。
支持复杂的采样算法： PagedAttention极大降低了并行采样、Beam Search等需要生成多个候选序列的算法的内存开销，使得这些算法在生产环境中变得实用。
灵活的内存共享机制： 为跨请求的KV Cache共享（如公共前缀共享）提供了高效的实现基础。

PagedAttention是LLM推理服务领域的一项革命性技术，它通过精细化的内存管理，极大地提升了服务的吞吐量和成本效益，并已成为vLLM、TGI等主流推理框架的核心技术之一。

大模型解码优化-Speculative Decoding及其变体

10.1 技术背景

大型语言模型（LLM）的推理过程是自回归的（Autoregressive），即逐个token生成。每个token的生成都需要对整个庞大的模型进行一次前向传播（Forward Pass），这个过程严重受限于内存带宽，导致生成速度较慢，尤其是在处理长序列时。

Speculative Decoding（投机性解码）是一种创新的解码加速技术，它旨在通过并行验证多个未来token的草稿来减少昂贵的大模型调用次数，从而在不牺牲任何生成质量的前提下，显著提升LLM的推理速度。

10.2 实现原理

Speculative Decoding的核心思想是使用一个更小、更快的“草稿模型”（Draft Model）来“投机地”生成一小段候选token序列（例如，k个token），然后让原始的、更大、更准确的“目标模型”（Target Model）一次性地、并行地验证这些候选token。

其工作流程如下：

草稿生成（Drafting）： 在第 n 步，使用轻量级的草稿模型，自回归地生成 k 个候选token，形成一个草稿序列 T_draft。由于草稿模型小而快，这一步的延迟远低于目标模型。
并行验证（Verification）： 将草稿序列 T_draft 与原始输入拼接后，一次性输入目标模型。目标模型会并行计算出每个位置上所有token的概率分布。
接受或拒绝（Accept/Reject）： 比较草稿模型生成的token与目标模型在该位置上的“真实”预测。具体来说，从第一个草稿token开始，逐个进行验证：

如果草稿token与目标模型的最高概率预测一致，或者其概率在某个可接受的阈值内（通过一种称为“修正采样”的随机过程来保证分布一致性），则接受该token。
一旦遇到第一个不匹配的token，就拒绝该token及其之后的所有草稿token。

修正与补充（Correction & Supplementation）：

在被拒绝的位置，从目标模型修正后的概率分布中采样一个新的token。
如果所有草稿token都被接受了，还会从目标模型在最后一个草稿token之后位置的预测分布中再额外采样一个token。

通过这种方式，目标模型的单次前向传播最多可以一次性解码 k+1 个token，而最少也能解码1个token（在所有草稿都被拒绝的情况下）。只要草稿模型的预测在一定程度上与目标模型一致（尤其是在“简单”或“可预测”的文本部分），就能实现显著的加速效果（通常为2-3倍）。

10.3 Speculative Decoding的变体与优化

为了进一步提升性能和适用性，研究者们提出了多种变体：

Blockwise Parallel Decoding: 思想类似，但更早提出，同样使用并行验证来加速。
Self-Speculative Decoding: 不再需要一个独立的草稿模型，而是让目标模型自身的一部分（例如，较浅的几层）来充当草稿模型。这简化了部署，避免了维护两个独立模型的开销。
Medusa: 引入多个并行的“解码头”（decoding heads）附加在目标模型的骨干网络上。这些解码头经过训练，可以同时预测多个未来的token，从而生成多个候选草稿。这种方法通过一次前向传播就能产生多个并行的、多样化的草稿，进一步提高了接受率和加速比。
Lookahead Decoding: 同样不需要辅助模型，它通过维护一个N-gram词表来高效地生成候选序列。当模型生成一个token时，它会利用这个N-gram词表快速地“向前看”，生成多个候选的后续token序列，然后并行验证。这种方法在保证性能的同时，进一步降低了实现的复杂性。

10.4 优势与挑战

优势：

无损加速： Speculative Decoding及其变体在数学上保证了其输出与原始目标模型完全一致，不会牺牲任何生成质量。
通用性： 该方法与模型架构无关，可应用于各种自回归模型。
高效率： 能够显著降低推理延迟，提升吞吐量，尤其适用于交互式应用。

挑战：

草稿模型选择： 草稿模型的质量直接影响加速效果。一个好的草稿模型需要在速度和准确性之间取得平衡。
开销问题： 独立的草稿模型会带来额外的内存占用和部署复杂性，而Self-Speculative等方法则致力于解决这个问题。
对“难”token的敏感性： 在文本的“转折点”或信息量大的地方，草稿模型的预测准确率会下降，导致接受率降低，此时加速效果会减弱。

总而言之，Speculative Decoding为加速LLM推理提供了一个强大而通用的范式，通过“猜测-验证”机制，将串行的解码过程部分并行化，是当前大模型解码优化领域最重要的技术方向之一。

大模型推理优化-结构化文本生成 (Structured Generation)

11.1 技术背景

大型语言模型（LLM）在生成自然、流畅的文本方面表现出色，但它们的输出本质上是自由形式的。当需要将LLM集成到更广泛的软件生态系统时，这种非结构化的特性带来了挑战。例如，许多应用程序需要LLM生成严格格式化的数据，如JSON对象、XML文档或遵循特定正则表达式的字符串。如果LLM的输出不符合预期的格式，下游系统在解析时就会失败，导致整个工作流程中断。

传统的解决方案通常是在LLM生成完整的文本后，通过后处理（post-processing）步骤来解析和验证输出。这种方法的缺点是：

可靠性差： LLM可能生成格式错误或无效的输出，导致解析失败。
效率低下： 如果生成的内容很长，但只有一小部分不符合格式，整个生成过程就被浪费了，需要重试。
纠错能力弱： 除了简单的修复，后处理很难纠正复杂的结构性错误。

为了解决这些问题，结构化生成（Structured Generation） 技术应运而生。它通过在解码（decoding）阶段施加约束，引导LLM生成符合预定格式的文本，从而确保输出的有效性和可靠性。

11.2 实现原理

结构化生成的核心思想是在LLM生成每个token时，动态地限制其选择范围，只允许选择那些能够满足最终格式要求的token。这通常通过以下几种方式实现：

基于语法的采样（Grammar-Based Sampling）:

定义语法：

用户首先需要提供一个形式化的语法来定义期望的输出结构，例如JSON Schema、正则表达式（Regex）或上下文无关文法（Context-Free Grammar, CFG）。
构建有限状态机（FSM）：

系统根据提供的语法构建一个有限状态机（Finite State Machine, FSM）或下推自动机（Pushdown Automaton）。这个自动机在任何给定的生成点，都能确定下一个合法的token是什么。
约束解码过程：

在解码的每一步，LLM的原始输出概率分布（logits）会根据FSM的当前状态进行修改。只有那些能够引导FSM进入下一个有效状态的token才会被保留，其余token的概率被设置为零（或一个极小值）。这样，模型在采样时就只会选择合法的token。

模板和模式匹配（Templating and Pattern Matching）:

对于一些相对简单的结构，可以使用模板来引导生成。例如，Jinja模板可以动态地构建prompt，并结合少量示例（few-shot examples）来引导模型生成特定格式的输出。
这种方法虽然简单，但保证性不如基于语法的方法强。

11.3 主流框架和工具

一些开源库为结构化生成提供了强大的支持：

Outlines: 一个专注于结构化生成的Python库，它通过将语法（如JSON Schema或Regex）编译成有限状态机来指导文本生成。Outlines可以与多种模型（如Hugging Face Transformers、vLLM、Ollama）无缝集成，并保证输出始终符合指定的格式。
LangChain: 提供了 PydanticOutputParser等工具，它允许用户使用Pydantic模型来定义数据结构。LangChain会动态生成包含格式指令的prompt，并尝试解析模型的输出。虽然它也属于一种后处理方法，但通过精巧的prompt engineering提高了成功率。
LMQL (Language Model Query Language): 一种为语言模型设计的查询语言，它允许用户在prompt中混合使用自然语言和结构化约束。LMQL编译器会将这些查询转换成高效的、带约束的解码策略。

11.4 优势与应用场景

结构化生成带来了显著的优势：

可靠性和健壮性： 保证输出100%符合预定义格式，消除了下游解析失败的风险。
效率提升： 通过在生成早期就排除无效路径，避免了生成长篇无效文本后的重试，有时甚至可以加速生成过程，因为模型的选择空间变小了。
增强的可控性： 允许开发者精确控制LLM的输出，使其能够作为可靠的“函数”或“API”被调用。
与外部工具的无缝集成： 是实现函数调用（Function Calling）和构建基于LLM的Agent的关键技术。当Agent需要调用外部API时，它必须生成格式完全正确的API请求（如JSON格式的参数）。

典型应用场景：