SiliconFlow

SiliconFlow provides hosted inference for models from multiple model organizations. AISIX gives applications stable aliases across that catalog while keeping provider credentials at the gateway.

Prerequisites

Before starting, prepare the following:

One AISIX setup:
- For AISIX Cloud, an environment with an attached gateway and a write-scoped admin token. For On-Premises, follow the AISIX Cloud Quickstart. To request Hybrid Cloud access, contact API7.
- For the open-source AISIX gateway, prepare either a local AISIX installation or the Docker setup from the Open-Source AISIX Gateway Quickstart. Configure the gateway to load a declarative resources file.
A SiliconFlow API key from the SiliconFlow console.
curl and jq.

Choose a SiliconFlow Platform

SiliconFlow runs two platforms, and the model catalog carries one provider ID for each:

Catalog provider ID	API root	Use when
`siliconflow`	`https://api.siliconflow.com/v1`	The API key was issued on the `siliconflow.com` platform.
`siliconflow-cn`	`https://api.siliconflow.cn/v1`	The API key was issued on the `siliconflow.cn` platform.

The catalog models the two platforms as separate providers with separate credential variables, SILICONFLOW_API_KEY and SILICONFLOW_CN_API_KEY, so treat them as separate accounts and pick the provider ID that matches where the key was issued. The examples below use siliconflow. If your account is on the other platform, substitute siliconflow-cn and https://api.siliconflow.cn/v1 throughout.

Configure with AISIX Cloud

Export the AISIX Cloud connection details:

# AISIX_CP is the Admin API base URL; include /api and omit a trailing slash
# The local On-Premises quickstart uses 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"

Create a provider key, model alias, and caller API key for the SiliconFlow-backed chat-completions route.

SiliconFlow is a community catalog provider with an OpenAI-compatible API. AISIX connects through the openai adapter, authenticates upstream requests with a bearer token, and uses the SiliconFlow API root as api_base. AISIX does not register SiliconFlow-specific request or response rewrites.

The dashboard labels this provider as a community entry whose wire format is unverified.

Create a Provider Key

Create the provider key that stores the SiliconFlow credential and API root:

# Replace with your value
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 is siliconflow. The AISIX Cloud Admin API accepts the value because the ID is in the models.dev catalog it caches, and it derives the adapter from the catalog. Do not send an adapter field: it is accepted only when provider is the byo sentinel, and sending it on a catalog provider key returns a 400 error.

❷ api_key stores the SiliconFlow API key. SiliconFlow authenticates with HTTP bearer authentication, which is what the openai adapter already sends, so no extra header configuration is needed. The value follows the credential-handling behavior in Provider Keys.

❸ api_base is https://api.siliconflow.com/v1. SiliconFlow documents the full chat endpoint as POST https://api.siliconflow.com/v1/chat/completions, so the root already includes /v1, and AISIX appends the endpoint path such as /chat/completions to it. This field is optional for siliconflow: models.dev publishes the same value as the provider's API field, and the AISIX Cloud Admin API fills it in when you omit it. Set it explicitly anyway, so that the root each key targets stays visible in the configuration and the key does not depend on a catalog snapshot that may predate a vendor URL change.

The command captures the returned provider key ID in PROVIDER_KEY_ID.

Create a Model

SiliconFlow model IDs are org-namespaced. The ID is the model organization, a slash, and the model name, and both halves are case-sensitive: deepseek-ai/DeepSeek-V3.2, zai-org/GLM-5.2, Qwen/Qwen3.6-27B, moonshotai/Kimi-K2.6, and openai/gpt-oss-120b are current examples. Check the SiliconFlow model catalog for the current list before you create an alias, because the hosted set rotates as models are added and retired.

Create the model alias callers will send in requests:

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 is the alias callers send in model.

❷ model_name is the SiliconFlow model ID, including the organization prefix. The prefix names the model organization, not the upstream provider. An alias for openai/gpt-oss-120b on SiliconFlow still has the provider value siliconflow, which is what the gateway's per-route provider rules evaluate.

❸ provider_key_id attaches the alias to the SiliconFlow provider key.

The models.dev catalog carries per-token prices for the SiliconFlow chat models it lists, so usage and budget accounting resolve without extra configuration for those aliases. The catalog lists no SiliconFlow embedding or audio models, so add a pricing override for an embedding or transcription alias.

For a transcription model billed by duration, configure its Audio per minute rate. Speech requests appear as zero-token usage events, but AISIX does not apply character-based text-to-speech pricing. See Model Pricing and Cost Metadata.

Create a Caller API Key

Create the caller API key that can access the model alias. The plaintext key is server-generated and returned once in the create response, so capture it now:

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"

The allowed_models value must reference the model ID captured in the previous step. After the write, the configuration projects to attached gateways automatically.

Configure with the Open-Source AISIX Gateway

Export the upstream credential and choose the caller API key that applications will send to the gateway:

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

Create a complete declarative resources file for this provider:

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"

If AISIX is installed locally, validate the file before loading it:

aisix validate --resources resources.yaml

After validation, start the gateway with the referenced environment variables in its process environment. Reload an existing gateway only if those variables are already available to the process; otherwise, restart it with the updated environment.

If you use Docker, adapt the validation and startup commands in the Open-Source AISIX Gateway Quickstart. Mount this resources.yaml file and pass every environment variable it references with -e in both commands. After the resources load, prepare the shared verification request below:

export AISIX_API_KEY="$CALLER_API_KEY"

Verify the Provider Connection

Export the AISIX gateway origin:

# The local quickstarts use http://127.0.0.1:3000
export AISIX_PROXY="YOUR_AISIX_GATEWAY_ORIGIN"

Send a chat-completions request through the AISIX proxy:

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."
      }
    ]
  }'

The gateway returns an OpenAI-compatible response that echoes the caller-facing alias siliconflow-deepseek-prod.

Two failure modes separate a credential problem from a URL problem:

An upstream authentication error points at api_key, or at a key issued on the platform that does not match the configured provider ID.
An upstream 404 usually points at api_base. AISIX strips a pasted endpoint suffix such as /chat/completions and a trailing slash from api_base, but it does not add a missing /v1 segment for a non-OpenAI host. A value of https://api.siliconflow.com therefore resolves to https://api.siliconflow.com/chat/completions, which is not a SiliconFlow route.

If the request is rejected because the model does not exist, compare model_name against the SiliconFlow catalog, including the capitalization of both halves of the ID.

Pass Reasoning Controls Through

SiliconFlow puts its reasoning controls at the top level of the chat-completions body rather than inside a nested object:

Parameter	Type	Effect
`enable_thinking`	boolean	Switches a hybrid-reasoning model between thinking and non-thinking mode.
`thinking_budget`	integer	Caps the tokens spent on the chain of thought. SiliconFlow documents the range 128 to 32768.

AISIX models only a fixed set of chat parameters, such as temperature, top_p, max_tokens, and stream. Every other top-level parameter is forwarded to the upstream verbatim, so both controls reach SiliconFlow unchanged:

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

Support for these parameters is per model, not per provider. A value that one SiliconFlow-hosted model accepts can be rejected by another, so confirm the controls for the model you configured in the SiliconFlow chat-completions reference.

On the response side, SiliconFlow returns the chain of thought in reasoning_content, which is already the canonical field AISIX uses for both streaming and non-streaming responses. No response override is needed for the models that use it. If a specific model streams reasoning at a different delta path, set response.reasoning_field on the provider key.

Configure Wire Overrides

Because SiliconFlow has no AISIX-curated adapter mapping, AISIX registers no provider-specific request or response rewrites for it. The gateway uses the standard OpenAI-compatible chat shape. When SiliconFlow renames a parameter or a hosted model diverges from that shape, configure the adjustment on the provider key.

Two overrides cover the common cases and are inherited by every model that references the provider key. In AISIX Cloud, they must be included when the provider key is created because the update endpoint does not accept request or response. In the open-source AISIX gateway, update the provider key entry in the declarative resources file.

For AISIX Cloud, create a replacement provider key with the complete configuration and repoint the model alias:

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}"'"
  }'

For the open-source AISIX gateway, add the same blocks to the existing provider key entry:

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"

Validate and reload or restart the declarative resources file as described above.

request.param_renames renames a top-level parameter on the way upstream. Use it when clients send the current OpenAI name and the upstream expects the older one, or the reverse. If a request carries both names, AISIX keeps the value from the original caller-facing name.

response.reasoning_field lifts reasoning from a nonstandard streaming delta path onto the canonical delta.reasoning_content. Set this only if a model actually diverges; SiliconFlow's documented field is already canonical.

In AISIX Cloud, the model update switches MODEL_ID to the replacement key; verify the alias before deleting the old provider key. In either product, overrides apply to every alias on a key, so test them against a non-production alias first. See Provider-Specific Overrides for the full field catalog.

Endpoint Coverage

SiliconFlow serves several OpenAI-shaped inference routes, but the siliconflow provider value is outside the allowlists that some proxy routes enforce. The table below records what a SiliconFlow-backed alias can and cannot serve.

Route	Behavior with a SiliconFlow alias
`/v1/chat/completions`	Supported, including `stream: true`.
`/v1/responses`	Supported through the Responses bridge over the chat adapter path. OpenAI-specific Responses fields without a chat equivalent are ignored.
`/v1/messages`	Supported for Anthropic-shaped callers through translation to chat completions. This does not call SiliconFlow's native `/messages` route. Use `/passthrough/siliconflow/messages` with the exact upstream model ID when the native Messages request or response contract matters. Token counting at `/v1/messages/count_tokens` requires an Anthropic-backed model.
`/v1/embeddings`	Supported when the alias names a SiliconFlow embedding model. The `openai` adapter forwards the OpenAI request shape to `{api_base}/embeddings`, which SiliconFlow serves on the same API root. See Embeddings.
`/v1/audio/transcriptions`	Supported when the alias names a SiliconFlow transcription model, such as `FunAudioLLM/SenseVoiceSmall` or `TeleAI/TeleSpeechASR`. AISIX rewrites the multipart `model` field to the upstream model ID and forwards the file to `{api_base}/audio/transcriptions`.
`/v1/audio/speech`	Supported when the alias names a SiliconFlow text-to-speech model, such as `FunAudioLLM/CosyVoice2-0.5B`. AISIX rewrites the JSON `model` field and returns the provider's binary audio response. SiliconFlow-specific fields such as `gain`, `sample_rate`, and `references` pass through unchanged.
`/v1/audio/translations`	Fails upstream. SiliconFlow does not publish an audio-translation route on this API base.
`/v1/rerank`	Rejected. The route accepts only the `openai`, `cohere`, and `jina` provider values, so a `siliconflow` alias is refused even though SiliconFlow hosts rerank models. Reach SiliconFlow reranking through a passthrough route instead. See Rerank.
`/v1/images/generations`	Rejected. The route accepts only models whose provider is `openai`.
`/v1/videos`	Rejected with `501 not_implemented`. The route dispatches on its own provider allowlist, which does not include `siliconflow`.
`/passthrough/siliconflow/*`	Available through a configured passthrough route for provider-native routes, with limited gateway normalization. Authorization comes from the caller key's `allowed_routes`, not its model allowlist.

The /passthrough/siliconflow paths on this page assume a passthrough route claiming that prefix with SiliconFlow's API root as its target_url; grant the route name on the caller key's allowed_routes. Passthrough is the practical way to reach SiliconFlow features that have no normalized gateway surface, including native Messages and rerank. Because the route's target_url already ends in /v1, AISIX drops a duplicated leading /v1 from the passthrough path, so both /passthrough/siliconflow/rerank and /passthrough/siliconflow/v1/rerank resolve to the same upstream URL.

Next Steps

You have now connected AISIX to SiliconFlow and verified the model alias. Continue with these guides:

Model Aliases: configure routing, retry behavior, or cost metadata for this alias.
Routing and Failover: fail over between SiliconFlow and a second provider, or rank targets by cost or latency.
Speech and Audio: call a SiliconFlow transcription or text-to-speech alias through the normalized audio routes.
Provider-Specific Overrides: adapt request and response shapes when an upstream API differs from its adapter.
Provider Compatibility: review supported proxy endpoints and provider-specific boundaries.

Prerequisites​

Choose a SiliconFlow Platform​

Configure with AISIX Cloud​

Create a Provider Key​

Create a Model​

Create a Caller API Key​

Configure with the Open-Source AISIX Gateway​

Verify the Provider Connection​

Pass Reasoning Controls Through​

Configure Wire Overrides​

Endpoint Coverage​

Next Steps​