Ваш LLM-под перегружен, а Kubernetes считает, что всё в порядке.

Kubernetes может идеально маршрутизировать трафик и при этом отправлять запрос LLM в ужасное место. Причина проста: работоспособные реплики LLM не всегда одинаковы. У одного Pod может быть длинная очередь. Другой может быть почти бездействующим. А у третьего уже может быть полезное состояние KV-кэша для запроса. В этом видео я разбираю, почему обычная маршрутизация сервисов Kubernetes начинает давать сбои при выводе LLM, как давление в очереди и локальность кэша влияют на решение о маршрутизации, и почему это начинает больше походить на планирование, чем на традиционную балансировку нагрузки. Мы рассмотрим: • Что Kubernetes на самом деле знает о своих конечных точках • Почему идентичные реплики LLM могут иметь очень разное внутреннее состояние • Как глубина очереди влияет на задержку • Почему кэш KV меняет оптимальное решение по маршрутизации • Как локальность кэша может создавать «горячие точки» • Что бы я проверил при устранении неполадок, связанных с медленным выводом LLM в производственной среде • Как работает маршрутизация с учетом вывода • Расширение вывода API Kubernetes Gateway • Концепции маршрутизации vLLM и llm-d • Проблемы с пропускной способностью против проблем с размещением Главный вывод: Готовность пода не означает, что это лучшее место для следующего запроса на вывод. Для рабочих нагрузок LLM маршрутизация должна понимать больше, чем просто состояние конечных точек. РАЗДЕЛЫ 0:00 Почему работоспособные LLM-поды не одинаковы 0:45 Обычная ментальная модель Kubernetes 2:05 Та же модель, другое состояние 3:45 Проблема очереди 4:40 KV-кэш меняет решение 6:00 Когда локальность кэша создает горячую точку 7:10 Устранение неполадок в производственной среде 9:45 Маршрутизация с учетом вывода 11:00 Компромисс 12:00 Выводы для инженеров Больше информации о производственной инфраструктуре, Linux, Kubernetes, SRE, DevOps и инфраструктуре ИИ: ctrlchaos.io #Kubernetes #LLM #AIInfrastructure #SRE #DevOps