这篇论文我前前后后读了三遍。第一遍划重点第二遍对着自己的部署笔记逐段核验第三遍是梳理哪些结论可以直接迁移到我的日常优化工作里。在LLM服务化这个领域大家平时聊得最多的就是两个问题框架怎么选资源怎么省。选型的时候翻文档、跑benchmark、看社区口碑费时费力还不一定全面。这篇文章标题里的“Empirical Study”是我最看重的地方它不是一个框架的广告软文也不是泛泛而谈的设计原则而是把当前主流服务框架放到统一负载下做横向对比结合调度方法、批处理策略、显存管理、推测解码这些关键设计点逐项量化验证。如果你最近正在做LLM服务层的技术选型或者在调服务延迟和吞吐这篇文章值得静下心读一遍。它覆盖的范围很广从框架层到调度层从batch策略到KV Cache管理既适合刚入门想建立全局观的人也适合像我一样已经在生产环境里摸爬滚打过一阵、想对照验证自己经验的人。接下来我把论文的核心内容、关键数据、以及对工程实践最有价值的部分拆开来讲顺便补一些论文里没有展开、但实际部署时你一定用得到的细节。1. 论文到底在讲什么先把大问题说清楚1.1 为什么需要这样一篇实证研究LLM服务化这件事过去两年演化得非常快。从早期粗糙的批处理转发到后来vLLM这类框架提出PagedAttention再到PD分离、Chunked Prefill、投机解码这些进阶手段整个生态的复杂度和分化程度都上了一个量级。但问题是框架和优化手段太多彼此之间的对比数据却非常分散。每个项目都在自己的readme里贴一份benchmark测试负载、显卡型号、量化精度、最大并发全都不一样根本没有办法拿来做横向比较。这是这篇论文出现的第一层动机把主流框架放到同一套评测流程里用一致的负载和指标把它们拉通跑一遍给出可以复用的参考基线。第二层动机是针对系统设计本身的。很多文章只告诉你“PagedAttention对显存更友好”“Continuous Batching能提升吞吐”但没有人系统地回答这些机制在什么条件下收益最大在什么条件下会互相冲突组合使用之后会不会引入新的瓶颈。论文的贡献就是把Framework、Batching、KV Cache、Decoding这些设计维度拆开逐个验证效果边界。第三层动机也是我觉得最贴近实际的一点生产环境的负载模式和学术界常用的静态压测差别很大。真实流量有突发性请求长度分布极不均匀长上下文请求会频繁触发prefill和decode的交错这些都会显著影响框架的实际表现。论文在实验设计上专门加入了这些“wild”因素试图回答不同框架在一个更真实的负载模型下会有怎样的表现差异。1.2 论文回答的几个核心问题读完整篇论文它其实在围绕四个核心问题展开论证。第一个是框架层面的当前主流服务框架在吞吐、延迟、显存占有这几个维度上的真实水平如何彼此之间的差距有多大。这个结论直接影响选型也是大家最关心的部分。第二个是方法层面的调度算法和批处理策略对服务的性能影响到底有多大包括Continuous Batching的收益边界、请求排队策略的作用、以及不同调度方式之间的组合效果。第三个是资源层面的KV Cache管理、显存预留策略、以及量化精度选择这些参数在服务成本里占据的位置到底有多重。论文尝试把这些资源开销量化出来帮读者算清每一笔显存账。第四个是系统设计层面的PD分离、投机解码这类架构级优化在真实负载下究竟能带来多大的收益它们的适用条件是什么是否值得为这些优化付出额外的架构复杂度。这四层问题层层递进从选框架到调参数再到改架构基本覆盖了LLM Serving从起步到优化的完整路径。补充一句论文在回答这些问题的时候采用的是可复现实验的实证方法。所有结论都有测试环境、负载配置、指标定义作为支撑这就意味着你在自己的环境里可以用同样方法重新跑一遍验证这些结论是否适用于你的场景。2. 研究方法与实验设计实证研究到底是怎么做的2.1 研究对象与评测维度论文选取了当前主流的服务框架包括vLLM、TensorRT-LLM、SGLang等几种典型实现加上llama.cpp这类面向轻量级场景的方案作为研究对象。选择这些框架不是因为它们“有名”而是因为它们分别代表了不同的设计路线有的强调调度灵活性比如SGLang的RadixAttention有的强调底层优化比如TensorRT-LLM在NVIDIA GPU上的深度调优有的则走极简部署路线比如llama.cpp。评测维度也覆盖得很全主要分成三类吞吐类指标包括每秒处理请求数、每秒生成Token数用来衡量系统整体处理能力延迟类指标包括TTFT、TPOT、端到端延迟用来评价用户侧的实际体感资源类指标包括显存峰值占用、KV Cache利用率、GPU利用率这部分通常被很多性能评测忽略但恰恰是成本控制最需要的数据。论文同时记录这些维度是为了避免出现“吞吐很高但延迟完全不可接受”这种单项指标过度优化的情况。2.2 负载模型与评测流程负载模型是这篇论文和普通benchmark最大的区别。论文不只用固定长度的输入输出做压测而是模拟了混合负载请求的输入长度和输出长度都分布在一个较宽的区间内还引入了突发流量测试系统在波动负载下的反应。具体流程大概是这样的先确定一组统一的模型权重比如相同规模的通用对话模型确保不同框架跑的是同一个模型排除模型差异的干扰。然后配置一组典型的推理参数包括最大生成长度、温度、采样策略让所有框架都在同样条件下运行。测试过程中记录每一轮的请求延迟和吞吐数据并且在不同并发压力下重复多轮取中位数和分位数作为最终结论的依据。这套流程比较扎实因为很多框架自带的benchmark脚本只测最优场景比如固定batch、固定长度、不考虑排队而这套流程把排队延迟、长尾延迟、突发流量都引入进来了测出来的数据更接近生产环境真实表现。2.3 需要留意的实验边界论文的实验结果是在特定硬件环境、特定模型规模、特定负载分布下得出的。如果你换一个显卡型号或者模型参数量从几十亿跨到几百亿相对结论可能变化不大但绝对值一定有差异。论文的价值更多在于揭示趋势和机制而不是给你一份可以直接照抄的数字表。它的真正用法是提供一个方法论框架照着论文的评测流程在自己环境和业务负载上重跑一遍得到自己的基线数据。建议读论文里的性能表时不要盯着具体数字看排名而是看差距的倍数关系和变化趋势。比如某个框架在长上下文场景下延迟增长了数倍这种趋势性的结论在跨硬件迁移时依然有参考价值。3. 核心发现框架差距、瓶颈分布与资源账本3.1 框架之间的真实性能分层论文的执行结果验证了一个我在实践中也有同感的判断框架之间的性能差距在实际使用场景下远比在厂商preset benchmark里看到的小。所有主流框架在静态最优负载下都能跑到不错的吞吐值差距通常在10%到30%之间。这个幅度的差距在选型决策里不应该占主导地位因为你通过调整部署参数和调度策略完全可以弥补这部分差距。但这不意味着框架没有差别。差别主要体现在几个特定场景上一个是高度动态的负载下调度策略更灵活、Prefill和Decode处理更协调的框架优势明显吞吐差距被拉大到接近一倍另一个是长上下文场景KV Cache管理效率直接决定了你能支撑多大的并发这方面不同框架的量级差距会在高并发下被放大。所以框架选型的正确思路是先明确你的负载特征再判断哪个框架在对应场景下有结构性优势而不是单看benchmark数字。3.2 延迟到底被消耗在哪些环节论文对延迟的拆解比较细它把一次请求的完整时间链路划分成几个阶段包括排队等待时间、预填充时间、逐Token生成时间以及调度开销。拆开之后能看到一个非常关键的现象在中等以上负载下排队时间经常占掉端到端延迟的40%以上有时候甚至超过一半。这其实暴露了一个经常被忽略的问题很多人优化延迟把注意力全放在TTFT和TPOT上却忘了在并发压力下请求在进入执行引擎之前就已经在队列里等了很久。这就像你优化了收银台的结账速度但顾客排队排到了门外体感提升依然有限。对应到工程实践这个发现意味着延迟优化必须同时考虑排队策略。比如是否启用请求优先级队列长请求和短请求混跑时是否需要做抢占负载超过一定阈值时应该用限流还是扩容这些决策对延迟的影响不亚于框架本身的执行效率。3.3 显存与吞吐的真实账本显存占用是论文里让我觉得最有价值的数据之一。它明确展示了KV Cache在不同框架里的消耗差异同样模型、同样并发下有的框架KV Cache稀疏复用得比较好显存占用平稳有的框架会产生大量碎片显存峰值明显偏高。这个差异在长上下文的场景下被特别放大因为上下文越长KV Cache占比越高显存管理的效率直接影响最大并发数。另外一个值得关注的数据是预填充阶段的显存峰值。论文显示即使引入了分块预填充这类优化手段prefill阶段仍然会产生显著的显存尖峰和decode阶段交错在一起的时候容易造成瞬时显存压力过大。这里我补充一个实操经验如果你在部署时发现偶发的OOM或显存不足不要只盯着KV Cache的预留值还要看prefill阶段是否出现了瞬时尖峰。很多框架是允许配置prefill和decode的并发策略的把这个参数调好对整体稳定性很有帮助。4. 关键技术点深挖论文里最值得反复读的几页4.1 PD分离把预填充和生成拆开看PD分离是论文中系统设计部分的一个重要主题也是最值得工程化尝试的方向之一。它的核心思路是改变单个请求内部两个阶段必须绑定在一台机器上串行执行的约束把Prefill阶段和Decode阶段拆开由不同的实例来执行。Prefill阶段计算密集需要大量并行计算适合用高算力实例一次性处理Decode阶段是访存密集显存带宽和KV Cache容量更关键适合用资源配比不同的实例来处理。论文通过实验验证了PD分离在特定负载下的收益当请求包含大量长上下文时PD分离能显著降低TTFT同时对整体吞吐也有正向贡献。这个结果符合我的判断因为长Prefill会长时间占用GPU算力导致decode请求排队拆开之后两类请求可以并行推进互不争抢。但论文同时也指出PD分离并不是银弹。它引入了跨节点通信需要用一个调度器统一协调Prefill实例和Decode实例之间的数据传输这部分的调度开销和网络时延需要足够小否则收益会被抵消。4.2 KV Cache管理策略的演进论文对KV Cache管理花了不少篇幅这并不令人意外。KV Cache是LLM Serving显存成本的最主要来源也是几乎所有的性能优化都会触碰到底层机制。早期做法是静态分配每个请求预留最大可能长度的KV Cache简单但浪费严重显存利用率低。PagedAttention是第一个把显存管理从“连续大块预留”变成“按需分页分配”的方案它把KV Cache拆成固定大小的块按需分配给请求显著降低了预留给KV Cache的浪费空间。论文在验证这个机制时特别提到它在长上下文和并发较高的场景下提升非常明显显存利用率可以提高一倍以上。和KV Cache管理相关的另一个机制是Prefix Caching或者叫RadixAttention。如果多条请求共享同一段公共前缀比如同一个System Prompt框架可以复用这部分KV Cache避免重复计算。论文实验显示在Prompt前缀高度共享的场景下这个机制能显著降低TTFT吞吐收益也相当可观甚至可以达到成倍的差距。但是请注意它依赖请求前缀的命中率。如果你业务里的Prompt多变、公共前缀很短这个机制的收益会大幅缩水。4.3 动态批处理与投机解码的组合拳动态批处理是当前所有高性能框架的标配论文对它做了一组专门的对比实验。结论其实也比较符合预期在短请求和动态负载场景下动态批处理对吞吐的提升最明显可以看出明显的性能跨度但在请求长度非常均匀、负载时间又很长的静态场景下传统静态批处理和动态批处理的差距会缩小这也说明动态批处理的核心价值在于应对不确定性。投机解码是论文另一个重点分析的对象。它的工作原理是用一个小模型快速生成多个候选Token然后用大模型并行验证这些候选。验证时一次前向传播的耗时和生成单个Token差不多但一次可以验证多个Token所以如果小模型预测足够准确就能大幅减少大模型的解码步数从而降低延迟、提升吞吐。论文对投机解码的实验结果比很多人预期的要“冷静一些”。它在简单任务上表现不错能提升接近一倍以上的解码速度在复杂推理任务上收益就显著下降因为小模型经常预测错误导致大模型经常需要回退重新验证额外消耗了算力。所以我的建议是如果你的业务大部分请求都是代码生成、摘要生成这类局部规律明显的任务投机解码值得部署如果你的请求普遍是长链推理、数学逻辑这类对模型能力要求很高的任务那需要先在业务数据上做一轮验证再决定要不要开启这个功能。5. 论文给工程实践的意见从论文结论到生产环境5.1 选型时应该问自己的五个问题读完整篇论文我印象最深的不是某一个具体数据而是它反复强调的一个思路服务性能和业务负载特征强相关没有脱离场景的最佳框架。基于这个前提我整理了一份在选型之前需要回答清楚的问题清单。第一个问题是我最常见的流量形态是什么。短对话为主还是长文档分析为主ELI动态负载还是固定QPS这两个方向的差异决定了KV Cache管理和批处理策略的重要性排序。如果你的流量形态从来都是短输入短输出那KV Cache的优化收益会被明显削弱后续也不需要为它投入太多精力。第二个问题是系统瓶颈感不敏感。如果是面向C端用户的应用排队时间的增加对体验的影响非常直接如果是离线批处理任务整体吞吐反而是更重要的核心指标。延迟敏感方向应该优先考虑调度延迟更短的方案吞吐优先方向应该容忍一定的排队时间以最大化资源利用。第三个问题是显存边界在哪里。当前推理只用一张卡还是已经需要多卡推理或者考虑把显存池化这个问题的答案决定了你是否需要框架在KV Cache压缩、PD分离上提供更好的支持。第四个问题是你对框架生态的要求程度。比如是否需要支持某类量化算法是否需要和已有的监控体系对接这些看似外围的生态问题在长期运维中往往比框架峰值性能更重要。最后一个问题是团队对复杂度的承受能力。有的框架性能好但引入了额外的组件比如单独的调度器、单独的PD实例部署和排查问题的难度都会上升。如果团队人手有限选一个性能稍差一点但架构简单的方案长期来看可能反而更划算。5.2 从论文结论落地的压测方法论文给了很好的评测思路但落地到自己的环境里还需要细化。我强烈建议你照着论文的负载设计搭建一套自己的压测脚本周期性地跑回归测试。这样做可以在框架升级、配置变更之后第一时间知道引入了哪些性能变化。具体来说压测脚本需要覆盖三个压测维度。第一是固定QPS下的延迟测试持续压一段时间观察平均延迟和P99延迟是否平稳第二是突发流量测试从低并发瞬间拉升到高并发观察延迟恶化和恢复的时间第三是混合场景测试同时打短请求和长请求观察长短请求互相影响的程度。这些测试产生的基线数据应该在每次架构调整后重新记录形成你自己的性能基线库。我们团队在实际执行中还发现一个点压测时要特别注意把监控数据一起采集下来。只记录客户端延迟是不够的还要同时记录GPU利用率和显存占用。不然你只知道变慢了不知道是卡上算力不够还是显存瓶颈导致调度器在排队。5.3 部署时容易踩的坑第一个坑是照搬官方推荐的KV Cache配置。论文里KV Cache相关的实验说明了不同负载下显存利用率的巨大差异如果你直接照搬默认配置在长上下文场景下可能频繁触达显存上限而短场景下又浪费了大量显存。建议根据自身请求长度分布动态调整KV Cache的预留策略没有固定的所谓“最佳值”。第二个坑是忽略了prefill和decode的资源争抢。论文对prefill阶段的计算特性做了详细分析这部分在推理引擎里其实非常关键。如果prefill请求很长decode阶段的吞吐会明显下降两个阶段互相抢占GPU资源最终导致两者性能同时受损。这个问题的解决办法要么是启用模型框架的prefill调度优化要么就控制长Prompt请求的比例要么考虑PD分离。第三个坑是低估了Prompt前缀带来的重复计算。很多团队在做服务化改造时会把System Prompt拼到每个请求里但这会导致每一个请求都重复计算同一个前缀的KV Cache。论文里关于Prefix Caching的实验很清楚地点出了这个问题。更合理的做法是启用框架的前缀缓存或者通过API层把频繁使用的Prompt统一管理让同一个前缀尽可能被多个请求复用。6. 一些读论文时个人很受用的整理和思考6.1 每一章该怎么读这是整篇论文比较大的一个亮点它的章节组织非常清晰可以作为一篇完整的LLM Serving工程手册来阅读。如果你是初学者建议从实验设计的部分读起先把负载模型和各指标定义弄清楚再去看性能数据部分否则很容易被表格里的数字带跑。如果你已经在做实际部署直接跳到系统设计的几个章节PD分离、Prefix Caching、投机解码这几节值得反复读它们给出的实验条件和结论边界可以帮助你判断这些优化点是否值得引入自己的系统。如果你是在做长期运维工作建议把这篇文章的评测方法整理成文档沉淀到团队内部作为回归测试的参考依据。性能基准这件事不同团队、不同业务之间差异很大能复现的测量方法比结论本身更有价值。6.2 论文之外我觉得后续值得继续探索的方向论文把当前的主流框架和优化方法做了一个非常扎实的横向对比但LLM Serving这个领域演进得太快。我读完这篇文章之后也在思考后续值得进一步深入的方向。其中一个方向是多模型混合场景下的调度策略。论文的实验主要围绕单模型服务展开但实际生产环境里一个推理集群部署多个模型的情况已经很常见了。当不同模型共享GPU集群时模型间的调度、抢占、隔离策略会引入新的问题。论文提出的评测方法可以扩展到这个场景回答“多模型共存时显存如何切分、调度如何协调”这些问题。另一个方向是自适应调度策略。当前动态批处理已经能根据队列情况动态组合请求但主要还是基于简单规则。如果引入更复杂的预测机制对请求的输出长度做预判再动态决定是否开启动态批处理组合这或许能进一步压缩延迟。这已经超出了纯serving系统设计的范畴涉及机器学习预测辅助推理但如果做实了对生产环境的价值会非常大。6.3 我在自己环境里复现实验的一些补充经验读论文最大的收获之一是它的评测流程可以直接复用。我在自己的测试环境里跟着论文的方法跑了一遍发现几个论文里没有直接展开但实践上值得注意的细节。首先是预热时间问题。每次跑基准测试之前需要先跑一段热身请求让框架把CUDA内核加载、显存分配等相关的初始化工作完成。如果跳过这一步前几个请求的耗时数据会非常离群直接拉高整体平均延迟。其次是结果统计方式我建议同时记录中位数和P99避免算术平均被长尾请求干扰。其次是显存统计数据不要只盯峰值。峰值反映的是最坏情况但平时的基线占用和波动幅度同样重要需要在监控指标里一并看。最后是显卡温度对结果的影响不容忽视。长时间压测会让显卡温度上升可能触发降频导致后半段结果变差。所以正式压测前确定好显卡散热情况测完后也要看一眼温度数据是否一致。这些细节看起来琐碎但决定了你压测数据的可信度也决定了你基于数据做选型和调优判断的可靠性。我在实际运维中最大的体会是LLM Serving的优化很少有一步到位的方案它更像一个不断逼近的过程。论文给了你一张比较清晰的“地图”告诉你各个优化手段分布在什么位置、收益有多大、边界在哪里。但最终每条路要怎么走还是得靠你在自己的负载和资源条件下一步步试出来。这篇文章适合作为案头参考每隔一段时间重读一遍往往会有新的体会。