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

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

Раздел: [Железо и развёртывание](https://ml-book.com/s/infra/) · Страница темы: https://ml-book.com/t/local-vs-saas/ · Обновлено: 2026-07-07 · Источник: ml-book.com, учебник делается сообществом

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

Вопрос «локально или в облаке» на самом деле распадается на две независимые оси. Первая — **где** крутить модель: на собственном железе (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 и утилизацией.

> 🎛 Интерактивная визуализация — на странице темы: https://ml-book.com/t/local-vs-saas/

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

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

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

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

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

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

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

## Связанные темы

- [Видеокарты и VRAM: железо для нейросетей](https://ml-book.com/t/gpu-vram/)
- [Инференс: KV-cache, квантизация, спекулятивный декодинг](https://ml-book.com/t/inference/)
- [Fine-tuning: SFT, LoRA, PEFT](https://ml-book.com/t/finetuning/)
- [Дизайн ML-систем на собеседовании](https://ml-book.com/t/ml-system-design/)

---

Интерактив, тест из 12 вопросов и карточки терминов — на странице темы: https://ml-book.com/t/local-vs-saas/
Весь учебник в markdown: https://ml-book.com/llms-full.txt · Оглавление для агентов: https://ml-book.com/llms.txt