Self-hosted vs hosted инференс: vLLM, TGI и математика точки безубыточности

Питч убедительный. Open-source модели конкурентоспособны. GPU доступны. Inference-серверы вроде vLLM, TGI и SGLang зрелые. Зачем платить наценку в 5-10x OpenAI или Anthropic, если можно поднять эквивалент самим?

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

В статье разбираемся в математике, операционных реалиях и паттернах, отличающих команды, которым стоит хоститься самим, от тех, кому нет. Считаем, что вы рассматриваете это всерьёз и хотите честные числа.

Когда self-hosting оправдан

Характеристики в пользу self-hosting:

Масштаб. Высокий объём инференса. Конкретно, месячные расходы на API сверх €5K-10K обычно оправдывают рассмотрение self-hosting.

Предсказуемая нагрузка. Стабильное, предсказуемое использование. Self-hosting требует планирования мощностей; всплески либо тратят мощность впустую (недозагрузка), либо валятся (перегруз).

Требования приватности / комплаенса. Данные, которые нельзя отправлять облачным провайдерам (регулируемые отрасли, отдельные госконтракты, исключительно внутренние данные).

Кастомные модели. Fine-tune'ы, кастомные архитектуры или специализированные варианты, которых managed-провайдеры не предлагают.

Контроль латентности. Sub-100ms latency на первый токен для некоторых приложений требует запуска моделей на инфраструктуре, которой вы управляете.

Стоимость вызова ниже точки безубыточности. Когда математика показывает: self-hosting реально выигрывает.

Если большинство этих пунктов истинны, self-hosting стоит серьёзного рассмотрения.

Когда self-hosting не оправдан

Обратная сторона. Характеристики в пользу managed API:

Низкий или нестабильный масштаб. Инференс-расходы под €5K/месяц. Экономия не оправдывает операционные затраты.

Всплесковая нагрузка. Использование колеблется в 10 раз между пиком и затишьем. Self-hosting тратит мощность в спадах.

Нужны фронтирные возможности. GPT-5, Claude 4 Opus, последние reasoning-модели — закрытые и доступны только через API. Если нагрузке действительно нужно фронтирное качество, вы платите за API.

Маленькая команда. Self-hosted инференс требует операционной экспертизы. Без выделенных мощностей ломается.

Быстрая итерация. Перебор разных моделей, конфигураций, провайдеров. API упрощают это; self-hosting делает каждое изменение деплоем.

Multi-region / глобальные пользователи. Self-hosting требует оперировать в каждом регионе. Managed API это закрывают.

Для таких случаев managed API — правильный ответ, даже при значительной стоимости.

Математика затрат (аккуратно)

Прогоним реальные числа на репрезентативном кейсе. Допущения:

• Нагрузка: 100 миллионов входных токенов/месяц, 30 миллионов выходных/месяц.
• Целевое качество: сопоставимо с Claude 4 Sonnet или GPT-5.
• Доступная открытая модель: Llama 4 70B (качество близкое к флагманскому закрытому для многих задач).

Вариант A: API закрытой модели.

• Флагманский закрытый API: грубо €3/M входных × 100M = €300. €15/M выходных × 30M = €450. Итого: ~€750/месяц.

Этот уровень расходов не оправдывает self-hosting.

Масштабируем нагрузку в 10 раз:

• 1 миллиард входных токенов, 300 миллионов выходных.
• Закрытый API: €7,500/месяц.

Теперь self-hosting становится интересным.

Вариант B: API открытой модели у managed open-source провайдера.

• Llama 4 70B на Together AI: ~€0.50/M входных, €0.80/M выходных.
• 1B входных × €0.50/M = €500. 300M выходных × €0.80/M = €240. Итого: €740/месяц.

Экономия 90% против закрытой. Значимо.

Вариант C: self-hosting на арендуемых GPU.

• Llama 4 70B требует ~2 H100 для разумной пропускной способности (с квантизацией).
• Аренда H100: €2-3/час каждая.
• 2 H100 × €2.50/час × 730 часов/месяц = €3,650/месяц только за вычислительные мощности.
• Плюс: хранилище, сеть, время эксплуатации.

Для этой нагрузки open-source-на-managed обгоняет self-hosting по чистой стоимости. Self-hosting выигрывает, только если вам также нужен контроль (приватность, кастомная модель) или пропускная способность гораздо выше.

Вариант D: self-hosting на собственных/долго-зарезервированных GPU.

• 2 H100 в собственности или на долгом резерве: €1-2/час фактически.
• 2 H100 × €1.50/час × 730 часов = €2,190/месяц.
• При высокой утилизации стоимость размывается: если GPU обрабатывают несколько нагрузок, цена на нагрузку ниже.

Теперь мы конкурентны с managed open-source провайдерами. Но операционные накладные реальны.

Ключевое наблюдение: на этом масштабе нагрузки (~10B токенов/месяц) экономия от self-hosting против managed open-source провайдеров маржинальна. Экономия против закрытых API драматична, но managed open-source ловит большую её часть.

На 10x больше (100B+ токенов/месяц) self-hosting начинает явно выигрывать. На 10x меньше — ответ hosted.

Операционная стоимость

Помимо чистой стоимости инференса — операционная стоимость self-hosting.

Первоначальная настройка:

• Выбор подходящего inference-сервера (vLLM, TGI, SGLang).
• Конфигурация под вашу модель и железо.
• Настройка GPU-инфраструктуры (облако или собственность).
• Сеть, безопасность, observability.
• Квантизация и оптимизация.

Типично: 1-4 инженеро-недели на первый деплой.

Постоянная эксплуатация:

• Мониторинг (латентность, пропускная способность, ошибки, утилизация GPU).
• Планирование мощностей.
• Обновления (новые версии моделей, обновления inference-сервера, security-патчи).
• Реакция на инциденты (отказы GPU, OOM-краши, баги ПО).
• Масштабирование (больше GPU по мере роста нагрузки).

Типично: 0.25-1 FTE инженера постоянно, в зависимости от масштаба.

Скрытые затраты:

• Волатильность цен на GPU.
• Стоимость egress в облаке при гибриде.
• Специализированная экспертиза (CUDA, квантизация, оптимизация).
• Стоимость замены / отказов для собственного железа.

При €100K-200K на инженера в год полной стоимости даже частичное инженерное внимание значимо. Экономия €5K/месяц на инференсе исчезает под €15K/месяц инженерных затрат.

Именно здесь команды недооценивают стоимость self-hosting. Математика инференса в изоляции выглядит отлично; общая стоимость владения куда выше.

Inference-серверы

Если хоститесь сами — основные варианты:

vLLM. Open-source. Вероятно, самый популярный для подачи open-source LLM. PagedAttention, continuous batching, широкая поддержка моделей. Дефолтный выбор.

TGI (Text Generation Inference). Сервер от Hugging Face. Зрелый, широкая поддержка моделей, хорошая производительность. По темпу новых фич последнее время отстаёт от vLLM.

SGLang. Новее, очень высокая производительность. Сильный для structured generation. Активная разработка.

LMDeploy. От команды InternLM. Сильная квантизация, быстро.

llama.cpp / Ollama. Для меньших моделей, низкой пропускной способности. Дружественный к CPU. Production-grade для отдельных кейсов.

Hugging Face TGI Inference Endpoints. Managed self-hosting. Почасовая оплата инстансов; HF их эксплуатирует. Промежуточный вариант между полным self-hosting и managed.

Modal, RunPod, Replicate. Function-as-a-service для инференса. Меньше обязательств, чем полный self-hosting; дороже, чем DIY.

Для большинства команд: vLLM или SGLang для продакшен self-hosting. Оба зрелые, быстрые, хорошо документированные.

Выбор железа

Вопрос про GPU:

NVIDIA H100. Текущий state-of-the-art для инференса. ~€2-3/час в аренде. Даёт 80GB VRAM, быстрый инференс. 70B модели хорошо идут на одной H100 с квантизацией или на 2x без.

NVIDIA H200. Преемник H100, больше VRAM (141GB). Для очень больших моделей.

NVIDIA L40S. Доступнее, ~€1-2/час. Хороша для моделей среднего размера (до ~30B с квантизацией).

NVIDIA A100. Прошлое поколение, по-прежнему широко доступно. ~€1-2/час. Рабочая лошадка многих продакшен-развёртываний.

AMD MI300X. Конкурент H100 на части нагрузок. Всё доступнее. Софт-стек менее зрелый, чем у NVIDIA.

Apple M-series. Для очень маленьких моделей (до 8B) Mac Studio или Mac Pro с unified memory работают. Нишевый кейс.

Для большинства продакшен self-hosting в 2026: H100 или H200, если нужны крупные модели; L40S или A100 для средних.

Источники аренды: AWS, GCP, Azure (мейнстрим), Lambda Labs, Runpod, Together, Vast.ai (специальные). Цены варьируются. Spot / preemptible инстансы могут сэкономить 50-70%, если терпите перебои.

Квантизация

Большинство продакшен self-hosted развёртываний используют квантизованные модели. Компромиссы:

FP16 (16-bit). Дефолтная точность. Полное качество. Самая прожорливая по памяти.

INT8 / FP8 (8-bit). Память пополам, лёгкая потеря качества. Распространённый продакшен-выбор.

INT4 (4-bit). Память в четыре раза меньше, более заметная потеря качества, но всё ещё полезно. Агрессивный выбор.

AWQ, GPTQ, GGUF. Разные форматы квантизации с разными компромиссами.

Для модели 70B:

• FP16: 140GB VRAM.
• INT8: 70GB VRAM.
• INT4: 35GB VRAM.

У H100 — 80GB VRAM. INT8 встаёт с запасом; FP16 требует 2 GPU.

Влияние на качество:

• INT8: обычно <1% деградации на бенчмарках.
• INT4: 1-5% деградации, варьируется по задачам.

Тестируйте на своей нагрузке перед деплоем. Часть задач (особенно структурированные/код) чувствительнее к квантизации, чем другие.

Пропускная способность и планирование мощностей

Ключевой вопрос планирования: сколько токенов/секунду вам нужно?

Пропускная способность на одного юзера.

• 70B модель на H100, INT8: ~50-80 токенов/секунду на одного пользователя.

Пропускная способность в батче.

• Несколько одновременных запросов: 1000-3000 токенов/секунду суммарно по запросам (vLLM с хорошим батчингом).

Соображения латентности.

• Латентность первого токена: типично 100-500ms.
• Латентность на токен: 10-30ms.

Для планирования мощностей:

• Оценить пиковое число одновременных запросов.
• Оценить среднюю длину запроса.
• Посчитать суммарные токены/секунду.
• Добавить 50% запаса.

Команда, обрабатывающая 1M токенов/час с пиком 50 одновременных пользователей, обычно нуждается в 2-4 H100 при хорошей утилизации.

Надёжность и фолбэк

Self-hosting означает: надёжность — на вас.

Health-чеки. Постоянный мониторинг состояния. Перезапуск нездоровых инстансов.

Graceful degradation. Когда мощность насыщена — предпочитайте медленные ответы отказам.

Фолбэк на API. Многие команды держат self-hosted под основной трафик и падают на managed API при перегрузе. Лучшее из двух миров; сложность реальна.

Резервное железо. GPU отказывают. Запасные мощности наготове.

Multi-region. Для глобальных пользователей — реплицируйте. Или используйте managed API для удалённых регионов.

Стратегия обновлений. Новые версии моделей, апгрейды сервера. Blue-green деплои, чтобы избежать простоя.

Каждое из этого — инженерная работа, которую managed API забирают на себя.

Проработанный пример: решение команды о self-hosting

Реальный пример. SaaS-команда, AI-фичи, ежемесячная стоимость инференса на managed API: €18,000.

Математика:

• 80% инференса — классификация и извлечение (могут идти на меньшей открытой модели).
• 20% — сложная генерация (нужен фронтирный закрытый).

План:

• Self-host Llama 4 70B на 80% нагрузки.
• Оставить Claude/GPT API для 20%.
• 3 H100 на Lambda Labs в резерве: ~€4,500/месяц.
• Инженерная настройка: 4 недели, €25K единоразово.
• Постоянная эксплуатация: 0.25 FTE инженера, ~€30K/год.

Результат через 6 месяцев:

• Стоимость инференса упала с €18K/месяц до €6K/месяц (€4.5K self-host + €1.5K закрытый API для сложных задач).
• Чистая экономия против прошлого: €12K/месяц = €144K/год.
• Минус инженерные вложения: €25K + €30K = €55K/год.
• Чистая финансовая выгода: ~€89K/год.

Скрытые сложности:

• Один даунтайм, когда в деплое был баг конфига. 2 часа частичной деградации.
• Несколько недель текущего тюнинга, чтобы выйти на оптимальную пропускную способность.
• Инженер на self-hosting хотел бы заниматься другим.

Итог: финансово в плюсе, но операционно тяжелее ожидаемого. Команда продолжает self-hosting; если бы объём просел на 50%, вернулись бы к managed.

Так выглядит реальное успешное решение по self-hosting. Не магия — инженерная работа с измеряемым ROI.

Проработанный пример: решение «обратно на API»

Другая команда, похожая исходная позиция.

Исходная установка: self-hosted Llama 3 70B на арендуемых GPU. Стоимость инференса: €3K/месяц аренды. Плюс инженерия ~€20K/год постоянно.

Изменение:

• Цены open-source-у-managed-провайдеров упали на 50% за 18 месяцев.
• Команда выросла, но не нанимала специализированного MLOps.
• Установка self-hosting требовала серьёзной работы, чтобы поспевать за новыми моделями.

Решение:

• Прекратить self-hosting.
• Перейти на Together AI, хостящий открытые модели.
• Стоимость: €2.5K/месяц за managed open. Лёгкая экономия, меньше сложности.
• Освободить инженера.

Результат:

• Умеренная финансовая экономия.
• Время инженера освобождено под продуктовую работу.
• Меньше операционного стресса.

Итог: правильный звонок для них. Self-hosting выигрывает у одних команд; не у других.

Когда пересматривать решение

Решение не вечное. Периодически пересматривайте:

Изменения объёма. Сильно вверх: self-hosting привлекательнее. Сильно вниз: менее привлекателен.

Изменения цен. Закрытые API дешевеют или дорожают. Managed open дешевеют. Железо дешевеет.

Улучшения моделей. Новые open-source модели, соответствующие закрытому качеству. Новые закрытые модели, отрывающиеся.

Операционная мощность. Команда выросла или сжалась в ML/ops-компетенции.

Изменения по приватности / комплаенсу. Новые требования, диктующие self-hosting.

Квартальная сверка разумна. Не постоянная переоценка, но и не «решили раз и навсегда».

Распространённые ошибки

Паттерны, которые мы видим в решениях по self-hosting:

Ошибка 1: математика без операционных затрат. «Self-hosting сэкономит €10K/месяц» — но игнорирует €15K/месяц на инженерию. Отрицательный ROI.

Ошибка 2: self-hosting слишком рано. Инженерные усилия на self-hosting, когда нагрузка маленькая. Преждевременная оптимизация.

Ошибка 3: self-hosting фронтирного качества с маленькими открытыми моделями. «Сэкономим, перейдя на меньшую модель» — но качество падает, пользователи жалуются. Возврат на API.

Ошибка 4: нет фолбэка. Self-hosted инфраструктура легла; нет graceful degradation. Простой, которого у API-клиентов не было бы.

Ошибка 5: недоинвестирование в оптимизацию. Запускают 70B модель на одной GPU с 5 токенов/сек, когда правильная установка даёт 50. Выбрасывают большую часть ценности.

Ошибка 6: игнорирование дрейфа качества. Self-hosted модель деградировала относительно текущей закрытой. Клиенты замечают; команда — нет.

Ошибка 7: не пересматривают. Однажды на self-hosting — никогда не переоценивают. Решение могло быть правильным два года назад и неправильным сейчас.

Ошибка 8: spot/preemptible без аккуратной обработки. Сэкономили 60% на компьюте; простои каждые несколько часов, когда инстансы отзывают.

Чек-лист решения

Чтобы решать осмысленно:

• [ ] Инференс-расходы на API минимум €5-10K/месяц?
• [ ] Нагрузка стабильна и предсказуема?
• [ ] У команды есть или можно нанять MLOps/inference-экспертизу?
• [ ] Существует open-source модель достаточного качества?
• [ ] Требования к латентности совместимы с self-hosting?
• [ ] Прошли детальную математику затрат, включая операционные?
• [ ] Есть план фолбэка?
• [ ] Требования по комплаенсу/приватности не диктуют только один путь?
• [ ] Будете ли пересматривать ежеквартально?

Если большинство — да, self-hosting стоит серьёзного рассмотрения.

Гибридные паттерны

Это не «всё или ничего». Многие команды работают гибридно:

Self-hosted на основную массу; API на сложные случаи. Классификация, простая генерация — на self-hosted; сложные рассуждения — через закрытые API.

Self-hosted на стабильное; API на всплески. Self-hosted держит базовую нагрузку; API поглощает пики.

Self-hosted на чувствительное; API на общее. Чувствительные данные — через self-hosted; общие запросы — через API.

Self-hosted на fine-tune'ы; API на базовое. Кастомные модели — сами; готовые модели — из API.

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

Главный вывод

Self-hosting LLM-инференса по-настоящему жизнеспособен в 2026. Open-source модели конкурентоспособны. Inference-серверы зрелые. Железо доступно.

Но операционная стоимость реальна и легко недооценивается. Точка безубыточности против managed API — примерно €5-10K/месяц на инференсе; ниже инженерные вложения не окупаются.

Команды, у которых self-hosting получается:

• Честно посчитали математику, включая операционные затраты.
• Имеют или могут построить MLOps-способность.
• Работают на масштабе, оправдывающем вложения.
• Имеют стабильную нагрузку.
• Не нуждаются исключительно во фронтирных возможностях.
• Планируют надёжность, мониторинг и обновления.

Команды, которым стоит остаться на API:

• Меньший масштаб.
• Всплесковая нагрузка.
• Нужна быстрая итерация.
• Маленькие команды без операционных мощностей.
• Нужны фронтирные закрытые возможности.

Правильный ответ конкретен для вашей ситуации. Считайте числа аккуратно. Честно оценивайте операционную способность. По умолчанию — API, если только self-hosting не выигрывает явно.

Когда self-hosting выигрывает — он выигрывает крупно, экономически и архитектурно. Когда не выигрывает — это дорогой способ выяснить, что managed API всё это время был правильным звонком.