調査期間：2026-10-30 04:30 ~ 2026-11-02 04:30（北京時間、過去3日間、土日を含む。前回2026-10-30 04:30の締め切りと端から端まで連続している）。

情報源：GitHub組織全リポジトリ核查（RuyiAI-Stack、ruyisdk、openRuyi-Project、buddy-compiler、リポジトリごとに期間内のコミット、PR、Releaseを照合。上流フォークはRISC-V / RVV / 玄鉄などのキーワードでフィルタリングし、コミット比較インターフェースでリプレイと新規を区別）、openRuyiのコミットとPRマージ統計、ruyiパッケージマネージャとruyi-imagerのReleaseとタグ、RuyiSDK開発者コミュニティフォーラム、ruyiai-dailyのデイリー情報アーカイブ、RuyiAI公式ホームページ3ページのスナップショット、openRuyiディストリビューションニュースページ、Google News RSSの中英語定向検索（プロキシ経由）。

本期インデックス

  • 今日の重点：Buddy Compiler 0.1.3が正式版リリース、16件のコミットのうち10件がRVVスケーラブルベクトル化、リリースノートにはサーバー側ABIのみ記載（10-31）
    1. RuyiAIスタックの進展（PyTorch / Triton / TileLang RISC-V対応）
      • 1.1 pytorch：riscvブランチが11-01未明に2回目のブランチ全体リプレイ、ベースラインは依然3afdbd3のまま（11-01）
      • 1.2 llvm-project：riscvブランチが11-01深夜にリプレイ、A100のIME/AME降格がリストに含まれる（11-01）
      • 1.3 triton-riscv：2件マージ、5件新規オープン、別途1件が公式Triton v3.8.0にリベース（10-30〜11-01）
      • 1.4 tilelang-riscv：メインブランチが17日間沈黙、オープンPRは残り1件のみ（11-01時点）
    1. RuyiSDKツールチェーンとディストリビューション
      • 2.1 openRuyi：6件のコミットがすべて10-30に集中、LLVM 23とollamaのセキュリティアップデートがマージ（10-30）
      • 2.2 openRuyi審査中：Prometheus依存バッチ13件、box64とfirecrackerがキューに追加（10-30〜11-01）
      • 2.3 Ruyiai三件セット #1350：2週目もspec規範で停滞、10-30に1回リフレッシュ（10-30時点）
      • 2.4 ruyi 0.54.0：10月末の目標が未達、メインブランチはドキュメント1件のみマージ（10-30）
      • 2.5 openRuyi 2026.10未リリース、月次リリースリズムに空白が発生（11-02時点）
    1. ベクトル拡張とオペレータ最適化（VecIntrinBench / IntrinTrans / FBGEMM）
      • 3.1 3つのベクトルリポジトリは本期すべて沈黙、最新コミットはそれぞれ02-13、06-25、07-13で停止
      • 3.2 オペレータ作業面は全面的にtriton-riscvの降格パスに移行（10-31〜11-01）
      • 3.3 パフォーマンス主线 #85は10-18で停止、降格パスの5件とリズムの対比を形成
    1. Buddy Compilerの動向
      • 4.1 BUDDY MLIR 0.1.3：16件のコミット、136ファイル、説明にはABIの1項目のみ記載（10-31）
      • 4.2 ナイトリー版と下流アンカー：3ホップ遅延が2日以内に解消、アンカーは依然ナイトリー版（10-31）
      • 4.3 3件が審査中で0.1.3に未収録、Whisperとインターフェース整合は依然宙に浮く（10-31時点）
    1. コミュニティとイベントと公式ホームページ
      • 5.1 公式ホームページ3ページに変化なし、ブログ2本、ドキュメント23章（11-02時点）
      • 5.2 フォーラム期間内に新規投稿なし、隔週進捗第080期未公開（11-02時点）
      • 5.3 ruyiai-daily 2期、情報範囲はPyTorch、Triton、KVキャッシュをカバー（10-31、11-01）
      • 5.4 外部ニュースはゼロヒット、ディストリビューション側の2つの月次コミットメントが同時に期限切れ（11-02時点）
    1. トレンド観察
      • 6.1 正式版の説明とコード差分が乖離、RISC-Vの進展はコミット履歴に隠れている
      • 6.2 triton-riscvが「1件修正して1件マージ」から「バッチ提出審査」へ転換、受け入れ側は依然不在
      • 6.3 ディストリビューション側の月次コミットメントが連続未達、スタックレベルパッケージングは依然spec層で手戻り中

今日の重点：Buddy Compiler 0.1.3が正式版リリース、16件のコミットのうち10件がRVVスケーラブルベクトル化、リリースノートにはサーバー側ABIのみ記載（10-31）

日付：2026-10-31　情報源：BUDDY MLIR 0.1.3、v0.1.2 と v0.1.3 のコミット差分、PR #999 rvv-vlen、PR #1003 scalable vector 幅選択

11-01 07:01（北京時間）、buddy-mlir は正式版 0.1.3 をリリースした。前回の正式版は 10-25 の 0.1.2 であり、その間には 5 つのナイトリービルドが挟まっている。リリースノートで展開されている項目は 1 つだけである。buddy-server の新しい ABI（#1015）、すなわちモダリティごとに別々に書かれていたモデルプラグインハンドルを統一インターフェースに収束させ、加えて統一されたロード、状態照会、呼び出し、ストリーミング、キャンセルの経路を備えたものである。

しかし v0.1.2 と v0.1.3 のコミット差分を取得して見ると、このバージョンには実際に 16 件のコミット、136 ファイルが含まれており、そのうち 10 件は [midend][VIR] 配下の RISC-V ベクトル化に関する一連の作業である：

  • #999 で (rvv-vlen) を導入し、可変長ベクトル長をベクトル化ターゲット属性とする；
  • #1000 でネストループ内のアクティブベクトル数を集計し、ベクトル幅選択の入力とする；
  • #1002 で可変長 strip-mining ループを vscale ステップで進めるようにする；
  • #1003 で RVV 向けに可変長ベクトル幅を選択する；
  • #1004 で結果を持つ set_vl を可変長ベクトルに降格する；
  • #1005 で set_vl 内の多次元動的ベクトルが結果を持つケースを処理する；
  • #1006 で動的ベクトルの行レベル vir.shuffle を新規追加する；
  • #1007 で vir.load / vir.store のインデックス規約を統一する；
  • #1008 でインデックスベクトルの幅を自動導出する；
  • #996 で vir.from_vector を新規追加し、再結合を削減する。

さらに 2 件が VIR ラインに属するが [midend] プレフィックスの下にはない。decode attention の VIR 方言実装（[frontend][tools]）と VIR の Python バインディング（#1009）である。つまり 16 件のうち 12 件がベクトル方言の層に手を入れており、しかもリリースノートには RISC-V や RVV について一言も触れられていない。

この落差は記録に値する。なぜなら「このスタックの RISC-V 進展はどこにあるのか」という問いへの答えを変えるからである。これまでの数期の判断はこうだった：buddy-mlir の RISC-V 作業は主にナイトリービルドで行われ、正式版は ABI リファクタリングのような汎用作業に占拠されており、下流が RVV の変更を入手するにはナイトリータグにアンカーするしかない。0.1.3 はこの判断が半分しか正しくないことを証明した——正式版は確かに RVV の一連を取り込んだが、リリースノートがそれに追随して更新されていない。リリースページを見る人は 0.1.3 が単なるサーバーサイドのリファクタリングだと思うだろうが、実際に手に入るのは可変長ベクトル化能力が著しく前進したバージョンである。

下流への直接的な意味はこうである：triton-riscv は 10-31 13:15 に依存アンカーを nightly/v0.1.3.dev20261030 に引き上げた（PR #91）。このナイトリービルドの日付は 0.1.3 正式版のパッケージ生成時刻より早いが、両者の内容は同源であり（0.1.3 は 10-29 のメインブランチ先頭から切り出された）、したがって RVV の 10 件はすでに下流で有効になっている。本当に追随できていないのは「アンカーが依然としてナイトリータグと書かれている」という点である——現行の renovate のリズムでは、release/v0.1.3 に切り替えるにはもう一巡待つ必要がある。

抑制すべきはカバレッジである。この 10 件は VIR 方言の可変長ベクトル化、すなわち set_vl から scalable vector への降格経路に集中しており、エンドツーエンドのモデル性能データではない。リリースノートにもベンチマークは一切示されていない。ベクトル化能力の前進は検証可能だが、どれだけ速く動くかについては今期は答えが出ていない。

1. RuyiAI スタックの進展（PyTorch / Triton / TileLang RISC-V 適配）

1.1 pytorch：riscv ブランチ 11-01 未明に 2 回目のブランチ全体リプレイ、ベースラインは依然 3afdbd3 のまま（11-01）

日付：2026-11-01　情報源：pytorch riscv ブランチ、PR #51 riscv64 ローカルイメージ、PR #44 bytes_to_scalar 修正、オープン PR 一覧

11-01 03:00、riscv ブランチが一度ブランチ全体のリプレイを行った。ブランチ上の20コミットのコミット時刻が一律 03:00:26 から 03:00:27 の1〜2秒以内に書き換えられ、作者時刻はすべて元のまま維持された。先頭コミットは 1867c9b8、メッセージは引き続き [SyncBots] Integrate PyTorch at 3afdbd3 で、この同期コミット自体の作者時刻は 10-29 12:48——つまり今回のリプレイはベースラインを変更しておらず、ブランチは依然として上流 3afdbd3 に留まり、10-29 のリプレイと同じ着地点である。

10-29 の回と比べると、違いは形式のみだ。前回は「7日間の静寂の後のリプレイ + 同期ボットによる依存キャッシュ修正の追加」であったのに対し、今回は「3日後に再度リプレイ、内容は不変」。ブランチ上のパッチセットも変化しておらず、依然として Add riscv64 image locally (#51)、Fix bytes_to_scalar for float/complex on RISC-V (#44)、Scope linear cross entropy ULP tolerance to RISC-V (#42)、inductor opinfo blocklist (#50) およびそれ以前の CI とテスト許容差の変更である。

この「ベースラインを動かさず、コミット時刻だけを変更する」リプレイには通常2つの原因がある。1つは同一ベースラインへの異なるパッチ適用順でのリプレイで、コンフリクトマーカーの除去や履歴の整理に用いられる。もう1つは自動化タスクによる周期的な無条件リプレイである。いずれにせよ、今回の内容に対する増分はゼロであり、記録に値するのはリズムだけ——2週間で2回のブランチ全体リプレイがあり、いずれも新たな上流同期を伴っていない。

引き続き留意すべきはあのズレである。配布側の python-torch-ruyiai（openRuyi #1352）はブランチ成果物に基づいてビルドされ、ブランチ先頭はリプレイのたびに SHA が変わるため、パッケージ内で固定されたソースの落とし所を再調整する必要がある。今回はその調整動作が見られなかった。

1.2 llvm-project：riscv ブランチが 11-01 深夜にリプレイ、A100 の IME/AME 引き下げが含まれる（11-01）

日付：2026-11-01　情報源：llvm-project riscv ブランチ、RISCV_CONTRIBUTING.md、リベースワークフロー

11-01 23:00、riscv ブランチも同様にブランチ全体のリプレイを行い、26のブランチ固有コミットのコミット時刻が一律 23:00:22 から 23:00:26 に書き換えられた。先頭コミットは afdd0982、内容は [workflows] Push rebased PRs directly and document contribution options（作者時刻 10-29 01:59）、すなわち前回記録した「プレビューを廃止し、コントリビューションガイドを追加」する変更——これが依然としてブランチ先頭であり、今回それの上に新しいものは積まれていない。

ブランチ内で本スタックに最も関連するのは依然として A100 の2件、[RISCV] Lower IME intrinsics to SpacemiT A100 dot instructions (#30) と [RISCV] Add A100 HP/SP and pack/unpack lowering with calibrated scheduling (#31) である。前者は IME 組み込み関数を A100 のドット積命令に降下させ、後者は HP/SP の2つの精度形態の pack/unpack 降下を補い、校正済みのスケジューリングモデルを伴う。さらに下の層には [AME] Update BOSC AME instructions (#29) と [RISCV] Update xtame design (#27) があり、「AME 設計ドキュメント → 命令定義 → 組み込み関数 → 降下とスケジューリング」という完全なチェーンを構成している。このチェーンは行列拡張に資するもので、RuyiAI の「RVV から Matrix へ」という物語のコンパイラ側における着地点である。

次回確認が必要な不整合が1つある。ブランチ上の直近の [SyncBots] Integrate LLVM at b3b5e33 の作者時刻は 09-29 で止まっているが、現在の先頭コミットと前回の先頭コミットをコミット比較すると、返される差分集合には 10-30 の上流コミット（例えば [clang][AST] Don't give NestedNameSpecifier pointer identity in DynTypedNode (#233153)、[libc] Add truncation casts to avoid warnings in file_test.cpp (#237262)）が含まれる。両者を並べると解釈は1つしかない。今回のリプレイは履歴を書き換えると同時に上流ベースラインを前進させたが、同期ボットの記録にはそれに伴う1件が追加されていない。同期記録と実際のベースラインが乖離すると、「このブランチはどの上流に基づくか」といった判断は比較インターフェースから逆算するしかなくなる。今後、ブランチ上に明示的なベースライン説明を追加することを推奨する。

1.3 triton-riscv：2件のマージ、5件の新規オープン、さらに1件が公式 Triton v3.8.0 へリベース（10-30 から 11-01）

日付：2026-10-30 から 2026-11-01　情報源：PR #55 asin フロントエンドパッチ、PR #91 依存関係更新、PR #92 Triton v3.8.0 へのリベース、コミット一覧

メインブランチには調査期間内に2件がマージされ、いずれも週末だった。10-30 20:14、[patches] Support asin op via frontend patch (#55) がマージされた——これは asin オペレータをフロントエンドパッチの形で取り込むもので、バックエンドが逆三角関数をサポートしていない制限を回避している。「フロントエンドの書き換え1回でオペレータ1つを使えるようにする」典型的な手法である。10-31 13:15、renovate の #91 が buddy-mlir 依存を nightly/v0.1.3.dev20261029 から dev20261030 へ引き上げた。その後、メインブランチに新たなコードコミットはない。

実際の変化は PR キューにある。maochuanjun は 10-31 15:20 から 11-01 17:36 の間に5件を連続してオープンし、すべて降級と解析の2層に属している：

  • #93 [Conversion] Preserve scalar load/store masks（10-31 15:20）、スカラーアクセスのマスク保持；
  • #94 [Analysis] Preserve lane offsets in mixed pointers（10-31 21:57）、混合ポインタ内の lane オフセット保持；
  • #95 [Conversion] Lower tensor gathers（10-31 23:41）、テンソル gather の降級；
  • #96 [Analysis] Preserve incomplete tensor masks（11-01 17:29）、不完全テンソルマスクの保持；
  • #97 [Conversion] Handle stacked zero strides（11-01 17:36）、スタックされたゼロストライドの処理。

5件のタイトル構成は整っている：Conversion が3件、Analysis が2件で、いずれも「ある種の情報を失わずに保持する」という表現だ。これは 10-29 の3件の修正（テンソル充填、ループキャリーオフセット、散列テスト）と同じ問題群の継続である——降級パスが Triton IR を構造化/非構造化形態へ変換する際に、マスク、オフセット、ストライドといった境界情報を繰り返し失い、一種類失うたびに1件補う必要がある。

さらに方向性の異なる1件がある：#92 [triton] Rebase integration onto the official Triton v3.8.0 release（jason-hue、10-31 12:57 更新）。これは欠陥修正ではなく、RISC-V 統合全体を公式 Triton 3.8.0 上へ移すものだ。これまでこのリポジトリの統合ベースラインは [triton] Update integration for latest upstream (#76)（09-02）で止まっており、中間の2ヶ月間はパッチのみでリベースを行っていなかった。#92 がマージされれば、後続5件の落とし込み先も一度移動することになる。これが #92 と #93 から #97 が同時にキューにありながら一連にマージされていない理由でもある——リベースは先行アクションであり、まず手を付けない。

1.4 tilelang-riscv：メインブランチは17日目連続で静か、オープン PR は1件のみ（11-01 時点）

日付：2026-11-01（時点）　情報源：tilelang-riscv コミット一覧、オープン PR #4

メインブランチの最後のコミットは依然として 10-16 10:52 の「Build Python extension in Buddy CI」であり、17日連続でコミットがない。オープン PR は2件から1件に減り、残るのは #4「RVV vector mask and max reduction lowering」（09-28 で停止）のみ；以前あった #2「Add Codex-compatible RISC-V operator workflow」はオープンリストから外れている。

同一組織、同一調査期間で、triton-riscv は三日間に二件を取り込み、五件を起票したが、tilelang-riscv は一件もない。この分化はすでに三週間続いており、「週末は誰もいない」ではもはや説明できない。外部から見える代替経路はただ一つ：openRuyi の python-tilelang-ruyiai 仕様（#1350 の三件セットに含まれる）であり、つまりリポジトリの反復の代わりにディストリビューション成果物を用いるというものだ。しかも #1350 自体がまだレビューで止まっている。二つの道が同時に止まっているということは、このコンポーネントは今期、前進する方向がまったくないということに等しい。

2. RuyiSDK ツールチェーンとディストリビューション

2.1 openRuyi：六件のコミットはすべて 10-30 に集中、LLVM 23 と ollama のセキュリティ更新がマージ（10-30）

日付：2026-10-30　情報源：PR #1424 LLVM 23、PR #1514 ollama セキュリティ更新、PR #1545 clang-wrap、メインリポジトリのコミット一覧

調査期間内の六件のコミットはすべて 10-30 の一日に集中し、その後は週末全体でコミットゼロ。三件の PR がマージされた：

11:20 に #1424 をマージ、llvm23 パッケージを新規追加、バージョンは 23.1.4。これは LLVM 23 を併存パッケージとして導入するものであり、デフォルトのツールチェーンを全体として引き上げるのではない。ディストリビューションとしては低リスクな手法だ：新バージョンを必要とするプロジェクトは明示的に llvm23 に依存し、それ以外は従来のデフォルトのままで、一度のメジャーバージョン跳躍で全ビルド面を巻き込むことはない。RISC-V 側にとっての意味はツールチェーンバージョンの選択肢があること——これまでは新しい LLVM バックエンドを試すには自前でビルドするしかなかった。

12:39 に #1514 をマージ、ollama を 0.40.7 に上げ security-fixes を付与。この件は前号ではまだレビュー待ちキューにあった（執筆時点で +259/−3371、削除されたのは vendor ディレクトリ）が、今期マージされたということは、あの一連のセキュリティ修正がすでにメインラインに入ったことを意味する。同じ分にさらに三件の go エコシステムパッケージが着地した：go-github-tree-sitter-cpp、go-github-tree-sitter-go-tree-sitter、go-github-mattn-go-pointer で、いずれも既存パッケージの依存クロージャを補うものだ。

17:39 に #1545 をマージ、clang-wrap が 20261030 に追随。このパッケージは上流と同日リズムを保つことがすでに何号も連続しており、ディストリビューションの中で数少ない「毎日動きがある」仕様に属する。

六件のコミットのうち、RuyiAI 三件セットを直接変更したものは一件もなく、つまりディストリビューション側が今期行ったのは「土台を前へ動かす」ことであり、「スタックを載せる」ことではない。

2.2 openRuyi レビュー中：Prometheus 依存バッチは十三件、box64 と firecracker がキューに追加（10-30 から 11-01）

日付：2026-10-30 から 2026-11-01　情報源：PR #1561 box64、PR #1559 firecracker、PR #1516 qemu-rustsbi、PR #1562 binutils RISC-V テスト追跡、PR #1547 から #1557 Prometheus バッチ

オープンキューには調査期間内に二十四件の更新があり、規模は前号より大きく、構造的な特徴も明確だ：

最大の塊は Prometheus v3.13 のモジュール依存バッチで、計十三件（#1540、#1441、#1547 から #1557）。すべて同一作者が DAG 順にバッチでコミットしており、タイトルは統一して「Add Prometheus v3.13 modules - DAG dependency batch NN」。このように「依存グラフを十数件に切り分けて層ごとにコミットする」手法は、ディストリビューションでは往々にしてやむを得ず採られる——一度にコミットするとレビュアーから分割を求められ、層ごとに分ければ各件を独立してビルド検証できることが保証される。代償はマージウィンドウが長引くことで、どの層かが詰まれば後続はすべて入れなくなる。

第2のクラスタは仮想化とバイナリトランスレーションです：#1561 で box64（RISC-V 上で x86-64 プログラムを動かす動的リコンパイラ）を新規追加、#1559 で firecracker（軽量マイクロVM）を新規追加、#1516 で qemu-rustsbi（RustSBI 作者 luojia65 によるコミット、既に5件の議論あり）を新規追加。三つを重ねて見ると、指し示しているのは同じ種類のニーズです——RISC-V デスクトップ上で非ネイティブソフトウェアと隔離された負荷を動かすこと。

第3類は RISC-V に直接関係するメンテナンス項目です：#1562 binutils: Track RISC-V pr19719 test failures は、binutils 内の RISC-V 関連の既知のテスト失敗を、直接修正するのではなく追跡項目として登録するものです。このやり方はディストリビューションにおいて「ビルドは通るが、テストは全部グリーンではない」ことを意味し、下流で binutils を使ってリンクする人には有用な情報です。

残りは3件の定例のバージョン追従です：#1563 で Node.js を 26.13.0 に上げてシステムライブラリを使うよう変更、#1544 で firefox を 159 に上げ、#1421 で qemu に GUI テスト用の機能群を有効化。

2.3 Ruyiai 三件セット #1350：第2週も spec 規範で停滞、10-30 に一度リフレッシュ（10-30 状態）

日付：2026-10-30（状態）　情報源：PR #1350 Add Ruyiai packages、PR #1352 python-torch-ruyiai

#1350（buddy-mlir、python-triton-ruyiai、python-tilelang-ruyiai の三件セット）は 10-30 16:16 に一度リフレッシュされましたが、依然としてマージされておらず、タイムラインに 10-30 の記録が1件増えました。前号で記録した18件のレビュー意見はすべて spec の書き方に向けられていました——BuildOption の間に空行を挿入する必要はない、BuildRequires: python3dist(wheel) が欠けている、Provides は実際のパッケージ名と揃える必要がある、パッチは git format-patch で生成する必要がある、空の %check にはコメントを書く必要がある——今号では新たな方向性の議論は出てきていません。

09-21 の開始から現在まで、この PR は既に第6週を超えています。前号ではこれを「ゼロから spec を書くため、あらゆる非定型点を説明する必要がある」と要因分析しましたが、今号で見るともう一層あります：三件セットのうち buddy-mlir は LLVM を自前で持ち、triton は git 実行ファイルに依存し、tilelang は buddy-mlir ツールチェーンを発見する必要があり、この3つの非定型点はレビューで個別に指摘されているものの、それらを一つにまとめる統一的なパッケージング規約ドキュメントがありません。その結果、毎回のレビューで同じ問題群を再度説明しなければならず、手戻りコストは文章作成ではなく往復に発生しています。

同じ束の #1352（python-torch-ruyiai）は今号アクションがなく、依然として 10-27 で止まっています。これは 1.1 の pytorch ブランチのリプレイと同じ未解決の問題です：ブランチはリプレイのたびに SHA が変わり、パッケージ内のソースの落とし所も合わせて変更するのかどうか、誰も結論を出していません。

2.4 ruyi 0.54.0：10月末の見通しが外れ、メインブランチはドキュメント1件のみマージ（10-30）

日付：2026-10-30　情報源：PR #508 ベンダー命名リスト、ruyi タグ、ruyi Releases

10-30 09:54、ruyi メインブランチに #508「docs: update vendor naming list」がマージされ、ベンダー命名ドキュメントに BananaPi、OrangePi、XiangShan、ZhiheComputing の4つの識別子が追加されました。ドキュメント側のこの整合と、ruyi-imager がインターフェースの「製造元」を「サプライヤー」に変更したのは同じ事柄の両端であり、2箇所で呼び方が不一致になるのを避けるものです。

これ以外、0.54.0 の状態に変化はありません：タグ一覧では 0.54.0-alpha.20260918 以降も新規タグはなく、正式版の最新は依然として 09-24 の 0.53.0 で、メインブランチは 09-25 以降このドキュメント1件を除いてコミットがありません。隔週進捗 079 号で示された見通しは「リリースサイクル調整のため10月末に変更」でしたが、今日は 11-02 で、10月は既に終わっており、この見通しは既に外れており、新たな見通しも出てきていません。

注目すべきは外れ方です：リリース失敗でもなく、リリース候補の巻き戻しでもなく、10月下半月にコードの動きがほとんどなかったのです。#508 はドキュメント変更1件で、つまり10月末のその期間、メインブランチ上には「リリースのための準備」すらほとんどなかったということです。これは 0.53.0 以前のリズムとは異なります——当時は alpha、beta、正式版と連続3段跳びでしたが、今は最初の一跳びすらありません。

2.5 openRuyi 2026.10 は未リリース、月次リリースのリズムに空白が発生（11-02 状態）

日付：2026-11-02（状態）　情報源：openRuyi ニュースページ、openRuyi メインリポジトリ

openRuyiディストリビューションのニュースページの最新記事は依然として「openRuyi 2026.09 リリース」（09-30）であり、2026年10月のリリース告知ページは404を返す。過去4か月のリリース日はそれぞれ6-30、7-23、8-27、9-30であり、厳密に同じ日ではないものの、丸一か月欠番となった前例はない。10月分のこのリリースは11-02時点でもまだ出現していない。

この項目は2.4と併せて読むことで、今号で最も留意すべき一組の事実を構成する：「RuyiSDKエコシステム配布」に属する二つのパイプライン——パッケージマネージャruyiとディストリビューションopenRuyi——が、同じ10月末にそれぞれ一度ずつ公開の月次コミットメントを逃したのである。しかも両ラインともコード側は停滞しているとは言えない（openRuyiメインリポジトリは10-30にも6件のコミットがあり、ruyiにはドキュメントのマージがある）。これはボトルネックが開発になく、リリースそのものにあることを示している：バージョンフリーズ、告知文の執筆、イメージビルドとリリースフロー、この区間が直近2か月間、期日通りに走っていないのである。

3. ベクトル拡張とオペレータ最適化（VecIntrinBench / IntrinTrans / FBGEMM）

3.1 三つのベクトルリポジトリは今号すべて沈黙、最新コミットはそれぞれ02-13、06-25、07-13で停止

日付：2026-11-01（状態）　情報源：VecIntrinBench、IntrinTrans、FBGEMM

組織内で「ベクトル」をテーマとする三つのリポジトリは、今号いずれも調査期間内のコミットがなく、しかもそれらの最新コミット時刻は三つの異なる四半期に分散している：VecIntrinBenchは02-13で停止、IntrinTransは06-25で停止、FBGEMMは07-13で停止。三者はそれぞれベクトル組み込み関数ベンチマーク、組み込み関数翻訳、量子化オペレータバックエンドであり、本来「何を測るか、どう翻訳するか、オペレータをどう実装するか」という三角を構成していた。

この三角は現在全体として停止しており、しかも停止した時点がそれぞれ異なることは、統一的なプロジェクト終了ではなく、各自が自然に冷却したことを示している。VecIntrinBenchが約9か月間停止しているのは最も説明に値する点である——ベクトル組み込み関数ベンチマークライブラリが長期に更新されなければ、それが測るカバレッジはコンパイラが実際にサポートする集合からますます乖離していく。

3.2 オペレータ作業面はすでに全体がtriton-riscvの降級パスへ移動（10-31から11-01）

日付：2026-10-31から2026-11-01　情報源：PR #93、PR #94、PR #95、PR #96、PR #97

三つの専用リポジトリがすべて停止した以上、オペレータ層の実際の作業面はtriton-riscvのPRキューからしか見られない。今号新規オープンの5件のPRはすべて「情報保持」を巡るものであり、一件ずつ分解すると以下のようになる：

#93はスカラーload/storeのマスクを処理する——スカラーアクセスパスは降級時にマスクを定数真値として最も失いやすく、一度失われれば、条件付きのスカラー読み書きは構造化IR内で無条件となり、範囲外アクセスはエラーにならずダーティデータを読むことになる。#94は混合ポインタ内のlaneオフセットを処理する。すなわち、一つのポインタ式に基底アドレスとlaneごとのオフセットの両方が含まれる場合、解析段階で基底アドレスのみを保持し、オフセットを定数として扱う。#96は不完全なテンソルマスク、すなわちマスク形状がテンソル形状より小さい場合のブロードキャストセマンティクスを処理する。#97はスタックされたゼロストライド、すなわち複数の次元がすべてゼロストライドの場合、降級後に一つの次元に折り畳まれる可能性があるものを処理する。

#95は唯一の「情報保持」ではなく「新規能力」の一件である：テンソルgatherを降級させる。これまでgatherは非構造化パスしか通れず、構造化パスには対応する実装がなかったが、#95はこの欠落を補うものである。

5件の共通背景は同じ一件事である：この層の正しさは「実際のオペレータを持ち上げて実行する」ことで露呈させるのであり、回帰テストによってではない。3週間で累積した8件（10-29の3件＋今号の5件）はすべてこの類に属する。この仕組みは有効だが、コストは高い——オペレータを一批持ち上げるたびに一連の境界ケースを修正せねばならず、しかも修正後の検証強度はまちまちである（10-29の3件のうち、1件は全量lit 291項目を実行し、1件は対象を絞った回帰のみ、1件は単一ファイルのみを実行した）。

3.3 性能メインライン#85は10-18で停止、降級パスの5件とリズムの対照をなす

日付：2026-10-18（状態）　情報源：PR #85 softmax と matmul の最適化

#85「softmax 及び matmul の最適化」は 10-18 23:55 以降更新がなく、今期も引き続きその場に留まっている。これは当該リポジトリで唯一、明確に性能を目標としたオープン PR であり、降級経路の五件とは明確な対照をなしている。正確性の方向では一週間で五件提出できる一方、性能の方向では半月動きがない。

「実際のモデルを動かす」ことを目指すスタックにとって、この対照には具体的な結果が伴う。マスク、オフセット、ストライドといった正確性の修正は「正しく計算できるかどうか」を決め、softmax と matmul の最適化は「十分に速く計算できるかどうか」を決める。前者が急速に進む一方で後者が止まっているということは、たとえ 604 個のオペレータをすべて移植できたとしても、エンドツーエンドの性能は三週間前の水準に留まることを意味している。

4. Buddy Compiler の動向

4.1 BUDDY MLIR 0.1.3：十六件のコミット、百三十六ファイル、ABI の一项だけを書いたことを示す（10-31）

日付：2026-10-31　情報源：BUDDY MLIR 0.1.3、コミット差分 v0.1.2…v0.1.3、PR #1015 buddy-server 新 ABI、PR #1009 VIR Python バインディング

0.1.3 のコミット差分は「今日の重点」で既に展開した内容と互いに裏付け合うものであり、ここでは重点で触れなかった三点の観察を補う。

第一に、このバージョンのファイル面はコミット数以上に大きい。十六件のコミットで 136 ファイルが動いており、その相当部分は #1015 のインターフェース再構築に由来する（ランタイムヘッダ四個を新規追加し、モダリティ別に書かれたプラグインハンドル四組と対応する単体テストを削除）。つまり 0.1.3 は同時に二つのことを盛り込んでいる——ベクトル方言の十件の連続的な推進と、七十余ファイルにまたがるプラグイン体系の収束——二つは時間的に重なり（VIR の十件は 10-25 から 10-27、#1015 は 10-29）、レビュー上では別々に進んだ。

第二に、[frontend][tools] Implement the decode attention in the VIR dialect のコミットは見落とされやすいが、その指し示す方向は先の VIR 降級とは異なる。decode attention を VIR 方言内の実装として書くことは、「アテンション・デコード」という具体的な負荷に対して方言からベクトル化までの直通路を築くことに等しい。これは VIR が「汎用ベクトル方言」から「負荷別最適化」へ向かう最初の一件である。

第三に、VIR の Python バインディング（#1009）は、この方言を Python 側から構築・検査できることを意味し、下流にとっての直接の利点は、triton-riscv のようなプロジェクトが Python 層で VIR を生成して単体検証できるようになり、毎回完全なコンパイルチェーンを通す必要がなくなることである。

4.2 ナイトリービルドと下流のアンカー：三ホップの遅延が二日で閉じ、アンカーは依然ナイトリー（10-31）

日付：2026-10-31　情報源：ナイトリー dev20261030、triton-riscv PR #91、Releases 一覧

前回、固定された遅延構造を一つ記録した：buddy-mlir のマージ → 翌日のナイトリービルド → renovate による依存更新の提案 → triton-riscv のマージ、という三ホップは通常一～二日である。今期このチェーンが一度完全に走り切ったので、各ステップの実所要時間を確認できる：

#1015 は 10-29 15:08 にメインブランチへマージされた。ナイトリー dev20261030 は 10-30 08:49 にパッケージ化され（#1015 を含む）、renovate の #91 は 10-31 13:15 に triton-riscv へマージされた。マージから下流が受け取るまでの合計は二日と五分であり、「一～二日」という見積もりと符合する。

ただ、アンカーの形態は変わっていない。triton-riscv が依存しているのは依然としてナイトリータグ nightly/v0.1.3.dev20261030 であり、10-31 23:01 に出た正式版 release/v0.1.3 ではない。二つのタグの内容は同源である（0.1.3 は 10-29 にメインブランチの先頭から切り出され、dev20261030 も同様）。違いは再現性にある——ナイトリータグは後続のビルドによって参照が上書きされるが、正式タグは上書きされない。ディストリビューションに取り込むスタックにとって、長期的にナイトリー版をアンカーにするということは、パッケージ内で固定された来源が長期的に再現不可能であることを意味し、これは 2.3 の「パッチは git format-patch で生成する」と同じ種類の要求である。

4.3 審査中の三件は 0.1.3 に入らず、Whisper とインターフェースの整合は依然宙に浮く（10-31 状態）

日付：2026-10-31（状態）　情報源：PR #1011、PR #1013、PR #994、オープン PR リスト

0.1.3 の十六件のコミットには #1011、#1013、#994 の三件が含まれておらず、これらが依然として正式バージョンに取り込まれていないことを示している。三件の性質はそれぞれ次のとおり：#1011 はスケーラブル VIR フラグメントのカウントを強制的に int64 に変換する（今期の VIR 十件と同じベクトル幅の路線に属する）、#1013 は Whisper の単一転写内で前処理を再利用する、#994 は buddy-server のインターフェースを llama-server に整合させる。

三件の中で最も厄介なのは #994 である。それが整合させようとしている llama-server インターフェースは、まさに #1015 がリファクタリングで置き換えたその層である。0.1.3 はすでにモダリティ別に分割されたプラグインハンドルを統一 ABI に収束させており、#994 を元の方向でマージすると、書き換えられたばかりのインターフェースの上にさらに互換層を重ねることになる。PR ではこの衝突について議論されておらず、今期もそれがクローズまたは方向転換された形跡は見られない——現在の状態は「バージョンにも入っておらず、否定もされていない」である。

#1011 の状況も類似しているが方向は逆である。それはベクトル幅路線の締めくくり項目であり、同期の十件の VIR 作業はすでに 0.1.3 に入っている。締めくくり項目がバージョンの外に落ちているということは、0.1.3 のスケーラブルベクトル化が「フラグメントカウントが 32 ビットを超える」という境界において依然として結論が出ていないことを意味する。

5. コミュニティとイベントと公式サイト

5.1 公式サイトの三ページに変化なし、ブログ二篇、ドキュメント二十三章（11-02 状態）

日付：2026-11-02（状態）　情報源：RuyiAI 公式サイト、ブログインデックス、ドキュメントインデックス

公式サイトの三ページは調査期間内にいずれも変化がなく、スナップショットハッシュは前号と一致している：トップページインデックス 3 件、ブログインデックス 2 篇（「Triton の RISC-V 適配」と「PyTorch RISC-V CI 実践」）、ドキュメント 23 章。この状態はすでに複数期連続で維持されており、今期は新規記事や章の追加はなかった。

4.1 と対照すると、この静けさはやや特殊である：0.1.3 の十件の RVV ベクトル化作業は直近三か月で最も体系的な進展の一段落であるにもかかわらず、ブログ側には対応する解説記事がない。公式ブログの二篇はいずれも「適配実践」類であり、欠けているのはまさに「ベクトル化能力はどこまで進んだか」といった段階的説明である。

5.2 フォーラムは調査期間内に新規投稿なし、隔週進捗 080 期は未公開（11-02 状態）

日付：2026-11-02（状態）　情報源：RuyiSDK 開発者コミュニティ、投稿 #2899、隔週進捗 079 期 #2895

フォーラムは調査期間内に新規投稿がなく、最新の投稿は依然として 10-29 の #2899（RuyiAI が第六回 RISC-V 中国サミットに登場）であり、この項目は前号ですでに収録済みである。前回の正式報告は 10-26 の 079 期であり、080 期は隔週のペースであれば 11 月上旬に公開されるはずだが、今期はまだ出现していない。

なお、フォーラムの活発度分布について説明が必要である：10-29 の三投稿（#2897 から #2899）はすべてサミット関連の内容であり、その後四日間はゼロ投稿であった。サミットの話題が十月底の議論枠を使い切っており、次の波は 080 期を待つ必要がある。

5.3 ruyiai-daily 二期間、情報範囲は PyTorch、Triton と KV キャッシュをカバー（10-31、11-01）

日付：2026-10-31、2026-11-01　情報源：ruyiai-daily

デイリーニュース倉庫は調査期間内に2期分（daily-news: 2026-10-31 と daily-news: 2026-11-01）をコミットしており、依然として毎日22:20から22:40の間という固定リズムである。11-02の分はそのリリース習慣に従えば当日夜間にならないと出現せず、調査期間内にはなかった。

この2期は本レポートのクロスチェック情報源の一つである。うちPyTorch上流同期、Tritonデグレード経路に関する項目は本レポート1.1、1.3の判断と一致しており、表現の食い違いは発生していない。

5.4 外部ニュースはゼロヒット、ディストリビューション側では2件の月次コミットメントが同時に期限切れ（11-02時点）

日付：2026-11-02（時点）　情報源：Google News RSS、openRuyi ニュースページ

RuyiSDK、RuyiAI、openRuyiの3組の中英語による定向クエリは調査期間内にゼロヒットであった。中国語側で唯一「如意」を含む結果は依然として10-25のサミット出展報道（奕行智能）であり、調査期間外でかつ如意コミュニティとは無関係である。「openRuyi」の英語クエリは4月の旧記事を1件返すのみであった。

外部に報道がないことは、2.4、2.5の観察と矛盾しない。2件の月次コミットメントの不履行はいずれも「起こらなかったこと」に属し、本来ニュースにはならないからだ。本当に問題を示しているのは内部シグナルである。パッケージマネージャとディストリビューションが同時に10月のリリースウィンドウを逃しており、しかも両ラインともコード側はまだ動いている。

6. トレンド観察

6.1 正式版の説明とコード差分の乖離、RISC-Vの進展がコミット履歴に隠れている

0.1.3の這件事の方法論的意義はそれ自体よりも大きい。プロジェクトの「対外説明」と「実際に組み込まれたもの」が長期間一致しない場合、外部からの判断はコミット履歴から逆推測するしかない。今期の具体的な現れは、リリースノートにはサーバー側ABIリファクタリングしか書かれておらず、16筆のコミットのうち12筆がVIRベクトル層を変更していることである。

この乖離には慣性のコストがある。下流にとっては「アップグレードすべきか」を判断するためにリリースノート、コミット差分、依存アンカーの3箇所を同時に見る必要がある。上流にとっては、本当に見てほしい作業が本来出るべきページに出ていない。直近3ヶ月で最も体系的なベクトル化の進展は、ブログ、ドキュメント、リリースノートの3箇所のいずれにも対応する記述がない。「RVVからMatrixへ」を語るスタックが、ベクトル化の進展をコミット履歴の10行のタイトルとして書いてしまうのは無駄である。

より実際的なリスクはレビュー側にある。バージョン説明が一部の変更しかカバーしていなければ、レビュー者の注意力もその部分に集中し、もう一方の変更は「すでに正式版に組み込まれた」後には誰も振り返らなくなる。

6.2 triton-riscvは「1筆修正して1筆マージ」から「バッチ申請」へ転換、検収側は依然不在

10-29の3筆は「80分以内に連続マージ」、今期の5筆は「2日以内に連続オープン、未マージ」である。前者はメンテナが明確な欠陥修正に対して迅速なチャネルを持っていることを示し、後者は新たな一群の変更がまだその段階に達していないことを示す。2つのリズムの違いは開発強度になく、レビュー帯域にある。

この5筆に10-29の3筆を加えると、3週間で同類の修正が8筆累積し、すべてデグレード経路の情報欠落を指している。この数量自体がシグナルである。この経路には体系的な等価性チェックが確立されておらず、オペレータごとに突き当て、突き当てるたびに補うしかないことを示している。そして下流にとって最も価値のあること——FlagGemsの604個のオペレータのエクスポートを毎晩1回実行する常駐リグレッションにすること——は依然として行われていない。PR #56は09-16の停滞から回復したものの（10-30 20:50に1回プッシュがあり、規模は156の新規ファイルに拡大、エクスポート項目は468から604へ）、依然としてオープン状態である。

検収がPRの中にありパイプラインの中にない限り、「この一群のオペレータがriscv64で動作するか」という問題は繰り返し先送りされる。

6.3 ディストリビューション側の月次コミットメントが連続不履行、スタックレベルパッケージングは依然spec層で手戻り

10月の最後の3日間で、「配布」に直接関連する2つのラインが同時にウィンドウを逃した。ruyi 0.54.0の「10月底」の表現は不履行となり、openRuyiの2026.10バージョンは11-02時点で未リリースである。両ラインともコード側は停止していない——openRuyiは10-30にも6筆のコミットがあり、ruyiにはドキュメントのマージが1筆ある——したがってボトルネックはリリースプロセス自体にあり、開発にはない。

同時に、スタックレベルの三点セット#1350はすでに第6週を越え、依然としてspec規範レベルで手戻りしている。この3件を合わせると、同じ構造的問題を指す。このエコシステムの「ものを作る」と「ものを出す」は2つの能力であり、前者は複数のリポジトリで同時に推進されているが、後者は直近2ヶ月で一度も期日通りに完了していない。

RuyiAIにとって、短期的に最も実際的な提案はリリースを急かすことではなく、2.3の3つの非定型点（buddy-mlirがLLVMを自前で持つ、tritonがgitに依存、tilelangがツールチェーン検出を必要とする）をパッケージング規約として書き下し、#1350のレビューが毎週同じ一群の問題を再討論しなくて済むようにすることである——往復コストを下げてこそ、月次リリースリズムへの移行が語れる。

情報源チェック表

情報源 検査結果
RuyiAI-Stack 組織（全リポジトリ） pytorch：riscv ブランチ 11-01 03:00 二回目の全体リベースで二十筆をリプレイ、先頭コミット 1867c9b8、ベースラインは依然 3afdbd3、新規パッチなし；llvm-project：riscv ブランチ 11-01 23:00 二十六筆をリプレイ、A100 の IME/AME 引き下げ（#30、#31）が含まれ、比較インターフェースでは上流ベースラインに 10-30 コミットが既に含まれていることを表示；triton-riscv：二筆マージ（#55、#91）、五筆新規オープン（#93 から #97）、一筆リベース（#92）、#56 は 10-30 20:50 にプッシュ再開；tilelang-riscv は十七日目も静寂、オープン PR は #4 のみ；VecIntrinBench、IntrinTrans、FBGEMM、harness、cpuinfo、torq-tile、pytorch-ci、dsh-osc、skills、caffe、mxnet は調査期間内コミットなし
ruyisdk 組織（全リポジトリ） ruyi メインリポジトリ：1 筆コミット（#508 ベンダー命名リスト）、新規 Release なし、0.54.0 は依然 09-18 の alpha タグのみ、正式版は 0.53.0 を維持；packages-index、support-matrix、docs、ruyisdk-website、ruyi-imager、wechat-articles、attached-matrix-extension、ruyici、AME-operator は調査期間内コミットなし
openRuyi-Project 組織 メインリポジトリ 6 筆コミット（すべて 10-30）＋ 3 筆 PR マージ（#1424 LLVM 23、#1514 ollama 0.40.7、#1545 clang-wrap 20261030）；オープン PR 24 筆に調査期間内活動あり（Prometheus バッチ 13 筆、#1561 box64、#1559 firecracker、#1516 qemu-rustsbi、#1562 binutils RISC-V テストトラッキング、#1563 Node.js、#1544 firefox、#1421 qemu GUI、#1350 Ruyiai 三点セット）；2026.10 バージョンは未リリース、リリースページは 404
buddy-compiler 組織 buddy-mlir：正式版 0.1.3 を 10-31 23:01 UTC にリリース（v0.1.2 から v0.1.3 まで計 16 筆コミット、136 ファイル、うち 10 筆は [midend][VIR] RVV ベクトル化）＋ ナイトリー版 dev20261030；メインブランチは調査期間内コミットなし（最新 10-29 07:08）；#1011、#1013、#994 は 0.1.3 に未収録
RuyiSDK 開発者コミュニティフォーラム 調査期間内の新規投稿なし、最新は依然 10-29 の #2899；隔週進捗 079 期（10-26）が直近の正式報告、080 期は未公開
openRuyi ディストリビューションニュースページ 新規記事なし、2026.09 リリース告知（09-30）が依然最新；2026-10 と 2026-11 のリリースパスはいずれも 404 を返す
ruyi パッケージマネージャー / Releases 0.53.0 を維持、新規 alpha または beta なし（0.54.0-alpha.20260918 が依然直近バージョン）；メインブランチはドキュメントコミット一筆のみ
公式ホームページ（ruyiai.org） 三ページとも変化なし：ホームインデックス 3 件、ブログ 2 篇、ドキュメント 23 章、スナップショットハッシュは前回と一致
ruyiai-daily 調査期間内二期（10-31、11-01）、基準は本レポートと一致
Google News RSS（中日英複数組） RuyiSDK、RuyiAI、openRuyi、如意 RISC-V の定向クエリはゼロヒット；「如意」側の最新は 10-25 のサミット出展報道で、調査期間外かつ如意コミュニティとは無関係のため未収録

完全な情報源リスト

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