ContinuityBench：多提供商大语言模型路由中有状态故障转移的基准测试与系统研究

# ContinuityBench：多提供商LLM路由中有状态故障切换的基准测试与系统研究

来源：https://arxiv.org/html/2607.15899
Vishal Pandey Metriqual 英国伦敦 vishal@metriqual\.com & Gopal Singh Metriqual 希腊雅典 gopal@metriqual\.com

###### 摘要

在生产环境的大型语言模型 \(LLM\) 部署中，高 API 可用性保证并不等同于对话连续性。当主提供商发生故障或严格限流时，无状态故障切换机制虽然能成功维持正常运行时间，但会静默丢弃对话历史，严重破坏用户体验。为了严谨地量化并解决这种故障模式，我们引入了两个新指标：连续性保持率 (Continuity Preservation Rate, CPR) 和连续性延迟开销 (Continuity Latency Overload, CLO)。我们提出了一种有状态的多提供商代理架构，利用历史转发 (History-Forwarding) 策略在故障切换期间跨异构 LLM 端点无缝重建对话状态。此外，我们发布了 continuity-bench^1^[https://github.com/Vishal-sys-code/continuity-bench](https://github.com/Vishal-sys-code/continuity-bench)，这是一个开源评估框架，旨在高并发提供商故障条件下压力测试上下文保持能力。我们的实证评估（\(N=750\) 次故障切换事件）表明，有状态代理实现了 99.20% 的 CPR [95% CI: 98.27%, 99.63%]，能够将深层对话上下文干净地转移到备用提供商，而标准无状态架构的保持率接近 0%。最后，我们刻画了故障切换延迟分布，指出了带抖动的异步指数退避对于防止针对严格限流备用 API 的级联重试风暴的关键必要性。我们的结果为构建鲁棒的、保持状态的多模型推理系统提供了原则性基础。

*关键词* LLM 服务⋅多提供商路由⋅故障切换⋅对话连续性⋅LLM 作为评判者⋅分布式系统可靠性

## 1 引言

语音代理在提供商故障切换时并不会崩溃。它会遗忘。考虑以下故障场景，这一场景是在一次常规调试过程中观察到的，并最终促成了这项工作。一个主 LLM 提供商经历了持续十一秒的短暂中断。重试逻辑完全按设计执行：请求被重新路由到备用提供商，后者返回了一个格式正确的响应。每项健康检查都显示绿色。HTTP 状态码显示 200。按照所有常用运营指标，系统行为是正确的。然而用户却被迫从头开始重复叙述，因为故障切换后的模型未收到任何之前的对话上下文。仪表盘显示系统健康。用户却知道并非如此。这种故障模式普遍存在、影响严重，却几乎完全未被衡量。机器学习社区已开发出针对准确性 [7]、延迟 [2] 和幻觉率 [9] 的严格基准。目前尚无类似方法来评估多提供商系统在发生故障切换时是否保持了对话连续性。业界隐式的假设——一个成功的 HTTP 响应意味着一次成功的对话——混淆了两个本质上不同的属性：可用性（系统返回了答案）和连续性（系统返回的答案基于完整的先前上下文）。在交互式语音应用中，连续性的丧失表现为对话的突然重置，功能上等同于挂断。在执行多步骤任务的代理流水线中，后果更为隐蔽：代理继续操作在截断的上下文窗口上，产生看似合理但错误的输出，其根本原因——在故障切换边界上状态的静默丢失——可能直到几个推理步骤之后才显现，而此时实际损害早已造成。

### 1.1 现有基础设施中的差距

一个不断增长的多提供商 LLM 网关生态系统已经出现，以应对跨异构模型端点部署的运营挑战。诸如 LiteLLM [10]、Portkey [18] 和 OpenRouter [17] 等系统提供了统一的 API 接口、自动故障切换路由、负载均衡以及跨提供商（包括 OpenAI、Anthropic、Google 等）的成本优化。这些系统为运营可靠性做出了实质性贡献，我们在本工作中借鉴了它们的一些架构模式。然而，现有网关在请求级别运行：每个 API 调用被视为一个独立的、无状态的事务。当触发故障切换时，网关将当前请求路由到替代提供商，但之前由现已不可用的主提供商维护的对话历史并未重建。故障切换模型收到的是单个脱离上下文的消息，而不是完整的对话。这并非实现疏忽；它反映了一个根本性的架构选择。这些系统被设计为确保返回一个响应，而不是确保对话得以延续。这一区别尚未被正式描述，据我们所知，也没有现有的基准对其进行评估。

### 1.2 贡献

本文做出以下贡献：

1.  1.将对话连续性形式化为一个可衡量的属性。我们识别并定义了连续性差距（continuity gap）：多提供商故障切换事件期间对话状态的静默丢失。我们认为连续性与可用性是正交的，需要独立评估。
2.  2.提出两个评估指标。我们引入了连续性保持率（Continuity Preservation Rate, CPR），用于衡量故障切换事件中备用模型的响应展示出对完整先前上下文访问权限的比例；以及连续性延迟开销（Continuity Latency Overload, CLO），用于量化故障切换期间状态重建带来的额外延迟成本。
3.  3.构建并评估一个有状态故障切换系统。我们设计了一种采用历史转发（History-Forwarding）策略的多提供商代理架构，在备用提供商处重建完整的对话状态。在由 LLM 评判者评估的 \(N=750\) 次故障切换事件中，我们的系统实现了 99.20% 的 CPR [95% Wilson CI: 98.27%, 99.63%]，而在相同条件下基线接近 0%。
4.  4.发布可复现的基准测试框架。我们开源了 continuity-bench，这是一个完全自动化的评估框架，可生成包含嵌入事实锚点的多轮对话，在可配置的轮次索引处编排受控的故障注入，并通过自动化 LLM 评判对上下文保持进行评分，从而能够对任何多提供商系统进行可复现的评估。
5.  5.刻画两种系统级故障模式。在高并发压力测试（\(C=100\) 个并发对话）期间，我们发现并记录了现有文献中缺失的两种故障模式：(a) 并发竞态条件（concurrency race condition），其中并行故障切换事件损坏共享代理状态；(b) 重试风暴漏洞（retry-storm vulnerability），其中针对限流备用提供商的固定间隔重试逻辑会生成自我维持的请求风暴，永久锁死备用端点并级联为系统完全故障。我们证明带抖动的指数退避对于解决后者既必要又充分。

## 2 相关工作

我们的工作处于三个不同研究领域的交叉点：多提供商 LLM 编排、基于 LLM 的评估方法论以及系统级可靠性工程。我们依次考察各个领域，并指出促使我们做出贡献的具体差距。

### 2.1 多提供商 LLM 网关与路由器

商业 LLM API 的迅速激增——每个都有不同的定价结构、速率限制、能力概况和可用性特征——催生了一类旨在抽象提供商异构性的中间件系统。这些多提供商网关向下游应用呈现统一的 API 表面，同时在内部管理跨异构后端的路由、故障切换、负载均衡和成本优化。LiteLLM [10] 提供了一个开源、兼容 OpenAI 的代理层，支持超过 100 个 LLM 提供商。它实现了具有可配置重试策略的自动故障切换、请求级负载均衡和费用追踪。其架构将每次补全请求视为一个无状态事务：当某个提供商失败时，相同的请求被转发到替代端点。LiteLLM 不会在故障切换边界维护或重建对话状态；这是设计使然，因为其抽象在 HTTP 请求级别而非对话级别运行。Portkey [18] 通过托管控平面扩展了网关模式，提供语义缓存、基于请求元数据的条件路由以及详细的可观测性。其故障切换机制支持具有加权路由策略的可配置备用链。与 LiteLLM 类似，Portkey 的故障切换逻辑按请求运行：失败调用使用相同有效负载对替代提供商进行重试。系统在故障切换期间不会检视或增强对话上下文。Portkey 的文档明确将其可靠性保证表述为正常运行时间和成功响应交付，而非对话连贯性。OpenRouter [17] 提供了一个商业路由层，基于成本、延迟和可用性动态选择提供商。它支持在其提供商池中自动回退，并提供统一计费接口。OpenRouter 的路由决策基于实时提供商健康信号按请求做出。与上述系统一样，对话历史在路由层中并非一等公民；系统确保返回一个响应，而非确保响应基于完整的先前对话。Martian [11] 和 Not Diamond [14] 代表了更新一代的模型路由器，它们采用学习到的路由策略，基于预测的质量、延迟或成本为给定查询选择最优模型。这些系统在模型选择层引入了复杂性，但继承了相同的无状态请求级抽象：路由决策取决于当前请求，而非正在进行对话的连续性。还有几个系统值得提及。Amazon Bedrock [1] 提供托管的多模型推理，具有跨区域故障切换能力。Azure OpenAI 服务 [12] 提供具有自动区域故障切换的预配吞吐量。两者都在各自的云生态系统中运行，并在基础设施级别实现故障切换，确保请求级可用性，而不解决对话级连续性。总结：现有的多提供商系统对 LLM 部署的运营可靠性做出了实质性的真正贡献。它们已在很大程度上解决了可用性问题：确保尽管个别提供商出现故障，仍能返回格式正确的响应。它们没有解决的——并且我们认为这构成了一个不同的、正交的属性——是连续性：确保故障切换事件后返回的响应反映了与现已不可用提供商建立的完整对话上下文。本文形式化了这一区别，并提供了第一个用于衡量它的系统性评估框架。

### 2.2 LLM 评估与 LLM 作为评判者

我们的评估方法论依赖于自动化 LLM 评判，以评估对话上下文是否在故障切换边界得以保持。这种方法借鉴了将语言模型作为评估者的快速成熟的工作领域。LLM-as-Judge [21] 表明，强大的语言模型（例如 GPT-4）可以在各种生成任务中作为人工评估的可靠代理，在质量评估上与人工评分者达成高度一致。随后的工作完善了这一范式：Chatbot Arena [5] 大规模采用成对 LLM 评判，从众包偏好中产生 Elo 风格的模型排名，而 AlpacaEval [6] 使用自动化 LLM 与参考模型的比较来近似人工偏好判断。我们对 LLM-as-Judge 的使用与这些努力在一个关键方面不同。先前的工作使用 LLM 评判者来评估开放式质量——流畅性、有用性、无害性——其中真实情况本质上是主观的。我们的评估任务则更为受限：评判者必须确定在对话早期建立的特定事实锚点（例如日期、姓名、表达的偏好）是否在故障切换后的响应中被正确回忆。这是一个事实验证任务而非偏好判断，我们预期并经验性地观察到因此具有更高的评分者间信度。FActScore [13] 和 HaluEval [9] 评估生成文本中的事实一致性和幻觉检测，为使用 LLM 验证特定事实主张提供了方法论先例。我们的事实锚定策略——在早期对话回合中嵌入独特的、可验证的事实（虚构专有名词、特定日期、不寻常偏好），并在故障切换后探查其回忆——受到该研究方向的启发，但适应于跨提供商上下文迁移这一新场景。

### 2.3 系统可靠性与故障切换

在组件故障期间维持服务连续性的问题在分布式系统研究中有着深厚的根基。断路器（Circuit breakers）[15] 在微服务架构中得到普及，通过暂时停止对不健康下游服务的请求来防止级联故障。舱壁模式（Bulkhead patterns）[15] 隔离故障域以限制爆炸半径。带抖动的指数退避（Exponential backoff with jitter）[4] 是防止针对限流或恢复中服务的同步重试风暴的标准方法，我们在 LLM 故障切换场景中独立重新发现了该技术的必要性并进行了经验性验证（第 6 节）。分布式系统中确保来自同一逻辑会话的连续请求被路由到同一后端的概念——会话亲和性（session affinity）或“粘性会话” [8]——是连续性需求的部分类比。然而，传统系统中的会话亲和作用保证路由一致性，而非状态重建：如果粘性后端发生故障，会话状态通常会丢失，除非显式复制。我们的历史转发策略可以理解为故障切换时的主动状态重建，类似于容错分布式系统中的状态机复制 [19]，但作用于对话而非确定性状态机。惊群效应（thundering herd problem