月跑17个AI工具，成本不到一杯咖啡

凌晨三点，一位开发者在调试第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免费档搭建一个端到端原型，验证真实流量下的成本曲线。

成本坍塌的时代，最大的风险不是花错钱，是慢一步发现更便宜的解法。