PR #34782: не просто тикет, а технический манифест
Когда в репозитории Hugging Face Transformers появляется pull request на добавление новой модели, это обычно скучная техническая рутина. Конфиг, пара файлов, тесты. Но PR #34782 - другое дело. Это 47 файлов изменений, где разработчики из Zhipu AI буквально вываливают на стол всю внутреннюю кухню GLM-5. И если присмотреться, там есть на что посмотреть.
На момент 09 февраля 2026 года PR все еще открыт и активно обсуждается. Это не релиз - это предложение по интеграции, которое показывает, куда движется архитектура GLM.
Архитектурные детали, которые меняют правила
Первое, что бросается в глаза - GLM-5 отказывается от некоторых привычных решений GLM-4.7. Нет, это не революция, но эволюция с конкретными техническими причинами.
Квантование в ядре: не опция, а стандарт
Если в GLM-4.7-REAP квантование было отдельным трюком для экономии памяти, то в GLM-5 оно встроено в архитектуру. В конфигурации появился параметр quantization_config прямо в основном классе модели. Это значит, что модель из коробки понимает, как работать с квантованными весами без дополнительных костылей.
hidden_act теперь по умолчанию 'swiglu' вместо 'gelu'. SwiGLU - это не новая активационная функция (ей уже пара лет), но её использование в GLM говорит об оптимизации под точность вычислений с квантованием.Контекстное окно: 128К - это только начало
В конфиге видно max_position_embeddings: 131072. 128 тысяч токенов - стандарт для 2026 года? Не совсем. Важнее то, как это реализовано. RoPE (Rotary Positional Embeddings) с динамическим масштабированием - это уже не просто позиционные эмбеддинги, а целая подсистема для работы с длинными контекстами.
| Параметр | Значение в GLM-5 | Что было в GLM-4.7 | Что это значит |
|---|---|---|---|
| hidden_size | 8192 | 7168 | Увеличили размерность скрытого слоя на 14% |
| intermediate_size | 28672 | 24576 | FFN слой стал больше почти на 17% |
| num_attention_heads | 64 | 56 | Больше голов внимания для параллельной обработки |
| num_hidden_layers | 80 | 80 | Количество слоев не изменилось |
Адаптация под Transformers v5: боль или облегчение?
Тот, кто работал с миграцией на Transformers v5, знает - обратной совместимости там нет. GLM-5 создается с учетом этого. В коде видно использование новых абстракций v5, особенно в части инициализации и конфигурации.
Например, класс GLM5Config наследуется от PretrainedConfig новой версии, где убрали кучу legacy-параметров. Это хорошо для чистоты кода, но плохо для тех, у кого есть кастомные конфиги под старую версию.
Если у вас есть пайплайны с GLM-4.7, которые используют старый API Transformers - готовьтесь к рефакторингу. GLM-5 не будет работать со старыми вызовами.
Поддержка vLLM из коробки
Раньше чтобы запустить GLM на vLLM, нужно было либо ждать поддержки от сообщества, либо писать кастомный бэкенд. В PR видно, что GLM-5 сразу включает конфигурацию для vLLM в modeling_glm5.py. Это не случайность - это ответ на требования 2026 года, где скорость инференса критична.
Что скрыто между строк конфига
Технические PR часто читаются как сухой код, но здесь есть интересные моменты:
use_cache: trueпо умолчанию - модель оптимизирована для последовательной генерации с кэшированием ключ-значение- Нет параметра
torch_dtypeв основном конфиге - тип данных вынесен в отдельную логику инициализации attention_dropout: 0.0- дропаут в механизме внимания убран полностью. Либо переобучение стало лучше, либо это оптимизация под инференс- Появился параметр
residual_dropoutвместо общегоhidden_dropout- более тонкий контроль регуляризации
Мультимодальность как опция, а не фича
В GLM-4 мультимодальность была встроена в архитектуру. В GLM-5 из PR видно другой подход - отдельные классы для текстовой и мультимодальной версий. GLM5ForConditionalGeneration и GLM5ForVisionText2Text наследуются от разных базовых классов.
Это умно. Разработчики не хотят тащить лишний код в текстовые модели. Но для тех, кто разворачивает модели в продакшне, это означает две разные codebase для поддержки.
Тесты, которые говорят больше документации
В PR добавлено 12 тестовых файлов. И это не просто "проверяем, что модель запускается". Тесты покрывают:
- Генерацию с разными стратегиями (greedy, beam search, sampling)
- Работу с различными длинами контекста
- Квантование в разных режимах (4-bit, 8-bit)
- Совместимость с разными бэкендами (PyTorch, vLLM)
Особенно интересен тест test_model_parallelism - он проверяет, как модель ведет себя при распределении по нескольким GPU. Значит, GLM-5 проектировали с учетом масштабирования.
Проблемы, которые еще не решены
PR открыт не просто так. В обсуждениях видны спорные моменты:
Еще один момент - документация. В текущем виде её почти нет. Комментарии в коде есть, но полноценной docs строк нет. Это типично для early-stage PR, но значит, что первые пользователи будут разбираться методом тыка.
Что это значит для нас в 2026?
GLM-5 в Transformers - это не просто новая модель. Это сигнал о том, как будут выглядеть LLM в ближайшие пару лет:
- Квантование станет стандартной частью архитектуры, а не постобработкой
- Мультимодальность будет модульной - бери только то, что нужно
- Поддержка разных бэкендов (vLLM, llama.cpp) будет из коробки
- Конфигурация станет проще за счет удаления legacy-параметров
Если вы планируете мигрировать с GLM-4.7 - начинайте изучать PR сейчас. Не ждите, когда он вмержится. Потому что когда это случится, вам придется переписывать код под новую архитектуру. И судя по проблемам с GLM-4.7-Flash, миграция может быть болезненной.
Мой прогноз? GLM-5 будет медленнее внедряться, чем ожидают. Потому что Transformers v5 еще не везде, а обратной совместимости нет. Но те, кто перейдет первыми, получат преимущество в производительности и памяти. Выбор за вами - ждать стабильной версии или ковыряться в сыром PR.
P.S. Если интересно, как это все развернуть в продакшне - посмотрите статью про развертывание LLM в Kubernetes. Там принципы те же, только масштаб другой.
