Skip to main content
API7.ai Logo

SiliconFlow

Connect AISIX AI Gateway to SiliconFlow so applications can call SiliconFlow-hosted models through the gateway's OpenAI-compatible API. AISIX keeps the SiliconFlow credential on the gateway side. It authorizes model access with caller API keys and allowlists, and applies the same rate-limit and usage-accounting controls as other model aliases.

SiliconFlow aggregates models from many model organizations behind one OpenAI-compatible API, so it uses the openai adapter with a SiliconFlow api_base. SiliconFlow reaches AISIX through the community catalog path: siliconflow is a models.dev catalog provider ID that AISIX accepts, and the catalog's default rule assigns the openai adapter with HTTP bearer authentication. AISIX registers no SiliconFlow-specific request or response rewrites, so the operator supplies any compatibility adjustment explicitly. The dashboard labels providers on this path as community entries with an unverified wire format.

Prerequisites​

The following examples configure the upstream through the AISIX Cloud Admin API. Before configuring the upstream, prepare the following:

  • Access to AISIX Cloud with an environment, an attached gateway, and a write-scoped admin token. For On-Premises, follow the AISIX Cloud Quickstart. To request Hybrid Cloud access, contact API7.
  • A SiliconFlow API key from the SiliconFlow console.

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

Catalog provider IDAPI rootUse when
siliconflowhttps://api.siliconflow.com/v1The API key was issued on the siliconflow.com platform.
siliconflow-cnhttps://api.siliconflow.cn/v1The 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.

Export the connection details used by every request below:

# Replace with your values
export AISIX_CP="http://localhost:8080/api"
export AISIX_TOKEN="aisix_pat_YOUR_ADMIN_TOKEN"
export ENV_ID="YOUR_ENVIRONMENT_ID"

Configure the SiliconFlow Upstream​

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

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 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 Credentials.

❸ 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 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.

note

Not every community catalog provider has a published API field. When models.dev publishes none, the Cloud Admin API rejects the create request with a 400 error and api_base becomes required. SiliconFlow is not in that group, but a provider key created for another community provider may be.

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 models, so add a pricing override for an embedding alias. 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.

Verify the Provider Connection​

Send a chat-completions request through the AISIX proxy:

curl -sS -X POST "http://127.0.0.1:3000/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:

ParameterTypeEffect
enable_thinkingbooleanSwitches a hybrid-reasoning model between thinking and non-thinking mode.
thinking_budgetintegerCaps 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 at Creation​

Because SiliconFlow has no curated catalog entry, AISIX registers no request or response rewrites for it. The gateway sends what the caller sent and returns what the upstream returned. That is the right default for an OpenAI-compatible upstream, and it is also the boundary of the operator's responsibility: when SiliconFlow renames a parameter, or when one hosted model diverges from the OpenAI shape, you configure the adjustment on the provider key.

Two overrides cover the common cases. Both must be included when the provider key is created and are inherited by every model that references it. The provider-key update endpoint does not accept request or response.

If an existing model needs overrides, create a replacement provider key with the complete configuration:

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

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.

The model update switches MODEL_ID to the replacement key. Verify the alias through AISIX before deleting the old provider key. Because overrides apply to every alias on a key, test them against a non-production alias first. See Provider-Specific Overrides for the full field catalog.

Endpoint Coverage​

SiliconFlow is an inference-only upstream, and the siliconflow provider value is outside the allowlists that several proxy routes enforce. The table below records what a SiliconFlow-backed alias can and cannot serve.

RouteBehavior with a SiliconFlow alias
/v1/chat/completionsSupported, including stream: true.
/v1/responsesSupported through the Responses bridge over the chat adapter path.
/v1/messagesSupported for Anthropic-shaped callers through translation. Token counting at /v1/messages/count_tokens requires an Anthropic-backed model.
/v1/embeddingsSupported 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/rerankRejected. 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 passthrough instead. See Rerank.
/v1/images/generationsRejected. The route accepts only models whose provider is openai.
/v1/videosRejected with 501 not_implemented. The route dispatches on its own provider allowlist, which does not include siliconflow.
/passthrough/siliconflow/*Supported for provider-native routes, with limited gateway normalization. The tunnel borrows the credential and api_base from the first SiliconFlow alias the caller key is allowed to use, so the caller key still needs a SiliconFlow model in allowed_models. See Provider Passthrough.

Passthrough is the practical route for SiliconFlow features that have no normalized gateway surface, including rerank. Because the provider key's api_base 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: