从处理请求到调度推理：Bedrock 重构故事里的架构问题

研究文章 v1.0｜2026-09-10｜预计阅读 12–15 分钟

本文以 The Information 对 AWS Bedrock 重构的报道为起点，结合论文、AWS原始资料和两轮教学模拟，研究大模型推理为什么需要更细的资源调度。核心判断是：推理服务必须在执行过程中反复决定谁继续运行、状态放在哪里、谁可以等待。本文解释这些决定的机制与代价，未对Mantle做性能实测。

1. 一个 API 请求，为什么不是一份固定的工作？

The Information 报道，AWS 为 Bedrock 构建了新的推理引擎 Mantle，以应对容量、可靠性与不断变化的负载。报道中最值得追问的技术问题，是为什么一个已经能够接收模型请求的平台，还需要重新思考资源调度。种子文章及页码证据表（本地研究附件）

先看一个日常场景：你让模型把一句话改得简洁一些，另一位用户让同一个模型阅读一份长文档并写出分析。对 API 网关来说，这是两个请求；对计算系统来说，它们未必接近两份相等的工作。

假设一个请求有 100 个输入 token、实际生成 20 个输出 token，另一个有 8,000 个输入 token、实际生成 1,000 个输出 token。这些数字只是教学设定。我们不能据此直接算出谁耗时多少倍，但能提出更有用的问题：需要处理多少上下文？要生成多久？执行期间需要保留多少状态？它们各自允许等待多久？

请求数量描述了入口有多忙，却不足以描述内部还有多少工作。 资源分配需要同时考虑工作量与服务目标。

这里还存在一个容易忽略的差别。调用接口时，用户可以给出输出上限；生成何时实际结束，则未必能提前精确知道。系统需要在生成期间保留状态，并随着进度调整资源分配。PagedAttention 论文把输出长度未知、执行状态动态增长作为内存管理问题的重要背景。PagedAttention，§4.5

因此，研究应沿着请求的整个生命周期展开：它怎样进入系统，怎样与其他请求共享计算，状态放在哪里，什么时候完成并释放资源。入口限流只覆盖了其中一部分。

2. 请求进入模型后，为什么还要不断调度？

在本文讨论的普通自回归生成过程中，模型先处理输入，之后反复执行生成步骤。Orca 把调度边界从整批请求完成，推进到一次模型迭代结束：完成的请求退出，等待的请求可以被考虑加入。批次大小仍受约束，扩大批次也仍需权衡延迟。Orca，§2–4

用一个可以手算的例子看这种变化。假设系统一轮最多处理两个请求，每个活跃请求一轮完成一个单位的生成工作。A 需要 4 轮，B 需要 1 轮，两者最先进入；C 在第一轮结束时到达，也需要 1 轮。

下表比较“本批全部结束才接纳新请求”和“每轮结束都能补位”。空位标为“空”。

硬件没有增加，A 的完成时间也没有变化。改变的是 C 能否利用 B 释放的位置。这个例子只说明调度边界决定机会何时出现，不代表实际 GPU 性能：它假设每轮等长，并忽略输入处理、状态内存和调度开销。

“能补位”还不等于“放得下”。模型为了继续生成，会保留称为 KV cache 的中间状态。PagedAttention 将这类状态按块管理，减少提前预留和碎片造成的浪费，使更多请求有机会共同执行。代价也要计算：块寻址有开销，内存紧张时的换出或重计算并非免费。PagedAttention，§4.2–4.5、§7–8

我们因而要同时问两个问题：下一轮应该选谁，以及选中的请求需要的状态是否可用。前者是执行选择，后者是资源条件；把两者结合起来，才构成有用的运行时调度。

3. 为什么吞吐越高，不一定体验越好？

读者可以先区分两种等待：发出问题后多久开始看到回答，以及回答开始以后输出是否流畅。对应的常用指标是首 token 延迟 TTFT 和后续输出 token 的平均时间 TPOT。平均值也可能掩盖局部停顿，所以实际评估还需说明统计口径和尾部表现。

这里提供一个独立于任何论文的指标例子。假设我们自己规定“首 token 不超过 1 秒”，观察两种服务策略：甲在一段时间里完成了更多请求，但其中大量请求等了好几秒才开始；乙完成数量略少，却几乎都在目标时间内开始。用户认为谁更好，取决于服务承诺，不能由总吞吐单独裁定。

DistServe 专门讨论了输入处理阶段 prefill 与后续生成阶段 decode 的相互干扰。它将两阶段放到不同 GPU 上，并按延迟要求、资源配置和网络条件寻找部署方式。论文的每 GPU goodput 指满足给定达标比例目标时可承受的最大请求速率，不能与原始 token/s 混为一谈。分离还引入 KV cache 传输，收益取决于放置与通信条件。DistServe，§1–4

另一条路线是控制每次输入处理占用的工作量。Sarathi-Serve 把长 prefill 拆成小块，与持续生成的工作配合调度，以缓解长输入对输出流畅度的影响。这说明阶段分离并不是面对干扰问题的唯一选择。Sarathi-Serve，官方论文摘要

为了看清这些目标怎样冲突，本研究构造了一个包含9个请求的教学模型：一个长输出请求A、一个长输入请求P和7个短请求。每轮可以同时处理输入和已就绪请求的输出，耗时由人为公式 1 + 本轮输入量/4 + 本轮decode数/8 决定。公式假设批处理可以共享固定开销，时间只有逻辑单位；表中数值用于检验假设的后果，不能换算成真实GPU性能。

这组对照中，连续补位缩短了全部完成耗时，却让A经历更长的输出停顿，因为新加入的长输入拉长了混合执行轮次。把输入块上限从64减到8后，A的最长间隔缩短了，但排在长输入后面的短请求需要等待更多轮次，首输出更晚。总耗时在这两组中恰好相同，来自本例的轮数与公式，不能推广为分块没有开销。

较小KV预算还会使请求在有并发槽位时等待。这里按输入长度与输出上限保守预留状态，且不足时不跳过队首；因此，容量限制、预留方式和准入顺序共同造成了等待，不能全部归为物理显存不足。这个模型也没有实现PagedAttention的按需分配。输入、公式、敏感性检查和原始结果见研究笔记04（本地研究附件）。

对于研究者，合理的比较应该先固定模型、硬件、输入输出分布、到达负载和体验目标，再讨论哪种机制更合适。否则，两个系统即使都报告“吞吐提升”，也可能回答的是完全不同的问题。

4. 单个引擎优化后，云平台还需要解决什么？

上面的例子关注已经在执行资源附近等待的请求。一家云平台还需要面对不同客户同时请求容量的问题。它必须决定哪些请求可以进入、哪些需要排队，以及共享容量怎样分配。

AWS 在 2026 年 2 月 12 日的公告中，将 Mantle 描述为分布式推理引擎，并明确列出自动容量管理、统一资源池和服务质量控制。这些是带有日期的厂商能力陈述，尚需独立基准验证其实际效果。AWS PrivateLink 公告

Dave Brown在2025年12月的演讲中介绍了每客户队列与自适应容量共享。按客户分别管理积压，为共享容量下的公平分配提供了边界。但演讲没有给出队列选择算法或可检验的最坏等待上界。AWS keynote，39:21起

服务层级则让客户表达紧迫度。Priority与Flex于2025年11月18日宣布，早于上述演讲。按本次读取的文档，Priority、Standard、Flex共享模型的按需配额；选择优先级与预留容量是不同决定。发布公告、服务层级文档

还要区分接口与引擎：截至本次2026年9月10日直接读取，AWS吞吐文档明确表示，bedrock-runtime与bedrock-mantle两种API端点使用相同底层推理引擎，配额核算与容量选项不同。因此，端点名称不能直接充当旧、新调度架构的分界。AWS吞吐最佳实践

下面的图将问题分层。它是本文的概念框架，箭头表示需要理解的关系，不是 AWS 内部组件或实际调用顺序。

flowchart TD
    A[应用发起推理请求] --> B[平台层：准入、排队、容量分配]
    B --> C[执行资源选择：具体策略有待核验]
    C --> D[运行时层：选择下一轮执行的请求]
    D <--> E[状态资源：KV cache 的空间与位置]
    D --> F[执行模型并返回输出]
    F --> G{请求是否结束}
    G -->|否| D
    G -->|是| H[释放本次请求资源]
    X[Agent 工作流与持久化] -. 多次调用 .-> A

图中平台层有 Mantle 的公开资料支持；运行时与 KV cache 的讨论来自通用论文。将二者画在一起，是为了梳理研究问题，不能作为 Mantle 使用 Orca、vLLM 或 DistServe 的证据。

调度还涉及中断后如何保留进度。演讲把Journal描述为保存请求状态的持久事务日志，并以实时流量上升时暂停微调、之后恢复为例。这为理解“可恢复的工作怎样参与调度”提供了依据；日志究竟保存哪些字段、恢复成本有多高，仍未公开。AWS keynote，40:17起

这里应分清三种状态：生成期间的KV cache、可恢复的推理请求状态，以及Agent跨模型调用和工具操作的任务进度。它们有关联，却不能互相替代。Journal的公开描述不能证明它保存完整KV cache，更不能自动保证外部工具操作的事务恢复。

5. 调度怎样在不同请求之间分配等待？

即使只改变执行顺序，评价也可能出现分歧。第一轮教学模拟使用单处理器：一个20单位的长任务在t=0到达，20个1单位的短任务在t=1至20逐个到达，每单位时间完成1单位工作，切换没有开销。三种策略最终都在t=40完成全部工作。

完成延迟从各自到达时刻算起，输出指模型中完成一个工作单位。最短剩余优先被赋予了真实剩余长度信息，这是理想条件；模型没有批处理、输入阶段和显存限制。这里“先到先服务”让任务独占处理器到完成，不能代表所有采用先到队列的推理引擎。规则与数据见研究笔记03（本地研究附件）。

短任务占21个请求中的20个，因此整体平均延迟可以在长任务明显变慢时下降。后两种策略的长任务完成时间相同，输出停顿却不同。这解释了为什么评价应同时展示不同请求组的等待与持续进展。只观察有限时间窗口时，未完成请求也必须留在报告里；否则，迟迟得不到服务的任务会从延迟统计中消失。

两轮模型共同展示了资源管理的不同作用：执行顺序可以重新分配等待，批处理还可能改变开销被多少工作共享。它们的数值均依赖公开写明的假设，不能为生产策略排名。真实系统的比较需要固定模型、硬件、输入输出分布、到达负载与服务目标，再报告首输出延迟、输出间隔、完成率、未完成工作和资源占用。

回到研究起点，推理服务需要把调度推进到请求的生命周期：进入平台时决定如何排队与分配容量，执行时结合状态空间和阶段干扰重新选择工作，中断时考虑恢复进度的成本。负载均衡与入口限流仍然有用，它们与这些机制共同承担资源管理。

调度也有容量边界。利用空档和减少浪费能够改善效率；当持续到达的工作仍超过有效处理能力时，单靠改变顺序无法让全部请求都及时完成。服务需要增加资源、控制提交量、允许等待或调整目标。优先照顾某类请求时，还应观察其余请求承担的代价。

本研究能够支持的结论是：大模型推理的调度粒度、状态约束和评价目标需要一起设计。 Mantle公开材料提供了客户队列、容量共享、优先级与请求恢复的案例；论文解释了运行时和状态管理的机制。现有证据尚不能确定Mantle采用了哪些具体算法，更不能量化这些机制各自贡献了多少性能改善。

证据与复现： 本文区分新闻线索、厂商公开描述、论文机制和本地教学推演。论文阅读位置及实验限制见研究笔记02（本地研究附件）；两轮模拟的代码、原始结果和既有测试记录见笔记03（本地研究附件）与笔记04（本地研究附件）；Mantle事实对照、原始演讲时间定位和文档快照见笔记05（本地研究附件）。演讲依据英文自动字幕，未逐句听校；当前AWS文档的状态不用于倒推全部历史行为。本文没有进行生产环境、真实GPU或付费API测试，未使用商业增长数字证明技术因果。定稿的结论与数值审查见审查记录（本地研究附件）。