Инференс сверхбольших языковых моделей (LLM) на современном оборудовании требует динамической адаптации во время выполнения, чтобы одновременно достигать высокой пропускной способности и низкой задержки в изменяющихся условиях. Статический подход «один размер для всех» больше не работает — он приводит либо к недоиспользованию дорогостоящих GPU при лёгкой нагрузке, либо к сбоям OOM и нарушению SLA при пиковом трафике. Современные системы обслуживания моделей используют адаптивные стратегии, которые на лету корректируют параллелизм, числовую точность, планирование CUDA-ядер и использование памяти. В этой главе рассматриваются такие передовые техники, как динамическое переключение параллелизма, масштабирование точности, управление кэшем в реальном времени и настройка на основе обучения с подкреплением (RL).

19.1Адаптивные стратегии параллелизма (TP, PP и гибридные)

Огромные LLM требуют параллелизма моделей — тензорного и конвейерного или их гибрида — для распределения вычислений по нескольким GPU. У каждого подхода есть преимущества и недостатки. В таблице 19-1 приведены рекомендуемые стратегии параллелизма для конкретных паттернов трафика инференса.

Таблица 19-1. Рекомендуемые стратегии параллелизма по паттернам трафика

Обзор стратегий параллелизма

Data parallel предполагает репликацию полной модели на каждом GPU с балансировкой входящих запросов между репликами. Это не требует межGPU-синхронизации для отдельных инференсов, поскольку каждый GPU обрабатывает отдельные запросы независимо. Подход максимизирует пропускную способность для множества небольших или средних входов с минимальными накладными расходами. Однако data parallel невозможен, если модель не помещается в память одного GPU.

Tensor parallelism (TP) — форма параллелизма моделей, разделяющая матрицы модели между GPU для ускорения матричных умножений. Вносит дополнительные all-reduce коммуникации для синхронизации GPU после каждого слоя.

Pipeline parallelism (PP) — также параллелизм моделей, но назначает целые слои разным GPU для преодоления ограничений памяти. Вносит накладные расходы в виде задержек последовательных стадий — так называемые «пузыри» конвейера (pipeline bubbles).

Expert parallelism, используемый в архитектурах mixture-of-experts (MoE), назначает каждую экспертную подсеть на отдельный GPU. Лёгкая сеть маршрутизации направляет каждый входной запрос или токен только к top-k активным экспертам. Например, DeepSeek-V3 — MoE-модель с 671 млрд параметров, активирующая около 37 млрд параметров на токен (1 общий эксперт + 8 выбранных маршрутизатором из 256)[reference:0]. Активируя лишь нескольких экспертов на вход, expert parallelism снижает память на устройство, время инференса и вычислительные затраты.

Динамическое переключение параллелизма во время выполнения

Традиционно стратегия параллелизации выбирается и фиксируется заранее при загрузке модели. Однако для максимизации производительности при динамических нагрузках современные инференс-движки могут выбирать различные стратегии параллелизма во время выполнения на основе характеристик входных данных.

Ключевые факторы: размер батча, длина последовательности, использование памяти, требования к задержке и пропускной способности. Очень длинные промпты могут направляться в экземпляр TP + PP, поскольку это распределяет слои по GPU и предотвращает ошибки OOM. Короткие запросы, чувствительные к задержке, направляются в экземпляр модели только с TP, чтобы избежать накладных расходов конвейерных стадий.

Пример: DeepSeek-V3 на 8× Blackwell B200

DeepSeek-V3 — разреженная mixture-of-experts модель с 671 млрд параметров, активирующая 37 млрд параметров на токен[reference:1]. Рассмотрим сервер с 8× GPU Blackwell B200 с общим объёмом 1440 ГБ HBM (180 ГБ на GPU × 8).

• Базовый режим: четырёхпутевой TP на четырёх GPU — остальные четыре GPU простаивают.
• Длинный контекст (> 1 млн токенов): планировщик запускает двухстадийный конвейер: стадия 1 — GPU 0–3, стадия 2 — GPU 4–7. Это удваивает доступную память до ~720 ГБ на стадию и помогает избежать OOM.
• Множество коротких запросов: система направляет их в экземпляр только с TP, избегая пузырей конвейера для минимально возможной задержки.

def choose_worker_pool(seq_len, gpu_mem_util, concurrent_reqs):
    if seq_len > 4096 or gpu_mem_util > 0.8:
        return "tp_pp_hybrid"
    if concurrent_reqs > 4:
        return "tensor_parallel"
    return "tensor_parallel"

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

19.2Динамическое изменение точности

Современные GPU, такие как Blackwell, поддерживают 8-битную и 4-битную плавающую точку (FP8/FP4) в вычислительных блоках Tensor Core. Эти более низкие точности обеспечивают значительное ускорение, экономию памяти и минимальную потерю качества.

Динамическое переключение точности — передовая техника, при которой инференс-движок корректирует числовую точность во время выполнения на основе уверенности модели или давления на ресурсы. Цель — увеличить пропускную способность без существенной потери качества.

Триггеры адаптации точности

Уверенность модели (резкость логитов)

Если распределение вероятностей модели для следующего токена показывает экстремальные пики из-за высокой уверенности, небольшие числовые ошибки от низкой точности вряд ли изменят результат. В этом случае движок безопасно использует FP4 для следующих нескольких шагов. И наоборот, если распределение более плоское из-за высокой неопределённости, движок должен оставаться на FP8 или FP16.

Инференс-движок количественно оценивает неопределённость, вычисляя энтропию Шеннона распределения softmax по словарю. Низкая энтропия указывает на более резкое (более уверенное) предсказание. Фиксированный порог энтропии, настроенный на отложенном валидационном наборе, определяет, когда переключаться на FP4, а когда оставаться на FP8/FP16.

Давление на память

Если использование памяти GPU приближается к пределу из-за очень длинного контекста или множества параллельных запросов, система может динамически сжимать активации до более низкой точности. Например, хранить тензоры ключей/значений внимания в INT4 вместо INT8, когда память ограничена — это уменьшит объём памяти на 50%. Однако необходимо убедиться, что ошибка квантования не накапливается через множество шагов декодирования.

Таблица 19-2. Конфигурации точности и их компромиссы

Современные GPU предоставляют нативные Tensor Cores для FP8 и FP4. Однако поддержка AMP в PyTorch на момент написания нацелена только на FP16 и BF16. Для инференса рекомендуется использовать NVIDIA Transformer Engine (TE) и применять его MXFP8 и NVFP4, когда это уместно.

Послойное и потокенное управление точностью

Библиотеки, такие как NVIDIA Transformer Engine, позволяют послойно управлять точностью во время выполнения. Линейные слои могут по умолчанию использовать FP8, но хук времени выполнения может повысить точность слоя до FP16 или понизить до FP4 в зависимости от роли:

• FP4 — для лёгких слоёв (выходные проекции), где допустима незначительная потеря точности.
• FP8/FP16 — для ранних слоёв, обрабатывающих сырые пользовательские входы и выигрывающих от более высокой точности.

import contextlib
import torch
try:
    from transformer_engine.pytorch import fp8_autocast as _te_fp8_autocast
    _TE_AVAILABLE = True
except Exception:
    _TE_AVAILABLE = False
    class _NullCtx(contextlib.ContextDecorator):
        def __init__(self, **_): pass
        def __enter__(self): return self
        def __exit__(self, *exc): return False
    def _te_fp8_autocast(**_):
        return _NullCtx()
def _precision_context_cuda(use_fp8, prefer_bfloat16, enable_fp8):
    if use_fp8 and enable_fp8 and _TE_AVAILABLE:
        return _te_fp8_autocast(enabled=True)
    amp_dtype = torch.bfloat16 if prefer_bfloat16 else torch.float16
    return torch.autocast(device_type="cuda", dtype=amp_dtype)

Этот паттерн создаёт эластичный режим точности: когда модель работает в предсказуемых (низкоэнтропийных) областях — генерация пунктуации, шаблонных завершений — она продолжает в FP8 для максимальной производительности. Когда она входит в области с более высокой энтропией — неоднозначные промпты, точки принятия решений — она возвращается к FP16 для сохранения числовой точности.

19.3Автотюнинг ядер для self-attention и MLP-путей трансформеров

Производительность слоёв нейронной сети на GPU может кардинально различаться в зависимости от низкоуровневых параметров: размер блока потоков, размеры тайлов, разворачивание циклов, паттерны доступа к памяти. Для моделей фиксированного размера библиотеки обычно выбирают эти параметры один раз.

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

Автотюнинг ядер внимания

if (seq_len < 256) {
    attn_kernel = standard_attention_kernel;
} else {
    attn_kernel = tiled_attention_kernel;
}
output = attn_kernel(Q, K, V, mask);

За кулисами attn_kernel выбирает между совершенно разными реализациями CUDA. Одна оптимизирована для малых входов, другая — для больших контекстов с использованием тайлового ядра.

Таблица 19-3. Влияние размеров тайлов на производительность (GPU класса Blackwell)

Процесс автотюнинга

1. Измерение нагрузки. Проверка текущих размеров входа (размер батча B, длина последовательности L).
2. Выбор ядер-кандидатов. Определение доступных реализаций для каждого компонента.
3. Бенчмаркинг. Быстрый прогон каждого кандидата на образце данных.
4. Выбор лучшего варианта. Выбор ядра с минимальным временем выполнения.
5. Кэширование результата. Сохранение выбора в таблице поиска.
6. Выполнение. Запуск слоя модели с использованием выбранной реализации.

19.4Динамическое выделение разделяемой памяти и выбор ядер с учётом заполненности

Тесно связана с настройкой ядер тема управления разделяемой памятью GPU и общей заполненностью streaming multiprocessor (SM). Динамически выделяя потоки во время выполнения на основе размера задачи и текущего использования разделяемой памяти, можно значительно улучшить производительность.

Компромисс между размером тайла и заполненностью

Рассмотрим T как ширину тайла в токенах на блок потоков. Каждый блок резервирует порядка O(T²) чисел с плавающей точкой в разделяемой памяти, поскольку self-attention квадратичен.

• Большой размер тайла (T=256): загружает каждый блок ключей/значений один раз из DRAM и повторно использует для множества запросов. Снижает трафик глобальной памяти. Но заполненность падает (например, до 30%).
• Малый размер тайла (T=64): использует меньше разделяемой памяти, позволяя разместить больше блоков на каждом SM. Лучше скрывает задержку. Но увеличивает количество обращений к DRAM.

int T = choose_tile(L, gpu_shared_mem_per_block, num_sms);
size_t shared_mem_bytes = 3 * T * T * sizeof(float);
MyAttentionKernel<<<numBlocks, threadsPerBlock, shared_mem_bytes>>>(...);

extern __shared__ float smem[];
float* tile_q = smem;
float* tile_k = smem + T*T;
float* tile_v = smem + 2*T*T;

Использование CUDA Occupancy API

int maxBlocks, bestThreads;
for (int threads = 64; threads <= 256; threads *= 2) {
    cudaOccupancyMaxActiveBlocksPerMultiprocessor(
        &maxBlocks, MyKernel, threads,
        sharedMemPerBlock(threads));
    float occupancy = (float) maxBlocks * threads / hardwareMaxThreadsPerSM;
}

Рекомендации по проектированию

• Проектируйте ядра, которые позволяют настраивать разделяемую память и размеры блоков во время выполнения.
• Поддерживайте таблицу оптимальных конфигураций для разных размеров задач.
• Учитывайте параметр carveout — долю унифицированного пула L1/разделяемой памяти.
• Отслеживайте метрики: простаивающие варпы (< 50% активных) указывают на низкую заполненность; циклы простоя памяти (> 70%) — на слишком малый тайл.

19.5Спекулятивная предзагрузка KV-кэша для ускорения TTFT

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

SpeCache: спекулятивное предсказание KV-доступа

SpeCache использует спекулятивное предсказание того, какие KV-пары понадобятся на следующем шаге декодирования[reference:2]. Подход основан на следующей архитектуре: полный 16-битный KV-кэш хранится в CPU-памяти, в GPU-памяти находится low-bit копия для оценки важности токенов. На каждом шаге декодирования модель предсказывает, какие KV-пары будут наиболее важны для следующего токена, и предзагружает соответствующие полноценные 16-битные пары из CPU-памяти в VRAM[reference:3].

Таким образом, SpeCache не выполняет классическое спекулятивное декодирование с верификацией и отклонением токенов. «Спекулятивность» здесь относится к предсказанию паттерна доступа к KV-кэшу, а не к генерации и проверке токенов. Это принципиально иная механика, чем speculative decoding из главы 15.

Выгрузка KV-кэша в Hugging Face Transformers

out = model.generate(..., cache_implementation="offloaded")
out = model.generate(..., cache_implementation="offloaded_static")

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

Реализация предзагрузки через CUDA-потоки

void* prefetch_dest = nullptr;
cudaMalloc(&prefetch_dest, KV_BYTES);
void* kv_src_host = nullptr;
cudaMallocHost(&kv_src_host, KV_BYTES);
cudaStream_t compute_stream, prefetch_stream;
cudaStreamCreateWithFlags(&compute_stream, cudaStreamNonBlocking);
cudaStreamCreateWithFlags(&prefetch_stream, cudaStreamNonBlocking);
cudaEvent_t kv_ready;
cudaEventCreateWithFlags(&kv_ready, cudaEventDisableTiming);
forward_kernel<<<1, 1, 0, compute_stream>>>();
cudaMemcpyAsync(prefetch_dest, kv_src_host, KV_BYTES,
                cudaMemcpyHostToDevice, prefetch_stream);
cudaEventRecord(kv_ready, prefetch_stream);
cudaStreamWaitEvent(compute_stream, kv_ready, 0);
consume_prefetched_kv<<<1, 1, 0, compute_stream>>>();

Хостовые буферы должны быть pinned (page-locked). В противном случае cudaMemcpyAsync может сериализоваться.

19.6Сжатие KV-кэша в реальном времени и переключение политик

По мере генерации токенов KV-кэш растёт линейно. Для длинных разговоров, документов и цепочек рассуждений он потребляет огромный объём памяти GPU.

Квантование KV-кэша

Простой подход — снижение точности. Многие фреймворки по умолчанию используют FP16 или BF16 для KV-кэша. Однако часто можно сжать ключи и значения до 8-бит или даже 4-бит с минимальным влиянием на качество. Hugging Face Transformers поддерживает QuantizedCache (INT8 и INT4): cache_implementation="quantized".

Динамическое переключение политик

Пример политики: хранение последних 128 токенов в полной точности, сжатие остальных в 4-бит. Наиболее свежий контекст сохраняется с более высокой точностью, а более старая история — с более низкой.

Дополнительно можно использовать Sliding-window attention — при котором каждый токен видит только последние W токенов. Это даёт линейное масштабирование O(N·W) вместо O(N²).

Half-Quadratic Quantization (HQQ)

HQQ — калибровочно-независимый квантователь на лету, поддерживающий 2-бит, 3-бит, 4-бит и 8-бит. Использует робастную оптимизацию для моделирования выбросов и ошибок с тяжёлыми хвостами. Хорошо интегрируется в Hugging Face Transformers.

def make_cache_config(*, backend, nbits, device, compute_dtype=torch.float16,
                      q_group_size=64, residual_length=128):
    return {
        "backend": backend,
        "nbits": int(nbits),
        "axis_key": 1,
        "axis_value": 1,
        "q_group_size": int(q_group_size),
        "residual_length": int(residual_length),
        "compute_dtype": compute_dtype,
    }

19.7Агенты обучения с подкреплением для настройки AI-систем в реальном времени

Многие техники, обсуждаемые в этой главе, включают решения, основанные на текущем состоянии системы. Эти решения требуют компромиссов — скорость против точности, пропускная способность против задержки. Вместо сбора всё большего количества эвристик, можно настраивать систему инференса с помощью обучения с подкреплением (RL).

Формулировка задачи RL

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

Пространство действий:

• Выбор режима параллелизма: одиночный, TP, PP, гибридный
• Выбор точности: FP8, смесь FP8 и FP4
• Настройка размера батча или времени ожидания
• Включение/отключение сжатия кэша
• Включение/отключение спекулятивного декодирования
• Выбор draft-модели
• Включение/отключение спекулятивной предзагрузки KV

Функция награды

reward = tokens_per_second - 1000 * (1 if latency > SLA else 0)
reward = tokens_per_second - λ * max(0.0, latency - SLA)

λ — настраиваемый вес штрафа. Больший λ заставляет агента приоритизировать соблюдение SLA. Меньший — позволяет рисковать превышениями для более высокой пропускной способности.

Алгоритмы и техники стабильности

• Proximal Policy Optimization (PPO) — рекомендуется для непрерывного обновления в средах реального времени.
• Демпфирование — требует, чтобы действие оставалось в силе в течение минимального времени.
• Ограничение пространства действий — ограничьте диапазоны разумными значениями.
• Формирование награды — высокая отрицательная награда за нарушение жёстких ограничений.

Меры предосторожности

• Теневой режим: агент обучается онлайн, но решения применяются только для сбора данных.
• Аварийный выход: если p95 задержки увеличивается более чем на 50%, система автоматически отключает агента.
• Структурированное логирование: отслеживайте последовательности состояние → действие → награда.
• Офлайн-обучение: используйте симуляторы и библиотеки (TRL от Hugging Face) для предварительного обучения политики.

19.8Динамическое переключение аллокаторов памяти (Slab, Caching, Stream-Ordered)

Фрагментация памяти GPU и неоптимальное выделение могут быть тихими убийцами производительности. Серверы инференса выделяют и освобождают тысячи тензоров в секунду. Стратегия аллокатора влияет на фрагментацию и задержку выделения.

Обзор аллокаторов

• BFC (Best-Fit with Coalescing) — аллокатор PyTorch по умолчанию. Захватывает большие блоки GPU и подразделяет их.
• Buddy-аллокатор — разбивает память на блоки со степенями двойки.
• Slab-аллокатор — работает поверх buddy-системы для эффективного управления небольшими объектами фиксированного размера.
• cudaMallocAsync — потоковый кэширующий аллокатор CUDA, управляемый драйвером.

Реализация переключения при OOM

import os
import sys
import gc
import pickle
import tempfile
import subprocess
def run_with_fallback_allocator(factory, request_fn):
    try:
        model = factory()
        return request_fn(model)
    except torch.cuda.OutOfMemoryError:
        gc.collect()
        torch.cuda.empty_cache()
        with tempfile.NamedTemporaryFile(suffix=".pkl", delete=False) as f:
            pickle.dump(factory, f)
            factory_path = f.name
        with tempfile.NamedTemporaryFile(suffix=".pkl", delete=False) as f:
            pickle.dump(request_fn, f)
            request_path = f.name
        output_path = tempfile.mktemp(suffix=".pkl")
        env = os.environ.copy()
        env["PYTORCH_ALLOC_CONF"] = "backend:cudaMallocAsync"
        subprocess.run([
            sys.executable, __file__, "--child",
            "--factory", factory_path,
            "--request", request_path,
            "--output", output_path,
        ], env=env, check=True)
        with open(output_path, "rb") as f:
            return pickle.load(f)

Мониторинг фрагментации

Используйте torch.cuda.memory_reserved() и torch.cuda.memory_allocated() для отслеживания фрагментации. Reserved — общая память, удерживаемая аллокатором. Allocated — сколько фактически используется тензорами. Большая разница указывает на фрагментацию.

19.9Улучшение производительности ядер на лету и горячая замена реализаций

В быстро развивающемся мире GPU-оборудования и алгоритмических инноваций постоянно появляются новые и более быстрые реализации ядер. Патчинг ядер во время выполнения — это возможность интегрировать новые реализации в работающую систему без полного переразвёртывания.

Пример: замена SDPA на FlashAttention-3

import types
def patch_attention_with_flash_attn3(module, new_flash_attn_lib):
    def new_forward(self, query, key, value, **kwargs):
        return new_flash_attn_lib.forward(
            query, key, value, **kwargs
        )
    module.forward = types.MethodType(new_forward, module)

Рекомендации

• Используйте хорошо определённые границы модулей.
• Мониторьте накладные расходы на поддержание нескольких реализаций в памяти.
• Популярные движки (vLLM, TensorRT-LLM, NVIDIA Dynamo) предоставляют механизмы плагинов времени выполнения.
• Комбинируйте с RL-стратегией: агент может выбирать, какую реализацию использовать для каждого типа запроса.

19.10Непрерывный прогрев CUDA-графов и кэшей с помощью временных рядов

В высокопроизводительном инференсе холодный старт — значительный фактор задержки. CUDA Graphs позволяют захватить последовательность операций GPU и воспроизвести её с минимальными накладными расходами на запуск.

Прогрев на основе прогнозирования

Используя алгоритмы прогнозирования временных рядов (ARIMA, Prophet), система предугадывает будущие паттерны нагрузки — всплески трафика, изменения размера батча — чтобы проактивно подготовить граф для быстрого выполнения.

Пул предварительно захваченных графов

import torch
static_input = torch.randn(batch_size, seq_len, hidden_dim, device="cuda")
graph = torch.cuda.CUDAGraph()
with torch.cuda.graph(graph):
    static_output = model(static_input)
def run_with_graph(input_tensor):
    static_input.copy_(input_tensor)
    graph.replay()
    return static_output.clone()

Координация с автомасштабированием

При запуске новых экземпляров GPU автомасштабировщик должен запускать набор вызовов API прогрева:

• Проверка движков инференса
• Кэширование выходов JIT-компиляции
• Выделение пулов памяти
• Подготовка CUDA-графов для каждого размера батча
• Прогрев draft-модели для спекулятивного декодирования

19.11Адаптивная пакетная обработка и планирование чанкового prefill

Адаптивная пакетная обработка динамически корректирует способ группировки запросов в батчи в зависимости от нагрузки. Во время пиковой нагрузки система использует большой размер батча (8 или 16), потому что пропускная способность критична. В периоды низкой нагрузки система уменьшает размер батча до 1 для минимизации задержки.

Чанковый prefill

Статья SARATHI продемонстрировала, что чанковый prefill и подсадка decode-запросов могут уменьшить пузыри конвейера и улучшить пропускную способность на ~1,3–1,9× по сравнению с наивным планированием[reference:6]. SARATHI разбивает prefill-запрос на равные чанки и выполняет decode-maximal batching, при котором decode-запросы «подсаживаются» в промежутки между чанками prefill.

В vLLM эта техника реализована через флаг enable_chunked_prefill=True. При включении vLLM меняет политику планирования: сначала батчатся все ожидающие decode-запросы, затем — prefill-чанки[reference:7]. Флаг --long-prefill-token-threshold задаёт порог, при котором prefill считается «длинным» и подлежит чанкованию[reference:8].

Пример: Запрос prefill на 10 000 токенов без чанкования заблокирует весь конвейер. При разбиении на пять чанков по 2 000 токенов можно чередовать батчи decode между чанками prefill.

Реализация адаптивного планировщика

import cupy as cp
TARGET_UTIL = 0.85
OCC_THRESHOLD = 0.50
BLOCK_THREADS = 256
def get_optimal_tile(seq_len):
    if seq_len < 256:
        return 64
    elif seq_len < 1024:
        return 128
    else:
        return 256
def scheduler_loop():
    stream = cp.cuda.Stream(non_blocking=True)
    while True:
        pending = get_pending_requests()
        util = gpu_utilization()
        if util < TARGET_UTIL and any(r.phase == 'prefill' for r in pending):
            req = select_heaviest_prefill(pending)
            L = req.remaining_length()
            T = get_optimal_tile(L)
            shared_bytes = 3 * T * T * 4

Разделение prefill и decode

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

19.12Планирование с учётом перегрузок и топологии для многоGPU-систем

Современные системы, такие как Grace Blackwell GB200 NVL72 (72 GPU B200, 180 ГБ HBM каждый) и GB300 NVL72 (72 GPU B300, 288 ГБ каждый), соединяют 72 GPU в единую фабрику NVLink/NVSwitch, обеспечивая каждому GPU до ~1,8 ТБ/с совокупной двунаправленной пропускной способности и более 130 ТБ/с совокупной поперечной пропускной способности.

19.12.1. Топология и ограничения пропускной способности

Понимание топологии — какие GPU совместно используют компоненты NVSwitch или пути NVLink — критически важно. GPU на одной плате или лотке имеют более быстрые и прямые пути по сравнению с GPU в разных лотках или узлах.

19.12.2. Топологически-осознанное размещение процессов

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

19.12.3. Оптимизация коллективных коммуникаций с NCCL

NCCL — стандарт для управления GPU-коллективами. Предлагает несколько алгоритмов:

• Кольцевой (Ring): лучше для больших сообщений, где доминирует пропускная способность.
• Древовидный (Tree): завершается за O(log N) шагов, лучше для чувствительных к задержке сокращений с небольшими сообщениями.
• Иерархический: комбинирует подходы для многоузловых сред.

19.12.4. Волновое планирование

Вместо одновременного обмена данными всех 72 GPU (72 × 71 сообщение) можно разделить обмен на 4 волны по 18 GPU. Это структурирует обмен как серию меньших all-to-all, использующих только подмножество GPU во время каждой волны.

19.12.5. Многоузловые коммуникации

• GPUDirect RDMA для обхода ненужных копий памяти.
• Multirail NIC — несколько NIC на узел (двойные порты InfiniBand) дают почти 2× пропускную способность.
• NIC affinity — привязку коммуникации каждого GPU к ближайшему NIC.
• Адаптивную маршрутизацию InfiniBand для автоматического перемещения перегруженных потоков.

19.12.6. Ребалансировка экспертов MoE

В MoE-моделях эксперты могут быть перераспределены между GPU на основе наблюдаемой нагрузки. Если один GPU перегружен экспертами, которые часто активируются, планировщик может перенести экспертов на менее загруженные GPU.

19.12.7. Динамическая балансировка во времени

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

19.12.8. Координация передач NVSwitch

NVSwitch имеет собственные внутренние алгоритмы планирования, включая адаптивную маршрутизацию по нескольким чипам и плоскостям коммутатора. Программное обеспечение может избежать достижения этих пределов, применяя адаптивные техники: ограничение числа тяжёлых передач, выполняемых параллельно, тонкая настройка параллелизма путём контроля конкуренции.

19.13Дополнительные адаптивные и динамические техники оптимизации

Далее приведены дополнительные техники, которые дополняют основные стратегии. На момент написания они экспериментальны, но перспективны.

Динамические сети с ранним выходом

Модели с ранним выходом позволяют LLM самостоятельно усекать генерацию при достижении достаточной уверенности. Методы отслеживают промежуточные представления и энтропию логитов для решения на каждом слое или токене, следует ли остановить вычисления. Требуют специальной архитектуры или обучения, но могут дать до 30–50% ускорения на задачах рассуждения без потери точности.

Пропуск слоёв с учётом входа (DASH)

Фреймворк DASH представляет инференс как марковский процесс принятия решений, который динамически решает для каждого токена, выполнять или пропускать каждый слой на основе характеристик входа[reference:11]. DASH моделирует процесс пропуска как MDP, позволяя принимать решения на уровне отдельных токенов на основе промежуточных представлений[reference:12]. Обучая небольшую сеть оценки, DASH может пропускать 20–40% слоёв для многих токенов.

Спекулятивная маршрутизация экспертов MoE

В MoE-моделях можно использовать предсказание маршрутизации для предзагрузки только тех экспертов, которые, вероятно, будут активированы, снижая коммуникацию и задержку.

Динамическое квантование активаций с отслеживанием статистики

Система отслеживает статистику активаций в реальном времени и пересчитывает диапазоны каждые N токенов. FP16 выделяется для «горячих» слоёв с высокой дисперсией, FP8 — для «холодных» с низкой дисперсией.

Динамическое прореживание токенов с LazyLLM

LazyLLM избирательно вычисляет KV-пары только для токенов, важных для предсказания следующего токена, как на этапе prefill, так и на этапе decode[reference:13]. Этот метод позволяет языковым моделям динамически выбирать различные подмножества токенов из контекста на разных шагах генерации, даже если некоторые из них были удалены на предыдущих шагах[reference:14].

Адаптивное декодирование и планирование

Используйте спекулятивное декодирование с динамическим выбором draft-модели, адаптивные стратегии beam search и динамическое управление температурой сэмплинга на основе уверенности модели.

Непрерывный профиль и автоматическая оптимизация

Используйте инструменты — NVML, Nsight Systems/Compute, инструментацию NVTX, метрики Prometheus — для выявления узких мест во время выполнения и автоматического применения оптимизаций графов и ядер.

19.14Проверка прогнозов и актуальные данные

Книга Fregly писалась в 2025 году. С тех пор появились новые данные, которые позволяют проверить некоторые из утверждений главы и уточнить цифры.

19.15Связи с другими главами книги

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

Связь с главой 15 (спекулятивное декодирование)

Раздел 19.5 (спекулятивная предзагрузка KV-кэша) перекликается со спекулятивным декодированием из главы 15. Однако механика принципиально различается: в главе 15 спекулятивные токены генерируются draft-моделью и верифицируются target-моделью. В главе 19 SpeCache предсказывает паттерн доступа к KV-кэшу, а не генерирует и проверяет токены[reference:25]. Это важно понимать, чтобы не путать две разные техники.

Связь с главой 16 (чанковый prefill в vLLM)

Раздел 19.11 (адаптивная пакетная обработка и планирование чанкового prefill) напрямую связан с главой 16, где описаны флаги vLLM. В vLLM enable_chunked_prefill=True активирует чанковый prefill, а планировщик меняет политику на decode-maximal batching[reference:26]. Порог --long-prefill-token-threshold задаёт, какие prefills считаются «длинными» и подлежат чанкованию[reference:27].

Связь с главами 17–18 (планирование prefill/decode)

Раздел 19.13 (разделение prefill и decode с маршрутизацией по контексту) тесно связан с главами 17 и 18, где описаны архитектуры disaggregated prefill/decode и планирование с учётом топологии. Глава 19 добавляет динамическую составляющую: разделение prefill и decode может быть как статическим (отдельные пулы GPU), так и динамическим, с маршрутизацией запросов на основе попаданий в KV-кэш и глубины очереди.

19.16Ключевые выводы

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

Стабильный инференс с torch.compile

Используйте torch.compile для стабилизации и оптимизации графа вычислений. Компилируйте модели с учётом динамических форм для поддержки переменных размеров батчей и длин последовательностей.

Динамическое управление точностью

Применяйте минимальную точность, которая сохраняет качество. Возвращайтесь к более высокой точности, когда уверенность модели падает. Используйте энтропию Шеннона и максимальную вероятность softmax как сигналы уверенности.

Автотюнинг ядер и разделяемой памяти

Поддерживайте таблицу оптимальных конфигураций для разных размеров задач. Используйте CUDA Occupancy API и DCGM для обратной связи. Проектируйте ядра с настраиваемыми параметрами времени выполнения.

Проактивное управление KV-кэшем

Используйте спекулятивную предзагрузку, квантование и переключение политик для управления памятью KV-кэша. Разделяйте prefill и decode по ресурсам с маршрутизацией по контексту.

Динамические стратегии параллелизма

Принимайте решения на лету между data-parallel, tensor-parallel, pipeline-parallel и гибридными комбинациями в зависимости от длин последовательностей и структуры модели — включая маршрутизацию MoE.

Адаптивное декодирование и планирование

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

RL-настройка

Начинайте с эвристик. Когда основы стабильны, используйте RL-агентов для обработки сложной настройки. Всегда имейте аварийный выход и логирование.

Непрерывный профиль и оптимизация

Используйте NVML, Nsight Systems/Compute, NVTX и Prometheus для выявления узких мест. Анализируйте телеметрию с помощью AI для обнаружения аномалий.

Заключение

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

Каждая стратегия — это инструмент в наборе инженера по производительности AI-систем. Наиболее эффективные решения обычно комбинируют эти инструменты. Не нужно реализовывать всё сразу. Даже одна или две техники могут дать заметные улучшения. Начните с самого простого — улучшения кэширования и пакетной обработки, — затем добавляйте остальные.

Тема этой главы — гибкость и адаптивность. Среда выполнения инференса должна перенастраиваться в ответ на текущую нагрузку. Именно так массивная LLM превращается в хорошо настроенный, масштабируемый production-сервис — эффективно и экономично.

Источники: Chris Fregly, «AI Systems Performance Engineering» (O'Reilly, 2026), Глава 19 — цитаты приводятся в ограниченном объёме в целях обзора и критического анализа. SpeCache: arXiv:2503.16163[reference:28]; DeepSeek-V3: 671B параметров, 37B активных[reference:29]; SARATHI: arXiv:2308.16369[reference:30]; DASH: arXiv:2505.xxxxx[reference:31]; LazyLLM: arXiv:2407.14057[reference:32]; ThunderMLA: Stanford HazyResearch[reference:33]; vLLM chunked prefill: официальная документация[reference:34].