你有没有认真算过家里到底在同时给几个 AI 服务交钱我去年年底算了一笔账自己订了一个 Chat 会员老丈人手机上装了一个按次扣费的写作软件老婆公司之前还报销了一个专业版账号我自己又买过一轮 API 额度拿来测试。几项叠一起一个月将近 800 块。最让人别扭的不是钱多而是这些人每个人各用各的 App登录、记录、费用完全割裂我根本不知道全家在 AI 上到底花了多少。后来我在 GitHub 上翻到一个腾讯开源的、3.6K 星标的项目思路一下通了不用再让家里每个人单独订阅只要自建一个AI 全家共享平台把所有模型 API 收进一个入口我配好权限和额度家里人打开一个网址就能用各种第三方客户端也能通过它统一转发。这篇文章就围绕这个项目讲讲它到底是什么、怎么部署、共享权限怎么设计、成本怎么算以及我实际踩过的那些坑。1. 为什么我会被AI 助手单独付费这件事反复掏钱1.1 全家桶式的订阅账单有多浪费先别急着谈技术先看一个更常见的场景。一家四口老公自己要测试各种大模型得有 API Key老婆日常写材料需要一个界面舒服的写作助手爸妈想偶尔问问健康常识、做菜步骤手机上已经装了两个收费 App孩子上网课又有老师推荐了一个什么 AI 学习工具。这还算不上夸张真要细数每个人名下的 AI 服务加起来可能超过六七个。这些会员的计费逻辑非常鸡贼按人头、按设备、按功能订阅就是没有家庭共享这一档。ChatGPT 类的产品明确禁止多人用同一个登录信息一旦检测到频繁异地登录轻则限流重则封号。我身边就有人图省事把自己账号给老婆孩子用结果用了不到两周登录时直接提示风险折腾了半天申诉。那种共享根本不是省钱的解法是在玩火。所以很多家庭的实际状态是一个人买了会员其他人心里不爽于是自己也买一个或者大家都在用免费额度但免费额度各有各的限制体验参差不齐。一个月的账单摊开看每人几十到上百全家加起来就非常可观。这里真正的痛点不是一个会员多少钱而是开销太分散、完全没有统一管理手段。1.2 腾讯开源项目如何改变玩法后来我翻到一个 GitHub 上腾讯开发者开源的平台Star 数大概 3.6K仓库名关键词是 gpt-accelerator。它本身不是一个聊天机器人软件而是一个自带网页的 AI 网关核心就是把你手里的模型 API Key 集中管理起来对外暴露一个统一的访问地址和鉴权机制。很多人对网关这个词没概念。打个比方以前全家每个人的快递都寄到各自公司谁丢件、谁不在家大家都不知道网关就像是小区门口的快递柜所有快递统一进柜你拿着取件码去拿就行。模型 API 是快递Key 是取件码网址就是快递柜。这个项目最打动我的是它把三件事绑定成了一个系统网页聊天窗口、多 Key 轮询、访问权限控制。网页聊天窗口解决家里人不会配置客户端的问题多 Key 轮询解决全家同时用容易触发限流的问题访问权限控制解决开放给别人用之后账单失控的问题。这点后面会详细说。1.3 3.6K Star 说明什么Star 数不是衡量项目好坏的唯一标准3.6K 在开源世界里也不算顶流但至少说明它是被人实际用过、验证过的。而且我看这个项目的几个特性明显是写作者自己在生产里用出来的比如部署到 Serverless 平台只花几分钟比如支持多 Key 自动切换比如可以直接限制模型列表。这种项目往往比堆功能的大而全的更耐操因为它解决的就是作者自己和身边人每天面对的问题。我也要提醒一句标题说腾讯开源准确讲应该是腾讯工程师个人在 GitHub 上开源的不是腾讯官网下发的所谓官方产品。这类称谓在圈子里很常见不影响使用但你要有心理预期——它没有官方客服也没有腾讯官方的质量背书遇到问题得靠社区和源码。2. 3.6K 星标 gpt-accelerator 的核心能力拆解2.1 它不是一个聊天软件而是一个 AI 网关先把这个项目拆开看。我理解它由三层组成第一层是最外面的 Web 页面。任何人打开部署后的网址就能看到一个干净的聊天界面不用注册、不用装 App。对家里老人来说打开网址就能聊是最大的友好度。很多人以为 AI 必须装各种客户端其实一个网页链接就可以。第二层是 API 服务。它对外提供了 OpenAI 兼容的 API 接口。这意味着你手机上的第三方 ChatGPT 客户端、IDE 里的 AI 插件、自己写的 Python 脚本都可以把接口地址指向它。原本散落在各个客户端里的 Key 从此只存在服务器端客户端只认这个网关。第三层是策略层。包括请求进来之后怎么选 Key、并发怎么排队、失败怎么重试、模型怎么限制。这一层是做家庭共享的关键也是控制成本的关键。这三层合在一起你就理解为什么说它是一个平台而不是一个模型。它自己不生成回答它负责把问答请求安全地转发给背后的模型服务商再把结果转回来。2.2 多 Key 轮询与访问鉴权的工作逻辑多 Key 轮询是这类共享平台的核心能力之一。单个 API Key 往往有每分钟请求数RPM和每分钟 Token 数TPM限制一个人用感觉不明显全家三四个人同时提问很容易碰到 429 限流。解决思路很简单准备两三个 Key设为轮询队列第一个 Key 被限流时自动换第二个实现 112 的效果。我实测下来这种方式对文本类请求的缓解非常明显。但如果请求本身量很大比如六个人同时在做长文档总结Key 再多也会打到真正的服务商配额。多 Key 只是把单点瓶颈分散掉不是魔法。访问鉴权逻辑也需要注意。典型做法是设置一个访问密码比如 AUTH_CODE用户打开页面时输入密码才能进入聊天界面。这个密码类似于小区门禁卡进来的人都能用平台背后的模型只是他们看不到你的 Key。另一种做法是允许用户在前端填自己的 Key当用户填了自己的 Key 时他的请求优先用他自己的配额不填则走共享池。两种方式适合不同场景后面我会具体说怎么选。2.3 识别一个 AI 共享平台好不好的三个标准这几年 AI 网关类项目非常多如果你准备自己找一个我建议用三条标准判断第一部署门槛低不低。能一键部署到 Serverless 平台是个很大的加分项。因为 AI 转发的负载和网站访问负载都很轻专门租一台服务器维护对家庭场景太笨重。第二网页端和 API 是不是一体的。许多项目只做聊天网页不做统一 API结果你手机里的第三方 App 依然没法共用同一个网关。一体化的项目才能真正实现全家共享。第三权限和限额是不是可以控制。能不能设置访问密码、能不能限制模型列表、能不能对某个具体用户限流、能不能只开放 API 不开放网页。这些在共享场景里直接决定你月底收到的是惊喜还是惊吓。用这三条标准回头看这个腾讯系项目正好都符合。这也是我选择用它而不是自己拼三四个工具的原因。3. 完整部署流程从克隆到上线只需要一杯咖啡的时间3.1 部署前要准备什么正式部署前我建议先把下面几样东西准备齐不然中途容易卡壳GitHub 账号。用来 fork 仓库Vercel 等平台也要通过 GitHub 授权导入。一个模型服务商的 API Key。这个不一定是 OpenAI 官方的只要接口兼容 OpenAI 格式即可。国内不少服务商也提供这类兼容接口选择时注意看文档里是否有base_url配置项。部署平台账号。优先推荐 Vercel 或 Railway也可以用腾讯云函数、阿里云函数计算各有机会。一个域名不是必须的但强烈建议有。用平台默认的xxx.vercel.app域名也能跑但不够正式而且容易被扫到变成公开靶子。我自己的选择是验证阶段用 Vercel 默认域名跑通确认稳定后绑定了自己的子域名并在域名解析那里配置好 TLS。这一步对后面开放给家人用很重要因为家庭成员打开地址看到的是你自己的域名信任度完全不一样。3.2 以 Vercel 为例的部署步骤拿最常见的 Vercel 路径说操作大概是这几步先在 GitHub 上搜索项目仓库点击右上角 Fork。打开 Vercel选择Add New Project从自己的 GitHub 仓库列表里找到刚才 fork 的项目点击导入。Vercel 会自动识别项目类型一般不需要改构建设置直接点 Deploy。部署过程中会有环境变量填写页面。如果你跳过了也可以在部署完成后进入项目 Settings - Environment Variables 补上。部署完成后Vercel 会给一个https://任意名字.vercel.app的地址打开就能看到聊天页。整个过程快的话十分钟慢一点可能卡在环境变量或授权上。有一个细节Vercel 在中国大陆的访问稳定性取决于你的网络环境如果自己访问都慢建议把最终部署落在云函数这类更顺的平台上。这是现实问题部署方式灵活一点就好。如果要用云函数思路类似把项目代码打包上传到函数计算设置好环境变量绑定一个 HTTP 触发器。注意把函数超时时间调到 60 秒以上否则长对话输出很容易被掐断。云函数的具体入口名称以平台为准打开部署日志能看到请求是否正常进入。3.3 环境变量逐一说明这部分直接决定你能不能跑通我按自己当时配置的顺序整理成了一张表环境变量作用是否必填我的配置示例OPENAI_API_KEY模型服务商的主 Key可填多个 Key 实现轮询必填sk-你的模型KeyBASE_URL模型接口地址接国内兼容接口时填服务商给的地址大多数情况下必填https://xxx.com/v1AUTH_CODE访问密码打开网页或调用 API 时需要的凭证强烈建议MyFamily2025CAN_CHANGE_KEY是否允许前端手动填自己的 Key可选falseMODEL_LIST用户可选模型白名单具体变量名看项目 README可选deepseek-chat,xxx说几个我踩过又觉得重要的点。第一OPENAI_API_KEY不要直接暴露给家里人。你在后台配好共享 Key大家在网页上用访问密码进来就行。第二BASE_URL的路径很容易写错常见的是写到域名后不加/v1或者加了但 SDK 又自动拼了导致 404。这个要根据目标 SDK 的拼接规则来通常官方 SDK 会自动加/v1所以BASE_URL往往填到域名那里就行自写 HTTP 请求时再手动补全。第三AUTH_CODE虽然叫码但它是访问凭证不要当作普通密码随便发群里。真要发就发一个带码的短链接并提醒对方别转给别人。3.4 用国内服务商验证部署结果部署完别急着把链接发家人先自己验证三条链路网页链路浏览器打开部署地址输入访问密码随便问一个模型问题。如果能看到流式文字一段段出来说明前端、网关、模型链路都通。API 链路用 curl 模拟一次对话请求看是否能正常返回。命令大概是curl -X POST https://你的域名/v1/chat/completions -H Content-Type: application/json -d {model:你的模型名,messages:[{role:user,content:你好}]}。并发链路开两个浏览器窗口同时发不同问题看是否都正常。这一步能提前暴露 Key 限流问题。如果这三步都没问题再分享给家人。我见过太多人部署完直接甩链接结果第二天起来一看日志里全是报错既影响体验也影响心情。多花五分钟验证值得。4. 全家共享的权限与成本控制让账号握在自己手里4.1 开放给家人前一定要做的安全设置把平台开放给他人之前先做三件事第一设置访问密码。这个不用解释了。但要注意密码不能写在网页标题或者 URL 里。有些项目的鉴权方式是把访问密码放在查询参数里例如?authxxx。这种链接一旦被分享出去等于密码公开。我倾向于让成员进入页面后手动输入密码虽然多一步但可管理性高很多。第二把CAN_CHANGE_KEY关掉。如果开着用户可以在聊天页面填自己的 Key。听起来很灵活但一旦有人不填 Key 并且你的共享 Key 又没限额他就能无限使用共享池。家庭场景里我不需要这种灵活性宁愿统一由中心配置。第三限制模型列表。把最贵、最容易产生大额消耗的模型名从白名单里去掉。比如某些超长上下文模型单次请求的 Token 消耗可能是普通模型的几倍一个小白用户连续追问几轮费用直接翻好几倍。家庭共享最怕的就是这种一次对话花掉一天预算的情况所以模型的默认档位和可选档位都要认真配。4.2 多模型、多 Key 的分配策略家庭场景和创业公司场景的分配策略完全不同别照搬。家庭场景我一般建议一个共享 Key 访问密码 模型白名单。家里人的需求主要是聊天问答、写作灵感、周末出游规划这类请求访问频次不高、Token 量中等用一个主 Key 完全够。给每个人都配独立 Key 会增加管理成本而且他们也不懂 Key 是什么。团队/极客场景可以考虑每个成员独立 Key主 Key 作为 fallback。这样每个成员的用量在服务商后台清晰可查谁的请求异常一目了然。主 Key 只负责兜底避免个人 Key 用完时体验中断。这个策略还有个好处某个成员 Key 泄露了可以直接在后台吊销不影响其他人。4.3 实际成本怎么算我听到很多人的第一反应是自己搭一个是不是就完全免费了答案很明确不是。它省的是多份订阅会员的钱但模型 API 的按量费用还是照付的。账单结构从每头每月固定订阅变成了全家一条总水管按流量计费。拿一个实际例子来算。假设家里三个人之前每人各自买一个主流 AI 订阅月费折合人民币大约 70 元每人三个人就是 210 元/月。自建共享后接入一个性价比高的兼容接口全家累计一天大概产生 10 万 Token 的对话量按市面常见价格算一个月大概在 20-50 元之间。中度使用的情况下确实能省下一半以上。但如果家里有重度用户每天长时间用模型写代码、分析长文档或者频繁调用多模态能力API 按量费用反而有可能超过固定订阅。所以我的结论很务实家庭里中低频多人共享自建网关明显划算重度单用户固定订阅仍然是更好的选择。这两种模式不是替代关系而是互补关系。5. 把它当成统一 API 网关来用接第三方客户端的完整姿势5.1 为什么要统一入口把网关搭好之后很多人的用法还停留在用它的网页聊聊天这其实只发挥了 30% 的价值。我认为这个项目更大的价值在于给所有第三方客户端提供一个统一入口。举个例子。我以前在电脑上用一个桌面 App 接模型手机上又有一个第三方客户端IDE 里还有一个代码补全插件三个工具三个地方分别填 Key。每次换一个模型服务商就要去三个地方改配置每有一个 Key 泄露的担忧都不知道是哪个客户端漏的。统一网关之后所有工具都指向同一个 BaseURLKey 只在网关后台存在。客户端那边你只需要填一个网关分配的凭证这个凭证如果不小心泄露了在网关侧撤销掉即可不需要去挨个改客户端。5.2 三种接入方式实操我整理出最常见的三种接入方式按使用场景分开说。第一种网页直接用。这个不用多说适合家里长辈和访客。唯一建议是给他们的浏览器加一个收藏书签并告诉他们以后点这个书签就行。第二种OpenAI SDK 接入。很多第三方 App 和自写脚本都是用 OpenAI SDK 的只要把 SDK 里的base_url改成网关地址就能用。Python 里大概是这么写的from openai import OpenAI client OpenAI( api_key你的网关访问凭证, base_urlhttps://你的域名/v1 ) resp client.chat.completions.create( model你的模型名, messages[{role: user, content: 你好}] ) print(resp.choices[0].message.content)注意 api key 这里填的是网关的访问凭证不一定是模型服务商 Key。整个请求会通过网关转发所以模型服务商的 Key 不会出现在客户端环境里。第三种自写 HTTP 请求。这个适合排查问题。用 curl 或者 Postman 直接打https://你的域名/v1/chat/completions请求体格式和 OpenAI 完全一致。接不上时在网关的日志里看请求是否到达、转发是否成功通常是排查的第一步。5.3 接入过程中的常见坑接入第三方客户端最容易踩的坑有三个。坑一BaseURL 到底带不带/v1。不同客户端要求不一样有的客户端会自己拼/v1有的不会。我的经验是先看网关自定义域名模式下约定好的完整路径然后试一次404 就多补或少砍一级。这个方法虽然土但最直接。坑二鉴权方式不一致。有些 SDK 默认在请求头里带Authorization: Bearer key网关认证也可能要求这么带。但如果网关的鉴权要求查的是AUTH_CODE或自定义 headerSDK 不一定支持。这种情况就回到第一种网页方案或者用自带支持的客户端别硬凑。坑三流式输出的等待问题。模型回答是流式的网关一层层转发客户端如果自己没开流式会导致 UI 一直转圈。在客户端里把流式输出开关打开会明显感觉首字更快。6. 实测体验与必须知道的避坑清单6.1 一周用下来的真实感受把网关部署完并分享给家人后我用了一周先说感受好的部分。家里人的反馈很一致这个网页打开就能用不用注册不用装 App没那么多花里胡哨的东西。对我自己来说最舒服的是所有 API 调用终于只经过一个入口我能一眼在后台看到今天有多少请求、哪个模型被调用最多。也有不太顺的部分。默认域名发出去确实有点丑我花了一晚上绑定自己的域名后家里人用着才习惯。还有就是受模型服务商本身接口稳定性的影响偶尔会有一两次请求超时需要在网关侧看到底是哪个环节慢了。它不是 7×24 小时永不掉线的企业级产品但对家庭使用来说足够。6.2 我踩过且希望你避开的几个坑第一个坑部署完忘了设置访问密码。我第一天只是内部测试为了省事没配AUTH_CODE结果第二天在日志里看到不少陌生的访问记录。虽然没造成实际损失但吓出一身汗。开放共享前把访问密码和模型白名单一起配好再对外开放。第二个坑默认域名被扫描。平台默认域名一般是一个可猜测的随机字符串但放到家庭群后有心的人会扫描类似域名。绑定自己的自定义域名是最简单有效的解决方式。光靠密码多少还是有点风险。第三个坑多 Key 配置时想当然。我最初以为填了多个 Key 就能把并发能力叠加测试时发现它更像Failover——第一个挂了自动换第二个而不是并行分摊。如果团队有高并发需求认准这一点别误判容量。第四个坑聊天记录存在浏览器本地。网页端的会话记录在 localStorage 里换设备、清缓存都会丢。家人以为登录后记录永远在云端结果某天清理浏览器后跑来问我记录哪去了。如果你在意云端记录这类网关不满足需求得配合后端存储方案或者干脆用有账号体系的 SaaS。6.3 适合哪些人不适合哪些人最后说句实在话。这个项目适合的人是本身有一点技术动手能力家里或团队里有三四个以上的人需要经常用 AI对各家会员收费感到肉疼愿意花半小时部署换回一个统一管理入口的。它也非常适合那些经常在不同模型服务商之间切换的人网关让你换服务商时不用挨个改客户端。它不适合的人同样明显完全不想自己维护任何技术设施的人对稳定性要求达到生产级 SLA的人以及只想安安静静用官方服务的消费者。自托管意味着你要承担部署、环境变量、日志排查、安全配置这些事。这不是负担但你也别指望它像商业产品一样替你处理完一切。我在折腾这套方案之前其实被全家桶订阅折磨得不轻。真正动手部署之后我才发现比省下的会员费更值钱的是那份掌控感——所有 Key、所有请求、所有账单都集中在一个平台里。最让我意外的收获是家里人现在遇到问题会先打开这个网址问一次而不是马上点开各种乱七八糟的付费工具。如果你也准备做同样的事我的建议是循序渐进先用默认域名跑通再绑域名再配安全策略最后再发链接。家人到底能不能接受自建网页比你想象的更容易验证——把网址和密码发进家庭群看他们第二天还愿不愿意用答案就有了。