企业用 AI 的方式变了。一年前还在纠结"选 GPT-4 还是 Claude",现在真正的问题是:几十个模型怎么调度、怎么按场景切换、怎么在成本和效果之间动态权衡。OpenRouter 刚完成的 1.13 亿美元 B 轮融资,把这个问题推到了台前——CapitalG 领投,NVIDIA、Snowflake、Databricks、MongoDB、ServiceNow 五家企业级巨头同时跟投。这不是在投一个模型,是在投模型之间的那条管道。
多模型生产系统:从试点到刚需
单模型试点的阶段已经过去。现实场景里,一个产品往往同时需要:
- 高精度推理——复杂决策用 GPT-4o 或 Claude Opus
- 低成本高频调用——简单分类、摘要用 Gemini Flash 或 Mistral Small
- 专域能力——代码生成用 DeepSeek-Coder,图像理解用专门的多模态模型
- 合规与数据驻留——某些场景必须用本地部署的模型
这意味着企业面对的不是"哪个模型最好",而是"哪个模型最适合当前这个请求"。手动写 if-else 硬编码切换逻辑,很快就会变成维护噩梦。路由层要做的,就是把这个决策自动化。
OpenRouter 做了什么
OpenRouter 的核心定位很清晰:一个统一的 API 端点,背后连接上百个模型,由路由逻辑决定每次请求走哪条路。
具体来说,它提供了三层能力:
- 统一接入——不管底层是 OpenAI、Anthropic、Google 还是开源模型托管方,调用方只需要一个 endpoint、一个 API key。
- 动态路由——可以按成本上限、延迟要求、模型能力标签自动选择模型,也支持手动指定 fallback 链。
- 成本与用量治理——统一计费、统一限额,不用在每个模型提供商那里分别管理账单和 quota。
这解释了为什么 NVIDIA 和 Databricks 会同时出现在投资名单里——NVIDIA 关心推理基础设施的流量分配,Databricks 关心数据平台上的模型编排,而 OpenRouter 恰好是两者之间的调度节点。
用 OpenRouter 实现多模型路由:一个可运行的示例
下面是一个最小但完整的 Python 示例,展示如何通过 OpenRouter 实现按场景自动路由的调用模式。你需要先在 openrouter.ai 注册并获取 API key。
import os
import requests
from datetime import datetime
OPENROUTER_API_KEY = os.environ.get("OPENROUTER_API_KEY")
OPENROUTER_BASE = "https://openrouter.ai/api/v1"
# 定义路由策略:不同任务类型走不同模型
ROUTING_TABLE = {
"complex_reasoning": {
"model": "anthropic/claude-opus-4",
"max_tokens": 4096,
"reason": "复杂推理需要最强模型",
},
"code_generation": {
"model": "deepseek/deepseek-coder-v2",
"max_tokens": 2048,
"reason": "代码生成用专域模型,成本更低",
},
"quick_summary": {
"model": "google/gemini-2.5-flash-preview",
"max_tokens": 512,
"reason": "摘要任务用快速模型,延迟最低",
},
}
def classify_task(prompt: str) -> str:
"""简单的任务分类器——生产环境可替换为更精细的规则或小模型"""
if any(kw in prompt.lower() for kw in ["分析", "推理", "决策", "比较优劣"]):
return "complex_reasoning"
if any(kw in prompt.lower() for kw in ["写代码", "实现函数", "debug", "refactor"]):
return "code_generation"
return "quick_summary"
def call_openrouter(prompt: str, task_type: str = None):
"""通过 OpenRouter 路由调用,自动选择模型"""
if task_type is None:
task_type = classify_task(prompt)
route = ROUTING_TABLE[task_type]
model = route["model"]
headers = {
"Authorization": f"Bearer {OPENROUTER_API_KEY}",
"Content-Type": "application/json",
# OpenRouter 支持在 header 中传递应用信息,用于统计和排名
"HTTP-Referer": "https://my-app.example",
"X-Title": "Multi-Model Router Demo",
}
payload = {
"model": model,
"messages": [{"role": "user", "content": prompt}],
"max_tokens": route["max_tokens"],
}
print(f"[{datetime.now().isoformat()}] 任务类型={task_type} → 模型={model} ({route['reason']})")
resp = requests.post(f"{OPENROUTER_BASE}/chat/completions", headers=headers, json=payload, timeout=60)
resp.raise_for_status()
data = resp.json()
# OpenRouter 返回中包含用量和成本信息
usage = data.get("usage", {})
content = data["choices"][0]["message"]["content"]
print(f" tokens: prompt={usage.get('prompt_tokens')}, completion={usage.get('completion_tokens')}")
print(f" cost: ${usage.get('total_cost', 'N/A')}")
print(f" 回复: {content[:200]}...")
return content
# —— 运行三种不同任务 ——
if __name__ == "__main__":
# 1. 复杂推理 → Claude Opus
call_openrouter("分析以下两种微服务架构方案的优劣:基于服务网格 vs 基于 API 网关的中心化路由")
# 2. 代码生成 → DeepSeek Coder
call_openrouter("用 Python 实现一个带过期时间的 LRU Cache 类,要求支持 O(1) get 和 put")
# 3. 快速摘要 → Gemini Flash
call_openrouter("请用一句话总结:Kubernetes 中 HPA 和 VPA 的核心区别是什么")
运行前设置环境变量:
export OPENROUTER_API_KEY="sk-or-v1-xxxxxxxxxxxx"
python router_demo.py
几个值得注意的细节:
usage.total_cost——OpenRouter 在响应里直接返回本次调用的美元成本,这对多模型成本治理非常关键。- 路由表是声明式的——新增模型只需要在
ROUTING_TABLE里加一行,不需要改调用逻辑。 - 分类器可以进化——从关键词规则到小模型分类,再到 OpenRouter 自身的自动路由,升级路径清晰。
OpenRouter 自带的自动路由:更省心的方式
上面的示例是手动路由,适合需要精细控制的场景。OpenRouter 还支持更激进的用法——让平台自动选模型:
# 不指定具体模型,让 OpenRouter 根据成本和性能自动路由
payload = {
"model": "openrouter/auto", # 自动路由模式
"messages": [{"role": "user", "content": prompt}],
"max_tokens": 1024,
# 可选:设置成本上限
"max_price": {"input": 0.005, "output": 0.01}, # 每 1M tokens 的价格上限(美元)
}
openrouter/auto 模式下,平台会根据你的价格约束和请求特征自动匹配最优模型。对于不想维护路由表团队来说,这是最快的起步方式——代价是失去了对具体模型的确定性控制。
路由层的取舍与采用建议
路由层不是银弹。引入 OpenRouter 或类似方案之前,需要想清楚几个边界:
什么时候该用路由层: - 产品已经或计划接入 3 个以上模型提供商 - 不同请求对延迟、成本、能力的要求差异明显 - 团队不想在每个模型提供商分别管理计费和限额 - 需要快速切换模型而不改业务代码(比如某个模型 API 暂时宕机)
什么时候不该用: - 只用一个模型,且短期内不会增加——路由层是额外依赖,没有收益 - 对模型响应有严格的确定性要求(比如医疗、金融合规场景),自动路由可能选到你不完全了解的模型 - 延迟极度敏感——路由层本身会增加一次决策开销(通常 <50ms,但对某些实时场景可能不可接受)
采用路径建议:
- 先手动路由,再自动路由——用显式的路由表起步,摸清各模型在你实际场景中的表现差异,再考虑切换到
auto模式。 - 保留 fallback 链——任何模型都可能宕机或限速,路由配置里始终设置 1-2 个备选。
- 监控成本分布——OpenRouter 返回的
total_cost字段是金矿,按任务类型聚合后你会发现,80% 的成本往往集中在 20% 的请求上,这些才是优化的靶心。 - 不要路由一切——某些高价值核心路径(比如最终决策输出)直接指定最强模型,比让路由层猜更可靠。
这轮融资的核心信号不是"OpenRouter 做得不错",而是从 NVIDIA 到 Databricks 到 Snowflake,基础设施层的主流玩家一致认为:模型路由是下一代 AI 基础设施的必选项。模型会越来越多,切换会越来越频繁,而路由层就是让这件事从"运维噩梦"变成"声明式配置"的关键管道。