Выбор агентской модели для кластеров из 2× DGX Spark (сентябрь 2026)

К сентябрю 2026 года на Hugging Face появились три интригующие модели, идеально подходящие для связки из двух DGX Spark под управлением Claude Code: DeepSeek‑V4.1-Flash (552B параметров), GLM-5.3-Flash (320B) и Qwen3.8-Flash‑Next (125B). Лидер бенчмарков DeepSeek безнадежно велик — он не помещается в 243 ГиБ даже при 4-битной квантовании. Вторая модель требует 198 ГБ и загружается целых 15 минут. Третья почти вписывается в один Spark, не хватая всего пары гигабайт. Ниже мы разберем, почему на этом кластере всё решает жесткая арифметика памяти, а не рекламные таблицы, почему скромные 6 миллиардов активных параметров не гарантируют бешеные 90 ток/с, и почему ключевым фактором для Claude Code внезапно становится один-единственный флаг vLLM, который в самом быстром конфиге по умолчанию отключен.

Около полутора месяцев назад я развернул deepseek-ai/DeepSeek-V4-Flash-0731 с тензорным параллелизмом на два узла. Скорость держалась на отметке около 57 ток/с, что долгое время оставалось безусловным фаворитом. Однако за последние три недели релизнули трех новичков, каждый из которых на бумаге превосходит мою текущую сборку, вновь порождая муки выбора. Стратегия осталась неизменной: скрупулезный расчет до скачивания, а не после.

Для начала обрисуем конфигурацию стенда — именно от его параметров отталкиваются все дальнейшие расчеты.

Стенд: два спарка с объединённой памятью

Каждый узел Spark построен на суперчипе NVIDIA GB10 Grace Blackwell: 20 ядер Arm v9.2-A (десять Cortex‑X925 и десять Cortex‑A725), графический чип архитектуры Blackwell с compute capability 12.1 и теплопакетом порядка 140 Вт.

Ключевая особенность этого железа кроется вовсе не в терафлопсах, а в унифицированной архитектуре памяти. Установленные 128 ГБ LPDDR5x-9400 на узел служат одновременно системной RAM и видеопамятью — дискретной VRAM здесь попросту нет. Привычные схемы вроде «отдадим модели 88 ГБ, а остальное скинем в хост» здесь нежизнеспособны: выгружать данные некуда, ведь пул единый, и любое такое действие лишь отъедает ресурсы у самой модели. Пользователю из 128 ГБ доступно 121,6 ГиБ, то есть на всю пару приходится ровно 243 ГиБ. От этой цифры мы и будем отталкиваться.

Узлы связаны напрямую по схеме point-to-point посредством ConnectX-7 и кабелей QSFP56. Июльские тесты показали пропускную способность около 17 Гбит/с в один TCP-поток, около 107 Гбит/с в 8 параллельных потоков и примерно 19 ГБ/с на NCCL поверх RoCE при задействовании обоих интерфейсов PCIe. Контроллер ConnectX-7 подключен к системе двумя линиями PCIe Gen5 x4 и видится как пара адаптеров, где одиночный лимит упирается в 13,9 ГБ/с. Стандартный гигабитный Ethernet выдает 943 Мбит/с по iperf3 и используется исключительно для администрирования, тогда как тяжелые веса моделей храятся локально на узлах.

Взаимодействие с Claude Code организовано через шлюз free‑claude‑code, транслирующий запросы Anthropic API в локальный формат vLLM. Благодаря этому стандартные модели от Anthropic (Opus, Sonnet, Haiku, Fable) прозрачно подменяются одной локальной.

Исходные метрики текущего стека таковы: веса DeepSeek-V4-Flash весят 155 ГиБ и распределены поровну между нодами, сервер API и планировщик vLLM запущены на первой. Скорость генерации составляет 57,54 ± 5,61 ток/с в однопоточном режиме (медиана с разбросом около 20% между запусками, что диктует необходимость учета погрешности). Префилл держится на уровне 1600–2000 ток/с, размер KV-пула составляет примерно 699 тысяч токенов при контекстном окне 262 144, а холодный старт занимает около 5 минут.

Калькулятор важнее бенчмарка

Десятого сентября состоялся релиз DeepSeek‑V4.1-Flash. Заявленные характеристики сулили сокрушительную победу над моим сетапом, и первой мыслью было срочно запустить загрузку. Вторые мысли обычно приходят после изучения config.json.

Архитектура включает 552 миллиарда параметров в самом трансформере и еще 196 миллиардов в таблице n-грамм Engram, которая опрашивается на каждом токене. В 4-битном представлении один лишь трансформер отъедает около 276 ГБ. Наша пара DGX Spark располагает суммарно 2 × 121,6 ГиБ = 243 ГиБ, причем без учета KV-кэша. Иными словами, модель не поместится ни в одну адекватную квантовую схему: для нее требуется минимум 3–4 спарка, в то время как у меня их всего два (хотя четырехсерверные кластеры в сети встречаются).

В этот момент закономерно всплывает мысль: «А как же NVFP4?». Увы, это заблуждение: эксперты DeepSeek изначально упакованы в формат MXFP4 (4 бита на вес). NVFP4 предлагает лишь альтернативный метод масштабирования при тех же 4 битах, а не двукратное сжатие.

Итог закономерен: лидер месяца сошел с дистанции за пять минут без единого скачанного килобайта. Переходим к следующему претенденту.

Почему на двух Spark решает память, а не скорость соединения

Многоузловые конфигурации традиционно вызывают опасения насчет узкой горловины межсетевого взаимодействия, через которое на каждом токене прогоняется коллективная операция all-reduce. Однако при тензорном параллелизме MoE-моделей по проводам летает лишь вектор скрытого состояния — это мизерные объемы в несколько мегабайт, тогда как интерфейс прокачивает 18–19 ГБ/с. Сеть загружена на сущие доли процента.

Все упирается исключительно в память.

Во-первых, критичен чистый объем. Тензорный параллелизм дробит весовые матрицы так, чтобы каждый узел хранил и обрабатывал лишь свою долю, синхронизируя результаты через all-reduce. Следовательно, суммарный вес должен строго укладываться в 243 ГиБ с равным делением пополам. Для GLM с ее 198 ГБ (≈184 ГиБ) это означает 92 ГиБ весов на узел из 121,6 доступных. При параметре gpu-memory-utilization 0.85 под KV-кэш и активации остается около 11 ГиБ на ноду. Именно поэтому размер KV-кэша жестко зафиксирован флагом --kv-cache-memory 6 GiB, а не отдан на откуп автоматике.

Во-вторых, важна пропускная способность памяти. Генерация каждого нового токена требует считывания всех активных весов. Паспортная пропускная способность памяти GB10 составляет 273 ГБ/с (данные производителя). У GLM активно 18B параметров, что в 4-битном формате дает около 9 ГБ на токен. При разделении на два узла нагрузка падает до 4,5 ГБ на ноду, ограничивая теоретический потолок на отметке около 60 ток/с в один поток (без спекулятивного декодирования). Грубый расчет показывает, что быстрее 60 ток/с эта модель физически не поедет, а все заманчивые заявления о «100 ток/с» на сторонних графиках наверняка получены за счет спекулятивной генерации.

По аналогичной логике Qwen3.8-Flash‑Next с ее 6 активными миллиардами параметров должна развивать втрое большую скорость. Однако суровая реальность оказалась иной, чему посвящена вторая половина статьи.

GLM-5.3-Flash, 198 ГБ и 15 минут загрузки

Модель GLM-5.3-Flash дебютировала 26 августа: 320B общих параметров, 18B активных, лицензия MIT, нативная поддержка мультимодальности (изображения) и миллионный контекст. Согласно публикации на z.ai, в бенчмарке Code Bench внутри Claude Code она набирает 29,0 балла против 29,5 у Opus 4.8. Цифры разработчиков — вещь умозрительная, но показателен сам контекст: тесты прогонялись внутри Claude Code 2.1.207, то есть в абсолютно идентичном моему рабочем окружении.

На Hugging Face под нее доступны две версии в формате NVFP4, и здесь легко оступиться. Вариант от NVIDIA (ModelOpt) безбожно портит аргументы tool calling: вместо корректных данных приходит «битая» строка, из-за чего Claude Code безмолвно теряет вызовы инструментов (vLLM #54150). Единственный рабочий вариант — RedHatAI/GLM-5.3-Flash-NVFP4 в сжатом тензорном формате W4A4 (10 шардов по 20 ГБ плюс 7,6 ГБ головы MTP, итого около 198 ГБ).

Готовый конфиг для пары DGX Spark от tonyd2wild включает собственный образ vLLM под архитектуру sm121, легковесную модель DFlash2 (2,3 ГБ) для спекулятивного декодирования с k = 7, патч разреженного внимания для обхода ошибок top-k на SM121, а также параметры --block-size 2304, квантование KV-кэша в fp8 и --enforce-eager. Автор заявляет о 46,9 ток/с в однопоточном режиме на кодовых задачах (и около 56 суммарно при 5 параллельных запросах), KV-пул емкостью 581–678 тысяч токенов и холодную загрузку около 15 минут. Сопоставляя это с моим расчетным потолком в 60 ток/с, получаем около 78% эффективности со спекуляцией — вполне правдоподобный результат.

Пара критически важных нюансов из README:

1. Необходимо активировать подкачку (swap) со значением swappiness=0, иначе пиковые нагрузки при заливке 198 ГБ уложат систему. На моем кластере подкачка отключена намеренно. Без нее превышение лимита в 128 ГБ мгновенно триггерит ошибку CUDA OOM. С включенным swap машина на часы уходит в глубокий уход в файл подкачки: формально система жива, но функционировать не способна.

2. Перед запуском обязательно выполнять echo 3 > drop_caches. Без этого страничный кэш от прошлой модели займет драгоценную память, необходимую загрузчику. Ритуал кажется суеверием ровно до тех пор, пока вы не столкнетесь с OOM на 190-м гигабайте.

Qwen3.8-Flash‑Next, 133 ГБ и спарк, в который она почти помещается

Qwen3.8-Flash‑Next — предвестник четвертого поколения семейства Qwen: 125B общих параметров, 6B активных, дополненных 51B в таблице n-грамм PLE и 4B в MTP-голове. Заявлена нативная поддержка 262K контекста (расширяемого до миллиона через YaRN) и картинок. Квантованная сборка nvidia/Qwen3.8-Flash-Next-NVFP4 весит около 133 ГБ. По утверждению NVIDIA, по качеству генерации этот NVFP4 неотличим от FP8.

Первое, что привлекает внимание: 133 ГБ подозрительно близко к емкости одного Spark. Но лишь почти: 121,6 ГиБ эквивалентны 130,5 ГБ, то есть модели не хватает каких-то 2,5 ГБ. Тем не менее, односерверный конфиг TP1 существует благодаря подгрузке таблицы PLE по частям без удержания ее целиком в памяти. Он выдает 43,9 ток/с против 53,7 на двух нодах. Это единственный кандидат, способный функционировать на одиночном сервере без межсетевого взаимодействия и all-reduce. Поскольку у меня в любом случае задействованы оба спарка, я буду развертывать TP2, но сам факт наличия одноузлового режима впечатляет.

Второе — метрики для TP2. Тот же энтузиаст на двух спарках фиксирует медиану в 53,7 ток/с на одиночный поток, 97,9 суммарных при 6 потоках и колоссальный KV-пул на 1,97 миллиона токенов. Последняя цифра почти втрое превосходит показатели GLM, что логично вытекает из скромных 6 активных миллиардов параметров — облегченная основа оставляет максимум пространства под кэш.

Третье — строчка в конфигурации, имеющая решающее значение для агентных сценариев: --no-enable-prefix-caching. У Qwen3.8-Flash‑Next кэширование префиксов в vLLM принудительно деактивировано из-за багов, приводящих к генерации бреда (vLLM #54173).

6 миллиардов активных параметров не дают 90 ток/с

Вернемся к оценке скоростного потолка через пропускную способность памяти, которая дала для GLM ориентир в 60 ток/с. У GLM 18 активных миллиардов, у Qwen — 6. По логике вещей, Qwen должна разгоняться до 180 ток/с. Однако на практике конфиг выдает скромные 53,7 ток/с. Эффективность падает до 30% от теоретического максимума против 78% у GLM, и списывать это на погрешность измерений нельзя.

Главные виновники:

• Таблица PLE. 51 миллиард параметров формально не входят в число «активных», но считываются при обработке каждого токена. Точный объем в байтах зависит от n-граммов и реализации операции gather, о чем создатели скромно умалчивают.

• Накладные расходы на запуск ядер CUDA. При 6 активных миллиардах параметры матричных вычислений настолько мизерные, что накладные расходы на инициализацию ядер, синхронизацию all-reduce и работу планировщика перестают быть незаметными. В конфиге Qwen от tonyd2wild заметно активное противодействие этому недугу: захват CUDA-графов (минимизирующий издержки на запуск) активирован только для фазы декода, а спекулятивная генерация через MTP-голову настроена на предсказание трех токенов за один проход вместо одного, распределяя накладные расходы.

Практический вывод неутешителен: число «активных параметров» перестает работать как надежный индикатор скорости, как только опускается ниже отметки в 10 миллиардов. Между 18B и 6B активных параметров практической разницы в скорости почти нет (47 против 54 ток/с). Разница кроется в другом — в объеме доступного KV-пула и возможности развернуть модель на одном-единственном спарке.

Где теория расходится с практикой — и почему я публикую ее без купюр

Расчет скоростного потолка через пропускную способность памяти опирается на два допущения:

• Паспортные 273 ГБ/с — идеализированная величина, а реальная пропускная способность под управлением vLLM ниже (и этот дельта-коэффициент я не замерял).

• В расчете учитывалось чтение исключительно активных весов, тогда как на практике система параллельно считывает KV-кэш, индексатор разреженного внимания у GLM и таблицу PLE у Qwen.

Оба неучтенных фактора смещают теоретический потолок вниз. Следовательно, полученные для GLM 78% ближе к 90% от реального предела, а 30% у Qwen составляют порядка 40%.

Я сознательно оставляю эти расчеты в первозданном виде, поскольку свою задачу они выполнили: моментально отсеяли громоздкую DeepSeek‑V4.1 и пояснили парадокс, почему модели с трехкратной разницей в активных параметрах демонстрируют сопоставимую скорость. Доводить математику до абсолютной точности пока бессмысленно — реальные бенчмарки появятся в следующем посте, когда одна из этих моделей пропишется на кластере.

Ниже приведена сводная таблица известных на сегодня параметров. Мои собственные замеры выделены курсивом, заимствованные — обычным шрифтом.

	DeepSeek‑V4-Flash (текущая)	GLM-5.3-Flash NVFP4	Qwen3.8-Flash‑Next NVFP4
Параметров / активных	284B / 13B	320B / 18B	125B (+51B PLE) / 6B
Веса на диске	155 ГиБ	≈198 ГБ	≈133 ГБ
Размещение	два спарка	два спарка	два или один
Single‑stream, ток/с	57,5 ± 5,6	46,9 (со спекуляцией)	53,7 (TP2), 43,9 (TP1)
KV‑пул, токенов	≈699K при 262K	581–678K	≈1,97 M
Prefix caching	активен	активен	отключен (#54173)
Загрузка	~5 мин	≈15 мин	в README нет данных
Нюансы	—	нужен swap, drop_caches, избегать ModelOpt	PLE, YaRN только в text_config

Следствие: для Claude Code выбирает не скорость токенов, а кэш префиксов

Claude Code — принципиально иной инструмент, нежели обычный чат-бот. Каждый запрос автономного агента передает на сервер увесистый системный промпт с описанием порядка 150 инструментов, накопленную историю переписки и свежую реплику. Практически 95% входящего контекста дословно дублируют предыдущий запрос, и весь смысл кэширования префиксов (prefix caching) сводится к тому, чтобы исключить повторный пересчет этой базы.

Августовские логи моего шлюза демонстрируют красноречивую статистику. Запросы, у которых в кэш префиксов попадало свыше 80% контекста, возвращали первый токен за 4,3 секунды. Запросы с попаданием ниже 20% при аналогичном объеме промпта заставляли ждать 73,2 секунды. Разница в 17 раз на идентичном железе и той же длине контекста обусловлена исключительно тем, пересчитывался ли префикс с нуля.

Теперь вспомним про --no-enable-prefix-caching в конфигурации Qwen. При скорости префилла в 1600–2000 ток/с (моя метрика для DeepSeek; у Qwen с ее 6 активными миллиардами префилл должен быть шустрее, но порядок цифр сохраняется) агент с контекстом в 100 тысяч токенов будет каждый раз перемалывать этот объем заново. Это гарантирует минуту простоя перед каждой репликой, которую не спасут никакие 53,7 ток/с декодирования — ведь агент генерирует порядка 200 токенов на шаг, а считывает 100 тысяч.

Именно поэтому итоговый рейтинг претендентов кардинально отличается от красивых таблиц с бенчмарками. На первое место выходит GLM-5.3-Flash, полностью совместимая со сложившимся пайплайном и уже обкатанная в связке с Opus внутри Claude Code. Qwen3.8-Flash‑Next занимает вторую позицию, и входным билетом для нее служит исключительно исправление кэша префиксов: если удастся завести его без искажения ответов, она победит за счет троекратного превосходства в пуле и освобождения целого узла. Если нет — она останется отличной моделью для интерактивных чатов, но не для автономных агентов.

Выводы

1. Первичным фильтром для мультисерверного развертывания на DGX Spark служит вовсе не бенчмарк, а банальное сопоставление веса модели с доступными 243 ГиБ. Не прошедшие этот ценз модели отсекаются на корню — DeepSeek‑V4.1-Flash (552B) выбывает из игры за пять минут.

2. Метка NVFP4 не уменьшает физический размер модели, если ее эксперты изначально упакованы в MXFP4. Формат с пометкой «FP4» в первоисточнике порождает четырехбитный аналог ровно тех же габаритов.

3. Потолок скорости декодирования вычисляется через пропускную способность памяти и количество активных параметров еще до изучения чужих отчетов. Для 18B активных параметров на чипе GB10 предел составляет около 60 ток/с в один поток, а все, что выше — заслуга спекулятивного декодирования.

4. При падении числа активных параметров ниже 10 миллиардов этот показатель перестает быть предсказателем скорости: 6B у Qwen и 18B у GLM выдают схожие 54 и 47 ток/с. Причину следует искать в фоновых операциях вроде опроса таблиц PLE, индексаторов и работы с KV-памятью.

5. В агентных сценариях критически важно смотреть не на скорость генерации токенов, а на работу кэша префиксов. Разница между попаданием в кэш и промахом на моем шлюзе составляет 4,3 против 73,2 секунды ожидания первого токена. Конфигурация с отключенным кэшем префиксов профнепригодна для Claude Code.

   Принудительное включение файла подкачки (swap) меняет политику работы с памятью для всей системы целиком. Мой выбор в пользу отключенного swap сделан ради честных ошибок OOM вместо скрытых лагов подкачки, и это решение принимается осознанно, а не после зависания системы на 190-м гигабе.

6. Прежде чем внедрять модель в боевой контур, убедитесь, что все системные механизмы оптимизации функционируют корректно и не отключены принудительно.

---

Источники: RedHatAI/GLM-5.3-Flash‑NVFP4, nvidia/Qwen3.8-Flash‑Next‑NVFP4, конфигурации tonyd2wild для GLM-5.3-Flash на двух Spark и Qwen3.8-Flash‑Next, обсуждения в треках vLLM #54150 и #54173, а также официальный блог z.ai о релизе GLM-5.3-Flash.

 

Источник