Процесс вывода большой языковой модели естественным образом распадается на две принципиально разные фазы: prefill и decode. Разделив их физически, можно одновременно оптимизировать время до первого токена (TTFT) и время на один выходной токен (TPOT) — то, что в монолитной архитектуре недостижимо. Эта глава — систематический разбор того, как проектировать, эксплуатировать и масштабировать разделённый prefill/decode инференс на масштабе ультрабольших кластеров.

IВведение и исторический контекст

Процесс вывода LLM распадается на два этапа. Prefill принимает входной запрос целиком и формирует KV-кэш для всей последовательности. Decode порождает выходные токены по одному (или небольшими группами при спекулятивном декодировании), опираясь на уже сформированный KV-кэш.

Эти фазы обладают диаметрально противоположными профилями производительности. Prefill — вычислительно тяжёлая операция с интенсивной работой тензорных ядер; она ограничена FLOPS. Decode — ограничен пропускной способностью памяти: для каждого нового токена приходится перечитывать огромный KV-кэш и дописывать в него новые значения. Проще говоря, prefill — высокопараллельная задача с упором на пропускную способность, тогда как decode — последовательный процесс, критичный к задержкам.

Первые системы обслуживания LLM обрабатывали обе фазы в едином конвейере на одном оборудовании. Такой подход отдавал приоритет prefill, поскольку позволял максимизировать пропускную способность за счёт батчинга. Однако с ростом популярности интерактивных приложений на первый план вышли TTFT и TPOT. Обеспечить одновременную оптимизацию обоих в едином движке на одном GPU крайне затруднительно.

Понимание того, что prefill и decode имеют разные ресурсные профили, возникло не одномоментно. Уже в 2023 году практика непрерывного батчирования, популяризированная системой Orca и затем vLLM, показала: совмещение фаз на одном GPU создаёт «пузыри» — decode-последовательности простаивают, пока GPU обрабатывает тяжёлый prefill. Первые экспериментальные системы — Splitwise (Microsoft Research, 2024) и DistServe (2024) — независимо показали, что физическое разделение фаз на разные пулы GPU даёт двукратное и более улучшение goodput при тех же SLO. К 2025 году практически все крупные фреймворки — vLLM, SGLang, TensorRT-LLM, NVIDIA Dynamo — встроили поддержку disaggregated prefill/decode как первоклассную возможность. К 2026 году подход стал стандартом де-факто для инференса в масштабе сотен тысяч GPU.

Разделение фаз означает закрепление каждой фазы за специализированными ресурсами, оптимизированными под её нужды. DistServe показала потенциал обслуживания в 7,4 раза большего числа запросов в рамках строгих SLO по задержке по сравнению с монолитным решением. С тех пор промышленные фреймворки начали массово внедрять отдельные серверы для prefill и decode.

Открытая библиотека vLLM внедрила поддержку раздельного режима совместно с LMCache. NVIDIA Dynamo реализует disaggregated prefill и decode с динамической маршрутизацией и автомасштабированием. По сообщениям, масштабные сервисные системы OpenAI, Meta и xAI используют этот подход для соблюдения жёстких SLO по задержке. В ультрамасштабных развёртываниях речь может идти о сотнях тысяч или даже миллионах GPU, обслуживающих миллиарды запросов. В таких условиях выгода от разделения становится колоссальной.

IIЗачем разделять prefill и decode

Современные интерактивные сервисы на базе LLM зачастую ставят целью обеспечить задержку TTFT < 200–300 мс на уровне p99. Без разделения prefill-вычислений гарантировать это практически невозможно.

Рассмотрим сценарий: один пользователь отправляет запрос с чрезвычайно длинным промптом в несколько тысяч токенов, другой — с очень коротким. Без разделения, если эти запросы приходят одновременно, вычисление prefill для длинного промпта надолго займёт GPU. Второму запросу придётся ждать неоправданно долго, прежде чем начнётся его декодирование. Это явление называется интерференцией: работа по prefill одного запроса задерживает декодирование другого.

При простой стратегии FIFO длинные промпты усиливают хвостовую задержку для всех. Тяжёлые prefill-задачи в начале очереди блокируют более лёгкие запросы позади — это блокировка начала очереди (head-of-line blocking), ведущая к низкой утилизации, выбросам задержки и недовольству пользователей.

В разделённой архитектуре можно направить prefill большого промпта в выделенный пул вычислительно-оптимизированных prefill-воркеров, а prefill лёгкого промпта — напрямую декодерам. Такая гибкость не даёт коротким запросам страдать от head-of-line blocking.

IIIКоличественная оценка интерференции

В монолитной системе, обслуживающей модель Llama-3.1-70B на одном H100 SXM5, типичное время prefill для промпта из 2048 токенов — около 150–250 мс. За это время все decode-потоки на этом GPU замораживаются. Если одновременно в батче 32 активные decode-последовательности с целевым TPOT 20 мс, каждая получает «паузу» до 250 мс — задержку в 12,5 раз больше целевой. В p99 это всплеск с 20 мс до 250+ мс, что нарушает SLO для подавляющего большинства активных запросов.

В разделённой системе тот же prefill выполняется на выделенном GPU, не затрагивая decode-пул. TPOT активных последовательностей остаётся стабильным — единственная добавка — время передачи KV-кэша от prefill-воркера к decode-воркеру.

Здесь SLO установлен на уровне 0,4 с для P90 TTFT и 0,04 с для P90 TPOT. Совмещённая система способна поддерживать лишь около 3 RPS полезной пропускной способности в границах TTFT и только 1,6 RPS в границах TPOT. Goodput совмещённой конфигурации — 1,6 RPS. После разделения (2 prefill + 1 decode) prefill-воркеры дают ~5,6 RPS, decode — ~10 RPS. Goodput конфигурации 2P1D — 3,3 RPS на GPU — двукратный рост.

Устранение интерференции не только улучшает средние задержки, но и сжимает хвосты. Эмпирически разделённые системы демонстрируют более плотное распределение задержек и избегают длинных хвостов, характерных для монолитных систем.

IVПулы prefill- и decode-воркеров

В разделённом развёртывании поддерживаются два (или более) пула воркеров: один набор GPU выделен под обработку промптов (prefill), другой — под генерацию токенов (decode). Эти воркеры могут располагаться на отдельных узлах или стойках — или даже в разных дата-центрах, если пропускная способность межсоединений достаточна.

Пулы общаются по сети для передачи KV-кэша, сформированного prefill-воркером, тому GPU, который будет выполнять декодирование. Этой коммуникацией управляет планировщик, или маршрутизатор.

Обычно эти две группы воркеров взаимодействуют через высокоскоростные межсоединения (NVLink/NVSwitch и InfiniBand) и zero-copy передачи GPU-to-GPU с использованием RDMA. На практике такие передачи задействуют GPUDirect RDMA или UCX. Для NVL-фабрик на базе суперчипов (Grace-Blackwell, Vera-Rubin) используют NVIDIA Multi-Node NVLink (MNNVL), держат NVLink-first коллективы включёнными для TP-декодирования и включают SHARP для коллективов AllGather и ReduceScatter.

Когда система получает новый запрос, обычно он принимается на decode-воркере. Это decode-центричный дизайн. Он предпочтителен, поскольку prefill-воркеры уже загружены вычислениями KV. Перекладывая на decode-воркеры клиентский ввод-вывод, маршрутизацию и управление состоянием сессии, система избегает перегрузки prefill-воркеров.

Ниже приведён фрагмент упрощённой конфигурации кластера NVIDIA Dynamo, определяющей две роли, использующие NVIDIA Inference Xfer Library (NIXL) для передачи KV-кэша через GPUDirect RDMA:

roles:
  - name: prefill_worker
    model_path: models/llm-70b
    instance_count: 4
    gpu_type: B200
  - name: decode_worker
    model_path: models/llm-70b
    instance_count: 8
    gpu_type: B300

NVIDIA Rubin CPX (CP = context processing) специально спроектирован под вычислительно-тяжёлые задачи — такие как prefill. Он знаменует отход NVIDIA от универсальных ускорителей к специализированным чипам, оптимизированным под конкретную фазу AI-нагрузки.

Внутри, когда система работает, каждый decode-воркер регистрирует область GPU-памяти, чтобы prefill-воркеры могли писать в неё напрямую через RDMA. Метаданные регистрации обмениваются при старте или первом контакте — так, для каждой удалённой prefill-задачи достаточно передать лишь небольшой идентификатор.

Dynamo использует etcd для обнаружения воркеров и аренды. Воркеры регистрируют дескрипторы памяти в роутере, чтобы пиры могли получить их при необходимости. Так prefill-запрос может содержать лишь ID целевого KV-буфера.

VПередача KV-кэша

Критический вопрос: сколько фактически времени занимает передача KV-кэша между prefill- и decode-воркерами? Без этих чисел невозможно осознанно выбрать порог PREFILL_LENGTH_THRESHOLD, при котором передача становится выгодной.

Размер KV-кэша для одного запроса вычисляется по формуле:

KV_размер = 2 × n_layers × n_kv_heads × head_dim
           × bytes_per_element × n_tokens

Для DeepSeek-R1 с MLA размер KV-кэша определяется латентным представлением: 61 слой × (512 латент + 64 RoPE) × 1 байт ≈ 35 КБ/токен. Даже в FP16 это ~68,6 КБ/токен — примерно в 40 раз меньше, чем у Llama-70B с GQA.

Время передачи зависит от доступной пропускной способности сети:

Для Llama-3.1-70B в FP8 и промпта из 1024 токенов (KV ~160 МБ) передача через InfiniBand RDMA занимает 3–6 мс. Через TCP — около 170 мс. Эмпирические данные из продакшена подтверждают: на AWS p5.48xlarge для Llama-3.1-8B при длине входа 8000 токенов накладные расходы на передачу KV — всего ~37 мс, при том что disaggregated режим дал 41% ускорение на токен и 22% рост пропускной способности.

Сравнение движков передачи KV-кэша

Бенчмарки на AMD MI300X (400 Гбит/с NIC) показали следующие результаты для передачи 1 ГБ данных:

NIXL и UCCL P2P достигают наилучших результатов для типичных размеров KV-кэша (256 КБ – 1 МБ), поскольку не расходуют GPU SM на передачу — данные идут напрямую через GPUDirect RDMA.

VIПроектирование prefill-воркеров

Prefill-воркеры — вычислительные узлы, предназначенные для выполнения начальной фазы. Поскольку prefill-нагрузка вычислительно интенсивна, prefill-узлы должны использовать GPU с высокой вычислительной мощностью и быть оптимизированы под крупные матричные умножения.

Управление памятью

Prefill заполняет память GPU параметрами модели и рабочими активациями прямого прохода с входными токенами промпта. Как только KV-кэш создан, он немедленно отправляется decode-воркерам. KV-кэш не задерживается надолго в памяти prefill-узла. Некоторые фреймворки предварительно резервируют большой блок GPU-памяти под prefill как рабочее пространство — это снижает фрагментацию и время на выделение буферов.

Оптимизация под задержку или пропускную способность

При настройке разделённого prefill-кластера возникает фундаментальный компромисс между минимизацией TTFT для каждого отдельного промпта и максимизацией общего RPS.

Подход «сначала задержка». Чтобы сократить TTFT, prefill-узлы обрабатывают промпты сразу по мере поступления — с минимальным батчированием или без него. Недостаток — более низкая утилизация GPU. Можно либо избыточно зарезервировать ёмкость, либо использовать размер батча, равный 1.

Подход «сначала пропускная способность». Объединение промптов в крупные батчи (8–32) повышает арифметическую интенсивность и загружает вычислительные блоки. Недостаток — каждый запрос несёт задержку батчирования, равную времени сбора батча.

Многие inference-движки отдают предпочтение задержке для prefill-воркеров: быстрый первый токен значительно улучшает UX. Обычно для prefill-кластера резервируют больше ёмкости, чем нужно для средней нагрузки — так он поглощает всплески промптов без скачков задержки.

Планирование и батчирование с учётом задержек

Разделённые системы применяют политики планирования с учётом задержек: гарантируют выполнение одиночного запроса, пока нагрузка не станет достаточно высокой, применяют адаптивные окна батчирования (при низкой нагрузке — батч 1, при высокой — микробатчи 2–10 мс), используют очереди приоритетов для коротких промптов. NVIDIA Dynamo поддерживает классы задержки в планировании.

VIIПроектирование decode-воркеров

Decode-воркеры предназначены для авторегрессионной фазы декодирования. Как только KV-кэш промпта готов, он передаётся decode-воркеру, который использует его для генерации оставшихся выходных токенов как можно быстрее, чтобы поддерживать низкую задержку TPOT.

Если запрос изначально направляется decode-воркеру, он решает, выполнять prefill локально или удалённо. Prefill-воркер непрерывно забирает задачи из очереди prefill, читает KV-блоки из prefix-кэша и выполняет prefill. Затем записывает KV-блоки обратно decode-воркеру.

Непрерывное батчирование

Decode-серверы активно полагаются на непрерывное батчирование. В отличие от prefill-фазы, выполняющей крупные матрично-матричные вычисления, фаза декодирования выполняет множество малых вычислений. Чтобы избежать низкой утилизации GPU, decode-воркеры объединяют несколько входных последовательностей, формируя более крупные матрично-матричные вычисления на каждой итерации.

Например, если 32 различных запроса готовы сгенерировать следующий токен, планировщик непрерывного батчирования выполнит один прямой проход, генерирующий 32 токена параллельно. Так матричные умножения получают эффективный размер батча 32.

Непрерывное батчирование гарантирует, что decode-GPU-воркеры не простаивают. Они всегда работают над доступными запросами. При высокой нагрузке оно эффективно, при низкой — отзывчиво. Это хороший баланс между высокой пропускной способностью и низкой задержкой.

Группировка последовательностей переменной длины

Обработка последовательностей переменной длины требует тщательного планирования. Смешивание коротких и длинных промптов в одном батче ведёт к накладным расходам на padding — иногда до 50% от числа токенов. Решение — группировать запросы в корзины по длине последовательности. Более продвинутый подход — Flash Attention с интерфейсом переменной длины (varlen), упаковывающий все последовательности в один непрерывный тензор с метаданными кумулятивных длин. Это полностью устраняет padding (экономия до 63%) и сокращает число запусков ядер с N до 1 на каждый слой внимания.

NVIDIA Programmatic Dependent Launch (PDL) и device-initiated CUDA Graph Launch используются для снижения накладных расходов на запуск на каждом токене, перекрытия работы и устранения пузырей между итерациями декодирования.

Управление памятью под KV-кэш

Поскольку декодирование включает внимание ко всей последовательности, память под KV-кэш — критичный ресурс для decode-воркеров. Для больших моделей и длинных последовательностей память KV растёт линейно с числом токенов.

Практическая оценка: байт_на_токен = 2 × n_layers × n_kv_heads × head_dim × байт_на_элемент.

Для модели класса Llama 13B с 40 слоями, 40 головами внимания и FP16 при контексте 4096 токенов со стандартным MHA размер KV составляет ~0,819 МБ/токен или ~3,36 ГБ всего. При KV в FP8 — ~1,68 ГБ. При GQA с 8 группами запросов — ~0,671 ГБ в FP16 и ~0,336 ГБ в FP8. Для MQA с 1 KV-головой — ~0,084 ГБ в FP16.

Paged GPU memory allocator. Механизм PagedAttention в vLLM разбивает KV-кэш на страницы фиксированного размера и может выгружать неактивные страницы в память CPU. Менеджеры paged KV-памяти реализованы в SGLang, TensorRT-LLM, NVIDIA Dynamo.

Выгрузка KV-кэша. Когда GPU-память заполняется, decode-воркеры могут выгружать более старые KV-блоки в CPU DRAM или NVMe. NVIDIA Dynamo реализует многоуровневое управление через KV Block Manager (KVBM). В сценарии с 20 многоходовыми диалогами и 15 пользователями KVBM с выгрузкой в CPU-память дал улучшение TTFT в 2,2–12 раз.

Иерархия памяти в разделённой архитектуре

GPU-память decode-кластера полностью посвящена хранению весов модели и KV-кэша. Она не пытается обрабатывать крупные вычисления prefill промптов. Разделение не устраняет проблемы памяти KV, но позволяет выбирать типы decode-узлов, оптимизированные под ёмкость памяти и пропускную способность.

VIIIМаршрутизация и планирование

Не каждый запрос нужно передавать prefill-воркеру. Разделённая система использует политику маршрутизации, чтобы условно использовать удалённый путь prefill только тогда, когда это вероятно поможет.

Факторы маршрутизации

Пример политики динамической маршрутизации

На практике политика маршрутизации реализуется как условная проверка. Ниже — упрощённая версия логики маршрутизации:

def should_offload_prefill(prompt_length: int,
                           prefix_cached_length: int,
                           prefill_queue_size: int,
                           decode_active_reqs: int,
                           ttft_slo_ms: int = 500) -> bool:
    eff_len = max(0, prompt_length - prefix_cached_length)

    PREFILL_LENGTH_THRESHOLD = 256
    PREFILL_QUEUE_MAX = 10
    DECODE_LOAD_THRESHOLD = 8

    long_prefill = (eff_len >= PREFILL_LENGTH_THRESHOLD)
    prefill_available = (prefill_queue_size < PREFILL_QUEUE_MAX)

    if long_prefill and prefill_available:
        return True

    if decode_active_reqs >= DECODE_LOAD_THRESHOLD and eff_len >= 64:
        return True

    return False

Пример конфигурации Dynamo Planner

В производственном развёртывании политику маршрутизации следует настраивать через файл. NVIDIA Dynamo позволяет задавать сложные правила маршрутизации и автомасштабирования в JSON или YAML:

model: ...
split_policy:
  prompt_length_threshold: 256
  prefix_cache_weight: 10.0
  queue_length_weight: 1.5
  decode_load_weight: 0.5
  enable_hotspot_prevention: true
cache:
  reuse_prefix: true
  min_cache_hit_ratio: 0.75
autoscale:
  prefill:
    min_replicas: 4
    max_replicas: 12
    scale_up:   { queue_length: 8,  gpu_utilization: 80 }
    scale_down: { queue_length: 2,  gpu_utilization: 40 }
  decode:
    min_replicas: 8
    max_replicas: 24
    scale_up:   { queue_length: 16, kv_cache_usage: 75 }
    scale_down: { queue_length: 4,  kv_cache_usage: 30 }
qos:
  enable_early_rejection: true
  low_priority_threshold_ms: 500
  reject_on_slo_violation: true

Маршрутизация с учётом ёмкости и задержек

Dynamo Planner использует метрики вроде TTFT, TPOT и оценённой стоимости передачи KV-кэша для решения об изменении маршрутизации — или даже о перераспределении GPU для конкретной фазы. При наплыве задач суммаризации Planner перераспределит больше GPU в фазу prefill. При наплыве reasoning-задач — в фазу decode.

KV-aware маршрутизация: результаты из продакшена

NVIDIA Dynamo сообщает 3-кратное улучшение TTFT и 2-кратное снижение средней задержки запроса при маршрутизации 100 000 реальных запросов к DeepSeek-R1 Distilled Llama 70B (FP8, 2 узла H100) с учётом KV-кэша по сравнению со случайной маршрутизацией. Проект llm-d на B200 сообщает о 3-кратном росте выходной пропускной способности и 2-кратном ускорении TTFT с prefix-cache-aware маршрутизацией.

IXМногопутевое спекулятивное декодирование

Спекулятивное декодирование может быть наложено поверх процесса принятия решений роутером. Система может обнаружить неопределённую ветвь спекулятивного декодирования и отправить несколько спекулятивных запросов разным decode-воркерам параллельно. Это обменивает дополнительные вычисления на более низкую задержку для генераций с непредсказуемыми ветвями.

Адаптивное спекулятивное декодирование. Система StreamServe (2026) объединила disaggregated prefill/decode с адаптивным спекулятивным декодированием, глубина которого настраивается онлайн на основе runtime-метрик. На бенчмарках StreamShow показал снижение задержки на 11–18% относительно tensor-parallel vLLM и прирост пропускной способности до 6,8% при стабильном TPOT. Взаимодействие между disaggregation, metric-aware routing и adaptive speculation даёт сверхаддитивный эффект.

В практическом плане спекулятивное декодирование через EAGLE-3 может давать до 6× ускорения на плотных моделях. Однако при constrained decoding (JSON mode, tool calls с грамматиками) acceptance rate часто резко падает, поскольку constraint mask инвалидирует спекулятивные токены. Это важно учитывать при планировании нагрузки в разделённом кластере.

XQoS и политики раннего отклонения

Политики QoS приоритизируют или ограничивают определённые запросы для соблюдения целей по задержке. Раннее отклонение, также называемое контролем допуска, может отказать в низкоприоритетных запросах, когда система насыщена. Так сохраняются ресурсы и SLO для других запросов.

Современные системы делают это на основе порога времени в очереди. Если запрос пробыл в очереди > X мс, возможно, лучше отклонить его, чем допустить серьёзное нарушение SLO. Такой QoS-барьер становится всё более распространённым для критически важных систем инференса.

В ультрамасштабных системах механизмы QoS необходимы для поддержания гарантий хвостовой задержки под тяжёлой нагрузкой. Вместо того чтобы позволить нарушение SLO для всех запросов, хорошо спроектированная система предпочтёт изящно сбросить нагрузку: отклонив или отложив низкоприоритетные запросы, когда ясно, что их обслуживание нарушит гарантии для других.

Контроль допуска

class QoSController:
    def __init__(self, ttft_slo_ms: int = 500):
        self.ttft_slo_ms = ttft_slo_ms

    def admit_request(self, priority: str) -> bool:
        est_ttft = (get_current_prefill_queue_length()
                    * get_avg_prefill_time_per_req()
                    + get_current_decode_queue_length()
                    * get_avg_decode_time_per_req())

        if est_ttft > self.ttft_slo_ms and priority == "low":
            return False
        return True

Адаптивные лимиты генерации. Если фаза decode угрожает затянуться слишком долго и вызвать нарушение SLO по TPOT, система может досрочно прервать генерацию. Если пользователь запросил 1000 токенов, но система под давлением, она может разрешить только 200 токенов, оставляя ресурсы для других запросов.

Изящная деградация. Одна из интересных форм — временное отключение удалённого prefill для низкоприоритетных запросов, когда система под нагрузкой. Низкоприоритетные запросы выполняют локальный prefill, освобождая prefill-воркеры для высокоприоритетных.

Отказоустойчивость и хвостовая задержка

По мере масштабирования систем до тысяч и миллионов GPU-узлов становится труднее контролировать хвостовую задержку. Изоляция prefill-задач на одном узле, а decode-задач на другом означает, что медленный узел с одной стороны не окажет резкого влияния на задачи с другой стороны. Кэширование больших частей контекста означает, что одна медленная операция не замедлит всю генерацию так сильно.

XIГетерогенные кластеры

Одно из самых мощных следствий disaggregation — возможность использовать разные типы GPU для prefill и decode, подбирая оборудование под ресурсный профиль каждой фазы.

Экономическое обоснование

Prefill — compute-bound: нужен максимум FP8/FP4 TFLOPS, ёмкость HBM не критична. Decode — memory-bound: нужна максимальная пропускная способность HBM, вычислительная мощность почти не используется. Это создаёт неэффективность: использовать H100 (стоимость ~$2,57/час за GPU) для decode — значит платить примерно в 3,6 раза больше за пропускную способность памяти, которая вам не нужна. L40S (стоимость ~$0,72/час) имеет достаточную пропускную способность HBM для decode моделей 70B и стоит в 3,5 раза дешевле.

Гетерогенная конфигурация 1 (H100 для prefill + L40S для decode) экономит 61% на почасовой стоимости и снижает цену за 1M токенов на 48% — при снижении пропускной способности на 25%. Для моделей до 70B это наиболее рентабельная пара. Для моделей 70B–405B лучше подходит связка B200 + A100 80G.

Когда гетерогенность оправдана

1. Модель крупная (32B+). Для моделей меньше 10B накладные расходы на передачу KV-кэша перевешивают выгоды.
2. Нагрузка несбалансированная. Преобладание длинных промптов или длинных ответов.
3. Доступны разные типы GPU. В облаке — разные инстанс-типы; в on-premise — смешанный парк.
4. RDMA-инфраструктура доступна. Без RDMA гетерогенность теряет смысл.

Архитектурные паттерны

«Вычислительный prefill + бюджетный decode» — prefill на H100/B200, decode на L40S/A100. Роутер Dynamo направляет prefill на вычислительный пул, KV-кэш передаётся через NIXL/RDMA на decode-пул.

«Перекрёстное перемешивание» (work stealing) — реализован в HeteroServe. Когда consumer-GPU простаивают, они временно забирают decode-задачи у других воркеров, восстанавливая простаивающую ёмкость.

«Спотовые GPU с on-demand fallback» — ShuntServe. Decode на дешёвых spot-инстансах, при отзыве — переключение на on-demand. DP-оптимизатор на основе roofline-модели находит оптимальное размещение слоёв. Достигается 1,42× более высокая пропускная способность на Llama-3.1-70B.

«GPU Combo» — Cauchy. Концептуальная «GPU-комбинация» выбирается для каждого типа нагрузки на основе cost-efficiency.

Перспективы: специализированные чипы

Работа DUET (2026) предлагает аппаратное разделение на уровне чипов: «Prefill Chips» с увеличенными систолическими массивами и GDDR7 вместо HBM, и «Decode Chips» с сохранением высокой пропускной способности, но сокращённой вычислительной мощности. Отчёты показывают: 8% выше prefill-производительность при 52% меньшей стоимости для Prefill Chips, и 97% decode-производительности при 28% меньшем TDP для Decode Chips — относительно смоделированных H100.

XIIРеальные бенчмарки

DistServe (прототип, 2024)

Базовый эксперимент показал: goodput совмещённой конфигурации — 1,6 RPS на GPU; разделённой 2P1D — 3,3 RPS на GPU (2,1× улучшение) при строгих SLO.

SGLang + DeepSeek-R1 (96× H100, 2025)

PD-дезагрегация с экспертным параллелизмом: 52,3k входных токенов/с на узел prefill (24 GPU), 22,3k выходных токенов/с на узел decode (72 GPU). На GB200 NVL72 — до 3,8× для prefill и 4,8× для decode по сравнению с H100-конфигурацией.

NVIDIA Dynamo (H100, 2025–2026)

• Одноузловой тест (Llama 70B, FP8, vLLM): 30% рост пропускной способности на GPU.
• Двухузловой тест: более 2× прирост.
• KV-aware маршрутизация (100k запросов, DeepSeek-R1 Distilled 70B): 3× TTFT, 2× средняя задержка.
• GTC 2026 (Dynamo 1.0 на GB200 NVL72 + wide EP): 7× пропускная способность.

llm-d (B200, 2025–2026)

• 3× выходная пропускная способность и 2× быстрее TTFT с prefix-cache-aware routing.
• До 70% больше токенов/с с P/D disaggregation vs стандартный vLLM.
• ~3,1k tok/s на B200 decode GPU (wide-EP).
• До 50k выходных tok/s на топологии 16×16 B200.
• 40% снижение задержки на выходной токен для DeepSeek V3.1 на H200.

AWS EFA + libfabric (H100, 2025)

Измеренные накладные расходы на передачу KV-кэша для Llama-3.1-8B (ISL=8000, OSL=50): всего 37 мс (TTFT: aggregated 173 мс vs disaggregated 210 мс). При этом disaggregated режим даёт 41% ускорение на токен и 22% рост пропускной способности.

XIIIПрактические рекомендации

• Оптимизируйте каждую фазу независимо. Prefill ограничен вычислениями и выигрывает от максимального параллелизма и высокой вычислительной мощности. Decode ограничен памятью и выигрывает от GPU с высокой пропускной способностью памяти и непрерывного батчирования.
• Используйте KV-кэш. Умный роутер решает, должен ли новый запрос быть передан prefill-воркеру или обработан локально. Политика должна учитывать длину промпта, попадания в кэш и загрузку кластера.
• Маршрутизируйте разумно. vLLM, SGLang и NVIDIA Dynamo используют многофакторный алгоритм оценки. Отслеживайте TTFT (p50/p95/p99) и ITL/TPOT (p50/p95/p99) отдельно для prefill- и decode-узлов.
• Используйте QoS для поддержания SLA при масштабе. Применяйте контроль допуска и приоритизацию под тяжёлой нагрузкой.
• Начинайте с агрегированного baseline. Прежде чем внедрять disaggregation, измерьте производительность монолитной конфигурации.
• Проверяйте RDMA. Без RDMA disaggregation практически неприменима. Перед запуском в продакшен валидируйте NIXL-бенчмарком.
• Рассмотрите гетерогенность для снижения затрат. Для моделей 32B+ с несбалансированной нагрузкой связка H100/B200 для prefill и L40S/A100 для decode может дать 30–60% экономии.

XIVБудущие направления

Дезагрегированная квантизация. Использование разных форматов квантизации для prefill (аппаратно-нативный NVFP4) и decode (weight-only 2–3 бита) с совместной оптимизацией весов. QADD показал прирост точности на decode-задачах при сохранении скорости prefill — до 1,49× ускорения над BF16 на Qwen3-8B и Gemma3-12B.

Адаптивное спекулятивное декодирование. Объединение disaggregation с онлайн-настройкой глубины спекуляции на основе runtime-метрик. StreamServe показал сверхаддитивный эффект от этого сочетания.

Специализированные чипы для фаз. Проекты вроде DUET предлагают чипы, спроектированные исключительно под prefill или decode, с разной архитектурой памяти и вычислительных блоков.

Дезагрегация для диффузионных LLM. Prefilling-dLLM расширяет disaggregation на диффузионные языковые модели, кэшируя chunked prefix KV один раз и переиспользуя его между шагами денойзинга. На LongBench и Infinitebench — ускорение 9,1–28,0× при контекстах 8K–32K.

Мультимодальная дезагрегация. Расширение на трёхфазную архитектуру: encode (визионный энкодер) → prefill (языковой prefill) → decode. NVIDIA Dynamo уже поддерживает disaggregated encode/prefill/decode с кэшем эмбеддингов — 30% быстрее TTFT на image-нагрузках.

XVЗаключение

Разделение prefill и decode стало обычной практикой в современном высокомасштабном LLM-инференсе. Практически все крупные AI-провайдеры — Meta, Amazon, NVIDIA, Google и OpenAI — в той или иной форме внедрили разделённую архитектуру в своих крупномасштабных развёртываниях LLM.

Хотя большинство этих компаний не публикуют свою полную производственную архитектуру, существует множество открытых реализаций — vLLM, SGLang, NVIDIA Dynamo, llm-d, LMCache, Mooncake — которые демонстрируют этот подход и его преимущества. Разделённый prefill-decode даёт более высокий goodput — полезную пропускную способность в рамках ограничений по задержке — и лучшую экономическую эффективность, чем монолитные дизайны.

Спустя 18 месяцев после выхода DistServe концепция эволюционировала от небольшого прототипа до фундаментальной техники, питающей практически каждый современный inference-движок.