拆解大模型推理底层双阶段,Prefill与Decode如何决定服务速度与成本
开篇:你滑动聊天框时,GPU正在并行与串行间反复拉扯
打开任意一款AI对话工具发送提问,输入一段上千字的文档让模型总结,你会明显感知到两种截然不同的等待节奏。提交长文本后会有一段空白等待,随后文字像打字机一样逐字弹出,这两种体验背后对应大模型推理完全割裂的两套计算逻辑。很多做AI工程落地的同事初期只会关注模型参数量、显卡显存大小,却忽略推理天然拆分的Prefill预填充与Decode解码阶段,两个阶段硬件瓶颈、算力利用率、优化方向完全相反,几乎所有线上推理卡顿、并发上不去、长文本首字延迟爆炸的问题,根源都藏在这两个阶段的资源冲突里。
前段时间帮企业部署千亿级大模型推理服务,客户反馈两个核心痛点,一是粘贴上万字合同文档提问,首字出现要等两秒以上,用户流失严重,二是并发开到三十人后,所有人回复打字速度明显变慢,GPU显存很快占满。排查过程中我们顺着Prefill和Decode的运行链路逐层拆解,搭配KV缓存调度、批处理策略调整,最终把首Token延迟压缩到三百毫秒内,并发承载量提升三倍。整个调优过程让我意识到,想要真正吃透大模型推理优化,第一步必须抛开各类花哨框架,先把Prefill与Decode底层运行逻辑彻底理顺,所有调度、缓存、硬件分离技术,都是围绕两个阶段的矛盾瓶颈衍生出来的解决方案。
一、先搞懂基础:大模型推理不是一次性输出全文
正式拆解双阶段之前,需要统一几个基础概念,避免后续理解出现断层。
大模型推理指训练完成后的模型接收用户输入,生成对应文本的完整流程,模型不会一次性输出整段回答,而是以Token为最小单位逐一生成,一个Token对应半个汉字或者单个英文单词,日常短句大概十五到二十个Token,一千Token约等于一页A4文档。用户发送一次提问算一条推理请求,线上服务需要同时承载数十上百条请求并行处理,这也是吞吐量指标的由来。
逐Token生成的模式叫做自回归生成,每一个新Token的生成,都需要依赖前面所有输入和已经输出的内容做上下文注意力计算。如果每次生成新Token都重新计算全部历史文本的注意力权重,计算量会随文本长度平方级暴涨,长文本场景下推理速度会降到无法使用,KV缓存就是为了解决重复计算诞生的核心机制,同时它也是Prefill和Decode两个阶段的数据桥梁。
简单概括完整推理链路:用户输入Prompt全部送入Prefill阶段并行计算,生成KV缓存并输出第一个Token,之后进入循环执行的Decode阶段,复用缓存逐一生成剩余所有Token,直到模型识别结束符停止输出。整个流程只会执行一次Prefill,Decode循环次数等于输出Token总长度减一。
二、Prefill预填充:一次性读完所有输入的并行计算阶段
2.1 生活化类比理解Prefill运行逻辑
把推理流程比作考场答题,Prefill就是拿到试卷后通读全部题干的过程,学生不会逐行读一句思考一句,而是一次性扫完整张试卷,标记关键信息,对应模型一次性加载全部输入Token并行运算。不管输入是一百Token还是一万Token,Prefill都会把所有输入张量同时送入注意力层同步计算,不存在串行等待,这是Prefill最核心的特性。
并行运算过程中,模型会为每一个输入Token单独计算Key向量与Value向量,全部存储在显存中形成KV缓存,这一步是Prefill唯一的写入操作,缓存构建完成后,模型输出整条请求的第一个Token,Prefill阶段就此结束,后续所有文字生成工作交给Decode。
2.2 Prefill天生是计算密集型任务,GPU算力拉满
Prefill阶段的核心瓶颈是算力,也就是常说的计算受限,GPU内部的张量计算单元会持续高负载运转,长文本场景下算力利用率能达到百分之九十以上,硬件算力被充分利用。背后原因是并行处理大量Token时,注意力机制执行超大矩阵相乘运算,矩阵运算恰好是GPU最擅长的工作,硬件优势能完全释放。
但这里存在一个极易踩坑的特性,注意力计算复杂度和输入Token长度呈平方关系。输入Token翻倍,注意力计算量会变为四倍,一百Token的输入和两千Token输入,Prefill耗时差距不是二十倍,而是四百倍。这也是粘贴超长文档后首字等待时间急剧拉长的根本原因,大量矩阵运算消耗算力,直接拉高TTFT首Token延迟指标。
2.3 Prefill直接决定用户最敏感的TTFT指标
TTFT全称首Token生成时延,从用户点击发送按钮到第一个文字出现的全部耗时,绝大部分时间消耗在Prefill阶段。短Prompt场景下Prefill毫秒内就能完成,用户几乎感知不到等待,一旦输入上万字长上下文,平方级增长的计算量会直接拉长TTFT,交互体验断崖式下跌。
线上ToC聊天产品对TTFT容忍度极低,行业通用标准是五百毫秒以内,超过一秒用户就会明显感知卡顿,长文档问答、知识库检索类业务,TTFT控制在两秒内才能保证留存。所有针对首字延迟的优化技术,本质都是降低Prefill阶段的无效计算量,或是拆分超大并行任务避免抢占全部GPU资源。
三、Decode解码:逐字输出的串行循环阶段
3.1 串行自回归,每一步只能处理单个Token
延续考场答题的类比,Prefill读完试卷后,Decode就是提笔逐字书写答案的过程,写完一个字才能构思下一个,无法并行批量生成。每一轮Decode循环只处理上一步生成的单个新Token,属于严格串行流程,也就是自回归生成逻辑。
如果没有KV缓存,每一轮生成新Token时模型需要重新计算全部历史输入与输出的K、V向量,海量重复计算会让推理彻底失去可用性。KV缓存的价值在此刻完全体现,Decode阶段不会重新计算历史文本,只会读取Prefill阶段构建好的全部缓存数据,仅计算当前单个新Token的K、V向量,计算完成后把新向量追加写入缓存,每一轮循环缓存长度增加一条记录。
举个直观的数值例子,输入Prompt共三千Token,Prefill完成后缓存拥有三千条K、V数据。第一轮Decode生成第一个输出Token,新增一条缓存,缓存总长度三千零一,第二轮基于三千零一条缓存计算下一个Token,缓存扩充至三千零二,循环往复直到输出结束。
3.2 Decode是访存带宽受限,算力大量闲置
和Prefill完全相反,Decode阶段的瓶颈不在计算,而是GPU显存数据搬运速度,也就是内存带宽受限。单轮循环仅处理单个Token,矩阵运算退化为矩阵乘向量,计算量极小,GPU算力单元利用率常年只有百分之二十到四十,大部分时间处于空闲等待状态。
算力闲置的核心原因是每一轮循环都需要完整读取全部模型权重与持续膨胀的KV缓存,权重与缓存总数据量巨大,显存向计算单元传输数据的速度跟不上计算速度,GPU大部分时间都在等待数据加载,出现“算力空转”的现象。可以类比厨师做菜,每做好一小份菜品都要往返储物间取食材,来回搬运消耗绝大多数时间,切菜烹饪的操作反而耗时很短。
绝大多数推理请求的总耗时都消耗在Decode阶段,哪怕Prefill只占用几百毫秒,几百上千轮串行循环叠加起来,整体等待时间会大幅拉长,这也是行业绝大多数优化方案聚焦Decode阶段的核心原因。
3.3 Decode性能对应TPOT指标,决定流式输出流畅度
TPOT单Token生成时延,也叫Token间隔时延ITL,指首Token生成后,每两个相邻输出文字的间隔时间,直接对应用户肉眼看到的打字速度。TPOT数值越小,文字弹出速度越快,五十毫秒的TPOT对应每秒二十个Token,二十五毫秒则能达到每秒四十个Token,流畅度提升一倍。
批量文档总结、离线生成场景可以适度放宽TPOT标准,但在线实时对话场景,TPOT超过一百毫秒就会出现明显卡顿,用户能清晰感受到文字输出断断续续。同时系统整体吞吐量,也就是单位时间内服务的总Token数量,由Decode阶段的批处理调度能力决定,如何在访存带宽瓶颈下塞进更多并发请求,是提升吞吐量的核心课题。
四、KV缓存:串联Prefill与Decode的核心存储载体
4.1 KV缓存解决的核心矛盾:消除重复注意力计算
大模型注意力机制运行时,每一段文本都会生成Query、Key、Value三组向量,Query向量仅当前计算轮次使用,无需存储,Key和Value向量生成后不会随后续新增Token发生变化,具备永久复用价值。KV缓存把全部历史Token的K、V向量持久保存在显存,避免每一轮Decode重复计算,把整体计算复杂度从文本长度平方级压缩至线性级,是大模型推理能够落地的基础。
抛开KV缓存谈推理优化没有实际意义,没有缓存机制,长文本生成任务耗时会提升数十倍,线上服务完全无法承载并发流量。但缓存存在无法回避的短板,每生成一个Token缓存就扩充一条,上下文越长、并发用户越多,显存占用越高,极端场景下缓存占用会超过模型权重本身,直接触发显存溢出报错。
4.2 缓存完整生命周期:Prefill写入,Decode读写扩容
完整生命周期分为三个阶段,第一阶段Prefill接收全部输入Token,批量计算所有K、V向量,一次性写入缓存,缓存初始长度等于输入文本Token总量,同时产出首Token;第二阶段进入循环Decode,每一轮读取全部存量缓存数据完成注意力计算,生成新Token后计算其K、V向量追加写入缓存;第三阶段请求结束,系统回收该请求占用的全部缓存显存,释放资源供新请求使用。
多条并发请求之间缓存相互独立,普通无优化框架中每条请求占用一段连续显存空间,请求结束前显存无法复用,大量空闲预留空间会造成显存资源浪费,这也是PagedAttention分页缓存技术诞生的背景。
五、Prefill与Decode核心差异全景对比
结合前面的运行逻辑,把两个阶段核心特征整合梳理,能直观看到二者完全对立的运行特性,也是后续所有优化技术分层设计的底层依据。
| 对比维度 | Prefill预填充 | Decode解码 |
|---|---|---|
| 核心工作 | 并行处理全部输入Prompt,构建KV缓存,产出首Token | 串行循环逐一生成输出Token,读写并扩容KV缓存 |
| 执行次数 | 每条请求仅执行一次 | 输出Token数量减一次循环执行 |
| 计算模式 | 多Token并行大矩阵相乘 | 单Token串行矩阵乘向量 |
| 硬件瓶颈 | 算力计算受限 | 显存带宽访存受限 |
| GPU算力利用率 | 百分之九十左右高负载 | 百分之二十至四十低负载 |
| KV缓存操作 | 一次性写入初始化缓存 | 循环读取并追加扩容缓存 |
| 关联性能指标 | TTFT首Token时延 | TPOT单Token时延、系统吞吐量 |
| 资源消耗特征 | 输入文本越长消耗越大,短文本几乎无感知 | 输出越长耗时越高,并发越多显存压力越大 |
两种阶段完全相反的硬件需求,给单卡推理服务带来天然冲突,一条超长Prompt的Prefill并行计算会占满整张显卡算力,正在执行Decode的其他用户请求会被阻塞,流式输出直接卡顿,这也是分块预填充、Prefill-Decode解耦分离架构诞生的业务痛点。
六、面向两大阶段的主流推理优化技术拆解与落地场景
市面上主流推理框架vLLM、SGLang、TensorRT-LLM的优化方案,全部针对性适配Prefill或Decode的瓶颈,部分技术同时改善两个阶段性能,下面结合工程落地经验逐一拆解,区分每种技术解决的问题、适配场景以及对TTFT、TPOT、吞吐量三个指标的影响。
6.1 PagedAttention分页KV缓存:解决显存碎片化,提升并发吞吐量
传统缓存管理会为每条请求分配一段连续固定长度显存,按照最大预设上下文长度预留空间,绝大多数场景下预留空间全程闲置,显存浪费严重,能承载的并发请求数量被大幅压缩。
PagedAttention借鉴操作系统内存分页思路,把显存切割为十六Token固定大小的独立内存块,不提前分配连续大空间,仅在缓存扩容时按需分配小块内存,通过块记录表记录每条请求占用的分散内存块。多条请求存在相同前缀文本时,还能共享同一块物理显存,直接支撑前缀缓存功能。
这项技术不改变Prefill与Decode的计算速度,核心价值是减少显存浪费,单卡可承载并发量提升两到四倍,系统吞吐量显著上涨,是vLLM等开源推理引擎的底层基础,所有线上高并发聊天服务必须开启分页缓存。
6.2 持续批处理Continuous Batching:最大化GPU资源利用率
早期静态批处理会收集一批请求,等待批次内最慢的请求完全结束后,才释放整张批次资源处理下一批,短请求提前完成后对应显存与算力槽位持续空闲,GPU资源大量浪费。
持续批处理放弃固定批次等待机制,每一轮Decode调度都会重新整合可用请求,任意请求生成完毕释放资源后,等待队列中的新请求会立刻填充空闲槽位,保证GPU每一轮循环都满载运行。同时支持Prefill任务和Decode任务混合调度,均衡算力与访存资源占用。
该技术同时优化两个阶段资源利用率,核心收益是系统吞吐量,适用于客服、AI对话等高并发在线场景,离线批量生成场景收益相对有限。搭配分页缓存使用,吞吐量提升幅度能达到三倍以上。
6.3 分块预填充Chunked Prefill:解决长Prompt阻塞全局流式输出
业务中经常出现上万字超长文档输入,一次性完整执行Prefill会占用全部GPU算力,此时所有正在生成回答的Decode请求全部暂停,用户看到文字输出卡顿中断,线上体验极差。
分块预填充会把超长输入拆分为多个小尺寸Token块,分段执行Prefill计算,每完成一个小块,调度器会插入一轮Decode循环处理其他用户的生成任务,交替执行并行计算与串行解码,不会让单条长请求独占全部算力。
这项技术不会减少Prefill总计算量,TTFT不会明显优化,核心作用是保障多用户并发场景下流式输出平滑不间断,知识库长文档问答、本地文件总结类业务必须部署该优化,避免其他用户出现严重卡顿。
6.4 前缀缓存Prefix Caching:复用重复Prompt缓存,压低TTFT
绝大多数线上服务存在大量重复输入前缀,比如统一的系统提示词、固定知识库文档、多轮对话历史上下文,每条请求都会重复执行相同前缀的Prefill计算,造成算力浪费,拉长首Token等待时间。
前缀缓存会持久存储高频共用前缀对应的KV缓存块,新请求到来时先匹配已缓存前缀,匹配成功后直接复用已有缓存,仅对差异化新增文本执行Prefill并行计算,大幅减少需要运算的Token数量,直接缩短TTFT首Token时延。
该优化完全作用于Prefill阶段,缓存命中率越高收益越强,智能客服、企业内部知识库、固定角色对话场景缓存命中率普遍超过百分之八十,首Token延迟可降低一半以上。缺点是缓存会占用额外显存,极低重复输入的零散问答场景收益微弱。
6.5 Prefill-Decode解耦分离部署:两套硬件匹配两类瓶颈
单卡同时承载两类任务永远存在资源冲突,Prefill吃算力、Decode吃显存带宽,无法同时针对两种瓶颈做硬件调优,大规模集群场景下行业普遍采用PD分离架构,搭建独立的Prefill算力池与Decode算力池。
Prefill池选用高FP算力GPU,专门处理全部输入并行计算,生成完整KV缓存后通过高速RDMA网络传输至Decode池;Decode池选用高显存带宽、大容量显存显卡,仅负责循环生成Token,两套集群独立调度,互不抢占资源。
Prefill池可以集中批量处理大量长文本输入,压低整体TTFT,Decode池持续承载高并发串行生成任务,稳定控制TPOT时延,同时吞吐量上限大幅提升。该方案适合日活百万级大型AI服务、长上下文Agent平台,中小单机部署业务网络传输缓存的开销会抵消性能收益,不推荐落地。国内Mooncake、DistServe等开源项目均基于PD分离架构搭建分布式推理集群。
6.6 投机解码Speculative Decoding:加速Decode阶段,降低TPOT
Decode访存带宽受限的特性决定,单次循环读取完整模型权重的开销固定,仅生成单个Token会浪费访存资源,投机解码利用这一特性实现多Token并行验证。
整体流程分为两步,第一步使用轻量化小模型快速一次性预测多个候选Token,第二步将全部候选Token送入大模型并行验证,一次性完成多条文本的注意力计算,保留全部匹配正确的Token,舍弃第一个预测错误的候选并重新生成。单次访存开销不变的前提下,一轮循环产出多个有效Token,TPOT时延直接降低,生成速度提升两到三倍。
该优化仅作用于Decode阶段,不会影响Prefill与TTFT,聊天、代码生成、故事创作等输出长度较长的场景适配性极强,唯一短板是需要额外部署小草稿模型,占用少量显存资源。
七、落地调优实操思路:根据业务场景选择优化组合
不同业务流量特征下,Prefill与Decode的资源压力完全不同,不能套用统一优化方案,结合线上业务分为三类典型场景给出调优思路。
7.1 在线对话、智能客服(短Prompt、多轮交互、高并发)
业务特征:输入Prompt普遍两百Token以内,输出长度两百至五百Token,并发用户数量多,用户对TTFT、TPOT流畅度敏感。
优先部署优化:分页缓存+持续批处理+前缀缓存,小集群无需PD分离。短输入Prefill耗时短,前缀缓存复用系统提示词压低TTFT,持续批处理与分页缓存拉高并发承载量,保障大量用户同时对话不卡顿。
7.2 长文档问答、知识库检索(上万Token输入,中等输出,低并发)
业务特征:输入超长上下文,单次请求Prefill计算量大,并发量不高,但长输入会阻塞其他用户,TTFT压力大。
优先部署优化:分块预填充+前缀缓存,搭配投机解码。分块预填充避免长输入独占算力造成流式卡顿,前缀缓存复用知识库固定文档KV缓存缩短首字等待,投机解码加快长文本输出速度。
7.3 批量文档总结、离线文本生成(超大输出、批量任务,无实时交互)
业务特征:一次性批量提交大量请求,输出Token可达数千,不要求低TTFT,核心追求整体吞吐量。
优先部署优化:持续批处理+分页缓存,关闭前缀缓存节省显存容纳更多并发批量任务,可适度放大批处理尺寸,牺牲少量TPOT换取更高单位时间Token产出。
7.4 百万级日活大型AI平台、Agent长上下文服务
业务特征:混合长短输入,并发量级极高,同时存在大量超长上下文任务,对TTFT、TPOT、吞吐量均有严格SLA要求。
优先部署优化:PD分离解耦集群为基础,叠加分页缓存、持续批处理、分块预填充、前缀缓存、投机解码全套优化,硬件层面Prefill池选用高算力卡,Decode池选用大显存高带宽显卡,通过分布式KV缓存共享进一步降低显存压力。
八、总结:读懂双阶段是推理优化的底层基石
很多AI工程师调参、更换高性能显卡后,推理性能提升有限,本质是没有抓住Prefill与Decode底层对立的瓶颈逻辑。Prefill依靠并行算力处理输入,决定用户等待首字的时长,瓶颈是矩阵计算算力;Decode依靠串行循环生成全文,决定流式输出速度与系统并发上限,瓶颈是显存数据传输带宽,KV缓存作为两者的数据纽带,同时带来显存占用持续膨胀的新问题。
市面上所有推理优化技术,都是针对其中某一个阶段的短板设计,分页缓存解决缓存显存浪费,前缀缓存削减Prefill重复计算,分块预填充平衡两类任务算力争夺,PD分离架构从硬件层面彻底隔离两种瓶颈,投机解码挖掘Decode访存带宽的闲置潜力。
后续学习vLLM、SGLang等推理框架、搭建分布式推理集群、做芯片级推理硬件选型时,都可以用Prefill与Decode双阶段逻辑作为底层分析框架,快速定位延迟高、并发低、显存溢出等线上故障,针对性选择优化方案,避免盲目堆砌硬件造成算力成本浪费。随着长上下文模型、AI Agent大规模落地,Prefill与Decode分层优化会成为AI工程岗必备核心知识,也是区分初级部署工程师与资深推理优化专家的关键分水岭。
