开篇你滑动聊天框时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直到模型识别结束符停止输出。整个流程只会执行一次PrefillDecode循环次数等于输出Token总长度减一。二、Prefill预填充一次性读完所有输入的并行计算阶段2.1 生活化类比理解Prefill运行逻辑把推理流程比作考场答题Prefill就是拿到试卷后通读全部题干的过程学生不会逐行读一句思考一句而是一次性扫完整张试卷标记关键信息对应模型一次性加载全部输入Token并行运算。不管输入是一百Token还是一万TokenPrefill都会把所有输入张量同时送入注意力层同步计算不存在串行等待这是Prefill最核心的特性。并行运算过程中模型会为每一个输入Token单独计算Key向量与Value向量全部存储在显存中形成KV缓存这一步是Prefill唯一的写入操作缓存构建完成后模型输出整条请求的第一个TokenPrefill阶段就此结束后续所有文字生成工作交给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共三千TokenPrefill完成后缓存拥有三千条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池可以集中批量处理大量长文本输入压低整体TTFTDecode池持续承载高并发串行生成任务稳定控制TPOT时延同时吞吐量上限大幅提升。该方案适合日活百万级大型AI服务、长上下文Agent平台中小单机部署业务网络传输缓存的开销会抵消性能收益不推荐落地。国内Mooncake、DistServe等开源项目均基于PD分离架构搭建分布式推理集群。6.6 投机解码Speculative Decoding加速Decode阶段降低TPOTDecode访存带宽受限的特性决定单次循环读取完整模型权重的开销固定仅生成单个Token会浪费访存资源投机解码利用这一特性实现多Token并行验证。整体流程分为两步第一步使用轻量化小模型快速一次性预测多个候选Token第二步将全部候选Token送入大模型并行验证一次性完成多条文本的注意力计算保留全部匹配正确的Token舍弃第一个预测错误的候选并重新生成。单次访存开销不变的前提下一轮循环产出多个有效TokenTPOT时延直接降低生成速度提升两到三倍。该优化仅作用于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工程岗必备核心知识也是区分初级部署工程师与资深推理优化专家的关键分水岭。