- Недавние измерения Red Hat выявили критические различия в производительности крупномасштабных языковых моделей (LLM) при использовании различных методов балансировки нагрузки, несмотря на схожие...
- Ключевым фактором, объясняющим эту разницу, является KV-cache.
- Этот анализ особенно актуален для инженеров, развертывающих self-hosted LLM-инференс в Kubernetes на нескольких GPU, а также для владельцев платформ, оценивающих нагрузку на...
Влияние балансировки на производительность LLM-инференса
Недавние измерения Red Hat выявили критические различия в производительности крупномасштабных языковых моделей (LLM) при использовании различных методов балансировки нагрузки, несмотря на схожие показатели запросов в секунду (RPS). Исследование показало, что хотя обычный алгоритм round-robin и маршрутизация с учетом префиксов демонстрируют почти идентичные значения RPS (0,52 и 0,49 соответственно), медианное время до первого токена (p95 TTFT) значительно отличается. У round-robin этот показатель составил 745 мс, что в 2,7 раза хуже, чем 272 мс у маршрутизации с учетом префиксов.
KV-cache и эффективность маршрутизации
Ключевым фактором, объясняющим эту разницу, является KV-cache. В условиях, когда GPU, модель и общая нагрузка были идентичны, менялся лишь способ выбора реплики. Стандартный счетчик RPS не отражает внутреннюю работу, которую под выполняет для каждого запроса. Если запрос попадает на реплику, где необходимый префикс уже находится в KV-cache, модель может начать генерацию токенов значительно быстрее. Однако, если тот же запрос направляется на соседнюю реплику без предварительно кэшированного состояния, ей приходится заново вычислять всю начальную часть запроса, что приводит к существенным задержкам.
Применимость и инфраструктурные аспекты
Этот анализ особенно актуален для инженеров, развертывающих self-hosted LLM-инференс в Kubernetes на нескольких GPU, а также для владельцев платформ, оценивающих нагрузку на основе загрузки карт и количества запросов. Для систем с одной репликой проблема маршрутизации не возникает, но при масштабировании она становится критичной. Все представленные примеры основаны на публичных замерах различных команд, с акцентом на инфраструктурное влияние маршрутизации на использование GPU, задержки и требования к Kubernetes-контуру. VK Tech предлагает GPU-ноды и vGPU для развертывания подобных высокопроизводительных систем.
Интересно, но статья фокусируется на идеальных условиях. На практике, поддержание актуального KV-cache для каждого префикса при динамической нагрузке и частых изменениях запросов может оказаться значительно сложнее и ресурсозатратнее, чем кажется. Неясно, насколько это решение масштабируемо в реальных продакшн-средах, где префиксы не всегда стабильны, а их разнообразие огромно. Есть ли риск, что накладные расходы на управление кэшем сведут на нет выгоду?