NVIDIA DGX Spark: NVFP4 в vLLM сломан на уровне архитектуры, реальная производительность далека от заявленного петафлопа

NVIDIA продаёт DGX Spark под лозунгом «один петафлоп на FP4», но реальный инференс выдаёт 40 токенов в секунду на 35B MoE-модели — цифра, которая после маркетинговых обещаний выглядит удручающе. Причина кроется не в пользовательской ошибке, а в фундаментальной несовместимости: NVFP4 в основной ветке vLLM и FlashInfer физически не работает на SM_121 — варианте архитектуры Blackwell, установленном в GB10.

Техническая суть проблемы: ядра собраны под compute_120f, тогда как нативные NVFP4-инструкции существуют только в compute_120a и compute_121a. На SM_121 распаковка квантованных весов идёт через программные битовые манипуляции в шейдере — без участия тензорных ядер. Это означает, что заявленное ускорение от FP4-квантования на текущих конфигурациях просто недостижимо. Сообщество уже нашло обходные пути и собрало рабочие конфигурации, но они требуют ручной доработки и не доступны из коробки.

Автор прогнал шесть различных конфигураций vLLM на своём DGX Spark — от стокового BF16 до форка с DFlash speculative decoding — и замерил каждую идентичным тестом. Результаты показывают, что выбор конфигурации критически влияет на производительность, а официальная документация не отражает реальное положение дел. Для инженеров и команд, планирующих внедрение DGX Spark в продакшн, это сигнал: маркетинговые спецификации требуют независимой верификации, а рабочие решения придётся собирать самостоятельно или ждать патчей от сообщества.