Вы планируете обслуживать 300 пользователей с помощью Gemma 3 4B. По одному этому числу нельзя выбрать GPU или назвать месячный счёт: важны частота запросов, длина контекста и допустимое время ответа.
Этот разбор относится к текстовому чату с google/gemma-3-4b-it. Изображения, длинные документы и отдельные требования к отказоустойчивости нужно тестировать дополнительно. Ниже — методика оценки и явно условная смета, без обещания вместить всю аудиторию на одной карте.
Что определяет бюджет при self-hosted инференсе
Перед калькулятором провайдера опишите три группы требований:
- Память. Веса модели — лишь часть VRAM. Нужны также KV-кэш для контекстов запросов, рабочие буферы и память движка. RAM сервера и VRAM видеокарты считают отдельно.
- Нагрузка. 300 зарегистрированных или онлайн-пользователей не равны 300 запросам одновременно. Нужны распределение запросов во времени, пики и длительность ответа.
- Качество обслуживания. TTFT — время до первого токена; полная задержка — время до завершения ответа. Измеряйте оба показателя, ошибки и очередь, а не только суммарные токены в секунду.
Показатель «модель загрузилась» проверяет старт, но не способность обслуживать поток. При недостатке KV-кэша движок может откладывать или повторно вычислять запросы, увеличивая задержку. Это описано в руководстве vLLM по настройке памяти.
1. Переводим требования пользователей в нагрузочный профиль
Для начала возьмите два учебных профиля. Все значения в таблице — выбранные цели и входные допущения, а не измеренная производительность Gemma или характеристики конкретного GPU.
| Параметр | Чат-поддержка | Интерактивный инструмент |
|---|---|---|
| Средний вход с историей диалога | 1024 токена | 512 токенов |
| Средний выход | 300 токенов | 100 токенов |
| Поток новых запросов в пике | 3 запроса/с | 10 запросов/с |
| Цель p95 TTFT | менее 1,5 с | менее 0,5 с |
| Цель p95 полного ответа | не более 10 с | не более 5 с |
| Нижний ориентир потока выходных токенов | 3 × 300 = 900 токенов/с | 10 × 100 = 1000 токенов/с |
900–1000 токенов/с здесь описывают спрос на выходные токены при условии обслуживания всего потока. Они не учитывают сами по себе стоимость обработки входа и не доказывают выполнение p95. В стабильной системе среднее число запросов в работе связано со средним временем ответа; нельзя подставлять p95 как среднее или выводить concurrency фиксированным процентом от 300 пользователей.
Проверьте реальные длины и всплески по данным приложения. Для первого теста увеличивайте интенсивность постепенно, задайте предел очереди и явный отказ при перегрузке, чтобы система не копила бесконечное ожидание.
2. Выбираем движок и формат весов
TGI поддерживает Gemma3, но проект переведён в режим сопровождения и рекомендует смотреть на активно развиваемые альтернативы, включая vLLM и SGLang. Для нового развёртывания можно начать с vLLM: официальная карточка google/gemma-3-4b-it содержит соответствующий способ запуска. Зафиксируйте версии движка, CUDA, модели и токенизатора; поддержку конкретного квантованного checkpoint проверяйте отдельно.
Квантование сокращает представление весов, но не гарантирует ускорение или неизменное качество. Сравнивайте выбранный checkpoint с базовой моделью на своих русскоязычных запросах, проверяя фактические ответы и формат вывода.
- BF16/FP16. На один параметр весов приходится 2 байта. Условные ровно 4 млрд параметров дали бы 8 млрд байт сырых весов; обозначение «4B» округлено и не является измерением всей памяти процесса.
- 8 бит. Сырые веса в арифметической модели занимают 1 байт на параметр, но формат добавляет служебные данные и не обязан квантовать все тензоры.
- 4 бита. Теоретически это 0,5 байта на параметр. Отсюда нельзя заключить, что Gemma 3 4B гарантированно работает на GPU с 4–6 ГБ: нужны поддерживаемые kernels, буферы и KV-кэш при целевой нагрузке.
Планируйте память по реально загруженному checkpoint и пику использования при тесте. Максимальная длина контекста из карточки модели не означает, что выбранный GPU обслужит столько токенов одновременно для всех клиентов.
3. Подбираем железо по одному сопоставимому тесту
Начните с одного обслуживающего процесса и continuous batching: движок объединяет работу над несколькими запросами. Несколько копий модели на одной GPU делят вычисления и пропускную способность памяти; их throughput нельзя умножать на число копий. Дополнительные процессы также повторно занимают память под веса.
| Кандидат для проверки | Физическая память | Первый сценарий теста | Что записать |
|---|---|---|---|
| NVIDIA L4 | 24 ГБ | Одна копия модели, ограниченные контекст и batching | Пиковая VRAM, p95 TTFT, полная задержка, ошибки, успешные запросы/с |
| NVIDIA A10 | 24 ГБ | Тот же checkpoint, версии и набор запросов | Те же метрики и полную цену конфигурации |
| Несколько отдельных GPU | Память каждого устройства учитывается отдельно | Реплики на разных устройствах либо поддерживаемое распределение модели | Масштабирование, сеть и поведение при потере узла |
Объёмы памяти подтверждены спецификациями NVIDIA L4 и NVIDIA A10. Таблица не задаёт ни токены/с, ни победителя по цене: это результаты будущего теста. Деление GPU средствами виртуализации также не создаёт дополнительной вычислительной мощности.
Для нагрузочного измерения можно использовать vllm bench serve. Воспроизведите реалистичные входы и параметры генерации, прогрейте сервер и снимите p50/p95/p99 TTFT и полной задержки при растущем потоке. Отдельно испытайте всплеск и длинные запросы. Если ограничиваете concurrency генератора, проверьте фактически достигнутый поток: ограничитель может скрыть перегрузку сервера.
В итоговую конфигурацию входят CPU, RAM, диск для модели и временных файлов, API-шлюз, мониторинг, сеть и резервирование. Их стоимость может быть включена в тариф или считаться отдельно; универсальной надбавки «15–25%» нет.
Собираем итоговый счёт
Когда тест определит число подходящих вычислительных узлов, подставьте актуальные ставки. Для сравнения Hyperstack и Runpod важно учитывать условия простоя и отдельное хранение. В список для собственного расчёта можно включить и Timeweb Cloud (партнёрская ссылка): у провайдера есть серверы с GPU, но пригодность конкретного тарифа для этой нагрузки нужно подтвердить тем же тестом.
Формула: C = сумма по конфигурациям (число узлов × цена узла в час × оплачиваемые часы) + диски + сеть + резервные копии + остальные платные сервисы. Стоимость эксплуатации командой учитывайте отдельной строкой. Не прибавляйте CPU/RAM повторно, если они уже включены в ставку.
Пример арифметики, не коммерческое предложение: допустим, тест показал необходимость двух узлов, а выбранный тариф каждого целиком стоит $1/час. За месяц из 30 дней при непрерывной работе вычислительная часть равна 2 × 1 × 720 = $1440. Условно заложив ещё $100 на остальные инфраструктурные компоненты, получим $1540 до налогов и расходов команды. Эти допущения не доказывают, что двум узлам хватит мощности для 300 пользователей; фактические значения заменяют после измерений.
Если нужен резерв на отказ одного узла, повторите тест в таком режиме и добавьте его стоимость. Сокращение часов имеет смысл только при сохранении нужной доступности и реальном прекращении тарификации GPU.
С API сравнивайте ту же полезную задачу и качество ответов. Для Gemini стоимость считают по выбранной версии модели, режиму обработки и отдельным объёмам входных, выходных и кэшированных токенов по официальному прайсу. Общих «50 млн токенов на вход/выход» недостаточно для честного счёта. Материал об изменениях условий Gemini API даёт контекст, но текущие квоты и бесплатные уровни нужно проверять заново.
Ошибки, которые опустошат ваш бюджет
- Считать аудиторию нагрузкой. Сначала измерьте запросы в секунду, длины контекста и пики. Не назначайте concurrency как произвольный процент пользователей.
- Игнорировать хвост задержки. Высокий суммарный throughput может сопровождаться долгим ожиданием отдельных запросов. Следите за p95, ошибками и очередью.
- Кэшировать ответы без границ доступа. Повторные вопросы не всегда имеют одинаковый ответ. Ключ кэша должен учитывать пользователя или область доступа, историю, версию модели и данных; иначе возможна выдача чужого контекста.
- Экономить память по размеру файла весов. Измерьте VRAM и RAM под нагрузкой, учитывая KV-кэш, буферы, контейнер и загрузку checkpoint.
- Сравнивать только цену часа. Старый или дешёвый GPU может не поддерживать нужный формат или выполнять задачу дольше. Сравнивайте стоимость успешных запросов, удовлетворяющих вашим ограничениям.
Перед покупкой длительного тарифа проведите ограниченный тест с бюджетным лимитом. Зафиксируйте конфигурацию, версии, профиль нагрузки, метрики и счёт за тест. Если используете spot, потеря узла не должна уничтожать исходные данные и результаты; для проверки производительности отдельно исключите влияние прерываний.
Если выбор региона связан с требованиями к данным, рассмотрите предложения OVHcloud и других провайдеров, но не считайте размещение в Европе автоматическим доказательством соответствия всем требованиям. Проверяются условия обработки данных и вся архитектура, включая логи, резервные копии и доступ сотрудников.
Следующий шаг — описать один реалистичный профиль запросов и измерить его на одной конфигурации. После этого бюджет превращается из обещания «на 300 пользователей» в смету с проверяемой нагрузкой и понятным резервом.