模型服务、调度、路由与 API

所属： 服务编排与API管理层。本页边界： 多个请求怎样共享模型实例，并在延迟、吞吐和隔离之间权衡。

#核心公式

L=\lambda W

#符号说明

符号	含义	单位/条件
$L$	稳态下系统中的平均请求数	请求数
$\lambda$	长期平均到达率或完成率	请求/s
$W$	请求在系统中的平均停留时间	s
$\mu$	简化队列模型中的平均服务率	请求/s
$T_{\mathrm{queue}}$	请求排队时间	s
$T_{\mathrm{prefill}}$	输入 prompt 的预填充时间	s
$T_{\mathrm{decode}}$	自回归输出阶段的时间	s
$M_{\mathrm{KV}}(n_i)$	长度为 $n_i$ 的请求所占 KV Cache	Byte
$C(m,q),\ Q(m,q),\ T(m,q)$	模型与请求分别为 $m,\ q$ 时的成本、质量与延迟	依指标定义
$\mathcal M,\ m,\ q$	可选模型集合、候选模型、当前请求	集合、模型、请求
$q_{\min},\ t_{\max}$	允许的最低质量与最高延迟	与 $Q,\ T$ 同量纲
$A(m,q)$	模型与请求分别为 $m,\ q$ 时的权限与可用性约束	0 或 1
$r_{\mathrm{P/D}}$	预填充实例与解码实例的配比	正整数
$\hat{c}_q^{(\alpha)}$	请求与分位数水平分别为 $q,\ \alpha$ 时的成本估计	s
$B_{\mathrm{backlog}}$	路由端可见的积压信号	请求数/Byte
$\rho_{\mathrm{KV}}$	KV Cache 压缩率	$[0,1]$

Little 定律要求系统处于长期稳定状态；它不单独描述等待时间如何随负载变化。

#技术要点

continuous batching 让不同请求在不同 decode 步并行。chunked prefill 将长 prompt 拆分为等长块，与 decode 步骤交错执行，在 token 预算下形成混合批次，减少 decode 停顿且吞吐损失极小，已成为 vLLM 和 SGLang 的默认策略。
动态 P/D 分离通过实时负载监控调整预填充与解码实例的配比，解决异构工作负载下的生产者-消费者失衡。DOPD 相比 vLLM 和 DistServe 提升系统有效吞吐最高 1.5 倍，P90 TTFT 降低 67.5%。
量化感知路由用请求成本的保守分位数估计替代点估计，降低 TTFT 尾延迟和 SLO 违规。QUARTZ 作为 SGLang 的路由器升级实现。
约束优化路由将路由建模为全局约束优化问题而非逐查询贪心决策。OmniRouter 通过拉格朗日对偶分解迭代收敛到全局最优分配，响应准确率提升最高 6.30% 的同时计算成本降低至少 10.15%。
分层 KV Cache 管理同时优化 token 级和元素级冗余。HiKV 实现最高 7.95 倍注意力计算加速和 90% 能耗降低，准确率损失仅 1%。
API 契约定义输入、流式输出、错误与版本兼容。生产级 API 网关已普遍支持多提供商故障转移、按 key 限流和 SSE 流式中途错误处理。

#原理与演进

#Little 定律解释队列为何变长

在稳定系统中， $L$ 是系统内平均请求数， $\lambda$ 是平均到达/完成率， $W$ 是平均停留时间。到达率逼近服务能力时，排队会增大 $W$ 。
吞吐、首 token 延迟（TTFT）、后续 token 间隔（TPOT）和 P99 延迟不是同一指标；静态大 batch 可提高吞吐，却让短请求等很久。

#为什么生成服务需要特殊调度

机制	解决问题	新代价
静态 batch	矩阵运算利用率低	长短请求互相等待
Continuous batching	请求在每个 decode 步进入/退出批次	KV 管理与公平性更复杂
Chunked prefill	长 prompt 阻塞 decode 步骤	调度器复杂度增加
Paged KV	不同长度请求预留连续缓存造成碎片	地址映射与块管理开销。PagedAttention 原论文
Prefill / Decode 分离	大 prompt 挤占 decode 延迟	两阶段之间传输 KV、队列协调
动态 P/D 配比调整	异构负载下两阶段实例失衡	需要实时负载监控与重配置机制

#路由与 API 契约

路由可依据任务、上下文长度、模型能力、延迟预算和可用权限选择后端；能力不足的便宜模型不能仅凭低成本替代复杂任务。
API 契约要定义消息角色、token 上限、流式事件、错误语义与版本；即便模型权重相同，模板或 tokenizer 变动也可能改变行为。
限流保护队列稳定性；超时、重试与降级会改变用户可见结果，因此可靠性需按端到端请求测量。

模型侧机制： KV Cache 与解码。

#1. 服务层优化的是多请求系统，不是单条生成

模型推理可拆为 prefill 与逐 token decode；服务层额外管理到达过程、排队、并发、缓存分配、取消和失败恢复。单请求 latency 最低的配置，不一定是高并发下吞吐与尾延迟最优的配置。

在稳态近似下有下式，若平均到达率 $\lambda$ 接近最大服务率 $\mu$ ，小幅流量波动即可显著增加排队。Little 定律本身不直接给出 $W$ 的函数形式；具体队列延迟取决于服务时间分布和调度策略。

L=\lambda W

#2. 三类关键资源

资源	主要消耗来源	典型症状
计算吞吐	prefill 大矩阵运算	长提示 TTFT 高
权重/显存带宽	小批 decode 重复读权重	输出 token 速度低
KV Cache 容量/带宽	并发数×上下文长度	请求被拒或频繁换出

因此调度不是只扩大 batch：prefill 与 decode 混跑会互相干扰；请求长度差异导致静态 batch 中短请求等待；过多并发可能先耗尽 KV 内存而非计算能力。

#3. 从静态批处理到动态 P/D 分离

静态 batch（利用率低且头阻塞）→ continuous batching（每个 decode 步动态进出）→ 分页 KV（减内存碎片、支持变长）→ prefill/decode 分离（分别优化计算与延迟）→ 动态 P/D 配比调整（解决异构负载失衡）→ 按 SLO、长度、优先级路由（减少混合负载干扰）。

#3.1 动态 P/D 分离的工程机制

固定 P/D 配比的分离架构在异构 LLM 工作负载下面临生产者-消费者失衡问题：预填充实例和解码实例之间的负载不匹配导致资源浪费。DOPD（Dynamic Optimal Prefill/Decoding） 通过实时负载监控动态调整实例分配，达到最优 P/D 配比。

DOPD 的关键设计包括：（1）基于历史负载的主动重配置，而非被动响应；（2）适配混合长度请求的调度策略，在高并发下缓解资源分配错配。实验结果表明，相比 vLLM（聚合式）和 DistServe（分离式），DOPD 提升系统有效吞吐最高 1.5 倍，P90 TTFT 降低 67.5%，P90 TPOT 降低 22.8%，同时以更少的额外资源实现超过 99% 的 SLO 达成率。

MAPS（Memory-Aware Predictive Scheduling） 针对分离式架构中内存受限的解码实例的持续负载不均衡问题。由于请求到达时输出长度未知，解码实例的负载难以预测。MAPS 通过预测输出长度进行前瞻性调度，减少解码实例的空闲等待。

#3.2 Chunked Prefill 的默认化

Chunked prefill 将 prompt 处理拆分为等长块，在调度步中与 decode 步骤交错执行，形成混合批次。这一机制在 token 预算约束下同时控制 TTFT 和 TPOT，减少 decode 停顿，吞吐损失极小。它已成为 vLLM 和 SGLang 的默认调度策略，也是 2025 年后生产部署的基线配置。

分离并非总有利：阶段间 KV 传输、额外队列和网络可能抵消收益；只有负载足够、阶段瓶颈明显时才值得。应以端到端吞吐、TTFT、TPOT、P99 和成本一起判断。

#4. 路由：从逐查询贪心到约束优化

对于请求 $q$ 和模型 $m$ ，可写约束优化：

\min_{m\in\mathcal M} C(m,q) \quad\text{s.t.}\quad Q(m,q)\ge q_{\min},\quad T(m,q)\le t_{\max},\quad A(m,q)=1.

$Q$ 是任务质量估计， $T$ 是预测延迟， $A$ 是权限/能力可用性。便宜模型若无法满足正确率或工具权限，不属于可行集合。

#4.1 约束优化路由：OmniRouter

现有路由框架通常将路由建模为逐查询的局部最优决策，忽略了全局预算约束，导致资源分配效率低下。OmniRouter 将路由任务建模为约束优化问题：在确保所需性能水平的前提下，分配最小化总成本的模型。

OmniRouter 的技术路径包括：（1）混合检索增强预测器预测 LLM 的能力和成本；（2）约束优化器使用拉格朗日对偶分解与自适应乘子迭代收敛到全局最优的查询-模型分配，动态平衡延迟最小化与质量阈值，同时满足异构容量约束。实验显示，OmniRouter 相比竞争性路由基线实现响应准确率最高提升 6.30%，同时计算成本降低至少 10.15%。

#4.2 量化感知路由：QUARTZ

TTFT 对路由器侧的排队效应高度敏感：prefill 成本随 prompt 长度缩放，decode 长度不确定，前缀局部性造成请求间强烈的性能偏斜。现有路由器通常对请求成本无感知，容易在混合工作负载下遭受头阻塞和尾延迟放大。

QUARTZ 提出量化感知路由与排队层，使用轻量级路由器可见信号预测保守的基于分位数的请求成本代理，而非点估计。这些分位数与积压感知的路由器信号一起指导工作节点选择和准入决策，使路由决策更好地对齐 TTFT 尾延迟 SLO 同时保持公平性。QUARTZ 作为 SGLang 的路由器升级实现，在交互式和检索增强工作负载上均降低了 TTFT 尾延迟和 SLO 违规。

#4.3 分层路由：Select-then-Route

在所有可用 LLM 中为每个查询做选择是极其昂贵的。Select-then-Route（StR） 采用两阶段框架：第一阶段用轻量级分类引导选择器将查询映射到其语义类别已验证擅长的模型池（如推理、代码、摘要）；第二阶段在选定池内通过自适应级联路由，从最便宜的模型开始，仅在多评审一致性测试发出低可靠性信号时升级。

在六个公共基准上，StR 将端到端准确率从 91.7%（最佳单模型）提升至 94.3%，同时降低推理成本 4 倍。分类体系和多评审评估阈值均可调节，暴露了平滑的成本-准确率前沿。

#4.4 级联与路由的统一

Cascade Routing 将路由和级联整合为理论上最优的策略。现有方法存在三个关键局限：缺乏最优性的形式证明、未能识别这些策略最有效的条件、无法组合两种范式。Cascade Routing 推导了级联的最优策略并证明了路由策略的最优性，实验表明统一框架持续大幅优于单独方法。

#4.5 路由方式对比

路由方式	机制	优势	局限
规则阈值	按长度/任务类型硬编码	可预测、易调试	无法适应分布变化
分类器/小模型预测	训练路由器预测最佳模型	可学习、可扩展	路由器本身可能误判
级联调用	先小后大，按信心升级	省平均成本	失败检测漏判时困难任务留给小模型
约束优化（OmniRouter）	全局预算下的成本最小化	全局最优、可控制	需预测能力与成本
量化感知（QUARTZ）	分位数成本代理+积压信号	尾延迟对齐SLO	需路由器可见信号
分层路由（StR）	先缩小池再级联	成本-准确率前沿可调	分类体系设计成本

#5. 分层 KV Cache 管理

#5.1 两级重要性感知压缩

随着长上下文 LLM 的广泛采用，解码期间持续增长的 KV Cache 已成为关键内存瓶颈。HiKV 提出算法-硬件协同设计，通过分层重要性感知利用 KV Cache 冗余。

HiKV 在两个粒度上压缩 KV Cache：Stage I 在固定预算内驱逐不重要的 token；Stage II 进一步仅加载每个保留 token 中的重要元素，达到单一粒度无法实现的压缩率。在架构层面，HiKV 开发了专用加速器，核心是可重构的重要性排序器，在不同阶段所需的不同排序数据路径之间切换，以最小开销统一两级加速。

评估结果显示，HiKV 相比原始 KV Cache 基线在注意力计算中实现最高 7.95 倍加速和 90% 能耗降低，准确率损失仅 1%。在等精度约束下，HiKV 相比最先进的基于重要性的方法实现了额外 1.82～4.87 倍的外部内存访问减少。专用硬件组件仅增加 8% 的系统面积。

#5.2 跨层动态预算分配

现有逐出方法要么将预算优化限制在单个注意力层内，要么使用间接统计指标进行跨层分配。G-AdaKV 通过单次全局 Top-k 选择在所有层和注意力头之间分配缓存预算。与多阶段基线不同，G-AdaKV 依赖单一机制，但在 LongBench 基准的三个预算水平上均达到最高整体平均。在最受限预算（满足下式）下，G-AdaKV 在 16 个任务中的 12 个上取得最佳分数。

B=128

#6. API 契约与可观测性

#6.1 API 网关的最新实践

生产级 API 网关的核心能力已从简单的请求转发演进为多层治理。多提供商故障转移：当某一提供商触发限流或连接失败时自动切换到备用提供商，保持服务连续性。SSE 流式中途错误处理：流式输出若中途失败，网关需要区分“部分文本已发送”与“任务成功完成”，并向调用者传递正确的错误语义。按 key 的滚动窗口限流：支持 RPM（每分钟请求数）、RPD（每日请求数）、TPM（每分钟 token 数）、TPD（每日 token 数）四种维度的独立追踪。

AWS API Gateway 与 Amazon Bedrock 的集成方案展示了生产级实践：使用用量计划和 API 密钥控制请求速率，响应流式传输实现模型输出的实时交付。

#6.2 尾延迟的诊断与监控

Agentic LLM 服务的尾延迟问题比单次推理更复杂：用户感受到的是整个工作流的延迟，而非孤立的解码路径。P99 表示 99% 的工作流在此延迟下完成，一小部分慢工作流即可主导感知质量和运营成本。

QueueBreak 提出从追踪到诊断的流水线，用于定位 Agentic 服务中的尾延迟根因。FlowGuard 针对多 Agent 服务中的突发工作负载导致的队列堆积、内存失衡和尾延迟膨胀，提出松弛感知的过载控制机制。相比基于 vLLM 的静态服务基线，CALM-MAS 将共享后端尾延迟降低 77%，精度退化限制在 6.1 pps 以内。

API 需定义：输入角色/模板、模型版本、最大上下文、输出限制、工具 Schema、流式事件顺序、取消语义、错误类型和重试行为。一次请求的“最终成功”必须由用户可见结果定义，不应以 HTTP 200 代替质量。

重试可能重复工具副作用；调用者应提供幂等标识或在服务端保证去重。版本变动的评测见模型制品与观测。

#7. Little 定律不能代替排队模型

式（1）只给稳态平均关系，并不说明当 $\lambda$ 上升时 $W$ 如何变化。若额外假设单服务台、到达和服务过程均为指数分布的 M/M/1 模型，则有式（2）（其中式（3））；接近 $\mu$ 时等待急剧增加。真实 LLM 服务的请求长度、批处理与服务率随并发变化，不满足这些简单假设。

式（1）：

L=\lambda W

式（2）：

W=1/(\mu-\lambda)

式（3）：

\lambda<\mu

服务系统中还要区分排队等待、prefill 处理和 decode 生成。TTFT 若升高而 TPOT 稳定，更可能是队列或 prefill；TPOT 随并发升高则可能是 decode 带宽/KV 竞争。

#8. 迭代级调度的本质

静态 batch 让所有请求一起进入并等长执行，短输出请求可能被长输出拖住。Continuous batching 在每次 decode 迭代后移除已完成请求、加入新请求；调度单位从“整条请求”变成“一个生成步”。这提高设备利用率，但每个活跃请求都持有 KV，须同时满足 token 计算预算与 KV 内存预算。

若活跃请求集合为 $A$ ，可写入场约束如下。仅按请求数限制并发不够，因为 $n_i$ 差异很大。过度填满 KV 会造成新请求长时间排队，甚至频繁换出，降低整体吞吐。

\sum_{i\in A}M_{\mathrm{KV}}(n_i)+M_{\mathrm{weights}}+M_{\mathrm{temp}}\le M_{\mathrm{device}}

#9. 服务质量与公平性

吞吐最大化可能让长输入或低优先级请求持续等待；严格 FIFO 又可能让一个超长 prefill 阻塞短请求。EWSJF 等自适应调度器通过混合分区策略解决 FCFS 的严重头阻塞问题。调度可按 token 预算、等待时间、用户配额和截止期限综合决定。但任何优先级方案都要防止饥饿，并明确不同租户共享 KV/计算时的隔离边界。

若请求中途取消，服务端应及时释放 KV 与工具会话状态；否则已停止的流仍消耗资源。指标除 token/s 外应包含拒绝率、取消后释放延迟、P50/P99 TTFT 与 TPOT、每请求成本。

原始资料：

关联概念：

推理与 KV Cache负责单请求生成机制；
Agent解释多步调用如何放大延迟；
模型制品与观测负责版本与指标归因。

本页由仓库中的 Markdown 生成。具体技术结论请结合正文引用与实验条件理解。