Выбор агентской модели для кластеров из 2× DGX Spark (сентябрь 2026)
В сентябре 2026 года на Hugging Face есть 3 модели, которые хочется поставить на пару DGX Spark под Claude Code: DeepSeek‑V4.1-Flash на 552B, GLM-5.3-Flash на 320B и Qwen3.8-Flash‑Next на 125B. Первая лучше всех в бенчмарках, но не помещается в 243 ГиБ даже в 4 битах. Вторая занимает 198 ГБ и грузится 15 минут. Третья влезает в один спарк — если не считать 2 ГБ, которых ей не хватает. Ниже — почему на этом кластере выбор делает арифметика памяти, а не таблица бенчмарков, почему 6 миллиардов активных параметров не дают 90 ток/с, и почему для Claude Code решающим оказывается не tok/s, а один флаг vLLM, который в самом быстром конфиге выключен.
DSpark на двух DGX Spark: порт, баг на одну строку и бенчмарки, которые пришлось мерить заново
DeepSeek выпустил DSpark — спекулятивный декодер для V4. В окне 27–30 июня 2026 рабочего публичного пути для GB10 не было — мы портировали его сами, нашли унаследованный баг, убивавший качество драфта, и сняли профиль своего стенда. Потом комьюнити выложило рецепт вдвое быстрее нашего. Мы его воспроизвели — и вместо гонки за цифрой сняли данные, которых в паблике не нашли: кривую деградации до реального 1M, механизм выигрыша NVFP4 и петли когерентности на глубине. Плюс три негативных результата. TL;DRПорт состоялся.
DGX Spark на 256K контексте: тестирую конфигурации vLLM, реальные замеры и почему NVFP4 в mainline сломан
NVIDIA продаёт спарку с лозунгом «один петафлоп на FP4». Я купил коробку, поставил vLLM, запустил инференс и получил 40 токенов в секунду на 35B MoE‑модели. После маркетинговых слайдов цифра выглядит грустно.Объяснение простое. NVFP4 в основной ветке vLLM и FlashInfer физически сломан на SM_121 — варианте Blackwell, который установлен в GB10. Ядра собраны под compute_120f, а нативные NVFP4-инструкции есть только в compute_120a и compute_121a. На SM_121 распаковка квантованных весов идёт через программные битовые манипуляции в шейдере, без участия тензорных ядер.
