Отчётный период: с 26 октября 2026 г. (понедельник) по 30 октября 2026 г. (пятница), всего 5 рабочих дней.

Источники материалов: 5 выпусков ежедневного отчёта RuyiAI за 2026-10-26 — 2026-10-30 (окно каждого выпуска — с 04:30 предыдущего дня до 04:30 текущего дня, при этом для понедельника — за прошедшие 3 дня с охватом выходных); кроме того, 168-часовая проверка репозиториев трёх организаций RuyiAI-Stack, ruyisdk и buddy-compiler, полная статистика ежедневных коммитов и слитых PR основного репозитория openRuyi-Project (перекрёстная проверка через постраничный API), перекрёстная проверка по двум источникам — сообществу разработчиков RuyiSDK и странице новостей дистрибутива openRuyi, а также три снимка страниц официального сайта RuyiAI (проверка охватывает период до второй половины дня 10-31).

Пояснение к составлению: на этой неделе параллельно развивались четыре основные линии. Во-первых, векторизованное промежуточное представление VIR прошло три уровня — «выражение — вызов — сверка»: за одну ночь семью коммитами были дополнены масштабируемые векторы, на следующий день добавлены Python-привязки, а на третий день декодирующее внимание K3 целиком перенесено на VIR со сверкой по пропускной способности на плате. Во-вторых, принципы управления двумя ветками riscv разошлись: на стороне llvm прекращён ежедневный полный реплей ветки, вместо этого написаны руководство по внесению вклада и рабочий процесс автоматического перебазирования, а также отменён переключатель предварительного прогона; на стороне pytorch по-прежнему после семидневного молчания выполняется единовременный реплей. В-третьих, в основном репозитории openRuyi на этой неделе 234 коммита и 52 слитых PR, KDE Frameworks 6.31.0 развёрнут сразу 64 пакетами, при этом три revert отозвали курс на «распространение LLVM IR вместе с пакетами». В-четвёртых, окно выпуска версий в конце месяца не состоялось: ruyi 0.54.0 и openRuyi 2026.10 по состоянию на конец этой недели не выпущены. В еженедельный отчёт помимо материалов ежедневных отчётов добавлены восемь новых находок проверки (в основном после окна ежедневного отчёта или на границах периода), они перечислены в приложении.

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

  • VIR за три дня прошёл «выражение — вызов — сверку»: масштабируемые векторы, Python-привязки и декодирующее внимание K3 реализованы последовательно: с 10-26 22:48 по 10-27 03:22 один и тот же автор выполнил в buddy-mlir семь коммитов подряд (#1002—#1008), за один раз дополнив пошаговое продвижение strip-mining по vscale, вычисление размера вектора по VLEN/64, понижение vir.set_vl с результатом до масштабируемых векторов, динамическую перестановку векторных строк и соглашение об индексации; 10-27 22:42 слит #1009 (12 файлов, +614/−1), добавляющий в VIR модуль buddy_mlir.dialects.vir, благодаря чему этот диалект, ранее исполнявшийся только в buddy-opt, теперь может напрямую конструироваться и понижаться из Python; 10-28 09:36 слит #1014 (4 файла, +476/−14), переносящий декодирующее внимание K3 w4g32 целиком на VIR. Источники: #1002 пошаговое продвижение по vscale, #1009 Python-привязки, #1014 декодирующее внимание K3

  • Все три пункта сверки на K3 убедительны: побитовое совпадение числовых значений, по 178 векторных инструкций, перекрытие диапазонов пропускной способности: ядро из #1014 сегментировано по 64 lanes, одна голова — это векторная группа LMUL 4 из 128 значений f32, цель понижения изменена с vector-width=128 на rvv-vlen=1024 с отключением масштабируемых векторов. Как с нормализацией q/k, так и без неё результат побитово совпадает со старым _attn_decode_fn; в машинном коде два параллельных тела содержат по 178 векторных инструкций, цикл по ключам и значениям имеет те же инструкции, что и в старой версии, изменились лишь позиции двух перезагрузок регистров при переполнении; на K3 все три уровня пропускной способности жадного декодирования перекрываются — после 63 token 28.26~28.49 против 28.10~28.58, после 458 token 26.82~27.13 против 27.02~27.04, после 900 token 25.37~25.41 против 25.29~25.77. Автор отмечает, что две сборки одного и того же кода могут различаться на 2%. Источники: #1014, документация K3

  • Ветка llvm riscv переходит от «ежедневного полного перебазирования» к «написанию правил»: 244 строки рабочего процесса автоматического перебазирования плюс руководство по участию, а предварительный просмотр отменён: в первые два дня недели ветка всё ещё перебазировалась (10-26 перенесено 221 коммит, 10-27 — 237 коммитов), с 10-28 добавлен .github/workflows/autorebase.yml (+244/−0), 10-29 добавлен RISCV_CONTRIBUTING.md (+82/−8) и из рабочего процесса удалён вход dry_run — при успехе изменения сразу отправляются обратно в ветку автора, без предварительного просмотра. Руководство описывает два пути участия: сопровождающий создаёт рабочую ветку work/issue-NNN, либо нужно напрямую отправить PR в riscv и вручную запустить перебазирование. При конфликтах в рабочем процессе всегда выбирается сторона riscv, эквивалентные патчи автоматически отбрасываются, код из PR и сборка никогда не выполняются. Источники: autorebase.yml, RISCV_CONTRIBUTING.md, коммит faf4def312

  • Три понижающих исправления triton-riscv влиты за 80 минут, мотивация всех — миграция операторов FlagGems: с 15:38 до 16:58 10-29 последовательно влиты #82 (уникальный целевой индекс для теста скаттеринга, 1 файл +23/−3), #83 (маскированная загрузка поддерживает тензорное заполняющее значение, 4 файла +160/−16), #58 (сохранение переносимого циклом смещения gather, 2 файла +125/−0). #83 проверен на машине riscv64: три новых регрессии RUN/FileCheck все пройдены, полный lit 291 пройден, 9 ожидаемых падений, 0 неожиданных падений, 18 проверок времени выполнения пройдены. Три исправления ждали влития 82, 43 и 44 дня соответственно, а нужный им PR миграции #56 в то время всё ещё висел с 09-16. Источники: PR #83, PR #58, PR #82

  • openRuyi за неделю 234 коммита, 52 влитых PR, KDE Frameworks 6.31.0 за минуту разложен на 64 пакета: по статистике по дням пекинского времени, с 10-26 по 10-30 соответственно 80, 36, 36, 73, 9 коммитов, авторы в основном Leetfs (87 коммитов), KiritakeKumi (65 коммитов), misaka00251 (17 коммитов). В одну и ту же минуту 15:11 10-29 добавлены 64 пакета kf6-*, что в основном покрывает полный набор фреймворков, от которых зависит Plasma 6; на этой неделе также вся семья Samba разом переведена на 4.25.1 (включая tevent 0.17.2, tdb 1.4.15, talloc 2.5.0, а jack2 и rpm-config-openruyi переведены на сборку Waf), два обратных переноса qemu 11.1.2 и libvirt. Источники: список коммитов openRuyi, PR #1513 KDE, PR #1428 Samba

  • Комплект из трёх компонентов RuyiAI перешёл от «спора о маршрутах» к «переработке спецификаций», стоимость сборки количественно оценена в 2,81 раза: PR #1350 одним коммитом добавляет три spec — buddy-mlir, python-triton-ruyiai, python-tilelang-ruyiai; открыт 9-21, затем почти месяц простоя; 10-27 автор отвечает по пунктам на три замечания ревью; 10-28 переводит «сборку через GCC» в фактическую оценку — с 8814 секунд до 24798 секунд (около 2 часов 27 минут против 6 часов 53 минут, причём на этом прогоне этап компоновки завершился ошибкой); 10-29 получен первый раунд ревью на уровне кода из 18 пунктов, все касаются написания spec (отсутствует BuildRequires, Provides не согласован с именем пакета, патчи должны генерироваться через git format-patch, пустой %check должен сопровождаться комментарием). К концу недели PR остаётся открытым, объём — 10 файлов, +838/−0. Источники: PR #1350, PR #1352 пакет PyTorch

  • Обещание на конец месяца не выполнено: у ruyi 0.54.0 по-прежнему только alpha от 09-18, openRuyi 2026.10 не выпущен: в выпуске 079 двухнедельного отчёта о прогрессе пакетный менеджер 0.54.0 из-за корректировки цикла релизов перенесён на конец октября; по состоянию на вторую половину дня 10-31 список тегов всё ещё заканчивается на 0.54.0-alpha.20260918, последняя официальная версия — 0.53.0 от 09-24; теги репозитория openRuyi заканчиваются на 2026.09-experimental, на странице новостей нет анонса релиза 2026.10. Последние два изменения в основном репозитории за неделю — документ со списком названий производителей от 10-29 и слияние #508 от 10-30, оба не являются действиями по релизу. Источники: ruyi Releases, теги ruyi, теги openRuyi

  • Ветка pytorch riscv после семидневного молчания единовременно переиграна, SyncBots поднимает базовую линию до апстрим-коммита 3afdbd3; в tilelang-riscv на четырнадцатый день по-прежнему нет коммитов: в ветке riscv репозитория pytorch с 10-22 семь дней подряд не было коммитов; 10-29 в 14:06 одиннадцать существующих патчей были переиграны с единообразным перезаписыванием времени автора, а в 20:48 синхронизирующий бот добавил коммит [SyncBots] Integrate PyTorch at 3afdbd3 (изменена только строка FORCE в cmake/Dependencies.cmake). В основной ветке tilelang-riscv последний коммит по-прежнему от 10-16 10:52, открытый PR #4 не обновлялся с 09-28; единственное присутствие на этой неделе — спецификация python-tilelang-ruyiai в дистрибутиве. Источники: ветка pytorch riscv, коммит SyncBots 5a29c201, tilelang-riscv

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

Обзор окна мониторинга: действия организации RuyiAI-Stack (18 репозиториев) на этой неделе сосредоточены в llvm-project (две смены базы за первые два дня, затем три дня на управленческих активах и полной переигровке ветки), pytorch (переигровка после семидневного молчания), triton-riscv (три понижающих исправления и два обновления опорных точек), ruyiai-daily (пять выпусков подряд) и репозиториях сайта (обновление ботом данных о контрибьюторах); в tilelang-riscv, FBGEMM, cpuinfo, VecIntrinBench, IntrinTrans, torq-tile, pytorch-ci, dsh-osc за всю неделю коммитов не было.

Ветка llvm-project riscv: после пяти смен базы за пять дней работа остановлена, эстафету принимают управленческие активы

Дата: 2026-10-26 — 10-30　Источники: список коммитов ветки riscv, рабочий процесс autorebase, RISCV_CONTRIBUTING.md

На этой неделе последовательность ребейзов составила 474 коммита 10-25, 221 коммит 10-26 и 237 коммитов 10-27. Общая черта всех трёх переигрываний одинакова: заголовок головы по-прежнему «[RISCV] Add A100 HP/SP and pack/unpack lowering with calibrated scheduling (#31)», отставание в 26 коммитов в точности равно числу локальных патчей, построчное сравнение заголовков и порядка не выявило изменений; в случае 10-27 те 20 локальных коммитов были перезаписаны и переотправлены в пределах одной минуты (время коммиттера сосредоточено с 15:00:29 по 15:00:31), тогда как время автора простирается с 1 июля по 3 октября. Иными словами, действия этих трёх дней состояли в переносе существующего набора патчей на новую базовую линию, весь функциональный прирост пришёл из upstream.

С 10-28 ритм изменился. Ветка продвинулась всего на один коммит cf00909d — это .github/workflows/autorebase.yml (+244/−0): устанавливается на ветку по умолчанию в исходном репозитории автора, запускается через workflow_dispatch, два входа — номер PR и «только предварительный прогон без отправки» (включён по умолчанию), среда выполнения ubuntu-24.04, таймаут 90 минут; комментарии прямо требуют никогда не исполнять код PR, хуки, сборки или подмодули при наличии прав записи, конфигурация git направляет hooksPath, attributesFile и fsmonitor в /dev/null; обработка конфликтов для случаев, которые не покрывает -Xours, выполняется по одному через ls-files --unmerged: при наличии 2-й стадии берётся локальная версия, иначе — удаление, а также распознаются «эквивалентные патчи» с отбрасыванием дублирующих патчей старой базовой линии.

В полном переигрывании ветки 10-29 в 23:00 реально новым оказался коммит [workflows] Push rebased PRs directly and document contribution options (время автора 10-29 09:59): из autorebase.yml удалено 8 строк (убраны вход dry_run и ветка предварительного прогона), добавлено 82 строки RISCV_CONTRIBUTING.md. Руководство предлагает два пути — сначала открыть issue, затем мейнтейнер отводит от текущей riscv рабочую ветку work/issue-NNN, и контрибьютор отправляет PR в рабочую ветку; либо сразу отправить PR в riscv и вручную запустить ребейз, при этом рабочий процесс с --force-with-lease и явным ожидаемым SHA отправляет обратно в исходную ветку. В документе также напоминается, что отправка через GITHUB_TOKEN обычно не запускает последующие рабочие процессы push/PR, и факт прохождения CI на обновлённом SHA требует ручной проверки.

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

llvm-project upstream: 17 RISC-V pass за час перенесены в NewPM

Дата: 2026-10-26　Источники: миграция InsertVSETVLI, миграция PreAllocZilsdOpt, миграция DeadRegisterDefinitions

Среди 221 коммита upstream, привнесённых ребейзом 10-26, 21 относится к RISC-V, из них 17 — портирование в NewPM, все автором Aiden Grossman, время сосредоточено с 12:59 по 13:55 (пекинское время) — менее чем за час. Список охватывает основные pass бэкенда: вставку VSETVLI после выбора инструкций, чтение-запись CSR и запись VXRM, устранение VMV0, генерацию сжатых инструкций, оптимизацию push/pop, объединение базовых адресов, оптимизацию LoadStore, предварительное распределение Zilsd, оптимизацию ветвлений и маркировку QCRelax, а также устранение мёртвых определений регистров, устранение избыточных копий, отслеживание косвенных переходов, настройку landing pad и поднятие констант.

Оставшиеся четыре коммита относятся к трём направлениям: атрибут vxrm-pipeline-flush ограничивает спекулятивную запись VXRM циклами с гарантией сброса; LSR на цели Zibi отдаёт предпочтение сравнению на равенство в качестве выхода из цикла; GlobalISel дополняет легализацию G_FPTOSI_SAT и G_FPTOUI_SAT, делая насыщающее преобразование с плавающей точки в целое доступным на пути глобального выбора инструкций. Ещё один коммит переводит понижение сборки-распространения и использование оптимизатора VL в анализ на ленивые запросы.

Значение не в отдельных изменениях, а в принадлежности к конвейеру: этот набор pass долго висел на LegacyPM, а после переезда в NewPM он согласуется с кэшем анализа нового pass manager, порядком проходов и интерфейсами отладки. Непосредственное влияние на нижестоящие форки состоит в том, что каждая смена базы теперь несёт с собой этот набор изменений, а имена -passes= и состав pipeline сдвигаются вместе с ним — это одно из немногих мест, где на ветке riscv на этой неделе при «смене базы без изменения патчей» фактическое содержимое изменилось.

pytorch: полное переигрывание ветки после семидневного молчания, SyncBots поднимает базовую линию до 3afdbd3

Дата: 2026-10-29　Источники: ветка pytorch riscv, коммит SyncBots 5a29c201, список открытых PR

Голова ветки riscv после 10-22 03:00 оставалась неизменной семь дней подряд; семь открытых PR (#23, #35, #36, #38, #43, #46, #48) при поиске по времени обновления не дали ни одного попадания за всю неделю; из них #46 «RISC-V Vector Extension support for ATen» и #48 «Add RISC-V Vector CPU capability» — две магистральные заявки на подъём возможностей RVV, их состояние такое же, как три недели назад.

10-29 14:06 ветка была полностью переиграна: время коммиттеров у 11 существующих патчей единообразно переписано на 14:06:44–14:06:45, авторское время сохранено как было, набор патчей сохраняет локальное зеркало riscv64 (#51), исправление плавающей точки в bytes_to_scalar (#44), blocklist opinfo в inductor (#50), допуск ULP для linear cross entropy (#42) и серию CI. Коммит [SyncBots] Integrate PyTorch at 3afdbd3 в 20:48 меняет только одну строку: к cache-переменной KINETO_SOURCE_DIR добавляется FORCE, что означает, что базовая линия ветки автоматически продвигается вслед за роботом синхронизации с upstream.

В основной ветке в тот же период около 20 коммитов в день — всё это синхронизация с upstream; на этой неделе содержимое сосредоточено на сведении конструкторов VariableTracker в Dynamo (партия #200473, #200472, #199832, #199831, #199830, #199829), исправлении 64-битного индекса в max_pool3d для CUDA и переходе объединённого онлайн-softmax на точную экспоненту — ни один коммит не касается RISC-V.

Заслуживает параллельного прочтения рассогласование на стороне дистрибуции: #1352 в openRuyi упаковывает артефакты этой ветки в python-torch-ruyiai, но этот PR остановился на 10-27, а голова ветки уже перешла на новую базовую линию. Если пакет собирается из артефактов ветки, зафиксированную в пакете точку исходников нужно будет выровнять ещё раз — сейчас этим не занимается ни один PR.

triton-riscv: три исправления понижения влиты за 80 минут, якорь перескочил сразу на две ступени

Дата: 2026-10-27 — 10-29　Источники: обновление якоря PR #90, PR #83, PR #58

Три линии сошлись в один день. Первая — зависимости: 10-27 19:43 влит #90 от renovate (+2/−2), якорь buddy-mlir перескочил с nightly/v0.1.1.dev20261017 сразу на nightly/v0.1.3.dev20261027, минуя официальную версию 0.1.2 и две ночные сборки — это значит, что те семь изменений масштабируемых векторов VIR в ночь на 10-26 с этого выпуска входят в нижестоящую цепочку сборки. #91 от 10-28 18:51 поднимает якорь до dev20261028, но из-за того, что три CI-задачи riscv64 стоят в очереди и не вернулись, в тот день он не влит.

Вторая — код: три исправления понижения от 10-29, подробности см. в «Главном за неделю». Глубина проверки у трёх не одинакова — #83 прогнал полный lit и 18 проверок времени выполнения, #58 прогнал только целевые регрессии, #82 прогнал только один файл (21 прошёл).

Третий пункт — рассинхронизация состояний: три исправления уже вошли, но нужный для них миграционный PR #56 «Migrate additional FlagGems operators» по-прежнему висит с 09-16 и за всю неделю не был слит; из открытых PR #55 (патч фронтенда оператора asin) был слит 10-30 в 20:14, а #85 «softmax и оптимизация matmul» с 10-18 не обновлялся. Обновление якорей решает только вопрос «можно ли этим воспользоваться», но не означает «уже используется»: ночная сборка от 10-28 была собрана раньше трёх слияний утром того же дня, и нижестоящим потребителям, чтобы получить #1014 и #1015, придётся ждать ещё одну ночную сборку плюс одно обновление зависимостей.

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

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

Последний коммит в основную ветку по-прежнему «Build Python extension in Buddy CI» от 10-16 10:52; к 10-30 прошло уже четырнадцать дней подряд без коммитов; открытых PR два: #2 застрял на 06-16, #4 «RVV vector mask and max reduction lowering» — на 09-28, оба за эту неделю не обновлялись. Это прямой контраст с тремя слияниями в triton-riscv за тот же период: одна и та же организация, один и тот же период, но в одном случае идёт сосредоточенная расчистка деградационных дефектов, а в другом — полное отсутствие движения.

Единственное присутствие нижестоящего уровня — спецификация python-tilelang-ruyiai в openRuyi (4 патча внутри #1350: ослабление требования Apache TVM FFI 0.1.10, переход на системные зависимости сборки, обнаружение инструментальной цепочки buddy-mlir, пропуск перезаписи soname для z3). Состояние «артефакт дистрибутива вместо итераций в репозитории» длится уже третью неделю; сигналы восстановления этой линии следует искать в двух местах: когда в репозитории появится новый коммит и когда этот пакет будет слит.

3. Инструментальная цепочка и дистрибутивы RuyiSDK (пакетный менеджер, дистрибутивы, зеркала и матрица поддержки)

Основной репозиторий openRuyi: 234 коммита, 52 слияния, KDE Frameworks разом покрывает 64 пакета

Дата: 2026-10-26 — 10-30　Источники: список коммитов openRuyi, PR #1513 KDE Frameworks 6.31.0, список слитых PR

При подсчёте по дням по времени автора коммитов за 10-26 — 10-30 получилось 80, 36, 36, 73 и 9 коммитов соответственно, всего 234; за тот же период слито 52 PR, открытая очередь сократилась с 71 на прошлой неделе до 58. Основные авторы — Leetfs (87 коммитов), KiritakeKumi (65), misaka00251 (17), Jingwiw (12), KimmyXYC (11).

По характеру дни заметно различаются. 10-26 — это зачистка безопасности: 31 исправление безопасности (почти четыре десятых), 18 новых Rust crate, 14 обновлений версий, затронуто 48 пакетов; планка безопасности поднята для nats-server 2.15.1, moby 29.9.2, fzf 0.74.5, etcd 3.7.2, containerd 2.4.2, openjdk-latest продвинут до 27.0.1.0.2.1 с обновлением контрольных сумм исходников, кроме того, в репозиторий вошли целый набор инструментов OpenPGP sequoia, fwupd-efi и набор зависимостей Cloudmux; в тот же день #1512 перенёс поддержку Zvk SHA-2 из основной линии Go — это единственное за неделю изменение дистрибутива, напрямую связанное с набором инструкций RISC-V.

27-10 — это связано с обновлением: всё семейство Samba выравнивается в одной временной точке (samba 4.25.1, tevent 0.17.2, tdb 1.4.15, talloc 2.5.0, cmocka 2.0.2), все пакеты, зависящие от этих трёх ABI, должны быть пересобраны; линия безопасности представлена в #1506 сразу 12 пакетами (sysrepo 5.2.27, libzip 1.12.1, libyang 6.4.13, libical 4.0.7, vim 9.2.1201, squashfuse 0.6.5, simdutf 9.3.2, pcre2 10.49, libheif 1.23.6, imagemagick 7.1.2.34, cups 2.4.20, cpp-httplib 0.63.0); добавлено 13 новых пакетов, преимущественно в экосистеме Go (три пакета go-git, goldmark-highlighting-v2, go-udev, go-evdev, gonetworkmanager-v2, ghw, go-pinyin, kustomize и др.), что вместе с заменой встроенного vendor bundle на упакованные Go-зависимости в dms-shell является двумя сторонами одного и того же.

28-10 — переход к виртуализации: qemu обновлён с 11.1.x до 11.1.2, два обратных переноса в libvirt (распространение /var/lib/libvirt/secrets вместе с пакетом, исправление отказа пула rbd после удаления auth_supported в Ceph 21), принят макрос %toolchain_major_version, позволяющий переключаться между gcc-15, gcc-16, clang-22, clang-23; также ряд исправлений сборки python-пакетов, среди которых scikit-build-core 1.1.1 и метаданные дистрибутива Python в cmake оказывают прямое влияние на путь сборки wheel для CMake-расширений, таких как triton и tilelang.

29-10 — пик текущего периода: из 76 коммитов 64 относятся к KDE Frameworks 6.31.0, все они попали в одну и ту же минуту 15:11, от kf6-kcoreaddons, kf6-kconfig до kf6-kio, kf6-ksvg, kf6-kwallet, практически охватывая полный набор фреймворков, от которых зависит Plasma 6; остальное — Gradio 6.31.0, python-pyvex 10.0.5, исправление эпохи provides в graphql-core, добавлен vkpeak (определение пиковой производительности и возможностей устройств Vulkan), а также исправление пути к модулям cmake в ecbuild, ежедневное обновление clang-wrap и три очистки графа зависимостей Go (удаление дублирующихся пакетов, дополнение provides для import path).

Путь упаковки openRuyi: связанное обновление Samba и отзыв линии распространения LLVM IR

Дата: 2026-10-27　Источники: PR #1509 Revert llvm ir, PR #1428 Samba, PR #1511 dms-shell

В прошлых выпусках ключевым словом openRuyi было «дополнить»: дополнить пакеты, дополнить безопасность, дополнить Rust crate. На этой неделе впервые появляется явное вычитание — принятый в 15:15 #1509 содержит всего три коммита, чистое удаление 105 строк (+5/−105), отменяя три экспериментальные упаковки: feature llvmir в gsl, переход pixman на сборку clang с выпуском IR вместе с пакетом, распространение LLVM IR вместе с libjpeg-turbo.

В тексте PR причина не указана; судя по содержанию, направление состояло в том, чтобы компилировать библиотеки в LLVM IR и распространять их с пакетом, оставляя интерфейс для повторной оптимизации или отложенной генерации кода; вся линия была отозвана перед выпуском, что говорит о том, что цепные издержки этого подхода в трёх аспектах — размер пакета, согласованность ABI и отладочных символов, поддержка инфраструктуры — в краткосрочной перспективе вряд ли дадут выгоду. Для дистрибутива RISC-V это запоминающийся компромисс: распространение IR теоретически позволяет переиспользовать оптимизации upstream, но без сопутствующего инструментария лишь перекладывает издержки на пользователя.

С другой стороны, сложение — это «связанное обновление»: Samba и три зависимые библиотеки меняют версии одновременно, все пакеты, зависящие от ABI tevent/tdb/talloc, должны быть пересобраны, что является наиболее типичным массовым действием в дистрибутиве. На одной неделе есть и сложение «пересобрать целый пласт пакетов ради согласованности», и вычитание «отрезать экспериментальную линию ради сопровождаемости», что показывает, что центр тяжести сопровождения смещается от «охватить больше пакетов» к «удержать границы качества уже имеющихся пакетов».

Упаковка триады RuyiAI: #1350 переходит от спора о направлении к переработке спецификации spec

Дата: 2026-10-27 — 10-29　Источники: PR #1350, комментарии проверки PR #1350

#1350 — самый важный коммит недели на уровне дистрибуции: один PR одновременно добавляет три пакета — buddy-mlir, python-triton-ruyiai, python-tilelang-ruyiai. Хронология: 21.09 открыт PR (три коммита с 09:46 по 09:48), 24.09 мейнтейнер Z572 выдвинул три требования по изменениям, 28.09 автор исправил два из них, затем почти месяц простоя, 27.10 с 17:55 по 18:54 подряд опубликованы три ответа с подробным разъяснением по каждому пункту, 28.10 в 16:22 три коммита в одну и ту же минуту перебазированы на последнюю главную ветку, 29.10 с 16:19 по 16:24 получены пять замечаний первого раунда код-ревью.

Центр спора смещается. До 27.10 это был вопрос «выносить ли наружу LLVM, поставляемый с buddy-mlir» — автор обосновывал это тем, что эти пакеты всегда привязаны к конкретному коммиту LLVM, LLVM используется только внутри данного пакета, и только внутри пакета можно обеспечить воспроизводимость; кроме того, в upstream-репозитории triton setup.py принудительно проверяет, исполняем ли git, поэтому либо нужно добавлять сборочную зависимость git, либо патчить setup.py (последнее перестанет работать при обновлении triton). 28.10 автор квантифицировал цену «перехода на сборку через GCC»: на riscv64 время вырастает с 8814 секунд до 24798 секунд, в 2,81 раза, причём та сборка упала на этапе линковки и не завершилась. Эта цифра превратила спор из технических предпочтений в арифметику планирования сборочной фермы: коэффициент 2,81 означает пересчёт занятости машин, стратегий таймаутов и окон релиза.

Ревью 29.10 сместилось к механическим нормам: между BuildOption(xxx) не нужно вставлять пустые строки; в python-triton-ruyiai отсутствует BuildRequires: python3dist(wheel); Provides должен соответствовать фактическому имени пакета; необходимость Conflicts: python-%{srcname} требует пояснения; патчи должны генерироваться через git format-patch, причём в том же каталоге есть неиспользуемый патч; пустой %check требует комментария с объяснением причины. Подобные замечания обычно появляются на стадии «направление одобрено, идёт доводка». К концу недели PR насчитывает 10 файлов, +838/−0, 18 комментариев ревью, всё ещё открыт.

PyTorch отдельным пакетом: список патчей в #1352 и управление RVV

Дата: 2026-10-27 (статус)　Источник: PR #1352, python-torch-ruyiai spec

#1352 упаковывает RuyiAI-Stack/pytorch отдельно в python-torch-ruyiai (8 файлов, +783/−0), открыт в тот же день, что и #1350, обновлён в тот же день, единственный коммит остановился 21.09 в 11:22, за всю неделю не двигался.

Набор патчей читается как полный список адаптации под дистрибутив: 2001 заставляет OpenBLAS использовать cblas для комплексного скалярного произведения, 2003 переходит на системный fmt, 2005 переходит на системную зависимость cmake, 2006 пропускает бесполезную проверку предсборки подмодулей, 2011 включает управление RVV-ядром по возможностям целевого вектора, 2012 встраивает scikit-build-core; дополнительно прилагается pytorch-smoke-test.py — после установки нужно прогнать smoke-тест, чтобы считать проверку пройденной. 2011 — самый ценный из этой партии: он меняет условие включения RVV-ядра с «предполагается поддержка на этапе компиляции» на «управление по возможностям целевого вектора», что прямо отвечает на старую проблему целей вроде RVA20 без векторных расширений — «пакет ставится, при запуске падает». Такие исправления обычно добавляют только после того, как пользователи наткнутся на них на платах; теперь они заранее вошли в упаковочный патч.

Риски столь же очевидны: ветка была полностью перебазирована на новую базовую линию только на этой неделе, зафиксированные в пакете точки исходников нужно заново выравнивать; #1352 остановился 27.10, на два дня раньше перебазирования ветки (29.10).

Пакетный менеджер ruyi: обещание конца месяца для 0.54.0 не выполнено

Дата: 2026-10-30 (статус)　Источник: ruyi Releases, список тегов ruyi, список коммитов ruyi

В выпуске двухнедельного отчёта 079 формулировка была такой: «из-за корректировки цикла релизов 0.54.0 ожидается в конце октября». По состоянию на вторую половину дня 31.10 список тегов по-прежнему не имеет новых тегов после 0.54.0-alpha.20260918, последняя официальная версия — 0.53.0 от 24.09, в главной ветке на этой неделе всего два коммита: «docs: update vendor naming list» от 29.10 и слияние #508 от 30.10, и ни один не является релизным действием. Судя по ритму предыдущего цикла — beta 17.09, официальная версия 24.09 — для соблюдения срока 0.54.0 должна была сначала выйти beta, а затем начаться релизный процесс; на этой неделе запаса уже не осталось.

В тот же период есть два предложения и документа, которые стоит зафиксировать: #507 отправлен 10-28, добавляет в ruyi возможность «проверять совместимость ABI хоста для заданного пакета» (43 файла, +4023/−716); подход состоит в том, чтобы использовать встроенный в пакет ELF ABI sidecar как план запроса и сравнивать архитектуру, ELF class, интерпретатор, разделяемые библиотеки, версии символов и атрибуты архитектуры; результат имеет три состояния: совместимо, несовместимо, невозможно определить; также добавлена подкоманда ruyi admin check-abi. #508 — обновление списка именований производителей и замена в интерфейсе ruyi-imager «производитель» на «поставщик» — это две стороны одного и того же, чтобы избежать несогласованности названий в двух местах. Первое превращает вопрос «можно ли установить предсобранный RISC-V пакет на эту машину» из метода проб и ошибок в объяснимую проверку; для экосистемы RuyiSDK, ориентированной в основном на распространение бинарных пакетов, это ценнее любого обновления версии отдельного пакета; на данный момент изменение все еще не слито.

ruyi-imager 1.1.0-rc.1, packages-index и матрица поддержки

Дата: 2026-10-26 – 10-29　Источники: ruyi-imager v1.1.0-rc.1, коммит support-matrix K3 Pico-ITX, packages-index

ruyi-imager выпустил v1.1.0-rc.1 10-29 в 16:02, примерно через семь недель после 1.0.0 (09-10). Все четыре изменения — шлифовка удобства использования: на шаге выбора образа добавлено действие загрузки (#12), вывод CLI приведен в соответствие с кодировкой символов терминала, а JSON сохраняет UTF-8 (#14), двойной щелчок в диалоге выбора сразу подтверждает (#19), диалог выбора требует явного выбора (#21); при этом «подтверждение двойным щелчком» и «обязательный явный выбор» — пара взаимодополняющих ограничений: первое ускоряет, второе предотвращает ошибочный выбор. В примечаниях к релизу отмечен один впервые внесший вклад участник; три из четырех изменений принадлежат одному человеку. На этой неделе также были поддержка прошивки K3 UFS и UEFI (10-23, в пределах окна мониторинга понедельника), двойной щелчок и подтверждение с клавиатуры в диалоге выбора, изменение терминологии интерфейса с «производитель» на «поставщик» и другие предварительные подготовительные изменения.

В packages-index на этой неделе всего один коммит: 10-26 образ revyos Milk-V Meles и связанный uboot подняты до 20260504. Малое количество согласуется с пояснением из выпуска 079 — программный источник ISCAS в последние две недели столкнулся с проблемой синхронизации данных, уже собранные пакеты не успели обновиться на публичном ресурсе, поэтому в списке пакетов, естественно, нет массовых обновлений. Это создаст предсказуемое расхождение: если 0.54.0 будет выпущен, а программный источник не восстановится, содержимое, которое пользователь видит при ruyi update, будет отставать от фактического состояния репозитория.

На этой неделе три отчета матрицы поддержки, автор один и тот же, выводы разные: Bianbu 4.0.1 для Milk-V Jupiter2 (заводской предустановленный образ, питание USB-PD 65W или ATX 2-pin 12V, первая загрузка через мастер настройки); Bianbu 4.0.8 для SpacemiT K3 Pico-ITX (вариант LXQt, статус good, функции рабочего стола полные, без блокировок); Ubuntu 24.04.5 для StarFive VisionFive 2 Lite (официальный предустановленный серверный образ, SFFB для входа в fastboot и прошивки, последовательный порт USB-to-TTL, статус только basic). Последние два отчета слиты в один день одним и тем же автором; разница в оценках как раз показывает, что реальная пригодность текущих дистрибутивов RISC-V зависит от глубины адаптации вендорских образов, а не только от поддержки ядра.

Двухнедельный прогресс, выпуск 079: корректировка цикла релизов и три пункта в разработке

Дата: 2026-10-26　Источники: Двухнедельный прогресс, выпуск 079, файл выпуска 079

Выпуск 079 опубликован на форуме сообщества 10-26 в 18:02, отчетный период — до 10-22, на четыре дня позже отчетного периода. Изменение формулировки по менеджеру пакетов наиболее прямое: 0.54.0 из-за корректировки цикла релизов перенесен на конец октября, текущей официальной версией остается 0.53.0, программный источник сообщества поддерживается в обычном режиме и обещана совместимость с примерно тремя последними официальными версиями.

Три пункта в разработке: проверка совместимости ABI программного пакета с текущей системой, упаковка для macOS большего числа официально поддерживаемых программных пакетов, адаптация инструментальной цепочки для SpacemiT K1/K3. На стороне базовых компонентов glibc перенесла sinh, sinhf, sinpi в векторный математический фреймворк libmvec, newlib добавила шесть векторных математических функций acosf, logf, asinf, asinhf, asinpif, atanf; в GCC — поддержка базовых Zvdota/Zvbdota, поддержка Md в расширении Ztt и обновление поддержки расширения P до версии 0.6. Три пункта в разработке вместе со сроками 0.54.0 формируют точки наблюдения для следующего выпуска: для проверки ABI уже есть предложение #507, адаптация K1/K3 зависит от формы инструментальных пакетов, а упаковка для macOS связана с доступностью на не-RISC-V хостах.

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

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

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

Четыре репозитория, связанных с векторизацией, за всю неделю не получили ни одного коммита, период молчания продолжает удлиняться: VecIntrinBench застыл на 02-13, cpuinfo — на 05-20, IntrinTrans — на 06-25, FBGEMM — на 07-13; torq-tile застыл на 04-09, dsh-osc — на 09-15, pytorch-ci не имеет записей о коммитах, harness застыл на 10-27 (тот самый коммит по разделению плагина в понедельник).

Именно на этой неделе возникло место, где бенчмарки нужны больше всего: все три исправления triton-riscv проверялись по «числу пройденных lit-тестов + числу пройденных runtime-кейсов», и ни одно не дало сопоставимых цифр качества векторизации (количество инструкций, занимаемый LMUL, число переполнений регистров); сверка производительности в #1014 также прямо признаёт, что две сборки одного и того же кода различаются на 2%. Делать выводы на основе пропускной способности на плате и так непросто, а если сторона бенчмарков продолжит стоять на месте, то вопрос «действительно ли оптимизация что-то улучшает» ещё долго можно будет решать только ручной сверкой. Это не проблема, возникшая на этой неделе, но три слитых исправления и одна сверка производительности высветили её ещё отчётливее.

Миграция FlagGems стала механизмом обнаружения дефектов в triton-riscv

Дата: 2026-10-29　Источники: PR #83, PR #58, PR #56 миграция FlagGems

Если разложить мотивы трёх исправлений, их общий источник — не набор тестов, а сам процесс «переноса операторов PyTorch партиями на triton-riscv»: tl.load с реальными заполняющими значениями тензора в unique_dim, смещение, переносимое циклом, в broadcast_to, сравнение повторяющихся индексов в операторе хеширования — все три лежат не на уровне инструкций RISC-V, а на границе слоя понижения и слоя верификации. Такие дефекты трудно естественным образом вырастить в модульных тестах — нужна реальная библиотека операторов, которая будет давить сверху партиями, чтобы они проявились.

Методологическая ценность выше самих трёх исправлений: для стека AI на RISC-V с точкой входа через Triton миграция FlagGems фактически служит сквозным набором приёмки, более близким к реальной нагрузке, чем набор lit-тестов компилятора. С другой стороны, эта неделя обнажила и точечную зависимость этого механизма — #56 не обновлялся с 09-16, и после слияния трёх исправлений процесс приёмки, наоборот, остановился; если это надолго не продвигать, следующую партию дефектов обнаружат только тогда, когда на них наткнутся другие пользователи. В конце периода появился позитивный сигнал: у #56 30.10 в 20:50 было одно обновление (подробности в приложении), но он всё ещё не слит.

Определение разрядности векторов: 1024 бита, по одному LMUL 4 на голову

Дата: 2026-10-28　Источники: buddy-mlir PR #1014, коммит llvm 1811501f, коммит llvm ed439f3e

#1014 задаёт целевую длину вектора при понижении ядра в 1024 бита и требует не использовать масштабируемые векторы, поэтому каждая голова (128 значений f32) занимает ровно одну векторную группу LMUL 4, а та самая vir.shuffle в области также выполняется внутри группы — размер, группировка и инструкция оказываются связаны одним набором параметров, это техническое определение стоит зафиксировать на этой неделе.

Этот подход и вышестоящий бэкенд — две стороны одной и той же задачи: влитый в прошлом окне в ветку llvm riscv коммит #30 понижает встроенные функции IME до инструкций точечного произведения SpacemiT A100, а #31 добавляет для A100 пути понижения HP/SP и pack/unpack и выполняет калибровку планирования. Один — это выбор инструкций и планирование на уровне бэкенда по регистрам, другой — задание размеров вектора по регистрам на уровне выражения ядра. Сейчас нет документации, указывающей, являются ли параметры в этих двух местах взаимными ограничениями, и не проводилась перекрёстная проверка на K3; когда на следующем этапе произойдёт переключение на масштабируемые векторы (автор уже указал, что это следующий шаг), предположение о группировке LMUL 4 ослабнет, и будет ли этот подход скорректирован вместе с ним — самый интересный момент для наблюдения.

Верификация вышестоящего проекта и статьи: 30 коммитов после переезда arch-test, на arXiv за всю неделю ничего нового

Дата: 2026-10-23 — 10-30　Источники: список коммитов riscv/riscv-arch-test, слияние набора Sv #2981, поиск на arXiv

Проверка на этой неделе показала, что прежний адрес riscv-arch-test/riscv-arch-test уже возвращает 404, репозиторий переехал в riscv/riscv-arch-test. После переезда в понедельничном окне (10-23 — 10-25) в репозитории было 30 коммитов — один из самых активных вышестоящих проектов за всё окно: одна линия — объединение разрозненных наборов в один (PMP #2996, группы Exceptions объединены в единый набор, Sv и SvSm, SvZicbo, ExceptionsSv объединены в единый набор Sv #2981), при этом список исключений CI переделан в формат «одна строка — одна запись»; другая линия — заполнение пробелов в привилегированных уровнях и виртуализации (наборы CSR и инструкций расширения H #2982, тесты M-режима hypervisor объединены в группу Sm #2983, прерывания уровней VS/VU/VS в режимах S и H #2911, группы H и SmH для Svinval #2997, включение счётчиков H_Zicntr и Sm_Zicntr_H и htimedelta #2998, а также шесть ограничений S-режима, включая Shcounterenw, и четыре базовых ограничения Zic). Объединение и дополнение выполняются одновременно, что говорит о том, что цель реорганизации — сначала привести структуру в порядок, а затем наполнять её содержимым. И support-matrix RuyiSDK, и оценки соответствия чипов различных производителей опираются на этот набор тестов, так что сам факт переезда нужно запомнить.

На стороне arXiv за всю неделю не появилось новых препринтов по RISC-V AI. Две последние работы — SecDMP от 10-27 (доказуемо безопасная схема префетчинга, связанного с обращениями к данным) и лёгкий генератор C-кода для гетерогенного TinyML; две работы от 10-23 — сравнение путей суперкомпьютеров на открытом ISA и исправление дефектов RISC-V процессоров с помощью LLM; наиболее близкой к нашей теме остаётся работа от 10-21 «Reorienting the Vector Axis: Restructuring FlashAttention for Long-Vector Processors», где обсуждается сегментация по 64 lanes и реструктуризация векторной оси на длинновекторных процессорах — это тот же класс задач, что и #1014, но, к сожалению, продолжения в окне не было.

5. Динамика Buddy Compiler (коммиты и релизы buddy-mlir)

VIR: семь коммитов по масштабируемым векторам за одну ночь, на следующий день добавлены Python-биндинги

Дата: 2026-10-26 — 10-27　Источники: #1002 шаг по vscale, #1007 унификация соглашения об индексах, #1009 Python-биндинги

С 22:48 26-10 до 03:22 27-10 один и тот же автор сделал семь коммитов подряд (#1002–#1008), все с префиксом [midend][VIR], вокруг одного и того же переключателя use-scalable, которые можно разбить на три слоя. Слой циклов и размеров: #1002 исправил шаг strip-mining — ранее vir.set_vl без результата понижался до главного цикла с шагом в константный vector-width, но каждый раунд обращался к памяти по N-кратному vscale числу lane, и при vscale больше 1 итерации перекрывались; #1003 заставил выбор размера на RVV вычисляться по vscale = VLEN/64, чтобы N и SEW определяли LMUL и больше не откатывались к фиксированным векторам; #1008 исправил падение утверждения, когда индексный вектор не имеет явной ширины. vir.set_vl с результатом: #1004 разрешил ему понижаться до масштабируемых векторов, #1005 дополнительно поддержал многомерные динамические векторы. Доступ к памяти и перестановки: #1006 добавил vir.shuffle для построчной перестановки динамических векторов, #1007 унифицировал соглашение об индексах для vir.load и vir.store.

Мотивация — не обобщённая переделка векторизации, а вынужденная конкретным оператором: в decode attention rotate_half из RoPE должна поменять местами переднюю и заднюю половины 128-элементной головы и затем взять отрицание (то есть [-x[1], x[0]]), по сути это построчная перестановка, а VIR ранее не мог выразить построчную перестановку динамических векторов и мог только во внешнем слое вычислить фиксированными векторами, а затем внести query в region. Поэтому #1006 добавил перестановку, #1005 — многомерные динамические векторы, #1007 — вход для индексов, и три коммита образовали путь «оставить весь decode attention внутри VIR».

Слитый на следующий день в 22:42 #1009 (12 файлов, +614/−1) добавил привязки Python: ранее у VIR не было ни входной точки конструирования операторов на стороне Python, ни входной точки конструирования типов, имена операторов и описания типов приходилось вручную склеивать в строках, а весь процесс понижения мог работать только в одном исполняемом файле buddy-opt; реализация идёт через ODS-определение операторов плюс C API плюс расширение nanobind, изоморфно диалектам с собственными типами, таким как quant в репозитории, и делится на три части: Ops, Types и регистрация pass. Смысл этого шага в композируемости — описания операторов, вывод форм и тестовые примеры можно писать на стороне Python, и стыковка фронтенда с VIR больше не обязана зависеть от добавления хуков на стороне C++.

K3 decode attention перенесён на VIR: побитовое совпадение чисел, одинаковое число инструкций, перекрывающиеся интервалы пропускной способности

Дата: 2026-10-28　Источники: PR #1014, изменения документации K3, тестовый файл

#1014 слит в 09:36 (4 файла, +476/−14, из них ядро 264 строки, тесты 152 строки, конвейер понижения 10 строк, документация 50 строк), он переносит весь decode attention ядра K3 w4g32 на диалект VIR. Это первый раз, когда сверка велась на ядре реальной модели — с одной стороны написанное ранее вручную RVV-векторное ядро, с другой — собранное на Python ядро VIR, сравнение чисел, числа инструкций и пропускной способности на плате.

Реализация в четыре слоя: слой конструирования больше не склеивает вручную операторы и типы, а идёт через SetVLOp, load, shuffle, fma, reduce из buddy_mlir.dialects.vir, один work item — это регион vir.set_vl длиной в половину размерности головы (64 lane), регион возвращает (max, sum) этой головы; слой вращения загружает q внутри региона, вращает и масштабирует, rotate_half реализуется одной vir.shuffle, cos/sin хранятся как две строки данных равной длины, vir.from_vector больше не нужен; слой представления памяти использует memref.expand_shape, чтобы разрезать q, KV cache, выход и веса нормализации q по последней размерности на 2×64; слой нормализации отдельно открывает одномерный регион vir.set_vl для q/k norm в Qwen3. Параметры конвейера изменены на rvv-vlen=1024, use-scalable=false, старый _attn_decode_fn сохранён для ядра A210.

Три точки проверки: тест выполняет побитовое сравнение _attn_decode_fn, покрывая случаи с потоками и без потоков, начальные точки 0/15/16/37/70; при наличии нормализации q/k покрываются 0/37; путь qk_norm в test_k3_w4_moe.py также прогоняет ядро VIR; check-buddy — 239 плюс 401, все проходят. Машинный код: два параллельных тела по 178 векторных инструкций каждое, цикл по ключам-значениям полностью совпадает со старой версией, изменяются только позиции перезагрузки в двух регистрах переполнения; вращение q превратилось из операции над двумя полугруппами LMUL 2 в vfneg плюс одно перемещение регистра. На K3 пропускная способность жадного декодирования при трёх длинах последовательностей — все интервалы перекрываются (цифры см. в разделе «Главное за неделю»). В PR прямо сказано, что это повторное выполнение уже закрытого #998, а основой для переделки служат последующие четыре коммита (#1000, #1005, #1006, #1009), поэтому это не независимая оптимизация, а разовая нагрузочная проверка фундамента, заложенного предыдущими четырьмя.

Нужна сдержанность: на этот раз «паритет производительности» получен на одной плате K3, при жадном декодировании и на трёх длинах последовательностей; автор также отмечает, что два сбора одного и того же кода могут различаться на 2%. Это доказывает, что VIR больше не вносит потерь производительности, а не то, что VIR уже превосходит рукописное ядро; охват также составляет только одно ядро, A210 по-прежнему использует старую функцию, а пути MoE, квантования и префилла ещё не затронуты.

Новый ABI buddy-server: 56 файлов сводят модальные плагины к единому интерфейсу

Дата: 2026-10-29　Источники: PR #1015, коммит 7d2ce844, анализ упаковки и загрузки RAX

Слитый в 15:08 #1015 (56 файлов, +3934/−1661) — самая масштабная по объёму изменений правка во всём стеке за неделю. Описание PR содержит лишь одну фразу о намерении: обновить ABI-интерфейс, используемый buddy-server при разборе файлов RAX; новый интерфейс облегчает будущую поддержку большего числа моделей.

Структурно «отдельный набор дескрипторов плагинов для каждой модальности» заменён на «единый интерфейс»: добавлены ServerModelABI.h (392 строки), ServerModelABIConversion.h (179 строк), ServerModelPluginAdapters.h (742 строки), ModelError.h (57 строк); удалены разделённые по модальностям реализации четырёх групп AudioTranscription, Embedding, MaskedLM, Resident и ModelPluginDiscovery, вместо них добавлены ServerModelPluginHandle на 350 строк плюс заголовочный файл на 102 строки, а слой адаптеров подключает старые точки входа каждой модальности к новому ABI; один файл BuddyServerApp.cpp +446/−225. На стороне моделей синхронно переписаны пары Model и Plugin в шести каталогах bge_m3, deepseek_r1, llama31_tt, proteinglm, qwen3_vl, whisper.

В тестовой части наиболее примечательно: добавлены ServerModelPluginHandleTest.cpp (325 строк) и четыре класса интеграционных тестов — ошибки ABI, возможности, конкурентность, зависимости; удалены четыре группы юнит-тестов, написанных по модальностям (около 226 строк) — центр тяжести тестирования сместился с «проверить каждую модальность по отдельности» на «сквозное поведение единого ABI», и охват стал шире. Нужна сдержанность: это рефакторинг интерфейса, PR не приводит данных о производительности и не доказывает поддержку новых моделей; «облегчение поддержки большего числа моделей» будет подтверждено только тогда, когда следующая модель будет подключена по новому ABI.

Ритм релизов: после 0.1.2 подряд вышли пять ночных сборок, опорные точки downstream поднимаются одна за другой

Дата: 2026-10-25 — 10-30　Источники: список релизов, ночная сборка v0.1.3.dev20261030, BUDDY MLIR 0.1.2

Версия 0.1.2 официально выпущена 25.10 в 06:18 (описание релиза пустое, сгенерировано автоматическим процессом, изменения приходится восстанавливать из истории коммитов), что завершило паузу длиной в пять выпусков подряд; интервал в семь дней ближе к обычному ритму, чем двухдневный интервал между 0.1.0 и 0.1.1. После этого ночные сборки вернулись к одному выпуску в день: dev20261026 от 26.10 06:37 (первый пакет линии 0.1.3), dev20261027 от 27.10 08:26, dev20261028 от 28.10 07:56, dev20261029 от 29.10 08:21, dev20261030 от 30.10 08:49 — всего пять, все помечены как предварительные.

Разрыв между выпуском пакета и слиянием стоит отметить отдельно, поскольку это фиксированная структура задержек данного стека: слияние в buddy-mlir → ночная сборка следующего дня → renovate предлагает обновление зависимостей → слияние в triton-riscv, три перехода обычно занимают один-два дня. dev20261028 вышел раньше трёх слияний того же утра (#1010 08:54, #1014 09:36, #1012 09:55), поэтому не содержит декодирующего внимания K3; dev20261029 вышел на семь часов раньше #1015, поэтому не содержит новый ABI; только dev20261030 несёт одновременно #1014 и #1015. Линия 0.1.3 уже пять ночных сборок подряд не имеет официальной версии, последней официальной остаётся 0.1.2 — если такое изменение интерфейса, как #1015, пойдёт в официальную версию, придётся ждать ещё один круг.

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

Двухнедельный прогресс, выпуск 079, и пять тем на форуме

Дата: 2026-10-26 — 10-29　Источники: Двухнедельный прогресс, выпуск 079, Обзор саммита RuyiAI #2899, Перепечатка конференции экосистемы Xiangshan Ruyi #2898

На форуме на этой неделе пять новых тем. #2895 от 26.10 18:02 — это выпуск 079 двухнедельного прогресса (отчётный период до 22.10), единственный официальный отчёт на этой неделе; следующий выпуск в двухнедельном ритме ожидается примерно в начале ноября. #2896 «lpi4a UEFI» от 27.10 10:45 опубликован пользователем, приложены три системных скриншота 1366×768 и три фотографии 1920×1440, в тексте говорится, что обновление было обнаружено ещё 26 сентября, терпел целый месяц, прежде чем прошивать, и хотя подходящей под UEFI RevyOS пока нет, «но хотя бы есть надежда» — эта тема фиксирует реальную узкую точку экосистемы прошивок LPi4A: прошивку UEFI можно записать, а сопутствующий образ дистрибутива ещё не подоспел.

Три темы 29.10 сосредоточены на отголосках саммита. #2899 «RuyiAI на шестом саммите RISC-V Китая: практика программного стека AI-систем от RVV к Matrix» вспоминает шэньчжэньский саммит 18–20.10: команда через тематические доклады Tutorial, стендовые презентации и общение на стенде представила архитектуру стека и пути участия, а также приняла участие в техническом семинаре AME и Гонконгском дне RISC-V 21.10, тема — матричные расширения и программная поддержка; текст темы довольно скуден, содержательная часть вынесена во внешнюю статью в официальном аккаунте. #2898 перепечатывает репортаж о дневной сессии форума открытой экосистемы Xiangshan Ruyi: 20.10 были централизованно представлены результаты полного стека программного и аппаратного обеспечения RISC-V «для эпохи интеллектуальных агентов», охватывающие серверные чипы, AI-нативный программный стек, многопоточную архитектуру процессоров, комплект Agile-разработки AI-CPU, оптимизацию согласованности памяти и адаптацию инструментов EDA-верификации — для RuyiAI это задаёт координату экологической ниши, «AI-нативный программный стек» — один из результатов, представленных на том же форуме рядом. Есть также #2897 — перепечатка доклада Бао Юньгана на саммите «Двенадцать лет познания, десять лет перспективы», не вошедшая в ежедневные отчёты этой недели, добавлена в этом выпуске.

Официальный сайт: три страницы без изменений, разрыв между инженерией и коммуникацией продолжает расти

Дата: 2026-10-30 (состояние)　Источники: Официальный сайт RuyiAI, Блог, Документация

sha256 главной страницы, блога и документации совпадают с предыдущим выпуском: в индексе главной страницы 3 записи, в блоге 2 статьи (адаптация Triton для RISC-V, практика PyTorch RISC-V CI), в документации 23 главы. Уже несколько окон подряд нет новых статей блога и глав.

Материала, из которого на этой неделе можно было бы сделать технические статьи, немало: полная цепочка VIR от масштабируемых векторов к привязкам Python и далее к сверке производительности K3, идеи рефакторинга унифицированного ABI в buddy-server, переработка взаимодействия в ruyi-imager 1.1, предложение по определению ABI хоста в ruyi — всё это остаётся в описаниях PR и документации репозиториев, причём три показателя из #1014 — пропускная способность на плате, число инструкций, побитовая согласованность — сами по себе готовый материал для статьи. Внешних точек входа в этот стек по-прежнему всего две статьи сентября, что не соответствует ритму «ежедневные коммиты, еженедельные слияния».

Внешние новости: целевые запросы за всю неделю без попаданий

Дата: 2026-10-30 (состояние)　Источники: Google News RSS, Страница новостей дистрибутива openRuyi

Целенаправленные запросы на китайском и английском по RuyiSDK, RuyiAI, Ruyi RISC-V, компилятору сообщества Ruyi и openRuyi (включая when:3d) дали ноль совпадений во всех пяти выпусках за неделю. Пойманные за тот же период новости, связанные с RISC-V, к сообществу Ruyi отношения не имеют; по дням зафиксировано: описание RISC-V-платформы от MIPS, репортаж о XuanTie C950 от DAMO Academy, демонстрация верификации и прототипов S2C на саммите RISC-V в Китае, продукты интеллектуальных вычислений на основе потоков данных от Zhongke Tongliang, прогресс настольной экосистемы deepin на саммите, RISC-V JIT в Pharo 14, завершение Tenstorrent раунда E на 1,5 млрд долларов, прогресс аэрокосмических вычислений Microchip PIC64-HPSC. Эти пункты не относятся к данной теме, в этот выпуск не включаются и приводятся лишь как внешний ориентир.

Новостная страница openRuyi: в октябре опубликованы две статьи, версия 2026.10 всё ещё не выпущена

Дата: 2026-10-31 (проверка)　Источник: новостная страница openRuyi, анонс Ruyi Firmware, статья об инфраструктуре экосистемы

При повторной проверке новостной страницы дистрибутива на этой неделе обнаружилось расхождение, требующее исправления: в предыдущих пяти выпусках ежедневного отчёта указывалось, что «последняя статья на новостной странице — по-прежнему анонс релиза 2026.09 (9-30)», однако фактически в октябре на странице уже опубликованы две статьи, обе датированы 19 октября 2026 года — «openRuyi-Project: публичная инфраструктура программной экосистемы RISC-V» и «openRuyi выпускает Ruyi Firmware: открытое решение UEFI-прошивки для платформ RISC-V». Обе вышли до текущей недели и не относятся к содержимому этого периода, но показывают, что контентная часть дистрибутива не полностью остановилась; прежнее суждение следует исправить на «анонс месячного релиза не вышел, но в октябре уже есть две тематические статьи».

Вывод по версии не меняется: теги репозитория заканчиваются на 2026.09-experimental, анонс релиза 2026.10 не появился; при месячном ритме 6-30, 7-23, 8-27, 9-30 октябрьская версия уже пропустила конец месяца и становится первоочередным объектом наблюдения в следующем периоде.

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

VIR прошёл путь «выразительность — вызов — сверка», но вывод может быть только «без внесения потерь»

Последние три недели эта основная линия постоянно наращивала выразительность: в ночь на 10-26 семью коммитами добавили масштабируемые векторы, 10-27 добавили привязки Python, 10-28 целиком перенесли декодирующее внимание K3 и провели сверку по пропускной способности на плате. Только три цифры вместе дают смысл этой недели — побитовое совпадение численных результатов, одинаковое число векторных инструкций (по 178 в каждом случае), перекрывающиеся интервалы пропускной способности. Самодельный диалект чаще всего застревает на этапе «работает, но медленно»; на этой неделе как минимум доказано, что этот этап пока пройден.

Однако читать это как «VIR догнал рукописные ядра» было бы перебором. Точная формулировка — «на участке декодирующего внимания K3 при фиксированной длине вектора потерь не вносится». Два пробела очевидны: охват ограничен только декодирующим вниманием, ядра A210, MoE, квантование и путь префилла не затронуты; масштабируемые векторы явно отключены (use-scalable=false), а после включения следующим коммитом размер вектора перестанет определяться на этапе компиляции, предположение о группировке LMUL 4 ослабнет, и тогда нужно будет заново сверять, удержатся ли численные результаты и число инструкций. Автор сам указал в PR разницу в 2% между двумя сборками одного и того же кода — этот порядок величины как раз и очерчивает границы вывода о «паритете».

Управление ветками разошлось: llvm пишет правила и отменяет предварительный прогон, pytorch полагается на переигрывание и синхронизирующего бота

В течение одного месяца две ветки дали два разных ответа. Набор патчей ветки riscv в llvm велик (26 коммитов), внешних вкладов много, основные издержки — конфликты и дрейф истории, поэтому имеет смысл написать документацию (RISCV_CONTRIBUTING.md) и настроить рабочий процесс (autorebase.yml), а шаг «предварительного прогона» удалить — успех означает пуш, трения минимизируются, риск переносится на контрибьютора, а страховкой служат --force-with-lease и повторная проверка SHA. Набор патчей ветки riscv в pytorch мал (11 коммитов), стоимость одного переигрывания самим мейнтейнером ниже стоимости поддержания процесса, поэтому продолжается ежедневное или через день переигрывание всей ветки, плюс синхронизирующий бот поднимает базовую линию до последнего состояния upstream.

Общее у обоих — «локальный набор патчей долго не меняется»: 26 коммитов в llvm и 11 в pytorch, новых функций на этой неделе не появилось ни там, ни там. Правильный способ отслеживать эти две ветки — не смотреть на SHA или число коммитов (переигрывание унифицированно переписывает время автора и раздувает число коммитов вслед за upstream), а смотреть на множество заголовков патчей и на то, что принёс upstream (на этой неделе — перенос 17 pass в NewPM и доработка isel для расширения P).

Чтобы судить, эффективно ли управление веткой, можно смотреть на два проверяемых сигнала: в случае llvm — действительно ли после запуска рабочего процесса стало больше внешних PR (если в течение двух недель никто не отправит коммит по новой базовой линии, значит узкое место не в инструменте перебазирования); в случае pytorch — стабилизировалось ли переигрывание снова до ежедневного (на этой неделе это была одна догоняющая операция после семидневного молчания, то есть работа по выбору момента, а не поток).

Упаковка стала реальным узким местом стека RuyiAI, и у споров начали появляться цены

#1350 Спор длится почти месяц, ключевое разногласие — выносить ли LLVM, поставляемый с buddy-mlir, наружу. На прошлой неделе формулировка была ещё «можно использовать GCC, но как минимум в 1,5 раза дольше», на этой неделе автор приводит измерения: на riscv64 8814 секунд превращаются в 24798 секунд, 2,81 раза, и в случае с GCC сборка падает на этапе линковки. Характер спора таким образом смещается от технических предпочтений к арифметике расписания сборочной фермы — 2,81 раза означает, что занятость машин, политику таймаутов и окна релизов придётся пересчитывать.

Урок этого для всего стека заключается в методе, а не в выводе: многие разногласия вокруг упаковки дистрибутивов RISC-V (вендорить или нет, выносить ли инструментарий, распространять ли IR вместе с пакетом) в конечном счёте сводятся к трём измеримым числам — «время сборки, размер образа, воспроизводимость». На той же неделе openRuyi отзывает курс на «распространение LLVM IR вместе с пакетом» (#1509), а #1350 с множителем 2,81 раза отстаивает «оставить LLVM внутри пакета» — два решения противоположны по направлению, но опираются на один и тот же тип расчёта затрат.

Если посмотреть дальше, замечания к ревью #1350 на этой неделе сместились с дизайна курса к написанию spec (отсутствующие BuildRequires, согласование Provides, формат патчей, пустой комментарий %check), что показывает: вопрос «сможет ли дистрибутив это проглотить» превратился в вопрос «достаточно ли сам пакет обычен». Три нестандартных момента — buddy-mlir несёт собственный LLVM, triton зависит от исполняемого файла git, tilelang должен обнаруживать инструментарий buddy-mlir — каждый требует патчей и объяснений, и каждое объяснение требует времени мейнтейнера на оценку. Если хочется, чтобы трио вошло в месячный ритм релизов, свести их к одному-двум явным соглашениям об упаковке (например, инструментарий единообразно предоставляет buddy-mlir, а патчи единообразно укладываются через git format-patch) будет проще, чем отвечать на замечания ревью по пунктам.

Обещания конца месяца массово сдвинулись: дистрибутив переходит на ритм «месяц на массовую закладку, неделя на зачистку»

На этой неделе два обещания конца месяца одновременно не выполнены: ruyi 0.54.0 по-прежнему представлен только альфой от 09-18, openRuyi 2026.10 не выпущен. В соответствии с этим в 234 коммитах основного репозитория openRuyi на этой неделе — разом 64 пакета фреймворка KDE, связка всей семьи Samba, возврат qemu 11.1.2 и libvirt, 12 обновлений безопасности C/C++ — это типичная «массовая закладка параллельно с зачисткой», а не «заморозка перед сменой версии».

Разница в ритме двух конвейеров тоже заслуживает упоминания: у пакетов KDE есть вышестоящий spec для сверки и установленный ритм версий, пересборка — механическое действие, поэтому 64 пакета удаётся сделать за день; а трио RuyiAI — это spec, написанные с нуля, где нужно объяснять и «почему LLVM остаётся внутри пакета», и «почему %check пуст», и с 09-21 работа идёт до сих пор и всё ещё возвращается на доработку. Способность дистрибутива к «массовой закладке месяца» и стоимость «приёма нового пакета» несимметричны: последняя зависит от того, насколько сам пакет обычен.

Практическое значение для читателя: пользователи ruyi в конце октября всё ещё будут получать 0.53.0; если 0.54.0 выйдет в начале ноября, ещё нужно смотреть, восстановился ли программный источник ISCAS, иначе список пакетов, который видит ruyi update, будет отставать от фактического состояния репозитория. Эти два момента — первоочередные пункты проверки следующего цикла.

Обнаружение дефектов зависит от единственной точки входа, цепочка приёмки хрупче цепочки исправлений

Общий источник трёх исправлений triton-riscv на этой неделе — не набор тестов, а само «перенесение операторов FlagGems на triton-riscv»: маскированная загрузка значений заполнения тензора, смещение gather, переносимое циклом, сравнение повторяющихся индексов у оператора разброса — все три лежат на границе слоя понижения и слоя валидации. Такие дефекты не вырастают в собственном наборе lit компилятора, нужна реальная библиотека операторов, которая будет давить наверх пакетным способом.

Проблема порядка обнажается следом: исправления вошли первыми, а нужный им миграционный PR #56 стоит с 09-16. У партии «исправлений, подготовленных под некоторое использование» временно нет соответствующего использования в работе; если #56 возобновится, а вышестоящий Triton успеет сменить несколько кругов, нужно заново проверять, совместимы ли три исправления с новым базовым уровнем; если он долго не возобновится, этот набор сквозной приёмки попросту остановится, и следующая партия дефектов будет ждать, пока на них наткнутся внешние пользователи. В конце цикла у #56 было одно обновление (10-30 20:50), но слияния всё ещё нет — это самое примечательное место для наблюдения в следующем цикле.

Вывод применим на практике: для стека, целью которого является «запускать реальные модели», превратить миграцию в постоянную регрессию (пусть даже всего несколько десятков операторов, прогон раз в ночь) ценнее, чем слить ещё несколько исправлений. Доказательство на уровне инструментария появилось на той же неделе — проверка #83 — самая весомая из трёх за неделю (291 прохождение lit, 18 проверок времени выполнения), и она же оказалась наиболее глубоко интегрированной с реальными операторами.

Длительная пустота на стороне бенчмарков не даёт ответить на вопрос «эффективна ли оптимизация»

VecIntrinBench остановился на 02-13, cpuinfo — на 05-20, IntrinTrans — на 06-25, FBGEMM — на 07-13; за всю неделю в четырёх репозиториях, связанных с векторизацией, ни одного коммита, срок простоя исчисляется месяцами. Между тем выводы о производительности на этой неделе опираются лишь на диапазон пропускной способности на плате K3, а автор прямо пишет, что две сборки одного и того же кода могут отличаться на 2%; проверка трёх исправлений тоже даёт только число прохождений, без каких-либо показателей качества векторизации (число инструкций, занятость LMUL, число переполнений регистров).

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

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

Список материалов

  • Выпуск от 2026-10-26: окно мониторинга 10-23 04:30 ~ 10-26 04:30 (последние 3 дня, охватывает субботу и воскресенье).
  • Выпуск от 2026-10-27: окно мониторинга 10-26 04:30 ~ 10-27 04:30.
  • Выпуск от 2026-10-28: окно мониторинга 10-27 04:30 ~ 10-28 04:30.
  • Выпуск от 2026-10-29: окно мониторинга 10-28 04:30 ~ 10-29 04:30.
  • Выпуск от 2026-10-30: окно мониторинга 10-29 04:30 ~ 10-30 04:30.
  • Динамика за пределами границ периода (день 10-30 до второй половины дня 10-31) после проверки организационных репозиториев, страниц релизов и источников сообщества была добавлена, см. «Пункты вне ежедневных отчётов, добавленные на этой неделе».

Способ проверки и критерии

  • Проверка организаций (окно 168 часов): охватывает коммиты, PR и релизы трёх организаций RuyiAI-Stack, ruyisdk, buddy-compiler, по двойному каналу Atom и веб-страниц, без зависимости от лимитов API; коммиты вышестоящих fork (PyTorch riscv, LLVM riscv, LLVM main) включаются после фильтрации по ключевым словам, связанным с RISC-V, RVV, векторными расширениями, XuanTie.
  • Статистика основного репозитория openRuyi: после полной постраничной проверки через API, начало окна — пекинское время 10-26 00:00 (UTC 10-25 16:00), конец — 10-30 24:00, получено 234 коммита; при подсчёте по естественным дням в пересчёте на пекинское время по «времени автора коммита» — 80, 36, 36, 73, 9. Объединённые PR по запросу is:merged merged:>= — 52, открытая очередь — 58. Эти критерии отличаются от 24-часовых окон отдельных ежедневных отчётов, поэтому не полностью соответствуют цифрам отдельных выпусков ежедневного отчёта.
  • Дополнительная проверка ключевых репозиториев: openRuyi (последовательные коммиты, PR, теги), homepage проекта openRuyi-Project; qemu (p-dev, ame-0.6), llvm-project (AME), linux-xuantie-kernel, riscv-gcc, wechat-articles, ruyi, ruyi-imager, packages-index, support-matrix, AME-operator из ruyisdk; buddy-mlir из buddy-compiler; pytorch (ветка riscv), triton-riscv, tilelang-riscv, ruyiai-daily, ruyiai-stack.github.io из RuyiAI-Stack.
  • Два источника сообщества: форум разработчиков сообщества RuyiSDK (список последних тем, пять постов на этой неделе) и страница новостей дистрибутива openRuyi (включая проверку дат двух тематических статей за октябрь).
  • Официальный сайт: снимки трёх страниц www.ruyiai.org — главной, страницы блога, страницы документации — и сравнение sha256, с приложением элементов индекса блога и документации (2 статьи блога, 23 главы документации).
  • Временные критерии: коммиты репозиториев пересчитываются по времени автора коммита в пекинское время; описания «ежедневных» событий основаны на последовательных календарных днях; недельный период — пять рабочих дней с 2026-10-26 по 2026-10-30.

Пункты вне ежедневных отчётов, добавленные на этой неделе

  1. 10-30 20:14, triton-riscv слил #55 «Support asin op via frontend patch» (реализация оператора asin через фронтенд-патч), после окна ежедневного отчёта за 10-30.
  2. 10-30 20:50, миграционный PR #56 в triton-riscv «Migrate additional FlagGems operators» возобновил обновление (по-прежнему в открытом статусе), первое действие после 09-16.
  3. 10-30 08:49, buddy-mlir выпустил ночную сборку v0.1.3.dev20261030, впервые одновременно включающую #1014 (декодирующее внимание K3) и #1015 (новый ABI).
  4. 10-31 13:15, #91 в triton-riscv слит, якорь поднят до nightly/v0.1.3.dev20261030 — цепочка из трёх шагов (слияние, ночная сборка, смена якоря нижестоящим проектом) замкнулась в последний день недели.
  5. 10-30 23:00, ветка riscv в llvm-project ещё раз перебазирована и воспроизведена (25 коммитов, время коммиттеров сосредоточено с 23:00:40 по 23:00:44); 10-31 03:00, ветка riscv в pytorch ещё раз перебазирована и воспроизведена, в голове по-прежнему содержит [SyncBots] Integrate PyTorch at 3afdbd3.
  6. 10-30 09:54, ruyisdk/ruyi слил #508 «docs: update vendor naming list», в основном репозитории за неделю всего два коммита, новых релизов по-прежнему нет.
  7. 10-30 12:39, #1514 в openRuyi «ollama: Update to 0.40.7» слит с меткой security-fixes; в тот же день также clang-wrap 20261030 (#1545) и др., всего за период 234 коммита.
  8. Форум #2897 «【Репост】Двенадцать лет осознания, десять лет перспективы: Бао Юньган на саммите RISC-V China Summit 2026 обсудил китайский путь открытых чипов» (опубликовано 10-29), в ежедневные отчёты этой недели не попало, добавлено в этом выпуске.
  9. Уточнение данных новостной страницы openRuyi: в октябре уже опубликованы две тематические статьи (обе помечены как опубликованные 10-19), прежнее утверждение «последним по-прежнему остаётся анонс релиза 2026.09» ошибочно; анонс ежемесячного релиза 2026.10 всё ещё не появился.

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

Источники Результаты проверки
Организация RuyiAI-Stack (все репозитории) pytorch: ветка riscv семь дней молчания (22.10–28.10), 29.10 в 14:06 полное перевоспроизведение 11 коммитов, в 20:48 SyncBots поднял до upstream 3afdbd3, основная ветка ежедневно около 20 коммитов, все — upstream; llvm-project: ветка riscv 26.10 и 27.10 дважды перебазирована (базовая линия сдвинута на 221 и 237 коммитов), 28.10 добавлен рабочий процесс autorebase, 29.10 перевоспроизведение и новый гайд по участию, 17 upstream RISC-V pass перенесены в NewPM; triton-riscv: три понижающих исправления слиты, два обновления анкеров (#90 слит, #91 в тот день не слит); tilelang-riscv четырнадцатый день молчания; ruyiai-daily пять выпусков; FBGEMM, cpuinfo, VecIntrinBench, IntrinTrans, torq-tile, pytorch-ci, dsh-osc без коммитов
Организация ruyisdk (все репозитории) ruyi-imager: предрелиз v1.1.0-rc.1 (29.10), на этой неделе также предшествующие коммиты по UFS/UEFI, диалоговому взаимодействию, унификации терминологии; основной репозиторий ruyi два коммита (документ списка именований производителей, слияние #508), новых версий нет, 0.54.0 только с тегом alpha; packages-index один коммит (образ revyos Milk-V Meles и uboot подняты до 20260504); support-matrix три отчёта по платам (Jupiter2 Bianbu 4.0.1, K3 Pico-ITX Bianbu 4.0.8 оценён как good, VisionFive 2 Lite Ubuntu 24.04.5 оценён как basic); wechat-articles, ruyisdk-website, docs, AME-operator без коммитов в окне мониторинга
Организация openRuyi-Project Основной репозиторий 234 коммита, 52 слитых PR, 58 открытых; категории включают пакет KDE Frameworks 6.31.0 — 64 коммита, связанное обновление всего семейства Samba, обновления безопасности 12 пакетов, qemu 11.1.2, libvirt два коммита, три revert (отзыв распространения LLVM IR), 13 новых пакетов экосистемы Go, включение vkpeak; теги заканчиваются на 2026.09-experimental, 2026.10 не выпущен
Организация buddy-compiler buddy-mlir: VIR семь коммитов (#1002–#1008), Python-привязки #1009, реорганизация исходников buddy-server #1010, Whisper x64 CI #1012, декодирующее внимание K3 #1014, новый ABI #1015; официальная версия 0.1.2 и пять ночных сборок (dev20261026–dev20261030); три открытых PR без обновлений с 28.10 (#1011, #1013, #994)
riscv/riscv-arch-test Прежний путь организации riscv-arch-test уже 404, репозиторий перенесён в организацию riscv; в окне понедельника (23.10–25.10) 30 коммитов, в основном слияние наборов тестов и дополнение расширения H
Форум сообщества разработчиков RuyiSDK На этой неделе пять постов: выпуск 079 (26.10), lpi4a UEFI (27.10), обзор саммита RuyiAI и репост конференции экосистемы Xiangshan Ruyi, репост выступления Бао Юньгана (все 29.10); выпуск 080 не вышел
Страница новостей дистрибутива openRuyi Две тематические статьи за октябрь (обе помечены как опубликованные 19.10); анонс ежемесячного релиза по-прежнему 2026.09 (30.09), 2026.10 не выпущен; теги репозитория заканчиваются на 2026.09-experimental
Пакетный менеджер ruyi / теги 0.53.0 сохраняется, у 0.54.0 только alpha от 18.09; в основной ветке на этой неделе два коммита; обещание «релиза в конце октября» по состоянию на 31.10 не выполнено
ruyi-imager / Releases v1.1.0-rc.1 опубликован 29.10 в 16:02 (предрелиз), включает четыре изменения взаимодействия и CLI
Официальный сайт (ruyiai.org) Три страницы без изменений: индекс главной 3 записи, блог 2 статьи, документация 23 главы, sha256 совпадает с предыдущим выпуском
Upstream IREE В коммитах окна нет специализированных изменений для RISC-V
arXiv (RISC-V) За всю неделю нет новых; последние — SecDMP и генератор C-кода TinyML от 27.10, длинновекторный FlashAttention от 21.10 по-прежнему ближе всего к RVV
Google News RSS (несколько наборов на китайском и английском) Целевые запросы RuyiSDK, RuyiAI, Ruyi RISC-V, openRuyi за все пять выпусков недели дали ноль совпадений; новости RISC-V за тот же период не связаны с сообществом Ruyi и не включены

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

riscv PR #56 миграция операторов FlagGems — https://github.com/RuyiAI-Stack/triton-riscv/pull/56

ir K3 документация — https://github.com/buddy-compiler/buddy-mlir/blob/main/docs/K3DeepSeekR1.md

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