Squirrel：企业级 LLM 网关，让 AI 调用像搭积木一样简单

一套系统，接入所有大模型——Squirrel 如何解决 AI 集成的最后一公里

想象这样一个场景：你的公司同时接入了 OpenAI GPT-4、Anthropic Claude、Azure OpenAI 以及几个开源模型，每个模型有不同的 API 格式、计费规则和调用限制。业务团队今天想换用最便宜的模型降本，明天又因为某个模型在特定地区不可用需要切换，后天你发现开发团队直接在代码里硬编码了 API Key……

Squirrel（中文名"松鼠"，取其"收集+分发"的寓意）就是为了解决这类问题而生的。它是一个高性能企业级 LLM 网关，扮演"AI 流量路由器"的角色——一次接入，就能通过统一的 API 访问所有主流大模型服务，并且自带智能路由、故障转移、成本统计和管理面板。

---

项目背景：LLM 集成为什么这么难

大语言模型 API 生态正在快速碎片化。OpenAI 有 Chat Completions API 和 Responses API 两套协议，Anthropic 有自己的 Messages API，Google 有 Gemini 的专属格式，而开源模型（Ollama、vLLM）又是另一套。各家 SDK 互不兼容，企业内部往往需要维护多套接入代码。

更棘手的是成本管理。一家公司每月在 GPT-4 和 Claude 上花费数万美元，但没有人知道哪次调用花了多少钱、哪个团队的用量最大、是否可以通过切换到更便宜的模型省下预算。

Squirrel 的作者 mylxsw 从 2024 年开始开发这个项目，核心思路是：让所有 LLM API 调用都通过一个统一的代理层，在这一层做路由、计费、监控和协议转换。项目基于 FastAPI（Python 3.12）构建后端，Next.js 16 构建管理面板，当前 GitHub 获 69 star，虽然 star 数不高，但在企业级 LLM 网关这个细分领域具备相当的工程完成度。

---

核心功能：路由、容错、观测，一个都不能少

智能路由——让请求自动找最优解

Squirrel 支持四种负载均衡策略：

• 轮询（Round-Robin）：请求均匀分配到多个后端，适合多账号场景
• 优先级（Priority）：优先使用首选供应商，失败时自动切换到备用
• 权重（Weight）：按自定义比例分配，例如 GPT-4 占 30%、Claude 占 70%
• 最优成本（Cost-Based）：根据各模型实时价格自动选择最低价选项

此外，Squirrel 支持规则路由：可以基于模型名称、请求头、消息内容或 Token 数量来决定路由策略。例如，设置"当消息长度超过 8000 Token 时，强制路由到支持 128K 上下文的模型"。

模型映射功能允许你定义虚拟模型名称到多个真实后端的映射。比如定义一个 gpt-4-cheap 映射到 gpt-4o-mini，前端应用无需改动，切换模型只改网关配置。

协议转换——OpenAI、Anthropic、Responses 三者互通

Squirrel 内置 llm_api_converter 模块，实现了三种协议之间的请求、响应和流式输出互转：

• OpenAI Chat Completions ↔ OpenAI Responses（含 tool-calls 和 streaming）
• OpenAI Chat Completions ↔ Anthropic Messages
• Anthropic Messages ↔ OpenAI Responses

这意味着：如果你有一个基于 OpenAI SDK 开发的应用，现在想切换到 Claude，只需改 Squirrel 配置，不用动一行代码。协议转换对上层应用完全透明。

全面可观测性——每一分钱的去处都清晰可见

Squirrel 记录每一次请求的完整日志，包括：

• Token 用量（基于 tiktoken 自动计算）
• 首字节延迟和总响应时间
• 按时间、模型、供应商和 API Key 聚合的成本统计
• 请求体和响应体全量记录（含流式响应），便于调试

日志采用分层存储策略：摘要保存在 request_logs 表，大体积载荷保存在 request_log_details，既保证日志列表查询性能，又支持按需查看完整内容。

MCP 管理接口——让 AI Agent 来管理 AI 网关

这是 Squirrel 的一个亮点功能：通过 Model Context Protocol (MCP) 让 AI Agent 直接管理网关。Agent 可以查询供应商状态、查看模型配置、浏览请求日志和成本统计，甚至可以开启写操作来动态调整路由规则。这在需要 AI 驱动的自动化运维场景中很有价值。

---

技术架构：FastAPI + Next.js，工程完成度高

后端基于 FastAPI + Python 3.12，采用异步架构（async/await），支持高并发。核心技术栈：

• API 层：FastAPI 路由，分为 proxy（代理核心）、admin（管理接口）、auth（认证）
• 数据层：SQLAlchemy ORM + PostgreSQL（生产）或 SQLite（轻量）；Redis 用于 KV 存储
• 调度：APScheduler 定时任务
• LLM 集成：内置 llm_api_converter 协议转换；MCP Server（Streamable HTTP）
• 测试：pytest + pytest-asyncio，覆盖率报告（.coverage）

前端基于 Next.js 16 + TypeScript + shadcn/ui，是目前最主流的企业级 React 技术栈。功能模块包括供应商管理、模型映射配置、API Key 生命周期管理、日志查看器和成本分析仪表盘。

容器化采用多阶段 Dockerfile：前端 Node 镜像构建静态资源，后端 Python 镜像运行服务。生产部署通过 docker-compose.prod.yml 一键启动，包含 PostgreSQL 16 和 Redis 7 依赖服务，全部带 healthcheck。另有 docker-compose.dev.yml 用于本地开发。

---

上手体验：零代码改造成最大卖点

Squirrel 的使用方式极其简单——应用端完全不用改代码。只需要把原本指向 https://api.openai.com 的请求改成指向 Squirrel 地址，Squirrel 会根据配置路由到正确的后端，并记录所有调用数据。

部署只需三步（生产模式）：

git clone https://github.com/mylxsw/llm-gateway.git
cd llm-gateway
POSTGRES_PASSWORD=xxx REDIS_PASSWORD=yyy ALLOWED_ORIGINS=http://localhost docker compose -f docker-compose.prod.yml up -d
# 访问 http://localhost:8000

管理面板基于浏览器使用，支持供应商连接测试、模型映射规则配置、API Key 生成和日志查询，功能完整。

轻量模式：不想跑 PostgreSQL + Redis？可以不配置这些依赖，Squirrel 内置 SQLite 存储，单个 Docker 容器即可运行，适合小规模使用或本地测试。

---

局限与不足

1. Star 数偏低，社区活跃度有限：69 star 在开源项目中属于早期阶段，Issues 和 PR 数量较少，长期维护的可持续性需要观察。
2. 无 License 声明：仓库根目录 LICENSE 文件缺失，使用前需确认授权条款。
3. 无 AI 相关 topics：GitHub topics 为空，在 GitHub 的 AI 项目生态中发现率较低。
4. 成本计算基于 API 定价：Squirrel 内置了模型价格表，但实际计费需要自行维护最新价格，且不同地区的 API 价格可能不同。
5. MCP 写操作需谨慎开启：允许 AI Agent 动态修改路由规则有安全风险，生产环境建议仔细评估权限配置。

---

总结与适用场景

Squirrel LLM Gateway 定位清晰：企业级 LLM 流量管理层，解决多供应商、多协议、多团队场景下的统一接入和成本管控问题。FastAPI + Next.js 的技术选型工程化程度高，Docker Compose 一键部署降低了使用门槛，MCP 接口则为 AI 原生运维提供了想象空间。

适合引入的场景：

• 企业内部有 3+ 个 LLM 供应商，需要统一管理
• 需要按团队/项目追踪 AI API 用量和成本
• 应用需要在不同模型之间动态切换
• 希望用统一的 OpenAI SDK 格式访问非 OpenAI 模型

不建议使用的场景：

• 个人或小团队，单一模型，简单调用
• 对 AI 网关没有成本分析、路由控制需求的场景
• 追求极简、不希望引入额外基础设施依赖的环境

总体来说，Squirrel 是一个工程完成度扎实、功能定位精准的企业级工具，适合有 LLM 多供应商管理需求的技术团队关注和试用。