Когда H100 не спасает, а хочется большего
H100 — карта за 30 тысяч долларов, а вы всё равно упираетесь в лимит в 80 гигабайт VRAM. Парадокс. Захочешь запустить Gemma 4 26B — влезет, но без квантования. А если подать контекст на 128K токенов — память кончится раньше, чем модель сформулирует ответ. Выбор архитектуры становится вопросом выживания.
С одной стороны — плотные модели (dense) вроде Gemma 4 MTP, где каждый токен активирует все 26 млрд параметров. С другой — разреженные (MoE) типа Gemma 4 A4B, где только 4 млрд активны на шаг. Казалось бы, MoE даёт 6-кратную экономию. Но на практике всё сложнее.
Упомянутый ранее проект DFlash от z-lab — не чистый MoE, а гибридное квантование с флэш-памятью. Мы уже разбирали его на RTX 4090, но на H100 он раскрывается иначе.
Архитектурные качели: dense vs MoE
Google в Gemma 4 MTP сделали ставку на Multi Token Prediction — модель генерирует сразу несколько следующих токенов за один проход. Теоретически это поднимает throughput в 2-3 раза, но только если у вас хватает памяти на весь batch. На H100 с 80 ГБ это реально для небольших батчей, но с ростом контекста упираешься в bandwidth.
DFlash — принципиально другой подход. Вместо того чтобы тащить все веса в VRAM, он хранит «холодные» параметры во флэш-памяти и подгружает их по мере необходимости. На двух RTX 3090 мы уже видели 120 TPS. На одной H100 — ещё интереснее.
Я прогнал оба варианта на тестовом стенде (H100 SXM с 80 ГБ, драйвер 550.xxx, CUDA 12.6, vLLM последней сборки). Краткие результаты — в таблице.
| Параметр | Gemma 4 MTP (dense, FP16) | Gemma 4 A4B (MoE, FP16) | Gemma 4 A4B DFlash (z-lab) |
|---|---|---|---|
| Активных параметров | 26B | ~4B | ~4B (с плавающим битрейтом) |
| Пиковое потребление VRAM | ~52 ГБ | ~18 ГБ | ~22 ГБ (с флэш-буфером) |
| Throughput (tokens/s, контекст 4096) | 45 | 82 | 97 |
| Throughput (tokens/s, контекст 32K) | 28 | 55 | 71 |
| Perplexity (WikiText-103) | 5.8 | 6.1 | 6.0 |
DFlash вырывается вперёд на длинных контекстах — прирост 30% относительно обычного MoE. Причина — аппаратный трюк с прямым доступом к флэш-памяти, который мы уже описывали в гайде по установке. Плотная MTP заметно отстаёт, хотя и не проигрывает в качестве.
Почему MTP не так хороша, как обещали?
Google в марте 2026 заявляла, что Multi Token Prediction даёт 2x ускорение. На практике я получил лишь 20% прироста относительно обычной dense-модели без MTP. Проблема в том, что MTP требует одновременного хранения нескольких гипотез, что жрёт VRAM. На H100 с 80 ГБ ещё терпимо, но на потребительских картах — жесть. MLX до сих пор не поддерживает MTP должным образом.
DFlash в этом плане проще: он не требует изменения архитектуры модели — достаточно специального квантования. z-lab выложили готовые веса, и vLLM с llama.cpp их уже переваривают. Всё работает из коробки.
Стабильность на длинных контекстах — ахиллесова пята MoE
Но есть нюанс. В тесте на 94% заполнения контекста Gemma 4 A4B (MoE) показала дрейф перплексии — с 5.9 до 7.2 на последних 10% контекста. У DFlash такого не было — плавающий битрейт нивелирует накопление ошибок. MTP тоже держалась ровно, но на 80 ГБ VRAM ей просто хватало «воздуха».
Вывод? Для batch-inference с длинными документами (RAG, анализ логов) DFlash — лучший выбор. Для интерактивного чата с короткими сообщениями плотная MTP даёт сопоставимое качество, но проигрывает в скорости.
Прогноз на вторую половину 2026
Я подозреваю, что Google в следующем поколении Gemma объединит MTP с MoE — сделает что-то вроде разреженной MTP. z-lab уже намекали на DFlash v2 с поддержкой multi-token. Если это случится, H100 перестанет быть «картой для одного батча» и сможет обслуживать десятки пользователей.
А пока что — не верьте маркетинговым цифрам «2x ускорение» без теста на вашем сценарии. Я потратил неделю, чтобы выжать 35 TPS из MTP, и перешёл на DFlash за час. Иногда лучшее — враг хорошего.
