ainews
llama.cpp теперь загружает MTP-тензоры по умолчанию — лишний гигабайт VRAM для всех
Свежие сборки llama.cpp автоматически загружают MTP/NextN-тензоры из GGUF-моделей (GLM-5.2, Qwen3.5-MoE и др.), даже если спекулятивная декодировка отключена. Раньше эти блоки грузились только при явном --spec-type draft-mtp. Теперь каждый запуск жрёт на ~1 дополнительный MoE-слой памяти, даже если MTP не используется.
Если ты запускаешь модели локально (разработка, inference-сервис, хобби), это изменение может выбить твою конфигурацию из строя или заставить апгрейдить железо. Даже если MTP тебе не нужен, ты за него платишь памятью.
Что случилось
llama.cpp (популярная библиотека для запуска LLM локально) обновила логику загрузки моделей. Если в GGUF-файле есть MTP (Multi-Token Prediction) или NextN-тензоры — блоки для спекулятивной декодировки — движок теперь грузит их в память всегда, даже если флаг --spec-type draft-mtp не передан.
Раньше эти тензоры пропускались, если спекулятивная декодировка отключена. Теперь — грузятся по дефолту.
Какие модели затронуты
GLM-5.2, hy_v3, Qwen3.5-MoE, step35 и другие популярные GGUF из community-репозиториев. Многие квантизированные версии включают MTP-блоки «из коробки», даже если большинство пользователей их не использует.
Реальный эффект
Дополнительный расход VRAM/RAM примерно равен одному лишнему MoE-слою (для Mixture-of-Experts моделей). Если у тебя 8–12 ГБ видеопамяти, это может вытолкнуть часть модели обратно в RAM или вообще сломать загрузку. Если работаешь на CPU, то просто жрёшь больше оперативки зря.
Что с этим делать
Пока только костыль: ждать фикса или откатываться на старые сборки. Обсуждение идёт в PR #25980 на GitHub — разработчики в курсе, но пока единого решения нет.
Автор: Никита Громов · Источник: reddit.com
Разработчикам. Если собираешь llama.cpp из main или тащишь свежие релизы, готовься к тому, что модели с MTP займут больше памяти. Следи за PR #25980, там обсуждают флаг для выключения дефолтной загрузки. Если делаешь inference-сервис на ограниченной VRAM, проверь, какие GGUF используешь — возможно, стоит запечь свои без MTP-блоков или откатиться на билд до этого изменения.
Бизнесу. Сервисы локального инференса на llama.cpp могут внезапно упереться в нехватку памяти — особенно при плотной загрузке GPU. Если раньше 24 ГБ VRAM хватало на несколько моделей параллельно, теперь может не хватить. Это увеличит требования к железу и бюджет на облачные GPU, либо потребует отката на стабильные релизы.
Инвесторам. Тренд на запуск больших моделей на consumer-GPU получает очередной удар: каждый новый слой памяти — это либо дороже железо, либо хуже UX. Вендоры hardware (NVIDIA, AMD) выигрывают, если пользователям придётся апгрейдиться. Но для стартапов, строящих бизнес на локальном AI, это риск внезапного роста издержек.
- Сделать утилиту для автоматической чистки MTP-блоков из GGUF (пользователи платят за экономию памяти).
- Предложить хостинг GGUF-моделей с гибкими пресетами (с MTP / без MTP) — как CDN для AI.
- Запустить сервис мониторинга изменений в llama.cpp и уведомлений о breaking changes для бизнеса на локальном AI.
- Консалтинг для inference-провайдеров: аудит памяти, оптимизация конфигов llama.cpp под текущее железо.
- Если ты обновил llama.cpp не глядя, твой продакшн может упасть из-за нехватки VRAM — особенно при автоскейлинге с несколькими моделями.
- Community-GGUF могут стать токсичными: большинство пользователей не понимают, зачем им MTP, но платят лишней памятью.
- Откат на старую версию llama.cpp — временное решение, но ты пропустишь новые фичи и оптимизации (trade-off).
- Если PR #25980 закроют костылём, проблема вернётся с новыми архитектурами — следить за каждым апдейтом станет обязательным.
Это классический случай, когда open-source движется быстро, а пользователи узнают о breaking change постфактум. llama.cpp — де-факто стандарт для локального запуска LLM, но такие изменения показывают хрупкость зависимости от быстрых релизов. Если ты в production, фиксируй версии и тестируй обновления в изолированной среде — иначе рискуешь проснуться с упавшим сервисом.
С другой стороны, это открывает нишу для инструментов: автоматическая чистка GGUF, мониторинг изменений в популярных библиотеках, консалтинг по оптимизации памяти. Боль пользователей — это всегда деньги для тех, кто умеет её решать быстро и удобно.
Комментарии