Окно мониторинга: 2026-10-29 04:30 ~ 2026-10-30 04:30 (пекинское время, последние 24 часа), стыкуется с предыдущим выпуском (отсечка 10-29 04:30).

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

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

  • Главное за день: triton-riscv — три слияния за день, все восходят к деградационным дефектам, выявленным при миграции операторов FlagGems (10-29)
    1. Прогресс стека RuyiAI (адаптация PyTorch / Triton / TileLang под RISC-V)
      • 1.1 pytorch: ветка riscv завершила седьмой день молчания, после полного переигрывания ветки поднята до апстрима 3afdbd3 (10-29)
      • 1.2 llvm-project: полное переигрывание ветки riscv, добавлено руководство по участию и отменён переключатель предварительного прогона (10-29)
      • 1.3 triton-riscv: три исправления деградации слиты за 80 минут, обновление зависимостей всё ещё открыто (10-29)
      • 1.4 tilelang-riscv: четырнадцатый день молчания основной ветки (состояние на 10-29)
    1. Инструментарий и дистрибутивы RuyiSDK
      • 2.1 openRuyi: 76 коммитов, 10 слияний, KDE Frameworks 6.31.0 разом покрыл 64 пакета (10-29)
      • 2.2 Пакетная плоскость openRuyi: принят vkpeak, исправлен путь модуля cmake, ежедневное обновление clang-wrap (10-29)
      • 2.3 openRuyi на рассмотрении: первый раунд код-ревью #1350 — 18 замечаний, обновление безопасности ollama ожидает слияния (состояние на 10-29)
      • 2.4 Выпущен ruyi-imager 1.1.0-rc.1, у ruyi 0.54.0 по-прежнему нет beta (10-29)
      • 2.5 Основной репозиторий ruyi: обновлён перечень наименований производителей, дополнено предложение по детектированию ABI (10-29 / 10-28)
    1. Векторные расширения, тестирование архитектуры и оптимизация операторов
      • 3.1 Четыре векторных репозитория продолжают молчать, пробел на стороне бенчмарков сохраняется (состояние на 10-29)
      • 3.2 Миграция FlagGems стала механизмом обнаружения дефектов для triton-riscv (10-29)
      • 3.3 В окне arXiv новых нет, две статьи от 10-27 — последние (состояние на 10-29)
    1. Динамика Buddy Compiler
      • 4.1 Слит новый ABI buddy-server: 56 файлов, система плагинов моделей переведена на единый интерфейс (10-29)
      • 4.2 Ночная сборка dev20261029 вышла раньше #1015, нижестоящим ждать следующей версии (10-29)
      • 4.3 Три на рассмотрении застряли на 10-28, Whisper и выравнивание интерфейсов без движения (состояние на 10-29)
    1. Сообщество, мероприятия и официальный сайт
      • 5.1 Три страницы официального сайта без изменений, две записи в блоге, двадцать три главы документации (состояние на 10-29)
      • 5.2 Два поста на форуме: обзор саммита RuyiAI и репост конференции экосистемы Xiangshan Ruyi (10-29)
      • 5.3 Один выпуск ruyiai-daily, охват разведданных — PyTorch, LLVM, Triton и RISC-V (10-29)
      • 5.4 Внешние новости — ноль совпадений, ни openRuyi 2026.10, ни 0.54.0 не выпущены (состояние на 10-29)
    1. Наблюдения за трендами
      • 6.1 Исправления раньше приёмки: три исправления опираются на заявки, накопленные в ходе миграции, а не на регрессионные тесты
      • 6.2 Два подхода к управлению ветками: llvm пишет правила и отменяет предварительный прогон, pytorch полагается на полное переигрывание ветки
      • 6.3 Дистрибутив наращивает объёмы помесячно, триада уровня стека застревает на ревью помесячно

Главное за день: triton-riscv — три слияния за день, все восходят к деградационным дефектам, выявленным при миграции операторов FlagGems (10-29)

Дата: 2026-10-29　Источник: PR #58, PR #83, PR #82, список коммитов

В течение 80 минут с 15:38 до 16:58 в основную ветку triton-riscv последовательно влиты три коммита, автор всех — maochuanjun, и все они затрагивают один и тот же слой — путь понижения Triton в структурированный/неструктурированный IR. По времени это необычно: предыдущий коммит кода в этом репозитории, не связанный с обновлением зависимостей, был #86 от 10-09, между ними двадцать дней присутствовали только ночные якоря renovate, а сами эти три коммита провисели 82, 43 и 44 дня соответственно, прежде чем были влиты.

Каждый из трёх коммитов нацелен на конкретный дефект. #83 (16:38, 4 файла, +160/−16) исправляет маскированную загрузку с неоднородным тензорным заполняющим значением, то есть конструкцию вида tl.load(ptr, mask=mask, other=cur). Исходная реализация признавала заполняющее значение только скаляром или splat, а при настоящем тензоре застревала на извлечении скаляра, и в понижённом IR оставались неподдерживаемые операции с указателями; исправление состоит в том, что обе ветки — структурированная загрузка и неструктурированный gather — поддерживают тензорное заполнение, несовпавшие каналы восстанавливаются через arith.select(mask, loaded, other), одновременно допускается неудача извлечения скаляра без ошибки, а обработка возвращается вызывающей стороне. #58 (16:58, 2 файла, +125/−0) исправляет потерю переносимого циклом смещения gather: как только тензор, переносимый в scf.for, выходит из структурированной формы, вспомогательное состояние остаётся лишь нейтральным заполнителем, и восстановление результата цикла с его помощью схлопывает gather/scatter в непрерывные tts.make_tptr, все накопленные в цикле смещения теряются; исправление сначала проверяет, что анализируемый операнд действительно является результатом scf.for, и если да, напрямую сохраняет исходный результат цикла в качестве смещения, а также добавляет регрессионный тест loop_result_gather.mlir. #82 (15:38, 1 файл, +23/−3) исправляет недетерминированность теста scatter: исходный тест использовал случайные индексы, допускал повторяющиеся целевые позиции, и при нередукционном scatter любой победивший исходный элемент был законен, однако сравнение велось точно с единственным результатом PyTorch CPU; исправление переводит сравнения 1D, 2D и in-place на уникальные целевые индексы, дополнительно добавляет шесть случаев с повторяющимися индексами (три длины 512, 1023, 1024, по одной группе in-place и не in-place), проверяя лишь то, что победившее значение происходит из набора источников правильной цели, а непопавшие цели сохраняют исходное значение.

Мотивация всех трёх коммитов записана в описаниях PR и указывает на одно и то же место: миграцию операторов FlagGems. #83 обслуживает реализацию unique_dim, #58 обслуживает broadcast_to (это ядро ранее, чтобы обойти данную ошибку компиляции, заменило range(MAX_DIMS) на tl.static_range), #82 — это исправление теста, вынужденное провалом сравнения оператора scatter в ходе миграции. Иными словами, эти три коммита — не дефекты, обнаруженные регрессионными тестами, а дефекты, выдавленные самим процессом «перенести партию операторов PyTorch на triton-riscv и запустить их».

Стоит отметить глубину проверки. #83 явно указывает проверку на машине riscv64, связанной с RuyiAI: все три RUN/FileCheck нового регрессионного теста проходят, полный набор lit — 291 прошёл, 9 ожидаемых падений, 0 неожиданных падений, рантайм-проверки тензорного заполнения — 18 пройдено (покрывают обе ветки, структурированную и gather, float32/float64/int64, пустую маску/частичную маску/полную маску, отрицательный ноль, NaN и недопустимое смещение gather при промахе), интеграция с обновлённым unique_dim — 23 пройдено. #58 прогнал только целевой регрессионный тест TritonToStructured, #82 прогнал только этот файл теста (21 прошёл) — глубина проверки у трёх коммитов неодинакова: первые два скорее локальные, третий — в пределах одного файла.

Требует сдержанности вопрос причинного порядка: исправления влиты раньше, а PR миграции #56, которому эти исправления нужны, всё ещё стоит на 09-16, открыт и не слит. Это означает, что после влития трёх коммитов обходной путь с tl.static_range в broadcast_to можно отозвать, а unique_dim можно отправить в исходном виде, но вопрос «запустится ли вся партия операторов на riscv64» в этом выпуске остаётся без ответа — нужно дождаться возобновления продвижения #56, чтобы проверить.

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

1.1 pytorch: седьмой день тишины ветки riscv завершён, после полного переигрывания ветка поднята до апстрим-коммита 3afdbd3 (10-29)

Дата: 2026-10-29　Источники: ветка pytorch riscv, коммит SyncBots 5a29c201, PR #51, PR #44

После семи дней подряд без коммитов ветка riscv в 14:06 выполнила полное перебазирование ветки: время коммиттера у 11 уже существующих патч-коммитов в ветке было унифицированно перезаписано на одну и ту же секунду (14:06:45), время автора осталось прежним — это типичный след перебазирования на новую базовую точку, а не новая разработка. Перебазирование сохранило исходный набор патчей, включая «Add riscv64 image locally (#51)», «Fix bytes_to_scalar for float/complex on RISC-V (#44)», а также более ранние изменения CI и допусков тестов.

В 20:48 был добавлен ещё один коммит [SyncBots] Integrate PyTorch at 3afdbd3, изменяющий только одну строку в cmake/Dependencies.cmake: к кэш-переменной KINETO_SOURCE_DIR добавлен FORCE. Изменение небольшое, но смысл однозначен — базовая точка ветки поднята до upstream 3afdbd3, и этот коммит сгенерирован автоматически синхронизационным ботом, не требуя ручного решения.

Одновременно наблюдается расхождение: на стороне дистрибуции python-torch-ruyiai (openRuyi #1352) остановился на 10-27, в этом выпуске не двигался; голова ветки уже переключена на новую базовую точку. Если этот пакет собирается из артефактов ветки, зафиксированная в пакете точка привязки исходного кода требует повторного выравнивания, и этим шагом сейчас не занимается ни один PR. У семи открытых PR (#23, #35, #36, #38, #43, #46, #48) время updated у всех — 20:47:49, это массовое обновление, вызванное пушем ветки, и его нельзя считать обновлением содержимого; две основные линии RVV (#46 — поддержка векторных расширений для ATen, #48 — возможности RISC-V Vector CPU) в этом выпуске по-прежнему без новых коммитов.

1.2 llvm-project: полное перебазирование ветки riscv, добавлено руководство по внесению вклада и отменён переключатель предварительного прогона (10-29)

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

Около 23:00 ветка riscv выполнила полное перебазирование ветки: у видимых 25 коммитов время коммиттера всё попадает в интервал с 23:00:40 по 23:00:44, то есть в 4 секунды. Среди содержимого перебазирования есть один действительно новый элемент — [workflows] Push rebased PRs directly and document contribution options (время автора 10-29 09:59), изменяющий два файла: в autorebase.yml удалено 8 строк (убраны вход dry_run и соответствующие ветки предварительного прогона), добавлен файл RISCV_CONTRIBUTING.md на 82 строки.

Это руководство описывает «как отправлять что-либо в ветку riscv» двумя путями. Путь первый — сначала открыть issue, затем maintainer от текущей riscv отводит рабочую ветку work/issue-NNN, контрибьютор отправляет PR в рабочую ветку, а maintainer после интеграции вливает её в riscv — подходит для совместной работы нескольких человек и рабочих элементов, требующих стабильной истории. Путь второй — отправлять PR напрямую в riscv и при изменении базовой точки вручную запускать рабочий процесс перебазирования: рабочий процесс выполняется в исходном репозитории PR, использует GITHUB_TOKEN исходного репозитория и с --force-with-lease и явно указанным ожидаемым SHA пушит обратно в исходную ветку; при конфликтах всегда выбирается сторона riscv (включая конфликты изменение/удаление, где сохраняется удаление со стороны riscv), эквивалентные патчи автоматически пропускаются, сама riscv никогда не перезаписывается и автоматическое слияние никогда не выполняется.

По сравнению с тем рабочим процессом на 244 строки из прошлого выпуска наибольшее изменение — предварительный прогон отменён: в прошлом выпуске по умолчанию было «только предварительный прогон, без пуша», в этом выпуске стало «успех — значит пуш, без варианта предпросмотра», и в документации это прямо написано. Это снижает трение, но одновременно переносит риск на более ранний этап — локальная ветка контрибьютора должна своевременно синхронизироваться, иначе старая история базовой точки может быть возвращена; в документации есть специальный абзац с напоминанием сохранять незакоммиченную работу и не возвращать старую базовую точку в удалённый репозиторий. Ещё одна деталь заслуживает фиксации: в документации прямо сказано, что пуш с GITHUB_TOKEN обычно не запускает последующие рабочие процессы push/PR, поэтому факт запуска CI на обновлённом SHA требует ручного подтверждения.

1.3 triton-riscv: три исправления деградации влиты за 80 минут, обновление зависимостей всё ещё открыто (10-29)

Дата: 2026-10-29　Источники: PR #58, PR #83, PR #82, PR #91, PR #56

Технические детали трёх исправлений раскрыты в разделе «Главное за сегодня» этого выпуска, здесь же дополним тремя замечаниями о состоянии. Во-первых, после слияния трёх коммитов в основной ветке в пределах окна мониторинга новых коммитов кода не появилось — последняя запись в git log по-прежнему остаётся на #58, что говорит о разовой масштабной зачистке, а не о непрерывной разработке. Во-вторых, #91 от renovate поднимает ночную сборку вышестоящего buddy-mlir с nightly/v0.1.3.dev20261027 до dev20261029 (+2/−2, один файл); после слияния #58 29 октября в 16:58 была выполнена однократная пересборка, PR по-прежнему открыт и доступен для слияния со статусом unstable — именно это обновление зависимости служит каналом, через который нижестоящие проекты получают #1015, подробнее в 4.2. В-третьих, среди открытых PR #55 (фронтенд-патч оператора asin) обновился в 18:06, #56 (миграция операторов FlagGems) остановился на 16 сентября, а #54, #57, #59, #72, #75, #85, #46 не проявляли активности в пределах окна — в частности, #85 «оптимизация softmax и matmul» не обновлялся с 18 октября; это основная линия производительности, за ней стоит последить в дальнейшем.

1.4 tilelang-riscv: четырнадцатый день молчания основной ветки (состояние на 10-29)

Дата: 2026-10-29 (состояние)　Источники: список коммитов tilelang-riscv, список открытых PR

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

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

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

2.1 openRuyi: 76 коммитов, 10 слияний, KDE Frameworks 6.31.0 одним разом закрывает 64 пакета (10-29)

Дата: 2026-10-29　Источники: PR #1513 KDE Frameworks 6.31.0, PR #1532 Gradio, PR #1533 pyvex, PR #1531 graphql-core, список коммитов основного репозитория

В этом выпуске в основном репозитории 76 коммитов и 10 слитых PR; время коммитов простирается с 29 октября 15:05 до 30 октября 00:20 — масштаб почти втрое больше предыдущего выпуска (27 коммитов), и причина вполне конкретна: единовременное обновление KDE Frameworks 6.31.0 закрыло 64 пакета kf6-*. Весь этот пакет был залит в одну и ту же минуту в 15:11 (#1513), от kf6-kcoreaddons, kf6-kconfig до kf6-kio, kf6-ksvg, kf6-kwallet — практически полностью охватывая набор фреймворков, от которых зависит Plasma 6. В предыдущем выпуске этот PR ещё значился как WIP и находился в очереди на рассмотрение, а за один день превратился в слитый — это показывает, что отслеживание версий десктопного стека обладает возможностью пакетной пересборки.

Остальные включения — это обычное сопровождение версий и исправления упаковки: Gradio 6.31.0 и его зависимости (#1532, включая gradio-client 2.7.2, python-brotli 1.2.1), python-pyvex 10.0.5 (#1533), ручная правка эпохи provides для python-graphql-core (#1531). Прямых компонентов стека RuyiAI здесь нет, но серия исправлений метаданных на стороне python по-прежнему остаётся той же основой для последующих путей сборки wheel для triton/tilelang — scikit-build-core и метаданные cmake из прошлого выпуска относятся к тому же классу работ.

Стоит отметить распределение по времени: 64 пакета KDE сгруппированы в одну минуту в 15:11, остальные 12 коммитов разбросаны с 15:05 до 00:20 следующего дня, что говорит о том, что эта партия коммитов — скриптованное массовое обновление с ручной доводкой, а не поштучные ручные коммиты по каждому пакету.

2.2 Сторона упаковки openRuyi: добавление vkpeak, исправление путей модулей cmake, ежедневное обновление clang-wrap (10-29)

Дата: 2026-10-29　Источники: PR #1349 vkpeak, PR #1536 ecbuild, PR #1535 clang-wrap, PR #1537, PR #1538, PR #1539

Один новый пакет: vkpeak (#1349, включён в 16:38) — инструмент для определения пиковой производительности Vulkan и возможностей устройства, полезный для оценки графики и вычислительных возможностей на платах RISC-V, относится к категории «есть железо, нет инструментов измерения». Три коммита по инфраструктуре упаковки: модули cmake для ecbuild теперь устанавливаются в %{_libdir} (#1536), исправлена проблема попадания в нестандартный путь; clang-wrap обновлён до 20261029 (#1535), сохраняется ритм упаковки в тот же день, что и upstream; исправление эпохи provides для python-graphql-core (#1531).

Ещё три коммита — чистая очистка графа зависимостей: #1537 удаляет дублирующий пакет go-github-smartystreets-assertions, устраняя конфликт выбора одного из многих; #1538, #1539 добавляют отсутствующие provides import path для go-golang-x-text, go-github-hexops-gotextdiff, go-github-magefile-mage. Подобные проблемы не мешают установке пакета, но при разрешении зависимостей заставляют dnf выбирать неверную версию — это скрытая стоимость долгосрочного сопровождения дистрибутива.

2.3 openRuyi на рассмотрении: 18 замечаний первого раунда проверки на уровне кода по #1350, обновление безопасности ollama ожидает включения (статус 10-29)

Дата: 2026-10-29 (статус)　Источники: PR #1350 Ruyiai packages, PR #1514 ollama, PR #1490 кросс-тулчейн, PR #1516 qemu-rustsbi

#1350 (набор из трёх: buddy-mlir, python-triton-ruyiai, python-tilelang-ruyiai) в этом выпуске впервые получил проверку на уровне кода: misaka00251 с 16:19 по 16:24 подряд отправил 5 замечаний, все касаются написания spec, а не архитектурного подхода — между BuildOption(xxx) не нужно вставлять пустые строки; в python-triton-ruyiai отсутствует BuildRequires: python3dist(wheel), Provides должны соответствовать фактическому имени пакета; необходимость Conflicts: python-%{srcname} требует пояснения; патчи нужно создавать через git format-patch, к тому же в том же каталоге есть неиспользуемый патч; пустой %check должен содержать комментарий с объяснением причины. Размер PR вырос до 10 файлов, +796/−0, общее число замечаний проверки — 18, статус по-прежнему unstable, не включён.

Если читать этот раунд вместе с предыдущими, видно, что центр спора смещается: до 10-27 вопрос был «нужно ли выносить LLVM, поставляемый с buddy-mlir, наружу» (автор отстоял сохранение его в пакете, приведя 2.81-кратное время сборки), а в этом выпуске акцент перешёл на механическую проработку спецификации. Подобные замечания обычно появляются на этапе «направление уже одобрено, идёт подготовка к завершению», но нельзя исключать и того, что это лишь рутинная сверка — будет ли изменение включено, по-прежнему зависит от того, даст ли кто-то approve в следующем раунде.

Остальные состояния очереди на рассмотрении: #1514 обновляет ollama до 0.40.7 и помечен security-fixes, обновлён 10-30 в 02:04, +259/−3371 (масштаб удаления каталога vendor), не включён; #1516 qemu-rustsbi обновлён в 22:36; #1540 пакет исправлений зависимостей Prometheus v3.13 обновлён в 17:01; #1534 simdjson 5.0.8 и офлайн-тесты обновлены в 16:27; #1490 кросс-тулчейн riscv64 по-прежнему помечен WIP и застыл на 10-28, что вместе с уже включённым макросом мажорной версии тулчейна образует состояние «точка входа есть, а тулчейна ещё нет».

2.4 Выпуск пакета ruyi-imager 1.1.0-rc.1, у ruyi 0.54.0 по-прежнему нет beta (10-29)

Дата: 2026-10-29　Источники: ruyi-imager v1.1.0-rc.1, коммит 839a8f56, ruyi Releases, теги ruyi

В 16:02 ruyi-imager выпустил v1.1.0-rc.1, примерно через семь недель после 1.0.0 (09-10). Четыре изменения: на шаге выбора образа добавлено действие загрузки (#12), вывод CLI приведён в соответствие с кодировкой терминала, а JSON сохраняет UTF-8 (#14), двойной клик в диалоге выбора сразу подтверждает (#19), в диалоге выбора требуется явный выбор (#21). Все четыре — шлифовка удобства использования, причём «подтверждение двойным кликом» и «обязательный явный выбор» представляют собой пару взаимодополняющих ограничений взаимодействия: первое ускоряет, второе предотвращает ошибочный выбор. В примечаниях к релизу также отмечен первый контрибьютор (qingwan12138), три из четырёх коммитов принадлежат одному человеку. В тот же день в 15:40 был коммит «Bump base version to 1.1.0» — подготовка версии перед выпуском пакета.

Тем временем у пакетного менеджера ruyi 0.54.0 по-прежнему нет beta: в списке тегов после 0.54.0-alpha.20260918 новых тегов нет, последней стабильной версией остаётся 0.53.0 от 09-24, а в основной ветке с 09-25 нет коммитов. Формулировка из двухнедельного отчёта о прогрессе, выпуск 079, такова: «из-за корректировки цикла выпуска перенесено на конец октября». Текущее окно — уже предпоследний день октября, а кандидата в релизы всё нет — при месячном ритме 6-30, 7-23, 8-27, 9-24 этот выпуск является последним окном, в котором ещё можно выполнить обещание «конец октября».

2.5 Основной репозиторий ruyi: обновление списка наименований производителей, дополнение предложения об ABI-зондировании (10-29 / 10-28)

Дата: 2026-10-29　Источники: PR #508 список наименований производителей, PR #507 ABI-зондирование

#508 «docs: update vendor naming list» обновлён в 16:13, это изменение на стороне документации и представляет собой другой конец того же дела, что и замена в ruyi-imager в этом выпуске «производителя» на «поставщика» в интерфейсе — установщик изменил формулировку, а список наименований производителей на стороне документации выровнен с ним, чтобы избежать расхождений в названиях в двух местах.

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

3. Векторные расширения, тестирование архитектуры и оптимизация операторов

3.1 Четыре векторных репозитория продолжают хранить молчание, пробел на стороне бенчмарков сохраняется (состояние на 10-29)

Дата: 2026-10-29 (статус)　Источники: 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% между двумя сборками одного и того же кода», и делать выводы на основе пропускной способности на плате и так непросто; если сторона VecIntrinBench продолжит стоять на месте, то в дальнейшем вопрос «действительно ли оптимизация что-то улучшает» долгое время придётся выяснять вручную. Это не новая проблема текущего выпуска, но три слитых изменения высветили её ещё яснее.

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

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

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

Методологическая ценность этого события выше самих трёх исправлений: для стека AI на RISC-V с входом через Triton миграция FlagGems фактически выполняет роль «приёмки end-to-end», будучи ближе к реальной нагрузке, чем lit-набор компилятора. С другой стороны, текущий выпуск обнажил и единичную зависимость этого механизма — PR миграции #56 не обновлялся с 09-16, и после слияния трёх исправлений процесс приёмки, наоборот, остановился. Если #56 не будет продвигаться длительное время, этот «механизм обнаружения дефектов» перестанет работать, и следующая партия дефектов будет обнаружена лишь тогда, когда на них наткнутся другие пользователи.

3.3 В окне arXiv новых поступлений нет, две статьи от 10-27 — самые свежие (статус 10-29)

Дата: 2026-10-29 (статус)　Источники: поиск по arXiv

Поиск по условиям RISC-V плюс компиляторы, векторы, MLIR не дал новых статей в окне. Две самые свежие найденные статьи датированы 10-27: SecDMP: Provably Secure Data Memory-Dependent Prefetching (доказуемо безопасная схема зависимой от данных памяти префитчинг-выборки) и A lightweight C Code Generator for Heterogeneous TinyML Systems (лёгкий генератор C-кода для гетерогенных TinyML-систем). Первая связана с безопасной предвыборкой на стороне микроархитектуры, вторая относится к генерации кода на периферийных устройствах — обе не лежат непосредственно на пути компиляции стека AI.

Наиболее близкой к основной теме текущего выпуска остаётся статья от 10-21 Reorienting the Vector Axis: Restructuring FlashAttention for Long-Vector Processors — реструктуризация FlashAttention для процессоров с длинными векторами, относящаяся к тому же классу задач, что и подход от 10-28 с сегментированием декодирующего внимания по 64 lanes и одним LMUL-4-группированием на голову; в окне продолжения не последовало.

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

4.1 Слияние нового ABI buddy-server: 56 файлов, система плагинов моделей переведена на единый интерфейс (10-29)

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

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

По структуре «отдельный набор дескрипторов плагинов для каждой модальности» заменён на «единый интерфейс». Добавлены четыре заголовочных файла уровня рантайма: ServerModelABI.h (392 строки), ServerModelABIConversion.h (179 строк), ServerModelPluginAdapters.h (742 строки), ModelError.h (57 строк); одновременно удалены прежние реализации, разбитые по модальностям: AudioTranscriptionModelPluginHandle, EmbeddingModelPluginHandle, MaskedLMModelPluginHandle, ResidentModelPluginHandle и ModelPluginDiscovery, вместо них добавлен ServerModelPluginHandle на 350 строк плюс заголовочный файл на 102 строки, а адаптерный слой подключает старые точки входа каждой модальности к новому ABI. В одном файле BuddyServerApp.cpp изменения +446/−225, в SimpleHttpServer добавлено 25 строк (связано с разбором запросов и возвратом ошибок).

На стороне моделей синхронно переписаны семь каталогов: bge_m3 (эмбеддинги), deepseek_r1, llama31_tt, proteinglm (маскированные языковые модели), qwen3_vl (визуально-языковые), whisper (транскрипция аудио) — пары Model и Plugin скорректированы согласованно, каждая пара имеет форму «меньше кода на стороне C++, больше кода в общей части» — это та же линия, что и реорганизация исходников в #1010 из предыдущего выпуска: сначала разделить каталоги по ответственности, затем свести интерфейсы в один слой.

Наиболее примечательная часть этого изменения — тесты: добавлены ServerModelPluginHandleTest.cpp (325 строк), BuddyServerAbiErrorIntegrationTest.py (184 строки), BuddyServerCapabilityIntegrationTest.py (135 строк), ServerModelConcurrencyFakePlugin.cpp (162 строки), ServerModelDependencyPlugin.cpp (38 строк) и ServerModelErrorFakePlugin.cpp (149 строк), а также удалены четыре набора модульных тестов по модальностям (в сумме около 226 строк). То есть центр тяжести тестирования сместился с «прогнать тесты для каждой модальности» на «четыре класса поведения единого ABI: ошибки, возможности, конкурентность, зависимости» — покрытие при этом стало шире. На стороне документации обновлены RAXPackagingAndLoadingAnalysis.md и Runtime.md.

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

4.2 Ночная сборка dev20261029 вышла до #1015, нижестоящим проектам ждать следующей версии (10-29)

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

Ночная сборка v0.1.3.dev20261029 выпущена в 08:21, почти на семь часов раньше слияния #1015 (15:08), поэтому эта версия не содержит нового ABI. Чтобы получить #1015, нужно дождаться сборки dev20261030, а затем поднять якорь через renovate в triton-riscv (#91 сейчас закреплён на dev20261029 и остаётся открытым).

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

4.3 Три PR на рассмотрении застыли на 10-28, Whisper и выравнивание интерфейса не двигались (состояние на 10-29)

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

После слияния #1015 из прежних «четырёх на рассмотрении» осталось три: #1011 (принудительное приведение счётчика масштабируемых фрагментов VIR к int64), #1013 (повторное использование предобработки в рамках одной транскрипции Whisper), #994 (выравнивание интерфейса buddy-server на llama-server). Время последнего обновления всех трёх — между 10-28 16:01 и 16:01, в окне мониторинга новых действий нет.

Положение #1011 несколько деликатное: зелёный CI x64 для #1012 из прошлого выпуска был получен поверх него, а сам он до сих пор не слит; #1015 уже изменил плагинный интерфейс buddy-server, и вопрос о том, не войдёт ли направление интерфейса «выравнивание на llama-server» из #994 в конфликт с новым ABI, в PR не обсуждается. В списке открытых также #993 (распознавание tile.upsample_nearest), #1001 и #997 (оптимизация prefill/decode для Qwen3-0.6B и DeepSeek-R1-Distill-Qwen-1.5B на K3 A100), #995 (непрерывный обход Cumsum по не последней оси), #992 (исправление broadcast по каналам bn), #938, #932, #928, #924, #838 — обновлений в окне мониторинга нет.

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

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

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

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

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

5.2 Два поста на форуме: обзор саммита RuyiAI и перепечатка конференции экосистемы Xiangshan Ruyi (10-29)

Дата: 2026-10-29　Источники: обзор саммита RuyiAI #2899, перепечатка конференции экосистемы Xiangshan Ruyi #2898, сообщество разработчиков RuyiSDK

На форуме в этом выпуске два поста, оба опубликованы 10-29. В категории RuyiAI #2899 «RuyiAI на шестом саммите RISC-V China: практика AI-стека системного ПО от RVV до Matrix» освещает шэньчжэньский саммит 10-18 — 10-20: команда через тематические доклады Tutorial, стендовые постеры и общение на стенде представила архитектуру стека и способы участия, а также приняла участие в техническом семинаре AME и RISC-V Hong Kong Day 10-21, тематика которых вращалась вокруг матричных расширений и поддержки ПО. Текст поста очень краткий, содержательная часть вынесена по внешней ссылке на статью в официальном аккаунте.

В категории новостей и около-технологических тем #2898 содержит перепечатку репортажа с конференции: вторая половина дня форума открытой экосистемы Xiangshan Ruyi 10-20 была посвящена презентации полностековых достижений RISC-V программного и аппаратного обеспечения «для эпохи агентов», охватывающих серверные чипы, AI-нативный программный стек, многопоточную архитектуру процессоров, комплект быстрой разработки AI-CPU, оптимизацию согласованности памяти и адаптацию инструментов верификации EDA. Для RuyiAI это задаёт координату в экосистеме — «AI-нативный программный стек» здесь один из результатов, представленных одновременно на том же форуме, и относится к тому же пласту нарратива, что и серверные чипы с многопоточной архитектурой.

5.3 Один выпуск ruyiai-daily, охват источников: PyTorch, LLVM, Triton и RISC-V (10-29)

Дата: 2026-10-29　Источники: список коммитов ruyiai-daily, daily-news 2026-10-29

ruyiai-daily 10-29 в 06:42 (пекинское время) зафиксировал выпуск daily-news-2026-10-29.md, продолжая ежедневное архивирование. Охват этого выпуска включает пять направлений: экосистема PyTorch, LLVM/MLIR, Triton и TileLang, программный стек и продукты RISC-V, AI-модели и индустрия; три пункта напрямую связаны с этим репозиторием: релиз PyTorch 2.15 (переписанный NCCL стал по умолчанию, MPS расширен на FP8), декодирующее внимание K3 VIR от Buddy (то есть #1014 от 10-28), а также предложение ruyi по обнаружению ABI хоста (то есть #507). Окно мониторинга этих источников — с 10-28 05:14 по 10-29 06:00, что на несколько часов смещено относительно окна ежедневного отчёта; при цитировании необходимо указывать дату самого элемента.

5.4 Внешние новости: ноль совпадений, openRuyi 2026.10 и 0.54.0 не выпущены (состояние на 10-29)

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

Целевые запросы Google News на китайском и английском по RuyiSDK, RuyiAI, openRuyi и сообществу Ruyi (when:3d) в пределах окна дали ноль совпадений; в списке кандидатов по теме RISC-V также нет элементов, связанных с сообществом Ruyi, поэтому внешние новости в этот выпуск не включены.

Что касается дистрибутива, оба релиза по-прежнему вне окна. Последняя публикация на странице новостей openRuyi — всё ещё анонс релиза 2026.09, теги репозитория заканчиваются на 2026.09-experimental, 2026.10 не выпущен; у ruyi для 0.54.0 есть только alpha-тег от 09-18. Если ориентироваться на ритм конца предыдущих месяцев, ближайшие два-три дня — это окно релизов 2026.10 и 0.54.0; в следующем выпуске нужно следить за этими двумя точками.

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

6.1 Исправления раньше приёмки: три исправления опираются на проблемы, накопленные в процессе миграции, а не на регрессионные тесты

Три слияния в этом выпуске обнажили проблему порядка: сначала исправления, потом приёмка. Заполнение тензора в unique_dim, циклическое смещение в broadcast_to, повторяющиеся индексы в операторе хеширования — все три дефекта обнаружены не собственными тестами компилятора, а при переносе операторов FlagGems наверх; исправления слиты, но необходимый для них PR миграции #56 остановился на 09-16 без движения. В результате набор «исправлений, подготовленных для определённого способа использования» временно не имеет соответствующего способа использования в работе.

Риск такого состояния не в настоящем, а в следующем месяце: если при возобновлении #56 в upstream Triton снова сменится несколько итераций, придётся заново проверить, совместимы ли три исправления с новой базовой линией; а если #56 так и не возобновится, этот «набор сквозной приёмки» фактически остановится, и следующая партия дефектов будет ждать, пока на них наткнутся внешние пользователи. Для стека, нацеленного на «способность запускать реальные модели», превращение миграции в постоянную регрессию (пусть даже всего несколько десятков операторов, запускаемых раз в ночь) ценнее, чем слить ещё несколько исправлений.

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

В один и тот же день две ветки дали два ответа на вопрос управления. Ветка riscv в llvm была полностью переиграна, а реально новым стал документ о правилах участия: путь «отправки кода в riscv» разбит на два — «PR в рабочую ветку мейнтейнера» и «PR напрямую в riscv с ручным запуском перебазирования», при этом переключатель предварительного прогона в workflow удалён — успех означает пуш, без предпросмотра. Ветка riscv в pytorch лишь переиграна на upstream 3afdbd3, а затем синхронизирующий бот добавил правку кеша зависимостей, без какой-либо документации о процессе.

Структура издержек у них разная. У ветки llvm набор патчей большой, внешних вкладов много, конфликты и дрейф истории — основные издержки, поэтому формализация правил заслуживает документации и настройки workflow; у ветки pytorch набор патчей мал (11), и стоимость одного переигрывания самим мейнтейнером ниже стоимости поддержания процесса. Отмена предварительного прогона требует наблюдения: снижая трение, она переносит риск «пуша неверной истории» на участников, полагаясь на --force-with-lease и повторную проверку состояния; фактический эффект станет ясен по следующим одному-двум внешним PR.

6.3 Дистрибутивы выпускаются помесячно массово, три ключевых компонента уровня стека ежемесячно застревают на проверке

openRuyi в этом выпуске: 76 коммитов, 10 влитых, из них 64 — пакет обновлений фреймворка KDE; ruyi-imager прошёл путь от 1.0.0 до 1.1.0-rc.1 за семь недель — нормальный темп; а на другой стороне, также относящейся к «дистрибуции», PR #1350 по упаковке триплета RuyiAI открыт с 09-21 и до сих пор возвращается на доработку на уровне спецификации spec. Разница между двумя конвейерами не в людях, а в зрелости: для пакетов KDE есть вышестоящий spec, на который можно ориентироваться, и устоявшийся ритм версий — переупаковка это механическое действие; spec триплета написан с нуля, и приходится объяснять и «почему LLVM оставлен внутри пакета», и «почему %check пуст».

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

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

Источники Результаты проверки
Организация RuyiAI-Stack (все репозитории) pytorch: ветка riscv полностью перезаписана 11 коммитами, SyncBots поднят до upstream 3afdbd3, основная ветка — 20 коммитов, все из upstream; llvm-project: ветка riscv — 25 перезаписанных коммитов, добавлено руководство по участию (faf4def312, +82/−8), основная ветка — 20 коммитов из upstream; triton-riscv: 3 коммита влиты (#58, #83, #82), 3 ночных обновления тегов, 1 PR с зависимостями открыт (#91); tilelang-riscv — четырнадцатый день тишины; ruyiai-daily — один выпуск; harness, FBGEMM, cpuinfo, VecIntrinBench, IntrinTrans, torq-tile, pytorch-ci, dsh-osc, skills, SyncBots-DeepAgents, caffe, mxnet — коммитов в окне мониторинга нет
Организация ruyisdk (все репозитории) ruyi-imager: 1 коммит (позиция версии 1.1.0) + предварительный релиз v1.1.0-rc.1; основной репозиторий ruyi: 1 обновление открытого PR (#508 список наименований производителей), коммитов нет, новых Release нет (0.53.0 сохраняется, 0.54.0 — только alpha-тег); packages-index, support-matrix, docs, ruyisdk-website, wechat-articles, attached-matrix-extension, ruyici, AME-operator — коммитов в окне мониторинга нет
Организация openRuyi-Project основной репозиторий openRuyi — 76 коммитов (пакет KDE Frameworks 6.31.0 — 64 коммита, остальные 12 — исправления пакетов vkpeak, ecbuild, clang-wrap, Gradio, pyvex, graphql-core и go) + 10 влитых PR; 15 открытых PR обновлены (включая #1350 — 18 замечаний первого раунда проверки на уровне кода, #1514 — обновление безопасности ollama); теги заканчиваются на 2026.09-experimental, 2026.10 не выпущен
Организация buddy-compiler buddy-mlir — 1 коммит влит (#1015 новый ABI, 56 файлов +3934/−1661) + ночная сборка v0.1.3.dev20261029; три открытых PR застряли на 10-28 (#1011, #1013, #994), ещё #992, #993, #995, #997, #1001, #924, #928, #932, #838 без обновлений в окне мониторинга; buddy-benchmark, buddy-examples, compiler-eval, FeGen, gemmini, firesim — коммитов в окне мониторинга нет
Форум сообщества разработчиков RuyiSDK два поста в окне мониторинга: #2899 «RuyiAI на шестом саммите RISC-V Китая» (10-29, категория RuyiAI), #2898 «Конференция экосистемы Xiangshan Ruyi: презентация полностековых результатов RISC-V для эпохи агентов» (10-29, репост); двухнедельный отчёт выпуска 080 не вышел
Страница новостей дистрибутива openRuyi новых статей нет, анонс выпуска 2026.09 остаётся последним; теги репозитория заканчиваются на 2026.09-experimental, 2026.10 не выпущен
Менеджер пакетов ruyi / Releases 0.53.0 сохраняется, новых alpha или beta нет (0.54.0-alpha.20260918 остаётся последней версией); в основной ветке с 09-25 коммитов нет
ruyi-imager / Releases v1.1.0-rc.1 выпущен 10-29 в 16:02 (предварительный релиз), включает четыре изменения в интерактивности и CLI
Официальный сайт (ruyiai.org) три страницы без изменений: индекс главной страницы — 3 записи, блог — 2 статьи, документация — 23 главы, sha256 совпадает с предыдущим выпуском
arXiv (RISC-V) в окне мониторинга нового нет; последние — SecDMP и генератор C-кода TinyML от 10-27, длинновекторный FlashAttention от 10-21 остаётся наиболее близким к RVV
Google News RSS (несколько наборов на китайском и английском) целевые запросы RuyiSDK, RuyiAI, openRuyi, сообщество Ruyi — ноль совпадений; кандидаты по теме RISC-V, включая Qwenputer и не относящиеся к Ruyi записи, не включены

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