模型路由把请求切到备用服务后，HTTP 错误可能消失，业务行为却悄悄改变。Sunil Mallya 的 LAB 长文把延迟、可用性与行为要求放到同一张决策表上，提醒团队为每类任务明确降级策略。它最有价值的贡献，是给“故障切换后仍算不算完成任务”建立讨论语言。

原文：The LAB Problem: A CAP-Like Tradeoff in LLM Inference · sunil mallya（@sunilmallya）· 2026-10-23 UTC

一次成功切换，为什么仍可能是业务故障

文章用一个假设场景开头：主模型遇到限流，路由器立即切到备用模型，延迟和错误率恢复正常；之后才发现，原本应该升级人工审核的交易被自动批准。这里恢复的是请求通路，改变的是决策标准。例子用于解释风险，不是公开事故报告或实验结果。

这种差异并不要求备用模型总体更差。不同模型对提示、工具格式、模糊指令和拒绝条件的反应可能不同；相同模型名称在不同提供商上，也可能受到服务配置影响。若应用只判断“返回成功且够快”，这些变化就很难进入路由器的目标函数。

LAB 由 Latency、Availability、Behavior 组成。延迟指有用回答是否赶上任务期限；可用性指主模型故障或变慢时，工作能否继续完成，允许部分任务晚到；行为则指格式、决策、升级规则、工具调用与限制是否满足任务要求。行为一致并不要求每句文字都与主模型相同，应该由应用可接受的规则定义。

CAP 类比必须保留的前提

作者明确说 LAB 借用 CAP 的形状，而非数学证明。最强的论点发生在一个特定条件下：受信任的模型无法在期限前回答，也没有经过验证的备用模型能做到。此时系统可以等待、拒绝，或交给尚未验证的替代品，但不能同时承诺按时交付与行为满足要求。

如果已经存在能按时回答、又通过该任务验证的备用模型，切换就不必必然牺牲行为。因此 LAB 不能写成任何推理系统永远只能三选二的定理。它更适合迫使设计者写清故障前提、任务期限与可接受行为，再讨论剩余选项。

延迟与可用性也不是在所有业务里都独立。实时交互晚一分钟可能就等于失败，夜间批处理晚一小时仍有价值。定义是否允许延期，直接决定“等待以保行为”是否可行；如果把可用性本身定义为在同一期限内返回，两个维度就会明显重合。

三种位置是策略起点

长文列出三种简化选择。LB 倾向保持一个经过测试的模型而不切换，主路径正常时兼顾速度与行为，失败时损失可用性；AB 通过排队或重试等待该模型，接受延期；LA 切到能响应的替代模型，以保持服务和速度，但承担行为漂移风险。

这些标签不能代替故障状态机。单模型也可能变慢，因此“不切换”不保证任何时刻都低延迟；排队需要有截止、取消与过期处理，否则等待可能无限延长；切换则要定义哪些任务允许进入备用路径。上述是从框架推出的实现问题，而不是文章提供了完整控制算法。

同一个系统可以为摘要、工具执行和付款判断设置不同策略。关键并不是某种任务天然属于哪一角，而是它能否容忍延迟、错误决策和暂时停止。按工作负载制定政策，才有机会让降级与业务损失一致，而不由默认路由规则统一决定。

行为感知路由要比改 URL 多做一步

原文建议让应用先表达任务，再由下层选择与目标模型匹配的提示、参数和验证规则。备用模型上线前，应在固定难例上测试：模糊输入、工具调用、拒绝、结构格式和升级条件都要覆盖。成功请求比例之外，还需分开评价正确性与对规则的遵守。

工程上，这意味着路由配置应与测试过的执行条件共同版本化。模型或提示换了，原先合格的组合未必继续合格；提供商或服务精度变化，也可能需要重新检查。这里的重点不是宣称所有变化都会导致错误，而是让“允许接收这类流量”的判断有明确证据和失效条件。

验证器本身也有范围。JSON 合法只能说明语法成立，不能说明退款是否该批准；工具名正确也不能说明参数对应了用户授权。对无法在线完整判定的语义要求，可以把离线测试、受控放量和人工升级组合起来。它们降低风险，但仍不等于形式化的行为等价证明。

故障演练应该测什么

作者建议演练限流、容量丢失、慢响应和区域故障，并把按时回答、完成工作、行为忠实度与正确性分开记录。这样，切换后“服务正常”的结论就不会只来自 API 状态码。一个业务可接受的延迟响应和一个快速但越权的响应，应该落在不同结果类别里。

正常时期为了省时或省钱而路由到小模型，也是在改变执行条件，只是没有故障触发。是否存在取舍，要看小模型在该任务上是否通过验证；成本更低并不必然损失行为，未经测试则无法承诺。即使不切换，模型版本退役、别名更新或提供配置变化也让长期监控有意义。

多提供商的经过测试的副本能改善可用性，但还要面对共同容量、账号限制或模型演化等相关风险。文章没有给出量化优化算法、可用性证明或受控基准，不能从这个框架推出某个产品的可靠性数值。

LAB 值得读作一次设计评审的提纲：写下期限、行为契约、可用备用与失败策略，再决定哪些切换已被验证。它推进的是让应用行为成为推理基础设施的显式约束，帮助团队解释“请求完成”与“可接受工作完成”之间的距离。

把行为契约写成可讨论的对象

例如，一个工具型任务可以分别说明允许调用哪些工具、哪些参数必须由用户确认、何种不确定性需要升级，以及超时后结果是否仍可执行。这些约束比“备用模型应当差不多”更容易测试。这里的例子是对框架的工程展开，不是原文提供的现成策略；真正的契约仍需要由任务拥有者定义。