SiliconFlow

SiliconFlow 托管来自多个模型组织的模型并提供推理服务。AISIX 将服务提供方凭证保留在网关中，同时为应用提供覆盖该目录的稳定别名。

准备工作

开始前，请准备以下内容：

• 一套 AISIX 环境：
  • 对于 AISIX Cloud，需要一个已关联网关的环境和具有写入作用域的 Admin Token。对于 On-Premises，请按照 AISIX Cloud 快速入门操作。如需申请 Hybrid Cloud 访问权限，请联系 API7。
  • 对于开源 AISIX 网关，请准备本地 AISIX 安装，或使用开源 AISIX 网关快速入门中的 Docker 环境。配置网关以加载声明式资源文件。
• 从 SiliconFlow 控制台获取的 SiliconFlow API Key。
• curl 和 jq。

选择 SiliconFlow 平台

SiliconFlow 运营两个平台，模型目录为每个平台提供一个服务提供方 ID：

目录服务提供方 ID	API Root	适用场景
siliconflow	https://api.siliconflow.com/v1	API Key 由 siliconflow.com 平台签发。
siliconflow-cn	https://api.siliconflow.cn/v1	API Key 由 siliconflow.cn 平台签发。

目录将两个平台建模为独立服务提供方，并分别使用凭证变量 SILICONFLOW_API_KEY 和 SILICONFLOW_CN_API_KEY。因此，请将它们视为独立账户，并选择与密钥签发平台匹配的服务提供方 ID。以下示例使用 siliconflow。如果你的账户位于另一个平台，请在全文中将其替换为 siliconflow-cn 和 https://api.siliconflow.cn/v1。

使用 AISIX Cloud 配置

导出 AISIX Cloud 连接信息：

# AISIX_CP 是 Admin API 基础 URL；应包含 /api，且末尾不带斜杠
# 本地 On-Premises 快速入门使用 http://localhost:8080/api
export AISIX_CP="YOUR_AISIX_CLOUD_ADMIN_API_URL"
export AISIX_TOKEN="YOUR_ADMIN_TOKEN"
export ENV_ID="YOUR_ENVIRONMENT_ID"

为 SiliconFlow 支持的 Chat Completions 路由创建服务提供方密钥、模型别名和调用方 API Key。

SiliconFlow 是使用 OpenAI 兼容 API 的社区目录服务提供方。AISIX 通过 openai 适配器连接，使用 Bearer Token 对上游请求进行身份认证，并将 SiliconFlow API Root 用作 api_base。AISIX 不会注册 SiliconFlow 特有的请求或响应重写规则。

控制台将该服务提供方标记为传输格式未经验证的社区条目。

创建服务提供方密钥

创建用于存储 SiliconFlow 凭证和 API Root 的服务提供方密钥：

# 请替换为实际值
export SILICONFLOW_API_KEY="YOUR_PROVIDER_API_KEY"

PROVIDER_KEY_ID=$(curl -sS -X POST "$AISIX_CP/provider_keys" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "siliconflow-prod",
    "provider": "siliconflow",
    "api_key": "'"${SILICONFLOW_API_KEY}"'",
    "api_base": "https://api.siliconflow.com/v1",
    "allowed_environments": ["'"${ENV_ID}"'"]
  }' | jq -r '.provider_key.id')

echo "$PROVIDER_KEY_ID"

❶ provider 为 siliconflow。AISIX Cloud Admin API 接受该值，是因为此 ID 存在于其缓存的 models.dev 目录中，并且它会从目录推导适配器。不要发送 adapter 字段：仅当 provider 为 byo 哨兵值时才接受该字段；在目录服务提供方密钥中发送它会返回 400 错误。

❷ api_key 存储 SiliconFlow API Key。SiliconFlow 使用 HTTP Bearer 身份认证，openai 适配器已经会发送该认证信息，因此无需额外配置请求头。该值遵循服务提供方密钥中的凭证处理行为。

❸ api_base 为 https://api.siliconflow.com/v1。SiliconFlow 文档中的完整聊天端点是 POST https://api.siliconflow.com/v1/chat/completions，因此 Root 已包含 /v1，AISIX 会在其后追加 /chat/completions 等端点路径。对于 siliconflow，此字段可选：models.dev 会将同一值发布为服务提供方的 API 字段，省略时 AISIX Cloud Admin API 会自动填充。仍建议显式设置该字段，以便在配置中清楚显示每个密钥所指向的 Root，并避免密钥依赖可能早于服务商 URL 变更的目录快照。

该命令会把返回的服务提供方密钥 ID 保存到 PROVIDER_KEY_ID。

创建模型

SiliconFlow 模型 ID 带有组织命名空间。ID 由模型组织、斜杠和模型名称组成，且前后两部分均区分大小写。当前示例包括 deepseek-ai/DeepSeek-V3.2、zai-org/GLM-5.2、Qwen/Qwen3.6-27B、moonshotai/Kimi-K2.6 和 openai/gpt-oss-120b。创建别名前，请在 SiliconFlow 模型目录中查看当前列表，因为托管模型集合会随着模型新增和退役而变化。

创建调用方将在请求中发送的模型别名：

MODEL_ID=$(curl -sS -X POST "$AISIX_CP/environments/$ENV_ID/models" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "siliconflow-deepseek-prod",
    "model_name": "deepseek-ai/DeepSeek-V3.2",
    "provider_key_id": "'"${PROVIDER_KEY_ID}"'"
  }' | jq -r '.model.id')

echo "$MODEL_ID"

❶ display_name 是调用方在 model 中发送的别名。

❷ model_name 是包含组织前缀的 SiliconFlow 模型 ID。该前缀表示模型组织，而不是上游服务提供方。SiliconFlow 上 openai/gpt-oss-120b 的别名仍以 siliconflow 作为服务提供方值，网关的逐路由服务提供方规则会对此值进行判断。

❸ provider_key_id 将别名关联到 SiliconFlow 服务提供方密钥。

models.dev 目录为其收录的 SiliconFlow 聊天模型提供每 Token 价格，因此这些别名无需额外配置即可进行用量和预算核算。该目录未收录 SiliconFlow 嵌入模型，因此请为嵌入模型别名添加价格覆盖项。请参阅模型定价和成本元数据。

创建调用方 API Key

创建能够访问该模型别名的调用方 API Key。明文密钥由服务器生成，并只在创建响应中返回一次，因此请立即保存：

AISIX_API_KEY=$(curl -sS -X POST "$AISIX_CP/environments/$ENV_ID/api_keys" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "siliconflow-caller",
    "allowed_models": ["'"${MODEL_ID}"'"]
  }' | jq -r '.plaintext')

echo "$AISIX_API_KEY"

allowed_models 值必须引用上一步保存的模型 ID。写入后，配置会自动投射到已关联的网关。

使用开源 AISIX 网关配置

导出上游凭证，并选择应用将发送给网关的调用方 API Key：

export SILICONFLOW_API_KEY="YOUR_PROVIDER_API_KEY"
export CALLER_API_KEY="YOUR_CALLER_API_KEY"

为该服务提供方创建完整的声明式资源文件：

resources.yaml

_format_version: "1"

provider_keys:
  - display_name: "siliconflow-prod"
    provider: "siliconflow"
    adapter: "openai"
    api_key: ${SILICONFLOW_API_KEY}
    api_base: "https://api.siliconflow.com/v1"

models:
  - display_name: "siliconflow-deepseek-prod"
    provider: "siliconflow"
    model_name: "deepseek-ai/DeepSeek-V3.2"
    provider_key: "siliconflow-prod"

api_keys:
  - display_name: "siliconflow-caller"
    key_env: CALLER_API_KEY
    allowed_models:
      - "siliconflow-deepseek-prod"

如果 AISIX 安装在本地，请在加载前验证文件：

aisix validate --resources resources.yaml

验证后，在网关进程环境中提供文件引用的环境变量，再启动网关。仅当这些变量已经可供进程使用时，才重新加载现有网关；否则，请使用更新后的环境重启网关。

如果使用 Docker，请调整开源 AISIX 网关快速入门中的验证和启动命令。挂载此 resources.yaml 文件，并在两条命令中使用 -e 传入它引用的每个环境变量。资源加载后，准备下文共用的验证请求：

export AISIX_API_KEY="$CALLER_API_KEY"

验证服务提供方连接

导出 AISIX 网关 Origin：

# 本地快速入门使用 http://127.0.0.1:3000
export AISIX_PROXY="YOUR_AISIX_GATEWAY_ORIGIN"

通过 AISIX 代理发送 Chat Completions 请求：

curl -sS -X POST "$AISIX_PROXY/v1/chat/completions" \
  -H "Authorization: Bearer ${AISIX_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "siliconflow-deepseek-prod",
    "messages": [
      {
        "role": "user",
        "content": "Say hello from SiliconFlow."
      }
    ]
  }'

网关返回 OpenAI 兼容响应，并回显调用方可见的别名 siliconflow-deepseek-prod。

以下两种失败模式可以区分凭证问题和 URL 问题：

• 上游身份认证错误通常指向 api_key，或表示密钥的签发平台与配置的服务提供方 ID 不匹配。
• 上游返回 404 通常指向 api_base。AISIX 会从 api_base 中移除粘贴的 /chat/completions 等端点后缀和末尾斜杠，但不会为非 OpenAI 主机补充缺失的 /v1 路径段。因此，https://api.siliconflow.com 会解析为 https://api.siliconflow.com/chat/completions，而这并不是 SiliconFlow 路由。

如果请求因模型不存在而被拒绝，请将 model_name 与 SiliconFlow 目录进行对照，并检查 ID 前后两部分的大小写。

透传推理控制参数

SiliconFlow 将推理控制参数放在 Chat Completions 请求体顶层，而不是嵌套对象中：

参数	类型	作用
enable_thinking	boolean	在思考模式和非思考模式之间切换混合推理模型。
thinking_budget	integer	限制思维链消耗的 Token 数量。SiliconFlow 文档规定范围为 128 到 32768。

AISIX 仅对一组固定的聊天参数建模，例如 temperature、top_p、max_tokens 和 stream。其他所有顶层参数都会原样转发到上游，因此这两个控制参数会原封不动地到达 SiliconFlow：

{
  "model": "siliconflow-deepseek-prod",
  "messages": [
    {
      "role": "user",
      "content": "Plan a three-step migration."
    }
  ],
  "enable_thinking": true,
  "thinking_budget": 4096
}

这些参数的支持情况取决于模型，而不是服务提供方。一个由 SiliconFlow 托管的模型接受的值可能会被另一个模型拒绝，因此请在 SiliconFlow Chat Completions 参考中确认所配置模型支持的控制参数。

在响应侧，SiliconFlow 通过 reasoning_content 返回思维链，该字段已是 AISIX 对流式和非流式响应采用的规范字段。使用该字段的模型无需配置响应覆盖项。如果某个特定模型通过其他 delta 路径流式返回推理内容，请在服务提供方密钥上设置 response.reasoning_field。

配置传输格式覆盖项

由于 SiliconFlow 没有精选目录条目，AISIX 不会为其注册请求或响应重写规则。网关会发送调用方提交的内容，并返回上游返回的内容。这是 OpenAI 兼容上游的正确默认行为，也划定了运维人员的责任边界：当 SiliconFlow 重命名参数，或某个托管模型偏离 OpenAI 格式时，需要在服务提供方密钥上配置相应调整。

两个覆盖项可以处理常见场景，并会被引用该服务提供方密钥的所有模型继承。在 AISIX Cloud 中，必须在创建服务提供方密钥时包含这些覆盖项，因为更新端点不接受 request 或 response。在开源 AISIX 网关中，请更新声明式资源文件中的服务提供方密钥条目。

对于 AISIX Cloud，请使用完整配置创建替代服务提供方密钥，并将模型别名重新指向该密钥：

OVERRIDE_PROVIDER_KEY_ID=$(
  curl -sS -X POST "$AISIX_CP/provider_keys" \
    -H "Authorization: Bearer $AISIX_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "display_name": "siliconflow-overrides",
      "provider": "siliconflow",
      "api_key": "'"${SILICONFLOW_API_KEY}"'",
      "api_base": "https://api.siliconflow.com/v1",
      "allowed_environments": ["'"${ENV_ID}"'"],
      "request": {
        "param_renames": {
          "max_completion_tokens": "max_tokens"
        }
      },
      "response": {
        "reasoning_field": "delta.thinking"
      }
    }' | jq -er '.provider_key.id'
)

curl -sS -X PATCH "$AISIX_CP/environments/$ENV_ID/models/$MODEL_ID" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "provider_key_id": "'"${OVERRIDE_PROVIDER_KEY_ID}"'"
  }'

对于开源 AISIX 网关，请将相同的配置块添加到现有服务提供方密钥条目中：

resources.yaml

provider_keys:
  - display_name: "siliconflow-prod"
    provider: "siliconflow"
    adapter: "openai"
    api_key: ${SILICONFLOW_API_KEY}
    api_base: "https://api.siliconflow.com/v1"
    request:
      param_renames:
        max_completion_tokens: max_tokens
    response:
      reasoning_field: "delta.thinking"

按照上述说明验证声明式资源文件，然后重新加载或重启网关。

request.param_renames 会在请求发往上游时重命名顶层参数。当客户端发送当前 OpenAI 参数名而上游需要旧名称，或情况相反时，请使用此配置。如果请求同时携带两个名称，AISIX 会保留原始调用方参数名对应的值。

response.reasoning_field 会将非标准流式 delta 路径中的推理内容提升到规范的 delta.reasoning_content。仅当模型确实存在差异时才设置此项；SiliconFlow 文档中的字段已是规范字段。

在 AISIX Cloud 中，模型更新会将 MODEL_ID 切换到替代密钥；删除旧服务提供方密钥前，请验证该别名。在两种产品中，覆盖项都会应用于同一密钥上的所有别名，因此请先使用非生产别名进行测试。有关完整字段目录，请参阅服务提供方特定覆盖项。

端点覆盖范围

SiliconFlow 是仅提供推理功能的上游，而 siliconflow 服务提供方值不在部分代理路由执行的允许列表中。下表说明 SiliconFlow 支持的别名可以和不可以提供哪些功能。

路由	使用 SiliconFlow 别名时的行为
/v1/chat/completions	支持，包括 stream: true。
/v1/responses	支持通过聊天适配器路径上的 Responses 桥接。
/v1/messages	通过转换支持 Anthropic 形态的调用方。/v1/messages/count_tokens 的 Token 计数要求使用 Anthropic 支持的模型。
/v1/embeddings	当别名指向 SiliconFlow 嵌入模型时支持。openai 适配器会将 OpenAI 请求格式转发到 {api_base}/embeddings，SiliconFlow 在同一 API Root 上提供该端点。请参阅嵌入。
/v1/rerank	拒绝。该路由仅接受 openai、cohere 和 jina 服务提供方值，因此即使 SiliconFlow 托管重排序模型，也会拒绝 siliconflow 别名。请改用透传功能访问 SiliconFlow 重排序服务。请参阅重排序。
/v1/images/generations	拒绝。该路由只接受服务提供方为 openai 的模型。
/v1/videos	返回 501 not_implemented 并拒绝请求。该路由根据自身的服务提供方允许列表进行分发，其中不包含 siliconflow。
/passthrough/siliconflow/*	支持服务提供方原生路由，并提供有限的网关标准化。隧道会借用调用方密钥有权使用的第一个 SiliconFlow 别名所对应的凭证和 api_base，因此调用方密钥的 allowed_models 中仍需包含一个 SiliconFlow 模型。请参阅服务提供方透传。

对于重排序等没有标准化网关接口的 SiliconFlow 功能，透传是实用的访问方式。由于服务提供方密钥的 api_base 已以 /v1 结尾，AISIX 会移除透传路径开头重复的 /v1，因此 /passthrough/siliconflow/rerank 和 /passthrough/siliconflow/v1/rerank 都会解析到同一个上游 URL。

后续步骤

现在，你已将 AISIX 连接到 SiliconFlow，并验证了模型别名。请继续阅读以下指南：

• 模型别名：为此别名配置路由、重试行为或成本元数据。
• 路由和故障转移：在 SiliconFlow 和第二个服务提供方之间进行故障转移，或按成本或延迟对目标进行排序。
• 服务提供方特定覆盖项：当上游 API 与其适配器不同时，调整请求和响应形态。
• 服务提供方兼容性：查看支持的代理端点和服务提供方特定边界。