你有没有过这种体验电脑浏览器里开着一堆大模型厂商的工作台页面DeepSeek 一个、智谱一个、Kimi 一个、通义一个每个页面里都躺着一个 API Key而且每个 Key 的计费规则、模型命名、接口地址还都不一样。我身边玩 AI 应用的朋友几乎都经历过在同一段代码里反复切换 base_url、复制粘贴 key 的崩溃瞬间。后来我自己在 NAS 上部署了 Octopus把家里这台 7x24 小时开机的群晖腾出一个容器跑了一个大模型 API 统一管理网关DeepSeek、智谱、Kimi、通义这些全部收编成一个 OpenAI 兼容的入口、一把统一的钥匙、一套模型列表。这篇文章就把我的完整部署过程、配置细节、踩坑经历都整理出来如果你也在折腾 NAS 和 AI 应用大概率用得上。1. 为什么我会盯上 Octopus大模型 API 管理的烂摊子1.1 多模型 API 管理的真实痛点先说一个很典型的场景。我自己写了一个本地知识库问答机器人一开始只接了 DeepSeek后来觉得某些任务上智谱的 GLM 效果好一点又加了个 Key再后来想对比一下 Kimi 的长上下文模型于是又一通改配置。三个月下来代码目录里全是废弃的 base_urlenv 文件里的 API Key 到底哪个在用我自己都记不清了。这种混乱不止体现在切模型上。每家厂商的接口命名习惯不同有的叫deepseek-chat有的叫glm-4-flash还有的叫moonshot-v1-32k请求参数虽然大体都兼容 OpenAI 格式但总有些小差异。更麻烦的是限流和故障某家平台晚间高峰期响应变慢甚至 502你的客户端就只能干等没有任何容错机制。账单也是各查各的月底想算一下“这个月 AI 到底花了多少钱”得登录四五个后台手工拉表格。这些痛点背后其实是一个共性问题模型供应商越来越多但开发者的接入方式还停留在“每个应用直连多个厂商”的原始阶段。你需要的不是一个新模型而是一个把“多模型接入”这件事统一起来的中间层。1.2 为什么选 NAS而不是另外买一台服务器很多人会问统一管理大模型 API为什么非得用 NAS买一台云服务器不是更简单吗我的理由有三层。第一NAS 本来就是 7x24 小时开机的设备家里跑着的 Jellyfin、Home Assistant、相册备份已经占用了它再多跑一个 Docker 容器几乎零额外功耗。第二API 网关涉及的 Key、令牌、日志都属于敏感信息放在自己的 NAS 上数据完全在自己手里比丢在第三方服务器上踏实得多。第三从成本看一台能跑 Docker 的老 NAS 完全够用Octopus 这类网关对性能要求不高贵在稳定不在算力。当然如果你家里没有 NAS也可以跑在一台常开的小主机上比如 NUC 或者各种迷你工控机原理完全一样。我自己用的是群晖 DS920x86 架构跑 Docker 非常顺手。ARM 架构的机型比如部分入门款群晖、威联通我也试过只要你选对镜像架构同样能跑只是个别容器做不了docker compose pull这种操作时要注意版本兼容。1.3 典型使用场景谁需要这玩意儿把话说明白点Octopus 这类工具适合下面几类人本地 AI 应用玩家用了 NextChat、LobeChat、Cherry Studio 这类客户端希望一个地址就能切换所有模型。开发者正在做 AI 机器人、自动化脚本、知识库检索等不想在每个项目里维护一堆 Key 和 base_url。小团队内部共享几个人同时调模型又要控制预算需要一个统一的出入口来分配额度、记录消费。喜欢对比评测模型的人想在同一套代码里快速换模型看同一个 Prompt 在不同大模型下的表现差异。说白了它就是你家 AI 应用的“总电线闸”外面有一堆供电公司模型厂商你只需要记得自己家的总闸在哪不用记每家公司的电线编号。2. Octopus 核心能力拆解它到底帮我解决了什么2.1 统一入口的工作原理Octopus 本质上是跑在 NAS 上的一个服务进程它对外提供的是一个 OpenAI 兼容的 HTTP 接口。你的所有客户端、脚本、应用都只认这一个地址、一把 Key至于这个请求后端到底走了 DeepSeek 还是智谱网关来判断和转发。正常情况下一个请求的流转是这样的客户端把请求发到http://NAS地址:端口/v1/chat/completionsOctopus 收到请求后解析出模型名去它的“模型路由表”里找到对应的供应商和真实 Key然后自己作为客户端去请求 DeepSeek 或智谱的上游接口拿到结果之后再返回给你的客户端。对于客户端来说它根本不知道自己被“转折”了一下。这里最妙的是 OpenAI 兼容格式。现在几乎所有国产大模型厂商都会提供一个 OpenAI 兼容接口这意味着 Octopus 不需要为每家厂商写特殊适配只要统一转成 OpenAI 的请求格式发出去就行。市面上主流的 AI 客户端也都以 OpenAI 协议作为“通用语言”两边一凑整个链路就通了。2.2 关键特性路由、容错、计费我实际用下来Octopus 最值钱的功能有三个路由、容错、计费。路由指的是你可以把多个模型映射在一起。比如我在配置里把“主模型”指向 DeepSeek把“备用模型”指向智谱当前端请求一个叫main-model的模型名时网关会自动优先打给 DeepSeek如果 DeepSeek 超时或返回错误它自动转为调用智谱。对于像我这种不喜欢前端感知异常的玩家来说这种“用户无感切换”能极大提升体验。容错体现在重试机制上。你可以配置最多重试几次、超时多久算失败、哪些错误码需要重试。比如上游返回 429限流和 500服务器错误时网关会按规则重新选择一个渠道去请求避免单个厂商抖动拖垮整个应用。计费方面Octopus 会把每一次请求的输入 token、输出 token、模型名、用户标识、耗时都记录下来。我在管理后台能看到每个应用、每个时间段分别消耗了多少 token、折合多少钱。虽然各家价格随市场波动但它至少解决了“钱去哪了”的问题。2.3 同类方案对比为什么 Octopus 适合个人 NAS 玩家我先坦白市面上这类工具不少最出名的是 one-api 和它的分支 New API。我在决定用 Octopus 之前也把这两类都跑过一遍。简单做个对比。方案部署难度功能侧重适合人群Octopus低一个 compose 即可统一入口、路由容错、用量统计、轻量管理界面个人 NAS 玩家、小团队one-api中功能全面但界面较老多租户、令牌管理、渠道分组偏向运营级有一定运维能力的人New API中高功能比 one-api 更丰富支持更多高级转发、模型广场、比价需要给多人提供服务的场景Cloudflare AI Gateway中依赖域名和外部服务全球节点、缓存、速率限制有公网域名和海外访问条件的玩家我最后选 Octopus原因很简单它在 NAS 上跑得轻、默认配置合理、界面现代化对“一个人管全家 AI 调用”这个场景非常对口。功能不是越复杂越好够用、稳定、好维护才是自托管的第一原则。如果你的需求是给几百人开放注册那 one-api 或 New API 可能更合适但那就不是这篇博文要聊的事了。3. 实战部署在群晖 NAS 上把 Octopus 跑起来3.1 前置准备与目录规划部署之前先把环境理清。我以群晖为例DSM 7 及以上版本自带 Container Manager如果你还在用 Docker 套件操作逻辑类似只是套件名称不同。你还需要开启 SSH控制面板 - 终端机和 SNMP - 启用 SSH 功能因为在命令行里操作远比自己点鼠标方便得多。硬件上x86 的群晖基本没压力Arm 的要看具体型号。Octopus 本体加上数据库和 Nginx内存占用大概在 300MB 到 500MB 之间存储占用除了初始镜像约 1GB 多主要是日志会慢慢增长。如果你用的是 2GB 内存的入门款只要不在同一时间跑太多容器也是能跑的。我习惯把目录规划好再开始建容器。建议目录结构/volume1/docker/octopus/ ├── config/ # 配置文件目录 ├── data/ # 数据库文件、数据持久化 └── logs/ # 运行日志提前建目录的目的很简单容器一旦跑起来文件写入就落在这些固定路径上后面升级容器、备份数据都非常省事。不要把数据写在容器内部否则容器一删所有配置和账单记录全没了。3.2 docker-compose 配置详解下面是我的docker-compose.yml经过大半年的使用验证已经非常稳定。你复制过去改一下端口和路径就行。services: octopus: image: octopus-gateway/octopus:latest container_name: octopus restart: unless-stopped ports: - 18000:8000 environment: - TZAsia/Shanghai - OCTOPUS_ADMIN_USERNAMEadmin - OCTOPUS_ADMIN_PASSWORD请改成高强度密码 - OCTOPUS_DATA_DIR/app/data - OCTOPUS_LOG_LEVELinfo volumes: - /volume1/docker/octopus/config:/app/config - /volume1/docker/octopus/data:/app/data - /volume1/docker/octopus/logs:/app/logs healthcheck: test: [CMD, curl, -f, http://localhost:8000/api/health] interval: 30s timeout: 10s retries: 3这里有个细节要说明宿主机端口我映射成18000而不是直接占用的8000。原因很实际——NAS 上跑的容器、套件不少8000是很多 Web 服务的默认端口冲突概率极大。映射成18000之后后端服务的地址就是http://NAS的IP:18000一眼就能认出是 Octopus。healthcheck也是我后来加的。之前遇到过容器假死、端口还能通但请求全部超时的情况没有健康检查就没法及时发现加了之后配合 watchtower 这类工具可以自动重启异常容器。3.3 初始化与访问管理后台SSH 登录到 NAS进入 Octopus 目录执行docker compose up -d第一次拉取镜像可能需要一点时间取决于你的 NAS 网络情况。完成后用docker compose logs -f octopus看日志看到类似“Octopus has started successfully”的字样就说明起来了。浏览器访问http://NAS的IP:18000第一次打开会让你设置管理员账号。到这里你其实已经完成了整个部署过程中最难的 80%。Octopus 的界面设计得比较简单左侧导航主要是模型管理、渠道管理、令牌管理、日志和统计。我建议初始化后第一件事是去“设置”里改一下管理员密码并关闭注册入口避免局域网上其他设备直接访问进来改配置。3.4 接入第一个真实模型供应商DeepSeek部署起来之后真正要紧的是把模型供应商接进来。我拿 DeepSeek 举例因为它的 API 风格简单明了。在管理后台选择“添加供应商”需要填的核心信息包括供应商类型DeepSeekAPI Base URLhttps://api.deepseek.comAPI Key你在 DeepSeek 开放平台创建的 Key支持的模型列表至少要填deepseek-chat和deepseek-reasoner这两个逗号分隔填完保存Octopus 会自动做一次连通性测试请求一下模型列表接口确认 Key 有效。如果失败界面会直接提示错误信息多数情况是 Key 抄漏了字符或者是 Base URL 多写了一个/。接着再接入其他厂商。智谱的 Base URL 是https://open.bigmodel.cn/api/paas/v4模型名一般是glm-4、glm-4-flash这类阿里通义千问的 OpenAI 兼容入口是https://dashscope.aliyuncs.com/compatible-mode/v1。每家 Base URL 的差异其实是最容易踩坑的地方我的建议是添加供应商之前先去它的官网文档页搜“OpenAI compatible”以文档为准别凭记忆写。最后把不同渠道的模型归到“统一模型池”里比如 DeepSeek 的deepseek-chat和智谱的glm-4-flash都挂在一个分组下前端就能用一个逻辑名称调用它们由网关根据路由规则自动选择。4. 把应用接到统一网关改造与测试全流程4.1 一个 curl 测试打通全链路先把最底层的验证做了。在 NAS 上执行curl http://127.0.0.1:18000/v1/chat/completions \ -H Authorization: Bearer 你的统一访问令牌 \ -H Content-Type: application/json \ -d { model: deepseek-chat, messages: [{role: user, content: 你好}], stream: false }这里的“统一访问令牌”不是厂商 Key而是你通过 Octopus 界面生成的、只属于你这个网关的令牌。看到正常返回一段文本就说明全链路已经打通客户端 - Octopus - DeepSeek - Octopus - 客户端。这也是 Octopus 这类网关的核心价值之一你的应用完全不用知道“上游是 DeepSeek”只要 Octopus 支持这个模型名并且你的令牌有权限调用它应用就能正常工作。以后即使你想把主通道从 DeepSeek 换成别的厂商前端一行代码都不用改后台改一下路由优先级就行。4.2 主流客户端接入示例接下来说说把客户端接过来的实际过程。以 NextChatChatGPT-Next-Web为例在系统设置里把“接口地址”改为http://NAS的IP:18000/v1填入你从 Octopus 生成的令牌保存即可。模型列表会自动从网关拉取你在界面里就能看到 Octopus 上挂了哪些模型。LobeChat、Cherry Studio 的逻辑几乎一样找“自定义 OpenAI 兼容接口”的地方填上同样的地址和令牌即可。唯一要注意的是某些客户端会自带上千个模型预设接入网关之后反而显得乱建议在 Octopus 后台把“模型可见性”整理一下只暴露你自己常用的那几款。Python 脚本客户端也不复杂把 OpenAI SDK 的 base_url 切过来就行from openai import OpenAI client OpenAI( api_key你的统一访问令牌, base_urlhttp://NAS的IP:18000/v1 ) resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 你好}] ) print(resp.choices[0].message.content)我自己的经验是改完 base_url 之后最好在客户端设置里把连接超时时间适当调大一点默认 10 秒有时候不够。因为网关转发请求给上游需要额外时间尤其是 DeepSeek 的推理模型响应可能十几秒才回来超时设置太短容易误判为失败。4.3 流式输出与超时那些事流式输出SSE是我一开始忽略、后来被它折腾过的重点。如果你在客户端开了流式对话效果但只收到整段结果或者一直转圈不用怀疑十有八九是中间某层把响应缓冲住了。我自己遇到过的问题是这样的优先生成模式下 Octopus 本身是支持流式响应的请求到网关后网关向 DeepSeek 打的是流式请求再把每个 chunk 转给客户端。理论上没问题但我当时为了让局域网外的设备也能访问在 NAS 的反向代理服务里加了一条转发规则结果所有流式响应都被 Web 服务器缓冲了客户端要等整个输出完成才拿到内容体验非常糟。解决办法是给对应的反向代理入口关闭响应缓冲。以 Nginx 系为例需要加proxy_buffering off;和proxy_cache off;两条配置如果用群晖自带的反向代理也有类似的“关缓冲”选项。如果你只是局域网内使用不经过反代那基本不用管这问题。5. 运维实用手册日志、安全、备份与常见问题5.1 用量统计与成本控制Octopus 会记录每一次请求的详细日志包括时间、模型、令牌、token 消耗、耗时。我装修完界面后最常用的页面其实是“统计”里面按图表展示每日请求量、Token 消耗、延迟趋势。它不能像商业 SaaS 那样精确到小数点后几位的金额但估算每月成本、找出某个疯狂消耗 token 的应用完全够用。成本控制上我还发现一个实用功能可以对不同令牌设置额度上限。我媳妇偶尔会用 NextChat 玩 AI我给她开了一个独立令牌额度设成每月 10 万 token用完了她在界面上就会看到余额不足不会影响我自己的主令牌。对多人共用一个 NAS 网关的玩家来说这个功能比什么花哨的限速都重要。5.2 安全加固要点接下来要说的这段虽然放在运维章节但我建议你部署完第一时间看。Octopus 管理后台里保存着多家厂商的 Key如果把后台暴露到公网且密码又弱基本等于把家门的钥匙挂在了门把手上。我的安全策略很简单第一NAS 本机防火墙只允许局域网 IP 访问 18000 端口外网一律不通第二管理后台密码用 20 位以上随机密码关掉任何形式的注册入口第三应用访问只走单独生成的令牌不给任何程序和管理员同一个 Key。如果你确实需要外网访问比如在公司或者手机流量环境也要用我建议通过 NAS 官方的安全隧道功能或者搭建在 HTTPS 后面的反向代理来访问但前提是你对公网安全有充分的把握。反正我的建议是能用局域网就尽量不暴露公网自托管图的是稳定可控不是给自己添堵。5.3 常见问题速查表我把自己和几个朋友实际踩过的坑整理成了表格按“现象-原因-解决”的思路列出来方便你对照排查。现象原因解决办法容器启动后马上退出数据卷权限不对Octopus 无法写文件检查目录属主用chmod或chown调整权限管理后台能进但测试模型失败厂商 Base URL 写错或 Key 无效去官方文档核对 OpenAI 兼容地址重新复制 Key客户端请求超时网关转发的总耗时超过客户端设置调大客户端超时时间或检查 NAS 到上游厂商的网络流式输出卡住反向代理缓冲了 SSE 响应关闭 Nginx 的 proxy_buffering日志增长把磁盘塞满默认日志保留策略太宽松定期清理 logs 目录或用 logrotate 按天切割ARM 机型拉取镜像失败镜像名没有对应架构确认使用的是支持 multi-arch 的镜像或在官方文档找 ARM 分支上游 429 限流但网关一直重试重试策略过于激进配置合理的重试次数和退避间隔比如最多 2 次、间隔 2 秒5.4 备份与升级自托管服务最怕的就是“容器一删全部归零”。升级之前一定先把config、data、logs三个目录整体打包备份到 NAS 的另一个位置或者干脆上传到对象存储。升级动作本身很简单cd /volume1/docker/octopus docker compose pull docker compose up -dOctopus 新版本迭代不算频繁但偶尔会有配置结构变化。升级完第一次启动如果报配置解析错误别慌看日志里具体报错字段看一眼官方升级文档就能解决。如果你不急着用新功能其实可以滞后几个版本再升稳定优先。6. 一点真实折腾心得最后说几句掏心窝的话。从我在群里看到别人喊“XX 厂商又出问题了我的应用全挂了”再到现在家里所有 AI 应用都走 Octopus 这一个出口最大的改变不是省了多少配置时间而是我终于有底气在客户端里同时挂十几个模型并且完全不担心某个厂商偶尔抽风。我自己的一个使用习惯是把所有常用模型按场景分好组。聊天问答用一个组长文档处理用另一个组代码补全单独走一个组。Octopus 允许对每个组分别设置主备和权重这样前端应用只需要选逻辑模型后端怎么安排资源基本不用管。另一个想强调的事是不要一上来就追求大而全。如果你手里只有一个模型 Key那 Octopus 的价值没那么明显但只要你手里有第二个、第三个或者在多人之间共享模型那统一网关就是刚需。先把最小闭环跑通再慢慢加模型、加规则这才是自托管该有的节奏。这套东西在我 NAS 上已经稳定跑了半年多中间经历了三次升级、无数次的模型切换从来没有一次让我的客户端长时间不可用——这就是我觉得它值得折腾的根本原因。
