前言

随着大型语言模型（LLM）在各类场景的深度渗透，其推理阶段面临的核心矛盾日益凸显。

• 一方面，千亿级参数规模与海量 KV 缓存带来的内存压力，使静态资源分配模式难以为继；
• 另一方面，自回归生成的特性导致吞吐量与延迟的权衡难题，且不同模型架构（如编码器-only BERT 与解码器-only GPT）、任务类型及硬件环境对推理系统提出差异化需求，传统深度学习推理框架已无法适配。

此外，多请求并发场景下的缓存复用效率、多副本架构中的资源调度偏差等问题，进一步加剧了系统设计的复杂性。

推理系统和关键创新时间线
横轴为 2022-2025 年，纵轴包含 Single Replica、Multi-Replica、Disaggregated、Serverless 等类别，标注了 Orca（2022）、vLLM（2023）、SGLang（2024）、DeepFlow（2025）等系统及 Paged Attention、Continuous Batching 等关键创新

为应对上述挑战，《A Survey of LLM Inference Systems》本文系统性梳理了 LLM 推理系统的核心解决方案，形成“内存管理-系统架构”双线优化框架。

• 在内存管理层面，通过分页内存实现灵活分配，结合***长上下文驱逐（位置/注意力值导向）与卸载（分层/模型级）***技术平衡内存占用与恢复成本；量化技术以均匀/非均匀压缩为基础，搭配张量、向量、维度级粒度方案及离群值保护（混合精度、平滑）减少精度损失；缓存持久化则借助前缀共享与选择性重建提升复用效率。

• 在系统架构层面，【前端】通过声明式（如 LMQL、DSPy）与命令式（如 SGLang、LangChain）接口支持结构化输出与交互优化；【运行时】分为单副本（如 vLLM 的块级缓存、SGLang 的缓存持久化）与多副本系统，后者通过负载均衡、分布式缓存及预填充-解码解耦架构突破扩展性瓶颈。

本文进一步指出，当前技术仍存在量化策略依赖试错、解耦架构调度矛盾、请求级内存协同不足等问题。未来需要聚焦：

1. 构建适配模型与任务的量化理论框架
2. 设计动态负载感知的调度机制
3. 实现请求级内存分配与缓存合并的精准协同

这三大方向，将为下一代【高性能】、【自适应】 LLM 推理系统，提供了关键思路与技术参照。

关键问题

问题 1. 如何建立无试错的量化策略系统化框架，动态适配模型特性与任务需求？

【具体问题】论文指出量化方案的选择需在内存节省与模型精度间权衡，且高度依赖模型架构（如编码器-only BERT 与解码器-only GPT 差异）、模型大小及任务类型，当前多依赖试错法。那么，如何建立一套不依赖大量实验、能根据模型特性与任务需求动态生成最优量化策略（含粒度选择、离群值处理）的系统化理论框架？

关于建立动态生成最优量化策略的系统化理论框架，论文指出当前量化方案选择依赖 trial and error，且与模型架构（如 encoder-only BERT 与 decoder-only GPT 的方差差异）、大小及任务强相关，同时提及量化需兼顾粒度选择（张量/向量/维度级）与离群值保护（混合精度、平滑）等要素。

构建该框架需整合三方面核心支撑：

1. 建立模型特征表征体系，量化提取模型各组件（权重/激活/KV 缓存）的信息密度、方差分布等固有属性，如论文中 GPT 与 BERT 的权重方差差异可作为典型特征输入 ；
2. 构建任务需求映射函数，将精度容忍度、 latency 约束等转化为量化参数约束；
3. 基于上述两者设计量化损失的解析模型，替代实验试错，例如将均匀量化的缩放因子与信息损失的数学关系显性化，并嵌入离群值影响因子。

当前论文已提及量化损失函数（如均方误差）与组件差异化处理思路，为框架提供了基础，但**【关键挑战】在于如何实现特征-需求-策略的动态闭环映射，避免依赖静态规则。**

问题 2. 多副本解耦架构中，如何设计调度机制解决解码资源不可用的核心矛盾？

【具体问题】多副本解耦架构通过分离预填充与解码 worker 实现资源灵活调度，但存在解码 worker 负载预测偏差导致的内存不足、异步缓存传输与模型执行的协同效率瓶颈等问题。针对这一架构，如何设计兼顾负载动态性与资源利用率的智能调度机制，以彻底解决“预填充完成后解码资源不可用”的核心矛盾？

针对多副本解耦架构的调度矛盾，论文显示现有方案存在局限：

• Mooncake 虽提前选择解码 worker 并异步传输缓存，但需在解码前检查负载，不足则终止请求；
• TetriInfer 采用 power-of-two 负载均衡缓解但未解决预测偏差 。

核心**【解决路径】需构建“预测-预留-适配”三位一体的智能调度机制：**

• 首先，基于请求前缀特征（长度、复杂度）与历史负载数据，训练时序预测模型，精准预估解码阶段的内存与计算需求，论文中 DeepFlow 的预暖池思想可延伸至需求预测 ；
• 其次，引入动态资源预留机制，在预填充阶段为解码 worker 锁定最低资源阈值，同时通过资源超分技术提升利用率，参考 Preble 的热点缓存复制策略实现资源弹性调配 ；
• 最后，设计缓存传输与模型执行的深度协同协议，如将传输进度与预填充层执行进度绑定，确保解码启动时缓存已传输关键分片，复用论文中分层卸载的异步传输隐藏延迟思路 。

该机制需突破的核心是预测误差的容错机制，而非单纯提升预测精度。

问题 3. 多请求并发下，如何协同请求级内存分配与缓存合并且控制开销？

【具体问题】论文提及层间动态内存分配、条目合并等新型内存管理技术，可在控内存的同时保精度，但未深入探讨其在多请求并发场景下的适配性。那么，如何量化不同请求的上下文重要性权重，以实现请求级动态内存分配与缓存合并的精准协同，且不引入过高的计算与调度开销？

关于请求级动态内存分配与缓存合并的协同，论文提及层间动态内存分配（优先分配给早期层）与条目合并（选择相似 tokens 减少条目），但未涉及多请求场景 。实现路径倒是可以考虑分三步量化与协同：

• 首先，建立请求级上下文重要性量化模型，结合两维度指标——单请求内 tokens 的注意力累积分数与请求的服务优先级（如 latency 约束、用户等级），生成每个请求的内存分配权重；
• 其次，设计“全局调度-局部优化”的二级机制：全局层基于权重分配总内存配额，局部层在请求内执行层间分配与缓存合并，利用 SGLang 的 radix 树索引加速相似 tokens 匹配 ；
• 最后，通过轻量化计算降低开销，例如采用近似注意力分数计算替代精确值，复用论文中离群值平滑的 scalar 缩放思想简化权重计算 。

【核心挑战】在于量化指标的实时更新效率，需确保计算开销【不抵消】内存节省带来的收益。

一、内存管理

若未考虑 KV 缓存内存，可能导致内存容器的过度订阅（over-subscription），进而引发高昂的内存交换（memory swapping）开销。

作为预防措施，可在请求处理开始时为每个请求预分配最大内存，从而避免内存容器的过度订阅[102]。然而，除了长度受限生成（详见 5.1 节）的场景外，KV 缓存的最终精确大小无法提前确定，这可能因过度分配导致内存浪费。即便能提前知晓 KV 缓存大小，提前预分配内存也会导致该部分内存无法被其他请求临时使用。

• 相比静态预分配，动态的基于页的内存管理（paged-based memory management）会根据需求以小块形式分配内存，从而避免因大量预留内存导致的实际利用率低下问题（详见 4.1 节）。
• 同时，为减轻内存负担，可采用驱逐与卸载技术（详见 4.2 节）将无用的 KV 条目从内存容器中移除，通过量化技术（详见 4.3 节）减小物理字节大小。

在某些场景下，例如存在共享系统提示或特定检索增强生成（RAG）工作流时*，可采用缓存持久化技术（详见 4.4 节）实现多个请求间 KV 条目的复用*，避免高昂的重新计算开销与存储冗余。卸载、恢复、量化与持久化技术的多种组合，为创新内存方案的设计提供了可能，相关内容将在 4.5 节中讨论。

4.1 基于页的内存分配

由于 KV 缓存在每轮解码过程中会逐渐增长，与静态预分配相比，根据需求以小块形式动态分配内存可避免大量的前期内存开销。然而，动态的块级分配可能导致 KV 缓存非连续，这就需要一个内存管理器来将逻辑缓存条目（即缓存页）映射到物理块，同时还需要专门为非连续内存范围设计的基于页的内核[51,81]。此外，基于页的内存除了支持动态分配外，还为块共享（block sharing）提供了可能，从而避免重新计算与存储冗余。块共享是后续 4.4 节将讨论的缓存持久化技术的基础。

内存管理器

内存管理器负责页的创建、删除与查找。为跟踪页块的地址与内容（即映射到页中存储的 KV 条目的令牌及其在序列中的位置），可使用页表（page table）记录每个页的地址与内容，见图 13。在 vLLM[51]中，GPU 内存作为内存容器，内存管理器与页表则在主机（host）机器上实现。

对于采用 CPU-based 内存管理器的 GPU 系统，由于物理块存储在 GPU 上，页的创建与删除会触发从 CPU 向 GPU 提交内存分配与释放命令。同样，由 GPU 内运行的特殊“页感知注意力内核”（page-aware attention kernel）执行的页查找操作，会触发从内核向内存管理器提交查找命令。在 vAttention[81]中，通过利用 GPU 的原生内存管理能力，降低了上述通信带来的开销。这一设计还带来了一个附加优势：对内核而言，缓存看起来如同存储在连续内存中，从而支持使用 2.2 节中讨论的非页式内核。

这段话可总结为如下表格

| 核心维度                | 具体内容                                                                 |
|-------------------------|--------------------------------------------------------------------------|
| 场景                    | CPU管GPU的“零件盒”（即采用CPU-based内存管理器的GPU系统，物理块实际存储在GPU上） |
| 问题（慢的原因）        | 每次与“页”相关的操作都需CPU与GPU通信，产生额外开销：<br>1. 页的创建/删除：触发CPU向GPU提交内存分配/释放命令<br>2. 页的查找：GPU内“页感知注意力内核”需向CPU内存管理器提交查找命令 |
| 解决方案（vAttention）  | 利用GPU自身的原生内存管理能力，让GPU自主处理“页”的管理（无需依赖CPU调度），减少CPU与GPU之间的通信开销 |
| 附加好处                | 1. 对GPU内核而言，缓存看起来如同存储在连续内存中，避免非连续内存的混乱<br>2. 支持使用2.2节讨论的“非页式内核”，简化内核对缓存的操作逻辑 |

块共享

要实现块共享，只需将对应不同请求的多个页条目分配到相同的块地址即可。是否以这种方式关联页，取决于共享注意力机制（详见 4.4 节）。

1. 精确匹配共享（exact-match sharing）[51,136,94]机制下，仅能共享一个或多个请求间“最长公共前缀”（longest common prefix）对应的缓存条目。块大小会影响共享机会的多少，因为页表仅支持整块共享：小块大小更易找到所有条目均满足共享条件的块，但同时也会增加推理过程中的块检索次数。
2. 部分匹配共享（partial-match sharing）机制下，对前缀匹配的条件进行了放宽，允许“部分前缀匹配”（即共享部分或全部相同令牌，但令牌顺序可能不一致）。

4.2 驱逐与卸载

缓存驱逐（eviction）与卸载（offloading）不仅是支持抢占（preemption）的必要技术**，也有助于处理超出内存容器容量的长上下文。

在抢占场景中，可通过驱逐或卸载低优先级请求的缓存条目，为高优先级请求腾出内存空间。由于被抢占的请求最终仍需恢复，选择驱逐还是卸载主要【取决于】恢复成本[51]。在长上下文场景中，可驱逐对最终输出序列影响较小的“非重要条目”，以继续解码过程（即稀疏注意力）。选择驱逐哪些条目可基于多种因素，包括令牌位置[114]与注意力分数[74,67,135]。此外，也可对大型缓存进行部分卸载，利用分层存储（tiered storage）补充内存容器。但与被抢占请求类似，卸载的条目最终仍需重新加载到内存容器中，因此需要相关技术在内存使用与恢复成本之间取得平衡[5,52,93]。对于持久化缓存，可通过驱逐技术控制缓存大小，此时可采用传统缓存控制技术（如 LRU 即最近最少使用）[136]。

被驱逐的条目可通过基于 LLM 部分输出生成键（key）和值（value）向量来恢复，而卸载的条目则可通过将其传输回内存容器来恢复。

• 对于被抢占且提示词较短、解码轮次较少的请求，重新计算可能比从卸载存储中加载更快，这一权衡关系在[51]中已有研究。
• 对于卸载的缓存，可通过提前异步执行传输操作——将传输过程与其他模型执行阶段重叠——来隐藏传输延迟，从而降低有效传输成本[52]。
• 对于解耦运行时（详见 5.2 节），解码工作节点必须先从预填充工作节点恢复缓存条目，才能启动解码过程。若在选择预填充工作节点的同时确定了解码工作节点，则可通过异步方式恢复缓存，例如在预填充过程中将条目流式传输到解码工作节点[78]。

长上下文驱逐

驱逐特定缓存条目可为更重要的条目腾出内存空间，同时最大限度降低对输出质量的影响。

1. 基于位置的策略根据缓存条目对应令牌在输出序列中的位置对其排序。在[114]的研究中，输出序列开头或末尾附近的令牌被发现具有比其他位置令牌更大的注意力值，这促使研究人员通过手工设计的注意力掩码，图 14(b)制定针对这些特殊位置的驱逐策略。
2. 基于注意力的策略则根据缓存条目的注意力值对其排序[74]，图 14©。为提升排序准确性，相关技术包括添加非对称噪声[1]、跨解码轮次对分数取平均[84]，或采用累积分数[67,135]等。

长上下文卸载

另一种方案是采用长上下文卸载：将大型 KV 缓存分布到分层存储中，同时保持缓存的完整性。

执行工作节点（如 GPU）中，Transformer 块的权重与部分 KV 缓存存储在工作节点内存（如 80GB GPU DRAM）中；第 i 层执行期间，异步读取第 i+1 层的 KV 缓存，执行完成后写入当前层 KV 缓存。

1. 逐层卸载将部分或全部 Transformer 层的缓存迁移到二级缓存存储中[5,52]。由于模型执行按层依次进行，可在执行第 i 层时异步传输第 i+1 层的缓存，从而有效隐藏传输延迟。
2. 逐模型卸载仅从所有层中部分卸载缓存，通过设置卸载比例来控制传输成本[93]如图 15，尤其针对超大型缓存，传输成本在逐层卸载后还可能很高的问题，进行缓解。

4.3 量化

量化通过降低数值精度来减少数据的物理字节大小（模型可直接使用量化权重进行训练或微调，例如 Q8BERT。相关技术细节建议感兴趣的读者参考[71]）。为避免推理质量下降，量化器的【设计目标】是在压缩后的数值范围内，最大限度保留原始数据中信息密集区域的特征。

• 均匀量化器通过数值舍入将浮点数映射到压缩范围（如整数），其参数包括偏移量以及范围高低端的钳位值[71]；
• 而非均匀量化器则通过非线性方法进一步减少信息损失[26,127]。由于模型各组件的信息含量存在差异，可为每个组件单独应用量化器，从而形成基于张量级[71,127]、向量级[22,123]和维度级[12]的量化方案（图 16）。

此外，还可采用异常值保护技术（如混合精度保留[22,127]（图 17）和异常值平滑[58,112,131]（图 18）），防止因量化重要异常值导致的模型质量下降。

量化器设计

无论是均匀量化器还是非均匀量化器，其设计通常以最小化量化前后的损失函数（如均方误差）为目标。

• 对于形式为 的均匀量化器，由于参数数量少，可通过网格搜索找到最优参数值[71]。
• 对于非均匀量化器，可采用分桶[127]或更复杂的搜索算法[26]等技术直接确定映射关系。

其他量化器设计技术详见[31]。

量化方案

1. 张量级量化：模型权重通常需要大量存储，对权重矩阵应用张量级量化可直接实现显著的存储节省[26,71,127]。
2. 向量级量化：对于激活矩阵，向量级量化通过将矩阵划分为多个组（每组包含 个嵌入向量），并为每个组应用不同量化器，实现对量化矩阵质量的精细控制[22,123]。g 值可根据所需粒度调整：g 值越高，对量化范围的控制越精细，但需训练更多量化器，且会增加后续矩阵乘法操作的复杂度。
3. 维度级量化：为实现更精细的控制，维度级量化将每个向量划分为 k 个片段，将 d 维向量空间分解为 维子空间，并对每个子空间应用单独的量化器[12]。

异常值保护

研究表明，异常值对模型质量的影响远超普通数据[22,112,127]。针对这一问题，有两种主要解决方案：

1. 混合精度保留：将异常值保留为原始高精度形式，但会导致张量处于混合精度状态。需使用专门的数据结构存储这类张量（例如为低精度和高精度值分配单独的字节区域[23,127]，图 17），但对这些结构的操作需要能识别不同精度区域的专用解码器或内核算子。
2. 异常值平滑：在矩阵乘法过程中避免混合精度张量，同时保留异常值信息。对于两个矩阵操作数，该技术通过标量除法降低高方差矩阵中异常值的有效强度，同时在低方差矩阵中执行反向缩放，从而在矩阵乘积中完整保留高方差信息，图 18（下图）。在[112]中，该技术被应用于激活矩阵和权重矩阵；而在[58,131]中，其被应用于构成 KV 缓存的键矩阵和值矩阵。

4.4 缓存持久化

内部注意力层中的 KV 向量，会根据其对应令牌在生成序列中的位置，呈现不同值。因此，两个请求的 KV 条目仅在序列中“令牌首次不同的位置”之前保持一致，这就形成了直接缓存共享的“精确匹配”条件。但在某些场景下，KV 条目仍可实现一定程度的共享——例如在检索增强生成（RAG）工作流中，即使两个请求的提示词不同，也可能使用相同的文档片段。

1. KV 向量是 “词的身份 + 关系” 数据，位置变了，KV 就变；
2. 只有 “前面的词完全一样”，KV 才能直接共享（精确匹配）；
3. 特殊场景（比如 RAG 用同一份文档），哪怕问题不一样，文档部分的 KV 也能共享。

前缀共享与选择性重建

1. 前缀共享技术：在精确匹配前缀的前提下复用持久化缓存条目。为找到“最长匹配前缀”，需从请求前缀的开头到结尾逐令牌扫描，在每个令牌的序列位置处执行缓存查找，判断是否已存在对应缓存条目[66]。若存在大量持久化缓存块，可使用基数树（radix tree）等索引结构加速检索[136]。
2. 选择性重建技术：针对部分匹配共享场景，通过重新计算“对输出影响最大的部分令牌”的 KV 条目，缓解因使用非对齐条目导致的质量下降，见下图图 19。这些关键令牌的识别方式包括：以第一个 Transformer 层的注意力分数偏差作为排序依据[121]，或使用令牌位置作为启发式规则[32,40]。

块 Y 的 KV 条目受块 X 影响（顶部红色框），给缓存复用带来挑战；通过重新计算部分关键条目（底部），可缓解质量下降问题。

4.5 讨论

本节讨论的技术均源于缓解内存压力的核心需求：一方面，最常见的 LLM 模型参数数量高达数十亿；另一方面，推理过程中生成的 KV 缓存体积庞大，两者共同导致了严峻的内存挑战。

• 分页内存相比静态预分配实现了更灵活的内存分配；
• 而驱逐与卸载、量化、缓存持久化等技术则直接致力于减少内存使用。

此外，这些技术的多样性使得 LLM 系统和应用可根据内存容量、期望精度、上下文长度等差异进行针对性优化：

• 对于被抢占的请求：由于分层存储资源充足，卸载技术可通过避免缓存重新计算降低恢复成本，尤其是当恢复过程可异步执行时。
• 对于长上下文支持：驱逐与卸载可作为分布式注意力机制，如需要横向扩展 GPU 的环形注意力（Ring Attention）[63]的替代方案，且无需依赖大规模硬件集群。
• 对于量化技术：任何推理系统均可应用，但确定“内存节省与模型质量平衡”的最优量化方案需反复试验。例如在[123]中，权重与激活矩阵均采用向量级量化，但因权重值方差小于激活值，故对权重设置 ，对激活设置 ；而在[22]中，为实现更激进的空间节省，对两者均设置 ，但为激活矩阵添加异常值保护以防止精度损失。
• 模型特性的影响：研究表明，仅编码器的 BERT 模型因权重方差更低，对激进权重量化的敏感度低于仅解码器的 GPT 模型。因此 GPT 模型更能从向量级或维度级等复杂量化方案中获益[123]。模型大小也是量化方案选择的关键因素[22]。
• 缓存持久化的权衡：若精度并非首要目标，选择性重建可实现激进的内存节省；若需保证精度，则前缀匹配技术是更佳选择（无精度损失）。

缓存内存的受限与非受限模式

推理系统设计的核心决策之一是 KV 缓存内存应采用“受限模式”还是“非受限模式”：

• 【受限模式】：通过限制缓存大小，使内存使用更可预测（已知最大内存用量），简化批处理与调度决策，但可能降低长时间运行请求的模型精度。
• 【折中方案】：在[13,120]的研究中，允许内存限制在不同 Transformer 层之间动态变化——为早期层分配更多内存，为后期层分配更少内存，最终在大幅减少内存使用的同时，对输出质量影响极小。

未来类似技术可探索“请求级动态内存分配”或其他创新分配方案。

条目合并技术

另一种与“驱逐”类似的内存优化思路是“条目合并”：不直接丢弃被驱逐条目，而是将其合并到剩余的非驱逐令牌中。该***【技术的目标】并非选择“影响最小的令牌”，而是选择“相似令牌”，使合并后的 KV 条目整体特征与合并前差异不大***，仅条目数量减少[60,98,103,133]。

unsetunset五、推理系统unsetunset

在大型语言模型（LLM）推理系统中，各类请求处理、执行和内存管理技术被整合在一起，以支持对通用 LLM 工作负载的高效、高质量处理，或针对更特定的应用场景。

一个完整的推理系统由前端（frontend）和运行时（runtime）组成。

• 前端支持用户交互（例如，通过声明式或命令式接口），并可能提供结构化输出、自动提示优化等功能（见 5.1 节）。
• 运行时负责模型执行的所有其他方面：

• 单副本（single-replica）运行时面向单个 LLM 的请求处理，多副本（multi-replica）运行时则面向包含多个相同 LLM 副本的环境（见 5.2 节）。
• 单副本和多副本系统均支持分布式执行，而多副本系统还可设计为支持解耦式（disaggregated）执行。

我们将在 5.3 节总结一些主流系统的关键特性。

5.1 前端

前端使用户能够通过编程方式访问底层 LLM，同时对 LLM 的输入和输出进行精确控制。

• 前端可提供模块或命令，将用户指令转换为思维链（CoT）、少样本（few-shot）或检索增强生成（RAG）提示；
• 根据先前提示的输出提交不同提示；
• 约束输出以遵循特定模板或格式等。

在上述这些功能中，结构化输出和模板补全尤其支持交错式提示（interleaved prompting），该方式可利用快速预填充（prefill）加速推理。目前已有大量关于提示策略的研究工作（见http://smith.langchain.com/hub），感兴趣的读者可参考文献[86]。

前端接口本身可分为命令式和声明式两类，见上面表 2。

• 命令式接口提供底层 API，可用于构建 LLM 程序；
• 声明式接口则通过查询字符串或高层模块，支持更易用的查询式交互。

基本交互

控制流（如if...else和for语句）的实现方式是：捕获 LLM 输出，然后根据输出提交不同提示。

示例 1（捕获与控制流）

下面生成的输出被捕获到s["tool"]中，并参与控制执行流（http://docs.sglang.ai/frontend/frontend）：

s += assistant("To answer " + q + ", I need " + gen("tool", choices=["calc", "www"]))
if s["tool"] == "calc":
    // .. 执行某些操作
elif s["tool"] == "www":
    // .. 执行某些操作

“约束生成”（constrained generation）可在满足用户指定条件时停止 LLM 生成，该功能对于终止 LLM 的冗长响应十分有用，其实现同样可借助输出捕获。例如，LMQL [9]通过声明式语法提供该功能，如提示脚本"Give your answer here: [y]" where len(TOKENS(y)) < 25，当 Python 解释器捕获的生成输出长度超过 25 个 token 时，生成过程终止。

结构化输出

与之相关的一项功能是“结构化输出”（structured outputs）：LLM 输出需遵循用户指定的类型和格式（例如两位数）。

为实现结构化输出功能，前端会先将用户设定的约束条件转换为提示语句（例如“Give answer as a two-digit number”）；在获取 LLM 生成的响应后，再通过 logit 掩码[107]、token 重采样或重新提示（reprompting）等技术手段，强制确保输出结果满足预设约束。

在此基础上，结构化输出可进一步扩展为“模板补全”（template completion）功能：即通过提示让 LLM 填充特定格式的模板（如 JSON 结构模板）。由于模板中的每个字段项本质上都是一个独立的结构化输出需求，因此填充模板时，一种高效方式是针对每个字段项分别向 LLM 发起提示；与之相对的是，也可通过单次提示要求 LLM 填充整个模板，但这种方式可能需要多次重新提示——尤其当要求模板格式在生成响应中完整保留时——直到 LLM 输出完全符合模板规范的结果。

值得注意的是，“逐项提示”（item-by-item prompting）模式还支持“提示与解码的交错执行”：借助快速预填充技术（尤其在支持缓存持久化的运行时环境中），能够有效减少重复计算开销，从而实现推理过程的加速。

示例 2（约束模板生成）

Write a summary of Bruno Mars, the singer:
{{ "name": "[STRING_VALUE]", "age": [INT_VALUE], "top_songs": [[ "[STRING_VALUE]", "[STRING_VALUE]" ]] }}

上述是一个 LMQL 程序（示例来自：http://lmql.ai/playground），大括号中的内容指定了类型约束。LMQL 会解析该程序，生成对应的提示并协调执行与输出捕获。为说明预填充与解码的交错技术，以下是 LMQL 提交的第一个提示：

Write a summary of Bruno Mars, the singer:
{ "name": "

当 LLM 输出“Bruno Mars”后，LMQL 会提交第二个提示：

Write a summary of Bruno Mars, the singer:
{ "name": "Bruno Mars", "age": "

其中，先前的输出（“Bruno Mars”）被直接包含在提示中。由于该提示与第一个提示有大量重叠，运行时可利用共享缓存条目加速预填充。此过程会重复进行，直到模板填充完成。

声明式前端

在声明式接口中，用户通过调用声明式语句或模块来使用上述功能。例如：

1. LMQL [10]采用声明式语法，如提示语句后紧跟from子句（指定模型）和where子句（约束输出）。这些声明式查询可嵌套在控制流结构中，示例见文献[9]。LMQL 前端会将查询转换为提示链，并对生成输出强制执行约束。由于提示结构是预先声明的，可将其视为模板，通过提示与解码的交错执行实现高效模板生成。
2. DSPy [46]提供面向对象的声明式接口。与 LMQL 不同，用户无需编写提示查询，而是编写模块声明——不同模块封装不同的提示策略。在调用模块前，需将提示内容及其他参数传入模块。该框架支持 DSPy 执行提示优化（例如合成少样本示例以提高模型精度）。

命令式前端

用户也可通过命令式接口使用上述功能。例如：

1. **SGLang [136]提供用于与底层 LLM 交互的底层 API。**为提高推理速度，其支持“推测执行”（speculative execution）技术：允许 LLM 在用户指定的终止条件之外继续解码，以期生成更多有用 token，从而避免多次 API 调用。与 SGLang 协同设计的运行时还支持前端通过“提示-解码交错”利用缓存持久化，实现模板生成。
2. Guidance（http://github.com/guidance-ai/guidance）提供与 LMQL 类似的功能，但采用命令式语法而非声明式语法。与 LMQL 相同，输出约束以参数形式传入生成函数。
3. LangChain 与 Guidance 类似，但更偏向面向对象设计。提示和 LLM 输出被封装在类中，可通过编程方式操作。LangChain 还提供名为 LangGraph 的基于智能体（agent）的框架，可用于编写复杂交互（如嵌套if/else分支）。

5.2 运行时

推理运行时可分为面向单副本环境和多副本环境两类。

单副本和多副本系统均可通过将模型层分布在多个推理设备或机器上，支持分布式执行（即模型并行或流水线并行）。但与分布式数据库系统不同，LLM 推理的分布式执行计划无法优化（因为层必须按顺序执行），数据分区也无法优化（因为除层执行后的中间结果外，任何层都不需要其他层的数据）。更多详见：http://huggingface.co/docs/accelerate。

对于多副本运行时，由于承载每个副本的工作节点（无论是否分布式）可能处于不同负载状态（即处理处于不同完成阶段的请求，因 KV 缓存增长产生不同内存负担，且请求队列长度各异），多副本运行时需依赖负载均衡技术将请求选择性地分配给副本，以维持高性能。

同时，运行时支持多请求并行处理，结合分块持久化缓存（blocked persistent caches），还可采用块复制与分区技术，最大限度利用缓存复用。

最后，为精细管理资源密集型副本的数量，运行时可采用单体式（monolithic）、解耦式（disaggregated）和无服务器式（serverless）架构，以实现更精细的扩展与控制。

5.2.1 单副本运行时

单副本运行时需应对 LLM 执行的基础性系统挑战，包括批处理（batching）、调度（scheduling）和内存管理（memory management）。这类运行时开发的技术也为多副本运行时提供了基础。

Orca [126]是最早专门针对 LLM 独特自回归特性设计的推理运行时之一，率先提出了“基于轮次的连续批处理”（round-based continuous batching）技术，该技术目前已被广泛采用。在缓存内存管理方面，Orca 采用静态内存分配：根据应用指定的最大上下文长度，为每个请求预分配固定内存。其调度器不支持抢占（preemption），因此没有针对被抢占请求的驱逐（eviction）或卸载（offloading）机制。由于每个内存块均为单个请求私有，也不存在缓存共享的可能。

为解决这些局限性，后续研究者开发了多款运行时：

• 针对静态分配的局限性，vLLM [51]引入了“基于块的缓存内存”（block-based cache memory）。内存块由内存管理器负责处理，支持多个活跃请求共享部分块。但 vLLM 未显式管理跨多个请求生命周期的缓存持久化。为应对低内存场景，vLLM 支持基于请求优先级的抢占：在内存不足时，调度器会驱逐最低优先级请求的所有缓存块，以释放内存。
• SarathiServe [2]将“连续批处理”扩展到预填充阶段，在 vLLM 的基础上引入“分块预填充”（chunked prefills）。该技术允许在批处理中打包预填充 token，基于 token 预算实现动态批大小调整。**
• SGLang [136]引入“托管缓存持久化”（managed cache persistence），通过协同设计前端与运行时以充分利用该技术。其运行时将所有缓存块持久化在内存中，并使用基数树（radix tree）加速预填充阶段的块检索。为控制持久化缓存的大小，SGLang 对持久化条目采用 LRU（最近最少使用）驱逐策略。为避免缓存抖动（cache thrashing），请求优先级根据共享前缀的长度确定。
• 针对 FCFS（先来先服务）调度的局限性，FastServe [108]引入“多级队列（MLQ）作业优先级”技术，基于请求到达时间降低平均请求延迟。

5.2.2 多副本运行时

多副本运行时通过负载均衡器将工作负载均匀分配到多个工作节点。对于支持缓存持久化的多副本运行时，持久化条目可分布在不同工作节点上，因此需要分布式缓存管理技术。

单体式（非解耦）架构（a）与预填充-解码（P/D）解耦式架构（b、c）

针对不同的应用扩展需求，目前已出现单体式、解耦式和无服务器式三类运行时，见图 20。

单体式运行时

以 Preble [94]为例，其展示了如何将缓存持久化扩展到多副本场景。中央调度器维护一个全局基数树，负载均衡决策同时基于缓存命中率和工作节点负载。由于持久化缓存分布在多个工作节点上，部分节点会拥有更高的命中率。为避免负载均衡器过度负载这些节点，会将热点条目复制到其他节点。

解耦式运行时

与单体式架构相比，为预填充（prefill）和解码（decode）阶段分配专用工作节点，可实现对这两个阶段的独立控制与扩展。

单体式（非解耦）架构（a）与预填充-解码（P/D）解耦式架构（b、c）

在解码工作节点开始处理请求前，需先将预填充阶段生成的 KV 缓存条目传输到解码节点。根据传输方式的不同，可分为两类：

1. 【同步传输】：

• DistServe [138]通过根据推理集群中推理设备（GPU）的物理位置及工作负载需求，将设备分配给预填充任务或解码任务，以降低传输成本。例如，将同一机器内的 GPU 分配给独立的预填充和解码任务，可利用高带宽 NVLink 减少传输开销。但由于解码节点是在预填充阶段完成后才选择，见图 20(b)，若工作负载突发，贪心式解码侧负载均衡器可能会意外导致某个解码节点过载。
• TetriInfer [39]通过采用“二选一随机负载均衡”（power-of-two load balancing）[70]解决了该问题。

2. 【异步传输】：

• SplitWise [78]和 Mooncake [82]在选择预填充节点的同时选择解码节点，允许在生成缓存的过程中，将缓存异步流式传输到解码节点，见图 20©。但由于预填充阶段进行时解码节点的负载可能发生变化，当预填充完成时，选定的解码节点可能不再有足够可用内存处理请求。为避免抢占，Mooncake 会在解码开始前检查解码节点的负载；若内存不足，则终止该请求。

在热点条目复制方面，Mooncake 采用中央哈希表记录每个持久化缓存块的位置和内容。在预填充阶段，若检测到缓存命中，则将可复用的块复制到预填充节点，从而实现热点块在多个工作节点间的复制。

无服务器式运行时

无服务器式运行时利用无状态硬件资源实现灵活的资源扩展。但由于机器是无状态的，这类运行时需解决“冷启动”（cold starts）问题——即在获取机器时，需先加载模型权重才能使用。

例如，DeepFlow [41]面向共享基础设施上的 LLM 推理：为避免冷启动，其会将获取的机器跨多个请求持久化（而非在每个请求后将机器归还资源池），同时维护一个“预预热”（prewarmed）机器池以实现快速获取。DeepFlow 通过将缓存条目卸载到主机内存（由中央基数树管理），充分利用缓存共享机会。

5.3 讨论

尽管 Clipper [19]、TensorFlow Serving [73]、TensorRT、Clockwork [36]和 Hugging Face Accelerate（http://huggingface.co/docs/accelerate） 等**【非专用】深度学习推理系统可用于 LLM 推理，但它们的性能通常不及【专用】 LLM 推理系统。**

本节介绍的多款系统均通过创新技术提高吞吐量、降低延迟、减少内存使用，同时维持高推理质量。这些技术大多可无冲突地组合使用，事实上，近年来的系统已呈现出融合趋势。例如，“分页注意力”（paged attention）和“带分块预填充的连续批处理”等技术已被广泛采用；而“MLQ 调度”“基于分层存储的异步缓存恢复”等较新技术，由于相比前代方案具有明显优势，未来也可能得到更广泛应用。

在系统架构方面，多副本系统需包含额外组件，如负载均衡器和分布式缓存管理机制（即热点缓存复制、缓存传输机制）。对于单副本环境，在多副本系统中禁用这些组件可减少额外开销，否则单副本系统可能更适用。对于多副本环境，解耦式系统在资源管理灵活性上优于单体式系统，且无显著缺点（尤其在使用混合工作节点池时）。若在共享基础设施上部署，DeepFlow [41]等无服务器式系统可解决冷启动、无状态工作节点等问题。

量化方案可能是未来系统差异化的一个方向。如 4.3 节所述，量化在精度与压缩率之间存在固有权衡，且该权衡取决于模型架构及请求所涉及的任务类型。因此，最优量化方案需根据推理系统所面向的应用和模型确定。 另一方面，推理系统也迫切需要提高“自适应性”：由于请求生命周期的不可预测性，工作负载本质上具有复杂性。尽管可通过约束输出生成（如仅允许约束生成）或工作负载解耦（将需低延迟的交互式请求与需高吞吐量的非交互式请求分开处理[79,96]）来管理这种不可预测性，但面向更通用工作负载的 LLM 推理系统仍需更强大的技术——包括更精确的负载预测，以及动态批大小、弹性资源配置等自适应技术，以应对工作负载波动。

目前，研究人员已开始研发更具弹性的推理系统。

• 例如，在解耦式系统的弹性扩展方面，Splitwise [78]和 TetriInfer [39]可根据工作负载动态调整预填充与解码节点的比例。
• 在静态资源配置或初始资源配置确定方面，iServe [56]提出了“轻量级指纹模型”（lightweight fingerprint models）的概念，可用于快速评估不同配置。

unsetunset六、挑战与开放问题unsetunset

随着大型语言模型（LLM）在各类应用中不断普及，高性能推理系统的重要性将日益凸显。

• 在请求处理算子与算法方面，LLM 的应用场景已超越自然语言领域[68]，这可能会因注意力模式的差异催生新的算子与序列生成技术，为开发更具针对性的技术创造了机遇。
• 在模型执行方面，算子与算法的新进展自然会推动新内核的研发；
• 此外，负载预测对于任务优先级排序和负载均衡而言，仍是一个亟待解决的重要问题。
• 在内存管理方面，量化方案种类繁多，亟需更系统地理解“何时量化”“量化对象”以及更深入地研究“如何量化”。此外，诸如金字塔缓存[13,120]等新型逻辑内存层次结构，以及条目合并[60]等创新技术，也值得进一步探索。

所有这些方向都推动着系统设计领域的持续研究，尤其需要研发能够根据工作负载变化*【自适应管理】【有限硬件资源】的【弹性系统】。*

我们还提出未来研究的其他方向。

• 测试时缩放[109]的***【核心目标】是在固定延迟预算内实现最高推理质量***，而非直接最小化延迟；
• 目前，诸如深度研究[24]等消费级服务已开始利用宽松的延迟约束来处理网页分析等对质量敏感的应用。降低对延迟的关注度，可能会催生出新的推理系统设计方案。
• 对于支持通过低秩适配器（LoRA）进行配置切换的模型，推理过程中的适配器加载问题也需纳入考量[30,92]。
• 此外，专用 LLM 的兴起进一步丰富了 LLM 的多样性，例如面向资源受限设备的移动端 LLM[117]、多模态 LLM[76]以及用于与物理世界交互的机器人 LLM[59]。
• 与模型设计相辅相成的是硬件技术的进步：新型设备的多样特性为任务优先级排序和负载均衡带来了额外挑战，目前已有部分相关技术初步涌现[35,43]。

二、结论

LLM 的快速普及使得 LLM 服务提供商亟需专门的高性能推理系统来处理高流速、高容量的工作负载。此外，LLM 推理的自回归特性也推动了新技术的研发。

在本综述中，我们表明这些技术可在一个涵盖请求处理、模型执行和内存管理的统一框架下得到理解。为应对自回归生成带来的成本不确定性，这些技术依靠负载预测、自适应设计和根本性成本降低方法，以维持高性能。

这些技术最终整合形成了单副本和多副本推理系统，其中包括旨在通过逻辑任务解耦实现更精细资源管理的解耦系统。

最后

为什么要学AI大模型

当下，⼈⼯智能市场迎来了爆发期，并逐渐进⼊以⼈⼯通⽤智能（AGI）为主导的新时代。企业纷纷官宣“ AI+ ”战略，为新兴技术⼈才创造丰富的就业机会，⼈才缺⼝将达 400 万！

DeepSeek问世以来，生成式AI和大模型技术爆发式增长，让很多岗位重新成了炙手可热的新星，岗位薪资远超很多后端岗位，在程序员中稳居前列。

与此同时AI与各行各业深度融合，飞速发展，成为炙手可热的新风口，企业非常需要了解AI、懂AI、会用AI的员工，纷纷开出高薪招聘AI大模型相关岗位。

最近很多程序员朋友都已经学习或者准备学习 AI 大模型，后台也经常会有小伙伴咨询学习路线和学习资料，我特别拜托北京清华大学学士和美国加州理工学院博士学位的鲁为民老师给大家这里给大家准备了一份涵盖了AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频 全系列的学习资料，这些学习资料不仅深入浅出，而且非常实用，让大家系统而高效地掌握AI大模型的各个知识点。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

AI大模型系统学习路线

在面对AI大模型开发领域的复杂与深入，精准学习显得尤为重要。一份系统的技术路线图，不仅能够帮助开发者清晰地了解从入门到精通所需掌握的知识点，还能提供一条高效、有序的学习路径。

但知道是一回事，做又是另一回事，初学者最常遇到的问题主要是理论知识缺乏、资源和工具的限制、模型理解和调试的复杂性，在这基础上，找到高质量的学习资源，不浪费时间、不走弯路，又是重中之重。

AI大模型入门到实战的视频教程+项目包

看视频学习是一种高效、直观、灵活且富有吸引力的学习方式，可以更直观地展示过程，能有效提升学习兴趣和理解力，是现在获取知识的重要途径

光学理论是没用的，要学会跟着一起敲，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战案例来学习。

海量AI大模型必读的经典书籍（PDF）

阅读AI大模型经典书籍可以帮助读者提高技术水平，开拓视野，掌握核心技术，提高解决问题的能力，同时也可以借鉴他人的经验。对于想要深入学习AI大模型开发的读者来说，阅读经典书籍是非常有必要的。

600+AI大模型报告（实时更新）

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示。

AI大模型面试真题+答案解析

我们学习AI大模型必然是想找到高薪的工作，下面这些面试题都是总结当前最新、最热、最高频的面试题，并且每道题都有详细的答案，面试前刷完这套面试题资料，小小offer，不在话下

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】