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

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

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

  • Главное за день: декодирующее внимание K3 перенесено на VIR, производительность на уровне рукописного ядра RVV (10-28)
    1. Прогресс стека RuyiAI (адаптация PyTorch / Triton / TileLang под RISC-V)
      • 1.1 llvm-project: смена базы прекращена, добавлен рабочий процесс «перебазирование fork автора одной кнопкой» (10-28)
      • 1.2 pytorch: ветка riscv молчит седьмой день, двадцать коммитов основной ветки по-прежнему из вышестоящего репозитория (состояние на 10-28)
      • 1.3 triton-riscv: якорь поднят ещё на ступень, три проверки CI для riscv64 в очереди без ответа (10-28)
      • 1.4 tilelang-riscv: основная ветка молчит тринадцатый день (состояние на 10-28)
    1. Инструментальная цепочка и дистрибутивы RuyiSDK
      • 2.1 openRuyi PR #1350: перебазирование трёх коммитов, стоимость сборки GCC измерена количественно — в 2,81 раза (10-28)
      • 2.2 openRuyi: 27 коммитов, слито 15 PR, приземлились бэкпорты qemu 11.1.2 и libvirt (10-28)
      • 2.3 Очередь на рассмотрении: KDE Frameworks 6.31, кросс-инструментальная цепочка, Gradio 6.31 (состояние на 10-28)
      • 2.4 ruyisdk: 0.54.0 всё ещё не выпущен, манифест пакетов и матрица поддержки молчат, установщик сменил терминологию интерфейса (состояние на 10-28)
    1. Векторные расширения, архитектурное тестирование и оптимизация операторов
      • 3.1 Векторный репозиторий и три репозитория FBGEMM молчат, cpuinfo застыл на 05-20 (состояние на 10-28)
      • 3.2 Трактовка векторной ширины: на стороне VIR зафиксировано 1024 бита, одна голова — одна группа LMUL 4 (10-28)
      • 3.3 В окне arXiv новых поступлений нет, длинновекторный FlashAttention от 10-21 по-прежнему ближе всего к RVV (состояние на 10-28)
    1. Динамика Buddy Compiler
      • 4.1 Декодирующее внимание K3 перенесено на VIR: побитовое числовое совпадение, измеренная пропускная способность K3 в том же интервале (10-28)
      • 4.2 Реорганизация исходников buddy-server, пример Whisper вошёл в x64 CI (10-28)
      • 4.3 На рассмотрении четыре изменения: приведение int64, переиспользование предобработки Whisper, новый ABI, выравнивание с llama-server (состояние на 10-28)
      • 4.4 Ночная сборка dev20261028 выпущена, три изменения текущего дня в неё всё ещё не вошли (10-28)
    1. Сообщество, мероприятия и официальный сайт
      • 5.1 Три страницы официального сайта без изменений, две записи в блоге, двадцать три главы документации (состояние на 10-28)
      • 5.2 В окне на форуме новых тем нет; дополнительно внесена тема от 10-27 с практическим тестом UEFI на LPi4A (10-27)
      • 5.3 Один выпуск ruyiai-daily, ruyi-imager заменил «производитель» на «поставщик» (10-28)
      • 5.4 Внешние новости — ноль совпадений, ни openRuyi 2026.10, ни 0.54.0 не выпущены (состояние на 10-28)
    1. Наблюдения за трендами
      • 6.1 От «умения выразить» к «той же скорости»: VIR впервые сверяет производительность на ядрах реальной модели
      • 6.2 Стоимость смены базы смещается от дрейфа патчей к управлению: рабочий процесс берёт перебазирование на себя, ветка по-прежнему держится на людях
      • 6.3 Спор о слое дистрибуции обретает цену: 2,81-кратное время сборки убедительнее «предпочтений»

Главное за день: декодирующее внимание K3 перенесено на VIR, производительность на уровне рукописного ядра RVV (10-28)

Дата: 2026-10-28　Источник: buddy-mlir PR #1014, документация K3, triton-riscv PR #91, рабочий процесс перебазирования llvm-project

Самый существенный шаг этого выпуска произошёл в 09:36: в buddy-mlir смержен PR #1014 «K3: write the decode attention in the VIR dialect» (4 файла, +476/−14), который целиком переносит декодирующее внимание ядра K3 w4g32 на диалект VIR. Это не очередное расширение возможностей диалекта, а первая сверка на ядре реальной модели — с одной стороны написанное ранее вручную векторное ядро RVV, с другой — ядро VIR, собранное на Python: сравнение численных значений, числа инструкций и пропускной способности на плате.

Подход раскладывается на четыре слоя. Слой конструирования больше не собирает операторы и типы вручную (раньше приходилось писать имена операторов и описания типов в строках), а идёт через SetVLOp, load, shuffle, fma, reduce из buddy_mlir.dialects.vir; один work item — это область vir.set_vl длиной в половину головного измерения (64 lanes), каждая голова — масштабируемый вектор, собранный из двух половин RoPE, а область возвращает для этой головы (max, sum). Слой вращения загружает q внутри области, вращает и масштабирует; rotate_half реализуется одной vir.shuffle, cos/sin хранятся как две строки равной длины, поэтому vir.from_vector больше не нужен. Слой представления памяти с помощью memref.expand_shape режет q, KV cache, выход и веса нормализации q по последнему измерению на 2×64. Слой нормализации (q/k norm в Qwen3) выделяется в отдельную одномерную область vir.set_vl, где по методу _head_rmsnorm для двух половин вычисляется сумма квадратов.

Параметры конвейера тоже изменились: понижение ядра переключено с vector-width=128 на rvv-vlen=1024, use-scalable=false, размеры векторов определяются анализом по регистрам A100, поскольку в области есть vir.shuffle, каждая голова остаётся векторной группой из 128 f32 (LMUL 4). Автор прямо пишет в PR: переход на use-scalable=true — дело следующего коммита. Старая _attn_decode_fn сохранена, декодирующее внимание ядра A210 всё ещё использует её.

Результаты убедительны по всем трём пунктам. По численным значениям — с q/k-нормализацией и без неё — полное побитовое совпадение с _attn_decode_fn; по машинному коду два параллельных тела содержат по 178 векторных инструкций, цикл по ключам и значениям имеет те же инструкции, что и в старой версии, изменились лишь позиции двух перезагрузок вытесненных регистров; пропускная способность на плате (K3, жадное декодирование через buddy-cli, три чередующихся прогона, полное совпадение 9 пар сгенерированных текстов) во всех трёх диапазонах попадает в один интервал — после 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%, интервалы перекрываются.

В тот же день вышли ещё два коммита, поддерживающих эту основную линию. Во-первых, в ветку riscv проекта llvm-project добавлен рабочий процесс автоматического перебазирования на 244 строки (подробнее в 1.1), который переносит вопрос «PR в форке автора отстаёт от базовой линии» из ручной работы в Actions. Во-вторых, якорь зависимостей triton-riscv ещё раз поднят renovate до dev20261028 (подробнее в 1.3), но эта ночная сборка была выпущена раньше трёх смерженных утром коммитов, поэтому даже после слияния этого обновления зависимостей нижестоящие проекты всё ещё не получат #1014 — чтобы воспользоваться сегодняшними результатами, нужно дождаться следующей ночной сборки.

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

1.1 llvm-project: больше не перебазируется вручную — добавлен рабочий процесс «перебазирование форка автора одной кнопкой» (10-28)

Дата: 2026-10-28　Источники: коммит ветки riscv cf00909d, полный текст рабочего процесса, список коммитов ветки riscv

В отличие от предыдущего выпуска с «пятым за пять дней полным переигрыванием ветки», локальный набор патчей ветки riscv на этот раз не тронут ни одним коммитом: голова ветки продвинулась на один коммит от ed439f3e, и по сравнению с головой предыдущего выпуска это опережение на 1 коммит, отставание на 0, затронут всего 1 файл. Этот новый коммит (cf00909d, автор 23:27, коммит 23:54) — чистый CI-актив: .github/workflows/autorebase.yml, +244/−0.

Замысел рабочего процесса описан в комментариях: он устанавливается в ветку по умолчанию исходного репозитория автора, запускается вручную в Actions с указанием номера целевого PR, использует собственный GITHUB_TOKEN исходного репозитория и не требует пользовательских секретов или меток. Триггер — workflow_dispatch, два входа: номер PR (обязательный) и «только предварительный прогон без отправки» (включён по умолчанию). Среда выполнения ubuntu-24.04, тайм-аут 90 минут; в комментариях явно требуется «никогда не выполнять код PR, хуки, сборку или подмодули при наличии прав на запись», в конфигурации git параметры hooksPath, attributesFile и fsmonitor указывают на /dev/null, заданы GIT_TERMINAL_PROMPT=0 и GIT_EDITOR=true. Для разрешения конфликтов предусмотрена отдельная функция: сценарии, которые не решаются через -Xours (включая конфликты изменение/удаление), обрабатываются поочерёдно через ls-files --unmerged — при наличии второй стадии берётся локальная версия, при отсутствии файл удаляется; при перебазировании сначала проверяется, является ли базовая точка предком, распознаются «эквивалентные патчи» и отбрасываются дублирующие патчи старой базовой точки.

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

1.2 pytorch: ветка riscv молчит седьмой день, двадцать коммитов основной ветки — по-прежнему upstream (состояние на 10-28)

Дата: 2026-10-28 (состояние)　Источники: ветка riscv pytorch, основная ветка pytorch

Голова ветки riscv — по-прежнему «Add riscv64 image locally (#51)» от 10-22 03:00 (пекинское время), с 10-22 по 10-28 седьмой день подряд ноль коммитов. Два основных предложения по развитию возможностей RVV (#46 — поддержка векторных расширений для ATen, #48 — возможности RISC-V Vector CPU) в этом выпуске снова без обновлений.

В основной ветке за тот же период 20 коммитов, все — синхронизация с upstream, ни один не касается RISC-V: исправление 64-битного индекса внутри слайса max_pool3d на стороне CUDA, переход объединённого онлайн-softmax на точную экспоненту, откат очистки устаревшего API symbolic shapes, закрепление pytest 9.1.1 в образе inductor-benchmarks, массовое применение c10::irange в нативных операторах ATen, переключение выделения рабочей области пакетного syevd rocSOLVER из ROCm на аллокатор из кэша. Ритм этой ветки совпадает с выводом прошлого выпуска: отслеживание upstream обновляется ежедневно, воспроизведение RISC-V выполняется вручную по мере необходимости.

Стоит читать параллельно сторону дистрибуции: #1352 в openRuyi по-прежнему упаковывает артефакты этой ветки в пакет python-torch-ruyiai (в этом выпуске не обновлялся, застыл на 10-27). Ветка не двигается, пакет ждёт — это текущее самое важное расхождение на переднем крае pytorch: отстала ли ветка от базовой точки upstream к моменту вливания пакета, ответа пока нет.

1.3 triton-riscv: якорь поднят ещё на ступень, три CI-задачи riscv64 в очереди без ответа (10-28)

Дата: 2026-10-28　Источники: triton-riscv PR #91, PR #90, список ночных версий buddy-mlir

В 18:51 робот renovate открыл #91, подняв ночную версию upstream buddy-mlir с nightly/v0.1.3.dev20261027 до nightly/v0.1.3.dev20261028, изменение по-прежнему в две строки (+2/−2). Отличие от прошлого коммита в том, что автоматического вливания не произошло: к концу окна этот PR остаётся открытым, статус возможности слияния — unstable.

Из восьми проверок шесть уже вернулись: три уровня x64 — 3.12, 3.13, 3.14 — все успешны, pre-commit и clang-format успешны; riscv64 3.12 с 18:54 находится в состоянии выполнения, 3.13 и 3.14 с момента открытия всё время в очереди. Предыдущий коммит в том же репозитории (#90) был автоматически влит через несколько минут после открытия; отличие этого выпуска заключается именно в очереди выполнения на стороне riscv64 — это ритм инфраструктуры, а не проблема самой зависимости.

Есть ещё один временной нюанс, который нужно прояснить: сборочное ведро ночной версии dev20261028 предшествует трём вливаниям утра того же дня (#1010 08:54, #1014 09:36, #1012 09:55), поэтому эта версия не несёт декодирующего внимания K3. Чтобы downstream получил результаты #1014, нужно дождаться следующей ночной сборки плюс ещё одного обновления зависимости — в лучшем случае один цикл сборки.

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

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

Последний коммит в основную ветку по-прежнему датирован 16.10 10:52, непрерывный тринадцатый день без коммитов; открытый PR #4 замер 28.09. Молчание на стороне репозитория контрастирует со стороной triton-riscv: последний хотя бы следует за зависимостями, первый же не предпринимает никаких действий даже по обновлению зависимостей.

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

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

2.1 openRuyi PR #1350: перебазирование трёх коммитов, стоимость сборки GCC количественно оценена в 2,81 раза (28.10)

Дата: 2026-10-28　Источники: openRuyi PR #1350, комментарии ревью, список коммитов PR

В 16:22 три коммита PR по упаковке набора из трёх компонентов RuyiAI (buddy-mlir, python-triton-ruyiai, python-tilelang-ruyiai) были полностью переписаны в течение одной минуты — очевидно, перебазированы на последнюю основную ветку; текущий масштаб — 9 файлов, +680/−0, что на 14 строк больше по сравнению с записью прошлого выпуска. В 18:15 PR снова обновился из-за комментариев ревью, всего комментариев 13, слияния по-прежнему нет.

Самая содержательная информация этого выпуска — из ответа автора в 10:41. Формулировка прошлого выпуска была «можно заменить на GCC, но время сборки как минимум в 1,5 раза больше»; в этом выпуске приведены измерения: на машине riscv64 при замене LLVM на GCC при сборке buddy-mlir время изменилось с 8814 секунд на 24798 секунд (примерно 2 часа 27 минут против 6 часов 53 минут), в 2,81 раза, причём та сборка с GCC упала на этапе компоновки и не завершилась.

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

2.2 openRuyi: 27 коммитов, влито 15 PR, qemu 11.1.2 и обратный перенос libvirt реализованы (28.10)

Дата: 2026-10-28　Источники: список коммитов openRuyi, PR #1520 qemu, PR #1519 libvirt, PR #1521 пакет python, PR #1522 макрос инструментальной цепочки

Основной репозиторий в этом выпуске: 27 коммитов, 15 PR слито, участвовало 9 человек: misaka00251 — восемь, Ruoqing He — четыре, Sun Yuechi — четыре, Jingiw — три, Zheng Junjie — три, Kimmy — два, cl2t, Julian Zhu, YunQiang Su — по одному. Все коммиты сосредоточены между 11:20 и 20:49, после чего до конца окна новых коммитов нет. Масштаб заметно сократился по сравнению с прошлым выпуском (45 коммитов), а характер сместился от «зачистки перед релизом» к обычному сопровождению.

Сторона виртуализации — самая полная группа в этом выпуске. qemu обновлён с 11.1.x до 11.1.2 (#1520, слито в 13:28), в прошлом выпуске он ещё был в «очереди на рассмотрении», а за один день был доведён до конца. Два коммита libvirt слиты (#1519, 09:47): первый — распространение в составе пакета /var/lib/libvirt/secrets, чтобы каталог, нужный virt-secret-init-encryption, существовал и virtsecretd мог запуститься; второй — бэкпорт исправления, из-за которого после удаления auth_supported в Ceph 21 переставал работать пул rbd. Оба — патчи для проблем класса «устанавливается, но не запускается», что относится к жёстким показателям качества дистрибутива.

На стороне инфраструктуры упаковки также есть содержание. Слит макрос %toolchain_major_version (#1522, 12:36), позволяющий указать крупную версию инструментальной цепочки вроде gcc-15, gcc-16 или clang-22, clang-23 — это как раз даёт точку опоры для находящегося на рассмотрении PR с кросс-инструментальной цепочкой. Слита партия исправлений сбоев сборки python-пакетов (#1521, 14:02): scikit-build-core обновлён до 1.1.1, cmake дополнен метаданными дистрибутива Python, ml-dtypes обновлён до 0.6.0, charset-normalizer — до 3.5.2, httptools ослабил жёсткую привязку версии setuptools. Два пункта — scikit-build-core и метаданные cmake — имеют прямое значение для стека RuyiAI: сборка wheel для CMake-расширений вроде triton и tilelang идёт именно по этому пути.

Остальные слитые изменения: attr обновлён до 2.6.0, go — бэкпорт оптимизации индекса, удалён python-backports-zstd, пакеты семейства go приведены к переименованию gcfg v2 с исправлением зависимостей, python-graphql-core понижен до 3.2.13, procps — исправлено имя rpm и восстановлен uptime, krb5 — набор параметров сборки и служба systemd, ceph — следование снапшоту upstream, добавлен sql-migrate, rustvmm — зависимости четырёх crate (linux-loader 0.14, vm-memory 0.18, kvm-ioctls 0.25, acpi-tables 0.2.1), в корневой каталог добавлен .gitignore.

2.3 Очередь на рассмотрении: KDE Frameworks 6.31, кросс-инструментальная цепочка, Gradio 6.31 (состояние на 10-28)

Дата: 2026-10-28 (состояние)　Источники: PR #1513 KDE, PR #1490 кросс-инструментальная цепочка, PR #1516 qemu-rustsbi, PR #1532 Gradio

В окне обновлено 9 открытых PR. WIP-обновление KDE Frameworks 6.31.0 обновлено в 00:04 (#1513), по-прежнему помечено WIP. Кросс-инструментальная цепочка riscv64 (#1490, Z572) обновлена в 14:18, по-прежнему WIP — образует пару с слитым в этом выпуске макросом крупной версии инструментальной цепочки: макрос даёт точку переключения, PR предоставляет конкретную инструментальную цепочку, и только когда оба на месте, кросс-компиляция становится работоспособной. Gradio 6.31.0 с выравниванием зависимостей (#1532), python-pyvex обновлён до 10.0.5 (#1533), исправление версии эпохи ручного provides для graphql-core (#1531) — три PR сосредоточенно обновлены между 20:03 и 21:27. qemu-rustsbi (#1516) имеет два обсуждения, это подготовительная работа по введению SBI, написанного на Rust, в стек виртуализации. Остальные — vkpeak (#1349) и модуль Prometheus v3.13 (#1441).

2.4 ruyisdk: 0.54.0 всё ещё не выпущен, список пакетов и матрица поддержки молчат, установщик меняет терминологию интерфейса (состояние на 10-28)

Дата: 2026-10-28 (статус)　Источники: ruyi Releases, packages-index, support-matrix, ruyi-imager коммит a87b8dd9

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

В окне мониторинга packages-index коммитов нет (последний остановился на поднятии версии образа revyos Milk-V Meles от 10-26), что подтверждает упомянутую в выпуске 079 проблему синхронизации данных программного источника ISCAS — собранные пакеты не обновились на публичном ресурсе, и в манифесте, естественно, нет массовых обновлений. В окне мониторинга support-matrix также нет коммитов; две платы из прошлого выпуска (SpaceMiT K3 Pico-ITX с Bianbu 4.0.8, оценённая как good, и VisionFive 2 Lite с Ubuntu 24.04.5, оценённая как basic) — это последняя партия.

В ruyi-imager один коммит: в 15:46 «Rename manufacturer labels to supplier in the GUI» — в интерфейсе «производитель» единообразно заменён на «поставщик». Это унификация формулировок перед релизом, того же рода, что и «диалог выбора больше не предвыбирает» из прошлого выпуска — шлифовка удобства использования установщика.

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

3.1 Векторный репозиторий и три репозитория FBGEMM молчат, cpuinfo остановился на 05-20 (статус 10-28)

Дата: 2026-10-28 (статус)　Источники: 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 записей о коммитах нет.

Это означает, что все векторные достижения этого выпуска произошли в другом месте — на уровне представления в VIR проекта buddy-mlir, на уровне инструментальной цепочки в ветке riscv проекта llvm, а не в специализированных репозиториях тестирования векторных интринсиков и оптимизации операторов. Для стека,whose цель — «рост векторных возможностей», длительная неподвижность тестового базиса является скрытой угрозой: VIR теперь умеет выражать масштабируемые векторы, но без постоянно прогоняемого векторного бенчмарка интринсиков трудно определить, является ли последующая оптимизация настоящим улучшением или колебанием (в #1014 уже встречался случай «разница 2% между двумя сборками одного и того же кода», как раз и нужен стабильный базис для оценки).

3.2 Спецификация векторной ширины: на стороне VIR зафиксировано 1024 бита, один заголовок — одна группа LMUL 4 (10-28)

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

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

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

3.3 В окне arXiv новых поступлений нет, длинновекторный FlashAttention от 10-21 по-прежнему наиболее близок к RVV (состояние на 10-28)

Дата: 2026-10-28 (состояние)　Источник: поиск по arXiv

Поиск по условиям RISC-V плюс компиляторы, векторы, MLIR не выявил новых статей в окне; самыми свежими остаются сравнение архитектур суперкомпьютеров с открытым ISA от 10-23 и мультиагентный фреймворк для бинарного подъёма в канонический IR компилятора от 10-22. Наиболее близкой к основной линии этого выпуска по-прежнему остаётся работа от 10-21 «Reorienting the Vector Axis: Restructuring FlashAttention for Long-Vector Processors» — реструктуризация FlashAttention для длинновекторных процессоров, которая относится к тому же классу задач, что и подход из #1014 с сегментацией декодирующего внимания по 64 lanes и группировкой по одному LMUL 4 на голову; к сожалению, продолжения в окне не появилось.

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

4.1 Декодирующее внимание K3 перенесено на VIR: побитовое числовое совпадение, измеренная пропускная способность на K3 попадает в тот же диапазон (10-28)

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

В прошлом выпуске Python-привязки из #1009 были отмечены как «превращение из специализированного buddy-opt в программируемый диалект»; в этом выпуске представлена первая реальная вещь, написанная с использованием этих привязок: #1014 влит (09:36), 4 файла, +476/−14, из которых реализация ядра — 264 строки добавлений, тесты — 152 строки, конвейер понижения — 10 строк, документация K3 — 50 строк.

Технические моменты уже раскрыты в разделе «Главное за сегодня», здесь лишь три поддающиеся проверке детали. Во-первых, в PR явно указано, что это повторная реализация уже закрытого #998, а основой для переделки послужили последующие четыре коммита: определение размеров по активности (#1000), строки (#1005), vir.shuffle (#1006), Python-привязки (#1009) — то есть это не независимая оптимизация, а однократная нагрузочная проверка фундамента, заложенного предыдущими четырьмя коммитами. Во-вторых, проверка выполнена достаточно строго: тесты проводят побитовое сравнение _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, при жадном декодировании и на трёх длинах последовательностей; автор также отмечает, что две сборки одного и того же кода могут различаться на 2%. Это доказывает, что VIR больше не вносит потерь производительности, а не то, что VIR уже превосходит рукописные ядра.

4.2 Реорганизация исходного кода buddy-server, пример Whisper добавлен в x64 CI (10-28)

Дата: 2026-10-28　Источник: PR #1010, PR #1012

#1010 влит в 08:54, 47 файлов, +349/−292 — это самый масштабный по объёму изменений коммит текущего выпуска. Содержание — реорганизация buddy-server по зонам ответственности: производственный исходный код сгруппирован по трём блокам — HTTP, протокол, плагины; тесты разложены по каталогам — unit, интеграционные, упаковочные, фикстуры; введена библиотека buddy-server-core, чтобы избежать повторной компиляции производственного исходного кода в тестах; жизненный цикл сервиса и регистрация маршрутов вынесены в BuddyServerApp, а в исполняемой точке входа оставлены только разбор аргументов и запуск. Подобная реорганизация не влияет на функциональность, но освобождает пространство для последующих изменений интерфейсов.

#1012 был объединён в 09:55, 4 файла, +92/−3, добавляет проверку вывода в пример Whisper и подключает его к x64 CI. В PR указано, что он затрагивает только ту часть issue #757, которая касается Whisper и x64, остальные примеры по-прежнему остаются в этом issue; также отмечено, что локальная проверка опиралась на исправление сборки из #1011 (принудительное приведение счётчика фрагментов масштабируемого VIR к int64), а само это исправление ещё не объединено — то есть этот зелёный CI получен поверх исправления сборки, которое ещё не вошло в основную ветку.

4.3 На рассмотрении четыре: приведение к int64, повторное использование предобработки Whisper, новый ABI, выравнивание по llama-server (состояние на 10-28)

Дата: 2026-10-28 (состояние)　Источники: PR #1011, PR #1013, PR #1015, PR #994

Четыре открытых PR обновились в окне мониторинга. #1011 — исправление компиляции: в закреплённой в репозитории версии Clang/LLVM divideCeil возвращает беззнаковое значение, и агрегатная инициализация, помещающая его в поле int64, вызывает ошибку сужения; исправление делает явное приведение, при этом деление, ширина вектора, маски и раскладка не меняются (+4/−4, один файл) — хотя это изменение маленькое, оно является предпосылкой того, что #1012 может пройти.#1013 обновлён в 16:01, повторно использует результат предобработки Whisper для сокращения повторных вычислений.#1015 обновлён в 22:53, переводит buddy-server на новый ABI.#994 обновлён в 15:35, выравнивает интерфейс buddy-server по llama-server и является самым ранним PR, предложившим это направление выравнивания; до сих пор не объединён.

4.4 Ночная сборка dev20261028 выпущена, по-прежнему без трёх коммитов дня (10-28)

Дата: 2026-10-28　Источники: ночная сборка dev20261028, список Releases

Ночная сборка выпущена в 07:56 (v0.1.3.dev20261028). Время выпуска раньше трёх объединений утренней части дня (#1010 08:54, #1014 09:36, #1012 09:55), поэтому эта версия не содержит декодирующего внимания K3, а также реорганизации buddy-server и Whisper CI. В линии 0.1.3 уже четыре ночных сборки подряд без официального релиза (последний официальный релиз — 0.1.2 от 10-25); следующая ночная сборка станет первой остановкой #1014 на пути к downstream.

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

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

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

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

Разрыв между этой стороной и инженерной стороной в этом выпуске стал ещё заметнее: в один и тот же день VIR несёт ядра реальных моделей, в ветке llvm добавлен рабочий процесс перебазирования, в дистрибутиве 15 объединений, а страницы официального контента по-прежнему стоят на двух статьях сентября. Сами измеренные данные K3 из #1014 (пропускная способность на плате, число инструкций, побитовая согласованность) — это готовый материал для технического поста в блоге, который сейчас существует только в описании PR и в документации репозитория.

5.2 Новых постов на форуме в окне нет; дополнена запись о тестировании LPi4A UEFI от 10-27 (10-27)

Дата: 2026-10-27　Источники: lpi4a UEFI #2896, сообщество разработчиков RuyiSDK

Новых постов на форуме в окне нет, последний пост по-прежнему #2896 от 10-27. Здесь нужно исправить одну вещь: в предыдущем выпуске состояние форума было записано как «последние две записи остановились на обзоре саммита и конспекте курса от 10-22», при этом были пропущены #2895 с двухнедельным прогрессом от 10-26 (эта запись уже была освещена в выпуске 10-27) и #2896 от 10-27; последняя была пропущена между двумя окнами и дополняется в этом выпуске.

#2896 под названием «lpi4a UEFI», опубликован 10-27 в 10:45 пользователем lzzhzh, с шестью скриншотами и фотографиями: три системных скриншота 1366×768, три фотографии 1920×1440. В тексте говорится, что обновление было обнаружено ещё 26 сентября, автор терпел месяц, прежде чем прошить LPi4A, и хотя на данный момент нет доступной RevyOS, совместимой с UEFI, «но хотя бы есть надежда». Yuxi ответил: «Можно-можно». Ценность этой записи в том, что она фиксирует реальную узкую точку в экосистеме прошивок LPi4A: прошивку UEFI уже можно прошить, но сопутствующий образ дистрибутива ещё не подоспел — именно такое состояние должна включать матрица поддержки (support-matrix), но в текущем окне мониторинга коммитов по ней нет.

5.3 Выпуск ruyiai-daily, ruyi-imager меняет «производитель» на «поставщик» (10-28)

Дата: 2026-10-28　Источники: ruyiai-daily, коммит ruyi-imager a87b8dd9

ruyiai-daily в 06:22 закоммитил выпуск «daily-news: 2026-10-28», продолжая ежедневную архивацию новостной динамики.

ruyi-imager в 15:46 закоммитил изменение, унифицирующее метку «производитель» в интерфейсе на «поставщик». Изменение небольшое, но направление ясное: установщик ориентирован на поставщиков плат, а не на производителей чипов, и формулировка приведена в соответствие с фактической семантикой. Остальные репозитории в окне мониторинга коммитов не имеют — harness остановился на 10-27, ruyisdk-website на 10-23, wechat-articles на 10-26, docs и attached-matrix-extension не двигались.

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

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

Целевые запросы Google News по RuyiSDK, RuyiAI, openRuyi и RISC-V в китайской и английской версиях в окне мониторинга дали ноль попаданий; по запросу «RISC-V» последний результат — репортаж об участии в саммите от 10-25 (Yixing Intelligent), который выходит за пределы окна и не связан с сообществом, поэтому в этот выпуск не включён.

На стороне дистрибутива две версии всё ещё вне окна. Последняя публикация на странице новостей openRuyi — анонс релиза 2026.09 (9-30), теги репозитория заканчиваются на 2026.09-experimental, 2026.10 не выпущен. У ruyi 0.54.0 есть только альфа-тег от 09-18, официальная версия по критерию выпуска 079 ожидается в конце октября. Согласно ритму предыдущих месяцев (6-30, 7-23, 8-27, 9-30), октябрьская версия с большой вероятностью выйдет в конце этого месяца; до конца месяца два дня, следующий выпуск — последняя возможность это проверить.

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

6.1 От «способности выражать» к «той же скорости»: VIR впервые сверяет производительность на реальном ядре модели

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

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

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

В тот же день ветка riscv в llvm прекратила полное перебазирование и перешла на добавление автоматического рабочего процесса перебазирования на 244 строки. Этот поворот стоит отдельной записи: ритм последних пяти дней — «одно полное перебазирование в день, каждый раз переписывание двадцати коммитов», время автора не менялось, время committer унифицировано, сам набор патчей не добавлял функциональности. Такой подход позволяет следовать за апстримом, но ценой является то, что PR внешних контрибьюторов всегда отстают на шаг, и любой, кто хочет отправить коммит, должен перебазировать сам.

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

6.3 Спор о слое дистрибуции начинает иметь цену: 2,81-кратное время сборки убедительнее «предпочтений»

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

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

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

Источники Результаты проверки
Организация RuyiAI-Stack (все репозитории) llvm-project: ветка riscv — 1 новый коммит (cf00909d, рабочий процесс перебазирования +244/−0), локальный набор патчей без изменений; pytorch: ветка riscv — седьмой день подряд нулевых коммитов, основная ветка — 20 коммитов, все из upstream; triton-riscv: 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 коммит (унификация терминологии интерфейса); packages-index, support-matrix, docs, ruyisdk-website, wechat-articles, attached-matrix-extension, ruyici, AME-operator — коммитов в окне мониторинга нет; основной репозиторий ruyi — с 09-25 нет коммитов, нет новых релизов (0.53.0 сохраняется)
Организация openRuyi-Project Основной репозиторий openRuyi — 27 коммитов (misaka00251 — 8, Ruoqing He — 4, Sun Yuechi — 4, Jingiw — 3, Zheng Junjie — 3, Kimmy — 2, остальные 3 человека по 1) + 15 смерженных PR; включая qemu 11.1.2, два коммита libvirt, макрос основной версии инструментальной цепочки, пакетную сборку python; 9 открытых PR обновлены (включая два от RuyiAI, из которых #1350 — перебазирование трёх коммитов); новых тегов нет (2026.09-experimental — последний)
Организация buddy-compiler buddy-mlir — 3 смерженных коммита (#1014 декодирование внимания K3, #1010 реорганизация buddy-server, #1012 Whisper x64 CI) + ночная сборка v0.1.3.dev20261028; 4 открытых PR обновлены (#1011, #1013, #1015, #994); buddy-benchmark, buddy-examples, compiler-eval, FeGen, gemmini, firesim — коммитов в окне мониторинга нет
Форум сообщества разработчиков RuyiSDK Новых сообщений в окне мониторинга нет; последнее #2896 «lpi4a UEFI» (10-27 10:45) — пропуск предыдущего выпуска, включено в этот выпуск; двухнедельный отчёт о прогрессе № 079 (10-26) — последний официальный отчёт, № 080 ожидается в начале ноября
Страница новостей дистрибутива openRuyi Новых статей нет, объявление о выпуске 2026.09 (9-30) остаётся последним; теги репозитория заканчиваются на 2026.09-experimental, 2026.10 не выпущен
Пакетный менеджер ruyi / Releases 0.53.0 сохраняется, новых alpha или beta нет (0.54.0-alpha.20260918 — по-прежнему последняя версия); основная ветка с 09-25 без коммитов
Официальный сайт (ruyiai.org) Три страницы без изменений: индекс главной — 3 записи, блог — 2 статьи, документация — 23 главы, sha256 совпадает с предыдущим выпуском
arXiv (RISC-V) В окне мониторинга новых нет; последние — сравнение открытых ISA для суперкомпьютеров от 10-23 и фреймворк бинарного подъёма до IR компилятора от 10-22, длинновекторный FlashAttention от 10-21 по-прежнему наиболее близок к RVV
Google News RSS (несколько групп на китайском и английском) Целевые запросы RuyiSDK, RuyiAI, openRuyi, Ruyi RISC-V — ноль совпадений; последняя запись по «Ruyi RISC-V» — репортаж об участии в саммите от 10-25, находится вне окна и не связана с сообществом Ruyi, не включена

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