推理为什么是
一个调度问题

你问模型一个问题，它的处理分两段。

记住这三件事——前后吃的资源相反、笔记必须一直留着、耗时取决于答多长而这个事先不知道。后面每一条论证都从这里出发。

前提一失效：请求根本不同质

两个层面。请求之间不同质——"帮我改个错别字"和"写一份三千字方案"耗时差两个数量级，而且你事先不知道它要答多长，这不像文件下载，大小是已知的。

更麻烦的是请求内部也不同质：读题段吃算力，答题段吃内存带宽。

前提二失效：必须记事，而且记的东西很占地方

那份笔记必须从头留到尾，这带来三个连锁后果：

前提三失效：时长跨度大到没法用一个超时值覆盖

从几秒到几十分钟。你没法设一个超时值同时适用于"改错别字"和"写方案"。

调度这个领域有四个经典关切。推理系统四个全占，而且其中一个是网站架构里完全不存在的。

4.1　优先级：不只是"谁先排队"，是"能不能打断正在做的"

网站架构里也有优先级——分流器可以设权重、可以有优先队列。但它们调整的都是"入队顺序"：决定谁先被取出来处理。一旦开始处理，就一路跑到完。

推理系统里的优先级不一样。AWS 在发布会上描述过这样一个场景：

如果一波实时流量涌进来，正在跑的微调任务会暂停。等这波流量过去，它从刚才停下的地方接着跑。 AWS re:Invent 2025 主题演讲

4.2　公平：真正的问题不是"公不公平"，是"资源能不能流动"

这一条网站架构有对应物——就是额度制。而 AWS 的官方文档里，恰好把两种做法摆在一起对比了：

老入口：在许多传统的多客户共享服务中，架构是围绕给每个账号设额度来设计的，以此管理对共享资源的公平访问。老入口就是这么做的。

新入口：这个入口采用高级调度与排队机制……大多数情况下请求会被立即处理，某些情况下请求可能会短暂排队，直到手上的活干完、算力释放出来。 AWS 官方文档 · 已译为白话，"传统的"三个字是原文用词

4.3　放置：这个请求该发到哪台机器

网站架构里这是"负载均衡"——轮流、或者谁手上活最少给谁。而且这个决定是无记忆的：每个请求独立决定去哪，因为前提一成立。推理场景下这个前提不成立，有两个原因。

这件事已经被主流厂商做成了价格，而且差价非常大——见第 05 节。

4.4　共置：这个请求和谁一起做

这是四个里最特别的一个。前三个在网站架构里至少有退化版本，这一个完全没有。

网站为什么没有：网站的并发靠多进程、多线程实现。两个请求同时在跑，各跑各的，除了抢 CPU 和内存之外互不影响。请求 A 存在与否，不改变请求 B 的执行方式。

推理为什么有：为了让显卡跑满，推理系统会把多个请求的字拼进同一次计算——它们在数学上被合并成一个矩阵运算，一起过一遍模型。

这不是推演。vLLM 的官方文档把这个权衡量化到了具体参数上——把下面的滑块拖一拖：

我特意去找了反例

既然说"网站架构完全没有"，那就得去找找看是不是真的没有。我查了三个候选：

翻开主流大模型的价目表，都能看到一个网站服务里从来没有的东西：同样是"输入"，被拆成了两个价——缓存命中和缓存未命中。而且差得非常多。

从便宜 5 倍到便宜 50 倍。同样的字，价格为什么能差这么多？答案全在第 01 节讲过的那件事里——那份笔记。

原理一：命中省掉的，正是最贵的那一段

回想第 01 节：读题阶段要把整段输入读一遍、生成那份笔记，这一段吃算力。如果两次请求的开头一模一样——同一段系统提示词、同一份长文档、同一组示例——那段开头的笔记第一次就已经算好了，第二次拿来接着用就行。

vLLM 的设计文档把做法讲得很清楚：把笔记切成一块一块，每一块用"这块里的字 + 它前面所有的字"算一个指纹（哈希）；新请求来了，从头逐块比对指纹，对得上的块直接复用。

核心想法很简单——我们把已处理请求的笔记块缓存下来，当新请求带着与之前请求相同的前缀到来时，复用这些块。vLLM 官方文档 · 已译为白话

原理二：命中不是自动的——要被"调度"到对的机器上

笔记存在哪？OpenAI 的官方文档写得很直白：

缓存状态存在单台机器上……只有当请求到达一台持有匹配且未过期条目的机器时，才能复用缓存前缀。因此，把请求路由到正确的机器，对缓存复用至关重要。OpenAI 官方缓存指南 · 已译为白话

它的路由依据也写明了三条：当前机器的负载和可用容量、请求开头若干 token 的哈希，以及一个可选的缓存键。

原理三：让笔记一直摊着要占显存——所以要收写入费，还会过期

第 03 节说过，笔记必须留在显存里，而显存是整台机器最稀缺的资源。缓存，就是有意让笔记在请求结束之后继续占着显存，等下一个人来用。这件事有成本，价目表上看得见：

有一家的做法值得一提：DeepSeek 把笔记存到了硬盘上，官方叫"上下文硬盘缓存"，默认开启、无需改代码，"缓存不再使用后会自动被清空，时间一般为几个小时到几天"，同时明说这是"尽力而为，不保证 100% 缓存命中"。它的命中价也是表里最低的——只有未命中的 2%。

原理四：同时来的请求，谁也吃不到缓存

Anthropic 官方文档里有一句很容易被忽略的话：

对于并发请求，缓存条目只有在第一个响应开始之后才可用。如果希望并行请求也能命中缓存，请等第一个响应开始后再发送后续请求。Anthropic 官方缓存文档 · 已译为白话

DeepSeek 的文档说的是同一件事："缓存命中的前提是相应前缀已被'落盘'。"十个开头相同的请求同时发出去，十个全按未命中计价——第一份笔记还没写完，别人借不到。自己切换一下看看：

显式与隐式：确定性是有价格的

两种模式把"确定性"和"省事"做成了两个价：显式要你先付一笔创建费（125%），换来确定命中和更低的命中价；隐式免配置，但命中不保证、命中价高一倍。你告诉调度器的越确定，它越能替你省。

对使用方的四条实际建议

1. 固定的放前面，变动的放后面。系统提示词、工具定义、长文档放开头；时间戳、用户问题、每次不同的内容放最后。开头改一个字，后面全部未命中。开头还要够长——OpenAI 要求至少 1,024 个 token（GPT-5.6 及以后），阿里云百炼也是 1,024，Google Gemini 3 系列是 4,096，太短的开头根本不进缓存。
2. 开头相同的一批请求，别同时发。先发一个，等它开始返回，再发其余的。
3. 请求间隔别超过有效期。5 分钟没人用，笔记就被腾掉了。
4. 看返回结果里的命中数字，别凭感觉。Anthropic 的 cache_read_input_tokens、OpenAI 的 cached_tokens、DeepSeek 的 prompt_cache_hit_tokens——如果它一直是零，说明你以为固定的开头，其实每次都在变。

到这里为止的论证，主要材料来自 AWS。所以我去看了开源社区的代码：目前最主流的两个开源推理引擎 vLLM 和 SGLang，它们的调度策略是公开的、可以逐行读的。

把它们实现的策略名字，和传统网站分流器的策略名字并排放——

左边那个"最高响应比优先"，是 1970 年代提出的算法，专门解决一个老问题：如果总让"活最短的先做"，大活会永远排不上队、被活活饿死。配套机制叫老化——排队越久自动加分，慢慢往前挪。

而 vLLM 官方文档解释这么做的理由时，说的正是第 01 节那件事：

把大的读题任务切成小块，和答题任务混在一起批处理，可以更好地平衡吃算力的和吃内存带宽的两类操作。 vLLM 官方文档 · 已译为白话

同一个物理事实，一边是厂商在发布会上讲，一边是开源代码在实现。两边对上了。

所以我专门去找了反例：有没有哪种情况下，推理请求确实可以被当成一批一模一样的活来处理？

找到了。

静态批处理并不总是错的。当负载可预测、延迟不关键时它就够用。更具体地说，如果请求预先就都在手上、且长度相对均匀，静态批处理简单有效，不需要任何动态调度。 推理系统技术文档 ·「静态批处理」＝ 凑够一批一起发、等全批做完

翻译一下：如果你是把一万条数据一次性丢过去、不着急要结果，那笨办法就够用了。前面说的资源差异依然存在，但它们不再影响你该怎么排班。

顺带纠正一个想当然

我原本以为，把"读题"和"答题"拆到不同机器上跑是为了提高效率。vLLM 官方文档明确写着：

注意：拆分读题和答题并不提高吞吐量。 vLLM 官方文档 · 原文为 "Disaggregated prefill DOES NOT improve throughput."

它存在的理由是让"首字响应速度"和"后续吐字速度"可以分别调整，以及控制最坏情况下的延迟。换来的是延迟可控，不是效率。

去读 vLLM 和 SGLang 的源码注释，会看到这类词。

顺带一个观察

AWS 讲抢占时只讲好处——微调任务给实时流量让路、之后从断点接着跑。从不讲代价。

而 vLLM 的官方文档直接写着：抢占和重算会损害端到端延迟。