#облако — Public Fediverse posts

RPS одинаковый, но p95 по TTFT хуже в 2,7 раза: что round-robin делает с KV-cache

В замере Red Hat два балансировщика распределяли один и тот же чат-трафик между четырьмя GPU NVIDIA L4. По числу обработанных запросов в секунду результаты почти совпали: 0,52 у обычного round-robin и 0,49 у маршрутизации с учётом префиксов. Но p95 времени до первого токена различался в 2,7 раза: 745 мс у round-robin против 272 мс у prefix-aware routing. GPU, модель и нагрузка в обоих прогонах были одинаковыми, менялся только способ выбора реплики. Счётчик RPS этого не показывает: он учитывает обращения, но не работу, которую под выполняет для конкретного запроса. Если нужный префикс уже лежит в KV-cache, модель начинает генерацию быстрее. Если запрос попадает в соседнюю реплику без этого состояния, ей приходится заново считать всю голову запроса. Этот разбор посвящён выбору реплики для self-hosted LLM-инференса в Kubernetes. Он пригодится инженерам, которые запускают модели на нескольких GPU, и владельцам платформ, оценивающим нагрузку по загрузке карт и числу запросов. Для контуров с одной репликой вопрос маршрутизации не возникает; порог применимости разобран отдельно. Все примеры основаны на публичных замерах разных команд. Я рассматриваю задачу со стороны инфраструктуры: как маршрутизация влияет на использование GPU, задержки и требования к Kubernetes-контуру. VK Tech предоставляет GPU-ноды и vGPU для развёртывания таких систем.

https://habr.com/ru/companies/vktech/articles/1082026/

#vk_cloud #kubernetes #облако #vk_tech #LLMинференс #KVcache #маршрутизация_запросов #prefixaware_routing #GPU #vLLM

Kubernetes 1.37: gang scheduling появился в ядре, но включать его придётся вручную

28 августа Tech Times вынес в заголовок сразу две новости: бету gang scheduling в Kubernetes 1.37 и «экономию на простое GPU по умолчанию» . За день этот заголовок разошёлся по лентам. Через одиннадцать дней авторы функции написали в блоге проекта : «Все перечисленные здесь бета- и альфа-функции по умолчанию выключены; их нужно включать вручную». В этом расхождении между заголовком и первоисточником — вся суть релиза. Группу подов впервые описали в 2018 году и тогда же решили реализовать вне ядра Kubernetes. Следующие восемь лет функцию развивали Volcano, YuniKorn, Kueue и отдельные плагины. В Kubernetes 1.37 групповое размещение стало бетой в kube-scheduler, но по умолчанию оно выключено. Некоторые обзоры называют бету включённой. Из этого легко сделать вывод, что внешний планировщик больше не нужен. Но KEP передаёт ядру только размещение группы. Очереди и квоты по-прежнему остаются задачей Kueue и Volcano — это прямо указано в документе. Инженерам здесь пригодится разбор работы кластера с GPU и внешним планировщиком. Администраторам платформы — список feature gates, которые нужно открыть пользователям. Руководителям — критерии, по которым можно решить, стоит ли после обновления отказываться от Volcano. В каждом разделе указано, для кого он предназначен.

https://habr.com/ru/companies/vktech/articles/1082028/

#vk_cloud #gang_scheduling #Kubernetes #облако #ядро #vk_tech