調査期間：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を照合；上流forkはRISC-V / RVV / 玄鉄などのキーワードでフィルタリング）、openRuyiのコミットとPRマージ統計、ruyiパッケージマネージャとruyi-imagerのRelease、RuyiSDK開発者コミュニティフォーラム、ruyiai-dailyデイリー情報アーカイブ、RuyiAI公式サイト3ページのスナップショット、arXiv検索、Google News RSSの中英文定向クエリ（プロキシ経由）。

本期インデックス

  • 今日の重点：triton-riscvで1日3件マージ、すべてFlagGemsオペレータ移行で露呈したデグレード欠陥に由来（10-29）
    1. RuyiAIスタック進展（PyTorch / Triton / TileLang RISC-V適配）
      • 1.1 pytorch：riscvブランチは7日目に静かに終了、ブランチ全体を再適用して上流3afdbd3へ（10-29）
      • 1.2 llvm-project：riscvブランチ全体を再適用、コントリビューションガイドを追加しプレビュー用スイッチを取消（10-29）
      • 1.3 triton-riscv：デグレード修正3件が80分以内にマージ、依存更新は依然オープン（10-29）
      • 1.4 tilelang-riscv：mainブランチ14日目も静か（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 ベクトル4リポジトリは引き続き静か、ベンチマーク側の欠落は依然（10-29時点）
      • 3.2 FlagGems移行がtriton-riscvの欠陥発見メカニズムに（10-29）
      • 3.3 arXivは期間内に新規なし、10-27の2件が最新（10-29時点）
    1. Buddy Compiler動向
      • 4.1 buddy-server新ABIマージ：56ファイル、モデルプラグイン体系を統一インターフェースに変更（10-29）
      • 4.2 ナイトリービルドdev20261029が#1015より早くリリース、下流は次版待ち（10-29）
      • 4.3 審査中3件は10-28で停止、Whisperとインターフェース整合はいずれも未着手（10-29時点）
    1. コミュニティ・イベント・公式サイト
      • 5.1 公式サイト3ページに変化なし、ブログ2件、ドキュメント23章（10-29時点）
      • 5.2 フォーラム2スレッド：RuyiAIサミット回顧と香山如意生態大会の転載（10-29）
      • 5.3 ruyiai-daily1期、情報範囲はPyTorch、LLVM、Triton、RISC-Vをカバー（10-29）
      • 5.4 外部ニュースはゼロヒット、openRuyi 2026.10と0.54.0はいずれも未リリース（10-29時点）
    1. トレンド観察
      • 6.1 修正が検収に先行：3件の修正は移行過程で貯まった問題票に依拠し、回帰テストには依拠せず
      • 6.2 ブランチガバナンスの2つの流儀：llvmはルールを明文化しプレビューを取消、pytorchはブランチ全体の再適用に依拠
      • 6.3 ディストリビューションは月次で一括展開、スタック層の三点セットは月次で審査が停滞

今日の重点：triton-riscvで1日3件マージ、すべてFlagGemsオペレータ移行で露呈したデグレード欠陥に由来（10-29）

日付：2026-10-29　出所：PR #58、PR #83、PR #82、コミット一覧

15:38から16:58までの80分間に、triton-riscvのメインブランチへ3件が連続してマージされた。いずれも作成者はmaochuanjunで、変更箇所も同じレイヤー、すなわちTritonから構造化/非構造化IRへの降格パスである。これは時間的に異例だ。このリポジトリの依存更新以外のコードコミットは10-09の#86が最後で、その間の20日間はrenovateのナイトリービルドのアンカーのみだった。しかもこの3件自体、それぞれ82日、43日、44日を経てようやくマージされたものだ。

3件はそれぞれ具体的な欠陥に対処している。#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の回帰テストを1本追加した。#82（15:38、1ファイル、+23/−3）は散列テストの非決定性を修正する。元のテストはランダムなインデックスを使い、重複するターゲット位置を許容していたため、非還元散列ではどのソース値が勝っても合法だったにもかかわらず、単一のPyTorch CPU結果と厳密比較していた。修正方法は、1D、2D、およびin-place比較を一意なターゲットインデックスに変更し、さらに重複インデックスのケースを6つ追加した（512、1023、1024の3段階の長さで、in-placeと非in-placeを各1組）。勝った値が正しいターゲットのソース集合に由来すること、未ヒットのターゲットは元の値を保つことのみを検証する。

3件の動機はすべてPRの説明に書かれており、いずれも同じ一点を指している。FlagGemsオペレータの移行である。#83はunique_dimの実装に、#58はbroadcast_toに（このカーネルは以前、この誤コンパイルを回避するためrange(MAX_DIMS)をtl.static_rangeに置き換えていた）、#82は移行過程での散列オペレータの比較失敗に突き動かされたテスト修正に寄与する。つまり、この3件は回帰テストが見つけた欠陥ではなく、「一連のPyTorchオペレータをtriton-riscv上で動かす」という作業に迫られて露呈した欠陥なのである。

検証の強度は特筆に値する。#83はRuyiAIに関連するriscv64マシン上で検証したと明記されている。新しい回帰の3本のRUN/FileCheckはすべて通過し、全量litは291通過、9件の予期された失敗、0件の予期せぬ失敗、テンソル充填の実行時チェックは18項目通過（構造化とgatherの両パス、float32/float64/int64、空マスク/部分マスク/全マスク、負のゼロ、NaN、不正な未ヒットgatherオフセットをカバー）、更新後のunique_dimとの統合は23項目通過。#58は対象を絞ったTritonToStructured回帰のみを実行し、#82は当該テストファイルのみ（21通過）を実行した。3件の検証の深さは揃っておらず、最初の2件は局所的、3件目は単一ファイルに偏っている。

抑制すべきは因果順序である。修正が先に着地した一方で、これらの修正を必要とする移行PR #56は依然として09-16で止まったまま、オープンで未マージだ。これは、3件のマージ後、broadcast_toのtl.static_rangeによる回避を撤回でき、unique_dimを元の記法で提出できることを意味するが、「オペレータ群全体がriscv64上で動くかどうか」という問いには本期の答えは出ていない。#56の推進が再開されて初めて検証できる。

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

1.1 pytorch：riscvブランチは7日目に静かに終了、ブランチ全体のリプレイ後に上流3afdbd3へ引き上げ（10-29）

日付：2026-10-29　情報源：pytorch riscvブランチ、SyncBotsコミット5a29c201、PR #51、PR #44

七日連続のコミットゼロの後、riscv ブランチは 14:06 にブランチ全体のリプレイを実施した。ブランチ上の既存パッチコミット 11 件の committer 時間が同一秒（14:06:45）に統一して書き換えられ、作者時間は元のまま維持された——これは新しいベースラインへのリプレイの典型的な痕跡であり、新規開発ではない。リプレイは元のパッチセットを保持しており、「Add riscv64 image locally (#51)」「Fix bytes_to_scalar for float/complex on RISC-V (#44)」およびより早い CI とテスト許容差の変更を含む。

20:48 にさらに 1 件 [SyncBots] Integrate PyTorch at 3afdbd3 が追加され、cmake/Dependencies.cmake の 1 行のみを変更した。KINETO_SOURCE_DIR の cache 変数に FORCE を追加した。変更は小さいが意味は明確だ——ブランチのベースラインが上流の 3afdbd3 に引き上げられ、かつこのコミットは同期ボットが自動生成したもので、人手による判断は不要である。

同時に観測されたずれ：配布側の python-torch-ruyiai（openRuyi #1352）は 10-27 で止まっており、本期は動いていない。ブランチのヘッドはすでに新しいベースラインに切り替わっている。このパッケージがブランチの成果物に基づいてビルドされる場合、パッケージ内で固定されたソースの落とし所を一度再整合する必要があるが、この手順は現在どの PR も行っていない。オープン中の 7 件の PR（#23、#35、#36、#38、#43、#46、#48）の updated 時間はすべて 20:47:49 であり、ブランチプッシュによる一括リフレッシュに属し、内容が更新されたと見なすことはできない。そのうち RVV の 2 本のメインライン（#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 件のコミットは、committer 時間がすべて 23:00:40 から 23:00:44 の 4 秒以内に収まっている。リプレイ内容のうち 1 件は本当に新しいものだ——[workflows] Push rebased PRs directly and document contribution options（作者時間 10-29 09:59）は 2 つのファイルを変更した。autorebase.yml は 8 行を削除し（dry_run 入力と対応する予行ブランチを除去）、82 行の RISCV_CONTRIBUTING.md を新規追加した。

このガイドは「どう riscv ブランチに送るか」を 2 つの道として書き出している。道 1 はまず issue を開き、メンテナが現在の riscv から work/issue-NNN 作業ブランチを切る。コントリビュータは作業ブランチに PR を出し、メンテナが統合して riscv にマージする——複数人協力で安定した履歴が必要な作業項目に適する。道 2 は直接 riscv に PR を出し、ベースラインが変われば手動でリベースワークフローをトリガーする。ワークフローは PR ソースリポジトリで実行され、ソースリポジトリの GITHUB_TOKEN を使い、--force-with-lease で明確な期待 SHA を持ってソースブランチへプッシュバックし、コンフリクトは一律 riscv 側を取る（変更削除コンフリクトでは riscv 側の削除を保持することを含む）。等価パッチは自動スキップされ、riscv 自体を決して書き換えず、自動マージも決して行わない。

前回の 244 行のワークフローと比べ、最大の変化は予行が廃止されたことだ。前回はデフォルトで「予行のみでプッシュしない」だったが、今回は「成功即プッシュ、プレビューオプションなし」に変わり、ドキュメントにもこの一文が明記されている。これは摩擦を下げる一方でリスクを前倒しする——コントリビュータのローカルブランチは適時に同期しなければならず、さもなければ旧ベースラインの履歴が押し戻される可能性がある。ドキュメントには未コミット作業の保存と、旧ベースラインをリモートに押し戻すことの回避を促す段落が専用に設けられている。もう一つの記録すべき細部：ドキュメントは GITHUB_TOKEN でのプッシュは通常後続の push/PR ワークフローをトリガーしないと明言しているため、更新後の SHA 上で CI が実行されたかは人手で確認する必要がある。

1.3 triton-riscv：3 件の降級修正を 80 分以内にマージ、依存更新は依然オープン（10-29）

日付：2026-10-29　情報源：PR #58、PR #83、PR #82、PR #91、PR #56

3件の修正の技術的詳細は今号の「今日の重点」で展開済みのため、ここでは3点のステータスを補足する。第一に、3件のマージ後、メインブランチには調査期間内に新たなコードコミットはなく、git log の最新は#58のまま停止しており、これは継続的な開発ではなく集中的なクリーンアップであることを示している。第二に、renovateの#91は上流のbuddy-mlirナイトリー版をnightly/v0.1.3.dev20261027からdev20261029へ引き上げ（+2/−2、1ファイル）、10-29 16:58に#58をマージした後に一度リフレッシュされ、依然としてオープン・マージ可能状態でunstableとなっている。この依存更新こそが下流が#1015を入手する経路であり、詳細は4.2を参照。第三に、オープンPRのうち#55（asinオペレータのフロントエンドパッチ）は18:06にリフレッシュ、#56（FlagGemsオペレータ移行）は09-16で停止、#54、#57、#59、#72、#75、#85、#46はいずれも調査期間内の動きなし——特に#85「softmaxおよびmatmul最適化」は10-18以降更新がなく、これは性能の主線であり、今後注視する価値がある。

1.4 tilelang-riscv：メインブランチ14日間の静寂（10-29ステータス）

日付：2026-10-29（ステータス）　情報源：tilelang-riscv コミット一覧、オープンPR一覧

メインブランチの最後のコミットは依然として10-16 10:52の「Build Python extension in Buddy CI」であり、14日連続でコミットがない。オープンPRも依然として2件：#2は06-16で停止、#4「RVV vector mask and max reduction lowering」は09-28で停止し、いずれも調査期間内の更新はない。

これはtriton-riscvの今期3件のマージと直接対照をなす。同一組織、同一時期に、一方のブランチは劣化欠陥の集中的クリーンアップを行い、もう一方は全く動きがない。tilelang-riscvの現在唯一の下流での存在感は依然としてopenRuyiのpython-tilelang-ruyiaiスペック（#1350の4つのパッチ）に由来しており、すなわち「リポジトリのイテレーションの代わりにディストリビューション成果物を用いる」状態が第3週まで続いている。

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マージで、コミット時刻は10-29 15:05から10-30 00:20まで続き、規模は前号（27コミット）の約3倍に達した。理由は非常に集中している：KDE Frameworks 6.31.0の一括アップグレードで64個のkf6-*パッケージを展開したのだ。この一括は15:11の同一分に着地し（#1513）、kf6-kcoreaddons、kf6-kconfigからkf6-kio、kf6-ksvg、kf6-kwalletまで、基本的にPlasma 6が依存するフレームワーク全集をカバーしている。前号ではこの件はまだWIP、レビュー待ちキューにあったが、1日でマージに転じたことは、デスクトップスタックのバージョン追従がバッチ再ビルド能力を備えていることを示している。

残りはよくあるバージョン追従とパッケージング修正である：Gradio 6.31.0 とその依存（#1532、gradio-client 2.7.2、python-brotli 1.2.1 を含む）、python-pyvex 10.0.5（#1533）、python-graphql-core の手動 provides エポックバージョン修正（#1531）。ここに RuyiAI スタックの直接的なコンポーネントはないが、python 側の一連のメタデータ修正は、その後の triton/tilelang の wheel ビルド経路にとって同じ基盤であり、前回の scikit-build-core と cmake のメタデータも同種の作業である。

特筆すべきは時間分布である：64 個の KDE パッケージが 15:11 の 1 分間に集中し、残りの 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

新規パッケージが 1 件：vkpeak（#1349、16:38 マージ）。Vulkan のピーク性能とデバイス能力を検出するツールで、RISC-V ボード上のグラフィックスと演算能力の把握に有用であり、「ハードウェアはあるが計測ツールがない」という類の補完に属する。パッケージング基盤が 3 件：ecbuild の cmake モジュールを %{_libdir} にインストールするよう変更（#1536）、以前に非標準パスへ落ちていた問題を修正；clang-wrap を 20261029 へ追従（#1535）、上流と同日のパッケージングペースを維持；python-graphql-core の provides エポックバージョン修正（#1531）。

他に純粋な依存グラフ整理が 3 件：#1537 は重複した go-github-smartystreets-assertions パッケージを削除し、多択一の衝突を解消；#1538、#1539 は go-golang-x-text、go-github-hexops-gotextdiff、go-github-magefile-mage に欠落していた import path provides を補完。この種の問題はパッケージがインストールできなくなるわけではないが、依存解決時に dnf が誤ったバージョンを選ぶ原因となり、ディストリビューションの長期メンテナンスにおける隠れたコストである。

2.3 openRuyi レビュー中：#1350 初回コードレベルレビュー 18 件、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 の 3 点セット）は今回初めてコードレベルのレビューを受けた：misaka00251 が 16:19 から 16:24 に 5 件を連続投稿し、いずれも設計方針ではなく spec の書き方を指摘している——BuildOption(xxx) の間に空行を挿入する必要はない；python-triton-ruyiai に BuildRequires: python3dist(wheel) が欠落、Provides と実際のパッケージ名を一致させる必要がある；Conflicts: python-%{srcname} の必要性を説明する必要がある；パッチは git format-patch で生成すべきで、しかも同一ディレクトリに参照されていないパッチがもう 1 つある；空の %check には理由を説明するコメントを書く必要がある。PR の規模はこれに伴い 10 ファイル、+796/−0 に増え、レビューコメント総数は 18 件、ステータスは依然 unstable で未マージである。

このラウンドを前の幾つかのラウンドと併せて読むと、議論の重心が移動していることが分かる。10-27 以前は「buddy-mlir が持つ LLVM を外に出すべきか」(作者は 2.81 倍のビルド時間でパッケージ内に留めることを守った)であったが、今期は spec の機械的規範に移っている。こうした意見は通常「方向性は承認され、収束準備に入った」段階に現れるが、単なる定例の確認に過ぎない可能性も排除できない——マージされるかどうかは、次のラウンドで誰かが 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)から約 7 週間。4 件の変更：イメージ選択ステップにダウンロード動作を追加(#12)、CLI 出力をターミナル文字セットに合わせて JSON を UTF-8 に保つ(#14)、選択ダイアログをダブルクリックで確定(#19)、選択ダイアログは明示的な選択を必須化(#21)。4 件はいずれもユーザビリティの磨き込みであり、うち「ダブルクリック確定」と「明示的選択の必須化」は互いに補完する対のインタラクション制約で、前者は高速化、後者は誤選択の防止である。リリースノートには初回貢献者(qingwan12138)も記載されており、4 件のうち 3 件は同一人物によるものである。同日 15:40 には「Bump base version to 1.1.0」のコミットがあり、出荷前のバージョン位の準備である。

一方、パッケージマネージャ ruyi の 0.54.0 は依然 beta なし：タグ一覧では 0.54.0-alpha.20260918 の後に新しいタグはなく、正式版の最新は依然 09-24 の 0.53.0、メインブランチは 09-25 以降コミットがない。隔週進捗 079 期で示された方針は「リリースサイクル調整のため 10 月末に変更」であり、本調査期間はすでに 10 月の最後から 2 日目であるが、依然として候補版はない——6-30、7-23、8-27、9-24 の月次リズムに従えば、今期が「10 月末」という説明を実現できる最後の調査期間である。

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 メインリポジトリで最大のコミットである。方法はパッケージ内の ELF ABI sidecar をクエリプランとし、アーキテクチャ、ELF class、インタプリタ、共有ライブラリ、シンボルバージョン、未バージョン化シンボル、アーキテクチャ属性を比較し、結果を互換、非互換、判定不能の三態に分け、新たに ruyi admin check-abi サブコマンドを追加する；ライブラリ解決は意図的に候補ライブラリをロードせず、Ruyi プロセスの LD_LIBRARY_PATH にも依存しない。これは「プリコンパイル済み RISC-V パッケージがこのマシンにインストールできるか」を試行錯誤から説明可能なチェックへと変える——バイナリ配布を主とする RuyiSDK エコシステムにとって、この経路の価値は個々のパッケージのバージョン更新よりも高い。現在も未マージである。

3. ベクトル拡張、アーキテクチャテストとオペレータ最適化

3.1 ベクトル四リポジトリは引き続き静か、ベンチマーク側の欠落は依然(10-29 状態)

日付：2026-10-29（状態）　情報源：VecIntrinBench、IntrinTrans、FBGEMM、cpuinfo

ベクトル関連の4リポジトリは調査期間内すべてコミットゼロ、静穏期間に変化なし：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 の3件の修正はいずれも「lit 通過数 + 実行時ケース通過数」で検証されており、ベクトル化品質の比較可能な数値（命令数、占有 LMUL、レジスタスピル回数）を出したものは一箇所もない。前回 #1014 ではすでに「同一コードの2回ビルドで2%の差」というノイズが現れており、ボード上のスループットで結論を出すのはもともと厳しい；VecIntrinBench 側が引き続き動かなければ、今後の「最適化が本当に向上したか」は長期にわたり人手による突き合わせに頼るしかなくなる。これは今期新たに生じた問題ではないが、3件のマージがそれをより鮮明に照らし出した。

3.2 FlagGems 移行が triton-riscv の欠陥発見メカニズムになった（10-29）

日付：2026-10-29　情報源：PR #83、PR #58、PR #82、PR #56 FlagGems 移行

3件の修正の動機を広げて見ると、それらの共通の来源はテストスイートではなく、「PyTorch オペレータをバッチごとに triton-riscv へ移植する」という行為そのものであることがわかる：unique_dim で真のテンソル填充値を伴う tl.load、broadcast_to のループキャリー偏移、散列オペレータの重複インデックス比較——いずれも RISC-V 命令レベルにはなく、降級層と検証層の境界に位置している。こうした欠陥は単体テストでは自然に生まれにくい——実際のオペレータライブラリがあり、バッチ方式で上に押し付けて初めて露見する。

このことの方法論的価値は3件の修正そのものより高い：Triton を入口とする RISC-V AI スタックにとって、FlagGems 移行は実質的に「エンドツーエンド検収セット」の役割を果たしており、コンパイラの lit スイートよりも実負荷に近い。逆に言えば、今期はこのメカニズムの単一点依存も露呈した——移行 PR #56 は 09-16 以降更新されておらず、3件の修正のマージ後にかえって検収フローが止まってしまった。#56 が長期にわたり進まなければ、この「欠陥発見メカニズム」も連鎖的に失效し、次の欠陥のバッチは他の利用者がぶつかるまで発見されないことになる。

3.3 arXiv は調査期間内に新規なし、10-27 の2本が最新（10-29 状態）

日付：2026-10-29（状態）　情報源：arXiv 検索

RISC-V にコンパイラ、ベクトル、MLIR を条件とした検索で、調査期間内に新規論文はなし。検索でヒットした最新の2本はいずれも 10-27：SecDMP: Provably Secure Data Memory-Dependent Prefetching（データアクセス関連プリフェッチの証明可能な安全方案）と A lightweight C Code Generator for Heterogeneous TinyML Systems（異種 TinyML 向け軽量 C コード生成器）。前者はマイクロアーキテクチャ側の安全プリフェッチに関係し、後者は端側コード生成に属し、いずれも 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 buddy-server に新 ABI がマージ：56 ファイル、モデルプラグイン体系を統一インターフェースに変更（10-29）

日付：2026-10-29　情報源：PR #1015、コミット 7d2ce844、RAX パッケージングとローディング分析ドキュメント

15:08、#1015「Buddy-server new ABI」がマージされた。56 ファイル、+3934/−1661 で、本期のスタック全体で最も変更範囲が大きい一笔である。PR 説明の意図はわずか一文で、buddy-server が RAX ファイルを解析する際に用いる ABI インターフェースを更新し、新インターフェースが将来より多くのモデルをサポートするための便宜を提供するというものだが、実際の変更はそれよりはるかに大きい。

構造上は「モダリティごとにプラグインハンドルを一式ずつ書く」を「一つの統一インターフェース」に置き換えるものである。新たに四つのランタイムヘッダファイルを追加した：ServerModelABI.h（392 行）、ServerModelABIConversion.h（179 行）、ServerModelPluginAdapters.h（742 行）、ModelError.h（57 行）。同時に元々モダリティごとに分割していた AudioTranscriptionModelPluginHandle、EmbeddingModelPluginHandle、MaskedLMModelPluginHandle、ResidentModelPluginHandle の四組の実装と ModelPluginDiscovery を削除し、350 行の ServerModelPluginHandle と 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 のパッケージングを待ち、その後 triton-riscv の renovate がアンカーを一度上げる必要がある（#91 は現在 dev20261029 にアンカーしており、まだオープンである）。

このタイムラグは個別に記録する価値がある。なぜなら、これはこのスタックの固定遅延構造だからだ：buddy-mlir マージ → 翌日夜間ビルド → renovate が依存更新を提出 → triton-riscv マージ。三つのホップを合計すると通常は一～二日。0.1.3 ラインは既に五つの夜間版が正式版なしで連続しており、最近の正式版は依然として 10-25 の 0.1.2 だ；#1015 のような規模のインターフェース変更が正式バージョンで出すとなると、さらにもう一巡待つ必要がある。

4.3 審査中三件は 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 の立場はやや微妙だ：前号の #1012 の x64 CI グリーンはそれの上で得られたものであり、それが今もなおマージされていない；さらに #1015 が既に buddy-server のプラグインインターフェースを変更しており、#994 の「llama-server への整合」というインターフェース方針が新 ABI と衝突するかどうかは、PR 内で議論されていない。オープンリストには他に #993（tile.upsample_nearest 認識）、#1001 と #997（K3 A100 上の Qwen3-0.6B と DeepSeek-R1-Distill-Qwen-1.5B の prefill/decode 最適化）、#995（非末軸 Cumsum 連続走査）、#992（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 章。既に複数の調査期間にわたり新規ブログ記事と章の追加はない。

エンジニアリング側との落差は引き続き存在する。今号では技術ブログに書ける素材が少なくない：三件の降級修正の背後にある「非均一意味論」の問題、buddy-server 統一 ABI のリファクタリング方針、ruyi-imager 1.1 のインタラクション改造——いずれも PR 記述とリポジトリドキュメントに留まっている。このスタックを対外的に示す入口は依然として 9 月の二本の記事だけで、これは「毎日コミットがあり、毎週マージがある」というリズムと一致していない。

5.2 フォーラム二スレッド：RuyiAI サミット回顧と香山如意生態大会の転載（10-29）

日付：2026-10-29　情報源：RuyiAI サミット回顧 #2899、香山如意生態大会転載 #2898、RuyiSDK 開発者コミュニティ

フォーラムの今号二スレッドは、いずれも 10-29 に投稿された。RuyiAI カテゴリの #2899「RuyiAI が第六回 RISC-V 中国サミットに登場、RVV から Matrix までの AI システムソフトウェアスタック実践を共有」は 10-18 から 10-20 の深圳サミットを振り返る：チームは Tutorial 専門セッションでの共有、ポスター展示とブース交流を通じてスタックのアーキテクチャと参加方法を紹介し、同時期の AME 技術検討会と 10-21 の RISC-V 香港日にも参加、テーマは行列拡張とソフトウェア支援を中心とした。スレッド本文は非常に薄く、実質的な内容は外部リンクで公式アカウント記事に誘導されている。

ニュースゴシップカテゴリの #2898 はあるサミット報道を転載している：10-20 の香山如意オープンソース生態フォーラム午後の部は「エージェント時代に向けて」の RISC-V ソフトウェア・ハードウェアフルスタック成果を集中的に発表し、サーバー級チップ、AI ネイティブソフトウェアスタック、プロセッサマルチスレッドアーキテクチャ、AI-CPU アジャイル開発キット、メモリ一貫性最適化と EDA 検証ツール適配をカバーした。RuyiAI にとって、これが示すのはエコシステム上の位置づけである——「AI ネイティブソフトウェアスタック」は同じフォーラムで並置発表された成果の一つであり、サーバーチップ、マルチスレッドアーキテクチャと同じ一批の語りに属する。

5.3 ruyiai-daily 第1号、情報範囲は PyTorch、LLVM、Triton、RISC-V をカバー（10-29）

日付：2026-10-29　情報源：ruyiai-daily コミット一覧、daily-news 2026-10-29

ruyiai-daily は 10-29 06:42（北京時間）に第1号 daily-news-2026-10-29.md をコミットし、日次アーカイブを継続した。本号の範囲は PyTorch エコシステム、LLVM/MLIR、Triton と TileLang、RISC-V ソフトウェアスタックと製品、AI モデルと産業の五方向をカバーし、そのうち本リポジトリに直接関連する三項目：PyTorch 2.15 リリース（NCCL をデフォルトに書き換え、MPS を FP8 に拡張）、Buddy の K3 VIR デコードアテンション（すなわち 10-28 の #1014）、および 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、如意コミュニティの中英語定向クエリ（when:3d）は期間内にいずれもゼロヒット。RISC-V 主題の候補リストにも如意コミュニティ関連の項目はなく、本号は外部ニュースを収録しない。

ディストリビューション側の二つのバージョンは依然として期間外にある。openRuyi ニュースページの最新記事は依然として 2026.09 リリース告知であり、リポジトリのタグは 2026.09-experimental で止まり、2026.10 は未リリース。ruyi の 0.54.0 は 09-18 の alpha タグのみ。前数月の月末リズムに従えば、今後二三日が 2026.10 と 0.54.0 のリリース期間であり、次号はこの二点を注視する必要がある。

6. トレンド観察

6.1 修正が受け入れ検証より先行：三件の修正は移行過程で溜まった問題票に依存し、回帰テストには依存しない

本号でマージされた三件は順序問題を露呈した：まず修正があり、その後に受け入れ検証がある。unique_dim のテンソル充填、broadcast_to のループオフセット、ハッシュオペレータの重複インデックス、この三箇所の欠陥はいずれもコンパイラ自身のテストで発見されたのではなく、FlagGems オペレータを上へ移行する際に衝突して出てきたものである；修正はマージされたが、それらを必要とする移行 PR #56 は 09-16 で止まったまま動いていない。結果として、「ある用法のために用意された修正」の一群に対応する用法が一時的に走っていない状態である。

この状態のリスクは現在ではなく来月にある：もし #56 が再開されたとき Triton 上流がさらに数回変わっていれば、三件の修正が新しいベースラインとまだ互換性があるか、もう一度検証する必要がある；そして #56 がずっと再開されなければ、この「エンドツーエンド検証セット」は停止状態に等しく、次の一群の欠陥は外部利用者が衝突するまで待つことになる。「実モデルを動かせる」ことを目標とするスタックにとって、移行を常駐回帰にする（たとえ数十のオペレータだけで、毎晩一回走らせるとしても）方が、さらにもう数件修正をマージするより価値がある。

6.2 ブランチガバナンスの二つの書き方：llvm はルールを書き予演を取消し、pytorch は全枝リプレイに依存

同じ日のうちに、二つのブランチが二つのガバナンスの答えを示した。llvm の riscv ブランチは全枝をリプレイし直し、本当に新規追加されたのは貢献ガイドである：「riscv へコードを送る」を「メンテナの作業ブランチへ PR を提出する」と「直接 riscv へ PR を提出し手動でリベースをトリガーする」の二つの道に分解し、同時にワークフローの予演スイッチを削除した——成功即プッシュ、プレビューなし。pytorch の riscv ブランチは上流 3afdbd3 へリプレイしただけで、さらに同期ボットに依存キャッシュ修正を一筆補わせ、プロセス文書は一切ない。

両者のコスト構造は異なる。llvm ブランチはパッチセットが大きく外部貢献が多く、衝突と履歴ドリフトが主要コストであるため、ルール化は文書を書く価値があり、ワークフローを配置する価値がある；pytorch ブランチはパッチセットが小さく（11 筆）、メンテナ自身が一度リプレイするコストはプロセスを維持するコストより低い。予演を取消した点は観察が必要である：摩擦を下げると同時に「誤った履歴をプッシュする」リスクを貢献者へ前倒しし、--force-with-lease と状態再検査で受け止めるが、実際の効果は次の一、二件の外部 PR を見る必要がある。

6.3 ディストリビューションは月次で量を敷き、スタック級三件セットは月次で審査が滞る

openRuyi 本期 76 コミット、10 件マージ、うち 64 件は KDE フレームワークの一括アップグレードである。ruyi-imager は 1.0.0 から 1.1.0-rc.1 まで七週間かかっており、ペースは正常である。一方、「配布」に属するもう一方の側では、RuyiAI 三件セットのパッケージング PR #1350 が 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 を上流 3afdbd3 へ引き上げ、メインブランチ 20 件はすべて上流；llvm-project：riscv ブランチ 25 件リプレイ、コントリビューションガイドを新規追加（faf4def312、+82/−8）、メインブランチ 20 件は上流；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 マージ；オープン PR 15 件に更新あり（#1350 初回コードレベルレビュー 18 件、#1514 ollama セキュリティ更新を含む）；タグは 2026.09-experimental 止まり、2026.10 は未リリース
buddy-compiler 組織 buddy-mlir 1 件マージ（#1015 新 ABI、56 ファイル +3934/−1661）＋ ナイトリー版 v0.1.3.dev20261029；オープン PR 3 件は 10-28 で停止（#1011、#1013、#994）、他に #992、#993、#995、#997、#1001、#924、#928、#932、#838 は調査期間内の更新なし；buddy-benchmark、buddy-examples、compiler-eval、FeGen、gemmini、firesim は調査期間内のコミットなし
RuyiSDK 開発者コミュニティフォーラム 調査期間内に 2 スレッド：#2899「RuyiAI が第六回 RISC-V 中国サミットに登場」（10-29、RuyiAI カテゴリ）、#2898「香山如意エコシステム大会：エージェント時代に向けた 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 にリリース（プレリリース）、4 件のインタラクションおよび CLI 変更を含む
公式サイト（ruyiai.org） 3 ページに変化なし：トップページインデックス 3 件、ブログ 2 篇、ドキュメント 23 章、sha256 は前号と一致
arXiv（RISC-V） 調査期間内の新規なし；最新は 10-27 の SecDMP と TinyML C コード生成器、10-21 の長ベクトル FlashAttention が依然 RVV に最も適合
Google News RSS（中英文複数組） RuyiSDK、RuyiAI、openRuyi、如意コミュニティの定向クエリはゼロヒット；RISC-V トピック候補のうち Qwenputer、Ruyi 無関係エントリは未収録

完全な情報源リスト