Окно мониторинга: 2026-10-30 04:30 ~ 2026-11-02 04:30 (пекинское время, последние 3 дня, включая субботу и воскресенье; стыкуется с предыдущей точкой отсечения 10-30 04:30).

Источники: сплошная проверка всех репозиториев организаций GitHub (RuyiAI-Stack, ruyisdk, openRuyi-Project, buddy-compiler, по репозиториям сверены коммиты, PR и Release в окне; вышестоящие fork отфильтрованы по ключевым словам RISC-V / RVV / XuanTie, с использованием интерфейса сравнения коммитов для различения воспроизведений и новых добавлений), статистика коммитов и слияний PR в openRuyi, Release и теги пакетного менеджера ruyi и ruyi-imager, форум сообщества разработчиков RuyiSDK, архив ежедневной разведки ruyiai-daily, три страницы снимков официального сайта RuyiAI, страница новостей дистрибутива openRuyi, целевые запросы Google News RSS на китайском и английском (через прокси).

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

  • Главное за сегодня: выпущен официальный релиз Buddy Compiler 0.1.3, из шестнадцати коммитов десять посвящены масштабируемой векторизации RVV, в примечаниях к релизу указан только серверный ABI (10-31)
    1. Прогресс стека RuyiAI (адаптация PyTorch / Triton / TileLang для RISC-V)
      • 1.1 pytorch: вторая полная перезапись ветки riscv ранним утром 11-01, базовая точка по-прежнему на 3afdbd3 (11-01)
      • 1.2 llvm-project: перезапись ветки riscv поздним вечером 11-01, в списке понижение IME/AME для A100 (11-01)
      • 1.3 triton-riscv: два слияния, пять новых открытых, ещё один ребейз на официальный Triton v3.8.0 (10-30 по 11-01)
      • 1.4 tilelang-riscv: семнадцатый день тишины в основной ветке, остался только один открытый PR (статус на 11-01)
    1. Инструментальная цепочка и дистрибутивы RuyiSDK
      • 2.1 openRuyi: все шесть коммитов пришлись на 10-30, влиты обновления безопасности LLVM 23 и ollama (10-30)
      • 2.2 openRuyi на рассмотрении: партия из тринадцати коммитов зависимостей Prometheus, в очередь добавлены box64 и firecracker (10-30 по 11-01)
      • 2.3 Три комплекта Ruyiai #1350: вторая неделя по-прежнему застряла на спецификации spec, одно обновление 10-30 (статус на 10-30)
      • 2.4 ruyi 0.54.0: обещанный конец октября не состоялся, в основную ветку влит только один коммит документации (10-30)
      • 2.5 openRuyi 2026.10 не выпущен, в месячном ритме релизов образовался пробел (статус на 11-02)
    1. Векторные расширения и оптимизация операторов (VecIntrinBench / IntrinTrans / FBGEMM)
      • 3.1 Все три векторных репозитория в этом выпуске молчат, последние коммиты остановились на 02-13, 06-25, 07-13 соответственно
      • 3.2 Фронт работ по операторам целиком сместился на путь понижения в triton-riscv (10-31 по 11-01)
      • 3.3 Основная линия производительности #85 остановилась на 10-18, контрастируя с ритмом пяти коммитов пути понижения
    1. Динамика Buddy Compiler
      • 4.1 BUDDY MLIR 0.1.3: шестнадцать коммитов, сто тридцать шесть файлов, в описании указан только пункт ABI (10-31)
      • 4.2 Ночные сборки и нижестоящие якоря: задержка в три перехода замкнулась за два дня, якорь по-прежнему на ночной сборке (10-31)
      • 4.3 Три коммита на рассмотрении не вошли в 0.1.3, Whisper и выравнивание интерфейсов остаются подвешенными (статус на 10-31)
    1. Сообщество, мероприятия и официальный сайт
      • 5.1 Три страницы официального сайта без изменений, две записи в блоге, двадцать три главы документации (статус на 11-02)
      • 5.2 В окне на форуме нет новых постов, двухнедельный выпуск прогресса 080 не вышел (статус на 11-02)
      • 5.3 ruyiai-daily два выпуска, разведывательная сводка охватывает PyTorch, Triton и KV-кэш (10-31, 11-01)
      • 5.4 Внешние новости — ноль совпадений, два месячных обещания на стороне дистрибутива одновременно истекли (статус на 11-02)
    1. Наблюдения за трендами
      • 6.1 Описание официального релиза расходится с разницей кода, прогресс RISC-V спрятан в истории коммитов
      • 6.2 triton-riscv переходит от «чинить по одному и сливать по одному» к «пакетной подаче на ревью», сторона приёмки по-прежнему отсутствует
      • 6.3 Месячные обещания на стороне дистрибутива снова не выполнены, пакетирование на уровне стека по-прежнему переделывается на уровне spec

Главное за сегодня: выпущен официальный релиз Buddy Compiler 0.1.3, из шестнадцати коммитов десять посвящены масштабируемой векторизации RVV, в примечаниях к релизу указан только серверный ABI (10-31)

Дата: 2026-10-31　Источники: BUDDY MLIR 0.1.3, разница коммитов между v0.1.2 и v0.1.3, PR #999 rvv-vlen, PR #1003 выбор ширины масштабируемого вектора

01.11 в 07:01 (пекинское время) buddy-mlir выпустил релиз 0.1.3; предыдущим релизом был 0.1.2 от 25.10, между ними прошло пять ночных сборок. В примечаниях к релизу раскрыт только один пункт: новый ABI buddy-server (#1015), то есть сведение отдельного набора дескрипторов плагинов моделей, написанных для каждой модальности, в единый интерфейс, плюс единые пути загрузки, запроса состояния, вызова, потоковой передачи и отмены.

Однако если выгрузить разницу коммитов между v0.1.2 и v0.1.3, в этой версии фактически содержится шестнадцать коммитов и сто тридцать шесть файлов, из которых десять — целый блок работ по векторизации RISC-V в разделе [midend][VIR]:

  • #999 вводит (rvv-vlen), делая масштабируемую длину вектора атрибутом цели векторизации;
  • #1000 подсчитывает количество активных векторов во вложенных циклах как входные данные для выбора ширины вектора;
  • #1002 заставляет циклы масштабируемого strip-mining шагать по vscale;
  • #1003 выбирает ширину масштабируемого вектора для RVV;
  • #1004 понижает set_vl с результатом до масштабируемого вектора;
  • #1005 обрабатывает случай многомерных динамических векторов с результатом в set_vl;
  • #1006 добавляет построчный vir.shuffle для динамических векторов;
  • #1007 унифицирует соглашения об индексах для vir.load / vir.store;
  • #1008 автоматически выводит ширину индексного вектора;
  • #996 добавляет vir.from_vector и сокращает переассоциацию.

Есть ещё два коммита, относящихся к линии VIR, но не под префиксом [midend]: реализация диалекта VIR для decode attention ([frontend][tools]) и Python-привязки для VIR (#1009). То есть из шестнадцати коммитов двенадцать затрагивают уровень векторного диалекта, а в примечаниях к релизу нет ни слова о RISC-V или RVV.

Этот разрыв стоит зафиксировать, потому что он меняет ответ на вопрос «где находится прогресс RISC-V в этом стеке». В предыдущих выпусках вывод был таков: работа buddy-mlir по RISC-V идёт в основном через ночные сборки, релизы заняты универсальными работами вроде рефакторинга ABI, и нижестоящим проектам, чтобы получить изменения RVV, приходится привязываться к ночным тегам. 0.1.3 доказывает, что этот вывод верен лишь наполовину — релиз действительно вобрал в себя блок RVV, но примечания к версии не были обновлены вслед за этим, и те, кто смотрит на страницу релиза, подумают, что 0.1.3 — это лишь рефакторинг серверной части, тогда как на деле получена версия со значительно продвинувшимися возможностями масштабируемой векторизации.

Непосредственное следствие для нижестоящих проектов: triton-riscv 31.10 в 13:15 поднял якорь зависимости до nightly/v0.1.3.dev20261030 (PR #91); дата этой ночной сборки раньше времени сборки релиза 0.1.3, но их содержимое однородно (0.1.3 отпочкован от головы основной ветки 29.10), поэтому те десять коммитов RVV уже действуют в нижестоящем проекте; реально не поспевает за изменениями то, что «якорь по-прежнему указывает на ночной тег» — при текущем ритме renovate переход на release/v0.1.3 потребует ещё одного круга ожидания.

Нужно проявить сдержанность в отношении охвата: эти десять коммитов сосредоточены на масштабируемой векторизации диалекта VIR, то есть на цепочке понижения от set_vl до scalable vector, а не на сквозных данных о производительности моделей; в примечаниях к релизу также не приведено ни одного бенчмарка. Продвижение возможностей векторизации поддаётся проверке, а на вопрос, насколько быстро это работает, в этом выпуске ответа нет.

1. Прогресс стека RuyiAI (адаптация PyTorch / Triton / TileLang к RISC-V)

1.1 pytorch: вторая полная переигровка ветки riscv ранним утром 01.11, базовая линия по-прежнему на 3afdbd3 (01.11)

Дата: 2026-11-01　Источники: ветка riscv в pytorch, PR #51 локальный образ riscv64, PR #44 исправление bytes_to_scalar, список открытых PR

01-01 03:00 ветка riscv подверглась полному перебазированию: время коммитов двадцати коммитов в ветке было унифицированно перезаписано в интервал с 03:00:26 по 03:00:27 (в пределах двух секунд), при этом авторское время всех коммитов осталось без изменений. Головной коммит — 1867c9b8, сообщение по-прежнему [SyncBots] Integrate PyTorch at 3afdbd3, а авторское время самого этого синхронизирующего коммита — 10-29 12:48, то есть данное перебазирование не сменило базовую линию: ветка по-прежнему стоит на upstream 3afdbd3, совпадая с точкой, на которую пришлось перебазирование 10-29.

По сравнению с перебазированием 10-29 различие только в форме: в прошлом выпуске это было «перебазирование после семидневного молчания + синхронизирующий бот добавил один коммит с исправлением кэша зависимостей», в этом выпуске — «ещё одно перебазирование через три дня, содержание не изменилось». Набор патчей в ветке также не изменился: по-прежнему Add riscv64 image locally (#51), Fix Bytes_to_scalar for float/complex on RISC-V (#44), Scope linear cross entropy ULP tolerance to RISC-V (#42), inductor opinfo blocklist (#50), а также более ранние изменения CI и допусков тестов.

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

Обратить внимание следует по-прежнему на то рассогласование: python-torch-ruyiai на стороне дистрибуции (openRuyi #1352) собирается из артефактов ветки, а головной коммит ветки при каждом перебазировании меняет SHA, поэтому зафиксированная в пакете точка источника должна заново выравниваться; в этом выпуске действий по выравниванию не наблюдалось.

1.2 llvm-project: перебазирование ветки riscv поздно вечером 11-01, в списке понижение IME/AME для A100 (11-01)

Дата: 2026-11-01　Источники: ветка riscv llvm-project, RISCV_CONTRIBUTING.md, рабочий процесс перебазирования

11-01 23:00 ветка riscv также подверглась полному перебазированию: время коммитов двадцати шести собственных коммитов ветки было унифицированно перезаписано в интервал с 23:00:22 по 23:00:26. Головной коммит — afdd0982, его содержание — [workflows] Push rebased PRs directly and document contribution options (авторское время 10-29 01:59), то есть отмеченное в прошлом выпуске изменение «отмена предварительного прогона, добавление руководства по контрибуции» — оно по-прежнему является головным коммитом ветки, и в этом выпуске поверх него ничего более нового не появилось.

Наиболее релевантными для данного стека в ветке остаются те два коммита для A100: [RISCV] Lower IME intrinsics to SpacemiT A100 dot instructions (#30) и [RISCV] Add A100 HP/SP and pack/unpack lowering with calibrated scheduling (#31). Первый понижает встроенные функции IME до инструкций точечного произведения A100, второй добавляет понижение pack/unpack для двух форм точности HP/SP вместе с калиброванной моделью планирования; уровнем ниже — [AME] Update BOSC AME instructions (#29) и [RISCV] Update xtame design (#27), образующие полную цепочку «проектный документ AME → определение инструкций → встроенные функции → понижение и планирование». Эта цепочка обслуживает матричное расширение и является точкой опоры нарратива RuyiAI «от RVV к Matrix» на стороне компилятора.

Одно несоответствие, требующее проверки в следующем выпуске: авторское время последнего коммита [SyncBots] Integrate LLVM at b3b5e33 в ветке остановилось на 09-29, но при сравнении коммитов текущего головного коммита с головным коммитом прошлого выпуска возвращаемый набор различий содержит upstream-коммиты от 10-30 (например, [clang][AST] Don't give NestedNameSpecifier pointer identity in DynTypedNode (#233153), [libc] Add truncation casts to avoid warnings in file_test.cpp (#237262)). У этого есть только одно объяснение: данное перебазирование одновременно с перезаписью истории сдвинуло базовую линию upstream вперёд, а запись синхронизирующего бота не добавила вслед за этим новую строку. Расхождение между записью синхронизации и фактической базовой линией приводит к тому, что суждения вроде «на каком upstream основана эта ветка» можно вывести только обратным образом через интерфейс сравнения; рекомендуется в дальнейшем добавить в ветку явное описание базовой линии.

1.3 triton-riscv: два слияния, пять новых PR и один ребейз на официальный Triton v3.8.0 (30.10–01.11)

Дата: 30.10.2026 – 01.11.2026　Источники: PR #55 патч фронтенда asin, PR #91 обновление зависимостей, PR #92 ребейз на Triton v3.8.0, список коммитов

В основную ветку за окно мониторинга слито два коммита, оба в выходные. 30.10 в 20:14 слит [patches] Support asin op via frontend patch (#55) — это подключение оператора asin через патч фронтенда в обход ограничения бэкенда, не поддерживающего обратные тригонометрические функции, типичный приём «одна перезапись фронтенда — один доступный оператор». 31.10 в 13:15 renovate-коммит #91 поднял зависимость buddy-mlir с nightly/v0.1.3.dev20261029 до dev20261030. После этого новых коммитов кода в основной ветке не было.

Настоящие изменения — в очереди PR. maochuanjun с 31.10 15:20 по 01.11 17:36 открыл подряд пять PR, все в слоях понижения и анализа:

  • #93 [Conversion] Preserve scalar load/store masks (31.10 15:20) — сохранение масок скалярных обращений к памяти;
  • #94 [Analysis] Preserve lane offsets in mixed pointers (31.10 21:57) — сохранение смещений lane в смешанных указателях;
  • #95 [Conversion] Lower tensor gathers (31.10 23:41) — понижение тензорных gather;
  • #96 [Analysis] Preserve incomplete tensor masks (01.11 17:29) — сохранение масок неполных тензоров;
  • #97 [Conversion] Handle stacked zero strides (01.11 17:36) — обработка уложенных нулевых шагов (strides).

Заголовки пяти PR выстроены очень стройно: три Conversion, два Analysis, и все формулируются как «сохранить определённый тип информации без потерь». Это продолжение того же семейства проблем, что и три исправления от 29.10 (заполнение тензоров, смещения, переносимые циклом, тест скаттера) — путь понижения при переводе Triton IR в структурированную/неструктурированную форму раз за разом теряет граничную информацию вроде масок, смещений и шагов, и на каждую потерю приходится добавлять отдельный PR.

Есть один PR другого направления: #92 [triton] Rebase integration onto the official Triton v3.8.0 release (jason-hue, обновлён 31.10 в 12:57). Это не исправление дефекта, а перенос всей интеграции RISC-V на официальный Triton 3.8.0. Прежняя базовая линия интеграции в этом репозитории остановилась на [triton] Update integration for latest upstream (#76) (02.09), и два месяца посередине делались только патчи без ребейза; как только #92 будет слит, точки приземления последующих пяти PR придётся сдвинуть ещё раз. Это же объясняет, почему #92 и #93–#97 одновременно находятся в очереди и не объединены в одну серию — ребейз является предварительным действием, его пока не трогают.

1.4 tilelang-riscv: семнадцатый день тишины в основной ветке, остался один открытый PR (состояние на 01.11)

Дата: 01.11.2026 (состояние)　Источники: список коммитов tilelang-riscv, открытый PR #4

Последний коммит в основной ветке по-прежнему от 16.10 в 10:52 — «Build Python extension in Buddy CI», семнадцатый день подряд без коммитов. Открытых PR стало на один меньше: остался только #4 «RVV vector mask and max reduction lowering» (замер с 28.09); прежний #2 «Add Codex-compatible RISC-V operator workflow» уже не числится в списке открытых.

В той же организации, в том же окне triton-riscv за три дня влил два коммита и открыл пять, а в tilelang-riscv — ни одного. Такое расхождение длится уже три недели, и объяснять его «на выходных никого нет» больше нельзя. Извне виден только один альтернативный путь: спецификация python-tilelang-ruyiai в openRuyi (в составе трио #1350), то есть замена итераций в репозитории артефактами дистрибутива, — но сам #1350 всё ещё застрял на ревью. Оба пути стоят одновременно, а значит, у этого компонента в текущем периоде нет никакого направления движения.

2. Инструментальная цепочка и дистрибутив RuyiSDK

2.1 openRuyi: все шесть коммитов пришлись на 10-30, влиты LLVM 23 и обновление безопасности ollama (10-30)

Дата: 2026-10-30　Источники: PR #1424 LLVM 23, PR #1514 обновление безопасности ollama, PR #1545 clang-wrap, список коммитов основного репозитория

Все шесть коммитов окна сосредоточены в один день 10-30, после чего за все выходные — ноль коммитов. Влиты три PR:

11:20 влит #1424, добавлен пакет llvm23 версии 23.1.4. LLVM 23 вводится как сосуществующий пакет, а не через подъём всей цепочки по умолчанию — для дистрибутива это малозатратный по риску подход: проекты, которым нужна новая версия, явно зависят от llvm23, остальные остаются на прежней по умолчанию, и один большой скачок версии не тянет за собой всю поверхность сборки. Для стороны RISC-V смысл в опциональности версии инструментальной цепочки — раньше, чтобы протестировать новый бэкенд LLVM, приходилось собирать его самому.

12:39 влит #1514, ollama обновлён до 0.40.7 и помечен security-fixes. В прошлом выпуске этот коммит ещё висел в очереди на рассмотрении (на момент написания +259/−3371, удалялся каталог vendor), в этом выпуске он влит, а значит, та партия исправлений безопасности уже в основной ветке. В ту же минуту прошли ещё три коммита в экосистеме go: go-github-tree-sitter-cpp, go-github-tree-sitter-go-tree-sitter, go-github-mattn-go-pointer — все дополняют замыкание зависимостей существующих пакетов.

17:39 влит #1545, clang-wrap обновлён до 20261030. Этот пакет держит тот же дневной ритм, что и upstream, уже несколько выпусков подряд и остаётся одной из немногих спецификаций дистрибутива, где «каждый день что-то происходит».

Ни один из шести коммитов напрямую не трогает трио RuyiAI, то есть на стороне дистрибутива в этом периоде занимались «сдвигом фундамента вперёд», а не «установкой стека внутрь».

2.2 openRuyi на рассмотрении: тринадцать коммитов партии зависимостей Prometheus, в очередь добавлены box64 и firecracker (10-30 — 11-01)

Дата: 2026-10-30 — 2026-11-01　Источники: PR #1561 box64, PR #1559 firecracker, PR #1516 qemu-rustsbi, PR #1562 отслеживание тестов binutils RISC-V, PR #1547–#1557 партия Prometheus

В открытой очереди за окно двадцать четыре обновления — масштаб больше, чем в прошлом выпуске, и структурные особенности тоже заметны:

Самая крупная группа — партия модульных зависимостей Prometheus v3.13, всего тринадцать коммитов (#1540, #1441, #1547–#1557), все поданы одним автором партиями в порядке DAG, с единым заголовком «Add Prometheus v3.13 modules - DAG dependency batch NN». Такой подход — «разрезать один граф зависимостей на десяток с лишним коммитов по слоям» — в дистрибутивах обычно вынужденная мера: единый коммит ревьюеры попросят разбить, а разбиение по слоям позволяет независимо собрать и проверить каждый коммит. Цена — растянутое окно вливания: если застрянет любой слой, всё, что за ним, не войдёт.

Второй кластер — виртуализация и бинарная трансляция: #1561 добавляет box64 (динамический рекомпилятор для запуска программ x86-64 на RISC-V), #1559 добавляет firecracker (лёгкая микровиртуальная машина), #1516 добавляет qemu-rustsbi (отправлено автором RustSBI luojia65, уже есть пять обсуждений). Если сложить эти три вместе, они указывают на одну и ту же потребность — запуск не-native программ и изолированных нагрузок на рабочем столе RISC-V.

Третья категория — элементы обслуживания, напрямую связанные с RISC-V: #1562 binutils: Track RISC-V pr19719 test failures, регистрирует известный сбой теста, связанный с RISC-V, в binutils как элемент отслеживания, а не исправляет его напрямую. В контексте дистрибутива такая практика означает «сборка проходит, тесты не все зелёные», что является полезной информацией для тех, кто ниже по потоку использует binutils для линковки.

Остальные — три обычных обновления версий: #1563 поднимает Node.js до 26.13.0 и переключается на системные библиотеки, #1544 поднимает firefox до 159, #1421 включает для qemu ряд возможностей, используемых в GUI-тестах.

2.3 Триплет Ruyiai #1350: на второй неделе всё ещё застревает на спецификации spec, 10-30 было одно обновление (статус на 10-30)

Дата: 2026-10-30 (статус)　Источники: PR #1350 Add Ruyiai packages, PR #1352 python-torch-ruyiai

#1350 (триплет buddy-mlir, python-triton-ruyiai, python-tilelang-ruyiai) имел одно обновление 10-30 в 16:16, всё ещё не слит, в таймлайне появилась ещё одна запись от 10-30. Все восемнадцать замечаний ревью, зафиксированных в прошлом выпуске, указывали на написание spec — между BuildOption не нужно вставлять пустые строки, отсутствует BuildRequires: python3dist(wheel), Provides должны совпадать с фактическими именами пакетов, патчи нужно генерировать через git format-patch, пустой %check нужно снабдить комментарием — в этом выпуске новых принципиальных спорных моментов не появилось.

С момента открытия 09-21 этот PR уже перешагнул шестую неделю. В прошлом выпуске это объяснялось тем, что «spec пишется с нуля, каждую нестандартную точку приходится объяснять»; в этом выпуске виден ещё один слой: в триплете buddy-mlir несёт в себе LLVM, triton зависит от исполняемого файла git, tilelang должен обнаруживать инструментальную цепочку buddy-mlir — эти три нестандартные точки поднимались в ревью по отдельности, но нет единого документа с соглашениями об упаковке, который собрал бы их вместе. В результате каждый раунд ревью приходится заново объяснять одну и ту же группу вопросов, и стоимость переработки ложится на переписку, а не на написание.

#1352 (python-torch-ruyiai) из той же партии в этом выпуске без движений, всё ещё стоит на 10-27. Он связан с тем же нерешённым вопросом, что и повтор ветки pytorch в 1.1: каждый повтор ветки меняет SHA, нужно ли менять место размещения источника в пакете — никто не дал заключения.

2.4 ruyi 0.54.0: обещание конца октября не выполнено, в основную ветку слит только один коммит с документацией (10-30)

Дата: 2026-10-30　Источники: PR #508 список именований производителей, теги ruyi, ruyi Releases

10-30 в 09:54 в основную ветку ruyi слит #508 «docs: update vendor naming list», в документацию именований производителей добавлены четыре идентификатора: BananaPi, OrangePi, XiangShan, ZhiheComputing. Это выравнивание на стороне документации и замена в ruyi-imager интерфейсного «производитель» на «поставщик» — две стороны одного и того же дела, чтобы избежать расхождения в названиях в двух местах.

Помимо этого, статус 0.54.0 не изменился: в списке тегов после 0.54.0-alpha.20260918 новых тегов по-прежнему нет, последняя официальная версия — всё ещё 0.53.0 от 09-24, в основной ветке с 09-25, кроме этого коммита с документацией, коммитов нет. В выпуске 079 двухнедельного обзора было сказано: «из-за корректировки цикла релизов перенесено на конец октября»; сегодня 11-02, октябрь уже закончился, это обещание не выполнено, и нового обещания на смену не появилось.

Примечателен способ, которым оно не выполнено: это не провал релиза и не откат кандидата, а почти полное отсутствие кодовой активности во второй половине октября. #508 — это изменение документации, что означает, что в тот период конца октября в основной ветке было очень мало даже «подготовки к релизу». Это отличается от ритма перед 0.53.0 — тогда alpha, beta и официальная версия шли тремя последовательными шагами, а сейчас нет даже первого шага.

2.5 openRuyi 2026.10 не выпущен, в месячном ритме релизов появился пробел (статус на 11-02)

Дата: 2026-11-02 (статус)　Источник: страница новостей openRuyi, основной репозиторий openRuyi

Последняя публикация на странице новостей дистрибутива openRuyi по-прежнему «Релиз openRuyi 2026.09» (09-30), страница анонса релиза за октябрь 2026 возвращает 404. Даты релизов за предыдущие четыре месяца: 6-30, 7-23, 8-27, 9-30 — хотя они и не приходятся строго на один и тот же день, случая полного пропуска месяца ранее не было; октябрьский релиз по состоянию на 11-02 так и не появился.

Этот факт в сочетании с пунктом 2.4 образует наиболее примечательную группу фактов текущего выпуска: две линии конвейера, относящиеся к «дистрибуции экосистемы RuyiSDK» — менеджер пакетов ruyi и дистрибутив openRuyi — в конце одного и того же октября каждая пропустила своё публичное месячное обязательство, при этом кодовая часть обеих линий не выглядит застойной (в основном репозитории openRuyi 10-30 было ещё шесть коммитов, в ruyi было слияние документации). Это показывает, что узкое место не в разработке, а в самом релизе: заморозка версии, написание анонса, сборка зеркал и процесс публикации — этот участок последние два месяца не проходил по графику.

3. Векторные расширения и оптимизация операторов (VecIntrinBench / IntrinTrans / FBGEMM)

3.1 Все три векторных репозитория в этом выпуске молчат, последние коммиты остановились на 02-13, 06-25 и 07-13 соответственно

Дата: 2026-11-01 (статус)　Источник: VecIntrinBench, IntrinTrans, FBGEMM

Три репозитория организации на тему «векторов» в этом выпуске не имеют коммитов в окне мониторинга, а время их последних коммитов распределено по трём разным кварталам: VecIntrinBench остановился на 02-13, IntrinTrans — на 06-25, FBGEMM — на 07-13. Эти три проекта — соответственно бенчмарк векторных встроенных функций, трансляция встроенных функций и бэкенд квантованных операторов — изначально образовывали треугольник «что измерять, как транслировать, как реализовывать операторы».

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

3.2 Рабочий фронт операторов целиком переместился в путь понижения triton-riscv (10-31 — 11-01)

Дата: 2026-10-31 — 2026-11-01　Источник: PR #93, PR #94, PR #95, PR #96, PR #97

Поскольку все три специализированных репозитория остановлены, фактический рабочий фронт уровня операторов можно видеть только по очереди PR в triton-riscv. Пять новых PR текущего выпуска все посвящены «сохранению информации»; в разбивке по каждому это выглядит так:

#93 обрабатывает маски скалярных load/store — путь скалярного доступа к памяти при понижении легче всего теряет маску, принимая её за константную истину; если она потеряна, условные скалярные чтения и записи в структурированном IR становятся безусловными, и выход за границы не выдаёт ошибку, а читает грязные данные. #94 обрабатывает смещения lane в смешанных указателях, то есть случай, когда в выражении указателя есть и база, и посмещённое смещение по lane, а на этапе анализа сохраняется только база, а смещение трактуется как константа; #96 обрабатывает неполные тензорные маски, то есть семантику широковещания, когда форма маски меньше формы тензора; #97 обрабатывает накопленные нулевые шаги, то есть случай, когда несколько измерений имеют нулевой шаг и при понижении могут свернуться в одно измерение.

#95 — единственный, представляющий «новую возможность», а не «сохранение информации»: понижение тензорного gather. Ранее gather мог идти только по неструктурированному пути, в структурированном пути соответствующей реализации не было, и #95 восполняет этот пробел.

Общий фон всех пяти — одно и то же: корректность этого уровня выявляется «поднятием и запуском реальных операторов», а не регрессионными тестами. Накопленные за три недели восемь PR (три от 10-29 + пять текущего выпуска) все относятся к этой категории. Этот механизм эффективен, но дорог — на каждую партию поднятых операторов приходится чинить серию граничных случаев, а сила проверки после починки неоднородна (из трёх PR от 10-29 один прогнал полный набор lit из 291 пункта, один — только целевые регрессии, один — только один файл).

3.3 Основная линия производительности #85 остановилась на 10-18, что образует ритмический контраст с пятью PR пути понижения

Дата: 2026-10-18 (статус)　Источник: PR #85 оптимизация softmax и matmul

#85 «оптимизация softmax и matmul» не обновлялся с 10-18 23:55 и в этом выпуске остаётся на прежнем месте. Это единственный открытый PR в данном репозитории, явно нацеленный на производительность, и он составляет ясный контраст с пятью коммитами по пути деградации: в направлении корректности за неделю можно сделать пять коммитов, в направлении производительности за полмесяца нет движения.

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

4. Динамика Buddy Compiler

4.1 BUDDY MLIR 0.1.3: шестнадцать коммитов, сто тридцать шесть файлов — по существу написан только ABI (10-31)

Дата: 2026-10-31　Источник: BUDDY MLIR 0.1.3, разница коммитов v0.1.2…v0.1.3, PR #1015 новый ABI buddy-server, PR #1009 Python-привязки VIR

Разница коммитов 0.1.3 и содержание, уже разобранное в «ключевом за сегодня», взаимно подтверждают друг друга; здесь добавим три наблюдения, не вошедших в ключевое.

Во-первых, файловая поверхность этой версии больше числа коммитов: шестнадцать коммитов затронули 136 файлов, и значительная часть приходится на рефакторинг интерфейсов в #1015 (добавлены четыре заголовочных файла рантайма, удалены четыре группы дескрипторов плагинов, написанных по модальностям, и соответствующие юнит-тесты). То есть 0.1.3 одновременно вмещает две вещи — десять последовательных продвижений векторного диалекта и одну конвергенцию плагинной системы, охватившую более семидесяти файлов — во времени они перекрываются (десять коммитов VIR с 10-25 по 10-27, #1015 — 10-29), но на ревью шли раздельно.

Во-вторых, коммит [frontend][tools] Implement the decode attention in the VIR dialect легко упустить, но он указывает направление, отличное от предыдущей деградации VIR: реализация decode attention на диалекте VIR означает создание прямого пути от диалекта к векторизации для конкретной нагрузки «декодирование внимания». Это первый коммит, где VIR переходит от «универсального векторного диалекта» к «оптимизации под нагрузку».

В-третьих, Python-привязки VIR (#1009) означают, что этот диалект можно конструировать и проверять со стороны Python; непосредственная выгода для нижележащих проектов в том, что проекты вроде triton-riscv могут генерировать VIR на уровне Python для юнит-верификации, не проходя каждый раз полную цепочку компиляции.

4.2 Ночные сборки и нижележащий якорь: задержка в три перехода замкнулась за два дня, якорь по-прежнему на ночной сборке (10-31)

Дата: 2026-10-31　Источник: ночная сборка dev20261030, triton-riscv PR #91, список Releases

В прошлом выпуске была зафиксирована устойчивая структура задержки: слияние в buddy-mlir → ночная сборка на следующий день → renovate предлагает обновление зависимости → слияние в triton-riscv; три перехода обычно занимают один-два дня. В этом выпуске эта цепочка прошла полностью один раз, можно сверить фактическое время каждого шага:

#1015 слит в основную ветку 10-29 в 15:08; ночная сборка dev20261030 выпущена 10-30 в 08:49 (включает #1015); #91 от renovate слит в triton-riscv 10-31 в 13:15. От слияния до получения нижележащим проектом прошло ровно два дня и пять минут, что согласуется с оценкой «один-два дня».

Но форма якоря не изменилась: triton-riscv по-прежнему зависит от ночного тега nightly/v0.1.3.dev20261030, а не от официального релиза release/v0.1.3, выпущенного 10-31 в 23:01. Содержимое обоих тегов имеет один источник (0.1.3 отсечён от головы основной ветки 10-29, dev20261030 — тоже), разница в воспроизводимости — ссылка на ночной тег перезаписывается последующими сборками, официальный тег — нет. Для стека, который войдёт в дистрибутив, долгосрочная привязка к ночной версии означает, что зафиксированный в пакете источник невоспроизводим в долгосрочной перспективе, что относится к той же категории требований, что и в разделе 2.3 — «патчи должны генерироваться через git format-patch».

4.3 Три изменения на рассмотрении не вошли в 0.1.3, Whisper и выравнивание интерфейсов по-прежнему подвешены (состояние на 10-31)

Дата: 2026-10-31 (состояние)　Источники: PR #1011, PR #1013, PR #994, список открытых PR

Среди шестнадцати коммитов 0.1.3 нет #1011, #1013 и #994, что означает, что они всё ещё не включены в официальный релиз. Характер трёх изменений следующий: #1011 приводит счётчик масштабируемых фрагментов VIR к int64 (относится к той же линии ширины векторов, что и десять изменений VIR в этом выпуске), #1013 обеспечивает повторное использование предобработки в рамках одной транскрипции Whisper, #994 выравнивает интерфейс buddy-server по llama-server.

Самое неудобное из трёх — #994: интерфейс llama-server, к которому он хочет выровняться, — это именно тот слой, который переработан в #1015. В 0.1.3 дескрипторы плагинов, разделённые по модальностям, уже сведены в единый ABI; если #994 слить в исходном направлении, это будет означать наложение ещё одного слоя совместимости на только что переписанный интерфейс. В PR это противоречие не обсуждается, и в этом выпуске не видно, чтобы он был закрыт или перенаправлен — его текущее состояние: «ни в релизе, ни отклонён».

Положение #1011 аналогично, но направление противоположное: это завершающий пункт линии ширины векторов, тогда как десять изменений VIR за тот же период уже вошли в 0.1.3. Завершающий пункт остался за пределами релиза, что означает, что масштабируемая векторизация в 0.1.3 всё ещё не имеет окончательного решения на границе «счётчик фрагментов превышает 32 бита».

5. Сообщество, мероприятия и официальный сайт

5.1 Три страницы официального сайта без изменений, два сообщения в блоге, двадцать три главы документации (состояние на 11-02)

Дата: 2026-11-02 (состояние)　Источники: официальный сайт RuyiAI, индекс блога, индекс документации

Три страницы официального сайта в течение окна мониторинга не изменились, хеши снимков совпадают с предыдущим выпуском: индекс главной страницы — 3 записи, индекс блога — 2 статьи («Адаптация Triton для RISC-V» и «Практика PyTorch RISC-V CI»), документация — 23 главы. Это состояние сохраняется несколько выпусков подряд; в текущем выпуске новых статей или глав не появилось.

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

5.2 На форуме в течение окна мониторинга новых сообщений нет, двухнедельный отчёт выпуска 080 не вышел (состояние на 11-02)

Дата: 2026-11-02 (состояние)　Источники: сообщество разработчиков RuyiSDK, сообщение #2899, двухнедельный отчёт выпуск 079 #2895

На форуме в течение окна мониторинга новых сообщений нет, последнее сообщение по-прежнему #2899 от 10-29 (RuyiAI на шестом саммите RISC-V China), эта запись уже была включена в предыдущий выпуск. Предыдущий официальный отчёт — выпуск 079 от 10-26; выпуск 080 по двухнедельному ритму должен выйти в первой половине ноября, в текущем выпуске он ещё не появился.

Следует отметить распределение активности на форуме: три сообщения от 10-29 (#2897–#2899) все посвящены саммиту, после чего четыре дня — ноль сообщений. Тема саммита исчерпала дискуссионный лимит конца октября; следующая волна — после выпуска 080.

5.3 Два выпуска ruyiai-daily, охват аналитики — PyTorch, Triton и KV-кэш (10-31, 11-01)

Дата: 2026-10-31, 2026-11-01　Источники: ruyiai-daily

Ежедневный информационный склад в течение окна представил два выпуска (daily-news: 2026-10-31 и daily-news: 2026-11-01), сохраняя фиксированный ритм между 22:20 и 22:40 каждый день. Выпуск от 11-02 по своей привычке публикации появится только ночью того же дня, в окне его нет.

Эти два выпуска являются одним из источников перекрёстной проверки для настоящего отчёта: содержащиеся в них записи о синхронизации с upstream PyTorch и о пути деградации Triton согласуются с выводами разделов 1.1 и 1.3 настоящего отчёта, расхождений в формулировках не обнаружено.

5.4 Нулевые попадания во внешних новостях, два месячных обещания со стороны дистрибутива истекают одновременно (состояние на 11-02)

Дата: 2026-11-02 (состояние)　Источники: Google News RSS, страница новостей openRuyi

Три группы целевых запросов на китайском и английском по RuyiSDK, RuyiAI и openRuyi дали нулевые попадания в окне. Единственный результат на китайской стороне, содержащий «Жуи» (如意), по-прежнему относится к репортажу об участии в саммите от 10-25 (Yixing Intelligent), который выходит за пределы окна и не связан с сообществом Жуи; английский запрос «openRuyi» возвращает лишь одну старую статью от апреля.

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

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

6.1 Описание официального релиза расходится с множеством изменений в коде, прогресс RISC-V спрятан в истории коммитов

Случай с 0.1.3 методологически значимее, чем он сам: если «внешнее описание» проекта и «то, что фактически установлено» долгое время не совпадают, внешнее суждение о нём может строиться только обратным выводом из истории коммитов. Конкретное проявление этого выпуска состоит в том, что в примечаниях к релизу описана лишь реструктуризация серверного ABI, тогда как из шестнадцати коммитов двенадцать затрагивают векторный слой VIR.

У такого расхождения есть инерционная цена. Для нижележащих потребителей суждение «стоит ли обновляться» требует одновременного просмотра трёх мест: release notes, разности коммитов и якоря зависимостей; для вышележащей стороны работа, которую действительно хотели бы видеть, не появляется на странице, где она должна быть — наиболее системный за последние три месяца прогресс векторизации не имеет соответствующего описания ни в блоге, ни в документации, ни в примечаниях к релизу. Для стека, повествующего о «RVV к Matrix», оформлять прогресс векторизации как десятистрочный заголовок в истории коммитов — это расточительство.

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

6.2 triton-riscv переходит от «чинить по одному и сливать по одному» к «пакетной подаче на ревью», сторона приёмки по-прежнему отсутствует

Три коммита от 10-29 были «слиты подряд за 80 минут», пять коммитов текущего выпуска — «открыты подряд за два дня, ещё не слиты». Первое показывает, что у мейнтейнеров есть быстрый канал для однозначных исправлений дефектов, второе — что новая партия изменений ещё не дошла до этой стадии. Разница между двумя ритмами не в интенсивности разработки, а в пропускной способности ревью.

Эти пять коммитов плюс три от 10-29 дают накопленные за три недели восемь однотипных исправлений, все указывающие на потерю информации на пути деградации. Само это количество — сигнал: данная ветка не обзавелась систематической проверкой эквивалентности, приходится натыкаться на проблемы оператор за оператором и дописывать исправления после каждого столкновения. А самое ценное для нижележащих потребителей — сделать экспорт тех 604 операторов FlagGems постоянно действующей регрессией, запускаемой каждую ночь, — по-прежнему не сделано. Хотя PR #56 вышел из застоя с 09-16 (10-30 в 20:50 был один пуш, масштаб уже расширен до 156 новых файлов, число экспортируемых записей выросло с 468 до 604), он всё ещё открыт.

Пока приёмка живёт в PR, а не в конвейере, вопрос «заработает ли эта партия операторов на riscv64» будет вновь и вновь откладываться.

6.3 Месячные обещания со стороны дистрибутива снова не выполнены, пакетирование на уровне стека по-прежнему переделывается на уровне spec

За последние три дня октября две линии, непосредственно связанные с «дистрибуцией», одновременно пропустили окно: формулировка «конец октября» для ruyi 0.54.0 не выполнена, версия openRuyi 2026.10 к 11-02 не выпущена. Кодовая сторона обеих линий не остановлена — в openRuyi 30-10 было ещё шесть коммитов, в ruyi — один слитый коммит документации, — так что узкое место в самом процессе выпуска, а не в разработке.

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

Для RuyiAI наиболее практичная краткосрочная рекомендация — не торопить выпуск, а записать те три нестандартных пункта из раздела 2.3 (buddy-mlir несёт собственный LLVM, triton зависит от git, tilelang требует обнаружения инструментальной цепочки) в виде соглашения о пакетировании, чтобы ревью #1350 не приходилось каждую неделю заново обсуждать одну и ту же партию вопросов — снизив стоимость круговых итераций, только тогда можно говорить о вхождении в месячный ритм выпусков.

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

Источники Результаты проверки
Организация RuyiAI-Stack (все репозитории) pytorch: ветка riscv, 11-01 03:00, вторая полная перебазировка с повторным применением двадцати коммитов, головной коммит 1867c9b8, базовая линия по-прежнему 3afdbd3, новых патчей нет; llvm-project: ветка riscv, 11-01 23:00, повторно применено двадцать шесть коммитов, в списке понижение IME/AME для A100 (#30, #31), интерфейс сравнения показывает, что базовая линия upstream уже содержит коммит от 10-30; triton-riscv: два слияния (#55, #91), пять новых открытых (#93–#97), одна перебазировка (#92), #56 возобновлён к отправке 10-30 20:50; tilelang-riscv семнадцатый день молчания, из открытых PR остался только #4; VecIntrinBench, IntrinTrans, FBGEMM, harness, cpuinfo, torq-tile, pytorch-ci, dsh-osc, skills, caffe, mxnet — коммитов в окне нет
Организация ruyisdk (все репозитории) основной репозиторий ruyi: 1 коммит (#508 список наименований производителей), новых Release нет, 0.54.0 по-прежнему имеет только alpha-тег от 09-18, стабильная версия остаётся 0.53.0; packages-index, support-matrix, docs, ruyisdk-website, ruyi-imager, wechat-articles, attached-matrix-extension, ruyici, AME-operator — коммитов в окне нет
Организация openRuyi-Project основной репозиторий: 6 коммитов (все 10-30) + 3 слитых PR (#1424 LLVM 23, #1514 ollama 0.40.7, #1545 clang-wrap 20261030); активность в окне по 24 открытым PR (партия Prometheus — 13, #1561 box64, #1559 firecracker, #1516 qemu-rustsbi, #1562 отслеживание тестов binutils RISC-V, #1563 Node.js, #1544 firefox, #1421 qemu GUI, #1350 триптих Ruyiai); версия 2026.10 не выпущена, страница релиза возвращает 404
Организация buddy-compiler buddy-mlir: стабильная версия 0.1.3 выпущена 10-31 23:01 UTC (от v0.1.2 до v0.1.3 всего 16 коммитов, 136 файлов, из них 10 — [midend][VIR] RVV-векторизация) + ночная сборка dev20261030; в основной ветке коммитов в окне нет (последний 10-29 07:08); #1011, #1013, #994 не вошли в 0.1.3
Форум сообщества разработчиков RuyiSDK новых сообщений в окне нет, последнее по-прежнему #2899 от 10-29; двухнедельный отчёт выпуск 079 (10-26) — последний официальный отчёт, выпуск 080 не вышел
Страница новостей дистрибутива openRuyi новых статей нет, объявление о выпуске 2026.09 (09-30) остаётся последним; пути релизов 2026-10 и 2026-11 возвращают 404
Пакетный менеджер ruyi / Releases 0.53.0 сохраняется, новых alpha или beta нет (0.54.0-alpha.20260918 остаётся последней версией); в основной ветке только один коммит документации
Официальный сайт (ruyiai.org) три страницы без изменений: индекс главной страницы — 3 записи, блог — 2 статьи, документация — 23 главы, хеш снимка совпадает с предыдущим выпуском
ruyiai-daily два выпуска в окне (10-31, 11-01), методика совпадает с настоящим отчётом
Google News RSS (несколько групп на китайском и английском) целевые запросы RuyiSDK, RuyiAI, openRuyi, Ruyi RISC-V — ноль совпадений; по запросу «Ruyi» последнее — репортаж об участии в саммите от 10-25, вне окна и не связано с сообществом Ruyi, не включено

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

23 — https://github.com/openRuyi-Project/openRuyi/pull/1424