On-prem LLM: стоит ли разворачивать языковую модель на своих серверах

На днях звонит знакомый — IT-директор с завода. Голос уставший: «Слушай, мы уже полгода пытаемся поднять свою LLM на серверах. Закупили железо, нашли ML-инженера, а оно до сих пор толком не работает. Может, ну его, просто ChatGPT оплатить?»

Типичная история. Идея «своего GPT» на своих серверах звучит круто: данные под контролем, ни от кого не зависишь, никаких подписок. А потом оказывается, что реальность посложнее, чем рассказывали в продажных вебинарах.

Я не собираюсь агитировать ни за, ни против. Иногда on-prem LLM — единственный нормальный вариант. Иногда — выброшенные деньги. Попробуем разобраться, как понять, что у вас, и честно посчитать расходы.

Зачем вообще люди хотят свой LLM на серверах

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

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

Понятные расходы. Токены — штука непредсказуемая. Запустил новую фичу, народ подхватил — и счёт за API скакнул втрое. Со своим железом проще: купил сервер, платишь за свет и поддержку. Не факт, что дешевле, но хотя бы бюджет можно свёрстать.

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

Кастомизация. Хочется дообучить модель на своих данных, прикрутить нестандартно, добавить хитрую логику. С облачными API это или нельзя, или сильно ограничено. On-prem даёт свободу — и ответственность за всё, что накрутишь.

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

Из чего состоит вся эта кухня

«Поставить LLM на сервер» — звучит как одна задача. На деле это куча компонентов, каждый требует внимания и ресурсов. Разберём по частям.

Слой inference — где модель отвечает на запросы

Это сердце системы. Здесь загружена языковая модель, сюда приходят запросы, отсюда уходят ответы. Для inference нужен сервер с GPU — причём не любой видеокартой, а специализированной для машинного обучения. NVIDIA A100, H100 или хотя бы A10 — вот типичные варианты для продакшена.

Почему GPU, а не CPU? Языковые модели состоят из миллиардов параметров, и для генерации ответа нужно выполнить огромное количество матричных операций. GPU делает это на порядки быстрее благодаря параллельной архитектуре. На CPU модель размером 7 миллиардов параметров будет генерировать ответ минуты, на хорошем GPU — секунды.

Есть нюанс с памятью. Модель нужно полностью загрузить в память GPU (или распределить по нескольким GPU). Модель в 7 миллиардов параметров в формате float16 занимает около 14 ГБ памяти. Модель в 70 миллиардов — уже 140 ГБ. Для больших моделей нужны либо очень дорогие GPU с большой памятью, либо кластер из нескольких карт.

Слой embeddings — для работы с контекстом

Если вы планируете использовать RAG (Retrieval-Augmented Generation) — а это самый частый сценарий для корпоративных LLM — понадобится отдельный компонент для создания эмбеддингов. Это векторные представления текстов, которые позволяют находить релевантные документы для добавления в контекст.

Эмбеддинг-модели обычно меньше генеративных и менее требовательны к ресурсам. Но они тоже требуют GPU для приемлемой производительности, особенно если нужно обрабатывать большие объёмы документов.

Векторная база данных

Созданные эмбеддинги нужно где-то хранить и быстро искать по ним. Для этого используются специализированные векторные базы данных: Milvus, Weaviate, Qdrant, Chroma. Каждая имеет свои особенности, но все они требуют ресурсов на хранение и индексацию.

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

API Gateway и балансировка

Между пользователями и моделью нужен промежуточный слой. Он принимает запросы, проверяет авторизацию, управляет очередью, распределяет нагрузку между GPU-серверами, собирает метрики, логирует всё для аудита. Это может быть как готовое решение (vLLM, TGI, Triton Inference Server), так и собственная разработка.

Guardrails и фильтрация

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

Мониторинг и observability

Как понять, что система работает нормально? Какие запросы вызывают проблемы? Где узкое место — в модели, в базе, в сети? Для ответа на эти вопросы нужны инструменты мониторинга: сбор метрик, трейсинг запросов, алерты на аномалии. Prometheus, Grafana, Jaeger — типичный стек.

Какую модель выбрать для локального развёртывания

Вот здесь начинается самое интересное — и самое сложное. В отличие от облачных API, где вы просто выбираете «GPT-4» или «Claude», для on-prem нужно принимать решения о конкретных моделях и их версиях.

Первый выбор — открытые или коммерческие модели. Открытые модели (Llama, Mistral, Qwen) можно использовать бесплатно, но их качество обычно уступает топовым коммерческим решениям. Коммерческие модели для локального развёртывания предлагают некоторые компании, но это дороже и сложнее в лицензировании.

Второй выбор — размер модели. Модели бывают от 1 миллиарда параметров (компактные, быстрые, но ограниченные) до 400+ миллиардов (мощные, но требующие серьёзной инфраструктуры). Золотая середина для корпоративного использования — модели в диапазоне 7-70 миллиардов параметров.

Есть техники сжатия моделей — квантизация, которая уменьшает требования к памяти в 2-4 раза с небольшой потерей качества. Квантизованная модель 70B может работать на одном GPU с 80 ГБ памяти вместо кластера. Но качество падает, и для критичных задач это может быть неприемлемо.

Мой совет: начните с модели 7-8B, настройте всю инфраструктуру, отладьте процессы. Потом, если качества не хватает, переходите на более крупную модель. Пытаться сразу запустить модель на 70B без опыта — верный путь к разочарованию.

Считаем TCO: во что реально обойдётся своя LLM

Теперь самое важное — деньги. TCO (Total Cost of Ownership) для on-prem LLM складывается из нескольких компонентов, и каждый из них может неприятно удивить.

Капитальные затраты (CAPEX)

Это то, что нужно купить один раз. Главная статья — GPU-серверы. Один сервер с NVIDIA A100 (80 ГБ) обойдётся в $15 000-25 000 в зависимости от конфигурации и поставщика. H100 — ещё дороже, $25 000-40 000 за карту. Для модели 70B нужно минимум два таких сервера (основной и резервный), а для высокой нагрузки — больше.

Прибавьте серверы для API Gateway, векторной базы, мониторинга. Сетевое оборудование. Системы хранения. Охлаждение (GPU-серверы выделяют много тепла). Источники бесперебойного питания.

Операционные затраты (OPEX)

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

Электричество. GPU-сервер потребляет 1-2 кВт в режиме нагрузки. При круглосуточной работе это 700-1400 кВт·ч в месяц на один сервер. По коммерческим тарифам — $50-150 в месяц только на электричество. Плюс охлаждение, которое потребляет сопоставимо.

Аренда места в дата-центре. Если серверы стоят не в вашем офисе (а для серьёзной инфраструктуры лучше в ЦОД), аренда стойко-места с охлаждением и питанием — $500-1500 в месяц.

Персонал. Это главная скрытая статья расходов. Кто-то должен поддерживать инфраструктуру, обновлять модели, реагировать на инциденты, оптимизировать производительность. Это либо выделенный ML-инженер ($3 000-8 000 в месяц в зависимости от региона), либо часть времени существующих DevOps/SRE специалистов.

Обновления и развитие. Модели устаревают, появляются новые версии, меняются требования бизнеса. Закладывайте 15-20% от CAPEX ежегодно на обновления и модернизацию.

Сравнение с облачными API

Теперь честный вопрос: а сколько стоит облако? Давайте сравним.

GPT-4o стоит примерно $5 за 1 миллион входных токенов и $15 за 1 миллион выходных. Средний корпоративный запрос — около 1000 входных и 500 выходных токенов. Значит, один запрос стоит примерно $0,0125 (около 1 рубля).

Если ваша компания делает 10 000 запросов в день — это $125 в день, или $3 750 в месяц. 100 000 запросов — $37 500 в месяц. При таком объёме on-prem начинает окупаться примерно через 1-2 года.

Но есть нюанс: открытые модели, которые вы ставите on-prem, обычно уступают GPT-4o в качестве. Если честно сравнивать, нужно либо принять это ограничение, либо учесть затраты на дообучение и оптимизацию.

Ограничения on-prem: о чём не пишут в рекламных материалах

Теперь давайте поговорим о том, с чем вы столкнётесь на практике. Это не причины отказаться от on-prem, но факторы, которые нужно учитывать.

Качество моделей отстаёт от frontier

Лучшие открытые модели (Llama 3.1, Qwen 2.5, Mistral) хороши, но они всё ещё уступают GPT-4o и Claude 3.5 в сложных задачах. Разрыв сокращается, но он есть. Если ваши задачи требуют топового качества — придётся либо мириться с ограничениями, либо комбинировать on-prem с облачными API для сложных случаев.

Обновления — ваша головная боль

OpenAI выпустил новую версию GPT — и все пользователи API получили её автоматически. С on-prem каждое обновление модели — это проект: скачать новую версию, протестировать, убедиться что ничего не сломалось, раскатить в продакшен. Это занимает время и требует экспертизы.

А ещё новые модели могут требовать больше ресурсов. Llama 3 работала на вашем сервере отлично, а Llama 4 уже требует в два раза больше памяти. И вы оказываетесь перед выбором: остаться на старой версии или покупать новое железо.

Масштабирование — сложно и дорого

В облаке масштабирование — это ползунок в интерфейсе. Нужно больше мощности — платите больше, получаете больше. С on-prem каждое увеличение мощности — это закупка железа, доставка, установка, настройка. Это недели или месяцы, а не минуты.

Пиковые нагрузки — отдельная проблема. Если у вас сезонный бизнес или бывают всплески активности — придётся либо держать избыточные мощности (переплачивая в спокойное время), либо мириться с деградацией производительности в пики.

Экспертиза — критичный ресурс

ML-инженеры с опытом развёртывания LLM — дефицитный ресурс. Их мало, они дорогие, и они легко уходят к конкурентам. Если вся экспертиза сосредоточена в одном человеке — вы в зоне риска. Что будет, если он уволится? Кто будет поддерживать систему?

Аутсорс поддержки возможен, но тогда теряется часть преимуществ on-prem: внешний подрядчик всё равно получает доступ к вашей инфраструктуре и данным.

Промежуточные варианты: VPC и managed inference

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

Virtual Private Cloud (VPC)

Некоторые провайдеры предлагают развернуть LLM в изолированном облачном контуре, который логически принадлежит только вам. Данные не смешиваются с другими клиентами, можно настроить шифрование, ограничить сетевой доступ. Это проще в управлении, чем полноценный on-prem, но даёт часть его преимуществ.

Azure OpenAI Service, Amazon Bedrock, Google Vertex AI — все предлагают варианты с повышенной изоляцией. Это дороже стандартного API, но дешевле и проще полного on-prem.

Managed inference платформы

Можно арендовать GPU в облаке и развернуть на них открытую модель. Вы контролируете модель и данные, но не занимаетесь железом. Runpod, Lambda Labs, Together AI — примеры таких платформ. Это компромисс между контролем и операционной сложностью.

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

Гибридные архитектуры

Часто оптимальное решение — комбинация. Простые запросы обрабатывает локальная модель. Сложные, требующие максимального качества — уходят в облачный API. Конфиденциальные данные остаются on-prem, публичная информация может обрабатываться в облаке.

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

Как не провалить проект on-prem LLM

Если вы всё-таки решили идти в on-prem, вот несколько советов из практики, которые помогут избежать типичных ошибок.

Начните с пилота на арендованном железе. Не покупайте сервера сразу. Арендуйте GPU в облаке на месяц-два, разверните инфраструктуру, протестируйте на реальных задачах. Это поможет понять реальные требования к ресурсам и избежать ошибок в закупках.

Определите метрики успеха заранее. Что значит «работает хорошо»? Какая точность ответов приемлема? Какое время отклика допустимо? Сколько одновременных пользователей должна выдерживать система? Без чётких критериев вы будете бесконечно «дотюнивать» систему.

Закладывайте запас по ресурсам. Если расчёты показывают, что достаточно 16 ГБ GPU-памяти — берите 24 или 32. Модели растут, требования растут, лучше иметь запас, чем через полгода покупать новое железо.

Автоматизируйте всё, что можно. Развёртывание, обновления, мониторинг, бэкапы — всё должно работать без ручного вмешательства. Иначе поддержка системы съест всё время вашей команды.

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

Планируйте отказоустойчивость с первого дня. Что будет, если GPU-сервер выйдет из строя? Если кончится место на диске? Если сеть упадёт? Для каждого сценария должен быть план действий и, желательно, автоматическое восстановление.

Чек-лист готовности к on-prem LLM

Прежде чем принимать решение, пройдитесь по этому списку. Если на большинство вопросов вы отвечаете «нет» — возможно, стоит начать с облачного решения.