Supabase替代Firebase：AI配置Auth与Storage模块

在AI应用开发的实践中，越来越多研究者和开发者开始质疑一个看似“理所当然”的选择——使用Firebase作为默认后端。尤其当项目聚焦于轻量级推理模型、学术实验或低成本部署时，Firebase那套封闭架构、按量计费模式和有限可定制性，反而成了负担。

有没有一种更开放、更可控、更适合小团队甚至个人开发者的替代方案？答案是肯定的：Supabase。

它不仅开源、支持私有化部署，还自带PostgreSQL数据库、实时能力、身份认证（Auth）和对象存储（Storage），功能几乎完全对标Firebase，但在灵活性与成本控制上更具优势。更重要的是，它可以无缝集成到AI服务中，为像VibeThinker-1.5B-APP这样的专用小模型提供稳定、安全且可扩展的支撑平台。

为什么是 VibeThinker-1.5B-APP？

这不是一个通用聊天机器人，也不是用来写诗讲故事的玩具模型。VibeThinker-1.5B-APP是微博开源的一款专攻数学推理与算法编程任务的15亿参数语言模型。它的目标很明确：用极低的成本，在高强度逻辑任务中打出高光表现。

你可能要问：1.5B参数能做什么？毕竟现在动辄70B、120B的大模型遍地走。

但关键不在于“多大”，而在于“多准”。这款模型的训练语料高度聚焦于LeetCode题解、Codeforces竞赛代码、AIME数学证明等结构化数据。通过定向微调和链式思维（Chain-of-Thought）优化，它在多个基准测试中甚至超过了某些20B级别的通用模型。

比如，在AIME24数学推理基准上，它的得分达到了80.3，略高于DeepSeek R1的79.8；而在LiveCodeBench编程任务中，其准确率也表现出惊人的一致性。最令人震惊的是——整个训练成本仅约7,800美元。

这意味着什么？意味着我们不再必须依赖昂贵的云端大模型服务来完成专业级推理任务。一台配备消费级GPU（如RTX 3090/4090）的机器就能跑起来，本地部署、快速响应、无需联网，真正实现“边缘AI”。

不过，这样的模型也有局限：

它对中文输入不够友好，建议全程使用英文提问；
没有预设角色行为，必须显式设置系统提示词（system prompt），否则容易“发呆”或输出无关内容；
不适合做情感分析、摘要生成这类通用NLP任务。

换句话说，它是“工具型AI”的典范：不全能，但够专精。

如何让用户安全访问这个模型？

设想一下场景：你把模型部署好了，开了个Web界面让大家上传题目求解。结果第二天发现服务器资源被耗尽——有人写脚本疯狂调用接口，还有人试图上传恶意代码。怎么办？

这就引出了核心问题：如何构建一套轻量但可靠的身份认证机制？

传统做法是自己从零实现登录注册、密码加密、会话管理……但这不仅耗时，还极易出错。而Supabase Auth的存在，正是为了让我们跳过这些重复劳动。

它基于OAuth 2.0和JWT协议，开箱即用地支持邮箱/密码登录、Google/GitHub第三方认证，所有用户信息都存在PostgreSQL的auth.users表里，你可以直接用SQL查询、修改甚至添加自定义字段（比如用户积分、订阅等级）。而且，这一切都不需要你去处理JWT签发、刷新令牌、黑名单管理这些复杂细节。

前端只需几行代码即可完成认证流程：

import { createClient } from '@supabase/supabase-js' const supabase = createClient('https://your-project.supabase.co', 'your-anon-key') async function signIn(email, password) { const { data, error } = await supabase.auth.signInWithPassword({ email, password }) if (error) { console.error('登录失败:', error.message) return null } return data.user }

一旦用户登录成功，Supabase就会自动将JWT保存在浏览器本地，并在后续请求中自动携带。你的AI服务端可以通过Supabase SDK验证该Token的有效性，确认用户身份后再放行推理请求。

更进一步，你可以利用Supabase的RBAC（基于角色的访问控制）机制，轻松实现免费用户与付费用户的权限隔离。例如：

免费用户每小时最多调用10次；
付费用户可上传批量问题文件，享受优先队列处理；
管理员可以查看全局日志、导出统计数据。

这种细粒度的权限控制，在Firebase中也能实现，但往往需要配合Cloud Functions和Firestore规则手动编写；而在Supabase中，大部分逻辑都可以通过SQL策略或内置API完成，工程成本显著降低。

推理结果怎么存？谁能看到？

另一个现实问题是：用户的每一次提问和模型返回的答案，是否应该保留？如果保留，如何确保数据归属清晰、隐私安全？

想象一个学生用VibeThinker解决数学题，希望一个月后还能回看自己的解题记录。或者一位程序员想复用某个生成的算法模板。这时候，持久化存储就成了刚需。

Supabase Storage 正好填补了这一空白。它本质上是一个兼容S3协议的对象存储系统，允许你创建多个“桶”（Bucket）来分类管理文件。比如：

prompt_templates：存放常用提示词模板；
inference_results：保存每次推理输出的结果；
debug_logs：记录错误堆栈或性能指标。

更重要的是，它和Auth深度集成。你可以通过RLS（行级安全策略）定义严格的访问规则。例如：

-- 只允许用户读写自己目录下的文件 CREATE POLICY "User can manage own files" ON storage.objects FOR ALL USING (bucket_id = 'inference_results' AND auth.uid() = owner) WITH CHECK (bucket_id = 'inference_results' AND auth.uid() = owner);

这样一来，即使两个用户知道彼此的文件路径，也无法越权访问。安全性由数据库层面保障，而不是靠前端隐藏URL。

Python客户端上传文件也非常直观：

from supabase import create_client import os url = os.environ.get("SUPABASE_URL") key = os.environ.get("SUPABASE_KEY") supabase = create_client(url, key) def upload_inference_result(user_id: str, result: str, filename: str): with open(filename, "w") as f: f.write(result) with open(filename, "rb") as f: supabase.storage.from_("inference_results").upload( file=f, path=f"{user_id}/{filename}", file_options={"content-type": "text/plain"} ) print(f"结果已保存至：{user_id}/{filename}")

这段代码会把模型输出的内容写入临时文件，再上传到对应用户的专属目录下。结合前端的历史记录页面，用户就能随时查阅过往交互。

此外，Storage还支持分片上传、版本控制、CDN加速和生命周期自动清理。比如你可以设定“超过30天的日志文件自动删除”，避免存储无限膨胀。

整体架构如何设计？

完整的系统其实并不复杂，可以用三层结构概括：

+------------------+ +---------------------+ | Web Frontend |<----->| Supabase Backend | | (React/Vue) | HTTPS | - Auth: 用户认证 | +------------------+ | - Storage: 文件存储 | | - Realtime: 状态同步 | +----------+-----------+ | | 私有网络 v +-----------------------+ | AI Inference Server | | - VibeThinker-1.5B-APP| | - Gradio/FastAPI | +-----------------------+