前言你有没有想过当你和ChatGPT、Kimi这些大模型聊天时为什么它能几乎“秒回”为了这短暂的一两秒流畅体验背后究竟付出了多大的代价今天我们来揭露一个大厂不太会主动告诉你的事实大语言模型LLM在实际服务中看起来很强大但背后浪费了很多算力。为了让你不觉得AI回消息卡顿公司只能让昂贵的GPU浪费一半以上的算力然后用更多显卡来硬撑用户量。一、延迟要求很严格用户体验的“及格线”用户发一个请求比如让AI写邮件、回答问题必须在很短的时间内例如1秒内开始一个字一个字地输出。不能等太久。这背后有两个核心指标直接决定了你“爽不爽”TTFT首字延迟你点下发送后多久看到第一个字如果超过1秒你就会觉得“卡了”甚至以为AI死机了。TPOT / TBT字间间隔生成过程中每个字蹦出来的间隔。如果一顿一顿的读得比AI生成还快体验就很糟糕。TTFT决定“第一印象”TPOT决定“整体体验”。工业界通常把这两个指标限制在TTFT 200msTPOT 50ms作为服务等级目标SLO。SLO就是“用户体验的量化及格线”——只有同时满足这两个条件的请求才算真正有效的吞吐量。这就是Goodput有效吞吐量的概念Goodput 满足TTFT 目标值 AND TPOT 目标值的请求数量举个例子系统1秒完成了10个请求原始吞吐10 req/s但只有3个请求同时满足TTFT≤200ms且TPOT≤50ms那么Goodput 3 req/s。Throughput是“系统觉得自己多努力”Goodput是“用户觉得你多有用”。那个宣传中漂亮的“每秒10万token”总吞吐量在用户体验面前只是个幻觉。二、为了快GPU只能“闲着”GPU其实可以一下处理很多请求高吞吐量但如果同时处理太多每个用户都要排队等待延迟就会变高。为了保证快企业只能让GPU只用到30%–50%的能力剩下的算力空转。为什么为了“快”反而要让GPU闲着这背后的根本原因是GPU的计算特性与LLM生成文本的方式自回归解码不匹配。LLM生成是一个接一个的串行过程要生成“Hello world”模型先算“Hello”然后基于“Hello”再算“world”。每个词的计算不能并行因为后面的词依赖前面输出的词。GPU最擅长“同时算很多独立的事情”GPU有几千个小核心适合同时做大量互不依赖的数学计算。但LLM的每一步生成都要等上一步的结果——这是天然串行的瓶颈。一旦同时服务很多用户就会排队假设GPU一次只能同时算4个请求但你来了10个用户剩下6个就得排队。队列越长首字延迟就越长。为什么不能一次处理更多用户因为GPU显存有限。每多服务一个用户就要多存一份这个用户的“对话状态”KV Cache。用户太多→显存爆了。而且同时算太多用户每个用户分到的算力变少生成速度反而变慢。结论企业会设定每个用户的首字延迟必须小于比如500ms。测试发现同时处理100个用户时新请求要等2秒→超标降到30个用户时几乎不用等→达标。但GPU同时只能跑30个用户时它的计算资源只用到30–50%——剩下资源不是故意浪费而是不能用来服务更多用户否则大家一起慢。一句话比喻GPU像是一个只能同时倒几杯饮料的机器人如果要给更多人倒大家就得排队等。为了保证你1秒内就能拿到第一口机器人宁愿闲着也不敢收太多订单。三、Prefill与Decode的“抢道”冲突LLM生成一个回答分为两个完全不同的阶段阶段一Prefill预填充你在做什么用户输入一段很长的prompt比如1000字的邮件背景模型在做什么一次性把这段文字全部“读完”计算出初始的理解硬件特点计算密集型→ 疯狂使用GPU的Tensor CoreGPU算得冒烟利用率极高阶段二Decode解码你在做什么模型一个字一个字输出“您好…感谢…”模型在做什么每生成一个字都要回头读一下之前生成的所有字的“记忆”KV Cache硬件特点内存带宽密集型→ 计算其实很简单但需要飞快地从显存里读大量数据计算单元闲着但显存通道被挤爆矛盾在哪阶段要什么GPU状态Prefill算得快计算单元累死Decode读得快计算单元闲置显存通道紧张它们需要的硬件资源完全不同。就像Prefill 搬砖工人需要肌肉Decode 图书管理员需要跑得快但不需要多大力气混合调度的灾难如果同时把两类任务放进同一个batch一个长Prefill进来 → 它会霸占所有计算单元很长时间几毫秒到几十毫秒在这期间所有正在Decode的请求被迫排队无法读取下一轮的KV Cache结果Decode的每个token间隔TPOT突然变大用户感觉输出卡一下然后突然蹦几个字再卡一下比喻一个收费站。Prefill大货车过秤要10分钟霸占整个秤Decode小轿车只需1秒刷卡。如果混着排队货车一进来后面所有小轿车干等10分钟。不是秤不够快而是混在一起造成的排队等待。四、为什么Prefill天生就慢O(S²) vs O(S)你可能会问生成token也要载入之前运算的KV Cache为什么Prefill反而更长核心答案Prefill真正的耗时大头不是读而是暴力计算所有token两两之间的注意力分值。在Transformer的每一层内部Prefill阶段输入有S个token比如1000这一层要计算所有token两两之间的注意力 → 计算量 ≈S²1000×1000 1e6次Decode阶段每生成一个新token只需要计算新token和之前所有token之间的注意力 → 计算量 ≈S1000次当S1000时Prefill的单层计算量是Decode的1000倍。当S2000时差距扩大到2000倍。KV Cache只省了K、V的计算省不了Q·K^T的矩阵乘法次数。结论所有请求都流经所有层但Prefill在每一层内部要做S²次注意力计算而Decode只做S次。当输入很长比如几千token这个平方关系就是冲突的根源。五、Batch同步机制为什么Decode必须等一次回答中Prefill只填充一次为什么还会反复冲突关键点GPU不是一次只服务你一个人。真实生产环境是GPU同时服务几百个用户每个用户处于不同的进度。举例说明冲突时间点用户A用户B用户CT0ms刚发来请求需要Prefill已在Decode第5个token已在Decode第12个tokenT10ms还在Prefill需50ms要生成第6个token要生成第13个tokenT20ms还在Prefill等A算完等A算完T50msPrefill完成终于能生成第6个token终于能生成第13个token用户B和C的Decode被迫从10ms/token变成了50ms/token。为什么不能“让A单独Prefill其他人继续Decode”因为GPU的batch机制一个batch里的所有请求必须同步地逐层计算。把GPU想象成一辆公交车每个乘客请求要依次经过N个车站N层网络公交车必须等所有乘客都上完当前这站才能开往下一站比喻100个学生请求99个已经做完了加法Decode某层等着学乘法下一层1个还在学加法Prefill这一层。老师GPU只能等那1个学完加法才能一起教乘法。那99个学生虽然早就学会了加法但必须干等。等待不是因为读KV Cache慢而是因为Prefill在每一层霸占时间过长导致Decode无法进入下一层被迫空转。六、解决方案的三代演进为了解决Prefill与Decode的冲突业界经历三代技术革新第一代Chunked Prefill分块预填充通俗解释不让推土机Prefill一口气干完。把它要推的土分成100车推一车就让小轿车Decode跑一会儿再推一车再让小轿车跑一会儿。优缺点优点只需要一张显卡成本低缺点TTFT变差用户看到第一个字的速度变慢TPOT一般仍有微小卡顿定位小规模部署的无奈之选个人开发者或小公司显卡不够时的凑合用。第二代Inter-GPU Disaggregation跨GPU分离通俗解释修两条路。一条高速路只跑推土机Prefill一条专用路只跑小轿车Decode中间用传送带高速网络传输结果。优缺点优点TTFT和TPOT都做到极致用户体验无敌缺点成本极高双倍GPU昂贵传输网络定位超大规模集群的昂贵方案像ChatGPT这种级别为了全球用户体验砸钱做的。第三代Intra-GPU SM Logic SeparationGPU内逻辑分离通俗解释不修两条路了而是把一条路单个GPU画上不同颜色的车道拿出一小部分车道例如20%的SM单元专门给小轿车Decode跑保证它永远不堵拿出大部分车道80%给推土机Prefill跑这两类车在物理上被隔离互相看不见也就不会互相撞车核心机制空分复用vs 时分复用时分复用轮流执行会有排队等待空分复用同时执行没有等待三大核心技术无气泡执行引擎将层同步阻塞从几十毫秒压缩到微秒级人完全无感资源竞争评估器离线建模在线预测提前避开高速缓存和显存的拥堵点SLO感知动态调度毫秒级调整车道宽度——Decode任务少时临时借更多SM给PrefillDecode一多立刻锁回优缺点优点达到接近第二代的低延迟成本仅略高于第一代零网络传输开销缺点实现极其复杂需要深入GPU微架构魔改底层驱动定位2026年的高效能标准最优解——用一张卡的配置打出两张卡的体验降本增效的终极武器。三代方案对比表方案隔离效果通信成本配置灵活性Goodput成本传统混合批处理极差极低强耦合低低Chunked Prefill中等偏高强耦合中低跨GPU物理分离极好极高完全独立极高极高GPU内SM逻辑分离极好极低逻辑独立极高中七、落地挑战为什么不是今天就能随便用的坏消息工程挑战巨大内核级改造CUDA/MPS需要绕过甚至改写GPU的底层驱动程序不是普通应用层工程师能搞定的动态Profiling开销需要为“什么模型什么显卡”的组合建立精准的“拥堵预测模型”工作量巨大好消息部署优势无与伦比打破KV Cache内存墙Prefill和Decode在同一张卡的显存里传递KV Cache像从左手递到右手零成本直接共享内存自适应弹性吞吐当Decode任务少的时候动态地把专用车道临时征用给Prefill等Decode任务多了再还回去——没有一丝算力闲置谁最需要云服务提供商在同一张卡上安全混跑“延迟敏感的交互式应用”和“吞吐优先的离线任务”把一张卡的价值榨干AI初创企业用少得多的显卡提供接近大厂的流畅体验八、KV Cache到底存在哪每次和LLM的对话KV Cache一直存在GPU中吗答案不一定。取决于系统和场景。通常不会“一直”存在而是为了性能会“尽量”保留。理想情况为了极致性能一直存在GPU显存中对于一个正在进行的连续对话每一轮系统都会把KV Cache继续保留在GPU显存里。下一轮直接读取只需计算新消息的部分——速度快得飞起。存在时间从对话开始到对话结束或超时被清理。现实情况为了节省显存不一定一直存在GPU显存非常昂贵。如果服务器同时服务成千上万的用户每个用户的对话都一直霸占着显存显存会瞬间爆掉。策略做法KV Cache还在GPU吗交换Swap用户暂时不说话时搬到CPU内存或SSD❌ 不在回收Evict对话太长扔掉最早的那几轮❌ 部分不在需时重算超时清理用户30分钟没说话清空❌ 不在不同架构的差别架构KV Cache位置特点单GPU服务该GPU的显存简单高效跨GPU分离第二代Prefill阶段在一组GPU传输后保存在Decode组的GPU需要高速网络搬运GPU内SM逻辑分离第三代同一张GPU的显存被Prefill和Decode共享访问零拷贝最快KV Cache会一直增长每一轮对话KV Cache都会变长第1轮你50字AI200字 Cache存250字第2轮再问20字AI回300字 Cache变成570字第10轮Cache可能长达几千甚至上万字KV Cache越长占用的GPU显存越大后续计算的代价也越大。这就是为什么长对话会变慢、变贵。一句话总结KV Cache在GPU里存在的时间 “用户正在对话 显存足够”的时间。为了省显存系统会把它换出到CPU甚至丢掉——这是“省显存”和“保速度”之间的经典权衡。九、1M超长上下文的秘密现在LLM都宣称1M上下文了是把每次对话的KV Cache数据放到非GPU内存用的时候再调入是的这正是当前实现百万级超长上下文的核心技术路径之一。但整个流程远比“用的时候再调入”复杂得多。路径一KV Cache卸载Offloading当GPU显存放不下完整的KV Cache时系统自动将暂时用不到的那部分缓存搬到CPU内存上。代价CPU内存的带宽约200 GB/s远低于GPU显存可达8 TB/s速度相差40倍。会带来一定延迟增加TTFT增加10-50%。路径二KV Cache压缩与其频繁搬运庞大的数据不如在源头就把数据变小。主要手段量化使用FP8甚至更低精度存储KV Cache直接砍掉一半体积架构革新设计新的注意力机制。例如DeepSeek采用CSA/HCA混合稀疏注意力将KV Cache压缩到10%Kimi Linear通过线性注意力机制减少75%结果1M上下文的KV Cache需求从理论上的84GB以上被压缩到5.8GB单卡运行长上下文成为可能。路径三分层存储与智能调度构建多级存储体系L1最快GPU显存L2较慢CPU内存L3最慢但大NVMe固态硬盘智能预取系统预测“接下来可能会用到哪些历史数据”在GPU还在处理当前token时就提前将未来的KV Cache从CPU内存甚至SSD加载到GPU显存中。这种“用计算掩盖IO延迟”的方式使得从CPU内存读取缓存的体验在很多情况下接近于直接从GPU显存读取。一句话总结1M上下文从实验室Demo变成可日常使用的功能靠的是——使劲压缩让数据变小 多级缓存把最常用的留在最快介质上 预读在你用到之前准备好。十、谁在推动这些技术核心受益者云服务提供商如AWS、阿里云他们买来一堆GPU切成小块卖给无数用户。第三代方案让他们在同一张卡上安全混跑不同任务把一张卡的价值榨干。AI初创企业他们没钱买几千张H100来做“跨GPU分离”。第三代方案让他们用少得多的显卡提供接近大厂的流畅体验。技术落地现状第一代Chunked Prefill已经广泛应用用户只需在启动命令里加--enable-chunked-prefill参数第二代跨GPU分离头部大厂在用成本极高第三代GPU内SM逻辑分离主要停留在头部大厂和顶尖研究机构的实验室被称为“2026年的高效能标准”结语今天为了让你不觉得AI回复卡顿云厂商不得不让GPU的空闲率高达50%以上然后用“多买几倍显卡”的暴力方式硬撑用户量。但随着第三代方案GPU内SM逻辑分离、KV Cache压缩、分层预取等技术的成熟我们正走向一个既不卡顿、也不浪费的未来。三代演进的核心逻辑第一代时间换空间软件妥协第二代空间换时间硬件堆叠第三代精细化管理软硬协同下一次你感慨AI“秒回”的时候不妨想一想背后那些被榨干的、以及曾经被浪费的算力——它们正在被工程师们一寸一寸地拯救回来。本文整理自对LLM推理调度、Goodput指标、Prefill/Decode冲突、Batch同步机制、KV Cache管理及三代架构演进的深度讨论。参考资料