多模态统一路由：OpenRouter 单端点架构对每个 AI 网关运营商的启示

每个 AI 产品路线图迟早都会撞上"多模态 N SDK 问题"。第一个冲刺交付的是对话功能，接着需要产品图像生成，再然后是移动端语音输入，最后还要一个需要向量嵌入的知识库。不知不觉间，你维护着四套 Provider SDK、四套计费关系、四套鉴权刷新逻辑、四套重试退避实现——这些还没算上任何业务功能代码。

7 月 16 日，OpenRouter 发布了一篇技术拆解文章，介绍他们如何在平台层面解决这一问题：统一 base URL（https://openrouter.ai/api/v1）、一个 API Key、一张账单，以及对所有模态统一生效的路由控制规则。这篇文章不仅值得关注 OpenRouter 本身的设计，更值得每位 AI 网关运营商思考：背后揭示的架构选择，正是你也在悄悄做的决定。

OpenRouter 的多模态端点映射

OpenRouter 的设计将模态分为两类。其中五种——文本对话、图像输入（视觉理解）、PDF、音频输入和视频输入——都走现有的 /chat/completions 端点，仅通过消息数组中的 content type 区分。你已经在为文本调用这个端点；支持图像或音频输入，只需改变内容类型，无需换端点。

另外五个专属端点处理生成与转换类任务，因为其请求结构与对话接口本质不同：

视频生成天然是异步的——你提交 prompt、获取 job ID、轮询结果——这正是任何运营商处理长延迟媒体任务时都需要的模式。

为什么"路由层"才是核心洞察

API 界面只是表层。更重要的主张是：同一套路由策略对象在所有模态中一致生效。Provider 故障转移、针对隐私敏感负载的 data_collection: "deny"、以及基于成本/延迟的排序，无论你调用 /chat/completions 还是 /embeddings，运作方式完全相同。

这在运营层面至关重要。当每种模态通过独立 SDK 和 Provider 集成时，策略执行就变得碎片化：

• 你的对话调用遵守数据驻留规则，但图像生成走另一套集成，规则被绕过；
• 你的回退逻辑覆盖了文本 Provider 故障，但图像生成 Provider 宕机时直接报错；
• 你的计费仪表盘展示文本 token 消耗，图像生成费用在另一张独立账单里。

将模态无关的策略视为一等原语的路由层，能同时消除这三个缺口。一条规则管辖所有调用，无论返回什么类型的内容。

运营商决策框架

当你的产品走向多模态，面临一个分叉：

选项 A：按模态分别集成。 各团队为自己的模态选最优 Provider，直接对接，最终形成 N 套计费关系和 N 个策略面。启动快，规模化治理成本高。

选项 B：所有流量经由统一网关路由。 一套凭证、一个计费面、一处统一执行限流、预算上限、数据驻留和故障转移逻辑——覆盖对话、图像、音频和嵌入。

选项 B 的代价在于：你的网关必须理解它路由的每种模态。一个只为 /chat/completions 构建的网关无法为图像生成调用执行 Provider 故障转移，因为这些流量根本不经过它。

评估现有技术栈的运营商，可以参考以下实操检查清单：

1. 你的网关是否像路由对话一样路由图像生成和视频任务？ 如果不是，这些模态游离于你的路由策略之外。
2. 你是否为图像生成 Provider 配置了故障转移？ 图像生成市场仍高度集中，单一 Provider 宕机叠加无回退，直接等于产品中断。
3. 异步媒体任务（视频生成、长 TTS 任务）是否与同步调用记录在同一用量台账中？ 否则你的成本核算存在缺口。
4. 你是否能对嵌入调用执行 data_collection: deny 或等效的隐私控制？ 嵌入往往承载应用中语义敏感度最高的内容。

对你的路由策略意味着什么

OpenRouter 的设计是一个有用的参照系，无论你使用哪种网关。信号是：行业正在将多模态视为一个路由问题，而非单纯的集成问题。通过单一策略层路由所有模态的团队，获得统一计费、一致治理，以及添加或切换 Provider 的单一入口。按模态分别直接集成的团队，在规模化时为此付出治理代价。

对于今天已在运行对话、图像、音频和嵌入混合负载的运营商：审查你的路由层是否覆盖了所有模态。如果只覆盖了文本，你离一次 Provider 宕机触发模态级别的可靠性缺口只有一步之遥。

来自 OpenRouter 拆解文章的几个需要规划的实际限制：嵌入不支持流式（整体返回）、音频输入仅接受 base64（不支持 URL 引用）、视频 URL 支持因 Provider 而异而非通用。这些是统一接口遭遇不同 Provider 实现时真实存在的粗糙边角，在针对特定模态负载锁定 Provider 前值得提前了解。