Большой бенчмарк: ROCm против Vulkan в LM Studio 0.4 и параллельные запросы

31.01.2026 • Хабр

LM Studio 0.4.0 добавил continuous batching для параллельной обработки запросов в локальном API. Автор сравнил ROCm и Vulkan и показал, что выбор бэкенда и настройка параллелизма сильно меняют TPS.

Релиз LM Studio 0.4.0 вышел 27 января и перевёл обработку запросов с последовательной очереди на continuous batching (по умолчанию до 4 параллельных запросов).
Тестовый стенд: Windows 11, AMD Radeon RX7800XT 16 ГБ, AMD Ryzen 5700X3D, 64 ГБ RAM; нагрузка — асинхронные запросы Python aiohttp при конкуренции 1–64.
Основная метрика — TPS (tokens per second); также считались TPS на запрос, рост эффективности и среднее время до первого токена (TTFT).
Пример на Qwen3 VL 2B (ROCm, 8 параллельных запросов): общий TPS вырос с 84.21 при 1 запросе до 609.52 при 64 запросах (эффективность 7.24×), а TPS на запрос в примере снизился с 84.21 до 76.19.
Сравнение бэкендов: на моделях 3–8B ROCm показал пик TPS выше Vulkan примерно на 85–100% (например, Ministral 3B 455 vs 246; Ministral 8B 266 vs 133; Qwen 4B 201 vs 103), тогда как на GPT-OSS 20B разница почти отсутствовала (122 vs 118).
В тесте под нагрузкой на 20B Vulkan оказался менее стабильным: при 64 параллельных запросах успешно обработано 48% запросов против 64% у ROCm; увеличение Max Concurrent Predictions с 4 до 8 на ROCm дало прирост пикового TPS примерно на 44–50% на нескольких моделях.

Почему это важно: Переход к параллельной обработке запросов меняет практическую экономику локального запуска LLM: один и тот же ПК может обслуживать больше одновременных обращений. В тексте это показывается через рост общего TPS и сравнение бэкендов для AMD-GPU.

На что обратить внимание: Результаты привязаны к конкретной конфигурации домашнего ПК и набору моделей/квантований, поэтому переносимость цифр зависит от железа и размера модели. Рост общего TPS сопровождается изменением TPS на один запрос и поведения задержек, поэтому важен выбранный режим нагрузки. Отдельным «рычагом» в описании выступает настройка Max Concurrent Predictions = 8, после которой подразумевается подбор компромисса между общей пропускной способностью и скоростью реакции на запрос.

Коротко

В бенчмарке использованы разные конфигурации моделей и квантования (Qwen3, Ministral, Nemotron, GPT-OSS), чтобы сравнение не упиралось в один сценарий.
В тексте отмечается зависимость масштабируемости от размера модели: у 0.6–2B рост от батчинга заметнее, а у 9–20B эффект ограничен.
Автор отдельно объясняет, что Vulkan выглядит конкурентнее на очень крупных моделях, когда упор смещается в видеопамять, а не в вычисления.
Сравнение CPU и GPU показывает большой разрыв по TPS, но для задач без жёстких требований к реальному времени батчинг на CPU описан как полезный компромисс.
Для интерпретации результатов обычно важны условия нагрузки: сколько одновременных запросов, сколько параллельных предсказаний и как считается успешность запросов.

FAQ

Зачем это важно тем, кто запускает локальные LLM как API-сервис: что в LM Studio 0.4.0 меняется для многопользовательской нагрузки и пропускной способности?

В тексте говорится, что continuous batching позволяет обрабатывать несколько запросов параллельно и существенно повышать общий TPS, приближая локальные LLM к production-сценариям.

Что именно нового появилось в LM Studio 0.4.0 и какие параметры в интерфейсе отвечают за параллельную обработку запросов?

Версия 0.4.0 внедряет continuous batching и позволяет задавать Max Concurrent Predictions; также упоминается Unified KV Cache для динамического распределения ресурсов между запросами.

Какие выводы в статье сделаны о том, как размер модели влияет на масштабируемость и где появляется «стена» батчинга при росте числа пользователей?

Автор описывает, что малые модели (0.6–2B) масштабируются лучше, модели 3–8B выходят на плато при полной загрузке GPU, а 9–20B дают минимальный прирост от параллелизма.

Что в тексте говорится о запуске на CPU и в каких случаях, по описанию автора, батчинг на CPU всё же может быть полезен?

В статье приведён пример, где CPU сильно уступает GPU по TPS. При этом отмечено, что для задач без требований к реальному времени батчинг на CPU может почти в 4 раза ускорять обработку без заметной потери на поток.

PubMag