用途
OpenRouter 参考架构用于指导以 OpenRouter 作为统一 LLM 网关的生产级系统设计。它把 OpenRouter 视为抽象掉各模型供应商复杂性的统一入口，并在其外层包裹缓存、限流、成本控制、可观测性和异步处理等能力，帮助团队在系统设计规划、架构评审和 AI 应用扩容时做出有依据的架构选择。
主要能力
该技能提供三种参考架构：
- 架构 1（简单版，单服务）：一个共享的 OpenRouter 客户端（max_retries=3、timeout=30.0），外层套一个带日志的 complete() 包装函数，记录每次调用实际服务的模型以及 prompt 与 completion 的 token 数量。
- 架构 2（标准版，微服务）：一个 FastAPI 的 /v1/complete 端点，包含按任务类型路由的 ROUTING_TABLE、缓存优先查找、预算检查，以及回退链（通过 extra_body 指定 models 列表与 route: "fallback"）。返回 {content, model, tokens}，命中缓存时返回 {content, cached: true}。
- 架构 3（企业版，事件驱动）：队列（Redis/SQS）→ 自动扩缩容的 worker（运行 worker_loop()）→ 结果存储，配合 OTEL 指标驱动仪表盘与告警。worker 产出的结果记录为 {id, content, model, status}，推送到 ai:results:{id} 并设置一小时 TTL。
此外还提供架构选型表，按团队规模、每日请求量、延迟需求、预算跟踪粒度、故障处理方式和可观测性等维度给出建议。
使用方式
前置条件：
- OpenRouter API 密钥（sk-or-v1-...），以 OPENROUTER_API_KEY 环境变量导出。
- Python 3.8+ 与 OpenAI SDK；架构 2 的 AI 服务需要 FastAPI + Pydantic；架构 2 的缓存和架构 3 的队列/结果存储需要 Redis 实例（含 redis 包）。
- 若实现架构 2 的预算执行器，需要 SQLite 或 Postgres。
- 需要明确自身的规模数据：团队规模、每日请求量和延迟需求，用于架构选型。
操作步骤：
- 对照选型表为系统打分：团队规模、每日请求量、延迟需求、预算跟踪粒度、故障处理、可观测性。
- 从架构 1（简单版）起步：一个共享客户端，外层套带日志的 complete() 包装。
- 当需要任务路由、缓存和按用户预算时，升级到架构 2（标准版）：FastAPI 的 /v1/complete 端点，配合 ROUTING_TABLE、缓存优先查找、预算检查和回退链。
- 当达到每日 10 万+ 请求或存在同步/异步混合负载时，采用架构 3（企业版）：队列（Redis/SQS）→ 自动扩缩容 worker 运行 worker_loop() → 结果存储，OTEL 指标接入仪表盘与告警。
- 无论采用哪一层，所有调用都应经过同一个 OpenRouter 客户端包装，以保证日志、成本跟踪一致，且不绕过预算。
适用场景
- 规划 AI 应用系统设计、评审现有架构。
- 需要按任务类型路由到不同模型（如分类、代码、分析、通用、预算等）。
- 需要缓存、按用户预算控制、回退链和可观测性的生产环境。
- 每日请求量从不足 1K 到 10 万+ 的不同规模团队。
- 可容忍超过 1 秒延迟的请求（如成本报告、批处理）适合采用队列模式。
限制
- 资料未提供具体的收费、价格信息。
- 资料未提供除文中列出的模型标识（如 openai/gpt-4o-mini、anthropic/claude-3.5-sonnet、meta-llama/llama-3.1-8b-instruct）之外的其他模型支持情况。
- 资料未提供部署平台、性能基准或效果数据。
- 使用前需自行准备 OpenRouter API 密钥及相关依赖（Python、OpenAI SDK、FastAPI、Redis、SQLite/Postgres 等）。
- 资料中提到的错误处理（单点故障、队列积压、缓存击穿、预算绕过）需要按对应修复方式自行实现。