腾讯开源AI共享平台：家庭部署指南，一次搭建全家用，省钱又私密

免费的东西不香香但很多人不敢用。外面那些AI助手一个月动辄几十上百块的订阅费一年下来一个人就是大几百家里三代人人手一份钱包是真的顶不住。直到我翻到腾讯开源的这个3.6K星标项目才发现“AI助手”这件事完全可以做成家庭共享的私有平台一次部署全家一起用不用为一个账号的并发限制头疼也不用为了孩子偶尔用一次再掏一份会员钱。这个项目本质是一个带多用户管理、多模型路由、知识库共享能力的AI助手网关平台能统一接云端大模型API也能接本地模型比如Ollama拉下来的开源模型。它跟普通“套壳客户端”最大的区别是解决了一个痛点如何让一个家庭或一个小团队共用一个AI能力中枢同时每个人保有自己的对话记录和配置互不打扰。这篇文章会把它背后的设计思路、部署步骤、模型接入和路由逻辑完整拆开适合正在寻找“全家共享AI方案”的人也适合小团队、实验室、社团这类非企业场景做统一AI服务出口。1. 核心需求解析为什么你需要的不是一个AI助手而是一个AI共享平台1.1 先算一笔账一个家庭每年在AI助手上要花多少钱目前市面上主流的AI助手订阅基本都在一个月20元到100元这个区间专业版或者带更强推理能力的套餐可能更贵。假如一家四口大人一个要处理工作文档和编程问题另一个要写材料和给孩子辅导功课两个孩子一个初中一个小学都需要查资料、整理错题、做英语对话练习。按每人每月30元的最保守档位来算一家四口一年就是1440元。如果其中有人需要更高级别的推理能力和更长的上下文单价翻倍甚至翻三倍都很正常一年花到3000元以上并不夸张。这笔钱花完之后体验还不一定好。一个人用的账号同时只能维持少量会话家里两个人同时问问题可能一个就要排队。家庭成员之间还会互相污染对话历史——爸爸查工作资料孩子接着问数学题AI的上下文里混着上一轮的工作内容回答质量和准确性都会受影响。1.2 家庭共享平台要解决的是“使用权”和“管理权”分离的问题如果只是图省钱可以全家登录同一个账号但那是用体验换钱。真正的解法是做一个共享平台让每个家庭成员有自己的身份、自己的对话空间、自己的历史记录底层统一走同一个模型池或者同一个API出口。这就引出了“使用权”和“管理权”分离的概念。家庭成员是使用者他们只感受到有一个好用、响应快、还能记住自己喜好的AI助手。管理员一般是家里懂技术的那个负责统一管理模型接入、额度分配、知识库更新和访问权限。腾讯开源的这类项目星标能到3.6K说明有同样需求的人不在少数。开源社区为什么愿意给星因为它解决了一个很普适的问题AI能力不应该按人头付费而应该按“服务能力”付费。1.3 和“套壳客户端”的核心区别在哪里市面上有很多AI客户端工具能让你在本地窗口里跟不同的大模型对话但它们大多只有单用户能力。如果家里三台电脑、两部手机都要用就要在每台设备上分别配置API Key、分别维护历史记录完全没有统一管理可言。而腾讯开源的这个项目属于“服务型”架构部署在一台常开的小主机或者云服务器上家庭成员通过浏览器访问同一个地址每个账号独立登录所有对话记录和知识库都集中在服务器端。你不需要在每个设备上重复配置手机上收藏一个网址电脑上存一个书签体验跟访问常用网站一样简单。这个“服务化”思路才是它跟普通客户端工具拉开差距的关键。它不把自己定位成“一个软件”而是“一个服务”服务覆盖全家人所以叫“全家共享平台”一点不为过。2. 整体设计思路与技术选型为什么可以做到一平台多用2.1 多用户体系家庭场景下的权限分配方案既然要共享底层必须有一层独立的用户体系。管理员账号拥有最高权限能创建子账号、分配模型访问权限、设置配额。普通家庭成员账号只有对话、查询知识库的权限无法修改系统参数。家庭场景下还有一个细节容易被忽略就是未成年人的内容管控。项目里支持给子账号设置启用时间段和可访问模型范围比如孩子的账号只能使用偏向教育的模型影视、娱乐相关的模型可以单独关闭。另外同一家庭里的账号之间默认相互隔离对话记录不可互看既保住了爸爸的工作信息也保住了孩子在AI面前的小秘密。从技术实现上看这套用户体系可以基于成熟的权限模型做核心就三张表用户表、角色表、角色权限表。管理员给普通用户绑定角色角色决定他能用哪些模型和功能。部署时双击一个脚本就能初始化管理员账号后面所有家庭成员账号都在管理后台创建不用碰数据库。2.2 模型路由如何让不同请求自动走向不同大模型这个平台最巧妙的设计是模型路由。管理员可以在后台配置多个模型包括云端大模型和本地模型然后按照一定的策略将请求分配给合适的模型。这里我举个例子。一家人的使用场景可能长这样爸爸写代码需要强大的代码理解和生成能力路由到云端专业模型妈妈写公文需要稳定的语句组织能力路由到通用大模型孩子问百科知识不需要太高级的推理直接走便宜的轻量模型或者本地模型深夜时段API高峰期自动切换到备用模型避免等待路由策略可以按用户维度设置也可以按对话的复杂程度动态判断。比如简单的“秦始皇哪一年统一六国”这类知识问答用便宜甚至免费的本地模型就够了。如果问题涉及多层逻辑推理再升级到更强模型。这个动态切换逻辑能显著降低整体API消耗实际用下来每月云端费用可以控制在个人订阅价的几分之一。2.3 本地模型接入断网还能用的家庭私有AI项目中本地模型接入走的是Ollama这类标准化运行时部署好之后本地模型被包装成一个和云端模型完全一致的标准API接口上层业务逻辑不需要关心请求到底去了哪里。本地模型的价值有两层。第一层是省钱像Qwen2.5 7B这类开源模型跑在32G内存的普通家用小主机上日常问答和资料整理完全够用不产生任何API费用。第二层是隐私家里的一些敏感信息比如医疗报告、财务数据、保险单据可以在本地模型里完成处理数据不出家庭网络这一点尤其吸引对隐私敏感的用户。当然本地模型也有局限复杂推理和长文本生成效果跟云端顶级大模型还有差距。这个平台没有把本地和云端对立起来而是让它们各司其职简单任务本地处理复杂任务才走云端成本、隐私、效果三者取得平衡。2.4 共享知识库把家庭资料变成AI的“长期记忆”项目里除了对话功能还有一个很吸引人的模块就是共享知识库。你可以把家庭常用资料传上去——比如孩子学校的校历和课程表、家里的常用菜谱、保险单扫描件的内容摘要、常用药品说明AI在回答问题时就能自动引用这些资料。知识库的技术原理不复杂本质上是先做文档解析和分块再用嵌入模型把文本块向量化存进向量数据库。用户提问时系统把问题转成向量在向量库里做相似度检索把最相关的文本块连同问题一起交给大模型生成回答。这个流程在项目里全部自动化了管理员只需在后台上传文档系统自动完成切分、向量化和索引构建。多个家庭成员可以通过共享知识库让AI“懂家事”。孩子问“妈妈这周末有空吗”AI可以结合共享日历和知识库里的安排给出合理答复这种体验是个人的独立订阅账号给不了的。3. 部署实操手把手把共享平台跑起来3.1 部署前需要准备的硬件和软件我实际跑这套平台用的是一台老旧的迷你主机16G内存4核CPU没有独立显卡。放客厅角落功耗不到30W每月电费十几块比给三个人买AI会员便宜太多。部署系统是Ubuntu 22.04 LTS安装好Docker和Docker Compose插件。为什么推荐Docker Compose而不是裸机安装因为这个项目涉及的组件比较多除了主程序还需要Redis做会话缓存、向量数据库存知识库、Nginx做反向代理。用Docker Compose可以一条命令拉起全部依赖升级的时候只替换一个镜像数据目录单独挂载出来备份也非常方便。如果家里没有常开的小主机也可以选一台轻量云服务器2核4G起步费用在每个月几十元以内。服务器部署的优势在于随时随地从外网访问手机在地铁上也能用缺点是需要额外考虑鉴权和防护。3.2 Docker Compose配置文件实战下面是一个我实际在用的docker-compose.yml简化版本保留了核心结构方便你理解它由哪几部分组成version: 3.8 services: app: image: your-registry/ai-hub:latest container_name: ai-hub restart: always ports: - 8080:80 environment: - DATABASE_URLpostgresql://aihub:aihubpostgres:5432/aihub - REDIS_URLredis://redis:6379/0 - VECTOR_DB_URLhttp://vector-db:8000 - JWT_SECRETchange-me-to-a-long-random-string - ADMIN_INIT_PASSWORDchange-me-strong-password depends_on: - postgres - redis - vector-db volumes: - ./data/uploads:/app/uploads - ./data/logs:/app/logs postgres: image: postgres:16-alpine container_name: ai-hub-postgres restart: always environment: - POSTGRES_USERaihub - POSTGRES_PASSWORDaihub - POSTGRES_DBaihub volumes: - ./data/postgres:/var/lib/postgresql/data redis: image: redis:7-alpine container_name: ai-hub-redis restart: always command: redis-server --appendonly yes volumes: - ./data/redis:/data vector-db: image: your-registry/vector-db:latest container_name: ai-hub-vector restart: always volumes: - ./data/vector:/data这个文件里几个值得注意的点。数据库用PostgreSQL存用户、对话记录和配置信息。Redis用来缓存会话状态和处理流式输出时的临时数据因为AI对话是流式的需要临时缓冲。向量数据库独立一个服务存知识库的embedding向量。启动之前记得把JWT_SECRET和管理员初始密码改成足够复杂的随机字符串。如果服务器暴露在公网JWT_SECRET泄露等于整个系统被接管。执行启动命令# 登录服务器或者进入小主机终端 cd ~/ai-hub docker compose up -d docker compose ps第一次启动会拉取镜像取决于网络环境可能需要几分钟。等所有容器状态变成healthy之后浏览器访问http://服务器IP:8080就能打开登录页。3.3 接入第一个云端模型以混元大模型为例平台后台有一个模型管理页面添加模型时需要填写三块核心信息模型名称、API地址、API Key还有一个可选的信息是模型类型比如是对话模型、Embedding模型还是多模态模型。以混元大模型为例在腾讯云控制台开通大模型服务后拿到API Key添加模型时填以下参数模型名称混元-proAPI地址https://api.hunyuan.cloud.tencent.com/v1/chat/completionsAPI Key控制台生成的密钥注意不同平台的API地址格式有差异有些兼容OpenAI格式有些是自定义格式。填完之后点保存系统会做一次连通性测试如果返回正常的模型响应说明接入成功。批量接多个模型时建议命名带上用途后缀比如“混元-pro-文档处理”“混元-lite-日常闲聊”“本地Qwen2.5-知识问答”这样后台日志里能清楚看到每次请求走了哪个模型排查问题时一目了然。3.4 接入本地模型Ollama安装与挂载本地模型的安装其实更简单。在部署平台的那台机器上装好Ollama然后拉取一个合适尺寸的模型# 安装Ollama后拉取Qwen2.5 7B ollama pull qwen2.5:7b # 确认运行 ollama list拉取完成后Ollama默认监听在本机的11434端口。在平台的模型管理页面再添加一个模型API地址填以下格式http://宿主机IP:11434/v1如果平台和Ollama在同一台物理机器上建议用Docker的host.docker.internal特殊域名来访问宿主机避免容器IP变动导致连接失败。Docker Compose里需要在app服务下加一行extra_hosts配置extra_hosts: - host.docker.internal:host-gateway配置好之后在模型路由策略里新建一条规则当知识库检索的相似度得分在0.7以上也就是能确定命中家庭知识库时直接走本地模型回答相似度低于0.7说明是开放性问题再升级到云端模型。这套规则配合下来我实际用了两周80%的日常问答都落在本地模型上云端API费用降低了一大截。3.5 创建家庭成员账号和配额管理员登录管理后台后在“用户管理”页面创建新的家庭成员账号手机号或者邮箱都可以作为登录名。每个账号创建时能设置可用模型范围该账号只能使用特定模型每日消息次数上限防止孩子无节制使用启用时段默认7×24小时也可以设置仅白天是否允许访问共享知识库我给家里每个人的配置策略是家庭成员可用模型每日上限时段知识库权限爸爸混元-pro、本地Qwen2.5200次全天可读写妈妈混元-pro、本地Qwen2.5200次全天可读写大孩子本地Qwen2.5、轻量云端100次8:00-22:00只读小孩子本地Qwen2.530次9:00-20:00只读这个表只是参考实际按家庭需要调节。配额限制尤其适合有在校孩子的家庭既能保证孩子正常使用AI学习又不会在家长不知情的时候把API额度刷爆。4. 核心环节实现解析一个Web请求是怎样被路由到合适模型的4.1 从聊天框到模型响应的完整链路理解了这个链路后续排查问题会轻松很多。一次普通对话在平台内部经历了七个阶段用户通过浏览器输入消息前端将消息以WebSocket或HTTP请求的方式发给后端后端先做身份鉴权确认用户token有效并检查该账号当日配额是否用完后端从Redis取该用户最近的会话历史打包成上下文如果是知识库增强模式先把当前问题转成向量检索向量数据库取回最相关的文本片段模型路由器根据预设策略从可用模型列表中选择目标模型后端将“系统提示词知识库片段会话历史当前问题”拼成请求发送给目标模型API模型返回流式响应后端一边转发给前端展示一边将完整回复存入数据库任一步骤出问题都能在后台日志中对应到具体环节。比如用户反映回答很空大概率是知识库检索没命中如果模型半天不出字基本是目标模型的API响应太慢。4.2 模型路由器的决策逻辑模型路由器是整个共享平台的调度核心。它从几个维度动态评估每一次请求应该交给哪个模型用户指定用户可以手动切模型这个优先级最高管理员的固定规则比如某些账号只能走某些模型请求复杂度系统内置一个轻量分类器对问题长度、关键词做快速判断可用性某个云端API如果最近连续失败自动降级到备用模型成本权重管理员可以为每个模型设定成本系数成本低的优先听起来复杂实际运行中管理员不需要关心细节后台的策略配置页面以可视化规则呈现。比如我可以添加一条规则“本地模型连续三次回答超时自动切换至混元-lite继续回答”。这个由管理员配置系统自动执行。4.3 上下文窗口管理怎么防止多轮对话“内存泄漏”大模型对话不能把所有历史消息无限塞进去这就涉及上下文窗口管理。7B模型通常只有8K到32K的上下文窗口越长的历史占用越多token消耗也越大。平台采用滑动窗口策略。每轮对话结束后系统会估算当前对话的token总量如果超过设定的阈值比如12K就把最早的一部分消息压缩成一段摘要然后用“摘要最近完整消息”继续后续对话。这个机制跟人脑记忆有点类似久远的细节只留一个梗概近期的信息完整保留。想要控制云端的token消耗建议在后台把“历史消息摘要阈值”设低一些比如8K。本地模型因为免费可以设高一些比如16K让本地模型记住更完整的上下文。4.4 流式输出与并发控制现在的AI API都支持SSE流式输出也就是模型生成一个字就推送一个字用户看到的是打字机效果而不是干等十几秒然后一次性看到一大段文字。平台后端在这里做了一个缓冲区的设计从上游模型API收到流式内容先写入Redis临时队列再转发到前端。前端断线重连时可以从Redis恢复最近的内容避免用户感觉“突然丢了一段话”。并发控制策略则是配置“模型最大并发数”和“全平台最大并发数”。本地模型跑在CPU上并发太高会直接把内存打爆推荐把本地模型并发数限制在2到4之间云端模型可以设置成10以上。超出的请求自动排队前端会显示“排队中前面还有N人”。4.5 数据与隐私设计这个平台的数据归属设计值得单独说一说。每个用户的会话记录存储在独立的表里通过user_id字段隔离。后端所有查询会话数据的接口都强制带当前登录用户ID不传则不返回结果。即使是管理员查看用户列表也只能看到用户的用量统计无法直接翻看对话内容。知识库分为“共享库”和“私有库”两种。共享库全家可见私有库只有创建者本人能检索。我把家里的保险单扫描件放在共享库方便全家查阅条款。日记和健身计划放在私有库谁也看不到。另外平台支持对出站请求做敏感词过滤。担心孩子的提问会包含家庭住址、学校名称等隐私信息时可以在后台设置脱敏规则系统在把请求发送给云端模型之前自动替换掉这些关键词云端只接收到处理后的文本家庭成员信息不会完整暴露出去。5. 常见问题与排查技巧实录5.1 高频问题处理对照表实际用了两个月遇到的坑不少我把典型的几类整理成了表格方便你直接对照排查。现象可能原因解决方案登录页打不开Docker容器未启动/端口被占用执行docker compose ps查看状态检查端口是否冲突某个账号无法对话配额已用完/模型权限未配置后台查看该用户配额检查可用模型范围本地模型回答很卡内存不足/并发太高降低模型并发数拉取更小尺寸模型云端API报401API Key失效或填写错误在云平台控制台重新生成密钥并更新知识库检索结果不准文档分块过大/Embedding模型不匹配调整分块大小为500字左右更换更合适的Embedding模型回答到一半断流上游模型超时/Redis内存不足查看上游API状态面板适当扩容Redis内存重置密码邮件收不到SMTP未配置/邮件进垃圾箱在后台配置正确的SMTP服务检查垃圾邮件5.2 本地模型提示内存不足怎么破16G内存的小主机跑7B模型偶尔还是会遇到内存告警。最有效的办法是换小模型比如Qwen2.5 3B或者1.5B虽然推理能力弱一些但日常问答、摘要总结完全够用。如果坚持要用7B模型可以打开Ollama的num_gpu参数把部分层加载到GPU但这需要一块独立显卡迷你主机不具备这个条件。另外可以把Ollama服务的上下文窗口调小默认8K经常会有溢出改成4K能明显降低内存占用ollama run qwen2.5:7b # 在对话内设置 /set parameter num_ctx 4096平台侧的模型并发数也要压低。上午全家都在上网课查资料的时候本地模型并发一高就容易OOM容器被杀掉重启。把并发数设为2响应会慢一点但稳定性明显提升。5.3 API费用突然飙升的排查思路有一天我发现云端API费用比平时高了3倍后台日志里看到同一个账号短时间发了大量请求。排查步骤是进入后台“用量统计”页按天分组查看消耗再按用户分组查看锁定是谁在大量使用查看该用户的对话记录确认是否误操作或者被别人登录实际情况是孩子在使用时发现模型回答不符合预期反复重新生成每次都触发了新的完整请求。解决方法是拉低该账号的“每日消息次数上限”同时开启“上下文中问题重复检测”如果连续两个问题高度相似就自动合并为同一个上下文避免重复计费。5.4 公网访问的安全加固建议如果是部署在云服务器上需要开放SSH和HTTPS端口。建议不要在服务器上直接开HTTP明文访问至少用Caddy或者Nginx做一层TLS终止。Caddy的配置非常简单自动申请和续期证书ai.example.com { reverse_proxy localhost:8080 }同时关闭服务器的密码登录只保留密钥对登录。安全组里只放行443和22两个端口其他一律拒绝。如果家庭成员在同一个局域网内使用干脆不开放公网直接通过http://内网IP访问最安全。6. 实操心得与进阶玩法6.1 移动端和桌面端的接入体验这套平台本身是Web服务手机浏览器、电脑浏览器都能直接用。你可以在手机上把登录页添加到主屏幕它会以全屏WebApp的方式打开体验接近原生App。桌面端可以把网址做成一个浏览器快捷方式放在任务栏上点击就能对话。如果家里有平板设备放在厨房当“家庭智能终端”也很有意思。早上打开平板就是AI助手的主页问天气、查菜谱、看孩子课表操作门槛比手机还低。6.2 把原来买会员的钱花在更有价值的地方自建平台之后原来每个月的AI订阅费用直接省掉了。我把这部分预算用来买了一块更大内存的二手小主机剩余的钱买了一个UPS电源保证停电时平台也能持续运行。整个投入是一次性的之后每月成本只有几十度电和偶尔的云端API调用费。现在家里所有人都在用这个AI共享平台。妈妈的用法是整理会议纪要和起草文稿爸爸让AI辅助分析Excel数据两个孩子一个用来查学习资料一个是拿来练英语对话。他们用到的能力不同但背后支撑的都是同一个中枢平台。6.3 这个项目后续还可以怎么扩展平台本身预留了API接口如果你有一定开发能力可以基于它做更多事情。我把平台对接到了家庭智能音箱语音问“明天天气怎么样”时音箱内部调用平台的API完成意图识别和回答生成。如果你想把它接到企业微信或者钉钉上作为团队AI助手也是可行的。后端有标准OpenAI兼容接口生态里大量现成的机器人框架都可以直接对接团队内部的内部知识库也能挂进来。再进一步如果你想做大模型训练层面的优化可以导出平台积累的全部对话数据整理成指令微调数据集用开源框架做LoRA微调。投喂给本地模型之后它会更熟悉家庭的语言习惯和常用称呼回答风格也会越来越自然。6.4 最后分享一个小技巧部署完成后强烈建议你在管理后台把“模型健康检查”功能打开。平台会每5分钟ping一次所有已配置模型的API接口任意一个连续3次无响应就被自动标记为不可用路由时会自动跳过它。我就是靠这个机制避免了两次“大事故”。一次是云端模型服务升级导致API短暂不可用一次是本地Ollama服务被系统重启之后没有自动拉起。配置了健康检查之后平台会自动切换到备用模型家里人完全无感知只有后台日志里能看到切换记录。如果你准备部署这套全家共享AI平台建议从一台16G内存的小主机起步先接一个云端模型和一个本地7B模型把最基本的全家对话跑通再慢慢加知识库、加自动化路由规则。这套方案的灵活性远高于给每个人单独买会员而且越用越顺越用越像一个真正属于自己家的AI中枢。