OpenRouter Fusion Flash API：状态、配置与 400 错误排查

搜索OpenRouter Fusion Flash API的人，通常是想使用速度更快的 Fusion 预设，或者正在处理 HTTP 400 错误。问题在于，官方文档列出了 openrouter/fusion-flash，但实时模型发现结果可能并不包含它。因此，在接入之前，最好先在自己的账户环境中确认这个别名是否真的可用。

OpenRouter Fusion Flash 现在到底能不能用？

官方的Fusion Router 文档将 openrouter/fusion-flash列为独立的模型 slug，并说明它实际上是默认启用 general-fast 预设的 Fusion。这个预设针对更快的 Agent 交互设计，使用的模型面板也更偏向于提供相对一致的延迟。

同一份官方指南介绍了标准 Fusion 的工作方式：多个面板模型并行回答，由分析器比较共识与分歧，再由外层模型组织最终回复。Fusion Flash 是这个复合路由器的快速预设，并不是某个单独供应商提供的模型。

本指南于 2026 年 9 月 11 日获取的实时OpenRouter 模型目录中包含 openrouter/fusion，但没有显示独立的 openrouter/fusion-flash 记录。一位用户在 X 上报告了完全相同的情况：

“文档说 openrouter/fusion-flash 是一个单独列出的模型，在 /api/v1/models 中也有自己的条目，但目前 API 调用会返回 400 错误：fusion-flash is not a valid model ID。”——@PeterDaveHello

这只是用户报告，并不是 OpenRouter 的官方确认。OpenRouter 的官方文档确实介绍了 Fusion，但本指南找到的官方公告中，没有任何一则确认 Fusion Flash 已单独上线或被回滚。最稳妥的结论是：文档中有说明，但接入前必须以实时可用性为准。

排查代码之前，先确认这几件事

使用应用实际采用的同一个 API key 和运行环境请求模型目录：

curl https://openrouter.ai/api/v1/models \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

在返回的 JSON 中搜索完整字符串 openrouter/fusion-flash。不要仅凭模型页面、SDK 自动补全列表或缓存的集成配置来判断可用性。OpenRouter 的模型文档将模型目录视为当前模型标识符和支持参数的依据。

同时也可以查看官方状态页，但平台整体显示正常，并不能证明某个路由别名此刻一定可用。状态面板展示的是 Chat API、Data API 等较大范围的服务组件；即使通用 Chat API 正常运行，某个别名也可能因为目录或配置不一致而无法使用。

OpenRouter Fusion Flash API 的最小配置

第一步应当只发送最简单的 Chat Completions 请求。这样可以先排除 SDK 适配层、工具 schema、流式输出和自定义 Fusion 参数的干扰。

export OPENROUTER_API_KEY="your-key"

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/fusion-flash",
    "messages": [
      {
        "role": "user",
        "content": "Reply with the word: ready"
      }
    ],
    "stream": false
  }'

上面的示例只保留了必要的接口和请求头。第一次测试建议保留 stream: false，这样更容易完整查看错误响应。

如果该别名出现在 /api/v1/models 中，并且这条请求能够成功，再逐项加回应用中的其他字段。如果别名根本不存在，就不要继续修改提示词，也不要反复重试同一请求。可以用文档中的等效配置进行诊断：

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/fusion",
    "plugins": [
      {"id": "fusion", "preset": "general-fast"}
    ],
    "messages": [
      {"role": "user", "content": "Reply with the word: ready"}
    ],
    "stream": false
  }'

这个回退测试可以确认 Fusion 路由和快速预设是否可访问，但不能说明别名调用与显式配置在所有后端细节上都完全等价。

OpenRouter Fusion Flash API 400 错误排查顺序

400 通常意味着请求或供应商拒绝了请求，具体原因要看响应正文。它不同于 500 服务故障，也不同于 HTTP 200 但 Fusion 内部操作失败的情况。下面的顺序可以让每一步测试都只回答一个问题。

1. 先读取完整错误正文

不要只记录 400 Bad Request，把完整响应保存下来：

curl -i https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openrouter/fusion-flash","messages":[{"role":"user","content":"ready"}]}'

重点查看错误代码、错误消息、供应商名称、请求或生成 ID，以及附带的元数据。出现“fusion-flash is not a valid model ID”，通常指向模型发现结果与实际上线状态不一致；出现“Provider returned error”，则说明请求已经进入某条供应商路径，但在那里被拒绝。若 400 响应非常笼统，就去检查 OpenRouter 的 Activity 记录，不要靠猜。

2. 确认模型 ID 完全正确

模型标识符是区分大小写的字符串。将请求中的值与实时 /api/v1/models 响应逐字比较，包括标点和斜杠。清理应用配置中的过期别名，也不要擅自把它替换成猜测出来的 Gemini 或其他 Flash 模型名称。

可以参考下面这张诊断表：

3. 移除不受支持的字段

先只发送 model、messages、stream: false 和两个必需请求头，然后按以下顺序逐项恢复字段：

1. temperature 或推理相关设置。
2. plugins 和 Fusion 预设。
3. 自定义 analysis_models 或分析器 model。
4. tools 和 tool_choice。
5. 流式输出及框架特有的响应选项。

OpenRouter 的 Fusion 指南记录了 analysis_models、model、preset、max_tool_calls、max_completion_tokens、reasoning 和 temperature 等参数。但某个接口或模型系列支持的字段，并不意味着所有上游模型都接受它。应当以OpenRouter Models 参考文档以及具体模型的支持参数元数据为准。

4. 降低工具和消息历史的复杂度

启用工具的客户端可能导致难以理解的 400，因为最终请求体中可能包含无效的 JSON Schema、不受支持的工具参数，或者不完整的 assistant/tool 消息序列。一份公开的 Hermes Agent 报告记录了在版本 0.10.0 中启用工具时、多个测试模型出现 OpenRouter 400 错误的情况；报告怀疑原因是默认启用了28 个工具，但没有提供禁用工具后的成功对照，也没有确认根因。因此，应将issue #13927视为复现线索，而不是认定所有 Fusion Flash 400 都由工具引起的证据。

排查时可以分别尝试以下三种方式：

• 发送相同提示词，但移除 tools。
• 只发送一个使用简单对象 schema 的最小工具。
• 开启不包含历史工具调用或工具结果的新对话。

如果最小文本请求和精简后的工具请求都能成功，就逐个把工具加回来。如果长篇工具调用历史会失败，而全新请求可以成功，那么应先截断或总结历史，再继续调查模型本身。

5. 区分别名、路由和供应商故障

Fusion 可能同时涉及面板模型、分析器模型和负责生成最终回复的外层模型。某个内部调用失败时，表现未必像普通的单模型错误。OpenRouter 文档建议检查生成数据和 Activity 记录，以确认实际运行了哪些内容。正常响应中的 model 字段可以标识具体的外层模型，但单凭这个字段，无法证明 Fusion 一定被使用或一定没有被使用。

一次成功的 Fusion 运行，其文档所示的生成元数据包括：

{
  "router": "openrouter/fusion"
}

如果你提供了自定义 analysis_models，先移除它们，再重新测试预设。如果预设可以工作，但某个自定义模型失败，问题很可能与该模型的参数、供应商可用性或上下文限制有关。如果只有通过 SDK 调用时所有模型都会失败，就比较 SDK 实际发送的请求体和能够成功的 cURL 请求体。OpenAI 兼容客户端可能会额外添加工具、流式标志、响应格式或消息转换，而这些变化在应用层代码中未必显而易见。

什么时候该停止重试？

自动重试无法解决无效模型 ID 或确定性的 schema 校验失败。对于标记为不可重试的 400，应当设计清晰的回退路径：

• 模型目录中没有该别名：改用带有 general-fast 的 openrouter/fusion，或者暂时使用已知可用的普通模型，同时持续关注模型目录。
• 请求体导致 400：保留最小请求作为回归测试，并修复第一个导致请求失败的字段。
• 供应商特定的 400：移除受影响的面板模型，或使用已配置的回退模型；同时记录供应商返回的错误。
• Chat API 出现大范围故障：查看OpenRouter 状态页，暂停发布，不要贸然修改应用逻辑。
• HTTP 200 但内部失败：记录面板失败信息，并判断是否可以接受部分结果；不要把它归类为身份验证失败。

官方 Fusion Router 文档估算，默认的三模型面板成本大约是单次完成请求的4–5 倍；实际账单取决于底层调用。因此，在别名状态尚不明确时准备回退方案，既能提升可靠性，也能控制成本。

OpenRouter Fusion Flash API 常见问题

正确的 OpenRouter Fusion Flash 模型 ID 是什么？

官方文档列出的是 openrouter/fusion-flash。部署前，请通过 GET /api/v1/models 验证这段字符串，因为文档和实时模型发现结果可能暂时不一致。

Fusion Flash 是普通的快速模型吗？

不是。文档将它定义为使用 general-fast 预设的 Fusion。它仍然可能发起多次内部模型调用，所以“Flash”描述的是预设追求的延迟目标，而不是单次调用执行。

应该使用哪个接口？

使用 https://openrouter.ai/api/v1/chat/completions，通过 Bearer 进行身份验证，并发送 JSON 请求体。不要自行构造 Fusion 专用 URL 路径。

可以强制 Fusion 运行吗？

Fusion 文档支持 tool_choice: "required"。当 Fusion 是唯一可用工具时，这实际上会强制发起一次工具调用。如果同时存在其他工具，required 只表示必须调用某个工具，并不一定是 Fusion。

为什么 OpenRouter 状态页显示正常，Fusion Flash 却返回 400？

状态页展示的是范围较大的服务组件。别名缺失、路由配置无效或供应商特定拒绝，都可能只影响某条路由，而通用 Chat API 仍然正常运行。

Fusion Flash 免费吗？

不要想当然地认为免费。OpenRouter 的Fusion 模型页面说明，即使路由别名没有单独显示 token 价格，底层面板调用和分析器调用仍会计入费用。投入生产前，请检查 Activity 和所选模型的费率。

只有在实时模型发现结果与最小请求都确认可用时，才使用快速预设。否则，应回退到标准 Fusion 或已知可用的模型，并保留失败请求体，不要盲目重试。