概述（Overview）
AI 服务商是受制于多重因素（如速率限制、基础设施故障、模型下线等）而随时可能出现宕机罢工的外部依赖。有了 ModelRiver 内置的多供应商故障转移机制，即便是某一家个别供应商服务断线，您的请求依然能无缝平滑切至后备顺利通行。各项请求日志精细地捕捉下每一次不论成功或失败的供应方尝试调用情况，为您提供用以评估各家服务商可靠度以及优化自身工作流配置的关键数据支撑。
解读供应商可靠性数据指标
请求日志中的故障转移（Failover）尝试记录
当遭遇某个模型提供商掉线，进而导致 ModelRiver 发起向后备选项重试的转接时会发生：
- 系统将为那次失败的尝试创建一条记录状态为
status: "failed"且附带有primary_req_id参数指向并关联其最终那条成功请求的日志条目。 - 最终的那条成功请求（如果所有后备都挂了那就显示最终失败的那条）被会当作整个记录的主日志展示。
- 进入详情展示板的**时间线（timeline）**会完全按照先后的时间发生顺序把每次做过的尝试都逐一铺开显示。
反映供应商可靠性的核心关键指标群
| 指标 | 去哪里找它 | 它说了什么 |
|---|---|---|
| 失败模型数量红签徽章 | 位于日志列表页（标有具体数字计数的红色警示徽章） | 成功被接通之前总计遭受过多少把供应商尝试失败 |
| Failover（后备转接）尝试情况 | 存在于明细详情视图的时间线上（带琥珀色警示牌） | 揭露明确是哪些服务商挂了并附带出错因由 |
| Error（报错）信息 | 在失败详情的视图页 | 每一回发生失败事件其背后的根源要害 |
| 整体成败情况比率 | 贯穿全部多条请求的 Status 状态列 | 可观察供应商常年长跑下的健康生存状态 |
可靠性分析工作流
步骤 1：明确后备转接激活频率
- 登入进您所属的项目中枢内找到 Request Logs（请求日志）栏。
- 将数据切在属于生产流量专属范围的 Live mode（实时运行态）。
- 去寻找哪些顶着 "failed models"（失败模型）报错徽牌 的不良请求项：它们是动用了系统防坠底线的备选项才活下来的。
- 在整体的全部单量里核算一下这种切去后备的触发频次。
健康水准界线： 去跑去切走后备应该是一个稀罕罕发事件（发生频率低于全部求请量的 5%）。如超了一成（10%）的请求都在切转后备才得以生存返回，这就绝对意味着其中有某家提供商烂出了问题需要立马治治了。
步骤 2：逐家服务商追查失败类型规律
点击那些启动了降级后备机制的数据并拉开它们的时间轴：
- 谁崩了？ – 记下提供商牌子还有它具体的模型款式。
- 为何崩？ – 扒开那个失败尝试里的详情错误明细串内容看看原因。
- 何时崩的？ – 对一下崩的这个点是不是在某些有着聚集规律的特定时间段。
分提供商典型的常见失败病因：
| 失败种类 | 详细阐述 | 揭示出 |
|---|---|---|
| Rate limiting（超出频限） | 该平台回传了 429 号 HTTP (Too Many Requests) 错误 | 必须着手去降低请求发送密度或者索性砸钱去升级在该平台的充值套餐配额 |
| Server errors（服务器死机） | 收到供应商回弹 500/502/503 | 这个供货商那边拉跨瘫痪了 |
| Model unavailable（无此模型可寻） | 该模型暂时下线消失 | 服务商正在搞它的更新亦或者是把它给报废砍掉了 |
| Authentication error（认证不通过） | 拿着无效过期 API 秘钥来叩门 | 需到 ModelRiver 后台把给他们家的对接口令换新 |
| Content policy（内容政策碰壁） | 提交东西触犯人家管控禁制令遭全盘驳回拒收 | 怕是得给自己用户提进来的字词过一遍安检网 |
| Timeout（应声超时没信） | 过了系统限定耐心红线都不给个反馈 | 他们家要么爆满挤死要么出了别的大毛病 |
步骤 3：捕捉供应商表现走势
通过时间来跨度审视它这段时间总的运行情况是否可靠：
- 这家供应商是不是天天烂？屡教不改？ – 必须从首发顺位撤出或是果断彻底地拉黑。
- 这些失败是不是扎堆聚集于特定时刻？ – 注意有些渠道一到高峰拥挤点就集体疲软瘫痪。
- 这拉跨表现是不是针对某一款单一具体模型特有的？ – 提供方整个网络其实还行不赖，仅偏偏这一款某类型极度不可靠。
- 各类失败报错有没有愈演愈烈的苗头趋势？ – 说明这个供货商整体架构每况愈下走上了危局。
步骤 4：上手配置及调整各大供应商格局情况
在依据以上情况做出全方位诊断研判得出结论：
- 重排后备名单顺序位次 – 让一贯稳定牢靠的王者选手排在首发头阵。
- 果断砍去不靠谱的拉胯机构 – 若哪家机构天天罢工掉链就不该留在这工作流队列中。
- 实现多元组合以消解互通株连 – 拉开几家不同的大型机构作为混搭能极大程度上避雷全网死。
- 勤快更新门禁暗号（API Key） – 若总是因拿不出通关证报错请自觉循环刷新更迭使用最新的 API 密钥码。
- 调整速率限制 – 实在撞门次数太高请痛快地购买他们的高限流付费订阅等。
各家独门供应商特别关照注意事项
Rate limiting patterns（限速规律模式）
家家都有本难念的限速经：
- 按每分钟请求出管次数限频（Per-minute request limits） – 您在这眨眼间投下太多请求求信了。
- 以每分产生能处理 Token 容量限频（Per-minute token limits） – 产生跟进太快总字数早已刷爆它们处理上线。
- 按天限制额头度数（Per-day limits） – 全天限额配额都被您一次性抽干喝尽了。
怎样去找出被限速了的痕迹：在那些记录于惨遭拒绝尝试细节栏下里细寻编号 429 报错印记。被限速截住这破事儿它好发作群起蜂拥暴发起于访问流量极高极度集中时刻。
怎么去解决消除这种限频问题：
- 给求情频率节奏来个缓冲冲泡把集火波次摊平打散些。
- 上用多家长手拉手连环排一起分发重担压力。
- 买更贵高段位升级配额的通行证。
- 在自身平台发送侧建打限流管水阀堵绝冲浪高峰浪流。
Provider outages（供应商死机全面停摆）
怎样去找出这类症状：源于某一固定厂牌的单门服务下断头崖一般地海量跌盘，伴随机出现各种形形色色的诸如 500/502/503 代码轰炸。
这事要怎么处理和挽救解决：
- 放心，ModelRiver 早早备好的后备后手兜底机制这就会立马自觉顶上一并处理好。
- 只管放眼查看这明细里时间线核实在后备的确在正常发力接棒即可。
- 去这家病商自己的官网挂着故障显示页面确认它们那是不是在张贴大罢工告警预告告示。
- 若这瘫痪罢工的修期漫漫太久遥不可及迟迟不到家，就该盘算将他们家临时先给踢出局外了。
Model deprecations（模型停止服务被废弃停用）
如何认出这些玩意：不停地报着同一个“此模型寻不见没影子”或“模型当前不再提供有效服务”的恒常死亡回响反馈。
这时候要怎样处理挽救解决这问题：
- 快到自家控制栏位上的调选配置流程里将其改换指向更迭代的新出代替版本使用。
- 多走走多留心这几家的厂牌发行新文通知等，掌握好它们手下那几头模型的生老病死全周期变幻命数。
- 对其做好相关的雷达监控布置去主动网截探照下各式的终结使用警报通知消息等防范于先。
理性以数据为主导实施出牌调度裁决
选择在什么情况下将一家供应商继续留堂：
- 常败坏发生破事失败挂掉记录极具低发罕见（低于总单量 5% 时）。
- 即便翻车也是微小一惊一乍的自身带自恰带自行回本能力且短时间马上自我满血复生过来的表现等。
- 这所商家具备极具特色唯一仅存在别处求而不得拿来即用这独特的独家本事专有秘方及独一份拿手看门招式类大件专才能力项能供给等项等等。
- 花出来的这点微末碎银和它带出那强悍优异等强能力发挥极度契合性极佳极有着等超强极高那无匹比等的极等性价比对。
应当将其清理出局的状况：
- 持续的错误失败率稳定攀高越过 10%。
- 明明没有发高压量请求也屡次频频触碰到限速板。
- 返回等待延迟状况相比其它友商极为离谱长久。
- 不停不间断地报出各种授权和鉴权的报错。
何时更迭主次名位排列：
- 首发提供商跑出的掉链报错率反倒比替身的高。
- 在当前您的跑分情景中，后备老二的各项生成反馈用时显然更少、更快。
- 坐在主力宝座这老兄不仅昂贵且天天罢工报错不断（带来双倍的高额失败成本代价）。
关联指标
提供商的可靠程度往往会与系统内其它的观测核心指标构成紧密的交错拉扯影响：
- 系统性能时长（Performance） – 不怎么靠谱的厂商无端带进来的报错和退步重试，只会平白大幅长加你整个运转过程里的滞后耗时。详参相关指引：性能监控。
- 花销成本（Cost） – 即便是以报错收场的烂单子在少数的极个别部分缺德平台中，它们依旧胆敢计入算钱消耗您的字数额度花销本金。（指引参看：造价分析篇）
- 开发纠错调试（Debugging） – 这是极度隐性不可预估暗伤之一：由于触发了提供商更换重试导致接手的后备和原设计生成在返回格式中有着重大结构分歧变化等。请指路明细看：寻找漏洞纠错分析篇）
后续引导建议
- 深入查看排版梳理各类切换转移时间轴 – 切去后背转接里的水有多深？到这里来看个透彻。
- 关注性能数据 – 服务商不行，请求肯定快不了。
- 盯紧钱包算算花费 – 在平台崩亏背后那些冤枉买单到底花了多少。
- 揪病探伤调试分析 – 翻遍日志查找到底这倒霉错误该怪谁、怎么排查修正。
- 全要素宏观把控总集 – 退出回到观测一览页总界面俯瞰诸等全局。