响应缓存

当后续请求具有相同缓存 Key 时，响应缓存允许 AISIX 复用先前的非流式 Chat Completions 响应。这是网关侧响应缓存，不是模型服务提供方的提示词缓存，也不是 AISIX Cloud 的配置快照缓存。如需为 Anthropic 模型配置模型服务提供方侧缓存，请参阅 Anthropic 提示词缓存。若要为相似而非完全相同的提示词返回缓存响应，可在策略上叠加语义缓存。

本指南介绍如何通过 AISIX Cloud 或声明式资源文件配置模型作用域缓存策略、验证缓存未命中和命中、选择共享范围、绕过与清空缓存条目，并按需使用 Redis 在多个网关实例间共享缓存响应。

响应缓存的工作原理

AISIX 会缓存完全匹配的非流式 Chat Completions 响应。流式响应和其他代理 API 类型不会使用此响应缓存路径。

缓存策略可以应用于所有符合条件的请求、一个模型别名或一个调用方 API Key。每个策略把响应存储在网关的进程内 Memory 缓存中；如果启动时配置了 Redis，也可以存储在 Redis 中。

AISIX 缓存响应之前，网关必须能够使用所选后端，并且请求必须匹配一个已启用的缓存策略。

缓存 Key 匹配

AISIX 根据会影响上游响应的规范化 Chat Completions 请求创建缓存 Key。只有模型别名、消息角色和规范化内容、采样设置、响应长度以及额外的兼容 OpenAI 请求选项都相同时，两个请求才会共享缓存条目。

JSON 对象 Key 的顺序不会影响缓存匹配，包括嵌套对象中的 Key。数组顺序会影响匹配，因此工具定义相同但顺序不同的两个请求会使用不同缓存条目。

对于多目标模型，缓存 Key 使用调用方请求的别名，而不是处理未命中请求的目标模型。请求 ID 和请求头不参与缓存 Key。

调用方 API Key 是否分隔缓存由策略的 scope 字段控制。默认的 scope: api_key 下条目仅对写入它的 API Key 可见；scope: env 则在环境内所有调用方之间共享。见选择共享范围。

选择缓存后端

每个缓存策略都要选择匹配响应的存储位置：

后端	行为
Memory	默认。使用处理未命中请求的网关实例上的进程内缓存。
Redis	使用网关启动时配置的共享 Redis 缓存。

单实例部署或可以接受节点本地缓存条目时使用 Memory。多个网关实例需要共享同一策略的缓存响应时使用 Redis。AISIX 支持单个 Redis 端点、Redis Cluster 和 Redis Sentinel。

配置 Memory 缓存策略

以下示例使用默认的进程内 Memory 后端创建模型作用域策略。请选择 AISIX Cloud 或开源配置路径，再使用通用验证步骤。如果已有其他已启用的缓存策略匹配示例请求，请先将其禁用或删除。

准备工作

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

• 以下配置路径之一：
  • AISIX Cloud，其中包含环境、已接入的网关和具有写权限范围的 Admin Token。对于 On-Premises，请按照 AISIX Cloud 快速入门操作。如需申请混合云访问权限，请联系 API7。
  • 加载声明式 resources.yaml 文件的开源 AISIX 网关。
• 可以发送非流式 Chat Completions 请求的模型别名和调用方 API Key。
• curl。AISIX Cloud 路径还会使用 jq。

导出两种路径都会使用的网关连接和资源参数：

# AISIX_PROXY 末尾不包含斜杠或 /v1 等端点路径。
# 本地快速入门使用 http://127.0.0.1:3000。
export AISIX_PROXY="YOUR_AISIX_GATEWAY_URL"
export AISIX_API_KEY="YOUR_CALLER_API_KEY"
export AISIX_MODEL="gpt-4o-mini"
export CACHE_PROMPT="cache-check-$(date +%s)"

AISIX Cloud

导出控制平面连接参数：

# AISIX_CP 包含 /api，末尾不包含斜杠。
# 本地 On-Premises 快速入门使用 http://localhost:8080/api。
export AISIX_CP="YOUR_AISIX_CLOUD_ADMIN_API_BASE_URL"
export AISIX_TOKEN="YOUR_ADMIN_TOKEN"
export ENV_ID="YOUR_ENVIRONMENT_ID"

为示例模型别名创建 Memory 缓存策略。保存策略 ID，因为后面的 Redis 步骤会替换该策略：

CACHE_POLICY_RESPONSE=$(curl -sS -X POST "$AISIX_CP/environments/$ENV_ID/cache_policies" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary @- <<EOF
  {
    "name": "default-chat-cache",
    "enabled": true,
    "backend": "memory",
    "applies_to": "model:${AISIX_MODEL}",
    "ttl_seconds": 3600
  }
EOF
)

export CACHE_POLICY_ID=$(printf '%s' "$CACHE_POLICY_RESPONSE" | jq -r '.cache_policy.id')
printf '%s' "$CACHE_POLICY_RESPONSE" | jq

策略会自动投射到已接入的网关。响应包含策略 ID、环境 ID、所选后端、作用域、TTL 和时间戳。

开源 AISIX 网关

在已定义示例模型和调用方 API Key 的资源文件中添加缓存策略：

resources.yaml

cache_policies:
  - name: default-chat-cache
    enabled: true
    backend: memory
    applies_to: "model:gpt-4o-mini"
    ttl_seconds: 3600

applies_to 中的模型名称必须与模型面向调用方的 display_name 一致。验证完整资源文件，然后重新加载网关。可运行的 Docker 工作流参见重新加载资源文件。

验证缓存未命中和命中

定义一个每次都发送相同请求正文的辅助函数：

send_cache_request() {
  curl -sSi -X POST "$AISIX_PROXY/v1/chat/completions" \
    -H "Authorization: Bearer ${AISIX_API_KEY}" \
    -H "Content-Type: application/json" \
    --data-binary @- <<EOF
    {
      "model": "${AISIX_MODEL}",
      "messages": [{"role": "user", "content": "${CACHE_PROMPT}"}]
    }
EOF
}

发送一次请求：

send_cache_request

第一个匹配请求应包含以下响应头：

x-aisix-cache: miss

未命中表示 AISIX 调用了上游模型服务提供方，并把响应写入缓存。在不更改模型或正文的情况下重复请求：

send_cache_request

重复请求应包含：

x-aisix-cache: hit

命中表示 AISIX 未调用上游模型服务提供方，直接返回了已存储的响应。更改提示词，确认请求正文参与缓存 Key 的计算：

CACHE_PROMPT="${CACHE_PROMPT}-different" send_cache_request

更改后的请求应返回 x-aisix-cache: miss。

使用 Redis 共享缓存条目

Redis 允许多个网关实例共享条目。请确保 Redis 正在运行，且每个参与的网关都能访问它，然后把连接信息添加到 config.yaml：

config.yaml

cache:
  redis:
    mode: single
    url: redis://127.0.0.1:6379/

添加 Redis 配置后，启动或重启每个网关。配置 backend: redis 的策略不会建立 Redis 连接。如果匹配策略选择 Redis，但未配置 cache.redis，AISIX 会禁用这些请求的缓存，而不会静默回退到 Memory。

Redis 可用后，通过前面使用的同一管理路径，用 Redis 策略替换 Memory 策略。

AISIX Cloud

现有 AISIX Cloud 缓存策略的后端不能更改。请删除 Memory 策略，再创建使用 Redis 的替代策略：

curl -sS -X DELETE \
  "$AISIX_CP/environments/$ENV_ID/cache_policies/$CACHE_POLICY_ID" \
  -H "Authorization: Bearer $AISIX_TOKEN" | jq

curl -sS -X POST "$AISIX_CP/environments/$ENV_ID/cache_policies" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary @- <<EOF | jq
  {
    "name": "shared-chat-cache",
    "enabled": true,
    "backend": "redis",
    "applies_to": "model:${AISIX_MODEL}",
    "ttl_seconds": 3600
  }
EOF

开源 AISIX 网关

在 resources.yaml 中更改策略后端：

resources.yaml

cache_policies:
  - name: shared-chat-cache
    enabled: true
    backend: redis
    applies_to: "model:gpt-4o-mini"
    ttl_seconds: 3600

验证完整资源文件，然后重新加载网关，再测试 Redis 策略。

验证 Redis 缓存行为

设置一个新的提示词，然后运行两次 send_cache_request。第一个请求应未命中，第二个请求应命中：

export CACHE_PROMPT="redis-cache-check-$(date +%s)"

send_cache_request
send_cache_request

验证多个网关实例共享缓存

要确认 Redis 已共享，请把第一个请求发送到一个网关实例，再把完全相同的请求发送到另一个实例。两个实例必须加载相同缓存策略，并连接到同一 Redis 部署。

export AISIX_PROXY_A="https://gateway-a.example.com"
export AISIX_PROXY_B="https://gateway-b.example.com"
export CACHE_PROMPT="shared-cache-check-$(date +%s)"

AISIX_PROXY="$AISIX_PROXY_A" send_cache_request
AISIX_PROXY="$AISIX_PROXY_B" send_cache_request

通过网关 A 的请求应未命中，通过网关 B 的请求应命中。使用 Memory 后端时，第二个网关拥有自己的空缓存，因此会再次未命中。

调整策略作用域

验证基本缓存行为后，请为要缓存的流量调整策略作用域。

applies_to 字段控制哪些请求匹配缓存策略：

值	作用域
all	所有符合条件的非流式 Chat Completions 请求。
model:<alias>	使用调用方可见模型别名的请求。
api_key:<id>	使用该调用方 API Key 资源 ID 认证的请求。

对于 AISIX Cloud，请使用 Admin API 返回的调用方 API Key ID。在 resources.yaml 中，请使用该 Key 确定性的派生 ID；资源加载器不会在此字段中解析调用方 API Key 的 display_name。

请先使用模型作用域或调用方 Key 作用域等较窄策略。只有所有符合条件的 Chat Completions 请求都应参与响应缓存时，才使用全局策略。

applies_to 选择器控制的是资格——策略覆盖哪些请求。被覆盖的请求之间是否共享条目，由下一节介绍的独立字段 scope 决定。

应避免为相同请求设置重叠的已启用策略。多个策略匹配时，AISIX 使用第一个匹配策略选择后端和 TTL，因此重叠策略会使缓存行为更难推断。

只使用受支持的匹配形式。网关会把无法识别的前缀视为 all，因此无论通过哪种管理路径创建，拼写错误都可能让策略作用域超出预期。

选择共享范围

策略的 scope 字段选择缓存条目的共享边界：

Scope	行为
api_key	默认值。条目仅对写入它的调用方 API Key 可见。一个调用方的响应绝不会回放给另一个调用方。
env	环境内所有调用方 API Key 共享条目。相同的合格请求跨调用方复用同一条目。

一般流量保持默认的 api_key：响应常常嵌入调用方特有的上下文，按 Key 分隔可防止一个调用方的回答泄露给另一个。FAQ 机器人、文档问答等共享知识型流量——跨调用方复用正是目的、共享池能提升命中率——才选择 env。

scope 对语义层同样生效：在 scope: env 下，调用方可能拿到为另一个调用方的相似（而不仅是相同）请求存储的条目，启用前需要更审慎的评估。

scope 可修改，因此直接切换你已创建的策略，而不是再添加一个重叠策略（把 CACHE_POLICY_ID 设为当前覆盖该模型的策略 ID）：

curl -sS -X PATCH \
  "$AISIX_CP/environments/$ENV_ID/cache_policies/$CACHE_POLICY_ID" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"scope": "env"}' | jq

在 resources.yaml 中，在策略条目上设置同一字段（scope: env）。未设置该字段的既有策略使用 api_key。

按请求绕过缓存

调用方可以用标准的 Cache-Control 请求指令为单个请求跳过缓存，无需改动策略：

指令	行为
Cache-Control: no-cache	跳过缓存查找。全新的上游响应仍会刷新存储的条目。
Cache-Control: no-store	跳过查找，且不把响应写入缓存。

curl -sSi -X POST "$AISIX_PROXY/v1/chat/completions" \
  -H "Authorization: Bearer ${AISIX_API_KEY}" \
  -H "Cache-Control: no-cache" \
  -H "Content-Type: application/json" \
  --data-binary @- <<EOF
  {
    "model": "${AISIX_MODEL}",
    "messages": [{"role": "user", "content": "${CACHE_PROMPT}"}]
  }
EOF

被绕过的请求报告 x-aisix-cache: bypass，而不是 hit 或 miss。用 no-cache 强制刷新过期答案；对响应绝不应被缓存的请求使用 no-store。

清空缓存条目

清空操作会使策略存储的所有条目失效——所有网关实例上，对配置了语义层的策略还包括两个匹配层——而不删除或禁用策略：

curl -sS -X POST \
  "$AISIX_CP/environments/$ENV_ID/cache_policies/$CACHE_POLICY_ID/purge" \
  -H "Authorization: Bearer $AISIX_TOKEN" | jq

响应包含策略递增后的 purge_generation。更新后的配置到达各网关后，更早代次存储的条目立即停止被返回；存储空间在后台回收。AISIX Cloud 控制台在每个策略行上以清空按钮提供同一操作。

在 resources.yaml 中，在策略条目上添加 purge_generation 字段，需要使该策略的条目失效时递增它：

resources.yaml

cache_policies:
  - name: default-chat-cache
    enabled: true
    backend: memory
    applies_to: "model:gpt-4o-mini"
    ttl_seconds: 3600
    purge_generation: 1

当缓存的答案先于 TTL 过时——系统提示词变更、服务提供方侧模型更新、上游文档被修正——时执行清空。

后续步骤

你已经配置响应缓存，并验证了缓存未命中和命中行为。接下来：

• 叠加语义缓存，为相似而非完全相同的提示词也返回缓存响应。
• 如果希望通过重复的提示词前缀获得模型服务提供方侧折扣，而不是复用整个响应，请启用 Anthropic 提示词缓存。
• 继续配置安全护栏，在调用模型服务提供方之前和之后添加请求与响应检查。