Auto AI Router：LLM API 的智能流量调度引擎

当你的 AI 应用遭遇「薛定谔的 API」

凌晨两点，你的 AI 客服系统突然全部报 429 错误——不是 OpenAI 挂了，而是其中一个 API Key 的 Rate Limit 悄无声息地触发了。你的程序还在傻傻重试同一个 Key，直到所有请求全部超时。

又或者：你在 Vertex AI 上跑 Claude Sonnet 4，因为某次突发流量导致日配额提前耗尽，而你的系统完全不知道还有另一个备用 Key 可以分流。

这些场景，是每一个在生产环境中运行 LLM 应用的人或多或少都经历过的痛。Auto AI Router 正是为解决这些问题而生的高性能 LLM API 代理网关。

项目背景：一个运维工程师的「被迫」作品

Auto AI Router（简称 AIR）由独立开发者 MiXaiLL76 创建于 2024 年。他的动机很直接：在自己的项目中同时使用 OpenAI、Vertex AI、Gemini 和 Anthropic 的 API，每个平台又持有多个 API Key，缺乏一个统一且可靠的路由层。他评估了 LiteLLM Proxy 等现有方案，发现要么功能过于复杂、要么性能不满足需求，于是决定自己写一个。

AIR 用 Go 语言从零构建，目标明确：轻量、高性能、功能专一。项目采用 Apache 2.0 开源协议，目前 GitHub 收获约 49 颗星，虽然社区规模不大，但代码质量相当扎实。

类比：AI 世界的「七号交换机」

如果把传统的 API 调用比作「拨打固定电话号码」，那么 Auto AI Router 就是一台智能电话交换机。它接收你的请求，根据预设规则自动选择最优的出口线路（哪个 Key、哪个 Provider），同时监控每条线路的健康状态。一旦某条线路出现占线（Rate Limit）或故障（500 错误），它立即自动切换到备用线路，对客户端完全透明。

这听起来简单，但实际做起来涉及：多协议转换、流量整形、负载均衡、故障转移、安全防护、日志审计……每一个环节都有大量细节需要处理。

核心功能：不是简单转发，而是智能调度

多 Provider 统一接入

AIR 目前支持六大类 Provider：

• OpenAI（含 Responses API、图像/视频/嵌入模型）
• Anthropic（Messages API、Responses API、Claude Code）
• Google Vertex AI（Gemini 全系列、Image 2/3、Imagen）
• Google AI Studio Gemini
• AWS Bedrock（Claude 系列）
• Comet API & 其他 AIR 实例（链式代理）

更重要的是，AIR 实现了协议层自动转换。客户端可以用 OpenAI 格式调用 Claude，客户端用 Vertex 格式调用 Gemini——AIR 在中间做格式转换，上下游完全解耦。

智能负载均衡

AIR 支持两种均衡策略：

• Round-robin（轮询）：均匀分发请求到多个 Key，适合各 Key 配额相同的情况
• Weighted（加权）：按权重比例分发，适合 Key 配额差异大的场景

它还能识别认证上下文（用户/团队/组织），在同一会话中将请求路由到同一个 Key（Session Sticky），确保对话上下文的一致性。

限流与熔断

每个 Key 都有独立的 RPM（每分钟请求数）和 TPM（每分钟 Token 数）限制。超出限制的请求会被优雅地排队或拒绝，而不是直接 429 抛给客户端。

Fail2ban 机制是其亮点：连续触发指定错误码（401/403/429/500/502/503/504）的 Key 会被自动封禁，可以是临时的（如 5 分钟）也可以是永久的，确保故障 Key 不会拖垮整个系统。

费用追踪与 Key 管理

AIR 与 LiteLLM Database 深度集成，可以：

• 按用户/团队/组织维度记录 API 调用费用
• 通过 API Key 进行认证和访问控制（ACL）
• 支持密钥加密存储，敏感信息不裸存于配置文件

此外，AIR 支持从 ClickHouse 导出消费日志，方便接入企业 BI 系统做成本分析。

观测性：Prometheus + OpenTelemetry + Grafana

生产级观测三件套全部就位：

• Prometheus metrics：请求量、延迟分布、各 Key 健康状态
• OpenTelemetry：分布式链路追踪，端到端可视化
• Grafana dashboard：开箱即用的可视化面板（examples/grafana.json）

内置的 Web UI（/health、/config、/trace）提供轻量级的状态查看，不依赖外部 Dashboard 也能了解系统运行情况。

部署体验：Docker 一键启动

AIR 的部署体验打磨得很成熟：

# 最简方式
docker pull ghcr.io/mixaill76/auto_ai_router:latest
docker run -p 8080:8080 -v $(pwd)/config.yaml:/app/config.yaml ghcr.io/mixaill76/auto_ai_router:latest

docker-compose.yml 默认启动 3 副本 + Valkey（Redis 兼容）缓存，还支持可选接入 ClickHouse、Kafka、Grafana 等组件。Dockerfile 采用多阶段构建，最终镜像是精简的 scratch 运行时——只有一个静态编译的 Go 二进制文件，镜像体积极小。

技术架构：清晰的分层设计

项目目录结构清晰，体现了良好的工程分层：

internal/
├── proxy/          # HTTP 反向代理核心逻辑
├── router/         # 请求路由与分发
├── balancer/       # 轮询/加权负载均衡算法
├── converter/      # 多协议格式转换（OpenAI/Anthropic/Vertex/Bedrock）
├── ratelimit/      # RPM/TPM 限流（本地 + Redis 后端）
├── fail2ban/       # 自动封禁机制
├── litellmdb/      # LiteLLM DB 集成（认证、费用记录）
├── kafkalog/       # Kafka 异步日志
├── responsestore/  # 响应缓存（Redis）
├── monitoring/     # Prometheus metrics 暴露
├── scope/          # ACL 权限表达式引擎
└── security/       # 敏感信息脱敏

关键依赖全部选型克制：

• gorilla/websocket：WebSocket 流式响应
• jackc/pgx：PostgreSQL 客户端（LiteLLM DB）
• twmb/franz-go：Kafka 客户端（日志）
• valkey-io/valkey-go：Valkey 缓存
• prometheus/client_golang：监控指标
• tiktoken-go/tokenizer：本地 Token 计数

代码中测试覆盖相当完善（internal/ 下大量 *_test.go），且配有 Python pytest 集成测试套件（tests/ 目录），覆盖多 Provider 的基本对话、流式输出、工具调用、多模态等场景。

局限与注意事项

1. 项目相对小众：49 星，社区规模和生态远不及 LiteLLM Proxy，生产使用需自行评估维护风险
2. 配置复杂度较高：config.yaml 有大量选项，需要仔细阅读文档才能正确配置
3. Grafana 图片因 CDN 问题无法内嵌展示：可访问 GitHub 仓库查看截图
4. 多 Provider 语义对齐：不同 Provider 的 Tool Use、Thinking Budget 等高级特性语义存在差异，AIR 虽然做了大量工作，但仍可能在特定边界场景出现意外行为

行业意义

随着 LLM 应用从 POC 走向生产，多 Provider、多 Key 的管理已成刚性需求。LiteLLM Proxy 代表了「功能优先」的路线，而 Auto AI Router 则代表了**「性能优先」**的路线——Go 的并发模型天然适合这种 I/O 密集型的代理场景，纯静态编译也极大简化了容器化部署。

未来，随着更多企业需要在同一系统中同时使用 OpenAI、Claude、Gemini 以及开源模型，这类智能路由网关的价值会越来越突出。AIR 以 Apache 2.0 协议开源，代码质量扎实，是值得关注的技术方案。

---

报告生成时间：2026-08-13 | 数据来源：GitHub API + 源码分析