LLM 推理的延迟不能只用“快”或“慢”概括。一次回答里至少有两个阶段Prefill和Decode。Prefill 负责处理完整 prompt并生成第一个输出 tokenDecode 负责在第一个 token 之后继续一个 token 一个 token 地生成内容。这两个阶段的瓶颈不一样。Prefill 主要吃 GPU 算力决定用户等多久才能看到第一段文字Decode 主要吃显存带宽和 KV Cache决定文字流出来的间隔有多短。所以优化 LLM 应用前先问清楚延迟发生在哪里。是首 token 出得慢用户提交问题后一直空等还是首 token 已经出来但后续文字像挤牙膏这两种慢对应不同系统瓶颈也对应不同优化手段。Akshay Pachaar 把 LLM inference 的链路讲得比较完整tokenizer、embedding、attention、prefill、decode、KV cache、quantization 都串在了一起。下面按工程视角重新梳理一遍。这张图把推理延迟拆成两块Prefill 是 compute-boundDecode 是 memory-bound。第一 token 慢、后面 token 一粒一粒出来原因就在这里。LLM 为什么只能一个 token 一个 token 写LLM 不是一次性写完整段答案。模型每一步只做一件事根据当前上下文预测下一个 token。预测出来以后这个 token 会被接回上下文模型再继续预测下一个 token。循环不断重复直到生成结束。一次生成可以简化成下面这个过程输入 prompt ↓预测第 1 个 token ↓把第 1 个 token 接回上下文 ↓预测第 2 个 token ↓不断重复理解 LLM 推理关键不是想象模型如何“一次写出答案”而是看清楚每一步如何预测下一个 token以及第一个 token 和后续 token 为什么走的是两种性能路径。Tokenizer 决定模型实际处理多少内容神经网络不直接读取中文或英文。模型看到的是数字。用户输入的文本会先经过 tokenizer被切成一串 token每个 token 对应一个整数 ID。现代 LLM 常用 Byte Pair Encoding 一类方法。它会把高频片段合并成词表里的 token。常见词可能一个 token 就能表示少见词会被拆成多个片段。Tokenizer 会影响成本也会影响延迟。如果某种语言或领域词在 tokenizer 训练数据里覆盖不足同样一句话可能被切成更多 token。token 越多模型要处理的位置越多首 token 等待时间也会变长。这也是为什么“字符数差不多”的两段输入在模型服务里成本可能不一样。模型计费和推理负载看的是 token不是字符数。Embedding 把 token ID 变成语义向量token ID 只是编号还不能直接参与神经网络计算。模型会用 embedding table 把每个 token ID 映射成一个向量。假设词表大小是 50Khidden dimension 是 4096那么 embedding table 的形状就是[50000, 4096]。输入一个 token ID实际就是去表里取一行向量。这些向量会在训练过程中学到语义关系。语义相近的 token 会被推到相近位置。比如king和queen会比较接近python既可能靠近snake也可能在另一个语义方向上靠近javascript。模型还需要知道顺序。Attention 本身不知道哪个 token 在前、哪个 token 在后所以现代模型会用 RoPE 这类位置编码方法让向量携带位置信息。Attention 让每个 token 带着上下文判断向量进入 transformer 层后主要计算开始。一个 LLM 往往有几十层 transformer。每一层大致做两类计算self-attention 混合不同 token 之间的信息feed-forward network 处理每个 token 自己的信息。Self-attention 的关键是 Q、K、V。每个 token 的向量会分别乘上三组权重矩阵得到三个新向量Query我现在要找什么信息Key我这里有什么信息可供匹配Value如果别人需要我我能贡献什么内容Attention 的计算可以这样理解每个 token 用自己的 Query 去匹配所有 token 的 Key再按匹配强度混入对应的 Value。这个机制让 token 不再孤立。代词可以回看前面的人名技术名词可以吸收上下文定义长句后半段也可以引用前半段的信息。Attention 负责搬运上下文feed-forward network 负责继续加工每个位置的表示。几十层堆叠以后模型就能在长上下文里追踪引用、关系和语义依赖。第一个 token 为什么要等经过最后一层 transformer 后模型会取最后一个位置的向量把它投影回词表大小。如果词表有 50K 个 token模型就会得到 50K 个分数。经过 softmax 后这些分数变成概率分布。采样或取最大概率以后下一个 token 才会出来。这一步听起来只是“预测一个词”前面却要先完成整段 prompt 的计算。当 prompt 有 2000 个 token 时每一层 transformer 都要处理这 2000 个 token。好消息是Prefill 阶段可以并行所有 token 的 Q、K、V 可以一起算attention 也可以通过大矩阵乘法完成。GPU 很擅长这种工作负载。大矩阵乘大矩阵正是 GPU 的强项。Prefill 的瓶颈主要是算力也就是 compute-bound。它决定的指标叫TTFTTime To First Token也就是用户提交问题后第一段文字多久才开始出现。长 prompt 会显著增加 TTFT因为模型必须先把所有输入 token 处理完才有资格生成第一个输出 token。后续 token 为什么一粒一粒出来第一个 token 出来以后模型进入 Decode 阶段。Decode 和 Prefill 的工作负载完全不同。生成第 51 个 token 时前 50 个 token 的 Key 和 Value 已经算过而且不会再变化。模型只需要为新 token 计算新的 Q、K、V然后让新 token 去看前面缓存好的 K、V。这个阶段计算量看起来变小了瓶颈却转向显存读写。每生成一个 tokenGPU 都要加载模型权重还要读取已有的 KV Cache。计算本身不大但数据搬运很多。GPU 算力可能空着延迟卡在内存带宽。Decode 决定的指标叫ITLInter-Token Latency也就是相邻两个输出 token 之间隔多久。这就是 Prefill 和 Decode 的关键差异Prefill 是 compute-boundDecode 是 memory-bound。同一个模型、同一张 GPU、同一次请求前后两个阶段的优化方向完全不同。KV Cache 用显存换时间KV Cache 解决的是重复计算。如果没有 KV Cache模型每生成一个新 token都要重新计算整个上下文的 attention。生成越长重复计算越多复杂度会迅速变差。有了 KV Cache模型会把每一层、每个历史 token 的 Key 和 Value 存下来。下一步 decode 时模型直接复用这些缓存只为新 token 计算增量。收益很直接长生成场景里速度可以提升数倍。代价也同样直接KV Cache 吃显存而且会随 token 数线性增长。原文里给了一个估算对 13B 模型来说KV Cache 可能接近每 token 1MB。4K 上下文光缓存就可能占掉约 4GB 显存。长上下文慢不只是模型“想得更多”。更准确地说是缓存变大了显存压力和带宽压力都在变大。常见优化包括把 KV Cache 量化到 INT8 或 INT4使用 sliding window丢掉窗口外的 token用 grouped-query attention 让多个 attention head 共享 K、V像 vLLM 的 PagedAttention 那样把 KV Cache 当成操作系统内存分页管理这些优化看起来底层却直接决定长上下文模型能不能稳定服务用户请求。DeepSeek-V4 的例子长上下文开始围绕缓存设计原文特别提到 DeepSeek-V4因为它把长上下文推理的瓶颈讲得更直观。根据原文引用的技术报告DeepSeek-V4-Pro 在 100 万 token 上下文下相比前代模型单 token 推理 FLOPs 约为 27%KV Cache 约为 10%。这类工作的意义不只是“又一个新模型发布了”。更值得关注的是模型架构开始围绕 KV Cache 做设计。过去大家更多讨论参数规模、benchmark 分数、上下文窗口长度到了长上下文服务阶段缓存成本能不能付得起已经变成模型能否落地的关键约束。当 attention 结构开始为了减少 KV Cache 改造时推理瓶颈已经从“能不能支持长上下文”转向“能不能高效服务长上下文”。Quantization 减少的是权重搬运成本训练需要较高精度推理不一定需要。生产环境里很多模型不会用 FP32 跑推理而是用 FP16 或 BF16。这样可以直接把权重显存占用减半并利用 Tensor Core 提高吞吐。更激进的方案会把权重量化到 INT8甚至 INT4。原文给了一个 7B 模型的直观数字精度7B 模型权重大小FP3228 GBFP1614 GBINT87 GBINT43.5 GBINT4 能让 7B 模型跑在笔记本 GPU 上原因就在这里。当然量化不是免费午餐。位宽越低信息损失越大。GPTQ、AWQ 这类方法会为不同通道选择缩放因子尽量把质量损失压低。做得好时INT4 在很多 benchmark 上只会损失很小一部分效果。工程上量化通常是杠杆很高的优化项。它同时降低权重加载成本、显存占用和服务延迟。推理框架优化的是调度、缓存和内存布局理解 Prefill、Decode 和 KV Cache 后再看 vLLM、TensorRT-LLM、Text Generation Inference 这些服务框架就更容易理解它们在做什么。它们不是简单把generate()包成 API。这些框架主要优化三类问题Continuous batching把多个用户的 token 生成步骤交错到同一张 GPU 上提高利用率Speculative decoding用小模型先草拟 token再让大模型验证减少等待KV Cache 管理更高效地分配、复用和分页缓存避免显存碎片和浪费单个用户看到的是流式输出服务端看到的是一堆请求在同一张 GPU 上抢算力、抢显存、抢内存带宽。高性能推理服务的难点不只是模型结构而是调度、缓存和内存布局。定位慢要先拆 TTFT 和 ITL理解 LLM inference 后优化方向会清楚很多。长 prompt 主要影响 TTFT。用户第一次等得久通常和输入 token 多、检索上下文太长、系统提示词臃肿有关。优化方向是减少 prompt 长度、精简 RAG 上下文、缓存可复用前缀。长输出主要影响 ITL。如果首 token 很快但后续输出慢瓶颈更可能出在 decode 阶段。优化方向是更好的 KV Cache 管理、更高内存带宽、更激进的量化或者使用 speculative decoding。上下文长度也不是免费的。把上下文从 32K 拉到 128K不只是多算几倍 token。KV Cache 会变大batch size 会被挤压并发能力会下降。GPU 利用率也可能误导判断。Prefill 时 GPU 可能很忙Decode 时 GPU 算力利用率可能不高但显存带宽已经卡住。这个时候加更多算力不一定有效减少缓存和改善内存访问才更重要。遇到“模型很慢”时先把问题拆成两类它是慢在开始还是慢在输出这个拆法能直接决定优化方向。结尾把延迟拆开优化才会落到工程上Transformer 架构很重要但线上推理性能经常卡在更具体的环节。Tokenizer 会影响输入长度Prefill 会影响首 tokenDecode 会受显存带宽限制KV Cache 会吃掉上下文扩展的红利Quantization 会改变模型能不能装进显存。落到工程上不要只问“模型为什么慢”。这个问法太粗。更好的排查顺序是输入 token 是不是太多TTFT 是不是太高ITL 是不是太长KV Cache 是不是挤压了显存和并发权重或缓存有没有量化空间serving 框架有没有做好 batching、分页和调度把这些问题拆开LLM 推理优化才会从玄学变成工程。学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%免费】
LLM 推理为什么先慢后快？从 Prefill、Decode 到 KV Cache 讲清楚
LLM 推理的延迟不能只用“快”或“慢”概括。一次回答里至少有两个阶段Prefill和Decode。Prefill 负责处理完整 prompt并生成第一个输出 tokenDecode 负责在第一个 token 之后继续一个 token 一个 token 地生成内容。这两个阶段的瓶颈不一样。Prefill 主要吃 GPU 算力决定用户等多久才能看到第一段文字Decode 主要吃显存带宽和 KV Cache决定文字流出来的间隔有多短。所以优化 LLM 应用前先问清楚延迟发生在哪里。是首 token 出得慢用户提交问题后一直空等还是首 token 已经出来但后续文字像挤牙膏这两种慢对应不同系统瓶颈也对应不同优化手段。Akshay Pachaar 把 LLM inference 的链路讲得比较完整tokenizer、embedding、attention、prefill、decode、KV cache、quantization 都串在了一起。下面按工程视角重新梳理一遍。这张图把推理延迟拆成两块Prefill 是 compute-boundDecode 是 memory-bound。第一 token 慢、后面 token 一粒一粒出来原因就在这里。LLM 为什么只能一个 token 一个 token 写LLM 不是一次性写完整段答案。模型每一步只做一件事根据当前上下文预测下一个 token。预测出来以后这个 token 会被接回上下文模型再继续预测下一个 token。循环不断重复直到生成结束。一次生成可以简化成下面这个过程输入 prompt ↓预测第 1 个 token ↓把第 1 个 token 接回上下文 ↓预测第 2 个 token ↓不断重复理解 LLM 推理关键不是想象模型如何“一次写出答案”而是看清楚每一步如何预测下一个 token以及第一个 token 和后续 token 为什么走的是两种性能路径。Tokenizer 决定模型实际处理多少内容神经网络不直接读取中文或英文。模型看到的是数字。用户输入的文本会先经过 tokenizer被切成一串 token每个 token 对应一个整数 ID。现代 LLM 常用 Byte Pair Encoding 一类方法。它会把高频片段合并成词表里的 token。常见词可能一个 token 就能表示少见词会被拆成多个片段。Tokenizer 会影响成本也会影响延迟。如果某种语言或领域词在 tokenizer 训练数据里覆盖不足同样一句话可能被切成更多 token。token 越多模型要处理的位置越多首 token 等待时间也会变长。这也是为什么“字符数差不多”的两段输入在模型服务里成本可能不一样。模型计费和推理负载看的是 token不是字符数。Embedding 把 token ID 变成语义向量token ID 只是编号还不能直接参与神经网络计算。模型会用 embedding table 把每个 token ID 映射成一个向量。假设词表大小是 50Khidden dimension 是 4096那么 embedding table 的形状就是[50000, 4096]。输入一个 token ID实际就是去表里取一行向量。这些向量会在训练过程中学到语义关系。语义相近的 token 会被推到相近位置。比如king和queen会比较接近python既可能靠近snake也可能在另一个语义方向上靠近javascript。模型还需要知道顺序。Attention 本身不知道哪个 token 在前、哪个 token 在后所以现代模型会用 RoPE 这类位置编码方法让向量携带位置信息。Attention 让每个 token 带着上下文判断向量进入 transformer 层后主要计算开始。一个 LLM 往往有几十层 transformer。每一层大致做两类计算self-attention 混合不同 token 之间的信息feed-forward network 处理每个 token 自己的信息。Self-attention 的关键是 Q、K、V。每个 token 的向量会分别乘上三组权重矩阵得到三个新向量Query我现在要找什么信息Key我这里有什么信息可供匹配Value如果别人需要我我能贡献什么内容Attention 的计算可以这样理解每个 token 用自己的 Query 去匹配所有 token 的 Key再按匹配强度混入对应的 Value。这个机制让 token 不再孤立。代词可以回看前面的人名技术名词可以吸收上下文定义长句后半段也可以引用前半段的信息。Attention 负责搬运上下文feed-forward network 负责继续加工每个位置的表示。几十层堆叠以后模型就能在长上下文里追踪引用、关系和语义依赖。第一个 token 为什么要等经过最后一层 transformer 后模型会取最后一个位置的向量把它投影回词表大小。如果词表有 50K 个 token模型就会得到 50K 个分数。经过 softmax 后这些分数变成概率分布。采样或取最大概率以后下一个 token 才会出来。这一步听起来只是“预测一个词”前面却要先完成整段 prompt 的计算。当 prompt 有 2000 个 token 时每一层 transformer 都要处理这 2000 个 token。好消息是Prefill 阶段可以并行所有 token 的 Q、K、V 可以一起算attention 也可以通过大矩阵乘法完成。GPU 很擅长这种工作负载。大矩阵乘大矩阵正是 GPU 的强项。Prefill 的瓶颈主要是算力也就是 compute-bound。它决定的指标叫TTFTTime To First Token也就是用户提交问题后第一段文字多久才开始出现。长 prompt 会显著增加 TTFT因为模型必须先把所有输入 token 处理完才有资格生成第一个输出 token。后续 token 为什么一粒一粒出来第一个 token 出来以后模型进入 Decode 阶段。Decode 和 Prefill 的工作负载完全不同。生成第 51 个 token 时前 50 个 token 的 Key 和 Value 已经算过而且不会再变化。模型只需要为新 token 计算新的 Q、K、V然后让新 token 去看前面缓存好的 K、V。这个阶段计算量看起来变小了瓶颈却转向显存读写。每生成一个 tokenGPU 都要加载模型权重还要读取已有的 KV Cache。计算本身不大但数据搬运很多。GPU 算力可能空着延迟卡在内存带宽。Decode 决定的指标叫ITLInter-Token Latency也就是相邻两个输出 token 之间隔多久。这就是 Prefill 和 Decode 的关键差异Prefill 是 compute-boundDecode 是 memory-bound。同一个模型、同一张 GPU、同一次请求前后两个阶段的优化方向完全不同。KV Cache 用显存换时间KV Cache 解决的是重复计算。如果没有 KV Cache模型每生成一个新 token都要重新计算整个上下文的 attention。生成越长重复计算越多复杂度会迅速变差。有了 KV Cache模型会把每一层、每个历史 token 的 Key 和 Value 存下来。下一步 decode 时模型直接复用这些缓存只为新 token 计算增量。收益很直接长生成场景里速度可以提升数倍。代价也同样直接KV Cache 吃显存而且会随 token 数线性增长。原文里给了一个估算对 13B 模型来说KV Cache 可能接近每 token 1MB。4K 上下文光缓存就可能占掉约 4GB 显存。长上下文慢不只是模型“想得更多”。更准确地说是缓存变大了显存压力和带宽压力都在变大。常见优化包括把 KV Cache 量化到 INT8 或 INT4使用 sliding window丢掉窗口外的 token用 grouped-query attention 让多个 attention head 共享 K、V像 vLLM 的 PagedAttention 那样把 KV Cache 当成操作系统内存分页管理这些优化看起来底层却直接决定长上下文模型能不能稳定服务用户请求。DeepSeek-V4 的例子长上下文开始围绕缓存设计原文特别提到 DeepSeek-V4因为它把长上下文推理的瓶颈讲得更直观。根据原文引用的技术报告DeepSeek-V4-Pro 在 100 万 token 上下文下相比前代模型单 token 推理 FLOPs 约为 27%KV Cache 约为 10%。这类工作的意义不只是“又一个新模型发布了”。更值得关注的是模型架构开始围绕 KV Cache 做设计。过去大家更多讨论参数规模、benchmark 分数、上下文窗口长度到了长上下文服务阶段缓存成本能不能付得起已经变成模型能否落地的关键约束。当 attention 结构开始为了减少 KV Cache 改造时推理瓶颈已经从“能不能支持长上下文”转向“能不能高效服务长上下文”。Quantization 减少的是权重搬运成本训练需要较高精度推理不一定需要。生产环境里很多模型不会用 FP32 跑推理而是用 FP16 或 BF16。这样可以直接把权重显存占用减半并利用 Tensor Core 提高吞吐。更激进的方案会把权重量化到 INT8甚至 INT4。原文给了一个 7B 模型的直观数字精度7B 模型权重大小FP3228 GBFP1614 GBINT87 GBINT43.5 GBINT4 能让 7B 模型跑在笔记本 GPU 上原因就在这里。当然量化不是免费午餐。位宽越低信息损失越大。GPTQ、AWQ 这类方法会为不同通道选择缩放因子尽量把质量损失压低。做得好时INT4 在很多 benchmark 上只会损失很小一部分效果。工程上量化通常是杠杆很高的优化项。它同时降低权重加载成本、显存占用和服务延迟。推理框架优化的是调度、缓存和内存布局理解 Prefill、Decode 和 KV Cache 后再看 vLLM、TensorRT-LLM、Text Generation Inference 这些服务框架就更容易理解它们在做什么。它们不是简单把generate()包成 API。这些框架主要优化三类问题Continuous batching把多个用户的 token 生成步骤交错到同一张 GPU 上提高利用率Speculative decoding用小模型先草拟 token再让大模型验证减少等待KV Cache 管理更高效地分配、复用和分页缓存避免显存碎片和浪费单个用户看到的是流式输出服务端看到的是一堆请求在同一张 GPU 上抢算力、抢显存、抢内存带宽。高性能推理服务的难点不只是模型结构而是调度、缓存和内存布局。定位慢要先拆 TTFT 和 ITL理解 LLM inference 后优化方向会清楚很多。长 prompt 主要影响 TTFT。用户第一次等得久通常和输入 token 多、检索上下文太长、系统提示词臃肿有关。优化方向是减少 prompt 长度、精简 RAG 上下文、缓存可复用前缀。长输出主要影响 ITL。如果首 token 很快但后续输出慢瓶颈更可能出在 decode 阶段。优化方向是更好的 KV Cache 管理、更高内存带宽、更激进的量化或者使用 speculative decoding。上下文长度也不是免费的。把上下文从 32K 拉到 128K不只是多算几倍 token。KV Cache 会变大batch size 会被挤压并发能力会下降。GPU 利用率也可能误导判断。Prefill 时 GPU 可能很忙Decode 时 GPU 算力利用率可能不高但显存带宽已经卡住。这个时候加更多算力不一定有效减少缓存和改善内存访问才更重要。遇到“模型很慢”时先把问题拆成两类它是慢在开始还是慢在输出这个拆法能直接决定优化方向。结尾把延迟拆开优化才会落到工程上Transformer 架构很重要但线上推理性能经常卡在更具体的环节。Tokenizer 会影响输入长度Prefill 会影响首 tokenDecode 会受显存带宽限制KV Cache 会吃掉上下文扩展的红利Quantization 会改变模型能不能装进显存。落到工程上不要只问“模型为什么慢”。这个问法太粗。更好的排查顺序是输入 token 是不是太多TTFT 是不是太高ITL 是不是太长KV Cache 是不是挤压了显存和并发权重或缓存有没有量化空间serving 框架有没有做好 batching、分页和调度把这些问题拆开LLM 推理优化才会从玄学变成工程。学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%免费】
