渠道冷却到底影响了谁：怎样用实体标识核对失败计数的作用域

渠道冷却影响了谁，取决于失败计数按什么身份聚合。业务模型展示名相同，不代表两个部署实体的健康状态必须一起变化；上游账号共用，也不自动意味着所有实体应共用熔断计数。本文给出中性作用域比较，让部署者先明确自己的策略。

把三个身份字段拆开

附件有三个渠道实体。entity-1与entity-2都显示为chat，但分别属于acct-x和acct-y；entity-3显示other，却与entity-1共用acct-x。只给entity-1注入失败。按实体标识聚合，影响集合只有entity-1；按展示名聚合，连entity-2一起影响；按账号聚合，则连entity-3一起影响。

三个答案各自对应一种策略，不能仅凭集合更大就称为产品漏洞。若故障源是某账号的配额耗尽，账号域可能有管理价值；若只是一个部署地址连接失败，把账号下所有健康端点摘掉可能过宽。首先分类失败原因，再选择作用域，不能把展示名当成天然可靠的全局唯一键。

用稳定实体标识复核改名与复制

管理端改展示名，不应在没有策略依据时清空或合并健康历史。复制渠道时，也要明确新对象是否获得新实体标识，是否共享账号限额，以及冷却状态是否继承。样本中不同字段故意交叉，正是为了抓住“看起来同名所以认为同一个对象”的错误推断。

验收可以把失败事件写成实体标识、错误类别和策略版本，再输出实际受影响集合。若只记模型名字和冷却倒计时，事后很难判断究竟哪个部署被计数。对于别名解析到多个实体的情形，应保留解析后的候选对象，避免把业务请求名称直接拿来当故障计数键。

配额共享与健康共享分开决策

两实体共用账号时，配额可能需要合并，但网络健康状态仍可能独立。反过来，不同账号如果依赖同一个故障域，也可能需要更高层保护。这里没有统一推荐粒度，只要求实际实现与声明的契约一致，并为不同错误类型写独立例子。账号身份还应匿名化，不能用真实Key作为公开分组标签。

LiteLLM可靠性文档出现冷却相关配置，但不同版本和路由对象如何计数，需要部署者核对；本文不把某个字段默认绑定到哪种实体作无依据断言。本批实际执行的是三种字段等值分组及集合断言，没有运行网关、触发冷却或切换真实渠道。交付物能作为变更前的作用域审查表，明确一次失败预期影响哪些对象、哪些仍应保留，再到目标版本补做集成验证。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C033。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文说明allowed_fails/cooldown_time；本文验失败计数器按部署实体而非展示名或租户名分组，区别于C005配额域聚合。