简介
大语言模型 (LLM)（如 OpenAI 的 GPT-4 和 DeepSeek 的模型）正越来越多地应用于从 AI 助手到代码生成平台的各种应用中。然而，LLM API 也带来了独特的挑战：它们受限于速率、计算密集型，并且有时不够稳定。API 网关可以帮助软件团队在生产系统中管理、保护和优化 LLM 请求。
本文阐述了 API 网关如何代理 LLM 请求，包括架构设计、插件集成、流量控制机制以及真实用例。我们还将探讨如何配置 Apache APISIX 以高效处理 LLM 工作负载。
代理 LLM API 的核心概念与挑战
LLM 特有的 API 特性
- 高延迟：LLM 响应可能需要几秒钟才能返回。
- 基于 Token 的计费：大多数 LLM 提供商根据 Token 使用量收费。
- 速率限制：严格的每分钟或每秒速率限制。
- 重试策略：由于过度使用偶尔会出现的瞬时错误。
- 流式响应：SSE (Server-Sent Events) 或分块响应。
代理 LLM 请求的挑战
- 管理带有指数退避的重试机制。
- 强制执行请求/响应超时阈值。
- 处理 SSE 并保持响应的流式传输。
- 区分不同的上游 API（如 OpenAI 与 DeepSeek）。
架构概览：API 网关作为 LLM 代理
API 网关在 LLM 场景中的关键职责
- 根据模型或提供商进行流量路由。
- 认证管理（例如 OpenAI、DeepSeek 的 API 密钥）。
- 针对每个客户端或租户的限流。
- 缓存非动态提示词（缓存）。
- 可观测性：日志、链路追踪、指标监控。
- 故障转移与降级机制。
API 网关的请求生命周期
1sequenceDiagram
2 participant Client
3 participant API Gateway
4 participant OpenAI
5 Client->>API Gateway: POST /v1/chat/completions
6 API Gateway->>API Gateway: Validate key, apply rate limiting
7 API Gateway->>OpenAI: Forward request with upstream credentials
8 OpenAI-->>API Gateway: LLM response (possibly streaming)
9 API Gateway-->>Client: Stream response使用 Apache APISIX 代理 LLM 请求
Apache APISIX 提供了丰富的插件能力，非常适合处理 LLM 工作负载。
核心插件
ai-proxy：
ai-proxy插件通过将插件配置转换为指定的请求格式，简化了对 LLM 和嵌入模型的访问。它支持与 OpenAI、DeepSeek 以及其他兼容 OpenAI 格式的 API 进行集成。ai-rate-limiting：
ai-rate-limiting插件对发送至 LLM 服务的请求实施基于 Token 的速率限制。它通过控制特定时间范围内消耗的 Token 数量来帮助管理 API 使用量，确保资源公平分配并防止服务负载过高。它通常与 ai-proxy-multi 插件配合使用。ai-request-rewrite：
ai-request-rewrite插件在将客户端请求转发给上游服务之前，先将其发送到 LLM 服务进行转换处理。这实现了基于 LLM 的请求修改，例如数据脱敏、内容丰富或格式重组。该插件支持与 OpenAI、DeepSeek 以及其他兼容 OpenAI 格式的 API 集成。ai-aws-content-moderation：
ai-aws-content-moderation插件支持在代理 LLM 请求时集成 AWS Comprehend 以检查请求体中的违规内容，例如脏话、仇恨言论、侮辱、骚扰、暴力等，如果评估结果超过配置的阈值，则拒绝该请求。
示例：代理至 OpenAI
1curl "http://127.0.0.1:9180/apisix/admin/routes" -X PUT \
2 -H "X-API-KEY: ${ADMIN_API_KEY}" \
3 -d '{
4 "id": "ai-proxy-route",
5 "uri": "/anything",
6 "methods": ["POST"],
7 "plugins": {
8 "ai-proxy": {
9 "provider": "openai",
10 "auth": {
11 "header": {
12 "Authorization": "Bearer '"$OPENAI_API_KEY"'"
13 }
14 },
15 "options":{
16 "model": "gpt-4"
17 }
18 }
19 }
20 }'OpenAI 与 DeepSeek 之间的故障转移
1sequenceDiagram
2 participant Client
3 participant API Gateway
4 participant OpenAI
5 participant DeepSeek
6 Client->>API Gateway: POST /v1/chat/completions
7 API Gateway->>OpenAI: Primary upstream call
8 OpenAI-->>API Gateway: Error (e.g. 429)
9 API Gateway->>DeepSeek: Retry as fallback
10 DeepSeek-->>API Gateway: Success
11 API Gateway-->>Client: Return DeepSeek response在 LLM 实例之间实现负载均衡
以下示例演示了如何配置两个模型进行负载均衡，将 80% 的流量转发到一个实例，将 20% 转发到另一个实例。
为了便于演示和区分，我们将配置一个 OpenAI 实例和一个 DeepSeek 实例作为上游 LLM 服务。
创建一个如下所示的路由，并在适用时使用你的 LLM 提供商、模型、API 密钥和端点进行更新：
1curl "http://127.0.0.1:9180/apisix/admin/routes" -X PUT \
2 -H "X-API-KEY: ${ADMIN_API_KEY}" \
3 -d '{
4 "id": "ai-proxy-multi-route",
5 "uri": "/anything",
6 "methods": ["POST"],
7 "plugins": {
8 "ai-proxy-multi": {
9 "instances": [
10 {
11 "name": "openai-instance",
12 "provider": "openai",
13 "weight": 8,
14 "auth": {
15 "header": {
16 "Authorization": "Bearer '"$OPENAI_API_KEY"'"
17 }
18 },
19 "options": {
20 "model": "gpt-4"
21 }
22 },
23 {
24 "name": "deepseek-instance",
25 "provider": "deepseek",
26 "weight": 2,
27 "auth": {
28 "header": {
29 "Authorization": "Bearer '"$DEEPSEEK_API_KEY"'"
30 }
31 },
32 "options": {
33 "model": "deepseek-chat"
34 }
35 }
36 ]
37 }
38 }
39 }'代理 LLM API 的最佳实践
使用基于 Token 的限流
- 避免对每个请求实行固定速率限制。
- 使用针对每个用户或每个 Token 的限制。
启用带退避策略的重试机制
- 在
ai-proxy-multi插件中使用 fallback_strategy。 - 准确检测状态码（如 429，5xx）。
保持 SSE/流式传输
- 避免使用会缓冲完整响应的插件。
- 确认
Transfer-Encoding: chunked得到保留。
区分提供商
- 根据模型名称、请求头或请求模式将请求路由到不同的上游。
使用可观测性插件
- 启用 prometheus 插件进行追踪。
- 记录响应时间和 Token 使用情况以控制成本。
真实案例：多智能体系统的 LLM 网关
场景：
- 使用 OpenAI GPT-4 的 AI 平台，并以 DeepSeek 作为故障转移备选。
- 每个用户的自定义 Token 配额。
- 向前端提供流式响应。
API 网关带来的收益：
- 减轻主上游服务的负载。
- 通过自动重试提升用户体验。
- 增加基于 Token 消耗量的分析能力。
结论
随着 LLM 成为生产应用的关键组成部分，API 网关在可靠、高效、安全地管理 LLM API 流量方面发挥着至关重要的作用。借助 Apache APISIX 等工具及其 LLM 兼容插件，工程师可以实现基于 Token 的限流、智能重试、流式代理以及跨 OpenAI 和 DeepSeek 等多个提供商的故障转移。
通过以这些能力来构建 API 网关层，团队可以打造出具备成本控制、强大错误处理和优秀开发者体验的弹性 AI 驱动系统。