Локальная LLM или облако: где граница выгоды

Локальная LLM или облачный API — этот выбор рано или поздно встаёт перед каждой командой, которая встраивает AI в продукт. На пилоте всё просто: подключили API, получили ответ, показали демо. Вопросы появляются позже, когда приходит счёт за первый месяц в проде.

В спорах «self-hosted против облака» часто сравнивают цену токена в прайсе с ценой видеокарты. Такое сравнение почти всегда врёт. Реальная стоимость складывается из инфраструктуры, людей, простоя и рисков.

В статье разберём:

• из чего состоит полная стоимость владения LLM;
• когда выгоднее Cloud API, а когда собственный сервер;
• как посчитать точку безубыточности на своих цифрах;
• зачем нужен гибрид и что говорит 152-ФЗ.

Стоимость языковой модели в проде — это TCO, полная стоимость владения. В неё входит не только инференс, но и всё, что его окружает: хранение, сеть, мониторинг и время инженеров. Цена токена или аренды GPU-сервера закрывает в лучшем случае половину картины.

Скрытые статьи затрат

Эти расходы редко попадают в первую оценку, но всегда появляются в отчётах:

• Инженерное время. Кто-то должен развернуть модель, настроить пайплайн, обновлять версии и разбирать инциденты.
• Хранение. Веса моделей, логи запросов, векторная база для RAG, датасеты для дообучения. Часто всё это живёт в S3-совместимом хранилище и тоже стоит денег.
• Сеть и доступ. VPN до внутренних систем, proxy или API-шлюз перед моделью, балансировка, DNS-записи для эндпоинтов.
• Наблюдаемость. Метрики латентности, алерты, трекинг ошибок в Sentry, логирование промптов для отладки.
• Оценка качества. Тестовые наборы, прогоны при смене модели или промпта, ручная проверка ответов.
• Длинный контекст. Системный промпт и куски базы знаний уходят в модель с каждым запросом. Вы платите за них снова и снова.

Метрика CPT

Чтобы сравнивать подходы честно, удобно считать CPT (Cost Per Token) — стоимость одного обработанного токена с учётом всех расходов. Формула простая:

CPT = все расходы на LLM за месяц / число токенов за месяц (вход + выход)

Например, команда тратит 1,2 млн ₽ в месяц и обрабатывает 4 млрд токенов. Получается 300 ₽ за 1 млн токенов. Эту цифру уже можно сравнить с прайсом облачного API или с расчётом для собственного сервера.

CPT полезно выводить в дашборд рядом с продуктовыми метриками. Тогда разговор «дорого или дёшево» перестаёт быть спором мнений.

Cloud API — самый быстрый способ проверить гипотезу. Вы не покупаете железо и не ищете MLOps-инженера, а платите только за токены. Но та же модель оплаты на большом объёме превращается в главный аргумент против.

Плюсы

• Быстрый запуск

От регистрации до первого ответа модели проходят минуты. Достаточно получить ключ и указать эндпоинт в OpenAI-совместимом client.

• Нет капитальных затрат

Не нужно закупать GPU и ждать поставку.

• Доступ к большим моделям

Модели на сотни миллиардов параметров сложно и дорого запускать самостоятельно.

• Гибкость

Новые модели появляются в каталоге провайдера, переключиться на них можно сменой одного параметра.

• Эластичность

Пиковую нагрузку берёт на себя провайдер, а не ваш сервер.

Сколько стоит?

Облачные модели тарифицируют отдельно за входящие и исходящие токены. Стоимость зависит от выбранной модели и не напрямую связана с числом параметров. Например, gpt-oss-120b крупнее qwen3.6-35b-a3b, но обходится примерно в 5 раз дешевле. Например, в GPT Model Hub на октябрь 2026 года:

Цены указаны с НДС, актуальные тарифы — в документации.

Посчитаем бота поддержки: 10 000 диалогов в день, в среднем 3 000 входящих и 500 исходящих токенов на диалог. За месяц это 900 млн входящих и 150 млн исходящих токенов. На gpt-oss-120b счёт составит около 20 тыс. ₽, на qwen3.6-35b-a3b — около 106 тыс. ₽, на glm-5.3 — около 272 тыс. ₽. Разница между самой дешёвой и самой дорогой моделью — больше чем в 13 раз при той же нагрузке. Поэтому модель стоит выбирать по результатам тестов на своих задачах: если дешёвая справляется, переплачивать за флагман нет смысла.

Скрытые риски

• Линейный рост счёта

Трафик вырос вдвое — счёт тоже вырос вдвое. Эффекта масштаба нет.

• Оплата контекста

Длинный системный промпт и RAG-фрагменты оплачиваются в каждом запросе.

• Лимиты

У провайдера есть квоты на запросы и токены в минуту, их нужно заранее согласовать под пик.

• Зависимость от провайдера

Модель могут перевести в deprecated, а цены — пересмотреть.

• Данные за периметром

Если провайдер зарубежный, запросы с персональными данными становятся юридической проблемой. Об этом ниже.

Self-hosted LLM — это модель с открытыми весами, которую вы запускаете на своём GPU-сервере или на арендованных мощностях. Первые месяцы обходятся дороже облака. Зато каждый следующий миллион токенов почти ничего не стоит, пока сервер не упёрся в предел.

Плюсы

• Фиксированные расходы

Счёт не зависит от числа запросов, пока хватает мощности.

• Контроль над данными

Запросы не покидают ваш контур, доступ можно закрыть VPN и внутренними правилами.

• Дообучение

Модель на 7–32B параметров можно дообучить под узкую задачу: классификацию тикетов, извлечение сущностей, помощь в кодинге на внутреннем стеке.

• Предсказуемая задержка

Нет чужих очередей и квот, latency зависит только от вашей нагрузки.

Скрытые статьи затрат

• Железо

Для LLM нужен GPU с достаточным объёмом видеопамяти. Обычный VPS или web-hosting здесь не подойдёт: модель либо не поместится в память, либо будет отвечать минутами.

• Установка и настройка

Драйверы, CUDA, inference-сервер вроде vLLM, балансировщик, авторизация. Локально на ноутбуке всё работает за вечер, в проде — за недели.

• Отказоустойчивость

Один сервер — одна точка отказа. Для SLA нужен второй узел, который часть времени простаивает.

• Обновления

Новые версии моделей выходят каждые несколько месяцев. Каждая миграция — это тесты, оценка качества и выкатка.

• Недозагрузка

GPU, который работает на 15% мощности, обходится так же, как загруженный на 80%.

Когда окупается?

Self-hosting выгоден, когда сходятся три условия:

1. Объём запросов высокий и ровный, без резких пиков.
2. Задачу решает модель среднего размера, а не флагман на сотни миллиардов параметров.
3. В команде уже есть люди, которые умеют эксплуатировать GPU-инфраструктуру.

Если хотя бы одно условие не выполняется, экономия на токенах уходит на простой железа и время инженеров.

Точка безубыточности — это объём токенов в месяц, при котором собственный инференс обходится так же, как облачный API. Ниже этой границы выгоднее облако, выше — self-hosted. Универсальной цифры нет: граница сильно зависит от выбранной модели. Чем дешевле облачный токен, тем больше объём, с которого окупается своя инфраструктура. Посчитать её на своих цифрах можно за полчаса.

Формула:

N = F / (P − V)

• F — фиксированные расходы на self-hosted в месяц: аренда или амортизация GPU-серверов, резервный узел, доля зарплаты инженера, мониторинг, хранение.
• P — средняя цена 1 млн токенов в облаке с учётом соотношения входа и выхода.
• V — переменные расходы на 1 млн токенов у себя: электричество, трафик. В аренде часто близки к нулю.

Возьмём условный пример. Сценарий из бота поддержки выше даёт среднюю цену около 100 ₽ за 1 млн токенов на модели среднего размера. Допустим, собственная инсталляция с резервом и сопровождением стоит 600 тыс. ₽ в месяц.

В этом примере граница проходит около 6 млрд токенов в месяц, или 200 млн в день. Это уровень крупного продукта, а не внутреннего ассистента на сотню сотрудников.

Учтите два нюанса:

1. Расходы на self-hosted растут ступенькой

Когда текущий сервер упирается в предел, нужно добавить ещё один, и F резко увеличивается.

2. Граница сдвигается вместе с моделью

Для флагманской модели облачный токен дороже, но и собственный кластер под неё стоит в разы больше.

На практике выбор редко сводится к «всё локально» или «всё в облаке». Чаще команды распределяют запросы между несколькими моделями по стоимости, сложности и чувствительности данных.

Гибрид имеет смысл, если:

• есть большой поток однотипных задач и редкие сложные запросы;
• нагрузка неровная, с пиками в рабочие часы или в сезон;
• часть данных нельзя выпускать за периметр, а часть — можно;
• нужен запасной маршрут на случай сбоя одного из контуров.

Типовая схема выглядит так:

1. Маршрутизатор — перед моделями стоит LLM-proxy с единым OpenAI-совместимым API. Приложения обращаются к одному адресу и не знают, какая модель ответит.
2. Базовый контур — небольшая модель забирает рутину: классификацию, извлечение полей, короткие ответы. Её можно развернуть у себя или взять в облаке недорогой вариант.
3. Контур для сложных задач — длинные рассуждения, анализ документов, генерацию кода отправляют в большую облачную модель.
4. Fallback — если один контур недоступен, proxy переключает трафик на другой.

Отдельный вариант гибрида — managed-модели в российском облаке. Например, в GPT Model Hub модели уже развёрнуты на GPU внутри контура MWS Cloud, а подключение идёт через OpenAI-совместимый API. Сервис не сохраняет запросы и ответы и не использует их для обучения моделей. Команда получает экономику Cloud API без настройки инфраструктуры и при этом не отправляет данные за рубеж. В каталоге сервиса есть текстовые, embedding- и аудиомодели. Аудиомодели вышли в General Availability 19 октября 2026 года, и на них действует SLA.

Полезный приём: сначала запустите продукт на облачном API и соберите реальную статистику по токенам. Через пару месяцев у вас будут данные для расчёта точки безубыточности, а не прогнозы.

Для российских компаний вопрос, «где обрабатывать запросы к модели» часто решает не бюджет, а закон. Если в промптах есть ФИО, телефоны, номера договоров или медицинские данные, каждый запрос к LLM — это обработка персональных данных.

152-ФЗ и приказ об обезличивании

Что важно учитывать при выборе архитектуры:

• Локализация

Закон требует записывать, хранить и обновлять персональные данные граждан России в базах на территории страны. Логи промптов и векторная база с клиентскими документами тоже попадают под это правило.

• Трансграничная передача

Отправка ПДн в зарубежный API — это трансграничная передача. Перед ней оператор обязан уведомить Роскомнадзор и оценить, обеспечивает ли страна получателя защиту данных.

• Обезличивание

Если данные нужно отправить во внешнюю модель, их можно заменить на идентификаторы до запроса и вернуть обратно в ответе. С 1 сентября 2025 года требования и методы обезличивания задаёт приказ Роскомнадзора № 140. Он заменил приказ № 996 от 2013 года — в обзорах его номер иногда пишут как «приказ 966».

• Защита ИИ в госсистемах

С 1 марта 2026 года действует приказ ФСТЭК № 117. Он впервые прямо требует защищать компоненты ИИ в государственных информационных системах: модели, датасеты, параметры.

Простой путь соблюсти требования — обрабатывать запросы внутри российского контура. Это может быть собственный сервер или облако с аттестацией. Например, облако MWS имеет аттестат соответствия 152-ФЗ по уровню защищённости УЗ-1.

Технические меры тоже нужны: доступ к модели только через VPN или приватную сеть, ротация API-ключей, маскирование ПДн в логах и трекерах ошибок.

Может ли локальная модель заменить облачную?

Для многих рабочих задач — да. Классификацию обращений, извлечение данных из документов, суммаризацию и подсказки при кодинге хорошо закрывают модели на 7–32B параметров. Для сложных рассуждений и длинного анализа облачные флагманы пока сильнее. Поэтому чаще речь идёт не о замене, а о разделении задач между моделями.

С какого объёма self-hosting окупается?

Универсального порога нет. Посчитайте фиксированные расходы на собственный inference server и разделите их на среднюю цену 1 млн токенов в облаке. Для моделей среднего размера граница обычно измеряется миллиардами токенов в месяц. Если ваш объём ниже, развёртывание своей инфраструктуры чаще всего не окупит время команды.

Можно ли использовать облако и не нарушать 152-ФЗ?

Да. Для этого запросы с персональными данными должны обрабатываться на территории России, у провайдера с подходящей аттестацией. Второй вариант — обезличивать данные до отправки в модель по правилам приказа Роскомнадзора № 140. Решение лучше согласовать с юристом и специалистом по ИБ до запуска в прод.