硅基流动 API 地址怎么填？端点、兼容层与常见填错

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

硅基流动的 API 地址之所以容易填错，是因为它在文档里其实有两个形态：一个是基址 https://api.siliconflow.cn/v1，用在 SDK 的 base_url 参数上；另一个是聊天端点的完整地址 https://api.siliconflow.cn/v1/chat/completions，用在 curl 或者自己拼 HTTP 请求的场景。两者差的就是末尾 /chat/completions 这一段，谁该带谁不该带，是这一类问题的全部来源。鉴权那一侧同样只有一条规则：请求头 authorization: Bearer <你的 apikey>。官方文档说明该平台兼容 OpenAI 与 Anthropic 的对话协议，大语言模型可以直接用 OpenAI 官方库调用，只要把 base_url 指向上面那个基址——也就是说，从别处迁过来时，代码里真正要动的其实只有基址和模型名两处。

先分清两个地址：基址和端点

官方文档在接入说明里同时给出了这两个字符串：

• 基址：https://api.siliconflow.cn/v1
• 聊天端点：https://api.siliconflow.cn/v1/chat/completions

它们不是「新旧两版」，也不是「两个可选的服务器」，而是同一条路径的两个截取长度。基址截到 /v1 为止，端点在它后面再接一段具体功能的路径。

分界线在于谁来补后面那一段。官方给出的 Python 示例里，传给 OpenAI 客户端的是基址那个版本（OpenAI(api_key=..., base_url="https://api.siliconflow.cn/v1")），而聊天端点的完整地址是在这个基址后面再接 /chat/completions——剩下这段路径由客户端库按你调用的方法自己拼上去，不需要你写进配置里。

反过来，如果你不走 SDK，而是直接用 curl 或者自己发 HTTP 请求，那就得用完整端点那个版本，因为这时候没有任何东西会替你补路径。

这条区别在图形界面的客户端里最容易翻车。很多第三方工具的配置项名字就叫「API 地址」「服务器地址」「接口地址」，光看名字看不出它要的是哪一段。判断办法是看这个工具让不让你自己选接口类型：如果它明确说自己走的是 OpenAI 兼容接口、并且还有一个单独的模型名输入框，那它要的通常是基址那一段；如果它让你填一整条 URL 并且没有任何拼接说明，那多半要的是完整端点。填之前先在工具自己的文档里确认一次，比填错了再按报错猜要省事。

鉴权头怎么写

地址对了，鉴权头写错一样过不去。官方文档给的写法是：

authorization: Bearer <你的 apikey>

有两个点容易被忽略：一是 Bearer 和 key 之间有一个空格，这是 HTTP 鉴权头的固定格式，粘贴时被吞掉或者变成两个空格都可能出问题；二是很多人会把 key 前后的引号、换行、或者从页面复制时带出来的空白字符一起粘进去。

key 本身在控制台的「API 密钥」页面新建。账号侧，官方文档写明目前支持短信登录和邮箱登录两种方式——如果你在团队里是用某个统一入口进来的，先确认自己拿到的 key 属于哪个账户，这一点后面会再提到，它是「地址明明没错却一直不通」的一个常见根因。

key 一旦泄漏就等同于账户被人白用（限流还是账户级共享的），粘到第三方客户端、CI 变量、甚至截图里之前，先想清楚泄漏之后怎么处置。这部分的通用做法可以看API Key 安全管理。

兼容层兼容到哪一层

官方文档的表述是：平台兼容 OpenAI 与 Anthropic 的对话协议，大语言模型可以直接用 OpenAI 官方库调用，只需把 base_url 指向平台基址。官方示例要求 Python 3.7.1 或更高版本。

这句话的实际含义，对迁移来说是最有价值的一条信息：你原来那套用 OpenAI 官方库写的代码，结构不用动。客户端初始化的方式不变，调用方法不变，请求体的字段名不变，要改的是两个地方——base_url 指到硅基流动的基址，model 换成平台上的模型名。

模型名这一栏比地址更容易出问题，因为它不是你熟悉的那个短名字。官方文档里说明了一条命名规则：部分模型同时有免费版和收费版，免费版按原名称命名，收费版在名称前面加 Pro/ 前缀。也就是说同一个模型在平台上可能有两个名字，选哪个直接决定这次调用走的是哪一档资源。DeepSeek 的 R1 与 V3 更进一步，官方说明它们是按支付方式区分命名的：Pro/ 版仅支持充值余额支付，非 Pro/ 版则支持赠费余额和充值余额支付。

所以「地址填对了但模型报错」是很正常的一件事——那是两个独立的字段，各自有各自的填法。模型不存在时，官方给出的错误响应形态是这样的：

{"code":20012,"message":"Model does not exist. Please check it carefully.","data":null}

看到这条就不用再回去折腾地址了，问题在 model 那一栏。

至于 Anthropic 协议那一侧，本次核到的官方页面只写了「兼容 Anthropic 对话协议」这句结论，并没有单独给出 Anthropic 协议对应的端点路径和调用示例。所以如果你打算用 Anthropic 风格的 SDK 接入，具体该填哪条路径，请以官方文档当前版本为准，不要拿别家平台的路径套过来试。

地址相关的几种典型填错

把上面两条规则倒过来看，就是几种典型的错法：

把完整端点粘进了 base_url。 这时候客户端库还会在后面接一段功能路径，最终请求的路径就会多出一截。官方文档没有针对这种情况单独列出返回哪个错误码，所以别指望靠状态码把它认出来——最快的确认方式是把你实际配置的那个字符串打印出来，跟官方基址逐字符比一遍。

只填到域名，漏掉了 /v1。 官方给的基址是带 /v1 的，这一段属于地址本身，不是可选后缀。

协议头写成了 http。 官方给的两个地址都是 https。

在工具里同时填了地址和一个「路径前缀」之类的额外配置。 有些客户端把 URL 拆成两三栏让你分别填，拆法各家不同，填之前按该工具的说明对一遍，别按印象填。

还有一类不算地址错、但表现很像的：开了代理。官方给的通用排查步骤里明确有一条——如果开了代理，关闭代理再试。代理会让请求实际走到别的地方去，而你在配置里看到的地址却是对的。

通不过的时候，按官方的排查顺序走

官方文档给出的通用排查步骤是四步，顺序值得照做：

1. 把错误码和 message 打印出来（不要只看客户端弹的那句概括）
2. 用 curl 复现一次
3. 换一个模型试
4. 如果开了代理，关闭代理再试

第二步是这里面最关键的。用 curl 复现的意义在于：它把 SDK、第三方客户端、以及各种配置项拼接逻辑全都摘出去了，只剩下地址、鉴权头、请求体三样东西。curl 通了、程序不通，问题就在你的客户端配置；curl 也不通，那才是地址或者账户层面的事。

拿到错误码之后，官方文档的错误码表可以直接倒推（以官方文档为准）：

HTTP	官方给的原因
400	参数不正确，按 message 修正非法请求参数
401	API Key 没有正确设置
402	账户欠费，充值后重试
403	权限不够，最常见原因是该模型需要实名认证
429	触发 rate limits，按 message 判断是哪一种指标
503 / 504	服务负载较高，稍后再试；对话与 TTS 请求可尝试改用流式输出
500	未知错误，联系官方排查

对新手来说最反直觉的是 403。按字面理解「权限不够」很容易往 key 权限、模型授权上想，但官方写得很清楚：最常见的原因是该模型需要实名认证。这不是接入配置问题，是账户状态问题，地址怎么改都没用。更多按状态码倒推的细节可以看硅基流动报错排查。

地址没错，也可能是账户那一侧的事

有两类情况会让人反复怀疑地址，但根因都在账户：

已经充值成功，却还提示余额不足。 官方给的排查方向是：先确认你用的 api_key 是不是跟刚充值的那个账户匹配；另外也可能存在网络延迟，等几分钟再重试。多账号、或者团队里有人代充的场景下，第一条命中率不低。

429 一直触发。 这里有一条机制值得单独记住：官方文档说明 Rate Limit 是定义在用户账户级别的，不是 API key 维度。所以为了绕限流去多建几把 key 是没有意义的，它们共享同一份账户配额。另外每个模型的限额是单独设置的，一个模型超限不影响其他模型；触发条件也不是「几项都超才算」，而是官方列出的那几种指标里任意一项先达峰即触发。触发之后官方推荐的做法是等待后重试，并采用指数退避。这套退避逻辑各家平台是通用的，写法可以参考API 返回 429 的通用处理。

最后：填之前对一遍这四样

地址这件事真正需要你确认的东西不多，就四样：

• 你填的这一栏要的是基址还是完整端点——按工具文档确认，不按名字猜
• 基址那个版本末尾有没有 /v1
• 鉴权头是不是 authorization: Bearer 加一个空格再加 key，key 前后有没有混进空白字符
• model 那一栏填的是不是平台上的完整模型名，要不要带 Pro/ 前缀

四样都对还是通不过，就别在配置界面里继续试了——按官方那四步排查走一遍，打印错误码、用 curl 复现、换模型、关代理。真正的答案往往不在地址栏里，而在返回体的 message 那一行。想从零开始把整条链路配通，可以从硅基流动 API 接入那篇看起。