tekBlueprint

В Части 2 рассматривались квантование и оптимизация KV-кэша. Это Часть 3 из 4 – она посвящена методам, ускоряющим инференс: предсказанию нескольких токенов (multi-token prediction) и стратегиям распределенного параллелизма.

Часть 1: Архитектура и метрики → Часть 2: Квантование и KV-кэш ← Часть 3: Параллелизм и скорость → Часть 4: Фреймворки и эксплуатация

Предсказание нескольких токенов (MTP)

Предсказание нескольких токенов (Multi-Token Prediction, MTP) представляет собой структурное изменение того, как авторегрессионные модели генерируют текст. Вместо того чтобы выдавать один токен за прямой проход (forward pass), модель MTP предсказывает несколько токенов вперед за один проход, а затем проверяет их. Если предсказания верны, вы пропускаете промежуточные прямые проходы и генерируете несколько токенов по цене одного.

Что такое MTP

Традиционный авторегрессионный паттерн следует фиксированному ритму: прямой проход, получение логитов, сэмплирование токена, добавление в последовательность, повтор. Каждый шаг требует полного прямого прохода через модель. Для модели на 70B параметров это означает потоковую загрузку более 70B весов из HBM для каждого отдельно сгенерированного токена.

Спекулятивное декодирование (speculative decoding) ввело концепцию генерации черновых токенов с помощью небольшой модели и их проверки большой моделью. Маленькая модель-черновик независимо генерирует n токенов. Затем большая модель проверяет все n токенов за один прямой проход, поскольку ее логиты в каждой позиции независимы при данных промпте и черновых токенах. Если черновые токены совпадают с теми, которые сгенерировала бы большая модель, вы принимаете их все и продвигаетесь на n позиций. Если черновой токен отклонен, вы принимаете токены до этой точки и возвращаетесь к стандартному декодированию.

MTP берет эту идею и встраивает ее в архитектуру модели. Вместо использования отдельной модели-черновика, основная модель включает дополнительные головы (heads), которые предсказывают несколько будущих токенов. Эти головы обучаются совместно с основной генеративной головой, поэтому они изучают то же распределение, а не аппроксимируют его с помощью меньшей модели. Шаг проверки все равно происходит, но черновик и целевые данные исходят из одного пространства параметров.

Смена парадигмы заключается в устранении разрыва в качестве черновика. Внешнее спекулятивное декодирование страдает, когда маленькая модель-черновик делает уверенно неверные предсказания. Большая модель все равно должна выполнить полный прямой проход для проверки, не получая ничего взамен. В MTP генеративные головы являются частью обученной модели, обеспечивая более высокий уровень принятия (acceptance rate) – обычно 60-85% против 40-60% у внешних генераторов.

Как работает MTP

Шаг генерации MTP состоит из двух фаз. На фазе черновика (draft phase) модель выполняет прямой проход через основной путь генерации, создавая логиты для следующего токена. Одновременно она передает скрытые состояния (hidden states) в серию голов MTP. Каждая голова MTP предсказывает один дополнительный токен вперед. Для 3-шаговой головы MTP модель создает логиты для позиций t+1, t+2 и t+3 за один прямой проход.

Генерация черновых токенов принимает две формы в зависимости от архитектуры. В MTP в стиле Medusa несколько голов располагаются поверх основных скрытых состояний и предсказывают токены вперед параллельно – между самими головами нет последовательной зависимости, но принятие происходит последовательно: токен со смещением k принимается только если все предыдущие смещения приняты. В MTP в стиле Gemma 4 токены генерируются последовательно внутри генератора MTP: каждый токен создается авторегрессионно, с отдельным эмбеддером, обращая внимание на предыдущие токены MTP и KV-кэш основной модели. Оба подхода создают черновую последовательность из n токенов-кандидатов.

На фазе проверки (verify phase) модель выполняет один прямой проход через основной путь генерации по накопленному контексту (исходный промпт плюс все черновые токены). Это создает логиты для каждой черновой позиции. Модель сравнивает свои собственные логиты с черновыми токенами в каждой позиции. Это сравнение и есть тест на принятие.

Логика принятия/отклонения следует определенному шаблону. Начиная с позиции t+1, модель проверяет, совпадает ли черновой токен с аргмаксом (или высоковероятным совпадением) ее собственных логитов. Если совпадает, токен принимается, и проверка продолжается для t+2. Если нет, модель повторно сэмплирует из своих логитов в этой позиции, чтобы получить правильный токен. Все последующие черновые токены отбрасываются.

Это означает, что MTP обеспечивает переменное ускорение. На простых путях продолжения все черновые токены принимаются, и вы пропускаете n прямых проходов. На неопределенных путях принимается только первый токен, и MTP не дает ускорения сверх единственного прохода проверки. Среднее ускорение зависит от уровня принятия.

Конкретный пример иллюстрирует экономию. Предположим, голова MTP генерирует 3 токена вперед, а вероятность принятия для каждой позиции составляет 70% (при допущении независимости между позициями). Каждый шаг MTP состоит из двух прямых проходов: одного прохода черновика и одного прохода проверки. Ожидаемое количество токенов за шаг MTP равно:

E[tokens per step] = 1 + p + p^2 + p^3
                   = 1.0 + 0.7 + 0.49 + 0.343 ≈ 2.52

“1” учитывает обязательный первый токен от основного пути генерации; оставшиеся члены — это ожидаемые принятые черновые токены. На каждый прямой проход это даёт примерно 1.26 токена в среднем. На практике ускорение ниже – около 1.3-1.5x эффективных токенов на каждый проход – из-за управления KV-кэшем во время проверки, накладных расходов генератора MTP и того факта, что вероятности принятия черновых токенов не полностью независимы между позициями.

Архитектура MTP

Головы MTP не являются независимыми модулями. Они разделяют KV-кэш с основной моделью, то есть читают из того же хранилища ключей-значений, в которое пишут основные головы внимания (attention heads). Каждый принятый черновой токен проходит через эмбеддер и слои внимания генератора, которые записывают новые записи в общий KV-кэш на соответствующих позициях.

Типичная реализация MTP использует отдельный, меньший блок Transformer, размещенный поверх основной модели. Этот блок получает финальное скрытое состояние от основной модели и обрабатывает его через дополнительные слои Transformer. Каждый слой в блоке MTP производит логиты для одной позиции вперед через отдельную проекцию выхода.

Механизм перекрестного внимания (cross-attention) имеет решающее значение. Слои внимания блока MTP обращаются к KV-кэшу, общему с основной моделью. Это означает, что токены MTP могут видеть полный контекст – они не генерируются изолированно. Блок MTP также записывает данные в KV-кэш по мере генерации, поэтому более глубокие головы MTP могут обращаться к более ранним предсказаниям MTP.

Дизайн сохраняет головы MTP меньшими, чем основная модель. Типичная конфигурация использует ту же скрытую размерность, но меньшее количество голов внимания. Например, если в основной модели 64 головы внимания, блок MTP может использовать 16. Это снижает вычислительные накладные расходы MTP, сохраняя качество предсказаний.

Накладные расходы памяти управляемы. KV-кэш увеличивается на n дополнительных позиций токенов во время фазы черновика, но эта память освобождается при отклонении черновых токенов. Принятые токены повторно используют черновые записи KV-кэша, поэтому для принятых токенов не происходит удвоения размера кэша.

Пример: Gemma 4

Gemma 4, выпущенная Google в начале мая 2026 года, поддерживает Multi-Token Prediction через выделенные генераторы MTP. Генераторы MTP были выпущены недели спустя после запуска основных моделей в виде отдельных чекпойнтов – каждой модели соответствует своя модель-ассистент (например, gemma-4-12B-it с gemma-4-12B-it-assistant).

Генератор MTP для Gemma 4 представляет собой 4-слойную модель Transformer, загружаемую совместно с основной моделью. Он генерирует токены вперед последовательно – каждый токен создается с использованием отдельного эмбеддера и обращает внимание на KV-кэш предыдущих токенов MTP и основной модели. Генератор разделяет KV-кэш с основной моделью и использует уменьшенное количество голов внимания по сравнению с основными слоями. Обычно настраиваемый на 3 токена вперед, поддерживает произвольную длину черновика. Веса генератора добавляют примерно 10-25% к общему объему загружаемых параметров в зависимости от размера модели.

Бенчмарки Google и технический отчет (arXiv:2607.02770, опубликованный в июле 2026 г.) показали ускорение генерации до 3x на оборудовании с высокой пропускной способностью памяти. Ускорение наиболее выражено на GPU H200 и H100, где узким местом является пропускная способность памяти. На оборудовании, ограниченном по памяти, ускорение падает до 1.3-1.8x, поскольку загрузка дополнительных весов MTP частично компенсирует экономию от пропущенных прямых проходов.

Влияние на качество по стандартным бенчмаркам было измерено как нулевое. Поскольку головы MTP обучаются совместно с основной моделью, они не изменяют распределение генерации для принятых токенов. Отклоненные токены повторно сэмплируются из логитов основной модели, поэтому они следуют тому же распределению, что и стандартная авторегрессионная генерация. Единственное потенциальное влияние на качество заключается в перплексии на уровне токенов во время прохода проверки, чего дизайн Gemma 4 не допускает.

EAGLE и Medusa: продвинутое внешнее черновое кодирование

Помимо простого MTP на уровне токенов, появились две продвинутые архитектуры чернового кодирования, которые повышают уровень принятия до 70-85% на предсказуемых нагрузках без значительного увеличения размера модели.

Medusa добавляет несколько легковесных голов предсказания поверх финальных скрытых состояний модели, каждая из которых предсказывает токен с разным смещением в будущее (t+1, t+2, t+3, …). Эти головы разделяют представления основной модели и обучаются совместно с ней, каждая оптимизируя предсказание своего смещения с помощью комбинированной функции потерь.

EAGLE (Extrapolation Algorithm for Greater Language-model Efficiency) использует более сложный подход: вместо предсказания будущих токенов он предсказывает будущие скрытые состояния – векторы признаков, которые основная модель произвела бы на последующих слоях. Затем небольшая авторегрессионная голова отображает эти предсказанные признаки в логиты токенов. Поскольку распределения признаков более гладкие и предсказуемые, чем дискретные распределения токенов, EAGLE достигает более высоких уровней принятия с меньшими накладными расходами на генерацию, чем чистый MTP на уровне токенов.

Оба метода легко интегрируются с логикой принятия, используемой в проходе проверки (описанной выше), и оба поддерживаются современными фреймворками обслуживания (serving), такими как vLLM и SGLang.

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

Внешнее спекулятивное декодирование использует отдельную небольшую модель (часто 1/10 размера) в качестве генератора. MTP встраивает генератор в архитектуру модели. Оба достигают одной цели – проверку черновых токенов для пропуска прямых проходов – но с различными компромиссами.

У внешнего спекулятивного декодирования есть одно преимущество: гибкость. Вы можете комбинировать любую модель-черновик с любой целевой моделью. Это полезно при работе со старыми архитектурами, лишенными встроенного MTP. Вы также можете менять модели-черновики, чтобы настроить баланс между уровнем принятия и накладными расходами памяти.

MTP имеет преимущество в виде более тесной поверхности оптимизации. Генератор учится предсказывать то, что произведет основная модель, а не то, что она произвела бы, будь она другой архитектурой. Уровень принятия сходится к теоретическому максимуму для данного распределения, ограничиваясь лишь внутренней неопределенностью в распределении следующих токенов.

MTP на практике

MTP обеспечивает предсказуемое ускорение, когда путь генерации имеет низкую энтропию на токен. Автодополнение кода, генерация документации, структурированный вывод и перевод – эти задачи обладают высокой предсказуемостью следующего токена. Уровни принятия MTP на таких нагрузках достигают 80-90%, обеспечивая эффективное ускорение в 2-3 раза.

Ускорение снижается для творческого письма, открытых рассуждений и диалогов. Эти задачи имеют высокую токенную неопределенность, что означает, что логиты самой модели имеют более плоские распределения. Когда основная модель не может быть уверена в следующем токене, ее головы MTP тоже не могут. Уровни принятия падают до 40-50%, и MTP дает незначительное или нулевое ускорение.

Соображения по размеру батча критичны. MTP и спекулятивное декодирование наиболее эффективны при малых размерах батча (BS=1-4), где инференс ограничен памятью, а вычислительные блоки GPU недоиспользованы. Головы MTP заполняют свободные вычислительные циклы полезной работой. При размерах батча выше 8-16 инференс становится ограниченным вычислениями, и накладные расходы MTP конкурируют с основной моделью за Tensor Cores, потенциально снижая пропускную способность. Для высоконагруженных задач с большими батчами рассмотрите возможность полного отключения MTP и использования других оптимизаций.

MTP и другие методы оптимизации суммируются. Вы можете комбинировать MTP с квантованием, непрерывным батчингом и PagedAttention. Совокупный эффект мультипликативен для пропускной способности. Квантованная модель с MTP и PagedAttention может достичь в 3-5 раз большей эффективной пропускной способности по сравнению с неквантованным авторегрессионным базовым уровнем. Ключевым ограничением остается VRAM: все оптимизации должны укладываться в доступный бюджет памяти.

Стратегии параллелизма

Один GPU редко вмещает современную большую модель при полезных размерах батча. Обслуживание модели на 70B параметров при батче 32 с весами и активациями в fp16 требует десятков гигабайт VRAM и превышает то, что может предоставить даже A100 80G без какой-либо формы распределенных вычислений. Стратегии параллелизма решают эту проблему, распределяя модель или работу между несколькими устройствами. Ни одна стратегия не является универсально оптимальной, и продакшн-системы комбинируют несколько стратегий для соответствия своей аппаратной топологии и профилю нагрузки.

Тензорный параллелизм (TP)

Тензорный параллелизм разделяет сами матрицы весов между GPU в пределах одного узла. Ключевая идея заключается в том, что многие линейные слои в трансформере – особенно большие проекции feed-forward и выходные проекции внимания – могут быть разделены без фундаментального изменения графа вычислений. Этот подход относится к одной из старейших и наиболее зрелых техник распределенного обучения, восходящей к статье Megatron.

Базовая схема разделения использует две взаимодополняющие операции. Параллелизм по столбцам (Column parallel) разделяет матрицу весов W вдоль ее выходных размерностей. Если W имеет форму (d_model, d_ff), GPU 0 вычисляет W[:, :d_ff//2] @ x, а GPU 1 вычисляет W[:, d_ff//2:] @ x, каждый производит половину выходного вектора. Параллелизм по строкам (Row parallel) разделяет вдоль входных размерностей. GPU 0 вычисляет W[:d_model//2, :] @ y, GPU 1 вычисляет W[d_model//2:, :] @ y, и их частичные результаты должны быть просуммированы.

Эти две операции естественным образом появляются вместе внутри слоя трансформера. Проекции query, key и value используют параллелизм по столбцам: каждый GPU производит четверть выходов каждой проекции Q, K и V соответственно. После того как механизм внимания завершает работу для каждой головы, выходная проекция использует параллелизм по строкам для рекомбинации разделенных голов обратно в полное представление d_model.

И параллелизм по столбцам, и по строкам требует all-reduce после слоя для синхронизации частичных результатов между GPU. Каждый слой выполняет эту коллективную операцию, что означает, что объем коммуникации масштабируется с количеством слоев. Для модели на 70B с 80 слоями это 80 операций all-reduce на каждый прямой проход. Эти накладные расходы на коммуникацию – основное ограничение TP.

Степень TP равна количеству GPU на каждую реплику модели. Степень TP, равная 4, означает, что четыре GPU совместно вычисляют одну копию модели. Увеличение общей пропускной способности требует нескольких независимых реплик, каждая со своей группой TP. Это разделение важно для развертывания: степень TP ограничена количеством GPU в пределах одного узла, поскольку межузловая коммуникация на порядок медленнее, чем внутризузловой NVLink.

На практике TP работает лучше всего, когда цель состоит в снижении задержки для одного запроса к большой модели. Разделение модели 70B на 8 GPU с NVLink часто дает почти линейное масштабирование FLOP, снижая время до первого токена до интерактивного уровня. Накладные расходы на коммуникацию остаются в пределах соединения между нодами, удерживая синхронизацию на уровне слоя в диапазоне от микросекунд до единиц миллисекунд. Компромисс в том, что степень TP не может расти за пределы физического количества GPU на узел.

Конвейерный параллелизм (PP)

Конвейерный параллелизм использует другую ось: вместо разделения тензоров, он разделяет последовательность слоев модели между GPU. Если модель имеет 40 слоев и доступны два GPU, GPU 0 обрабатывает слои 0-19, а GPU 1 – слои 20-39. Каждый GPU выполняет полные вычисления прямого прохода для своего среза, прежде чем передать промежуточные активации следующему этапу.

Этот подход работает как между узлами, так и внутри одного узла. Промежуточные активации между этапами передаются по PCIe или стандартным сетевым каналам, и их требования к пропускной способности умеренные по сравнению с трафиком all-reduce в TP. Коммуникация на каждом шаге является точка-точка (point-to-point): каждый этап отправляет один тензор своему соседу и получает один тензор от предшественника.

Основная неэффективность конвейерного параллелизма – это конвейерный пузырь (pipeline bubble). Во время прямого прохода с G этапами первый этап завершает свою работу и передает данные этапу 2, в то время как этап 2 простаивает в ожидании этих данных. Если один батч обрабатывается через конвейер, последний этап начинает работу только после того, как первый этап завершит свой, оставляя (G-1)/G общего времени GPU простаивающим.

Микро-батчинг (micro-batching) решает эту неэффективность. Вместо отправки одного большого батча через конвейер, батч разбивается на M меньших микро-батчей. Пока этап 1 обрабатывает микро-батч 2, этап 0 передает микро-батч 1 вперед. Пропускание микро-батчей через этапы держит все GPU занятыми, хотя остаточные потери на пузырек сохраняются. Техника планирования 1F1B (используемая в основном при обучении) оптимизирует дальнейшее: после фазы разогрева, заполняющей конвейер прямыми микро-батчами, она чередует один шаг обратного прохода с одним шагом прямого. Эта стратегия обратного давления минимизирует пиковую память для градиентов, сохраняя утилизацию GPU почти оптимальной. Для развертываний, предназначенных только для инференса, PP с микро-батчингом обычно использует более простое расписание чередующегося конвейера только для прямого прохода.

Чередующийся конвейерный параллелизм (Interleaved PP) добавляет еще одну степень свободы. Вместо назначения одного непрерывного куска слоев на GPU, он назначает несколько непрерывных кусков в циклическом порядке. GPU 0 обрабатывает слои [0, k, 2k, …], GPU 1 обрабатывает [k, 2k, 3k, …]. Это чередование уменьшает долю пузырька, потому что каждый GPU участвует чаще на каждом шаге конвейера, улучшая как балансировку памяти, так и утилизацию вычислений.

PP – правильный выбор для очень глубоких моделей или многоузловых развертываний, где пропускной способности NVLink недостаточно. Llama 70B с PP на 4 узлах все еще работает без постоянного шума all-reduce между стойками. Сложность планирования – это плата: PP требует тщательного выбора размера микро-батча, отслеживания памяти для активаций и состояния KV-кэша, а зачастую и кастомной библиотеки коммуникации.

Параллелизм экспертов (EP)

Параллелизм экспертов существует только для моделей Mixture-of-Experts (MoE). В архитектуре MoE сеть feed-forward внутри каждого слоя трансформера содержит K независимых “экспертных” подсетей, а маршрутизирующий шлюз (routing gate) выбирает, какие эксперты обрабатывают каждый токен. Во время инференса токен обычно активирует 2-4 эксперта из 64 или 128.

EP назначает каждому GPU подмножество общего пула экспертов. Если есть 64 эксперта на 8 GPU, каждый GPU содержит 8 экспертов. Во время прямого вычисления токены маршрутизируются на тот GPU, которому принадлежат их назначенные эксперты. Эта маршрутизация создает паттерн коммуникации “все-со-всеми” (all-to-all): каждый GPU отправляет токены каждому другому GPU и получает токены от каждого другого GPU.

Коммуникация all-to-all значительно дороже, чем all-reduce или передача точка-точка. Объем коммуникации зависит как от количества экспертов, так и от распределения токенов между ними. Если маршрутизация идеально равномерна, каждый GPU отправляет примерно 1/K своих токенов каждому GPU-соседу. При несимметричной маршрутизации возникают горячие точки, и некоторые GPU обрабатывают гораздо больше токенов, чем другие, создавая отстающих (stragglers).

EP почти всегда комбинируется с TP. Типичный паттерн – EP между узлами (распределение подмножеств экспертов по разным узлам) и TP внутри каждого узла (разделение весов отдельного эксперта между GPU на общем NVLink). Эта двухуровневая декомпозиция балансирует стоимость коммуникации и требования к памяти и является стратегией, используемой в стеках обслуживания DeepSeek V3 и Mixtral.

Параллелизм данных и последовательностей (DP/SP)

Параллелизм данных (DP) – самая простая и наиболее широко понятная стратегия. Каждый GPU содержит полную реплику модели, а входной батч делится между GPU. GPU 0 обрабатывает токены из среза 0 батча, GPU 1 – срез 1 и так далее. Во время обучения градиенты синхронизируются между репликами через all-reduce. Во время инференса каждая реплика работает независимо без коммуникации между репликами. Параллелизм данных масштабирует пропускную способность линейно с количеством GPU и не требует разделения модели.

Ограничение обычного параллелизма данных в том, что каждому GPU все еще нужно достаточно VRAM для одной полной реплики модели. Модели, превышающие память одного GPU, не могут использовать только DP, независимо от размера батча.

Параллелизм последовательностей (SP) решает проблему узких мест в памяти в слоях без внимания (таких как LayerNorm и Dropout) путем разделения активаций вдоль размерности последовательности, что снижает пиковое потребление памяти во время прямого и обратного проходов. Это требует операций all-gather и reduce-scatter для поддержания согласованности между GPU.

Контекстный параллелизм (CP), с другой стороны, разработан специально для длинных контекстных окон. Для контекста в 128K вычисление внимания и объем KV-кэша растут квадратично или линейно с длиной последовательности. CP разделяет матрицу внимания и KV-кэш вдоль размерности токенов. GPU 0 вычисляет внимание для токенов 0-64K, GPU 1 – для токенов 64K-128K. Во время внимания GPU обмениваются своими локальными KV-кэшами через коллективную коммуникацию (например, Ring Attention). CP особенно ценен для потоковой передачи длинных документов или многоэтапных бесед, где контекст выходит за пределы бюджета VRAM одного GPU.

Дезагрегированный инференс: разделение Prefill и Decode

Наиболее значимым архитектурным сдвигом в обслуживании LLM за последние несколько лет является дезагрегация – разделение фаз prefill (предзаполнение) и decode (декодирование) на разные пулы GPU. Системы вроде DistServe, Splitwise и Mooncake стали пионерами этого подхода, и он стал стандартом для крупномасштабных продакшн-развертываний.

Ключевое понимание заключается в том, что prefill и decode имеют принципиально разные профили ресурсов и мешают друг другу при совместном размещении. Один long-context prefill (ограниченный вычислениями), разделяющий GPU с несколькими последовательностями decode (ограниченными памятью), вызывает эффекты “пузырьков”: последовательности decode испытывают всплески ITL в ожидании завершения больших matmul-операций prefill, а prefill недоиспользует пропускную способность памяти, пока последовательности decode конкурируют за нее.

Дезагрегация решает это путем выделения отдельных пулов GPU для каждой фазы. Пул prefill оптимизирован для вычислительной пропускной способности: большие размеры батшей токенов промпта, агрессивное слияние матриц и насыщение Tensor Cores. Пул decode оптимизирован для пропускной способности памяти: малые батчи, локальность KV-кэша и непрерывный батчинг. Когда поступает новый запрос, он обрабатывается пулом prefill, который вычисляет начальные скрытые состояния и KV-кэш, затем передает их по высокоскоростному интерконнекту (NVLink, InfiniBand или RoCE) в пул decode для генерации токенов.

Преимущества существенны. Дезагрегированные системы достигают в 2-4 раза лучшей утилизации оборудования, чем объединённые системы, потому что каждый пул работает в своем оптимальном режиме без помех. TTFT, как правило, улучшается для запросов с длинным контекстом, где вычисления prefill доминируют над временем очереди, хотя добавленные накладные расходы на передачу KV-кэша могут компенсировать выигрыш для коротких промптов. ITL улучшается, потому что GPU decode никогда не простаивают на длинных prefill. Компромисс – дополнительные накладные расходы на сеть для передачи состояния KV-кэша, которые становятся значительными при очень большой длине контекста (64K+ токенов).

Современные фреймворки обслуживания, такие как vLLM и TensorRT-LLM, теперь изначально поддерживают дезагрегированные конфигурации, а специализированные системы, такие как Mooncake (используемые Moonshot AI), продемонстрировали свою жизнеспособность в общеотраслевом масштабе.

3D-параллелизм

Продакшн-системы обслуживания редко полагаются на одну стратегию параллелизма. 3D-параллелизм объединяет TP, PP и DP для одновременной оптимизации утилизации вычислений, накладных расходов на коммуникацию и гибкости развертывания.

Типичная декомпозиция работает следующим образом. TP разделяет тензорные операции внутри каждого узла, используя пропускную способность NVLink для минимизации внутризузловой коммуникационной задержки. PP объединяет группы узлов в стойке, распределяя глубину модели, чтобы избежать концентрации в памяти. DP реплицирует комбинированный конвейер TP+PP по кластерам GPU, достигая масштабирования пропускной способности на уровне рабочей нагрузки.

Megatron-LM популяризировал комбинацию TP+DP для обучения и адаптировал ее для обслуживания. DeepSpeed добавил состояния оптимизатора ZeRO и PP для моделей экстремального масштаба. На стороне инференса vLLM полагается на TP как на свой основной примитив параллелизма, развертывая одну реплику с группой TP на каждый экземпляр-обслуживатель и масштабируясь горизонтально с помощью DP. TensorRT-LLM поддерживает как TP, так и PP, обеспечивая размещение параллельных стадий с учетом компиляции для максимальной пропускной способности в одно- и многоузловых развертываниях.

Выбор правильной 3D-конфигурации зависит от трех факторов: размер модели относительно памяти на GPU, желаемый профиль задержки и пропускной способности, а также доступная аппаратная топология.

Таблица сравнения стратегий параллелизма

Глоссарий

Ссылки

1. Параллелизм – Тензорный, конвейерный и данных
   1. Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism (Тензорный + конвейерный параллелизм). arXiv:1909.08053
   2. ZeRO: Memory Optimizations Toward Training Trillion Parameter Models (Параллелизм данных + ZeRO). arXiv:1910.02054
2. Параллелизм – Последовательностей и контекста
   1. Ring Attention with Blockwise Transformers for Near-Infinite Context (Контекстный параллелизм). arXiv:2310.01889
3. Дезагрегированное обслуживание
   1. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving. arXiv:2401.09670
   2. Splitwise: Efficient Generative LLM Inference Using Phase Splitting. arXiv:2311.18677
4. Предсказание нескольких токенов (MTP) и спекулятивное декодирование
   1. Fast Inference from Transformers via Speculative Decoding. arXiv:2211.17192
   2. Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads. arXiv:2401.10774
   3. EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty. arXiv:2401.15077
   4. Gemma 4 Technical Report (Головы MTP, мультимодальная архитектура). arXiv:2607.02770
5. Ссылки на модели и архитектуры
   1. DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model (MLA + EP). arXiv:2405.04434
   2. DeepSeek-V3 Technical Report (MoE с 256 экспертами, параллелизм экспертов в масштабе). arXiv:2412.19437

Предыдущая: Часть 2 – Квантование и KV-кэш

Следующая: Часть 4 – Фреймворки и эксплуатация рассматривает фреймворки обслуживания, эксплуатацию в продакшене и матрицу принятия решений.