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，且不含尾部斜杠
# 本地私有化部署快速入门使用 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 Chat 模型提供每 Token 价格，因此这些别名无需额外配置即可进行用量和预算核算。该目录未收录 SiliconFlow Embedding 或音频模型，因此请为 Embedding 或转录别名添加价格覆盖项。

对于按时长计费的转录模型，请配置其每分钟音频费率。语音请求会显示为零 Token 用量事件，但 AISIX 不会应用按字符计费的文本转语音定价。请参阅模型定价和成本元数据。

创建调用方 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：

# AISIX_PROXY 不含尾部斜杠或端点路径
# 本地快速入门使用 http://127.0.0.1:3000
export AISIX_PROXY="YOUR_AISIX_GATEWAY_URL"

通过 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 精选适配器映射，AISIX 不会为其注册服务提供方特定的请求或响应重写规则。网关使用标准 OpenAI 兼容 Chat 形态。当 SiliconFlow 重命名参数，或某个托管模型偏离该形态时，需要在服务提供方密钥上配置相应调整。

服务提供方密钥覆盖项会由引用该密钥的每个模型继承。在 AISIX Cloud 中，就地更新现有服务提供方密钥。在开源 AISIX 网关中，更新声明式资源文件中的对应条目。

Admin API 会整体替换提供的每个 request 或 response 块。前面创建的服务提供方密钥没有覆盖项，因此下面的 request 块是完整的。如果要更新已经包含覆盖项的密钥，请先获取其详情，并在提供的每个块中包含所有希望保留的设置。省略整个块会保持该块不变，提供空对象则会清除它。

无论通过 AISIX Cloud 还是资源文件更新，覆盖项都会影响引用该服务提供方密钥的每个模型别名。如果该密钥承载生产流量，请先在仅供非生产别名使用的单独服务提供方密钥上验证相同覆盖项，并在受控变更窗口内更新共享密钥。

curl -sS -X PATCH "$AISIX_CP/provider_keys/$PROVIDER_KEY_ID" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "request": {
      "param_renames": {
        "max_completion_tokens": "max_tokens"
      }
    }
  }'

该请求省略了 response 和凭证字段，因此这些设置保持不变，模型也会继续引用同一个服务提供方密钥。

对于开源 AISIX 网关，请在 provider_keys 中现有的 siliconflow-prod 条目上添加下面的 request.param_renames 映射。保留该条目的所有其他字段以及其他条目和集合，不要创建第二个顶层 provider_keys 键：

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

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

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

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

有关完整字段目录，请参阅服务提供方特定覆盖项。

端点覆盖范围

SiliconFlow 提供多种 OpenAI 形态的推理路由，但 siliconflow 服务提供方值不在部分代理路由执行的允许列表中。下表说明 SiliconFlow 支持的别名可以和不可以提供哪些功能。

路由	使用 SiliconFlow 别名时的行为
/v1/chat/completions	支持，包括 stream: true。
/v1/responses	通过聊天适配器路径上的 Responses 桥接提供支持。没有对应 Chat 语义的 OpenAI Responses 专用字段会被忽略。
/v1/messages	通过转换到 Chat Completions 支持 Anthropic 形态的调用方，而不会调用 SiliconFlow 原生 /messages 路由。当原生 Messages 请求或响应契约很重要时，请通过 /passthrough/siliconflow/messages 发送准确的上游模型 ID。/v1/messages/count_tokens 的 Token 计数要求使用 Anthropic 支持的模型。
/v1/embeddings	当别名指向 SiliconFlow 嵌入模型时支持。openai 适配器会将 OpenAI 请求格式转发到 {api_base}/embeddings，SiliconFlow 在同一 API Root 上提供该端点。请参阅嵌入。
/v1/audio/transcriptions	当别名指向 FunAudioLLM/SenseVoiceSmall 或 TeleAI/TeleSpeechASR 等 SiliconFlow 转录模型时受支持。AISIX 会把 multipart model 字段重写为上游模型 ID，并把文件转发到 {api_base}/audio/transcriptions。
/v1/audio/speech	当别名指向 FunAudioLLM/CosyVoice2-0.5B 等 SiliconFlow 文本转语音模型时受支持。AISIX 会重写 JSON model 字段，并返回服务提供方的二进制音频响应。gain、sample_rate 和 references 等 SiliconFlow 专用字段会原样透传。
/v1/audio/translations	在上游失败。SiliconFlow 未在此 API Base 上提供音频翻译路由。
/v1/rerank	拒绝。该路由仅接受 openai、cohere 和 jina 服务提供方值，因此即使 SiliconFlow 托管重排序模型，也会拒绝 siliconflow 别名。请改用透传路由访问 SiliconFlow 重排序服务。请参阅重排序。
/v1/images/generations	拒绝。该路由只接受服务提供方为 openai 的模型。
/v1/videos	返回 501 not_implemented 并拒绝请求。该路由根据自身的服务提供方允许列表进行分发，其中不包含 siliconflow。
/passthrough/siliconflow/*	通过已配置的透传路由可用于服务提供方原生路由，网关标准化有限。授权来自调用方 Key 的 allowed_routes，而不是其模型允许列表。

本页的 /passthrough/siliconflow 路径假定一条透传路由认领该前缀，target_url 设为 SiliconFlow 的 API 根地址；在调用方 Key 的 allowed_routes 上授予路由名称。对于原生 Messages 和 Rerank 等没有标准化网关接口的 SiliconFlow 功能，透传是实用的访问方式。由于路由的 target_url 已以 /v1 结尾，AISIX 会移除透传路径开头重复的 /v1，因此 /passthrough/siliconflow/rerank 和 /passthrough/siliconflow/v1/rerank 都会解析到同一个上游 URL。

后续步骤

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

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