Мы в LLMStart.ru делаем AI-системы для бизнеса. Часто работаем с on-premise — это закрытые контуры, где безопасность не разрешает внешние API. В одном проекте мы разворачивали LLM-агента на 2× RTX Pro 6000 Blackwell под GPT-OSS-120B (MoE). Нам нужно было дать клиенту железную гарантию: сколько одновременных диалогов потянет система. Облачного автоскейлинга нет, права на ошибку — тоже.
Сначала пошли простым путем — открыли публичный калькулятор. Он пообещал 4696 токенов в секунду при 8 параллельных пользователях. Прежде чем радовать заказчика, мы написали скрипт и прогнали тесты на реальном железе. Результат? 880 токенов в секунду. Расхождение — в 5 раз!
Кому это читать:
-
AI-инженерам, считающим железо под on-premise LLM.
-
Тем, кто работает с нестандартными сборками (у нас тут редкая связка workstation-GPU RTX Pro 6000 Blackwell и MoE-модели, на которой калькуляторы сходят с ума).
-
Всем, кто хочет понять разницу между теоретическим потолком и суровой реальностью.
Оценка в теории: почему калькулятор обещал нам золотые горы
В качестве целевой модели мы выбрали GPT-OSS-120B. Это крупная reasoning-модель с архитектурой MoE (Mixture of Experts). Фишка в том, что из 120B параметров на каждом запросе работают только ~5B.
-
По качеству — топ среди аналогов.
-
По памяти — идеальный баланс (модели крупнее на нашем железе просто не завелись бы).
Заказчик выбрал нестандартное железо: 2× RTX Pro 6000 Blackwell (по 96 GB VRAM каждая, итого 192 GB). Это редкая штука, не из стандартных дата-центров.
Мы закинули эти вводные в популярный калькулятор apxml.com. Вердикт: 4696 токенов в секунду (8 пользователей, контекст 2000 токенов). Ради интереса глянули в selfhostllm.org и howmanygpus.ai — там цифры вообще плясали. И вот тут логика сломалась: доверять голым формулам было страшно. Пришлось тестировать руками.
Как мы устроили краш-тест на серверах заказчика
Заказчик поднял vLLM в своем защищенном контуре и выдал нам только доступ к API. Никакого прямого доступа к серверу, GPU или настройкам рантайма у нас не было. Пришлось выкручиваться и писать скрипт, работающий чисто поверх API.
Мы прогнали 10 сценариев:
-
От 1 до 8 параллельных пользователей.
-
Контекст от 2K до 16K токенов.
-
С включенным и выключенным prefix caching. Итог: 1080 запросов, по 30 раундов на пользователя.
Важный нюанс: «один пользователь» в нашем тесте — это не одинокий запрос, а долгая беседа. Мы прогоняли по 30 раундов, чтобы сымитировать реальный диалог и отловить все задержки. А когда пользователей восемь, это уже похоже на настоящий хардкорный трафик, а не на стерильное лабораторное тестирование.
Заглядываем под капот: что вообще нужно мерить
Мы собирали несколько ключевых метрик. Давайте расшифруем их один раз, чтобы дальше не путаться:
-
TTFT (time to first token) — время до первого сгенерированного токена. Для reasoning-моделей первый токен — это обычно внутреннее рассуждение, невидимое пользователю. Поэтому наше TTFT — это про время работы железа, а не про ожидание на экране.
-
TPOT (time per output token) — задержка между соседними токенами (в секундах).
-
TPS (tokens per second) — общая скорость генерации. Сюда входят все токены, включая скрытые reasoning-размышления. GPU потеет над ними всеми, даже если пользователь видит лишь красивый итог.
-
p50, p95 — перцентили задержек. Среднее значение часто врет, поэтому мы смотрим на хвосты: p50 (половина запросов быстрее этой цифры) и p95 (самые долгие 5% запросов).
Запомните: бенчмарк меряет сырую мощь железа и модели. Бизнес-логика, вызовы инструментов и многоходовочки агента сюда не входят — это отдельная история.
Сухие цифры и внезапные инсайты
Смотрим на базу: 1 пользователь, 2000 токенов контекста.
-
TTFT p50 = 0.162 секунды.
-
Скорость генерации = 271.9 токенов/сек.
-
Общая пропускная способность = 237.5 токенов/сек (тут учитывается еще и переваривание самого промпта).
А теперь добавим жару — 8 параллельных юзеров. И вот тут логика сломалась: TTFT p50 внезапно упала до 0.135 секунды (стало на 17% быстрее!). Общая скорость выросла до 880.8 токенов/сек. Масштабирование получилось 4× вместо идеальных 8× — вполне ожидаемо из-за накладных расходов батчинга в vLLM.
Увеличиваем контекст до 16K токенов (те же 8 юзеров). Скорость падает до 645.3 токенов/сек. Больше контекст — больше работы для памяти и процессора.
Почему при 8 юзерах отклик быстрее, чем при одном? Спойлер: интуиция нас обманывает. Это магия архитектуры vLLM. Система параллельно обрабатывает запросы и лучше забивает ядра видюхи работой, вместо того чтобы простаивать в ожидании одного единственного пользователя.
Пару слов про накладные расходы. GPT-OSS-120B генерит кучу невидимого текста: на 1 видимый токен приходится 2-3 скрытых reasoning-токена. Юзер видит ответ на 100 токенов, а GPU в реальности отпахала на все 400.
Нас мощно спас prefix caching. Если 80% контекста повторяется (например, системный промпт), TTFT p50 падает на 41%, а жесткие тормоза (p95) исчезают на 67%.
В новых vLLM эта фича включена по умолчанию. Но у нас был только REST-доступ — глухой черный ящик. Чтобы проверить работу без кэша, мы вставляли случайный мусор в начало промпта, ломая кэширование. И, конечно, мы убедились, что в момент тестов никто другой систему не трогал.
Почему формулы ломаются на практике
Итак, apxml.com обещал нам 4696 токенов, а мы выжали только 880. Разница в 5.3 раза! Прежде чем обвинять разработчиков калькулятора, давайте разберемся.
Почему сферический конь в вакууме не работает
Любой публичный калькулятор выдает вам сферического коня в вакууме. Он считает теоретический максимум (roofline): как бы работала карточка, если бы не было никаких накладных расходов. Но реальность кусается. Как пишет Pierre Lienhart в LLM Inference Series, формулы дают best-case, а не SLA. Плюс vLLM оптимизирован под быстрый отклик (TTFT), а не под пропускную способность.
С MoE-моделями всё еще сложнее. Активна только часть параметров, кэш считается хитро, нагрузка скачет. Обычный калькулятор этого не понимает. Умные ребята пилят отдельные штуки типа MoE-Lens, которые учитывают эти боли и предсказывают скорость с точностью 94%.
Так что калькулятор нас не обманул. Он просто ответил на другой вопрос.
Анатомия 5-кратного провала
Мы препарировали ошибку и нашли двух виновников:
-
Завышение скорости для 1 юзера (в 2.3 раза).
-
Завышение масштабирования (еще в 2.1 раза).
Перемножаем и получаем те самые 5× разницы. Калькулятор верит, что масштабирование линейное, а GPU загружена на 100%. Наше нестандартное железо легко ломает эти сказки.
Забавно, что другой сервис — selfhostllm.org — ошибся в обратную сторону. Он занизил скорость в 17 раз! Проблема в том, что он считал кэш по всем 120B параметрам модели, а у нас работают только ~5B.
Третий пациент, howmanygpus.ai, вообще не знал про карточки RTX Pro 6000. В его мире существуют только монстры из дата-центров. Ошибка составила около 100×.
Почему они все мажут?
-
Не умеют считать FP4-вычисления на Blackwell.
-
Не знают о существовании десктопных карт вроде нашей RTX.
-
Не понимают магию батчинга vLLM.
-
Считают MoE-архитектуру по лекалам обычных плотных сеток.
Вывод прост: для редких связок железа и хитрых моделей эти калькуляторы бесполезны.
Мы не сумасшедшие: независимые пруфы от Millstone AI
Увидев расхождение в 5 раз, мы слегка напряглись: а не криво ли мы всё намеряли? Полезли копать интернет и наткнулись на свежий бенчмарк от Millstone AI. Ребята тестировали ровно тот же стек: GPT-OSS-120B, формат MXFP4 и две RTX Pro 6000 Blackwell.
Сравним цифры:
-
У них 1 юзер выдает 230.5 токенов/сек (у нас 272 — на 18% шустрее).
-
Их пиковый TPS — 667 токенов/сек (у нас 880 — на 32% больше).
Почему мы оказались быстрее? У нас свежая версия vLLM (v0.15.1), куда как раз завезли фиксы под Blackwell в феврале 2026. Плюс немного отличались параметры нагрузки.
Выдыхаем — мы мерили правильно! Расхождение с калькулятором — это суровая реальность. Давать гарантии клиенту на основе одних только формул — самоубийство.
Чек-лист: как правильно считать железо под LLM
Итого, вот наша инструкция по выживанию.
Оценка VRAM (памяти) — тут калькуляторам можно верить. Формула простая, зависит от веса модели и контекста. Отличный инструмент для первого прикидочного расчета.
Оценка пропускной способности — а вот тут всё сложнее. Рейтинг надежности выглядит так:
-
Только хардкорный тест. Редкое железо, кастомная модель, хитрые флаги vLLM? Не рискуйте. Потратьте пару дней на скрипт и реальный прогон. Цена ошибки слишком высока.
-
Готовые бенчмарки. Типичная сборка? Ищите тесты вроде Millstone AI. Они дадут понимание с погрешностью ~30%, чего вполне хватит для старта.
-
Публичные калькуляторы. Последняя надежда. Помните: вам покажут красивый, но недостижимый потолок.
Наш пайплайн теперь кристально прост: за 5 минут прикидываем VRAM в калькуляторе, а затем тратим день-два на реальные тесты под on-premise. Один раз обкатали конкретную сборку — используем цифры для всех будущих клиентов на таком же стеке.
Главное: вам не нужно быть гением GPU-вычислений. Хватит базового скрипта, доступа к железу и пары дней терпения. Только так можно спать спокойно после подписания договора.
А вы нарывались на такие сюрпризы от калькуляторов? Кто гонял MoE-модели на B200, H100 или мощных десктопных картах — закидывайте цифры в комменты. Соберем свою карту реальности!
Расхождение теоретических метрик с реальностью — обычное дело для on-premise систем, и грамотный нагрузочный тест спасает от критических ошибок в оценке оборудования.
В LLMStart.ru мы помогаем бизнесу решать такие задачи и получать реальный эффект от ИИ — от прототипа до промышленной эксплуатации. Обращайтесь к нам за консультацией или разработкой on-premise AI-решений под ключ.
Если хотите перенять опыт и научиться делать подобные системы самостоятельно, у нас есть Комбо из четырех курсов по AI-driven разработке и ИИ-агентам. Это полный гайд от AI-кодинга и первых ассистентов к AI-продуктам, RAG-системам, агентам и мультиагентным системам.
По любым вопросам пишите мне в личку: Telegram или ВК. Приглашаем также в наши соцсети про ИИ-кодинг ИИ-агентов: в ТГ-канал и ВК-сообщество
ссылка на оригинал статьи https://habr.com/ru/articles/1046722/