为什么同一批模型,有的秒回有的卡成PPT?20篇论文万字深扒大模型推理的隐藏瓶颈

“KV缓存亲和性与负载均匀性如何两全？P/D分离架构下，Kairos、NexusSched等系统如何实现SLO达成率近40%的提升？一文带你搞懂大模型推理的智能调度核心。”

摘要

大语言模型（LLM）推理服务正从“模型精度的竞赛”转向“系统效率的比拼”。当模型能力趋同，推理延迟与吞吐量的优化成为大模型规模化落地的关键瓶颈。然而，传统负载均衡算法在设计之初并未预见LLM推理负载的三大根本特征：

请求处理时间因输入/输出长度差异而波动达百倍、KV缓存使服务高度有状态化、批处理收益与延迟约束之间存在非线性的张力。

今天我们以“两层调度”架构为分析框架，系统梳理集群层请求路由与实例层任务调度的负载均衡算法设计：

1. 1. 在集群层，重点分析KV缓存感知路由、P/D分离调度和跨层协同预测三类机制；
2. 2. 在实例层，深入探讨连续批处理、SLO感知的抢占调度以及自适应批大小策略。

对比vLLM Router、NexusSched、Kairos、LMetric等代表性系统在算法复杂度、SLO达成率和规模化能力方面的优势与局限，并展望Predictive LB、端云协同调度和MoE专家负载均衡等前沿方向。

关键词：大语言模型推理；负载均衡；请求调度；KV缓存感知路由；Prefill-Decode分离；服务等级目标

1 引言

大语言模型的参数规模以每年约10倍的速度增长，而GPU显存的增长速度仅为每两年约2倍 [1]。这一剪刀差使得LLM推理服务的核心挑战从“能否加载模型”转变为“如何在延迟预算内服务尽可能多的请求”。在此背景下，智能调度引擎的负载均衡算法设计成为决定推理系统效率的关键环节。

LLM推理负载与传统Web服务负载存在本质差异，这使得轮询（Round-Robin）、最少连接（Least-Connections）等通用负载均衡算法在AI推理场景中几乎完全失效。具体而言：

1. 1. 请求成本的巨大变异性：一次推理请求的FLOPs开销与输入prompt长度呈超线性关系，Transformer自注意力机制的计算复杂度为，使得输入10 tokens与10,000 tokens的请求计算量差异可达数百倍 [1]。传统负载均衡器仅依赖请求数量或连接数进行决策，完全忽视了单请求成本的巨大差异。
2. 2. 服务的强有状态性：KV Cache是LLM推理的核心优化手段。一次请求的prefill阶段计算的键值状态若能在后续decode步骤或新一轮对话中复用，可节省高达40%–60%的计算开销 [2]。然而，若负载均衡器将同一会话的后续请求分发至不同的GPU实例，则所有缓存效益将被完全抹消。
3. 3. 动态批处理的调度依赖：与传统API服务不同，LLM推理的效率高度依赖于批处理（batching）。连续批处理（Continuous Batching）通过动态地合并请求的decode迭代步，可将吞吐量提升高达23倍 [3]。但批处理的形成需要在延迟容忍范围内故意引入微小的排队时延，形成了“吞吐量-延迟”之间的根本性权衡。

传统负载均衡器无法感知上述三个特征，因此，AI推理时代呼唤“智能调度引擎”——即具备模型感知（model-aware）、系统状态感知（state-aware）、以及SLO感知（SLO-aware）能力的新型负载均衡器 [4]。

本文其余部分组织如下：第2节介绍大模型推理服务的计算特征与负载均衡问题的数学建模；第3节系统分类并分析集群层的负载均衡算法；第4节聚焦实例层的请求调度机制；第5节对比主流系统的综合性能；第6节讨论设计与实现中的开放挑战；第7节展望未来方向；第8节总结全文。

2 背景与问题建模

2.1 LLM推理服务的计算特征

标准的LLM自回归推理分为两个阶段，其资源特征截然不同 [1]：

• • Prefill阶段：一次性处理整个输入prompt的所有token，计算所有层的注意力分数并生成完整的KV Cache。该阶段为计算密集型（compute-bound），FLOPs与prompt长度和模型参数量的乘积成正比。对于长prompt（>10K tokens），单次Prefill可耗费数秒甚至数十秒。
• • Decode阶段：逐token进行自回归生成，每步仅计算新token的注意力，但需要访问之前在Prefill阶段生成的完整KV Cache。该阶段为内存密集型（memory-bound），大量时间消耗在将KV Cache从HBM搬运至计算单元的I/O上。输出长度决定了Decode的总迭代次数。

这种Preill-Decode两阶段结构产生了两个关键延迟指标：首token时间（Time-To-First-Token, TTFT） 衡量Prefill阶段的完成时间，而每输出token时间（Time-Per-Output-Token, TPOT） 衡量Decode阶段每生成一个token的平均时间。终端用户对TTFT高度敏感（通常期望<100ms），而TPOT的要求相对宽松（<50ms/token即可接受）[5]。

2.2 负载均衡的核心矛盾

在上述计算特征下，LLM推理负载均衡面临三个相互交织的矛盾 [1]：

矛盾一：缓存亲和性 vs. 负载均匀性。将请求路由至持有其KV缓存的GPU实例可以显著降低TTFT [2]，但可能导致热点实例过载而其他实例闲置。

矛盾二：吞吐量最大化 vs. 延迟SLO保障。填充batch到最大容量可以最大化GPU利用率，但batch中的“慢请求”（长输出）会拖慢所有其他请求的生成进度，形成队头阻塞（Head-of-Line Blocking）[5]。

矛盾三：Prefill与Decode的资源竞争。在传统一体化架构中，Prefill和Decode共享同一GPU，计算密集的Prefill会抢占Decode的算力资源，导致正在进行的token生成出现抖动（jitter）[6]。P/D分离（Disaggregation）可解决该问题，但又引入了Prefill节点与Decode节点之间的负载再均衡挑战。

2.3 系统模型与问题形式化

典型的LLM推理服务系统采用“两层调度”架构 [4]，如下图所示：

图1 LLM推理服务的两层调度架构（参考 Zhang et al. [4] 的设计范式）

在集群层，负载均衡器（Router）接收外部请求，决策将每个请求分发至后端推理实例。路由决策函数可形式化为：

其中为时刻的系统全局状态，函数综合考量实例负载、KV缓存命中情况和路由延迟等因素 [7]。

在实例层，每个推理引擎维护一个请求队列，实例级调度器决定每个decode步从中选取哪些请求组成执行batch 。该层的核心优化目标是 [5,8]：

即最大化batch的执行效率，同时确保batch内所有请求满足各自的SLO约束。

2.4 性能评估指标体系

评估负载均衡算法的效果，需要一套完整的多维指标体系 [1,4]：

表1 LLM推理负载均衡的核心评估指标体系（综合 [1,4,5] 建立）

3 集群层负载均衡算法

集群层负载均衡负责决策“将请求路由到哪个推理实例”，重点考量缓存亲和性、实例负载状态和服务等级要求。

3.1 通用负载均衡策略及其在LLM场景下的局限性

基础的请求分发策略及其在LLM推理场景下的问题如下 [1,4]：

• • 轮询（Round-Robin）/ 随机（Random）：轮询或随机分发请求，实现简单且开销极低，但完全忽视请求特征和实例状态。在LLM推理负载的强异构性下，这种策略会导致严重的负载不均。
• • 最少连接（Least-Connections, LC）：将请求发送至当前活跃连接数最少的实例。该策略假设“连接数 ≈ 负载”，但在LLM场景下该假设完全失效——一个长prompt的连接可能消耗10倍于短连接的GPU资源 [1]。
• • 最短响应时间（Least-Response-Time）：将请求发送至最近平均响应时间最低的实例。相比LC更接近LLM的实际负载特征，但平均响应时间是滞后信号（lagging metric），无法反映瞬时批量状态 [4]。

通用策略的共性问题在于缺乏模型感知和状态感知。NexusSched的研究表明 [4]，集群层路由器若仅依赖平均延迟和队列长度等粗粒度指标进行决策，会导致严重的“决策滞后”（decision lag），造成SLO违规和资源浪费。

图2 传统负载均衡 vs. 智能状态感知负载均衡（对比思路源自 Zhang et al. [4]）

3.2 KV缓存感知路由策略

KV缓存的引入使LLM推理服务从“无状态”转变为“强有状态”。研究表明，KV缓存命中可将请求的prefill计算量削减40%–60%，使TTFT显著降低 [2]，但同一会话的请求必须被持续路由至同一GPU实例。

3.2.1 一致性哈希路由

vLLM Router采用一致性哈希（Consistent Hashing）实现会话亲和性 [9]。以会话ID或用户ID作为哈希键，映射到固定的推理实例，确保同一对话的所有轮次均被路由至持有相应KV缓存的同一实例。一致性哈希的优势在于：当实例池发生变更（扩缩容、故障摘除）时，仅影响哈希环上相邻区间的请求，而非全量重分布。AWS SageMaker同样采用了基于有状态路由的KV Cache复用方案 [2]。其代价在于“哈希不均匀”可能导致某些实例承载过多热门会话，形成热点。

3.2.2 “二选一”策略（Power of Two Choices）

“二选一”策略（Power of Two Choices, PoT）是一种低开销的随机化负载均衡方法：随机采样两个候选实例，选择当前负载较轻者路由。在LLM推理场景中，PoT的“负载”度量可以扩展为复合指标——同时考量实例的当前batch大小、KV缓存命中潜力和剩余显存。PoT的开销仅为的轻量采样，在大规模集群中（>100实例）表现出良好的可扩展性 [10]。

3.2.3 KV感知与负载均衡的多目标优化：LMetric

LMetric提出了一种极简而优雅的调度评分机制 [7]：将“KV感知指标”与“负载均衡指标”简单相乘，构成路由评分（scheduling score）：

其中表示若将请求路由至实例所需的新prefill token数量（体现KV缓存复用潜力——该值越小越优），表示实例当前的批量大小（体现负载——该值越小越优）。乘积评分的精妙之处在于：两个指标的量纲差异在比较过程中被自然消除，因此无需任何超参数调优。

根据LMetric的原始实验报告 [7]，相比vLLM-v1和某生产级调度器，该方法在真实工作负载（聊天机器人、API调用、代码Agent）上分别降低TTFT达92%和52%，降低TPOT达21%和20%。这一结果彰显了“简洁设计”在大规模系统中的竞争力。

3.2.4 跨区域KV感知路由：GORGO

在多区域部署场景下，GORGO进一步将KV缓存命中的收益与跨区域网络延迟的代价统一建模 [11]。传统多区域负载均衡器优先通过KV缓存命中节省prefill计算，但忽视了跨区域路由引入的网络延迟。GORGO引入网络感知的路由决策，在降低P99 TTFT的同时避免病态的跨区域请求转发。

3.3 Prefill-Decode分离架构下的调度算法

3.3.1 P/D分离的动机与优势

一体化的推理架构中，Prefill和Decode共享同一GPU。计算密集的Prefill任务会抢占内存密集的Decode任务的计算资源，导致正在生成的token出现延迟抖动（jitter），影响用户体验 [1,6]。P/D分离（Prefill-Decode Disaggregation）通过将这两个阶段部署到不同的GPU工作组，从物理上消除资源竞争。Ray Serve LLM on Anyscale的生产实践表明，Disaggregated Serving可实现更优的延迟与吞吐量SLA保障 [12]。

3.3.2 动态实例分配：Arrow

P/D分离引入的新问题是：Prefill实例组和Decode实例组之间如何按需动态分配GPU资源。Arrow系统通过引入“无状态实例+自适应调度”机制解决此问题 [6]：它根据实时集群性能指标（如Prefill队列长度、Decode步耗时分布、系统SLO达成率），动态调整处理Prefill和Decode任务的实例数量比例。实验表明，Arrow在多样化真实工作负载下相比固定分配的P/D分离系统，请求服务速率提升高达2.55倍 [6]。

3.3.3 SLO感知的Disaggregated调度：Kairos

Kairos系统针对P/D分离架构下的请求长度失衡问题，提出了两套互补的调度机制 [5]：

• • Prefill侧的紧迫性优先级调度：预测每个新请求的prefill完成时间，动态选择最能满足TTFT SLO的请求优先执行，避免长prompt请求阻塞短prompt请求。
• • Decode侧的Slack-Guided自适应批处理：利用每个请求的“松弛时间”（slack = TPOT SLO – 实际单步decode耗时），贪婪地将具有充足slack的短请求打包进batch，在严格满足SLO的前提下最大化decode吞吐。

实验显示 [5]，Kairos较基线系统提升了TTFT SLO达成率达23.9%、TPOT SLO达成率达27.1%、端到端SLO达成率达33.8%、Decode吞吐达19.3%。

图3 Prefill-Decode分离架构下的请求流转与Arrow自适应调度（架构参考 Wu et al. [6]）

3.4 跨层协同调度：从反应式到预测式

传统两层调度架构的核心缺陷在于信息断层：集群层路由器仅掌握滞后的粗粒度指标，实例层调度器仅执行静态启发式策略，两者各自为政。NexusSched框架打破了这一隔阂 [4]，由反应式负载均衡转向预测式编排。

NexusSched的核心构件包括 [4]：

• • PRISM（集群层）：利用结构化在线性能模型（structurally-informed online performance model）生成前瞻性的单步延迟与容量预测信号，驱动状态感知路由决策。
• • LENS（实例层）：基于PRISM的预测结果执行SLO感知的自适应调度，动态优化batch组成以满足实时负载下的SLO要求。

在FlowGPT生产集群的部署实践中 [4]，NexusSched平均提升SLO达成率43%，在长上下文和异构场景下的吞吐加速比高达3倍。

3.5 集群层算法对比小结

表2 集群层负载均衡算法对比（数据来源：各系统原始论文 [4,6,7,9,10,11]）

4 实例层请求调度算法

实例层调度器决策“在当前decode步，从等待队列中选择哪些请求组成执行batch”。该决策直接决定GPU利用率和用户感知延迟的平衡。

4.1 从静态批处理到连续批处理

传统的静态批处理（Static Batching）要求等够固定数量的请求后再统一执行，导致明显的排队延迟 [1]。连续批处理（Continuous Batching）的核心创新在于：在推理过程中持续接收新请求，动态构建最优批处理组，允许不同长度的请求在任意时刻加入或退出batch [3]。根据vLLM项目的官方技术报告，结合PagedAttention等内存优化技术，Orca论文中提出的迭代级调度使系统能够同时处理多个长短不一的请求，吞吐量跃升高达23倍 [3]。

图4 以甘特图直观呈现两种批处理模式的时序差异：

说明：Static Batching 表现为严格串行，每个后续请求必须等待前序批次完成；Continuous Batching 让请求1、2、3重叠执行（耗时分别为2、2、3单位），请求4在请求2结束后立刻接入，实现无需等待凑批的并发优势。

4.2 SLO感知的抢占式调度

先到先服务（First-Come-First-Served, FCFS）是大多数推理系统的默认调度策略。然而，FCFS在变化剧烈的LLM负载下会产生严重的队头阻塞（Head-of-Line Blocking）：长prompt请求可能使后续所有请求排队延迟超越SLO阈值 [5]。

AugServe通过“两阶段自适应请求调度”解决此问题 [8]：第一阶段根据请求特征（prompt长度、预估decode步数）和系统容量进行预分类；第二阶段基于分类结果执行抢占式优先级调度，使短请求可获得优先执行机会。根据AugServe的原始实验报告 [8]，该方法在生产测试中相比vLLM实现了4.7至33.1倍的有效吞吐量提升，TTFT降低高达96.3%，SLO合规率达到96.3%。

4.3 Slack-Guided自适应批处理

在Decode阶段，batch的构成面临“木桶效应”：batch中生成最长输出的请求（straggler）决定了整个batch的执行时间下限。Kairos的Slack-Guided自适应批处理策略 [5] 利用TPOT SLO提供的“松弛度”信息来指导batch打包：对于TPOT SLO要求宽松的请求（如批处理任务），可在单个decode步中打包更多token；对于TPOT SLO严格的请求（如实时对话），则严格控制batch大小以确保单步延迟不超限。

这种“以SLO slack为信号”的自适应打包，在理论上实现了SLO约束下的吞吐量最大化。实验证明 [5]，该方法在严格满足TPOT SLO的同时，将decode吞吐提升了19.3%。

4.4 基于延迟预测的调度

推理请求的完成时间预估是调度决策的关键信息。LAPS-SD（Least-Attained/Perceived-Service for Speculative Decoding）算法提出了一种“半预知”（semi-clairvoyant）的请求调度策略 [13]：基于请求在解码过程中已消耗或已感知的服务量，自适应地调度请求执行顺序，以最小化平均推理延迟。其思想源于操作系统中经典的公平调度理论，并将其巧妙地适配到了LLM推理的批处理语境中。

MARS（Memory- and API-Rooted Scheduler）则从系统级视角出发 [14]，将KV缓存内存压力预测与API调用序列纳入调度考量，实现了内存感知的预测式调度，有效降低了增强型LLM（augmented LLM）的端到端延迟。

4.5 实例层调度策略对比

表3 实例层调度策略对比（数据来源：各系统原始论文 [1,3,5,8,13,14]）

5 典型系统综合对比

5.1 主流推理框架的调度能力矩阵

表4 主流推理调度系统的功能矩阵对比（功能信息源自各系统官方文档及论文 [4,5,6,7,8,9,11]）

5.2 性能基准数据集与评估方法

LLM推理负载均衡的评估面临一个固有挑战：不同系统往往采用不同的模型、硬件和工作负载进行测试，跨论文的直接数值比较可能产生误导 [1]。目前主流的评估实践包括：

工作负载：多采用真实场景的混合负载，如ShareGPT对话数据集（覆盖短对话到长故事生成）、LMSYS-Chat-1M（百万级真实用户对话）、以及合成负载（如Azure Trace的子采样）。这些数据集的prompt和输出长度通常呈长尾分布，是测试负载均衡鲁棒性的关键 [1,4]。

评估框架：Inference Perf提供与模型服务器无关的统一基准测试能力 [1]，能端到端测量延迟、吞吐量和SLO合规率。vLLM Production Stack的基准测试表明，在prefill-heavy工作负载下，全栈优化相比基线vLLM可实现10倍性能提升 [9]。

5.3 不同调度策略的性能度量与权衡总结

综合各系统的实验数据 [4,5,7,8]，绘制不同策略的关键性能表现与权衡：

表5 不同调度策略的性能度量与权衡归纳（性能数据来源：各系统原始论文 [4,5,7,8,9]）

5.4 负载均衡调度系统的架构类图

图5 负载均衡与调度的核心类图（接口设计参考 Zhang et al. [4] 的系统抽象）

6 设计权衡与开放挑战

6.1 KV缓存亲和性 ⇌ 负载均衡均匀性

最根本的设计权衡之一。极致追求缓存亲和（如绝对固定的会话绑定）可最大化KV缓存命中率，但会导致严重的热点效应——某些实例承载大量活跃会话，而其他实例冷启动频繁 [7]。LMetric通过乘法评分机制在该权衡中取得了无需超参数的自适应平衡 [7]。然而，当系统状态剧烈波动（如突发流量导致所有实例同时处于高负载）时，其数学上存在的失效边界仍需更鲁棒的检测与缓解机制。

6.2 反应速度 ⇌ 决策精度

集群层路由器的决策需要在“快速响应”和“精确判断”之间权衡。依赖细粒度实时数据（如实例级KV缓存分布、精确的GPU利用率）能提高路由精度，但会引入不可忽略的采集延迟和通信开销 [4]。NexusSched为代表的预测式架构通过离线训练的性能模型实现“一次推演，实时调度”，在一定程度上解耦了这一权衡 [4]——但模型的训练和更新本身构成新的运维成本。

6.3 P/D分离的收益与复杂度

P/D分离能从根本上消除Prefill/Decode的资源竞争 [6]，但引入的复杂性不容忽视：

• • KV缓存的跨节点迁移：Prefill完成后，生成的KV缓存需传输至Decode节点。对于长prompt（>100K tokens），KV缓存可达数GB，传输延迟可能抵消分离带来的收益 [1]。
• • 负载再均衡的动态性：Arrow所示的自适应实例分配在理论上是优解 [6]，但在实践中需要应对“Prefill突发”和“Decode长尾”的高度时变特征。
• • 故障模型复杂化：分离架构中，一个Prefill节点的故障可能波及多个Decode节点上正在进行中的生成任务 [6]，容错设计需要在“超时可重试”和“状态同步开销”之间折中。

6.4 现有方法的局限性

尽管当前研究已取得显著进展，以下几方面仍存在明显不足 [1]：

1. 1. 异构硬件的统一建模：多数现有算法假设同构GPU集群（如全部为A100或H100），而真实生产环境中往往混合了不同代际的GPU，性能差异可达1.7至3倍 [15]。
2. 2. 冷启动开销的隐藏：模型加载需要50–100次推理预热才能达到最优性能 [1]。当弹性伸缩需要启动新实例时，预热阶段的性能退降如何与负载均衡策略协同，目前缺乏深入研究。
3. 3. 多租户的公平性保障：在多租户共享集群的场景下，如何确保不同用户的SLA需求得到公平满足，同时防止单个租户的资源滥用 [1]。
4. 4. 端到端可观测性：负载均衡决策的正确性高度依赖准确的系统状态信息，但当前推理框架的metrics暴露机制在指标粒度和时效性方面仍有提升空间 [4]。

7 未来方向展望

7.1 Predictive LB：端到端延迟预测驱动的前瞻性路由

NexusSched [4] 和GORGO [11] 等系统已初步展示了预测式负载均衡的潜力。未来方向是将延迟预测的范围从“实例级”扩展到“端到端”——将网络拓扑、交换机拥塞和跨机架延迟等基础设施层因素纳入路由决策模型。特别是随着RDMA和NVLink等高速互联技术的普及，网络拓扑对分布式推理性能的影响日益显著。

7.2 端云协同的智能调度与动态模型路由

随着异构计算环境的复杂化——从云数据中心到边缘节点的算力资源形成连续谱——一种新兴范式是“端云协同调度” [16]：根据请求的复杂度（如prompt类型、预期输出长度、延迟预算）在大小模型之间动态路由。当用户请求简单时可被路由至7B参数的边缘模型以降低延迟，而在需要深度推理时才接入云端的大参数模型。动态模型路由与负载均衡的融合将是提升整体推理效率的关键。

7.3 MoE架构下的专家负载均衡

混合专家（Mixture-of-Experts, MoE）模型（如DeepSeek系列、Mixtral）将传统负载均衡问题延伸到了“专家”粒度。MoE中不同的专家模块被放置在不同设备上，而token的路由（哪些token流向哪些专家）天然存在负载不均——某些“热门专家”承载不成比例的计算量。LASER算法通过即插即用的推理时路由策略，在不损失精度的情况下实现专家负载均衡 [17]。当前研究趋势正在将MoE的专家负载均衡与传统推理实例负载均衡进行融合设计。

7.4 强化学习驱动的工作负载调度

强化学习（RL）在调度领域的应用已有深厚积累，但在LLM推理调度中的应用仍处于早期阶段。未来可能的方向包括：将集群层的路由决策建模为马尔可夫决策过程（MDP），通过在线RL持续优化路由策略，以适应工作负载模式的长期漂移。RL还能在“缓存亲和-负载均衡-能耗”等多目标间自动寻找帕累托最优折中 [1]。

8 结语

大模型推理服务的负载均衡已演化为一个多层次、多维度的系统工程问题。本文系统梳理了从集群层路由到实例层调度的算法设计全景，重点分析了KV缓存感知路由 [2,7,9]、P/D分离调度 [5,6]、跨层协同预测 [4] 以及SLO感知的自适应批处理 [5,8] 等关键机制。

纵观该领域的技术演进，一条清晰的脉络正在浮现：从“反应式负载均衡”到“预测式系统编排” 。NexusSched [4] 和GORGO [11] 等系统已初步验证了预测式架构相对于传统反应式方法在SLO达成率和资源效率上的显著优势。从产业落地的角度观察，vLLM Router [9] 和SGLang等开源框架正在快速将学术成果产品化，而Kubernetes Gateway API的AI推理原生支持（如llm-d的路由扩展）[10] 则标志着云原生生态对大模型工作负载的深度适配。

大模型推理系统的负载均衡设计，几乎都是在延迟预算极度有限、状态高度耦合、请求成本强异构的复杂约束下寻找最优解。

这一领域仍处于高速发展期，预测式、自适应、多目标的智能调度引擎将是下一阶段的核心突破方向。

参考文献

[1] Zhen, R., Li, J., Ji, Y., Yang, Z., Liu, T., Xia, Q., Duan, X., Wang, Z., Huai, B., & Zhang, M. (2025). Taming the Titans: A Survey of Efficient LLM Inference Serving. In Proceedings of the 18th International Natural Language Generation Conference (pp. 522–541). Hanoi, Vietnam. Association for Computational Linguistics.

[2] Amazon Web Services. (2025). 基于 Amazon SageMaker 有状态路由优化大规模推理集群下的 KV Cache 复用方案. AWS China Blog.

[3] Yu, G.-I., Jeong, J. S., Kim, G.-W., Kim, S., & Chun, B.-G. (2022). Orca: A Distributed Serving System for Transformer-Based Generative Models. In Proceedings of the 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22). Carlsbad, CA: USENIX Association.

[4] Zhang, Y., et al. (2025). A Predictive and Synergistic Two-Layer Scheduling Framework for LLM Serving. arXiv:2509.23384v3.

[5] Wang, Q., et al. (2026). Taming Request Imbalance: SLO-Aware Scheduling for Disaggregated LLM Inference. arXiv:2605.02329.

[6] Wu, et al. (2025). Arrow: Adaptive Scheduling Mechanisms for Disaggregated LLM Inference Architecture. arXiv:2505.11916.

[7] Zhang, D., et al. (2026). LMetric: Simple is Better – Multiplication May Be All You Need for LLM Request Scheduling. arXiv:2603.15202v1.

[8] Wang, Y., Jin, Z., et al. (2025). AugServe: Adaptive Request Scheduling for LLM Inference Serving. Zhejiang University & Alibaba Group.

[9] vLLM Team. (2025). vLLM Router: A High-Performance and Prefill/Decode Aware Load Balancer for Large-scale Serving. vLLM Blog.

[10] Load Balancing for AI Inference: Distributing Requests Across 1000+ GPUs. (2026). Introl Blog.

[11] GORGO: Maximizing KV-Cache Reuse While Minimizing Network Latency in Cross-Region LLM Load Balancing. (2026). arXiv.

[12] Ray Serve LLM on Anyscale: Wide-EP and Disaggregated Serving with vLLM. (2025). Anyscale Blog.

[13] LAPS-SD: Semi-Clairvoyant Scheduling of Speculative Decoding Requests to Minimize LLM Inference Latency. (2025). IJCAI 2025.

[14] MARS: Fast Inference for Augmented Large Language Models. (2025). NeurIPS 2025.

[15] Llumnix Team. (2025). Llumnix: Dynamic Scheduling for Large Language Model Serving. In Proceedings of the 19th USENIX Symposium on Operating Systems Design and Implementation (OSDI 25). Boston, MA: USENIX Association.

[16] Moslem, Y., & Kelleher, J. D. (2026). Dynamic Model Routing and Cascading for Efficient LLM Inference: A Survey. arXiv.

[17] LASER: From Score Distributions to Balance – Plug-and-Play MoE Routing. (2025). arXiv.

[18] 中国信通院. (2026). 大模型推理优化关键技术及应用实践研究报告（2026年）.

[19] Heisler, M., Yousefijamarani, Z., Wang, X., et al. (2025). LLM Inference Scheduling: A Survey of Techniques, Frameworks, and Trade-offs. TechRxiv. DOI:10.36227/techrxiv.176238087.79673350/v1