Отчётный период: с 19 октября 2026 г. (понедельник) по 23 октября 2026 г. (пятница), всего 5 рабочих дней Источники материалов: 5 выпусков ежедневного отчёта о динамике сообщества TileLang (19.10, 20.10, 21.10, 22.10, 23.10); совокупное окно сбора пяти выпусков — с 07:00 16.10 по 07:00 23.10; кроме того, проведена дополнительная проверка 29 репозиториев организации tile-ai в 168-часовом окне и перепроверка страниц релизов, тегов и файлов VERSION каждого репозитория (подробнее в приложении)

1. Главные новости недели

  • Официально выпущен TileFoundry 0.0.3: планирование на уровне инструкций передано агенту, на H200 предзаполнение Qwen3.8-27B во всех трёх диапазонах быстрее, чем в SGLang (21.10): 21.10 в 10:26 опубликован тег v0.0.3, на PyPI — tilefoundry==0.0.3, кодовое название «Agent-driven scheduling». Ключевое изменение — кому принадлежит право планирования: компилятор перечисляет, какими инструкциями может быть реализована каждая операция HIR и что требуется каждой из них, агент выбирает из кандидатов, а компилятор затем понижает выбранное расписание в TIR; в CLI добавлены schedule candidates и schedule facts, инструкции объявляются как операции AtomSched с явным контрактом операндов TIR, начиная с CUDA MMA atom, SM90 WGMMA и асинхронного копирования. По производительности приведены три группы реальных цифр: предзаполнение Qwen3.8-27B на одной H200 для 1024 / 4096 / 8192 токенов — 80,29 / 309,61 / 631,19 мс соответственно, у SGLang — 89,06 / 317,11 / 638,25 мс; для коротких последовательностей 128 / 256 / 512 / 1024 токена результат составляет 1,88 / 1,41 / 1,10 / 1,03 от SGLang. Известны две проблемы: wheel пока не упаковывает заголовочные файлы среды выполнения CUDA (из установочного пакета нельзя собрать CUDA kernel, требуется checkout исходников; будет исправлено в следующей версии), а также неверная оценка в таймлайне производительности для insert_slice, tf.zeros при межсетевом (cross-mesh) размещении (#239).

  • SemiAnalysis отвела отдельную главу TileLang Ascend: из шести репозиториев с поддержкой Ascend на момент написания статьи работал только TileLang (21.10 ~ 22.10): опубликованная 21.10 статья «The Huawei-DeepSeek Symbiosis» в подзаголовке прямо перечисляет микробенчмарки Huawei Ascend 950PR, анализ DSv4.1 Flash, поддержку Ascend в DeepSeek, AICPU и TileLang Ascend. Три пункта, непосредственно связанных с TileLang: во-первых, из шести репозиториев с поддержкой Ascend (TileLang, DeepGEMM, DeepEP, TileKernels, FlashMLA, DeepSelect) на момент написания работал только TileLang, поскольку CANN 9.2.0 ещё не выпущен, а DeepSeek требует CANN 9.2.0 и компилятор C++20, тогда как 9.2.0-beta.2 последний не предоставляет; во-вторых, бэкенд Ascend 950 уже включён в основной репозиторий TileLang, а не существует лишь в отдельном репозитории адаптации, и обеспечивает нативную компиляцию, планирование, синхронизацию и интеграцию со средой выполнения; AutoSchedule на основе зависимостей по данным и оценок времени выполнения определяет перекрытие и число слотов буферов на кристалле, на 950PR для небольших одиночных операторов сокращая время до 40%; в-третьих, при сравнении с CANN и Triton-ascend «на некоторых размерах удаётся сравняться с CANN или превзойти её», а оптимальная реализация переключается в зависимости от размера (автор оговаривает, что это простой бенчмарк при горячем кэше). Статья также указывает на пробел в экосистеме: большинство оптимизаций ориентированы на суперузлы, а на x86-хостах в vLLM-Ascend 0.26.0rc1 по-прежнему множество проблем. 22.10 South China Morning Post в материале «Jensen’s nightmare» пересказала тот же отчёт — это вторичное распространение, не представляющее нового технического прогресса, но показывающее, что данный вывод проникает в мейнстримную медийную повестку.

  • Главный репозиторий за неделю прошёл три раунда упрочения корректности, типы дефектов расширились от «неверных вычислений» до «неверно выбранной цели» и «искажения состояния на этапе компиляции» (10-19 ~ 10-23): первый раунд расчистил warp-специализацию и геометрию конвейера — #3503 заставляет каждый поток чистого TMA-производителя достигать прямого барьера (исправляет зависание parity в #3470), #2342 заставляет братские конвейеры разделять буфер с единственным раскрытием (исправляет падение четырёхмерного LayoutInference в #2309), #3536 добавляет смещение потока для T.cumsum на разделяемом буфере, #2822 сохраняет транзитивные зависимости копирования. Второй раунд расчистил молчаливые числовые ошибки — #2818 требует явного K-заполнения для неподдерживаемых MMA tile (ранее K-атомы незаметно уменьшались), #2815 исправляет падение редукции с сохраняемой размерностью (64,1), #3550 заставляет предикаты TIR синхронно переписываться при повышении разрядности целых, #3070 исправляет пакетный finalize_reducer, который сворачивал только первый выходной блок, #3350 добавляет предварительную проверку трёх комбинаций источник/цель/округление для cast, #2860 заставляет CUDA target без arch выдавать ошибку вместо молчаливой подстановки sm_50. Третий раунд расчистил состояние этапа компиляции — #3579 включает ненулевую нижнюю границу цикла в анализ векторизации (10 файлов +818/-198, закрывает #2669 и #2616), #3612 клонирует analyzer перед переписыванием векторизации, #3226 исправляет недействительность привязки старого analyzer после разбиения параллельного цикла. Общая черта всех трёх партий — отсутствие ошибок и выдача недостоверных результатов только при определённых размерах или формах циклов.

  • Центр тяжести линии Ascend смещается к обратному проходу обучения и низкоуровневым путям передачи данных: за одну неделю влито 11 PR в репозиторий адаптации и открыто двустороннее направление sparse_mla (10-20 ~ 10-23): операторы со стороны обучения сосредоточенно реализуются — indexer_bwd в #1887 (+1294, обслуживает разреженную донастройку DSA, одновременно поддерживает двойные бэкенды AscendC и PTO, разделён на три уровня ядер: быстрый, универсальный и cast), обратный проход SiTU-GLU в #1877 (+854, семантика согласована с aclnnSituGluGrad из CANN, используется для обратного прохода активации гейта Kimi K3 Stable LatentMoE, на 910B3 перекрёстная проверка с официальным aclnn даёт максимальную относительную ошибку около 3e-3), LSTM в #1892 (+2304, 12 jit-ядер, поддерживает многослойное стекирование, двунаправленность и проекцию LSTMP) и GRU в #1902 (+2267, 8 ядер, вручную отключён AUTO_SYNC, чтобы избежать примерно 58 PipeBarrier на каждый временной шаг). В очереди на рассмотрение далее добавляются прямой проход и обратное распространение sparse_mla (#1929 / #1928), kpool-сжатие GLM-5.3 (#1910) и серия WY fast (#1827 и др.). Со стороны пути передачи данных #3530 с 18 файлами +993/-256 позволяет сжатому NZ-буферу поддерживать частичное копирование UB→L1 и явно задаёт межстрочный шаг группы C0; #1795 локализует проблему невозможности выразить компактный межстрочный шаг меньше 32B, на практике второй burst читает element 8 вместо element 1, исправляя искажение вывода keepdim reduce; #1903 переводит JIT-кэш на атомарную публикацию и восстановление при удалении кэша.

  • TileOPs за неделю принял 68 коммитов, SM89 и SM90 идут параллельно как основные направления, спецификации и покрытие бенчмарками одновременно достигли 205/205 (10-19 ~ 10-23): статистическая ветка организации 10-18 обновилась после 20 коммитов за один день и 44 коммитов за окно мониторинга до «реализовано 205/205, отбенчмарковано 205/205» — оба показателя одновременно на максимуме. В направлении SM90 за неделю добавлено шесть warp-специализированных kernel — постраничный GQA forward (#2668), FP8 lightning indexer с двумя consumer warpgroup (#2666), MLA decode со смещённым «качелями» (#2665), персистентный обход dense prefill (#2706), dense GQA decode (#2694), причинно-следственное скользящее окно band (#2696). В направлении SM89 сосредоточились на закрытии пробелов для потребительских и однокарточных сценариев: блочно-масштабируемый FP8 групповой GEMM (#2659) и INT8 W8A8 (#2655) вышли в один день, у FP8 BMM тайл по умолчанию изменён на 64×64 (#2681, 1×16×64×128 снизился с 5.161 до 3.799 us), верхняя граница M для W4A16 расширена до 64 (#2672, M=17 / 32 / 64 снизились на 43.35 / 47.20 / 40.00 процентных пункта), постраничный DSA реализован через MMA (#2669, 0.269 ms против эталона PyTorch FP32 0.727 ms), NSA top-k расширен до 2048 сжатых блоков (#2675). Параллельно два исправления NaN оба оказались на пути warp-специализации: неверная проверка периода активности разделяемой памяти (#2708) и переполнение при слиянии FMA под fast math (#2699).

  • PTO переходит от «отдельного пути исполнения» к «автоматической векторизации + бэкенду исполнения по умолчанию» (на рассмотрении, с 10-18): главный репозиторий PTO фреймворк векторизации #3512 позволяет пользователю писать скалярно-параллельный T.Parallel (поэлементные операции, управляющий поток, редукции) внутри T.SimdVF(lanes=L), компилятор векторизует его в инструкции PTO VMI, после компиляции через PTOAS он исполняется на Ascend 950; масштаб вырос с 44 файлов и 18988 строк 10-18 до 50 файлов и 21022 строк 10-21; #3516 предполагает, что target="pto" с execution_backend="auto" будет разрешаться в tvm_ffi и устанавливаться по умолчанию. Уже принятое сопутствующее — это серия исправлений семантики хранения, предикатов и редукций: T.alloc_ss в #3514, редукция SimdVF dim=1 в #3437, знаковость целых в PTO в #3582, экспоненциальный рост предикатов в #3581, выделение локальных переменных SIMT-векторов в #3523. Главный репозиторий одновременно через #3511 добавляет явный pitch для локального копирования L0 на стороне AscendC (24 файла +1458/-187, что позволяет собрать один GEMM tile из нескольких копирований) — эти два пути развиваются параллельно, а не заменяют друг друга.

  • Вторая форма downstream-дистрибуции: Sunrise выпускает PR релиза 0.1.15+sunrise.1.2.0 (22.10): #9 22.10 в 16:48 создал ветку candidate/sunrise-0.1.15-1.2.0-20261019 и открыл PR, обновив дистрибутив Sunrise до 0.1.15+sunrise.1.2.0, включив TileLang 0.1.15 и сопутствующие проверенные изменения TileOPs, TileKernels, TVM, tvm-ffi; импорт исходников и слияние, а также адаптация дистрибуции закоммичены отдельно, в итоге адаптирован wheel для бэкенда TANG и исправлена регрессия slice GEMM. Заявленная проверка: 55 контрактных тестов на локальной машине пройдено, 54 теста codegen конвейера TANG пройдено, два lint job и проверка границ доверия пройдены; однако после сборки wheel S2 установочная проверка import smoke завершилась ошибкой на tangGetDeviceCount. Данный PR ещё не слит.

  • За неделю в сообществе появилось несколько новых репозиториев: китайскоязычный системный учебник, репозиторий операторов сообщества CANN, рабочий процесс agent и эксперимент с бэкендом Hexagon (20.10 ~ 22.10): huandu/tilelang-tutorial создан 20.10, позиционируется как «китайскоязычный системный учебник TileLang от нуля до единицы», охватывает написание операторов, механизмы времени компиляции и два бэкенда — NVIDIA и Ascend; это первое появление систематизированного китайскоязычного учебного репозитория; Atlas-Ascend-Fork/ops-tilelang создан 20.10, это репозиторий активов операторов сообщества CANN для NPU Ascend (централизованное управление реализациями kernel, автоматизированное тестирование, стандартные рабочие нагрузки и базовые показатели производительности), 22.10 первый пуш с исправлениями; tilelang/agent запушен 22.10, сам README представляет собой шаблон исполняемого prompt, с @tilelang-operator-dev/SKILL.md для внедрения предметных знаний, оптимизация операторов идёт по десятишаговому циклу; также SoilSoi1/tilelang-hexagon (создан 20.10, эксперимент сообщества с бэкендом Hexagon), перекликающийся с находящимся на рассмотрении в основном репозитории #2155 поддержкой бэкенда Hexagon HMX.

2. Прогресс ключевых проектов (основной репозиторий tilelang)

Версии и релизы

  • Последний тег и релиз основного репозитория по-прежнему v0.1.15 (выпущен 30.09), за всю неделю ни новых тегов, ни новых записей страницы релизов, к пятнице этой недели прошло 23 дня. Проверка файла VERSION по-прежнему даёт 0.1.15, последняя веха в README остаётся на бэкенде Ascend 950 от 30.09.
  • TileFoundry 0.0.3 — единственная новая версия на этой неделе (21.10 10:26), а также первый новый тег в организации с 30.09. Теги линий адаптации за всю неделю не менялись: MetaX v0.1.14 (17.09), Moore Threads v0.1.15+musa.1 (30.09), MLIR Ascend v0.1.2.020.sglang.poc (09.09), Ascend v0.1.2.000.
  • Ограничения downstream по-прежнему застряли между 0.1.12 и 0.1.15: pyproject.toml в TileOPs до сих пор жёстко зафиксирован на tilelang==0.1.12, попытка обновления до 0.1.15 от 18.10 в #2554 закрыта и не слита. Указанная в PR причина блокировки — 29 smoke test, проходивших на 0.1.12, падают на 0.1.15: 28 из них вызваны тем, что T.Pipelined с динамическим extent оставляет в хвосте cp.async ptx_wait_group(3 - t * 2), и CUDA codegen сообщает об ошибке Downcast, ещё 1 — ошибка проверки на null в LegalizeSafeMemoryAccess в ветке, свёрнутой в False. Недавно слитый на этой неделе тест-кейс SM89 прогонялся как на 0.1.12, так и на dev-версии 0.1.15, что показывает: условием прохождения обновления является проверка на двух базовых линиях.

Компилятор, языковой уровень и путь исполнения

  • Windows ARM64 в релизном конвейере (#2962, смержен 10-19, 12 файлов +356/-45): добавлен установочный скрипт PowerShell, который забирает локальный установочный пакет CUDA 13.4 windows_arm64 из канала предварительных выпусков NVIDIA и размещает его по фиксированному пути; добавлены модуль FindPipCUDAToolkit и совместимый заголовок windows_arm64_clang_compat.h, устранены различия заголовочных файлов и встроенных функций инструментальной цепочки MSVC на ARM64, синхронно скорректированы pyproject, два файла requirements и layout, а также вспомогательный модуль MSVC. Это третья non-x86 поверхность поставки после ROCm и Ascend.
  • Разделение lower trace на исходники хоста и устройства (#3496, смержен 10-19, 6 файлов +121/-63): на стороне устройства выводятся codegen_device.cpp с базовой линией .original и последней версией .latest, на стороне хоста отдельно выводятся codegen_host.cpp с базовой линией той же структуры, а report.html указывает символической ссылкой на последний запуск. В развитие этого находящийся на рассмотрении #3583 (13 файлов +106/-4390) целиком выносит из основного репозитория реализацию lower trace, специализированную конфигурацию окружения и связанные тесты, оставляя только общий интерфейс инструментирования компилятора, чтобы инструмент трассировки развивался независимо.
  • Дополнение понижения 16-битной математики CUDA (#3172, 3 файла +463/-8): для asin, acos, asinh, acosh, atanh, log1p, atan2, hypot, copysign, ldexp, nextafter отсутствовали специализированные правила понижения для CUDA, и вызовы float16 и bfloat16 никто не обрабатывал на этапе codegen. Исправление регистрирует их в CUDAMath и добавляет перегрузки для half_t и bfloat16_t: десять операторов вычисляются в float32 с обратным преобразованием, а nextafter переведён на целочисленное пошаговое сравнение по 16-битному кодированию, чтобы сохранять субнормальные числа bfloat16 при fast math.
  • Eager-фронтенд сохраняет позиции в исходниках Python (#3558, 4 файла): сгенерированные вызовы циклов отображаются обратно на операторы for, обёртки контекста — на операторы with, а также добавлены позиции для распаковки итерируемых аргументов, что исправляет рассинхронизацию traceback и покрытия.
  • Векторизованное преобразование BF16→FP32 переведено на встроенный PTX (#3595, 4 файла +19/-7): добавлена реализация преобразования пары lane за один раз в f32x2 вместо поштучного скалярного повышения по каждому lane; поддержка всех трёх ширин lane — 2, 4 и 8 — сохранена, семантика не изменена, затронута только последовательность инструкций.
  • Pass разворачивания и ROCm Select (#2887): разворачивание циклов больше не устраняет stepped-циклы с trip count 0, а векторизованный Select на стороне ROCm понижается по каждому lane, чтобы избежать отказа группового понижения на неподдерживаемых целях.
  • Разбиение softmax по кластеру из 16 CTA (#2632, смержен 10-18): для таких малострочных длинных строк, как lm-head (4×102400), добавлено новое ядро; старая реализация обменивала (max, sum) через глобальную память по 58 сегментам на строку и использовала барьер между grid, новая реализация раскладывает одну строку по регистрам кластера из 16 CTA, каждый элемент берёт экспоненту только один раз, а свёртка выполняется по дереву shuffle с приоритетом max между warp, CTA и кластером.
  • Направления на рассмотрении: помимо двух PTO-изменений, в окне обновились [Transform] Locate VerifyBufferInit reads outside tile ops (#3620), [Codegen] Add unsigned mulhi intrinsic (#3617), [Transform] Keep assumption checks with local dependencies in scope (#3611), [Transform] Preserve tl.assume predicates that simplify to true (#3610), [CPU] Support clz in C and C host code generation (#3609); исправление смешанных знаковых сдвигов в #3597 и #87 форка tile-ai/tvm

Парные коммиты, кроме того, #86 переносит исправление области видимости цикла из upstream обратно. В fork на рассмотрении 25 коммитов, в основном репозитории — 163, путь сотрудничества, при котором сторона TIRx действует первой, а основной репозиторий следует за ней, появился на этой неделе во второй раз.

Корректность и исправление дефектов

  • 10-16 ~ 10-18 (окно в три дня с понедельника): чистые TMA-производители включены в прямой барьер (#3503, warp-производители с 1 по 3 ждут только барьер обратного давления, могут отставать на две фазы и зависать на переиспользуемом parity, блокируя весь блок); общий буфер родственных конвейеров разворачивается только один раз (#2342, исправлен случай, когда два T.Pipelined совместно используют буфер с разными num_stages, что приводило к срабатыванию ICHECK LayoutInference для четырёхмерного (4,2,64,32)); тройное исправление Profiler (#3559 — захват CUDA Graph между устройствами пуст, #3560 — последующий вызов перезаписывает вывод предыдущего снимка, #3561 — время cache-flush исключено из критерия ранней остановки).
  • 10-19: T.cumsum на общем буфере дополняется смещением потока при warp-специализации (#3536, 4 файла +101/-38, в шаблоны scan для CUDA и HIP введён thread_offset); голые data-переменные call_extern консервативно помечаются как записываемые (#2618, добавлено 69 строк тестовых случаев, покрывающих «call_extern записывает выходной буфер», направление — лучше меньше оптимизаций, чем неверная оптимизация).
  • 10-20: анализ векторизации учитывает ненулевую нижнюю границу цикла (#3579, 10 файлов +818/-198, прежняя реализация неявно предполагала, что цикл начинается с 0; при ненулевой нижней границе векторизация с unit-step вычисляла адреса разных lane как одну группу); обнаружение межпоточного WAW в разделяемой памяти переведено на два экземпляра потоков (#2821, 3 файла +153/-19, прежняя проверка WAW переиспользовала одну переменную потока для двух обращений, из-за чего пропускала нарушения и не вставляла барьеры); для неподдерживаемых MMA tile требуется явное заполнение K (#2818, FP16 K=8 даёт неверный результат, нерегулярные размеры вроде K=20 / 28 сразу падают на этапе вывода раскладки); fragment reduce поддерживает сохранение целевых измерений (#2815, 8 файлов +343/-63); предикаты TIR синхронно переписываются при повышении разрядности целых (#3550, 4 файла +950/-27, добавлен IndexPredicateRewriter); CuTeDSL scan дополнен смещением участвующих потоков (#3576, 2 файла +30/-6, tl.CumSum1D(32, False, 0) ранее сразу выдавал ошибку параметров конструктора).
  • 10-21: пакетный finalize_reducer ранее редуцировал только первый выходной блок (#3070, 2 файла +29/-5, при размерности вывода больше batch последующие сегменты получали неинициализированные значения; после исправления эмиссия идёт поблочно по ceil(OutputDim / batch), на L40S прошли 23 тестовых случая, внешняя матрица воспроизведения — 16 случаев без расхождений); предварительная проверка трёх комбинаций источник/цель/округление для cast (#3350, helper для f32→E8M0 округляет к плюс бесконечности и вообще не принимает параметр округления, а ветка векторизации никогда не читала round); CUDA target без arch отклоняется, а не молча заполняется sm_50 (#2860, 1 файл, исправляет #1049, в ошибке приведены два способа явного указания arch); программный конвейер сохраняет транзитивные зависимости копирования и учитывает домен потоков в определении конфликтов областей (#2822).
  • 10-22: клонирование analyzer перед переписыванием векторизации (#3612, 1 файл +2/-1); после разбиения параллельного цикла старая привязка analyzer становится недействительной ([#3226](https:/

/github.com/tile-ai/tilelang/pull/3226), 6 файлов +55/-19, затрагивает три pass: loop_partition, loop_vectorize, lower_tile_op); выход за границы буфера-кандидата в top-k селекторе deepseek_v32 (#3280, 2 файла +91/-10, tl_topk_impl помещает radix-кандидатов в фиксированный общий буфер [2, 4096] и не ограничивает размер корзины порога первого раунда, FP32-оценки с одинаковой младшей мантиссой или полностью совпадающие входы приводят к записи за границы и падению с CUDA_ERROR_ILLEGAL_ADDRESS; исправление — выделение глобального workspace (batch, 2, seq_len) на уровне обёртки tl_topk); небиективные формы разреженных метаданных sm8x теперь отклоняются (#3125, один файл +6/-0).

Среда выполнения, CI и инструментальная цепочка

  • Задача регрессии производительности закреплена за H100 (#3569, 1 файл +15/-1): организация внедряет собственные размещённые H20 для регулярного CI корректности, их набор меток пересекается с существующим [self-hosted, nvidia]. FP16-производительность H20 в плотных вычислениях составляет около 148 TFLOPS, что примерно в семь раз меньше примерно 990 TFLOPS у H100; если бы эта машина незаметно забирала benchmark-задачи, каждый benchmark сообщал бы о несуществующей регрессии. Теперь pr-regression обязан иметь метку h100 и до начала работы проверять, что выделенная карта действительно H100; при ошибке в метке происходит быстрый отказ.
  • Autotuner передаёт параметры profiler (#3337, 3 строки): warmup, rep, timeout в декораторе ранее не передавались в тюнер, поэтому изменение этих трёх параметров пользователем фактически не действовало. В том же пакете поддерживающих изменений ещё три: печать плавающих констант FP4 (e2m1) на стороне ROCm (#3548, теперь константы генерируются на устройстве через вспомогательную функцию преобразованием из float32), обновление cibuildwheel с 4.2 до 4.3 (#3565), добавление ещё одного ревьюера в линию ROCm (#3567).
  • CI Ascend объединяет пошаговые проверки в один check (#3564, 1 файл +61/-9): результаты сборки и тестирования собираются в одну PR-проверку Test for Ascend; окружение CANN разворачивается только один раз и сборка выполняется один раз, а пример AscendC, пример PTO и модульные тесты Ascend выполняются как три отдельных шага одного job; после сбоя одного набора остальные наборы продолжают выполняться, но итоговый результат всё равно считается неуспешным.
  • Сайт документации: tilelang.github.io за неделю получил 15 автоматических сборок-пушей (с 10-19 по 10-22, все запускаются при слиянии в основной репозиторий); сайт документации TileOPs получил три ручных обновления контента — восемь новых операторов внесены на страницу API (#76), шесть новых операторов внесены (#77), два обратных оператора MLA внесены на страницу Attention (#78, причина — check_api_pages.py сообщил, что из 207 экспортируемых основным репозиторием операторов отсутствуют две страницы).

Наблюдение за очередью ревью

  • Открытые PR в основном репозитории снизились с 167 (по состоянию на 10-21) до 163 (по состоянию на 10-22), в TileOPs — с 16 до 9, репозиторий адаптации Ascend держится на высоком уровне 235–236 — картина «основной репозиторий и библиотека операторов сжимаются, репозиторий адаптации всё ещё толстый» совпадает с прошлой неделей, но снижение TileOPs — самое крупное внутри организации за эту неделю.
  • Объём обновлений в окне мониторинга организации: 52 (10-20) → 71 (10-23). Из 51 в состоянии ревью по состоянию основного репозитория на 10-19 27 помечены [BugFix], сосредоточены в ThreadSync, Transform и codegen — это граничные условия, возвращающиеся после масштабного использования.
  • Около 11:30 10-20 у 64 PR в состоянии ревью одновременно обновился updated_at; выборочная проверка трёх из них показала отсутствие комментариев, ревью и событий пуша ветки в соответствующий момент, что было квалифицировано как массовый пересчёт на стороне платформы и не учтено в активности разработки; количество в состоянии ревью определяется по счётчику is:open каждого репозитория.

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

Ascend: переход от добавления операторов к обратному распространению обучения и путям данных

  • На этой неделе в репозиторий адаптации влито 11 PR: документация на китайском для поэлементных операторов (#1657 — для четырёх операторов relu / leaky_relu / sigmoid / silu дополнены описание функций, параметров, возвращаемых значений и типичного использования, 6 файлов +451/-19), indexer_bwd (#1887), обратный проход SiTU-GLU (#1877), LSTM (#1892), GRU (#1902), китайская версия бенчмарка CrossEntropy (#1801, по принятому в FA и SFA парному соглашению en/zh), исправление межстрочного расстояния менее 32B (#1795), атомарная публикация JIT-кэша (#1903), пример depthwise_conv_2d (#1915), пример Dilation2D (#1916), а также откат depthwise_conv_2d в тот же день (#1919, причина в сообщении коммита не указана; репозиторий примеров находится в состоянии «один пришёл, один ушёл»).
  • В основном репозитории 12 изменений, касающихся Ascend: T.alloc_ss (#3514 — скалярная память, разделяемая одним AIC и двумя AIV на dav-3510, пул SS 3 KiB внутри группы, база с выравниванием 32 байта), сброс состояния RNG (#3331 — предотвращает ошибку bisheng о необъявленном идентификаторе из-за остаточного __asc_rng_state от соседних ядер), сокращение SimdVF с сохранением только lane 0 (#3437), скалярный sqrt вне домена VF через стандартную математическую библиотеку (#3466), генерация PTO Ramp по типизированным векторам (#3535), явный pitch при локальном копировании L0 (#3511), выравнивание эвристики и epilogue DeepGEMM (#3577, 29 файлов +1392/-1036, охватывает fused bias, Alpha, BF16 stochastic rounding и FP8-квантование для плотных, batch и grouped GEMM), знаковость целых в PTO (#3582 — pto.redux_max/min отвергает типизированные целые, выявляется через uint32-lane ≥ 2^31), частичное копирование UB→L1 для NZ-буферов (#3530), экспоненциальный рост предикатов направления MAD (#3581), выделение локальных переменных SIMT-векторов по lane (#3523), связывание хоста и устройства в msprof (#3321).
  • #3321 — структурное дополнение возможностей измерений: ранее профилировщик Ascend мог сообщать только время выполнения ядра на устройстве, соответствия между хост-оператором и ядром не было, и образцы автотюнинга нельзя было отнести к конкретному вызову. Этот PR при сборке определяет заголовок профилирования CANN (совместим с двумя вариантами установки — msprof и profiling; при наличии включается, при отсутствии пропускается, без пользовательского флага компиляции), во время выполнения добавляет ascend_profiling.h и модуль профилирования на стороне хоста, сопоставляет по порядку вызовов запуск хост-оператора и выполнение ядра на устройстве; путь групповой компиляции использует ту же отчётность (13 файлов +676/-13).
  • #1795 обладает наибольшей технической сложностью: корневая причина на уровне шаблона — copy_ub_to_gm безусловно генерирует DataCopyPad с множественными burst, тогда как движок MTE3 реализует системное соглашение «узкие строки UB хранятся в слотах по 32B», и адрес источника на каждый burst продвигается на ceil(blockLen/32) + srcStride блоков по 32B. Для производителя, пишущего строки по границам 32B, это точное совпадение, но выход T.reduce_max (M,1) fp32 записывается компактно через V-pipe с межстрочным расстоянием всего 4B, и движок не может это выразить. Исправление сворачивает обе стороны в один flat одиночный burst, когда обе упакованы и суммарный объём не превышает 65535; невыразимые межстрочные расстояния, не кратные 32B, переводятся в явное прерывание через trap(); отказ от деградации объясняется тем, что автоматическая межконвейерная синхронизация bisheng покрывает только линейные intrinsics, и оборачивание DataCopyPad в условное ветвление заставит bisheng сгенерировать некорректный код синхронизации и привести к зависанию устройства (на практике построчный DMA, обёрнутый в ветвление времени выполнения, вызывает исключение aicore). В описании PR сохранены две границы: компактное межстрочное расстояние менее 32B с назначением, имеющим межстрочное расстояние, по-прежнему идёт пошагово по слотам; при blockCount > 4095 (12-битное поле) по-прежнему происходит молчаливое усечение.
  • Очередь на рассмотрении: sparse_mla_fwd (#1929 — varlen packed gather случайных строк, онлайн softmax, слияние двух GEMM QK/PV, размещается в examples/dsa_sparse_finetune/, область применимости fast-пути жёстко зафиксирована: H=128 и G=1, dim/tail 512/64, topk кратен 256) и sparse_mla_bwd (#1928 — цепочка GEMM dQ, векторная цепочка P/dP, scatter случайных строк dKV); indexer_topk_reducesum (#1917); kpool-сжатие GLM-5.3 (#1910); серия WY fast и chunk (#1827 / #1828 / #1802 / #1803 / #1799, явно нацеленная на цепочку обучения линейного внимания и gated delta networks); кроме того, аннотация сохраняемого блока UB→L1 staging и ND-смещение (#1907), исправление публикации кэша параллельных ядер (до вливания #1903), проверка конфигурации автоматической межъядерной синхронизации (#1854), ошибка результата W4A4 int4×int4 в gemm_v0 (#1731).

Hygon: исправление константного окна влито, профилирование производительности перешло в ветку

  • #25 влит 20.10 в 09:53 (2 файла +346): после разворачивания цикла повышение ресурсов MLS теряет смещение константного окна, из-за чего последующие обращения попадают в неверный интервал; исправление состоит в том, чтобы перед выбором одноосевого обновления или прямолинейной инкрементальной адресации сначала проверить необновляемое измерение, при необходимости консервативно переинициализировать окно и добавить регрессионное покрытие на существующих тестах MLS. Это единственный влитый коммит основной линии Hygon за неделю, на нём ветка main и остановилась.
  • Три на рассмотрении: #26 обрабатывает разделение warp для fp4 MLS (14 файлов +261/-144), #18 добавляет поддержку конвейера регистров и warp-diverge (в описании указано, что производительность example_gemm уже близка к rocblas), #19 — изменения, связанные с распределённостью.
  • Ветка feature даёт воспроизводимые выводы по производительности: feat/hcu-smls-b-vgpr имела три пуша 21.10 в 11:04 и 15:27. Пуш в 11:04 развернул k-loop декодирующего GEMM и вернул тайлы с M>96 к bn96; ключевое суждение автора — «фиксированные накладные расходы на каждом шаге идут от цепочки адресов, а не от barrier» — символический индекс совместного уровня (k+d) % 3 опускается до v_mul_lo_u16, v_sub_u16, v_readfirstlane_b32 и попадает на путь адресации matrix_load, занимая 13% ядра, тогда как T.Pipelined и так выдаёт те же два barrier. Пуш в 15:27 приоритетно разбивает средний участок wide-N с M от 64 до 128 по числу блоков, gate_up при M от 64 до 96 принимает bm96/bn128/bk128/ns2 и преобразует документацию декодирующего GEMM из 3825 строк в двухсекционную структуру «результаты + журнал оптимизации» на 588 строк.
  • 22.10 gcy_merge_main удаляет переключатель конвейера регистров (6 файлов +10/-24): одновременно изменяются два прохода — внедрение программного конвейера регистров HCU и планирование конвейера, а также pipeline_utils.h и расширение loop языкового уровня. Удаление переключателя обычно означает, что путь конвейера регистров уже действует по умолчанию и двухрельсовое сопровождение больше не оправдано, но эти изменения ещё ждут приземления в ветке слияния.

MetaX / Moore Threads (MUSA) / MLIR Ascend: тишина всю неделю

  • MetaX: последний пуш остановился на 16.10 (ветка dev #161 вливает main в dev, #160 исправляет xfail-кейсы MetaXGPU), релиз по-прежнему на v0.1.14 от 17.09. За всю неделю ни новых коммитов, ни новых тегов.
  • Moore Threads: последний пуш остановился на 30.09 «Prepare public TileLang MUSA 0.1.15», последний релиз v0.1.15+musa.1, за всю неделю ноль коммитов, ноль находящихся на рассмотрении.
  • MLIR Ascend: 19.10 влит #204 с исправлением изоляции TVM, устраняющий взаимное загрязнение между этим репозиторием и пространством имён TVM, видимостью символов; масштаб небольшой, но напрямую влияет на стабильность линковки при сосуществовании нескольких бэкендов; после этого пушей не было.
  • Вывод: все изменения бэкендов в этом окне несут две линии — Ascend и Hygon, две другие линии стоят на существующих версиях. Это согласуется с суждением прошлой недели «Moore Threads — единственный бэкенд, не выровненный по v0.1.15», и на этой неделе MetaX также перешёл в тишину.

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

TileOPs: 68 влитий за неделю, две аппаратные основные линии продвигаются одновременно

  • Покрытие: ветка статистики спецификаций организации после 20 слияний за один день 18-10 и 44 слияний за окно обновлена до «реализовано 205/205, бенчмаркировано 205/205» — оба показателя заполнены полностью. Слитые на этой неделе операторы охватывают шесть категорий: внимание, линейное внимание, пространство состояний, свёртки, нормализация и GEMM: уровень оператора обратного прохода prefilling MLA (#2678, совместим с интерфейсом _flash_attn_backward из FA3), специализированное под SM90 warp-ядро обратного прохода MLA (#2680, D_qk=192, D_v=128), постраничный прямой проход MLA (#2642), запись в KV-кэш MLA (#2635), фьюзинг QK-Norm-RoPE (#2639, семь комбинаций строк/точностей, поддержка двух вариантов ротации — NeoX и соседние пары), фьюзинг RMSNorm с остатком при поточной квантизации (#2634, 12 рабочих нагрузок согласованы с одноимённым интерфейсом vLLM), два оператора CausalConv1d (#2627, ширина от 2 до 4, опциональные bias и SiLU), преобразование Hadamard (#2624, base_order 1/12/20/28/40, n до 2^28), выборочное сканирование Mamba-1 (#2638, девять рабочих нагрузок покрывают предзаполнение 4096 токенов и декодирование одного токена для Mamba-2.8B), DSAPaged (#2633, 656-байтовый строчный формат DeepSeek-V3.2 из FlashMLA), постраничный прямой проход GQA FP8 (#2648, все 36 случаев прошли, включая проверки на NaN и Inf), FP32 attention sink для dense GQA (#2515, -inf отключает этот sink, +inf обнуляет выход соответствующего head).
  • Специализированные программы SM90 появляются группами: постраничный прямой проход GQA переведён на GQAPrefillPagedWSKernel (#2668, 8 файлов +901/-103, обслуживает head dim 256 и группы query шириной более 16 голов на одном KV head; неохваченные FP8 размерности 64 и 256 читаются через 16-битное зеркало страницы, разовый лимит 4 GiB); FP8 lightning indexer переведён на два consumer warpgroup, поочерёдно потребляющих 64-key tile (#2666, прежняя реализация за один чистый проход записывала -inf за пределами окна со скоростью 2.5 TB/s, что занимало 425 из 472 микросекунд в chunk-prefill-kscale); декодирование MLA идёт по смещённым качелям (#2665, ключи одного запроса режутся на min(sm_count // blocks, tiles // 2) сегментов и объединяются через log-sum-exp); персистентность dense prefill (#2706, когда число query tile превышает число SM, один CTA занимает один SM и поочерёдно проходит свои tile; на D64 каждые 192 строки query на tile распределяются между тремя потребителями по 64 строки, перечитывание K/V сокращается на треть); декодирование dense GQA (#2694, producer warp TMA заполняет двухслотовое кольцо K/V); полоса причинного скользящего окна (#2696, один CTA для «query tile, KV head» загружает два key/value tile полосы только один раз); обратный проход GQA напрямую обслуживает сгруппированные KV head (#2685).
  • SM89 закрывает потребительские и однокарточные сценарии: блочно-масштабируемый групповой GEMM FP8 расширен на SM89 (#2659, четыре явные конфигурации, шесть бенчмарков с копированием, число случаев выросло с 42 до 77), INT8 W8A8 включён на SM89 (#2655, 13 интерфейсных случаев SM89 и 29 нагрузок INT8-бенчмарка прошли проверку корректности против vLLM), тайл по умолчанию для FP8 BMM снижен до 64×64 (#2681, 1×16×64×128 с 5.161 до 3.799 us, 16×128×128×1024 с 12.943 до 7.414 us), верхняя граница M по умолчанию для 64 столбцов W4A16 расширена с 16 до 64 (#2672), постраничный DSA реализован через MMA (#2669, batch 4 / 128 head / 256 позиций — 0.269 ms против 0.727 ms у эталона PyTorch FP32; автор прямо пишет: «на крупных случаях в основном паритет, это не универсальное преимущество»), NSA top-k расширен до 1024–2048 сжатых блоков (#2675) и group48 с переиспользованием tiled-программы (#2674), GEMM «одна строка — один столбец» переведён в векторный (#2660, кандидаты фильтруются по бюджету разделяемой памяти, максимальный staged ring 96 KiB), число уровней конвейера по умолчанию для SSD chunk scan снижено до двух (#2705), разделение диапазона ключей paged DSA (#2691), NSA top-k с tile из 32 столбцов (#2690, медиана GPU busy по восьми случаям снизилась

от 2,1% до 15,0%).

  • Устоявшиеся приёмы оптимизации производительности: по четырём линейным линиям внимания GLA, GDN, KDA и DeltaNet в сумме более десяти коммитов, приёмы сошлись к двум — сжать матричные умножения в цепочке chunk до одного на блок (#2626, #2645, #2637, #2625), а также выбирать между групповым решением и одиночным warp в зависимости от числа warp-групп, которые вмещает SM (#2650, в самоописании границей указано «примерно семь warp-групп решения на каждый SM»); кроме того, перекрытие записи плиток пакетного GEMM под первым WGMMA следующей плитки (#2636), свёртка длинных построчных редукций в 512 потоков (#2641), обход деления bf16, когда масштабирующий множитель ровно равен 1 (#2646), приближённая обратная величина для остатка от деления float32 и целочисленного деления вниз (#2652), широковещательная передача предикатов и булевы операнды через 16-байтовые векторные чтения (#2702 поднял шесть сравнений linear-bias-float32 с 0,99 до 1,06, #2697 перевёл полноразмерные операнды бинарного kernel на evict-first чтения).
  • Два случая NaN и три исправления контрактов: планировщик разделяемой памяти счёл буферы ролей warp активными в разные промежутки времени, из-за чего разместил split handover по адресам кольца key или value, всё ещё заполняемого TMA (#2708, 2 файла +80/-30, возвращает NaN в комбинации «семь одиночных токен-запросов идут перед запросом на 300 токенов, 4099 строк FP8 cache, 48 строк страниц»); при причинном окне плитка настройки 128×64 заставляла последние несколько строк подряд встречать два полностью замаскированных key tile, fast math слил prev * scale - curr * scale в FMA, и ошибка округления около 2 в 99-й степени переполнилась в NaN (#2699, исправление — вычитать running maxima до перемасштабирования); в varlen query RoPE при нечётной половине ширины поворота параллелизм не делится на число потоков ветви поворота, из-за чего теряется верхняя граница цикла (#2700, общий путь просто зависает); при autotune подача для постраничного decode давала каждому запросу одну и ту же block table (#2703, на практике тюнер MHA decode на opt-1.3b-b16 выбрал block_N 128, то есть холодные 80,0 us, и отказался от 72,5 us, опустившись до 0,994 от flashinfer); ref_program служит одновременно эталоном корректности и объектом хронометража базовой линии torch, следуя за dtype входа (#2692, GroupNorm и InstanceNorm падали на MTT S5000, исправлено — эталон вычисляется в float32 или шире).
  • Ночной конвейер и отчёты: #2656 добавил в ночной отчёт колонку «новые операторы» и перевёл чтение исторических элементов данных со старого строкового представления на разбор JSON; в его самоописании отчёт за 10-18 (окно статистики с 10-05 по 10-17) перечисляет 109 улучшений, 6 новых операторов, всего 121 строку, из которых W4A8 GEMM занимает 98 строк. Ветка snapshots на этой неделе сделала два снимка: 10-19 05:41 и 10-20 05:39, после чего критерий ночного отчёта сменился на посуточное продвижение.
  • Очередь: на рассмотрении снизилось с 16 коммитов (10-21) до 9 (10-22) — единственный репозиторий в организации в этом окне с заметным снижением числа находящихся на рассмотрении; оба дня с 20 влитыми коммитами (по критериям выпусков 10-21 и 10-23) сопровождались этим сжатием.

TileFoundry: неделя рефакторинга перед 0.0.3

  • Релиз: тег 0.0.3 установлен 21.10 в 10:26 (подробности в главных новостях); в README раздел Latest News ещё до 21.10 через #247 был дополнен тремя записями за 10/2026 (релиз 0.0.3, пример префилла Qwen3.8-27B, пример префилла Apple AMX), а две записи за 08/2026 перенесены в свёрнутый список Earlier. В описании коммита указано, что README является длинным описанием для PyPI (pyproject.toml содержит readme = "README.md"), поэтому анонс должен быть зафиксирован до установки тега.
  • Структурный рефакторинг: разделение плана хранения и плана выдачи (#243, 39 файлов +2543/-1889: исходные решения о размещении оставлены на уровне анализа, удалена публикация исполняемых псевдонимов, выделены read-only StoragePlan и IssuePlan, а также исправлена проблема размещения разделяемой памяти, которая резервировалась по логическим байтам при разреженной физической раскладке); исправление вехи schedule (#241, 314 файлов +53049/-69314, охватывает M1–M8, миграция двух примеров Qwen, регенерация 31 полной длинной группы и всех 64 коротких файлов TIR); рефакторинг тестов (#246, 51 файл +655/-366: локально и в CI переиспользуются ccache и кэш torch extension, в двух местах тесты переведены на сравнение раскладки MMA с эталоном CuTe, скомпилированным на стороне хоста, вместо рукописных эталонов и тысяч параметризованных случаев).
  • Кроссплатформенность ускорителей: добавлена поддержка Apple AMX, и пример префилла Qwen запущен на M2 Pro (#244: включены четыре операции AMX, Copy и Fill могут размещаться в областях ядер Apple и исполнителя AMX, для Qwen3-1.7B и Qwen3.5-4B выполнено префилл-заполнение на 128 токенов, выходные logits конечны, номера следующих токенов — 1813 и 306 соответственно). Это первый в экосистеме TileLang случай, когда пример инференса целой модели вынесен на неускоритель CUDA.
  • Моделирование устройств и оценка стоимости: добавлены описания целей архитектуры sm_89 и RTX 6000 Ada с синхронизацией спецификационной документации (#259, 11 файлов +392/-22), моделирование устройств расширено с Hopper на Ada; оценка gmem переведена на основе footprint и запущенной mesh с привязкой к измерениям вызываемой стороны (#258, 74 файла +1128/-553, исправлены #239, #252, #253: ранее при проверке только 40 из 132 CTA under-fill был незаметен); устройство, отказавшееся запускать kernel, теперь обязано выбрасывать ошибку (#256, 7 файлов +69/-11: ранее лаунчер после выдачи kernel никогда не читал статус запуска, и на одном GPU sm_89 тест, скомпилированный под связанную цель sm_90, проявлялся лишь неверными значениями, а compute-sanitizer показывал, что cudaLaunchKernel возвращает cudaErrorNoKernelImageForDevice).

Адаптеры и дистрибутивы

  • TileKernels: репозиторий адаптера DeepSeek на этой неделе без коммитов, последний push остановился на слиянии v2.1.0-release от 14.10 (звёзды с 1991 до 2005). Этот релиз явно требует TileLang 0.1.15, PyTorch 2.13, Ascend 950 NPU и CANN 9.2.0 — это первое жёсткое ограничение нижестоящего проекта на «базу 0.1.15», которое также перекликается с указанием SemiAnalysis о невыпущенности CANN 9.2.0.
  • FlashQLA: репозиторий адаптера Qwen также без коммитов, последний push остановился на исправлении SM120 от 14.10 (звёзды с 732 до 737), версия по-прежнему v0.1.3 от 30.09. На стороне адаптеров уже две недели тишина, движущая сила основной линии остаётся внутри организации tile-ai.
  • Дистрибутив Sunrise: PR (#9) о выпуске 0.1.15+sunrise.1.2.0 на рассмотрении, подробности в главных новостях. В качестве артефакта поставки он использует wheel бэкенда TANG, что образует иную форму дистрибуции по сравнению с поверхностями поставки CUDA / ROCm / Ascend основного репозитория, и знаменует появление второй формы нижестоящего дистрибутива TileLang.
  • TileRT / tilescale / DeepStack: в окне мониторинга во всех трёх репозиториях коммитов не было (последние — 24.09, 25.08 и 05.10 соответственно).

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

  • Появление репозитория с систематизированным учебным курсом на китайском языке: huandu/tilelang-tutorial создан и запушен 20.10, позиционируется как «систематический учебный курс по TileLang на китайском языке от нуля до единицы», охватывает написание операторов, механизмы этапа компиляции, а также два бэкенда — NVIDIA и Ascend. Ранее материалы на китайском ограничивались отдельными блогами и переводами официальной документации; систематизированный учебный репозиторий появился впервые. На той же неделе обновился RuneFang/tvm_tilelang_cookbook (34 звезды, пуш 21.10), позиционирующий себя для читателей, «которые немного пишут на Python, слышали про CUDA, но не читали код компилятора», — от @tilelang.jit до .cubin.
  • Сообщество CANN открыло репозиторий операторов: Atlas-Ascend-Fork/ops-tilelang создан 20.10, внутри уже есть четыре уровня src, tests, scripts, docs, а также файлы спецификаций сообщества OpenAtom, такие как OAT.xml, SECURITY.md; 22.10 запушен коммит с исправлением «переполнение при комбинации легального верхнего зерна и хеша тест-кейса приводит к сбою CPU-теста», в более ранних коммитах есть «замена ссылок на Ascend A5 ссылками на Ascend 950» и «сессии с провалившимся или прерванным benchmark всё равно перезаписывают базовую линию производительности». Репозиторий операторов уровня сообщества с единственным DSL в качестве единственного языка реализации ранее не встречался.
  • Формирование рабочего процесса agent: tilelang/agent (создан 28.08, пуш 22.10) оформляет README как исполняемый шаблон промпта — через @tilelang-operator-dev/SKILL.md внедряются предметные знания, на входе только имя оператора, эталонная реализация GPU/CPU, shape и ограничения «поставка tilelang npu, поставка на китайском», в комментариях указано, что agent должен выполняться в среде A5 и после загрузки проходить замкнутый цикл из десяти шагов, Skill содержит дерево решений по выбору, правила 8-CSV, стратегии от L0 до L4 и 11 подводных камней. Кроме того, cc-c122/TileLang-Remote-Autotuning-Agent (1 звезда, пуши и 21.10, и 22.10) также превращает автоматическую настройку в agent с возможностью удалённого управления.
  • Эксперименты с бэкендами и инструментальная цепочка: SoilSoi1/tilelang-hexagon создан 20.10 — это общественный эксперимент с бэкендом Hexagon, перекликающийся с находящимся на рассмотрении в основном репозитории #2155; PTO-ISA/tilelangGym (создан 14.10, пуш 20.10) используется для тестирования чувствительности производительности различных benchmark и микробенчмарков при PTO lowering; easy-tilelang/tilelang-devkit-vscode (создан 19.10, пуш 20.10) позиционируется как инструмент для исследования lowering pass, различий IR и компиляции CPU C JIT в VS Code, что согласуется с направлением основного репозитория по полному выносу lower trace (#3583).
  • Сторонние небольшие репозитории: fanyuxiao-ui/w4a16-tilelang (создан 10.10, использует TileLang плюс рукописный CUDA для GEMM и GEMV квантизованного вывода W4A16 на A800), sablin39/tilelang-cuda-skills (145–146 звёзд, автор одновременно является активным контрибьютором TileFoundry), localizethedocs/tilelang-docs-l10n (локализация официальной документации), flytiger-eco/tilelang-wrapper-for-sail (создан 21.10, пуш 22.10, название репозитория указывает на предоставление обёртки TileLang для SAIL, без описания и README), chaigua/tilelang-agent (создан 19.10). Все являются инициативой сообщества, а не официальными репозиториями организаций.
  • Медиа и академическая сфера: запросы Google News на китайском и английском в окне 19.10 дали ноль новых результатов, в окне 20.10 — три совпадения (две отраслевые публикации о DeepSeek и чипах Huawei, один пресс-релиз prime-rl 0.10.0; при построчной проверке конкретных фактов о TileLang не найдено, обработаны как косвенно связанные), в окне 22.10 — три статьи о взаимодействии Huawei-DeepSeek, при этом только у SemiAnalysis есть специальный раздел о TileLang, в окне 23.10 — две статьи являются медиа-перепечатками одного и того же отчёта, ещё одна о финансировании DeepSeek не относится к теме и исключена. На Hacker News за всю неделю обсуждений не было; в arXiv по запросу с TileLang в заголовке или аннотации в окне мониторинга 0 записей, ближайшая релевантная запись — по-прежнему TileSight от 24.07.

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

  • Уровни повышения корректности последовательно усложняются, а не повторяются на одном уровне: на прошлой неделе основной репозиторий очищал «проверку форм и геометрии», а три сегмента этой недели различны — сначала геометрия и барьеры warp-специализации и конвейера (#3503, #2342, #3536, #2822), затем тихие числовые ошибки (#2818, #2815, #3550, #3070, #3350, #2860, #3125) и, наконец, согласованность состояния на этапе компиляции (#3579, #3612, #3226). Третий сегмент заслуживает наибольшего внимания: ядра, порождаемые такими дефектами, могут оставаться корректными, но компилятор говорит пользователю одно, а делает другое; TileLang внедряет автоматическое написание ядер агентом, и самосогласованность состояния на этапе компиляции напрямую определит, сможет ли цикл итераций агента сойтись.
  • Узким местом на стороне Ascend стало не количество операторов, а модель памяти, границы среды выполнения и обратный проход обучения: из 11 коммитов в репозиторий адаптации на этой неделе пять приходятся на обратные и рекурсивные операторы (indexer_bwd, обратный проход SiTU-GLU, LSTM, GRU, документация CrossEntropy); крупнейший коммит в основном репозитории — выражение шага строк UB→L1 для NZ-раскладки (#3530, 18 файлов), а наибольшая техническая плотность — у невозможности выразить компактный шаг строк менее 32B, что требует явной остановки (#1795). Вместе с атомарной публикацией JIT-кэша (#1903) и экспоненциальным ростом предикатов PTO (#3581) тема этой линии — «сделать так, чтобы существующие операторы не давали сбоев в граничных условиях». В сочетании с тем, что сообщество CANN заводит отдельный репозиторий операторов ops-tilelang, читается разделение труда: активы операторов несёт репозиторий сообщества, а основной репозиторий сосредоточен на семантике бэкенда и codegen.
  • SM89 и SM90 становятся двумя параллельными аппаратными магистралями, а критерий приоритизации смещается от пиковой производительности к доступности: направление SM90 на этой неделе дало шесть warp-специализированных ядер, а направление SM89 одновременно продвигает шесть путей — блочное масштабирование FP8, INT8 W8A8, FP8 BMM, W4A16, постраничный DSA, NSA top-k, — причём PR обычно сопровождаются измерением на одной карте и явно указывают «не претендуем на результаты работы SM90» и «на крупных сценариях в основном паритет, всеобъемлющего преимущества нет». Видеокарты уровня Ada (L40S, 4090 и подобные) — основное железо в руках отечественных разработчиков, и эта ориентация как раз дополняет отмеченное SemiAnalysis: «оптимизация в основном нацелена на суперузлы, универсальность отстаёт от производительности».
  • На уровне экосистемы организационных действий больше, чем кода: у основного репозитория на этой неделе нет релизов и breaking change, но вне организации появились репозиторий системных руководств на китайском, репозиторий операторов сообщества CANN, рабочий процесс agent SKILL, эксперимент с бэкендом Hexagon, расширение VS Code и репозиторий-обёртка SAIL; внутри организации — планирование агентов в TileFoundry 0.0.3, вторая форма дистрибуции Sunrise, полный набор спецификаций TileOPs. Если смотреть на три вещи вместе — «правила пишет человек, агент занимается тюнингом, в репозитории оседают базовые линии», — инженерное разделение труда на стороне Ascend и в TileLang в целом перестраивается, а сам темп кода спокоен.
  • Аналитические агентства начинают использовать TileLang как критерий доступности Ascend: SemiAnalysis определяет степень завершённости поддержки Ascend для DeepSeek через «из шести репозиториев только TileLang тогда работал», и это лучше любого отдельного технического блога показывает место TileLang в нарративе отечественных вычислительных мощностей — от экспериментального DSL до слоя по умолчанию. Тот же отчёт даёт и обратный сигнал: оптимизация сосредоточена на суперузлах, поддержка x86-хостов всё ещё неполна, между производительностью и универсальностью есть заметный компромисс. Пересказ SCMP показывает, что это суждение входит в мейнстримную медийную повестку.
  • На что обратить внимание в следующем выпуске: выйдет ли v0.1.16 основного репозитория (тишина уже 23 дня); удастся ли снять блокировку 0.1.12 в TileOPs (после закрытия #2554 нового варианта решения не видно, двухбазовостная проверка по-прежнему остаётся шлюзом); удастся ли влить #3512 и #3516 в PTO (это решает, станет ли PTO бэкендом выполнения по умолчанию); будут ли исправлены в следующей версии отсутствие заголовочных файлов в wheel TileFoundry 0.0.3 и проблема ценообразования в #239; как поступить со сбоем S2 wheel Sunrise в tangGetDeviceCount; темп внедрения прямого и обратного прохода sparse_mla на Ascend (#1929 / #1928) и kpool GLM-5.3 (#1910); когда в main попадёт очистка переключателя регистрового конвейера gcy_merge_main на Hygon.

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

  • Материалы: 5 выпусков ежедневного отчёта о динамике сообщества TileLang (10-19, 10-20, 10-21, 10-22, 10-23), суммарное окно сбора пяти выпусков — с 10-16 07:00 по 10-23 07:00 (пекинское время). Выпуск за 10-19 охватывает трёхдневное окно понедельника — с 10-16 07:00 по 10-19 07:00, в основном события выходных с 10-16 по 10-18; в настоящем отчёте они включены как фон и не учитываются в статистике слияний за текущую неделю; четыре выпуска с 10-20 по 10-23 строго попадают в текущую неделю.
  • Критерии учёта слияний: за неделю слито 129 коммитов; по критериям четырёх ежедневных выпусков — 36 (выпуск 10-20), 26 (10-21), 32 (10-22), 35 (10-23); распределение по репозиториям: основной репозиторий tilelang — 37, TileOPs — 68, репозиторий адаптации Ascend — 11, TileFoundry — 8, Hygon — 1, MLIR Ascend — 1, сайт документации — 3. В выпуске 10-19 дополнительно 61 коммит, относящийся к окну выходных с 10-16 по 10-18, в вышеприведённую таблицу не включён.
  • Дополнительная проверка: организация-уровневая проверка в 168-часовом окне подтвердила, что из 29 репозиториев tile-ai в окне были пуши в 11 (TileOPs, tilelang, tilelang-ascend, tilelang-hygon, tilelang-mlir-ascend, tilelang-sunrise, TileFoundry, сайт документации TileFoundry, сайт документации TileOPs, сайт документации tilelang, TileOPs-nightly), что согласуется с порепозиторными выводами каждого ежедневного выпуска; организационная динамика после 07:00 пятницы по установившейся практике включается в следующий ежедневный выпуск, настоящий отчёт её содержание не прогнозирует.
  • Критерии и границы: все данные о производительности — самозаявления из описаний PR или примечаний к релизам (H100, H200, L40S, M2 Pro, 910B3, MTT S5000 и др.); настоящее издание не располагает соответствующим оборудованием и не проводило независимого воспроизведения; покрытие спецификаций и бенчмарков 205/205 взято из данных бейджа статистической ветки организации и является самозаявлением проекта; время публикации сверено по тегам и страницам релизов соответствующих репозиториев, страницы релизов и продвижение веток репозиториев адаптации могут запаздывать; суждения SemiAnalysis и SCMP являются сторонним анализом, а не официальными заявлениями производителей. Количество находящихся на рассмотрении PR в разных выпусках учитывается по не полностью совпадающим критериям (в одних берётся общее число is:open репозитория, в других — число обновлённых в окне), при цитировании это отмечено в тексте.
  • Предлагаемый период следующего выпуска: 2026-10-26 ~ 2026-10-30.

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

Источник Результат проверки
Организация tile-ai (29 репозиториев) В 168-часовом окне пуши были в 11 репозиториях; по критериям четырёх выпусков текущей недели слито 129 коммитов, обновлено в окне рассмотрения от 52 до 71
Основной репозиторий tilelang За неделю слито 37 коммитов; открытых PR снизилось с 167 до 163; VERSION по-прежнему 0.1.15, за всю неделю нет новых тегов и релизов (тишина уже 23 дня)
TileOPs За неделю слито 68 коммитов (плюс 44 в окне выходных); на рассмотрении снизилось с 16 до 9; покрытие спецификаций и бенчмарков заявлено 205/205; по-прежнему закреплён tilelang 0.1.12
TileOPs-nightly Два снимка ветки snapshots: 10-19 05:41 и 10-20 05:39; в отчёт добавлена колонка «новые операторы»
TileFoundry За неделю слито 8 коммитов; v0.0.3 выпущен 10-21 10:26 (единственная новая версия за неделю); на рассмотрении от 1 до 4
Ascend (tilelang-ascend + изменения Ascend в основном репозитории) В репозитории адаптации слито 11 коммитов, на рассмотрении более 11; в основном репозитории слито 12 коммитов, связанных с Ascend; прямой и обратный проход sparse_mla на рассмотрении
Hygon (tilelang-hygon) В main слит 1 коммит (#25); на рассмотрении 3; три пуша в feature-ветку дали локализацию цепочки адресов для декодирующего GEMM
MetaX / Moore Threads / MLIR Ascend В окне во всех трёх репозиториях нет коммитов, они остановились на 10-16 / 09-30 / 10-19 соответственно
Sunrise PR релиза 0.1.15+sunrise.1.2.0 (#9) на рассмотрении; после установки wheel S2 import падает на tangGetDeviceCount
Потребители (TileKernels / FlashQLA) Оба остановились на 10-14, за всю неделю нет коммитов; требования к версиям по-прежнему указывают на TileLang 0.1.15 и CANN 9.2.0
TileRT / tilescale / DeepStack В окне пушей нет (последние 09-24, 08-25, 10-05 соответственно)
Сообщество и сторонние репозитории 4 новых репозитория (tilelang-tutorial, ops-tilelang, tilelang-hexagon, tilelang-wrapper-for-sail), более 5 активных (cookbook, devkit-vscode, tilelangGym, w4a16-tilelang, tilelang-cuda-skills)
СМИ и академическая сфера В Google News по нескольким группам запросов на китайском и английском в окне всего 6 совпадений, только у SemiAnalysis есть специальный раздел о TileLang, остальное — перепечатки или косвенно related; в Hacker News обсуждений нет; в arXiv за окно 0 записей

Основные ссылки

— https://github.com/tile-ai/TileOPs/tree/stats

Источники данных: ежедневный отчёт о динамике сообщества TileLang (пять выпусков с 2026-10-19 по 2026-10-23) и проверка фактическими измерениями в этом цикле; период отчёта — с 19 по 23 октября 2026 года.