DeepInfra

DeepInfra 为多个发布方的开放权重模型提供托管推理服务。应用通过稳定的 AISIX 别名调用这些模型，而不会获得上游 API Token。一个服务提供方密钥既可使用 DeepInfra 的 OpenAI 兼容根地址处理 Chat，也可使用其同级的 Anthropic 兼容根地址处理原生 Messages 和 Count Tokens。

前提条件

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

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

使用 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"

为以 DeepInfra 为后端的 Chat Completions、Messages 和 Count Tokens 创建服务提供方密钥、模型别名和调用方 API Key。

DeepInfra 是一个提供 OpenAI 和 Anthropic 兼容 API 的社区目录服务提供方。AISIX 对主要 API 根地址使用 openai 适配器，并在同一个服务提供方密钥上单独声明原生 Messages 协议面。AISIX 不提供经过维护的基础 URL，也不提供服务提供方特定的请求和响应重写规则。

对于 DeepInfra，AISIX Cloud Admin API 会返回 community_badge: true。控制台将其归入所有服务提供方（社区），并将其传输协议兼容性标记为推定兼容，而非已验证兼容。

创建服务提供方密钥

创建用于存储 DeepInfra 凭证和 API 根路径的服务提供方密钥：

# 替换为你的值
export DEEPINFRA_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": "deepinfra-prod",
    "provider": "deepinfra",
    "api_key": "'"${DEEPINFRA_API_KEY}"'",
    "api_base": "https://api.deepinfra.com/v1",
    "apis": {
      "messages": { "base": "https://api.deepinfra.com/anthropic" }
    },
    "allowed_environments": ["'"${ENV_ID}"'"]
  }' | jq -r '.provider_key.id')

echo "$PROVIDER_KEY_ID"

❶ provider 为 deepinfra。AISIX Cloud Admin API 会根据目录条目推导适配器；adapter 字段仅适用于 BYO 服务提供方密钥，在目录服务提供方密钥中发送该字段会返回 400 错误。对于 deepinfra，推导出的适配器为 openai。

❷ api_key 存储 DeepInfra API Token。DeepInfra 使用 HTTP Bearer 身份认证来验证 OpenAI 兼容接口，这正是 openai 适配器已采用的认证方式。该值遵循服务提供方密钥中的凭证处理方式。

❸ 对 DeepInfra 而言，api_base 是必填项。models.dev 的 deepinfra 条目没有发布 api 字段，因此 AISIX Cloud Admin API 没有可回退使用的缓存默认值。省略 api_base 会返回 400 错误，说明 models.dev 未发布该服务提供方的默认基础 URL。

❹ apis.messages 在同级 Base 上声明 DeepInfra 完整的 Anthropic 兼容协议面。Messages 和 Count Tokens 都使用此 Base 和同一凭证。

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

为什么基础 URL 在 /v1 处结束

DeepInfra 的 OpenAI SDK 示例将 base_url 设置为 https://api.deepinfra.com/v1/openai。DeepInfra 还在 /v1 下直接提供相同 API，包括 /v1/chat/completions、/v1/embeddings、/v1/images/generations 和 /v1/audio/*。

AISIX 会把端点路径追加到 api_base，因此直接使用 https://api.deepinfra.com/v1 根地址更实用。一个服务提供方密钥即可提供 Chat、原生 Messages、Count Tokens、Embedding 和音频别名，透传路由还可访问兼容图片端点和 DeepInfra 原生路由。

还需了解以下两种相关行为：

• 如果粘贴完整的直接端点 URL，AISIX 会先移除 /chat/completions 等已知端点后缀及其末尾斜杠，再构建上游 URL。因此，将 api_base 设置为 https://api.deepinfra.com/v1/chat/completions 仍可正常工作，但建议使用根路径形式以保持值清晰易读。
• AISIX 不会为非 OpenAI 厂商补充缺失的路径段。将 api_base 设置为裸主机 https://api.deepinfra.com 会生成上游 URL https://api.deepinfra.com/chat/completions，而 DeepInfra 并不提供该路径。请使用 DeepInfra 文档中的根路径，不要依赖 AISIX 修复较短的形式。将 api_base 留空也无法解决问题：对于非 OpenAI 服务提供方，网关不会回退到 OpenAI 主机，而是返回上游配置错误，以免将 DeepInfra Token 泄露给其他厂商。

创建模型

DeepInfra 模型 ID 以权重发布方作为命名空间，格式为 <publisher>/<Model-Name>，与相同权重对应的 Hugging Face 仓库 ID 一致。其大小写并不统一，发布方路径段使用的是 Hub 组织名称，而非厂商品牌名称——例如，GLM 模型发布在 zai-org 下，而不是 zhipuai。请从 DeepInfra 模型目录逐字复制 ID，不要手动重新输入。

当前可用的 ID 包括：

模型 ID	说明
deepseek-ai/DeepSeek-V3.2	推理模型；在 reasoning_content 中返回推理内容。
openai/gpt-oss-120b	开放权重模型；reasoning_effort 接受 low、medium 和 high。
meta-llama/Llama-3.3-70B-Instruct-Turbo	非推理指令模型。

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

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": "deepinfra-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 是完整的 DeepInfra 模型 ID，包含发布方路径段。上游会拒绝 DeepSeek-V3.2 这类不带命名空间的标识符。

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

创建调用方 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": "deepinfra-caller",
    "allowed_models": ["'"${MODEL_ID}"'"]
  }' | jq -r '.plaintext')

echo "$AISIX_API_KEY"

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

使用开源 AISIX 网关配置

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

export DEEPINFRA_API_KEY="YOUR_PROVIDER_API_KEY"
export CALLER_API_KEY="YOUR_CALLER_API_KEY"

对于新网关，请使用此完整资源文件。对于现有网关，请将这些条目合并到其当前文件中，并保留其他资源：

resources.yaml

_format_version: "1"

provider_keys:
  - display_name: "deepinfra-prod"
    provider: "deepinfra"
    adapter: "openai"
    api_key: ${DEEPINFRA_API_KEY}
    api_base: "https://api.deepinfra.com/v1"
    apis:
      messages:
        base: "https://api.deepinfra.com/anthropic"

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

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

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

aisix validate --resources resources.yaml

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

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

export AISIX_API_KEY="$CALLER_API_KEY"

验证服务提供方连接

导出 AISIX 网关源站地址：

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

通过 AISIX 代理发送聊天补全请求：

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

网关会返回 OpenAI 兼容响应，并在其中回显面向调用方的别名 deepinfra-deepseek-prod。

使用 Count Tokens 请求验证声明的 Messages Base；该请求不会生成模型响应：

curl -sS -X POST "$AISIX_PROXY/v1/messages/count_tokens" \
  -H "x-api-key: ${AISIX_API_KEY}" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepinfra-deepseek-prod",
    "messages": [
      {
        "role": "user",
        "content": "Count this DeepInfra prompt."
      }
    ]
  }'

成功响应包含 input_tokens。如果 Chat Completions 正常而此请求失败，请检查 apis.messages.base 的值。

如果 Chat Completions 请求失败，请根据症状定位原因：

症状	可能原因
上游身份认证错误	api_key 中的 DeepInfra Token 错误或已撤销。
上游返回 404	api_base 未指向提供 Chat Completions 的 DeepInfra 根地址，或 model_name 省略了发布方前缀。
尚未发送请求便出现上游配置错误	服务提供方密钥上的 api_base 为空。

选择 DeepInfra API 协议面

DeepInfra 在同一主机上提供多种请求协议面：

DeepInfra 协议面	路径	能否通过本指南配置的服务提供方密钥访问
直接兼容 OpenAI 的协议面	/v1/chat/completions、/v1/embeddings、/v1/images/generations 和 /v1/audio/...	可以。规范化 AISIX 路由覆盖 Chat、Embedding 和音频；图片生成需要透传路由。
OpenAI SDK 兼容根地址	/v1/openai/...	本指南的规范化路由不使用。DeepInfra 将其作为 OpenAI SDK 客户端的等价基础地址。
Anthropic Messages 和 Count Tokens	/anthropic/v1/messages 和 /anthropic/v1/messages/count_tokens	可以，通过已声明的 Messages 协议面访问。
原生推理	/v1/inference/{model}	可以，通过透传路由访问。

服务提供方密钥上的 apis.messages 声明会把两条 Messages 路由发送到 DeepInfra，而不会改变该密钥的 openai 适配器。因此，同一凭证和模型别名可同时用于 Chat Completions、原生 Messages 和 Count Tokens。

该声明不会改变 Chat Completions，也不会改变其他使用 api_base 的路由。应用需要 DeepInfra Anthropic 兼容格式时可使用 /v1/messages，其他工作负载仍可使用规范化 OpenAI 兼容路由。

设置生成 Token 上限

这是最可能影响 DeepInfra 别名的一项请求结构差异，也是采用社区目录流程的直接结果。

DeepInfra 在聊天补全文档中使用 max_tokens 表示生成 Token 上限。部分 OpenAI 客户端和集成使用较新的 max_completion_tokens 名称。AISIX 目录中的若干精选服务提供方带有重命名规则，会在请求离开网关前将较新名称转换为旧名称。deepinfra 没有 AISIX 精选适配器映射，因此没有为其注册重命名规则，AISIX 会原样转发调用方所发送的参数名称。

实际结果如下：

• 调用方发送 max_tokens 时，DeepInfra 会收到其文档中定义的参数名称，并应用该上限。
• 调用方发送 max_completion_tokens 时，DeepInfra 会收到其文档未定义的参数名称，因此无法保证上游行为：请求可能失败，或上限可能不生效。

如果客户端发送当前 OpenAI 参数名称，请自行在服务提供方密钥上注册重命名规则：

{
  "request": {
    "param_renames": {
      "max_completion_tokens": "max_tokens"
    }
  }
}

该重命名规则适用于引用此服务提供方密钥的所有模型。如果请求同时携带两个名称，AISIX 会使用原始调用方参数名称对应的值。请参阅服务提供方特定覆盖项。

控制推理输出

DeepInfra 接受聊天补全请求体顶层的标准 OpenAI reasoning_effort 参数，也接受包含 effort 和 enabled 字段的 reasoning 对象。设置 "enabled": false 等同于设置 reasoning_effort: "none"。AISIX 不会移除无法识别的顶层参数，因此这两种形式都会原样传递到上游：

{
  "model": "deepinfra-deepseek-prod",
  "messages": [
    {
      "role": "user",
      "content": "Plan a three-step migration."
    }
  ],
  "reasoning_effort": "low"
}

DeepInfra 为受支持的推理模型记录了 none、low、medium 和 high。模型可用性和行为仍可能不同，因此请在 DeepInfra 推理文档及模型目录页面中确认所用模型的控制项。对非推理模型使用这些参数不会产生任何效果。

在响应侧，DeepInfra 通过 reasoning_content 返回模型的思考内容；这已经是 AISIX 保留并标准化到的规范字段。上述模型无需配置响应覆盖项。

由于 deepinfra 未注册响应重写规则，此行为取决于所配置模型的特性，并非 AISIX 强制保证。如果新增的模型在其他 delta 路径中流式返回推理内容，请在服务提供方密钥上设置 response.reasoning_field，使流式客户端仍可在 delta.reasoning_content 中找到它。请使用流式请求进行验证，而不是非流式请求，因为该覆盖项应用于流式 delta 路径。

端点覆盖范围

DeepInfra 提供多种推理模态，但规范化 AISIX 路由支持同时取决于上游基础 URL 和模型的 deepinfra 服务提供方值。

路由	使用 DeepInfra 别名时的行为
/v1/chat/completions	支持，包括 stream: true。
/v1/responses	通过 Chat 适配器路径上的 Responses 桥接支持。没有 Chat 等价项的 OpenAI 特定 Responses 字段会被忽略。
/v1/messages 和 /v1/messages/count_tokens	由于本指南声明了 apis.messages，请求会发送到 DeepInfra 原生 Anthropic 兼容路由。如果没有此声明，Messages 会转换为 Chat Completions，而 Count Tokens 不可用。
/v1/embeddings	支持。DeepInfra 在同一个 OpenAI 兼容根路径上提供 Embedding 模型，因此一个服务提供方密钥可同时覆盖聊天和 Embedding 别名。请创建单独的模型别名，并将其 model_name 设置为 Embedding 模型 ID。请参阅 Embedding。
/v1/audio/transcriptions、/v1/audio/translations 和 /v1/audio/speech	本指南配置的服务提供方密钥在别名指向兼容 DeepInfra 音频模型时支持。请参阅 DeepInfra 音频 API 参考和语音与音频。
/v1/images/generations	拒绝。该路由仅接受服务提供方为 openai 的模型。可通过注入本指南所建服务提供方密钥的透传路由，在 /passthrough/deepinfra/images/generations 访问 DeepInfra 兼容图片端点。
/v1/rerank	拒绝。该路由仅接受 openai、cohere 和 jina 服务提供方值。
/v1/videos	拒绝。该路由仅接受其自身服务提供方允许列表中的值，其中不包含 deepinfra。
/passthrough/deepinfra/*	通过已配置的透传路由可用，路径拼接规则如下所述。

DeepInfra 模型 ID 即使以 openai/ 开头（例如 openai/gpt-oss-120b），也不会使该别名成为 OpenAI 服务提供方模型。其服务提供方值仍为 deepinfra，因此基于服务提供方身份而非适配器进行限制的路由——图片生成、视频生成和 rerank——会拒绝该别名。完整路由矩阵请参阅服务提供方兼容性。

本页的 /passthrough/deepinfra 路径假定一条透传路由认领该前缀，target_url 设为 https://api.deepinfra.com/v1 并挂上 DeepInfra 服务提供方密钥；在调用方 Key 的 allowed_routes 上授予该路由。

在前缀匹配的透传路由上，AISIX 会将通配符剩余部分追加到路由的 target_url。如果目标和通配符路径包含相同 API 版本路径段，AISIX 会移除重复项：

• /passthrough/deepinfra/models 会解析为 https://api.deepinfra.com/v1/models。
• /passthrough/deepinfra/images/generations 会解析为 DeepInfra 兼容 OpenAI 的图片端点。请求体包含 model 时，必须使用 DeepInfra 模型 ID，而非 AISIX 别名。
• /passthrough/deepinfra/v1/inference/deepseek-ai/DeepSeek-V3.2 会解析为 DeepInfra 原生推理端点。由于路由的 target_url 已以 /v1 结尾，AISIX 会移除重复的 v1 路径段。

透传路由会转发服务提供方原生请求和响应体，而不会重写 AISIX 别名。AISIX 会从每个请求中检测兼容 OpenAI 的 Chat、Completions 和 Responses 信封，并记录受支持的用量字段。没有可识别载体字段的请求保持不透明：缓冲响应记录零 Token，而不透明 SSE 仍可记录顶层受支持的 usage 字段。Anthropic 兼容协议面使用服务提供方密钥上单独声明的 apis.messages.base；指向 /v1 的透传路由无法跳转到同级 /anthropic 根地址。请参阅透传路由。

后续步骤

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

• 服务提供方特定覆盖项：注册该社区目录服务提供方默认不包含的参数重命名规则和响应映射。
• 模型别名：为该别名配置路由、重试行为或成本元数据。
• 路由和故障转移：在 DeepInfra 与提供同一开放权重模型的另一服务提供方之间进行故障转移。
• 服务提供方兼容性：查看支持的代理端点及服务提供方特定的限制。