Арифметика памяти против бенчмарков: выбор модели для кластера DGX Spark в 2026 году
В сентябре 2026 года энтузиасты и инженеры сталкиваются с новой дилеммой при развертывании локальных агентских моделей на кластерах NVIDIA DGX Spark. Три перспективных кандидата — DeepSeek-V4.1-Flash, GLM-5.3-Flash и Qwen3.8-Flash-Next — демонстрируют разную производительность, но выбор в пользу конкретной модели определяется не таблицами синтетических тестов, а жесткими ограничениями физической памяти и архитектурными особенностями работы с префиксами. Статья разбирает, почему «активные параметры» перестают быть надежным индикатором скорости и как одна строчка конфигурации может свести на нет преимущества сверхбыстрой модели.
# Выбор агентской модели для кластеров из 2× DGX Spark: почему арифметика памяти важнее бенчмарков
Сентябрь 2026 года принес на платформу Hugging Face несколько новых гигантов, вызывающих желание развернуть их на кластерах NVIDIA DGX Spark. Речь идет о трех моделях, позиционируемых для работы в режиме Claude Code (локальный агент): DeepSeek-V4.1-Flash (552B параметров), GLM-5.3-Flash (320B) и Qwen3.8-Flash-Next (125B). На первый взгляд, DeepSeek выглядит как очевидный лидер благодаря лучшим результатам в бенчмарках. Однако при попытке развернуть эту модель на двух узлах кластера выясняется, что её веса физически не помещаются в доступное пространство памяти, даже в агрессивном 4-битном квантовании. В этой статье мы проанализируем, почему математика памяти становится жестче таблиц производительности.
*Примечание редактора:* В эпоху растущих масштабов, когда энтузиазм по поводу «больше параметров = лучше интеллект» доминирует, легко забыть о физике вычислительных узлов. Ниже представлен разбор реального процесса деплоя, где каждый гигабайт имеет цену, а синтетические показатели могут вводить в заблуждение. Как и в тихих портах маяка, истинная истина часто кроется в деталях, скрывающихся за громкими заголовками.
1. Ограничения аппаратной платформы: 243 Гб на двоих
Анализ начинается не с выбора модели, а с изучения «стена» аппаратной конфигурации. Кластер состоит из двух узлов DGX Spark, каждый из которых осначен суперчипом NVIDIA GB10 Grace Blackwell. Ключевой особенностью этой архитектуры является отсутствие отдельной видеопамяти (VRAM). Все 128 ГБ оперативной памяти LPDDR5x-9400 функционируют как единый пул, обслуживая и процессорное ядро, и графический процессор.
После вычета системных потребностей доступно 121,6 ГБ на один узел и 243 ГБ на пару узлов. Это абсолютный потолок для размещения весов модели при использовании тензорного параллелизма.
Рассмотрим кандидатов: * DeepSeek-V4.1-Flash (552B параметров): Даже в квантовании по 4 бита вес одного трансформера составляет около 276 ГБ. Это превышает доступный объем в 243 ГБ, не считая KV-кэша. Модель требует минимум три или четыре узла, что выходит за рамки рассматриваемой конфигурации. * GLM-5.3-Flash (320B параметров, ~18B активных): В 4-битном формате (W4A4) модель весит около 198 ГБ. Это влезает в два узла, но оставляет очень малый запас (~11 ГБ на узел) для KV-кэша и активаций. Любое увеличение контекстного окна или параллелизма запросов приведет к ошибкам Out Of Memory (OOM). * Qwen3.8-Flash-Next (125B параметров, ~6B активных): Эта модель весит около 133 ГБ в NVFP4 квантовании. Она может разместиться даже на одном узле, оставив значительный объем памяти для работы с длинными контекстами.
Таким образом, первый фильтр отсекает наиболее мощную модель месяца, не дав даже шанс скачать её байты.
2. Почему «активные параметры» обманчивы: потолок скорости
Следующий вопрос, на который нужно ответить, касается производительности генерации. Складывается ложное впечатление, что чем меньше активных параметров (Active Parameters), тем выше скорость токенов в секунду (tok/s). При этом GLM с 18B активных параметров и Qwen с 6B активных параметрами должны показать разницу в три раза.
Реальные измерения на платформе GB10 показывают обратное: обе модели демонстрируют схожие результаты — около 47–54 ток/с. Почему?
При анализе пропускной способности памяти мы видим, что для модели с 18B активных параметров на интерфейсе памяти GB10 (паспортная полоса 273 ГБ/с) теоретический потолок составляет около 60 ток/с. Любые значения выше этого предела достигаются за счет спекулятивного декодирования, а не чистой скорости вычислений.
Однако у Qwen с 6B активных параметров скорость также не достигает ожидаемых 180 ток/с, останавливаясь на уровне 54. Разрыв объясняется факторами, не учитываемыми в простой формуле «активные веса = скорость»:
1. Накладные расходы запуска ядер (Kernel Launch Overhead): При работе с малым числом активных параметров длительность самого вычисления матричных умножений сокращается. В это время в работу включаются накладные расходы на планировщик CUDA, синхронизацию и коммуникации (all-reduce), которые перестают быть пренебрежимо малыми. Разработчики Qwen борются с этим через захват CUDA-графов и спекулятивное декодирование. 2. Дополнительные данные, читаемые на токен: У Qwen используется таблица n-грамм PLE (51B параметров), которая должна загружаться и считаться каждый шаг, что снижает эффективность пропускной способности памяти.
Таким образом, между 18B и 6B активных параметров разница в чистой скорости генерации практически отсутствует.
3. Главная ловушка для агентов: Prefix Caching и флаг vLLM
Для задачи Claude Code — работы агента, а не чат-бота — критическим фактором становится не скорость генерации, а время первого токена (Time to First Token, TTFT). Агентский запрос включает длинный системный промпт (~150 инструментов), полную историю диалога и новое действие. В таких сценариях 95% входного сообщения повторяется из предыдущего запроса.
Идеальным решением здесь является Prefix Caching (кэширование префиксов), которое позволяет модели не пересчитывать уже известные части промпта.
Однако здесь возникает критическая проблема для Qwen3.8-Flash-Next. В текущих версиях vLLM для этой модели включенный prefix caching приводит к генерации неверных ответов из-за багов (issue #54173). Единственный способ сделать модель работающей — принудительно выключить кэш через флаг --no-enable-prefix-caching.
Цена этого решения колоссальна: если префикс не кэшируется, агент с контекстом в 100 000 токенов будет переживать загрузку этого объема заново перед каждым ответом. Это создает задержку в минуту на каждый ход агента, полностью нивелируя преимущество в скорости декода. В то время как GLM-5.3-Flash поддерживает стабильный prefix caching без известных критических багов для этого стека.
Итоги и рекомендации
Выбор модели для кластера DGX Spark под задачи автоматизации и кодинга в сентябре 2026 года определяется не пиксельной точностью бенчмарков, а арифметикой памяти и стабильностью системы.
1. DeepSeek-V4.1-Flash отсеивается сразу: физически не помещается в доступную память (243 ГБ) без использования дополнительного железа. 2. Qwen3.8-Flash-Next показывает высокую потенциальную эффективность благодаря малому количеству активных параметров и возможности размещения на одном узле, но требует отключения prefix caching, что делает её непригодной для сложных агентов с длинной историей диалога. 3. GLM-5.3-Flash становится наиболее сбалансированным вариантом для данной конфигурации, обеспечивая стабильную работу, приемлемую скорость и полную поддержку необходимых технологий кэширования.
Таким образом, при планировании развертывания локальных моделей на ограниченных аппаратных ресурсах, стоит обращать внимание не только на «ток/с», но и на то, насколько модель готова к интеграции в реальные производственные процессы.