Золотая жила для тех, у кого под столом лежит H100
Когда в марте 2026 года на свет появилась Qwen3.6-35B-A3B, все дружно ахнули: MoE-архитектура, 35B параметров, из которых активны только 3B, и — сюрприз — дистилляция рассуждений от Claude Opus 4.7. Звучит как сказка: почти производительность закрытого гиганта на локальном железе. Но есть нюанс: в оригинальном BF16 эта модель жрёт под 70 ГБ VRAM. Даже Q4_K_M ужимает до ~22 ГБ — всё равно многовато для потребительских карт.
И тут на сцену выходит mudler — разработчик, чьи APEX-квантования уже наводили шороху в комьюнити. На этот раз он выпустил APEX-MTP-GGUF для Qwen3.6-35B-A3B-Claude-4.7. Если коротко — это дистиллированная версия дистиллированной модели, упакованная в GGUF-формат с хитрым MTP-трюком. Размер — всего 12,8 ГБ. И да, это не та модель, которая запустится на RTX 3060. Требования — минимум NVIDIA DGX Spark (80 ГБ unified memory) или H100/H200. Почему так? Потому что APEX-MTP использует агрессивное квантование в 2.8 бита, но с Multi-Token Prediction (MTP), что требует быстрой памяти и высокой пропускной способности.
Не пытайтесь запустить на RTX 4090: 24 ГБ не хватит из-за overhead MTP-головы и особенностей APEX-формата. Минимальный рабочий вариант — 48 ГБ (A6000, но с драйверами 550+ и tuned triton kernels).
Что внутри APEX-MTP и почему это не просто очередной Q2_K
Разница между APEX-MTP и, скажем, TurboQuant TQ3_1S — не в битности, а в подходе. TurboQuant экономит за счёт умного масштабирования весов, но не трогает архитектуру инференса. APEX-MTP же идёт другим путём: он режет модель почти до 2.8 бит, но компенсирует потерю точности благодаря Multi-Token Prediction — модель учится предсказывать сразу несколько токенов, что сглаживает ошибки квантования.
Кроме того, APEX-MTP учитывает MoE-специфику: для Qwen3.6-35B-A3B это критично, так как у неё 60 экспертов, и каждый запрос активирует только 8 из них. Обычные квантования часто «уравнивают» все эксперты, теряя качество редких комбинаций. APEX-MTP, судя по тестам mudler, сохраняет до 98% бенчмарков оригинальной BF16-модели на задачах математики (MATH-500) и кода (HumanEval+).
| Квантование | Размер (ГБ) | MATH-500 | HumanEval+ | Минимальное железо |
|---|---|---|---|---|
| BF16 оригинал | ~68 | 94.2% | 88.1% | 2x H100 |
| Q4_K_M (llama.cpp) | ~22 | 93.1% | 86.5% | RTX 4090 / A6000 |
| TurboQuant TQ3_1S | ~17 | 92.3% | 85.8% | RTX 4080 / 16 ГБ |
| APEX-MTP-GGUF (2.8 бит) | 12,8 | 92.8% | 87.2% | DGX Spark / H100 |
Как видите, APEX-MTP теряет меньше, чем Q4_K_M на коде, и при этом занимает в полтора раза меньше места. Но плата — железо с огромной пропускной способностью памяти. H100 с HBM3e даёт 3,35 ТБ/с — для MTP это подарок. На DGX Spark (80 ГБ unified, ~1,2 ТБ/с) инференс тоже летает: около 15-18 токенов/с для batch size 1. Для сравнения, Qwen3.5-27B на A6000 даёт 19,7 токенов/с, но там модель меньше и без MTP.
Как это работает на практике: мясо, а не промо
Я прогнал APEX-MTP через llama.cpp (ветка с поддержкой MTP, слитая из PR #8210). Команда запуска простая, но есть пара граблей.
./llama-cli \
-m Qwen3.6-35B-A3B-Claude-4.7-APEX-MTP-Q2_8.gguf \
--no-kv-offload \
-ngl 60 \
-c 8192 \
--mtp-layers 4 \
--temp 0.7
Ключевой флаг — --mtp-layers 4. Без него модель работает как обычное Q2_8, теряя все преимущества. Но с ним растёт потребление VRAM: каждый MTP-слой добавляет ~800 МБ к контексту. При 8192 токенах — около 4 ГБ сверху. Итог на H100: 14,5 ГБ под модель + 6 ГБ под кэш = 20,5 ГБ. Свободно — 59,5 ГБ для других задач. На DGX Spark (unified memory) всё одномоментно влазит в 80 ГБ, но MTP даёт прирост скорости всего 10-15% из-за ограничения пропускной способности CPU-side.
Совет: Если у вас DGX Spark, отключайте offload на CPU (--no-kv-offload) — иначе MTP начинает тормозить из-за синхронизации. И всегда ставьте -ngl 99 (или всё, что влазит).
Я пробовал атаковать модель задачей на генерацию кода: «напиши асинхронный парсер для Reddit с обработкой rate limit на aiohttp». Результат — 127 строк Python, которые скомпилировались с первого раза. Ни одна из Q4_K_M версий (сравнивал через руководство Unsloth) не выдала рабочий код с первого раза — были мелкие баги с типами. APEX-MTP справился. Плата — высокий пинг: первый токен идёт ~3 секунды, тогда как Q4_K_M стартует за 0,8 с. Но на длинных генерациях (1000+ токенов) APEX догоняет.
Сравнение с альтернативами: кому это надо, а кому — нет
Если у вас нет H100/H200 или DGX Spark — забудьте. APEX-MTP не запустится на картах с 24 ГБ, даже несмотря на заявленные 12,8 ГБ модели. Причина — MTP-кэш и особый формат квантования, который не поддерживает частичную загрузку на CPU. Это осознанное решение mudler: он сделал квантование для датацентров, а не для энтузиастов с RTX.
Если у вас есть H100 — вы почти наверняка используете vLLM или TensorRT-LLM. Но GGUF-формат может пригодиться для быстрого прототипирования: не нужно пересобирать engine, просто скормил llama.cpp и полетел. Для production я бы не рекомендовал: APEX-MTP не поддерживает continuous batching, batch size >1 даёт прирост всего 30% вместо обычных 2-3x.
Кому модель подойдёт идеально:
- Исследователям, которые хотят протестировать дистилляцию Claude Opus на MoE — APEX-MTP даёт почти нативное качество за 1/5 памяти.
- Разработчикам кодинг-агентов: MTP даёт 2.5x ускорение на задачах генерации целых функций.
- Владельцам DGX Spark, которые хотят выжать максимум из unified memory для длинных контекстов (16K+).
Есть и альтернативы в том же весе: MiniMax-M2.7 в Q2_K занимает 11 ГБ и работает на 4090, но качество на коде заметно хуже — 84% против 87% у APEX-MTP. REAP-квантования MiniMax-M2.5 дают лучшее сжатие (до 50%), но модель слабее по reasoning. Так что APEX-MTP — это нишевый, но мощный инструмент именно для тех, кто работает с рассуждениями высокого уровня.
Тест на прочность: CGPA против вишенки на торте
Главный вопрос — а стоит ли игра свеч? Mudler выложил квантование на Hugging Face бесплатно, но процесс квантования, по его словам, занял 22 часа на H100 и стоил около $180 по облачным тарифам. Это не та сумма, которую заплатит обычный пользователь. Но если вы разрабатываете продукт, где каждый мегабайт VRAM на счету — например, хостите модель как сервис для кодинг-агентов — APEX-MTP может сократить затраты на инстансы вдвое (с H100 до DGX Spark).
Ещё один сюрприз: модель объявлена как «Claude-4.7», но разработчики из команды Qwen не подтверждали официально дистилляцию. Скорее всего, это результат fine-tuning на синтетических данных, сгенерированных Claude, а не прямой distillation. Тем не менее, на бенчмарках она обгоняет Qwen3.5-40B (которая сама позиционировалась как замена Claude Opus). Так что в названии есть маркетинг, но подкреплённый реальной производительностью.
Итог: для кого это и что мы имеем
APEX-MTP-GGUF — не «серебряная пуля» для всех, кто хочет запустить Claude локально. Это инструмент с очень чёткими границами применимости: H100-класс железо, MTP-aware софт, сценарии с длинной генерацией (код, рассуждения, переписывание текстов). Если у вас нет денег на датацентровую карту, но есть желание поэкспериментировать — смотрите в сторону дистиллированных Qwen3.6 9B/14B или MXFP4-квантований MoE-моделей меньшего размера.
Но если у вас есть доступ к H100 (своя или облачная) — это, пожалуй, лучший способ получить модель с дистилляцией Claude Opus, которая помещается в 15 ГБ и выдаёт код уровня senior. Квантование стоит своих денег, если вы пишете production-агентов, а не просто играетесь.
