凌晨三点,一位开发者在调试第17个AI功能时,突然意识到账单问题——不是太贵,而是太便宜。便宜到让他写下这篇教程。
场景:一个边缘函数扛起所有AI
Supabase Edge Functions(边缘函数)+ Gemini 2.5 Flash(谷歌轻量推理模型),这套组合正在改写独立开发者的成本公式。
开发者跑通了完整链路:数据库、认证、限流、图像生成,全部塞进一个TypeScript文件。没有Vercel Pro订阅,没有OpenAI月账单,没有Redis实例。核心支出只有Gemini 2.5 Flash的调用费——约0.075美元/百万输入token。
免费层覆盖:Supabase免费档扛住数据库和认证,每月50万次边缘函数调用额度,Postgres表直接当限流器。
这套架构的精妙之处,在于把"边缘"用到极致。请求在靠近用户的节点处理,延迟够低;计算在函数内完成,无需常驻服务器;状态扔回Postgres,原子操作保证一致性。
代码解剖:200行内的完整AI服务
核心文件`supabase/functions/ai-task/index.ts`做了三件事:跨域处理、限流检查、模型调用。
跨域头直接硬编码,OPTIONS预检请求秒回。用户ID从请求头`x-user-id`提取,taskType区分不同AI功能——这意味着同一个端点可以路由到17种不同的提示词模板。
限流逻辑委托给Postgres存储过程`check_rate_limit`,而非引入Redis。设计很朴素:每小时窗口、单用户单功能计数、超频即返回429状态码。
Gemini调用走标准REST接口,temperature锁0.7,maxOutputTokens设2048。响应解析用了可选链`data.candidates?.[0]?.content?.parts?.[0]?.text`,防止模型返回空结构导致崩溃。
整个函数没有外部依赖,Deno原生运行时直接执行。部署即运行,冷启动控制在毫秒级。
原子限流:为什么不用Redis
开发者给出的方案是Postgres表+存储过程。表结构极简:用户ID、功能名、计数、窗口起始时间。
`check_rate_limit`函数内部先做清理——删除1小时前的旧记录。然后聚合当前窗口内的请求总数,与阈值比较。允许通过则插入新记录,拒绝则返回false。
关键保证在于`security definer`和事务边界。删除与插入在同一个存储过程内完成,PostgreSQL的MVCC机制天然隔离并发。开发者强调:没有竞态条件,不需要Redis。
这是对云原生架构的逆向思考。Redis擅长亚毫秒级计数,但引入一个新服务意味着:实例费用、连接池管理、故障面扩大。当QPS没到万级,Postgres的行级锁完全够用。
成本账算得很细:Supabase免费档的Postgres足够承载,限流查询走索引,性能损耗可忽略。
成本结构:每一分钱去哪了
开发者列出的支出项几乎全是零。
数据库+认证:Supabase免费层覆盖。AI推理:Gemini 2.5 Flash按量计费,百万token几分钱。服务器计算:50万次调用/月免费。限流:Postgres表零额外成本。图像分享:边缘函数动态生成SVG,无存储费用。
唯一需要申请的是Google AI Studio的API key,目前免费额度充足。
对比传统方案:Vercel Pro每月20美元起,OpenAI GPT-4 Turbo百万token输入10美元,Redis Cloud最小实例7美元/月。这套架构把固定成本压到趋近于零,边际成本只剩模型调用费。
对于月调用百万次以下的个人项目,成本确实低于一杯精品咖啡。
为什么是Gemini 2.5 Flash
模型选择暴露开发者的优先级:成本 > 延迟 > 能力边界。
Gemini 2.5 Flash定位轻量推理,上下文窗口够用,输出速度够快。开发者没有追求最强模型,而是找"够用且便宜"的选项。17个AI工具共享同一个端点,说明任务类型偏向文本生成、分类、简单推理,而非复杂多步Agent。
这种选型逻辑在小团队很常见:先让系统跑起来,用真实数据验证需求,再决定是否升级模型。Flash版本的幻觉率和指令跟随能力,对原型阶段足够友好。
更深层的判断是,谷歌正在用价格换生态。AI Studio的免费key、Flash版本的低价token,都是在抢开发者心智。这位开发者用脚投票,把完整架构开源出来,本身就是对性价比的认可。
边缘计算的隐藏成本
教程没说的是:这套架构有明确的适用边界。
Supabase Edge Functions的50万次/月额度,按每天1.6万次计算。17个AI工具如果平均分配,每个工具日活用户撑死几百人。超过额度后,Supabase按百万次调用收费,价格曲线会陡变。
Postgres限流在并发高峰可能成为瓶颈。存储过程虽原子,但高频率调用会消耗连接池。开发者没提QPS数据,但暗示这是"个人项目"规模。
Gemini 2.5 Flash的可用性也是变量。谷歌随时可能调整免费key策略,或给Flash版本加限速。把核心依赖押在单一供应商的免费层,是创业公司的经典风险。
图像生成走SVG而非多模态模型,说明需求被刻意简化。如果用户要的是照片级图片,这套架构需要重写。
行业信号:成本坍塌催生新物种
这位开发者的实践,指向一个正在发生的结构性变化。
AI基础设施的成本曲线比预期更陡峭。不是线性下降,是断层式坍塌。当推理成本降到"咖啡价",产品形态会发生质变——从"谨慎调用"变成"随处嵌入"。
17个AI工具不是17个独立产品,而是一个端点的17种配置。这种"微功能"模式,依赖极低的边际成本才能成立。每个功能可能只服务几百用户,但加起来覆盖完整场景。
更值得关注的是技术栈的收敛。Supabase从数据库工具变成全栈后端,边缘函数吃掉Serverless市场,Postgres用扩展性替代专用服务。这不是技术选型,是生态位的重新划分。
开发者的选择有代表性:用平台原生能力替代第三方服务,用代码复杂度换运营简单性。当云厂商把存储、计算、AI打包成一体化体验,独立开发者的最优策略是"深度绑定,极致榨取免费层"。
可复制的边界
这套架构适合谁?月活万级以下、以文本交互为主、愿意承担供应商锁定的个人开发者或小团队。
不适合谁?需要多模态生成、有合规审计要求、QPS峰值过千、或无法容忍谷歌服务可用性的场景。
核心可迁移经验是:用数据库原生机制替代专用中间件,用边缘计算替代常驻服务器,用轻量模型替代旗舰模型。成本优化不是砍功能,是重新设计依赖关系。
开发者把完整代码贴出来,等于公开了竞争壁垒的构成方式。这不是技术秘密,是执行力的证明——能把17个需求塞进200行代码,且账单可控。
下一步行动
如果你正在评估AI功能的成本结构,建议做三件事:第一,清点现有架构中的固定支出项,识别可被数据库原生功能替代的中间件;第二,测试Gemini 2.5 Flash在你具体场景下的幻觉率和延迟,确认"够用"的边界;第三,用Supabase免费档搭建一个端到端原型,验证真实流量下的成本曲线。
成本坍塌的时代,最大的风险不是花错钱,是慢一步发现更便宜的解法。
热门跟贴