Окно мониторинга: 2026-10-27 07:00 ~ 2026-10-28 07:00 (пекинское время, 24 часа).

Источники: проверка каждого репозитория организации tile-ai на GitHub (tilelang / TileOPs / TileOPs-nightly / TileFoundry / tilelang-hygon / tilelang-metax / tilelang-ascend / tilelang-musa / tilelang-mlir-ascend / TileRT / tilescale / DeepStack / сайт документации и репозиторий ночных бенчмарков) + поиск фактических данных по смерженным и находящимся на рассмотрении изменениям (смержено 20, обновлено на рассмотрении 45) + полная проверка новых issue (7) + проверка diff на уровне коммитов + проверка страницы релизов и артефактов PyPI + проверка внешних репозиториев бэкендов (Hexagon / репозиторий операторов CANN / обёртка PPU / репозиторий фрагментов моделей) + несколько групп запросов Google News на китайском и английском языках (через прокси) + Hacker News + arXiv.

Индекс текущего выпуска

  • Ключевое за сегодня: официальный релиз TileOPs 0.1.0 — 206 операторов, в эталоне из 2265 строк 2262 строки не медленнее самой быстрой реализации; за 24 часа влито 20 коммитов, на ревью 45 обновлений, открыто 7 новых issue; в Hygon влиты 1389 строк двойного банка scale-буфера; сторонний бэкенд Hexagon — 15 коммитов за день
    1. Основной прогресс проекта
      • 1.1 Основной репозиторий: exp/sin/cos на ROCm больше не понижаются по умолчанию до быстрых встроенных функций, погрешность sin/cos снижена с 7.8e-04 до 6.6e-08 (#3621) (10-27)
      • 1.2 Основной репозиторий: автоопределение цели теперь читает текущее устройство HIP, на многокарточных машинах архитектура больше не фиксируется на карте 0 (#3594) (10-27)
      • 1.3 Основной репозиторий: константные строчные индексы TMA gather/scatter переводятся в int32, литеральная запись больше не вызывает краш компиляции (#3365) (10-27)
      • 1.4 Основной репозиторий: NVRTC и CuTeDSL берут текущий поток по устройству первого входного тензора (#3359) (10-27)
      • 1.5 Основной репозиторий: ключ кэша автотюнинга включает compile_flags, при смене опций компиляции для того же ядра старый бинарник больше не переиспользуется (#3338) (10-27)
      • 1.6 Основной репозиторий: ThreadSync помечает address_of как запись, добавлен барьер после непрозрачных вызовов (#3346) (10-27)
      • 1.7 Основной репозиторий: эпилог конвейера при числе ходов, известном во время выполнения, разворачивается напрямую, постраничное декодирование снова компилируется (#3356) (10-27)
      • 1.8 Основной репозиторий: исправлены статические границы заполнения срезов и отрицательных индексов, закрыты записи за границы и молчаливые отрицательные адреса (#3352 / #3347) (10-27)
      • 1.9 Основной репозиторий: область T.ws(-1) выполняется на всех потоках, одиночная запись больше не теряет сохранение (#3354) (10-27)
      • 1.10 Основной репозиторий: profiler при неуказанном устройстве использует текущее, сброс кэша больше не бьёт в карту 0 (#3357) (10-27)
      • 1.11 Новые дефекты: попадание в кэш ядер ломает шесть тестов, предполагающих холодную компиляцию; захват CUDA graph в CuTeDSL даёт пустой граф (#3694 / #3693) (10-27)
    1. Адаптация под множество бэкендов (Ascend / Hygon / ROCm / Hexagon)
      • 2.1 Hygon: scale-буфер HCU разделён на два банка, blockscaled GEMM при ручной warp-специализации использует одно отображение строк (#29) (10-27)
      • 2.2 Основной репозиторий Ascend: тела кандидатов PerCoreTask допускают внутренние if/else, условное заполнение L1 больше не отклоняется целиком (#3686) (10-27)
      • 2.3 Основной репозиторий Ascend: CI разделяет AscendC и PTO на две матричные задачи, их можно перезапускать по отдельности (#3687) (10-27)
      • 2.4 Репозиторий Ascend на ревью: Cython-обёртка лениво создаёт анализатор, что напрямую закрывает зафиксированную вчера проблему пересоздания при каждом вызове (#1948) (10-27)
      • 2.5 Репозиторий Ascend на ревью: оператор сжатия kpool для GLM-5.3, величина сдвига тензора на PTO (#1910 / #1949) (10-27)
      • 2.6 Основной репозиторий Ascend на ревью: векторизация T.Parallel на PTO, канал AutoSimVF, пакетный трёхмерный ND2NZ, многобуферность счётчика записей, идентичность сборки Bisheng в ключе кэша (#3512 / #3320 / #3689 / #3629 / #3691) (10-27)
      • 2.7 ROCm на ревью: определение архитектуры и образы pip-версии ROCm 10, преобразование FP4 и тип E8M0 (#3549 / #3665) (10-27)
      • 2.8 Ежедневные тесты репозитория Ascend: 2903 пункта пройдены полностью, второй день подряд без сбоев (#1950) (10-28)
      • 2.9 MetaX: в представлении организации есть метки времени push, ни в одной из шести веток нет новых коммитов в окне мониторинга (10-27)
      • 2.10 Сторонние: бэкенд Hexagon DSP — 15 коммитов за день, готовы векторизация HVX, арена VTCM, раскладка Crouton и встроенные функции DMA (10-27)
    1. Экосистема и потребители (TileOPs / TileFoundry)
      • 3.1 Релиз TileOPs 0.1.0: первый официальный выпуск со 206 операторами, публичный API зафиксирован (10-27)
      • 3.2 Эталон TileOPs 0.1.0: на H200 из 2265 строк 2262 строки не медленнее самой быстрой реализации, геометрическое среднее 1.37x (10-27)
      • 3.3 Известные пробелы и следующие шаги TileOPs 0.1.0: слитые операторы, целые модели, слияние вычислений и коммуникаций (10-27)
      • 3.4 В TileOPs влито четыре: where и masked_fill поддаются тюнингу, причинно-диагональный D128 оценивается по 64 ключам, разбиение предзаполнения разреженного длинного GDN, даты в журнале изменений привязаны к дню релиза (#2782 / #2783 / #2779 / #2781) (10-27)
      • 3.5 В TileFoundry влито два: весь диапазон отправляется по самим операндам, размер динамической разделяемой памяти задаётся фактическим использованием ядра (#273 / #271) (10-27)
      • 3.6 Внешняя экосистема: репозиторий операторов TileLang в сообществе CANN, обёртка для PPU-версии без изменений, пример фрагмента DeepSeek V4.1 Flash (10-27)
    1. Сообщество, руководства и мероприятия
      • 4.1 Шесть автоматических обновлений сайта документации за день (10-27)
      • 4.2 Четыре пункта проверки фактов в документации репозитория Ascend, больше всего комментариев к одному пункту

46-й раунд (#1628 / #1655 / #1656 / #1659) (27.10)

  • 4.3 На рассмотрении: выделение lower trace в отдельный набор инструментов для разработки (#3583) (27.10)
  • 4.4 Новостная сторона: Google News и HN за 24 часа не содержат новых публикаций в рамках текущего окна мониторинга (27.10)
    1. Наблюдения за трендами
  • Приложение: материалы и примечания по проверке

Главное за сегодня

TileOPs 0.1.0 вышел в рамках сегодняшнего окна, завершив длившееся несколько дней состояние «застряли на последней клетке». Артефакт 0.1.0 на PyPI был загружен 27.10 в 07:45 (пекинское время), на 45 минут позже момента среза предыдущего ежедневного отчёта; страница релиза на GitHub появилась в 13:15, в репозитории впервые появился официальный tag. Ключевые показатели в примечаниях к релизу сгруппированы в три набора: все 206 операторов имеют записи в manifest (сигнатура, тестовые и бенчмарк-нагрузки, формулы roofline, проверяемые построчно в CI); из 2265 строк ночного бенчмарка на H200 2262 строки не медленнее самой быстрой эталонной реализации, геометрическое среднее — 1,37x, в число эталонов входят torch.compile, FlashAttention 3, FlashInfer, vLLM, DeepGEMM и FlagGems; из 206 операторов 195 merge-коммитов с меткой foundry были сгенерированы TileFoundry и попали в репозиторий через тот же CI. Релиз также заморозил публичный API: далее в 0.x будут только добавлять, не изменяя, и добавлен скрипт проверки совместимости API — любой PR, вызывающий API по образцу предыдущей версии, будет сразу отклонён.

За 24 часа организация tile-ai слила 20 коммитов (tilelang 13, TileOPs 4, TileFoundry 2, tilelang-hygon 1), 45 обновлений на рассмотрении, открыто 7 новых issue (из них 2 — ежедневные тестовые боты репозитория Ascend). Центр тяжести merge-коммитов распределён по двум линиям: одна — семантика чисел с плавающей точкой и контекст исполнения: ROCm вернул семь математических функций по умолчанию с быстрых встроенных реализаций на точные (погрешность sin/cos на MI300X снизилась с 7,8e-04 до 6,6e-08), автоматическая цель теперь читает текущее устройство вместо фиксированной карты 0, NVRTC и CuTeDSL переключены на получение потока по устройству входного тензора, ключ кэша автотюнинга дополнен compile_flags; другая — статические границы и домены потоков: валидация срезов-заполнений по концу региона, а не по длине, отрицательные индексы вне диапазона отклоняются на этапе компиляции, регион T.ws(-1) изменён на выполнение на всех потоках. Hygon слил 12 файлов и 1389 строк, разделив буфер scale на независимые двойные банки и отделив его от банка LDS. На стороне третьих лиц бэкенд Hexagon DSP за один день получил 15 коммитов, проложив путь от векторизации HVX, арены VTCM, раскладки Crouton и встроенных DMA до отображений и редукций на Crouton.

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

1.1 Основной репозиторий: exp/sin/cos на ROCm больше не понижаются по умолчанию до быстрых встроенных реализаций, погрешность sin/cos снизилась с 7,8e-04 до 6,6e-08 (#3621)

Слито 27.10 в 22:39, 5 файлов +107/-17, исправляет #3618. На HIP семь функций по умолчанию — T.exp, T.exp10, T.log, T.log2, T.log10, T.sin, T.cos — независимо от настройки tl.enable_fast_math понижались до быстрых встроенных реализаций вида __expf, тогда как на стороне CUDA согласно договорённости #875 использовались точные реализации; наоборот, явные быстрые операторы вроде T.__exp на HIP вообще не опускались и в tilelang.rocm.language сразу бросали AttributeError. Этот коммит приводит HIP к той же стратегии, что и CUDA: семь операторов по умолчанию перенаправляются на HIPMath, для восьми быстрых операторов с подчёркиванием добавляется правило минимального опускания на HIPFastMath, и все они переносятся в список FAST_MATH_INTRINSICS, экспортируемый языковым слоем ROCm. Сравнение точности взято из воспроизведения в #3618: на MI300X для exp и exp10 смотрится относительная погрешность, для sin и cos — абсолютная (x до 1e4), четыре столбца соответствуют T.exp, T.exp10, T.sin, T.cos, в основной ветке — 3,7e-06 / 4,1e-06 / 7,8e-04 / 7,8e-04, в этом коммите — 8,3e-08 / 8,1e-08 / 6,6e-08 / 6,4e-08.

Источник: https://github.com/tile-ai/tilelang/pull/3621

1.2 Основной репозиторий: автоматическая цель читает текущее устройство HIP, на многокарточных машинах больше не фиксируется архитектура карты 0 (#3594)

Объединено 10-27 22:37, 2 файла +24/-1. determine_target(“auto”) на ROCm попадает в зарегистрированный HIP-детектор, а этот детектор безусловно читает torch.cuda.get_device_properties(0), поэтому, когда текущее HIP-устройство не является картой номер 0, автодетект выдаёт архитектуру карты номер 0; на стороне CUDA уже давно используется torch.cuda.current_device(), а ROCm за этим не последовал. Исправление состоит в том, чтобы сначала получить индекс текущего устройства, а затем запросить свойства, и с помощью normalize_rocm_arch убрать суффикс возможностей. Новый тест подставляет заглушку, возвращающую 1, для current_device(), одновременно записывая все индексы, которые были опрошены, и утверждает, что обнаружен gfx942 и затронута только карта номер 1; до исправления это утверждение давало probed == [0]. Автор отмечает, что на его машине нет устройств ROCm, тест проверяет только помощник детектирования с помощью подставленного torch и не запускает реальный рантайм HIP; изменение затрагивает другую функцию, отличную от другого изменения #3549 за этот день (#3549 в tilelang/contrib/rocm.py, это изменение в tilelang/rocm/target.py).

Источник: https://github.com/tile-ai/tilelang/pull/3594

1.3 Основной репозиторий: константные строчные индексы TMA gather/scatter преобразуются в int32, литеральная запись больше не вызывает сбой компиляции (#3365)

Объединено 10-27 09:15, 2 файла +44/-2, исправляет #2601. Два фронтенд-помощника tma_gather4 и tma_scatter4 при получении строчного индекса в виде целого числа Python передавали его напрямую, в TIR он попадал без определённой целочисленной ширины, из-за чего компиляция на Blackwell падала; остальные строчные выражения остаются без изменений. Это изменение лишь преобразует целые числа Python в константы TIR типа int32 и добавляет регрессионный тест компиляции, закрытый условием Blackwell, который отдельно компилирует gather и scatter с литеральными строчными индексами, а затем проверяет, что в сгенерированном исходном коде CUDA действительно присутствуют соответствующие инструкции. Автор поясняет, что этот тест проверяет только возможность компиляции, а не корректность значений во время выполнения; кроме того, в локальной среде Windows Python 3.13 у отправителя плагин pytest для Home Assistant зависит от fcntl, из-за чего этап сбора pytest завершается ошибкой, и тесты TileLang из этого изменения локально так и не были реально запущены.

Источник: https://github.com/tile-ai/tilelang/pull/3365

1.4 Основной репозиторий: NVRTC и CuTeDSL берут текущий поток по устройству первого входного тензора (#3359)

Объединено 10-27 08:11, 2 файла +5/-4, продолжает F149 из #3301 и #3408. Оба адаптера ранее определяли тип цели по строковому префиксу и по умолчанию брали текущий поток текущего устройства вызывающей стороны, поэтому при несовпадении текущего GPU вызывающей стороны и GPU, на котором находится тензор, выбирался неверный поток. Это изменение переходит на определение по виду цели и запрашивает текущий поток по устройству первого входного тензора, явно переданный дескриптор потока по-прежнему имеет наивысший приоритет, а вызовы NVRTC без тензоров сохраняют прежнюю семантику. Это второе изменение после вчерашнего выделения потока для вывода out_idx (#3649) в рамках очистки семантики потоков. Автор очерчивает границы: это изменение исправляет только выбор потока, контекст запуска в потоке по умолчанию при кросс-устройственных вызовах остаётся нерешённой задачей, такие вызывающие стороны должны сами перед запуском установить устройство, на котором находится тензор, текущим устройством; в патче нет попискельного защитного механизма для устройств; при проверке реальными потоками Torch и запуском на GPU покрыты нестандартные потоки в пределах одного устройства и при кросс-устройственных вызовах, но корректность контекста потока по умолчанию при кросс-устройственных вызовах не установлена.

Источник: https://github.com/tile-ai/tilelang/pull/3359

1.5 Основной репозиторий: ключ кэша автоподбора включает compile_flags, один и тот же kernel с другими опциями компиляции больше не переиспользует старый бинарник (#3338)

Объединено 10-27 16:57, 3 файла +28/-1, продолжает F131 из #3301. Автоподборщик сохраняет результаты компиляции в постоянный кэш, но в идентификаторе кэша не было compile_flags, поэтому один и тот же kernel с другим набором опций компилятора устройства по-прежнему попадал в старый бинарник, и измеренная производительность не соответствовала реальному результату компиляции. Это изменение заставляет CompileArgs действительно сохранять флаги и участвовать в хэшировании в исходном порядке, а также передаёт flag от реализации JIT через AutoTuner.set_compile_args() по цепочке в компиляцию кандидатов, слияние проходов по каждой конфигурации, групповую компиляцию устройств и загрузку кэшированного kernel. Проверка охватывает три существующих теста ключа кэша, а также точечное сравнение CUDA с использованием нативного рантайма: обе формы flag — список и строка — выживают при попискельном переопределении; автор указывает, что прежняя логика слияния теряла макросы компилятора, и именно эту дыру и нужно закрыть на этот раз.

Источник: https://github.com/tile-ai/tilelang/pull/3338

1.6 Основной репозиторий: ThreadSync записывает address_of как запись, добавлен барьер после непрозрачного вызова (#3346)

Объединено 10-27 05:49, 2 файла +62/-1, продолжение F305 из #3301, продолжение основной линии семантики барьеров вчерашнего дня. address_of сам по себе не несёт информации о доступе, он лишь передаёт указатель ниже по потоку, но классификатор доступа жёстко кодирует его тип как чтение, поэтому разделяемый буфер после записи через непрозрачный вызов не попадает в множество writes, последующее полноблочное чтение не находит конфликтующей записи и больше не планирует барьер, и поток вот так проскакивает запись и читает содержимое до записи. Фактический вывод CUDA весьма прямолинеен: форма T.address_of(B[0]) после extern не имеет барьера, а форма T.access_ptr(B, “w”) имеет; последняя явно объявляет тип доступа, поэтому эта дыра так долго не обнаруживалась. loop_unswitching.cc уже давно обрабатывает address_of консервативно как запись, ThreadSync — единственное исключение. Данный коммит помечает address_of как запись, направление консервативное: назначение указателя неизвестно, значит возможна запись, а планированию барьеров достаточно один раз ошибиться в безопасную сторону; добавлены два случая, утверждающие, что после понижения этого ядра за extern следует __syncthreads().

Источник: https://github.com/tile-ai/tilelang/pull/3346

1.7 Основной репозиторий: пролог эпилога конвейера с числом итераций времени выполнения разворачивается напрямую, постраничное декодирование снова компилируется (#3356)

Объединено 10-27 07:02, 1 файл +5/-1. Когда число итераций цикла T.Pipelined является значением времени выполнения, достаточно развернуть эпилог на два и более шага и с асинхронным копированием, как CUDA codegen выдаёт TypeError: Downcast from tirx.Sub to ir.IntImm failed. Корень в EmitImpl: extent пролога и эпилога разворачиваются только когда они константны, чтобы счётчик ожидания на каждой итерации был константой; а extent эпилога равен end - start, то есть (n + max_stage) - n, при константном n сворачивается на этапе конструирования, при n времени выполнения остаётся как Sub, as_const_int возвращает пусто, и эпилог эмитируется как цикл T.unroll, чьё ожидание записывается в виде T.ptx_wait_group(1 - k), читающего переменную цикла, тогда как ptx_wait_group принимает только непосредственные значения. Исправление — перед проверкой сначала смотреть на упрощённый extent; случай константной границы упрощается в себя, что совпадает с прежним поведением. Дефект был обнаружен нижестоящим TileOPs#1852 и бисекцией сведён к afcebed1, ломает он постраничное декодирование — его число итераций происходит из длины KV. Автор сравнил компиляцию обеих версий на sm_89, CUDA 13.0; новый тест падает на основной ветке и проходит в этом коммите.

Источник: https://github.com/tile-ai/tilelang/pull/3356

1.8 Основной репозиторий: два исправления статических границ заливки среза и отрицательной индексации, закрыты запись за границы и молчаливый отрицательный адрес (#3352 / #3347)

Объединено 10-27 05:37 и 05:14, всего 4 файла +100/-3. Первое касается статической проверки границ конструктора Fill: изначально по каждому измерению проверялись только min >= 0 и extent <= shape, а extent <= shape верно лишь для области, начинающейся с начала буфера; срез с началом ближе к середине проходит обе проверки, но понижается в запись за границы — T.fill(As[6:12], 7) на буфере длиной 8 компилируется и эмитирует As[threadIdx.x + 6] = 7, записывая в 6–11. Исправление — проверять конец области также относительно целевой формы, причём новое условие требует, чтобы начало и длина были статическими; области, заякоренные на нуле, и области с символьным началом не затрагиваются; T.clear использует тот же узел, дефект тот же и также закрыт. Второе касается LegalizeNegativeIndex: изначально к отрицательному индексу один раз прибавлялась длина буфера и на этом всё, без проверки диапазона; на буфере длиной 8 A[-9] даёт -1, A[-10] даёт -2, выходя за начало выделения и без какой-либо диагностики, тогда как NumPy и PyTorch на таком же индексе бросают IndexError. Исправление — отклонять только тогда, когда анализатор может доказать, что после обёртки индекс всё ещё отрицателен, и сообщать индекс и длину; все константные индексы в пределах диапазона и все динамические индексы сохраняют прежнее поведение.

Источник: https://github.com/tile-ai/tilelang/pull/3352, https://github.com/tile-ai/tilelang/pull/3347

1.9 Основной репозиторий: область T.ws(-1) выполняется на всех потоках, одиночная запись больше не теряет сохранение (#3354)

Объединено 10-27 04:52, 2 файла +40/-3, продолжение #2978. Документация WarpSpecialize определяет -1 как «пропуск привязки threadIdx.x», то есть данная область не ограничена threadIdx; однако в реализации -1 трактуется как обычный индекс warp-группы, что порождает интервал [-warp_group_size, 0), не выполняющийся ни для одного потока, в результате чего область выполняется на нулевом числе потоков, а все сохранения внутри интервала отбрасываются без диагностики. Минимальное воспроизведение очень чистое: из 256 потоков сначала все записывают 0, затем внутри T.ws(-1) записывается 5, и в итоге 256 потоков по-прежнему записывают 0; те же сохранения без обёртки ws дают запись 5 всеми 256 потоками. Исправление состоит в том, чтобы при наличии -1 в id не порождать никаких ограничений диапазона, реальный индекс группы по-прежнему ограничивается собственным потоком, а в строку документации добавлен пример с -1 — в исходной документации его как раз не хватало. Автор проверил, что во всём репозитории использование ws(-1) не встречается, поэтому существующий код не зависит от этой пустой области.

Источник: https://github.com/tile-ai/tilelang/pull/3354

1.10 Основной репозиторий: profiler при неуказанном устройстве использует текущее, сброс кэша больше не попадает на карту 0 (#3357)

Объединено 10-27 07:26, 1 файл +1/-1. do_bench при неявно указанном устройстве и ненулевом текущем устройстве CUDA разрешает _cache_device(None) в модульное значение по умолчанию cuda:0, из-за чего выделение памяти для сброса кэша может попасть на другой GPU, отличный от измеряемой работы, и измеренные цифры оказываются не на той же карте, что и реальная нагрузка. Исправление — заменить значение по умолчанию на строку “cuda” без индекса, чтобы PyTorch разрешал текущее устройство при выделении буфера; явно указанное устройство и значения по умолчанию для NPU, MPS остаются без изменений. Восходящий CI (run 37915443170) прошёл на Quick Lint, CUDA, ROCm, Metal, Ascend и примерах CuTeDSL; автор отмечает, что последующие запуски по триггеру PR требуют одобрения сопровождающего, тесты ещё не выполнялись, и на локальной машине нет ни оборудования CUDA, ни тайминг-бенчмарков.

Источник: https://github.com/tile-ai/tilelang/pull/3357

1.11 Новые дефекты: попадание в кэш ядра ломает шесть тестов, предполагающих холодную компиляцию; захват CUDA graph в CuTeDSL даёт пустой граф (#3694 / #3693)

Оба issue открыты lucifer1004 10-27. Первый указывает, что шесть тестов проходят при холодном кэше и падают при повторном запуске с тем же каталогом кэша, поскольку предполагают обязательное выполнение компиляции: например, пограничный случай sm75 в test_tilelang_kernel_gemm_sm75.py при четырёх параметрах выдаёт AttributeError: ‘NoneType’ object …; второй ещё жёстче: запуск ядра из бэкенда CuTeDSL не записывается в CUDA graph, захват torch.cuda.CUDAGraph даёт пустой граф, replay() ничего не выполняет, тогда как тот же ядро, скомпилированное с бэкендом cuda, захватывается и воспроизводится нормально; в отчёте приложено минимальное воспроизведение. Оба являются продолжением семейства дефектов «кэш и контекст выполнения» и указывают на ту же область, что и два объединения в 1.4 и 1.5.

Источник: https://github.com/tile-ai/tilelang/issues/3694, https://github.com/tile-ai/tilelang/issues/3693

2. Мультибэкендная адаптация (Ascend / Hygon / ROCm / Hexagon)

2.1 Hygon: буфер scale в HCU разделён на два банка, blockscaled GEMM при ручной warp-специализации использует единое отображение строк (#29)

Объединено 10-27 08:26, 12 файлов +1389/-314 — крупнейшее изменение программной части в данном окне. Изменение планирует строки буфера scale в отдельные двухбанковые разделы, отдельно от банков LDS, и передаёт единое отображение строк одновременно в три места — выделение, копирование scale и погружение MMAC, — чтобы избежать трёх независимых выводов раскладки. Детали включают: сохранение жизненного цикла физических интервалов и выравнивание страниц по m0; сокращение числа выдач копирования scale; распределение работы простаивающих wave по двум банкам scale; данная раскладка используется для blockscaled GEMM при ручной warp-специализации. Это изменение продолжает вчерашние объединения нативного хранилища B16 и динамического WASP GEMM (#28): за два дня Hygon завершил три объединения в основную ветку.

Источник: https://github.com/tile-ai/tilelang-hygon/pull/29

2.2 Основной репозиторий Ascend: кандидат PerCoreTask допускает внутренний if/else, условное заполнение L1 больше не отклоняется целиком (#3686)

Объединено с 10-27 07:24, 2 файла +85/-24. В T.PerCoreTask T.Task отклоняется, если в его теле есть if/else, даже если ветвление управляет только внутренней работой — например, условное заполнение L1 после копирования. Воспроизведено на d85a70a9, на этапе материализации выдаётся «управляющий поток выбора кандидата должен находиться вне области действия task». Этот коммит удаляет безусловный отказ и заменяет его единой проверкой тела task: синхронный барьер охватывает весь кандидат, при этом каждая ветка по-прежнему поэлементно проверяется на совместимость конвейера и ядра, вложенные task и неподдерживаемую межъядерную синхронизацию. Регрессионные тесты принимают внутренние if и if/else, сохраняют тело кандидата и сохраняют прежние случаи отказа, дополнительно проверяя, что флаг завершения под внешним guard следует за всем кандидатом. Все 113 тестов трёх наборов — task, единицы планирования и задержки — проходят; ядро с условным заполнением L1 также проходит полный спуск исходников Ascend; выполнение на устройстве не тестировалось.

Источник: https://github.com/tile-ai/tilelang/pull/3686

2.3 Основной репозиторий Ascend: CI разделяет AscendC и PTO на две матричные задачи, которые можно перезапускать по отдельности (#3687)

Объединено с 10-27 07:05, 7 файлов +56/-27. Ранее AscendC и PTO были двумя шагами в одной задаче Test for Ascend, любой сбой, специфичный для одного бэкенда, делал красной всю проверку, а перезапуск неизбежно захватывал и другой набор примеров. Этот коммит разделяет примеры и модульные тесты на две матричные задачи: Test for AscendC запускает examples/ascend (target — ascend, 4 параллельно) и testing/ascend -m “not pto” (32 параллельно), Test for PTO запускает examples/ascend (target — pto) и testing/ascend -m pto (32 параллельно). Разделение опирается на существующую метку pto, и метка добавлена тестам, запускающим только PTO, и PTO-параметрам в тестах с двумя бэкендами; два выражения меток взаимоисключающие и вместе покрывают весь набор без дублирования выполнения. fail-fast установлен в false, сбой одной задачи не отменяет другую; обе стороны сохраняют поведение «при сбое примеров, но успешной сборке модульные тесты всё равно запускаются» и публикуют собственные сводки сборки и тестов. Общие тесты (включая контрактные проверки, где один и тот же фронтендный IR проходит через два генератора кода) запускаются только один раз на стороне AscendC, договорённость записана в testing/ascend/README.md.

Источник: https://github.com/tile-ai/tilelang/pull/3687

2.4 Репозиторий Ascend на рассмотрении: Cython-обёртка лениво создаёт анализатор, нацелена на зафиксированную вчера проблему пересоздания при каждом вызове (#1948)

Обновлено 10-27 07:42, автор zwh1025. Новый дефект #1945, зафиксированный во вчерашнем ежедневном отчёте, указывает, что Cython-обёртка репозитория Ascend при каждом вызове создаёт новый анализатор TVM, что даёт измеренные ~0,28 мс фиксированных накладных расходов; этот коммит под названием «ленивое создание анализатора TVM» нацелен именно на эти расходы. Подобные небольшие накладные расходы накапливаются в послойных вызовах при инференсе больших моделей в наблюдаемую задержку и относятся к низко висящим плодам оптимизации производительности на стороне Ascend. В настоящее время на рассмотрении.

Источник: https://github.com/tile-ai/tilelang-ascend/pull/1948

2.5 Репозиторий Ascend на рассмотрении: kpool-оператор сжатия для GLM-5.3, тензорная величина сдвига на PTO (#1910 / #1949)

Оба обновлены 10-27. #1910 добавляет для NPU Ascend пример kpool-оператора сжатия GLM-5.3 — это подход переноса структурных компонентов конкретной модели в репозиторий примеров, созвучный идее на стороне TileOPs «операторы растут из потребностей моделей»; #1949 позволяет T.tile.bitwise_lshift на PTO поддерживать величину сдвига в тензорной форме, ранее принималась только константа. PTO — относительно независимый путь генерации кода на стороне Ascend, тензоризация величины сдвига означает, что этот путь на шаг приблизился к универсальному выражению в операторах масок и битовой упаковки.

Источники: https://github.com/tile-ai/tilelang-ascend/pull/1910, https://github.com/tile-ai/tilelang-ascend/pull/1949

2.6 Основной репозиторий Ascend на рассмотрении: векторизация T.Parallel на PTO, канал AutoSimVF, пакетный трёхмерный ND2NZ, многобуферность со счётчиком записи, идентичность сборки Bisheng в ключе кэша (#3512 / #3320 / #3689 / #3629 / #3691)

Пять находящихся на рассмотрении пунктов образуют очередь на стороне Ascend в этом окне мониторинга, все обновлены 10-27. #3512 — это конвейерный фреймворк и поэлементная поддержка векторизации T.Parallel на PTO, структурное изменение; #3320 добавляет канал AutoSimtVF и регистрирует его в конвейере Ascend, направление — автоматический выбор пути между SIMT и векторами; #3689 поддерживает пакетное трёхмерное копирование ND2NZ из GM в L1, напрямую отвечая потребностям перемещения данных в пакетном внимании и блочном GEMM; #3629 добавляет многобуферность со счётчиком записи и перестраивает загрузку DeepGEMM; #3691 включает идентичность сборки компилятора Bisheng в ключ кэша бинарников, что является той же идеей, что и попадание compile_flags в ключ кэша в 1.5 — на стороне Ascend также существует проблема ошибочного попадания в старые бинарники после смены компилятора.

Источники: https://github.com/tile-ai/tilelang/pull/3512, https://github.com/tile-ai/tilelang/pull/3320, https://github.com/tile-ai/tilelang/pull/3689, https://github.com/tile-ai/tilelang/pull/3629, https://github.com/tile-ai/tilelang/pull/3691

2.7 ROCm на рассмотрении: определение архитектуры и образ pip-версии ROCm 10, преобразование FP4 и тип E8M0 (#3549 / #3665)

#3549 поддерживает установку ROCm 10 SDK через pip, изменения включают определение архитектуры и Dockerfile; это связано с исправлением цели auto из 1.2, но затрагивает другую функцию — здесь изменяется определение get_rocm_arch на основе /opt/rocm, а в 1.2 — вспомогательная функция определения в tilelang/rocm/target.py. #3665 исправляет преобразование чисел с плавающей точкой в FP4 в шаблонах HIP и добавляет поддержку типа E8M0, что указывает на доступность блочного масштабирования и низкоприцезионного квантования на ROCm. Оба PR находятся на рассмотрении.

Источники: https://github.com/tile-ai/tilelang/pull/3549, https://github.com/tile-ai/tilelang/pull/3665

2.8 Ежедневный тест репозитория Ascend: все 2903 пункта пройдены, два дня подряд без сбоев (#1950)

Отчёт ежедневного тестового бота репозитория Ascend от 10-28 06:49 показывает всего 2903 пункта, пройдено 2903, проходимость 100%, номер запуска workflow 40590261193; отчёт предыдущего дня (#1947) также показал все 2903 пункта пройденными. Для всё ещё быстро развивающегося бэкенда NPU два дня ежедневных тестов без сбоев говорят о стабильной доступности основной ветки, что также даёт базовую линию для разделения CI из 2.3 — после разделения обе задачи должны сохранять это число.

Источник: https://github.com/tile-ai/tilelang-ascend/issues/1950

2.9 MetaX: в представлении организации есть метка времени push, все шесть веток без новых коммитов в окне (10-27)

pushed_at репозитория tilelang-metax показывает 10-26 07:08, что находится до начала данного окна; при проверке каждой из шести веток новых коммитов в окне не обнаружено, рассматривается как отсутствие существенных изменений, содержимое на уровне записей не приводится.

Источник: https://github.com/tile-ai/tilelang-metax

2.10 Третьи стороны: бэкенд Hexagon DSP — 15 коммитов за один день, векторизация HVX, арена VTCM, раскладка Crouton и встроенные DMA в комплекте (10-27)

Ветка hexagon-backend репозитория xwhzz/tilelang-hexagon за один день 10-27 получила 15 коммитов — это наиболее интенсивная внешняя активность на стороне бэкендов в данном окне. Основную линию дня можно разделить на три части: на нижнем уровне генератор кода перестроен от CodeGenTileLangCBase, DMA оформлен как IR-встроение с группами коммитов, стартовая сетка и пул рабочих потоков опущены в TIR, а в TIR спланирована арена VTCM; на среднем уровне проложен единый путь векторизации HVX (арифметическое отображение, векторная математика плюс поэлементный путь), многострочная редукция через дерево транспонирования HVX, программная конвейеризация отображения HVX и поддержка фрагментов и T.reduce_*; на верхнем уровне введены раскладка Crouton и копирование областей, отображение и редукция HVX выполняются прямо на плитках Crouton, голосование за частоту DSP в каждой сессии, наконец, добавлены кэш сборки и параллельное тестирование устройств. В коммитах присутствует маркер breaking change (feat(hexagon)!), указывающий, что раскладка Crouton и копирование областей изменили существующий интерфейс. Hexagon — это DSP для мобильных и встраиваемых устройств; если эта линия заработает, охват аппаратного обеспечения TileLang расширится с GPU и NPU до DSP.

Источник: https://github.com/xwhzz/tilelang-hexagon

3. Экосистема и стороны внедрения (TileOPs / TileFoundry)

3.1 Выпуск TileOPs 0.1.0: первая официальная версия со 206 операторами, публичный API зафиксирован (10-27)

10-27 13:15 опубликован v0.1.0 — первый GitHub release репозитория; артефакт 0.1.0 на PyPI загружен раньше, в 10-27 07:45 (пекинское время, то есть 10-26 23:45 UTC), на 45 минут позже отсечки предыдущего ежедневного отчёта — именно это изменение произошло сразу после того, как вчерашний ежедневный отчёт написал «первый релиз всё ещё в последней ячейке». Позиционирование в примечаниях к релизу предельно ясное: библиотека операторов, переделанная для эпохи agent — для каждого оператора сначала пишется YAML-спецификация (объявление сигнатуры, нагрузки для тестов и бенчмарков, формула roofline), затем кодирующий agent разрабатывает и настраивает ядро, а тесты и бенчмарки, произведённые из спецификации, решают, что попадёт в библиотеку; именно так вошли 195 мержей с меткой foundry. В этой версии зафиксирован публичный API: операторы импортируются как tileops.., docs/stability.md перечисляет публичные модули, scripts/ci/check_api_compat.py заставляет любой PR, ломающий написание предыдущей версии, сразу падать; в дальнейшем 0.x только добавляет, но не меняет. В версию также вошли несколько возможностей: torch.compile(fullgraph=True) доступен для всех записей manifest, содержащих тензорные входы времени вызова и не имеющих композиции; на H200 проверен захват CUDA Graph для операторов в группе графовых тестов; после op.request_tune() выполняется автоматическая настройка, скомпилированные артефакты и результаты настройки кэшируются в TILELANG_CACHE_DIR и переиспользуются между процессами; tileops.backend позволяет дистрибутивам бэкендов через register_kernel_builder подключать целые операторы со своих устройств; tileops.trace записывает временную шкалу внутри ядра. В благодарностях релиза отмечено, что @FeathBow один внёс 98 мержей.

Источники: https://github.com/tile-ai/TileOPs/releases/tag/v0.1.0, https://pypi.org/project/tileops/

3.2 Бенчмарк TileOPs 0.1.0: на H200 2262 из 2265 строк не медленнее самой быстрой реализации, геометрическое среднее 1,37x (10-27)

Ночной бенчмарк сравнивает каждое ядро TileOPs со всеми другими реализациями того же оператора на одном и том же GPU; для строки берётся отношение времени самого быстрого конкурента к времени TileOPs, больше 1 означает быстрее. Всего 2265 строк, 16 семейств операторов, геометрическое среднее 1,37x, 2262 строки достигли 0,99 и выше. По семействам различия заметны: sequence_modeling 4,00x, sampling 2,95x, convolution 1,86x, mamba 1,61x, linear_attention 1,54x, pool 1,51x, quantization 1,45x, attention 1,42x; самое объёмное elementwise — 527 строк — лишь 1,09x, gemm 235 строк — 1,28x. В число конкурентов входят torch, torch.compile, FlashAttention 2 и 3, FlashInfer, FlashMLA, vLLM, DeepGEMM, flash-linear-attention, FlagGems, QuACK, Mamba, Marlin и cuBLASLt. Три строки, отставшие ниже 0,99, — это Where и ClampScalar на 16M элементов float32, а также FP8 GEMM на выходной проекции префилла DeepSeek-V3, разрыв от 1,1% до 1,7%. Это распределение показывает, что выигрыш идёт в основном от длиннохвостых семейств операторов, а не от мейнстримных GEMM и поэлементных операций — последние и так являются местом самой жёсткой конкуренции среди всех реализаций.

Источники: https://github.com/tile-ai/TileOPs/releases/tag/v0.1.0

3.3 Известные пробелы и следующие шаги TileOPs 0.1.0: слитые операторы, целые модели, слияние вычислений и коммуникаций (10-27)

В примечаниях к релизу перечислены четыре известные проблемы: FusedAddLayerNormFwdOp теряет точность на строках, далёких от нуля, и переполняется на строках вблизи 1e36 (#2773, этот дефект уже зафиксирован во вчерашнем ежедневном отчёте); если на одном хосте есть GPU разных архитектур, ядро, скомпилированное для одного GPU, может запуститься на другом (#2302); операторы класса Bwd нужно вызывать напрямую, они не подключены к torch.autograd; один экземпляр оператора одновременно поддерживает только один поток и один поток CUDA. Область валидации охватывает только H200, Python 3.12 и 3.13; часть ядер имеет дополнительные пути SM80, SM86, SM89 — эти пути работают на соответствующих устройствах, но не входят в область валидации релиза. Дорожная карта состоит из трёх шагов: сначала сложное слияние через границы операторов (attention вместе с предшествующей и последующей проекциями и нормализацией, целый слой MoE, квантизация внутри epilogue GEMM), затем префилл и декодирование целой модели со сквозным сравнением с сервисными движками, и наконец слияние вычислений и коммуникаций (тензорно-параллельный GEMM с all-reduce, экспертно-параллельный MoE с all-to-all). Если эти три шага будут реализованы, соперником TileOPs станет уже не библиотека отдельных операторов, а инференс-фреймворк.

Источники: https://github.com/tile-ai/TileOPs/releases/tag/v0.1.0

3.4 TileOPs: четыре коммита — where и masked_fill допускают тюнинг, причинно-диагональный D128 оценивается по 64 ключам, разреженный длинный предзаполнитель GDN разделён, дата в журнале изменений привязана к дате релиза (#2782 / #2783 / #2779 / #2781)

Четыре коммита влиты 27.10, ровно к завершению перед релизом. #2782 исправляет ошибку ValueError, которую request_tune() выбрасывал на WhereFwdOp, MaskedFillTensorFwdOp, MaskedFillScalarFwdOp: автотюнинг отвергал случайно сгенерированные целочисленные входы, а эти три ядра передают bool-условие или маску как uint8; случайный селектор меняет только то, какой операнд берётся для каждого элемента, и не меняет объём работы кандидата, поэтому случайные целочисленные входы объявлены безопасными; добавлены три тестовых узла, на основной ветке все три примера падают. #2783 оптимизирует причинную диагональ плотной программы D128: когда причинный вызов содержит только один сегмент key и обе длины лежат на границе 128 строк, диагональный key-тайл первой потребляющей warpgroup блокировал старшие 64 ключа для всех строк, поэтому этот шаг теперь выполняется с QK в конфигурации m64n64 и softmax по 64 ключам; выбор сделан compile-time флагом (diag_aligned, входит в ключ ядра), потому что ветвление во время выполнения между QK шириной 64 и 128 заставляло ptxas на некоторых специализациях сериализовать каждую WGMMA (C7511); после перехода на флаг ни одна специализация предзаполнителя D128 из манифеста больше не выдаёт C75xx. #2779 разделяет предзаполнитель GDN для разреженных длинных последовательностей на SM89 на сканирование состояния плюс отдельную выходную программу; применимо к плотным входам D128 с key-major порядком и не менее 16384 token, когда CTA сканирования состояния не превышают четверти числа SM; в бенчмарке время для (1, 16384, 4, 128) bf16 снизилось с примерно 0,612 мс до примерно 0,470 мс, что составляет 0,939 от 0,441 мс у flash-linear-attention. #2781 фиксирует в CHANGELOG дату 0.1.0 как день попадания в PyPI (2026-10-27) и удаляет из документации для контрибьюторов разовую настройку релиза и путь кликов в Actions.

Источники: https://github.com/tile-ai/TileOPs/pull/2782, https://github.com/tile-ai/TileOPs/pull/2783, https://github.com/tile-ai/TileOPs/pull/2779, https://github.com/tile-ai/TileOPs/pull/2781

3.5 TileFoundry: два коммита — целое окно передаётся как сам операнд, динамическая разделяемая память выделяется по фактическому использованию ядра (#273 / #271)

Оба коммита влиты 27.10. #273 исправляет понижение GEMM для sm_89: то, что записывает schedule finalize, не компилируется, потому что понижение заворачивает весь аккумулятор в окно, начинающееся с нуля и равное по протяжённости самому себе — T.ptr_of(acc[0:0+16, 0:0+8]), — а CUDA codegen отвергает срез указателя на тайл регистрового фрагмента с ошибкой «требуется обычная раскладка источника»; MMA к тому же читает регистровый фрагмент как голый Slice вида lhs_frag_dst[0:0+16, 0:0+32], для которого у codegen тоже нет обработчика. Исправление на стороне понижения: StoragePlan.operand и так трактует «окно, начинающееся с нуля и покрывающее весь операнд» как сам операнд, но материализация и выдача инструкций всё равно конструировали Slice; теперь решение принимается один раз — той же заменой, что делает MLIR TrivialSubViewOpFolder. #271 исправляет динамическую разделяемую память: синтезированная хостовая точка входа запускала каждое TIR-ядро с dynamic_smem=0, поэтому ядра, обращающиеся к разделяемой памяти через целочисленные смещения TensorView, не получали места, а свыше 48 KiB требуется установка cudaFuncAttributeMaxDynamicSharedMemorySize, которую лаунчер никогда не выполнял; автор не принял предложение из #267 «выдавать по полной ёмкости цели» и вместо этого задаёт размер по фактическому использованию ядра, поскольку статическая и динамическая разделяемая память считаются в одном лимите и объём запроса на блок определяет, сколько блоков поместится в один SM — на sm_89 при заполнении до 99 KiB ядро, использующее 512 байт, тоже смогло бы разместить лишь один блок. CUTLASS и TileLang задают размер тем же способом.

Источники: https://github.com/tile-ai/TileFoundry/pull/273, https://github.com/tile-ai/TileFoundry/pull/271

3.6 Внешняя экосистема: репозиторий операторов TileLang в сообществе CANN, обёртка для PPU без изменений, фрагментный пример DeepSeek V4.1 Flash (27.10)

Три внешних репозитория проявляли активность в течение окна мониторинга; в совокупности это представляет собой процесс формирования «фонда операторов со стороны Ascend». Atlas-Ascend-Fork/ops-tilelang — это репозиторий операторов TileLang для Ascend в сообществе CANN: создан 20 октября, 27 октября был сделан коммит «автоматическое обнаружение инкрементальных тестов и удаление таблицы сопоставления операторов»; в README явно указано, что поддерживаются только архитектуры Ascend 950 и выше, требуется CANN 9.3.0 или выше и используется weekly-версия сообщества; принципы проектирования — разделение интерфейса и планирования, агрегация по бизнес-доменам, корректность важнее производительности, разделение benchmark и тестов, причём базовые показатели сохраняются с разбиением по тестовым файлам и кластерам чипов. kevin3113/models-tilelang с помощью семи операторов этого репозитория выстраивает фрагмент DeepSeek V4.1 Flash «выход Attention плюс предобработка FFN» (mhc_post_forward, GEMM с суммой квадратов, редукция плюс RMSNorm, разбиение mix, sinkhorn, apply_mix, ffn_norm), HIDDEN=5120, MHC=4, форма decode по умолчанию SEQ_LEN=1, поддерживаются SuperKernel и ACL graph через npugraph_ex, при B от 1 до 256 измеренный выигрыш SuperKernel составляет от 1,17% до 2,75%. flytiger-eco/tilelang-wrapper-for-sail решает миграцию в другом направлении: код TileLang в стиле CUDA без изменений запускается на tilelang-sail (дистрибутив бэкенда PPU), подход — чисто runtime-перехват протокола import и механизма site, без изменения исходного кода upstream и без переупаковки; CUDA-возможности, не имеющие аналога в PPU, явно сообщают об ошибке, а не деградируют молча. Эти три проекта соответствуют трём звеньям: поставка операторов, внедрение в модели, миграция бэкенда.

Источники: https://github.com/Atlas-Ascend-Fork/ops-tilelang, https://github.com/kevin3113/models-tilelang, https://github.com/flytiger-eco/tilelang-wrapper-for-sail

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

4.1 Шесть автоматических обновлений документационного сайта за один день (27 октября)

tilelang.github.io в течение окна мониторинга получил шесть коммитов Update docs (05:20, 06:22, 07:19, 09:28, 22:42, 22:43), все отправлены ботом, содержимое — результат перегенерации документации после слияния в основной репозиторий. В день релиза частота обновлений документационного сайта синхронизирована с ритмом слияний в основную ветку, это нормальное взаимодействие, отдельно по содержанию не выделяется.

Источники: https://github.com/tile-ai/tilelang.github.io

4.2 Четыре проверки фактов в документации репозитория Ascend, до 46 раундов комментариев в одной ветке (#1628 / #1655 / #1656 / #1659)

В репозитории Ascend 27 октября обновлены четыре PR с документацией под заголовком «проверка фактов»: T.tile.clear (#1628), T.tile.bitwise_or (#1655), T.tile.bitwise_not (#1656), T.tile.bitwise_lshift (#1659), количество комментариев — 10, 46, 18 и 20 соответственно, три из них помечены ботом. Один раунд проверки может набрать 46 комментариев — это говорит о том, что обсуждается не только формулировка: такая поштучная сверка поведения каждого API фактически фиксирует семантические соглашения для стороны Ascend. Для новой линии бэкенда стоимость согласования документации и реализации часто недооценивают; эта группа PR — видимая инвестиция.

Источники: https://github.com/tile-ai/tilelang-ascend/pull/1655, https://github.com/tile-ai/tilelang-ascend/pull/1656

4.3 На рассмотрении: вынос lower trace в отдельный набор инструментов разработчика (#3583)

Обновлённый 27 октября PR на рассмотрении выносит lower trace из основного репозитория в tilelang-devkit. Трассировочная информация процесса понижения полезна для отладки адаптации бэкендов, но в основном репозитории она увеличивает нагрузку на путь компиляции и зависимости; после выноса в отдельный набор инструментов основной репозиторий может оставаться лёгким, а подключать его можно при необходимости. Подобные изменения «вынесения отладочных возможностей наружу» обычно появляются, когда у проекта начинает быть несколько downstream-бэкендов — в этом окне мониторинга одновременно активны три линии: Hexagon, PPU и Ascend, что как раз соответствует такому моменту.

Источники: https://github.com/tile-ai/tilelang/pull/3583

4.4 Новостная сторона: Google News и HN за 24 часа не содержат новых сообщений по данному окну (27 октября)

Четыре группы запросов на китайском и английском (TileLang, TileOPs, операторы TileLang, ядра tile-ai для интеллектуальных вычислений) вернули записи, все попавшие в период с конца сентября до середины октября: часть — сообщения об открытии исходного кода версии TileLang для Ascend от DeepSeek и Huawei 29–30 сентября (SCMP, Reuters, Tom’s Hardware, Leiphone, InfoQ и др.), самая свежая — анализ SemiAnalysis от 22 октября о симбиотических отношениях Huawei и DeepSeek, — все они вне окна мониторинга. Точный запрос по TileOPs дал ноль совпадений. В окне на Hacker News была только одна запись, связанная с переписыванием GameMaker, — отброшена как шум. На arXiv последняя статья с ключевым словом TileLang датируется 2026-07-24. Содержательный центр сегодняшнего дня полностью на стороне GitHub, что совпадает с моментом дня релиза — официальный релиз ещё не вошёл в цикл освещения в СМИ.

Источники: https://news.google.com/

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

Во-первых, TileOPs 0.1.0 изменил саму структуру затрат на «библиотеку операторов». Традиционный подход состоит в том, что число операторов линейно растёт вместе с требованиями к оборудованию и моделям, а узким местом становятся люди; здесь же для каждого оператора сначала пишется YAML-спецификация, где чётко объявляются сигнатура, нагрузка и roofline, затем agent генерирует и настраивает ядро, и наконец проводятся приёмочные испытания на основе тестов и бенчмарков, производных от спецификации. 206 операторов и 195 влитых коммитов с меткой foundry — это первая полная поставка такого процесса. Его устойчивость зависит от двух вещей: способна ли спецификация покрыть сложные fused-операторы (первый шаг дорожной карты — именно это) и способны ли бенчмарки отсечь ядра, которые «настроены под бенчмарк, но на практике не робастны» — известная проблема FusedAddLayerNormFwdOp с потерей точности на строках, далёких от нуля, как раз является образцом такого риска.

Во-вторых, влитые в этом окне изменения почти все относятся к «тихим ошибкам». Математические функции ROCm по умолчанию используют быстрые встроенные функции, из-за чего sin/cos расходятся на три порядка; address_of, воспринимаемый как чтение, приводит к тому, что после непрозрачного вызова из разделяемой памяти читается содержимое до записи; область T.ws(-1) выполняется на нулевом числе потоков, сохранение полностью отбрасывается и ошибка не выдаётся; заполнение среза проверяется по длине, а не по концу, что даёт прямой выход за границы; отрицательный индекс после обёртки остаётся отрицательным и попадает до начала выделения. Общее у этих пяти пунктов — компиляция проходит, выполнение не даёт ошибок, результат неверен, и все они были обнаружены сосредоточенно за последние две недели. Для языка, на котором пишут ядра для больших моделей, цена таких дефектов намного выше ошибок времени компиляции, и они указывают на одну инженерную потребность: отклонять на этапе компиляции конструкции, которые «не дают ошибок, но ведут себя неправильно». Именно этим и занимаются исправления проверки границ и исправление ws(-1) в этом окне.

В-третьих, покрытие бэкендов переходит от «доминирования производителей» к «самодеятельности сообщества». Помимо четырёх официально поддерживаемых линий — Ascend, Hygon, MetaX, Moore Threads — бэкенд Hexagon DSP за один день получил 15 коммитов и разложил примитивы линейной алгебры по тайлам Crouton, появилась обёртка версии PPU с нулевыми изменениями, сообщество CANN создало собственный репозиторий операторов и с его помощью собрало фрагмент модели DeepSeek V4.1 Flash. Все эти действия происходят не в репозиториях организации tile-ai, но все они опираются на стабильность языкового слоя TileLang. В этом и смысл заморозки публичного API в 0.1.0 и превращения проверки совместимости API в пропускной пункт CI — чем больше нижестоящих потребителей, тем выше ценность обратной совместимости.

В-четвёртых, за идентичность кэша взялись одновременно два бэкенда. Основной репозиторий включил compile_flags в ключ кэша автоподстройки (#3338), Ascend включил идентичность сборки Bisheng в ключ двоичного кэша (#3691). Одно и то же ядро при разных опциях компиляции или разных компиляторах даёт разные двоичные файлы, и если кэш строит ключ только по исходному коду и форме, происходят ложные попадания, а измеренная производительность не совпадает с реальным результатом компиляции. Две независимые линии в один день делают одно и то же — значит, эта проблема уже достаточно болезненна на практике.

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

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

Источник Результат проверки
Организация tile-ai на GitHub (29 репозиториев) В окне мониторинга было обновление в 7 репозиториях: tilelang, TileOPs, TileOPs-nightly, TileOPs.github.io, tilelang-hygon, TileFoundry, tilelang.github.io
Подтверждённые слияния (is:merged) 20 коммитов, по каждому проверено, что время слияния попадает в окно мониторинга (tilelang 13, TileOPs 4, TileFoundry 2, tilelang-hygon 1)
Подтверждённые открытые (обновления is:open) 45 коммитов, полностью проверены с сортировкой по времени обновления
Новые issue 7 записей, каждая прочитана по содержанию, из них 2 — ежедневные отчёты тестового бота в репозитории Ascend
Страница релизов и PyPI TileOPs v0.1.0 опубликован 10-27 в 13:15, загрузка артефакта на PyPI 10-27 в 07:45; tilelang последняя версия по-прежнему 0.1.15 (09-30), tilefoundry последняя 0.0.4rc1 (10-25)
Репозиторий tilelang-ascend В окне мониторинга нет коммитов, но активность PR и ежедневных тестовых issue высокая
Репозиторий tilelang-metax В представлении организации есть отметка времени обновления, но ни в одной из шести веток нет коммитов в окне мониторинга, считается отсутствием существенных изменений
Репозиторий tilelang-musa Последнее обновление 09-30, в окне мониторинга коммитов нет
Принимающие стороны (TileKernels / FlashQLA) Обновлений в окне мониторинга нет (10-14)
Репозитории внешних бэкендов Бэкенд Hexagon — 15 коммитов; в репозитории операторов CANN, обёртке PPU, репозитории фрагментов моделей есть активность в окне мониторинга, см. 2.10 и 3.6
Множественные запросы Google News на китайском и английском Точные запросы не дали результатов, все возвращённые записи относятся к периоду с конца сентября до середины октября, все вне окна мониторинга
Hacker News В окне мониторинга одна запись о реимплементации GameMaker, не связана с TileLang, исключена
arXiv Поиск по ключевым словам не выявил новых статей в окне мониторинга, последняя — от 2026-07-24

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

tilelang Bisheng идентификатор сборки в ключ кэша (#3691) — https://github.com/tile-ai/tilelang/pull/3691