Две RTX PRO 6000 и терабайт памяти: выдержит ли эта станция 20 одновременных пользователей?

Почему бизнес покупает монстров за полмиллиона, а потом плачет

Типичная история: компания заказывает серверную рабочую станцию с двумя RTX PRO 6000 и 1.15 терабайтами оперативной памяти. Стоит как хорошая квартира. Все ждут, что она будет обслуживать всю команду из 20-30 человек одновременно. А через месяц выясняется, что система задыхается уже на 5 пользователях.

Проблема не в железе. Проблема в том, что никто не проверяет реальную масштабируемость. Все смотрят на красивые цифры "токенов в секунду" для одного пользователя и думают: "Ну, если один получает 100 токенов/с, то двадцать получат по 5 токенов/с, сойдет".

Что мы тестировали и зачем

Конфигурация тестовой системы:

• 2× NVIDIA RTX PRO 6000 Ada (48 ГБ VRAM каждая)
• AMD Threadripper PRO 7995WX (96 ядер)
• 1.15 ТБ DDR5 ECC RAM (8×144 ГБ)
• Supermicro MBD-H13SWA-NF
• Два блока питания по 2000W

Модели для тестов (актуальные на январь 2026):

• DeepSeek-V3.2 (671B параметров, MoE) - самая требовательная
• MiniMax-M2.1 (405B параметров) - популярная в бизнес-среде
• Qwen2.5-Coder (72B параметров) - для разработчиков
• Llama-4-70B-Instruct - как референс

KV-cache: тихий убийца многопользовательского режима

Вот что происходит, когда вы не учитываете KV-cache. Представьте, что у вас 20 пользователей. Каждый генерирует ответ длиной 2000 токенов. Для модели Llama-4-70B в формате fp8 KV-cache занимает примерно:

# Расчет памяти для KV-cache
batch_size = 20
seq_len = 2000
layers = 80
heads = 64
dim_per_head = 128
bytes_per_param = 1  # fp8

kv_cache_per_user = 2 * layers * heads * dim_per_head * seq_len * bytes_per_param
kv_cache_total = kv_cache_per_user * batch_size
print(f"KV-cache для 20 пользователей: {kv_cache_total / 1024**3:.2f} ГБ")

Результат: около 62 ГБ только на KV-cache. Плюс веса модели (70 ГБ в fp8). Плюс overhead системы. И вот ваши 96 ГБ VRAM уже переполнены, хотя казалось, что должно хватить.

Результаты тестов: где обещанная масштабируемость?

Видите тренд? Производительность на пользователя падает не линейно, а почти экспоненциально. К 20 пользователям вы получаете в 10 раз меньше скорости, чем для одного.

1 Почему int4 иногда выигрывает у fp8 в многопользовательском режиме

Казалось бы, fp8 быстрее и точнее. Но посмотрите на цифры для 20 пользователей: int4 показывает 15 токенов/с против 8 у fp8. Почти в два раза лучше.

Причина простая: int4 модель занимает в два раза меньше места. Значит, больше места остается для KV-cache. Меньше swapping между GPU и CPU. Меньше contention на PCIe шине.

2 CPU offloading: спасательный круг или якорь?

Когда VRAM заканчивается, система начинает сбрасывать часть данных в оперативную память. У нас 1.15 ТБ RAM, казалось бы, можно все туда засунуть. Но цена этого решения - latency.

Тесты показывают:

• Без offloading: 142 токен/с для одного пользователя
• С offloading 20% слоев на CPU: 89 токен/с (падение 37%)
• С offloading 50% слоев на CPU: 31 токен/с (падение 78%)

Offloading - это не бесплатный обед. Каждый переход GPU-CPU-GPU стоит около 0.5-1 мс. При генерации 2000 токенов эти задержки накапливаются.

Prefill vs Decode: где настоящее бутылочное горлышко

Большинство бенчмарков измеряют только decode скорость (генерацию токенов). Но в реальном сценарии есть еще prefill - обработка промпта пользователя.

Prefill масштабируется хуже, потому что требует полного внимания модели к каждому токену промпта. Когда 10 пользователей одновременно отправляют запросы, система должна либо обрабатывать их последовательно (увеличивая latency), либо параллельно (перегружая память).

Практические рекомендации: как не облажаться с дорогой станцией

3 Рассчитывайте не на пиковую, а на устойчивую нагрузку

Если вам нужно обслуживать 20 пользователей, не смотрите на производительность для одного. Сразу тестируйте с 20 одновременными сессиями. Используйте инструменты вроде нашего гайда по настройке общего сервера для нагрузочного тестирования.

4 Выбирайте модель под задачу, а не под маркетинг

Для 20 пользователей Llama-4-70B в int4 будет работать лучше, чем та же модель в fp8. Для кодирования лучше взять специализированную модель типа MiniMax-M2.1, но в урезанном формате.

5 Настройте динамическую загрузку слоев

Не загружайте всю модель сразу. Используйте динамическую загрузку: когда пользователь начинает диалог, его сессия получает выделенный контекст в VRAM. Когда заканчивает - память освобождается. Это сложнее в реализации, но дает прирост в 2-3 раза по количеству одновременных пользователей.

Альтернативы: может, не стоит покупать эту станцию?

Две RTX PRO 6000 + 1.15 ТБ RAM - это около $45,000 только за железо. Плюс корпус, питание, охлаждение. Итог - под $60,000.

За эти деньги можно рассмотреть:

1. Кластер из 16 MI50 - в 3 раза дешевле, но требует больше места и энергии
2. Систему на Radeon R9700 с 128 ГБ VRAM - дешевле, но сложнее с софтом
3. Аренду облачных инстансов - платите только за использование

Ошибки, которые совершают все (и вы тоже)

• Тестирование только в идеальных условиях - запускают один запрос, получают красивые цифры, покупают железо. А потом удивляются.
• Игнорирование KV-cache - рассчитывают память только под веса модели. Это как покупать квартиру, учитывая только площадь комнат, но забывая про стены.
• Линейная экстраполяция - "если для одного 100 токенов/с, то для десяти будет 10 токенов/с". Не будет. Будет 3-5 токенов/с.
• Выбор самой большой модели - берут DeepSeek-V3.2 на 671B параметров, хотя для задач компании хватило бы Qwen2.5 на 72B.

Что в итоге выдержит эта станция?

Исходя из наших тестов:

• Для разработки (Qwen2.5-Coder): 8-10 программистов одновременно с комфортной скоростью (30+ токенов/с)
• Для поддержки клиентов (Llama-4-70B): 5-7 операторов с хорошим качеством ответов
• Для исследовательских задач (MiniMax-M2.1): 3-4 аналитика с длинными контекстами
• Для демонстраций и презентаций: до 20 пользователей с ограничением длины ответа (200 токенов)

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

И последнее: перед покупкой всегда делайте proof-of-concept с реальной нагрузкой. Арендуйте похожую систему на неделю, настройте локальный AI-сервер, запустите тесты. Сэкономите не только деньги, но и нервы.