Вы купили мощный компьютер с нейросетью. Один сотрудник работает — всё летает, 50 токенов в секунду. Подключается второй — уже 25. Третий — 16. Пятый — 10. Десятый — ответ приходит с паузами, и люди начинают жаловаться.
Это не баг и не плохое железо. Это физика. Нейросеть при генерации ответа загружает все свои веса из памяти — миллиарды параметров — для каждого токена. И пропускная способность этой памяти конечна. Она делится между всеми, кто запросил ответ одновременно.
В этой статье разбираем: от чего зависит количество одновременных пользователей, как его посчитать и сколько людей реально сможет работать на конкретном железе.
Почему нейросеть замедляется при нескольких пользователях
Генерация ответа нейросетью состоит из двух этапов. Они принципиально отличаются и упираются в разные ресурсы.
Этап 1: обработка промпта (prefill)
Когда пользователь отправляет запрос, модель обрабатывает весь входной текст параллельно. Это быстро — тысячи токенов в секунду. На RTX 5090 модель с 8 миллиардами параметров обрабатывает промпт со скоростью 10 000+ токенов в секунду.
Этот этап упирается в вычислительную мощность (TFLOPS). Современные видеокарты и Apple Silicon справляются с ним хорошо.
Этап 2: генерация ответа (decode)
Здесь модель создаёт ответ по одному токену за раз. Для каждого токена нужно загрузить все веса модели из видеопамяти в вычислительные ядра. Модель с 8B параметров в Q4-квантизации — это ~5 ГБ данных. Для каждого токена. Каждый раз.
Этот этап упирается в пропускную способность памяти (ГБ/с). И именно он определяет, сколько токенов в секунду получит каждый пользователь.
Как это влияет на многопользовательскую работу
Общая скорость генерации на одном устройстве — примерно постоянная величина. Она определяется формулой:
Максимальная скорость генерации = пропускная способность памяти / размер модели
Для RTX 4090 (1 008 ГБ/с) с моделью 8B Q4 (5 ГБ): ~200 tok/s.
Эти 200 tok/s — общий пирог. Один пользователь получает все 200. Два — по 100. Пять — по 40. Двадцать — по 10.
Формула: как посчитать максимум
Количество одновременных пользователей ограничено двумя факторами. Реальный лимит — наименьший из двух.
Ограничение 1: видеопамять (VRAM)
Каждый одновременный пользователь занимает место в видеопамяти для хранения контекста диалога — так называемого KV-кеша.
Доступная VRAM = общая VRAM - веса модели - накладные расходы (~2 ГБ)
KV-кеш на одного пользователя:
KV = 2 × слои × KV-головы × размерность × длина контекста × байт
Для модели 8B (32 слоя, 8 KV-голов, размерность 128) при контексте 4 096 токенов в FP16:
2 × 32 × 8 × 128 × 4096 × 2 = 0,5 ГБ на пользователя
Максимум пользователей (по VRAM) = доступная VRAM / KV-кеш на пользователя
Пример для RTX 4090 (24 ГБ) с моделью 8B Q4:
- Веса модели: ~5 ГБ
- Доступно: 24 - 5 - 2 = 17 ГБ
- KV-кеш при 4K контексте: ~0,5 ГБ
- Максимум: ~34 слота
Ограничение 2: пропускная способность памяти
Даже если VRAM позволяет 34 слота, каждый пользователь получит всего ~6 tok/s (200 / 34). Это ниже порога комфорта.
Комфортный порог: 20+ tok/s (быстрее скорости чтения, текст «течёт»).
Приемлемый порог: 10+ tok/s (читаемо, но с паузами).
Формула комфортных пользователей = общая скорость / порог на пользователя
RTX 4090, модель 8B Q4, порог 20 tok/s: ~200 / 20 = 10 комфортных пользователей.
RTX 4090, модель 8B Q4, порог 10 tok/s: ~200 / 10 = 20 приемлемых пользователей.
На практике лимитирует именно пропускная способность, а не VRAM. Видеопамяти обычно хватает на десятки слотов, но скорость генерации падает до неприемлемой раньше.
Контекст — тихий убийца производительности
Длина контекста влияет на производительность дважды. Во-первых, KV-кеш растёт линейно — при 32K контексте каждый пользователь занимает в 8 раз больше VRAM, чем при 4K. Во-вторых, обработка длинного контекста замедляет генерацию.
Данные с RTX 4090, модель 8B Q4 (один пользователь):
| Контекст | Скорость генерации | Падение |
|---|---|---|
| 4K | 131 tok/s | — |
| 8K | 119 tok/s | -9% |
| 32K | 77 tok/s | -41% |
| 65K | 53 tok/s | -60% |
| 131K | 32 tok/s | -76% |
Для многопользовательского сервера это означает: если ваши сотрудники загружают длинные документы (контракты, отчёты), количество одновременных пользователей падает в разы по сравнению с коротким чатом.
Чат vs конвейер: 10 пользователей — это не 10 одновременных запросов
Это ключевой инсайт, который не встречается ни в одном существующем руководстве.
Паттерн чата
В чате человек отправляет запрос, читает ответ 30–60 секунд, думает, формулирует следующий вопрос. Из 10 минут «работы» нейросеть генерирует текст ~1–2 минуты. Остальное время — пользователь читает и думает.
Это значит: 10 чат-пользователей одновременно создают 2–3 запроса в каждый момент времени. Не 10.
Паттерн конвейера
Автоматизация, пакетная обработка документов, API-интеграция. Запросы идут непрерывно, без пауз на чтение. Каждый «пользователь» — постоянная нагрузка.
Что это меняет на практике
RTX 4090 с моделью 14B Q4 выдаёт ~80 tok/s.
| Сценарий | Комфортно одновременных запросов | Реальных пользователей |
|---|---|---|
| Чат (офис) | 4 | 15–20 |
| Код-ассистент (IDE) | 4 | 8–12 |
| Пакетная обработка | 4 | 4 |
Продавцы серверов часто указывают «до 50 пользователей», имея в виду чат-режим с низкой одновременностью. При пакетной обработке на том же железе — в 5–10 раз меньше.
10 человек в чате и 10 конвейеров — это две совершенно разные нагрузки. Первая работает на RTX 4090. Для второй нужен кластер.
Бенчмарки: конкретные цифры на конкретном железе
Данные из независимых тестов. «Комфортно» — 20+ tok/s на пользователя. «Приемлемо» — 10+ tok/s.
Видеокарты NVIDIA
| Железо | Модель | 1 пользователь | Комфортно (20+ tok/s) | Приемлемо (10+ tok/s) |
|---|---|---|---|---|
| RTX 4090 (24 ГБ) | 8B Q4 | 131 tok/s | 5–6 | 10–12 |
| RTX 4090 (24 ГБ) | 14B Q4 | 83 tok/s | 3–4 | 6–8 |
| RTX 4090 (24 ГБ) | 32B Q4 | 39 tok/s | 1–2 | 3 |
| RTX 5090 (32 ГБ) | 8B Q4 | 186 tok/s | 8–9 | 15–18 |
| RTX 5090 (32 ГБ) | 14B Q4 | 124 tok/s | 5–6 | 10–12 |
| RTX 5090 (32 ГБ) | 32B Q4 | 61 tok/s | 2–3 | 5–6 |
| 2× RTX 5090 (64 ГБ) | 70B Q4 | 27 tok/s | 1 | 2 |
Apple Silicon
| Железо | Модель | 1 пользователь | Комфортно | Приемлемо |
|---|---|---|---|---|
| Mac Mini M4 Pro 64 ГБ | 8B Q4 | ~55 tok/s | 2 | 4–5 |
| Mac Mini M4 Pro 64 ГБ | 32B Q4 | ~16 tok/s | 0 (медленно даже для одного) | 1 |
| Mac Studio M4 Max 128 ГБ | 8B Q4 | ~93 tok/s | 3–4 | 7–8 |
| Mac Studio M4 Max 128 ГБ | 30B MoE | ~110 tok/s | 3–4 | 8–10 |
| Mac Studio M4 Max 128 ГБ | 70B Q4 | ~20 tok/s | 1 | 1–2 |
Почему Apple Silicon медленнее при конкурентности
Пропускная способность памяти M4 Max — 546 ГБ/с. У RTX 5090 — 1 792 ГБ/с. Разница в 3,3 раза. При одном пользователе и большой модели это не так заметно (Apple загружает модель из unified memory без копирования). Но при нескольких пользователях пропускная способность становится потолком, и NVIDIA выигрывает.
Apple Silicon выигрывает, когда нужна большая модель для одного-двух пользователей (70B целиком в 128 ГБ unified memory). NVIDIA выигрывает, когда нужна средняя модель для многих пользователей (пропускная способность = больше «пирога»).
Какое ПО использовать для нескольких пользователей
Выбор программного обеспечения влияет на результат не меньше, чем железо. На одной и той же видеокарте A100 с моделью 8B в тестах Red Hat измерили:
| Сервер | Суммарная скорость при 50 пользователях |
|---|---|
| vLLM | 793 tok/s |
| Ollama (настроенный) | 155 tok/s |
| Ollama (по умолчанию) | 41 tok/s |
Разница — в 19 раз между vLLM и Ollama по умолчанию.
Ollama — для 1–4 человек
По умолчанию обрабатывает 4 запроса параллельно (переменная OLLAMA_NUM_PARALLEL). Каждый дополнительный слот расходует VRAM на KV-кеш. При 4 слотах и контексте 4K — это ~2 ГБ дополнительно.
Ollama прост в установке и идеален для персонального использования или маленькой команды. Но при 5+ пользователях запросы встают в очередь, и время ожидания растёт непредсказуемо.
vLLM — для 5–50+ пользователей
Использует технологию PagedAttention — управление KV-кешем по принципу виртуальной памяти операционной системы. Это устраняет 60–80% потерь памяти и позволяет обслуживать в 2–4 раза больше пользователей на том же железе.
Также поддерживает continuous batching — когда один пользователь закончил генерацию, его место мгновенно занимает следующий запрос из очереди. Без простоев.
llama.cpp server — для macOS и специфических задач
Поддерживает --parallel N для нескольких слотов. Оптимален для Apple Silicon (Metal API). Бенчмарк на A40: 8 параллельных слотов обслуживают ~22 разработчика в режиме код-ассистента.
Как увеличить количество пользователей без замены железа
1. Используйте более агрессивную квантизацию
Модель 14B в Q8 (~14 ГБ) и в Q4 (~8 ГБ) — это та же модель, но в Q4 она занимает почти вдвое меньше памяти. Освободившееся место идёт под KV-кеш дополнительных пользователей, а пропускная способность расходуется эффективнее.
Потери качества при Q4 — 1–3%. При Q3 — 5–10%, уже заметно на сложных рассуждениях.
2. Используйте MoE-модели
Модель с 30B параметров и 3B активными (MoE) генерирует токены так, словно она 3B-модель — быстро. Но отвечает как 30B — умно. На RTX 5090 MoE-модель 30B выдаёт 234 tok/s — быстрее, чем плотная 8B. Это означает больший «пирог» для пользователей.
3. Ограничьте длину контекста
Если задачи не требуют 128K контекста — ограничьте до 4K или 8K. Это высвобождает VRAM (меньше KV-кеш на пользователя) и ускоряет генерацию.
4. Переключитесь с Ollama на vLLM
Если вы уже упёрлись в лимит Ollama (4 слота) — переход на vLLM даёт 5–19-кратный прирост пропускной способности при том же железе. Это самый простой способ «добавить» пользователей.
Практическая таблица: железо + модель = пользователи
Ниже — сводная таблица для конфигураций из нашего каталога. Все цифры — для чат-режима (офисное использование, 2–3 одновременных запроса на 10 пользователей). Для конвейерной обработки делите на 3–5.
| Конфигурация | Память | Модель | Скорость (1 чел) | В чате комфортно | В чате максимум |
|---|---|---|---|---|---|
| Mac Mini M4 (16 ГБ) | 16 ГБ | 8B Q4 | ~50 tok/s | 1–2 | 3–5 |
| Mac Mini M4 Pro (48 ГБ) | 48 ГБ | 14B Q4 | ~28 tok/s | 1–2 | 3–5 |
| Mac Mini M4 Pro (64 ГБ) | 64 ГБ | 32B Q4 | ~16 tok/s | 1 | 2–3 |
| Mac Studio M4 Max (64 ГБ) | 64 ГБ | 14B Q4 | ~48 tok/s | 3–5 | 8–12 |
| Mac Studio M4 Max (128 ГБ) | 128 ГБ | 30B MoE | ~110 tok/s | 5–8 | 15–20 |
| 2× RTX 5060 Ti (32 ГБ) | 32 ГБ | 14B Q4 | ~80 tok/s | 3–5 | 8–15 |
| 2× RTX 4080 Super (32 ГБ) | 32 ГБ | 14B Q4 | ~90 tok/s | 4–6 | 10–15 |
| 1× RTX 5080 (16 ГБ) | 16 ГБ | 8B Q4 | ~120 tok/s | 4–5 | 8–12 |
| 2× RTX 5090 (64 ГБ) | 64 ГБ | 32B Q4 | ~90 tok/s | 5–8 | 15–20 |
| 2× RTX 5090 (64 ГБ) | 64 ГБ | 70B Q4 | ~27 tok/s | 1–2 | 3–5 |
| Mac-ферма Старт (128 ГБ) | 128 ГБ | 70B Q4 | ~18 tok/s | 1–2 | 3–5 |
| Mac-ферма Про (256 ГБ) | 256 ГБ | 70B Q4 | ~35 tok/s | 3–5 | 8–15 |
| Mac-ферма Ультра (512 ГБ) | 512 ГБ | 70B Q4 | ~80 tok/s | 5–10 | 15–25 |
Цифры в столбцах «в чате» предполагают, что из N пользователей только 20–30% отправляют запрос в один момент. При непрерывной нагрузке (API, автоматизация) — делите на 3–5.
Итог: три правила планирования
Правило 1. Считайте не пользователей, а одновременные запросы. 10 человек в чате — это 2–3 запроса одновременно. 10 API-клиентов — это 10.
Правило 2. Пропускная способность памяти важнее объёма. 128 ГБ unified memory на Mac Studio (546 ГБ/с) обслужат меньше пользователей, чем 64 ГБ VRAM на двух RTX 5090 (1 792 ГБ/с × 2).
Правило 3. Софт умножает железо. vLLM на той же видеокарте обслуживает в 5–19 раз больше пользователей, чем Ollama. Переход на правильный инференс-сервер — самый дешёвый «апгрейд».
Мощность нейросети — не сколько она знает, а скольким людям она отвечает одновременно. И это можно посчитать.
Не хотите считать? Мы подберём конфигурацию под ваше количество пользователей.
Источники
- HuggingFace — Prefill and Decode for Concurrent Requests (англ.)
- Anyscale — 23x Throughput with Continuous Batching (англ.)
- Red Hat — Ollama vs vLLM Deep Dive (англ.)
- Hardware Corner — RTX 4090 LLM Benchmarks (англ.)
- Hardware Corner — RTX 5090 LLM Benchmarks (англ.)
- arXiv — Native LLM Inference at Scale on Apple Silicon (англ.)
- Spheron — KV Cache Optimization Guide (англ.)
- VMware — LLM Inference Sizing Guidance (англ.)
- PremAI — LLM Infrastructure Sizing (англ.)
- Selectel — Как приручить LLM: подбор инфраструктуры