先给你算一笔账一个普通AI助手订阅一个月差不多30块钱一家三口各订各的一年下来就是一千多。钱花了还不算聊天记录各存各的、额度各算各的、你用你的我用我的互相之间完全隔离孩子想用还得专门给ta开一个账号。看到这个标题的时候我第一反应是腾讯把这件事做成了开源项目——3.6K星标核心思路是把AI助手变成全家共用的一个平台而不是人手一份付费账号。这个项目能解决的问题其实很直接你只需要在一台小主机或云服务器上部署一套服务家里所有人都通过同一个入口访问后端可以接多个大模型每个家庭成员有独立账号和独立配额管理员还能统一控制费用。适合想把AI工具成本打下来、又不想牺牲数据隐私的家庭用户也适合小团队内部共用一套AI能力甚至适合想学习自托管AI平台是怎么运作的技术爱好者。1. 项目定位与核心思路拆解1.1 解决的真正痛点重复订阅、信息孤岛、数据外流很多人没意识到把AI助手当成“一个会员”来买其实是陷入了一种惯性思维。AI订阅本质上买的是模型调用能力而不是“一个账号只能给一个人用”的身份认证。只是商业化产品为了收入强行把模型能力绑死在账号体系里这才导致全家各买各的、公司里每人一张卡。这个开源平台最核心的设计就是把“模型能力”和“使用账号”拆开。平台本身不提供模型它负责做一件事——把大模型的API密钥统一管理起来然后通过自己的账号体系分发给家庭或团队里的每个人。底层可以接OpenAI兼容接口、国内各家大模型API、本地部署的开源模型甚至同时接多个按规则分流。拆开之后之前那些痛点当场消失。成本上一份模型API密钥全家共用按用量计费不会出现“三个人买三份会员”这种浪费。数据上所有对话记录都存在你自己的服务器里不经过任何第三方平台聊天记录不会再被某个厂商拿去做训练。管理上孩子用哪个模型、老人每月能用多少额度、哪些人只能读不能导出管理员在后台上看得清清楚楚。1.2 为什么选腾讯开源的方案而不直接用在线服务我刚开始也纠结过既然有那么多现成的在线AI服务为什么还要自己部署一套直接买会员不香吗实际操作下来自托管这个选择带来的自由度是任何在线服务都给不了的。第一认证与网关完全自主可控。在线平台的账号体系掌握在别人手里说封就封说限流就限流。而自托管平台上账号是你自己建的规则是你自己定的模型密钥也是你自己管的。它不是“租别人的服务”更像“在自己家里装了一台AI路由器”。第二3.6K星标代表的是社区验证。开源项目最怕的就是作者跑路、没人维护。这个项目挂在腾讯名下社区活跃度不低Issues响应也快遇到问题能翻到真实用户踩坑的记录而不是对着官方客服工单干瞪眼。对我这种喜欢折腾的人来说这种“背后有人、社区活跃”的确定性很重要。第三它没有把模型锁定死。今天你觉得这个模型好用就接这个明天觉得那个模型便宜就换那个甚至同一套系统里跑两三个模型做对比。这种“模型自由”在商业订阅里想都别想但在开源平台上是基本操作。1.3 平台的三个组成部分网关、前端、用户中心我第一次用这类平台时容易把它理解成一个“聊天网站”其实它是三个模块的合体。网关层负责统一接收所有请求校验用户身份识别用户当前用的模型是哪个然后把请求转发给对应的模型API再把结果回传。前端是大家能看到的Web对话界面本质上就是一个浏览器里跑的聊天应用支持多会话、流式输出、停止生成这类基础操作。用户中心负责账号、分组、配额、额度管理管理员在这里创建家庭成员账号、设置每月可用Token上限、查看每人的调用记录。打个比方这三者合起来就像一个家庭版的AI服务平台——网关是门卫前端是客厅用户中心是物业管理处。门卫认人客厅接待物业登记和管控。我部署的时候心里装着这个模型图后面配置每一项功能时就很清楚它属于哪一层出了问题也知道去哪个模块排查。2. 部署环境与核心配置详解2.1 一套家用级的硬件配置就够跑很多人一听“部署平台”第一反应是“得买服务器”“要搞GPU”其实完全不是。这个项目的定位是轻量级代理和前端服务主要消耗资源的不是它本身而是它调用的模型。如果全部用云API不跑本地模型一台N100小主机、8G内存、20G硬盘就非常宽裕。跑本地大模型是另一回事那需要GPU。但如果只是想解决“全家共享AI助手”这件事我个人建议先别急着上本地模型用云API跑一个月的成本通常远低于折腾显卡和显存。以下是部署的硬件参考配置部署方式CPU/内存硬盘模型来源适用场景轻量级家用小主机2核 / 4G以上20G云API日常对话、家人共用标准型旧电脑/NAS4核 / 8G以上50G云API 本地小模型追求隐私、偶尔离线重负载带GPU4核 / 16G以上 / 独立显卡100G本地大模型完全离线、重度使用我自己的部署环境就是一台吃灰的N100小主机装了Debian后用Docker跑起来稳得很。如果你有NAS直接在那上面跑也可以只要支持Docker就行。如果这两样都没有买台云服务器也是一条路选最便宜的1核2G都跑得动毕竟真正的计算发生在模型厂商那边。2.2 安装流程Docker Compose一键编排官方推荐的方式基本就是Docker Compose我按这个方式部署了好几遍流程很成熟。网上搜这个项目的部署文档大致是这个结构几个服务通过docker-compose.yml编排在一起启动后相关服务各自干活整体占用的内存很小。先把项目代码或者配置目录准备好我的习惯是放在/opt/ai-gateway下面mkdir -p /opt/ai-gateway cd /opt/ai-gateway然后创建一个docker-compose.yml主要内容大致长这样不同版本、不同子项目的服务名有差异以实际拉取的镜像名为准version: 3.8 services: web: image: your-registry/ai-platform-web:latest ports: - 3000:3000 environment: - API_BASE_URLhttp://api:8080 depends_on: - api api: image: your-registry/ai-platform-api:latest ports: - 8080:8080 environment: - DATABASE_URLpostgresql://user:passworddb:5432/ai_platform - REDIS_URLredis://redis:6379 depends_on: - db - redis db: image: postgres:16-alpine environment: - POSTGRES_USERuser - POSTGRES_PASSWORDchange_me - POSTGRES_DBai_platform volumes: - db_data:/var/lib/postgresql/data redis: image: redis:7-alpine volumes: - redis_data:/data volumes: db_data: redis_data:写好之后直接启动docker compose up -d docker compose ps首次启动会拉取镜像耐心等一会儿。看到所有服务都是running状态没有异常重启就可以打开浏览器访问http://你的服务器IP:3000进入初始化页面。第一次进去会让你创建管理员账号这个账号就是整个平台的管理员后面所有家庭成员、配额、模型渠道都由它来管。2.3 模型接入配置云API和本地模型混着用平台安装好之后真正让它“能用”的关键一步是接入模型。这个项目支持多种模型提供商但绝大多数都兼容OpenAI的接口协议所以配置思路都是一致的。在管理后台找到“渠道 Channel”或“模型提供商”的入口新建一个渠道核心参数如下配置项说明填写示例名称渠道的备注名阿里云百炼 / OpenAI / 本地Ollama类型模型接口类型OpenAI / Anthropic / OllamaBaseURLAPI请求地址https://api.openai.com/v1密钥模型厂商分配的API Keysk-xxxxx模型名称列表该渠道可用的模型gpt-4o-mini,qwen-plus分组渠道归属的组家庭版云API的配置相对直观填好密钥和BaseURL就能用。真正容易踩坑的是本地模型的接入。如果你在服务器上用Ollama跑了一个本地模型平台在Docker容器里是访问不到宿主机上的localhost的这里必须填对地址。Linux环境下通常需要额外配置容器的extra_hosts把host.docker.internal解析到宿主机IP然后在配置里填BaseURL: http://host.docker.internal:11434/v1填完以后在模型列表里加上你本地Ollama已下载的模型名称比如qwen2.5:7b保存后到对话页面选这个模型试一下。如果报连接超时先用curl http://localhost:11434/v1/models在宿主机上验证Ollama是否正常再回头看容器的网络配置。这几乎是我见过所有人第一次接本地模型时都会卡住的点。3. 实操核心用户体系、配额和访问控制3.1 家庭成员账号怎么建平台初始化完成之后默认只有一个管理员账号。要给家里人用就去用户管理页面逐个创建账号。在常见实现里创建时能设置用户名、初始密码、显示名、所属分组和角色角色一般分管理员和普通用户。家庭成员都用普通用户角色管理员权限不要下发。创建完账号后把地址和账号密码告诉对方就行。登录进去后每个人看到的是一个干净整洁的对话页面可以创建多个会话各个会话之间互不干扰聊天记录也按用户隔离。也就是说孩子问作业的记录不会跑到父母的会话列表里每个人的历史记录只有自己和管理员能看到。我在实际使用中会再花一步把每个用户的“默认模型”配置成不同的模型。家里长辈用的模型就配速度快的、语言通俗的自己用的就配推理能力强的孩子用的可以限制只能访问经过审核的模型并且在后台限制部分上下文能力。这种“千人千面”的配置在线公共账号完全做不到。3.2 配额与费用控制不再担心乱花钱自托管平台最大的好处之一是费用可控。云API是按token计费的如果家里有个“话痨”一个月能帮你烧掉不少预算。平台的用户配额功能就是干这个用的通常在用户编辑页面或者分组配置里能设置每日请求次数、Token上限、并发会话数。建议这样设以月为单位给每个用户设定一个合理的Token上限比如家庭日常使用50万Token。到这个量级之后平台会自动限制该用户的请求不产生额外费用。管理员可以在后台看到每个用户每天的调用曲线一旦发现某个人某天用量突然暴涨就去翻对话记录看看是不是在跑批量任务。还有个容易被忽略的点在渠道层面可以设置“模型限流”也就是同一个渠道同一时间最多处理多少个请求。如果不设这个假设你接了一个免费额度有限的模型家里人同时发消息可能瞬间就把额度刷爆。我在渠道配置里给免费模型加了并发限制给付费模型设置了按量预警这个习惯帮我避免了至少三次“月底账单吓人”的尴尬。3.3 局域网访问和远程访问怎么做部署好之后最简单的方式是局域网直接访问。家里的电脑、手机连同一个Wi-Fi在浏览器输入http://192.168.x.x:3000就能用。这个方式的优点是完全不出门数据只在家庭内网流转响应速度也最快。但如果人不在家或者家里有几处房子想用同一个服务就需要做远程访问。我的方案首选是把服务部署在云服务器上通过Nginx做反向代理加HTTPS。以下是Nginx配置的关键部分server { listen 443 ssl; server_name ai.example.com; ssl_certificate /etc/nginx/ssl/ai.example.com.crt; ssl_certificate_key /etc/nginx/ssl/ai.example.com.key; location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这里有个细节AI对话用到了WebSocket做流式输出如果反向代理没配Upgrade和Connection头页面能打开但对话迟迟不返回。这个问题我以前排查了整整一下午最后才发现就是少了两行配置。远程访问还有个前提是必须配HTTPS不然API Key和聊天内容等于在公网上裸奔。3.4 手机上当成App用很多家庭成员最关心的是手机上好不好用这个平台本身是个响应式Web页面手机浏览器直接访问就能用体验和电脑上差别不大。如果想让图标出现在手机桌面上像原生App一样点开就用可以用PWA功能。在浏览器里打开平台地址找到“添加到主屏幕”或“安装应用”选项系统会自动生成一个桌面图标。以后点开就是全屏的对话界面不需要在浏览器里找书签。实测下来这个方案比安装任何客户端都方便而且全家人用的都是同一个入口不会有“版本不一致”的问题。4. 常见问题与排查技巧实录4.1 页面打不开或响应慢页面打不开先别急着猜按这个顺序排查先看服务状态。docker compose ps docker compose logs -f --tail100 web如果web容器反复重启多半是环境变量里的API_BASE_URL写错了导致前端连不上后端。如果容器状态正常但浏览器访问不了检查一下端口监听和防火墙ss -tlnp | grep 3000如果端口没监听说明Web服务没起来如果监听了但外部访问不了优先检查云服务器的安全组和系统防火墙。响应慢的问题则先分清是首屏慢还是对话生成慢。首屏慢大概率是服务器带宽不足静态资源加载不出来对话生成慢那就要看模型API本身的响应时间以及平台有没有配置超时时间。生成对话卡住不动十有八九是WebSocket没走通去检查反向代理配置。4.2 本地模型连不上这个问题几乎每个尝试本地模型的人都会遇到。核心原因我在前面提过Docker容器里的localhost指的是容器自己不是宿主机。Linux环境下可以在docker-compose.yml里给API服务加上extra_hosts: - host.docker.internal:host-gateway然后重新启动docker compose down docker compose up -d接着在模型渠道配置里用http://host.docker.internal:11434/v1作为BaseURL模型名称填Ollama里实际存在的模型比如llama3.1:8b。如果还连不上在宿主机上用curl验证Ollama本身curl http://localhost:11434/v1/models返回JSON列表就是正常不返回则去检查Ollama服务和端口占用。4.3 升级与备份恢复这个平台的升级流程我建议按“备份—拉镜像—重启—验证”四步走。先备份数据库和配置再重启服务。用PostgreSQL的话备份一行命令docker compose exec db pg_dump -U user ai_platform backup.sql同时把.env和docker-compose.yml拷贝一份这些就是全部家底。确认备份成功后执行更新docker compose pull docker compose up -d更新完必须验证两件事管理员能正常登录、模型对话能正常生成。有些人更新完发现登录没问题但对话报错多半是新版本改动了数据库结构回滚或看迁移日志能解决。我自己的原则是小版本更新不追但积累了几个重要修复的版本一定要升安全和稳定优先于新功能。4.4 问题速查表现象可能原因解决办法页面打不开服务未启动 / 端口未放行docker compose ps检查状态对话一直转圈WebSocket反向代理没配好确认Nginx有Upgrade头模型返回401API Key错误 / 渠道密钥过期后台重新填入并测试本地模型连不上容器内无法访问宿主机配置 extra_hosts某用户突然无法对话配额用尽 / 账号被禁用后台查看该用户额度聊天记录丢失数据库卷被误删恢复之前备份别乱删volume生成速度极慢模型API限流 / 带宽不足换模型渠道或升级带宽升级后功能异常数据库迁移失败查看迁移日志回滚或修数据5. 实操中的体会与独家建议跑这套东西到现在我最深的感触是部署本身不难难的是把它真正融进一家人的日常使用里。技术上的坑可以通过文档和社区解决真正需要你自己花心思的是怎么定规则、怎么控制成本、怎么让不太懂技术的家庭成员也能顺畅使用。几个小建议算是实践沉淀下来的经验。第一账号权限一定要“最小化”。管理员账号只留给自己家里其他人一律普通用户。孩子拿着普通用户账号能正常对话但改不了模型配置、看不了其他人记录这就够了。给权限时想一想ta真的需要这个能力吗不需要就不给。第二API密钥千万不能出现在前端。所有模型密钥都只放在服务端配置前端对话页面只发“用户ID消息内容”不让浏览器直接接触任何模型厂商的密钥。我第一次部署完特地用浏览器开发者工具看了下网络请求确认没有密钥泄露才敢正式给家里人用。第三把配额当回事但别设得太紧。太紧会让家里人觉得“怎么用着用着就停了”太松又失了控制意义。我自己是先把默认配额设成“预估日常用量的两倍”跑一两周看后台统计再往回收。有了真实数据再调节比瞎猜舒服得多。第四同一个家庭里不用每个人都用同一个模型。给不同人配不同模型既是成本优化也是体验优化。我自己的账号接的是推理能力强的新模型长辈那边接的是响应快、语言通俗的模型孩子那边则限制了模型范围只能访问我审核过的那几个。一个平台两套体验很划算。这个项目让我省下的不只是订阅费还有管理AI工具的时间和心思。如果你家里、团队里也有类似的需求强烈建议找一台吃灰的小主机用Docker部署一套试试。从零到能用一个下午足够了从能用到全家都离不开也就是一周的事。
