跳到主要内容
版本：3.10.x

AI 网关快速开始

本文介绍使用 API7 AI 网关管理大模型请求的推荐路径。你可以从一个模型代理场景开始，再按生产环境要求逐步增加多模型路由、令牌限流、日志审计和安全治理能力。

前提条件​

开始之前，请准备以下信息：

  • 可用的 API7 企业版环境。
  • 一个或多个大模型服务提供方的访问密钥（API Key），例如 OpenAI、Azure OpenAI、DeepSeek、Anthropic 或 Google Gemini。
  • 一个用于测试的服务或路由。
  • 如果需要观测指标，请准备 Prometheus、日志系统或企业现有可观测性平台。

1. 代理第一个大模型请求​

使用 ai-proxy 插件可以把网关路由代理到上游大模型服务。业务应用只需要请求 API7 AI 网关暴露的统一入口，模型凭证和服务提供方细节由网关配置维护。

典型配置需要包含：

  • 服务提供方类型，例如 openai、deepseek、anthropic 或 openai-compatible。
  • 模型名称。
  • 访问密钥或凭证引用。
  • 上游端点，如使用兼容 OpenAI 协议的模型服务时需要配置自定义端点。

配置完成后，业务应用可以将原本指向模型供应商的请求改为指向网关入口。对于兼容 OpenAI 协议的调用，通常只需要替换 base_url 和网关访问凭证。

from openai import OpenAI

client = OpenAI(
    base_url="https://your-api7-gateway.example.com/v1",
    api_key="YOUR_GATEWAY_KEY",
)

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello"}],
)

2. 增加多模型路由和故障转移​

当你需要同时接入多个模型、多个服务提供方或多个区域时，可以使用 ai-proxy-multi 配置多模型路由。常见策略包括：

  • 按权重在多个模型实例之间分配流量。
  • 为关键模型配置备用模型或备用服务提供方。
  • 结合健康检查，在上游不可用时自动切换。
  • 在灰度期间逐步放量到新模型。

这类策略适合对稳定性要求较高的 AI 应用，也适合在成本、性能和模型效果之间做动态平衡。

3. 配置令牌与请求级限流​

使用 ai-rate-limiting 可以按令牌消耗设置配额。相比只按请求数限流，令牌限流更适合大模型计费和资源治理场景。

你可以按以下维度设置限制：

  • 路由或服务。
  • 消费者或消费者组。
  • 模型实例。
  • 自定义请求参数或标签。

推荐先为测试环境设置较小配额，确认日志和告警行为符合预期后，再在生产环境按团队、业务线或模型分层设置配额。

4. 打开日志、指标和审计​

AI 网关可以记录模型名称、令牌用量、首个令牌返回时间、请求延迟、错误和上游状态。你可以结合以下能力建立观测视图：

  • 使用 prometheus 采集大模型相关指标。
  • 使用 HTTP Logger、Kafka Logger、ClickHouse Logger 等日志插件采集请求日志。
  • 在 API7 企业版中保留配置变更与操作审计。

建议至少关注以下指标：

  • 请求量与错误率。
  • 平均延迟和首个令牌返回时间。
  • 提示词令牌、生成令牌和总令牌消耗。
  • 不同模型、消费者和路由的调用分布。

5. 增加提示词 / 响应安全治理​

当 AI 应用面向外部用户或处理敏感数据时，建议在网关层加入安全策略：

这些能力可以帮助团队降低提示词注入、敏感信息泄露、越权调用和不合规输出的风险。

推荐落地顺序​

  1. 先代理一个模型请求，确认业务应用可以通过网关访问大模型服务。
  2. 接入统一认证与访问控制，避免模型密钥散落在业务服务中。
  3. 增加日志与指标，建立调用量、延迟和令牌成本视图。
  4. 对关键业务启用多模型路由、重试和故障转移。
  5. 按团队、消费者或模型配置令牌限流和用量配额。
  6. 对外部用户场景启用提示词 / 响应安全治理和审计策略。

相关文档​