С ростом продакшен-нагрузок LLM становится ясно: классические механизмы Kubernetes не понимают природу inference. llm-d — это попытка закрыть этот разрыв на уровне платформы.
Главное ограничение проявляется, когда inference выходит за пределы «статeless HTTP-сервиса». Запросы к LLM имеют разную стоимость: длина prompt, фаза генерации, попадание в KV-кэш. В Kubernetes это всё выглядит как одинаковые запросы. В результате — неудачное размещение подов, разрушение локальности кэша и скачущая latency под нагрузкой. Особенно это заметно в multi-tenant сценариях, где эффективность зависит от переиспользования контекста. Базовые механизмы autoscaling и service routing здесь слепы к состоянию inference.
llm-d предлагает рассматривать distributed inference как first-class workload. Ключевая идея — связать уровень оркестрации (Kubernetes) с семантикой inference. Проект встраивается между control plane (например, KServe) и движками вроде vLLM, добавляя state-aware маршрутизацию и управление кэшем. Trade-off очевиден: усложнение платформы и появление нового уровня абстракции, но взамен — контроль над ключевыми метриками inference и отказ от «черных ящиков» в продакшене.
Реализация строится вокруг нескольких принципов. Во-первых, иерархическое управление KV-кэшем с возможностью offload между GPU, CPU и storage — это позволяет балансировать между скоростью и стоимостью. Во-вторых, маршрутизация с учетом модели и состояния: запрос направляется туда, где уже есть нужный контекст или подходящее железо. В-третьих, disaggregated serving — разделение ролей (например, leader/worker через LWS), что упрощает масштабирование и управление ресурсами. Отдельный акцент — на hardware-agnostic подходе: система должна одинаково работать с NVIDIA, AMD, TPU и другими ускорителями. Это снижает vendor lock-in, но требует аккуратной абстракции над различиями в производительности и памяти.
Практические результаты показывают, где именно появляется выигрыш. В сценарии multi-tenant SaaS с prefix caching llm-d удерживает почти нулевой Time To First Token при росте нагрузки, тогда как стандартный Kubernetes-сервис быстро деградирует. Пропускная способность достигает порядка 120k токенов в секунду на кластере (8×vLLM, 16×H100), при этом сохраняется предсказуемость latency. Важный момент — проект делает ставку на воспроизводимые бенчмарки, а не маркетинговые цифры, что для AI-инфраструктуры пока редкость.
Включение llm-d в CNCF Sandbox — это не столько про статус, сколько про попытку стандартизировать слой, которого до сих пор не хватало: state-aware оркестрацию inference. Если подход приживется, Kubernetes начнет воспринимать LLM-нагрузки не как исключение, а как норму.