随着大语言模型（LLM）的爆发式发展，企业在接入 AI 能力时面临以下痛点：
1. 协议碎片化 ：OpenAI、Anthropic、Google Gemini 等主流厂商各自维护独立的 API 协议，客户端需要针对不同模型编写适配代码，开发与维护成本高昂。
2. 高可用与容错困难 ：单一 API Key 或单一提供商极易因限流（429）、服务故障（5xx）或网络波动导致业务中断，缺乏开箱即用的故障转移机制。
3. 成本与流量管控缺失 ：多渠道 API Key 并行使用时，难以实现按优先级、单价的智能流量调度；缺乏细粒度的 Token 用量统计与配额限制，容易造成成本失控。
4. 模型管理复杂 ：各提供商频繁上下线新模型，依赖手动维护配置难以及时响应。
基于上述背景， One API RS 应运而生——一个基于 Rust + Axum + SeaORM 构建的高性能 LLM API 网关，旨在提供统一的接入层，屏蔽上游差异，同时解决路由调度、容错与可观测性问题。
1. 统一协议网关
- 对外暴露标准的 OpenAI 兼容端点（ /v1/chat/completions 、 /v1/embeddings 等）。
- 内置协议转换层，自动将 OpenAI 格式请求转换为 Anthropic Messages 或 Google Gemini 格式，响应时再反向转换回 OpenAI 格式，客户端零改造即可对接多家模型。
2. 模型池与智能路由
- 模型池（Model Pool） ：同一个模型入口名可绑定多个提供商的 API Key，形成资源池。支持"单模型池"（同模型多渠道扩容）与"混合池"（异名模型混合，如 Qwen + GLM）。
- 智能打分路由 ：综合质量层级、请求专长（Code/Reasoning/Translation/Chat）、单价、历史反馈评分、实时延迟（EWMA）五大因子动态打分，择优转发。
- 灵活策略覆盖 ：支持客户端通过 X-Route-Policy 请求头临时覆盖路由策略（如 strict 严格按优先级、 pin: 锁定特定渠道）。
3. 高可用容错机制
- 故障转移 ：请求遭遇 5xx、403 或连接错误时，自动毫秒级切换至下一个候选 Key。
- 冷却退避 ：遭遇 429 限流时，自动解析 Retry-After 或 x-ratelimit-reset-requests 头，进入冷却期，到期自动恢复。
- 自动禁用 ：连续 3 次失败的路由将被自动标记为不可用并热更新内存，防止持续请求无效节点。
4. 配额管控与用量统计
- 支持按 API Key 或模型配置 Token 配额（Quota），超额自动拒绝并返回 429。
- 实时记录每条请求的 Input/Output Token 消耗，通过 Prometheus 指标（ /metrics ）暴露，可无缝对接 Graf
1. 技术栈选型
- 语言 ：Rust（Edition 2024），兼顾极致性能与内存安全。
- Web 框架 ：Axum 0.7，基于 Tokio 异步运行时，支持高并发 SSE 流式转发。
- 数据库 ：PostgreSQL，通过 SeaORM（异步 ORM）进行数据持久化，启动时自动执行 Schema 迁移。
- HTTP 客户端 ：Reqwest 0.12，配置连接池复用、HTTP/2 Keep-Alive，支持全局代理与直连双通道。
- 监控 ：prometheus-client 0.25，原生构建 Prometheus 指标体系。
- 前端 ：React + TypeScript + Vite，构建轻量级管理后台。
2. 核心架构设计
- 协议抽象层（ protocol/ ） ：定义 Protocol 枚举与 Trait，将请求转换（ transform_request ）、响应转换（ transform_response ）及流式 SSE 转换（ transform_stream ）解耦，新增协议只需实现对应接口。
- 流式处理（ backends.rs ） ：
- 采用 Stream 机制做 SSE 实时转发，避免将整个响应体加载到内存。
- 内置 StreamFinalizer ，基于 Poll + Drop 机制确保无论流正常结束还是客户端提前断开，Token 用量都能准确落账。
- OpenAI 流式请求自动注入 include_usage 保证统计完整性，同时对客户端无感。
- 路由引擎（ routing.rs ） ：加载数据库快照构建内存路由表，支持无锁并发读取；打分引擎结合实时延迟追踪（ latency.rs ）与用户反馈（ feedback.rs ）动态计算权重。
评论