一个 API 接入多模型：生产级架构应该怎么设计

不同模型的原生参数永远不会完全一致。强行把它们压成一个最小公分母，通常会丢失高级能力。更可持续的做法，是先定义稳定的任务层：文本生成、图像生成、图像编辑、文生视频和图生视频。每个任务保留一组通用字段，再通过可选的 provider_options 暴露少量模型特性。

在 ModelRush 的设计中，业务代码只表达“我要完成什么任务”和“质量、延迟、预算有哪些约束”。具体模型、供应商账户和区域由路由层决定。这样，产品团队不会在每一个功能里重复维护供应商判断。

模型名称不是可靠的接口。真正可用于路由的是能力：输入模态、输出格式、最大时长、是否支持参考图、是否支持音频、异步回调方式，以及计费单位。

自动路由不应该是黑箱。每次请求都应记录候选模型、排除原因、最终选择、重试路径和真实费用。对开发者来说，一个稳定的 request_id 比供应商返回的多个任务号更重要，因为它能贯穿网关、队列、回调和账单。

ModelRush 建议至少提供三类显式策略：质量优先、速度优先和成本优先。策略名字保持稳定，底层模型可以随着评测、价格和健康状态更新。

第一版不需要建立复杂平台。先把密钥、超时、错误映射和请求日志收进一层网关，再逐步增加能力目录、异步任务状态、回退策略和预算规则。每增加一家供应商，都应该只新增一个适配器，而不是修改所有业务服务。