img
img14 августа 2026 в 09:30

Открытая модель дешевле в ценнике и дороже в эксплуатации

По данным Nodul, большие языковые модели на базе открытого кода в среднем в 40 раз дешевле проприетарных. Чем объясняется такая большая разница в стоимости и как она складывается? В чём фундаментальная разница между моделями?

По данным Nodul, большие языковые модели на базе открытого кода в среднем в 40 раз дешевле проприетарных. Чем объясняется такая большая разница в стоимости и как она складывается? В чём фундаментальная разница между моделями?

Цифра звучная, но она описывает ценник за обработку данных, а совокупная стоимость владения устроена сложнее. Разница возникает потому, что мы сравниваем две принципиально разные модели оплаты.

У открытых решений вы платите за арендованный сервер, и стоимость миллиона токенов (токен — часть слова или знак препинания) получается делением аренды на объём сгенерированного текста. Чем плотнее загружена видеокарта и чем выше скорость генерации, тем дешевле выходит каждый токен. У закрытых моделей вы платите за сам факт обращения по фиксированному прайсу, причем входящие и исходящие токены тарифицируются по-разному.

В расчётах Nodul это видно наглядно: миллион токенов у открытых моделей стоит от 23 руб. (GPT OSS) до 77 руб. (Qwen), а при более высокой скорости генерации — 17 и 51 руб. соответственно. У закрытых зарубежных решений миллион входящих токенов обходится в 140 руб. у GPT-5.2 и в 400 руб. у Claude Opus 4.5. Российские закрытые модели дороже: GigaChat 2 max — 650 руб., Alice AI LLM — 660 руб.

Фундаментальное же различие лежит не в области качества. Открытые веса (обученные параметры модели, по сути её «содержимое»)  можно скачать, развернуть в своем контуре, дообучить на собственных данных и заморозить конкретную версию. Закрытая модель остаётся сервисом: вы получаете доступ через API (программный интерфейс), но не можете её изменить, а решения о версиях и правилах принимает поставщик. По качеству разрыв за последние два года сузился до нескольких процентных пунктов на большинстве тестов, заметное преимущество у флагманских закрытых моделей сохраняется в сложных многошаговых рассуждениях.

И главная оговорка к экономии в 40 раз: она не включает видеокарты, ML-инженеров, мониторинг и обеспечение отказоустойчивости. В Just AI справедливо замечают, что корректно сравнивать только полную стоимость владения, а дефицитные специалисты и GPU стоят дорого.

При каком масштабе проекта открытая модель становится экономически оправданнее, а когда выгоднее платить за API?

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

Ориентир по рынку такой: собственное развёртывание начинает выигрывать у флагманских API при устойчивом потоке в несколько миллионов токенов в сутки и загрузке видеокарты от 60 %. Ниже двух-пяти миллионов токенов в день постоянные расходы, как правило, не отбиваются. Отдельно стоит держать в голове, что сопровождение занимает 10–20 часов инженерного времени в месяц, и это тоже деньги.

Есть и обратный случай. Сравните собственный сервер с недорогими хостингами открытых моделей — по цене он почти никогда не выигрывает. Схожую мысль высказывает руководитель платформы Yandex AI Studio Артур Самигуллин: открытые модели зачастую выгоднее использовать в облаке, поскольку вычислительные мощности, стабильность и безопасность уже входят в стоимость сервиса.

Экономику ломает неравномерная нагрузка. Видеокарту вы оплачиваете круглосуточно, а реальный трафик идёт три часа в день. В таком случае обещанная экономия по пиковой мощности не окупается.

При этом решение часто принимают вовсе не по объёму. Крупный бизнес выбирает открытые модели, когда нужно дообучить систему на собственных данных под узкую задачу: универсальная модель много знает, но прикладной сценарий выполняет нестабильно. Малым компаниям практичнее стартовать на готовом сервисе с оплатой по факту. Разумная стратегия — начать на API, измерить реальное потребление и профиль задач, а затем перенести в свой контур тот сценарий, который стал массовым и стабильным. Гибридная схема, когда разные задачи маршрутизируются на разные модели, сегодня тоже считается нормой.

Экономику ломает неравномерная нагрузка. Видеокарту вы оплачиваете круглосуточно, а реальный трафик идёт три часа в день — и красивый расчёт по пиковой производительности рассыпается.

В проприетарных моделях пользователи не знают веса. Насколько критично это незнание для бизнеса, который внедряет ИИ в важные процессы?

Скажу непопулярную вещь: само по себе знание весов бизнесу почти ничего не даёт. Прочитать миллиарды чисел и понять из них логику решения не может никто, включая авторов модели. Компании ведь не изучают исходный код своей СУБД перед покупкой.

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

Второй риск — прекращение поддержки. Модели снимают с обслуживания, и сроки предупреждения бывают короткими: в феврале 2026 года с площадок убрали Claude 3.5 и 3.7, в марте — GPT-4o. Если под конкретную версию были выверены подсказки и сценарии, всю связку приходится проверять заново.

Третий — воспроизводимость. Если через год регулятор или суд попросит объяснить, почему система приняла именно такое решение, повторить его на исчезнувшей версии не получится. В отраслях с обязательным аудитом это ощутимая проблема, и открытые веса её снимают: версию можно зафиксировать и хранить сколько нужно.

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

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

Проприетарные модели чаще open-source отказываются отвечать на «рискованные» запросы. С чем это связано? Какие ограничения такая цензура несёт для пользователей?

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

Технически это следствие настройки на безопасность. Аудиты моделей показывают сильную связь между осторожностью и избыточными отказами. Модели, которые надежнее всего блокируют по-настоящему опасные запросы, чаще прочих отказывают и на безобидных. При этом сама доля отказов — плохой показатель безопасности: система может отклонять безвредные вопросы и одновременно поддаваться на грамотно составленные вредоносные.

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

Выходы есть, и их два. Корпоративные тарифы у поставщиков позволяют смягчить политику под подтвержденный сценарий использования. Иногда достаточно точнее описать контекст и роль пользователя в запросе. Радикальный путь — открытая модель со своей политикой, но тогда придётся строить собственные ограничители и отвечать за результат. Универсального ответа здесь нет: избыточные отказы мешают работе, а недостаточные в клиентском сервисе обходятся дороже.

Open-source-модели дают полный контроль над данными и инфраструктурой, что критично для компаний с высокими требованиями к приватности. Как вы считаете, для каких сфер бизнеса этот аргумент является решающим?

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

В России у этого аргумента появилось и прямое правовое измерение. Помимо требований 152-ФЗ к обработке персональных данных и ужесточающейся ответственности за утечки, в июле 2026 года принят закон о поддержке развития технологий ИИ. Он вводит статусы суверенной и национальной моделей, а правительство определит случаи, когда допускается применение исключительно таких решений; первые положения вступают в силу уже 1 сентября. Для регулируемых отраслей вопрос смещается из плоскости «что выгоднее» в плоскость «что разрешено».

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

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

Читайте также

Похожие материалы

Петербург будущего? Нейросети показали, как будет выглядеть город с вышками 5G

17.09.2024

В России начали снос бесхозных антенн аналогового телевидения

25.09.2024

Искренне ваш, ИИ-инфлюенсер: бренду — выгода, аудитории — новизна

13.06.2025

«Телеспутник-Экспресс»: Дурова внесли в список террористов: к чему готовиться пользователям Telegram

31.07.2026

От автоответчика до интеллектуального помощника: как ИИ трансформирует облачную телефонию

17.02.2026

Популярные статьи

Подписка на рассылку

Подпишитесь на рассылку, чтобы одним из первых быть в курсе новых событий

Выбор редакции