Облачная или локальная LLM: что выбрать бизнесу для данных, скорости и бюджета

Коротко

• Не нужно выбирать «облако или сервер» сразу для всей компании. Решение принимают для каждого процесса и типа данных.
• Публичные и обезличенные данные можно спокойно обрабатывать через облачный API: отзывы WB, описания товаров, черновики постов. На старте так быстрее и дешевле.
• Персональные данные и коммерческую тайну либо маскируют перед отправкой, либо обрабатывают моделью в частном облаке или на своём сервере.
• Своя модель окупается при большом и стабильном объёме запросов или при жёстких требованиях к данным. При нескольких сотнях запросов в день облако почти всегда дешевле.
• Задержка чаще возникает не в самой модели, а в интеграциях, очередях и повторных запросах.
• Сразу заложите возможность сменить модель без переписывания всего процесса.

Три варианта, а не два

Обычно спорят о двух вариантах: облако или локально. На практике их три.

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

Начинайте с данных, а не с модели

Самая частая ошибка — выбирать модель по бенчмаркам. Сначала стоит понять, какие данные увидит модель в каждом процессе. Удобно разделить их на четыре уровня.

Публичные. Карточки товаров, отзывы на маркетплейсах, тексты с сайта. Они и так открыты, поэтому облачный API подходит без оговорок.

Внутренние, но не чувствительные. Регламенты, база знаний поддержки, шаблоны ответов. Обычно их можно обрабатывать в облаке, если по договору провайдер не обучает модели на ваших данных.

Персональные данные. ФИО, телефоны, адреса, переписки с клиентами из CRM и Telegram. Здесь начинаются требования 152-ФЗ: где хранятся данные, есть ли трансграничная передача, уведомлён ли Роскомнадзор. Есть два рабочих варианта: маскировать ПДн до отправки или выбрать модель, которая работает в российском контуре. Финальную схему стоит согласовать с юристом.

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

В одной компании обычно встречаются все четыре уровня. Поэтому правильный ответ на вопрос «облако или локально?» чаще всего звучит как «и то, и другое, по процессам».

Как это выглядит в рабочем процессе

Возьмём типичную задачу: заявки из Telegram и с сайта нужно разобрать, квалифицировать и занести в CRM. Это примерно та же связка, что мы описывали в статье про AI-агентов для бизнеса.

Заявка (Telegram / сайт)
  → маскирование: телефон, email, ФИО заменяются на метки
  → облачная модель: тип запроса, срочность, черновик ответа
  → обратная подстановка данных
  → менеджер подтверждает или правит ответ
  → запись в CRM + лог: что пришло, что предложила модель, что отправил человек

Модель не видит персональных данных, но выполняет основную работу: классифицирует заявку и готовит ответ. Решение остаётся за менеджером.

Второй пример — селлер на WB и Ozon. Ответы на отзывы и SEO-тексты карточек обрабатываются облачной моделью, потому что данные публичные, а качество текста важно. Анализ юнит-экономики с закупочными ценами и маржой по SKU выполняет открытая модель в частном облаке. Такая гибридная схема встречается чаще чистых вариантов.

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

Скорость: что на самом деле тормозит

Облачные модели обычно начинают отвечать за доли секунды или пару секунд. Длинный ответ генерируется дольше. Локальная модель на хорошем GPU работает сопоставимо. На слабом сервере или на процессоре без GPU ответ может идти десятки секунд, а при нескольких одновременных запросах выстраивается очередь.

На практике задержку чаще создают другие вещи:

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

Если клиент ждёт ответа в чате, важна задержка до первых слов. Если это ночной отчёт по 5000 SKU, важна пропускная способность и цена, а секунды значения не имеют. Требования к скорости стоит формулировать для каждого процесса отдельно, а не для «ИИ вообще».

Бюджет: как посчитать без иллюзий

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

Облако. Возьмите реальный объём. Например, 150 заявок в день, на каждую примерно 3000 токенов вместе с инструкцией и ответом. Получается около 450 тыс. токенов в день, или 13–14 млн в месяц. Умножьте на цену из текущего тарифа выбранной модели. Для типового бизнес-процесса такого объёма обычно выходят тысячи или низкие десятки тысяч рублей в месяц. Цены меняются, поэтому считайте по свежему прайсу.

Своя модель. Сюда входят аренда или покупка GPU-сервера, время инженера на запуск, мониторинг и обновления, а также резерв на случай отказа. Аренда сервера, на котором стабильно работает модель среднего размера, обычно стоит десятки тысяч рублей в месяц. Ещё столько же или больше уходит на поддержку, даже если её делает ваш же разработчик. Покупка железа даёт выгоду только при постоянной высокой загрузке и горизонте от года.

Экономия времени. Расчёт без неё неполный. Если менеджер тратит 4 минуты на разбор каждой из 150 заявок, это 10 часов в день. Если модель снимает 70–80% этой работы, освобождается больше рабочего дня сотрудника. Рядом с этим разница между облаком и своим сервером часто оказывается не главной статьёй расходов.

Своя модель обычно выгоднее в двух случаях. Первый — объём измеряется сотнями миллионов токенов в месяц и стабилен. Второй — требования к данным всё равно исключают облако, и вопрос уже не в экономии. Подробнее о том, как оценить, стоит ли процесс автоматизации, мы писали в статье «Как понять, что процесс пора автоматизировать».

Риски каждого варианта

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

Частное облако и on-prem. Открытые модели, которые помещаются на доступное железо, в сложных рассуждениях обычно уступают топовым облачным. Безопасность сервера тоже на вас: открытый наружу порт с моделью без авторизации делает «локальность» бессмысленной. Кто-то должен обновлять модель, следить за памятью GPU и поднимать сервис после сбоев.

Общие риски. Ни один вариант не защищает от ошибок модели. Она может уверенно выдумать срок доставки или неправильно прочитать сумму в счёте. Поэтому в любой схеме нужны:

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

Как внедрять: порядок, который работает

1. Выберите один процесс. Не «внедрить ИИ», а, например, «квалификация входящих заявок».
2. Разметьте данные. Определите, какие поля видит модель и к какому из четырёх уровней они относятся. Это сразу сужает выбор.
3. Соберите 50–100 реальных примеров с правильными ответами. Это ваш тест, и без него сравнение моделей будет на ощущениях.
4. Сделайте пилот на облачной модели, если данные позволяют или их можно замаскировать. Так вы быстро увидите, решает ли ИИ задачу в принципе.
5. Прогоните тот же набор через открытую модель, если требования к данным или объём говорят в её пользу. Сравните качество, скорость и стоимость на одних и тех же примерах.
6. Заложите слой абстракции между процессом и моделью, чтобы смена провайдера была настройкой, а не переделкой.
7. Запускайте с подтверждением человеком и логами. Автоматический режим включайте только для тех типов задач, где за несколько недель накопилась статистика без ошибок.

FAQ

Можно ли отправлять персональные данные клиентов в ChatGPT или другой зарубежный API?

Это трансграничная передача ПДн, и на неё распространяются требования 152-ФЗ, включая уведомление Роскомнадзора. Для большинства SMB-задач проще маскировать ФИО, телефоны и адреса до отправки или использовать модель в российском контуре. Конкретную схему стоит проверить у юриста.

Локальная модель — это безопаснее?

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

Насколько открытые модели хуже облачных?

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

Какой объём нужен, чтобы своя модель окупилась?

Ориентир — стабильные сотни миллионов токенов в месяц и постоянная загрузка сервера. При меньших объёмах свою модель выбирают из-за требований к данным, а не из-за экономии. Посчитайте облачный вариант по реальным цифрам и сравните с полной стоимостью сервера, включая время людей.

Можно ли начать в облаке, а потом перейти на свой сервер?

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

Нужен ли для локальной модели свой ML-инженер?

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

Что делать дальше

Не нужно решать «облако или локально» для всей компании. Возьмите один процесс, разметьте, какие данные увидит модель, соберите тестовые примеры и сравните варианты на реальных цифрах. Чаще всего получается гибрид: публичное и обезличенное идёт в облако, чувствительное остаётся в вашем контуре, а важные действия подтверждает человек.

Если хочешь понять, что автоматизировать у себя, напиши Дмитрию в Telegram @dmkosik или опиши процесс для диагностики Paramiko.