真正的 LLM 推理优化，不是更快，而是更会分工

你以为瓶颈在算力，其实瓶颈在“混在一起”

如果一个系统里，最慢的部分不是某个算法，而是把两种完全不同的工作硬塞在同一块 GPU 上，那问题就不再只是优化，而是架构设计。很多人谈 LLM 推理时，第一反应是提高吞吐、减少显存、压缩 KV Cache，仿佛只要把硬件榨干，性能就会自然上去。但真正决定体验的，往往是两个指标：TTFT，也就是首 token 延迟，以及 TPOT，也就是每个 token 的生成时间。

这两个指标之所以顽固，不是因为模型不会算，而是因为推理过程本身就不是一个单一任务。它更像一家餐厅里的两种工种：前厅要快速接单、备菜、出第一口热菜，后厨则要稳定、持续、批量地出餐。如果让同一个厨师既接电话又炒菜，结果往往不是更高效，而是双方都被拖慢。LLM 推理里最核心的张力，正是预填充阶段和解码阶段之间的冲突。

预填充阶段像是一次性把整道菜的食材处理完，计算密集，适合大批量并行。解码阶段像是每次只往前续一口，内存访问和状态管理更关键，延迟更敏感。把两者混在一起，会让“快启动”和“稳持续”互相掣肘。于是，一个更深的问题浮现出来：当一个系统同时追求低延迟和高吞吐时，究竟应该优化单点性能，还是重新定义工作如何被分配？

---

把预填充和解码分开，本质上是在分开两种时间逻辑

如果把 LLM 推理看成流水线，就会发现最容易被忽视的，不是算子，而是时间结构。预填充和解码之所以应该分离，不只是因为它们“性质不同”，而是因为它们遵循两套完全不同的时间逻辑。

预填充阶段的目标是快速建立上下文表示。它偏向计算密集，适合较大的 batch，越多请求同时进来，GPU 的矩阵计算越能摊薄开销。解码阶段则是逐 token 生成，单次计算小，但需要频繁访问 KV Cache，受内存容量和访存效率约束更大。前者像装货，后者像送货，前者追求单位时间处理尽可能多的货物，后者追求每一单都别晚。

这就是为什么混合连续批处理常常陷入一个陷阱：为了让 GPU 一直忙碌，系统把预填充请求和解码请求塞进同一批次，结果是短任务被长任务拖住，长任务又被短任务打断。首 token 等待时间变长，后续 token 也不够稳定。表面上资源利用率更高了，实际上用户体验更差了。

真正的吞吐优化，不是让所有工作共享同一条车道，而是为不同速度、不同重量、不同停靠频率的车辆设计不同道路。

更关键的是，分离之后，系统第一次拥有了一个以前几乎不可能实现的自由度：可以让多个预填充实例服务一个解码实例。这意味着，前端可以更积极地吸收请求、批量处理提示词，后端则可以专注于把解码 batch 做大，把 GPU 更接近计算上限地用在持续生成上。换句话说，分离不是拆散流程，而是让每一步都更接近自身的最优工作点。

---

真正的分水岭，不是“算得更快”，而是“把昂贵的状态留给最需要它的地方”

如果说分离架构解决的是工作节奏问题，那么 KV Cache 解决的就是状态如何跨时间存在的问题。LLM 推理的昂贵，并不只是每次前向计算的 FLOPs，而在于上下文状态越来越大，越来越难搬、难存、难复用。

这里有一个很重要但常被低估的事实：不同推理场景的 token 分布差异极大。有人问一句就走，有人一次输入成千上万 token，有人会连续对话上百轮。于是，统一设计的 KV 策略几乎必然失效。你不能用同一个背包去装登山装备、快递包裹和长期仓储品。更合理的方式，是把 KV Cache 当作一种动态资产配置：哪些状态该保留，哪些该压缩，哪些该跨层共享，哪些该跨轮次复用，都取决于场景。

这就把优化从单一的“减小缓存”推进到了“设计缓存经济学”。比如：

• MQA 通过让多个 head 共享 K 和 V，把缓存体积压到更小。
• 局部注意力 把大部分层限制在滑动窗口内，只把少数层保留全局视野。
• 跨层 KV 共享 则进一步让相邻层复用状态，减少重复存储。
• 有状态缓存 更进一步，把聊天轮次之间的 KV 留在主机内存里，下次继续复用。

这些方法看似分散，实则都在回答同一个问题：状态到底该在哪里停留，停留多久，谁有资格复用它？

这也是分离式架构和缓存技术之间最深的连接。分离让你知道哪个阶段最怕什么，缓存让你知道什么状态值得留下来。前者在解决“工作如何排队”，后者在解决“工作如何续命”。如果只做其中之一，系统只能半优化。只有把两者结合起来，才会出现真正的结构性收益。

可以把它理解成一座城市的交通与仓储协同。道路系统决定货物怎么流动，仓库系统决定货物是否要反复搬运。没有道路优化，仓库再大也堵车；没有仓储优化，路修得再好也只是空转。

---

工业级推理系统的真正形态，是一个会“识别任务”的操作系统

最有意思的地方在于，当推理系统从实验室走向工业场景后，问题就不再是单机上的 kernel 细节，而是整个系统是否能识别任务差异。一个成熟的推理平台，不应该把请求看成“一个 prompt 接一个 response”，而应该看成一组具有不同生命周期、不同资源偏好、不同复用机会的对象。

这也是为什么更完整的架构里会出现控制平面、全局调度器、长度预测模块、本地调度器，甚至实例翻转。它们并不是“多出来的复杂度”，而是系统开始理解：不是所有请求都应该走同样的路径。

举个具体的例子。一个短问答请求，提示词很短，生成也很短，最在意的是首 token 延迟。一个长对话请求，提示词可能来自历史聊天，最在意的是缓存复用和状态延续。一个高并发写作场景，则更关注解码阶段的稳定吞吐。若系统只会“先进先出”，那它是在用邮局的逻辑管理机场。

长度预测模块的意义也在这里。它不是为了炫技，而是为了让调度在请求刚进入系统时就能大致判断：这个请求将来会占用多少解码资源，是否值得送到某个 decode 实例，是否应该把更多工作推给某个更便宜的硬件。预测不一定完美，但哪怕只是粗粒度估计，也足以把系统从盲调度推进到带有意图的调度。

而实例翻转则更进一步，暗示一个更现代的观点：GPU 实例并不是天生属于 prefill 或 decode 的，它们只是被当前负载临时赋予了角色。这像云原生时代的容器编排思想，资源不应永久绑定于某种固定功能，而应随着需求变化重构职责。系统越成熟，越不像一堆固定机器，越像一个会变形的组织。

一个优秀的推理系统，不是让每个模块都更强，而是让每个模块更懂得什么时候该退后，什么时候该接管。

---

一个更实用的框架：把推理系统看成“三层匹配”

如果要把这些思想压缩成一个可操作的模型，我会把 LLM 推理优化理解为三层匹配。

1. 工作匹配：预填充和解码是否该分工

这是最基础的一层。先问自己，系统中的任务是不是天然分属两类。如果答案是肯定的，那么把它们拆开通常就是最直接的收益来源。预填充适合吞吐，解码适合时延，混合只会制造妥协。

2. 状态匹配：KV Cache 应该在哪里、以什么粒度存在

这一层关注状态管理。KV Cache 不是越大越好，也不是越小越好，而是要和任务分布、上下文长度、对话轮次、共享前缀这些特征对齐。能跨层共享就别重复存，能跨轮次复用就别每次重算，能压缩就别原样保留。

3. 资源匹配：不同阶段是否应该跑在不同硬件上

这一层决定成本结构。不是所有 GPU 都需要承担同样的工作。对长批量、高并行的预填充，可以用更强的算力；对持续生成、内存受限的解码，可以用更便宜、更适合访存的设备。真正高明的系统，不是把同一种卡用到极致，而是让不同卡承担各自最擅长的角色。

这个框架的价值在于，它把许多看似分散的优化，统一成了一个问题：如何让任务、状态和资源三者对齐。一旦对齐，性能提升往往不是线性的，而是结构性的。因为你优化的不再是某个点，而是整个流动过程。

---

Key Takeaways

1. 先区分工作类型，再谈优化。 预填充和解码不是同一种负载，混在一起通常会同时伤害 TTFT 和 TPOT。

2. 把 KV Cache 当成“可管理的资产”，不是固定开销。 重点不是只做压缩，而是决定哪些状态该跨层、跨轮次、跨请求复用。

3. 调度不是附属功能，而是架构的一部分。 一旦分离 prefill 和 decode，就必须用控制平面、长度预测和局部调度来匹配负载。

4. 不同阶段可以跑在不同硬件上。 预填充偏计算，解码偏内存，资源异构化通常比强行统一更划算。

5. 把系统设计目标从“更快”改成“更会分工”。 速度提升往往来自职责清晰，而不是单点极限。

---

结语：最强的推理系统，不是把一切压缩成一个流程，而是承认差异

LLM 推理优化的终点，可能并不是某个更快的 attention kernel，也不是某种神奇的缓存技巧，而是一个更朴素却更深刻的原则：系统必须承认，预填充和解码、短请求和长对话、计算和内存、速度和复用，本来就是不同的东西。

很多工程问题之所以反复出现，不是因为工程师不够努力，而是因为他们试图用统一答案处理不统一的现实。真正成熟的推理系统，不会强迫所有请求走同一条路，而是像一个优秀的城市规划者，知道哪里该修快速路，哪里该建仓库，哪里该设分流口，哪里该留缓存区。

所以，当我们说 LLM 推理优化时，也许应该少问一句“怎么让它更快”，多问一句“怎样让每一种工作都待在它最适合的地方”。一旦问题换成这个版本，很多以前看似零散的技巧，就会突然连成一张完整的地图。