Окно мониторинга: последние 24 часа (2026-09-19 07:00 ~ 2026-09-20 07:00, пекинское время). Текущий выпуск — регулярное ежедневное окно, пересечений с предыдущим выпуском нет. Источники: GitHub (сплошная проверка времени отправки по 28 репозиториям организации tile-ai, в окне были отправки в 3 репозитория; по основному репозиторию построчно перепроверены 3 влитых коммита и 5 новых PR, включая текст PR, число изменённых файлов и количество добавленных/удалённых строк; 5 влитых коммитов и 1 новый PR в TileOPs; цепочка зависимостей, контракты модели и записи проверки серии из 4 PR по страничному k-пулу GLM-5.3; полный разбор файлов результатов бенчмарков и корректности снапшота TileOPs-nightly, а также метаданные окружения; ежедневный отчёт регрессии Ascend; проверка отправок в репозиториях адаптации и репозиториях потребителей), Google News RSS с несколькими группами запросов на китайском и английском (через прокси), Hacker News, arXiv

Индекс выпуска

  • Главное за сегодня: на стороне ROCm полная цепочка разреженного внимания с k-пулом для GLM-5.3 собралась в единую цепь за 24 часа, четыре коммита в сумме дают около 9,8 тысяч добавленных строк (09-19/09-20)
    1. Прогресс ключевых проектов
      • 1.1 Основной репозиторий: бэкенд Metal получил 32-битное целочисленное атомарное сложение, переносимые ядра счётчиков больше не застревают на генерации кода (09-19)
      • 1.2 Основной репозиторий: 256-битный глобальный доступ к памяти ограничен архитектурой SM100 и новее, старые архитектуры откатываются к 128-битному (09-19)
      • 1.3 Основной репозиторий: набор тестов за раз урезан на 509 строк, утверждения быстрой математики переведены на настоящую эталонную реализацию (09-20)
      • 1.4 Очередь ревью основного репозитория: PR по перехвату типов данных обновлён, PR по строкам Metal закрыт без влития, бэкенд Tile IR в состоянии черновика и без обновлений (09-19/09-20)
      • 1.5 TileOPs: влито ядро FP8 для пакетного матричного умножения с транспонированием, ускорение до 4,66 раза на H200 (09-19)
      • 1.6 TileOPs: ядра GEMM переименованы по сервисным областям, две полосы GEMV объединены (09-19)
      • 1.7 Новое в TileOPs: блочная нарезка хвоста группового GEMM, прямое догоняющее движение за групповыми ядрами CUTLASS (09-19)
    1. Мультибэкендная адаптация (Ascend / Sunrise / MetaX / Hygon / Moore Threads)
      • 2.1 Ascend: ежедневная регрессия из 1936 пунктов пройдена полностью, второй день подряд (09-20)
      • 2.2 MetaX, Hygon, Moore Threads, Sunrise: новых коммитов в окне нет (09-17/09-18)
    1. Экосистема и потребители
      • 3.1 Ночной снапшот: 1040 бенчмарков и 1118 проверок корректности с нулевыми сбоями (09-19)
      • 3.2 Управление достоверностью бенчмарков: 8 аномалий пропускной способности и три исправления в тот же день (09-19/09-20)
      • 3.3 Потребители: в TileKernels и FlashQLA в окне не было отправок (09-18)
      • 3.4 Линия миграции: обновлён PR миграции предзаполнения плотного Gated DeltaNet (09-19)
    1. Сообщество, руководства и мероприятия
      • 4.1 Сайт документации: одно развёртывание сайта TileOPs, содержимое сайта не изменилось (09-19)
      • 4.2 Медиа и академическая сторона: нулевой прирост в окне (09-20)
      • 4.3 Ритм версий: основной репозиторий по-прежнему v0.1.14, теги репозиториев адаптации не двигались (09-02)
    1. Наблюдения за трендами
      • 5.1 Линия ROCm: от «бэкенд работоспособен» к «нативные операторы новой модели собраны в цепь»
      • 5.2 TileOPs вкладывает день в систему измерений: сначала сделать суждение достоверным, потом говорить о быстроте
      • 5.3 Все три влитых коммита основного репозитория в этом окне — восполняющего типа, прирост — в очереди ревью
      • 5.4 Тихая зона матрицы бэкендов расширяется: только Ascend сохраняет ежедневную регрессию
      • 5.5 Пробелы и точки риска
  • Приложение: материалы и пояснения по проверке

Главное за сегодня: на стороне ROCm полная цепочка разреженного внимания с k-пулом для GLM-5.3 собралась в единую цепь за 24 часа

Дата: 2026-09-19 по 2026-09-20　Источник: tilelang #3251 Обслуживание хвоста декодирования k-пула GLM-5.3／#3253 Логиты страничного k-пула／#3254 Преобразование Top-K для k-пула／#3255 Слияние выбора для страничного k-пула

В предыдущем окне (вечер 09-18) по направлению ROCm открылся #3250 для сжатия k-пула и записи в кэш для GLM-5.3; в текущем окне тот же автор за один день открыл подряд четыре коммита, доведя эту цепочку от обслуживания хвоста декодирования до слияния выбора; четыре коммита в сумме добавляют около 9767 строк, изменено 40 файлов (по отдельным коммитам — 7, 9, 11, 13 файлов). Все четыре помечены как составные зависимости (stacked), причём #3255 в описании указывает: «включает коммиты с #3250 по #3254 вплоть до их влития» — автор организует ревью как одну полную цепочку поставки. К концу окна ни один из четырёх не был влит.

Эта цепочка обслуживает уже выпущенную конфигурацию GLM-5.3-Flash: index_kpool=4, index_topk=2048, index_head_dim=128, index_n_heads=32. По этому контракту путь длинных строк выбирает 512 пулов по четыре токена, разворачивает их в 2048 исторических токенов, а затем добивает хвост менее трёх токенов — такова конкретная форма бюджета разреженного внимания на стороне кэша.

Распределение ролей между четырьмя коммитами:

  • #3251 (создан 09-19 08:31): поддержка хвоста декодирования. Ядро предзаполнения для каждого запроса инициализирует скользящий BF16-хвост, выполняет упорядоченное пакетное декодирование (обычный и спекулятивный пути декодирования), пул сжимается и записывается обратно при поступлении замыкающего токена; проверяется принадлежность хвоста, порядок позиций, заполнение и уникальность записи в кэш.
  • #3253 (создан 09-19 13:10): страничные logits. Выполняется страничное FP8 MQA-оценивание на сжатом кэше k-пулов: масштабирование по пулам, ReLU по каждому головному запросу, свёртка с предоставленными вызывающей стороной FP32 весами голов; поддерживаются интервалы пулов и принадлежность строк таблицы страниц по запросу, а до запуска отклоняются некорректные формы, типы, интервалы и строки страниц.
  • #3254 (создан 09-19 14:06): преобразование Top-K. Переиспользуется безопасный на стороне ROCm селектор tl_topk, по бюджету в 2048 токенов выбираются 512 пулов и разворачиваются в логические индексы токенов; короткие строки перечисляются напрямую, длинные используют радиксный выбор; поддерживаются три отображения вывода: тождественное, прямая таблица токенов и нерегулярные смещения.
  • #3255 (создан 09-20 00:21): слитное выбирание. За один запуск выполняются оценивание, радиксный выбор и преобразование индексов токенов; напрямую потребляется производственная форма чередующейся раскладки кэша uint8 (FP8-ключи, за которыми следуют FP32-масштабы), первая радиксная гистограмма сворачивается в этап оценивания; для стабильности графового воспроизведения предоставляются собственные FP32-буферы временного хранения и INT32-буферы вывода вызывающей стороны.

Проверка ведётся по exact-head CI: на ROCm 7.2 gfx942 для #3251 сообщается о 2423 пройденных и 1852 пропущенных тестах, все шесть сфокусированных тестовых случаев хвоста декодирования проходят; для #3255 сообщается о 2435 пройденных и 1816 пропущенных тестах, все шесть тестовых случаев слитного селектора проходят. Тестовое покрытие охватывает длинные и короткие строки, выпущенную геометрию 2048, нулевую историю и сценарии с более чем 4096 равных долей.

Толкование: если связать #3249 (пример декодирования KDA), #3250 и четыре коммита этого окна, продвижение на стороне AMD уже переключилось с «заставить бэкенд работать» на «нативные операторы новой модели тоже должны быть здесь», причём применяется организация через укладывающиеся в стек PR, а весь путь разреженного внимания продвигается как единый артефакт поставки.

1. Прогресс ключевых проектов

Обзор окна: в основную ветку главного репозитория влито 3 коммита, все — восполняющего типа (добавление возможностей, расширение области применимости, сокращение избыточности тестов); в очереди ревью открыто 5 новых PR, из которых 4 относятся к сегодняшней ключевой серии ROCm. TileOPs второй день подряд вливает по 5 коммитов за сутки и открывает 1 новый PR по производительности; его ночной бенчмарк выдал снимок в пределах окна.

1.1 Главный репозиторий: бэкенд Metal дополнен 32-битным целочисленным атомарным сложением (09-19)

Дата: 2026-09-19　Источник: tilelang #3211 Metal поддерживает 32-битное целочисленное атомарное сложение

Влито 09-19 20:55, автор anerli, 2 файла, +77/-0; этот PR вошёл в ревью 09-12 и был закрыт в пределах окна.

Исправляется конкретный пробел в возможностях: Metal не мог опустить скалярные int32 и uint32 T.atomic_add (включая форму с возвратом старого значения), и переносимые ядра, зависящие от целочисленных счётчиков или распределения слотов, напрямую падали на этапе генерации кода. Изменение опускает такие вызовы до atomic_fetch_add_explicit в Metal: при преобразовании атомарного указателя сохраняется различие между адресными пространствами device и threadgroup, применяется relaxed-порядок (согласующийся с существующей семантикой свёртки для этой операции), явно отклоняются неподдерживаемые ширины, типы и домены памяти, а также добавляется регрессия по опусканию исходного кода и выполнению на Metal (покрывающая обе формы: атомарность в группе потоков и возврат старого значения).

В плане проверки автор прогнал на Apple Metal конкурирующую гистограмму в группе потоков, сверив итоговые счётчики и возвращённое множество старых позиций; локальный набор тестов Metal: 20 пройдено, 3 пропущено, два новых теста атомарности проходят.

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

1.2 Главный репозиторий: 256-битный доступ к глобальной памяти ограничен SM100 и более новыми архитектурами (09-19)

Дата: 2026-09-19　Источник: tilelang #3248 256-битный доступ к глобальной памяти ограничен SM100 и более новыми архитектурами

Влито 09-19 13:15, автор penguin-wwy, 3 файла, +56/-7. Этот PR появился в предыдущем окне как новый открытый пункт, а в этом окне был влит.

Ограничить путь 256-битных глобальных load/store PTX архитектурами SM100 и новее, причём выдавать его только начиная с CUDA 12.9; для старых архитектур возвращаться к 128-битному пути; добавить CUDA-тесты для pre-SM100, покрывающие откат T.ldg256/T.stg256 и векторного store.

Толкование: широкий доступ к памяти — это возможность новой архитектуры; на пути «сначала ширина, потом сопутствующие условия» именно область отката и является источником регрессионного риска; эта правка ужесточает принцип «выдавать, если можем» до «выдавать, только когда следует», и вместе с консолидацией тестов из 1.3 относится к категории работ по закрытию исторических долгов.

1.3 Основной репозиторий: тестовый набор разом похудел на 509 строк, утверждения быстрой математики переведены на настоящие эталонные реализации (09-20)

Дата: 2026-09-20　Источник: tilelang #3252 Удалить дымовые тесты дублирующей генерации кода и исправить утверждения быстрой математики

Смержено 09-20 01:44, автор penguin-wwy, 6 файлов, +20/-509. Удалены дублирующиеся дымовые тесты генерации кода matmul и T.gemm на сторонах CPU и LLVM, полностью удалён отдельный CUDA-модуль тестов быстрой математики; и исправлено утверждение «сравнение вывода быстрой математики с самим собой» — для exp10, log2, log10, cos, sin, tan добавлены настоящие эталонные реализации, tan переведён на детерминированные входы с ослаблением допуска до rtol=atol=1e-2, а неподдерживаемые операции теперь явно проваливают утверждение вместо самосравнения.

Толкование: удалено дублирующее покрытие, добавлено настоящее покрытие — утверждение-самосравнение равносильно отсутствию утверждения; это вклад в «повышение качества и устранение дублей» тестовых активов, созвучный общему курсу основного репозитория на вынос контроля качества на более ранние этапы.

1.4 Очередь ревью основного репозитория: PR по перехвату типов данных обновлён, PR по числу строк Metal закрыт без мержа, бэкенд Tile IR переведён в черновик (09-19/09-20)

Дата: 2026-09-19 — 2026-09-20　Источник: #3245 Отклонять неподдерживаемые комбинации типов данных GEMM до генерации кода CUDA／#3215 Изменяемое во время выполнения число строк GEMM для Metal／#3247 Бэкенд исполнения CUDA Tile IR

Динамика статуса трёх существующих PR:

  • #3245 (обновлён 09-19 16:20, не смержен): перехватывает неподдерживаемые комбинации типов данных GEMM до входа в генерацию кода CUDA, продолжая курс на «вынос тихих ошибок на более ранний этап в виде явных сбоев».
  • #3215 (закрыт 09-20 01:37, не смержен): «изменяемое во время выполнения число строк GEMM» на стороне Metal закрыт после девяти дней ревью, мержа не состоялось.
  • #3247 (ключевой в прошлом выпуске, бэкенд исполнения CUDA Tile IR): в настоящее время в статусе черновика и без каких-либо обновлений в окне, последняя активность остановилась вечером 09-18; в этом выпуске только констатация статуса, без дальнейшего разбора.

Толкование: содержательный прирост в очереди ревью основного репозитория уже подхватили ROCm-операторы модели (см. сегодняшний фокус), продвижение существующих крупных изменений в этом окне застопорилось.

1.5 TileOPs: смержен транспонирующий ядро FP8 батчевого матричного умножения, ускорение до 4,66 раза на H200 (09-19)

Дата: 2026-09-19　Источник: TileOPs #2153 Транспонирование операнда B FP8 с помощью ядра со слитным доступом к памяти

Смержено 09-19 09:55, автор michaelwithu, 7 файлов, +308/-51, 2 коммита. Этот PR появлялся в предыдущем окне в статусе нового (тогда 4 из 5 случаев проигрывали контрольной реализации, худший уровень — 0,34 раза), а в этом окне смержен.

Содержание: конкретизация [B, K, N] → [B, N, K] для операнда B FP8 заменена на транспонирующее ядро TileLang со слитным доступом к памяти; путь копирования теперь определяется шагами b (а не только trans_b), вход с K в самом внутреннем измерении пропускает копирование при обоих вариантах параметров; предупреждение о раскладке выдаётся только при реально происходящем транспонировании; добавлено прямое покрытие транспонирующего ядра FP8 (включая хвост тайла), а опциональная строка бенчмарка контрольной реализации выровнена по эталону fp32.

Результат (H200, CUDA 13.2, torch 2.13.0): ускорение по пяти случаям относительно основной ветки от 2,30 до 4,66 раза — MoE prefill 0,8741 → 0,1874 мс (4,66 раза), MHA decode PV 0,0605 → 0,0131 мс (4,62 раза), квадратная матрица 4 батча 1K 0,0355 → 0,0137 мс (2,59 раза); соотношение с контрольной реализацией сменилось с отставания на опережение (например, квадратная матрица 8 батчей 2K выросла с 1,81 раза до 4,16 раза); путь trans_b=True без изменений, сохраняется 1,03 — 1,20 раза.

Толкование: это закрытие ветки в рамках #2130 (метазадача GEMM) — батчевое матричное умножение на стандартных формах уже утвердилось, FP8 и краевые случаи раскладки оставались последними слабыми местами, и этот вклад закрывает самый крупный из них.

1.6 TileOPs: ядра GEMM переименованы по обслуживаемой области и объединены две полосы GEMV (09-19)

Дата: 2026-09-19　Источник: TileOPs #2156 Переименование ядер по обслуживаемой области, объединение двух полос GEMV

Слито 09-19 в 23:11, автор lcy-seso, 19 файлов, +421/-274.

Содержание: каждый класс плотного ядра GEMM / BMM переименован по принципу «чем он отличается от родственного класса» — структура главного цикла (Tma, CpAsync, Persistent), форма входных данных (Gemv) или гранулярность масштабирования (TensorScale, BlockScale). SmallBatchGemmKernel слит в GemvKernel: оба и так использовали один и тот же конструктор, различаясь лишь заявляемой областью и правилами конфигурации; после объединения один класс содержит три полосы, полоса определяется через band_for и входит в параметры конструктора, идентификатор кэша, конфигурацию по умолчанию и сетку тюнинга. Диспетчеризация не изменилась (объединение трёх полос равно прежним двум областям), тело ядра, правила конфигурации и сетка тюнинга не тронуты; w4a16_decode.py вслед за именем класса переименован в w4a16_gemv.py.

Критические изменения: ключи kernel_map= мигрируют вместе с именами классов (7 ключей, например gemm_kernel → gemm_tma_kernel, gemm_basic_kernel → gemm_cp_async_kernel); раньше старые ключи молча отбрасывались и приводили к заводской реализации, теперь же на этапе конструирования возникает явная ошибка.

Оценка: переименование — не вопрос эстетики; по мере роста числа ядер имя должно напрямую отвечать на вопрос «почему следует выбрать именно это»; заодно «молчаливый откат при передаче неверного ключа» заменён на явный отказ, что соответствует той же дисциплине, что и правило основного репозитория «молчаливые ошибки выносить на ранний этап».

1.7 TileOPs, новое: блочная обработка хвостовых блоков группового GEMM, лобовая догоняющая атака на групповые ядра CUTLASS (09-19)

Дата: 2026-09-19　Источник: TileOPs #2157 Блочная обработка хвостовых блоков группового GEMM и возможность для вызывающей стороны объявить layout заполненных строк

Открыто 09-19 в 22:12 (не слито), автор michaelwithu, 10 файлов, +297/-110.

Содержание: из четырёх рабочих нагрузок группового GEMM только nt bf16 имеет реального противника (в случае fp16 групповое матричное умножение torch вырождается в 16 отдельных вызовов, и только bf16 доходит до группового ядра CUTLASS), и оно отстаёт на 6.4%. Две корневые причины: плитка 128x256 размещает всю выходную плитку (64 KiB) в разделяемой памяти, из-за чего в главный цикл помещается лишь трёхуровневый конвейер (для сравнения — четырёхуровневый); механизм epilogue_stage_n, позволяющий заменить этот буфер на четвёртый уровень конвейера, ранее был открыт только для плотного и пакетного матричного умножения. Просто молча открыть механизм тоже нельзя: последняя плитка плотной группы — это остаточный блок, такие строки хранятся с построчной маской, а не выписываются целиком одной плиткой, и блочная обработка вместо этого платит лишний раунд промежуточного хранения — при реальной маршрутизации MoE (минимум 1 строка на группу, максимум 663 строки, 55% плиток — остаточные блоки) цена составляет от 3% до 5.5%. Доля остаточных блоков — свойство маршрутизации, а не формы, селектор не может их различить, поэтому вызывающей стороне даётся возможность объявить, «какой случай у меня в руках».

Оценка: смена решения о «блочности» с вывода по форме на объявление вызывающей стороной — ключевой шаг группового GEMM к догонянию CUTLASS; повлияет ли это на путь по умолчанию, станет ясно после слияния по ночной регрессии.

2. Мультибэкендовая адаптация (Ascend / Sunrise / MetaX / Hygon / Moore Threads)

Обзор окна: у четырёх существующих бэкендов плюс Sunrise коммитов нет; единственная динамика — ежедневный отчёт о регрессии Ascend.

2.1 Ascend: ежедневная регрессия, все 1936 пунктов пройдены, второй день подряд (09-20)

Дата: 2026-09-20　Источник: tilelang-ascend ежедневный отчёт о тестировании #1814

Ежедневное плановое тестирование на стороне Ascend выпустило отчёт 09-20 в 05:30 (пекинское время): все 1936 пунктов пройдены, провалов 0, доля успешных 100%. По сравнению с предыдущим днём (1936 пунктов 09-19) и число тест-кейсов, и результат не изменились; новых коммитов в репозитории за окно нет.

Оценка: три слияния в основном репозитории за это окно приходятся на Metal, CUDA и тесты, пути Ascend они не затрагивают, неизменность регрессии ожидаема. Число тест-кейсов два дня подряд держится на 1936, что говорит о том, что за окно upstream не принёс на сторону Ascend новых тест-кейсов; их шардирование многопоточного тестирования (#1812) за окно не обновлялось.

2.2 MetaX, Hygon, Moore Threads, Sunrise: за окно новых коммитов нет (09-17/09-18)

Дата: 2026-09-17 – 2026-09-18 (последний пуш в каждом репозитории)　Источники: tilelang-metax／tilelang-hygon／tilelang-musa／tilelang-sunrise

Во всех четырёх репозиториях за 24-часовое окно коммитов нет: последние пуши MetaX и Hygon — 09-17 (17:38 и 20:25), Moore Threads — утром 09-17, Sunrise — утром 09-18; всё это уже было отражено в предыдущем выпуске. Статус версий: у MetaX и Hygon релизов нет, у Moore Threads последний — v0.1.14+musa.1 (09-11), кандидатная ветка Sunrise остановилась на 0.1.14+sunrise.1.1.0; теги ни в одном репозитории в пределах окна не обновлялись.

Интерпретация: активность Sunrise в предыдущем окне, когда он вышел в кандидаты, не продолжилась — все четыре адаптационных репозитория синхронно ушли в тишину; однодневная тишина не образует тенденции (у стороны-адоптера и ранее были прецеденты «импульсных обновлений»), но может служить точкой наблюдения — если в следующем окне тишина сохранится, это будет означать, что ревью адаптаций у всех вендоров идёт по ритму пакетов.

3. Экосистема и сторона-адоптер

3.1 Ночной снимок: 1040 бенчмарков и 1118 проверок корректности без единого сбоя (09-19)

Дата: 2026-09-19　Источники: ветка снимков TileOPs-nightly／метаданные окружения снимка

Ночной конвейер в пределах окна сгенерировал снимок для TileOPs 917590ba (то есть #2154: слияние перестроения окна истории производительности из репозитория снимков) (коммит 09-19 16:19). Разбор двух файлов результатов — бенчмарков и корректности: корректность 1118 пунктов, сбоев 0, пропущено 2; бенчмарки 1040 тест-кейсов, сбоев 0, пропущено 3 — число тест-кейсов на уровне предыдущего снимка, все прошли.

Метаданные окружения совпадают с предыдущим выпуском: H200, CUDA 13.2, драйвер 595.71.05, лимит мощности 700 Вт, частота SM 1500 МГц (лимит 1980), частота памяти 3201 МГц, MIG отключён, длительность повтора 100 мс, прогрев 25 мс, образ записан по его контентному идентификатору, TileLang 0.1.11 с кодовым обозначением версии, PyTorch 2.13.0.

3.2 Управление достоверностью бенчмарков: 8 строк аномалий пропускной способности и три исправления в один день (09-19/09-20)

Дата: 2026-09-19 – 2026-09-20　Источники: #2155 тарификация экспертов, выбранных по маршрутизации／#1996 аудит байтов смотрит только на сторону чтения／#2154 перестроение окна истории производительности из репозитория снимков

В этом окне самые плотные инженерные усилия TileOPs были направлены не на операторы, а на то, чтобы «сделать само определение бенчмарков достоверным» — за один день три изменения:

  • #2155 (объединён 19.09 в 21:24): ночной запуск в 3.1 выявил 8 строк с аномальной пропускной способностью (все декодирующие рабочие нагрузки IndexedExpertMLPFwdOp, поровну fp16 и bf16), показания достигали 132,4 ТБ/с, тогда как физический предел H200 составляет около 4,8. В результате локализации была выявлена ошибка в формуле: количество байтов рассчитывалось по всем экспертам, тогда как маршрутизируемый MoE читает только экспертов, выбранных через topk_ids. После исправления показания снизились — deepseek-v3-decode-1 с 132,43 до 3,62 (активных экспертов 7/256), decode-32 с 6,97 до 4,47 (164/256), decode-64 с 5,06 до 4,47 (226/256), qwen3-235b-decode-32 с 4,92 до 4,42 (115/128). Попутное обнаружение: FusedMoEExpertsFwdOp использует ту же формулу, но всегда проходил проверку лишь потому, что рабочая нагрузка начинается с 512 token и все эксперты активны — это «прохождение по форме», а не «прохождение по корректности»; FusedMoeSharedExpertFwdOp же никогда не учитывал запись общего вывода.
  • #1996 (объединён 20.09 в 06:50): критерий байтового аудита изменён так, чтобы учитывать только сторону чтения. Грязные строки L2 записываются обратно лишь после завершения ядра, выходя за пределы интервала профилирования, поэтому измеренные байты записи естественно оказываются меньше алгоритмического минимума, и использование их для определения неудачи приводило бы к ошибочному отсеиванию корректных строк (при первом же выполнении были ошибочно осуждены три строки). Одновременно устранено безусловное начисление за умножение на alpha по умолчанию в add_fwd/sub_fwd (на каждый элемент считалось 2 FLOP, тогда как спецификация требует 1), а также добавлены CI-вход и способ запуска по семействам для аудита.
  • #2154 (объединён 19.09 в 15:36): 14-дневное окно базовой производительности перенесено с «изменяемого артефакта» на ветку-снимок (один коммит на запуск, никогда не истекает): ранее каждый запуск читал артефакт предыдущего и перезаписывал его, и однажды из-за API 502 один запуск опубликовал только свою единственную запись (в сравнении с 14, 15, 19 записями у соседей).

Толкование: три коммита соответственно решают вопросы «формула отвечает за семантику», «измерение отвечает за физику», «данные отвечают за прослеживаемость» — ночная базовая линия библиотеки операторов есть основа её кредита доверия как вышестоящей зависимости: сначала сделать выводы достоверными, затем говорить о быстроте.

3.3 Сторона внедрения: TileKernels и FlashQLA без отправок в окне (18.09)

Дата: 2026-09-18 (последняя отправка)　Источники: TileKernels／FlashQLA

В окне у обеих сторон внедрения не было отправок: последняя отправка TileKernels по-прежнему остаётся на 23.04; последняя отправка FlashQLA — 18.09 в 15:53 (три объединения, уже освещённые в прошлом выпуске). В организации TileRT также без отправок (последняя 13.08, уже седьмую неделю без движения).

3.4 Линия миграции: обновление PR миграции плотного предзаполнения Gated DeltaNet (19.09)

Дата: 2026-09-19　Источник: TileOPs #2144 Миграция плотного предзаполнения Gated DeltaNet

Обновлённый в окне PR категории миграции: перенос плотного предзаполнения Gated DeltaNet в существующую организацию ядер (создан 16.09, обновлён 19.09 в 23:11, не объединён). Автор — участник сообщества, тот же аккаунт, что и у репозитория документации TileSight, о котором сообщалось в предыдущем окне. Этот коммит относится к тому же контексту, что и переименование в 1.6 и метазадача GEMM в #2130 — структурная реорганизация библиотеки операторов после роста количества: линейное внимание, GEMM и постраничный кэш — все эти линии сходятся к единой организации классов и манифестов.

4. Сообщество, руководства и мероприятия

4.1 Сайт документации: одно развёртывание сайта TileOPs, содержимое сайта не изменилось (19.09)

Дата: 2026-09-19　Источник: Репозиторий сайта документации TileOPs.github.io

В окне зафиксировано одно развёртывание сайта документации TileOPs (коммит развёртывания ветки gh-pages от 19.09 в 08:01, соответствующий содержимому главной ветки на 17.09), в её ветке по умолчанию новых коммитов нет (последнее обновление содержимого по-прежнему #51 от 17.09). Это действие категории развёртывания, а не обновление содержимого; в основном репозитории сайта документации в окне отправок не было.

4.2 Сторона СМИ и академии: ноль прироста в окне (20.09)

Дата: 2026-09-20　Источники: Google News RSS (через прокси)／Hacker News／arXiv

Тематические запросы Google News RSS на китайском и английском (9 групп, включая имена компонентов, отечественные ускорители и комбинации терминов операторных ядер) в окне не дали прироста; на Hacker News за последние пять дней попаданий по теме нет; все 9 тематических результатов полнотекстового поиска arXiv относятся ко времени до этого окна (самая свежая — статья о моделировании производительности от 24.07, уже освещённая в прошлом выпуске); новых репозиториев в организации нет.

4.3 Ритм версий: основной репозиторий по-прежнему v0.1.14, теги адаптационных репозиториев не двигались (02.09)

Дата: 2026-09-02 (последний релиз)　Источник: Релиз основного репозитория v0.1.14

Последний тег основного репозитория по-прежнему v0.1.14 (релиз 09-02), в окне новых тегов нет; у TileOPs записей о релизах нет; в репозитории Ascend последний — TileLang-ascend v0.1.2.000-release (09-09); у Moore Threads — v0.1.14+musa.1 (09-11). Основной репозиторий не выпускал релиз уже 18 дней с момента v0.1.14, тогда как очередь ревью и слияния продолжают работу — разрыв между темпом релизов и темпом разработки растёт.

5. Наблюдения за тенденциями

5.1 Линия ROCm: от «бэкенд доступен» к «нативные операторы новых моделей образуют цепочку»

Суждение предыдущего выпуска — «прогресс на стороне AMD сместился к конкретным операторам конкретных моделей» — в этом окне усилилось: четыре PR отправлены одним пакетом в форме стекированной цепочки, охватывающей все звенья k-пула разреженного внимания GLM-5.3, и напрямую привязаны к контракту конфигурации уже выпущенной модели (бюджет 2048 token, пул 512, гранулярность пула в четыре token). Это говорит о том, что фронт работ на стороне ROCm уже организован по принципу «поставки модели», а не «достройки возможностей бэкенда» — скорость выхода специфичных для новой модели операторов на пути AMD становится прямым показателем зрелости этого бэкенда.

5.2 TileOPs вкладывает день в систему измерений: сначала сделать суждение достоверным, потом говорить о быстроте

Три изменения #2154, #2155, #1996 — все касаются логики суждений в бенчмарках и аудите, а плюс к этому ночные снимки в окне полностью зелёные, что говорит о том, что уровень сопровождения считает «правильность ночных выводов» столь же важной, как и «быстрее ли ядро». Сигнальная ценность такого управления в том, что только при достоверной системе измерений сравнение производительности (например, 4,66-кратное преимущество версии 1.5, разрыв 6,4% у версии 1.7) обретает смысл для принятия решений. С другой стороны, выявленная в этом окне ситуация «одна и та же ошибочная формула долго не обнаруживалась» также указывает на то, что охват логики суждений всё ещё имеет слепые зоны.

5.3 Все три слияния в основном репозитории за это окно — «доучивание», прирост в очереди ревью

Дополнение возможностей (атомарное сложение Metal), исправление области применимости (откат 256-битного доступа к памяти), повышение качества тестов (минус 509 строк с добавлением эталонной реализации) — все три указывают на расчистку долгов, а не на расширение новых возможностей. Реальный прирост — в очереди ревью: четыре изменения по операторам моделей ROCm; а крупное изменение прошлого выпуска (бэкенд Tile IR) перешло в состояние черновика и застопорилось. Основной репозиторий сейчас демонстрирует две колеи: «осторожные слияния, exploration остаётся в архиве» — крупные маршрутные изменения отстаиваются в форме черновиков, повседневная работа продвигается мелкими шагами.

5.4 Тихая зона матрицы бэкендов расширяется: только Ascend сохраняет ежедневную регрессию

В прошлом окне ещё была активность Sunrise в кандидатах, в этом окне все четыре адаптационных репозитория плюс Sunrise молчат, единственная динамика — ежедневная регрессия Ascend (1936 пунктов, все пройдены). Нужно избегать трактовки однодневного молчания как застоя (пульсирующий ритм у принимающих сторон уже имел прецеденты), но само это сравнение даёт показание: в многобэкендовой конфигурации только Ascend поддерживает «ежедневно видимый» инженерный ритм, активность остальных нужно наблюдать понедельно или даже помесячно.

5.5 Пробелы и точки риска

Три пункта требуют пометки: во-первых, все четыре PR по GLM-5.3 не слиты, стековая зависимость означает необходимость последовательного ревью, и любая застрявшая позиция затормозит всю цепочку; во-вторых, исправленные в этом окне 8-строчная аномалия пропускной способности и ложное срабатывание байтового аудита (3.2) говорят о том, что логика ночных суждений какое-то время работала ошибочно (аномальные показания завышались вплоть до 27 раз относительно физического предела), и стабильность исправленных критериев нужно постоянно наблюдать в последующих снимках; в-третьих, остановка релизов основного репозитория достигла 18 дней, очередь ревью продолжает накапливаться, а в окне был закрыт металлический PR, работавший девять дней (#3215) — баланс между пропускной способностью очереди и её затором является дальнейшей точкой наблюдения.

Приложение: материалы и пояснения по проверке

Таблица проверки источников

Источник Результат проверки
Организация tile-ai (28 репозиториев) В окне пуши в 3 репозиториях: tilelang, TileOPs, TileOPs-nightly; в TileOPs.github.io ещё один коммит развёртывания сайта
Ветка по умолчанию основного репозитория tilelang 3 слияния (#3211, #3248, #3252); в окне открыто 5 новых PR (#3251–#3255); #3247 в статусе черновика без обновлений
TileOPs 5 слияний (#2153, #2154, #2155, #2156, #1996); открыт 1 новый (#2157); #2144 обновлён
TileOPs-nightly Сгенерирован снимок для коммита 917590ba (файлы результатов бенчмарков и корректности, метаданные среды), результаты полностью разобраны
Ascend Ежедневный отчёт о регрессии: 1936 пунктов, все пройдены (второй день подряд); коммитов в репозитории за окно нет
Остальные отечественные бэкенды и Sunrise У MetaX, Hygon, Moore Threads, Sunrise за окно коммитов нет, теги не обновлялись
Принимающие стороны У TileKernels, FlashQLA за окно пушей нет; у TileRT внутри организации также нет пушей
Google News RSS (несколько групп на китайском и английском, через прокси) Ноль новых за окно
Hacker News За последние пять дней попаданий по теме нет
arXiv Последняя по тематическому поиску — 07-24, новых препринтов в окне нет
Сайты документации Одно развёртывание сайта документации TileOPs (содержимое не изменилось); у сайта документации основного репозитория пушей нет

Полный список источников