Собственный инференс против облачного: vLLM, TGI и расчёт точки безубыточности

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

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

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

Когда оправдан самостоятельный хостинг

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

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

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

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

Собственные модели. Дообученные модели, нестандартные архитектуры или специализированные варианты, которых управляемые провайдеры не предлагают.

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

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

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

Когда самостоятельный хостинг не оправдан

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

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

Нагрузка со всплесками. Использование колеблется в 10 раз между пиком и затишьем. Самостоятельный хостинг тратит мощность в спадах.

Нужны передовые возможности. GPT-5.5, Claude Opus 4.8, новейшие уровни рассуждающих моделей — закрытые и доступны только через API. Если нагрузке действительно нужно передовое качество, вы платите за API.

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

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

Несколько регионов и глобальные пользователи. Самостоятельный хостинг требует присутствия в каждом регионе. Управляемые API это закрывают.

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

Расчёт затрат — аккуратно

Прогоним реальные цифры на показательном примере. Допущения:

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

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

• Флагманский закрытый API (прайс-лист Claude Sonnet 5, проверено 2026-07-07): $3/M входных × 100M = $300. $15/M выходных × 30M = $450. Итого: ~$750/месяц.

Этот уровень расходов не оправдывает самостоятельный хостинг.

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

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

Теперь самостоятельный хостинг становится интересным.

Вариант B: API открытой модели у управляемого провайдера открытых моделей.

• Llama 3.3 70B на Together AI: $0.88/M входных и выходных (прайс-лист, проверено 2026-07-07).
• 1B входных × $0.88/M = $880. 300M выходных × $0.88/M = $264. Итого: ~$1,144/месяц.

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

Вариант C: собственный хостинг на арендуемых GPU.

• Квантизованная (INT8/FP8) 70B помещается на одну H100 80GB; закладывайте ~2 H100 под FP16-веса или под запас пропускной способности при пакетной обработке — расчёт ниже предполагает 2 ради пропускной способности.
• Аренда H100: $2-3/час каждая.
• 2 H100 × $2.50/час × 730 часов/месяц = $3,650/месяц только за вычислительные мощности.
• Плюс: хранилище, сеть, время эксплуатации.

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

Вариант D: собственный хостинг на купленных или зарезервированных надолго GPU.

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

Теперь мы конкурентны с управляемыми провайдерами открытых моделей. Но операционные накладные расходы реальны.

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

На 10x больше (~13B токенов/месяц) собственный хостинг начинает явно выигрывать. На 10x меньше — ответ в пользу облачного.

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

Помимо чистой стоимости инференса — операционная стоимость самостоятельного хостинга.

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

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

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

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

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

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

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

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

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

Именно здесь команды недооценивают стоимость самостоятельного хостинга. Расчёт инференса в отрыве выглядит отлично; совокупная стоимость владения куда выше.

Серверы инференса

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

vLLM. С открытым исходным кодом. Вероятно, самый популярный для обслуживания открытых LLM. PagedAttention, непрерывная пакетная обработка, широкая поддержка моделей. Выбор по умолчанию.

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

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

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

llama.cpp / Ollama. Для моделей поменьше, с невысокой пропускной способностью. Дружелюбен к CPU. Пригоден для продакшена в отдельных сценариях.

Hugging Face TGI Inference Endpoints. Управляемый самостоятельный хостинг. Почасовая оплата инстансов; их эксплуатирует HF. Промежуточный вариант между полностью собственным хостингом и управляемым.

Modal, RunPod, Replicate. Инференс по модели «функция как сервис». Меньше обязательств, чем полный самостоятельный хостинг; дороже, чем своими руками.

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

Выбор железа

Вопрос про GPU:

NVIDIA H100. Сегодняшний эталон для инференса. ~$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. Для очень маленьких моделей (до 8B) подходят Mac Studio или Mac Pro с объединённой памятью. Нишевый сценарий.

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

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

Квантизация

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

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–500 мс.
• Задержка на токен: 10–30 мс.

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

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

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

Надёжность и запасной вариант

Самостоятельный хостинг означает: надёжность — на вас.

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

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

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

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

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

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

Каждое из этого — инженерная работа, которую управляемые API берут на себя.

Проработанный пример: команда решает хоститься сама

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

Расчёт:

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

План:

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

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

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

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

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

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

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

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

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

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

Изменение:

• Цены у управляемых провайдеров открытых моделей упали на 50% за 18 месяцев.
• Команда выросла, но не наняла выделенного MLOps-инженера.
• Конфигурация самостоятельного хостинга требовала серьёзной работы, чтобы поспевать за новыми моделями.

Решение:

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

Результат:

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

Итог: для них это правильное решение. Самостоятельный хостинг выигрывает у одних команд, но не у других.

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

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

Изменения объёма. Сильно вверх — самостоятельный хостинг привлекательнее. Сильно вниз — менее привлекателен.

Изменения цен. Закрытые API дешевеют или дорожают. Управляемый хостинг открытых моделей дешевеет. Железо дешевеет.

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

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

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

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

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

Паттерны, которые мы видим в решениях о самостоятельном хостинге:

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

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

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

Ошибка 4: нет запасного варианта. Собственная инфраструктура легла; нет плавной деградации. Простой, которого у клиентов API не было бы.

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

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

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

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

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

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

• Расходы на инференс через API — минимум €5-10K/месяц?
• Нагрузка стабильна и предсказуема?
• У команды есть экспертиза в MLOps и инференсе или её можно нанять?
• Существует открытая модель достаточного качества?
• Требования к задержке совместимы с самостоятельным хостингом?
• Проведён детальный расчёт затрат, включая операционные?
• Есть план на случай отказа?
• Требования по комплаенсу и приватности не диктуют единственный путь?
• Будете ли пересматривать ежеквартально?

Если большинство — да, самостоятельный хостинг стоит серьёзного рассмотрения.

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

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

Собственный хостинг на основную массу; API на сложные случаи. Классификация и простая генерация — на своём хостинге; сложные рассуждения — через закрытые API.

Собственный хостинг на стабильное; API на всплески. Свой хостинг держит базовую нагрузку; API поглощают пики.

Собственный хостинг на чувствительное; API на общее. Чувствительные данные — через свой хостинг; общие запросы — через API.

Собственный хостинг на дообученные модели; API на базовые. Собственные модели держите у себя; готовые модели — из API.

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

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

Самостоятельный хостинг инференса LLM по-настоящему жизнеспособен в 2026. Открытые модели конкурентоспособны. Серверы инференса зрелые. Железо доступно.

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

Команды, у которых самостоятельный хостинг получается:

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

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

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

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

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