Сколько пользователей выдержит одна видеокарта

MAATRIX

Рано или поздно к вам приходит этот вопрос: сколько людей одновременно смогут пользоваться вашим ИИ-сервисом на одной видеокарте, прежде чем всё начнёт тормозить. Проблема в том, что честного универсального ответа не существует — любое конкретное число, которое вам назовут в интернете («видеокарта X держит Y пользователей»), почти наверняка получено на другой модели, с другим паттерном запросов и на другом движке инференса. Ниже — не число, а методика: как посчитать ёмкость именно вашей конфигурации и как её потом проверить на практике.

Почему нет универсального числа

Когда кто-то говорит «эта видеокарта держит 50 одновременных пользователей», за кадром остаётся десяток параметров, без которых цифра ничего не значит: какая модель, в каком кванте, какой длины у людей вопросы и ответы, какой движок инференса крутит запросы, насколько нагрузка равномерна во времени. Поменяйте любой из этих параметров — и то же самое железо выдержит вдвое больше или вдвое меньше людей.

Это не увиливание от ответа, а честное описание того, как устроена ёмкость GPU-инференса. Видеокарта не «держит N пользователей» сама по себе — она держит определённый объём вычислений и определённый объём видеопамяти в единицу времени. Сколько живых людей уместится в этот объём, зависит от того, сколько вычислений и памяти требует каждый конкретный диалог. У одного проекта это будет чат-бот поддержки с короткими репликами, у другого — ассистент для написания текстов с диалогами на десятки тысяч токенов контекста. Один и тот же GPU обслужит первых в разы больше, чем вторых.

Дальше разберём четыре фактора, которые реально определяют ёмкость, а затем — как измерить её на своей системе и какой запас закладывать.

Фактор первый: какая модель развёрнута

Размер модели и её архитектура — первое, что определяет, сколько видеопамяти уйдёт под саму модель, а сколько останется под KV-кэш параллельных запросов. Модель на 7-8 млрд параметров в 4-битном кванте занимает несколько гигабайт и оставляет много памяти под контекст десятков одновременных диалогов. Модель на 70+ млрд параметров съедает большую часть видеопамяти уже сама по себе, и на параллельные запросы остаётся заметно меньше пространства — даже если по «интеллекту» разница между ними для вашей задачи не критична.

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

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

Фактор второй: как выглядят запросы ваших пользователей

Один из самых недооценённых параметров — реальная длина диалогов. Короткий вопрос-ответ без сохранения истории и развёрнутый диалог с накопленным контекстом на десятки сообщений — это принципиально разная нагрузка на одну и ту же видеокарту, даже при одинаковой модели.

Контекст стоит памяти напрямую: каждый токен во входном и выходном контексте требует места в KV-кэше, и это место занято всё время, пока диалог активен. Чем длиннее у ваших пользователей типичные диалоги (или чем больше документов вы суёте в контекст через RAG), тем меньше параллельных сессий влезет в ту же видеопамять. Как именно контекст переводится в мегабайты и что с этим делать, подробно разбирали в статье контекст: цена в памяти и скорости — она полезна именно на этом шаге расчёта.

Прежде чем считать ёмкость, полезно честно ответить на вопросы о вашем реальном сценарии:

• Какая типичная длина запроса пользователя в токенах (а не в символах — это разные вещи для русского текста)?
• Сколько токенов обычно генерируется в ответе?
• Сохраняется ли история диалога между сообщениями, и насколько она разрастается за сессию?
• Используется ли RAG или системный промпт с большим объёмом инструкций, который добавляется к каждому запросу?

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

Фактор третий: движок инференса и эффективность батчинга

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

Современные движки инференса (vLLM, SGLang и им подобные) реализуют непрерывный батчинг (continuous batching) и эффективное управление KV-кэшем именно ради того, чтобы вытянуть из GPU кратно больше параллельных запросов, чем при наивной последовательной обработке. Разница между «поставили модель и гоняем запросы по одному» и «подняли нормальный сервер инференса с батчингом» — это не проценты, а кратные величины по количеству одновременно обслуживаемых пользователей на том же железе.

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

Фактор четвёртый: реальный паттерн нагрузки

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

Средняя нагрузка и пиковая нагрузка — это разные величины, и рассчитывать систему нужно на пиковую, а не на среднюю. Если запросы ставятся в очередь при превышении ёмкости движка, то в моменты пика пользователи будут ждать ответа не потому, что видеокарта «сломалась», а потому что очередь перед ней выросла до неприемлемой длины. Механика такой очереди и то, почему задержка растёт нелинейно при приближении к пределу ёмкости, разобрана в статье очередь запросов к локальной LLM.

Практический шаг здесь — снять хотя бы приблизительную картину реальной нагрузки: логи с таймстампами запросов покажут, есть ли у вас выраженные пики (по часам дня, по дням недели) или нагрузка действительно равномерна. Без этой картины расчёт ёмкости «в среднем» может оказаться бесполезным — система будет работать хорошо 20 часов в сутки и разваливаться именно в те 4 часа, когда она нужнее всего.

Как измерить реальную ёмкость своей системы

Раз универсального числа нет, единственный надёжный способ узнать ёмкость конкретной связки «модель + движок + железо + типичные запросы» — измерить её на развёрнутой системе. Методика простая и не требует специального инструментария:

1. Разверните целевую конфигурацию (модель, квант, движок инференса) на реальном сервере — той же видеокарте, которую планируете использовать в проде.
2. Соберите набор тестовых запросов, максимально похожих на реальные — той же длины, с той же структурой системного промпта и историей диалога, что и у настоящих пользователей. Синтетика, скопированная из чужого бенчмарка, здесь не поможет — важна именно ваша специфика.
3. Запускайте параллельные запросы нарастающими партиями — например, сначала 5 одновременных сессий, затем 10, 15, 20 — и на каждом шаге фиксируйте задержку до первого токена (time to first token) и общую задержку до конца ответа.
4. Мониторьте задержку и загрузку GPU параллельно с нагрузочным тестом — большинство движков инференса отдают метрики (очередь запросов, использование KV-кэша, throughput) через встроенный эндпоинт метрик, который можно смотреть напрямую или собирать в Prometheus/Grafana.
5. Найдите точку, где задержка начинает расти нелинейно — до определённого числа параллельных сессий задержка растёт плавно, а затем при приближении к пределу ёмкости начинает расти скачкообразно из-за роста очереди перед движком.
6. Определите, какая задержка приемлема именно для вашего сценария (для чат-интерфейса это одни требования, для фонового пакетного анализа документов — совсем другие), и зафиксируйте число параллельных сессий, при котором задержка ещё укладывается в эту границу.

Это число — и есть практическая ёмкость именно вашей конфигурации. Оно может кардинально отличаться от того, что вы найдёте в чужом бенчмарке, потому что там другая модель, другой квант, другая длина запросов и другой движок. Свежая утилита для нагрузочного тестирования (locust, k6, vegeta, либо простой скрипт с параллельными curl-запросами к OpenAI-совместимому эндпоинту вашего движка) подойдёт для шага 3 — конкретный инструмент здесь менее важен, чем сама методика измерения на реальной нагрузке с реальными запросами.

Отдельно стоит проверить эффект батчинга именно в вашей связке: если один пользователь ощутимо просаживает throughput всей системы даже при низкой общей загрузке, это симптом плохо настроенного или отсутствующего батчинга — подробнее о том, как это проявляется и что с этим делать, в статье батчинг запросов: почему один пользователь тратит GPU.

Запас на пики, а не расчёт впритык

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

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

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

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