Каждый четверг в 17:00 — вебинар VikiCloud: «GPU-разбор: пришлите AI-задачу — разберём конфигурацию и стоимость». Записаться →

Сколько GPU нужно для Qwen 72B на 300 пользователей: расчёт, а не угадывание

«300 пользователей» само по себе ничего не говорит о нужном железе. Важно, сколько из них работают одновременно, в каком формате хранятся веса модели и какой запас нужен под рост. Разбираем расчёт по шагам на примере Qwen2.5-72B.

«Сколько GPU нужно под 300 пользователей» — некорректный вопрос сам по себе. Важно не число зарегистрированных, а сколько из них одновременно отправляют запросы, в каком формате хранятся веса модели (полная точность или квантизация) и какой запас нужен под рост нагрузки. Ниже — не готовый ответ «берите вот это», а разбор расчёта на примере Qwen2.5-72B, с явными допущениями и границами того, что можно посчитать заранее, а что проверяется только нагрузочным тестом.

Архитектура модели берётся из официального конфига Qwen2.5-72B-Instruct: 80 слоёв, 64 attention heads и 8 key-value heads (GQA — group query attention), hidden size 8192, bfloat16 по умолчанию. Эти параметры определяют и память под веса, и память под KV cache.

Память под веса модели — по официальному бенчмарку Qwen (NVIDIA A100 80 ГБ, один запрос за раз): BF16 — около 136 ГБ, квантизация AWQ/GPTQ-Int4 — около 40 ГБ. Квантизация экономит память ценой небольшой потери точности модели.

KV cache — память на хранение контекста каждого активного запроса, растёт с длиной контекста и числом одновременных запросов. Из архитектуры Qwen2.5-72B считается точно: 2 × 80 слоёв × 8 KV-heads × 128 (head dim) × 2 байта (BF16) ≈ 320 КБ на токен. Для запроса с контекстом 8 000 токенов на входе и 1 000 на выходе это около 2,8 ГБ — но это память на конец генерации для заданного сценария, а не средний постоянный расход: в реальном vLLM запросы находятся на разных стадиях одновременно, и PagedAttention управляет памятью динамически.

Дальше — иллюстративный сценарий, не утверждение о типовом поведении компаний: 300 зарегистрированных пользователей, три точки анализа по одновременной нагрузке — 10, 30 и 70 активных запросов. Это показывает, как меняется требование к инфраструктуре при росте конкурентности, а не заявление, что именно такая доля пользователей обычно активна одновременно.

Три класса конфигурации по памяти — не «подходит для N пользователей»:

  • Minimal/пилот — квантованная модель (~40 ГБ) + KV cache для 10 одновременных запросов (~28 ГБ) ≈ 68 ГБ. Помещается в минимальный заказ VikiCloud, 2×H100 (160 ГБ), с большим запасом.
  • Production/balanced — полная точность BF16 (136 ГБ) + KV cache для 30 одновременных запросов (~84 ГБ) ≈ 221 ГБ. В 2×H100 уже не помещается, нужен 2×H200 (282 ГБ).
  • High-concurrency, пример конфигурации под нагрузку — BF16 + KV cache для 70 одновременных запросов (~197 ГБ) ≈ 333 ГБ. Один из вариантов, который влезает по памяти — 4×H200 (564 ГБ); на практике для такой нагрузки может оказаться выгоднее несколько независимых реплик с балансировкой, а не одна конфигурация на 4 карты — это уже вопрос бенчмарка, не только объёма памяти.

Важная оговорка про саму таблицу: переход от Minimal к Production меняет не только нагрузку, но и формат весов — с квантованной модели на полную точность BF16. Это не чистое масштабирование одной и той же конфигурации под рост числа пользователей, а смена сразу двух параметров одновременно.

И ещё одна: то, что модель с её KV cache помещается в объём памяти нескольких GPU, подтверждает только вместимость — не производительность. В multi-GPU inference важна топология: tensor parallelism, связь между картами (NVLink или PCIe), конкретный узел backend. Проверка по памяти — необходимое, но не достаточное условие; реальную пропускную способность под конкретную нагрузку показывает только бенчмарк на целевой конфигурации.

Ориентировочные цены VikiCloud на дату публикации, не финальное предложение: минимальный срок аренды — 3 месяца, почасового тарифа на H100/H200 нет. Minimal на 2×H100 — от 622 666 ₽/мес, Production на 2×H200 — от 757 198 ₽/мес, пример конфигурации на 4×H200 — от 1 468 964 ₽/мес. Точная цена, доступность и срок поставки подтверждаются после проверки у backend под конкретную задачу.

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

Частые вопросы

Как быстро запускается GPU?

Срок запуска зависит от модели GPU, их количества и наличия мощностей. Мы называем его при заявке вместе с ценой и конфигурацией.

Что входит в инстанс?

Готовая вычислительная инфраструктура: NVIDIA GPU, CUDA, драйверы, Docker, хранилище, сеть, SSH/API-доступ и техническая поддержка.

Как проходит оплата?

Безналичная оплата по договору: счёт, закрывающие документы. Порядок расчётов и стоимость фиксируем в коммерческом предложении.

Можно ли потом перейти на собственный сервер?

Да. Когда аренда перестаёт быть экономически выгодной при постоянной загрузке, мы поставим и настроим собственный GPU-сервер.

Работаете по договору с российским ИП?

Да. Договор, счета и закрывающие документы — от российского ИП (индивидуального предпринимателя), оплата в рублях. Не нужно оформлять валютные платежи или работать с иностранным контрагентом.

Можно протестировать GPU перед арендой?

Пробный доступ обсуждаем индивидуально под задачу — уточните это в заявке, и мы предложим формат теста вместе с расчётом.

Заявка

Получить расчёт

Опишите задачу — подберём экономичный, оптимальный и максимальный вариант GPU под вашу нагрузку. Отвечаем в рабочий день.