Глава 12 — Дизагрегированный serving и Kubernetes
Двенадцатый пост поглавного разбора LLM Primer VI: Scaling AI Systems. Глава, наконец разделяющая prefill и decode на разные GPU-пулы и показывающая примитивы Kubernetes, удерживающие поды на нужной стороне интерконнекта.
Зачем эта глава существует
Глава 11 провела чистую линию между движками и платформами — до тех пор, пока сам движок не указывает, что prefill и decode — противоречивые нагрузки. Prefill ограничен вычислениями; decode ограничен пропускной способностью памяти. Запуск их на одном GPU вынуждает одно железо быть хорошим в двух противоречивых вещах, и оно оказывается посредственным в обоих. Дизагрегированный serving разделяет их на разные GPU-пулы, гоняет KV-кэш между пулами и позволяет каждому пулу быть настроенным под свою нагрузку. Цена — операционная сложность, оплачиваемая примитивами Kubernetes, топологией подов и сетевой фабрикой, несущей KV-трафик. Глава 12 обходит форму этой сложности — компоненты, путь передачи и CRD (LeaderWorkerSet, PodCliqueSet от Grove, KAI Scheduler), выражающие её.
12.1 Prefill и decode хотят разные чипы на разных частотах
На том же H100 длинный prefill действительно может дойти до 60–80 процентов пиковых FLOP, а шаг decode использует 5–15 процентов FLOP при насыщении 70–90 процентов пропускной HBM. Их чередование под continuous batching — рабочий компромисс, но течёт двумя способами. Вычислительный проход prefill бьёт по той же HBM-шине, по которой очередные decode-шаги пытаются стримить, и время между токенами раздувается. Карта также работает на одной операционной точке: настроил под prefill — decode ограничен пропускной; настроил под decode — prefill ограничен вычислениями. Промпты удлинились с сотен до тысяч токенов, поскольку RAG и агенты заняли продакшен-трафик, и цена чередования выросла вместе с ними. Дизагрегация даёт каждой фазе свой пул. Prefill-воркеры могут работать на картах чистых FLOP (H100 SXM, B200). Decode-воркеры могут работать на картах ёмкости-и-пропускной (H200, MI300X). Каждый пул размерен под свою нагрузку — трафик с длинным контекстом и коротким выводом требует больше prefill; чат-трафик требует больше decode.
12.2 Форма — четыре компонента плюс путь передачи KV
Рабочее дизагрегированное развёртывание имеет четыре компонента. Prefill-воркеры принимают запрос, вычисляют prefill, выдают первый токен и подготавливают KV-кэш к передаче. Decode-воркеры принимают приходящий KV-кэш и его метаданные, встраивают его в свой paged-attention-пул и гоняют continuous batching над своими in-flight-генерациями. Роутер KV-кэша — плоскость управления — держит представление о свободной ёмкости KV каждого decode-воркера, наполненности батча и сетевой локальности и назначает каждый выход prefill так, чтобы минимизировать стоимость передачи и сбалансировать нагрузку. Фронтенд-шлюз терминирует HTTP-соединение пользователя, стримит первый токен от prefill-воркера, затем прозрачно переключается на стриминг остального от decode-воркера. Критическое ограничение — передача KV: 70B GQA-последовательность на 4 096 токенов — это 1,5–2 ГБ, и она должна пройти от prefill-узла к decode-узлу в пределах того же 50–100 мс TTFT-бюджета, который смотрит пользователь. NVLink со скоростью 900 ГБ/с внутри узла и InfiniBand со скоростью 400 Гбит/с между узлами делают числа рабочими — если поды приземляются на нужной стороне фабрики.
12.3 LeaderWorkerSet, Grove и KAI выражают топологию
У Kubernetes изначально не было примитива для «эти два типизированных пода — одна логическая реплика». LeaderWorkerSet, добавленный в апстрим в 2024 году, выражает мульти-подовую реплику с лидером (скажем, prefill) и работниками (скажем, decode); контроллер держит группу как одну единицу планирования. PodCliqueSet от NVIDIA Grove (2025, часть NVIDIA AI Enterprise) обобщает дальше типизированными кликами (prefill, decode, роутер), каждая со своим шаблоном и размером, плюс описанием топологии клик, как они связаны. Grove отправляет весь набор планировщику вместе с внутри-клик и меж-клик ограничениями локальности. Ни один CRD не достаточен сам по себе; оба нуждаются в планировщике, знающем физическую топологию кластера, чего дефолтный планировщик Kubernetes не делает. KAI Scheduler — открытый исходник от Run:ai в 2024 году — потребляет граф топологии, произведённый nvidia-smi topo --matrix и менеджером подсети InfiniBand, и оценивает кандидатов размещения относительно него. Когда клика Grove запрашивает nvlinkDomain: required, KAI ограничивает размещение одним NVLink-когерентным доменом (восемь GPU на одной HGX-плате на одном NVSwitch). Когда меж-клик топология говорит sameInfiniBandIsland, KAI держит клики внутри одной группы leaf-свитчей, где KV-round-trip остаётся ниже 100 мкс.
Что подготавливает глава 12
Глава 12 дала развёртыванию статичную картину: в любой момент фиксированное число клик работает и обслуживает трафик. Реальный трафик не статичен — чат-ассистенты качаются 30× пик-к-впадине через день, инструменты разработчиков падают до нуля на выходных, потребительские продукты гонятся за солнцем. Глава 13 обходит историю автоскейлинга: почему стандартный HPA — не тот скейлер для serving-а LLM, на какие сигналы KEDA скейлит вместо него, как Knative выражает scale-to-zero и что сжимает 60–180-секундный холодный старт в нечто, что пользовательское приложение может абсорбировать.
Дальше — Глава 13: Автоскейлинг и смягчение холодного старта. KEDA, Knative, CRIU, кэширование CUDA-графов, NVMe — стек, позволяющий scale-to-zero сосуществовать с реальными пользователями.
