Перейти к содержанию
Публикация AiManual

Расчёт стоимости self-hosted Gemma 3 4B для 300 пользователей: от железа до счёта

Подробный гайд по оценке стоимости и инфраструктуры для self-hosted развёртывания Gemma 3 4B на 300 конкурентных пользователей. TGI, квантование, выбор железа.

Коротко

Что будет в материале

  1. 01

    Что ломает бюджет (и сервер) при self-hosted инференсе

  2. 02

    Собираем итоговый счёт

  3. 03

    Ошибки, которые опустошат ваш бюджет

Вы решили запустить собственную LLM, чтобы не зависеть от капризов облачных API, защитить данные или просто сэкономить в долгосрочной перспективе. Gemma 3 4B выглядит идеальным кандидатом: достаточно умная, относительно компактная. Но цифра в 300 потенциальных пользователей пугает. Сколько это будет стоить на самом деле?

Проблема в том, что оценка «на глаз» для инференса LLM — верный путь к переплате в 2-3 раза или, что хуже, к коллапсу системы под нагрузкой. Нельзя просто взять «мощную виртуалку» и надеяться на лучшее.

Что ломает бюджет (и сервер) при self-hosted инференсе

Перед тем как открывать калькуляторы провайдеров, нужно понять, что именно потребляет ресурсы. Основных «пожирателей» три:

  • Память модели (VRAM): Сама модель должна целиком помещаться в память GPU. Без квантования Gemma 3 4B в формате BF16/Float16 «весит» около 8 ГБ. Это отправная точка.
  • Конкурентные запросы: 300 пользователей — не значит 300 одновременных запросов. Реальный concurrency (одновременно обрабатываемых запросов) может быть 10, 30 или 50. Каждый запрос создаёт свой контекст в памяти.
  • Пропускная способность (Throughput): Сколько токенов в секунду должна генерировать система в сумме? От этого зависит, будут ли пользователи ждать ответа 2 секунды или 20.

Самая частая ошибка: оценивать стоимость, исходя только из размера модели. Это лишь билет на вход. Реальная цена определяется требованиями к latency (задержке) и throughput (пропускной способности).

1Определяем целевые метрики: от бизнес-требований к техническим

Спросите у продукт-менеджера (или у себя): «Какой ответ считается быстрым?» Ответ «чем быстрее, тем лучше» не считается. Нужны цифры.

МетрикаКонсервативный сценарий (Чат-поддержка)Агрессивный сценарий (Интерактивный инструмент)
Средняя длина ответа~300 токенов~100 токенов
Приемлемая задержка (Time to First Token)< 1.5 секунды< 0.5 секунды
Пиковый concurrency~30 (10% от 300 онлайн)~50
Требуемый throughput(30 запр. * 300 ток.) / 10 сек. = 900 ток/сек(50 запр. * 100 ток.) / 5 сек. = 1000 ток/сек

Видите? Хотя сценарии разные, требуемая пропускная способность системы оказывается схожей — около 1000 токенов в секунду. Это наш ключевой KPI для выбора железа.

2Выбираем стек: TGI, квантование и волшебная кнопка «экономить»

Запустить модель можно кучей способов, но для продакшена с конкурентными запросами Text Generation Inference (TGI) от Hugging Face — де-факто стандарт. Он написан на Rust, использует эффективное непрерывное пакетирование (continuous batching) и tensor parallelism из коробки.

А теперь главный инструмент экономии: квантование. Переводим веса модели из высокоточного формата (BF16) в низкоточный (INT8, INT4). Это радикально сокращает требования к VRAM и часто ускоряет инференс.

💡
Для Gemma 3 4B квантование в формат GPTQ/AWQ (INT4) — это не опция, а необходимость для cost-effective развёртывания. Модель сожмётся до ~2.5-3 ГБ VRAM с минимальной потерей качества (часто незаметной для конечного пользователя). Это позволяет использовать более дешёвые GPU.

Сравним требования:

  • BF16 (без квантования): ~8 ГБ VRAM. Потребует GPU уровня RTX 4090 (24 ГБ) или A10 (24 ГБ) с большим запасом, что неоптимально.
  • INT8: ~4 ГБ VRAM. Уже лучше, можно уместить на L4 (24 ГБ) и обслуживать несколько реплик модели.
  • INT4/GPTQ: ~2.5-3 ГБ VRAM. Золотая середина. Одна реплика помещается даже на GPU с 4-6 ГБ, но для нашей нагрузки нужно смотреть на производительность.

3Подбираем железо: от облачных инстансов до «железных» серверов

Нам нужно достичь ~1000 токенов/сек с приемлемой задержкой. Один GPU с квантованной Gemma 3 4B (INT4) может выдать, ориентировочно, 150-250 токенов/сек (зависит от GPU и длины контекста). Простая математика: 1000 / 200 = 5 одновременных реплик модели.

Но запускать 5 реплик на 5 отдельных маленьких GPU — неэффективно и дорого из-за фиксированной стоимости инстанса. Лучше взять более мощный GPU с большим объёмом VRAM и запустить на нём несколько реплик модели (multi-instance GPU).

Вариант инстанса (AWS/GCP/Azure аналог)Ориентировочная стоимость (в час)VRAMСтратегия развёртыванияОценка throughputМесячная стоимость*
1x NVIDIA L4 (24GB)~$0.55 - $0.7524 ГБ6-8 реплик INT4 модели~1200-1600 ток/сек$400 - $550
1x NVIDIA A10 (24GB)~$1.00 - $1.3024 ГБ6-8 реплик INT4~1400-1800 ток/сек$720 - $950
2x NVIDIA T4 (16GB каждый)~$0.70 - $0.902x16 ГБ3-4 реплики INT4 на каждом~900-1200 ток/сек$500 - $650

*При 24/7 работе (730 часов в месяц). Цены ориентировочные, сильно зависят от провайдера и типа коммитмента (on-demand, spot, резервный инстанс).

Вывод? L4 выглядит самым cost-effective вариантом для нашей задачи. Он дешевле A10, но обладает хорошей производительностью для инференса и позволяет упаковать много реплик.

Не забудьте про «скрытые» компоненты инфраструктуры: CPU (4-8 ядер), RAM (16-32 ГБ для системы и кэша), быстрый SSD (от 100 ГБ для модели, логов, контейнеров), исходящий трафик (может быть дорогим!) и балансировщик нагрузки (например, Nginx). Это добавляет 15-25% к стоимости инстанса.

Собираем итоговый счёт

Давайте посчитаем для консервативного сценария с L4 на одном из «альтернативных» провайдеров вроде Hyperstack или Runpod, где цены часто ниже, чем у гигантов.

  • Инстанс с 1x L4 GPU, 8 vCPU, 32 ГБ RAM, 200 ГБ SSD: ~$0.65/час.
  • Месяц работы (730 часов): $0.65 * 730 = $474.5.
  • + Резервное копирование, сеть, IP-адрес: ~$30-50.
  • Итого в месяц: ~$520.

За эти деньги вы получаете систему, способную обслуживать 300 пользователей с комфортной скоростью. Для сравнения: использование облачного API Gemini Flash для аналогичного объёма (предположим, 50 миллионов токенов на вход/выход в месяц) может обойтись от $600 до $1000+, не говоря уже о рисках блокировки API или изменении тарифов, о чём мы писали в статье «Конец эры халявы: Google убил бесплатный Gemini API».

Ошибки, которые опустошат ваш бюджет

  • Игнорирование мониторинга: Запустили и забыли. А в это время 80% запросов приходят в 3 часа ночи, и инстанс простаивает. Используйте автоскейлинг или планировщик отключения.
  • Развёртывание без кэширования: Если пользователи часто задают похожие вопросы, кэш ответов (например, с Redis) снизит нагрузку на GPU в разы.
  • Попытка сэкономить на памяти системы (RAM): TGI и операционная система тоже едят память. Недостаток RAM приведёт к свопу на диск и катастрофическому падению производительности.
  • Выбор самого дешёвого, но старого GPU (например, P4): У него может быть много VRAM, но низкая производительность tensor cores и пропускная способность памяти. Throughput будет ничтожным, и вы заплатите за время, а не за результат.
💡
Перед финальным развёртыванием сделайте нагрузочное тестирование на spot-инстансах или у более дешёвых провайдеров. Заплатите $20-30 за тесты, чтобы точно понять реальный throughput и оптимальное количество реплик, а не гадать по формулам.

И последний совет: если ваша основная цель — не абсолютный контроль, а GDPR-совместимость и европейские данные, присмотритесь к специализированным предложениям, как у OVHcloud или других локальных провайдеров. Иногда их готовые инференс-стэки могут оказаться выгоднее самостоятельной сборки, особенно если в вашей команде нет dedicated DevOps.

Self-hosted инференс — это уравнение со многими переменными: цена железа, стоимость DevOps-времени, требования к uptime. Но теперь у вас есть карта, чтобы пройти этот путь, не переплачивая на каждом углу.