Это страница-конспект. Полный разбор — со всеми перебранными конфигурациями, логами и таблицами — наш лонгрид на Хабре; все числа ниже — цитаты оттуда, не клеймы нашего реестра.
Сначала — привязка к версиям. Всё описанное измерено в мае 2026 на одной машине: vLLM линейки 0.15 с PyTorch 2.10, FlashInfer 0.6.8, драйвер 580.142, CUDA 13.0, DGX OS 7.5.0. Mainline движется каждую неделю: что было сломано тогда, сегодня может быть починено, и наоборот. Это датированное свидетельство, а не вечная истина — сверяйтесь с upstream перед тем, как повторять выводы.
Задача и охота за конфигом
Один DGX Spark: GB10, Blackwell SM_121, 128 ГиБ unified-памяти на 273 ГБ/с . Цель — окно в 262 144 токена для MoE класса Qwen3.6-35B-A3B. По дороге не завелось почти всё: FP8-attention во FlashInfer собран под sm120 и на SM_121 падает; эвристика CUTLASS/FA3 для FP4 требует нулевой минорной compute capability и исключает GB10 по построению; Triton-фолбэк стабилен, но заметно медленнее. Флаги MoE пришлось выставлять руками: FP4-путь — выключить (автотюнер отбрасывал десять из семнадцати тактик ), FP8-путь — включить. Полный захват CUDA-графа на сборках 0.15 виснет, лечится режимом piecewise. Драйвер закреплён на 580.142: ветка 590 текла по unified-памяти, а 595 ломала NVFP4 нелегальным доступом к памяти. Почему штатный мониторинг при этом молчит — отдельный отчёт.
Почему NVFP4 в mainline был сломан
В закреплённой нами mainline-сборке ядра NVFP4 были собраны под
compute_120f, а нативные NVFP4-инструкции существуют только в
compute_120a и compute_121a. На SM_121 это означало распаковку весов
софтом, битовыми операциями в шейдере, мимо тензорных ядер. Итог измерим:
квантизация с вдвое меньшим весом в памяти декодировала медленнее FP8 — 40,9 против 51,2 tok/s в один поток на конфигурации 260K .
Подчеркнём время глагола: NVFP4 был сломан в той сборке, на том чипе, в
ту дату — это пробел компиляции, а не свойство железа. Upstream-трекер —
issue flashinfer #3170, аудит SM_121.
Что в итоге заработало
Самая быстрая связка, удержавшая 260K, не похожа на стоковую: vLLM из исходников с семью локальными патчами, FlashInfer 0.6.8 с двумя PR, community-чекпоинт AEON-7 в NVFP4 и block-diffusion-драфтер DFlash на пятнадцать спекулятивных токенов. Ловушка быстрого пути: этот файнтюн ломает tool calling, поэтому для агентных сценариев рекомендация из статьи — обычный Qwen3.6-FP8 на стоковом vLLM: медленнее, зато вызовы функций возвращаются целыми.
Замеры одной машины, цитатами: у AEON-7 с DFlash средний декод 69,7 tok/s при пике 107 ; у FP8 — 51,2 tok/s в один поток и 349,2 на 32 параллельных запросах ; mainline-NVFP4 давал 40,9 . Само окно оказалось почти бесплатным: рост с 65K до 260K стоил около двух с половиной процентов однопоточного декода , а активный контекст одного пользователя редко превышал 30K из 260K . Потолок — не маркетинговый петафлопс, а пропускная способность памяти: roofline статьи упирает спекулятивный декод примерно в 320 tok/s .
Честная секция
Всё это — lab_single_run: одна лаборатория, одна машина, одиночные
прогоны; числа — цитаты из нашей же статьи со всеми её оговорками. Рецепт
двухнодового серв-стека с его ловушками —
отдельная страница,
а почему опубликованные цифры про Spark расходятся между собой —
собственное расследование.