Собственная языковая модель в закрытом контуре — не экзотика, а обычное требование для банков, промышленности и государственных организаций. Данные не покидают периметр физически, и это снимает большинство вопросов безопасности. Разберём, что для этого действительно нужно: какое железо, какого размера модель и во что обходится владение.
С чего начинается расчёт: не с модели, а с нагрузки
Главная ошибка — сначала выбрать модель, потом искать под неё железо. Правильный порядок обратный: сначала нужно понять профиль нагрузки, и уже он определяет и размер модели, и оборудование.
- Сколько одновременных пользователей в пике, а не в среднем.
- Какая задержка приемлема: ассистент в диалоге и ночная пакетная обработка — принципиально разные требования.
- Насколько длинные запросы и ответы: обработка документа целиком требует памяти намного больше, чем короткий вопрос.
- Круглосуточная работа или в рабочие часы — от этого зависит, окупается ли собственное железо вообще.
Частый и полезный вывод из такого расчёта: значительная часть задач вообще не требует большой модели. Классификация обращений, извлечение полей, маршрутизация прекрасно решаются небольшими моделями, которым хватает одной видеокарты потребительского класса.
Как выбрать размер модели
Размер модели измеряется числом параметров, и от него напрямую зависит требуемая видеопамять. Ориентир простой: в исходной точности каждый миллиард параметров требует примерно два гигабайта видеопамяти, плюс запас на контекст и одновременные запросы. Квантизация — сжатие весов до меньшей разрядности — снижает это требование в два-четыре раза.
Небольшие модели
До нескольких миллиардов параметров. Помещаются на одну видеокарту, работают быстро. Отлично справляются с классификацией, извлечением данных, простыми ответами по инструкции. Для задач с рассуждением слабоваты.
Средние модели
Рабочая лошадка большинства корпоративных внедрений. Требуют серьёзной карты или пары карт, дают приемлемое качество на большинстве прикладных задач, включая ответы по документам и генерацию кода. Именно в этом классе обычно находится оптимум по соотношению цены и результата.
Большие модели
Нужны, когда задача действительно требует рассуждения: разбор сложных договоров, многошаговое планирование. Требуют нескольких дорогих карт и обслуживания. Прежде чем закладывать такую модель, стоит проверить, не решается ли задача разбиением на шаги для средней модели, — часто решается и обходится втрое дешевле.
Квантизация: где выигрыш и где потери
Квантизация уменьшает разрядность весов, сокращая требования к памяти и ускоряя работу. Умеренная квантизация обычно почти не влияет на качество прикладных задач — потери заметны на сложных рассуждениях и на длинных цепочках вывода.
Практический подход: проверять на своём наборе задач, а не верить общим утверждениям. Мы прогоняем одинаковый набор через исходную и квантованную версии и сравниваем ответы вслепую. Если разница на ваших задачах незаметна, квантизация — это способ сэкономить на железе вдвое без потерь.
Что входит в стоимость владения
- Оборудование: карты, сервер, память, хранилище. Основная разовая статья.
- Размещение: стойка, питание, охлаждение, каналы. Для серьёзных карт энергопотребление заметно в счетах.
- Эксплуатация: обновления, мониторинг, восстановление после сбоев, резервирование. Это люди, а не только софт.
- Обновление моделей: раз в несколько месяцев появляются заметно лучшие открытые модели, и переход требует замеров и перенастройки промптов.
- Резерв: что произойдёт, если сервер выйдет из строя. Ответ «сервис не работает» устраивает не всех, а резервирование удваивает стоимость железа.
Считать это надо на два-три года и сравнивать с облачным вариантом на вашем реальном объёме запросов. Точка, где своё железо становится дешевле, зависит от объёма и наличия требования по контуру. Если требование есть — сравнение вообще не нужно, вариант один.
Подводные камни
Модель обновляется, промпты ломаются
Переход на новую версию модели меняет поведение, и промпты, отлаженные под прежнюю, начинают работать хуже. Поэтому нужен набор проверочных задач с эталонными ответами: он превращает обновление из лотереи в измеримую процедуру.
Память кончается на длинном контексте
Расчёт памяти по весам модели — только половина. Контекст занимает существенную часть, и растёт она с длиной запроса и числом одновременных пользователей. Система, работающая на коротких вопросах, ложится на первом же документе целиком.
Одна карта — одна точка отказа
Если сервис критичен для процесса, нужен резерв. Это не техническая деталь, а решение о бюджете, и принимать его должен заказчик, а не подрядчик по умолчанию.
Порядок работ, который обычно работает
- Собрать набор из 50–100 реальных задач с эталонными ответами.
- Проверить их на арендованной GPU в облаке — до всякой закупки. Аренда на неделю стоит несопоставимо меньше ошибки в выборе оборудования.
- Определить минимальный размер модели, дающий приемлемое качество, и проверить квантованную версию.
- Посчитать требования к железу по пиковой нагрузке с запасом на контекст.
- Только после этого закупать — и разворачивать уже проверенную конфигурацию.
Кто и как это обслуживает
Вопрос, который на этапе выбора почти не обсуждают, а потом он определяет успех. Собственная модель — это сервис, который надо эксплуатировать, и у него должен быть хозяин.
Что входит в эксплуатацию
- Мониторинг доступности и времени ответа с оповещением, а не с дашбордом, на который никто не смотрит.
- Обновление драйверов и библиотек. Экосистема вокруг GPU меняется быстро, и обновления иногда ломают то, что работало.
- Восстановление после сбоев: перезапуск сервиса, проверка целостности весов, возврат к предыдущей версии.
- Контроль загрузки: не упирается ли сервис в память при пиковых запросах и не ушёл ли кто-то в бесконечную генерацию.
- Периодическая проверка качества на эталонном наборе — модель не деградирует сама, но меняются запросы и промпты.
Сколько людей нужно
Для одного сервиса на паре карт это не полная ставка, а часть времени системного администратора плюс доступ к человеку, понимающему модели, — на случай, когда что-то ведёт себя странно. Полноценная выделенная роль появляется, когда моделей несколько и они критичны для процессов.
Реалистичная оценка на старте: заложите время администратора на первые недели с запасом. Развёртывание модели — не установка приложения; первый запуск почти всегда упирается в версии драйверов, объём памяти или особенности вашего окружения.
Гибридная схема: своё железо плюс облако
Выбор не обязан быть бинарным. На практике часто выигрывает разделение по чувствительности данных, а не по всему решению целиком.
Задачи с персональными данными и коммерческой тайной идут на собственную модель в контуре. Задачи без чувствительных данных — генерация маркетинговых текстов, работа с публичными документами, черновики — уходят в облако, где качество выше, а платить надо только за использование.
Такая схема требует одного: явного правила маршрутизации и механизма, который его соблюдает. Определять на глаз, «чувствительный ли это запрос», нельзя — нужен формальный признак, привязанный к источнику данных или типу задачи, и журнал того, что куда ушло.
Что проверить до закупки
- Помещается ли выбранная модель в память карты вместе с контекстом при пиковом числе одновременных запросов. Считать надо не только веса.
- Достаточна ли скорость на вашем сценарии. Для диалога и для пакетной ночной обработки требования отличаются в разы.
- Хватает ли качества квантованной версии на ваших задачах — это решение о том, брать одну карту или две.
- Есть ли в серверной место, питание и охлаждение под выбранную конфигурацию. Банальный, но регулярно всплывающий вопрос.
- Что происходит при отказе: есть ли резерв, приемлем ли простой, кто и как восстанавливает.
Все эти пункты проверяются на арендованной в облаке GPU за несколько дней. Это единственный способ узнать реальные требования до того, как оборудование куплено, — и он несопоставимо дешевле, чем обнаружить нехватку памяти после поставки.
Когда своё железо не нужно
Честно назовём случаи, когда закрытый контур — избыточное решение, за которое вы просто переплатите.
- Данные не чувствительные, а объём запросов небольшой. Облако будет дешевле и проще, и это не компромисс, а правильный выбор.
- Задача разовая или сезонная. Оборудование, простаивающее одиннадцать месяцев в году, не окупится.
- Нет ресурса на эксплуатацию. Сервис без присмотра ляжет, и это вопрос не «если», а «когда».
- Требования по контуру не сформулированы, а взяты по инерции. Стоит уточнить у службы безопасности, действительно ли задача требует изоляции, — иногда достаточно обезличивания.
Как модель попадает из репозитория в ваш контур
Практический вопрос, который на этапе планирования обычно упускают: закрытый контур означает отсутствие интернета, а модели скачиваются из внешних репозиториев. Процесс доставки надо продумать заранее.
Обычная схема такая: модель скачивается на промежуточную машину с доступом в интернет, проверяется на целостность по контрольным суммам, сканируется средствами информационной безопасности и переносится в контур согласованным способом. Для организаций с жёстким режимом это отдельная процедура со своими сроками, и её стоит инициировать в первый день проекта.
Отдельно про лицензии. Открытые модели распространяются на разных условиях: часть допускает коммерческое использование без ограничений, часть содержит требования по объёму бизнеса или запреты на отдельные применения. Проверять лицензию нужно до того, как модель легла в основу решения, — замена на поздней стадии означает повторные замеры качества и перенастройку промптов.
И ещё один пункт, который часто всплывает при проверках: библиотеки, из которых собирается сервис, тоже приходят из внешних репозиториев и тоже требуют контроля. Практика, которая снимает большую часть вопросов, — собственное зеркало зависимостей с зафиксированными версиями. Заодно это защищает от ситуации, когда сборка перестаёт воспроизводиться из-за изменений снаружи.
Типичные проблемы первого запуска
Развёртывание модели редко проходит гладко с первого раза. Перечислим то, на чём спотыкаются чаще всего, — предупреждённая проблема стоит дешевле.
- Несовпадение версий драйверов и библиотек. Самая частая причина, по которой сервис не стартует. Лечится фиксацией версий и контейнеризацией, но обнаруживается обычно в первый день.
- Нехватка памяти на пиковой длине запроса. Сервис работает на коротких вопросах и падает на первом длинном документе, потому что расчёт делали только по весам модели.
- Медленный первый запрос. Модель загружается в память несколько десятков секунд, и если сервис перезапускается часто, пользователи регулярно ждут. Решается прогревом при старте.
- Неожиданное поведение при одновременных запросах. Один пользователь получает ответ за секунду, десять — за двадцать. Требует настройки пакетной обработки, а не просто более мощной карты.
- Отсутствие ограничения на длину ответа. Модель уходит в длинную генерацию, занимает память и тормозит остальных. Лимит ставится сразу.
Общий вывод из этого списка: закладывайте на первый запуск больше времени, чем кажется разумным. Развёртывание модели ближе к пусконаладке оборудования, чем к установке приложения, и нормально, если первая неделя уходит на приведение окружения в рабочее состояние.
Коротко
- Начинать надо с профиля нагрузки, а не с выбора модели: нагрузка определяет и размер, и железо.
- Большинству прикладных задач достаточно небольшой или средней модели; большая нужна там, где требуется рассуждение.
- Квантизация часто экономит вдвое без заметных потерь, но проверять это надо на своих задачах.
- В стоимость владения входят размещение, эксплуатация, обновление моделей и резервирование, а не только карты.
- Проверяйте конфигурацию на арендованной GPU до закупки — это самый дешёвый способ не ошибиться на миллионы.