新闻

LLM推理优化:从每一层压低开销与延迟(2026)| Morph

新闻 2026-05-11 0 次浏览

平均每次 LLM API 调用中,约有 40-60% 的输入 token 被浪费在了模型并不需要的上下文上。过时的对话历史、冗余的系统提示词、明明只需要三个函数却传入了整个文件。你需要为每一个浪费的 token 付出双重代价:既包括 API 账单上的直接费用,也包括模型在处理这些填充内容时产生的延迟。

80%
成本降低(叠加优化)
2-4倍
量化带来的内存节省
3-10倍
连续批处理带来的吞吐量提升
33K tok/s
紧凑型上下文压缩速度
LLM 推理优化层级:模型量化、系统批处理及上下文压缩与成本降低箭头的叠加

成本难题

从 2025 年到 2026 年,LLM API 的价格大约下降了 80%。如今,GPT-4 级别的性能每百万 token 的成本仅需 0.40 美元,远低于 2023 年 3 月的 30 美元。然而,推理量的增长速度远超价格下跌的速度。那些每个任务需要调用 50-200 次 LLM 的智能体工作流,使得原本低廉的 token 价格变成了昂贵的单任务成本。

这个问题在三个方面不断恶化:

上下文膨胀

在多轮对话中,Agent 会不断积累上下文。到了第 30 轮,单次调用的输入 token 量可能是第一轮的 5-10 倍。其中大部分 token 都是无效的陈旧数据。

重复计算

如果不使用缓存,模型会在每次调用时重新计算相同的系统提示词和对话前缀的注意力。对于一个 10K token 的前缀,这意味着每个请求都会浪费数十亿次的 FLOPs。

硬件利用率不足

默认的服务配置会导致 GPU 在请求之间处于空闲状态。如果没有连续批处理,单价 3 美元/小时的 H100 可能每秒只能处理 50 个 token,而不是 16,000 个以上。

优化的核心不在于压榨那几个百分点的性能,而在于消除默认配置带来的 3-10 倍额外开销。下述技术将在源头针对性地解决每一处浪费。

模型层级的优化

模型层技术旨在降低每个参数的计算成本。它们在模型接收请求之前,直接对模型本身进行修改。

量化 (Quantization)

量化将权重精度从 FP16 降低至 INT8、INT4 甚至更低。这是一种权衡:精度的降低意味着更小的内存占用和更快的矩阵乘法运算,代价是微乎其微的精度损失。

2-4倍
内存减少 (INT8/INT4)
约50%
单次推理成本降低
95-99%
保留的精度
1.56倍
加速效果 (SmoothQuant)

SmoothQuant 将量化难度从激活值转移到权重上,实现了 2 倍的内存缩减,且几乎不损失精度。GPTQAWQ 利用校准数据来寻找每层最佳量化参数。谷歌的 TurboQuant(2026 年 3 月)将 KV 缓存本身压缩至每值 3 比特,在零精度损失的情况下将 KV 缓存内存削减了 6 倍。

剪枝 (Pruning)

剪枝技术负责移除模型中的冗余参数。结构化剪枝会移除整个注意力头或 MLP 列;非结构化剪枝则将单个权重置零。一个经过剪枝的 60 亿参数模型,其运行速度比其稠密版本快 30%,且在 MMLU 上的得分为 72.5,击败了未剪枝的 40 亿参数模型(得分 70.0)。

知识蒸馏 (Knowledge Distillation)

蒸馏技术训练一个较小的“学生”模型,使其输出分布匹配较大的“教师”模型。学生模型的运行成本仅为教师模型的一小部分。最优的压缩流程是 P-K-D-Q:先剪枝,次蒸馏,后量化。每一步的效果都会叠加。

何时使用何种技术

对于 API 提供商和自部署用户而言,量化提供了最佳的成本/回报比。剪枝和蒸馏需要训练算力,但能永久降低模型成本。如果你通过 API 使用 LLM,这些由供应商处理。如果你自托管,请从量化开始(零训练成本),然后针对特定工作负载评估剪枝和蒸馏。

系统层级的优化

系统层级技术旨在不改变模型的前提下最大化硬件利用率。它们运行于模型与网络之间的服务层。

连续批处理 (Continuous Batching)

静态批处理会等待批次内的所有请求完成后才接受新请求。短请求必须等待长请求生成完毕。连续批处理则能在旧请求完成时动态插入新请求,确保 GPU 始终处于满载状态。

吞吐量的差异是显著的:在相同硬件上可提升 3-10 倍。Anyscale 在生产工作负载中启用连续批处理后,测得的总体吞吐量提升了 23 倍。

PagedAttention 与 KV 缓存管理

KV 缓存用于存储计算出的注意力键值,避免模型在每个 token 上重复计算。但问题是:为最大序列长度预分配 KV 缓存内存会浪费高达 90% 的 GPU 内存,因为大多数请求根本用不上完整的上下文窗口。

PagedAttention (vLLM) 将 KV 缓存分割为小的、可复用的页面,按需分配。这能将内存浪费减少 90%,并使服务吞吐量提升至 24 倍,因为内存中能同时容纳更多请求。

ChunkKV 将语义块而非孤立的 token 作为压缩单元,从而在激进压缩下保留语言结构。RocketKV 使用了两级流水线:先是粗粒度的 KV 驱逐,然后对幸存者进行细粒度压缩。

推测解码 (Speculative Decoding)

自回归解码每次生成一个 token,导致 GPU 在每次前向传递中利用不足。推测解码引入了一个小型、快速的草稿模型,用于提前预测多个 token。目标模型则在一次并行传递中验证它们。被接受的 token 在数学上与目标模型单独生成的完全一致。

典型加速 2-3 倍

在通用查询中使用现成的 EAGLE3 草稿模型的生产基准测试。这种加速本质上是免费的:输出质量完全一致。

优化后高达 5 倍

针对特定领域或硬件优化的实现,相比标准自回归解码可达到 5-5.5 倍的加速。

草稿延迟是关键

最近的基准测试显示,草稿模型的精度与吞吐量之间关联不大。草稿模型的延迟才是决定端到端速度的主要因素。

FlashAttention

FlashAttention 通过分块计算以及将 Softmax 与矩阵乘法融合,重新组织了注意力计算以最小化内存 I/O。FlashAttention-3 提供了目前最快的定制注意力内核,已集成到 vLLM 和 SGLang 中。

推理引擎对比

四款引擎主导了 2026 年的生产级 LLM 服务。各自采用了不同的优化路径。

引擎版本吞吐量 (H100)核心特性适用场景
SGLangv0.4.316,200 tok/sRadixAttention 前缀缓存重前缀工作负载 (RAG, 聊天)
LMDeployLatest16,200 tok/s持久批处理调度高吞吐量服务
vLLMv0.7.312,500 tok/sPagedAttention, Blackwell 支持灵活性, 频繁模型切换
TensorRT-LLMLatest高并发下最高编译的 CUDA 内核单模型, 长期生产

SGLang/LMDeploy 与 vLLM 之间 29% 的吞吐量差距,在前缀较重的工作负载中会缩小,因为 SGLang 的 RadixAttention 能提供额外优势。TensorRT-LLM 需要编译步骤,但一旦完成,在规模化运行时能提供最高的吞吐量。

对于大多数团队,建议如下:如果你频繁更换模型且追求最便捷的生产路径,请选 vLLM。如果你的工作负载包含共享前缀(聊天机器人、RAG、多轮对话),请选 SGLang。如果你在长期生产环境中运行单一模型且优先考虑吞吐量,请选 TensorRT-LLM

应用层级的优化

应用层级技术旨在减少发送给模型的 token 数量。它们是对于通过 API 消费 LLM 的团队来说投资回报率(ROI)最高的优化,因为它们能与你供应商已完成的模型层和系统层工作产生叠加效应。

Prompt 缓存

Prompt 缓存重用注意力层中先前计算出的 KV 张量。当连续的请求共享一个公共前缀(系统提示词、对话历史)时,缓存部分会完全跳过预填充阶段。

Anthropic、OpenAI 和 Google 都提供了 Prompt 缓存。对于超过 10K token 的上下文,缓存部分的延迟可降低 80-90%。在 Anthropic 的实现中,缓存的输入 token 不计入速率限制,这意味着在 80% 的缓存命中率下,实际吞吐量翻了两番(5 倍)。

语义缓存 (Semantic Caching)

语义缓存更进一步:它存储完整的请求-响应对,并为语义相似的查询返回缓存响应。一旦命中缓存,LLM 推理调用将被完全省去。AWS 的基准测试显示,对于具有重复查询模式的工作负载,可节省 3-10 倍的成本。

上下文压缩 (Context Compression)

在智能体工作流中,大部分输入 token 都是低信噪比的:旧的对话轮次、样板化的文件头、模型已处理过的文件内容。上下文压缩会在推理前将它们移除。

LLMLingua 这样的技术通过排序并保留关键 token,可实现高达 20 倍的压缩。但是,那些重写内容的压缩方法会引入保真度问题。基于摘要的方法在生产评估中的准确度得分仅为 3.4-3.7/5,因为它们会把文件路径、错误码和具体决策给改写掉。

逐字压缩 采取了一种不同的方法:它删除低信息量的 token,同时逐字保留每个幸存的句子。不生成内容,不重新格式化。JetBrains 发现,与逐字压缩相比,摘要会导致 Agent 的轨迹延长 13-15%,因为 Agent 必须重新推导被改写掉的信息。

Morph Compact

Morph Compact 在定制推理引擎上以每秒 33,000 token 的速度运行逐字上下文压缩。它能将上下文缩减 50-70%,同时逐字保留每个幸存的句子。速度足够快,可以在每次 LLM 调用前实时运行,而不仅仅是在 95% 容量临界点时。

模型路由 (Model Routing)

并非每个请求都需要你最昂贵的模型。将分类和提取任务路由到 Haiku(输入 $0.25/M)而不是 Sonnet(输入 $3/M),对于这些任务类型来说,成本可降低 12 倍,而质量差异微乎其微。生产环境中的路由通常能带来 2-5 倍的总体成本节约。

叠加优化层级

每一层都针对不同的瓶颈。它们互不重叠,效果叠加。

层级降低对象典型节省投入精力
量化 (模型)单参数内存2-4倍内存, ~50% 成本低 (现有工具)
连续批处理 (系统)GPU 空闲时间3-10倍吞吐量低 (引擎配置)
PagedAttention (系统)KV 缓存内存浪费高达 24倍吞吐量低 (使用 vLLM/SGLang)
推测解码 (系统)解码延迟2-5倍速度中 (草稿模型选择)
上下文压缩 (应用)发送的输入 token减少 50-70% token低 (API 调用)
Prompt 缓存 (应用)重复预填充缓存部分 80-90% 延迟低 (API 标记)
模型路由 (应用)单次请求成本2-5倍总体节省中 (需分类器)

一个具体的例子:一个在量化后的 Llama 70B 模型(便宜 2 倍)上运行的编码 Agent,通过 vLLM 提供服务并启用连续批处理(吞吐量 5 倍),并在每次调用前使用 Morph Compact 压缩上下文(输入 token 减少 60%)。综合效果是:与使用全上下文的原始 FP16 服务相比,每任务成本大约降低 80%。

对于使用托管 API(OpenAI, Anthropic, Google)的团队,模型层和系统层由供应商处理。应用层优化,特别是上下文压缩、Prompt 缓存和模型路由,才是你能控制的杠杆。它们也是投资回报率最高的,因为它们减少了进入一个已经被你的供应商优化过的系统的 token 数量。

衡量优化效果

错误的指标会掩盖浪费。请分别追踪以下各项:

单任务 token 消耗量

完成单位工作所消耗的总 token 数(而非单次请求)。这是映射到成本的指标。一个需要 50 次请求且平均每次 8K token 的编码 Agent,每任务成本为 400K token。

时间

点击查看文章原文
上一篇
Inference Expense Reduction | EngineersOfAI — Tech Training for AI Specialists
下一篇
LLM 推理中隐藏的性能瓶颈及优化之道 | DigitalOcean
返回列表