Self-hosted LLM: как развернуть языковую модель на своих серверах и не пожалеть

Переговорная комната в одном алматинском банке. IT-директор откидывается на стуле и говорит то, что мы уже слышали десятки раз: «Никакие данные клиентов не должны покидать наш контур. Ни один запрос — на внешние серверы. Это не обсуждается».

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

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

Зачем вообще это нужно

Но прежде чем закапываться в железо и конфигурации — надо признать очевидное. Своя LLM-инфраструктура это боль. Много боли. Когда оно реально оправдано, а когда проще заплатить OpenAI и не мучиться?

Данные нельзя выпускать наружу

Главная причина, по которой компании вообще смотрят в сторону self-hosted. Каждый запрос к ChatGPT или Claude — это ваши данные на чужих серверах. Для банков и финтеха это сразу стоп: регулятор требует локализации персональных данных. Медицинские организации не могут рисковать данными о здоровье пациентов. Госсектору часто запрещено использование иностранных облаков в принципе. Крупный бизнес с NDA понимает: информация о клиентах, сделках и внутренних процессах не должна покидать периметр.

Даже если провайдер обещает не использовать ваши данные для обучения (а OpenAI для API это гарантирует), сам факт передачи данных на внешние серверы может нарушать compliance-политики или условия договоров с клиентами.

Не хочется зависеть от дяди

В марте 2023-го OpenAI отрубил доступ к API для ряда регионов. Просто так. Без предупреждения. А уж сколько раз были outage, когда у миллионов пользователей всё встало — не сосчитать. Когда ваш бизнес-процесс висит на чужом API, вы заложник.

Своё железо — это контроль. Модель работает, пока работает ваш сервер. Никто не поднимет цены втрое, не поменяет условия, не отключит доступ. Вы сами решаете, когда обновляться и как настраивать.

Счета от OpenAI уже пугают

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

Своё железо требует вложений на старте, зато каждый запрос обходится в 5-10 раз дешевле. При 50-100 тысячах запросов в день вы уже в плюсе. Точка окупаемости — вопрос математики, а не философии.

Хочется заточить модель под себя

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

Какую модель выбрать: ландшафт open-source LLM

Хорошая новость: за последние два года экосистема open-source моделей взорвалась разнообразием. Плохая новость: из-за этого выбор стал сложнее. Вот что сейчас есть на рынке и для каких задач это подходит.

Llama от Meta

Семейство Llama стало стандартом де-факто для self-hosted решений. Актуальная версия — Llama 3.1, доступная в размерах 8B, 70B и 405B параметров. Модель отлично работает с русским языком (что критично для Казахстана), имеет либеральную лицензию для коммерческого использования и широкую экосистему инструментов.

Llama 3.1 70B по качеству близка к GPT-4 в большинстве бизнес-задач, а 8B-версия — отличный выбор для запуска на скромном железе или для задач, где скорость важнее глубины понимания.

Mistral и Mixtral

Французский стартап Mistral выпустил несколько интересных моделей. Mistral 7B удивительно хороша для своего размера — работает быстро даже на CPU. Mixtral 8x7B использует архитектуру Mixture of Experts, обеспечивая качество 70B-модели при меньших вычислительных затратах.

Особенно хорош Mistral для задач, где нужен баланс между скоростью и качеством: чат-боты для FAQ, классификация обращений, генерация коротких текстов.

Qwen от Alibaba

Qwen 2.5 — тёмная лошадка, которая заслуживает внимания. Особенно хороша для работы с кодом и структурированными данными. Есть версии от 0.5B до 72B параметров, что даёт гибкость при выборе.

Специализированные модели

Для узких задач часто лучше работают fine-tuned версии базовых моделей. CodeLlama заточена под код, документацию, технические тексты — если ваш бот помогает разработчикам, это она. Llama-2-Chat оптимизирована для диалогов и хорошо держит контекст разговора. А для RAG-систем понадобятся отдельные embedding-модели типа BGE или E5 — они превращают текст в векторы для поиска.

Инфраструктура: GPU, CPU и что между ними

Вот мы подошли к самому интересному (и дорогому) вопросу: на чём всё это запускать. Тут есть варианты от «хотим сэкономить» до «деньги не проблема, нужно качество».

Вариант 1: Только GPU — максимальная производительность

Если вам нужна высокая скорость генерации и большие объёмы — без GPU не обойтись. Стандарт для продакшена — NVIDIA, потому что экосистема CUDA самая зрелая.

Теперь про конкретные карты. NVIDIA A100 (40GB или 80GB) — золотой стандарт для inference, одна карта потянет 70B-модель в 4-bit квантизации. Цена от $10 000 за б/у до $15 000+ за новую. H100 — следующее поколение, быстрее в 2-3 раза, но и стоит от $25 000, имеет смысл только для очень высоких нагрузок. RTX 4090 — потребительская карта, но с 24GB VRAM: потянет 8B-модели комфортно, 13B — впритык, цена около $2 000, хороший вариант для пилота. L40S — серверная альтернатива 4090 с 48GB VRAM за ~$7 000, отличный баланс цены и возможностей.

Вариант 2: Только CPU — когда GPU недоступен

Звучит странно, но бывает, что CPU-inference — единственный вариант. Например, когда регулятор запрещает использование GPU-серверов в облаке, а своих GPU нет. Или когда нагрузка маленькая и покупать GPU нерационально.

Современные библиотеки вроде llama.cpp оптимизированы для CPU и используют AVX-инструкции. На хорошем серверном процессоре (Intel Xeon или AMD EPYC) можно получить 5-10 токенов в секунду для 7B-модели. Это медленно, но для некоторых задач достаточно.

Ключевое требование — много RAM. Для 7B-модели в 4-bit квантизации нужно минимум 8GB RAM, для 70B — около 40GB.

Вариант 3: Гибридный подход

На практике часто работает гибридная схема. Маленькая модель (7-8B) крутится на GPU и отвечает за быстрые ответы и массовые задачи. Большая модель (70B) живёт на CPU или в облаке и подключается только для сложных случаев. А model routing решает, какую модель использовать для конкретного запроса — простой вопрос идёт на быструю модель, сложный — на умную.

Стек развёртывания: от модели к API

Скачать модель — это только начало. Дальше её нужно превратить в работающий сервис, который можно интегрировать с CRM, чат-ботом или другими системами. Рассмотрим типичный стек.

Inference-серверы: кто обслуживает запросы

Есть несколько популярных решений для запуска моделей:

• vLLM — оптимизирован для высокой пропускной способности, использует PagedAttention для эффективного управления памятью. Отличный выбор для продакшена с высокой нагрузкой.
• TGI (Text Generation Inference) от Hugging Face — хорошая документация, простая интеграция с экосистемой HF. Чуть медленнее vLLM, но проще в настройке.
• llama.cpp — минималистичное решение на C++, отлично работает на CPU, поддерживает множество квантизаций. Идеален для edge-deployment.
• Ollama — обёртка над llama.cpp с удобным CLI и REST API. Самый простой способ запустить модель локально за 5 минут.

API-шлюз: единая точка входа

Между inference-сервером и вашими приложениями обычно стоит API-шлюз, который решает несколько задач:

• Аутентификация и авторизация — кто и с какими правами может делать запросы
• Rate limiting — защита от перегрузки и злоупотреблений
• Load balancing — распределение нагрузки между несколькими GPU
• Кэширование — хранение ответов на частые запросы
• Логирование — запись всех запросов для аудита и отладки

Популярные варианты: LiteLLM (OpenAI-совместимый API для любых моделей), Kong или Nginx с плагинами, собственные решения на FastAPI/Flask.

RAG-пайплайн: контекст из базы знаний

Сама по себе LLM знает только то, на чём обучена. Чтобы она отвечала по вашим данным (документация, база знаний, история клиентов), нужен RAG-пайплайн:

• Векторная БД — Qdrant, Milvus, Chroma или pgvector для PostgreSQL
• Embedding-модель — тоже можно развернуть локально (BGE, E5, multilingual-e5)
• Chunking и препроцессинг — разбиение документов на фрагменты оптимального размера

Эксплуатация: как не сойти с ума после запуска

Развернуть модель — полдела. Дальше начинается эксплуатация: мониторинг, обновления, устранение инцидентов. Тут есть свои нюансы.

Мониторинг: что отслеживать

LLM-инфраструктура требует специфических метрик помимо стандартных CPU/RAM/диск:

• GPU utilization — загрузка видеокарты должна быть 70-90%. Ниже — недоиспользуете ресурс, выше — риск очередей.
• VRAM usage — память GPU. При приближении к лимиту начинаются ошибки OOM.
• Time to first token (TTFT) — сколько ждать первого слова ответа. Влияет на UX.
• Tokens per second (TPS) — скорость генерации. Падение может сигнализировать о проблемах.
• Queue depth — длина очереди запросов. Если растёт — нагрузка превышает возможности.
• Error rate — процент неуспешных запросов

Для мониторинга подходят стандартные инструменты: Prometheus + Grafana, Datadog. vLLM и TGI имеют встроенные метрики для Prometheus.

Алертинг: когда что-то пошло не так

Настройте алерты на критичные ситуации:

• GPU utilization > 95% более 5 минут
• Error rate > 1%
• TTFT > 5 секунд
• Queue depth > 100 запросов
• Температура GPU > 85°C

Обновление модели: как не сломать продакшен

Новые версии моделей выходят регулярно. Как обновляться безопасно:

1. Тестовый контур. Всегда разворачивайте новую версию на тестовом сервере и прогоняйте golden set — набор эталонных запросов с ожидаемыми ответами.
2. A/B-тестирование. Направьте 5-10% трафика на новую версию, сравните метрики качества и производительности.
3. Canary deployment. Постепенно увеличивайте долю трафика на новую версию, отслеживая метрики.
4. Rollback plan. Всегда должна быть возможность быстро откатиться к предыдущей версии.

Экономика self-hosted: считаем TCO

Сколько на самом деле стоит владеть своим LLM? Посчитаем Total Cost of Ownership для реального сценария — компании, которая обрабатывает 30 000 запросов в день.

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

Единоразовые инвестиции в железо:

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

Ежемесячные расходы:

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

30 000 запросов в день — это ~900 000 в месяц. При среднем запросе в 2000 токенов (input + output):

• GPT-4 Turbo: ~$15 000/месяц (при $10/$30 за миллион токенов)
• Claude 3 Sonnet: ~$5 400/месяц (при $3/$15 за миллион токенов)
• Self-hosted: ~$1 300/месяц (OPEX) + амортизация $680/месяц (CAPEX / 36 мес)

Особенности развёртывания в Казахстане

Местная специфика добавляет несколько нюансов к типовому сценарию.

Где размещать серверы

Варианты для физического размещения GPU-серверов в Казахстане:

• Крупные ЦОД в Алматы и Астане — Beeline Cloud, Kaztelecom, PS Cloud и другие предлагают колокацию. Стоимость: от $200/месяц за 1U.
• Собственная серверная — если есть помещение с хорошим охлаждением и резервным питанием. Учтите, что GPU-серверы шумные и горячие.
• Облачные GPU в СНГ — Yandex Cloud, Selectel предлагают GPU-инстансы. Данные остаются в регионе, но зависимость от провайдера сохраняется.

Закупка оборудования

NVIDIA A100 и H100 в Казахстане купить непросто — санкционные ограничения и дефицит. Варианты:

• Локальные дистрибьюторы — часто есть RTX 4090 и L40S, но с наценкой 20-30%
• Параллельный импорт — через ОАЭ, Гонконг. Работает, но сроки и гарантии непредсказуемы.
• Б/у оборудование — A100 из вывода из эксплуатации в Европе. Риски, но цена в 1.5-2 раза ниже.

Команда и экспертиза

Главная проблема — кадры. ML-инженеров с опытом inference-оптимизации в Казахстане единицы. Варианты решения:

• Удалённые специалисты из России, Беларуси, Украины
• Обучение своих DevOps-инженеров (базовые навыки можно освоить за 2-3 месяца)
• Партнёрство с интеграторами, которые возьмут на себя развёртывание и первоначальную поддержку

Пошаговый план: от идеи до продакшена

Если вы решили двигаться в сторону self-hosted LLM — вот реалистичный план действий.

Этап 1: Discovery и PoC (2-4 недели)

• Определите use case: какие задачи будет решать модель
• Оцените объём нагрузки: сколько запросов в день, пиковая нагрузка
• Запустите PoC на арендованных GPU (облако или GPU-хостинг)
• Протестируйте несколько моделей на реальных данных
• Соберите baseline метрики: качество ответов, latency, throughput

Этап 2: Выбор и закупка инфраструктуры (4-8 недель)

• Финализируйте выбор модели на основе PoC
• Рассчитайте требования к инфраструктуре (GPU, RAM, storage)
• Закупите оборудование или арендуйте в ЦОД
• Параллельно: настройте мониторинг, CI/CD, безопасность

Этап 3: Развёртывание и интеграция (4-6 недель)

• Разверните inference-сервер (vLLM, TGI)
• Настройте API-шлюз, аутентификацию, rate limiting
• Если нужно — поднимите RAG-пайплайн (векторная БД, embedding)
• Интегрируйте с целевыми системами (CRM, чат-бот, внутренний портал)
• Проведите нагрузочное тестирование

Этап 4: Пилот и выход в продакшен (2-4 недели)

• Запустите на ограниченной группе пользователей
• Собирайте фидбек, мониторьте качество и производительность
• Итерируйте: дорабатывайте промпты, настраивайте модель
• Постепенно расширяйте на всех пользователей

Общий срок: 3-5 месяцев от старта до продакшена. Это не быстро, но для серьёзного проекта — реалистично.

Вместо заключения: стоит ли игра свеч

Self-hosted LLM — это не серебряная пуля и не магия. Это инженерный проект, который требует инвестиций, экспертизы и постоянного внимания. Но для правильных use cases это может быть единственным разумным решением.

Вот честный итог:

И помните: гибридные сценарии тоже работают. Можно держать чувствительные данные на своей инфраструктуре, а для общих задач использовать облачные API. Главное — осознанно выбирать, понимая trade-offs каждого варианта.

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