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

一个系统,四种形态

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

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

从行业坐标来看，Vercel 的竞争对手和同类平台也在朝相似方向探索。Cloudflare Workers 基于 V8 Isolate 实现了极轻量的边缘函数执行；Fly.io 主打全球分布式的微虚拟机部署；Deno Deploy 则试图通过统一的 JavaScript 运行时消除部署复杂性。但 Vercel 的独特之处在于它同时掌握了框架层（Next.js 拥有超过 12 万 GitHub Star，是 React 生态最主流的全栈框架）和基础设施层——这种垂直整合意味着它可以在框架编译阶段就感知代码的运行时特征（哪些路由是静态的、哪些需要服务端渲染、哪些是 API 端点），从而在部署时自动将不同部分分配到最合适的计算形态。Fluid Compute 本质上是将这种「框架感知的智能部署」从应用层下沉到基础设施层的系统性工程。

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

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

为什么碎片化是个问题

传统架构下的多套系统

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

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

这些概念看似清晰，但每一种都承载着深厚的技术背景和设计取舍。

无服务器函数并非真的没有服务器，而是将服务器管理完全交给云平台。开发者只需编写业务逻辑代码，平台负责自动扩缩容、负载均衡和故障恢复。这种模式诞生于 2014 年 AWS 发布 Lambda 服务，彻底改变了后端开发范式。其核心特征是按实际执行时间计费（通常精确到毫秒级）、事件驱动触发（HTTP 请求、数据库变更、消息队列、定时任务等）以及自动弹性伸缩（从零到数千并发实例）。但它也有明显限制：单次执行时长上限（通常 5-15 分钟）、冷启动延迟（首次调用可能需要数百毫秒到数秒）、以及无状态特性（每次调用间不保留内存状态）。这些约束塑造了 Serverless 应用的独特架构模式——函数必须短小精悍、幂等可重试，复杂的有状态逻辑需要借助外部存储来协调。

值得一提的是，Serverless 的演进并非线性的。2014 年 Lambda 发布后，各大云厂商迅速跟进：Google Cloud Functions（2016）、Azure Functions（2016）、阿里云函数计算（2017）。但早期的 Serverless 主要局限于简单的事件处理场景——处理一次 Webhook、转换一张图片、发送一封邮件。随着开发者对 Serverless 期望的提升，行业逐渐暴露出「Serverless 鸿沟」：理论上的无限弹性与实际中的冷启动延迟、VPC 网络初始化缓慢、并发限制配额等问题之间的差距。这种落差催生了「Serverless 2.0」的探索——包括 Vercel 的 Fluid Compute、Cloudflare 的 Workers 平台、以及 AWS 在 Lambda 上持续推出的 SnapStart（基于快照的冷启动优化）和 Response Streaming（流式响应）等能力。本质上，Fluid Compute 是 Serverless 理念的下一步逻辑延伸：既然我们已经抽象掉了「服务器」这个概念，为什么不把函数、构建、沙箱、长驻服务之间的边界也一并抽象掉？

沙箱环境则是一种受限的执行环境，通过操作系统级或虚拟化技术限制进程的资源访问权限——包括文件系统、网络、系统调用等。在云计算场景中，常见的沙箱实现技术构成了一个从轻量到重量的谱系：容器（Docker/containerd）提供进程级隔离、微虚拟机（AWS Firecracker、Google gVisor）提供接近虚拟机的安全性但保持轻量启动、WebAssembly 运行时则在语言级别实现内存安全的沙箱化。AI 时代对沙箱的需求正在激增：当大模型生成的代码需要立即执行验证、当 Agent 调用外部工具操作文件系统、或者用户在平台上提交自定义脚本时，都必须确保恶意代码无法窃取数据或攻击宿主系统。现代沙箱追求毫秒级启动速度和极低的资源开销，这使得它们可以按需创建和销毁，成为动态工作负载的理想载体。

构建流程在现代 Web 开发中同样扮演着至关重要的角色，但它的计算特征与函数和服务器截然不同。一次典型的前端构建可能包括：TypeScript 编译为 JavaScript、CSS 预处理和压缩、图片优化和格式转换、代码分割和树摇（Tree Shaking）去除无用代码、生成静态页面（SSG）或预渲染路由。这类工作负载的特点是 CPU 和 I/O 密集、执行时间从几十秒到几十分钟不等、完成后即可回收资源。传统上，构建任务运行在 CI/CD 系统（如 GitHub Actions、Jenkins）提供的临时虚拟机中，与应用运行时完全隔离。将构建纳入 Fluid Compute 的统一调度意味着——构建任务可以与函数和服务器共享同一个资源池，平台可以根据构建的复杂度动态分配 CPU 和内存规格，而非使用固定配置的 CI 机器。这不仅提高了资源利用率，还可能实现更智能的增量构建：平台感知到哪些文件变更了，只重建受影响的部分，其余复用缓存。

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

统一带来的想象空间

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

这种思路在计算机科学中并非首创。历史上，操作系统层面的「进程」就是对不同工作负载的统一抽象——无论是短命的命令行工具还是长驻的守护进程，操作系统都用进程这个统一原语来管理它们的资源分配、调度和生命周期。Fluid Compute 可以被视为云时代对这种理念的升维：正如操作系统用进程抽象了 CPU 和内存的分配，Fluid Compute 试图用统一的「工作负载」抽象来管理跨地域、跨规格的分布式计算资源。区别在于，操作系统管理的是单机上的资源，而 Fluid Compute 管理的是全球网络中数十个数据中心和边缘节点上的异构资源池。

Fluid Compute 的技术意义

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

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

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

关于冷启动，值得深入展开。冷启动是 Serverless 架构最被诟病的性能瓶颈。当一个函数长时间未被调用时，云平台会回收其运行实例以节省资源。下次请求到来时，平台需要完成一系列串行操作：分配容器或虚拟机、下载并加载运行时环境（Node.js、Python 等）、初始化应用代码和依赖库、建立网络连接和数据库连接池。这整个过程可能耗时几百毫秒到数秒，对于延迟敏感的应用（如实时 API 服务、交互式对话界面）来说是不可接受的。业界已经发展出多种优化手段：预留实例（Provisioned Concurrency）保持部分容器常驻但成本上升、轻量级运行时（如 Deno、Bun）通过精简启动流程减少初始化时间、以及基于 CRIU（Checkpoint/Restore In Userspace）的快照恢复技术直接从内存镜像恢复函数状态。Fluid Compute 声称能缓解冷启动，很可能依赖了统一运行时池化（多种函数共享预热的运行时实例）和智能预热机制（基于历史调用模式预测性地启动实例）。

其中 CRIU 技术值得单独说明。CRIU 是一个 Linux 项目，能够将正在运行的进程「冻结」为磁盘上的一组镜像文件（包括内存页、文件描述符、网络连接等完整状态），之后可以从这些镜像文件恢复进程到冻结时的精确状态。这项技术最初用于容器的实时迁移（将运行中的容器从一台物理机迁移到另一台而不中断服务），后来被 AWS 引入 Lambda 的 SnapStart 功能——在函数首次部署时完成初始化并拍摄快照，后续冷启动时直接从快照恢复，将 Java 函数的冷启动时间从 10 秒以上降低到几百毫秒。如果 Fluid Compute 在内部使用了类似技术，它可以在函数初始化完成后保存快照，当同一函数再次被调用时，跳过整个初始化过程直接从快照恢复，实现近乎「零冷启动」的体验。

此外，Fluid Compute 的「按需生成」也与边缘计算紧密关联。边缘计算是指将计算资源部署在靠近用户的网络边缘节点，而非集中式数据中心。这种架构显著降低了网络延迟——例如从跨洲传输的 200ms 降至同城的 10ms 以内。Vercel 的全球边缘网络覆盖数十个城市，函数和静态资源都可以在边缘节点执行和分发。但边缘计算也带来新挑战：节点间状态同步困难（CAP 定理的约束）、数据库访问延迟增加（边缘函数仍需连接回中心区域的数据库）、以及调试和监控的复杂度提升（日志分散在数十个节点）。Fluid Compute 的统一抽象可能简化了边缘和中心节点的工作负载调度——系统根据请求来源的地理位置、资源需求的规格以及数据依赖的位置，自动决定在哪个层级创建计算实例，开发者无需手动指定部署区域。

这里提到的 CAP 定理是分布式系统的基石理论，由加州大学伯克利分校的 Eric Brewer 在 2000 年提出：在一个分布式系统中，一致性（Consistency，所有节点在同一时刻看到相同数据）、可用性（Availability，每个请求都能收到响应）和分区容错性（Partition Tolerance，网络分区时系统仍能运行）三者最多只能同时满足两个。在边缘计算场景中，这个定理的影响尤为直观：当全球数十个边缘节点需要共享状态（如用户会话、功能开关配置）时，网络分区是家常便饭（跨洲链路偶尔会出现丢包或延迟飙升），系统必须在「保证所有节点数据一致但部分请求被阻塞」和「允许节点间短暂不一致但所有请求都能响应」之间做出选择。这也解释了为什么许多边缘优先的应用采用「最终一致性」模型，以及为什么将有状态逻辑放在边缘节点是一件复杂的事情。

为 AI 时代的工作负载铺路

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

理解这一点，需要认识到 AI Agent 的工作负载特征与传统应用截然不同。AI Agent（智能代理）代表了新一代应用架构：由大语言模型驱动，能自主规划任务、调用工具并迭代执行。例如，一个编程 Agent 可能接收用户的自然语言需求，先调用 LLM 生成方案，再调用代码执行沙箱验证方案，然后根据执行结果多轮迭代修正。这种工作负载具有三个显著特征：高度动态（每次对话的执行路径不可预测，可能触发完全不同的工具组合）、工具密集（单次任务可能需要调用搜索引擎、代码执行器、数据库查询、文件操作等数十种工具）、突发性强（用户问题触发时才启动，可能几秒内连续调用十几次函数然后彻底沉默）。传统的预分配服务器在空闲时浪费资源，传统的 Serverless 函数在连续快速调用时面临反复冷启动——两者都无法高效支撑这种「阵发式多工具调用」的模式。

更具体地说，AI Agent 的工具调用模式（通常称为 Function Calling 或 Tool Use）正在催生一种全新的计算调度需求。以 OpenAI 的 Function Calling 机制为例：大模型在推理过程中决定调用哪个外部工具，生成结构化的调用参数，应用层执行调用后将结果返回模型继续推理。一次复杂的 Agent 任务（如「帮我分析这个 GitHub 仓库的代码质量并生成报告」）可能产生如下调用链：克隆代码仓库（需要文件系统沙箱）→ 运行静态分析工具（需要安装依赖的沙箱）→ 执行测试套件（需要更大规格的计算实例）→ 调用 LLM 总结分析结果（需要 GPU 或 API 调用）→ 生成 PDF 报告（需要渲染引擎）。这条调用链中每一步的资源需求都不同、执行时间从毫秒到分钟不等、且链条的具体步骤在执行前无法完全预测。Fluid Compute 的统一调度器正是为这种异构、动态、不可预测的工作负载链条而设计的——它可以在毫秒级粒度上为每一步创建最合适的计算环境，而不需要开发者预先规划和预分配资源。

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

一种正在成型的行业趋势

计算原语的收敛

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

这种收敛的背后，是隔离技术本身的演进为统一成为可能。容器和虚拟机是云计算中两种主要的隔离技术，它们代表了安全性与性能之间不同的权衡点。虚拟机通过 Hypervisor 模拟完整的硬件环境，每个 VM 运行独立的操作系统内核，隔离性最强但启动慢（通常需要数十秒）且资源开销大（每个 VM 至少消耗几百 MB 内存）。容器则共享宿主机内核，通过 Linux namespace（隔离进程视图）和 cgroups（限制资源配额）实现进程级隔离，启动快（秒级甚至亚秒级）且轻量，但安全边界弱于 VM（共享内核意味着内核漏洞可能导致逃逸）。近年出现的微虚拟机（如 AWS Firecracker，最初为 Lambda 开发）试图结合两者优势：使用 KVM 提供 VM 级别的硬件隔离，但将 Guest OS 精简到最小化的 Linux 内核，实现 125ms 的启动时间和仅 5MB 的内存开销。Fluid Compute 可能采用了混合隔离策略——对延迟敏感的函数使用轻量级容器或 WebAssembly、对安全要求高的沙箱使用微虚拟机、对资源密集的构建任务使用更大规格的实例——但通过统一的调度和抽象层向开发者完全屏蔽这些底层差异。

除了隔离技术的演进，WebAssembly（Wasm）的崛起也是推动计算原语收敛的关键力量。WebAssembly 最初由 W3C 设计为浏览器中的高性能执行格式，但它的设计特性——跨平台二进制格式、接近原生的执行速度、内置的内存安全沙箱、极小的运行时体积——使其迅速扩展到服务端和边缘计算场景。WASI（WebAssembly System Interface）标准为 Wasm 模块提供了标准化的系统接口（文件、网络、时钟等），使得 Wasm 程序可以脱离浏览器在任何符合标准的运行时上执行。Docker 联合创始人 Solomon Hykes 曾说：「如果 WASM + WASI 在 2008 年就存在，我们就不需要创造 Docker 了。」这句话揭示了 Wasm 在计算原语收敛中的潜在角色——它可能成为比容器更轻量、比进程更安全的通用执行单元，天然适合作为 Fluid Compute 这类统一计算系统的底层执行格式。Cloudflare Workers 已经在生产环境中使用基于 V8 Isolate（与 Wasm 共享底层技术）的轻量隔离，实现了零冷启动和亚毫秒级的执行启动时间。

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

平台的护城河逻辑

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

这种平台黏性策略在科技行业有深刻的历史先例。微软通过 Windows + Office + Azure 的生态绑定，使得企业一旦深入使用就极难迁移；AWS 通过 Lambda + API Gateway + DynamoDB + S3 的服务组合，让 Serverless 应用与 AWS 生态深度耦合。Vercel 的策略更为精妙——它的黏性不是来自专有 API 或数据格式的锁定，而是来自开发者体验的优越性和框架层面的深度集成。Next.js 应用可以在任何 Node.js 环境运行，但在 Vercel 上运行时能自动获得边缘缓存、增量静态再生（ISR）、图片优化等平台独有的性能加持。Fluid Compute 进一步加深了这种「体验锁定」：当开发者习惯了「推送代码即可，平台自动决定用函数还是服务器还是沙箱」的工作流后，回到需要手动选择和配置计算形态的传统平台就会感到明显的摩擦。这是一种更温和但更持久的护城河。

值得关注的问题

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

抽象泄漏是软件工程中的经典问题，由程序员兼作家 Joel Spolsky 在 2002 年提出：**所有非平凡的抽象在某种程度上都是有漏洞的。**当底层实现的复杂性穿透抽象层暴露给用户时，抽象就发生了泄漏。这个问题在云计算领域已有大量先例：Serverless 函数声称开发者无需关心服务器，但实际上不理解冷启动机制、执行时长限制、并发模型和内存配置的开发者，根本无法写出性能合格的函数代码；Kubernetes 声称抽象了底层基础设施，但网络分区、节点故障、存储延迟等问题仍会以不可预测的方式影响应用行为，运维团队最终仍需深入理解 Pod 调度策略、资源 Limit/Request 和亲和性规则。Fluid Compute 的「一套系统包打天下」承诺面临同样的风险：当 CPU 密集型的构建任务和毫秒级响应的 API 函数共用底层资源池时，如何保证性能隔离？当长期运行的服务器和短暂的沙箱共享调度器时，优先级冲突如何解决？统一抽象是否会掩盖关键的性能特征差异，导致开发者在不了解底层的情况下踩坑？

这里还涉及一个更深层的技术挑战：多租户环境下的资源隔离（Noisy Neighbor Problem）。在共享基础设施上，一个租户的高负载可能影响同一物理机上其他租户的性能——这被称为「吵闹的邻居」问题。传统云平台通过专用实例、资源配额和 CPU 绑定（CPU Pinning）来缓解此问题，但这些手段本质上与「按需共享资源池」的理念相矛盾。Fluid Compute 将四种不同特征的工作负载放入同一个调度系统，意味着一次大型构建任务可能与数百个低延迟 API 函数竞争同一节点的 CPU 缓存和内存带宽。如何在「资源共享以提高利用率」和「资源隔离以保证性能可预测性」之间取得平衡，是这类统一计算系统最核心的工程挑战。

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

关于成本可预测性，这是企业采用任何新计算模型时的核心关切。传统服务器的成本模型简单直接——按月付费，固定金额；Serverless 函数的成本与调用量和执行时间线性相关，虽然弹性但在流量突增时可能产生「账单冲击」（Bill Shock），即月底收到远超预期的费用。Fluid Compute 作为统一系统，其计费模型的设计将直接影响采用意愿。开发者需要回答的问题包括：沙箱和函数的计费粒度是否相同？长驻服务器是否仍按时间计费还是也转向按请求计费？统一引擎的调度开销是否会被转嫁到用户账单中？构建任务的等待队列时间是否计费？这些问题的答案将决定 Fluid Compute 对不同规模团队的经济吸引力——对初创公司而言，按需付费降低了入门门槛；对大型企业而言，成本可预测性可能比灵活性更重要。

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

核心要点

• 四种形态,一套系统：沙箱、函数、构建、服务器本质上都是同一计算基础设施的不同生命周期配置，Fluid Compute 用统一引擎动态调度它们
• 碎片化是真痛点：传统云开发中，不同计算形态各自拥有独立的调度逻辑、计费模型和运维负担，开发者在冷启动、成本、利用率之间疲于权衡
• 按需生成取代预分配：资源根据实际请求动态实例化，带来更高利用率、更平滑扩缩容和更低的冷启动成本
• 沙箱成为一等公民：AI Agent 时代对安全隔离的按需计算需求激增，快速拉起、执行即回收的沙箱是 AI 原生应用的关键基础设施
• 计算原语走向收敛：行业趋势从不断增加新产品形态转向用统一抽象覆盖所有形态，降低开发者认知负担
• 抽象泄漏风险仍在：统一系统需要证明在性能隔离、延迟表现和成本可预测性上能够真正兑现承诺