Prefill、Decode 与 KV Cache详细介绍

大语言模型推理产生的延迟没法单纯用快慢两个字简单定义。整个推理流程主要分为两大环节分别是Prefill与Decode。Prefill负责完整接收用户输入的提示词并且产出首个输出字符单元Decode则是在首个字符单元生成完成后逐个接续产出后续内容。这两个环节面临的性能限制完全不一样。Prefill环节极度依赖显卡算力直接决定用户多久能看到第一段回复内容Decode环节更吃显存带宽与KV缓存资源决定了后续文字输出的流畅程度。所以在着手优化大模型相关应用之前一定要先找准延迟出现的具体环节。究竟是首个输出内容迟迟不出用户发送提问后一直处于等待状态还是首个内容正常出现后续文字输出断断续续十分卡顿。这两种卡顿现象对应着完全不同的设备性能短板适配的优化解决办法也各不相同。Akshay Pachaar完整梳理出了大模型推理的全流程逻辑把字符拆分、向量转换、注意力机制、Prefill阶段、Decode阶段、KV缓存、模型量化这些核心环节全部串联起来。接下来从实际工程落地的角度重新梳理一遍整套流程。从这张流程图能清晰看出推理延迟的核心区别Prefill属于算力受限型任务Decode属于内存带宽受限型任务。首个内容加载慢、后续内容输出拖沓根本原因就在于此。很多人好奇大模型为什么只能逐个字符生成内容没办法一次性输出完整回答。其实大模型本身并不具备一次性写完整段回答的能力。模型运行的核心逻辑十分简单每一次运算只会依据现有的全部对话内容预判下一个字符单元预判完成后把这个新字符补充进原有对话内容里再继续预判下一个字符不断循环这个流程直到整段内容生成结束。完整的内容生成流程可以简化为这样想要弄懂大模型推理逻辑不要下意识认为模型是一次性整理出完整答案而是理清它逐字预判的运行逻辑弄明白首个字符和后续字符为何会走两套完全不同的性能运行路径。字符拆分工具直接决定模型实际处理的数据体量人工智能神经网络无法直接识别日常使用的中英文文字。模型识别读取的全部都是数字格式用户输入的文字内容首先会经过字符拆分工具处理被切分成一个个独立字符单元每一个字符单元都会对应专属数字编号。目前主流大模型普遍采用字节对编码这类拆分方式会把日常高频出现的文字片段整合进专属词库常用词汇基本只用一个字符单元就能完成表示生僻字词则会被拆分成多个小片段。字符拆分方式不仅会影响使用成本还会直接造成推理延迟差异。如果某一类语言文字或是专业领域词汇没有大量收录在字符拆分工具的训练数据中同样长度的一句话就会被拆分成更多字符单元。字符单元数量越多模型需要处理的数据位置就越多用户等待首个内容出现的时间自然就会变长。这也是现实使用里两段字数相差不大的文字内容接入模型服务后产生的使用成本却不一样的原因。模型计费标准和推理运行压力全都按照字符单元数量计算和日常统计的文字字符数量没有关系。向量转换把数字编号转化为具备语义的特征向量单纯的字符数字编号没办法直接投入神经网络进行运算处理。模型会借助向量映射表把每一个字符对应的数字编号转换成专属特征向量。举个例子假设词库总容量为50K隐藏层维度数值为4096那对应的向量映射表整体规格就是[50000, 4096]输入一组字符编号本质就是在映射表里调取对应行的特征向量数据。这些特征向量会在模型训练过程中慢慢学习掌握文字之间的语义关联。语义含义相近的字符对应的特征向量位置也会更加贴近。就好比国王和王后的向量距离很近蟒蛇既会和蛇类相关词汇贴近也会在另一层语义中和编程语言相关词汇产生关联。同时模型还需要识别文字排列顺序注意力机制本身无法自主区分文字先后顺序所以当下主流模型都会采用旋转位置编码这类位置标注方式让特征向量自带文字先后顺序信息。注意力机制让每一段文字都能关联全局上下文特征向量进入Transformer网络层之后正式开始核心运算流程。一款成熟的大模型通常搭载数十层Transformer结构每一层结构主要完成两项运算工作自注意力机制负责整合不同文字之间的关联信息前馈网络则单独处理单个文字自带的专属信息。自注意力机制的核心核心就是Q、K、V三组向量。每一个文字对应的特征向量都会分别和三组专属权重矩阵做运算生成三组全新向量查询向量明确当前内容需要调取哪一类相关信息键值向量标注自身内容能够提供哪些可用信息数值向量确定自身内容可以输出的实际信息内容大家可以这样通俗理解注意力机制的运算逻辑每一段文字都用自身的查询向量去匹配全文所有文字的键值向量再根据匹配契合程度融合对应的数值向量内容。依靠这套运行逻辑文字不再是孤立存在的个体。语句里的人称代词可以关联前文出现的人名专业术语能够结合上下文理解具体含义长句后半部分内容也能精准呼应前文表述。注意力机制负责串联整合全篇上下文信息前馈网络则进一步优化完善单个文字的特征表达。经过数十层网络结构层层处理后模型就能在超长对话内容里精准理清文字指代关系、内容逻辑以及各类语义关联。首个输出内容为何会产生等待时长经过最后一层Transformer网络运算结束后模型会提取最后一组位置对应的特征向量再将其转换适配词库容量规格。假设词库一共收录50K个字符单元模型就会生成50K组对应分值经过概率换算后这些分值会转化为字符出现概率最后通过筛选取值确定最终要输出的下一个字符单元。别看最终只是输出单个文字内容在此之前模型必须完成整段用户提示词的全部运算工作。当用户输入的提示词拆分后达到2000个字符单元时每一层网络结构都需要完整处理完这2000组数据。好在Prefill阶段支持并行运算所有字符单元的三组核心向量可以同步计算注意力机制也能依靠大规模矩阵运算快速完成。而大规模矩阵运算刚好是显卡最擅长处理的工作类型。所以Prefill阶段的性能瓶颈集中在算力层面也就是算力受限任务。这个环节对应的核心数据指标是首字符生成耗时简单来说就是用户发送提问后多久能看到第一段回复内容。用户输入的提示内容篇幅越长首字符等待时间就会明显增加毕竟模型必须处理完全部输入内容才能够开始生成回复内容。后续内容为什么会出现输出卡顿首个字符单元成功生成之后模型就正式切换进入Decode运行阶段。Decode阶段和Prefill阶段的运行模式有着天壤之别比如生成第51个字符时前面50个已经生成内容对应的三组核心向量都已经完成运算并且不会再发生变动模型只需要单独为新字符计算全新向量数据再让新字符调取已经缓存好的历史向量数据即可。这个阶段实际运算工作量大幅减少但是性能短板却转移到了数据读取传输上。每生成一个全新字符显卡都需要调取模型权重数据同时读取已经储存好的KV缓存内容。实际运算工作量并不大绝大部分耗时都耗费在数据传输搬运上显卡充足的算力处于闲置状态整体延迟全都卡在显存数据传输速度上。Decode阶段对应的核心数据指标是字符间隔耗时也就是前后两个输出字符之间的间隔时长。这也精准点明了Prefill和Decode两大阶段的本质区别前者受算力限制后者受内存带宽限制。同一套模型、同一张显卡设备、同一次用户请求前后两个阶段适配的优化方向完全不一样。KV缓存依靠占用显存资源换取更快运行速度搭建KV缓存的核心作用就是省去重复无用的运算步骤。如果没有KV缓存机制模型每生成一个新字符都要重新对全部上下文内容完成注意力机制运算生成的内容篇幅越长重复运算量就会成倍上涨整体运行效率会快速下滑。搭配KV缓存之后模型会把每一层网络、每一段历史内容对应的键值向量和数值向量全部储存起来。后续接续生成内容时直接调用已储存的缓存数据只针对新字符完成增量运算即可。带来的实际提升十分直观需要生成长篇内容的场景里整体运行速度能够提升数倍。对应的使用代价也十分明显KV缓存会持续占用显存空间并且占用空间大小会跟着生成字符数量同步上涨。按照业内通用估算标准130亿参数规模的模型单个字符对应的KV缓存占用空间大约接近1MB仅4096长度的上下文内容单单缓存数据就会占用大约4GB显存。长篇内容推理运行缓慢不只是模型需要处理更多信息这么简单更直白的说法就是缓存数据体量变大显存占用压力和数据传输压力都会同步上升。目前市面上主流的实用优化方式主要有这些将KV缓存数据压缩转为INT8或是INT4精度格式采用滑动窗口机制舍弃超出指定范围的历史字符运用分组查询注意力机制让多组注意力结构共用同一套键值向量参考vLLM采用的分页注意力机制仿照电脑内存分页模式管理KV缓存这些看似偏向底层技术的优化手段却是保障长篇上下文模型能够稳定承接用户访问请求的关键。拿DeepSeek-V4模型举例如今长篇上下文模型研发已经开始围绕缓存机制进行整体设计相关技术资料里重点提及了DeepSeek-V4模型这款模型能十分直观体现出长篇上下文推理的性能短板变化。根据公开技术报告数据显示DeepSeek-V4-Pro模型在承接百万级字符长度上下文内容时单次字符推理运算量仅为前代模型的27%KV缓存占用量更是缩减至前代模型的10%。这类新型模型的推出意义早已不止是发布一款全新大模型产品。更值得行业关注的趋势是如今模型整体架构设计已经开始围绕KV缓存机制展开优化调整。早些年行业研发更多聚焦模型参数体量、测评榜单成绩以及上下文支持长度到了实际落地部署服务的阶段缓存资源的使用成本能否控制得住已经成为一款模型能否顺利投入商用落地的核心约束条件。当注意力机制相关结构开始为了缩减KV缓存占用空间进行针对性改造时足以说明大模型推理的性能瓶颈已经从能否支持超长上下文内容逐步转变成如何低成本高效率承接超长上下文服务需求。模型量化技术主要缩减权重数据传输产生的消耗模型训练阶段对数据精度要求极高但是实际推理运行阶段并不需要维持同等高精度标准。在实际项目部署场景中绝大多数模型都不会采用32位浮点精度开展推理工作普遍选用16位浮点或是16位脑浮点精度运行。这样做能够直接把模型权重占用的显存空间缩减一半同时还能借助张量核心进一步提升整体数据处理吞吐量。追求更高运行效率的场景下还能把模型权重压缩转为INT8精度甚至直接压缩至INT4精度使用。INT4量化可以让7B规模的大模型顺利在笔记本独显上运行背后的原理其实很好懂。不过量化技术也存在一定弊端不存在零成本优化。模型使用的位宽数值越低本身丢失的有效信息就会越多。像GPTQ、AWQ这类主流量化方式会针对模型不同通道匹配对应的缩放参数尽可能把模型效果损耗控制在最低。调试到位的情况下INT4量化在绝大多数基准测试场景里只会让模型整体表现出现小幅下滑。从实际开发落地层面来说量化是性价比极高的优化手段既能缩减模型权重的读取加载开销还能减少显存占用同时有效压低模型推理响应耗时。而推理框架主要负责优化任务调度、缓存调用以及内存排布相关工作。弄懂Prefill、Decode和KV Cache这些基础概念后再去了解vLLM、TensorRT-LLM、Text Generation Inference这类线上部署服务框架就能清晰明白它们实际发挥的作用。这类服务框架绝不是简单把原生生成接口封装成通用API这么简单。它们核心主要优化三大实际业务难题Continuous batching将多位用户的文本生成流程交错排布在同一块显卡中运行大幅提升硬件资源利用率Speculative decoding先用小型模型提前生成初步文本内容再交由大模型完成核验修正缩短用户等待时长KV Cache管理合理分配调用资源实现缓存复用与分页存储从根源避免显存资源碎片化以及资源浪费普通用户只能直观看到连贯的流式文字输出而在服务后端大量用户请求会同时抢占同一块显卡的算力、显存以及内存带宽资源。想要搭建流畅稳定的高性能大模型推理服务难点从来都不只是模型自身架构设计更多集中在任务调度、缓存调配和内存布局这些实操环节。日常排查模型运行卡顿问题优先拆分区分TTFT和ITL两项核心指标吃透大模型推理完整流程后后续优化思路自然会变得清晰。过长的输入文本内容主要会拉高TTFT数值。用户启动对话后迟迟看不到首个回复内容大多是输入文本字数过多、RAG检索调取的上下文内容繁杂、预设系统提示词过于冗余导致。对应的优化思路就是精简输入文本、压缩检索上下文内容把能够重复使用的前缀内容提前缓存保存。大量连续文本输出则主要影响ITL表现。如果模型首个文字输出速度很快但是后续内容输出节奏拖沓基本可以确定瓶颈出现在Decode推理阶段。想要改善这类问题可以优化KV Cache调度策略、提升内存带宽、采用深度量化方式或是接入speculative decoding推理方案。扩充模型上下文长度同样需要付出相应代价。单纯把上下文容纳范围从32K提升至128K不只是成倍增加文本计算量还会直接扩大KV Cache占用空间压缩可同时处理的任务数量最终降低整体并发处理能力。另外单凭显卡利用率也无法精准判断运行状态。处于Prefill阶段时显卡算力会处于满负荷运转状态到了Decode阶段显卡算力利用率往往会出现下滑此时真正受限的其实是内存带宽。这种情况下一味提升显卡算力起不到实质作用精简缓存内容、优化内存读写逻辑才是正确解决办法。平时碰到大模型运行速度慢的情况直接划分两种场景判断即可看是启动响应慢还是后续内容输出慢。依靠这个简单判断方式就能快速锁定对应的优化调整方向。只有把整体延迟拆分开逐一分析各项优化操作才能真正落地到实际工程开发当中。Transformer基础架构固然重要但是线上正式环境里大模型推理运行速度往往卡在各类细分实操环节里。文本分词方式会左右整体输入篇幅Prefill流程决定首个内容输出速度Decode流程容易受内存带宽限制KV Cache会稀释扩充上下文带来的使用优势量化方式则直接决定模型能否顺利装入硬件显存。落实到实际项目开发中不要笼统询问模型运行缓慢的原因这种提问方式太过宽泛很难定位问题。整理一套实用的问题排查顺序即可确认输入文本总量是否超标核查TTFT响应耗时是否过高判断ITL内容输出间隔是否过长检查KV Cache是否挤占大量显存限制业务并发评估模型权重与缓存数据是否还有量化优化空间确认部署服务框架是否完善完成批量处理、分页存储以及任务调度工作把这些细节问题逐个梳理排查大模型推理优化就不再是没有依据的经验摸索变成条理清晰、有据可依的标准化工程工作。