Главная · Железо и развёртывание

Локальные модели против SaaS и API

Крутить open-weight модель на своём железе, арендовать GPU в облаке или ходить в чужой API — решение, которое на собеседовании по дизайну систем всплывает постоянно. Разбираем две оси выбора, три модели затрат и главную идею: точку перелома, где дешёвое становится дорогим.

Интуиция: две оси решения

Вопрос «локально или в облаке» на самом деле распадается на две независимые оси. Первая — где крутить модель: на собственном железе (self-hosted), на арендованных GPU-серверах в облаке или вообще не крутить, а ходить в чужой API. Вторая — какую модель: открытую (open-weight), которую можно скачать и дообучить, или проприетарную frontier-модель, доступную только через API провайдера.

Эти оси часто путают. «Локальная модель» — это и про приватность (данные не уходят наружу), и про контроль (можно файнтюнить), и про экономику (капитальные затраты вместо поштучной оплаты). А «API» — это скорость старта и доступ к качеству, которое своими силами не поднять. Разберём по мотивам.

Когда что уместно

Локальная / self-hosted open-weight модель выигрывает, когда:

Приватность и регуляторика — данные (медицина, финансы, персональные) физически не должны покидать периметр компании; чужой публичный API тут исключён.
Предсказуемая цена на большом стабильном объёме — если поток запросов велик и ровен, поштучная оплата API становится дороже амортизированного железа.
Офлайн / edge — работа без интернета, на устройстве, в закрытом контуре.
Полный контроль — свой файнтюн, своя версия, отсутствие вендор-лока (vendor lock-in) и внезапных изменений модели на стороне провайдера.

SaaS / API выигрывает, когда:

Быстрый старт — работает за час, без ops-команды, кластера и дежурств.
Доступ к frontier-качеству, которое локально не воспроизвести без огромных ресурсов.
Спайковая, непредсказуемая нагрузка — платишь только за использование, а не за простаивающие GPU.
Не нужно держать железо — провайдер сам занимается масштабированием, надёжностью и обновлениями.

Три модели затрат

Экономику удобно свести к трём вариантам, у каждого своя форма кривой «стоимость от объёма»:

Своё железо. Большие капитальные затраты (capex) на покупку GPU плюс электричество, амортизация и зарплаты инженеров. Зато цена на токен при высокой утилизации крошечная: кривая почти горизонтальна — платишь примерно одинаково, пока не упрёшься в потолок мощности.
Аренда GPU. Операционные затраты (opex) по часам — гибко, масштабируется вверх и вниз. Но платишь и за простой: если карта арендована, но не загружена, деньги всё равно идут.
API. Плата за токены — ноль на старте, идеально для прототипа и малого объёма. Кривая линейно растёт с объёмом и на больших числах обгоняет собственное железо.

💡 Ключевая мысль Ключ к выбору — точка перелома (crossover): объём, на котором один вариант становится дешевле другого. API выигрывает при малом и рваном потоке (платишь только за использованное), своё железо и аренда — при большом и стабильном (фиксированные затраты размазываются по множеству запросов). Считать надо не цену железа, а полную стоимость владения (TCO) — вместе с людьми, ops и утилизацией.

Начните с малого объёма слева — синяя линия API у самого пола, побеждает без вопросов. Тяните объём вправо: линия API растёт линейно и на каком-то объёме пересекает почти горизонтальную линию своего железа — это и есть точка перелома, отмеченная засечкой. Включите «рваную/спайковую» нагрузку — линии своего железа и аренды ползут вверх (вы платите за простой), и перелом сдвигается вправо: API остаётся выгодным дольше. Включите «нужна приватность» — линия публичного API исчезает вовсе, выбор идёт только между своим и арендованным.

TCO, а не цена железа

Главная ловушка расчётов — сравнивать цену GPU с ценой токенов API. Настоящая стоимость своего решения — это полная стоимость владения (TCO, total cost of ownership): железо + электричество + амортизация + зарплаты инженеров, которые это обслуживают и дежурят + стоимость простоя недозагруженных карт. Дешёвая цена на токен у собственного железа реальна только при высокой утилизации: карта, загруженная на 20%, обходится в пять раз дороже расчётной за токен. Поэтому «своё дешевле» верно для стабильного большого потока и неверно для стартапа с пятью запросами в минуту.

Гибридные схемы

На практике редко выбирают один полюс. Частый паттерн — роутинг (routing): дешёвая локальная модель обрабатывает простые и приватные запросы, а сложные уходят в мощный API. Так экономят на объёме и одновременно держат доступ к frontier-качеству там, где оно правда нужно. Другой вариант — базовую нагрузку держать на своём железе, а пики отдавать в облако (cloud bursting). Проектирование такого распределения — часть дизайна ML-систем.

⚠️ Подводный камень Легко посчитать только capex на GPU и объявить своё железо «в разы дешевле API». Забытые слагаемые — инженеры, ops, электричество и, главное, утилизация — часто переворачивают вывод. Недозагруженный собственный кластер почти всегда дороже API; выгода появляется только на стабильно высоком потоке.

🎤 На собеседовании

«Когда self-hosted, а когда API?» — API для быстрого старта, малого/рваного объёма и доступа к frontier-качеству; self-hosted — при жёстких требованиях приватности, большом стабильном потоке и нужде в контроле/файнтюне.
«Из чего складывается реальная стоимость локального решения?» — не только железо: плюс электричество, амортизация, зарплаты инженеров, ops и стоимость простоя; сравнивать надо TCO, а не цену карты.
«Как найти точку перелома?» — приравнять линейную стоимость API (цена за токен × объём) к почти фиксированной стоимости своего/аренды; объём пересечения и есть порог, выше которого своё дешевле.
«Как совместить приватность и frontier-качество?» — гибрид: приватные/простые запросы на локальной модели, сложные — в API; или self-hosted open-weight модель, если качества хватает.