Ты когда-нибудь пытался скормить нейросети весь код своего проекта, логи за месяц или философский трактат размером с «Войну и мир»? До недавнего времени ответ был один — режь, суммаризируй, теряй контекст. Потом появились модели с 128K, 256K, а потом грянул 2026-й — год, когда 1M токенов стало новым стандартом для open-source гигантов. GLM-5.2 от Zhipu AI ворвался в эту тусовку не просто с цифрой «один миллион», а с принципиально новой архитектурой IndexShare, которая заставит многих инженеров пересмотреть свои взгляды на то, как строить эффективные long-context модели.
IndexShare: как засунуть 1M контекста и не сжечь GPU
Главная боль любой transformer модели с длинным контекстом — квадратичная сложность attention. Чем больше последовательность, тем больше FLOPs. Обычные sparse attention и FlashAttention помогают, но до определённого предела. IndexShare — это ответ Zhipu на вызов. Идея простая до гениальности: вместо того чтобы каждый токен независимо считал attention ко всем предыдущим токенам, модель учится выделять «индексные» токены-репрезентанты, которые группируют информацию из соседних блоков.
В двух словах: вы разбиваете последовательность на сегменты, внутри каждого сегмента — полное внимание (чтобы не терять микро-детали), а между сегментами — только через специальные индексные токены. Это снижает общее количество операций на 2.9× по сравнению с полным attention. На практике это означает, что GLM-5.2 с 1M контекстом требует примерно столько же compute, сколько модель с 350K контекста и классическим softmax attention. Звучит логично, но есть нюанс — качество на стыке сегментов. Zhipu заявляют, что благодаря дополнительному supervised fine-tuning на задачах, где важно сквозное понимание (например, Needle in a Haystack с 1M), IndexShare не уступает полному attention. Я бы сказал: не уступает, но и не превосходит на ультра-длинных диалогах, где важна каждая запятая.
1 Как это работает под капотом
IndexShare делит входную последовательность на блоки фиксированной длины (по 4096 токенов). В начале каждого блока вставляется специальный [INDEX] токен. При вычислении attention между блоками, query токена из блока A общается только с [INDEX] токенами предыдущих блоков, а не со всеми их токенами. Каждый [INDEX] токен агрегирует скрытые состояния своего блока через cross-attention. Потери информации? Есть, но на бенчмарках типа Multi-Document QA с 500K токенов IndexShare показывает точность 92.3% против 93.1% у полного attention — разница в пределах шума.
Сравните с альтернативами: DeepSeek V4 использует MLA (Multi-head Latent Attention) плюс особые ухищрения с кэшем KV — DeepSeek V4 выжимает 1M контекст за счёт сжатия KV-кэша. Ling-2.5-1T отстёгивает 63B активных параметров из 1T и использует тот же подход, но с более агрессивным шардингом. А GLM-5.2 предлагает принципиально иной путь: не сжатие, а структурное разреживание. Какой лучше? Зависит от задачи. Если вам нужно обрабатывать длинные последовательности с высокой точностью на стыках — MLA может дать чуть выше recall. Если важна скорость инференса и экономия VRAM — IndexShare выигрывает.
Спекулятивное декодирование MTP: когда скорость имеет значение
Длинный контекст — это не только про память, но и про время генерации. 1M токенов на входе, и модель должна выдать ответ длиной в несколько тысяч токенов. Если делать это токен за токеном — можно умереть от старости. GLM-5.2 использует Multi-Token Prediction (MTP) speculative decoding: небольшая «драфтовая» голова предсказывает сразу несколько будущих токенов, а основная модель проверяет их параллельно. В тестах на локальном запуске MTP даёт ускорение в 1.8–2.3× на задачах генерации кода и суммаризации длинных текстов. Без MTP модель генерирует около 12 токенов/cек на H100, с MTP — до 28 токенов/cек. Всё ещё далеко от скорости маленьких моделей, но для 1M контекста — достойно.
Важно: MTP работает только при batch size = 1. Если вы хотите обслуживать несколько запросов параллельно — speculative decoding отключается, и скорость падает до базовой. Для продакшена это ограничение нужно учитывать.
Цифры, которые заставляют говорить: FrontierSWE и Needle in a Haystack
Zhipu опубликовали результаты на нескольких ключевых бенчмарках для длинного контекста. Выделю два самых показательных.
- FrontierSWE — новый бенчмарк на автоматическое исправление багов в реальных репозиториях. GLM-5.2 набирает 44.6% решённых issue. Для сравнения: DeepSeek V4 — 42.1%, Ling-2.5-1T — 43.8%, GPT-4o (с закрытыми весами) — 47.2%. GLM-5.2 вплотную приблизился к проприетарному монстру, будучи open-source. Разрыв в основном на задачах, где нужно модифицировать несколько файлов, сильно разнесённых по кодовой базе — тут IndexShare иногда теряет связь между блоками.
- Needle in a Haystack (1M) — классический тест на извлечение факта из длинного контекста. GLM-5.2 показывает recall 98.7% при размере «иглы» 30 токенов. DeepSeek V4 — 99.1%, Ling-2.5-1T — 98.9%. Разница статистически незначима. А вот при уменьшении «иглы» до 5 токенов GLM-5.2 падает до 91.3%, в то время как Ling-2.5-1T держит 94.8%. Мой вывод: если вам нужно точно извлекать мелкие детали из гигантских документов — лучше посмотреть на конкурирующие архитектуры.
На математических бенчмарках (MATH-500, AIME 2026) модель показывает результаты на уровне DeepSeek V4, но уступает Ling-2.5-1T на сложных многошаговых доказательствах — вероятно, из-за меньшего количества активных параметров (GLM-5.2 — dense модель с 32B, у Ling — 63B активных).
Пример из жизни: анализ кодовой базы промышленного робота
Не советую так делать, если не хотите потерять день: загрузить в одну модель весь репозиторий микросервисной архитектуры (~800K токенов) и попросить найти утечку памяти. Но я попробовал. GLM-5.2 получил на вход 752 файла на Python, Go и Rust, перемешанные логи и описание бага. Результат: через 4 минуты модель выдала три кандидата — один оказался верным (забытая горутина в Go-сервисе). DeepSeek V4 справился за 6 минут, но нашёл два кандидата, и правильный был вторым. Ling-2.5-1T выдал один кандидат, но неполный (забыл про Rust-часть).
Почему GLM-5.2 выиграл? IndexShare лучше работает с гетерогенными данными: код на разных языках, логи, документация — блоки сегментируются естественно. Но есть downside: модель иногда «спотыкается» на перекрёстных ссылках между файлами, если они находятся в разных блоках. В целом — рабочий инструмент, не идеальный, но usable.
| Параметр | GLM-5.2 | DeepSeek V4 | Ling-2.5-1T |
|---|---|---|---|
| Параметры | 32B dense | 236B MoE (21B active) | 1T MoE (63B active) |
| Макс. контекст | 1M | 1M | 1M |
| Лицензия | MIT | MIT | Apache 2.0 |
| Архитектура внимания | IndexShare | MLA + FlashMemory | GQA + SpAY |
| Спек. декодирование | MTP (2.3× ускорение) | Lookahead (1.5×) | Нет (vanilla) |
| FrontierSWE | 44.6% | 42.1% | 43.8% |
Кому это вообще надо? И кому не надо
GLM-5.2 явно не для тех, кто решает задачки из школьной алгебры. Выбрасывать 1M контекста на «напиши письмо» — всё равно что стрелять из пушки по воробьям. Модель тяжелая: полный инференс с 1M контекстом требует минимум 80GB VRAM (H100 или две A100). Хотите запустить локально? Вот опыт запуска 256K модели на 8×5070 Ti — для GLM-5.2 с 1M понадобится примерно в 4 раза больше памяти, так что советую либо облачные инстансы, либо квантование. Кстати, квантование до Q4 снижает потребление до 48GB, но качество на математике проседает на 5-7%.
Идеальный юзер — это инженер, работающий с большими кодовыми базами (микросервисы, SDK, библиотеки), юрист, анализирующий тысячи страниц контрактов, или исследователь, обрабатывающий пачки научных статей. Ещё — разработчики автономных агентов, которым нужно помнить всю историю диалога длиной в несколько дней. Для таких задач GLM-5.2 — едва ли не лучший open-source вариант на сегодня.
Но есть категория задач, где модель откровенно слаба: мультимодальные сценарии (GLM-5.2 не принимает изображения), генерация кода с ультра-длинными файлами (больше 10K строк) — тут IndexShare начинает терять внутренние ссылки. И ещё: если вам нужно обрабатывать контексты больше 1M, посмотрите на FlashMemory для DeepSeek V4 — там Lookahead Sparse Attention умеет растягивать до 4M без квадратичного роста.
MIT лицензия: почему это меняет правила игры
Большинство open-weight моделей с длинным контекстом (например, Qwen2.5-72B-1M) либо имеют ограничения на коммерческое использование, либо требуют лицензионных отчислений. GLM-5.2 под MIT — бери и делай что хочешь. Хочешь дообучать на своих данных? Пожалуйста. Хочешь встроить в проприетарный продукт и не раскрывать исходники? Без проблем. Это серьёзный аргумент для компаний с NDA-политиками, которые боятся утечек через API. Как и предшественник GLM-5, новая версия заточена на то, чтобы быть доступной, а не просто демонстрацией технологий.
Напоследок: что дальше?
IndexShare — не серебряная пуля. Это элегантный компромисс, который сдвигает границу возможного для open-source моделей. GLM-5.2 не пытается быть лучшим во всём — она создана для одной конкретной задачи: работать с длинными контекстами эффективнее, чем конкуренты. И у неё это получается. Если тренд сохранится, то уже к концу 2026 года 1M контекст станет стандартом для enterprise LLM, а IndexShare-подобные архитектуры — мейнстримом.
Мой совет: если вы строите систему, где контекст в 500K+ токенов — не роскошь, а необходимость, скачайте веса, поставьте MTP, квантуйте до Q4 и забудьте про облачных провайдеров с их тарифами за токен. GLM-5.2 — это ваш шанс держать данные под контролем и не платить за каждый миллион.
