AI 推理服务网关 — 统一多模型接入与管理的企业级 API 网关。

技术信息

语言技术
Python、Vue、Node.js、ElementUI、MySQL系统类型
Web行业分类
人工智能、企业服务

作品详情

行业场景

随着大语言模型（LLM）的爆发式增长，企业和开发团队面临以下挑战：
（1）OpenAI、通义千问、Kimi、DeepSeek 等厂商 API 格式各异，切换模型需要修改大量代码
（2）API Key 散落各处，无权限控制、无用量追踪、无成本核算
（3）各厂商计费规则不同，缺乏统一的费用统计和成本分析能力
（4）无请求频率限制，可能因误操作导致 API 费用飙升
（5）请求记录分散，无法追溯历史调用和排查问题

AI 推理服务网关是一个企业级 API 网关，统一代理多家大模型厂商的推理服务。它提供 OpenAI 兼容的统一接口，屏蔽底层厂商差异，集成了 API Key 管理、RPM/TPM 限流、Token 计费、请求日志、定时归档等企业级功能。

使用场景：
1. 企业内部 AI 中台：将网关部署在企业内网，对外暴露统一的 OpenAI 兼容接口，内部各团队通过申请 API Key 使用不同模型
2. AI 应用开发测试：开发者在 Playground 界面快速测试不同模型的响应效果，对比质量和成本
3. 多模型负载分发：根据请求量和成本策略，动态路由到不同厂商模型
4. 教学演示：课堂教学中展示 API 网关设计模式、滑动窗口限流、微服务架构等概念

功能介绍

统一推理接口：完全兼容 OpenAI API 格式，支持流式 (SSE) 和非流式调用
多模型适配：适配器模式，新增厂商只需配置 base_url
模型管理：支持自定义 Provider，动态切换
智能限流：RPM + TPM 双维度限流，Redis 滑动窗口算法，API Key 级别
实时计费：Token 用量统计 + 费用计算
用量仪表盘：费用趋势图、Token 统计、请求统计
审计日志：全量请求记录

项目实现

四家主流大模型厂商均支持 OpenAI 兼容的 `/v1/chat/completions` 接口格式，仅 `base_url` 和认证方式存在差异。因此采用「基类统一逻辑 + 子类覆写差异」的设计，避免重复代码。

传统的固定窗口限流（如「每分钟 60 次」）在窗口边界存在「突刺效应」——第 59 秒和第 61 秒各 60 次请求，实际 2 秒内通过 120 次。滑动窗口使用过去 60 秒的实际请求数，更平滑精确。

推理接口面向程序调用，需要轻量、无状态的认证；管理接口面向人员操作，需要会话管理。

计费触发时机：每次 `/v1/chat/completions` 请求完成后，从上游模型响应中提取 `usage` 字段，立即计算费用并写入 `request_logs` 表。

定时归档：Celery Beat 每天凌晨 2:00 触发归档任务

将横切关注点（日志、限流、CORS）从业务逻辑中解耦，通过中间件链统一处理。

AI 推理请求通常涉及网络 I/O（调用上游模型 API，耗时 2-30 秒），同步阻塞会耗尽 Worker 线程。全链路异步（从 Web 框架到数据库驱动到 HTTP 客户端）最大化并发吞吐。

避免 FastAPI 默认的纯文本异常响应（如 "Internal Server Error"），统一为 JSON 格式，方便客户端解析。