Thompson Sampling 如何优化 LLM 路由：从贝叶斯探索到生产成本控制

先说结论：模型路由不是一张静态排行榜

Ramp Builders 在 2026 年 7 月发布的文章 Online Learning for Cost-Efficient LLM Routing，介绍了他们如何在内部 LLM Gateway 中使用 Thompson Sampling，在线学习模型及服务等级的延迟表现，并结合供应商失败率、调用时限和成本，动态调整候选路由顺序。Ramp 报告称，在一组更大流量的实验中，成本下降了 26.3%，错误率变化为下降 0.09 个百分点；另一个以流式响应为主的用例节省约 30%。这些是 Ramp 报告的生产结果，不应直接外推为所有应用都能获得的收益。

这篇文章最值得学习的地方，并不是“用某个算法挑便宜模型”，而是把三个原本分开的信号放进同一个在线决策循环：失败率，即供应商是否正在限流或发生服务侧故障；延迟分布，即在当前场景里有多大概率赶不上 deadline，而不只是平均响应要多久；以及调用成本，即当多个候选都能满足业务要求时，优先使用成本更低的选项。

算法也不是一次性选出永久最优的模型，而是持续观察反馈，在探索尚不确定的候选项和利用当前表现较好的候选项之间动态调整。

一、为什么模型路由需要在线学习

很多系统最初使用静态优先级：首选模型失败后再尝试第二个，依次回退。这能表达应用对模型的偏好，也容易理解和排查，但它隐含了一个假设：候选项的相对表现大致稳定。

现实中的模型服务并不满足这个假设。服务端负载、地区、时段、配额、限流、供应商内部调度，以及 Standard、Flex、Priority 等服务等级，都可能改变实际延迟和失败概率。同一个模型在深夜可能很快，在业务高峰时却可能持续排队；一个更便宜的服务等级可能在大部分时间都足够快，但在高峰期发生明显退化。

仅根据历史平均延迟做静态排序会遇到两个问题。首先，过去快不代表现在快，历史均值会掩盖短期变化。其次，均值不能刻画尾部：对于有六秒硬超时的用户交互，平均两秒的模型并不一定安全，关键是它超过六秒的概率有多大。

这使模型路由更像一个在线决策问题：每次请求都要在满足业务约束的候选项中作出选择，之后再用真实结果更新对候选项的判断。

候选项不只是模型名称

Ramp 的示例把模型与服务等级作为独立候选项。同一个 Gemini 模型的 Flex、Standard 和 Priority 可以有不同的价格、延迟和可用性；不同供应商的模型则有不同的能力与服务特征。因此，“选哪个模型”实际可能是在选择一个路由组合：

这些维度不应不加区分地合并统计。面向六秒交互场景的路由策略，未必适用于后台批处理；擅长代码生成的模型，也未必能替代金融信息抽取任务中的质量基线。后文会讨论如何划分统计上下文，以及为什么质量和安全条件应先于成本排序。

二、Thompson Sampling：不是随机挑选，而是把不确定性纳入决策

Thompson Sampling 是一种常用于多臂老虎机（Multi-Armed Bandit）的贝叶斯在线决策方法。名字来自一个经典比喻：有多台老虎机，每台的回报概率未知，每次只能拉其中一台。系统既想尽量获得高回报，又需要试用那些可能更好、但目前证据还不足的选项。

把每个模型路由组合看作一台老虎机，就能理解它解决的问题。某个候选目前看起来最好，可能因为它确实表现优秀，也可能只是样本少、运气好。另一个候选目前的观测均值略差，却可能因为数据不足而仍有相当概率表现更好。

Thompson Sampling 的做法是：为每个候选维护一个关于真实表现的概率分布；每次决策时，从各自的后验分布中采样一个可能的真实参数；再根据采样结果计算候选得分，选择得分最高的候选。拿到请求结果后，系统更新相应候选的统计分布。

flowchart TD
    A[接收请求与业务约束] --> B[筛出允许使用的模型和服务等级]
    B --> C[读取各候选的在线统计状态]
    C --> D[为未知性能参数采样]
    D --> E[估计失败与超过 deadline 的风险]
    E --> F[结合成本和调用方偏好计算路由分数]
    F --> G[排序并尝试首选候选]
    G --> H{请求成功且满足时限？}
    H -->|是| I[记录延迟、成本与结果]
    H -->|否| J[按回退策略尝试下一候选]
    J --> I
    I --> K[更新失败率和延迟后验]
    K --> C

探索与利用如何平衡

假设路由 A 的成功率已观察几万次，估计很稳定；路由 B 只观察了十几次，当前平均延迟略高，但不确定性也很大。如果总是选当前平均表现最好的 A，系统可能永远无法发现 B 在某些时段更有优势。

Thompson Sampling 不需要设置一个固定比例，比如“每 100 次请求中的 5 次用于探索”。它通过参数分布体现不确定性：数据不足的候选通常拥有更宽的后验分布，因此在某些采样轮次中可能获得更好的估计值，被选中的机会也更高；随着观测增加，分布会逐步收敛，路由会更频繁地选择证据支持的优势候选。

这里的“随机”不是任意抽签。候选的入选概率由已有数据、先验假设和决策目标共同决定。探索不是额外增加的一项业务流量，而是在线决策本身对不确定性的处理方式。

不过，Thompson Sampling 并不意味着系统一定能在任意变化的环境中找到全局最优路由。经典多臂老虎机分析通常建立在一组明确假设上；真实模型服务会发生漂移，候选之间可能并不等价，deadline 和成本也会变化。因此，生产系统需要用近期统计、上下文切片和持续监控应对非平稳环境，不能只套用算法名称就认为问题已经解决。

三、Ramp 如何分别估计失败率和延迟风险

原文没有把失败率与延迟塞进同一个指标，而是分开建模，再在选路时组合。这是一个重要的设计选择：失败与慢响应是不同的故障模式，触发机制不同，治理措施也不同。

3.1 用 EWMA 追踪近期失败率

Ramp 使用指数加权移动平均（EWMA）跟踪失败率，只纳入真正由供应商侧导致的故障，例如限流和服务端错误。调用方发送了非法参数、请求格式错误等问题，不应该被统计成“模型服务不可靠”，否则路由器会惩罚一个本来运行正常的候选。

EWMA 的直觉是给最近的观测更高权重，较早的观测权重则随时间衰减。它与简单的全历史平均不同：如果某个供应商刚刚开始限流，最近的错误会更快地改变估计值；当服务恢复后，近期的成功结果也会逐渐把估计值拉下来。

它需要在响应速度与噪声之间权衡。更新过快会对偶发错误反应过度，更新过慢则可能在限流已经发生后仍大量选择故障候选。实际实现还需要明确失败分类、采样窗口、更新频率、初始值与衰减速度。Ramp 的文章解释了所采用的思路，但没有公开这些配置的完整数值。

3.2 为什么要对数延迟建模

延迟是正数，并且在生产系统里经常呈现右偏长尾：大部分请求很快，少量请求却因排队、重试或服务抖动变得很慢。如果直接假设原始延迟服从对称的正态分布，可能会低估长尾风险。

Ramp 对延迟取对数，并对对数延迟的均值和方差建模。换言之，假设延迟 L 的对数近似服从正态分布：

• 原始延迟始终大于零。
• 对数转换可以把乘法尺度上的差异变得更适合统计建模。
• 如果对数延迟近似正态，原始延迟可用对数正态分布描述，从而估计超过任意 deadline 的概率。

这里的重点不是“延迟一定严格服从对数正态分布”。这是一个可用于在线计算的建模假设，仍需结合真实的延迟分布、尾部表现和残差检查来验证。供应商服务的延迟可能是多峰分布，例如部分请求命中缓存、部分请求走慢路径；这时单一分布可能过于简单。

3.3 Normal-Inverse-Gamma 后验在做什么

原文使用 Normal-Inverse-Gamma（NIG）共轭先验描述对数延迟的未知均值和方差。对非贝叶斯读者，可以把它理解为同时维护两类不确定性：

• 当前路由的典型延迟到底有多快，即未知均值的不确定性。
• 这条路由的波动与长尾到底有多严重，即未知方差的不确定性。

当新请求完成时，系统不需要把全部历史原始样本重新读入内存。它可以累积样本数、对数延迟的均值与离差平方和等充分统计量，再更新后验参数。Ramp 提到这些统计状态被汇总存储在 Redis 中，这使多个请求处理进程可以共享在线学习所需的状态。

原文给出的更新式为：

κₙ = κ₀ + n

μₙ = (κ₀ × μ₀ + n × meanLog) / κₙ

αₙ = α₀ + n / 2

βₙ = β₀
     + 0.5 × deviationSum
     + κ₀ × n × (meanLog − μ₀)² / (2 × κₙ)

其中，μ₀、κ₀、α₀、β₀ 是先验参数；n 是已观测样本数；meanLog 是对数延迟的样本均值；deviationSum 是对数延迟相对于样本均值的离差平方和。参数的精确定义与先验初始化必须保持一致，否则不同进程的更新会产生不兼容的状态。

这些公式本身并不会直接告诉路由器“下一次应该选谁”。它们的作用是更新不确定性模型。决策时，算法从后验中抽样得到可能的均值和方差，再用它们计算延迟超过 deadline 的概率；这个概率会继续参与候选路由的评分。

一个实现层面的细节是：NIG 的优势在于可以用小规模充分统计量进行在线更新，但前提是统计口径稳定。比如不能把不同 deadline、不同请求类型或完全不同的工作负载不加区分地混进同一条延迟分布，否则均值和方差即使计算正确，也不再代表某个具体决策场景。

四、如何把失败率、超时概率和价格合并

对于有 deadline 的请求，Ramp 把“坏结果”定义为两种情况之一：调用直接失败，或者调用没有直接失败但响应时间超过业务时限。

原文使用的公式是：

P(bad_outcome)
  = P(failure)
    + (1 − P(failure)) × P(latency > deadline)

举个直观的例子。某路由的供应商失败概率是 2%；在没有发生这类失败的请求中，有 5% 超过 deadline。那么坏结果概率为：

2% + (1 − 2%) × 5% = 6.9%

为什么不是简单的 2% + 5%？因为第二项被定义为“未直接失败的前提下超时”的风险，概率要乘上请求没有直接失败的概率。这种写法把两类结果分开计算，避免在概率口径一致的条件下重复计数。

在 Ramp 的方案里，失败率来自前一步的 EWMA；超时概率则通过采样后验里的对数延迟均值和方差，并计算分布位于 deadline 右侧的面积得到。如果某次采样结果为 μ、σ²，且对数延迟近似正态，那么：

P(L > d | μ, σ²) = 1 − Φ((ln(d) − μ) / σ)

其中 d 是 deadline，Φ 是标准正态分布的累积分布函数。Thompson Sampling 的关键在于，μ 和 σ² 不是被视为完全确定的数字，而是从当前后验分布中抽样得到。于是系统不仅考虑“当前估计有多慢”，还把“我对这个估计有多确定”带进决策。

最后，路由器将风险与相对成本组合成候选分数，排序后尝试首选模型，如果调用失败则按回退策略继续。这里有一个必须说明的边界：Ramp 的文章没有披露最终评分函数的完整表达式、成本归一化方式和风险权重。 因此，能够从文章重建的是它的算法结构和风险估计方法，而不是声称写出一段代码就能逐项复现 Ramp 的生产路由器。

一个生产实现可以选择不同目标，例如先设定最大失败概率和最大超时概率，再在可行候选中最小化成本；也可以把成本与坏结果风险合成为统一的效用函数。但两种设计表达的是不同的风险偏好，必须通过业务 SLO 与实验来确定，不能从 Thompson Sampling 这个名称中自动推导出来。

五、案例复盘：为什么系统会在故障时切换，恢复后又切回来

Ramp 把这一策略先用于一个有六秒 deadline 的 LLM reranker。最初的候选偏好列表较短，主要包括 Gemini 3.1 Flash Lite Standard 和 GPT 5.4 Nano Standard。之后他们扩大了候选集合，把相同模型的不同服务等级也加入路由选项：

这个扩展很重要。路由器的决策不再只是“Gemini 还是 GPT”，还包括“同一个模型应该走哪种服务等级”。它能利用模型能力相同、但价格或运行特征不同的候选之间的差异。

部署时，Gemini 3.1 Flash Lite 正好处于限流较严重的时期。系统的候选份额迅速转向 GPT 5.4 Nano；在 Gemini 恢复后，流量又逐渐回流。这个变化说明，路由的选择依据不是永久写死的供应商偏好，而是近期观测和模型不确定性。它也反映了为什么只做“失败后回退”往往不够：当首选仍然偶尔成功、但持续变慢或频繁触发限流时，系统可能需要在错误彻底发生之前就重新排序。

文章还报告了一个有意思的选择：系统使用了 GPT 5.4 Nano Flex，而不是 GPT 5.4 Nano Standard。原文列出的同期数据如下：

从中位数和平均延迟看，两种服务等级的差异很小，Flex 的典型延迟略高；但在相似延迟表现下，Flex 的价格约为 Standard 的一半，路由器因此可以选择更便宜的候选。

这里值得留意一个细节：两种服务等级的 P95 都超过了六秒 deadline。 这与“典型延迟远低于时限”并不矛盾，却意味着不能把均值或 P50 当成 SLA 保证。只看平均延迟，容易低估尾部请求超时的风险。Ramp 的思路通过估计超过 deadline 的概率处理这一点；在自己的系统里复现时，必须验证这个概率估计与真实超时率是否相符。

Ramp 报告的更大流量实验结果是成本节省 26.3%，错误率变化下降 0.09 个百分点。此后，他们又将该策略实现为适用于流式场景的版本，并用于 Ramp Inspect，报告节省约 30%。这些数字说明在线路由可能同时改善成本和可靠性，但公开文章没有给出足以独立复算的完整实验设置，例如完整流量构成、成本口径、实验置信区间以及所有质量指标。因此，它们适合作为生产实践的信号，不应被当作在不同任务和供应商组合下的收益承诺。

六、这套策略与常见路由方案有什么区别

它们并非相互排斥。生产路由器完全可以用确定性规则管理不可妥协的约束，用健康检查和熔断器处理明显故障，再让 Thompson Sampling 对剩余的合格候选做在线排序。在线学习不应取代所有已有可靠性机制。

七、从文章走向生产：几个必须补齐的工程问题

Ramp 的文章给出了有价值的设计，但如果把它应用到自己的 LLM Gateway，还需要补齐以下内容。

7.1 先做资格筛选，再进行概率排序

不是所有候选都能互换。模型是否支持工具调用、结构化输出、长上下文、流式传输或指定的多模态输入，属于能力约束；数据驻留、隐私、供应商合同和业务安全要求属于策略约束；任务的准确率、格式正确率或人工覆盖率则是质量约束。

这些条件应先过滤候选，再对合格集合做 Thompson Sampling。否则，低价格或低延迟可能让一个能力不足的模型赢得路由，表面上成本降低，实际却增加业务错误和后续补救成本。

7.2 定义统计上下文，避免把不同工作负载混成一锅

每种调用的延迟分布可能不同。同步用户请求、后台批任务、长上下文推理和短分类请求，适合的 deadline 与风险偏好也不同。统计上下文至少需要考虑任务类别、模型、供应商和服务等级；必要时还要区分区域、流式与非流式请求，以及输入规模区间。

但切得太细也有代价：每个分区的流量变少，后验收敛变慢，冷启动更频繁。实践中可以从稳定且有业务意义的切片开始，对低流量分区采用合理的先验或分层共享信息，但必须明确哪些统计量可共享、哪些不可共享。共享统计量时不能把完全不同的工作负载假设成同一种分布。

7.3 处理环境漂移，而不是迷信全历史数据

模型服务的性能可能在数分钟内发生变化。EWMA 能让失败率估计重视近期信号；延迟统计也需要考虑时间衰减、滚动窗口或近期与历史统计的结合。窗口越短，对变化反应越快，但噪声越大；窗口越长，估计越稳定，却可能滞后于新状态。

这不是一个只靠公式就能决定的参数。需要回放真实流量或用模拟场景测试：突然限流、缓慢退化、短时尖峰、故障恢复、低流量冷启动和不同候选性能接近时，算法分别如何响应。

7.4 小心被 timeout 截断的延迟样本

如果请求在六秒时就被客户端取消，观测到的可能是“至少六秒仍未完成”，而不是服务端的真实完成延迟。如果把这个样本当作一次准确的六秒延迟，可能低估慢请求的真实尾部；如果直接丢弃，则可能让延迟估计偏向成功完成的快请求。

系统应区分完成响应、供应商失败、客户端取消、deadline timeout，以及重试或回退后的最终结果。可以用单独的 deadline-miss 指标、对超时样本进行正确处理，或采用更适合删失数据的统计方法。无论使用哪种方法，都应验证在线估计的超时概率与真实线上超时率是否校准。

7.5 选择结果与最终业务结果要分开记录

如果首选候选失败后，系统改用第二候选并最终成功，那么这次请求在用户视角可能成功，但路由器仍应知道首选候选发生了失败。这涉及两个不同的指标：

• 尝试级指标：每个模型路由尝试的失败、延迟、消耗和服务等级。
• 请求级指标：整个请求最终是否成功、是否超过总 deadline、是否满足质量要求，以及重试带来的总成本和额外延迟。

两种统计口径都很重要。只记录最终请求成功，会掩盖首选候选正在恶化；只看每次尝试的成功率，又无法判断整条 fallback 链的业务表现。成本账单也应把失败尝试和重试消耗计入，不能只统计最终成功调用。

7.6 探索流量需要保护措施

探索机制会让某些当前表现不确定的候选获得请求。生产系统仍然需要硬性边界，例如最大失败率、最大 deadline-miss 概率、供应商熔断状态、单候选预算上限，以及质量回归门禁。处在严重限流或已知故障状态的候选不必继续被概率探索；它可以先由确定性策略暂时移出候选集，待健康信号恢复后再有限度地重新进入。

同时需要防范反馈偏差：由于路由器只观察实际被选中的候选，未被选中的候选不会自动获得新样本。Thompson Sampling 用概率探索缓解了这一问题，但如果健康检查、候选过滤或流量规则长期把某个候选排除在外，它仍然无法学习该候选当前的真实表现。

7.7 路由器不能只优化成本与延迟

Ramp 这篇文章的核心目标是失败、时限和成本。对于实际的 LLM 应用，还应保留任务质量的独立门槛，例如分类准确率、抽取字段正确率、结构化输出有效率、工具调用成功率或人工覆盖率。一个延迟更短、价格更低的模型，如果导致业务错误显著增多，就不是更好的路由选择。

不要把所有目标都未经验证地压成一个分数。对高风险调用，更适合先设定质量、权限和可靠性门槛，再在通过门槛的候选中优化成本；对低风险、允许近似的请求，才可能接受更积极的成本—质量折衷。评分函数表达的是业务风险偏好，而不只是数学实现细节。

八、一个可以落地的分层架构

生产系统可以把路由拆为四层：资格与策略层、在线估计层、候选决策层、观测与更新层。这样既能使用 Thompson Sampling，也不会让概率算法绕过既有的可靠性、权限和审计机制。

flowchart TB
    subgraph Policy[资格与策略层]
        A[调用方模型偏好] --> C[能力与策略约束]
        B[质量门槛和 deadline] --> C
        C --> D[合格候选集合]
    end

    subgraph Learning[在线估计层]
        E[供应商失败事件] --> F[失败率 EWMA]
        G[完成延迟与 timeout 事件] --> H[延迟充分统计量]
        H --> I[NIG 后验状态]
    end

    subgraph Decision[候选决策层]
        D --> J[Thompson 参数采样]
        F --> K[候选风险估计]
        I --> J
        J --> K
        K --> L[结合相对成本和偏好评分]
        L --> M[路由排序与 fallback]
    end

    subgraph Feedback[观测与治理层]
        M --> N[请求级与尝试级结果记录]
        N --> E
        N --> G
        N --> O[成本、质量、超时和漂移监控]
        O --> P{超过安全阈值？}
        P -->|是| Q[熔断、降级或回滚]
        P -->|否| R[持续学习]
    end

建议明确以下运行边界：

• 资格筛选、权限校验、候选黑名单和熔断器属于确定性控制，不应由后验采样覆盖。
• 在线学习状态需要版本化并可恢复，至少记录统计窗口、先验版本、参数更新、数据口径和候选定义的变化。
• 每次路由都应记录候选集合、排除原因、采样或决策摘要、最终尝试顺序、回退原因以及对应的成本和延迟。
• 当评分逻辑、先验、上下文切片或供应商接口发生变化时，应视为路由策略变更，进行离线回放和分阶段发布，而不是把它当成无风险的配置修改。

九、建议怎样验证，而不是直接上线

可以先从离线回放开始，但回放需要注意一个限制：如果历史数据只记录了原策略选中的模型，就缺少其他候选在同一请求时刻的结果，无法简单地模拟“如果当时选了另一个模型会怎样”。因此，完整的反事实评估可能需要额外的影子流量、受控探索数据，或经过验证的服务性能模拟；不能只把历史平均延迟塞进算法，然后把回放结果当作真实实验。

一个相对稳妥的推进顺序是：

1. 建立基线。 记录请求级最终成功率、尝试级供应商失败率、deadline-miss rate、P50/P95/P99、单请求总成本、回退次数与任务质量指标。
2. 验证估计器。 检查 EWMA 是否能及时响应限流和恢复；检查模型估计的超时概率是否校准；检查不同工作负载的延迟分布是否适合当前假设。
3. 影子运行。 计算新路由器会选择什么候选，但暂不影响真实流量。比较它与当前路由的建议差异，并检查是否违反调用方偏好、质量或策略约束。
4. 小流量试点。 通过显式的流量上限、预算上限和自动停止条件，将真实请求逐步交给新策略。候选切换应可追踪，出现异常时能回到确定性的静态路由。
5. 按业务结果评估。 不仅看平均成本是否下降，还应检查错误率、超时率、尾部延迟、质量和回退后的总耗时是否恶化，并报告样本量、观察窗口和统计不确定性。
6. 持续监控与复核。 供应商模型、价格、服务等级或限流行为发生变化时，重新检查目标函数与质量门槛，避免路由策略静默漂移。

最重要的一点是：不能只用“成本下降”判定成功，也不能把“Thompson Sampling 是成熟算法”当作上线凭据。真正的证据来自明确的业务指标、可解释的候选变更、可靠的事件数据和受控的线上实验。

十、哪些场景值得采用

Thompson Sampling 更适合有足够请求量、存在多个合格候选、候选表现随时间变化，而且每次选择都能收集有用反馈的系统。例如，LLM Gateway、Embedding 服务、OCR/文档解析供应商选择、多个外部 API 的自适应路由，都可能受益于类似思路。

但有些场景并不适合一开始就做复杂的在线优化：请求量太低，无法快速学习；候选在质量、权限或数据处理边界上根本不可互换；失败代价过高，不允许在线试探；或者业务时限和候选分布高度不稳定，却没有足够监控与回退能力。此时应先做好确定性资格筛选、健康检查、熔断和静态回退，再考虑引入概率路由。

还要区分两个经常被混为一谈的问题：模型选择和工作流选择。Thompson Sampling 可以用于在合格模型之间选择服务路径，但它不会自动决定一个任务是否应该使用 Agent、是否要调用工具、是否需要更长推理，或是否应将任务交给人工处理。这些决策有不同的动作空间、反馈信号与风险约束，不宜为了“统一路由”就把它们全部混到同一个统计模型里。

结语

Ramp 的工程实践说明，LLM Gateway 不应只是一层统一 API、鉴权和账单代理。它还可以成为持续优化的决策层：从生产请求中学习服务真实表现，把近期失败、延迟尾部、deadline 与价格统一纳入路由策略，再通过反馈不断调整。

Thompson Sampling 的价值，在于把“我们对某条路由有多确定”也纳入选择，而不只是比较历史平均数。但它并不替系统回答所有问题：哪些模型有资格参与、质量底线是多少、超时风险如何定价、统计上下文怎么切分、反馈数据是否有偏，以及异常时如何止损，仍然必须由工程架构和业务策略明确规定。

实际落地时，建议把 Thompson Sampling 视作合格候选集合上的在线优化器，而不是安全策略、质量门禁、健康检查或可观测性的替代品。先把这些边界建好，再让算法优化边界以内的成本与性能，才更可能在真实生产系统里获得长期收益。

参考资料

1. Kedar Thakkar, Online Learning for Cost-Efficient LLM Routing, Ramp Builders, 2026-07-20。本文的主要案例、模型、公式与实验结果来源。
2. Ramp Builders, Make Better Decisions by Embracing Uncertainty, 2024-06-11。关于 Thompson Sampling、多臂老虎机和在线探索与利用的入门解释。