Облачные API от OpenAI, Anthropic и других провайдеров закрывают большинство задач: они не требуют капитальных вложений, масштабируются по щелчку и всегда предлагают свежие версии моделей. Поэтому первый вопрос, который стоит задать себе перед развёртыванием локальной LLM, — не «как», а «зачем». В подавляющем большинстве проектов ответом будет «незачем», и это нормально. Но есть класс сценариев, где локальное развёртывание перестаёт быть прихотью и становится требованием. Разберём их честно — вместе с ценой вопроса.
Когда локальная LLM действительно оправдана
Требования к защите данных и комплаенс. Это главный и самый частый триггер. Если через модель проходят персональные данные, банковская тайна, врачебная тайна, гостайна или коммерчески чувствительная информация, отправка её во внешний контур может быть прямо запрещена регуляторами или внутренней политикой безопасности. В России и Казахстане законодательство о локализации персональных данных, отраслевые требования (финансы, госсектор, критическая инфраструктура) часто делают облачный вариант нежизнеспособным. Локальная модель, работающая в изолированном контуре, снимает этот вопрос полностью.
Работа без доступа в интернет. Промышленные объекты, буровые платформы, закрытые сегменты сети, объекты в отдалённых регионах — там, где стабильного канала во внешний мир просто нет или он запрещён по режиму. Если LLM-функциональность нужна внутри такого контура, альтернативы локальному развёртыванию не существует.
Предсказуемая стоимость при высокой нагрузке. Облачные API тарифицируются за токены. При небольшом или среднем объёме это дёшево. Но когда речь идёт о миллионах запросов в сутки, стабильной круглосуточной нагрузке, счёт может превысить стоимость собственного железа за считанные месяцы. Здесь локальная модель превращается из статьи расхода в инвестицию, которая окупается (об этом подробнее в блоке про TCO).
Низкая и предсказуемая задержка. Обращение к внешнему API — это сетевой round-trip плюс очередь на стороне провайдера. Для интерактивных сценариев (голосовые ассистенты, real-time подсказки оператору, встроенные в производственный процесс контуры) задержка и её стабильность критичны. Локальная модель на своём железе даёт контроль над latency и устраняет зависимость от чужой инфраструктуры и rate limits.
Глубокая кастомизация и контроль. Собственный fine-tuning на закрытых данных, специфические квантизации, нестандартные пайплайны инференса, гарантия неизменности версии модели на годы вперёд — всё это проще и надёжнее реализовать на своём стеке.
Когда локальная LLM НЕ оправдана
Честности ради: если вы обрабатываете открытые данные, нагрузка непостоянная или невысокая, вам нужны самые сильные модели последнего поколения, а команды MLOps в штате нет — оставайтесь в облаке. Собственное развёртывание в этом случае даст вам худшее качество за большие деньги и с большей операционной болью.
Что нужно для пилота
Цель пилота — не построить промышленный контур, а проверить гипотезу: справляется ли открытая модель нужного размера с вашей задачей на приемлемом качестве и скорости. Экономить здесь стоит на всём, кроме памяти видеокарты.
Ключевой ресурс — VRAM. Именно объём видеопамяти определяет, какую модель вы сможете запустить. Ориентиры для квантизованных моделей (4-bit):
| Размер модели | Примерная VRAM (4-bit) | Что закрывает |
|---|---|---|
| 7–8B | 6–8 ГБ | Простые задачи, суммаризация, классификация, извлечение |
| 13–14B | 10–12 ГБ | Более качественный диалог, RAG, кодовые подсказки |
| 30–34B | 20–24 ГБ | Сложные рассуждения, качественная генерация |
| 70B | 40–48 ГБ | Задачи, близкие к уровню коммерческих API |
Минимальная конфигурация пилота: одна видеокарта потребительского или профессионального класса с 24 ГБ VRAM (например, RTX 4090 / RTX 3090 / A5000) закрывает большинство пилотных задач вплоть до моделей 30–34B в квантизации. К ней — 32–64 ГБ системной RAM, быстрый NVMe SSD под веса моделей (модель 70B в 4-bit занимает ~40 ГБ на диске) и любой современный многоядерный процессор.
Софт. Для пилота достаточно простых инструментов инференса: Ollama или LM Studio для быстрого старта, llama.cpp для гибкости, vLLM — если сразу хотите оценить пропускную способность, близкую к боевой. Всё это разворачивается за часы, а не недели.
На этом этапе не нужны кластеры, оркестрация и отказоустойчивость. Нужна одна машина, чтобы получить ответ на вопрос «работает ли это для нас в принципе».
Что нужно для промышленной нагрузки
Переход от пилота к продуктиву — это качественный скачок. Здесь появляются требования, которых на пилоте не было вовсе.
Пропускная способность и батчинг. Один запрос в интерактиве и сотни параллельных запросов — разные инженерные задачи. Для продуктива нужен серверный движок инференса с поддержкой continuous batching и эффективного управления памятью: vLLM, TGI (Text Generation Inference) или TensorRT-LLM. Они позволяют одной картой обслуживать десятки одновременных пользователей за счёт умного шедулинга.
Серьёзное железо. Промышленный инференс строится на профессиональных ускорителях: NVIDIA A100 (40/80 ГБ) или H100 (80 ГБ), объединённых через NVLink для больших моделей, не помещающихся в одну карту. Под них — серверные платформы с достаточной пропускной способностью PCIe/памяти, ECC RAM, резервированное питание и охлаждение. Для крупных моделей (70B+ в fp16) один сервер может нести 2–8 таких ускорителей.
Отказоустойчивость и масштабирование. Продуктив подразумевает горизонтальное масштабирование: несколько инференс-нод за балансировщиком, автоскейлинг под нагрузку, health-checks и graceful degradation. Стандартный инструментарий — Kubernetes (часто с профилями GPU-шедулинга), реестр моделей, отдельный слой кэширования и очередей.
Наблюдаемость. Без метрик продуктив слепой. Нужен мониторинг latency (p50/p95/p99), throughput (токенов/сек), утилизации GPU, длины очередей, а также логирование и трассировка запросов. Это входит в зону ответственности MLOps/AIOps и требует отдельной команды или компетенции.
Безопасность контура. Изоляция сети, управление доступом, аудит запросов, защита от prompt injection и утечек через выводы модели — в промышленном контуре это не опция, а обязательная часть архитектуры.
Практический совет: не проектируйте продуктивную архитектуру до завершения пилота. Реальные цифры по нагрузке, размеру нужной модели и требуемому качеству вы получите только эмпирически, и они почти всегда отличаются от первоначальных предположений.
Как оценить стоимость владения (TCO)
Ошибка номер один при обосновании локальной LLM — сравнивать цену видеокарты со счётом за облако. Total Cost of Ownership гораздо шире. Считать нужно все компоненты.
Капитальные затраты (CapEx):
- Ускорители (GPU) — основная и самая дорогая позиция.
- Серверные платформы, память, диски, сетевое оборудование.
- Модернизация ЦОД или серверной: стойки, питание, охлаждение (мощные GPU-серверы потребляют киловатты и требуют серьёзного теплоотвода).
Операционные затраты (OpEx):
- Электроэнергия — часто недооценивается. Сервер с несколькими H100 под нагрузкой потребляет несколько кВт непрерывно; за год это заметная сумма.
- Охлаждение и содержание помещения.
- Амортизация железа (реалистичный горизонт — 3–5 лет, после чего появляются более эффективные ускорители).
- Люди. Самая недооценённая статья. Локальную LLM нужно разворачивать, обновлять, мониторить и чинить. Инженер MLOps/DevOps — это зарплата, которая нередко превышает стоимость самого железа за год.
- Резервирование и запасные компоненты.
Как считать честно. Постройте две модели затрат на горизонте 3 лет:
- Облако: прогноз объёма запросов × стоимость за токен + рост нагрузки. Сценарии: пессимистичный, реалистичный, оптимистичный.
- Локально: CapEx (разово) + OpEx × 36 месяцев, включая ФОТ инженеров.
Точка безубыточности — объём нагрузки, при котором линии пересекаются. Ниже неё дешевле облако, выше — своё железо. Для многих организаций эта точка достигается только при действительно большой и стабильной нагрузке. Но если основной драйвер — комплаенс или работа без интернета, TCO-расчёт вторичен: локальное развёртывание становится не вопросом экономии, а вопросом возможности вести деятельность вообще.
Итог
Локальная LLM — это не «более продвинутый» вариант облака, а инструмент под конкретный класс задач. Она оправдана, когда данные нельзя выпускать во внешний контур, когда нет интернета, когда нагрузка велика и предсказуема или когда критична задержка. Во всех остальных случаях облако выигрывает по совокупности факторов.
Правильный путь: начать с пилота на одной машине с 24 ГБ VRAM, эмпирически подтвердить качество и снять реальные метрики, и только затем — с цифрами на руках — проектировать промышленный контур и считать полную стоимость владения на трёхлетнем горизонте, включая людей и электричество. Тогда решение будет обоснованным, а не интуитивным.
Материал подготовлен для блога K2W AI.