月处理5000万请求，Interfaze如何用Vercel重构AI后端

当大多数AI创业公司还在为GPU集群和推理延迟焦头烂额时，一家名为Interfaze的公司选择了一条截然不同的路径：把整个后端——包括模型API、代码沙箱和供应商路由——全部跑在Vercel上。每月5000万次请求的背后，没有独立的Kubernetes集群，没有专职的运维团队，只有一组serverless函数和几个精心挑选的Vercel产品。

确定性模型：在LLM不擅长的地方建立护城河

Interfaze的定位颇为反直觉。它不做通用的对话模型，而是专注于那些通用LLM表现糟糕的确定性任务：文档处理、OCR、目标检测、网页抓取、语音转文字和分类。

创始人Yoeven Khemlani的解释一针见血："大多数模型本质上不是确定性的。写文章时这没关系，但医院或法务团队处理文档时，你不会去用LLM。"他举了一个具体的例子——让LLM计算发票总额，你得到一个数字，却无法轻松验证它从何而来。Interfaze的模型返回的不仅是数字，还包括页面上的边界框（标明数字来源位置）和置信度分数。每个结果都可核查，同时模型仍像LLM一样接受提示词。

这种"可验证的输出"在医疗、法律和金融场景中具有刚性价值。这些行业的工程团队需要的是能审计、能追溯的AI结果，而非一个黑箱概率。Interfaze的客户画像恰好锁定在这三个领域。

后端零基础设施：一个文件夹就是一个后端

Interfaze的前端和后端都运行在Vercel上，全部以serverless函数的形式存在于同一个代码库中。API请求、文件上传、模型调用，都走同一套部署体系。当请求需要计算时，模型将代码交给Vercel Sandbox隔离执行。

Khemlani对比了其他平台的体验："在其他平台上，搭建后端意味着先搞定网络、安全和函数限制，然后才能服务第一个请求。在Vercel上，我建一个文件夹，就有了后端。"

这种开发体验的差异，对早期团队而言是实实在在的时间成本。没有独立的日志供应商需要配置，没有负载均衡器需要调优，预览部署自动携带独立的日志和URL。Interfaze同时运行多个模型版本，每个版本有自己的URL——当错误发生时，日志已经按版本归档，排查路径清晰。

Serverless 函数与冷启动

Serverless 函数是一种由事件触发、按需运行的计算模型，开发者无需预置或管理服务器。平台负责弹性伸缩和可用性，并按实际调用次数与资源消耗计费。其代价是冷启动：函数长时间未被调用后，平台会回收实例，下次请求需重新初始化运行时环境，带来额外延迟。对于 Interfaze 这类承接 API 请求和模型调用的后端，冷启动直接影响首字节时间。Vercel 通过 Fluid compute 等机制复用实例、减少冷启动频率，这也是它敢于承载生产流量的前提之一。

Vercel Sandbox

Vercel Sandbox 是 Vercel 提供的隔离代码执行环境，允许在受控容器中运行不可信或动态生成的代码。它常用于 AI Agent 场景：模型生成的代码需要被执行，但又不能影响主服务。Sandbox 提供文件系统、网络和资源配额的限制，执行结果以结构化形式返回。Interfaze 把模型需要计算的部分交给 Sandbox 隔离运行，既保证了安全性，又避免了在主函数中引入不受控的执行逻辑。

Fluid compute与AI Gateway：重活与路由的两块拼图

可扩展性是Khemlani的首要需求。目标是把模型服务给数百万用户，而Vercel的Fluid compute随流量自动伸缩。更关键的是，它承载了真正吃资源的工作负载。

Interfaze的网页抓取基于Puppeteer运行，这对内存和超时限制要求很高。Khemlani坦言："我们从没想过用Vercel做后端。Fluid compute底下是真正的Node.js服务器，所以即使是最重的工作负载也能直接跑。"

另一块拼图是AI Gateway。Interfaze将大量数据清洗任务分发给第三方供应商托管的开源模型。单一供应商是薄弱环节——限流或宕机时，清洗就会停摆，除非流量能自动切换。更微妙的问题是，两个供应商声称托管同一个开源模型，实际服务质量可能差异巨大。Khemlani指出："一个跑4-bit，一个跑8-bit。用AI Gateway我们可以在它们之间路由，看谁实际表现更好。"

AI Gateway在供应商失败或限流时自动故障转移，同时允许Interfaze为特定模型选择服务商，通过实际负载测试来分配流量。这套机制把"多供应商容灾"从工程负担变成了配置项。

Fluid compute 与 AI Gateway 的技术定位

Fluid compute 是 Vercel 对 serverless 执行模型的一种扩展，它在底层保留真实的 Node.js 运行时，并允许实例在请求之间复用，从而缓解冷启动、支持更长的执行时间和更高的内存上限。传统 serverless 函数通常有严格的超时和内存限制，而 Puppeteer 这类浏览器自动化工具需要持续的内存和较长的运行窗口，Fluid compute 正是为这类重负载设计的。

AI Gateway 则是位于应用与模型供应商之间的路由层。它统一了不同供应商的 API 协议，提供密钥管理、用量统计、限流和故障转移。对 Interfaze 而言，AI Gateway 的价值在于把“多供应商容灾”和“按质量路由”从自建工程变成了配置项：当某个供应商限流或宕机时，网关自动切换；当同一开源模型存在不同量化版本时，网关允许按实际表现分配流量。

Workflow SDK：跨越数月的邮件序列

Interfaze的生命周期邮件系统建立在Workflow SDK上，发送条件取决于产品使用情况——追踪客户调用了哪个API、调用量多少、与第一周相比如何变化。重试自动处理，单个步骤失败不会拖垮整个序列。

团队最看重的是持久化执行（durable execution）：工作流可以暂停一个步骤，数月后带着完整状态恢复。Khemlani表示其他系统无法做到如此长时间的保持。对于需要观察用户长期行为再触发触达的SaaS产品，这个能力直接决定了运营策略的可行性。

持久化执行（Durable Execution）

持久化执行是一种工作流编排模式：工作流的每一步状态都被持久化存储，进程中断后可以从最后一个成功步骤恢复，而不必从头重跑。它通常通过事件日志或状态机实现，使长时间运行、跨天甚至跨月的工作流具备故障恢复能力。与普通函数调用不同，持久化执行保证了“恰好一次”或“至少一次”的步骤语义，并支持暂停与恢复。Interfaze 的邮件序列依赖这一能力：系统可以暂停在某个步骤，数月后带着完整上下文继续执行，而无需保持进程常驻。这对于需要观察用户长期行为再触发触达的 SaaS 产品至关重要。

预览部署：模型版本的客户共创通道

Interfaze的发布流程值得单独一看。新模型版本就是一个新分支，Vercel侧构建约三分钟——慢的是GPU上托管权重。构建完成后，团队把预览URL发给少数客户，测试一个月后再合并。

这套流程把"客户共创"嵌入了工程管线。错误归属也因部署隔离而简化：每个URL有自己的日志，报错天然挂在导致它的版本名下。对于同时维护多个模型版本、需要快速定位回归问题的团队，这种结构省去了大量排查成本。

预览部署与分支构建

预览部署是 Vercel 的核心工作流之一：每次向代码仓库推送分支，平台会自动构建并生成一个带独立 URL 的临时环境，供团队或客户在合并前验证。每个预览环境拥有独立的日志、环境变量和域名，互不干扰。这种机制把“版本隔离”变成了默认行为。对于 Interfaze 这样同时维护多个模型版本的团队，每个版本对应一个分支和 URL，错误日志天然按版本归档，回归问题可以快速定位到具体版本，而不必在共享环境中排查。

下一步：搜索网关与开放权重

Interfaze近期发布了Interfaze 1 Lite，一个可在单GPU上运行的开放权重版本，通过同一API提供服务。下一步是网页搜索网关——一个API路由到开发者选择的搜索供应商，模式与AI Gateway对模型所做的一样，同样跑在现有的Vercel后端上。

从这家公司的技术选择中可以看到一个信号：AI应用的后端基础设施正在从"自建集群"向"托管原语"迁移。当serverless的计算限制、内存上限和超时窗口足以覆盖Puppeteer抓取这类重活时，创业团队把精力集中在模型质量和客户验证上，而不是运维上，成为更理性的资源配置。Interfaze的5000万月请求是一个可参考的样本——它证明了Vercel这套栈在AI后端场景中的实际承载能力，也暴露了其适用边界：重GPU推理仍然在别处，Vercel承接的是围绕模型的编排层。