需要微调模型的请求：聚合站到底转发了什么、什么会回落

微调模型（fine-tuned model）和自定义模型 ID 在聚合站里是一个容易被误解的环节。很多人以为“一把 key 调所有模型”意味着微调模型也会被自动处理，实际上一把 key 只解决鉴权与路由入口，真正能否服务取决于后端是否有对应资源。下面按请求路径拆开说。

请求进入聚合站后发生了什么

当你用同一个 API key 请求一个模型 ID 时，聚合站大致做三件事：

• 鉴权与计费归属：确认 key 有效、余额充足，并把这次调用记为一次扣费请求。
• 模型 ID 解析：判断这个 ID 是平台已知的公开模型，还是一个不在标准清单里的自定义/微调 ID。
• 后端路由：把请求交给持有该模型能力的上游渠道。

关键点在于第二步。公开模型 ID 有明确映射表；微调模型 ID 通常是“某账号下某次微调产生的私有标识”，它和平台级模型清单不在同一个命名空间里。

哪些情况会被原样转发

以下情形，聚合站通常会把请求体（包括 model 字段）原样透传给上游：

• 上游渠道声明支持该 ID，例如某个渠道明确代理了 OpenAI 兼容接口，而微调 ID 属于该渠道对应账号。
• 请求使用 OpenAI 兼容的 /v1/chat/completions 形式，model 只作为字符串传递，聚合站不做改写。
• 你在请求里带了渠道倾向或路由相关的 header，聚合站按你的指定转发。

原样转发的含义是：聚合站不校验这个 ID 是否真实存在，它只负责把字符串送到后端。因此“转发成功”不等于“调用成功”。

哪些情况会在到达后端前失败

• 模型 ID 不在任何渠道的能力声明里：聚合站无法确定路由目标，直接返回错误，不会发起上游请求。
• 上游返回模型不存在：请求被转发了，但上游不认识这个 ID，错误码由上游产生并回传。
• 上游认识 ID 但无权限：微调模型往往绑定创建它的账号或组织，换一个上游账号就无权访问。
• 计费口径不匹配：微调模型的价格通常与基础模型不同，聚合站按统一规则扣费，可能无法精确对应，具体以站点说明为准。

区分“聚合站拒绝”和“上游拒绝”很重要：前者说明路由层没有目标，改请求参数无用；后者说明目标存在但资源不对，需要换渠道或换 ID。

设计回落方案

微调模型调用天然比公开模型更脆弱，建议在客户端而不是聚合站一侧做回落。

用显式模型 ID 分层

把回落链写死在配置里，而不是靠猜：

• 首选：你的微调模型 ID。
• 次选：该微调所基于的基础模型 ID（公开模型，路由稳定）。
• 兜底：同任务下另一个公开模型。

回落只在“确定性失败”时触发，例如模型不存在、无权限、路由无目标。对于超时和限流，先重试同一 ID，再考虑降级。

用请求头做可控路由

如果你的聚合站支持按 header 指定渠道或优先级，可以在请求里显式声明。这样回落逻辑可以放在服务端配置里，客户端只需维护一条链路。要注意 header 的语义以站点文档为准，不要假设跨站通用。

记录错误来源

在日志里区分三类失败：聚合站路由失败、上游模型不存在、上游权限失败。这三类的处理方式不同，混在一起会导致回落被误触发，把本可成功的微调调用降级成基础模型，增加成本也损失效果。

不要假设自动回落

聚合站一般不会替你把微调模型请求“自动换成”基础模型。静默替换会让输出分布变化而你不知道。回落应当是你显式配置、可观测的行为。

实践建议

• 上线前对微调 ID 做一次探测调用，确认它在你使用的 key 和渠道下可达。
• 把微调 ID 当作配置项而非硬编码，方便渠道变更时替换。
• 在提示词与输出解析上，让基础模型也能作为回落目标工作，避免回落即报错。
• 关注计费差异：微调调用与公开模型调用的扣费口径可能不同，回落会改变单次成本，按站点实际规则核算。

一句话总结：一把 key 解决的是入口统一，微调模型能否被服务取决于后端是否持有对应资源。把回落放在客户端、显式配置、记录失败来源，比期待聚合站自动兜底更可靠。