# 从 OpenRouter 迁移：先选择目标运行模式

> 安全迁移 OpenRouter 要先盘点实际依赖的行为，选择目标责任模式，并在迁移其余负载前证明一条可回滚工作流。

_发布 2026-08-15 · 更新 2026-08-15 · [KeepRouter Editorial](https://keeprouter.com/editorial-policy#editorial-team) · 10 分钟阅读_

![按托管访问、供应商控制、可观测与自托管整理的 OpenRouter 替代图](https://keeprouter.com/editorial/blog/openrouter-alternatives-for-developers.png)

_替代范围应由需要保留的任务决定，而不是按功能数量排名。_

**先给结论：**每次只迁移一条可回滚的 OpenRouter 工作负载。先记录应用实际依赖的供应商偏好、回退、数据策略、模型 ID、端点形态与响应行为，再选择目标运行模式，然后比较功能。KeepRouter 适合需要托管多模型 API 和统一按量访问的团队；Cloudflare AI Gateway 适合希望在 Cloudflare 平台上给自有供应商账户增加 Gateway 控制的团队；Portkey 适合评估可配置 AI 控制面与 Gateway 的团队；LiteLLM 适合愿意自运维代理或把路由 SDK 嵌入代码的团队；供应商直连则适合重视原生契约与直接账户所有权的团队。

这是一张迁移地图，不是排名。每种选择都在你的团队和服务之间重新分配责任。承诺之前，应通过官方文档核对当前端点、模型、价格、数据控制与部署要求。

## 运行模式对照

| 选项 | 供应商账户与计费 | 部署所有权 | 控制界面 | 适合场景 | 需要重点验证的权衡 |
| --- | --- | --- | --- | --- | --- |
| KeepRouter | 托管目录与 KeepRouter 账户 | 托管服务 | 统一文档化路由、模型范围访问、请求证据 | 希望一次集成并按当前目录访问 | 精确路由/模型资格与托管服务信任要求 |
| Cloudflare AI Gateway | 通常是 BYOK 供应商凭证 | Cloudflare 托管 Gateway 层 | 分析、缓存、限流、重试、回退、动态路由 | 技术栈已有 Cloudflare 且保留供应商账户 | BYOK 设置、功能限制与数据/日志策略 |
| Portkey | 可配置供应商集成 | Portkey 文档说明的托管或部署选项 | Gateway 配置、路由、预算、Guardrail、可观测性 | 需要更广的 AI 控制面并愿意配置 | 产品范围、配置复杂度与运维责任 |
| LiteLLM | 自有供应商账户与配置 | 团队运维代理、数据库和升级；或使用 SDK | OpenAI 风格转换、虚拟 Key、路由、预算、回调 | 自托管或代码内控制是硬要求 | 可靠性、升级、安全与值班负担 |
| 供应商直连 | 多个供应商账户与账单 | 团队拥有每个集成 | 完整供应商原生 API | 原生能力与直接商业关系最重要 | 重复集成、策略、可观测性与账单工作 |

OpenRouter 官方供应商路由文档说明了供应商偏好、回退、参数要求与数据策略控制。应把你正在替换的当前行为作为基线。如果应用使用流式、工具、结构化输出、图像、response 状态或供应商选择控制，就不能只比较一个通用 Chat 请求。

## 六个能快速缩小范围的问题

1. **谁拥有上游账户？** 如果答案是你的团队，应优先评估 BYOK、自托管或直连；如果目标是统一托管访问，就明确评估其商业与信任模式。
2. **谁运维控制面？** 自托管提供部署控制，同时带来升级、安全、数据库和事故处理责任。
3. **哪种协议必须可移植？** 盘点 Chat Completions、Responses、Anthropic Messages、工具、流式与多模态，并分别核对路由和模型支持。
4. **哪些策略必须集中？** Key 范围、预算、重试、路由、日志、保留和脱敏是不同控制；只为真正需要的项索取证据。
5. **如何证明一次决策？** 要求请求 ID、最终目标、用量、错误，以及能支持核对的导出或 API。
6. **退出路径是什么？** 保留供应商中立的应用适配层、脱敏契约 Fixture，以及经过测试的 Base URL 或路由回滚。

## 从 OpenRouter 迁移的清单

- [ ] 导出应用实际使用的模型 ID、供应商偏好、回退规则与参数要求。
- [ ] 将隐式供应商行为改成明确的目标平台策略。
- [ ] 让同一组非流式、流式、工具、结构化输出与错误 Fixture 通过两套系统。
- [ ] 核对 token 用量与费用，但不要把临时价格表复制进代码。
- [ ] 审查新运行模式的数据收集、保留与日志访问。
- [ ] 只灰度一个工作流，并在验收门槛通过前保留旧路由。

针对 KeepRouter，可先读 [KeepRouter 与 OpenRouter](/zh/compare/openrouter)。[Cloudflare](/zh/compare/cloudflare-ai-gateway)、[Portkey](/zh/compare/portkey)与 [LiteLLM](/zh/compare/litellm)对比页分别拆解其运行模式，然后用 [AI Gateway 评估评分卡](/zh/blog/evaluate-ai-gateway)和[迁移清单](/zh/blog/openai-compatible-api-migration-checklist)生成自己的证据。

## 边界：官方功能会变化

供应商文档、端点、限制与产品包装都会变化。本文刻意不记录模型数量、价格快照、性能排名、客户陈述或节省承诺。每次决策都应重新阅读所链接的官方文档和 KeepRouter [实时模型目录](/models)，并记录验收测试的日期与账户上下文。

## 常见问题

### 哪一个 OpenRouter 替代方案最接近？

取决于你希望保留哪种责任模式：托管访问、BYOK 策略、自托管控制或供应商直连所有权。应先比较运行模式，再比较端点语法。

### 迁移时只改 Base URL 可以吗？

简单调用可能连通，但供应商路由、模型、流式、工具、错误、用量与数据策略仍需明确迁移测试。

## 参考的一手资料

_本文最近复核 2026-08-15_

1. [OpenRouter provider routing](https://openrouter.ai/docs/guides/routing/provider-selection)
2. [Cloudflare AI Gateway](https://developers.cloudflare.com/ai-gateway/)
3. [Portkey AI Gateway](https://portkey.ai/docs/product/ai-gateway)
4. [LiteLLM documentation](https://docs.litellm.ai/)
5. [KeepRouter OpenAPI](https://keeprouter.com/api/openapi.json)

## 继续阅读

- [KeepRouter 对比 OpenRouter](https://keeprouter.com/zh/compare/openrouter.md)
- [KeepRouter 对比 Cloudflare AI Gateway](https://keeprouter.com/zh/compare/cloudflare-ai-gateway.md)
- [KeepRouter 对比 Portkey](https://keeprouter.com/zh/compare/portkey.md)
- [KeepRouter 对比 LiteLLM](https://keeprouter.com/zh/compare/litellm.md)
- [如何用证据型评分卡评估 AI Gateway](https://keeprouter.com/zh/blog/evaluate-ai-gateway.md)

[全部文章](https://keeprouter.com/zh/blog.md) · [模型与价格](https://keeprouter.com/models.md)