摘要：
大模型上线后，性能优化成为核心挑战，本文系统梳理LLM推理优化的关键技术。核心问题包括首token延迟（Prefill阶段受输入长度影响）和逐token生成效率（Decode阶段依赖显存带宽与KVCache管理）。优化手段包括：

1. KVCache：缓存历史token的Key/Value以减少重复计算，但需平衡显存占用；
2. 量化：降低模型精度（如INT8/INT4）以缩减显存，需验证业务指标；
3. 连续批处理：动态调度请求提升GPU利用率，解决长短请求混合问题；
4. PagedAttention：分块管理显存，减少碎片化，适配动态请求；
5. 投机解码：用小模型预生成候选token，加速长文本生成；
6. Prompt优化：精简输入上下文，减少无效计算。
   推荐路径：优先优化Prompt和推理框架（如vLLM），再逐步引入量化、高级调度等。最终目标是在成本可控下提升系统吞吐与稳定性。

大模型应用真正上线后，很多团队会发现：Demo 阶段最关心“效果”，生产阶段最头疼“性能”。

同样一个模型，在本地测试时可以正常回答；但一旦接入真实业务，就会遇到各种问题：

• 首 token 等待时间太长；
• 并发一高就排队；
• GPU 显存很快被打满；
• 长文本请求拖慢整体吞吐；
• API 成本随着调用量快速上升。

这时，问题已经不只是“模型选哪个好”，而是“如何让模型更快、更稳、更便宜地服务用户”。

本文聚焦一个非常具体的大模型细分方向：大模型推理优化。我们会从推理流程、KV Cache、量化、批处理、PagedAttention、投机解码等关键技术入手，系统梳理 LLM 推理性能优化的核心思路。

---

一、大模型推理到底慢在哪里？

大语言模型的推理过程通常可以分为两个阶段：

1. Prefill 阶段：处理用户输入的 prompt2. Decode 阶段：逐 token 生成回答

例如用户输入：

请总结以下 3000 字文档，并提取 5 个关键观点。

模型首先要读取并理解这 3000 字输入，这就是 Prefill 阶段。

随后模型开始一个 token 一个 token 地生成答案：

这篇文档主要讨论了……

这就是 Decode 阶段。

两者的性能瓶颈不同。

1. Prefill 阶段

Prefill 阶段需要对整个输入序列做一次前向计算。输入越长，计算量越大。

如果 prompt 很长，比如包含文档、代码、历史对话、检索结果，首 token 等待时间就会明显增加。

常见表现是：

用户提交问题后，等了几秒甚至十几秒，才看到第一个字输出。

这类问题通常和输入长度、模型大小、GPU 算力有关。

2. Decode 阶段

Decode 阶段是逐 token 生成。

假设模型每秒生成 30 token，回答需要 600 token，那么仅生成阶段就需要约 20 秒。

Decode 阶段的特点是：

每一步只生成一个新 token，但每一步都要访问模型参数和历史上下文。

因此，它对显存带宽、KV Cache 管理和批处理调度非常敏感。

---

二、先理解 KV Cache：大模型推理优化的基础

Transformer 模型在生成每个 token 时，都需要关注前面已经生成的 token。

如果每生成一个新 token，都重新计算所有历史 token 的 Key 和 Value，成本会非常高。

KV Cache 的作用就是缓存历史 token 在 Attention 中的 Key 和 Value，避免重复计算。

可以简单理解为：

没有 KV Cache：每生成一个 token，都重新计算完整上下文
有 KV Cache：历史 token 的 Key/Value 复用，只计算新 token

1. KV Cache 为什么重要？

假设输入 prompt 有 2000 token，模型要继续生成 500 token。

如果没有 KV Cache，生成第 500 个 token 时，模型需要重新处理前面 2499 个 token 的注意力信息。

有了 KV Cache 后，模型只需要：

1. 读取历史 KV Cache2. 计算当前 token 的 Query、Key、Value3. 与历史 Key 做 Attention4. 生成下一个 token

这能极大降低重复计算。

2. KV Cache 的代价

KV Cache 虽然提升速度，但会占用大量显存。

KV Cache 显存大致和以下因素相关：

显存占用 ∝ batch_size × sequence_length × layer_count × hidden_size

也就是说：

• 并发越高，占用越大；
• 上下文越长，占用越大；
• 模型层数越多，占用越大；
• 隐藏维度越大，占用越大。

这也是为什么长上下文模型虽然能力强，但部署成本明显更高。

例如在客服、知识库问答、代码助手等场景中，如果每次都塞入很长的历史对话和检索内容，KV Cache 会迅速膨胀。

---

三、量化：用更低精度换更低成本

量化是大模型部署中最常见的优化手段之一。

模型训练通常使用 FP16、BF16 或 FP32 精度，而推理时可以使用更低精度，例如 INT8、INT4。

简单理解：

FP16：每个参数 16 bitINT8：每个参数 8 bitINT4：每个参数 4 bit

精度越低，模型占用显存越小，推理成本也可能越低。

1. 量化能带来什么收益？

量化主要带来三类收益：

1. 降低模型权重显存占用2. 提升显存加载效率3. 允许在更小 GPU 上部署更大模型

例如一个 7B 模型：

FP16 权重大约需要 14GB 显存INT8 权重大约需要 7GB 显存INT4 权重大约需要 3.5GB 显存

当然，这只是权重本身的占用，实际部署还要考虑 KV Cache、运行时开销、batch 等因素。

2. 量化会不会影响效果？

会，但不一定明显。

一般来说：

• INT8 对多数任务影响较小；
• INT4 对复杂推理、数学、代码任务影响可能更明显；
• 模型越小，低比特量化带来的损失通常越敏感；
• 量化算法越好，效果损失越低。

常见量化方法包括：

GPTQAWQSmoothQuantbitsandbytesGGUF

如果是生产环境，不建议只看 benchmark。最好准备自己的业务测试集，比如：

知识库问答准确率客服回复满意度代码生成通过率摘要一致性结构化抽取准确率

用业务指标判断量化是否可接受。

3. 什么时候适合量化？

量化适合以下场景：

1. 显存不足，但希望部署较大模型2. 并发压力较高，希望降低成本3. 对轻微效果损失可接受4. 任务偏问答、摘要、分类、抽取

如果任务高度依赖精确推理，例如复杂数学、代码竞赛、金融风控解释，低比特量化要更谨慎。

---

四、连续批处理：提高吞吐的关键

传统批处理的思路是：

收集一批请求 -> 一起推理 -> 全部完成后处理下一批

这在普通深度学习任务中很常见，但在大模型生成场景中并不高效。

因为不同用户的输出长度不同。

例如：

用户 A：生成 20 token用户 B：生成 200 token用户 C：生成 800 token

如果三者组成同一个 batch，短请求很快结束，长请求还在继续。传统批处理会导致资源浪费和等待。

1. Continuous Batching 是什么？

连续批处理的核心思想是：

推理过程中动态加入新请求，动态移除已完成请求。

也就是说，GPU 不需要等整个 batch 全部结束，而是每一步都可以重新调度活跃请求。

这对在线服务非常重要。

它能显著提升：

1. GPU 利用率2. 系统吞吐量3. 并发处理能力

当前很多高性能推理框架都支持连续批处理，例如：

vLLMTensorRT-LLMTGISGLangLMDeploy

2. 连续批处理解决什么问题？

它主要解决在线推理中的“请求长度不一致”问题。

在真实业务中，请求通常是不规则的：

• 有人问一句简单问题；
• 有人上传几千字文档；
• 有人要求生成长报告；
• 有人只要一句分类结果。

如果没有动态调度，短请求可能被长请求拖慢，整体延迟和吞吐都会变差。

---

五、PagedAttention：让 KV Cache 管理更高效

PagedAttention 是 vLLM 中非常重要的设计，它解决的是 KV Cache 显存管理问题。

传统 KV Cache 通常需要为每个请求分配连续显存空间。如果请求长度变化很大，就容易产生显存浪费。

PagedAttention 借鉴了操作系统虚拟内存分页思想，将 KV Cache 拆成固定大小的 block。

可以类比为：

传统方式：每个请求需要一整块连续显存
PagedAttention：KV Cache 被拆成多个小块，按需分配和映射

1. 为什么这很重要？

因为 LLM 请求的长度高度不确定。

例如：

请求 A：输入 500 token，输出 100 token请求 B：输入 6000 token，输出 50 token请求 C：输入 1000 token，输出 2000 token

如果预先分配大块显存，很容易浪费。

PagedAttention 通过 block 管理，可以提升 KV Cache 显存利用率，让同一张 GPU 承载更多并发请求。

2. PagedAttention 带来的收益

它主要带来：

1. 减少 KV Cache 显存碎片2. 提升长短请求混合场景的吞吐3. 支持更高并发4. 更适合在线服务动态请求

这也是为什么 vLLM 在很多部署场景中表现优秀的原因之一。

---

六、投机解码：用小模型帮大模型加速

投机解码，也叫 Speculative Decoding，是近年来非常热门的推理加速方法。

它的核心思想是：

用一个小模型先快速生成多个候选 token，再让大模型一次性验证这些 token。

如果小模型预测得比较准，大模型就可以一次接受多个 token，从而减少逐 token 解码次数。

1. 一个简单例子

假设用户输入：

中国的首都是

小模型快速预测：

北京，是中国的政治、文化中心

大模型随后验证这些 token 是否符合自己的分布。

如果大模型认可前几个 token，就可以一次性接受，而不是一个 token 一个 token 地生成。

2. 投机解码适合什么场景？

投机解码适合：

1. 输出较长的生成任务2. 小模型和大模型分布比较接近3. 对延迟敏感的在线服务4. 有额外计算资源运行 draft model

例如：

• 长文本生成；
• 报告生成；
• 代码补全；
• 对话式助手；
• 内容改写。

但它并不是所有场景都有效。如果小模型预测质量很差，大模型频繁拒绝候选 token，加速效果就会下降。

---

七、Prompt 和上下文优化：最容易被忽视的性能优化

很多团队优化推理性能时，第一反应是换 GPU、换框架、上量化。

但实际上，Prompt 本身也是重要性能因素。

因为输入越长：

Prefill 越慢KV Cache 越大成本越高

在 RAG 场景中尤其明显。

有些系统会把检索到的 10 个文档片段全部塞给模型，每个片段几百字，最后 prompt 动辄上万 token。

这不仅慢，还可能降低回答质量。

1. 控制检索上下文长度

RAG 系统中建议关注：

1. top_k 不要盲目过大2. chunk 不要过长3. 使用 rerank 过滤低相关内容4. 对长文档先摘要再输入5. 删除重复片段

比起“塞更多内容”，更好的策略是“塞更相关的内容”。

2. 减少无效历史对话

多轮对话中，不应该无限保留历史消息。

可以采用：

1. 只保留最近 N 轮2. 对早期对话做摘要3. 保留结构化用户画像4. 按任务上下文裁剪历史

否则用户聊得越久，系统越慢，成本也越高。

3. 简化系统提示词

有些应用的 system prompt 写得非常长，包含大量重复规则。

建议把提示词分成：

必须长期生效的规则当前任务需要的规则可由代码控制的规则

能用程序逻辑约束的，不一定都要塞进 prompt。

---

八、常见推理框架对比

目前常见的大模型推理部署框架包括：

1. vLLM

特点：

1. PagedAttention2. 连续批处理3. OpenAI API 兼容4. 部署门槛相对低5. 社区活跃

适合大多数在线服务场景，尤其是希望快速部署 OpenAI 兼容接口的团队。

2. TensorRT-LLM

特点：

1. NVIDIA 官方生态2. 性能优化能力强3. 适合 NVIDIA GPU4. 部署和调优复杂度较高

适合对性能要求极高、具备工程优化能力的团队。

3. Text Generation Inference

特点：

1. Hugging Face 生态友好2. 支持多种开源模型3. 部署相对成熟4. 适合模型服务化

适合已经深度使用 Hugging Face 生态的团队。

4. llama.cpp

特点：

1. 适合 CPU 或消费级设备2. 支持 GGUF 格式3. 量化模型生态丰富4. 本地部署方便

适合个人电脑、本地工具、边缘设备、轻量级场景。

---

九、一个生产级 LLM 服务需要关注哪些指标？

优化不能只凭感觉，需要看指标。

常见核心指标包括：

1. TTFT

TTFT 是 Time To First Token，即首 token 延迟。

用户感知上，TTFT 决定“模型多久开始回答”。

如果 TTFT 太高，用户会觉得系统卡顿。

影响 TTFT 的因素包括：

输入长度Prefill 速度排队时间batch 调度模型大小

2. TPOT

TPOT 是 Time Per Output Token，即每个输出 token 的耗时。

它决定模型生成速度。

影响 TPOT 的因素包括：

模型大小decode batch 大小显存带宽KV Cache 管理量化方式

3. Throughput

吞吐量通常用 tokens/s 衡量。

要区分：

单请求 tokens/s系统整体 tokens/s

单请求速度快，不代表整体吞吐高。生产服务更关心在高并发下系统能稳定处理多少 token。

4. GPU 利用率与显存占用

需要持续监控：

GPU compute utilizationGPU memory usageKV Cache usage显存碎片OOM 次数

显存打满不一定代表算力跑满。很多 LLM 服务瓶颈其实在显存带宽和调度效率。

5. 请求排队时间

用户看到的延迟包括：

排队时间 + Prefill 时间 + Decode 时间

如果并发上来后排队时间暴涨，说明服务容量不足或调度策略需要优化。

---

十、不同场景下的优化策略

1. 智能客服

特点：

请求多单次回答较短对首 token 延迟敏感

优化建议：

1. 使用较小模型或量化模型2. 控制 RAG 上下文长度3. 开启连续批处理4. 缓存高频问题5. 优化 TTFT

2. 知识库问答

特点：

Prompt 较长检索内容较多准确性要求较高

优化建议：

1. 使用 rerank 减少无关上下文2. 控制 chunk 数量3. 对长文档做摘要压缩4. 监控 Prefill 时间5. 保留答案来源，便于评估质量

3. 代码助手

特点：

上下文长输出可能较长对模型能力要求高

优化建议：

1. 谨慎使用低比特量化2. 优先优化上下文裁剪3. 可尝试投机解码4. 对项目文件做结构化索引5. 控制补全窗口大小

4. 文案生成

特点：

输出长并发可能波动对生成速度敏感

优化建议：

1. 使用流式输出改善体验2. 尝试投机解码3. 使用连续批处理提升吞吐4. 对模板类 prompt 做缓存5. 根据任务难度路由不同模型

---

十一、一个推荐的优化路径

如果你正在优化自己的 LLM 服务，不建议一开始就上复杂方案。

可以按照以下顺序排查和优化：

第一步：统计指标TTFT、TPOT、吞吐、显存、排队时间
第二步：优化 Prompt减少无效上下文、控制历史对话、压缩 RAG 内容
第三步：选择合适推理框架vLLM、TGI、TensorRT-LLM、llama.cpp
第四步：开启连续批处理提升高并发下 GPU 利用率
第五步：尝试量化从 INT8 或高质量 INT4 开始验证
第六步：优化 KV Cache关注长上下文、并发、显存占用
第七步：引入高级优化PagedAttention、投机解码、模型路由、缓存

这个顺序的原则是：

先做低风险、高收益优化；再做工程复杂度高的优化。

很多时候，仅仅通过减少无效 prompt 和开启高效推理框架，就能获得非常明显的收益。

---

十二、总结

大模型推理优化不是单点技术，而是一整套系统工程。

从底层看，需要理解 Transformer 推理流程、KV Cache、显存占用、批处理调度；从工程看，需要选择合适的推理框架、量化方案和部署策略；从业务看，还要控制 prompt 长度、设计缓存、区分不同任务复杂度。

可以用一句话概括：

LLM 推理优化的目标，不是单纯让一次请求更快，而是在成本可控的前提下，让系统稳定服务更多真实用户。

对于大多数团队来说，建议优先关注四件事：

1. 减少无效上下文2. 使用支持连续批处理的推理框架3. 合理利用量化降低显存成本4. 持续监控 TTFT、TPOT 和吞吐量

当你开始用这些指标来观察系统，就会发现大模型应用的性能瓶颈不再是一个模糊问题，而是可以被拆解、定位和持续优化的工程问题。