1. 先看看那张越叠越高的 AI 会员账单开源共享模式真正的起点前阵子我跟朋友聊天他说家里三个人在用不同的 AI 助手AI 编程助手、AI 写作工具、AI 对话聊天每个都是按月订阅一个月加起来快赶上几顿火锅钱了。其实这个场景特别普遍家里一人一个账号模型能力还各自割裂。爸妈要的是能帮忙查菜谱、写个朋友圈文案的助手伴侣要的是能处理工作文档、整理会议纪要的助手孩子可能偶尔需要问几道数学题。每个人都在重复买“差不多能力”的对话服务钱包倒是先受不了。所以当我看到腾讯开源的那个 3.6K 星标项目时第一反应不是“又多了一个开源项目”而是“终于有人把‘全家共享’这件事做成平台了”。这类项目最大的价值在于一套部署全家使用。你不用再给每个人单独开通会员、单独管理 API Key而是把模型服务统一架在家里或服务器上所有家庭成员通过浏览器或者手机就能访问。这篇内容我来拆几个层面为什么开源共享比每人订阅更合理一个可用的共享平台由哪些部分组成怎么在局域网里完整跑起来以及真正多人使用之后你才会遇到的那些坑。适合的人包括想给家里搭一个统一 AI 入口的技术爱好者、小团队里负责内部工具选型的工程师、以及单纯不想再给一堆 AI 订阅重复付费的普通用户。先说清楚一个认知开源共享平台不等于零成本。你省下的是“每个用户一份订阅”的重复开销但付出的是一次性的部署和持续的维护精力。这个交换值不值取决于你到底有多少人、用得多频繁。看完这篇文章你可以自己判断。2. 共享平台拆开看模型、网关、前端三层各管什么很多人一听到“自建 AI 助手平台”就以为是一个大而全的软件其实不是。真正靠谱的架构是松耦合的三层模型层、网关层、前端层。三层各干各的组合在一起才是完整的“全家共享平台”。2.1 模型层能力的来源不一定要本地跑模型层负责最核心的智能推理。这里有两个选择一是部署本地开源模型比如通过 Ollama、vLLM 跑 Qwen、Llama 这类权重开放的模型二是接入云端的模型 API比如 OpenAI、智谱、通义等各家服务。共享平台的好处是两者可以混用——日常问答走本地模型遇到难题再走云端大模型。我的建议是不管你有没有 GPU先保留一个云端 API 入口作为兜底。原因很简单本地模型在长文本理解、复杂推理上和顶级商用大模型之间还有差距。家庭共享场景里总有家人会提出一些“超纲”问题没有兜底方案会显得平台很弱。2.2 网关层共享成败的关键最容易被忽略网关层是整个平台的中枢干的事包括统一管理各模型的 API Key、控制每个用户能访问哪些模型、限制请求频率、做 token 计费统计。你可以把它理解成食堂里的取餐窗口——菜是后厨模型层做的但每个人能拿多少菜、能不能吃特定菜品都由窗口把关。没有网关层会怎样要么你把真正的云端 API Key 直接暴露给家里人一旦泄露就等于被人盗刷要么本地模型被某一个人无限调用GPU 被占满别人全卡住。所以网关层不是锦上添花是刚需。常用开源方案有 LiteLLM Gateway、One API 等。我实际用下来更倾向 LiteLLM因为它的模型路由能力更强而且原生支持 OpenAI 兼容协议后面接什么都方便。One API 的界面更直观适合不想写配置的人。两者二选一就行。2.3 前端层家人真正面对的东西前端让使用者不用关心底层的模型怎么切换、网关怎么配置打开页面就能直接聊天。开源方案里 Open WebUI 是我见过最成熟的一个支持多用户注册、会话隔离、文件上传、联网搜索插件而且原生长得就挺现代家里人上手没什么心理障碍。这三层之间的关系用一个生活类比更好理解模型层是后厨的大厨网关层是点菜系统前端层是餐桌。普通用户坐在餐桌前负责吃就行但你要保证点菜系统稳定、后厨不崩整个餐厅才能正常运转。选型参考我也整理成表格方便对照层级可选开源方案核心职责容易踩的坑模型层Ollama、vLLM、外部 API提供推理能力本地模型对显存要求比想象高网关层LiteLLM Gateway、One API密钥管理、配额、路由配置格式写错会导致全部接口不可用前端层Open WebUI、NextChat用户界面、多用户会话忘记设置用户角色导致权限过大3. 局域网实战部署让全家都能打开同一个 AI 助手这一节我把整个部署流程走一遍。先说硬件条件一台装了 Docker 的机器就行可以是家里的旧电脑、小主机也可以是一台云服务器。如果单纯想先体验用云服务器反而更快因为不需要处理内网穿透的问题。家庭局域网部署适合对隐私要求高、不想把数据放到云端的人。3.1 部署前的基础准备机器上先装好 Docker 和 Docker Compose 插件。我假设你已经装好了没装的话可以去各自官网按引导安装。网络层面建议给这台机器设置固定 IP比如 192.168.1.100方便家人每天用同一个地址访问。还要确定一件事要不要走 HTTPS。局域网内部使用HTTP 够用但如果想到外网访问必须加 HTTPS。我后面会单独讲 HTTPS 这里的一个坑。3.2 先启动本地模型服务确认推理能力正常# 安装 Ollama以 Linux 为例 curl -fsSL https://ollama.com/install.sh | sh # 拉取一个主流模型比如 Qwen2.5 7B ollama pull qwen2.5:7b # 启动服务默认端口 11434 ollama serve这样模型层就起来了。你可以先单独测一下接口是否正常curl http://localhost:11434/api/generate \ -d {model: qwen2.5:7b, prompt: 你好}这一步的目的不是跑通流程而是确认硬件能不能扛住。7B 模型大概需要 8GB 内存或 6GB 显存我和所有用 4GB 显卡试过的人一样一开始就觉得“小模型够用”实际一跑又慢又卡。如果你家的机器配置一般建议模型序列里只放 7B 及以下或者干脆走云端 API。3.3 配置网关层统一所有模型的入口我用 LiteLLM 做示例创建一个配置文件config.yamlmodel_list: - model_name: local-qwen litellm_params: model: ollama/qwen2.5:7b api_base: http://host.docker.internal:11434 - model_name: cloud-gpt litellm_params: model: openai/gpt-4o-mini api_key: sk-xxx general_settings: master_key: sk-my-master-key这里把本地模型和云端模型统一成一个入口。model_name是给上层前端看的逻辑名字真实请求走哪个后端由网关解析。master_key一定改成你自己的强密码别用默认配置。启动网关服务docker run -d \ --name litellm-gateway \ -p 4000:4000 \ -v $(pwd)/config.yaml:/app/config.yaml \ ghcr.io/berriai/litellm:main-latest \ --config /app/config.yaml为什么需要统一入口因为家庭共享场景里前端页面不希望关心“谁在调用哪个模型”它只需要拿着一个 Key向一个固定地址发请求剩下的模型选择和负载均衡全部交给网关。这个抽象层做得好后面的配额管理才有地方下手。3.4 部署前端让家人有一个友好的聊天页面Open WebUI 官方推荐用 Docker Compose 部署。最简配置长这样version: 3.8 services: open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui ports: - 3000:8080 environment: - OPENAI_API_BASE_URLhttp://litellm-gateway:4000/v1 - OPENAI_API_KEYsk-my-master-key - WEBUI_SECRET_KEYplease-change-me - ENABLE_SIGNUPtrue volumes: - open-webui-data:/app/backend/data extra_hosts: - host.docker.internal:host-gateway volumes: open-webui-data:这里有个关键点OPENAI_API_BASE_URL指向网关而不是直接指向 Ollama。这是整个共享架构最重要的连接动作。前端只需要认识 OpenAI 兼容协议网关负责把它翻译成 Ollama 或者其它后端能懂的请求。启动docker compose up -d浏览器访问http://机器IP:3000注册第一个账号这个账号默认是管理员。然后在后台“设置 - 模型”里面确认能看到local-qwen和cloud-gpt两个模型。3.5 家庭成员如何接入家人使用不需要任何安装只要手机或电脑和主机在同一个局域网打开浏览器输入http://192.168.1.100:3000就能注册使用。如果有一些设备访问不了局域网可以用反代工具把服务安全暴露出去但这就涉及到内网穿透的话题我建议先做内网访问稳定了再扩展。4. 部署完不等于好用多用户隔离、配额与成本核算怎么做平台能访问了家庭成员的账号也注册了这时候最容易忽略的问题才开始显现。一个人用的时候一切正常三个人同时用问题全冒出来。主要原因在于共享平台天然存在“公共资源”和“个人需求”之间的冲突。4.1 多用户隔离先解决“会话串号”Open WebUI 本身是有账号体系的每个人注册一个账号会话彼此隔离这个没问题。容易出问题的是你额外接入的一些组件比如如果自己写了一个代理脚本把所有人的请求都合在一个 Key 里发出去那前端看到的会话就可能乱掉。所以我特别提醒一句不要让多个用户共用一个网关 Key至少要做到每个用户一个 Key或者干脆信任前端的多用户隔离机制让 Open WebUI 用自己的服务账号去调网关。如果 Open WebUI 里所有人共用同一个后端 Key日志统计会完全失真——你根本分不清到底是谁在调用大模型。这也是为什么网关层的密钥管理如此重要。4.2 配额管理保护家庭共享资源不被某个成员占满家里最容易出现的情况是某个人对着模型连续聊几个小时或者有人拿它批量跑文本任务把 GPU 占满别人发一条消息等五分钟。所以必须给每个用户设置限额。LiteLLM 支持在配置里设置速率限制router_settings: routing_strategy: usage-based-routing-v2 model_groups: default_group: - local-qwen user_config: - user_email: dadhome.local max_parallel_requests: 1 rpm_limit: 30 models: [local-qwen] - user_email: kidhome.local models: [local-qwen]这样不同用户可以绑定不同的模型范围和调用频率。孩子账号默认只能用本地模型不会误触发云端 API 产生费用大人的账号有更高权限可以在本地模型不够用时自动路由到云端模型。4.3 成本核算本地部署和云端 API 怎么算账很多人以为本地部署零成本实际账要算清楚。以一台普通家用小主机、日常 7B 模型为例一个月电费几十块几乎可以忽略但如果你跑的是 70B 级别的大模型满载功耗顶一台小型空调月份账单可能上百。另外还得算上硬件折旧。云端 API 的费用更直接每次请求按 token 计费。家庭日常使用如果一天几百条消息一个月几十块到几百块不等。这也是为什么“先本地、后云端”是更符合家庭场景的策略。使用模式主要成本适合场景纯本地模型电费 硬件折旧隐私敏感、日均调用量大纯云端 APItoken 费用想要大模型能力但不想维护硬件本地为主 云端兜底少量 token 费用大多数家庭推荐5. 家庭共享实测四个典型故障的完整排查链路部署完不是结束真正麻烦的是日常使用中的故障排查。我把自己实测和帮朋友排查中遇到的四个典型问题记录下来每个都不是直接说答案而是把排查链路走一遍。5.1 症状一手机连不上电脑却能访问排查链路先看手机和电脑是不是在同一网段。很多家庭路由器开了“访客网络”或者“AP 隔离”手机虽然连了同一个 WiFi但实际和设备不在同一个局域网导致访问被切断。解决方法是在路由器后台关闭 AP 隔离或者让所有设备连主网络。这个坑不在服务器端很大概率在网络拓扑。5.2 症状二连续问两句之后开始转圈提示超时先用docker stats看容器 CPU 和内存占用再用nvidia-smi如果有 GPU看显存占用。通常会发现模型推理进程把显存占满了新请求排队等待。这是 Ollama 的默认行为它会尽量把模型常驻显存提升响应速度。解决方法是限制最大并发数或者减小模型规模。在 Ollama 中没法直接限制并发我用的办法是前端的并发控制。Open WebUI 环境变量里有一个关键参数MAX_TOKENS2048另外如果家庭成员数量固定为三四人可以接受一个请求排队结束再处理下一个这反而比强行并发更稳定。5.3 症状三A 因为粗心把 API Key 暴露在日志里怎么办这个问题的根源通常不是 Open WebUI而是家人可能在接入第三方工具时把网关 Key 填错了地方。排查方式是去网关日志里查最近请求来源找到调用频率异常的地址直接吊销对应的 Key 重新生成。所以前面强调的“每人独立 Key”这时候就体现出价值了。吊销一个 Key 不影响其他人最多让他重新配置一次。如果不区分 Key一旦泄露你就只能换主 Key全家都要重弄一遍。5.4 症状四手机浏览器能打开页面但语音输入不可用主要原因大多是浏览器安全限制。局域网使用 HTTP 协议时某些浏览器会禁用麦克风等敏感 API。解决方式是给服务加上自签名 HTTPS 证书或者在受支持的浏览器开启“不安全来源”访问权限。给家庭用户的最好方案是浏览器配置里允许安全来源或者用支持 HTTP 语音的浏览器。这属于小概率但很影响体验的坑知道解法就行。6. 开源共享和省钱之外什么情况下仍然要买商业订阅说到这我必须泼一盆冷水不是所有家庭/团队都应该彻底放弃商业订阅。自托管共享平台确实能把“人人都买会员”变成“一家人共用一个服务”但它不是万能的。6.1 商业订阅仍有优势的场景如果你追求的是最强模型能力比如最新一代的推理模型、长上下文、多模态能力开源自建方案很难同步覆盖。开源模型落后于商用顶级模型大概半年到一年这个差距在快速迭代的领域会被放大。另外如果你完全不想维护服务器家里没有一个 Linux 爱好者那出一次故障全家都用不了这种体验比付费订阅差得多。6.2 我的建议混合模式最实用就我自己目前的用法平台是开源自托管的但模型层混用了两个来源本地跑一个 7B 模型处理日常问答云端 API 走的是按量付费通道处理文档总结和高难度问题。这样既保住了家庭共享的好处也保留了商业模型的顶尖能力。关键是控制云端 API 的权限只有管理员账号的网关 Key 能访问云端模型其他家庭成员默认只用本地模型。想升级权限了再给费用和风险都可控。6.3 最后分享两个小技巧一是网关的日志一定要开并且定期瞄一眼。它能告诉你每一个家庭成员的实际使用频率、调用了哪些模型、消耗了多少 token。有了数据之后你才能决定本地模型要不要换更大的、云端 API 配额给谁涨。二是如果家里有孩子建议把网关里的云端模型彻底设为仅管理员可用免得孩子误触发收费模型。从“每人买一份会员”到“全家共用一个平台”差别不只是钱更是对 AI 资源的一种理性管理。腾讯开源的那个 3.6K 星标项目给了所有人一个好的起点但真正让全家都用得舒服的还是你愿意为它搭好的那套服务结构。