Почему ваши GPU простаивают 80% времени (и вы платите за это)
Запускаете Llama 4 70B или Gemini Ultra 2 на кластере из восьми H100? Проверьте мониторинг. Уверен, график утилизации GPU напоминает кардиограмму пациента в коме - редкие пики до 90%, а потом долгое плато на 10-15%. Это не баг. Это фундаментальная архитектурная дыра в инференсе больших языковых моделей.
Каждый запрос к LLM делится на две абсолютно разные фазы.
- Prefill (или context encoding): Молниеносный, взрывной штурм. Система загружает весь ваш промпт (допустим, 2000 токенов) и параллельно вычисляет ключи и значения (KV-cache) для каждого слоя модели. Это задача compute-bound. Ей нужны teraflops, тысячи ядер, максимальная загрузка тензорных ядер. Длится миллисекунды.
- Decode (или token generation): Медленный, последовательный марш. Модель генерирует ответ токен за токеном. На каждом шаге она обращается к гигантскому KV-cache (который занял полвидеопамяти) и выполняет относительно скромные вычисления. Это задача memory-bound. Ей нужна низкая латентность до памяти, высокая пропускная способность шины и... терпение. Длится секунды.
И вот проблема. Вы закупаете универсальные GPU за $30k штука. Они отлично справляются с prefill. А потом, во время decode, их мощные вычислительные блоки скучают, простаивают в ожидании данных из памяти. Вы платите за Ferrari, а 80% времени она едет как городская легковушка в пробке.
Disaggregated inference: когда одна задача - два типа железа
Решение родилось не в академических статьях, а в финансовых отчетах Perplexity и Meta. Когда счет за облачные GPU переваливает за миллион в месяц, начинаешь думать иначе.
Идея гениальна в своей простоте. Разделим фазы инференса на разные физические кластеры GPU.
- Prefill-кластер: Небольшой пул мощных GPU с быстрым межсоединением (NVLink, Infinity Fabric). Их задача - быстро сожрать промпт, вычислить KV-cache и отправить его по сети. После этого они сразу свободны для следующего промпта.
- Decode-кластер: Большой пул более дешевых, memory-оптимизированных GPU (или даже специализированных accelerators). Их задача - принимать готовый KV-cache и быстро, с минимальной задержкой, генерировать токены.
Это не горизонтальное масштабирование. Это вертикальное разделение труда. Как на конвейере: один цех штампует детали (prefill), другой собирает из них машины (decode).
| Компания/Проект | Реализация | Экономия (оценка на 2026) |
|---|---|---|
| Perplexity (по данным инсайдов) | Кастомный сервинг на базе модифицированного vLLM. Prefill на H100, decode на A100 40GB. | До 40% снижения TCO (Total Cost of Ownership) |
| Meta (система Project Aria) | Собственный фреймворк с разделением фаз для сервинга Llama 4 70B/400B внутри датацентров. | 2-3x увеличение throughput при тех же затратах |
| Mistral AI (крупные корпоративные развертывания) | Использование гибридного подхода: prefill на NVIDIA, decode на Groq LPU или Cerebras. | До 60% снижение latency на длинных генерациях |
| Исследование DistServe (Microsoft/Вашингтон) | Академический прототип, доказавший эффективность концепции. Открытый код на GitHub. | Теоретически до 4.2x лучшее использование GPU |
Архитектура под капотом: от DistServe до кастомных ядер
Звучит здорово. Но как заставить два разных кластера GPU работать как один мозг? Вот где начинается инженерная магия (и головная боль).
Ключевой вызов - KV-cache. Во время prefill мы создаем этот монстр (для Llama 4 70B с контекстом 32K это может быть 40+ ГБ данных). Пересылать его по сети перед каждым decode шагом - самоубийство для latency. Поэтому в DistServe и реальных системах используется хитрость: передается только seed KV-cache, а decode-кластеры сами управляют его обновлением во время генерации.
Представьте это так. Prefill-кластер - это шеф-повар, который готовит основу для супа (бульон и нарезанные овощи - seed KV-cache). Decode-кластеры - это линейные повара, которые получают эту основу и просто добавляют в нее ингредиенты (токены) по одному, не переделывая основу заново.
Важно: Эта архитектура убивает два классических подхода - tensor parallelism и pipeline parallelism внутри одного запроса. Потому что prefill и decode теперь выполняются на разных физических устройствах. Нужна новая форма параллелизма - phase parallelism.
Сетевые требования становятся критичными. Если в вашем кластере разница между PCIe 4.0 и 5.0 казалась академической, то здесь каждый микровтор задержки съедает ваше преимущество. InfiniBand NDR400 (400 Гбит/с) или даже новая технология Ultra Ethernet Consortium (UEC) 2026 года - вот реальные кандидаты.
1 Шаг первый: Инструментарий и анализ
Не бросайтесь переписывать продакшен. Сначала измерьте. Возьмите ваш текущий сервинг (например, на базе vLLM или TGI) и соберите метрики отдельно для prefill и decode. Вам нужны: время выполнения prefill (P50, P99), время на один токен decode, пиковое потребление VRAM в каждой фазе, утилизация тензорных ядер.
Инструменты: Prometheus + Grafana с кастомными дашбордами, NVIDIA DCGM, или встроенные метрики vLLM. Если decode фаза в 10 раз дольше prefill и при этом загрузка GPU падает ниже 30% - вы идеальный кандидат.
2 Шаг второй: Выбор и настройка железа
Prefill-кластер: малый, но мощный. 4-8 GPU последнего поколения (например, NVIDIA H200 или B200, если говорить о 2026 годе) с NVLink. Цель - минимизировать время prefill.
Decode-кластер: большой, но может быть на более старом, дешевом железе. Например, пул A100 40GB, или даже специализированные inference accelerators вроде Groq LPU, AMD Instinct MI300X (с их огромной HBM). Иногда сюда же можно применить техники оптимизации decode вроде SyDecode для еще большего ускорения.
3 Шаг третий: Выбор софта и модификация
У вас три пути.
- DistServe (рекомендуется для экспериментов): Академический, но рабочий прототип. Поддерживает основные модели (Llama, GPT). Исходники на GitHub. Идеален для proof-of-concept.
- Модификация vLLM (продакшен-путь): Fork vLLM, где scheduler знает о двух типах воркеров. Prefill-worker и decode-worker. Они общаются через высокопроизводительную очередь (Redis, RabbitMQ с плагинами zero-copy). Это сложно, но именно так делает Perplexity.
- Кастомный фреймворк на базе Triton Inference Server: Создаете два ансамбля моделей. Первый - prefill-модель. Второй - decode-модель. Triton управляет pipeline. Требует глубокого знания Triton, но дает максимальный контроль.
4 Шаг четвертый: Балансировка и мониторинг
Здесь система превращается из кластера в организм. Нужен orchestrator (Kubernetes с кастомными операторами, или HashiCorp Nomad), который динамически масштабирует decode-кластер в зависимости от длины очереди генерации. Prefill-кластер обычно статичен.
Мониторинг должен показывать не просто "загрузка GPU", а эффективность разделения: ratio времени prefill/decode, сетевой трафик KV-cache, latency 95-го перцентиля для end-to-end запроса.
Где спрятаны драконы: нюансы реализации, которые порвут вам проект
В теории все гладко. На практике вы наступите на все эти грабли.
Дракон 1: Сетевая латентность убивает short-lived запросы. Если ваш типичный промпт - 50 токенов, а ответ - 100 токенов, overhead на передачу KV-cache и синхронизацию съест всю выгоду. Disaggregated inference выгоден только для long-context и long-generation сценариев (чат, документный анализ, кодогенерация). Для классического NMT или коротких классификаторов - забудьте.
Дракон 2: Управление состоянием (statefulness) в decode-кластере. Что делать, если пользователь прервал генерацию? Или запрос на decode-кластере упал? Нужен механизм отката и очистки KV-cache, который теперь распределен. Это нетривиально.
Дракон 3: Гетерогенность железа - ад для отладки. Prefill на NVIDIA, decode на AMD? Приготовьтесь к ночам с отладкой драйверов и форматов данных. Даже если все GPU от NVIDIA, разные архитектуры (Hopper vs Ampere) могут требовать разных версий CUDA и кастомных ядер.
Дракон 4: Балансировка нагрузки становится двумерной. Нужно балансировать не просто запросы между GPU, а prefill-запросы на один кластер и decode-запросы на другой. Очередь decode может расти, пока prefill-кластер справляется. Нужна адаптивная логика, которая может даже запускать prefill на decode-кластерах в крайнем случае (теряя эффективность, но сохраняя latency).
FAQ: ответы на частые вопросы (прежде чем вы напишете в комментариях)
В: Это же усложняет систему в N раз. Стоит ли игра свеч?
О: Если ваш месячный счет за облачные GPU меньше $10k - нет. Если больше $50k - абсолютно да. Ручная оптимизация железа - это последний рубеж экономии после квантования, батчинга и всех стратегий масштабирования.
В: Можно ли это сделать локально, на моем сервере с 4 картами?
О: Технически - да. Практически - нет. Выигрыш станет заметен только при масштабе, когда decode-фаза занимает гигабайты видеопамяти на многих картах. Для домашнего стенда смотрите в сторону оптимизаций вроде AdaLLM или лучшего батчинга.
В: А что насчет альтернатив? Может, просто купить больше памяти?
О: Память - это не решение для compute-bound проблемы prefill. И наоборот, мощные ядра не решат memory-bound decode. Специализация - фундаментальный закон инженерии. В 2026 году мы увидим появление специализированных prefill-чипов (что-то вроде Google TPU, но только для context encoding) и дешевых decode-чипов (как Groq LPU).
В: Есть ли готовые облачные решения?
О: На 15.04.2026 AWS SageMaker, Google Vertex AI и Azure ML предлагают "оптимизированные конфигурации для инференса", но под капотом это часто просто автомасштабирование. Настоящее disaggregated inference пока предлагают только niche-провайдеры вроде Crusoe Energy или CoreWeave как кастомное решение. Готовьтесь к долгим переговорам с их инженерами.
И последнее. Не гонитесь за модной архитектурой, если не понимаете свой workload. Запустите недельный трассировку запросов. Постройте heatmap зависимости времени фазы от длины контекста и ответа. Возможно, ваша проблема решается простым улучшением батчинга или переходом на более новую модель с Grouped-Query Attention (как в Llama 4), которая сама по себе снижает нагрузку на decode.
Но если вы уже масштабируетесь до десятков GPU и видите, как деньги утекают в idle cycles - теперь вы знаете, куда смотреть. Perplexity и Meta не просто так делят prefill и decode. Они делят ваши будущие счета пополам.
