🛠 Выбор модели для 2× DGX Spark: память и кэш префиксов

Три свежие модели — DeepSeek-V4.1-Flash (552B), GLM-5.3-Flash (320B) и Qwen3.8-Flash-Next (125B) — появились на Hugging Face за последние недели. Каждая в тестах лучше текущего DeepSeek-V4-Flash, развернутого на паре DGX Spark. Но практический выбор, как показывает разбор на Habr, начинается не с точности, а с суммы весов против 243 ГиБ объединённой памяти.

Первый фильтр отсекает DeepSeek-V4.1-Flash: один только трансформер в 4 битах весит около 276 ГБ, а у двух Spark ровно 243 ГиБ. NVFP4 не спасает — эксперты уже хранятся в MXFP4, это не уменьшение вдвое. GLM-5.3-Flash занимает 198 ГБ и загружается 15 минут, требуя включённого файла подкачки и очистки кэша. Qwen3.8-Flash-Next весит около 133 ГБ, что почти равно памяти одного Spark, но не хватает 2,5 ГБ — и его можно запустить на одном узле только если пожертвовать частью PLE.

Оценка потолка скорости через пропускную способность памяти (273 ГБ/с) даёт для GLM с 18B активных параметров около 60 ток/с, для Qwen с 6B — около 180. Реальные замеры: 46,9 у GLM (со спекуляцией) и 53,7 у Qwen. Разница почти исчезает, потому что ниже 10B активных параметров накладные расходы и чтение PLE съедают теоретический выигрыш. Но решающим оказывается не скорость декодирования, а кэширование префиксов. В Claude Code каждый запрос агента на 95% совпадает с предыдущим, и у автора разница между попаданием в кэш и промахом — 4,3 с против 73,2 с до первого токена. А у Qwen3.8-Flash-Next кэширование префиксов принудительно выключено из-за ошибки vLLM #54173, которая портит ответы. Это делает модель непригодной для агентного сценария, несмотря на 1,97 млн токенов KV-пула.

Пока индустрия меряется тестами, реальный выбор агентской модели на локальном кластере сводится к чтению обсуждений vLLM и config.json. Продакшен начинается не с таблицы лидеров, а с того, включено ли у тебя кэширование префиксов и не ломает ли оно вызов инструментов. И это нужно проверять до первого скачивания, а не после 15 минут загрузки.

#DGXSpark #vLLM #ClaudeCode #prefixcaching #агенты