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

Источники: поатомная проверка репозиториев организации GitHub tile-ai (tilelang / TileOPs / TileFoundry / tilelang-ascend / tilelang-mlir-ascend / tilelang-hygon / tilelang-metax / tilelang-musa / TileRT / tilescale / DeepStack / сайт документации / ночное зеркало репозитория) + проверка достоверности смёрженных и находящихся на рассмотрении изменений (смёржено 12, обновлено на рассмотрении 54) + полная проверка новых issue (4) + поатомная проверка коммитов основной ветки (tilelang 5, tilelang-ascend 5, TileOPs 1, TileFoundry 1, сайт документации 5) + проверка страницы релизов и тегов + проверка сторонних бэкендов и экосистемных репозиториев (10 репозиториев) + шесть групп запросов Google News на китайском и английском (через прокси) + Hacker News + arXiv.

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

  • Ключевое за сегодня: в репозитории Ascend пять коммитов дополняют операторы алгоритмической стороны (kpool-сжатие GLM-5.3, Chunk Scaled Dot KKT, исправление W4A4 GEMM, пример depthwise-свёртки, skill профилирования производительности); в основном репозитории полное warp-редуцирование переведено на redux.sync, а независимая конфигурация autotuner заменена на параллельную компиляцию; за 24 часа влито 12 коммитов, обновлено в ревью 54 коммита, открыто 4 новых issue
    1. Ход работ по ключевым проектам
      • 1.1 Основной репозиторий: полное warp-редуцирование переведено на redux.sync, выбор максимума FP32 по четырём 32-lane группам превратился из 20 shuffle в 4 аппаратных редуцирования (#3692) (29.10)
      • 1.2 Основной репозиторий: независимая JIT-конфигурация autotuner заменена на параллельную компиляцию, блокировка сохраняется только для кандидатов с одинаковым ключом (#3476) (29.10)
      • 1.3 Основной репозиторий: layout и единицы указателя представления буфера Ascend больше не распространяются через алиасы (#3623) (29.10)
      • 1.4 Основной репозиторий: копирование GM→L1 и заполнение за границами объединены в одну задачу планирования, убран лишний барьер MTE2 (#3543) (29.10)
      • 1.5 Основной репозиторий: CI вернул задачи ROCm и Metal на совместимые wheel-пакеты PyTorch (#3706) (29.10)
      • 1.6 Три новых дефекта: пакетное копирование разделяемого буфера с заполнением сообщает о несовпадении формы, итерационный граф с отрицательным масштабом ошибочно компилирует обратный индекс, разрядность представления переполняется в int32 (#3704 / #3705 / #3707) (29.10)
      • 1.7 Три исправления в ревью: разрядность изменена на int64, скалярный GEMM на CPU очищает только целевую область, при отключённом кэше обходятся два уровня внутрипроцессного кэша (#3708 / #3709 / #3710) (29.10)
    1. Адаптация под множество бэкендов (Ascend / Hygon / Moore Threads / MetaX)
      • 2.1 Ascend: влит оператор kpool-сжатия indexer разрежённого внимания GLM-5.3, чисто Vector-маршрут в одном kernel (#1910) (29.10)
      • 2.2 Ascend: влит прямой оператор Chunk Scaled Dot KKT блочного gated linear attention, статическое разворачивание на четыре блока, без рабочей области GM (#1803) (29.10)
      • 2.3 Ascend: влито исправление полного рассогласования результатов GEMM int4×int4 для W4A4, корневая причина — ложное указание размера типа и молчаливое отключение специализированной инструкции транспонирования (#1731) (29.10)
      • 2.4 Ascend: повторно представлен пример depthwise_conv_2d, тестовые каналы переведены на списочную форму во избежание параллельных пакетов (#1920) (29.10)
      • 2.5 Ascend: добавлен skill профилирования производительности операторов, вывод msprof op определяет направление оптимизации (#1931) (29.10)
      • 2.6 Ascend в ревью: три исправления представлений и broadcast на языковом уровне NPUIR (#1962 / #1960 / #1961) (29.10)
      • 2.7 Ascend в ревью: исправление беззнакового байтового представления рабочей области для побитового XOR в бэкенде PTO (#1959) (29.10)
      • 2.8 Hygon: два обновления в ревью по HCU, в сообществе появился репозиторий fused-операторов для DCU; Moore Threads и MetaX за окно мониторинга без пушей (29.10)
    1. Экосистема и стороны внедрения (TileOPs / TileFoundry / TileKernels / FlashQLA / третьи стороны)
      • 3.1 TileOPs: влит релиз образа, библиотека операторов и TileFoundry впервые попали в один образ (#2793) (29.10)
      • 3.2 TileOPs в ревью: GEMM пересчитывает группировку сетки и число резидентных блоков с ограничением по энергопотреблению, DRAM-чтение q-b снижено с 168 МБ до 94 МБ (#2794) (29.10)
      • 3.3 TileFoundry: runtime-операторы AMX переведены на 39 статических контрактов TIR, это ломающее изменение (#279) (29.10)
      • 3.4 Стороны внедрения: в основных ветках TileKernels и FlashQLA за окно мониторинга пушей нет (29.10)
      • 3.5 На стороне Ascend появился независимый репозиторий операторов сообщества ops-tilelang, за окно мониторинга есть пуши (29.10)
      • 3.6 Парные репозитории PTO-ISA активны: репозиторий задач мигрирован на PTOAS 0.70, в репозиторий бенчмарков добавлены блочное масштабирование SV2 и поколоночный анализ (29.10)
      • 3.7 Наблюдение: в форк-репозитории tilelang под именем T-HEAD за окно мониторинга есть пуши, имена веток указывают на layout матричных инструкций PPU (29.10)
    1. Сообщество, руководства и мероприятия
      • 4.1 Сайт документации внёс границы применимости встроенного редуцирования в страницу инструкций синхронно с влитием redux (29.10)
      • 4.2 Репозиторий инструментов разработки завершил три доработки после выделения отслеживания нисходящих зависимостей, в том же направлении, что и изменения инструментария в ревью вышестоящего проекта (29.10)
      • 4.3 Новый репозиторий tilelang-knowledge: четыре коммита за день — 33 примера проектирования операторов, 20 карточек знаний с источниками, 7 паттернов оптимизации (29.10)
      • 4.4 В тот же день созданы сопутствующий репозиторий иллюстрированного курса и репозиторий экспериментов с распределённым layout (29.10)
      • 4.5 Новостная сторона: шесть групп запросов Google News на китайском и английском, Hacker News и arXiv — существенных попаданий за окно мониторинга нет (29.10)
    1. Наблюдения за трендами
  • Приложение. Материалы и примечания по проверке

Ключевое за сегодня

Сегодняшний объём слияний снизился с 24 вчера до 12, но структура стала более концентрированной: пять коммитов в специализированном репозитории Ascend, пять в основном репозитории, по одному в TileFoundry и TileOPs. Партия в репозитории Ascend целиком состоит из операторов алгоритмической стороны, причём все они относятся к тому типу, который можно напрямую использовать для вышестоящих моделей. Оператор kpool-сжатия indexer разрежённого внимания GLM-5.3-Flash упаковывает поразмерное softmax-пулирование, границы BF16, нормализованный поворот Hadamard-128 и квантизацию E4M3 в один чисто векторный kernel: каждый блок покрывает 64 pool, два векторных подъядра управляют по 32 каждое, на стороне хоста нулевая перестановка, данные напрямую переносятся с шагом по трёхмерной раскладке вызывающей стороны; кодирование E4M3 реализовано чисто целочисленными битовыми операциями (round-half-even, с субнормалями, с насыщением до 448), без зависимости от типа FP8 и без приближений. Chunk Scaled Dot KKT — это A = gate(K K^T) в прямом проходе блочно-гейтового линейного внимания: статическое развёртывание на четыре блока, нулевая рабочая область GM, ноль хостовых операторов, коэффициент совпадения для трёх случаев L0 и L1 равен 1.0.

Тема основного репозитория сегодня — уровень компиляции и запуска. Полновarp-редукция переведена на redux.sync: четыре независимых выбора максимума FP32 по тридцати двум линиям на главной ветке развёртывались в 20 shuffle при CUDA 13.1 и sm_103a, после изменения это четыре redux.sync.max.f32 без shuffle; целочисленная редукция на SM80 и выше идёт через аппаратную редукцию, выбор максимума и минимума FP32 доступен только на sm_100a, sm_100f, sm_103a, sm_103f, узкие типы (включая FP16, BF16 из CUTLASS) повышаются до FP32, FP64 по-прежнему остаётся на пути shuffle. Автор явно не заявляет сквозного ускорения, приводит только сопоставление на уровне инструкций. Параллельная компиляция autotuner’а разбивает блокировку компиляции, удерживаемую на весь участок: для каждой конфигурации покрытия через dataclasses копируется независимый JITImpl, последовательно выполняются только кандидаты, разделяющие ключ первой стадии, запись отладочного вывода на диск также остаётся последовательной. Приёмка автора по разным бэкендам: Ascend 1797 позиций, ROCm 3220 позиций, Metal 95 позиций, CUDA 5500 позиций.

Ещё одна деталь, заслуживающая упоминания: сегодня открытый дефект ошибочной компиляции обратного индекса (#3705) воспроизводился во время выполнения на ветке-репозитории tilelang под именем T-HEAD, что показывает: уже существует полноценная команда, которая сопровождает этот вышестоящий код как основу собственного аппаратного стека, а не просто как внешнюю зависимость.

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

1.1 Основной репозиторий: полновarp-редукция переведена на redux.sync, четыре выбора максимума FP32 по 32 lane превратились из 20 shuffle в 4 аппаратные редукции (#3692)

Слито 10-29 15:08, 4 файла +337/-35. Ранее обычная межпоточная редукция (например, T.reduce_max) даже при условии, что вся группа — выровненный полный warp, всё равно развёртывалась в дерево shuffle: на главной ветке 837486a четыре независимых выбора максимума FP32 по 32 lane при компиляции под sm_103a с CUDA 13.1 давали 20 shuffle и ноль redux, после изменения — четыре redux.sync.max.f32 и ноль shuffle. Способ — переиспользование уже имеющегося помощника warp_reduce из скалярной и пакетной полной редукции: вызывающая сторона определяет только геометрию потоков (выравнивание по warp, единичный шаг, полный warp), а архитектура, тип данных и диспетчеризация оператора передаются помощнику. Целочисленная редукция на SM80 и выше идёт через аппаратный redux, меньшие целые повышаются до 32 бит; выбор максимума и минимума FP32 доступен только на sm_100a, sm_100f и sm_103a, sm_103f; узкие плавающие типы повышаются до FP32 и затем передаются помощнику, FP64 не снижает точность и остаётся на пути shuffle. Субwarp, шаговые, упакованные редукции, а также неподдерживаемые операторы и цели всегда откатываются к shuffle; обмен через разделяемую память между warp и барьеры не меняются. Попутно исправлена одна ошибка компиляции: пользовательский редуктор беззнаковых целых ранее не компилировался из-за возврата пустого типа при встроенной диспетчеризации, теперь он откатывается к shuffle. PTX-регрессия утверждает наличие реальных инструкций и отсутствие shuffle, среда выполнения покрывает граничные значения знаковых и беззнаковых, пакетную неочистку, исполнение NVRTC, нефинитные значения, знаковый ноль и точный результат FP64. Автор явно не заявляет сквозного ускорения. В описании отмечена и одна унаследованная проблема: пакетная редукция при batch=4 с двумя выходами на поток и batch=8 с четырьмя выходами на поток даёт сбои FP16 и BF16, исходный шаблон главной ветки воспроизводит то же самое, причём сбой происходит на стадии понижения и к этому коммиту отношения не имеет.

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

1.2 Основной репозиторий: независимые JIT-конфигурации autotuner’а переведены на параллельную компиляцию, блокировка сохраняется только для кандидатов с одинаковым ключом (#3476)

Объединено 29.10 в 16:24, 2 файла +54/-46. В основной ветке _make_jit_compile_func удерживает блокировку на всё время компиляции, из-за чего даже конфигурации, использующие только опции компиляции по умолчанию, выполняются последовательно, и фронтенд, понижение и компиляция устройства оказываются в очереди. Решение — для каждой конфигурации переопределения с помощью dataclasses.replace конструируется кандидатный JITImpl, при этом бэкенд, цель, выбор вывода, уровень логирования, флаги компиляции и отладочные опции сохраняют исходные значения; опции по умолчанию по-прежнему идут по исходному пути ленивого вызова, сохраняя свой кэш ядра и идентичность объекта; последовательно выполняются только кандидаты с общим ключом первой стадии (вычисляется связывателем аргументов, используемым get_tir, сохраняет позиционные аргументы, значения по умолчанию и фабрики с тензорными аннотациями); общий вывод отладочных файлов по-прежнему сериализуется внутри компиляции, переопределяя debug_root_path, настройки дампа IR и визуализацию раскладки. Данные приёмки на сквозном конвейере разных бэкендов: задача Ascend объединяет 3be11be6 и основную ветку c58a86f0, Python 3.12.14, torch_npu 2.10.0, CANN 9.3.0, 1797 проверок пройдено, примеры AscendC — все 50 прошли, примеры PTO — 44 прошли, 6 пропущено; задача ROCm 7.2 на gfx942 — 3220 пройдено, 2765 пропущено; задача Metal на macOS arm64 — 95 пройдено, 5 пропущено; задача CUDA на H100 PCIe, cu130 — 5500 проверок пройдено, 491 пропущено, примеры — 76 прошли, 14 пропущены; задача CuTeDSL — 75 прошли, 17 пропущено, 2 неожиданно прошли.

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

1.3 Основной репозиторий: раскладка и единицы указателей в представлениях буферов Ascend больше не распространяются через псевдонимы (#3623)

Объединено 29.10 в 13:17, 23 файла +1139/-438. Несколько буферов, созданных через T.view или T.reshape, могут совместно использовать один участок хранилища, требуя разных раскладок; ранее раскладка разрешалась единообразно по общей переменной данных, из-за чего могла выбираться неверная Cube-разметка или адрес DMA, а устаревшая геометрия тайлинга теряла версионные смещения или интерпретировала типизированные смещения указателей в неверных единицах. Этот коммит привязывает раскладку к отдельному представлению Buffer на всём пути вывода раскладки, нормализации фрактального хранилища, материализации множественных буферов, а также понижения копирования и матричного умножения; идентичность представления сохраняется до применения отображения раскладки и компактного интервала L0, а смещения сырых указателей пересчитываются в единицах элементов каждого представления. Раскладки через псевдонимы хранилищ больше не распространяются — каждое представление использует свою аннотацию, выведенную оператором раскладку или обычную адресацию; на одном версионированном распределении Cube-представление теперь может использовать разные раскладки MajorK и MajorMN при условии, что логические шаги плотные, смещение базового адреса равно нулю, типы операндов совместимы и размеры хранилища после заполнения равны. Псевдонимы множественных буферов используют общий размер физического слота, пересчитываемый в единицах элементов каждого представления без распространения отображения индексов; представление лишь переинтерпретирует существующие байты, записывающая сторона должна писать в представлении, ожидаемом потребителем, а при необходимости выбрать представление для встроенных инструкций можно обратиться к интерфейсу указателя доступа.

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

1.4 Основной репозиторий: копирование GM в L1 и заполнение за границами объединены в одну задачу планирования, убран лишний барьер MTE2 (#3543)

Объединено 29.10 в 11:39. Копирование из глобальной памяти в L1 и его заполнение за границами совместно подготавливают один и тот же участок данных L1; ранее заполнение могло выделяться в отдельную задачу планирования, и вставка синхронизации добавляла лишний барьер конвейера MTE2 между копированием и заполнением. Этот коммит включает каждое копирование и его заполнение в одну задачу Ascend, и потребитель ожидает полные данные, включая заполнение; хвостовое заполнение K для FP8 MX также объединяется с сохранением условного заполнения внутри задачи, существующая явная область задачи остаётся неизменной и не вкладывается; прежняя очередь отложенного заполнения MX удалена, и заполнение каждого операнда следует непосредственно за своим копированием. 47 целевых тестов пройдено, охватывая как обычное заполнение за границами, так и хвостовые блоки MX.

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

1.5 Основной репозиторий: CI привязывает задачи ROCm и Metal обратно к совместимым wheel-пакетам PyTorch (#3706)

Объединено 29.10 в 21:38. CI для ROCm через переменную индекса предоставляет совместимый источник PyTorch ROCm, но стратегия уровня рабочего процесса «небезопасное наилучшее совпадение» всё равно позволяет побеждать более поздним кандидатам из PyPI: в задаче ROCm из #3534 резолвер выбрал PyTorch 2.15.0 из PyPI (CUDA 13.2) вместо доступной сборки 2.14.1 с ROCm 7.2; оба результата разрешения официально воспроизведены на раннере. То же развёртывание 2.15.0 нарушило и задачу Metal: на ARM64-раннере с macOS 26.6.2 версия 2.15.0 отказывает в Apple паравиртуальном GPU, поскольку не предоставляет Metal 2.0, тогда как на том же образе предыдущий успешный запуск использовал 2.14.1. Исправление состоит из трёх пунктов: установить переменную бэкенда согласно настроенной стабильной версии ROCm, чтобы uv удерживал PyTorch на источнике ROCm, а остальные зависимости по-прежнему использовали наилучшее совпадение; для ночной установки PyTorch использовать первый индекс, чтобы ночные задачи не могли выйти за пределы настроенного источника; добавить шаг быстрой проверки с немедленным провалом, который до запуска набора тестов подтверждает, что PyTorch является сборкой HIP, а не CUDA, и имеет доступ к GPU раннера.

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

1.6 Три новых дефекта: копирование разделяемого буфера с заполнением через пакетное копирование сообщает о несоответствии формы, итерационный граф с отрицательным масштабом ошибочно компилирует обратный индекс, разрядность представления переполняется в int32 (#3704 / #3705 / #3707)

Все три issue указывают на границы статической проверки. Во-первых, #3704 сообщает, что при копировании глобального тензора, последнее измерение которого не выровнено по 16 (например, K=100), в разделяемый буфер с заполнением (BK берётся как cdiv(K,16) умножить на 16, получается 112), как только это копирование направляется в путь пакетного копирования, понижение (lowering) сразу сообщает о несоответствии формы разделяемого блока и глобального блока (112 против 100), местоположение — в точке пакетного понижения CUDA-копирования; буфер с заполнением на поэлементном пути работает нормально, а заполнение как раз является распространённым способом удовлетворения выравнивания для матричного умножения, поэтому любое ядро, использующее его совместно с пакетным копированием, может с этим столкнуться. Во-вторых, #3705 сообщает, что упрощение плоского буфера ошибочно компилирует обратный индекс в итерационном графе с отрицательным масштабом; среда воспроизведения — v0.1.15 и сборка из исходников ветки tilelang под именем T-HEAD, в отчёте также сверено, что затронутые функции декомпозиции в upstream-основной ветке и соответствующей ревизии TVM не изменились, это общий для upstream путь. В-третьих, #3707 сообщает, что представление и reshape при сверке разрядности буфера перемножаются как int32, и при превышении 2 в степени 31 происходит переполнение с оборачиванием: вес lm_head у Qwen3.8 составляет 248320 умножить на 2560 байт NVFP4, всего 5 085 593 600 бит, произведение разрядностей оборачивается в 790 626 304, после чего при преобразовании статической разрядности представления в int32-константу выбрасывается превышение предела литерала.

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

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

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

1.7 Три исправления на рассмотрении: разрядность изменена на int64, скалярный GEMM на CPU очищает только целевую область, при отключённом кэше обходятся два уровня внутрипроцессного кэша (#3708 / #3709 / #3710)

В соответствии с тремя вышеуказанными дефектами и вчерашней темой семантики кэша, исправления поступили на рассмотрение в тот же день. Исправление разрядности меняет перемножение статических размерностей на перемножение с использованием целых чисел Python, преобразует символические размерности в int64 и преобразует литералы, превышающие int32, в int64-константы; регрессионный тест напрямую берёт буфер из этого issue (форма представления 248320 умножить на 5120), основная ветка выдаёт ошибку, после изменения проходит, также покрывается одноформное представление символической размерности. Исправление для CPU устраняет проблему скалярного матричного умножения, которое при обнулении накопления очищает весь нижележащий буфер: для выходного буфера 4 на 4 с инициализацией 7 и последующим вызовом подобасти 1–3 строк и столбцов исходная реализация обнуляла бы вместе с тем 12 элементов вне области, изменённый способ инициализирует только с использованием смещения и диапазона самой выходной области, регрессионный тест написан соответственно как матрица 2 на 2 из всех единиц. Исправление кэша устраняет #3699, зафиксированный вчера: отключение кэша ядер только переключало состояние кэша, тогда как обёртка jit перед фактической компиляцией ещё проверяет два внутрипроцессных кэша, и обычный вызов внутри блока получал ядро, ранее скомпилированное в том же процессе; изменение состоит в чтении переключателя кэша во время вызова (одновременно покрывается отключение через переменную окружения), пропуске двух уровней внутрипроцессного кэша в период отключения и восстановлении после выхода из блока. Тест из 1 неудачи и 4 успехов до изменения превращается в 5 успехов после изменения.

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

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

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

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

2.1 Ascend: оператор kpool-сжатия indexer разрежённого внимания GLM-5.3 влит, одиночное ядро с чисто Vector-маршрутом (#1910)

Влито 10-29 15:41. Оператор для каждого pool (pool_size равен 4) складывает тензор оценок с позиционным кодированием, затем выполняет поразмерный softmax-пулинг, пулинг-вектор проходит через границу BF16, затем умножается на нормализованное вращение Sylvester Hadamard-128 (делится на квадратный корень из 128), наконец выполняется квантизация E4M3 с масштабированием по абсолютному максимуму степени двойки FP32 для каждого вектора: строка E4M3 и масштабирующий множитель записываются в непрерывную временную область, откуда хост-адаптер рассеивает их в постраничный кэш (кэш ключей использует беззнаковые байты для переноса E4M3, кэш масштабов записывается FP32 на месте). Реализация — одиночное ядро с чисто Vector-маршрутом, в режиме разработчика включены три переключателя: автосинхронизация, автоматическое объединение векторных и матричных ядер, планирование памяти; каждый блок покрывает 64 pool, два векторных субъядра обрабатывают по 32 независимых параллельно; на хосте нулевая перестановка, ядро напрямую читает с шагом по трёхмерной раскладке вызывающей стороны, позиционное кодирование вкладывается в пулинг; кодирование E4M3 — чисто целочисленные битовые операции, round-half-even, включая денормализованные, с насыщением до 448, тип FP8 не используется и приближение не выполняется.

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

2.2 Ascend: прямой оператор Chunk Scaled Dot KKT блочно-стробированного линейного внимания влит, статическое разворачивание четырёх блоков, нулевая рабочая область GM (#1803)

Слито 10-29 в 15:01. Добавлено масштабированное скалярное произведение с блочным внутренним произведением для прямого прохода: для прямого вычисления блочно-гейтированного линейного внимания A равно гейтированному по входу K, умноженному на транспонированный K. Реализовано как один kernel, декорированный компилятором, со статическим развёртыванием четырёх блоков для внутричипового слияния, нулевым рабочим пространством глобальной памяти, нулевым числом вызовов хост-операторов, в режиме разработчика все четыре переключателя включены. Тестирование разделено на четыре уровня L0, L1, L2 и граничный с возможностью выбора уровня из командной строки, L0 покрывает три случая (с гейтированием, без гейтирования, маломасштабный с гейтированием), точность сверяется с эталоном FP32 PyTorch CPU, применяются двойные ворота со смешанным допуском. В отчёте приведена измеренная конфигурация: батч 1, длина последовательности 32768, голов 32, размерность на голову 128, блок 64, гейтирование включено, вход и выход BF16, накопление FP32, у L0 и L1 по три примера — все прошли, коэффициент совпадения 1.0000, максимальная абсолютная погрешность в диапазоне от 0 до 0.25.

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

2.3 Ascend: исправление полностью неверных результатов int4 умножить на int4 GEMM для W4A4 слито, корневая причина — ложное указание размера типа и молчаливое отключение специализированной инструкции транспонирования (#1731)

Этот PR, вчера ещё находившийся на рассмотрении, сегодня в 15:08 слит, соответствует #438. Корневая причина — наложение трёх уровней ошибок. Во-первых, фрактальная геометрия выводилась из равенства размера типа единице, тогда как тип с полбайтовой упаковкой занимает всего 4 бита на элемент, по два элемента на байт, поэтому правильное число элементов в 32-байтовом блоке C0 равно 64, а не 32, все шаги копирования, числа повторений и вычисления в байтах смещены вдвое, данные в L0A и L0B укладываются в неверные позиции. Во-вторых, транспонированная загрузка операнда B молча отбрасывалась: общий путь загрузки устанавливает флаг транспонирования для преобразования zN в nZ, но специализированная четырёхбитная инструкция жёстко отключает транспонирование и игнорирует этот флаг, B никогда не получает раскладку, ожидаемую инструкцией матричного умножения; правильный путь — специализированная загрузка с транспонированием, а она нигде не документирована в заголовочных файлах CANN, параметры приходится восстанавливать эмпирически на устройстве с помощью probe kernel (за одно повторение переносится целый блок, число повторений берётся как N делить на 64, шаг источника — K с округлением вверх до 16, делённое на 64, целевой зазор — 3), причём эта версия фактически работает блоками по 2048 байт, что отличается от фрактальной единицы 512 байт в общей документации. В-третьих, подсчёт байтов между вектором и глобальной памятью также ведётся из расчёта 1 байт на элемент вместо 0.5, длина копирования каждой строки завышена вдвое, подмешиваются данные соседних строк. Сама вычислительная инструкция всегда корректна, она лишь добросовестно перемножает неверно размещённые данные, симптом — 99.6% несовпадений, выходные значения минус 501 и 627 при правильных 641 и 1785. В отчёте также чётко описано соглашение об int4-упаковке в глобальной памяти: два полубайта на байт, младший полубайт — чётные элементы, старший полубайт — нечётные элементы, строка r начинается с байтовой позиции r умножить на N делить на 2, что согласуется с собственным форматом CANN.

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

2.4 Ascend: повторно подан пример depthwise_conv_2d, тестовый канал переведён на манифестный для обхода параллельных батчей (#1920)

Слито 10-29 в 15:43. Это повторная подача #1915: после слияния оригинального PR ночной полный CI упал, через #1919 произведён откат, корневая причина — срабатывание неизвестной ошибки в максимальном по размеру случае L0 в условиях восьмипоточного параллельного батча унаследованных скриптов; в этом PR этот случай урезан на четверть, а оператор зарегистрирован в манифесте операторных тестов непрерывной интеграции и проходит через канал Pytest, тем же маршрутом, что и остальные двадцать пять уже мигрированных операторов, полностью выведен из параллельного батча, тело kernel побайтово идентично оригинальному PR. Сам оператор поддерживает fp16, fp32, bf16 и произвольные размеры ядра, шаг, заполнение, расширение, при шаге 1, 2, 4 идёт путём векторизованной области, в остальных случаях — скалярное внутреннее произведение как запасной путь; реализация — два kernel: заполнение плюс свёртка, плюс быстрый путь 1 на 1, чисто Vector маршрут, сетка адаптируется по геометрии без жёсткого задания числа ядер. В отчёте стоит запомнить несколько измеренных ограничений: время этапа заполнения примерно равно числу инструкций умножить на 35 наносекунд и не зависит от числа байтов, поэтому последняя полоса завершается усечением; если целевое смещение копирования на стороне разделяемой памяти не выровнено по 32 байтам, срабатывает исключение 0x26 векторного ядра; синхронизация использует рукописную чемпионскую модель (в секции свёртки автоматическая синхронизация отключена), между каналами применяется протокол событий соседнего переноса и вычисления глубиной 1, протокол глубиной 2 или вставка полного барьера посередине приводят к взаимоблокировке.

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

2.5 Ascend: добавлен skill профилирования производительности операторов, вывод msprof op задаёт направление оптимизации (#1931)

Слито 10-29 в 17:17. Добавлен актив процесса разработки для профилирования производительности операторов: перед оптимизацией производительности прогнать операторный уровень msprof, затем по выводу определить направление следующей оптимизации. Автор уже проверил работоспособность процесса на трёх операторах: поэлементное сложение, пример уменьшения с поиском минимума и динамическое квантование. Ценность подобных активов в том, что принцип «сначала измерить, потом менять» закрепляется в процессе, а не выясняется заново каждый раз при освоении методики профилирования.

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

2.6 Ascend на рассмотрении: три PR по исправлению представлений и вещания на уровне языка NPUIR (#1962 / #1960 / #1961)

Три коммита поступили на рассмотрение в один день и взаимозависимы. Первый, #1962, исправляет дескриптор представления для локально унифицированного буфера: мостовой слой ищет буфер по переменной общих данных и может вернуть ссылку на выделенную память без применения дескриптора, из-за чего псевдоним с смещением того же типа читает префикс области выделения, псевдоним другого типа входит в понижение копирования с элементом типа выделения, а переформирование того же типа может войти в редукцию с неверной размерностью; исправление вводит унифицированный помощник получения представления, для неидентичных представлений того же типа используется реинтерпретация с проверкой, а для доступа к выделению с многоэлементным типом — единое байтовое выделение с типизированными операциями представления для сохранения общей идентичности хранилища. Второй, #1960, исправляет потерю исходного смещения представлением: при перестроении буфера из переменной данных представление теряло смещение элемента, поэтому псевдоним со смещением начинался с нулевого смещения выделения, а не с адреса первого элемента источника; исправление сохраняет смещение для того же типа, при байтовом изменении типа пересчитывает по ширине элемента и требует делимости, а невыровненные или неподдерживаемые преобразования прямо отклоняет, не вводя хранилища или копирования данных. Третий, #1961, меняет вывод широковещания унарного вектора по области доступа: ранее размерность широковещания выводилась по форме исходного буфера, и запись источника 8 на 8 в строки с 8 по 16 цели 24 на 8 завершалась неудачей; исправление выводит по типу сгенерированной ссылки на память, сохраняя форму участка доступа и существующие проверки совместимости. Все три коммита сопровождаются независимой чистой базовой сборкой и поразрядной проверкой.

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

2.7 Ascend на рассмотрении: исправление представления рабочей области беззнаковых байтов для побитового исключающего ИЛИ в бэкенде PTO (#1959)

Поступил на рассмотрение 10-29 16:36, закрывает #1721. В бэкенде PTO временная рабочая область для побитового исключающего ИЛИ передавалась инструкции как необработанная одномерная байтовая область вместо требуемого двумерного представления: при генерации двумерная форма назначения копировалась в информацию о форме рабочей области, но не помечалась как срез, поэтому для беззнаковых байтов (рабочая область не подвергается реинтерпретации типа) разрешался одномерный блочный дескриптор, и инструкция при выполнении выходила за границы при чтении и записи. Сама рабочая область выделяется как одномерная область по числу элементов источника, ёмкости для выровненного двумерного блока достаточно, сбой в дескрипторе, а не в ёмкости. Исправление наследует форму назначения, затем принудительно строит двумерное представление и помечает его как срез; тесты дополнены набором покрытий для беззнаковых и знаковых байтов (двумерный автоматический временный, явный одномерный временный, одномерный, выровненный срез с ненулевым смещением и сторожевым значением, знаковые байты), а также сохранён 16-битный регресс.

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

2.8 Hygon: два коммита HCU на рассмотрении с обновлениями, в сообществе появился репозиторий слитых операторов DCU; у Moore Threads и MetaX в окне мониторинга нет пушей (10-29)

На стороне Hygon всё ещё на рассмотрении: ветка характеристики вертикального чередования разделяемой памяти для обычного копирования (#30) и распределительный коммит (#19) получили обновления в окне мониторинга, последний коммит основной ветки по-прежнему остановился на характеристике группировки буферов от 10-27. На стороне сообщества в тот же день появился репозиторий направления DCU, сохраняющий вместе слитые операторы платформы Hygon и изменения компилятора TileLang, преимущественно C++, около 15 MB, в истории коммитов видны поддержка операторов внимания и поддержка переменной длины, это личный практический репозиторий, а не официальный от Hygon. В адаптационном репозитории Moore Threads (tilelang-musa) и адаптационном репозитории MetaX (tilelang-metax) в окне мониторинга пушей не было, последние соответственно 09-30 и 10-26.

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

Источник: https://github.com/SealSoul117/TileLang_DCU_FuseCmpComm

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

3.1 TileOPs: релизный образ слит, библиотека операторов и TileFoundry впервые попали в один образ (#2793)

Слито 10-29 11:18, 9 файлов +123/-49. В образ раннера добавлена цель релиза: поверх образа разработки устанавливаются PyPI-релиз библиотеки операторов и планировщика и именуются по версиям обоих; тег образа — tileops0.1.0 плюс tilefoundry0.0.3 плюс три сегмента идентификаторов окружения cuda13.2, torch2.13 и tilelang0.1.12, публикуется в пути релиза библиотеки операторов в репозитории контейнерных образов. Дополнительный скрипт извлекает образ и запускает на GPU проверку стека, проверку базовой линии, тесты упаковки и необязательные файлы бенчмарков, поскольку в колёсах нет тестов и бенчмарков, всё берётся из тегов, соответствующих собственной версии образа. Документация обновлена в разделе быстрого старта, документация раннера дополнена шагами сборки, проверки и отправки. Одновременно удалена базовая линия sgl-kernel: больше никакой образ её не устанавливает, соответствующие бенчмарки ранее постоянно пропускались.

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

3.2 TileOPs на рассмотрении: GEMM пересчитывает группировку сетки и число резидентных блоков с ограничением по мощности, чтение DRAM для q-b снижено с 168 MB до 94 MB (#2794)

Поступило на рассмотрение 10-29 21:44, 2 файла +35/-12, продолжает тему производительности при обратно-обратных вызовах. Два изменения: во-первых, когда A может поместиться в один раздел кэша второго уровня, а B не может, группировка сетки позволяет одной группе охватывать все строки, поэтому каждый блок B читается из памяти только один раз вместо одного раза на каждую группу из шестнадцати строк, и на форме q-b предзаполнения DeepSeek V3 (4096 на 24576 на 1536, раскладка NT) чтение из памяти снижается с 168 MB до 94 MB; граница разбиения узких блоков по-прежнему ограничена группировкой по шестнадцати строкам, выбор не меняется. Во-вторых, число резидентных блоков на сетке с двумя кооперирующими группами равномерной ширины теперь вычисляется как округлённое вверх резидентное число по числу блоков, общему числу блоков и числу процессоров, а не берётся напрямую из числа процессоров, поскольку самый загруженный блок в любом случае должен выполнить столько же блоков, а каждая волна может прочитать меньше различных панелей; для пинг-понга, узких блоков и сеток смешанной ширины по-прежнему используется число процессоров. Тесты прогонялись на H200, CUDA 13.2, PyTorch 2.13, TileLang 0.1.12, тесты операторов: 212 прошли, 24 пропущены.

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

3.3 TileFoundry: runtime-операторы AMX переведены на 39 статических контрактов TIR, это ломающее изменение (#279)

Слито 10-29 15:59, ломающее изменение (заголовок коммита с восклицательным знаком). Мотивация — дать AMX явное, типизированное объявление операторов, по которому агент может сопоставлять и оценивать из одного и того же описания вычисления. Сделано путём описания 24 семейств runtime-операторов AMX как 39 статически зарегистрированных версий контрактов с доменами параметров, шаблонами операндов и раскладок, наборами побочных эффектов и целевыми возможностями M1–M4; добавлены оценщик на Python, эталонный симулятор на чистом C в качестве золотого стандарта, а также 59 репрезентативных атомарных случаев, покрывающих все 39 статических операторов, случаи высокоуровневого и среднеуровневого промежуточного представления прогоняются на реальных доменах в 2, 4, 8, 12 потоков и проверяют принятие и отклонение кандидатов; кандидаты высокого уровня обнаруживаются из объявлений сопоставления внутри оператора, сохраняется вывод возможностей для цели. Именование унифицировано в пространстве имён AMX, псевдонимы хранятся на точке входа регистрации, зарегистрированное имя выдаётся единым запросом; выполнение на CPU использует топологию потоков, приватное логическое состояние регистров AMX, число потоков не равно числу движков AMX. Верификация: 46 сфокусированных тестов пройдено, включая одно сравнение с 57 результатами чистого C и две проверки жизненного цикла.

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

3.4 Адоптеры: TileKernels и FlashQLA без пушей в основную ветку в окне мониторинга (10-29)

Основные ветки обоих известных адоптеров остановились на 10-14, новых пушей в окне нет: репозиторий операторов DeepSeek (2018 звёзд) и FlashQLA со стороны Tongyi (742 звезды). Новые сигналы экосистемы за этот день исходят в основном от репозиториев, созданных сообществом, а не от этих двух внутренних потребителей.

Источник: https://github.com/deepseek-ai/TileKernels

Источник: https://github.com/QwenLM/FlashQLA

3.5 На стороне Ascend появился независимый репозиторий операторов сообщества ops-tilelang, в окне есть пуши (10-29)

Репозиторий создан 10-20, пуш 10-29 13:06, позиционируется как репозиторий высокопроизводительных операторов сообщества для NPU Ascend, единообразно управляет реализациями ядер, автоматизированными тестовыми случаями, стандартными рабочими нагрузками и базовыми показателями производительности, цель — сделать операторные активы переиспользуемыми, проверяемыми и устойчиво развивающимися. Он находится под именем организации форка экосистемы Ascend, а не в организации tile-ai, что указывает на то, что поставка операторов на стороне Ascend выходит за пределы официального репозитория, образуя слой сообщества; связь с официальным tilelang-ascend пока не ясна, при включении рассматривается только как наблюдение за экосистемой, а не как официальное действие.

Источник: https://github.com/Atlas-Ascend-Fork/ops-tilelang

3.6 Активны два сопутствующих репозитория PTO-ISA: репозиторий задач мигрирован на PTOAS 0.70, в эталонный репозиторий добавлены блочное масштабирование SV2 и постатейный анализ (10-29)

В обоих сопутствующих репозиториях организации PTO-ISA в окне есть коммиты. Репозиторий задач перенёс широковещательную загрузку PTO на PTOAS 0.70, ранее на этой неделе шло уточнение знака квантования-масштабирования и переписывание формулировки задачи «указывать на собственное решение, а не на ответ»; в эталонный репозиторий добавлены две аналитические фиксации: блочное масштабирование и постатейный анализ SV2, а также одно обоснование (число вариантов инструкции абсолютного максимума в библиотеке равно 31.39, с приложением анализа пропускной способности инструкций во время выполнения и roof-line анализа, явно не единая буферная метрика). Отношение этих двух репозиториев к официальному — учебно-измерительное сопровождение, заслуживает внимания как косвенное свидетельство методологии на стороне Ascend.

Источник: https://github.com/PTO-ISA/tilelang-puzzles-ascend

Источник: https://github.com/PTO-ISA/tilelangGym

3.7 Наблюдение: в форк-репозитории tilelang под именем T-HEAD в окне есть пуши, имена веток указывают на раскладку матричных инструкций PPU (10-29)

У организации T-HEAD (официальный сайт — домен портала разработчиков) есть форк-репозиторий tilelang, созданный 2026-09-22, являющийся форком основного вышестоящего репозитория; публично доступны 13 веток — помимо основной ветки и зеркал версий с v0.1.11 по v0.1.14, видны ветки исправления общего layout матриц PPU, пакета PPU language, функций компиляции во время выполнения и несколько веток исправления дефектов; последний коммит основной ветки этого репозитория датирован 10-22, но время пуша репозитория обновлено до 10-29 19:27 (пекинское время). В репозитории нет ни документации, ни записей о релизах, поэтому он может служить лишь observationalной зацепкой: некая полноценная команда ведёт разработку в ветках, используя TileLang как основу собственного аппаратного стека, в направлении, связанном с layout матричных инструкций PPU. Именно из исходников этого репозитория собрано воспроизведение отчёта о дефекте #3705 за сегодня.

Источник: https://github.com/t-head/tilelang-for-sail

4. Сообщество, обучающие материалы и мероприятия

4.1 Документационный сайт вносит границы применимости встроенного сокращения (reduce) на страницу инструкций синхронно с вливанием redux (10-29)

В окне мониторинга документационного сайта произошло пять автоматических обновлений, среди которых на страницу инструкций добавлен абзац с пояснением о сокращении, согласующийся с сегодняшним вливанием переработки аппаратного сокращения: межпоточное сокращение CUDA передаёт полные warp-группы, выровненные по warp с единичным шагом потоков, помощнику, имеющему тот же источник, что и warp-сокращение; помощник на целочисленном суммировании, максимуме, минимуме и побитовых операциях для SM80 и выше выбирает аппаратные инструкции сокращения, а более узкие целые повышает до 32 бит; скалярные FP32 максимум и минимум используются только на sm_100a, sm_100f и sm_103a, sm_103f, скалярные FP16 и BF16 повышаются до FP32; то же правило применимо к последнему сегменту более крупного сокращения и к неупакованному пакетному сокращению. Для под-warp, шаговых, упакованных, FP64, а также неподдерживаемых комбинаций типов и операторов сохраняется реализация через shuffle; обмен через разделяемую память между warp и барьеры не меняются. Внесение границ отката в документацию полезнее для пользователей, чем просто запись «поддерживается аппаратное сокращение».

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

4.2 Репозиторий инструментов разработки завершает три финальных коммита после выноса сквозной трассировки, в том же направлении, что и рассматриваемое вышестоящее изменение по инструментализации (10-29)

После завершения 10-20 выноса сквозной трассировки из основного репозитория в окне мониторинга добавлены три финальных коммита: предотвращение циклического импорта при активации трассировки, закрепление CI на версии с поддержкой плагинов инструментирования, инициализация TileLang перед загрузкой совместимых псевдонимов ядра. Это совпадает по направлению с рассматриваемым вышестоящим изменением «вынести сквозную трассировку в репозиторий инструментов разработки», что показывает: инструментализация уже не просто экспериментальная ветка вышестоящего репозитория, а сформировавшийся независимо публикуемый пакет.

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

4.3 Новый репозиторий tilelang-knowledge за один день: 33 кейса проектирования операторов, 20 карточек знаний с источниками, 7 паттернов оптимизации (10-29)

Репозиторий создан 10-29, четыре коммита за день образуют базу знаний, ориентированную на интеллектуальных агентов: сначала структура репозитория, затем упорядочивание 33 кейсов проектирования операторов (каждый с фиксированным источником), затем дополнение 20 карточек знаний по программированию с источниками, и наконец документирование 7 паттернов оптимизации GPU с доказательной базой. Заявленное назначение репозитория — дать агенту возможность при столкновении с оператором определить, какой опыт применим, как следует изменить код, как проверить, и куда искать после неудачи. Это тот же класс попыток, что контракты операторов TileFoundry и навык профилирования из репозитория Ascend: записать «как менять, как проверять» в виде индексируемых активов.

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

4.4 Репозиторий к курсу с иллюстрациями и репозиторий экспериментов с распределённым layout созданы в один день (10-29)

Два личных репозитория созданы в один день: репозиторий к курсу с иллюстрациями, в описании которого заявлено, что каждый пункт знаний раскрывается через оригинальные сценарии и анимацию и публикуется вместе с видео; и репозиторий экспериментов с распределённым layout, с сообщением коммита о добавлении экспериментов с распределённым layout TileLang. Вместе с репозиторием переноса моделей и репозиторием бэкенда Hexagon, куда сегодня был пуш (время пуша обновлено до 10-30 06:10, последний коммит основной ветки — всё ещё обновление зависимостей от 08-24), самодеятельные вложения сообщества продолжаются в двух направлениях: образование и диалектные бэкенды.

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

Источник: https://github.com/Leewin239/tilelang-distributed-layout

4.5 Со стороны новостей: шесть групп запросов Google News на китайском и английском, Hacker News и arXiv — существенных попаданий в окне нет (10-29)

Шесть групп запросов охватывают точные термины плюс два дня, китайский плюс Ascend, китайский плюс оператор, название организации плюс два дня, английский плюс GPU и китайский плюс компилятор плюс семь дней. Только запрос «китайский плюс Ascend» вернул одну запись — перепечатку о прогрессе клинического искусственного интеллекта, не связанную с языком операторов, остальные вернули пусто. Все релевантные попадания Hacker News за последние четыре дня оказались вне окна (ближайшее — перепечатка обсуждения стека программирования Ascend от 10-02). arXiv по запросу TileLang новых статей не дал. Новостная сторона несколько дней подряд показывает ноль попаданий, основная часть ежедневного отчёта продолжает опираться на репозитории и экосистемные репозитории.

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

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

Ритм на стороне Ascend уже сместился с «переноса бэкенда» на «дополнение операторов». Вчера было зафиксировано, что бэкенд NPUIR влит в основную ветку, а критерием приёмки стали 504 самотеста и 71 из 72 примеров; сегодня из пяти влитых коммитов четыре — это операторы и примеры, причём выстроены они по потребностям вышестоящих моделей: сжатие indexer для GLM-5.3, скалярное произведение для блочно-гейтированного внимания, матричное умножение с четырёхбитным квантованием, глубокая свёртка для квантованной визуальной модели. Общее у этих операторов то, что квантование и слияние записаны в само ядро kernel (чисто целочисленное кодирование E4M3, соглашение об упаковке четырёх бит, двойной kernel плюс быстрый путь 1 умножение на 1), а не оставлены на исправление на стороне хоста. Одновременно два коммита попутно закладывают инженерные нормы: профилирование производительности операторов включается в процесс, а нестабильные тестовые случаи, вызванные параллельными пакетами, переводятся на тестовый канал с ведением списка. Это показывает, что основное противоречие на стороне Ascend смещается от «можно ли это скомпилировать» к «можно ли стабильно принять численные результаты и производительность операторов».

Три сегодняшних коммита в основном репозитории (аппаратная редукция, параллельная компиляция, группировка копирования с выходом за границы) соответствуют выбору инструкций, задержке компиляции и качеству выдачи — всё это проблемы ядра компилятора, а не особенности языкового уровня. Это согласуется с вчерашним направлением новых дефектов: границы статических проверок вроде выхода за границы, алиасов и разрядности открываются одна за другой. Из трёх сегодняшних новых дефектов два (пакетное копирование с буфером заполнения, переполнение разрядности представления) срабатывают на реальных формах моделей, что говорит о том, что область использования TileLang уже доросла до масштабов, на которых встречаются граничные условия: веса NVFP4 размером 248320 на 5120, размерность голов внимания, где K не кратно 16.

Самое примечательное на стороне экосистемы сегодня — это «форкизация». В сообществе Ascend появился независимый репозиторий операторов, под именем T-HEAD есть форк TileLang с веткой PPU, PTO-ISA оформил и банк задач, и бенчмарки как сопутствующие репозитории, а ещё один репозиторий инструментов разработки выделил трассировку понижения в отдельный пакет. Общая предпосылка этих действий — отношение к TileLang как к основанию собственного аппаратного стека: нужно менять раскладку под свой набор инструкций, проводить приёмку по своей тестовой системе, накапливать опыт в своей форме знаний. Для предметно-ориентированного языка это более весомый сигнал принятия, чем число звёзд, но это также означает, что вышестоящему проекту предстоит столкнуться с долгосрочными издержками «как синхронизировать ветки с вышестоящей веткой»: сегодняшний дефект #3705 — как раз то, во что пользователи веток упираются первыми при реальной сборке.

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

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

Источник Результат проверки
Организация GitHub tile-ai по репозиториям (tilelang / TileOPs / TileFoundry / tilelang-ascend / tilelang-mlir-ascend / tilelang-hygon / tilelang-metax / tilelang-musa / TileRT / tilescale / DeepStack / сайт документации / ночное зеркало) В окне мониторинга есть отправки: tilelang, TileOPs, TileFoundry, tilelang-ascend, tilelang-hygon, tilelang.github.io, TileOPs.github.io, TileOPs-nightly; в tilelang-metax (10-26), tilelang-musa (09-30), TileRT, tilescale, DeepStack, tilelang-puzzles коммитов в основную ветку в окне мониторинга нет
Поиск влитых изменений (is:pr is:merged) 12: tilelang 5, tilelang-ascend 5, TileFoundry 1, TileOPs 1
Поиск изменений на рассмотрении (is:pr is:open updated) 54, включая пакет проверки документации Ascend, три исправления представлений NPUIR и изменение планирования GEMM в TileOPs
Проверка новых issue 4: три дефекта #3704, #3705, #3707, ещё 1 — уведомление о сбое ежедневного тестового робота в репозитории Ascend
Проверка на уровне коммитов в основную ветку tilelang 5, tilelang-ascend 5, TileOPs 1, TileFoundry 1, сайт документации 5; в tilelang число совпадает с числом влитых в оба репозитория
Страница релизов и теги tilelang последняя по-прежнему v0.1.15 (выпущена 09-30), новых версий в окне мониторинга нет; TileOPs последняя v0.1.0 (10-27); TileFoundry последняя 0.0.4rc1 (10-25); tilelang-ascend последняя v0.1.2.000 (09-09)
Сторонние репозитории и репозитории экосистемы Проверены по одному 10 репозиториев: репозиторий операторов сообщества Ascend, два репозитория PTO-ISA, репозиторий инструментов разработки, репозиторий знаний, репозиторий иллюстрированного курса, репозиторий распределённой раскладки, репозиторий слитых операторов DCU, репозиторий переноса моделей, репозиторий бэкенда Hexagon, форк T-HEAD — во всех есть отправки в окне мониторинга (в основной ветке Hexagon новых коммитов нет, обновилось только время отправки в репозиторий)
Пользователи Основные ветки TileKernels и FlashQLA остановились на 10-14, в окне мониторинга отправок нет
Google News (шесть групп на китайском и английском) Только одна перепечатка на китайском о клиническом искусственном интеллекте с добавлением Ascend, к теме не относится, не включена
Hacker News Все релевантные попадания за последние четыре дня оказались вне окна мониторинга
arXiv По запросу TileLang новых статей нет

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