Возможен ли стриминг-инференс MoE в условиях нехватки памяти?
Да, технически это возможно. TensorRT-LLM и DeepSpeed позволяют запускать полновесные Mixture-of-Experts модели в FP32/FP16 на конфигурациях, где совокупный объём VRAM и системной оперативной памяти меньше размера весов. Однако реальная производительность измеряется единицами токенов в секунду, а успешные кейсы за пределами академических лабораторий остаются редкостью.
Ключевой механизм - псевдо-унифицированная память. Фреймворк создаёт иллюзию единого адресного пространства, физически распределённого между GPU и CPU RAM. Когда модель требует эксперта, отсутствующего в VRAM, данные подгружаются с системной памяти через PCIe. Для моделей уровня DeepSeek-V4-Pro-NVFP4, требующих в штатном режиме H200 141GB HBM3 или H100 80GB, это единственный способ запуска на потребительском железе без квантизации.
Плата за такой подход - радикальное падение скорости. При инференсе плотных моделей оффлоадинг ещё может давать приемлемые результаты, но разреженная активация MoE создаёт паттерны доступа к памяти, которые сводят на нет все оптимизации предвыборки. Результат: вместо сотен токенов/с вы получаете 1-5, и это в лучшем случае.
Прежде чем погружаться в детали, стоит зафиксировать: стриминг-инференс MoE - нишевый инструмент для оффлайн-обработки и экспериментов. Для интерактивных сценариев он непригоден. Если ваша цель - чат-бот с быстрым откликом, этот путь ведёт в тупик.
Как работает стриминг параметров в MoE-моделях
Архитектура Mixture-of-Experts принципиально отличается от плотных моделей. Вместо активации всех параметров на каждом токене, MoE задействует лишь подмножество экспертов - обычно 2 из 8 или 8 из 256. Это даёт огромную экономию вычислений, но создаёт проблему для стриминга: роутер непредсказуемо переключает экспертов между токенами, и фреймворк не может эффективно предзагрузить нужные веса.
Плотная модель при оффлоадинге страдает предсказуемо: слои загружаются последовательно, и задержка PCIe амортизируется пайплайнингом. MoE ломает эту схему. Эксперт, понадобившийся для текущего токена, может отсутствовать в VRAM. Фреймворк вынужден ждать его подгрузки, блокируя весь конвейер. При длине последовательности в тысячи токенов такие остановки накапливаются, превращая генерацию в серию рывков с паузами.
Исследователи уже ищут способы обойти это ограничение. Одно из направлений - предсказание загрузки экспертов через MTP-головку, уже присутствующую в некоторых моделях для спекулятивного декодирования. Эксперимент с Qwen 3.6 35B A3B показал 78% точности предсказания при top-8, что теоретически поднимает скорость с 35 до 180-200 токенов/с. Но это пока исследовательский прототип, а не готовый продакшен-инструмент.
Роль псевдо-унифицированной памяти в TensorRT-LLM и DeepSpeed
TensorRT-LLM реализует managed memory через CUDA Unified Memory. GPU и CPU разделяют виртуальное адресное пространство, а драйвер NVIDIA автоматически мигрирует страницы памяти при промахах. Для MoE это означает, что отсутствующий эксперт будет подтянут с CPU RAM по требованию. Проблема в том, что миграция происходит на уровне страниц (обычно 64 КБ), и при первом обращении весь блок ждёт завершения передачи. TensorRT-LLM пытается смягчить удар через асинхронную предвыборку, но для разреженных паттернов MoE точность предсказания низка.
DeepSpeed идёт другим путём - ZeRO-Infinity. Этот механизм изначально проектировался для обучения, но адаптирован для инференса. Вместо полагания на автоматическую миграцию, ZeRO-Infinity явно управляет размещением тензоров: активные эксперты держатся в VRAM, неактивные вытесняются в CPU RAM или даже на NVMe-диск. Планировщик DeepSpeed отслеживает паттерны использования и пытается предзагружать экспертов до того, как они понадобятся. На практике для MoE с сотнями экспертов точность такого предсказания редко превышает 50-60%, и каждый промах обходится в миллисекунды задержки.
Выбор между подходами сводится к компромиссу: TensorRT-LLM проще в настройке и лучше интегрирован с экосистемой NVIDIA, но даёт меньше контроля. DeepSpeed требует тонкой конфигурации (размеры кэшей, стратегии вытеснения, параметры предвыборки), но позволяет выжать максимум из доступного железа. Сравнение бэкендов для инференса LLM даёт более широкий контекст по производительности на H100 и B200, хотя стриминг MoE там не был в фокусе.
Реальная производительность: цифры и ожидания
Конкретные бенчмарки стриминг-инференса MoE в открытом доступе практически отсутствуют - это один из признаков незрелости направления. По косвенным данным из баг-репортов и сообщений разработчиков, скорость генерации на конфигурациях с одной RTX 4090 24GB и 64GB системной RAM для моделей класса DeepSeek-V3 (671B параметров, ~37B активных) не превышает 2-4 токенов/с в FP16. Этого достаточно для пакетной обработки, но диалог с задержкой 250-500 мс на токен превращается в испытание терпения.
Для сравнения: та же RTX 4090 на плотной модели Llama-3-70B с квантованием Q4 выдаёт 40-60 токенов/с. Разрыв на порядок объясняется не объёмом вычислений, а именно паттерном доступа к памяти. Плотная модель после квантования целиком помещается в VRAM, и инференс упирается в вычислительную пропускную способность GPU. MoE со стримингом упирается в пропускную способность PCIe - 32-64 ГБ/с для PCIe 4.0 x16 против 1-2 ТБ/с пропускной способности VRAM.
Ситуация усугубляется для моделей с большим числом экспертов. DeepSeek-V4-Pro-NVFP4 использует тонкую гранулярность экспертов, и роутер часто переключает их между соседними токенами. Каждое переключение потенциально означает промах в кэше и загрузку нового эксперта. При 8 экспертах на токен и длине генерации в 100 токенов это до 800 обращений к памяти, каждое из которых может обернуться задержкой PCIe.
Почему стриминг-инференс MoE медленнее, чем для плотных моделей
Фундаментальная причина - энтропия паттернов доступа. Плотная модель активирует все параметры последовательно, слой за слоем. Предвыборка тривиальна: пока вычисляется слой N, слой N+1 уже загружается в VRAM. MoE активирует экспертов выборочно и непредсказуемо. Роутер принимает решение на основе скрытого состояния текущего токена, которое становится известно только после вычисления предыдущего слоя. Предзагрузить эксперта до того, как роутер примет решение, можно только вероятностно.
Исследование распределения использования экспертов в MoE выявило степенной закон: небольшая группа экспертов активируется часто, остальные - редко. Это открывает возможность для кэширования. Если держать топ-20% экспертов в VRAM постоянно, а остальные подгружать по требованию, можно сократить количество промахов. Но даже в этом случае холодный старт для редко используемых экспертов неизбежен, и каждый такой промах стоит сотен микросекунд задержки.
Ещё один фактор - фрагментация памяти. При активном оффлоадинге VRAM быстро превращается в лоскутное одеяло из загруженных экспертов, KV-кэша и промежуточных тензоров. Аллокатор вынужден постоянно дефрагментировать память, что добавляет накладные расходы. В предельных случаях фрагментация может привести к ситуации, когда свободной памяти достаточно для загрузки эксперта, но нет непрерывного блока нужного размера - и фреймворк падает с OOM, несмотря на формально доступный объём.
Успешные кейсы и подводные камни
За пределами академических статей задокументированных успешных кейсов стриминг-инференса MoE в продакшене практически нет. Сообщества разработчиков (r/LocalLLaMA, GitHub Issues) содержат отдельные отчёты энтузиастов, запускавших DeepSeek-V3 на конфигурациях с 2x RTX 3090 и 128GB RAM, но все они сходятся в одном: скорость генерации 1-3 токен/с, стабильность неудовлетворительная, а для сколько-нибудь серьёзной работы такой режим непригоден.
Показателен пользовательский опыт тестирования крупных MoE-моделей на ограниченном железе. Сравнение Qwen3.5 122B A10B и Qwen3 Next 80B в 64 ГБ RAM показало парадоксальную ситуацию: более тяжёлая модель с квантованием UD-Q2_K_XL даёт качественно лучшие ответы, чем меньшая с UD-Q4_K_XL, но скорость падает до ~2.9 токенов/с. Основное узкое место - обработка промптов на CPU, делающая невозможным использование в агентских нагрузках. Без квантования, в полной точности, скорость была бы ещё на порядок ниже.
Отдельного упоминания заслуживает проект Eider - кастомный инференс-рантайм под архитектуру SM121 (GB10), реализующий свопинг неактивных экспертов на диск. В отличие от vLLM и llama.cpp, Eider способен загружать модели целиком, выгружая неиспользуемых экспертов. Это демонстрирует, что инженерная мысль движется в сторону более агрессивного оффлоадинга, но пока такие решения остаются экспериментальными и привязанными к специфическому железу.
Баг SGLang с DP-attention: когда вывод становится мусором
Даже когда стриминг-инференс удаётся запустить, нет гарантии корректности вывода. В SGLang зафиксирован баг при использовании DP-attention с tensor-parallel-size=16 и data-parallel-size=4. Функция dp_gather_partial применяется к данным, которые уже реплицированы, что приводит к умножению скрытых состояний в attn-TP раз. Результат - численно-мусорный вывод, внешне похожий на осмысленный текст, но семантически бессвязный.
Условия возникновения бага специфичны, но сама ситуация показательна: распределённый инференс MoE с оффлоадингом нагружает редко используемые кодовые пути фреймворков, где вероятность ошибок выше. Разработчик, запускающий полновесную модель на нецелевом железе, фактически становится бета-тестером.
Ограничения поддержки форматов: DeepEP и Marlin NVFP4
Выбор фреймворка дополнительно ограничен поддержкой специфичных форматов сжатия. DeepEP - оптимизированная библиотека для MoE-коммуникаций - не зарегистрирована для пути Marlin NVFP4 на архитектуре Hopper. Это означает, что модель в формате NVFP4 (используемом в DeepSeek-V4-Pro) не сможет использовать DeepEP для передачи экспертов, даже если фреймворк в целом поддерживает стриминг. Разработчик вынужден либо отказаться от NVFP4, либо искать обходные пути, либо менять фреймворк.
Такие нестыковки типичны для rapidly evolving экосистемы. Форматы сжатия появляются быстрее, чем фреймворки успевают их интегрировать, и стриминг-инференс - периферийный сценарий, который не в приоритете у мейнтейнеров.
Сравнение TensorRT-LLM и DeepSpeed для стриминг-инференса MoE
Выбор между двумя основными инструментами определяется конкретными ограничениями вашего сетапа.
TensorRT-LLM жёстко привязан к экосистеме NVIDIA. Он требует сборки движка под конкретную модель и GPU, что означает дополнительные шаги при смене конфигурации. Для MoE с сотнями экспертов сборка движка может занимать часы и потреблять десятки гигабайт оперативной памяти. Плюс - максимальная производительность на поддерживаемых конфигурациях и зрелая система профилирования. Минус - ограниченная гибкость: если модель не поддерживается официально, запустить её через TensorRT-LLM практически невозможно.
DeepSpeed более гибок. ZeRO-Infinity работает на уровне PyTorch-тензоров и не требует предварительной компиляции. Это позволяет запускать произвольные MoE-модели, включая кастомные архитектуры. Цена гибкости - более высокие накладные расходы: отсутствие статической оптимизации графа вычислений означает, что каждый промах кэша экспертов обрабатывается через Python-рантайм, добавляя единицы миллисекунд задержки. Для моделей с частым переключением экспертов эти миллисекунды быстро складываются в секунды.
Практический критерий выбора: если ваша модель официально поддерживается TensorRT-LLM и вы работаете на NVIDIA GPU - используйте TensorRT-LLM. Если модель экзотическая или вы экспериментируете с разными конфигурациями оффлоадинга - DeepSpeed даст больше контроля. В обоих случаях приготовьтесь к тому, что скорость будет измеряться единицами токенов/с.
Минимальные аппаратные требования и альтернативы
Стриминг-инференс не отменяет потребности в максимально возможном объёме VRAM. Каждый гигабайт на GPU сокращает количество промахов и повышает скорость. Для моделей класса DeepSeek-V3 (671B параметров в FP16, ~1.3 ТБ весов) разумный минимум - GPU с 24GB VRAM (RTX 4090) и 128GB системной RAM. Меньшие конфигурации технически могут работать, но скорость упадёт до долей токена в секунду, что обессмысливает затею.
Для моделей с меньшим числом параметров, таких как Qwen 3.6 35B A3B, требования скромнее: 16GB VRAM и 64GB RAM достаточно для запуска в FP16 со стримингом. Но и здесь скорость будет на грани пригодности - 5-10 токенов/с в лучшем случае.
Альтернативы стриминг-инференсу стоит рассмотреть до того, как ввязываться в этот технологический квест. Квантование - самый очевидный путь. Разбор производительности GLM-5.2 в INT4/INT8 показывает, что хорошо реализованное квантование сохраняет приемлемое качество при радикальном сокращении требований к памяти. Если ваша задача допускает небольшое снижение точности, квантование даст на порядок более высокую скорость, чем стриминг полной точности.
Дистилляция - другой путь. Вместо запуска 671B-параметрической MoE-модели можно использовать дистиллированную плотную версию на 70B параметров, которая помещается в VRAM одной-двух карт и работает без оффлоадинга. Качество будет ниже, но скорость - на два порядка выше.
CPU-инференс через llama.cpp с оптимизациями под AVX-512 и AMX для современных процессоров может дать 2-5 токенов/с на моделях до 70B параметров в Q4. Для MoE в полной точности этот путь неприменим из-за объёма вычислений, но для квантованных версий - вполне рабочая альтернатива.
Облачный инференс - прагматичный выбор для тех, кому нужна полная точность эпизодически. Анализ цен DeepSeek и конкурентов в 2026 году показывает, что стоимость API-доступа к полновесным MoE-моделям продолжает снижаться. Для нерегулярных задач аренда GPU в облаке или использование API обходится дешевле, чем покупка железа под стриминг-инференс.
Выводы: когда стриминг-инференс MoE оправдан
Стриминг-инференс MoE в полной точности - решение для двух сценариев. Первый: исследовательские задачи, где важна воспроизводимость результатов и недопустима потеря точности из-за квантования. Второй: пакетная обработка больших объёмов текста, где задержка некритична, а качество важнее скорости. Для всего остального - чат-ботов, агентов, интерактивных систем - этот подход создаёт больше проблем, чем решает.
Технология находится в ранней стадии зрелости. Баги вроде dp_gather_partial в SGLang, ограничения поддержки форматов, отсутствие стабильных бенчмарков - всё это признаки того, что стриминг-инференс MoE пока не готов к продакшену. Энтузиасты могут получить работающий, но медленный инференс; инженеры, отвечающие за SLA, найдут здесь только головную боль.
Практическая рекомендация: начните с квантования. Если качество квантованной модели неприемлемо для вашей задачи, попробуйте дистилляцию или облачный инференс. Стриминг полной точности оставьте на случай, когда все остальные пути перебраны и низкая скорость не является блокирующим фактором. Технология развивается, и появление эффективного предсказания загрузки экспертов может изменить картину, но сегодня это инструмент для терпеливых.