阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/Star-11k-kaiyuan-LLM-API-juhefuwu-octopus/ 「芋道源码」欢迎转载，保留摘要，谢谢！

• octopus 不是聊天工具，而是模型网关
• 核心功能：个人项目也该有成本账本
• 快速开始：Docker 和二进制都能跑
• 适合哪些人用
• 最后说句实话

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

现在接大模型 API，最烦的不是写调用代码，而是供应商太多、Key 太多、价格太乱、格式还不统一。

今天用 OpenAI，明天换 DeepSeek，后天又接 Anthropic。每加一家，业务代码就多一堆适配逻辑。说白了，你需要的不是再封装一个 SDK，而是一个自己的 LLM API 网关。

国内做 AI 应用尤其痛——模型供应商比国外还多还碎：OpenAI 走代理 / Claude 经常被风控 / 国产的 DeepSeek、智谱 GLM、通义千问、Kimi、豆包、MiniMax 一个比一个能更新。一个项目同时接 3-5 家是常态，业务代码里散落各家 API Key、各家 SDK、各家 Token 计费——octopus 卡的就是国内这种”多模型并存”的混乱状态。

octopus 就是干这个的：一个面向个人和小团队的 LLM API 聚合与负载均衡服务，支持渠道管理、分组管理、价格管理、协议转换和用量统计。

项目地址：https://github.com/bestruirui/octopus

octopus 不是聊天工具，而是模型网关

很多人看到 LLM 项目第一反应是“能不能聊天”。octopus 不是这个方向。

它更像 Nginx，只不过代理的不是 HTTP 服务，而是各种大模型 API。你的业务系统只对接 octopus，再由 octopus 去分发到不同供应商。

好处很实在：

能力	解决的问题
多渠道聚合	OpenAI、Anthropic、各种兼容服务统一管理
多 Key 支持	单渠道多个 Key 轮询或备用
智能优选	多端点里选择延迟更低的节点
负载均衡	请求分散到多个渠道，减少单点压力
协议互转	OpenAI Chat、Responses、Anthropic 格式互转
费用统计	Token、请求量、模型成本能看清

一句话：你把模型供应商从业务代码里抽出来，后面换模型、换渠道、换价格策略，都不用到处改代码。

核心功能：个人项目也该有成本账本

octopus 最值得看的不是“支持很多模型”，而是它把模型使用的运营问题补上了。

多 Key 支持可以解决一个现实问题：很多人手里不止一个 API Key，有的是不同渠道，有的是不同账号，有的是备用额度。没有统一网关时，这些 Key 很快就变成配置地狱。

价格同步和模型同步也很实用。模型更新太快，价格和可用模型列表靠手填迟早出错。octopus 把这部分自动化，至少不会让你在月底账单出来时才发现某个模型贵得离谱。

数据统计则是老板最关心的部分：谁在用、用了多少、花了多少钱。个人项目也一样，AI 成本不是玄学，要能算账。

快速开始：Docker 和二进制都能跑

如果只是试用，Docker 最省事：

docker run -d --name octopus -v /path/to/data:/app/data -p 8080:8080 bestrui/octopus

也可以用 Docker Compose：

wget https://raw.githubusercontent.com/bestruirui/octopus/refs/heads/dev/docker-compose.yml
docker compose up -d

不想用容器，也可以从 Releases 下载对应平台的二进制文件：

./octopus start

适合哪些人用

它适合这几类人：

用户	使用价值
独立开发者	一个入口管理所有模型 Key
小团队	控制不同项目、不同成员的模型成本
AI 应用开发者	业务代码不直接绑定供应商
想做容灾的人	某个渠道挂了可以切备用渠道

如果你只是偶尔调用一次模型，直接写 SDK 就行。octopus 的价值在“持续调用、多个渠道、需要统计和控制”。

最后说句实话

AI 应用早期最容易犯的错，是把模型供应商写死在业务里。前期看起来快，后期换模型、控成本、查账单时就开始还债。

octopus 这类网关不炫，但很实用。它把模型接入从“到处散落的 API Key”变成“一个可以治理的入口”。对个人项目来说可能有点超前，但对认真跑 AI 应用的人来说，这一步迟早要补。