LLM推理优化核心技术

KV Cache基础中的基础KV Cache 是 Transformer 注意力机制最自然的一类优化。随着自回归推理进入大规模生产它几乎成为必需品。没有 KV Cache 的话每生成一个新 token都要从头对整个历史序列重算注意力导致时延和成本都随序列长度呈平方级增长。没有 KV Cache每个新 token 都重算整段序列的注意力成本约为O(n²)规模化时速度和成本都难以接受。有 KV Cache把每个 token 已算出的 K/V 张量缓存起来每个新 token 的注意力计算降为O(n)这是生产推理的关键能力。Prefix Caching跨请求复用 KVKV Cache 不只是“让单次请求可用”。Prefix Caching 把复用能力扩展到了多个请求只要它们共享同样的前缀就能共享已计算过的 KV。 Vllm使用PrefixCaching, Sglang使用RadixTree 核心思想举个例子如果某次请求里出现过 “I want to travel to” 这段前缀那么该前缀对应 KV 已经算好。下一次请求只要开头 token 一样就可以直接跳过这段 prefill复用已有 KV从第一个新 token 开始算。这样能降低 TTFT并节省算力。Prefix Caching 最有价值的场景复杂系统提示词应用里每次请求都带很长、稳定的 system prompt。代码补全同一会话下文件上下文往往高度一致。文档问答与检索多轮对话里会反复出现相同检索片段。这就是为什么按 token 计费的 API 往往对cache hit input tokens收费更低这部分计算已经做过。**上下文工程建议**Prefix Caching 只对“从序列起点到第一个新 token”这一段生效。想提高命中率应把变化内容尽量往后放稳定的 system prompt 和文档放前面用户个性化问题放后面。非前缀缓存研究热点Prefix Caching 的硬限制是只能复用到第一个不重复 token 为止。当前研究在尝试缓存 prompt 中间任意位置的 token但要解决位置编码修正问题以保证正确性。CacheBlend和LMCache是当前支持非前缀缓存的代表性工具。KV Cache 存储内存分层问题KV Cache 理想上应尽量靠近算力侧但 GPU VRAM 有限且很快会被占满。给 KV Cache 分多少显存是推理系统中的核心配置项。 以 TensorRT-LLM 配置 kv_cache_config.free_gpu_memory_fraction 0.8 为例在一张 B200180GB VRAM上若模型权重与 buffer 占用 100GB剩余 80GB 中的 80%即 64GB可给 KV Cache。KV Cache 填满后必须淘汰旧条目这会提高后续请求的 cache miss 风险。这也是为什么生产环境通常会把 KV Cache 下沉到更慢的存储层像GB200这类 SKU 会搭配专用 CPU 与高带宽互联因此 G2 层速度会明显更快。Nvidia Dynamo通过 KV Block ManagerKVBM支持 KV offloading提供 API 在不同存储层之间移动 KV block并把高频访问 block 保持在最高带宽层。Cache-Aware Routing缓存感知路由生产里通常是多副本推理服务通过负载均衡分发请求。但要吃满 Prefix Caching 红利路由策略必须感知缓存状态。按用户粘性路由Per-user sticky routing同一用户请求始终打到同一副本。该用户会话历史的 KV Cache 会持续“热”在该副本上响应更快、单轮成本更低。全局 KV CacheG4通过网络存储维护所有副本可访问的共享缓存。它比 VRAM 慢但能保证任意副本都能复用任意预计算 KV适合超大共享前缀如系统提示词。处理长上下文即使 KV Cache 已将注意力复杂度降到 O(n)长上下文仍会在推理时大量吞噬 VRAM而 decode 阶段又偏偏受显存带宽约束。 对应有三类关键算法优化FlashAttention在片上 SRAM 中按小 tile 计算注意力避免在 HBM 中显式构建完整 QKᵀ 矩阵并融合 softmax 与缩放计算。它是精确注意力不是近似只是内存访问模式更优。PagedAttention把 KV 张量切成固定大小“页”非连续存储并配查找表。可消除碎片、支持动态增长、支持跨请求共享提升显存利用率与批处理灵活性。Chunked Prefill把长提示词拆成块增量构建 KV Cache。调度器可把某些请求的 chunked prefill 与其他请求的 decode 交错执行平衡“算力密集”和“带宽密集”负载是稳定高吞吐服务的重要基建能力。说明RAG 或摘要本质上是减少模型需要读取的数据量上面这些方法是当你决定把大量内容放进上下文窗口后如何更高效地存储并处理这些数据。前者是架构策略后者是算法/系统优化。并行化Parallelism前沿大模型无法装进单卡。FP8 下可粗略按“每十亿参数约 1GB”估算DeepSeek V3 的 671B 参数约需 671GB仅权重就远超 B200 的 180GB VRAM。即便 4 卡总量接近可容纳也还要给 KV Cache 预留大量空间。很多场景下整节点并行是必选项。**关键约束**多 GPU 推理最大的瓶颈是 GPU 间通信开销。NVLink 与 InfiniBand 带宽都远低于显存带宽。decode 又是显存带宽受限型任务因此并行策略必须结合硬件拓扑设计这就是topology-aware parallelism。三种并行方式Tensor ParallelismTP层内切分Pipeline ParallelismPP按层段切分Expert ParallelismEPMoE token 路由切分三者对比TP EP 混合部署稠密层 / 注意力层 - Tensor Parallelism每个注意力层跨 GPU 切分权重与矩阵乘分摊执行并在下一层前通过 all-reduce 同步结果。它主要降低单用户时延但依赖 NVLink 级别带宽。稀疏 MoE 层 - Expert Parallelism每张 GPU 承载部分专家token 被路由到对应专家所在 GPU。这里不需要 all-reducetoken 直接“去找专家”。它主要提升系统总吞吐且避免 all-reduce 成为瓶颈。在稠密层使用 TP、在 MoE 层使用 EP 是互补关系TP 针对计算重的注意力块降低时延EP 则把专家路由负载高效分散到多卡二者共同作用于同一次前向中的不同瓶颈。多节点推理Multi-node Inference当模型权重 KV Cache 需求超过单节点8 卡容量时就要扩展到多节点。多节点推理通常比多节点训练更复杂。多节点挑战* 节点间 InfiniBand 远慢于节点内 NVLink因此 TP 的 all-reduce 跨节点会成为瓶颈。 * 多 GPU 云环境下的基础设施抽象与编排复杂度高。 *Dense 模型通常节点内 TP节点间 PP。 *MoE 模型节点内 TP 节点间 PP EP 负责专家路由。TP8PP2 可降低单用户时延叠加 EP 可提升整体输出吞吐。 * 若不是模型和 KV Cache 规模强制要求多节点推理通常不是最优资源使用方式横向副本扩展或解耦式服务往往更高效。解耦PD分离Prefill Decode Disaggregation在这五类技术中解耦是架构上最激进的一种。它基于三个关键观察 *Prefill 算力密集Decode 显存带宽密集。batch 变大后两者会争夺同一批硬件资源。 *专用化能提升性能从 kernel 选择到推理引擎调参prefill 优化引擎与 decode 优化引擎各自都优于“一套引擎包办全部”。 * 高效并行化需要尽量规避通信瓶颈。拆开 prefill 与 decode 后每个阶段可采用更匹配自身工作负载的并行策略。工作机制解耦架构把 prefill 与 decode 分到不同引擎在不同 GPU 或节点上运行。标准解耦流程Prefill 引擎接收输入序列执行完整 prefill计算 KV Cache并生成首 token。计算出的 KV Cache 通过硬件互联传给 decode 引擎节点内 NVLink节点间 InfiniBand。Decode 引擎接收 KV Cache 后继续自回归生成后续 token。两个引擎可分别扩缩容、分别调优、分别并行化。条件聚合Conditional Aggregation更实用的变体全量解耦会让每个请求都承担额外开销。条件聚合更贴近真实流量。工作方式请求先到decode 引擎先判断该序列是否已命中缓存是否足够短可本地处理如果是就在 decode 引擎本地完成 prefill跳过解耦路径如果否再转发到 prefill 引擎走解耦流程。为什么这样会更好呢真实流量是混合分布并非每个请求都值得走解耦。短请求或缓存命中请求可以完全绕过 KV 传输开销只有长输入、未命中、prefill 计算重的请求才走解耦路径此时额外开销才划算。何时值得使用PD分离解耦需要较高工程投入一般仅在以下条件同时满足时才值得条件1规模日服务量达到 1 亿到数十亿 token。低于这个量级工程复杂度通常不划算。条件2模型模型规模至少 100B 参数。更小模型单请求开销不够大难以摊薄解耦成本。条件3流量画像prefill 占比高且输入序列长。若输入普遍较短横向副本扩展通常更优。如果条件 1 或 2 不成立往往是“用更贵硬件换来很小收益”如果条件 3 不成立优先做横向扩展。Nvidia Dynamo 与动态解耦Nvidia Dynamo是一个整合多种推理优化技术的服务框架。针对解耦场景Dynamo 支持动态聚合/解耦根据实时条件序列长度、缓存状态、引擎负载在聚合路径与解耦路径之间自适应路由。它不是静态配置而是按请求做决策在需要时享受解耦收益在不需要时避免无谓开销。上述总结Caching、Parallelism 与 Disaggregation* KV Cache 把注意力计算从 O(n²) 降到 O(n)没有它就没有大规模生产推理。 * Prefix Caching 把 KV 复用扩展到跨请求稳定 token 放前、变化 token 放后可提升命中率。 * KV Cache 存储可看作四层层级GPU VRAM - CPU RAM - 本地 SSD - 网络 SSDNvidia Dynamo 的 KVBM 负责层间迁移。 * 缓存感知路由按用户粘性或全局共享缓存是多副本场景吃满 Prefix Caching 的关键。 * FlashAttention、PagedAttention、Chunked Prefill 是长上下文高效处理的基础算法。 * Tensor Parallelism 是默认多 GPU 低时延策略强依赖 NVLink多节点通常采用“节点内 TP 节点间 PP”。 * Expert Parallelism 面向 MoE 模型通过分布式专家路由提升系统总吞吐。 * 在稠密/注意力层用 TP在 MoE 层用 EP可同时命中不同瓶颈。 * Disaggregation 将 prefill 与 decode 分离仅在超大规模1e8 token/day、超大模型100B与 prefill-heavy 流量下值得投入。 * Conditional Aggregation 是更实用形态只让长且未命中的请求走解耦路径。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】