多模型 API 稳定性：上游成功不等于用户可用

多模型 API 平台排查问题时，要区分上游渠道可用、模型配置可用、用户分组可用和用户 Key 可用四个层级。

后台测试成功，只是第一步

很多平台会遇到这样的情况：管理后台测试某个上游模型成功，但用户端用自己的 Key 调用失败。这并不矛盾，因为上游成功只说明渠道能通，不代表用户具备调用权限。

排查时要把问题拆成四层：渠道、模型、分组、用户 Key。

第一层：渠道是否真的可用

渠道测试要看返回内容、模型名、状态码和延迟。只显示成功还不够，最好记录测试时间、错误信息和上游响应。视频、图片等异步模型，还要区分提交成功和最终生成成功。

不同类型模型不能都用同一种测试方式。

第二层：模型配置是否完整

模型 ID、显示名称、价格、分组权限、是否启用，这些都要配置完整。后台有账号不代表用户端会显示模型，模型没有加入对应范围时，用户创建 Key 也看不到。

这类问题最适合在 API 自检中心里一次性检查。

第三层：用户分组和 Key 范围

用户注册后通常进入默认分组。如果模型只开放给另一个分组，用户就无法调用。即使用户创建了 Key，也要看 Key 的模型范围是否包含目标模型。

所以用户管理、分组管理和 API Key 配置必须联动。

第四层：余额和扣费

最后检查余额是否足够、价格配置是否存在、扣费是否写入使用记录。很多“不能用”的问题，其实是余额不足或价格表缺失导致系统拒绝请求。

稳定性不是单点测试，而是一条完整链路。