Vercel Fluid Compute：统一计算基础设施的新范式

一个系统,四种形态

Vercel 近期提出了一个颇具启发性的观点:沙箱(sandbox)、函数(function)、构建(build)和服务器(server),这四种看似截然不同的计算形态,其实都是同一套底层计算基础设施的不同表达方式。

Vercel背景补充: Vercel是一家专注于前端开发者体验的云平台公司,最初以Next.js框架的商业化部署而闻名。其核心产品提供了从代码推送到全球部署的完整工作流,主打零配置和极致性能。Vercel的技术栈深度绑定边缘计算网络,在全球数十个节点部署内容和函数,这使得它在处理动态请求时能够就近响应。作为Serverless架构的重要推动者,Vercel一直在探索如何让开发者彻底摆脱服务器运维,而Fluid Compute正是这一理念在基础设施层面的最新演进。

这个论断背后是 Vercel 的 Fluid Compute 系统。用官方的话说,Fluid Compute 是「一个能按需创建你的工作负载所需机器的系统」。换句话说,开发者不再需要为不同类型的任务去选择、配置和管理不同的运行环境,而是由一套统一的引擎在背后动态调度。

这一理念的价值,在于它试图消解现代云计算中长期存在的一个痛点:碎片化。

为什么碎片化是个问题

传统架构下的多套系统

在传统的云开发流程里,一个应用往往要同时依赖多种计算资源:

无服务器函数(Serverless Functions):处理短时、事件驱动的请求
长期运行的服务器(Servers):承载需要持续在线的服务
构建流程(Builds):在部署阶段编译、打包代码
沙箱环境(Sandboxes):隔离执行不受信任的代码,比如 AI 生成的代码或用户提交的脚本

Serverless Functions深度解析: 无服务器函数并非真的没有服务器,而是将服务器管理完全交给云平台。开发者只需编写业务逻辑代码,平台负责自动扩缩容、负载均衡和故障恢复。这种模式诞生于AWS Lambda(2014年),彻底改变了后端开发范式。其核心特征是按实际执行时间计费(通常精确到100毫秒)、事件驱动触发(HTTP请求、数据库变更、定时任务等)以及自动弹性伸缩。但它也有明显限制:单次执行时长上限(通常5-15分钟)、冷启动延迟(首次调用可能需要数百毫秒到数秒)、以及无状态特性(每次调用间不保留内存状态)。这些约束塑造了Serverless应用的独特架构模式。

沙箱技术深度解析: 沙箱是一种受限的执行环境,用于隔离不受信任的代码运行。其核心原理是通过操作系统级或虚拟化技术限制进程的资源访问权限——包括文件系统、网络、系统调用等。在云计算场景中,常见的沙箱技术包括容器(Docker/containerd)、微虚拟机(Firecracker/gVisor)以及WebAssembly运行时。AI时代对沙箱的需求激增:当大模型生成代码需要立即执行、或者Agent调用外部工具时,必须确保恶意代码无法窃取数据或攻击宿主系统。现代沙箱追求毫秒级启动速度和极低的资源开销,这使得它们可以按需创建和销毁,成为动态工作负载的理想载体。

每一种资源背后通常都是独立的调度逻辑、独立的计费模型和独立的运维心智负担。开发者要在冷启动延迟、资源利用率、成本控制之间反复权衡,而这些权衡往往只是因为底层跑的是不同的系统。

统一带来的想象空间

Fluid Compute 的核心主张是:这些差异其实是表层的。无论是一次函数调用、一次构建任务,还是一个常驻服务,本质上都是「在某个时刻需要某种规格的计算资源来执行一段工作负载」。如果底层能够以统一的方式按需生成这些机器,那么上层的形态差异就只是配置和生命周期的不同,而非架构的割裂。

Fluid Compute 的技术意义

从「预分配」到「按需生成」

Fluid Compute 强调「on demand(按需)」地创建工作负载所需的机器。这意味着资源不是提前静态划分好的,而是根据实际请求动态实例化。这种模式的直接好处包括:

更高的资源利用率:闲置时不占用资源,避免为峰值容量长期买单
更平滑的扩缩容:从零到大规模并发之间的过渡更自然
降低冷启动成本:统一的运行时可以通过实例复用等手段缓解传统 Serverless 的冷启动痛点

冷启动问题深度解析: 冷启动是Serverless架构最被诟病的性能瓶颈。当一个函数长时间未被调用时,云平台会回收其运行实例以节省资源。下次请求到来时,平台需要重新分配容器或虚拟机、加载运行时环境、初始化应用代码和依赖库,这整个过程可能耗时几百毫秒到数秒。对于延迟敏感的应用(如API服务、实时交互),这是不可接受的。业界的优化手段包括:预留实例(Provisioned Concurrency)保持部分容器常驻、轻量级运行时(如Deno/Bun)减少初始化时间、实例复用和快照恢复技术。Fluid Compute声称能缓解冷启动,可能依赖了统一运行时池化和智能预热机制。

边缘计算补充: 边缘计算是指将计算资源部署在靠近用户的网络边缘节点,而非集中式数据中心。这种架构显著降低了网络延迟——例如从跨洲的200ms降至同城的10ms以内。Vercel的全球边缘网络覆盖数十个城市,函数和静态资源都可以在边缘节点执行和分发。但边缘计算也带来新挑战:节点间状态同步困难、数据库访问延迟增加(需要连接回中心区域)、以及调试和监控的复杂度提升。Fluid Compute的统一抽象可能简化了边缘和中心节点的工作负载调度——系统根据请求来源和资源需求,自动决定在哪个层级创建计算实例。

为 AI 时代的工作负载铺路

说个细节,Fluid Compute 中「沙箱」被明确列为一等公民。在 AI 应用爆发的当下,运行由大模型生成的代码、执行 Agent 的工具调用、隔离用户提交的脚本,都对安全隔离的按需计算环境提出了强需求。

AI Agent工作负载特征: AI Agent(智能代理)代表了新一代应用架构:由大语言模型驱动,能自主规划任务、调用工具并迭代执行。其工作负载特征与传统应用截然不同:高度动态(每次对话的执行路径不可预测)、工具密集(可能需要调用搜索、代码执行、API等数十种工具)、突发性强(用户问题触发时才启动,可能几秒内调用十几次函数)。这要求基础设施具备极快的冷启动、细粒度的资源隔离(防止恶意生成代码攻击系统)以及灵活的计费模式(按实际token消耗和工具调用计费)。Vercel将沙箱提升为一等公民,正是看到了这类工作负载在未来的爆发潜力。

一个能够快速拉起隔离沙箱、执行完即回收的系统,恰好契合了 AI Agent 时代「动态、短时、高并发」的计算特征。这或许也是 Vercel 将沙箱与函数、服务器并列的深层动机——它们瞄准的是下一代 AI 原生应用的基础设施底座。

一种正在成型的行业趋势

计算原语的收敛

Vercel 的这一表述,反映了云基础设施领域一个更宏大的趋势:计算原语的收敛。过去十年,云厂商不断推出新的产品形态(容器、函数、边缘计算、构建服务等),开发者的认知负担随之增加。而现在,头部平台开始反向思考——能否用一套统一的抽象来覆盖这些形态?

容器与虚拟机技术权衡: 容器和虚拟机是云计算中两种主要的隔离技术。虚拟机通过Hypervisor模拟完整的硬件环境,每个VM运行独立的操作系统内核,隔离性最强但启动慢(通常需要数十秒)且资源开销大。容器则共享宿主机内核,通过namespace和cgroups实现进程级隔离,启动快(秒级)且轻量,但安全性略弱。近年出现的微虚拟机(如AWS Firecracker)试图结合两者优势:用KVM提供VM级别的隔离,但精简Guest OS到最小化,实现100-200ms的启动时间。Fluid Compute可能采用了混合策略——函数用轻量级容器、沙箱用微虚拟机、长期服务器用传统VM——但通过统一调度层向开发者屏蔽差异。

对开发者而言,理想状态是「只描述我要做什么,不关心它跑在哪种机器上」。Fluid Compute 正是朝这个方向迈进的一次尝试。

平台的护城河逻辑

从商业角度看,这样的统一系统也强化了平台的黏性。当沙箱、函数、构建、服务器都由同一套引擎驱动时,开发者迁移的成本、跨形态协作的顺畅度、以及整体成本模型的透明度,都成为平台差异化竞争的关键。谁能把底层的复杂性藏得最好,谁就能赢得开发者的心智。

值得关注的问题

当然,这一愿景仍有待更多细节验证。统一系统在带来便利的同时,也可能引入抽象泄漏——当不同工作负载的性能特征差异巨大时,「一套系统包打天下」的承诺能否真正兑现?

抽象泄漏的工程现实: 抽象泄漏是软件工程中的经典问题,由Joel Spolsky提出:所有非平凡的抽象在某种程度上都是有漏洞的。当底层实现的复杂性穿透抽象层暴露给用户时,就发生了泄漏。在云计算中典型案例包括:Serverless函数声称无需关心服务器,但开发者仍需理解冷启动、执行时长限制、并发模型等底层细节才能优化性能;容器编排平台抽象了资源调度,但网络分区、节点故障时仍需理解Pod重启策略。Fluid Compute的'一套系统包打天下'承诺面临同样风险——当CPU密集型构建任务和毫秒级响应的函数共用底层时,如何保证性能隔离?统一抽象是否会掩盖关键的性能特征差异?

此外,按需生成机器的实际延迟表现、成本可预测性,以及对复杂长时任务的支持能力,都是开发者在落地前需要审慎评估的。

无论如何,Fluid Compute 所代表的「统一计算抽象」思路,指向了云基础设施演进的一个清晰方向。对于身处 AI 应用浪潮中的开发者而言,理解这种底层范式的转变,或许比追逐单个产品功能更有长远价值。