从硅基流动迁走或迁入：OpenAI 兼容层下要改什么

有一类迁移事故的现场是这样的：改完 base_url 和 API key，跑通了第一个请求，返回结构一模一样，测试全绿，上线。然后从当天起，接口的 P95 慢慢变长，偶尔冒几个限流错误，但没有任何一条日志说「你调错了模型」。查了一周，最后发现是模型名字里少了一个前缀——付费加速版的流量被退回了免费档。

这件事之所以难查，是因为它不在任何一个报警的路径上。下面把「OpenAI 兼容」这层皮下面真正要改的东西一条条摊开，迁入和迁出两个方向都讲。

一、先把「兼容」的边界划清楚

硅基流动的接入口径按官方 quickstart 是：base URL 为 https://api.siliconflow.cn/v1，key 在控制台的 API 密钥页用「新建 API 密钥」拿。协议层面官方的原话是「当前平台的大语言模型支持通过 OpenAI 库进行调用」。

这句话覆盖的是什么？是传输和骨架：地址、认证头、请求体和响应体的主要形状、SDK 能不能直接用。它没有覆盖、也不可能覆盖的是四样东西：

1. 模型标识。OpenAI 协议只规定有个叫 model 的字符串字段，不规定这个字符串长什么样。每家平台的命名自成体系。
2. 限速口径。按什么维度限、限多少、怎么涨，完全是平台自己的事。
3. 各家额外塞在返回里的扩展字段，以及只有某家有的平台侧能力。
4. 条款与账务：谁授权你用、能不能转手、余额怎么扣、欠费怎么处理。

所以「兼容」省掉的是 SDK 改写的工作量，省不掉选型的工作量。关于这层协议本身能替你省什么、又会给你留什么错觉，可以参考站内的 OpenAI 兼容协议说明 和 base_url 的取值与常见写错。

二、最容易静默出错的一处：Pro/ 前缀

这是本文最想让你记住的一条。

硅基流动的模型名是两段式的「厂商/模型名」，请求示例里出现的形态形如 Pro/deepseek-ai/DeepSeek-R1。按官方公告给出的命名规则：免费版沿用「厂商/模型名」，付费版在前面加 Pro/ 前缀。也就是说，同一个模型在这个平台上有两个合法的 ID，带 Pro/ 的是付费加速版，不带前缀的免费版速率与并发更低。命名规则这么定，本身是为了区分免费与收费、同时保住调用侧的兼容性。

为什么它不报错

把这两个 ID 放在一起看，就知道问题出在哪：

• 两个都是合法的模型 ID，请求返回 200，不是 4xx。
• 响应体结构一致，字段一致，SDK 不会抛异常。
• 背后是同一份模型权重，所以回答质量不会明显变差，你的评测集大概率照样通过。
• 唯一变的是速率与并发——而这两样东西在监控里的表现是「延迟分布右移」和「偶发限流」，不是「错误」。

一个变量在功能维度完全等价、只在容量维度有差别，这就是典型的静默故障：所有基于「对不对」的检查都会放过它，只有基于「多快、多少」的检查能抓到。

四条典型的丢失路径

• 迁入时把别家的裸模型名直接贴过来。这是最高频的一条。别家平台没有 Pro/ 这个概念，你从那边的配置里拷一串模型名过来，改成硅基流动的命名习惯，很自然就写成不带前缀的那种，于是全量落到免费档。
• 手写字符串散落在业务代码里。迁移时顺手「统一格式」「清理冗余前缀」，一次正则替换全砍掉。
• 多环境串台。开发环境为了省钱用免费档、生产用付费档，两套模型名靠环境变量区分，发布流程里变量没带上或者带错了。
• 照着教程抄。公开教程为了让读者不充值就能跑通，示例里用的往往是免费那个名字。你抄的是能跑的代码，抄漏的是它为什么能免费跑。

方向不对称：迁出安全，迁入危险

值得单独点出来的是，这个风险在两个方向上不对称：

• 从硅基流动迁出时，如果你把 Pro/ 前缀带到了别的平台，对方不认识这个 ID，会明确报错。虽然烦，但你当场就知道了。
• 迁入硅基流动时，前缀丢了不报错。你会以为迁移成功。

所以真正需要加一道门的是迁入方向。可做的三件事：

1. 把 model ID 收成配置里的单一出口，业务代码一律不许出现模型名字面量。
2. 服务启动时把实际生效的 model ID 打进日志，并对需要付费档的那几个模型做前缀断言——断言失败就拒绝启动，而不是打个 warn 了事。
3. 灰度期间的验收指标不看返回体，看P95 延迟和限流比例。功能对账在这里没有鉴别力。

三、限速模型换了，客户端限流策略得重调

硅基流动的限速按官方限速文档是两个独立维度：RPM（每分钟请求数）与 TPM（每分钟 token 数），两者任一触顶都会限流。实践上 TPM 常常先于 RPM 触顶——一次请求吃掉的 token 越多，同样的 RPM 下越早撞上 TPM 的墙。所以「我 RPM 明明没用满，怎么被限流了」在这套口径下是正常现象，不是 bug。

再叠一层：分层限速按官方公告设了六种用量级别（0 到 5），按账号的月度消耗金额划分，新注册账号默认落在最低级，等级越高 RPM/TPM 越高，也提供通过充值一步到位的「等级包」升级。

这条对迁移的含义比它看起来的更大：限速在这里不是一个固定规格，而是随消费额动态变的东西。

• 迁入时，你第一天拿到的速率是新账号的最低档，不是这个平台的能力上限。如果你拿第一天的压测结果去做容量规划，会低估；反过来，如果你按未来的等级去设计客户端并发，头几天就会被限流打脸。
• 迁出时，你在老平台靠长期消费攒下来的等级不会跟着搬走。在老平台跑得很顺的并发配置，换家之后可能一上线就撞墙。

所以迁移窗口里客户端的限流器、重试与退避参数都得重新标定一遍，而且要按你自己业务的 token/请求比去标——长上下文的检索增强场景和短问答场景，在同一套 RPM/TPM 下的实际可用吞吐完全是两回事。这块的机制细节另有一篇专门拆解，见 硅基流动的限速怎么算。

各等级的具体 RPM/TPM 数值、等级包价格、以及哪些模型有免费版，本文一律不写：这些是会变的，也是以官方模型广场与限速文档为准的东西。模型广场在 https://cloud.siliconflow.cn/models，模型、价格与限速都能在那里看到，迁移前自己拉一遍当天的口径，比信任任何一篇文章里的数字都可靠。

四、扩展字段与平台特性依赖

第三块要拆的是隐式依赖。两类：

一类是返回体里各家自己加的字段。 OpenAI 协议规定的那部分字段各家都有，但很多平台会在响应里多塞几样自己的东西。一旦你的代码读了这些字段——哪怕只是打日志或者做个统计——换平台之后这处访问就会拿到空值。空值本身也常常不报错，而是让下游的某个统计悄悄归零。这里我不列具体字段名，因为那属于各平台文档的内容，随版本会变；该做的是自己去 diff：把两边 SDK 的原始响应对象各打一份完整日志，逐字段比，而不是凭印象列清单。

另一类是平台侧的能力。 比如多供货方之间的路由、失败自动回退这类由聚合层提供的行为。这类东西迁走之后没有对应物，得在客户端自己实现，或者放到自建网关那一层去做——这是个要单独估工的决定，不是迁移脚本能顺手带过去的。

一个能一劳永逸的做法是：在你自己的代码和任何上游之间夹一层薄薄的 DTO，业务只认这层 DTO 的字段。这样每次换上游只需要改映射，改动面是可枚举的，而不是靠 grep 全仓库找有多少处读了上游返回。

五、条款与账务口径也要过一遍

迁移不只是技术动作。硅基流动《用户协议》给出的授权口径是「非排他性的、不可转让的」访问和使用权，仅用于个人使用或所代表公司／实体的内部业务目的，未明确授予的权利全部保留；同时约定未经事先书面同意，不得购买、出售或转让 API 密钥，不得复制、出租、出售、贷款、转让、许可或意图转授、转售、分发本服务的任何部分或其知识产权。另外《用户充值协议》里还有一条容易被忽略：如果委托第三方代充值，平台一旦被该第三方告知充值未经其同意，有权立即封禁账户，封禁期间 API 请求等全部服务暂停。

对迁移的实际含义是三条：

• 如果你迁入之后打算把能力再供给外部客户用，这属于需要事先谈的范围，不是配置问题。顺带说一句，这条路是通的而不是堵死的——按 Lead 于 2026-09-15 用 OpenRouter 官方 /api/v1/models/{id}/endpoints 接口的实测，deepseek/deepseek-chat-v3.1 在 OpenRouter 上的供货方列表里就包含 SiliconFlow，同列还有 DeepInfra、Novita、AtlasCloud、CoreWeave、Mara、Google、SambaNova。它自己就在做 B2B 供货，那条「需事先书面同意」是商务通道的入口。
• 账号主体要和你的实际使用主体对上，别用个人号承载公司业务再往外分发。
• 充值渠道要走自己的，代充带来的风险是账户级的、立刻生效的，迁移期间账户被停等于回滚窗口也一起没了。

以上只是条款原文的转述与它约束了什么，不构成法律意见，实际判断请找你自己的法务。更完整的合规视角见 中转服务的合规边界。

顺便交代一句平台性质：硅基流动不是模型厂商，是推理云平台／模型聚合器——把开源模型统一接入，由平台做托管、负载均衡与推理优化，你不用自己在 GPU 上部署。据公开报道，公司成立于 2023 年 8 月，2026 年 6 月完成 B 轮融资并递交了港交所上市申请（金额本文不写）。这层身份决定了上面那些条款为什么这么写：它既做零售也做批发。

六、可勾的迁移检查清单

按四组走，每组做完再进下一组。

A. 接入层（最简单的一组，别在这里花时间）

• base_url 改完，确认带不带 /v1 的写法与 SDK 预期一致
• key 从控制台新建，而不是复用任何共享的 key
• base_url 与 model ID 放进同一个配置结构，保证它们只能成对切换（这两个单独改任何一个都会出事）
• 老平台的 key 保留但降权，不要在迁移当天就吊销——回滚要用

B. 模型标识（本次迁移最危险的一组）

• 全仓库 grep，确认业务代码里没有模型名字面量，全部走配置
• 逐个模型确认命名是「厂商/模型名」的哪一种大小写与分段形态，照文档抄，不靠猜
• 需要付费加速档的模型，确认配置里带 Pro/ 前缀
• 启动时打印生效的 model ID，并对付费档做前缀断言，断言失败拒绝启动
• 测试环境如果故意用免费档，确认它和生产的配置来源是物理隔离的两份
• 迁出方向：确认没有把 Pro/ 前缀带到新平台（这个会报错，但别让它在生产报）

C. 限速与容量

• 按自己业务真实的 token/请求比，分别估一遍会先撞 RPM 还是先撞 TPM
• 客户端限流器的阈值重新标定，不沿用老平台的数字
• 重试与退避策略重看：限流错误要退避，不要立刻重试放大压力
• 明确当前账号处在哪个用量等级，以及这个等级会随消费额变化，容量规划别按第一天的观测做
• 灰度期间盯 P95 延迟与限流比例，而不是只看成功率
• 当天去模型广场核一遍你要用的每个模型的限速与计费口径

D. 扩展字段与账务

• 两边的原始响应对象各打一份完整日志，逐字段 diff，列出你实际依赖的非标准字段
• 依赖的平台侧能力（路由、回退等）确认在新方案里由谁承担
• 用量统计与成本归集的口径对齐，确认迁移前后的报表可比
• 授权范围与使用场景过一遍，确认不落在需要事先书面同意的那一类
• 充值渠道自持，不走第三方代充

七、如果迁移的目的地是国内网关

有一类迁移的动机不是换平台，而是想把某几个模型的流量收到一个更好管的入口上。这时候力达云是可选项之一，但必须把限制先说清楚：它一期只接 DeepSeek，如果你在硅基流动上用的是别家的开源模型，那这条路给不了你对应物；它是独立第三方，与任何模型厂商都没有官方合作、代理或授权关系。这两条都写在 我们的身份与边界说明 里，迁移前先看那一页，别先接后发现不适用。

更常见也更稳的做法不是整体迁移，而是按模型分流：把 base_url 与 model ID 收成配置之后，让不同模型走不同上游，逐个评估、逐个切。挑上游时该比什么、不该比什么，可以对着 国内推理平台横向对比 那套维度过一遍，别只看单价。

八、诚实的判断

迁移成本主要不在代码。改 base_url 和 key 是一个下午的事，把 SDK 换成兼容调用也不难。真正吃时间的是把「隐式依赖平台特性」的地方找出来——散落的模型名字面量、按老平台限速调出来的并发参数、读了非标准返回字段的那几行统计代码、以及那些「在老平台上一直好用所以没人写进文档」的行为。这些东西没有编译器帮你查，只能靠一层收口和一次逐字段的 diff。

有几种情况，我的看法是别迁：

• 你在老平台上已经攒到了比较高的用量等级，而迁过去要从最低档重新爬——短期内容量反而会掉，除非新平台在别的维度上有你非要的东西。
• 你依赖的是聚合层的路由与回退行为，而迁移后没人接手这部分。自己实现不是不行，但那是一个需要单独立项的工程，不是迁移的附带产物。
• 你的主要负载是闭源旗舰模型。这类模型的入口本来就少，换聚合层通常换不出新选择。

最后一句留给那个前缀：功能等价、容量不等价的变更，是所有迁移里最难被测试捕获的一类。 你的测试套件在验「答得对不对」，它变的是「答得多快、能答多少」。所以迁移的验收指标必须包含容量维度，否则这类问题只会在流量高峰那天，以一种和迁移看起来毫无关系的方式暴露出来。