Выбор между открытой моделью и облачным API решает не отдел разработки, а два документа: перечень данных, которые пойдут в нейросеть, и годовой бюджет на её эксплуатацию. Ошибка в первом стоит претензий регулятора и службы безопасности, во втором — сервера, который простаивает, или счёта, который растёт вместе с потоком. Открытая модель — это нейросеть с опубликованными весами, которую компания разворачивает на своих серверах; облачный API — доступ по сети к модели, работающей у поставщика. Ниже — где проходит граница, что обычно забывают посчитать и когда не нужен ни тот, ни другой вариант.
Открытая модель или облачный API — вопрос о данных, а не о технологиях
В облачном сервисе модель работает на инфраструктуре поставщика: вы отправляете запрос по сети и платите за объём обращений. Открытую модель вы разворачиваете у себя или на арендованных мощностях и платите за вычисления независимо от того, сколько запросов пришло.
Что это значит: в первом случае данные при каждом запросе покидают ваш периметр и попадают к поставщику, во втором — остаются внутри. Всё остальное — скорость старта, цена, качество — вторично по отношению к вопросу, можно ли этим данным уходить наружу.
Вердикт: разговор о выборе модели, который начинается с рейтингов, а не с перечня данных, начинается не с того конца.
Шесть различий, из которых обычно смотрят только на цену
| Критерий | Облачный сервис | Открытая модель у себя |
|---|---|---|
| Где данные | Уходят к поставщику | Не покидают контур |
| Старт | Дни: ключ и интеграция | Недели: сервер, развёртывание, настройка |
| Оплата | За объём обращений | За мощности, независимо от нагрузки |
| Обновление модели | Поставщик, иногда без предупреждения | Вы, когда сочтёте нужным |
| Поведение во времени | Может измениться после обновления | Стабильно, пока вы не решите иначе |
| Требуется экспертиза | Минимальная | Развёртывание и сопровождение |
Из этой таблицы на переговорах обсуждают третью строку, реже первую. Четвёртая и пятая всплывают через полгода эксплуатации, шестая — когда уходит единственный человек, который понимал, как устроен сервер. Каждой из них ниже посвящён отдельный раздел.
Персональные данные сужают выбор облака, но не всегда закрывают его
Если в обработку попадают персональные данные, коммерческая тайна или сведения под отраслевыми требованиями, отправлять их в произвольный зарубежный сервис нельзя или очень рискованно. Закон № 152-ФЗ требует при сборе записывать и хранить персональные данные граждан России в базах данных на территории России (ч. 5 ст. 18), а трансграничная передача обставлена отдельными требованиями (ст. 12). Если служба безопасности прямо запрещает передачу третьим лицам, вопрос закрыт окончательно.
Но «нельзя в зарубежное облако» не равно «только свой сервер». Между этими полюсами есть облачные сервисы и арендованные мощности в России, где обработка идёт по поручению оператора (ч. 3 ст. 6 152-ФЗ): в договоре перечисляются действия с данными, цели обработки и требования к их защите, а согласие субъекта на поручение нужно, если иное не предусмотрено законом. Оператором и ответственным перед субъектом при этом остаётся ваша компания. Для многих компаний это законный и более дешёвый вариант, чем собственный контур. Какой из них допустим именно у вас, решают юрист и служба безопасности, а не подрядчик и не отдел продаж поставщика.
Облако без оговорок подходит задачам без чувствительных данных: черновики текстов, работа с публичной информацией, проверка гипотез до того, как в процесс попадут реальные клиенты. Что нельзя отправлять в публичные сервисы, подробно разобрано в статье что нельзя загружать в нейросети.
Вердикт: сначала юрист отвечает, куда данным можно, потом инженер выбирает, как.
«Своя модель дешевле» верно только на большой и ровной нагрузке
Облако выгоднее на малых и неравномерных объёмах: платите ровно за использованное. Свой контур выгоднее на больших и постоянных: мощности уже оплачены, и дополнительный запрос почти не увеличивает счёт. Точка перелома у каждой компании своя и считается по фактической нагрузке, а не по прайсу поставщика.
Считать стоит годовую стоимость владения обоих вариантов целиком. Для облака это объём запросов, умноженный на их среднюю длину и цену, плюс интеграция. Для своего контура — оборудование или аренда мощностей, размещение, резервирование, мониторинг и часы людей на сопровождение.
Не «сколько стоит сервер против стоимости обращений», а полную стоимость владения за год: инфраструктура плюс сопровождение против платы за фактический объём. И отдельно — цену риска, если данные уйдут туда, куда им нельзя.
Вердикт: смета, в которой у своего контура нет строки «человек», занижена.
Сервер с моделью требует не только ускорителей, но и человека при нём
Расчёт своего контура обычно упирается в железо, и ответ зависит от размера модели и нагрузки. Но структура затрат одинакова, и часть статей в смету попадает не всегда: место в стойке или аренда, резервирование на случай отказа, мониторинг, обновления, резервные копии настроек.
И человек, который всем этим занимается, — не полный день, но регулярно и с ответственностью за результат. Практический ориентир: если в компании сейчас нет никого, кто поддерживает хотя бы один серверный сервис, свой контур означает появление новой функции целиком.
Это не запрет, а поправка к сравнению. Считать надо не разницу в счетах за модель, а стоимость новой эксплуатационной ответственности — включая ночь, когда сервер перестанет отвечать.
Разрыв в качестве сократился, но мерить его надо на своих задачах
Моя оценка такая: на типовых деловых задачах — поддержать диалог, разобрать обращение, найти ответ в документах, заполнить поля карточки — современные открытые модели дают результат, сопоставимый с облачными. Разница сохраняется на сложных многошаговых рассуждениях и на языках, которых мало в обучающих данных; для русского языка качество у разных открытых моделей заметно различается.
Что это значит для решения: общий тезис «открытые модели догнали» верен ровно настолько, насколько он подтверждается на ваших примерах. Модель, которая хорошо отвечает на английском, может путаться в падежах и профессиональном жаргоне русской речи.
Проверка занимает неделю: несколько десятков реальных примеров с эталонными ответами, прогон кандидатов в одинаковых условиях, слепая оценка. Как собрать такой набор — в статье о бенчмарках нейросетей.
Вердикт: чужая таблица отвечает на вопрос «какая модель лучше вообще», а покупателю нужен ответ «какая лучше у нас».
Облачная модель может поменять поведение без вашего участия
Это различие сильнее всего влияет на повседневную работу и обсуждается реже всего. В облаке модель обновляет поставщик по своему графику. Промпт, который работал полгода, начинает давать другой результат: ответы длиннее, формат чуть иной, отказы там, где раньше был ответ. Плюс в том, что улучшения приходят бесплатно; минус — вы не выбираете момент.
В своём контуре версия меняется тогда, когда вы решили. Поведение стабильно сколько угодно долго, что важно там, где результат должен быть воспроизводим: оценка звонков по чек-листу, извлечение полей из документов. Обратная сторона — обновляться всё равно придётся, и это отдельная работа с прогоном проверок.
Отсюда практический вывод. При облачном варианте нужен регулярный прогон эталонного набора, чтобы заметить изменение поведения раньше клиентов. При своём — план обновлений, чтобы не остаться на устаревшей версии, пока рынок ушёл вперёд.
Вердикт: стабильность своего контура — это не отсутствие работы с обновлениями, а право выбирать, когда её делать.
Пик нагрузки облако переживает счётом, свой контур — очередью
Облако гибко по определению: пик обрабатывается тем же способом, что и обычный поток, просто счёт больше. Свой контур ограничен купленным железом, и это его главное эксплуатационное отличие.
Если поток неравномерный — рекламные кампании, сезонность, дни отчётности, — мощность придётся закладывать под пик, а в остальное время она простаивает. Именно поэтому «своё дешевле» перестаёт быть верным при сильной неравномерности.
Рабочий обход — очередь с приоритетами. Часть задач не требует немедленного ответа: ночная обработка записей, подготовка сводок, разбор архива. Их откладывают на непиковое время, и мощность считается по пику интерактивных задач, а он заметно ниже общего.
Происхождение весов — вопрос закупки, а не утечки
Открытые модели выпускают разные разработчики, в том числе зарубежные. Технически после развёртывания в своём контуре данные никуда не уходят независимо от того, кто обучил модель: веса — это файл, а не канал связи.
Но для части заказчиков — государственный сектор, финансовые организации, критическая инфраструктура — важен сам факт, чья это модель. Такие требования появляются в закупочной документации и политике безопасности, а не в техническом задании.
Вердикт: выяснять это стоит на первой встрече, а не на этапе согласования договора, когда модель уже выбрана и проверена. О рисках опоры на зарубежных поставщиков — в статье о зависимости от зарубежных моделей.
Гибридная схема: маршрут выбирает система, а не сотрудник
Выбор между контуром и облаком часто оказывается ложной развилкой: задачи в компании разные, и требования к ним тоже. Разделение проводится по данным. Всё, что содержит персональные данные, коммерческую тайну или сведения под отраслевыми требованиями, обрабатывается там, где это допустимо. Остальное может идти в облако, где дешевле и быстрее стартовать.
Условие, при котором схема работает: решение о маршруте принимает система по заданным правилам, а не человек в момент запроса. Правило «сотрудник сам решает, что можно отправить наружу» не выполняется — не по злому умыслу, а потому что в потоке работы такие решения принимаются автоматически и неверно. Почему руководителю важнее путь поручения, чем имя модели, — в статье про агента-координатора.
Когда не нужны ни свой контур, ни прямая работа с API
Оба варианта предполагают, что компания сама встраивает модель в процесс. Это не нужно, если задача закрывается готовым продуктом, в котором вопросы хранения данных и выбора модели уже решены поставщиком: транскрибация встреч, контроль качества звонков, AI-агент первой линии. Проверять тогда стоит не модель, а поставщика — где он хранит данные и что будет при расставании.
Свой контур не окупится при небольшом и нерегулярном потоке: несколько десятков запросов в день не оправдывают сервер и человека при нём. И наконец, часть задач вообще не требует нейросети. Разложить заявки по трём категориям по ключевым словам или проверить заполненность полей можно правилами — дешевле, быстрее и предсказуемее. Шире о таких случаях — в статье когда AI не нужен.
Порядок решения: данные, стоимость владения, проверка качества
Что это меняет в решении: выбор между открытой моделью и облачным API перестаёт быть спором инженеров о предпочтениях и превращается в последовательность из четырёх вопросов. Какие данные пойдут в модель и куда им можно. Сколько стоит каждый вариант за год целиком, включая людей. Какая модель справляется с вашими примерами. Есть ли у заказчиков требования к происхождению модели.
Я бы начинал с первого вопроса и не переходил ко второму, пока юрист и служба безопасности не ответили письменно. Проверить остальное на своих данных можно без вложений в инфраструктуру: соберите несколько десятков обезличенных примеров, прогоните их через облачную модель и через открытую, развёрнутую на арендованных мощностях, и сравните качество, время ответа и стоимость. Если разница в качестве незаметна, решение определят данные и бюджет.
Почему разворачивание модели не заменяет базу знаний — в статье про дообучение и базу знаний. Как идёт работа по этапам — на странице внедрения ИИ.
