Transformers 5.18: GGUF для Qwen3.5 MoE вышел в стабильном релизе

Transformers 5.18: упакованный GGUF для Qwen3.5 MoE

30 сентября 2026 года Hugging Face выпустила стабильный Transformers v5.18.0. Для локального запуска важна не новая модель, а переход GGUF-интеграции из развивающейся ветки в закрепляемый релиз и её поддержка Qwen3.5 MoE. Ранее Modelium описывал запуск GGUF на Metal из ветки main для плотной Qwen3.5; теперь разработчик может зафиксировать именно версию 5.18.0 и отдельно проверить маршрут для смеси экспертов. s1 s2

Что изменилось для локального запуска

Документация версии 5.18.0 приводит пример с unsloth/Qwen3.5-35B-A3B-GGUF и файлом Qwen3.5-35B-A3B-Q4_K_M.gguf. Для Python-загрузки используются AutoModelForCausalLM.from_pretrained(model_id, gguf_file=filename) и такой же вызов для токенизатора. Установка kernels нужна для быстрого пути: если доступно ядро ggml-org/ggml-quantization, веса остаются упакованными и вычисления на MPS идут непосредственно над ними. На MPS также может использоваться ggml-attn, если ядро удаётся получить. Если нужное ядро недоступно, загрузчик распакует веса; сам файл GGUF в этом случае не гарантирует экономию оперативной памяти. s2

Репозиторий Unsloth на проверенной ревизии действительно содержит названный Q4_K_M-файл, а карточка помечает его как производный от Qwen/Qwen3.5-35B-A3B с Apache-2.0. Базовая модель Qwen также указывает Apache-2.0 и содержит отдельный LICENSE. Лицензия кода Transformers — Apache-2.0; лицензии компонентов и иных моделей надо проверять отдельно. Это открытые веса конкретного чекпойнта, а не заявление, что вся инфраструктура или любая доступная GGUF-модель имеет одинаковые права. s3 s4 s5

Практический маршрут: в отдельном окружении установить transformers==5.18.0 и kernels, затем использовать точные ID репозитория и имя GGUF из документации релиза. Перед интеграцией проверить, что MPS выбран, ядро загружено и не возникло предупреждения о распаковке. Это инструкция по документации авторов, не результат собственного теста Modelium. Не стоит оценивать необходимую память по размеру Q4-файла: её определяют загрузка, контекст, KV-кеш, реализации ядер и прочие компоненты запуска. s2 s3

Где граница поддержки

Документация версии 5.18.0 ограничивает упакованный маршрут архитектурами Qwen3.5 и Qwen3.5 MoE. Другие архитектуры идут через прежний загрузчик с распаковкой. Хотя в changelog указан PR по Qwen3.8 GGUF, переносить на Qwen3.8 утверждение о сохранении квантованных весов нельзя. В своей заявке разработчик PR по MoE также пишет, что на момент реализации поддерживалась только Qwen3.5 MoE. s1 s2 s6

Автор PR приводит сравнение на Apple Silicon/Metal с Q4_K_M и tg128: 59,9 токена/с для Transformers против 59,4 для llama.cpp на Qwen3.5-35B-A3B. Это замер автора PR, не независимый бенчмарк и не прогноз для любого Mac или промпта. Чтобы сравнить стеки для своей задачи, нужно одинаково задать модель, квантизацию, длину контекста, размер генерации и настройки, а затем измерить на собственном устройстве. s6

Если нужен управляемый Python-стек и локальное обслуживание через экосистему Transformers, релиз делает MoE-вариант удобнее для воспроизводимого внедрения. Если цель — гарантированная работа на конкретном железе и минимальные накладные расходы, сначала проверьте доступность ядер и поведение загрузки; название формата само по себе не подтверждает экономию памяти или превосходство по скорости. s2