調査期間：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 / 玄鉄などのキーワードでフィルタリング）、openRuyi のコミットと PR マージ統計、ruyi パッケージマネージャー Release、RuyiSDK 開発者コミュニティフォーラム、ruyiai-daily デイリー情報アーカイブ、RuyiAI 公式ホームページ3ページのスナップショット、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 ブランチは7日目沈黙、メインブランチの20コミットは依然上流（10-28 状態）
      • 1.3 triton-riscv：アンカーをさらに一段引き上げ、riscv64 の3本の CI がキューで未応答（10-28）
      • 1.4 tilelang-riscv：メインブランチ13日目沈黙（10-28 状態）
    1. RuyiSDK ツールチェーンとディストリビューション
      • 2.1 openRuyi PR #1350：3コミットをリベース、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 の3リポジトリは沈黙、cpuinfo は05-20で停止（10-28 状態）
      • 3.2 ベクトル幅の基準：VIR 側は1024ビット、単一ヘッドに LMUL 4 の1グループ（10-28）
      • 3.3 arXiv に期間内の新規なし、10-21 の長ベクトル FlashAttention が依然 RVV に最も適合（10-28 状態）
    1. Buddy Compiler の動向
      • 4.1 K3 デコードアテンションを VIR に移行：数値はビットレベルで一致、K3 実測スループットは同一区間に収まる（10-28）
      • 4.2 buddy-server のソース再編、Whisper サンプルが x64 CI に参加（10-28）
      • 4.3 レビュー待ち4件：int64 強制変換、Whisper 前処理の再利用、新 ABI、llama-server とのアライメント（10-28 状態）
      • 4.4 ナイトリー版 dev20261028 がビルド、当日の3コミットは依然含まず（10-28）
    1. コミュニティとイベントと公式ホームページ
      • 5.1 公式ホームページ3ページに変化なし、ブログ2本、ドキュメント23章（10-28 状態）
      • 5.2 フォーラムに期間内の新規投稿なし；10-27 の LPi4A UEFI 実測帖を追加収録（10-27）
      • 5.3 ruyiai-daily 1号、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 の #1014「K3: write the decode attention in the VIR dialect」がマージされ（4 ファイル、+476/−14）、K3 w4g32 カーネルのデコードアテンションを丸ごと VIR 方言へ移した。これは単なる方言機能の補完ではなく、実モデルのカーネルを使って初めて突き合わせを行ったものだ。一方はこれまで手書きしてきた RVV ベクトルカーネル、もう一方は Python で組み上げた VIR カーネルであり、数値、命令数、ボード上のスループットを比較する。

手法は四つの層に分解できる。構築層ではもはやオペレータや型を手作業で組み上げず（従来は文字列にオペレータ名と型記述を書く必要があった）、buddy_mlir.dialects.vir の SetVLOp、load、shuffle、fma、reduce を使う。一つの work item は一つの vir.set_vl 領域であり、長さはヘッド次元の半分（64 レーン）を取る。各ヘッドは RoPE の二つの半分から組み上げたスケーラブルベクトルであり、領域はそのヘッドの (max, sum) を返す。回転層では q を領域内でロードし、回転し、スケーリングする。rotate_half は一つの vir.shuffle に落とし込み、cos/sin は等長の二行データとして保存するので、vir.from_vector は不要になる。メモリビュー層では memref.expand_shape を使い、q、KV cache、出力、および q の正規化重みを最終次元で 2×64 に分割する。正規化層（Qwen3 の q/k norm）は別途一次元の 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% に達し、区間は重なっている、と。

同日、この主線に付随するもう二件がある。一つは llvm-project の riscv ブランチに 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 で、2 つの入力——PR 番号（必須）と「プレビューのみでプッシュしない」（デフォルトで有効）——を取る。実行環境は ubuntu-24.04、タイムアウトは 90 分。コメントには「書き込み権限を保持した状態で PR コード、フック、ビルド、またはサブモジュールを絶対に実行しない」ことが明記されており、git 設定では hooksPath、attributesFile、fsmonitor をすべて /dev/null に指定し、GIT_TERMINAL_PROMPT=0、GIT_EDITOR=true としている。競合処理には専用の関数がある。-Xours で処理できないシナリオ（変更・削除の競合を含む）は 1 件ずつ ls-files --unmerged を辿り、第 2 ステージがあればローカルを採用し、なければ削除する。リベース時にはまずベースラインが既に祖先であるかどうかを判断し、「等価なパッチ」を識別して重複する古いベースラインパッチを破棄する。

この項目が解決しようとするのは、過去数期に繰り返し現れた具体的なコストである。ブランチは 1 日に一度全体をリプレイし、作成者の fork 上の PR は即座に遅れ、手作業で 1 件ずつリプレイするのは遅い上にパッチセットを乱しやすい。境界を明確にしておく必要がある。それがリベースするのは他者の PR であり、ブランチ自身の毎日の全体リプレイは依然としてメンテナーの操作が必要である。「ベースラインに追随する」コストを人手の判断からプレビュー付きの 1 回のスケジューリングへと引き下げるが、自動化されたトリガー条件は持たない。真の価値は、次の外部 PR が新しいベースラインで提出されたときに初めて検証できる。

1.2 pytorch：riscv ブランチは 7 日目も静穏、メインブランチの 20 件は依然上流（10-28 状態）

日付：2026-10-28（状態）　情報源：pytorch riscv ブランチ、pytorch メインブランチ

riscv ブランチのヘッドは依然として 10-22 03:00（北京時間）の「Add riscv64 image locally (#51)」であり、10-22 から 10-28 まで連続 7 日目のゼロコミットである。RVV 能力を上流に載せる 2 本のメインプロポーザル（#46 ATen 向けベクトル拡張サポート、#48 の RISC-V Vector CPU 能力）は今期も更新がない。

メインブランチは同期間で 20 件、すべて上流同期であり、RISC-V に関わるものは 1 件もない。CUDA 側で max_pool3d のスライス内 64 ビットインデックスを修正、オンライン softmax のマージを正確な指数に切り替え、symbolic shapes の非推奨 API クリーンアップをロールバック、inductor-benchmarks のイメージを pytest 9.1.1 に固定、ATen ネイティブオペレータに c10::irange を一括適用、ROCm の rocSOLVER バッチ syevd ワークスペースをキャッシュアロケータから取得するよう変更、などである。このブランチのリズムは前回の結論と一致している。上流の追跡は日次更新、RISC-V のリプレイは手動で時期を選んで行う。

併せて読む価値があるのは配布側である。openRuyi の #1352 は依然としてこのブランチの成果物を python-torch-ruyiai パッケージに固めており（今期は未更新、10-27 で停止）、ブランチが動かずパッケージが待っている。これが現在の pytorch 一線で最も注視すべきずれである。パッケージがマージされる時点でブランチが上流ベースラインに遅れていないか、現時点では答えがない。

1.3 triton-riscv：アンカーがさらに一段上がり、riscv64 の 3 本の CI がキューで未応答（10-28）

日付：2026-10-28　情報源：triton-riscv PR #91、PR #90、buddy-mlir ナイトリー版リスト

18:51、renovate ボットが #91 を開き、上流 buddy-mlir のナイトリー版を nightly/v0.1.3.dev20261027 から nightly/v0.1.3.dev20261028 へ引き上げた。変更は依然 2 行（+2/−2）である。前回との違いは、これが自動マージされていない点にある。調査期間終了時点でこの PR は依然オープン状態であり、マージ可能状態は unstable である。

8 項目のチェックのうち 6 項目が応答済みである。x64 の 3.12、3.13、3.14 の 3 段階はすべて成功、pre-commit と clang-format も成功。riscv64 の 3.12 は 18:54 から実行中、3.13、3.14 は開かれてからずっとキュー待ちである。同一リポジトリの前回（#90）は開かれてから数分以内に自動マージされたが、今期はその差が riscv64 側の実行キューに現れている。これはインフラのリズムに属するものであり、依存自体に問題があるわけではない。

さらに時間の勘定を明確にしておく必要がある。dev20261028 というナイトリー版のビルドバケットは当日午前の 3 件のマージ（#1010 08:54、#1014 09:36、#1012 09:55）より前であるため、この版には K3 デコードアテンションが含まれない。下流が #1014 の成果を得るには、次のナイトリービルド＋さらにもう 1 件の依存更新を待つ必要があり、最速でも 1 ビルドサイクルかかる。

1.4 tilelang-riscv：メインブランチ13日間静黙（10-28 状態）

日付：2026-10-28（状態）　情報源：tilelang-riscv コミット一覧、オープン PR 一覧、openRuyi PR #1350

メインブランチの最後のコミットは依然として 10-16 10:52 であり、13日連続でコミットがない。オープン PR #4 も 09-28 から更新が止まっている。リポジトリ側の静黙は triton-riscv 側と対照をなしている。後者は少なくとも依存関係を追従しているが、前者は依存関係の更新すら動きがない。

唯一の進展は依然として配布側にある。#1350 の python-tilelang-ruyiai 仕様は今期、PR 全体のリベースに伴って更新され（詳細は 2.1 を参照）、依然として4つのパッチである：Apache TVM FFI 0.1.10 の緩和、システムビルド依存への切り替え、buddy-mlir ツールチェーンの検出、z3 soname 書き換えのスキップ。リポジトリは停滞し、パッケージは進行中という、この「リポジトリのイテレーションの代わりにディストリビューション成果物で代替する」状態はすでに2週間近く続いている。

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

2.1 openRuyi PR #1350：3コミットをリベース、GCC ビルドコストを2.81倍と定量化（10-28）

日付：2026-10-28　情報源：openRuyi PR #1350、レビューコメント、PR コミット一覧

16:22、RuyiAI 三点セットパッケージング PR の3つのコミット（buddy-mlir、python-triton-ruyiai、python-tilelang-ruyiai）が同一分内にすべて書き換えられ、明らかに最新メインブランチへのリベースである。現在の規模は9ファイル、+680/−0 で、前期の記録と比較して14行増えている。PR は 18:15 にレビューコメントにより再び更新され、コメント総数は13件で、依然としてマージされていない。

今期最も情報量の多いものは、作者の 10:41 の返信である。前期の見解は「GCC で代替可能だが、ビルド時間は少なくとも1.5倍」であったが、今期は実測値が示された：riscv64 マシン上で buddy-mlir のビルドを LLVM から GCC に変更すると、時間は 8814 秒から 24798 秒（約2時間27分対6時間53分）になり、2.81倍であり、しかもその GCC を使用したビルドはリンク段階で失敗し、完走しなかった。

この点は議論を立場の問題からコストの問題へと変えた。「buddy-mlir が内蔵する LLVM を外置きするかどうか」はもともと2つの技術路線の争いであったが、今ではディストリビューションのビルドファームが理解できる数字が出た：2.81倍はスケジューリング、マシン占有、タイムアウト戦略のすべてを再計算する必要があることを意味する。作者のもう一つの理由もこれによってより説得力を持つ——buddy-mlir が使用する LLVM は自身のパッケージ内でのみ使用され、かつこれらのパッケージは特定の LLVM コミットに固定されているため、パッケージ内に留めることで再現性が確保される。同時に彼は、triton 上流の setup.py には git が実行可能かどうかの強制チェックがあるため、git ビルド依存を追加するか、setup.py にパッチを当てるか（後者は triton のアップグレードで無効になる）のいずれかが必要であるとも説明した。

2.2 openRuyi：27コミット、15 PR マージ、qemu 11.1.2 と libvirt バックポートが着地（10-28）

日付：2026-10-28　情報源：openRuyi コミット一覧、PR #1520 qemu、PR #1519 libvirt、PR #1521 python パッケージ、PR #1522 ツールチェーンマクロ

本期メインリポジトリは27コミット、15件のPRマージ、参加者9名：misaka00251が8件、Ruoqing Heが4件、Sun Yuechiが4件、Jingiwが3件、Zheng Junjieが3件、Kimmyが2件、cl2t、Julian Zhu、YunQiang Suが各1件。すべてのコミットは11:20から20:49の間に集中し、その後ウィンドウ終了まで新規コミットはない。規模は前期（45件）から明らかに縮小し、性質も「リリース前の掃除」から通常の追随へと転換した。

仮想化関連は本期で最も完結した一群である。qemuは11.1.xから11.1.2へアップグレード（#1520、13:28マージ）、前期はまだ「審査待ちキュー」にあったが、1日で着地した。libvirtは2件マージ（#1519、09:47）：一つはパッケージと共に/var/lib/libvirt/secretsを配布し、virt-secret-init-encryptionが必要とするディレクトリを存在させ、virtsecretdが起動できるようにするもの；もう一つはCeph 21がauth_supportedを削除したことでrbdプールが無効になった問題の修正をバックポートするもの。この2件はいずれも「インストールはできるが動作しない」類の問題へのパッチであり、ディストリビューション品質の重要な指標に属する。

パッケージング基盤側にも内容がある。%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のメタデータの2件はRuyiAIスタックに直接的な意義を持つ——tritonやtilelangといったCMake拡張のwheelビルドはまさにこの経路を通る。

その他のマージ：attrを2.6.0へ、goのインデックス最適化をバックポート、python-backports-zstdを削除、go系パッケージがgcfg v2の改名に追随して依存を修正、python-graphql-coreを3.2.13へダウングレード、procpsのrpm名を修正しuptimeを復元、krb5の一連のビルドオプションとsystemdサービス、cephが上流スナップショットに追随、sql-migrateを新規追加、rustvmmの4つの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

ウィンドウ内に更新のあったオープンPRは計9件。KDE Frameworks 6.31.0のWIP更新は00:04にリフレッシュされ（#1513）、依然WIPマーク。クロスriscv64ツールチェーン（#1490、Z572）は14:18にリフレッシュされ、依然WIP——本期マージされたツールチェーンメジャーバージョンマクロと一対をなす：マクロが切り替えの入口を提供し、PRが具体的なツールチェーンを提供し、両方が揃って初めてクロスコンパイルが可能となる。Gradio 6.31.0とその依存の整合（#1532）、python-pyvexを10.0.5へアップグレード（#1533）、graphql-coreの手動providesエポックバージョン修正（#1531）の3件が20:03から21:27の間に集中的にリフレッシュされた。qemu-rustsbi（#1516）には2件の議論があり、Rustで書かれたSBIを仮想化スタックに導入するための事前作業に属する。残りはvkpeak（#1349）とPrometheus v3.13モジュール（#1441）。

2.4 ruyisdk：0.54.0は依然未リリース、パッケージリストとサポートマトリクスは静穏、インストーラはUI用語を変更（10-28状態）

日付：2026-10-28（状態）　情報源：ruyi Releases、packages-index、support-matrix、ruyi-imager コミット a87b8dd9

パッケージマネージャ ruyi のメインブランチは 09-25 以降コミットがなく、リリースの最新は依然として 09-24 の 0.53.0 で、0.54.0 は 09-18 の alpha タグのみである。隔週進捗 079 期の説明は「0.54.0 はリリースサイクル調整により 10 月末に変更」というものだが、月末まで残り二日しかなく、今期も beta やリリース候補版は存在しないため、実現可能な期間はすでにかなり狭まっている。

packages-index は調査期間内にコミットがなく（最新は 10-26 の revyos Milk-V Meles イメージのバージョン引き上げで停止）、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 はコミット記録なし。

これは今期のベクトル側の進展がすべて別の場所で起きていることを意味する——表現層は buddy-mlir の VIR 上に、ツールチェーン層は llvm の riscv ブランチ上にあり、専用のベクトル組み込みテストとオペレータ最適化リポジトリにあるのではない。「ベクトル能力の向上」を目標とするスタックにとって、テストベンチマーク側が長期間動かないことは潜在的なリスクである：VIR は現在スケーラブルベクトルを表現できるが、継続的にスコアを計測するベクトル組み込みベンチマークが欠けていると、後続の最適化が本当の改善なのか変動なのかを判断するのが難しくなる（#1014 ではすでに「同じコードの二回のビルドで 2% の差」という状況が出現しており、まさに安定したベンチマークによる判断が必要とされている）。

3.2 ベクトル幅の基準：VIR 側は 1024 ビット、単一ヘッドに一つの LMUL 4 グループ（10-28）

日付：2026-10-28　情報源：buddy-mlir PR #1014、llvm riscv ブランチコミット 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 ウィンドウ内に新規なし、10-21 の長ベクトル FlashAttention が依然として RVV に最も適合（10-28 状態）

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

RISC-V にコンパイラ、ベクトル、MLIR を条件として付加した検索では、ウィンドウ内に新論文はなかった。最新は依然として 10-23 のオープン ISA スーパーコンピュータアーキテクチャ比較と、10-22 のバイナリを規範コンパイラ IR へ引き上げるマルチエージェントフレームワークである。今期の主線に最も近いのは依然として 10-21 の「Reorienting the Vector Axis: Restructuring FlashAttention for Long-Vector Processors」——長ベクトルプロセッサ上の FlashAttention 再構築であり、#1014 がデコードアテンションを 64 lanes で分割し、単一ヘッドを 1 つの LMUL 4 グループとする手法と同種の問題に属するが、残念ながらウィンドウ内に後続はなかった。

4. Buddy Compiler ダイナミクス

4.1 K3 デコードアテンションを VIR へ移植：数値はビットレベルで一致、K3 実測スループットは同一区間に収まる（10-28）

日付：2026-10-28　情報源：buddy-mlir PR #1014、K3 ドキュメント変更、テストファイル

前号では #1009 の Python バインディングを「buddy-opt 専用からプログラマブル方言へ」と記録したが、今号はこのバインディング群で書かれた最初の実物を示した：#1014 がマージされ（09:36）、4 ファイル、+476/−14、うちカーネル実装は 264 行追加、テスト 152 行、降級パイプライン 10 行、K3 ドキュメント 50 行である。

技術要点は「今日の重点」で展開済みのため、ここでは再確認可能な細部を 3 点だけ補足する。第一に、PR はこれがクローズ済みの #998 をやり直すものであると明言しており、やり直しの基礎はその後の 4 コミット：アクティビティによるサイズ決定（#1000）、行（#1005）、vir.shuffle（#1006）、Python バインディング（#1009）——つまり、これは独立した最適化ではなく、前 4 コミットの土台を一括で負荷試験するものだ。第二に、検証はかなり硬派である：テストは _attn_decode_fn に対してビットレベル比較を行い、スレッド有り/無し、起点 0/15/16/37/70 をカバーし、q/k 正規化有りでは 0/37 をカバーする；test_k3_w4_moe.py の qk_norm パスも VIR カーネルを実行する；check-buddy 239 + 401 はすべて通過した。第三に、マシンコードレベルでは 2 つの並列体がそれぞれ 178 条のベクトル命令を持ち、キーバリューループは旧版と完全に一致し、溢れレジスタの再ロード位置が 2 箇所だけ変化し、q の回転は 2 つの LMUL 2 半グループ上の演算から vfneg と 1 回のレジスタ移動になった。

慎重であるべき点：今回の「性能同等」は K3 単板、貪欲デコード、3 つの系列長で得られたものであり、著者も同じコードが 2 回のビルドで 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、プロトコル、プラグインの 3 ブロックにグループ化し、テストをユニット、統合、パッケージング、フィクスチャのディレクトリに分けた；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 審査中 4 件：int64 強制変換、Whisper 前処理の再利用、新 ABI、llama-server へのアラインメント（10-28 状態）

日付：2026-10-28（状態）　情報源：PR #1011、PR #1013、PR #1015、PR #994

オープン PR 4 件が調査期間内に更新された。#1011 はコンパイル修正である。リポジトリが固定している Clang/LLVM バージョンでは divideCeil が符号なし値を返し、集約初期化でそれを int64 のフィールドに入れるとナローイングエラーになるため、明示的に変換する形に改めた。除算、ベクトル幅、マスク、レイアウトはいずれも変更していない（+4/−4、1 ファイル）——この小さな修正が #1012 を通過させる前提である。#1013 は 16:01 に更新され、Whisper の前処理結果を再利用して重複計算を削減する。#1015 は 22:53 に更新され、buddy-server に新 ABI を導入する。#994 は 15:35 に更新され、buddy-server のインターフェースを llama-server にアラインメントするもので、このアラインメント方針を最初に提起した一件であり、今もなお未マージである。

4.4 夜間版 dev20261028 がリリース、当日の 3 件は依然含まず（10-28）

日付：2026-10-28　情報源：夜間版 dev20261028、Releases リスト

夜間版は 07:56 にリリースされた（v0.1.3.dev20261028）。リリース時刻は当日午前の 3 件のマージ（#1010 08:54、#1014 09:36、#1012 09:55）より早いため、この版には K3 デコードアテンションも、buddy-server の再構成も、Whisper CI も含まれていない。0.1.3 ラインは 4 つの夜間版連続で正式版がない（直近の正式版は 10-25 の 0.1.2）。次の夜間ビルドが #1014 の下流への最初の到達点となる。

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

5.1 公式サイトは 3 ページとも変化なし、ブログ 2 本、ドキュメント 23 章（10-28 状態）

日付：2026-10-28（状態）　情報源：RuyiAI 公式サイト、ブログ、ドキュメント

トップページ、ブログ、ドキュメントの 3 ページの sha256 は前回と一致している。トップページのインデックスは 3 件、ブログは 2 本（Triton の RISC-V 適配、PyTorch RISC-V CI 実践）、ドキュメントは 23 章である。すでに複数の期間にわたりブログ記事と章の追加はない。

この側とエンジニアリング側の落差は今期さらに顕著である。同じ日に、VIR が実モデルカーネルを担い、llvm ブランチがリベースワークフローを補い、ディストリビューションブランチに 15 件のマージがあったにもかかわらず、公式コンテンツページは依然として 9 月の 2 本の記事のままだ。#1014 の K3 実測データ（ボード上のスループット、命令数、ビットレベル一致）はそれ自体が既製の技術ブログ素材であり、現時点では PR の説明とリポジトリのドキュメントにしか存在しない。

5.2 フォーラムは期間内に新規投稿なし；10-27 の LPi4A UEFI 実測投稿を追記（10-27）

日付：2026-10-27　情報源：lpi4a UEFI #2896、RuyiSDK 開発者コミュニティ

フォーラムは期間内に新規投稿がなく、最新の投稿は依然として 10-27 の #2896 である。ここで 1 点訂正する。前回、フォーラムの状態を「最新の 2 件は 10-22 のサミット振り返りと講座資料で止まっている」と書いたが、10-26 の隔週進捗 #2895（同件は 10-27 号で既にカバー済み）と 10-27 の #2896 を漏らしていた。後者は 2 つの期間の間で飛ばされていたため、本期で追記する。

#2896 は「lpi4a UEFI」と題し、10-27 10:45 に lzzhzh が投稿、6 枚のスクリーンショットと実写を添付：3 枚は 1366×768 のシステムスクリーンショット、3 枚は 1920×1440 の実写写真。本文によると 9 月 26 日にはアップデートがあることに気づいており、1 か月我慢してからようやく LPi4A に書き込んだ。現時点では UEFI に対応した RevyOS はまだ利用できないが、「少なくとも希望はある」。Yuxi は「いいねいいね」と一言返した。この投稿の価値は、LPi4A ファームウェアエコシステムの現実的なボトルネックを記録している点にある。UEFI ファームウェアはすでに書き込み可能だが、対応するディストリビューションイメージがまだ追いついていない——これはまさにサポートマトリクス（support-matrix）が収録すべきでありながら、現在の調査期間内にコミットがない類の状態である。

5.3 ruyiai-daily 1 期、ruyi-imager が「製造元」を「サプライヤー」に変更（10-28）

日付：2026-10-28　情報源：ruyiai-daily、ruyi-imager コミット a87b8dd9

ruyiai-daily は 06:22 に「daily-news: 2026-10-28」1 期をコミットし、日次アーカイブの情報動向を継続している。

ruyi-imager は 15:46 に 1 件コミットし、インターフェース内の「製造元」ラベルを統一的に「サプライヤー」に変更した。変更は小さいが方向性は明確である。インストーラーが対象とするのはボードの供給側でありチップの製造側ではないため、文言を実際の意味に合わせて収束させた。その他のリポジトリは調査期間内にコミットなし——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」が返した結果の最新 1 件は 10-25 のサミット出展報道（奕行智能）で、調査期間外であり如意コミュニティとも無関係のため本期は収録しない。

ディストリビューション側の 2 バージョンも引き続き調査期間外である。openRuyi ニュースページの最新記事は依然として 2026.09 リリース公告（9-30）で、リポジトリタグは 2026.09-experimental まで、2026.10 は未リリース。ruyi の 0.54.0 は 09-18 の alpha タグのみで、正式版は 079 期の口径では 10 月末を待つ必要がある。過去数か月のペース（6-30、7-23、8-27、9-30）からすると、10 月版は今月末に落ちる可能性が高い。月末まで残り 2 日、次期がこれを確認する最後の便となる。

6. トレンド観察

6.1 「表現できる」から「同じ速さで走る」へ：VIR が初めて実モデルカーネルで性能照合

過去 3 期にわたりこの主线はずっと表現力を補ってきた。10-26 の一夜 7 件で可伸縮ベクトルを追加し、10-27 に Python バインディングを追加し、10-28 には K3 のデコードアテンションを丸ごと移行し、さらにボード上のスループットで照合を行った。3 つの数字が合わさってこそ今回の意味がある——数値はビットレベルで一致、命令数も同一（各 178 条）、スループット区間は重複。自研方言が最も詰まりやすいのは「動くが遅い」という関門であり、#1014 は少なくともこの関門を一時的に通過したことを証明している。

しかしこのスタックが本当に手書きカーネルを代替可能か判断するには、まだ 2 つ足りない。1 つはカバレッジ：今回はデコードアテンションのみを移行し、A210 カーネルは依然として旧関数を使用、MoE、量子化、プリフィル経路はいずれも未着手である。2 つは可伸縮ベクトル：本期は明確に use-scalable をオフにしており、次にオンにするとベクトルサイズはコンパイル期に決定されなくなり、LMUL 4 のグループ化仮定が揺らぐ。その際に数値と命令数を守れるかは再照合が必要である。それまでは「VIR はすでに手書きカーネルに追いついた」を結論とするのは早すぎる。正確な表現は「K3 デコードアテンションのこの区間で、固定ベクトル長の下で追いついた」である。

6.2 基盤交換のコストはパッチドリフトからガバナンスへ：ワークフローがリベースを引き受け、ブランチ自体は依然として人手に依存

同じ日に、llvm の riscv ブランチはブランチ全体の再適用を停止し、244 行の自動リベースワークフローを追加する形に変更した。この転換は単独で記す価値がある。過去 5 日のリズムは「1 日 1 回のブランチ全体再適用、毎回 20 件のコミット列を書き換え」であり、作者時間は動かさず、committer 時間を統一し、パッチセット自体に新機能はなかった。この方式は上流に追随できるが、代償として外部コントリビューターの PR は常に一歩遅れ、提出したい者は自分で再適用する必要がある。

新しいワークフローはこの作業を「PR 番号を入力、デフォルトでドライラン、ワンクリックでプッシュ」というスケジューリングに仕立てた。コンフリクトは一律 riscv 側を採用し、重複パッチは自動的に破棄し、PR のコードとビルドは決して実行しない。これはブランチ自体の毎日の追従を解決するものではないが、「ベースラインへの追従コスト」の一部をメンテナーの手作業の判断から切り分けた。次の段階で観察すべきは、外部 PR が本当にこれによって増えるかどうかだ——もしワークフロー公開後 2 週間以内に、新しいベースラインに従って提出される外部 PR が依然として無ければ、ボトルネックはリベースツールではなく別のところにあるということになる。

6.3 配布層の議論に価格が付き始めた：2.81 倍のビルド時間は「好み」よりも説得力がある

#1350 は約 1 か月にわたって議論されており、核心的な相違点は buddy-mlir が内蔵する LLVM を外に出すかどうかだ。前号の見解はまだ「GCC を使ってもよいが、少なくとも 1.5 倍の時間がかかる」というものだったが、今号で作者は実測値を示した：riscv64 上で 8814 秒が 24798 秒になり、2.81 倍であり、しかも GCC を使った回はリンクに失敗して完走しなかった。これで議論の性質が変わった——技術的な好みから、ビルドファームのスケジューリング算術へと。

この指摘が RuyiAI スタックに示す示唆は結論ではなく方法にある：RISC-V ディストリビューションのパッケージングにおける多くの相違点（vendor するか、ツールチェーンを外に出すか、IR をパッケージに同梱して配布するか）は、最終的に「ビルド時間、イメージサイズ、再現性」という 3 つの測定可能な数字に落とし込まれる。前号で openRuyi は「LLVM IR をパッケージに同梱して配布する」路線を撤回し、今号の #1350 は 2.81 倍で「LLVM をパッケージ内に残す」を守った。二度の判断は方向が逆だが、根拠は同じ種類のコスト計算だ。今後の注目点は、この PR がこの数字を携えてマージできるかどうかだ——もしできないなら、ディストリビューションのビルド所要時間に対する許容度が作者の予想を下回っていることになり、そここそが本当に調整すべき点だ。

情報源チェック表

情報源 検証結果
RuyiAI-Stack 組織（全リポジトリ） llvm-project：riscv ブランチに1件追加（cf00909d、リベース作業フロー +244/−0）、ローカルパッチセットは変更なし。pytorch：riscv ブランチは連続7日目でコミットゼロ、メインブランチの20件はすべて上流。triton-riscv：依存更新 PR #91 が1件（未マージ）。tilelang-riscv は13日目も静か。ruyiai-daily 1期。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 以降コミットなし、新規 Release なし（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 2件、ツールチェーン大型バージョンマクロ、python パッケージングバッチを含む。オープン PR 9件が更新あり（RuyiAI 2件を含み、うち #1350 は3件のコミットをリベース）。新規タグなし（2026.09-experimental が最新）
buddy-compiler 組織 buddy-mlir 3件マージ（#1014 K3 デコードアテンション、#1010 buddy-server 再編、#1012 Whisper x64 CI）＋ ナイトリービルド v0.1.3.dev20261028。オープン PR 4件が更新あり（#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 期は11月上旬を予定
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ページに変化なし：トップページのインデックス3件、ブログ2篇、ドキュメント23章、sha256 は前回と一致
arXiv（RISC-V） 調査期間内の新規なし。最新は 10-23 のオープン ISA スーパーコンピュータ比較と 10-22 のバイナリからコンパイラ IR へのフレームワーク、10-21 の長ベクトル FlashAttention が依然として RVV に最も近い
Google News RSS（中英文複数組） RuyiSDK、RuyiAI、openRuyi、如意 RISC-V の定向クエリはゼロヒット。「如意 RISC-V」の最新1件は 10-25 のサミット出展報道で、調査期間外かつ如意コミュニティとは無関係のため未収録

完全な情報源リスト