Augur：面向生产的智能LLM推理网关，实现请求感知路由与自适应学习

Augur是一个用Go语言编写的开源LLM推理网关，它解决了多模型部署中的核心难题：如何为每个请求选择最合适的后端。项目支持OpenAI、Anthropic及兼容OpenAI的本地服务器，提供基于策略、健康状态、延迟、成本和实际结果学习的智能路由能力。

• 原作者/维护者：vanshamara
• 来源平台：GitHub
• 原始标题：Augur
• 原始链接：https://github.com/vanshamara/Augur
• 来源发布时间/更新时间：2026-06-05

在大语言模型（LLM）迅速普及的今天，调用模型本身已经变得相对简单——无论是通过OpenAI的API、Anthropic的Claude，还是本地部署的vLLM或Ollama，开发者都能快速集成模型能力。然而，真正的挑战在于如何为每个请求选择正确的后端。

不同的模型在成本、延迟、质量和能力上存在显著差异。GPT-4.1-nano可能足够处理简单的闲聊，但面对复杂的推理任务时，可能需要GPT-4.1甚至Claude 3.5 Sonnet。更糟糕的是，模型性能会随时间波动，某些后端可能出现故障或变慢。手动管理这些复杂性几乎是不可能的。

这就是Augur诞生的原因——一个自托管的Go语言推理网关，它智能地将请求路由到最合适的后端，同时强制执行延迟、成本、错误率和质量限制，并从实际结果中学习优化策略。

Augur定位为一个请求感知的LLM网关，它位于客户端和多个模型后端之间，提供统一的OpenAI兼容API接口（/v1/chat/completions和/v1/embeddings）。

• 多后端支持：可同时连接OpenAI、Anthropic以及任何OpenAI兼容的本地服务器（如Ollama、vLLM、LM Studio）
• 智能路由：基于能力、健康状态、成本预算和实时信号过滤候选后端
• 弹性机制：支持故障回退链（fallback chains）、金丝雀发布（canary）、影子金丝雀（shadow canary）、对冲请求（hedging）和单例模式（single flight）
• 可观测性：内置Prometheus指标、后端调试状态和路由决策记录
• 自适应学习：可选的bandit学习路由器，根据实际结果持续优化后端选择

理解Augur的最佳方式是跟踪一个请求的完整生命周期：

客户端 → HTTP API → 数据平面 → 路由器/控制器 → 后端适配器 → 模型提供商

1. 请求解析：internal/httpapi解析OpenAI兼容的请求格式，提取请求类型（chat/reasoning/coding/embedding）和客户端提示

2. 路由匹配：internal/dataplane根据配置的路由规则匹配候选后端集合。路由可按任务类型、租户、用户层级等条件匹配

3. 多层过滤：数据平面依次应用以下过滤器：

   • 能力过滤：确保后端支持请求类型（如embedding请求只能路由到支持embedding的后端）
   • 健康过滤：排除不健康或熔断状态的后端
   • 并发限制：强制执行自适应并发控制
   • 租户限制：检查租户级别的飞行中请求数和成本预算
   • 成本预算：估算每个候选后端的成本，剔除超出预算的选项

4. 金丝雀分配：如果路由配置了金丝雀规则，按百分比将部分请求分配给候选后端

5. 路由选择：路由器从剩余候选中选择一个后端。Augur支持多种策略：

   • 静态、轮询、最小负载
   • EWMA（指数加权移动平均）
   • 成本感知
   • P2C（Power of Two Choices）
   • Bandit学习路由器

6. 故障回退：如果选中的后端在返回完整响应前失败，Augur会尝试回退链中的下一个后端

7. 影子金丝雀：可选地调用候选后端但不返回其响应，用于收集性能数据

8. 请求执行：后端适配器将请求发送到实际的模型提供商或本地服务器

9. 响应增强：返回的响应包含丰富的元数据头：

   • X-Augur-Backend：实际处理请求的后端
   • X-Augur-Route：匹配的路由名称
   • X-Augur-Fallback-Count：回退尝试次数
   • X-Augur-Attempted-Backends：所有尝试过的后端
   • 成本相关头：预估和实际成本

10. 学习更新：如果启用了实时学习，internal/live会更新奖励和质量状态

Augur的路由配置采用声明式YAML/JSON格式，支持高度灵活的匹配规则：

routes:
  - name: "reasoning"
    match:
      task_types: ["reasoning"]
      tenants: ["premium"]
    candidates:
      - backend: "balanced"
    fallbacks:
      - backend: "strong"
    canary:
      backend: "candidate"
      percent: 5
      sticky_key: "tenant_and_request"

这种设计允许运营团队为不同场景定义精细的策略：高价值推理任务使用更强的模型，普通聊天使用更便宜的模型，同时保持代码的简洁性。