把大模型一键接进你的 App，火山引擎 Supabase 上线 AI-Gateway

大部分人在开发过程中都会遇到这样的情况产品经理提出了一个增加“AI助手”的功能需求这看起来也只是增加一个新入口但是打开 IDE 之后就得考虑后续一系列的技术难题API Key 不能暴露在前端因此需要有一个后端网关进行转发用户不能无限制地请求因此需要有配额以及计数调用过程需要被记录下来以便日后查询或者审计限流、Fallback、成本核算等问题也是不可避免。算下来这个看起来很“简单”的 AI 入口可能要花两三周的时间。现在火山引擎 Supabase 正式上线了 AI-Gateway大模型访问能力它与 Supabase Auth 无缝粘合复用 Supabase 的登录态在前端无需暴露模型 Key 的情况下调用大模型而配额、审计、观测、模型切换等操作都放到控制台里处理。这样就省去了很多原先需要自己补的工作。这篇文章你会看到AI-Gateway 是什么它可以做什么和自己搭一层 AI 中转服务有什么本质区别Demo 手把手可粘贴前端 30 行代码 一个“AI 待办助手”你在上线前避免踩坑的指南一、AI-Gateway 是啥从“数据库”到“AI 原生 BaaS”的那块拼图火山 Supabase 是基于火山云数据库 PostgreSQL Serverless 版打造的AI 原生 BaaSBackend-as-a-Service数据库、Auth、Storage、Edge Functions、Realtime……做 AI 应用时很多常用能力不用再分别搭建、维护一键接入即可使用。用户登录 Supabase获取access_token前端拿着这个 token 直接以 OpenAI 兼容协议调用${SUPABASE_URL}/v1/chat/completions——鉴权、限流、审计、计费这些全都可以通过火山 Supabase 一站式解决。一句话总结原本需要开发者自行搭建的 AI 中转层现已被火山 Supabase 纳入 BaaS 能力体系。核心原理如下鉴权复用 Supabase Auth前端不需要获取任何模型 API Key只需用session.access_token或service_role_key/ 第三方 JWT就能调模型火山 Supabase AI-Gateway 帮你识别“这是谁在调”。协议兼容 OpenAI请求地址为${SUPABASE_URL}/v1格式和 OpenAI Chat Completions 完全一致使用OpenAI SDK、Vercel AI SDK、cURL 都能直接连。运维套件内置每次调用均自动进入配额扣减、审计日志、观测指标控制台可视、可查、可导出。目前 AI-Gateway 上线支持字节跳动豆包Doubao系列包括Doubao-Seedance-2.0全系列、Doubao-Seedream-5.0全系列、Doubao-Seed-2.0-Pro、Doubao-Seed-2.0-Code、Doubao-Seed-2.0-Lite、Doubao-Seed-2.0-Mini它覆盖了视频生成、图片生成、通用推理、代码、轻量对话等组合。具体的模型清单以控制台为准。二、它到底解决了什么问题三个真实场景以下是三个由真实开发者所碰到问题以此来感受一下火山 Supabase AI-Gateway 带来的便捷之处。场景一一家 SaaS 软件想要增加一个“AI 客服”但是又不愿意为其单独新建一个后端。背景你开发一个 ToB SaaS 产品在前端使用 React在后端已使用 Supabase 完成认证以及数据库相关工作。产品经理提出“是否可以增加AI客服功能”如果没有 AI-Gateway你要做如下这些事一个新 Node/Python 服务用于保存模型 API Key校验用户登录状态一般需要考虑如何使用户登录状态与JWT保持一致做用户级限流防止有人一顿刷把你 Key 用爆记日志、做监控、加告警部署、上线、写 CI/CD。现在有了火山 Supabase AI-Gateway这些都不需要关心。在前端拿着已经有的session.access_token直接调${SUPABASE_URL}/v1/chat/completions就是完整的鉴权 限流 日志。场景二个人开发者做 AI 应用担心 API Key 暴露在前端背景假设你是一个独立开发者希望快速上线一个 AI 阅读助手产品。“纯前端 Supabase”是最简单的方式但是有一个无法避免问题模型 API Key 不能直接放在浏览器里否则用户随便打开 F12会看到这个Key。传统做法一般是再起一个后端或者用 Serverless Function 做一层中转。这样虽然能解决 Key 暴露的问题但严格意义上来说已经不是纯前端方案了。有了火山 Supabase AI-Gateway。前端拿到用户登录的access_token就能安全调模型。没有任何模型 Key 需要出现在浏览器里因为你要的不是模型 Key而是“这个用户登录了 Supabase”这件事本身。场景三团队要给每个内部用户“限量”用大模型控成本背景公司在内部希望所有员工都能使用AI提高效率但是公司的资金有限不可能给每个团队配置一个共享Key也无法知道每个员工消耗了多少 Token。火山 Supabase AI-Gateway 天然带用户级 Token 限额全局默认限额可以一键给所有用户设一个“每日 Token 上限”单用户可自定义限额重点用户可以给高试点用户给低控制台里能看到每个用户今日消耗、历史消耗、加入时间其实之前要实现这个功能你得自己写库、自己写页面、自己写扣费逻辑。现在它就是火山 Supabase 实例里的一组配置项。三、它跟“自己起个后端转发”到底有什么不一样行内人可能会问这不就是个 AI 网关吗我也能写一个。答案是“能做”和“值得为它单独做”是两回事。火山 Supabase AI-Gateway 给人带来的最大不同之处在于它是与 Supabase Auth、DB、Branch、Workspace 之间是原生粘合的相比自建方案会有明显优势火山引擎 Supabase 的分支能力可对“数据库 配额”一起做分支。比如你创建一个 feature 分支来测试新功能其 Token 用量会被单独统计不会混到生产环境里如果测试过程中发现问题也可以把分支回滚到某个时间点相关配额配置也能跟着回到当时的状态。四、手把手 Demo30 行代码做一个“AI 待办助手”接下来用一个能实际跑通的例子串起来看。我们先做一个AI 待办助手用户登录后输入一个大任务AI 会把它拆成多个更容易执行的小任务并写进 Supabase 数据库再由前端读取和展示。这套流程里不需要额外自研后端模型 Key 也不会出现在前端同时还能保留用户登录态并接上限额和日志能力。Step 0准备一个 Workspace 并打开 AI-Gateway 配额进入火山 Supabase 控制台创建 Workspace或者复用已有的。然后完成一件关键但容易疏忽的事⚠️ 新 Workspace 默认用户 Token 配额是 0——不改的话调用大模型一定会报错报错体形如{error:{message:no quota configured for user,type:quota_exceeded}}。在控制台“限额管理”里把“全局默认每日 Token 限额”设置成一个非 0 的数比如 200000或者给测试账号单独配额再重试即可。顺手记下两个东西SUPABASE_URL形如https://br-xxx.supabase.aidap.cn-beijing.volces.comSUPABASE_ANON_KEY从项目设置里拿到是前端初始化 Supabase 客户端用的Step 1建一张 todos 表在 Supabase SQL 编辑器里跑一段create table if not exists todos ( id uuid primary key default gen_random_uuid(), user_id uuid references auth.users(id) on delete cascade, title text not null, done boolean not null default false, created_at timestamptz not null default now() ); alter table todos enable row level security; create policy own todos on todos for all using (auth.uid() user_id) with check (auth.uid() user_id);熟悉 Supabase 的同学都知道这就是标准的“每人只能看自己的数据”。火山 Supabase AI-Gateway 会复用同一套 Auth后面 AI 的调用也天然带用户身份。Step 2初始化前端 登录前端用最普通的 React Supabase JS SDK。// supabase.ts import { createClient } from supabase/supabase-js export const supabase createClient( https://br-xxx.supabase.aidap.cn-beijing.volces.com, your-supabase-anon-key )登录部分可以直接用 Supabase 提供的 Auth UI或者自己写邮箱密码登录这里省略。Step 3让 AI 帮用户拆任务重点来了安装一下 OpenAI SDKnpm install openai然后写一个函数用当前登录用户的 access_token 直接调用模型。// aiPlanner.ts import OpenAI from openai import { supabase } from ./supabase const SUPABASE_URL https://br-xxx.supabase.aidap.cn-beijing.volces.com export async function planTasks(goal: string) { // 1) 拿到当前用户的登录态 const { data: { session } } await supabase.auth.getSession() if (!session) throw new Error(请先登录) // 2) 把 access_token 当作 API Key 传给 OpenAI SDK const openai new OpenAI({ baseURL: SUPABASE_URL /v1, apiKey: session.access_token, dangerouslyAllowBrowser: true, // 关键允许在浏览器里用 }) // 3) 调用 Doubao 模型 const stream await openai.chat.completions.create({ model: bytedance/doubao-seed-2.0-pro, stream: true, messages: [ { role: system, content: 你是一个任务拆解助手。请把用户的目标拆成 3-6 个可执行的小任务每行一条不要加编号。, }, { role: user, content: goal }, ], }) const tasks: string[] [] let buffer for await (const chunk of stream) { const delta chunk.choices[0]?.delta?.content ?? buffer delta // 边流边解析 const lines buffer.split(\n) buffer lines.pop() ?? for (const line of lines) { const t line.trim() if (t) tasks.push(t) } } if (buffer.trim()) tasks.push(buffer.trim()) return tasks }注意这里发生的事前端全程不知道模型 API Key用的是用户自己的登录 token不需要任何后端OpenAI SDK 直接指向 Supabase 接入地址的/v1模型可换model字段改成doubao-seed-2.0-lite成本降一个数量级代码不变。Step 4把 AI 拆好的任务写进数据库export async function saveTasks(userId: string, tasks: string[]) { const rows tasks.map(t ({ user_id: userId, title: t })) const { error } await supabase.from(todos).insert(rows) if (error) throw error }由于 RLS 策略里限定了user_id auth.uid()即便有人拿走 anon key 想写别人的 todos 也写不进去。Auth 一次配置AI 调用和数据库写入两边都受益。Step 5完整的按钮点击流程async function onGeneratePlan(goal: string) { const tasks await planTasks(goal) // AI 拆解 const { data: { user } } await supabase.auth.getUser() await saveTasks(user!.id, tasks) // 写库 // 触发列表刷新 }一个“输入目标 → AI 拆解 → 存表 → 展示”的完整闭环前端加起来不到 60 行代码没有后端。Step 6想要在 Node 后端跑用 service_role_key如果你的场景是“后端定时任务批量”比如夜里跑一批文档摘要那不适合用用户 access_token用户不在线改用service_role_keyimport os from openai import OpenAI supabase_url https://br-xxx.supabase.aidap.cn-beijing.volces.com service_role_key os.environ[SUPABASE_SERVICE_ROLE_KEY] client OpenAI( base_urlsupabase_url /v1, api_keyservice_role_key, ) resp client.chat.completions.create( modelbytedance/doubao-seed-2.0-pro, messages[{role: user, content: 用一句话解释什么是任务拆解功能}], ) print(resp.choices[0].message.content)⚠️service_role_key绝对不能出现在前端代码、浏览器、公开仓库里。它只能在你可控的后端环境变量里存在。前端场景一律用session.access_token。Step 7对于采用 Vercel AI SDK 的应用仅需调整两行调用配置。如果你已经在用 Vercel AI SDK 做流式渲染直接接过来import { createOpenAICompatible } from ai-sdk/openai-compatible import { streamText } from ai const gateway createOpenAICompatible({ baseURL: SUPABASE_URL /v1, apiKey: session.access_token, name: supabase-ai-gateway, }) const result streamText({ model: gateway(bytedance/doubao-seed-2.0-pro), prompt: 帮我写一段任务拆解的开场白, })协议兼容的意义应用在切换 Gateway 时仅需调整baseURL和apiKey无需改动原有业务逻辑。Step 8去 Logs 看一眼刚才发生了什么在火山 Supabase Dashboard 中进入 Logs 页面将 Collection 选择为 AI-Gateway即可查看此前调用过程中产生的相关日志信息包括请求时间、调用用户、使用模型、Token 消耗以及状态码等内容。平台同时支持按照时间范围、Severity 和 Module 等维度进行筛选并可根据需要导出日志数据。通过这一能力诸如“某个用户为何无法正常调用 AI”或“本周 AI 调用成本是多少”这类问题都可以直接通过日志进行排查和分析无需额外接入独立的观测系统。五、上线前一定要知道的三件小事Demo 跑通真上线之前有三点要注意① 提前配置好配额新 Workspace 中每个用户默认配额为 0。如果首次调用时出现连接失败或quota_exceeded报错通常并不是服务本身异常而是配额尚未设置。上线前应先配置全局默认配额并针对重点用户设置更高的自定义配额。② 配额是后置统计用户 Token 用量会在调用后进行统计和校对因此实际消耗可能会略微超过设定配额。配额更适合作为日常预算管理手段而不应被理解为实时熔断机制。如果业务场景对成本或调用次数有严格限制建议在业务侧增加一层限流或熔断。③ Key 分场景别混用前端 session.access_token后端定时任务 service_role_key接了 Auth0/Firebase/自有 IdP 第三方 JWT。三种 Key 有各自的适用面请注意写错就是一次事故。另外几件“建议但不强制”的实践模型选型分层高质量对话采用 Doubao-Seed-2.0-Pro代码相关使用 Doubao-Seed-2.0-Code聊天气泡以及意图识别等采用 lite/mini降低成本数倍。分支预算隔离试验新功能创建一个子分支在该子分支中使用AI配额由其父分支分配但是从零开始计算如果出现问题回退也十分方便。审计日志留存在一些特殊场合如客服、法务、医疗等应用可将 Logs 中的 AI-Gateway 相关日志接入到您自有的符合要求的日志管理系统中可使用官方提供的导出方式。六、写在最后AI 应用的“最短路径”回到最初的那个场景在产品说“加一个 AI 助手”的时候有经验的开发者都会首先想到一连串的问题是否需要一个服务key 如何存储如何进行限流日志以及审计如何添加等。而现在火山 Supabase AI-Gateway 上线后我们开发就变得十分简便在火山控制台中配置相应额度在前端可以直接使用/v1/chat/completions来发起请求。其实它并不是一种全新的 AI 应用开发方式。它只是把AI应用中最复杂、最繁琐、也是最无用的部分在 Supabase 中提前进行了整合。这样可以让开发者有更多的时间去优化 Prompt设计产品的流程与用户沟通需要解决的问题等而不必花费大量精力在转发服务、Key 管理、调用次数等方面。如果你手上正好有个没落地的 AI 想法不妨从这里开始尝试一下打开火山 Supabase 控制台在30秒内创建一个 Supabase Workspace;查看官方文档模型使用、限额管理以及 APP/Agent 如何通过 AI-Gateway 访问 AI 模型运行上面示例代码。在研发任务列表中删除你要写的“花几周开发AI转发后端”。AI-Gateway 对火山 Supabase 而言只是一小步但是对 AI 应用落地却是缩短一条通往“从想法到可运行”的距离。如果你有在开发 AI 应用、Agent或者是需要“用户 → 模型”都可以试一试这条更加便捷的道路。同时我们也非常愿意听到大家的意见在评论中讨论 Supabase 还有哪些“应当由人来做但是不应该每个人都要去重头开始”的功能可以集成进来。