Российская команда LLMStart.ru столкнулась с задачей, которая возникает у всё большего числа корпоративных заказчиков: развернуть языковую модель на собственном железе без доступа к облаку и дать клиенту точную гарантию по числу одновременных диалогов. Ошибиться нельзя — облачного автоскейлинга нет, а недооценка нагрузки означает деградацию сервиса в продакшне.
Для проекта выбрали модель GPT-OSS-120B с архитектурой Mixture of Experts (MoE) и железо заказчика — два GPU RTX Pro 6000 Blackwell с 96 ГБ видеопамяти каждый, итого 192 ГБ VRAM. Это рабочие станционные карты, а не серверные ускорители из стандартных дата-центров, что сразу делает их невидимыми для большинства онлайн-калькуляторов. Публичный сервис apxml.com при вводе этих параметров выдал прогноз: 4696 токенов в секунду при 8 параллельных пользователях и контексте 2000 токенов. Два других сервиса — selfhostllm.org и howmanygpus.ai — дали ещё более экзотические числа.
| Калькулятор | Прогноз TPS | Реальный TPS | Погрешность |
|---|---|---|---|
| apxml.com | 4696 | 880 | в 5,3 раза завышен |
| selfhostllm.org | ~15 (расчётно) | 880 | в 17 раз занижен |
| howmanygpus.ai | не знает RTX Pro 6000 | 880 | около 100× |
Перед тем как передать цифры заказчику, команда написала нагрузочный скрипт и прогнала его поверх API, который предоставил клиент. Прямого доступа к серверу, GPU и настройкам рантайма не было — только REST-эндпоинт. Тест охватил 10 сценариев: от 1 до 8 параллельных пользователей, контекст от 2K до 16K токенов, режимы с prefix caching и без него. Итого 1080 запросов, по 30 диалоговых раундов на каждого виртуального пользователя — чтобы имитировать реальный разговор, а не одиночный запрос.
Модель GPT-OSS-120B с архитектурой MoE активирует только ~5B из 120B параметров, что сбивает стандартные формулы расчёта.
Результат при 8 пользователях и контексте 2000 токенов составил 880,8 токена в секунду — в 5,3 раза меньше прогноза калькулятора. Авторы разложили ошибку на два множителя: завышение скорости для одного пользователя (в 2,3 раза) и завышение коэффициента масштабирования (ещё в 2,1 раза). Перемножение даёт те самые пять крат расхождения.
Один из неожиданных результатов теста — поведение задержки при росте нагрузки. При переходе с 1 на 8 параллельных пользователей TTFT p50 не вырос, а упал: с 0,162 до 0,135 секунды, то есть на 17%. Объяснение — в архитектуре vLLM: система группирует запросы в батчи и загружает ядра GPU плотнее, чем при обработке одиночного запроса. Одиночный пользователь фактически заставляет GPU простаивать между токенами.
При увеличении контекста до 16K токенов (те же 8 пользователей) пропускная способность упала до 645,3 токена в секунду — больше контекст требует больше операций с памятью. Отдельно команда проверила эффект prefix caching: если 80% контекста повторяется (например, системный промпт), TTFT p50 снижается на 41%, а задержки в хвосте (p95) — на 67%. В новых версиях vLLM кэширование включено по умолчанию, но проверить его работу без доступа к серверу пришлось косвенно — вставляя случайный текст в начало промпта, чтобы намеренно сломать кэш.
Отдельная проблема — архитектура MoE. GPT-OSS-120B активирует на каждом запросе только около 5 млрд из 120 млрд параметров. Стандартные калькуляторы этого не учитывают: selfhostllm.org считал кэш по всем 120B и занизил скорость в 17 раз, howmanygpus.ai вовсе не знал о существовании карт RTX Pro 6000 и ошибся примерно в 100 раз. Дополнительный фактор — reasoning-модели генерируют скрытые токены внутреннего рассуждения: на каждый видимый пользователю токен GPU обрабатывает ещё 2–3 невидимых, что снижает наблюдаемую скорость относительно теоретического максимума.
Для верификации результатов команда нашла независимый бенчмарк от Millstone ИИ на том же стеке — GPT-OSS-120B, формат MXFP4, две RTX Pro 6000 Blackwell. У Millstone ИИ одиночный пользователь давал 230,5 токена/сек, пиковый TPS — 667. У LLMStart.ru — 272 и 880 соответственно. Разница объясняется версией vLLM: команда использовала v0.15.1, в которую в феврале 2026 года добавили оптимизации под архитектуру Blackwell. Порядок цифр совпал — методология подтверждена.
Практический вывод для тех, кто планирует on-premise развёртывание: публичные калькуляторы дают теоретический потолок (roofline) без учёта накладных расходов батчинга, особенностей MoE-архитектур и нестандартного железа. Для получения реальных SLA необходим нагрузочный тест на целевом стеке — даже если доступен только API.
