使用 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 方案感兴趣或者有问题，欢迎留言讨论。