Vercel Turbo для одного деплоя: сколько стоит ускорение

17 сентября 2026 года в Vercel режим Vercel Turbo стал платной опцией для одного деплоя, а не решением на уровне всего проекта. Теперь можно доплатить за одну срочную сборку, а следующий деплой снова запустить на машине, выбранной в обычных настройках проекта.

Настройки проекта больше не нужно менять

Машина сборки — это временный компьютер, который Vercel выделяет для кода на время установки зависимостей, компиляции приложения и подготовки деплоя. Turbo — самый мощный вариант с фиксированной конфигурацией: 30 vCPU, 60 GB памяти и 64 GB диска.

Раньше для выбора фиксированной машины сборки приходилось менять настройку команды или проекта. Из-за этого работа перед коротким дедлайном становилась неудобной: либо оплачивать Turbo для обычных превью-сборок, либо включать его на время аврала и не забыть потом вернуть прежнюю настройку.

Теперь Turbo можно назначить одному деплою. Настройки проекта при этом не меняются. Если обычно проект использует Basic, Standard или Elastic, уже следующий деплой снова получит эту машину — если только не задать новое переопределение.

В этом и есть практическая ценность: дополнительные расходы на сборку теперь зависят от срочности, а не от каждого коммита.

Turbo, Enhanced и Elastic доступны на тарифах Pro и Enterprise. Проекты Hobby всегда используют Basic, поэтому ускорить Hobby таким способом не получится. Опция также бесполезна для проекта, в котором каждый деплой и без того запускается на Turbo.

Как включить Vercel 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, задайте в запросе значение turbo для поля buildMachine. Это необязательное поле действует только для текущего деплоя и не меняет настройки проекта.

Потребуется право на изменение машины сборки проекта. Есть и один неочевидный сценарий сбоя: если Turbo недоступен или у аккаунта нет нужного разрешения, Vercel не прерывает деплой, а использует обычную машину проекта.

Разовая доплата невелика, привычка включать Turbo — дорога

Сейчас Vercel тарифицирует время сборки по $0.0035 за CPU-минуту. В пересчете на оплачиваемую минуту сборки минимальная цена составляет $0.007 для Basic, $0.014 для Standard, когда его использование тарифицируется, $0.028 для Enhanced и $0.105 для Turbo.

Биллинг округляет длительность каждой сборки вверх до целой минуты, а затем учитывает число CPU машины. Поэтому сборка на Turbo длиной 3 минуты 40 секунд тарифицируется как 4 минуты и стоит $0.42.

Выбор между Basic и Elastic на уровне проекта разобран в материале Как сократить расходы на сборки Vercel с машинами Basic. Здесь вопрос уже: стоит ли ускорять один дедлайн за счёт доплаты за Turbo.

Расчётный пример, а не бенчмарк

Предположим, команда выпускает за неделю 20 обычных деплоев и 1 срочный. По её собственным замерам одна и та же нагрузка занимает 7 минут 20 секунд на Basic и 3 минуты 40 секунд на Turbo. Эти значения вымышлены и нужны только для расчёта. Turbo не сокращает время любой сборки вдвое.

Одно срочное переопределение добавляет $0.364 по сравнению с запуском этого деплоя на Basic. В данном примере эта доплата экономит 3 минуты 40 секунд на действительно важном релизе.

Если оставить 20 обычных сборок на Basic, недельные расходы будут на $7.28 ниже, чем при запуске всех 21 на Turbo. В этом и состоит новый способ управлять бюджетом. Для реального решения нужны собственные замеры: на результат влияют состояние кэша, загрузка CPU, нагрузка на память и округление.

Кому подходит такой сценарий

Соло-фаундер выпускает срочный фикс

Фаундер SaaS-сервиса, подключенного к GitHub, может добавить маркер в один коммит с хотфиксом. Смысл не в том, чтобы навсегда ускорить весь проект. Выигрыш — меньше ждать релиз, от которого зависит устранение сбоя, обещание клиенту или окно запуска, а уже со следующего пуша вернуться к обычным расходам.

Руководитель релиза в агентстве работает к одному дедлайну

Агентство может запустить vc deploy --turbo для клиентского релиза, когда результат уже ждут на проверку. Обычные превью останутся на стандартной конфигурации проекта, поэтому расходы на сборку не начнут незаметно расти с каждой правкой клиента.

Платформенный инженер выстраивает процесс согласования

Платформенная команда может добавлять buildMachine: "turbo" только в утвержденный сценарий срочного релиза своего сервиса деплоя. Тогда дополнительные вычислительные ресурсы становятся явным решением: его можно записать в лог, проверить и оценить по стоимости, а не держать как постоянную настройку проекта.

Где Turbo не поможет

Тридцать vCPU не означают, что сборка станет в 15 раз быстрее, чем на 2 vCPU у Basic. Некоторые процессы просто не способны загрузить все эти ядра. По данным 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. Возможно, он уже получает достаточно CPU и памяти, а принудительный Turbo только увеличит счёт, не дав заметного выигрыша во времени.
• Лучше измените настройку проекта, если Turbo нужен большинству деплоев. Исключение, которое приходится повторять в каждом коммите, — это политика, замаскированная под флаг.
• Можно пропустить эту опцию, если проект работает на Hobby, уже использует Turbo по умолчанию или в основном задерживается в очереди.

Что сделать в понедельник

В понедельник выберите один показательный деплой. Зафиксируйте обычную сборку, один раз включите Turbo, сопоставьте доплату с реально сэкономленным временем, затем отправьте обычный деплой и убедитесь, что проект вернулся к привычной конфигурации.

Подпишитесь на рассылку, чтобы получать понятные разборы изменений платформ, которые влияют на бюджет или рабочий процесс.