• Релиз 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, после которой подразумевается подбор компромисса между общей пропускной способностью и скоростью реакции на запрос.