Requesty 教程：具备自动故障切换的统一 LLM 网关

您的 AI 应用在使用 OpenAI 时运行良好，直到当月账单攀升至 $2,000。您又接入了 Anthropic 以提升推理能力、接入 Google 以节省成本，如今要同时处理三个不同的 API，各自独立计费与监控。一旦 OpenAI 宕机，您的应用就会出错；一旦触发速率限制，用户就会看到错误。您需要一种更可靠的方法。

Requesty 通过提供一个带有自动故障切换与成本优化工具的统一网关来解决这一问题。您只需在控制台中配置一次故障切换链与缓存偏好，随后每个 API 请求都会自动遵循这些策略。

当某个服务商出现故障时，Requesty 会切换至您的备用模型。对于 Anthropic 等支持缓存的服务商，启用缓存还能降低重复查询的成本。

在本教程中，我将介绍 Requesty 的核心功能。我们先从通过统一网关进行基础 API 调用与响应流式传输开始。随后我们将配置自动故障切换以保障可用性，启用服务商缓存以在查询重复时降低成本，并使用分析控制台监控支出并优化用量。无论您是在构建第一个 AI 原型，还是在大规模部署生产系统，这些功能的使用方式都相同。

Requesty 是什么？

Requesty 是一个统一的 LLM 网关，通过单一 API 将您与来自 OpenAI、Anthropic、Google、Meta 和 AWS 等服务商的 300 多个模型相连。它是托管服务，您无需自行部署任何基础设施。

概览与主要功能

Requesty 通过控制台而非代码或配置文件来设置路由策略。您可以通过网页界面配置故障切换链、负载均衡权重与缓存偏好，这些策略会自动应用到所有 API 请求。

基于控制台的配置可实现：

• 服务商原生缓存：在 Anthropic、Gemini 等支持的服务商上启用缓存，复用提示词的重复部分，降低重复请求的成本。
• 快速自动故障切换：当服务商出现问题时平台会自动切换到备用模型，并提供 99.99% 的 SLA 保证。
• 实时分析：通过统一控制台跟踪所有请求的 tokens、成本、延迟分位数、缓存命中率与故障切换频率。

这些能力与灵活的路由策略（回退链、负载均衡、延迟优化）、内置的 PII 与提示注入安全防护、以及详细的成本追踪相结合。

OpenRouter 也提供对多款 LLM 的统一访问，但仅具备基础路由且没有分析控制台。LiteLLM 提供相近功能，但需要自托管并手动用 YAML 配置路由策略。Requesty 作为托管服务，采用控制台驱动配置，介于两者之间。

我何时应使用 Requesty？

如果您运行的是对可用性有严格要求的企业系统，99.99% 的 SLA 至关重要。应用宕机就意味着损失。内置的 PII 涂抹与提示注入检测等安全功能，能满足合规需求而无需您自建这些系统。在 GDPR 规则下运营的团队可以启用欧盟托管，以确保数据留存在正确的司法辖区。

构建生产级 AI 应用的开发团队可以通过配置切换服务商，避免供应商锁定，而无需重写代码。自动故障切换意味着您无需自建可靠性基础设施。

预算敏感型项目可从服务商缓存与策略性负载均衡中受益。与其自行编写优化逻辑，不如一次性配置策略，交由 Requesty 自动实现成本降低。

先决条件

设置您的开发环境。约需 5 分钟，涵盖 Python 包、API 密钥与基础配置。

您的系统需安装 Python 3.7 或更新版本。验证您的版本：

import sys
print(f"Python {sys.version_info.major}.{sys.version_info.minor}")技术支持

使用 pip 或 uv 安装所需包：

pip install openai python-dotenv
# or with uv: uv add openai python-dotenv技术支持

您需要 openai 包来与 Requesty 的 API 交互。python-dotenv 包用于安全管理环境变量。

在 app.requesty.ai 创建一个 Requesty 帐号。登录后前往 API Keys 区域生成新密钥。复制该密钥用于鉴权。别忘了同时为您的帐户充值一些金额。

将您的 API 密钥存放在项目目录下的 .env 文件中：

REQUESTY_API_KEY=your_api_key_here技术支持

这样可避免在代码中明文保存凭据，便于在不暴露密钥的情况下共享项目。

通过加载环境变量并检查 API 密钥是否可用来验证一切是否正常：

import os
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
api_key = os.getenv("REQUESTY_API_KEY")

# Check your setup
if api_key:
   print("✓ API key loaded")
   client = OpenAI(
       api_key=api_key,
       base_url="https://router.requesty.ai/v1"
   )
   print("✓ Client configured")
else:
   print("✗ API key not found")技术支持

若您看到两个对勾，说明已准备好发出首个请求。

开始使用 Requesty：发出您的第一个 API 调用

当环境配置完成且 API 密钥就绪后，您可以进行第一次 API 调用。Requesty 可作为 OpenAI SDK 的即插即用替代。如果您用过 OpenAI，这将非常熟悉。唯一不同之处在于将客户端指向 Requesty 的路由器。

如下设置您的客户端：

import os
from openai import OpenAI
from dotenv import load_dotenv

load_dotenv()

client = OpenAI(
   api_key=os.getenv("REQUESTY_API_KEY"),
   base_url="https://router.requesty.ai/v1"
)技术支持

其中 base_url 参数会将请求路由至 Requesty 而非直接发往 OpenAI。您可以用一次对 GPT-5 的调用来测试：

response = client.chat.completions.create(
   model="openai/gpt-5",
   messages=[
       {"role": "user", "content": "Explain recursion in one sentence"}
   ]
)

print(response.choices[0].message.content)技术支持

输出：

Recursion is a technique where a function solves a problem by calling itself on smaller inputs until it reaches a base case.技术支持

model 参数采用 provider/model-name 格式。这里是 openai/gpt-5，可访问 OpenAI 最新模型，具备 原生推理能力与在编码和数学任务上的性能提升。除模型名格式与基础 URL 外，SDK 的用法与 OpenAI 完全一致。

注意：每次 API 调用都需要付费。Requesty 在服务商基础定价上加收 5% 的加价，因此通过 Requesty 调用 GPT-5 会比直接调用 OpenAI 略贵。您为更高的可靠性、故障切换能力与统一控制台付费。请通过 Requesty 控制台监控用量与支出。

响应对象除了消息内容外，还包含许多有用的元数据：

print(f"Model used: {response.model}")
print(f"Total tokens: {response.usage.total_tokens}")
print(f"Response: {response.choices[0].message.content}")技术支持

输出：

Model used: gpt-5-2025-08-07
Total tokens: 108
Response: Recursion is a technique where a function solves a problem by calling itself on smaller inputs until it reaches a base case.技术支持

token 计数有助于您跟踪成本，因为定价通常按 token 计费。

通过更改模型名称即可切换到不同服务商：

response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "user", "content": "Explain recursion in one sentence"}
   ]
)

print(f"Claude says: {response.choices[0].message.content}")技术支持

输出：

Claude says: Recursion is a programming technique where a function calls itself to solve a problem by breaking it down into smaller, similar subproblems until it reaches a base case that stops the repetition.技术支持

Claude 4 提供更长的上下文窗口与更强的推理能力，特别适合复杂代码分析。所有可用模型均遵循 provider/model-name 的模式：

# OpenAI GPT-4o
model = "openai/gpt-4o"

# Anthropic Claude
model = "anthropic/claude-sonnet-4"
Wrap your API calls in error handling before moving to production:
try:
   response = client.chat.completions.create(
       model="openai/gpt-5",
       messages=[{"role": "user", "content": "Hello!"}]
   )
   print(response.choices[0].message.content)
except Exception as e:
   print(f"Error: {e}")技术支持

这能在不使应用崩溃的情况下捕获网络超时、无效 API 密钥或模型不可用等问题。

Requesty 中的实时流式传输

当您请求较长的回答时，屏幕可能会在模型生成上千个 token 的几秒钟里“卡住”。随后内容一次性输出。

用户会盯着空白屏幕，不确定是否在进行处理。

流式传输通过在模型生成的同时分片发送响应来解决这一问题，用户会逐字看到内容呈现，就像 ChatGPT 一样。对于解释、代码生成或创意写作等较长回应，这能显著提升响应体验。

要在 Requesty 中启用流式传输，请将 stream 参数设为 True：

response = client.chat.completions.create(
   model="openai/gpt-4o",
   messages=[
       {"role": "user", "content": "Explain recursion like I'm five years old"}
   ],
   stream=True
)

for chunk in response:
   if chunk.choices[0].delta.content is not None:
       print(chunk.choices[0].delta.content, end="", flush=True)技术支持

响应会逐字流式输出：

Okay! Imagine you have a big basket of toys, and you're trying to find your favorite teddy bear. 
But instead of looking through the whole basket all at once, you call your little sibling and say, 
"Can you look in here and find my teddy bear? If you see more baskets inside, ask someone else to help in the same way!" …技术支持

stream=True 会将响应从单个对象变为按块产出的迭代器。每个块都在 delta.content 中包含一段文本。end="" 可避免块间换行，flush=True 则强制立即显示而非缓冲。

生产应用通常既需要流式体验，也需要完整文本用于日志或分析。可以用一个辅助函数同时处理两者：

def stream_and_capture(model, messages):
   """Stream response to user while capturing complete text."""
   response = client.chat.completions.create(
       model=model,
       messages=messages,
       stream=True
   )
  
   complete_text = ""
  
   for chunk in response:
       if chunk.choices[0].delta.content is not None:
           text = chunk.choices[0].delta.content
           complete_text += text
           print(text, end="", flush=True)
  
   print()  # Final newline
   return complete_text

# Use it
full_response = stream_and_capture(
   "anthropic/claude-sonnet-4",
   [{"role": "user", "content": "Write a haiku about debugging code at 3 AM"}]
)

print(f"\nCaptured {len(full_response)} characters")技术支持

输出：

Blinking cursor waits
Coffee cold, eyes burning red,
One missing bracket.

Captured 74 characters技术支持

流式并非总是最佳选择。对于短回答或如 JSON 之类的结构化输出，常规请求更简单更快，因为处理分片的额外开销可能超过用户体验收益。

流式可能会在中途因网络问题、速率限制或服务商故障而失败。请为您的流式代码加入基础错误处理：

try:
   response = client.chat.completions.create(
       model="openai/gpt-4o",
       messages=[{"role": "user", "content": "Explain quantum entanglement in one sentence"}],
       stream=True
   )
  
   for chunk in response:
       if chunk.choices[0].delta.content is not None:
           print(chunk.choices[0].delta.content, end="", flush=True)
except Exception as e:
   print(f"\nError: {e}")技术支持

如果流式失败，您可以捕获错误并手动重试，或回退到不同的模型。

面向可靠性的自动故障切换

生产应用无法承受停机。当 OpenAI 在高峰期触发速率限制时，您的用户会看到错误；当 Anthropic 宕机时，您的聊天机器人会停止工作。依赖外部服务商时，这些失败是不可避免的。

Requesty 通过自动故障切换来处理这一问题。当主用模型失败时，Requesty 会在 50 毫秒内切换到您的备用模型。

什么是故障切换，以及它为何重要

故障切换系统会在检测到主用模型不可用时，将请求重定向到备用模型，而无需更改任何代码。当服务商返回错误、触发速率限制或超时时，会自动完成检测。随后，Requesty 会将您的请求路由至您配置链中的下一个模型。

Requesty 通过该系统保证 99.99% 的正常运行时间。也就是说每月最多约 4 分钟的停机时间，而相较之下，如果只用单一服务商且无备份，停机可能长达数小时。

三种策略类型可控制故障切换的工作方式：

• 回退链（Fallback Chain）：按顺序尝试模型。若第一个失败则尝试第二个，依此类推。适用于您有首选模型但希望有备选方案的情形。
• 负载均衡（Load Balancing）：按比例在多个模型间分流。例如将 70% 流量发往 GPT-5、30% 发往 Claude Sonnet 4，以减少单一服务商的负载。当某个模型不可用时，Requesty 会自动将全部流量路由至仍在工作的模型。
• 延迟（Latency）：将请求路由到响应最快的模型。Requesty 会测量响应时间并将流量发送至延迟最低的选项，从而优先速度而非成本。

多数团队从回退链开始，因为其可预测：在首选模型可用时使用它，不可用时自动启用备份。

配置回退链

在 Requesty 控制台中设置故障切换。进入 API Keys 区域，点击 Policies。创建一个新的 Fallback Chain 策略。您会看到一个表单，可按偏好顺序添加模型。

以下示例链在质量、成本与可用性之间取得平衡：

1. openai/gpt-5

2. anthropic/claude-sonnet-4

3. deepseek/deepseek-r1:free

该链首先尝试 GPT-5，因为其快速且能力强；若失败则尝试 Claude Sonnet 4，质量相近；若两款付费高端模型均不可用，则回退到几乎总是可用且免费的 DeepSeek R1。

在保存该策略并将其绑定到您的 API 密钥后，无需修改代码即可进行故障切换：

response = client.chat.completions.create(
   model="openai/gpt-5",
   messages=[{"role": "user", "content": "Explain how DNS works"}]
)

print(f"Model used: {response.model}")
print(response.choices[0].message.content)技术支持

response.model 字段会显示实际处理您请求的模型。控制台会跟踪故障切换频率，便于查看何时启用了备用模型。

输出：

Model used: gpt-5-2025-08-07
DNS (Domain Name System) translates human-readable website addresses like "google.com" into IP addresses (like 142.250.80.46) that computers use to locate and connect to servers. This translation happens through a hierarchical system of DNS servers that cache and distribute this information globally for fast lookups.技术支持

如果链中的所有模型都失败，Requesty 会在逐个尝试后返回错误。您将收到标准的 API 错误响应，提示无可用模型。这种情况较少见，但在大范围故障时可能发生。

构建回退链时，有些指南行之有效：

• 使用不同服务商：若在链中同时放入 openai/gpt-5 与 openai/gpt-4o，一旦 OpenAI 故障，两者都可能不可用。混合不同服务商更可靠。
• 先按质量排序，再考虑成本：将最佳模型置于首位；若不可用，再尝试次优选项；最后的回退应是最可靠的选择，即便质量较低或免费。
• 至少包含三个模型：只有一个备份意味着仍有两个故障点；三个或更多模型能提供更好的覆盖。
• 测试您的链：发起一些请求并在分析控制台查看由哪些模型处理流量，以确认策略生效。

相比 LiteLLM 需要手动 YAML 配置故障切换，Requesty 通过控制台策略全程代管。

通过缓存降低成本

反复运行相同查询会产生成本。如果您有一个文档聊天机器人反复回答相同问题，或一个在每次请求中都使用相同系统提示的编码助手，您每次都在为全量内容付费。缓存通过复用不变的提示词部分来解决此问题。

部分服务商原生支持提示词缓存。Anthropic 与 Gemini 允许您缓存提示中不变的部分并跨请求复用。当存在重复模式时，这能降低成本，因为您只需为新增部分支付全价。

当您发送包含长系统提示的请求时，服务商会将该提示存入缓存。下一次使用相同系统提示的请求将直接从缓存中取回，而无需再次处理。您只需支付更低的缓存读取费用，而非全量处理成本。

在 extra_body 字段中传入 auto_cache，嵌套于 requesty 对象内：

response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "system", "content": "You are a helpful documentation assistant. You answer questions about Python's asyncio library based on the official docs. Be concise and include code examples."},
       {"role": "user", "content": "How do I create a basic event loop?"}
   ],
   extra_body={
       "requesty": {
           "auto_cache": True
       }
   }
)

print(response.choices[0].message.content)技术支持

系统提示在请求间保持不变。设置 auto_cache: True 后，Anthropic 会在首次请求后将其缓存。后续请求将复用缓存提示，只处理用户问题。

缓存参数支持三种取值：

• True：为该请求启用缓存
• False：即使服务商支持也显式绕过缓存（适用于敏感数据或对时效性要求高的内容，确保每次都进行全新处理）
• 省略：采用默认行为（除非全局配置，否则不启用缓存）

目前仅 Anthropic 与 Gemini 支持提示词缓存。对其他服务商使用 auto_cache 会静默回退为常规处理，不会报错。

何时使用缓存

当您拥有在请求间保持不变的长系统提示时，缓存最为有效。文档机器人与编码助手是典型示例。FAQ 机器人与客服系统在用户提问相似时也会受益。对于不常变动的庞大参考文档型知识库，同样是强力用例。

当每次请求都需要最新数据时，请跳过缓存。天气与股价类应用属于此类。针对每位用户定制、提示词各不相同的个性化推荐也不会受益。实时监控与直播类内容变化频繁，同样难以利用缓存。

下例展示了一个针对 Python 库的文档聊天机器人。系统提示包含完整 API 参考。用户的问题各不相同，但系统提示保持一致：

# Simulate a long API documentation string
long_api_documentation = """
Python AsyncIO Library Reference:
- asyncio.run(): Execute async functions
- asyncio.create_task(): Schedule coroutines
- asyncio.gather(): Run multiple tasks
... (this continues for 5,000+ tokens)
"""

# First request - cache miss, pays full price
response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "system", "content": long_api_documentation},
       {"role": "user", "content": "How do I authenticate?"}
   ],
   extra_body={"requesty": {"auto_cache": True}}
)

print(f"Tokens: {response.usage.total_tokens}")
# Output: Tokens: 5,247 (full processing)技术支持

第二次使用相同系统提示的请求会命中缓存：

# Second request - cache hit, reduced cost
response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "system", "content": long_api_documentation},
       {"role": "user", "content": "What are rate limits?"}
   ],
   extra_body={"requesty": {"auto_cache": True}}
)

print(f"Tokens: {response.usage.total_tokens}")
# Output: Tokens: 312 (only new content processed, 5,000 tokens served from cache)技术支持

缓存读取费用可让缓存部分的开销降低 50% 至 90%。

在 Requesty 控制台的 Analytics 区域查看缓存命中率。若低于 40%，说明您的提示变动过于频繁，难以收益于缓存。

尝试寻找可以标准化系统提示或将可变内容提取到用户消息中的模式。控制台还会按服务商与模型展示因缓存带来的总体节省，帮助您直观看到优化效果。

Requesty 的成本追踪与分析

此时您的控制台几乎是空的。您或许只做了几次测试，请了大约 $0.10，暂时没什么可分析的。本节将说明现在该做什么设置，以及当您进入生产后哪些功能会变得有用。

即便在测试阶段，也建议设置支出上限。前往控制台的 API Keys 区域，点击您的密钥，找到“API Limits”。设置每月 $5 的预算阈值。Requesty 会在达到该上限的 50%、75% 与 90% 时发出提醒。若需更严格的保护，可设置用量上限，一旦触及就停止所有请求。这能在测试期间避免意外，在生产环境中保护您。

随着用量增长，Requesty 会追踪五项关键指标：

• Token 用量：每个请求消耗的 token 数
• 成本追踪：按模型与服务商精确计费
• 延迟指标：P50、P95、P99 响应时间
• 缓存表现：命中率与节省效果
• 故障切换频率：使用备用模型的频次

在经历数周生产流量后，这些指标将揭示可供优化的模式。使用控制台找出昂贵的工作流并切换到更便宜的模型，发现重复查询并用 auto_cache: true 启用缓存，并监控故障切换模式以调整回退链。某文档聊天机器人在控制台显示 70% 查询相同后启用了缓存，将月成本从 $500 降至 $200。

当您从原型走向生产，监控、扩展与运维最佳实践至关重要。 LLMOps 涵盖完整生命周期 的生产化管理实践，其中的成本优化策略可与 Requesty 内置分析相辅相成。

结语

您已了解 Requesty 如何作为统一网关，通过单一 API 连接 300+ 款 AI 模型。设置十分简单：安装 OpenAI SDK，将其指向 Requesty 的基础 URL，即可联通。从此，流式传输带来渐进式响应；故障切换链在服务商故障时也能保障可用性；当提示重复时，缓存可将成本减半。

在 Requesty、LiteLLM 与 OpenRouter 之间的选择取决于您的侧重。如果您需要带有自动故障切换与内置分析的托管基础设施，Requesty 能为您处理复杂性。若团队擅长自托管并希望更细粒度的控制，可以选择 LiteLLM 的开源方案。 OpenRouter 提供基础的统一访问，适合您愿意手动选择模型且无需高级路由策略的场景。

首先配置一个由不同服务商的三个模型组成的回退链，然后为包含重复系统提示的请求启用缓存。若需更复杂的用例，可探索 Claude Sonnet 4 的推理能力，或在生产部署中应用 LLMOps 实践。