Vercel 构建成本怎么降：Basic 机器值不值得换

想降低 Vercel 构建成本，不能只看每分钟单价。2026 年 9 月 3 日，Vercel 为 Pro 和 Enterprise 团队新增了 Basic 选项：2 vCPU、8 GB 内存，构建费率为每分钟 $0.007。只有把运行时长、分钟取整、失败和排队延迟都算进去后，Basic 的每次成功构建成本仍低于 Elastic，它才真的省钱。

Vercel 到底改了什么

构建机器是 Vercel 用来安装依赖、编译应用并准备部署的临时计算机。付费项目现在多了一个资源更小、规格固定的选项：Pro 和 Enterprise 均可使用 Basic 构建机器，不再只有 Hobby 可用。

Basic 配备 2 vCPU、8 GB 内存和 32 GB 磁盘。Elastic 则会根据项目负载分配 4 至 30 vCPU、8 至 60 GB 内存。新建付费项目仍默认使用 Elastic。

这是一项可选设置，并非新的付费默认项。新建付费项目仍从 Elastic 起步，所有者可以在团队或项目设置中改选 Basic。Hobby 项目继续使用原有的 2 vCPU 配额内机器，只是现在改名为 Basic。

本文只讨论构建机器该怎么选。套餐费、用量额度、席位、流量、函数、存储和附加服务，仍应放到 Vercel 定价完整解析中一起看。

看 Vercel 构建成本，关键是每次成功构建

Basic 和 Elastic 的 CPU 起始费率相同：每 CPU 分钟 $0.0035。两者账单之所以不同，是因为 Basic 始终使用 2 vCPU，而 Elastic 会分配 4 至 30 vCPU。

Vercel 会将每次构建时长向上取整到最接近的整分钟。因此可以用下面两个公式估算：

• Basic： 向上取整后的构建分钟数 × $0.007。
• Elastic： 向上取整后的构建分钟数 × 分配的 vCPU 数 × $0.0035。

在 Elastic 最小的 4 vCPU 配置下，每个计费构建分钟起价为 $0.014。Basic 的每个计费分钟成本正好低一半。因此，当 Basic 的计费分钟数恰好是 Elastic 的两倍时，两者成本持平；少于两倍，Basic 就更便宜。

如果 Elastic 分配超过 4 vCPU，这条规则就会变化。每跨过一个分钟边界，结果也会改变，因为 Vercel 是对每次构建的时长取整，而不是对月度总量取整。要算清账单，需要使用真实构建时长和实际分配的机器，不能只看价目表猜测。

在这个例子里，节省 $7 是真实的，但未必有价值。如果每个预览都让开发者、审核者或编程 Agent 等着，更慢的反馈循环可能比账单节省更昂贵。如果这些构建在后台运行，而且队列始终通畅，Basic 的单位成本更划算。

分子里也要算上失败构建。真正该观察的运营指标，是构建总费用除以成功部署次数。一台机器即使每分钟便宜，只要导致重试，也可能输在你真正购买的结果上。

排队时间也是工作流成本

Vercel 公布的计费公式只使用构建时长和 CPU 数量，不会把排队延迟作为另一个收费项，但团队依然要承担这段等待。

关闭按需并发时，Pro 有 3 个并发部署槽位。超出这些活动槽位的构建必须等待。启用按需并发后，Vercel 标明最多支持 500 个并发部署，并按实际使用的构建分钟计费。

Basic 构建越慢，占用槽位的时间就越长。对每天只部署几次小型网站的创始人来说，这可能无关紧要；但当编程 Agent 同时创建多个预览、代理公司部署众多客户项目，或团队同时向多个分支推送时，影响很快就会显现。

请同时记录两套时间：

• 构建时长经过取整后，决定机器费用。
• 排队延迟加构建时长决定获得反馈需要多久。

决策逻辑就是这么简单：优化第一个数字，但别让第二个拖累工作流。

哪些人应该测试 Basic

只有一个小型应用的独立创始人

独立 SaaS 创始人可以先在项目层级把轻量营销站或仪表盘切换到 Basic，再用同一次有代表性的构建与 Elastic 对比。这样做的收益，是在不改变 Vercel 其余套餐内容的前提下，降低持续发生的构建费用。

只有构建依然可靠，而且可能变慢的运行不会拖延发布，才值得保留这一设置。对于不常部署的项目，金额差异可能小到不值得手动调优。

客户项目类型不一的代理公司

代理公司不该替所有客户账户做出同一个机器选择。小型落地页和内容项目可以逐个固定到 Basic；大型电商、monorepo 和依赖繁重的应用则继续使用 Elastic，直到各自的实测结果证明应该调整。

收益是每个项目的利润空间更清晰：低资源客户不必再沿用代理公司最重应用的构建机器。

负责运行编程 Agent 的工程负责人

Agent 驱动开发会改变公式里的构建量。自动提交越多，预览构建也可能越多，因此每次构建的一点成本差距会反复累积。

工程负责人应该测一轮有代表性的高峰，而不是只看一次安静时段的部署。如果 Basic 降低了每次成功构建的成本，但更长的运行占满 3 个可用槽位并形成队列，那这台便宜机器只是把成本从账单转移到了周转时间。

Enterprise 平台负责人

Enterprise 可以使用 Basic，但一项合同细节可能让团队无法自助更改。合同已启用 Enhanced 机器的 Enterprise 客户默认使用这些机器；要更新机器偏好，必须联系客户经理。

如何切换单个项目并完成测试

先从项目层级开始改。这样既不会影响无关应用，也能在同一处设置里快速回滚，实验边界更清楚。

1. 1

   记录 Elastic 基线

   打开 Vercel Observability 中的 Build Diagnostics，选择一次有代表性的部署。记录构建时长、分配的机器、计费用量、排队延迟，以及部署是否完成。测试 Basic 时，应尽量保持缓存条件和代码版本一致。

2. 2

   为项目选择 Basic

   在 Vercel 中打开项目，依次进入 Settings、Build and Deployment 和 Build Machine。选择 Basic 并保存。Vercel 文档也说明可以在团队层级设置，但首次测试从项目设置入手更安全。访问构建机器设置需要 owner 角色。

3. 3

   使用文档提供的 CLI 方法

   Vercel CLI 59.6.0 或更高版本可通过下面的命令更改项目：

   vc project update --build-machine basic

   常见误区是使用旧版 CLI，然后误以为当前套餐不支持机器选项。先检查版本，再判断命令失败是否源于套餐限制。

4. 4

   运行同一套工作负载

   在尽可能一致的缓存条件下，构建同一个有代表性的代码版本。记录相同字段：时长、机器、计费用量、排队延迟和完成状态。对于 Agent 驱动的工作流，还要加入一次正常的高峰负载，让排队问题有机会暴露出来。

5. 5

   按结果做选择

   计算月度构建总费用，再除以成功部署次数。只有当单位成本下降，同时总周转时间仍达到团队目标时，才保留 Basic。如果速度、内存或可靠性下降到足以抵消节省，就在 Build Machine 设置中把项目切回 Elastic。

必须正视的限制

Basic 是更小的机器，并不是效率更高的 Elastic。它的内存上限固定为 8 GB；Elastic 则可按工作负载需求扩展到 60 GB 内存和 30 vCPU。

分钟取整也可能吞掉本来不多的节省。只要超过分钟边界几秒，就会多出一个完整的计费分钟。应对比 Vercel 显示的计费用量，而不是用秒表计算后朝有利方向取整。

Elastic 还会随着项目变化继续调整资源，Basic 的配置却始终固定。今天适合小应用的机器，在依赖、路由或生成资源增加后，可能就不再合适。

谁该行动、观望或忽略这次变化

• 本周行动： Pro 或 Enterprise 项目的构建稳定、资源占用低，而且构建量足以让每次构建的持续差价产生实际影响。
• 先观望： 项目受 CPU 限制、内存占用高、接近 45 分钟上限，或已经对预览排队很敏感。先建立一套干净的 Elastic 基线。
• 忽略这次价格变化： 使用 Hobby。配额内的 2 vCPU 机器只是改名为 Basic，机器规格和套餐规则都没有变化。
• 先检查合同： Enterprise 已启用 Enhanced 机器。更改权限可能在客户经理手中。

周一就做这件事

周一选一个有代表性的小项目，在 Elastic 和 Basic 上运行同一次构建，然后记录时长、计费用量、分配的 CPU、排队延迟和完成状态。保留那个既能降低每次成功构建成本，又不会让团队错过周转时间目标的选项。

订阅 newsletter，继续阅读这些会影响预算或工作流的平台变化解析。