Сколько железа нужно ИИ-агенту: как считали ресурсы для on-premise LLM и почему калькуляторы ошиблись в 5 раз
В проекте использовали GPT-OSS-120B, reasoning-модель с архитектурой MoE: из 120B параметров на запросе активны примерно 5B. Клиент выбрал две RTX Pro 6000 Blackwell по 96 GB VRAM, всего 192 GB, а сервис apxml.com оценил такой стенд в 4696 токенов/с при 8 пользователях и контексте 2000 токенов. После тестов через API на реальном контуре результат оказался 880 токенов/с, то есть примерно в 5,3 раза ниже.
Проверка включала 10 сценариев: от 1 до 8 параллельных пользователей, контекст от 2K до 16K токенов, с prefix caching и без него. При 1 пользователе и 2000 токенах контекста авторы получили TTFT p50 0,162 секунды и 271,9 токена/с генерации; при 8 пользователях TTFT p50 снизился до 0,135 секунды, а общая скорость выросла до 880,8 токена/с. Масштабирование получилось примерно 4× вместо идеальных 8× из-за накладных расходов батчинга в vLLM.
Длинный контекст заметно снижал пропускную способность: при 16K токенов и 8 пользователях скорость упала до 645,3 токена/с. Prefix caching, наоборот, помогал: при повторении 80% контекста TTFT p50 снижался на 41%, а p95-тормоза — на 67%. Авторы объясняют ошибку калькуляторов тем, что они считают теоретический потолок, хуже учитывают MoE, FP4 на Blackwell, батчинг vLLM и нестандартные workstation-GPU, поэтому для таких конфигураций реальный бенчмарк важнее публичной оценки.
Коротко
- Публичный калькулятор оценил стенд 2× RTX Pro 6000 Blackwell и GPT-OSS-120B в 4696 токенов/с, реальный тест дал около 880 токенов/с.
- Тесты шли через API в закрытом контуре: 10 сценариев, 1–8 параллельных пользователей, контекст 2K–16K и проверка prefix caching.
- При 8 пользователях TTFT p50 стал ниже, чем при одном: vLLM лучше загружал GPU за счёт параллельной обработки и батчинга.
- Увеличение контекста до 16K токенов снизило скорость до 645,3 токена/с, а prefix caching уменьшил TTFT p50 на 41%.
- Авторы предлагают считать VRAM калькуляторами, но пропускную способность для редкого железа и MoE-моделей подтверждать реальным прогоном.
FAQ
Зачем проводить нагрузочный тест on-premise LLM, если публичный калькулятор уже показывает токены в секунду?
Калькулятор показывает теоретический максимум, а не SLA для конкретного железа, рантайма и нагрузки. В описанном кейсе реальный результат оказался ниже примерно в 5,3 раза.
Почему GPT-OSS-120B на MoE-архитектуре сложнее оценивать обычными калькуляторами для LLM-инференса?
В MoE активна только часть параметров, а кэш и нагрузка ведут себя иначе, чем у плотных моделей. Из-за этого расчёты по всем 120B параметрам могут сильно искажать результат.
Что в этом кейсе сильнее всего влияло на пользовательскую задержку и пропускную способность LLM-агента?
На скорость влияли параллельность, длина контекста, батчинг vLLM и prefix caching. При повторяющемся контексте кэш заметно снижал TTFT и p95-задержки.
Читайте также
Облачная LLM на 16 ГБ VRAM — часть 3: интерфейс в стиле ChatGPT для LangGraph-агентов
ИИ-агенты для бизнеса в России: обзор 10 локальных платформ и решений- Как я собрал LLM-печку на четырёх GPU и что она умеет
- Как выбрать между облаком, арендой GPU и своим железом для LLM-систем
- Запуск gpt-oss на 20B и 120B параметров на Core i9: сравнение инференса на CPU и GPU (RTX 4090)
- Публичные LLM-калькуляторы нельзя использовать как SLA по пропускной способности: Калькуляторы могут быть полезны для первичной оценки VRAM, но их прогноз TPS часто отражает теоретический roofline, а не реальную работу конкретного стенда. Для нестандартного железа, MoE-моделей и vLLM фактическая пропускная способность может отличаться от расчёта в несколько раз.
[AI-инфраструктура / Оценка ресурсов LLM]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
LLMStart.ru описывает практический расчёт железа для on-premise LLM-агента: публичный калькулятор обещал 4696 токенов/с, но реальный тест на 2× RTX Pro 6000 Blackwell дал около 880 токенов/с. Главный вывод: для SLA по нестандартному стеку формул недостаточно, нужен нагрузочный прогон.