腾讯开源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_URL=postgresql://aihub:aihub@postgres:5432/aihub - REDIS_URL=redis://redis:6379/0 - VECTOR_DB_URL=http://vector-db:8000 - JWT_SECRET=change-me-to-a-long-random-string - ADMIN_INIT_PASSWORD=change-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_USER=aihub - POSTGRES_PASSWORD=aihub - POSTGRES_DB=aihub 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，添加模型时填以下参数：

• 模型名称：混元-pro
• API地址：https://api.hunyuan.cloud.tencent.com/v1/chat/completions
• API 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小时，也可以设置仅白天
• 是否允许访问共享知识库

我给家里每个人的配置策略是：

这个表只是参考，实际按家庭需要调节。配额限制尤其适合有在校孩子的家庭，既能保证孩子正常使用AI学习，又不会在家长不知情的时候把API额度刷爆。

4. 核心环节实现解析：一个Web请求是怎样被路由到合适模型的

4.1 从聊天框到模型响应的完整链路

理解了这个链路，后续排查问题会轻松很多。一次普通对话在平台内部经历了七个阶段：

1. 用户通过浏览器输入消息，前端将消息以WebSocket或HTTP请求的方式发给后端
2. 后端先做身份鉴权，确认用户token有效，并检查该账号当日配额是否用完
3. 后端从Redis取该用户最近的会话历史，打包成上下文
4. 如果是知识库增强模式，先把当前问题转成向量，检索向量数据库，取回最相关的文本片段
5. 模型路由器根据预设策略，从可用模型列表中选择目标模型
6. 后端将“系统提示词+知识库片段+会话历史+当前问题”拼成请求，发送给目标模型API
7. 模型返回流式响应，后端一边转发给前端展示，一边将完整回复存入数据库

任一步骤出问题，都能在后台日志中对应到具体环节。比如用户反映回答很空，大概率是知识库检索没命中；如果模型半天不出字，基本是目标模型的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 高频问题处理对照表

实际用了两个月，遇到的坑不少，我把典型的几类整理成了表格，方便你直接对照排查。

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倍，后台日志里看到同一个账号短时间发了大量请求。排查步骤是：

1. 进入后台“用量统计”页，按天分组查看消耗
2. 再按用户分组查看，锁定是谁在大量使用
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中枢。