Vercel 构建费用新机制：Turbo 可按单次部署启用

2026 年 9 月 17 日，Vercel 把 Turbo 从项目级长期配置变成了单次部署的成本选项。遇到紧急构建时，可以只为这一次多花钱；下一次部署则自动回到项目原本选择的机器。Vercel 构建费用终于可以按发布的紧急程度来分配。

项目默认设置不必再改

构建机器是 Vercel 在安装依赖、编译应用并准备部署期间临时提供给代码的计算机。Turbo 是固定规格中最高的一档：30 vCPUs、60 GB 内存和 64 GB 磁盘。

在这项改动之前，选择固定构建机器意味着要修改团队或项目设置。赶工时会很别扭：要么让日常预览构建也一直按 Turbo 计费，要么临时改完设置，再提醒自己切回去。

新的覆盖选项只绑定到单次部署，不会改动项目设置。如果项目通常使用 Basic、Standard 或 Elastic，下一次部署仍会采用原来的选择，除非再次添加覆盖选项。

这才是它真正有用的地方：额外的构建支出可以跟着紧急任务走，而不是跟着每一次提交走。

Turbo、Enhanced 和 Elastic 仅面向 Pro 与 Enterprise。Hobby 项目始终使用 Basic，因此这并不是 Hobby 的加速开关。对于本来就让每次部署都跑在 Turbo 上的项目，它同样没有实际价值。

单次部署启用 Turbo 的三种方式

选择哪一种方式，取决于部署由什么触发。三条路径设置的都是同一个单次部署覆盖选项。

1. 1

   在 GitHub 提交中加入标记

   如果部署由 Vercel 的 GitHub 集成触发，请在提交信息正文中写入这个大小写敏感的精确标记：

   git commit -m "Test this change with Turbo" \
     -m "#VERCEL_BUILD_MACHINE=TURBO"

   该标记只对这次提交触发的部署生效。目前，它不适用于 Vercel 的 GitLab 或 Bitbucket 集成。

2. 2

   使用 Vercel CLI

   在已关联的项目中运行：

   vc deploy --turbo

   这条路径要求 Vercel CLI 59.20.0 或更高版本。如果无法识别该参数，首先应检查 CLI 是否过旧。

3. 3

   设置部署 API 字段

   如果内部发布服务通过 POST /v13/deployments 创建部署，请在请求中把 buildMachine 设为 turbo。这个字段可选，而且只作用于当前部署，不会改写项目设置。

操作者需要拥有更新项目构建机器的权限。还有一种不易察觉的失败方式需要留意：如果 Turbo 不可用，或账号没有相应权限，Vercel 不会让部署失败，而是改用项目原本选择的机器。

Vercel 构建费用：偶尔启用不贵，次次使用很贵

Vercel 目前按 CPU 分钟收取构建用量费用，价格为每 CPU 分钟 $0.0035。换算成每个计费构建分钟的起步价，Basic 为 $0.007，Standard 在计费时为 $0.014，Enhanced 为 $0.028，Turbo 为 $0.105。

计费时会先把每次构建向上取整到整分钟，再乘以机器的 CPU 数量。因此，一次运行 3 分钟 40 秒的 Turbo 构建会按 4 分钟计费，也就是 $0.42。

如果要判断项目级配置该选 Basic 还是 Elastic，请阅读用 Basic 机器降低 Vercel 构建成本。这里的新问题更具体：某一次赶期限的发布，是否值得支付 Turbo 的溢价。

工作负载示例，不是基准测试

假设某个团队一周会发布 20 次常规部署和 1 次紧急部署。按照团队自己的测量，同一工作负载在 Basic 上需要 7 分钟 20 秒，在 Turbo 上需要 3 分钟 40 秒。这些时长只是为了演示计算而设定，并不代表 Turbo 能让所有构建时间减半。

与让这次部署运行在 Basic 上相比，紧急覆盖选项多花 $0.364。在这个例子中，这笔溢价换来了关键发布上实测节省的 3 分钟 40 秒。

把 20 次常规构建留在 Basic 上，一周总费用比让全部 21 次构建都使用 Turbo 低 $7.28。这就是新的预算控制能力。实际决策仍要依据项目自己的时长，因为缓存状态、CPU 利用率、内存压力和向上取整都会影响结果。

哪些工作流真正适合这样用

独立创始人发布生产环境修复

使用 GitHub 连接 SaaS 项目的创始人，可以只在某个热修复提交中加入标记。收益并不是让项目永久加速，而是缩短与故障、客户承诺或上线窗口相关的那次发布等待时间，下一次推送则恢复正常支出。

代理公司的发布负责人遇到明确期限

如果客户发布正在等人审核，代理公司可以为它运行 vc deploy --turbo。日常预览仍沿用项目的常规配置，避免每轮客户修改都在不知不觉中抬高构建账单。

有审批流程的平台工程师

平台团队可以只在部署服务中经过审批的紧急发布路径上加入 buildMachine: "turbo"。这样，额外算力会变成一项可记录、可审查、可核算成本的明确发布决定，而不是项目长期默认配置。

必须说清楚的限制

30 vCPUs 并不代表构建速度会达到 Basic 的 2 vCPUs 的 15 倍。有些构建无法充分利用全部核心。Vercel 表示，很多项目并不能完全用满 Turbo 机器，这也是 Elastic 能为日常工作自动选择较小机器的原因之一。

Turbo 改变的是机器，而不是排队策略。如果延迟主要来自等待构建槽位，更大的机器可能解决错了问题。在为更多 CPU 付费之前，应先比较排队时间和实际构建时间。

缓存状态同样会让对比失真。一次热缓存的默认构建和一次冷缓存的 Turbo 构建，无法说明机器本身带来了什么变化。应选择相近的代码版本和缓存条件，并同时比较计费分钟数与实际耗时。

做一次受控测试

1. 1

   记录常规部署

   打开 Build Diagnostics，记录项目通常选择的机器、构建时长、排队时间、计费分钟数和结果。挑选一次与目标紧急工作负载相近的部署。

2. 2

   只覆盖一次部署

   在一次可比的部署中使用 GitHub 标记、CLI 参数或 API 字段，不要修改团队或项目的构建机器设置。

3. 3

   计算实际节省的价格

   用向上取整后的 Turbo 构建分钟数乘以 $0.105。将这笔费用与常规部署的计费用量比较，再用多花的钱除以实际节省的分钟数。

4. 4

   检查下一次部署

   不带标记、参数或 API 字段，再触发一次常规部署。确认它使用项目原本选择的机器。这一步既能发现误改项目设置的问题，也能证明覆盖选项确实只是临时生效。

现在该怎么做

• 本周就行动：适合使用 Pro 或 Enterprise、偶尔有期限紧迫的发布，同时又希望保留常规机器设置的项目。
• 先测再决定：适合使用 Elastic 的项目。Elastic 可能已经分配了足够的 CPU 和内存，强制使用 Turbo 可能只会涨账单，并不会明显缩短时间。
• 改用项目设置：如果大多数部署都需要 Turbo，就应直接调整项目配置。每次提交都重复设置“例外”，本质上只是把策略伪装成参数。
• 可以忽略：如果使用 Hobby、已经默认采用 Turbo，或者延迟主要来自排队，这项功能没有必要。

周一就做这件事

周一选一次具有代表性的部署：记录常规构建，执行一次 Turbo 覆盖，按照实际节省的时间计算溢价；随后再发起一次常规部署，确认项目已经恢复到通常的配置。

订阅邮件通讯，获取聚焦预算与工作流影响的平台变动解读。