nano-api

项目背景

本项目是适用于自建的 LLM API 中转平台，具有以下四点功能：

1. 额度共享
2. 用量统计
3. 多 key 轮询
4. 改进兼容性

额度共享

所有用户可以共享彼此贡献的账号额度。每个用户可以将自己在各供应商处的账号贡献到平台，所有用户通过各自的 nano-api 密钥访问时，可以使用平台上所有可用账号的额度。系统会记录每个密钥的用量。

我们定义以下概念：

• nano-api 用户：系统使用者（对应自然人）
• 账号：供应商处的注册账号，具有独立的额度和计费
• 渠道：供应商提供的服务平台或接入入口（如 AI Studio、Vertex API、OpenRouter），具有统一的密钥管理和计费体系，可能支持多种 API 格式
• 上游密钥：在特定渠道下生成的 API 密钥，关联到某个账号
• 密钥：用户访问 nano-api 时提供的密钥，用于区分用途和统计用量

用户与账号之间是一对多的关系，用户创建与供应商账号对应的账号并贡献给平台。账号与渠道之间是多对多的关系，通过上游密钥关联，例如同一个谷歌账号可以同时配置 AI Studio 和 Vertex API 两个渠道的上游密钥。用户与密钥之间也是一对多的关系，每个用户可以创建多个 nano-api 密钥用于不同的软件或用途。

使用示例：一个小团队搭建了 nano-api 实例。成员 A 贡献了自己的谷歌账号（可通过 AI Studio 和 Vertex API 接入），成员 B 贡献了 DeepSeek 账号（可通过官方 API 和 OpenRouter BYOK 接入）。每个成员创建自己的 nano-api 密钥用于日常使用，调用时自动从可用的上游账号中选择，用量按密钥维度统计。

关于兼容性

当前 LLM API 处于非常混乱的状况。

首先是长期存在的问题：五花八门的 API 格式。除主要的 OpenAI 兼容、Anthropic、Gemini 三种 API 格式以外，还有比如 OpenAI Response、Vertex 的各种其它格式。不同供应商的请求与响应字段也各不相同。

其次是模型带来的新问题：不同模型开始逐渐要求回传思维链。Gemini 3 在连续调用工具时需要回传思考签名，这实际上也是加密的思维链。这类模型的适配需要在客户端完成，如果客户端不回传思考内容，中转是无能为力的。

各类上游开始提供多种类型的接口（如智谱提供 OpenAI 兼容格式与 Anthropic 格式，Gemini 提供 OpenAI 兼容格式与 Gemini 格式，gcli2api 的 Antigravity 端点提供 Gemini、OpenAI 兼容和 Anthropic 三种格式）。Gemini 与 Anthropic 格式相对规矩，OpenAI 兼容格式由于种种原因各不相同。

再来看看客户端的情况。不同客户端对中转服务的适配不尽相同。例如 Cherry Studio 对中转极其友好，每类上游渠道都允许自定义 BaseURL 和模型列表；Kilo Code 只支持在 OpenAI 兼容格式下自定义模型名，且不支持回传思考内容。

因此还是需要对 OpenAI 兼容的请求参数和响应格式进行统一。比如将 OpenRouter 和 Cerebras.ai 的响应内容中 reasoning 字段转换为 reasoning_content；还有根据模型名适配不同的请求参数，比如对于 glm-4.6-nothink:cerebras 模型名，清除所有的额外参数，设置 disable_reasoning 为 true。

技术选型

• 后端框架：FastAPI + Uvicorn
• 数据库：SQLite + SQLModel + aiosqlite + Alembic
• 上游客户端：OpenAI SDK、GenAI SDK、Anthropic SDK、各个供应商自己的 SDK
• 前端：Jinja2 + HTMX + Tailwind CSS（CDN）
• 用户管理：fastapi-users
• 流式响应：sse-starlette
• 日志：loguru