使用 Vercel、Supabase、Stripe 打造 OpenAI 计费系统:1. 系统篇

过去两周,我基本都在跟这套付费/计费系统死磕,相对来说投入到 AI 学习里的时间不多,以至于 我的 AI 学习周记 系列本周停更。如今终于基本搞定这套系统,基本概念、开发调试都不存在难以逾越的问题,所以打算写几篇博客总结一下,给后来者分享我收获的知识、踩到的坑。也让自己需要的时候可以翻查笔记。

OpenAI 计费系统现状

目前我们讨论的 OpenAI 计费,基本是针对 ChatGPT 对应的 gpt-3.5-turbo 和 gpt-4 这两个模型,在 API 调用方面的费用。官方规定,gpt-3.5-turbo 是 $0.002/1000 tokens,gpt-4 根据容量不同,最多要贵 30 倍,所以提供服务时,我们基本还是以 3.5 为主。如果用户愿意多付钱,我们也可以提供 gpt-4(已经拥有权限)。

不使用 stream: true 的时候,OpenAI 会返回使用的 token 数量,这个时候,数据准确可靠。但是为用户体验考虑,也为云服务考虑,使用 stream: true 模式明显更好。但是在这种模式下,OpenAI 不返回使用的 token 数量。(我猜测这跟 Transformer 模型的工作原理有关。)所以我们就需要手动统计 token 的消耗。

这个时候得到的结果可能并不准确,但是没办法,我们只能这么做。

我们开始也不知道 OpenAI 怎么统计 token 数,好在官方提供了计算页面:https://platform.openai.com/tokenizer 和推荐方案(看起来是传说中的 GPT 地牢作者的作品),可以帮我们完成计算。至于详情,将来会具体介绍。

基于 Edge Function 的计费系统设计

首先,我们要选择服务器架构。

传统方案是配置一台云服务器,然后前面架一个 CDN。但由于我们是一个面向全球的服务,这样的架构不甚理想。而且基于 stream: true 的方案需要长时间维持网络连接,单机容量也不够。全球部署的话,成本太高,初创团队不现实。

所以很自然的,我们准备使用 Edge Function。Edge Function 的优势在于:

  1. 它借助云服务厂商的边缘节点提供服务,节点分布广泛,可以就近服务用户,大大改进响应时间。
  2. Edge Function 在用户请求的时候才工作,平时休眠。这种按需付费成本更低。
  3. 相比于传统的 Serverless Function,Edge Function 一般都会修改运行时,用减少负载的方式提升启动速度,以几乎 0 延迟的方式启动,用户体验很好。

以上几点我均已在之前的试做项目中在 Vercel 平台上体验过,所以这次没怎么纠结,直接选择 Vercel Edge Function 开发。

也欢迎大家阅读我前一篇分享文:使用 Vercel Edge Function 访问 OpenAI API 的注意事项

数据库选择:Supabase

确定使用 Edge Function 之后,下一步要选择数据库。传统的、基于数据库协议的方式不可行,必须支持 http 请求,必须支持连接池,可选方案不太多。刚好前阵子我为了抽键盘,了解到有一家叫 Supabase 的新 serverless 服务商,可以很好满足我们的需求。

首先,他们能满足 Vercel Edge Function 的需要,也是官方推荐的厂家之一。

其次,他们的服务基于 PosgreSQL,具备丰富的插件生态,可以实现各种功能,包括未来给 ChatGPT 提供内容拓展的 pg_vector,可以不用担心将来需求延伸。

再次,作为一家 serverless 服务商,他们家的免费额度看起来还不错,应该可以满足我们早期验证产品的目标(薅羊毛就是爽)。而且,自带 RLS(行级安全策略)也会给未来的开发带来很多方便,比如我们可以放心的把用户身份有关的读取操作放在客户端,不用单独开发接口,节省很多人力。

最后,我们决定选用 Supabase,作为数据库服务供应商。

其实 Supabase 也提供 Edge Function,效果理论上并不比 Vercel 差,但它是基于 Deno 的封装,生态和环境都跟 Node.js 不太一样。考虑到学习成本,以及分散投入有利于多嫖资源,所以我暂时不打算用,还是先集中在他们家的数据库上。

收费选择:Stripe

作为超迷你初创团队,主攻海外英文市场,我们的策略自然是一切从简,那么付费方案很自然就选择了 Stripe。Stripe 的功能全,文档强大,很适合我们这种小团队使用:

  1. 接受多种收费方式,各种信用卡不一而足,尽可能满足用户
  2. 提供订阅式购买
  3. 支持优惠码等促销手段
  4. 提供 SaaS 服务,方便管理用户
  5. 可以用 Payment link 创建付费页面,省去几乎所有购买流程的开发成本
  6. 提供 webhook,对接我们的账户体系
  7. 提供大量 API,如果有需要,将来我们可以逐步迁移到自己的平台

最终选择

基本上,我们最终形成了这样一套方案:

  1. Vercel Edge Function 提供 OpenAI API 的封装,我们借由它完成用户请求、额度拦截、计费等功能
  2. Supabase 提供存储,我们借由它存储用户的账户状态、付费记录、消费记录等功能
  3. Stripe 提供购买功能,我们用它的 Payment link 让用户完成购买付费

这些产品都支持 TS/JS 为主的语言,提供基于 npm 的 SDK,开发环境很大众,开发体验不错。未来属于 JS。

这套架构在初期没什么成本,可以覆盖几乎全球的用户,提供不俗的性能。将来用户量增长,需要扩容的时候,也不需要我们再手动开发扩容功能,只要根据用户量、使用量付费给云服务商就好。如果将来我们要提供 embedding,嵌入用户自己的数据,也可以很容易的在现有框架下实现扩展。

乐观估计,未来半年到一年内,我们都可以在这个体系下开发。


小结

我感觉全世界就我一个人在做计费系统,其他人:

  1. 要么是不知道是弄了很多免费账号还是自己负担费用先抢用户,反正是敞开给用户免费用
  2. 要么是收一大笔钱割韭菜,反正收的钱多,普通用户随便用也用不完

总之都不在意区分用户,也不在意回本。于是几乎看不到有人讨论如何做自己的付费系统。

我们认为成熟的商品,还是要在成本、收益、风险上形成稳定、友好的比例,计费系统早晚都得做,不如先做好。

如果你对 OpenAI 计费系统,对我们这套基于公共云平台的 Edge Function 方案感兴趣或者有问题,欢迎留言讨论。

如果您觉得文章内容对您有用,不妨支持我创作更多有价值的分享:


已发布

分类

来自

评论

《“使用 Vercel、Supabase、Stripe 打造 OpenAI 计费系统:1. 系统篇”》 有 6 条评论

  1. felix 的头像
    felix

    感觉用这套机制可以直接做一个方便国内用户付费的 API 代理。

    1. meathill 的头像

      理论上当然可以,实际测试也可行。不过麻烦的是,要在国内正经运营的话,各种公司实体之类的搞起来比较麻烦。顺便,stripe支持微信支付宝。

  2. ankin98cpcheats 的头像

    哈哈,果然有人有这个想法,期待你的项目

    1. ccccc 的头像
      ccccc

      国内大部分都是基于条数的套餐计费。
      OpenAI计费请求失败也会记prompt token的钱

  3. cccczl 的头像
    cccczl

    我们在国内想做一套类似的付费系统正在折腾中,看到你的文章,留下邮件沟通下。

    1. meathill 的头像

      这里的难点在于:

      1. Stripe 需要国外收款。
      2. 国内对收款的门槛设置很高。

      技术问题其实很好解决。

欢迎吐槽,共同进步

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据