GLM-5.3 в HF Viewer можно разбирать как крупную MoE-модель с 78 слоями и контекстом до 1M токенов. На графе особенно заметны четыре группы компонентов: sparse attention, MoE routing, shared indexers и отдельный MTP-блок.
Такая визуализация показывает карту вычислений: какие блоки повторяются, где расходятся ветви и как результаты возвращаются в общий поток. По графу можно изучать архитектуру и потенциальные узкие места памяти, но нельзя напрямую оценить качество ответов, скорость генерации или превосходство над другой моделью.
Что видно в GLM-5.3 через HF Viewer
HF Viewer помогает смотреть модель на уровне блоков, а не воспринимать её как один большой файл весов. Для GLM-5.3 это особенно полезно из-за сочетания большого общего числа параметров, MoE-экспертов, разреженного внимания и дополнительных предсказательных блоков.
В доступном описании GLM-5.3 указаны 743B общих параметров, около 40B активных MoE-параметров, 78 слоёв и контекст до 1M токенов. Эти цифры задают масштаб модели, но сами по себе не объясняют, сколько памяти потребуется в конкретном режиме запуска.
Какие выводы граф подтверждает, а какие нет
По схеме можно подтвердить несколько типов фактов:
- сколько повторяющихся слоёв входит в основной стек;
- какие ветви относятся к attention, а какие к MoE;
- где расположены router, selector и indexer;
- какие операции идут по общему пути, а какие выполняются внутри экспертных ветвей;
- есть ли отдельные головы или блоки за пределами повторяющейся части модели;
- как MTP-блок подключён к финальной части схемы.
Граф не подтверждает качество ответов. Он не показывает результаты бенчмарков, фактическую загрузку экспертов, среднюю скорость decode, задержку на конкретной видеокарте или точный объём KV cache при выбранной длине контекста.
Причины улучшений GLM-5.3 по сравнению с GLM-5.2 тоже нельзя восстановить по одной архитектурной карте. Если схема слоёв сохранилась, изменения могли быть связаны с данными, обучением, настройками оптимизатора, постобучением, квантованием и инженерией инференса.
Как ориентироваться в большой схеме
Большой граф удобнее читать сверху вниз, выделяя уровни:
- входные тензоры и embedding-часть;
- повторяющийся блок слоя;
- attention-ветвь;
- маршрутизация токенов к MoE-экспертам;
- объединение результатов и остаточные связи;
- выходную часть, head и дополнительные блоки вроде MTP.
Сначала найдите шаблон, который повторяется в большинстве слоёв. Затем ищите исключения: первый или последний слой, отдельные индексаторы, служебные узлы и дополнительные предсказательные головы. Такой порядок снижает визуальный шум. Иначе десятки параллельных линий легко принять за десятки независимых этапов обработки.
При просмотре полезно фиксировать не название каждого узла, а его функцию: получает ли он скрытое состояние, выбирает позиции, маршрутизирует токены, применяет преобразование или объединяет ветви.
GLM-5.3 архитектура модели: что означает сохранение схемы GLM-5.2
GLM-5.3 описывается как продолжение архитектурного принципа GLM-5.2. В доступном материале для новой модели воспроизведена layer map, использованная для GLM-5.2-Int4-Int8Mix. Это поддерживает осторожный вывод: основная схема слоёв и набор архитектурных идей сохраняются.
Формулировка не означает, что две модели полностью идентичны. Граф не раскрывает состав обучающих данных, длительность обучения, настройки оптимизации, изменения в токенизаторе или детали постобучения.
Почему большое общее число параметров не равно числу активных параметров
В плотной модели каждый токен проходит через один и тот же набор основных весов. В MoE-модели внутри слоя находятся несколько экспертных ветвей, но router направляет конкретный токен только к выбранной части экспертов.
Поэтому 743B общих параметров и около 40B активных MoE-параметров описывают разные характеристики. Первая цифра отражает полный набор весов, включая экспертов. Вторая ближе к объёму параметров, участвующих в обработке отдельного токена, хотя точная стоимость зависит от конфигурации маршрутизации и реализации движка.
Активность экспертов не отменяет требования хранить веса модели, если runtime не умеет выгружать или подгружать их частями. Память нужна и для самих параметров, и для KV cache, и для промежуточных тензоров.
Где заканчивается сравнение с GLM-5.2
Сходство layer map позволяет говорить о сохранении архитектурного направления. Оно не даёт оснований утверждать, что GLM-5.3 получила те же значения всех гиперпараметров или одинаковое поведение на каждом типе нагрузки.
Архитектура и обучение решают разные задачи. Архитектурная карта показывает, какие вычислительные блоки предусмотрены. Обучение определяет, насколько хорошо модель использует эти блоки, как распределяет знания между экспертами и как ведёт себя на прикладных задачах.
Для практического сравнения с GLM-5.2 нужны отдельные измерения: качество на одинаковых наборах задач, скорость prefill и decode, потребление памяти, стабильность длинного контекста и поддержка конкретным inference-движком.
GLM-5.3 sparse attention: как читать attention-ветвь
В плотном attention каждый токен сопоставляется со всем доступным контекстом. Разреженное внимание ограничивает набор обрабатываемых связей и позиций. Это может уменьшать объём работы на длинном контексте, однако добавляет служебные операции выбора и адресации.
На графе GLM-5.3 attention-ветвь выглядит сложнее простой последовательности проекций Q, K и V. В ней выделяются DSA sparse-attention selector и shared indexers. Их присутствие показывает, что модель отдельно готовит данные для выбора релевантных частей контекста.
Что делает selector и зачем нужны shared indexers
Selector можно описать как компонент, который помогает определить, какие позиции или связи должны попасть в разреженный attention-путь для текущего токена. Он не заменяет весь attention-блок, а подготавливает выбор, после которого основной расчёт работает с ограниченным набором данных.
Shared indexers служат общими индексирующими элементами для выбора или адресации нужных участков контекста. Слово shared указывает на повторное использование индексирующей информации несколькими операциями или ветвями, но точные детали зависят от конфигурации модели и реализации.
Поэтому корректно говорить о функциональной роли этих узлов. Нельзя по одному изображению графа уверенно вывести размер выбранного окна, алгоритм построения индексов или фактическое число обращений к KV cache.
Почему sparse attention усложняет граф
В простой плотной схеме путь выглядит почти линейно: скрытое состояние проходит через проекции, вычисляется attention, результат объединяется с остаточной ветвью.
В разреженной схеме появляются отдельные направления для выбора позиций, создания или передачи индексов, извлечения нужных ключей и значений, расчёта attention и возврата результата в общий поток. Viewer отображает эти операции как узлы и связи, поэтому граф быстро становится широким.
Визуальная сложность не означает автоматически высокую вычислительную стоимость. Разреженная схема может сокращать число обрабатываемых связей, но selector, индексы, перемещение данных и особенности GPU-реализации создают собственные накладные расходы. Итог определяется runtime и конкретной длиной контекста.
GLM-5.3 MoE routing: как модель выбирает экспертов
MoE routing определяет, какие экспертные ветви обработают конкретные токены. Router получает представление токена, рассчитывает оценки экспертов и передаёт токен выбранным ветвям. После этого результаты возвращаются в общий поток слоя.
На графе это видно как разветвление после общей части слоя и последующее объединение. Параллельные блоки MoE experts не означают, что каждый токен проходит через них все одновременно.
Что на графе относится к экспертам, а что к общему пути
К общему пути относятся операции, через которые проходят все токены или все активированные ветви: вход слоя, нормализация, router, объединение результатов и остаточные связи. Экспертные ветви содержат повторяющиеся преобразования, между которыми router распределяет токены.
Такое разделение помогает правильно интерпретировать масштаб GLM-5.3. Общее число параметров складывается из всех экспертов, а вычислительный путь одного токена использует лишь выбранную часть. При этом хранение полного набора весов и передача данных между устройствами могут оставаться существенными расходами.
На практике MoE особенно чувствительна к размещению экспертных весов. Если часть экспертов находится на другом устройстве, задержка обмена может повлиять на decode сильнее, чем номинальное число активных параметров.
Почему routing нельзя оценивать только по числу ветвей
Большое количество экспертов само по себе не доказывает высокое качество или низкую стоимость инференса. Поведение модели зависит от того, как обучался router, насколько равномерно распределяется нагрузка и сформировалась ли специализация экспертов.
Даже при одинаковой архитектуре два режима работы могут давать разную задержку. Один вариант упирается в вычисления, другой в передачу экспертных активаций между GPU или в загрузку памяти.
Граф показывает наличие router и экспертных путей. Фактическую частоту активации, баланс нагрузки, пропуски маршрутизации и среднюю стоимость обработки нужно измерять отдельно.
Практическое сравнение MoE-рантаймов на GLM-5.3-Flash разобрано в материале о TensorSharp и llama.cpp. Эти результаты нельзя переносить на GLM-5.3 без повторного тестирования: меняются размер модели, конфигурация, железо и режим нагрузки.
MTP-блок и 78-й слой: отдельная ветвь в конце схемы
MTP, или multi-token prediction, выделен в отдельный блок на 78-м слое. Он не выглядит как ещё один обычный элемент повторяющегося MoE-стека, поэтому в Viewer его путь читается отдельно от основной последовательности слоёв.
В описанной схеме MTP-блок оставлен в полной точности. Это показывает, что при смешанном квантовании авторы отделяют его от тех частей, которые можно сжать сильнее.
Чем MTP отличается от обычного повторяющегося слоя
Обычный слой обрабатывает текущее скрытое состояние и передаёт результат дальше. MTP добавляет предсказательные операции, связанные с несколькими будущими токенами или дополнительными шагами генерации.
Из-за этого MTP может подключаться к финальной части модели отдельной ветвью. Его присутствие в графе помогает увидеть, что генерационная схема заканчивается не единственным стандартным head-путём.
Общая идея MTP полезна для методов, где система заранее оценивает несколько следующих токенов или использует дополнительные предсказания для ускорения принятия результата. Конкретный механизм зависит от реализации модели и движка.
Что нельзя заключить о генерации по одному MTP-узлу
Наличие MTP-блока не доказывает конкретный прирост скорости. Оно не гарантирует совместимость со speculative decoding и не показывает, сколько токенов можно принять за один шаг.
Эффект зависит от качества дополнительных предсказаний, правил проверки кандидатов, поддержки со стороны runtime и характера запроса. На коротких ответах выигрыш может быть ограничен служебными расходами, а на длинной генерации результат будет зависеть от профиля нагрузки.
Связь MTP с предзагрузкой экспертных ветвей и сокрытием задержки обмена разобрана в отдельном материале о MoE routing и MTP. Это контекст для понимания идеи, а не доказательство характеристик GLM-5.3.
Что граф GLM-5.3 говорит о квантовании и требованиях к памяти
Архитектурная карта помогает понять, почему для разных частей модели выбирают разные форматы хранения. В опубликованной mixed-precision схеме MoE-эксперты в слоях 3-77 переведены в W4A16, dense- и attention-части в слоях 1-77 используют W8A16, а MTP-блок на 78-м слое оставлен в полной точности.
Отдельно сохраняются routing, indexer и head. В описании это связано с корректной работой схемы и сохранением точности. Такой подход показывает приоритет: сильнее сжать самый крупный массив экспертных весов, а чувствительные управляющие и attention-компоненты оставить в более точном формате.
Почему эксперты можно квантизировать сильнее, чем attention
В MoE-модели эксперты занимают значительную часть общего объёма параметров. Перевод этих весов в W4A16 уменьшает требования к памяти сильнее, чем аналогичное изменение небольших служебных компонентов.
Attention работает с каждым токеном и участвует в передаче информации по контексту. Ошибки в этой ветви могут затрагивать весь поток обработки, поэтому для неё в указанной схеме выбран W8A16. Это описание конкретного рецепта, а не универсальное правило для любой MoE-модели.
Разное квантование отдельных частей объясняет, почему имя сборки или одно значение битности не всегда описывает реальную структуру файла. Для оценки размещения нужно смотреть состав тензоров, формат каждого крупного блока и поддержку этих форматов выбранным движком.
Почему KV cache важен не меньше весов
При генерации модель сохраняет ключи и значения attention для уже обработанных токенов. Этот KV cache растёт вместе с длиной контекста. Для контекста до 1M токенов запас памяти под cache становится отдельным ограничением, даже если веса удалось сжать.
Runtime требуется память для KV cache, промежуточных активаций, рабочих буферов и самого фреймворка. Поэтому модель может не поместиться в доступную конфигурацию после квантования весов.
В опубликованном описании GLM-5.3 mixed-precision сборка предназначена для запуска на четырёх NVIDIA DGX Spark с GB10 и реальным запасом под KV cache. Прежние NVFP4-варианты, по приведённому объяснению, занимали около 465 ГБ из-за хранения всего attention stack в bf16. При таком размещении оставалось слишком мало памяти для KV pool и runtime.
Практический вывод простой: при оценке запуска считайте не только размер файла весов. Нужно заранее заложить память под длину контекста, batch, число параллельных запросов и рабочие буферы конкретного inference-движка.
Связь между архитектурой MoE, unified memory, выгрузкой экспертов и настройками VRAM разобрана в руководстве по запуску MoE-моделей. Конкретные параметры из этого материала не следует переносить на GLM-5.3 без проверки совместимости.
Как использовать HF Viewer для оценки большой LLM
HF Viewer полезен как первый этап технической оценки. Он позволяет быстро понять, с какой схемой предстоит работать, до установки нескольких runtime и загрузки огромного файла весов.
Чек-лист просмотра графа
- Зафиксируйте число слоёв и найдите границы повторяющегося стека.
- Проверьте, есть ли MoE, сколько экспертных ветвей отображается и где расположен router.
- Найдите attention-ветвь и определите, плотная она или содержит selector и индексирующие узлы.
- Проверьте наличие shared indexers и выясните, какие операции используют их результат.
- Ищите дополнительные головы и блоки за пределами обычного слоя, включая MTP.
- Разделите веса модели и runtime-компоненты: параметры, KV cache, активации и рабочие буферы.
- Сопоставьте граф с конфигурацией модели и форматом опубликованных весов.
Для GLM-5.3 этот порядок приводит к понятной картине: повторяющийся стек содержит attention и MoE-пути, sparse attention использует selector и shared indexers, а MTP вынесен к 78-му слою.
Какие данные нужно проверять вне Viewer
Одной визуализации недостаточно для решения о запуске. Перед выбором модели проверьте:
- конфигурацию модели и точные значения архитектурных параметров;
- формат весов и распределение битности между блоками;
- поддержку архитектуры и квантов выбранным inference-движком;
- требования к KV cache при нужной длине контекста;
- объём VRAM, unified memory и пропускную способность соединения между устройствами;
- режим batch и число одновременных пользователей;
- готовность runtime работать с router, selector, indexer и MTP.
Показатели из ранних публикаций могут оставаться предварительными: для некоторых режимов эксплуатации встречаются пометки staged page и TBD. Такие значения нельзя использовать как финальную гарантию производительности.
Итоги: какие выводы действительно даёт граф GLM-5.3
Граф GLM-5.3 показывает сложную MoE-схему с 78 слоями, разреженным attention-путём, MoE routing, shared indexers и отдельным MTP-блоком на 78-м слое. В нём можно увидеть устройство вычислений, разделение общих и экспертных ветвей, а также компоненты, которые требуют отдельного внимания при квантовании и запуске.
Сходство layer map с GLM-5.2 поддерживает тезис о продолжении архитектурного принципа. Оно не доказывает полную идентичность моделей и не объясняет различия в качестве. Для этого нужны сведения об обучении и независимые тесты.
С практической точки зрения HF Viewer помогает заранее оценить:
- насколько модель сложна для поддержки в runtime;
- где могут возникнуть расходы на маршрутизацию и обмен между GPU;
- какие части весов, вероятно, определяют основной объём памяти;
- почему одного размера квантованного файла недостаточно для расчёта конфигурации;
- какие вопросы нужно задать документации и собственным измерениям.
Кому такой разбор будет полезен
Разработчикам граф помогает выбрать подходящий inference-движок и заранее проверить поддержку нестандартных блоков. Пользователям локальных LLM он даёт ориентир для оценки VRAM, KV cache и распределения весов по устройствам.
Специалисты по инференсу могут использовать Viewer для поиска потенциальных узких мест: маршрутизации экспертов, sparse attention, передачи данных и дополнительных предсказательных голов. Владельцам мощных AI-систем граф помогает сопоставить заявленный размер модели с реальными требованиями к памяти.
Главный результат такого просмотра, техническая карта перед запуском. Она сокращает число ошибочных предположений, но не заменяет тесты на нужном железе. Скорость, качество, стабильность длинного контекста и совместимость с конкретным runtime нужно проверять отдельно.