Dynasor：针对 Reasoning 场景的 LLM Inference 优化系统

最新推荐文章于 2025-12-07 19:40:17 发布

原创最新推荐文章于 2025-12-07 19:40:17 发布 · 1k 阅读

28 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #AI大模型 #语言模型 #LLM #ai #agi

一、背景

LLM Router 其核心思路是：通过路由的方式组合多个模型，以提升速度或精度。常见的路由方式为按 Query 意图路由（SambaNova CoE），对应子模型为不同垂类模型；或者按 Query 难易程度路由（Hybrid LLM，Router LLM），对应子模型往往是不同大小的模型；此外，也有很多蒸馏相关工作，可以在保持精度的情况下降低 Token 数，比如我们之前提到的 “Meta 蒸馏 System 2 进 System 1”。

然而，上述工作往往是针对的单个 Query 的单一解决路径。本文中，我们介绍一种新的方案，其主要针对的是 Reasoning 任务等多路径的场景。

对应的论文为：[2412.20993] Efficiently Serving LLM Reasoning Programs with Certaindex [1]

二、摘要

LLM 的快速发展已使其在数学问题、代码生成及法律分析等高级 Reasoning 任务中展现出强大能力。这一进步的核心在于 Inference 阶段的 Reasoning 算法，该算法通过探索多种解决路径来优化输出，但代价是增加了计算需求和响应时延。现有服务系统未能适配这些算法的扩展行为或 Query 难度的变化，导致资源利用效率低下且无法满足时延目标。

本文中，作者提出了 Dynasor 系统，该系统针对 LLM Reasoning Query 优化了其 Inference 阶段的计算开销。与传统引擎不同，Dynasor 在 Reasoning Query 内部跟踪并调度请求，并利用 Certaindex（基于模型确定性指标统计 Reasoning 进度的代理）来动态指导计算资源分配。Dynasor 将调度与 Reasoning 进度协同处理：它为复杂 Query 分配更多计算资源，简单 Query 则减少计算，并提前终止无望的 Query，从而在准确性、时延和成本之间取得平衡。在多种数据集和算法上，Dynasor 在离线 Batch Processing 中最多减少了 50% 的计算量，并在在线服务中维持了 3.3x 的Query 率提升或 4.7x 的时延 SLO（服务水平目标）降低。

三、引言

3.1 常见 Reasoning 算法

如下图 Figure 2 所示，作者阐释了 4 种常见的 Reasoning 算法，尽管它们在具体细节上有所差异，但均包含 2 个核心操作：

扩展：生成 Token 以扩展解决方案路径。
聚合：整合各路径的结果，以得出最终答案。增加扩展阶段的计算资源，通常能提升聚合阶段答案的质量。

自一致性（Self-Consistency, SC）。如下图 Figure 2a 所示，SC 的核心思路是生成多个不同输出（可通过改变采样参数等方式实现），然后对所有答案进行投票表决，选出胜率最高的答案。关键参数是候选答案个数 n。

Rebase 算法。如下图 Figure 2b 所示，Rebase 同样是生成多个输出，只不过会分为多步生成，每一步都会使用 Reward 模型进行评分，并基于得分最高的结果继续生成，最后生成具有多个分支的推理树。聚合阶段选择得分最高（Best-of-N）的答案。

蒙特卡洛树搜索（Monte Carlo Tree Search，MCTS）。如下图 Figure 2c 所示，MCTS 是一种强大的 Reasoning 算法，通过逐步采样来扩展节点，并构建解决方案树，直至到达包含候选解的叶节点。每个解决方案通过 Reward 模型或模拟进行评分，并将分数反向传播至其祖先节点以更新其奖励值，从而完成一次迭代。关键参数同样是 n，增加 n 允许对潜在解决方案进行更深更广的探索。

内化思维链（ICoT）。如下图 Figure 2d 所示，最新的 LLM，比如 OpenAI o1 和 Qwen-QWQ，能够在训练过程中内化 Reasoning 行为，无需显式的 Reasoning 算法。其核心思路是会生成 CoT 序列，将复杂问题分解为多个小问题，然后通过反思之前的输出结果并迭代优化这些答案，并最终得出解决方案。

在这里插入图片描述

3.2 背景和动机

LLM Reasoning 能力提升：随着 LLM 的发展，其在数学问题求解、代码生成、法律分析等复杂 Reasoning 任务上的能力得到了显著提升。这些 Reasoning 算法通过在 Inference 阶段探索多种解决方案路径来提高输出的准确性和鲁棒性。

Reasoning 算法的挑战：这些 Reasoning 算法在 Inference 阶段需要生成更多的输出 Token，导致计算需求和响应延迟增加。现有的推理系统无法有效适应这些算法的扩展行为或不同 Query 的难度变化，导致资源利用效率低下，无法满足时延目标。

如下图所示作者展示了 2 个案例：

（a）在 GSM8K 数学 Reasoning 基准中，将生成 Token 数从 8K 扩展到 20K（2.5x），整体准确率从 60% 增加到 80%。
（b）不同 Query 计算资源不合理，其中 Even 为不合理分配，Ideal 为调整后的分配。
较难 Query（如 P3）可能未分配足够的计算资源以得出正确答案。
较简单 Query（如 P1）则可在减少计算流程的情况下更快完成。
部分 Query（如 P4）无论计算资源如何均无法解决，本可以提前终止。

在这里插入图片描述

当前已经有很多 LLM Inference 系统（比如 vLLM，SGlang 等），但它们均未能有效调度或分配 LLM Reasoning 所需的 Inference 计算资源。而且很多优化的调度器通常以单个输入/输出粒度进行操作，而 LLM Reasoning 算法可能需要调用多个输入/输出序列，比如 MCTS 中的不同路径；此外，这些系统也无法识别哪些单个输入/输出序列属于特定的父 LLM Reasoning Query，使得调度器无法针对这些父 Query 的端到端时延 SLO 进行优化。

四、Certaindex 指标

4.1 概述

LLM 具备一种内在能力，即“知晓其所知”，这意味着它们能够自我评估对答案的置信度。这一能力使得 LLM 在生成 Token 时能表达其确定性。本节中，作者提出了 Certaindex，作为衡量这种置信度的指标，用以代理 Reasoning 进程：高确定性表明 LLM 接近最终答案，或直接指向达到最终答案所需计算量的减少，无论答案正确与否。目标是在 Inference 过程中测量并追踪 Certaindex，从而实现动态资源分配、优先处理复杂 Query、简化简单 Query 以及终止无望 Query。

4.2 测量 Certaindex

4.2.1 典型 Reasoning 算法的 Certaindex

对于 SC、MCTS 和 Rebase 这样的 Reasoning 算法，作者采用基于经验熵（Empirical entropy）的语义熵（Semantic entropy）来量化这些 Reasoning 算法 Reasoning 路径中的确定性。

对于给定的问题 P，生成了 n 条 Reasoning 路径，并根据它们的答案分为 m 个组：C1, C2, …,Cm，其中 ∣Ci∣ 表示答案组 Ci 中路径的数量，1+2+…+m=n。经验熵的计算公式为：

其中，H 直观地衡量了答案分布的多样性，较高的 H 表示更大的不确定性，这表明 Reasoning 路径分散到许多不同的答案中。相反，较低的 H 表示更高的确定性，通常表现为大多数路径收敛到相同的答案（某个组 Ci 的 ∣Ci∣ 较大）。

最大熵 max⁡(H)=log⁡n 对应每条路径都生成唯一答案（即 m=n，对于所有 i，∣Ci∣=1）。作者通过将 H 归一化为 Certaindex 来量化：

对于 SC、MCTS 和 Rebase 等应用于精确答案（如算术、多项选择）的任务，可以对生成输出进行字符串匹配来提取答案，并基于相等性进行分组。而对于开放性生成任务（比如代码生成），作者使用小型嵌入模型（比如 100M 参数量）来计算最终输出之间的文本相似性，并基于语义相似性对 Reasoning 路径进行聚类，从而在不同问题格式下实现高效分组。

4.2.2 带有 Reward 系统的 Reasoning 算法的 Certaindex

对于整合了 Reward 模型的 Reasoning 算法（例如，MCTS、Rebase），作者直接采用 Reward 模型归一化后的输出 R ∈ [0,1] 作为确定性度量。作者收集每条 Reasoning 路径的最终奖励分数，并通过聚合计算 Certaindex。聚合方式因算法而异：

对于 MCTS，采用各路径奖励的平均值。
对于 Rebase，采用最大奖励值。

较高的聚合奖励意味着 Reasoning 路径有效性的确定性更强，反之则表明存在不确定性。这些奖励分数是在 Reasoning 算法正常执行过程中收集的，因此不会产生额外开销。

4.2.3 联合多种 Certaindex 指标

Certaindex 也可由多重信号构成，前提是这些信号能有效捕捉 LLM Reasoning 过程中的确定性。当存在多个信号时，可通过为每项指标设定独立阈值进行整合。例如，作者在 MCTS/GSM8K 实验中，采用了两项不同的指标来衡量 Certaindex：奖励分数 R 与基于熵的测量值 Ĥ。仅当所有指标均超越其阈值时，Program 才会视其满足确定性要求。

4.3 Certaindex 的有效性

本节中，作者通过实验证明，Certaindex 在多种模型、Reasoning 算法及任务上与达到正确解所需的计算资源呈现强相关性。较高的 Certaindex 值始终预示着较低的总计算需求。

相关性。作者在 Reasoning 过程的中间步骤测量 Certaindex，并分析其正确答案所需实际步骤数之间的相关性。Query 被分类为可解与不可解两类，其中不可解 Query 即便在近乎无限的计算资源下也无法产生正确答案。如下图 Figure 3 展示了 12种（模型、算法、任务）配置下的这种相关性。对于可解 Query，Certaindex 与所需计算资源之间的 Pearson 相关系数介于 0.17 至 0.75 之间（平均值为 0.52），表明高 Certaindex 与解决 Query 需要较少步骤之间存在强相关性。

基于阈值的分配策略。作者在特定 Reasoning 步骤（如上图 Figure 3 中红色垂直线标示）测量 Certaindex。一种直接的分配策略是设定一个阈值 t（橙色水平线），并停止对任何 Certaindex 超过 t 的 Query 进行 Inference。在所有图中，几乎无可解 Query 都落在红线和橙线之外的右上区域，表明适当选择的 t 值能在 Certaindex 超过 t 时有效提前终止 Query。对于这些 Query，此策略既减少了可解 Query 的资源消耗，又防止了对不可解 Query 的过度资源分配，且不牺牲准确性。

帕累托边界（Pareto front - Wikipedia [2]）分配策略。理想情况下，一种更为精细的分配方式，如上图 Figure 3 中拟合的绿色曲线所示，动态地为每个 Certaindex 值确定最大 Inference 计算资源分配。除了仅影响 Certaindex 超过 t 的 Query 的基于阈值的分配外，此策略在保持准确性的同时，为所有 Query 在任何 Certaindex 值下设定资源上限。

4.4 对比 Certaindex 与其他信号

作者将 Certaindex 与两种替代指标进行比较，以评估资源需求：

Reasoning 路径长度（Length）：较长的 Reasoning 路径（更多 Token）通常意味着问题难度更高，暗示路径长度与计算需求之间可能存在关联。
平均归一化对数概率（Log P Entropy）：作为 LLM 置信度的衡量标准，较高的对数概率可能意味着在 SC 中获取正确答案所需的样本量减少。

在（SC, GSM8K, Llama3.1-8B-instruct）实验下，作者评估了 Certaindex 与这些指标的表现。如下图 Figure 5 所示，H（蓝色）与实际计算需求的相关性最强，优于其他指标，并与复杂组合相当。

4.5 刻画 Certaindex 与检测步骤之间的关系

如下图 Figure 4 展示了在 GSM8K 数据集上使用 Llama3.1 8B Instruct 模型进行单次运行中，不同检测点处 Certaindex 值与程序步骤之间的关系。该图由 6 个子图组成，每个子图代表一个不同的检测步骤，范围从 5 到 30，由 “Detect @knob” 值表示。

图中的每个点代表一个单独的问题，分为三种类型：可提前终止问题（粉色）、可解决问题（蓝色）和不可解决问题（灰色）。x 轴表示所采取的步骤数，而 y 轴显示 Certaindex 值。水平的橙色虚线表示 Certaindex 阈值，垂直的红色虚线表示了收集 Certaindex 的步骤。

所有检测点显式了一致的模式，Certaindex 与所需 Reasoning 步骤之间存在强相关性，可解决问题中的 Pearson 相关系数超过 0.5。随着检测步骤从 5 增加到 30，作者观察到可提前终止问题增加了 30%，这表明较高的 Certaindex 值可靠地预测了 LLM 何时收敛到最终答案。然而，这种提高的准确性可能导致增加计算成本，因为较晚的检测点导致留给提前终止的机会减少。

五、Dynasor：系统设计

5.1 系统概览

作者进一步提出了一个端到端的 LLM Serving 系统 Dynasor，该系统利用 Certaindex 优化 Reasoning Program（可以理解为 Reasoning 任务或算法的执行过程）。Dynasor 提供了一个简洁的接口，支持多种 Reasoning 算法，并整合了资源分配与请求调度，以实现高效的 LLM 服务。

如下图 Figure 6a 展示了 Dynasor 的架构，由三个主要组件构成：

Reasoning Program 抽象（Reasoning Program Abstraction），为 Reasoning 算法提供统一接口。
应用运行时（Application Runtime），基于 Certaindex 动态分配资源。
系统运行时（System Runtime），负责后端请求级别的调度管理。

开发者可以通过 Dynasor 提供的抽象定义 Reasoning Program，实现 Certaindex 及扩展控制功能。这些 Program 提交至应用运行时，应用运行时监控 Certaindex 值，动态调整资源分配，并将请求转发至系统运行时执行。Program 在资源不再分配时，要么扩展以进行进一步计算，要么提前终止。

5.2 Reasoning Program 抽象

Reasoning Program 维护三项运行时属性：

certaindex，衡量 Reasoning 进程的确定性程度。
knob，Program 内在的缩放系数。
state，存储中间变量及先前步骤的结果。

如上图 Figure 6b 展示了一个 Reasoning Program 的结构。开发者仅需实现：

update_certaindex()，在特定 Inference 步骤计算并更新 certaindex。
execute()，执行 Reasoning 算法。

如上图 Figure 6c 展示了 SC 的实现示例：update_certaindex() 函数计算不同分支的熵，execute() 函数则迭代地扩展生成过程。每次迭代后，汇总结果并更新 certaindex。此过程循环进行，直至 Program 耗尽资源或退出。

5.3 应用运行时

5.3.1 基于 Certaindex 的 Intra-Program Scheduler

基于 Certaindex 的 Intra-Program Scheduler 在运行时控制 Program 的资源分配。Scheduler 的生命周期描述如下：

初始化阶段。当新 Program 到达时，Scheduler 以预设的最大资源上限对其进行初始化，并为其首次运行分配资源。同时，建立资源调度策略以指导未来的资源分配。

资源分配阶段。Scheduler 持续监控每个 Program 的 certaindex，并据此决定资源分配。Program 在运行过程中，会不断向 Scheduler 请求资源，同时更新其 certaindex 以反映 Reasoning 进度。当多个 Program 并发运行时，Scheduler 可通过基于 certaindex 的 Intra-Program 分配策略，在它们之间优先分配资源。

终止阶段。当 Program 的 certaindex 超过其分配策略设定的阈值或达到最大资源上限时，Scheduler 将拒绝为该 Program 进一步分配资源。随后，Program 接收到终止信号，并根据其生成历史汇总结果。

5.3.2 基于 Profiler 的策略校准

Program 提交者通常缺乏对运行时模式的深入理解，且 Program 特征可能因算法变更或数据分布变化而发生改变。确定有效的资源分配策略对于 Program 性能至关重要。

Dynasor 提供了一个可选的基于 Profiler 的超参数 Scheduler，以协助用户确定基于 certaindex 的最优调度策略。用户提交一批带有标注数据的 Program——如已验证的问题答案（例如，数学题解）、响应排序或 Reward 模型评分。Profiler 收集运行时指标，包括 certaindex 和 Token 使用量，以确定在满足精度要求的前提下，不同 certaindex 范围内的最优资源分配。对于基于阈值的分配策略，当 Program 的 certaindex 超过阈值时，Profiler 停止分配资源，否则将资源设置为最大上限。阈值经过校准以满足精度要求（例如，在所有校准数据点上不损害精度）。此校准过程可在实际服务场景中定期执行，以适应数据分布变化的动态性。

5.4 系统运行时

5.4.1 Program 感知 Inter-Program Scheduler

Program 感知 Inter-Program Scheduler 在 Program 级别优化调度与内存管理，通过两项关键策略降低单个 Program 的延迟：

采用 Gang Scheduling 算法优先处理源自同一 Program 的请求。
实施近似最短作业优先（SJF）Scheduling 算法以减少队头阻塞（Head-of-the-Line，HoL）并改善单请求时延。

Gang Scheduling。将同一 Program 的请求归为一组，旨在减少滞后任务并缩短整体完成时间。如下图 Figure 7 通过两个 Program 在 t=0 时刻到达、系统 Batch Size 为 2 的示例，展示了 Gang Scheduling 相较于顺序调度的优势。

SJF Scheduling。可以缓解 HoL 并改善各 Program 的平均时延。Program 的总执行时间取决于两个关键因素：总计算需求（如分支/迭代次数等可调参数）及每次分支/迭代的 Token 长度。尽管每次分支/迭代的确切 LLM 生成长度无法预先知晓，但可以利用 Program 局部性并参考前次迭代的历史平均值来估算每次迭代的 Token 长度。此估算结合计算需求，有助于预测总执行时间。在 Dynasor 中，certaindex 控制总计算需求（决定运行多少次迭代），而 SJF 则利用每次迭代的估算 Token 长度来优化执行顺序。

防饥饿机制。Dynasor 倡导完成时间公平性，仅采用 Gang Scheduling 能显著提升性能且不会引发饥饿问题，但加入 SJF 优化可能潜在地导致预估长度较长的 Program 遭遇饥饿。对于采用 SJF 的部署场景，作者实施了一种优先级提升机制，即等待过久的 Program 将获得提升后的优先级，从而有效防止饥饿。

5.4.2 其他系统运行时组件

Prefix Cache Manager。Dynasor 利用了 prefix cache sharing 机制。

Program 的独立分支共享统一的 Prompt KV-cache，而依赖的 Reasoning 链则复用其最长公共前缀。
对于采用 Reward 模型的算法，Dynasor 在奖励评估过程中复用前缀，从而降低延迟。
Manager 还负责自动淘汰 cache。当内存受限时，无活跃请求 Program 的 KV-cache 被赋予较低优先级并优先淘汰。

Program Context Manager。是一个轻量级封装层，用于追踪已注册 Program 及其运行时特征。根据 Program 行为向 Prefix Cache Manager 提供 cache 淘汰提示。与 SGLang/ParrotServe 中使用的静态 Program 有向无环图（DAG）不同，该组件通过支持如 MCTS 和 Rebase 等算法所需的动态生成模式，提供了更高的灵活性。

执行后端。负责管理 LLM 请求的执行，通过 CUDAGraph 等技术优化模型性能。该层设计为可适配多种执行引擎，包括 vLLM、TensorRT 和 SGLang。

5.5 系统实现

作者基于 SGLang（版本 0.3.3 post1）构建 Dynasor。Intra-Program Scheduler 作为客户端的一个 Python 库实现，而 Inter-Program Scheduler 则集成到服务器端的调度器中。

通过 Dynasor，作者将多种 Reasoning 算法适配到 Program 接口。系统包含约 3000 行 Python 代码，涵盖了 Program 接口、应用程序运行时和系统运行时。

每个 Reasoning Program 的适配需要额外 40 到 150 行代码来定义 certaindex 逻辑并与 Program 接口集成。与这些算法原始实现（代码量可达 4000 行）相比，这一实现开销极小。

六、评估

6.1 实验配置

如下图 Table 2 和 Table 3 分布为离线 Batch 和在线场景的工作负载：

如下图 Table 1 所示为针对每种任务的 certaindex 超参数：

6.2 离线 Batch Processing 场景

基线，主要是对比改进的 Intra-Program Scheduler：

baseline-even：在所有 Reasoning Program 间均匀分配资源。不同上限会导致不同的准确率。具体而言，所有 Query 都获得相同的资源：SC 使用相同数量分支，Rebase 使用相同的宽度，MCTS 使用相同搜索迭代次数。
baseline length：使用在特定步数（Table 中的 Detect@knob）生成的累计 Token 数作为 Program 的结束信号。

如下图 Figure 8 对比了不同工作负载下 Token-准确率指标。作者的方法在不同工作负载下均优于所有基线，在不牺牲准确率的前提下，相比 baseline-even 减少 9%-48% 的 Token；相比 baseline-length 减少 9%-52% 的 Token。这些收益主要源自于 Intra-Program Scheduling 算法。

6.3 在线服务场景

基线，主要是对比改进的 Inter-Program Scheduler：

SGLang：集成了最长前缀匹配算法，能高效地处理具有共同前缀的请求，减少冗余计算。
ParrotServe：采用 Gang Scheduling（App-FIFO）策略，优先处理同一 Program 内的请求。

速率 vs SLO 达成率：在 P90 截止时间达成率下，本文系统相比 SGlang 和 Parrot 分别提升了 1.6x-3.3x 和 1.6x-3.2x。
SLO scale vs SLO 达成率：Dynasor 允许更严格的 SLO scale，比 SGLang 严格 1.3x-4.7x，比 Parrot 严格 1.7x-3.3x。
准确性 vs SLO 达成率：在所有 3 个工作负载下，Dynasor 在相同 SLO 达成率下比 SGLang 和 Parrot 实现了 0.7%-2% 的准确率提升。