К рекурсивному самоулучшению: как GLM построила собственную инфраструктуру инференса

Команда Z.ai опубликовала запись в блоге, которая начиналась как рефлексия, а превратилась в технический разбор одного из самых показательных кейсов агентной разработки: модель GLM-5.3 в роли Infra Agent построила и оптимизировала производственную инфраструктуру инференса — в том числе для самой себя.

Модель, которая помогает строить ИИ

Авторы начинают с признания: GLM порой демонстрирует возможности, которые их удивляют и даже тревожат. В октябре 2025 года они начали усиливать кибербезопасностные навыки модели — а менее чем за год партнёры по безопасности с помощью GLM нашли тысячи уязвимостей в реальных кодовых базах. Для ответственного использования этой возможности пришлось создавать программу доверенного доступа.

Ещё сильнее команду потряс более фундаментальный сдвиг: GLM всё больше помогает строить сам ИИ. Модель выполнила инфраструктурную задачу, которая раньше заняла бы у команды опытных инфраструктурных инженеров недели, — и эта работа напрямую влияет на обучение следующего поколения моделей. Отсюда и заголовок про Recursive Self-Improvement (RSI): при достатке вычислений и времени конечная точка такой траектории — система, способная полностью автономно проектировать и обучать собственного преемника.

Показательна и эволюция внутреннего использования: до GLM-4.7 собственную модель для кодинга применяли скорее «из чувства долга», а сегодня GLM-5.3 стала незаменимым ежедневным инструментом всей команды. До полноценного RSI пока далеко, но ранние формы уже видны — описанный кейс как раз такой пример.

GLM-5.3-Flash на 100 000 ускорителей

Основная часть статьи — про запуск GLM-5.3-Flash. Z.ai построила полный production-grade инференс-сервис с нуля на кластере из более чем 100 000 китайских AI-ускорителей, и весь производственный инференс модели работает на этой системе. Кластеров отечественных (китайских) чипов такого масштаба до этого никто не разворачивал: ограниченная память и пропускная способность, новая архитектура модели, контекст 1M токенов, мультимодальные запросы, незрелая экосистема и неполная поддержка ядер.

Значительная часть работы была выполнена Infra Agent на базе GLM-5.3. Дальше — уже знакомая история: модель тестировали на OpenCode и OpenRouter под анонимным именем Ox-Alpha, и в первую неделю она стала самой используемой моделью на обеих платформах, обработав более 62 трлн токенов за шесть дней.

Стек оптимизаций получился агрессивным: внутринодовый тензорный параллелизм для linear attention и LM Head, ReplaySSM, W8A8-квантизация, смешанная квантизация KV-кэша (INT8/FP8/BF16), Layer Split, а сверху — disaggregated-архитектура Encode-Prefill-Decode (EPD). Вместе это дало примерно 3× к end-to-end производительности: утилизация железа и стоимость на токен вышли на уровень mainstream NVIDIA GPU. От первой адаптации модели до продакшена прошло меньше двух недель, итоговый прирост пропускной способности — трёхкратный относительно стартового базлайна.

Плотная обратная связь: главная идея

Ключевой инсайт команды: инженерная эффективность агента зависит не только от умения писать код, но и от того, даёт ли система полезный обратный след, который можно проследить до конкретной причины. End-to-end метрики вида «TTFT вырос на 30%» не объясняют, какой слой виноват, почему текущая гипотеза неверна и что тестировать дальше. Кодовая база — лишь статический контекст, а численные расхождения и регрессии рождаются из динамических взаимодействий ядер, стратегий параллелизма, коммуникации, управления памятью и оркестрации.

Решение — «плотная обратная связь» (dense feedback) с тремя характеристиками:

1. Локальность. Обратная связь привязана к конкретным параметрам запуска, изменениям кода, ядрам, потокам и путям исполнения — это сужает круг поиска. Не «упала точность после fusion-оптимизации», а различие выходов для конкретного запроса до и после изменения.
2. Дешевизна и скорость. Вопрос, на который отвечает kernel-тест или локальный микробенчмарк, не должен требовать полного деплоя и нагрузочного теста. Короткие циклы валидации помогают агенту быстрее сходить с неверных гипотез.
3. Объективная проверяемость. Корректность и прирост производительности подтверждаются эталонными реализациями, результатами тестов и сравнимыми метриками экспериментов. Корреляция наблюдений — не причина; нужны контролируемые эксперименты.

Сложилась петля из трёх участников: инженеры задают цели и системные границы, агент занимается анализом, гипотезами и изменениями кода, экспериментальная среда выдаёт многослойную и проверяемую обратную связь. Три кейса ниже показывают, как это работает.

Кейс 1. Корректность: ошибка в KDA-ядре

Оптимизация производительности бессмысленна без численной корректности. Команда построила отображение стратегий параллелизма инференс-движка на реализации ядер: агент мог понять, какие ядра затрагивает конфигурация, как делятся входы и какие пути исполнения сравнивать с непараллельными. Так системный дизайн превратился в исполнимые и прослеживаемые задачи проверки.

На этом этапе и всплыла проблема численной точности в CP-пути (Context Parallelism) KDA-ядра. Слияние состояний из разных шардированных фрагментов контекста упрощённо выглядит так:

M = tl.dot(M_chunk, M)     # Merge state transformations across shards
S_next = tl.dot(M, S) + H  # Update the initial state for the next shard

В исходной реализации tl.dot по умолчанию считал в TF32 даже при FP32-входах: ради скорости. Ошибка накапливалась при слиянии трансформаций и обновлении состояний и становилась заметнее на длинных контекстах. Фикс — явное указание input_precision="tf32x3" для обеих операций: три TF32-операции на Tensor Core дают результат более высокой точности, сохраняя большую часть их производительности.

Показательно, как работала среда обратной связи: отображение стратегий на ядра определило, что тестировать, сравнение параллельных и непараллельных путей выявило расхождение, анализ точности объяснил причину, регрессионные тесты подтвердили изменение. Фикс ушёл в апстрим Flash Linear Attention — детали в PR #1180.

Кейс 2. Системное поведение: узкое место в KV Transfer

Для системных проблем инженеры определили агенту сценарии тестирования — Prefill отдельно, Prefill + KV Transfer, Decode отдельно — с критериями приёмки. Например, разрыв между Prefill + KV Transfer и чистым Prefill при той же нагрузке не должен превышать 5%.

Агент обнаружил сценарии, где разрыв превышал 20%, и сузил поиск до накладных расходов и конкурентности KV Transfer. Изучение таймлайна показало аномалию: выполнение Python-стороны KV Transfer никогда не пересекалось по времени с интервалами вызовов DeepEP dispatch/combine. Спуск по цепочке вызовов до границы Python/C++ выявил причину: в DeepEP v1.2.1 функции intranode_dispatch и intranode_combine явно не отпускали Python GIL, плюс при необходимости узнать число полученных токенов CPU ждал ответа от GPU. Пока эти вызовы держали блокировку, Python-поток Mooncake Transfer не мог вовремя получить GIL — постановка задач на передачу задерживалась, и наложение передачи на вычисления не происходило, даже если сам механизм передачи асинхронный.

Косвенным подтверждением стал исходный код: internode_dispatch в той же версии GIL уже отпускал, с комментарием ровно про эту проблему. Фикс — освобождение GIL на нужных интервалах выполнения C++. После него разрыв между Prefill + KV Transfer и чистым Prefill упал ниже 1%. Здесь плотная обратная связь связала end-to-end производительность, межслоевое поведение рантайма и конкретную деталь реализации: ограничение превратило «не соответствует ожиданиям» в чётко определённое расхождение тестов, таймлайн сузил поиск до конкурентности двух компонентов, анализ кода указал на границы удержания GIL.

Кейс 3. Производительность: скелеты оптимизаций

Оптимизация ядер отвечает на два вопроса: как понять, что оптимизация работает, и где искать многообещающие направления. Первое требует оценивать ядро в реальном окружении движка: дать вычислительному ядру больше ресурсов может означать отнять их у KV Transfer и замедлить весь конвейер. Второе — извлекать экспертизу из рукописных ядер проектов вроде SGLang, Flash Linear Attention и DeepGEMM.

Агента научили извлекать техники оптимизации из существующих ядер на разных языках и платформах и дистиллировать их в «скелеты оптимизаций»: условия применимости, способы преобразования, ресурсные ограничения и доказательства валидности. Для нового ядра агент стартует от скелетов, профилированием и многослойным тестированием пересматривает tiling, доступ к памяти и распределение ресурсов, а проверенные находки возвращаются в библиотеку скелетов.

Эволюция представительного KDA Decode ядра из Figure 4: внедрение ReplaySSM (обмен вычислений на память) увеличило время выполнения с v0 до v1; оптимизация деления сократила время v1 на 9,6%; получив подтверждение, что узкое место — вычисления, агент обнаружил, что оригинал тайлится по измерению V и повторяет одни и те же FP32-нормализацию и gating четыре раза. Он объединил тайлы в один thread block, удержал промежуточные результаты в регистрах и заменил избыточные вычисления одним warp-level reduction — пожертвовав частью параллелизма, но получив ускорение в 1,71× относительно v2.

Что это значит

Три кейса показывают: ценность обратной связи — не в объёме, а в том, отвечает ли она на вопрос агента прямо сейчас. Кучи неструктурированных логов заслоняют сигналы, профилирование с неполным покрытием ведёт к ложной атрибуции, а выигрыш в микробенчмарке не обязан превращаться в end-to-end прирост. Ответственность инженеров — три вещи: задавать цели и системные ограничения, строить среду обратной связи, которой агент может пользоваться напрямую, и ревьюить критические изменения в архитектуре, асинхронной конкурентности и продакшен-рисках.

Формула из статьи: модель оптимизирует систему — система выполняет модель. До рекурсивного самоулучшения пока далеко: выбор целей, границ и оценка рисков остаются за людьми, и авторы считают, что эту линию люди должны удерживать долго. Но цифры — две недели, трёхкратный прирост, 100 000 ускорителей — намекают, что прогресс на этой границе замедляться не собирается.