報告週期：2026 年 10 月 26 日（週一）至 10 月 30 日（週五），共 5 個工作日。

素材來源：本刊每日 RuyiAI 動態報告 5 期（2026-10-26 至 2026-10-30，每期視窗為前一日 04:30 至當日 04:30，其中週一為過去 3 天、覆蓋週末）；另含 RuyiAI-Stack、ruyisdk、buddy-compiler 三個組織的 168 小時倉庫核查，openRuyi-Project 主倉逐日提交與合併 PR 的全量統計（API 分頁複核），RuyiSDK 開發者社群與 openRuyi 發行版新聞頁雙源複核，以及 RuyiAI 官方主頁三頁快照（核查覆蓋至 10-31 下午）。

編制說明：本週四條主線並行。其一，向量化中間表示 VIR 走完「表達—呼叫—對賬」三級：一夜七筆把可伸縮向量補齊，隔日補上 Python 繫結，第三天把 K3 的解碼注意力整段搬上 VIR 並用板上吞吐做對賬。其二，兩條 riscv 分支的治理方式分道：llvm 一側停止每日整枝重放，改為寫貢獻指南與自動重基工作流，並取消預演開關；pytorch 一側仍是七日靜默後一次性重放。其三，openRuyi 主倉本週 234 筆提交、52 筆合併 PR，KDE Frameworks 6.31.0 一次鋪 64 個包，同時三筆 revert 收回「隨包分發 LLVM IR」的路線。其四，月末發版視窗落空：ruyi 0.54.0 與 openRuyi 2026.10 截至本週末均未釋出。週報在日報素材之外補入八項核查新發現（多在日報視窗之後或週期邊界），列於附錄。

一、本週要聞

  • VIR 三天走完「表達—呼叫—對賬」：可伸縮向量、Python 繫結、K3 解碼注意力依次落地：10-26 22:48 至 10-27 03:22，buddy-mlir 由同一作者連做七筆（#1002 至 #1008），把 strip-mining 按 vscale 步進、向量尺寸按 VLEN/64 計算、帶結果的 vir.set_vl 降到可伸縮向量、動態向量行置換與索引約定一次補齊；10-27 22:42 合入 #1009（12 個檔案、+614/−1），為 VIR 加上 buddy_mlir.dialects.vir 模組，使這條此前只能在 buddy-opt 裡跑的方言可被 Python 直接構造與降級；10-28 09:36 合入 #1014（4 個檔案、+476/−14），把 K3 w4g32 的解碼注意力整段搬到 VIR。來源：#1002 按 vscale 步進、#1009 Python 繫結、#1014 K3 解碼注意力

  • K3 上的對賬三項都硬：數值位級一致、向量指令各 178 條、吞吐區間重疊：#1014 的核心按 64 lanes 分段、單頭為一個 128 個 f32 的 LMUL 4 向量組，降級目標從 vector-width=128 改為 rvv-vlen=1024 且關閉可伸縮向量。帶與不帶 q/k 歸一化都與舊 _attn_decode_fn 位級一致；機器碼兩個並行體各 178 條向量指令，鍵值迴圈與舊版指令相同，只有兩處溢位暫存器過載位置變化；K3 上貪心解碼三檔吞吐全部重疊——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%。來源：#1014、K3 文件

  • llvm riscv 分支從「每天整枝重放」轉向「寫規則」：244 行自動重基工作流加一份貢獻指南，並取消預演：本週前兩日分支仍在換基（10-26 前移 221 筆、10-27 前移 237 筆），10-28 起補入 .github/workflows/autorebase.yml（+244/−0），10-29 再落 RISCV_CONTRIBUTING.md（+82/−8）並把工作流的 dry_run 輸入刪掉——成功即推回作者分支，沒有預覽。指南給出兩條貢獻路徑：由維護者切 work/issue-NNN 工作分支，或直接向 riscv 提 PR 後手動觸發重基。工作流衝突一律取 riscv 側、等價補丁自動丟棄、絕不執行 PR 程式碼與構建。來源：autorebase.yml、RISCV_CONTRIBUTING.md、提交 faf4def312

  • triton-riscv 三筆降級修復 80 分鐘內合入，動機全部來自 FlagGems 運算元遷移：10-29 15:38 至 16:58，#82（雜湊測試用唯一目標索引，1 檔案 +23/−3）、#83（掩碼載入支援張量填充值，4 檔案 +160/−16）、#58（保留迴圈攜帶的 gather 偏移，2 檔案 +125/−0）依次合入。#83 在 riscv64 機器上驗證：新迴歸三條 RUN/FileCheck 全過、全量 lit 291 透過、9 個預期失敗、0 個意外失敗、執行時檢查 18 項透過。三筆分別掛了 82 天、43 天、44 天才合入，而需要它們的遷移 PR #56 當時仍停在 09-16。來源：PR #83、PR #58、PR #82

  • openRuyi 本週 234 筆提交、52 筆合併 PR，KDE Frameworks 6.31.0 一分鐘鋪 64 個包：按北京時間逐日統計，10-26 至 10-30 分別為 80、36、36、73、9 筆，作者以 Leetfs（87 筆）、KiritakeKumi（65 筆）、misaka00251（17 筆）為主。10-29 15:11 的同一分鐘落下 64 個 kf6-* 包，基本覆蓋 Plasma 6 依賴的框架全集；本週另有 Samba 全家一次換到 4.25.1（含 tevent 0.17.2、tdb 1.4.15、talloc 2.5.0，並把 jack2 與 rpm-config-openruyi 改用 Waf 構建）、qemu 11.1.2 與 libvirt 兩筆回移。來源：openRuyi 提交列表、PR #1513 KDE、PR #1428 Samba

  • RuyiAI 三件套打包從「路線之爭」轉入「規範返工」，構建代價被量化為 2.81 倍：PR #1350 一次提交 buddy-mlir、python-triton-ruyiai、python-tilelang-ruyiai 三個 spec，9-21 開出後停擺近一月，10-27 作者逐條回應三處複核意見、10-28 把「改用 GCC 構建」實測為 8814 秒變 24798 秒（約 2 小時 27 分對 6 小時 53 分，且該次連結階段失敗），10-29 收到首輪程式碼級複核 18 條，全部指向 spec 寫法（缺 BuildRequires、Provides 與包名對齊、補丁須用 git format-patch 生成、空 %check 要寫註釋）。截本週結束仍是開放狀態，規模 10 個檔案、+838/−0。來源：PR #1350、PR #1352 PyTorch 包

  • 月末承諾未兌現：ruyi 0.54.0 仍只有 09-18 的 alpha，openRuyi 2026.10 未發：雙週進展 079 期把包管理器 0.54.0 因發版週期調整改到 10 月底，截至 10-31 下午，標籤列表仍停在 0.54.0-alpha.20260918，正式版最新是 09-24 的 0.53.0；openRuyi 倉庫標籤止於 2026.09-experimental，新聞頁無 2026.10 釋出公告。主倉本週最後兩筆是 10-29 的廠商命名清單文件與 10-30 合併 #508，均非發版動作。來源：ruyi Releases、ruyi 標籤、openRuyi 標籤

  • pytorch riscv 分支七日靜默後一次性重放，SyncBots 把基線抬到上游 3afdbd3；tilelang-riscv 到第十四日仍無提交：pytorch 的 riscv 分支自 10-22 起連續七日零提交，10-29 14:06 把 11 筆既有補丁的提交者時間統一改寫完成重放，20:48 再由同步機器人補一筆 [SyncBots] Integrate PyTorch at 3afdbd3（只改 cmake/Dependencies.cmake 一行的 FORCE）。tilelang-riscv 主分支最後一筆仍是 10-16 10:52，開放 PR #4 停更在 09-28，本週唯一的存在感來自發行版的 python-tilelang-ruyiai 規格。來源：pytorch riscv 分支、SyncBots 提交 5a29c201、tilelang-riscv

二、RuyiAI 棧進展（PyTorch / Triton / TileLang RISC-V 適配）

視窗總覽：RuyiAI-Stack 組織（18 個倉庫）本週動作集中在 llvm-project（前兩日兩次換基、後三日轉入治理資產與整枝重放）、pytorch（七日靜默後重放）、triton-riscv（三筆降級修復加兩次錨點更新）、ruyiai-daily（連續五期）與站點倉庫（貢獻者資料機器人重新整理）；tilelang-riscv、FBGEMM、cpuinfo、VecIntrinBench、IntrinTrans、torq-tile、pytorch-ci、dsh-osc 全周無提交。

llvm-project riscv 分支：五天五次換基後停手，治理資產接棒

日期：2026-10-26 至 10-30　來源：riscv 分支提交列表、autorebase 工作流、RISCV_CONTRIBUTING.md

本週的換基序列是 10-25 的 474 筆、10-26 的 221 筆、10-27 的 237 筆。三次重放的共同特徵一致：頭部標題仍是「[RISCV] Add A100 HP/SP and pack/unpack lowering with calibrated scheduling (#31)」，落後 26 筆正好等於本地補丁集條數，逐條比對標題與順序未變；10-27 那次 20 筆本地提交在同一分鐘內被重寫重推（提交者時間集中在 15:00:29 至 15:00:31），而作者時間從 7 月 1 日排到 10 月 3 日。也就是說，這三天的動作是把既有補丁集搬到新基線，功能增量全部來自上游。

10-28 起節奏改變。分支只往前走了一筆 cf00909d，內容是 .github/workflows/autorebase.yml（+244/−0）：安裝在作者源倉庫預設分支上，workflow_dispatch 觸發，兩個輸入為 PR 號與「只預演不推送」（預設開啟），執行環境 ubuntu-24.04、超時 90 分鐘；註釋明確要求絕不在持有寫許可權時執行 PR 程式碼、鉤子、構建或子模組，git 配置把 hooksPath、attributesFile、fsmonitor 全指到 /dev/null；衝突處理對 -Xours 覆蓋不了的場景逐個走 ls-files --unmerged，有第 2 階段取本地、沒有就刪除，並能識別「等價補丁」丟棄重複的舊基線補丁。

10-29 23:00 的整枝重放裡，真正新增的是一筆 [workflows] Push rebased PRs directly and document contribution options（作者時間 10-29 09:59）：autorebase.yml 刪掉 8 行（去掉 dry_run 輸入與預演分支），新增 82 行的 RISCV_CONTRIBUTING.md。指南給出兩條路——先開 issue、由維護者從當前 riscv 切一條 work/issue-NNN 工作分支，貢獻者向工作分支提 PR；或直接向 riscv 提 PR 並手動觸發重基，工作流以 --force-with-lease 帶明確期望 SHA 推回源分支。文件另提醒用 GITHUB_TOKEN 推送通常不觸發後續 push/PR 工作流，更新後的 SHA 上 CI 是否跑過需人工確認。

判斷：這條分支的日常動作此前已完全變成「跟基線」——五天五次、本地補丁零變化。本週的新資訊是治理方式變了：把外部貢獻者「永遠落後一格」的成本從維護者手工判斷裡分出來，做成一次帶明確邊界（不執行 PR 程式碼、不改寫 riscv 本身、不自動合併）的排程。取消預演把摩擦降下來的同時把「推錯歷史」的風險前移給貢獻者，效果要等下一兩個外部 PR 才能驗證。

llvm-project 上游：17 個 RISC-V pass 一小時遷入 NewPM

日期：2026-10-26　來源：InsertVSETVLI 遷移、PreAllocZilsdOpt 遷移、DeadRegisterDefinitions 遷移

10-26 換基帶進來的 221 筆上游提交裡，RISC-V 相關 21 筆，其中 17 筆是 NewPM 移植，作者均為 Aiden Grossman，時間集中在 12:59 至 13:55（北京時間）不到一小時。清單覆蓋後端主要 pass：指令選擇後的 VSETVLI 插入、讀寫 CSR 與 VXRM 寫入、VMV0 消除、壓縮指令生成、壓棧出棧最佳化、基址合併、LoadStore 最佳化、Zilsd 預分配、分支最佳化與 QCRelax 標記，另有暫存器死定義消除、冗餘複製消除、間接跳轉跟蹤、落地墊設定與常量提升。

餘下四筆分屬三個方向：vxrm-pipeline-flush 屬性把 VXRM 的投機寫限制在帶重新整理保證的迴圈內；LSR 在 Zibi 目標上優先選等值比較作迴圈出口；GlobalISel 補上 G_FPTOSI_SAT 與 G_FPTOUI_SAT 的合法化，使浮點到整數的飽和轉換在全域性指令選擇路徑可用。另有一筆把收集散播降級與 VL 最佳化器用到分析改為惰性請求。

意義不在單筆改動，而在管線歸屬：這批 pass 長期掛在 LegacyPM，遷入 NewPM 後與新 pass manager 的分析快取、pass 順序與除錯介面對齊。對下游 fork 的直接影響是每次換基都會帶上這套變動，-passes= 名稱與 pipeline 組成會隨之上移——這也是本週 riscv 分支「換了基但補丁不變」時，實際內容發生變化的少數幾處之一。

pytorch：七日靜默後整枝重放，SyncBots 把基線抬到 3afdbd3

日期：2026-10-29　來源：pytorch riscv 分支、SyncBots 提交 5a29c201、開放 PR 列表

riscv 分支頭部在 10-22 03:00 之後連續七日沒有變化，七筆開放 PR（#23、#35、#36、#38、#43、#46、#48）按更新時間檢索全周零命中；其中 #46「RISC-V Vector Extension support for ATen」與 #48「Add RISC-V Vector CPU capability」是 RVV 能力上行的兩條主線提案，狀態與三週前一致。

10-29 14:06 分支做了整枝重放：11 筆既有補丁的提交者時間被統一改寫為 14:06:44 至 14:06:45，作者時間保持原樣，補丁集保留 riscv64 本地映象（#51）、bytes_to_scalar 浮點修復（#44）、inductor opinfo blocklist（#50）、linear cross entropy 的 ULP 容差（#42）與 CI 系列。20:48 的 [SyncBots] Integrate PyTorch at 3afdbd3 只改一行：KINETO_SOURCE_DIR 的 cache 變數加 FORCE，含義是分支基線跟著上游同步機器人自動前移。

主分支同期每日 20 筆左右提交全部是上游同步，本週內容集中在 Dynamo 的 VariableTracker 構造收斂（#200473、#200472、#199832、#199831、#199830、#199829 一批）、CUDA 的 max_pool3d 64 位索引修正與線上 softmax 合併改用精確指數，無一筆涉及 RISC-V。

值得並讀的是分發側的錯位：openRuyi 的 #1352 正在把這條分支的產物打成 python-torch-ruyiai，而該 PR 停在 10-27，分支頭部已換成新基線。若包按分支產物構建，包內鎖定的原始碼落點需要重新對齊一次，這一步目前沒有 PR 在做。

triton-riscv：三筆降級修復 80 分鐘合入，錨點連跳兩級

日期：2026-10-27 至 10-29　來源：PR #90 錨點更新、PR #83、PR #58

三條線在同一天交匯。第一條是依賴：10-27 19:43，renovate 的 #90 被合入（+2/−2），buddy-mlir 錨點從 nightly/v0.1.1.dev20261017 直接跳到 nightly/v0.1.3.dev20261027，跨過 0.1.2 正式版與兩個夜間構建——這意味著 10-26 夜裡那七筆 VIR 可伸縮向量改動自本期起進入下游構建鏈。10-28 18:51 的 #91 再把錨點抬到 dev20261028，但因 riscv64 三條 CI 排隊未回，當日未合入。

第二條是程式碼：10-29 的三筆降級修復，細節見「本週要聞」。三條的驗證深度並不齊平——#83 跑了全量 lit 與 18 項執行時檢查，#58 只跑針對性迴歸，#82 只跑單檔案（21 透過）。

第三條是狀態錯位：三筆修復先落地，需要它們的遷移 PR #56「Migrate additional FlagGems operators」仍停在 09-16，全周沒有合入；開放 PR 裡 #55（asin 運算元前端補丁）在 10-30 20:14 合入，#85「softmax 及 matmul 最佳化」自 10-18 後無更新。錨點更新只解決「能不能用上」，不等於「已經用上」：10-28 的夜間版構建早於當日上午的三筆合入，下游要拿到 #1014 與 #1015，還得再等一版夜間構建加一筆依賴更新。

tilelang-riscv：第十四日靜默，只剩發行版一條路徑

日期：2026-10-30（狀態）　來源：tilelang-riscv 提交列表、開放 PR #4、openRuyi PR #1350

主分支最後一筆提交仍是 10-16 10:52 的「Build Python extension in Buddy CI」，到 10-30 已連續第十四日無提交；開放 PR 兩筆：#2 停在 06-16、#4「RVV vector mask and max reduction lowering」停在 09-28，均無本週更新。與 triton-riscv 同期三筆合入形成直接對照：同一組織、同一時期，一條在集中清理降級缺陷，另一條完全沒有動作。

唯一的下游存在感來自 openRuyi 的 python-tilelang-ruyiai 規格（#1350 內 4 個補丁：放寬 Apache TVM FFI 0.1.10、改用系統構建依賴、發現 buddy-mlir 工具鏈、跳過 z3 soname 重寫）。「以發行版產物代替倉庫迭代」的狀態已延續到第三週，這條線的恢復訊號應看兩處：倉庫何時有新提交，以及該包何時合入。

三、RuyiSDK 工具鏈與發行版（包管理器、發行版、映象與支援矩陣）

openRuyi 主倉：234 筆提交、52 筆合入，KDE 框架一次鋪 64 包

日期：2026-10-26 至 10-30　來源：openRuyi 提交列表、PR #1513 KDE Frameworks 6.31.0、合併 PR 列表

按提交者時間逐日統計，10-26 至 10-30 分別為 80、36、36、73、9 筆，合計 234 筆；同期合併 PR 52 筆，開放佇列從上週的 71 筆降到 58 筆。作者以 Leetfs（87 筆）、KiritakeKumi（65 筆）、misaka00251（17 筆）、Jingwiw（12 筆）、KimmyXYC（11 筆）為主。

逐日性質差別明顯。10-26 是安全清掃：31 筆安全修復（佔近四成）、18 筆 Rust crate 新增、14 筆版本更新，涉及 48 個包，安全線抬了 nats-server 2.15.1、moby 29.9.2、fzf 0.74.5、etcd 3.7.2、containerd 2.4.2，openjdk-latest 推到 27.0.1.0.2.1 並重新整理原始碼校驗和，另有 sequoia 整套 OpenPGP 工具、fwupd-efi 與 Cloudmux 依賴集入倉；同日的 #1512 把 Go 主線的 Zvk SHA-2 支援回移，是本週唯一一條與 RISC-V 指令集直接相關的發行版改動。

10-27 是聯動升級：Samba 全家在同一時間點對齊（samba 4.25.1、tevent 0.17.2、tdb 1.4.15、talloc 2.5.0、cmocka 2.0.2），凡是依賴這三條 ABI 的包都要跟著重建；安全線由 #1506 一次帶 12 個包（sysrepo 5.2.27、libzip 1.12.1、libyang 6.4.13、libical 4.0.7、vim 9.2.1201、squashfuse 0.6.5、simdutf 9.3.2、pcre2 10.49、libheif 1.23.6、imagemagick 7.1.2.34、cups 2.4.20、cpp-httplib 0.63.0）；新增 13 個包以 Go 生態為主（go-git 三件、goldmark-highlighting-v2、go-udev、go-evdev、gonetworkmanager-v2、ghw、go-pinyin、kustomize 等），與 dms-shell 用打包好的 Go 依賴替換內嵌 vendor bundle 是同一件事的兩面。

10-28 轉向虛擬化：qemu 由 11.1.x 升到 11.1.2，libvirt 兩筆回移（隨包分發 /var/lib/libvirt/secrets、修 Ceph 21 移除 auth_supported 後 rbd 池失效），%toolchain_major_version 宏合入，可在 gcc-15、gcc-16、clang-22、clang-23 間切換；另有一批 python 包構建修復，其中 scikit-build-core 1.1.1 與 cmake 的 Python 分發包後設資料對 triton、tilelang 這類 CMake 擴充套件的 wheel 構建路徑有直接影響。

10-29 是本週期峰值：76 筆提交裡 64 筆是 KDE Frameworks 6.31.0，全部落在 15:11 的同一分鐘，從 kf6-kcoreaddons、kf6-kconfig 到 kf6-kio、kf6-ksvg、kf6-kwallet，基本覆蓋 Plasma 6 依賴的框架全集；其餘為 Gradio 6.31.0、python-pyvex 10.0.5、graphql-core 的 provides 紀元修正，新增 vkpeak（Vulkan 峰值效能與裝置能力探測），以及 ecbuild 的 cmake 模組路徑修正、clang-wrap 日更與三筆 Go 依賴圖清理（刪重複包、補 import path provides）。

openRuyi 打包路線：Samba 聯動升級與 LLVM IR 分發路線收回

日期：2026-10-27　來源：PR #1509 Revert llvm ir、PR #1428 Samba、PR #1511 dms-shell

過去幾期 openRuyi 的關鍵詞是「補」：補包、補安全、補 Rust crate。本週第一次出現明確的減法——15:15 合入的 #1509 只有三筆提交、淨刪 105 行（+5/−105），撤銷三項實驗性打包：gsl 的 llvmir feature、pixman 改用 clang 構建並隨包產出 IR、libjpeg-turbo 隨包分發 LLVM IR。

PR 正文沒有寫理由，從內容看，方向是把庫編成 LLVM IR 隨包分發，為再最佳化或延遲程式碼生成留介面；整條線在發版前被撤回，說明該路線在包體積、ABI 與除錯符號一致性、基礎設施配合三方面的連鎖成本短期難以形成收益。對 RISC-V 發行版而言這是一個可記的取捨：IR 分發理論上能複用上游最佳化，但沒有配套工具鏈時只是把成本轉嫁給使用者。

另一側的加法是「聯動升級」：Samba 與三條依賴庫同時換版，凡依賴 tevent/tdb/talloc ABI 的包都要跟著重建，屬發行版裡最典型的批次動作。同一周裡既有「為一致性重建整片包」的加法，也有「為可維護性砍掉一條實驗路線」的減法，說明維護重心正在從「覆蓋更多包」轉向「守住已有包的質量邊界」。

RuyiAI 三件套打包：#1350 從路線之爭轉入 spec 規範返工

日期：2026-10-27 至 10-29　來源：PR #1350、PR #1350 複核評論

#1350 是本週分發層最重要的一筆：一個 PR 同時加三個包——buddy-mlir、python-triton-ruyiai、python-tilelang-ruyiai。時間線是：9-21 開 PR（三筆提交落在 09:46 至 09:48），9-24 維護者 Z572 提三處修改要求，9-28 作者修掉兩處，隨後停擺近一月，10-27 17:55 至 18:54 連發三條回覆逐條說清，10-28 16:22 三筆提交同分鍾重基到最新主分支，10-29 16:19 至 16:24 收到首輪程式碼級複核五條。

爭論重心在移動。10-27 之前是「buddy-mlir 自帶的 LLVM 要不要外接」——作者給出的理由是這些包始終鎖定具體 LLVM 提交、LLVM 只在該包內部使用，留在包內才可復現；同時 triton 上游 setup.py 強制檢查 git 是否可執行，所以要麼加 git 構建依賴，要麼打補丁改 setup.py（後者會隨 triton 升級失效）。10-28 作者把「改用 GCC 構建」的代價量化：riscv64 上 8814 秒變 24798 秒，2.81 倍，且那次構建在連結階段失敗、沒有跑完。這個數字把爭論從技術偏好變成構建農場的排期算術，2.81 倍意味著機器佔用、超時策略與釋出視窗都要重算。

10-29 的複核轉向機械規範：BuildOption(xxx) 之間不必插空行、python-triton-ruyiai 缺 BuildRequires: python3dist(wheel)、Provides 與實際包名要對齊、Conflicts: python-%{srcname} 的必要性需說明、補丁須用 git format-patch 生成且同一目錄裡有未被引用的補丁、空 %check 要寫註釋解釋原因。這類意見通常出現在「方向已認可、準備收尾」的階段。截本週結束 PR 規模 10 個檔案、+838/−0，複核評論 18 條，仍開放。

PyTorch 單獨成包：#1352 的補丁清單與 RVV 門控

日期：2026-10-27（狀態）　來源：PR #1352、python-torch-ruyiai spec

#1352 把 RuyiAI-Stack/pytorch 單獨打成 python-torch-ruyiai（8 個檔案、+783/−0），與 #1350 同日開、同日更新，唯一一筆提交停在 9-21 11:22，全周未動。

補丁集讀起來是一份完整的發行版適配清單：2001 強制 OpenBLAS 走 cblas 複數點積、2003 改用系統 fmt、2005 改用系統 cmake 依賴、2006 跳過無用的子模組預構建檢查、2011 把 RVV kernel 按目標向量能力門控、2012 內嵌 scikit-build-core；另附 pytorch-smoke-test.py，安裝後要跑一次冒煙測試才算透過。2011 是這批裡最有價值的一條：把 RVV kernel 的啟用條件從「編譯時假定支援」改成「按目標向量能力門控」，正對應 RVA20 等不含向量擴充套件的目標上「包能裝、執行即崩」的老問題。這類修補通常要等使用者在板子上撞到才補，現在提前進了打包補丁。

風險同樣明確：分支本週才剛整枝重放到新基線，包內鎖定的原始碼落點需要重新對齊；#1352 停在 10-27，比分支重放（10-29）早兩天。

ruyi 包管理器：0.54.0 的月末承諾未兌現

日期：2026-10-30（狀態）　來源：ruyi Releases、ruyi 標籤列表、ruyi 提交列表

雙週進展 079 期給的口徑是「因發版週期調整，0.54.0 預期 10 月底釋出」。截至 10-31 下午，標籤列表仍是 0.54.0-alpha.20260918 之後沒有新標籤，正式版最新為 09-24 的 0.53.0，主分支本週只有兩筆：10-29 的「docs: update vendor naming list」與 10-30 合併 #508，均非發版動作。按 09-17 出 beta、09-24 出正式版的上一輪節奏，0.54.0 若要按期，需先出現 beta 再進發布流程，本週已無餘地。

同期有兩筆值得記的提案與文件：#507 在 10-28 提交，給 ruyi 加「探測給定軟體包的主機 ABI 相容性」的能力（43 個檔案、+4023/−716），做法是以包內 ELF ABI sidecar 為查詢計劃，比對架構、ELF class、直譯器、共享庫、符號版本與架構屬性，結果分相容、不相容、無法判定三態，並新增 ruyi admin check-abi 子命令；#508 的廠商命名清單更新與 ruyi-imager 把介面「製造商」改為「供應商」是同一件事的兩端，避免兩處叫法不一致。前者把「預編譯 RISC-V 包能不能裝在這臺機器上」從試錯變成可解釋檢查，對以二進位制分發為主的 RuyiSDK 生態價值高於任何單個包的版本更新，目前仍未合入。

ruyi-imager 1.1.0-rc.1、packages-index 與支援矩陣

日期：2026-10-26 至 10-29　來源：ruyi-imager v1.1.0-rc.1、support-matrix K3 Pico-ITX 提交、packages-index

ruyi-imager 在 10-29 16:02 釋出 v1.1.0-rc.1，距 1.0.0（09-10）約七週。四條變更全部是可用性打磨：映象選擇步驟加入下載動作（#12）、CLI 輸出對齊終端字符集並讓 JSON 保持 UTF-8（#14）、選擇對話方塊雙擊即確認（#19）、選擇對話方塊必須顯式選擇（#21）；其中「雙擊確認」與「必須顯式選擇」是一對互補約束，前者提速、後者防誤選。釋出說明標註了一位首次貢獻者，四筆裡三筆來自同一人。本週另有 K3 UFS 與 UEFI 刷寫支援（10-23，週一視窗內）、選擇對話方塊雙擊與鍵盤確認、介面術語由「製造商」改「供應商」等前序鋪墊。

packages-index 本週僅一筆：10-26 把 revyos 的 Milk-V Meles 映象與相關 uboot 抬到 20260504。數量少與 079 期的說明相符——ISCAS 軟體源近兩週遇到資料同步問題，已構建完成的包未能重新整理到公網，包清單側自然沒有批次更新。這會帶來一個可預期的錯位：若 0.54.0 釋出而軟體源未恢復，使用者 ruyi update 看到的內容會落後於倉庫實際狀態。

支援矩陣本週三份報告，作者相同、結論不同：Milk-V Jupiter2 的 Bianbu 4.0.1（出廠預裝映象、USB-PD 65W 或 ATX 2-pin 12V 供電、首次開機走設定嚮導）；SpacemiT K3 Pico-ITX 的 Bianbu 4.0.8（LXQt 變體，狀態 good，桌面功能完整無阻塞）；StarFive VisionFive 2 Lite 的 Ubuntu 24.04.5（官方預裝伺服器版映象、SFFB 進 fastboot 燒錄、USB-to-TTL 串列埠，狀態僅 basic）。後兩份同一天合入、同一作者，評級差異恰好說明眼下 RISC-V 發行版的實際可用度取決於廠商映象的適配深度，而非單純的核心支援。

雙週進展 079 期：發版週期調整與三條開發中事項

日期：2026-10-26　來源：雙週進展 079 期、第 079 期檔案

079 期在 10-26 18:02 發到社群論壇，報告期截至 10-22，晚於報告期四天。包管理器口徑變化最直接：0.54.0 因發版週期調整改到 10 月底，當前正式版仍是 0.53.0，社群軟體源保持常態化維護並承諾相容近三個正式版本。

開發中事項三條：檢測軟體包與當前系統的 ABI 相容性、更多官方維護軟體包的 macOS 打包、針對 SpacemiT K1/K3 的工具鏈適配。基礎元件側，glibc 把 sinh、sinhf、sinpi 移植進 libmvec 向量數學框架，newlib 補了 acosf、logf、asinf、asinhf、asinpif、atanf 六個向量數學函式；GCC 側重基 Zvdota/Zvbdota 支援、加上 Ztt 擴充套件的 Md 支援，並把 P 擴充套件支援更新到 0.6 版。三條開發中事項與 0.54.0 的時間口徑共同構成下一期的觀察位：ABI 檢測已有 #507 的提案、K1/K3 適配要看工具鏈包形態、macOS 打包則關係到非 RISC-V 宿主上的可用性。

四、向量擴充套件與運算元最佳化（VecIntrinBench / IntrinTrans / FBGEMM）

本棧向量四倉整週靜默，基準側缺口被三筆修復照亮

日期：2026-10-30（狀態）　來源：VecIntrinBench、IntrinTrans、FBGEMM、cpuinfo

四個向量相關倉庫全周零提交，靜默時長繼續拉長：VecIntrinBench 停在 02-13、cpuinfo 停在 05-20、IntrinTrans 停在 06-25、FBGEMM 停在 07-13；torq-tile 停在 04-09、dsh-osc 停在 09-15、pytorch-ci 無提交記錄、harness 停在 10-27（週一那筆外掛拆分）。

本週最需要基準的地方恰好出現了：三筆 triton-riscv 修復都是用「lit 透過數 + 執行時用例透過數」驗證的，沒有一處給出向量化質量的可比數字（指令條數、佔用 LMUL、暫存器溢位次數）；#1014 的效能對賬也明確承認同一份程式碼兩次構建差 2%。靠板上吞吐做結論本就吃緊，若基準側繼續不動，後續「最佳化是否真的提升」會長期只能靠人肉對賬。這不是本週新增的問題，但三筆合入與一次效能對賬把它照得更清楚。

FlagGems 遷移成了 triton-riscv 的缺陷發現機制

日期：2026-10-29　來源：PR #83、PR #58、PR #56 FlagGems 遷移

把三筆修復的動機攤開看，共同來源不是測試套件，而是「把 PyTorch 運算元一批一批搬上 triton-riscv」這件事本身：unique_dim 帶真張量填充值的 tl.load、broadcast_to 的迴圈攜帶偏移、雜湊運算元的重複索引比對，三者都不在 RISC-V 指令層面，而落在降級層與驗證層的邊界上。這類缺陷在單元測試裡很難自然長出來——得有一個真實運算元庫按批次方式往上壓，才暴露得出來。

方法論價值高於三筆修復本身：對一條以 Triton 為入口的 RISC-V AI 棧，FlagGems 遷移實際充當端到端驗收集，比編譯器的 lit 套件更接近真實負載。反過來說，本週也暴露了這個機制的單點依賴——#56 從 09-16 起就沒有更新，三筆修復合入後驗收流程反而停住；若長期不推進，下一批缺陷要等別的使用者撞上才會被發現。週期末尾出現一個積極訊號：#56 在 10-30 20:50 有一次更新（詳見附錄），但仍未合入。

向量寬度口徑：1024 位、單頭一個 LMUL 4 組

日期：2026-10-28　來源：buddy-mlir PR #1014、llvm 提交 1811501f、llvm 提交 ed439f3e

#1014 把核心降級的目標向量長度定在 1024 位，並要求不使用可伸縮向量，於是每個頭（128 個 f32）剛好佔一個 LMUL 4 的向量組，區域裡那條 vir.shuffle 也正好在組內完成——尺寸、分組、指令三者被同一組引數約束住，這是本週值得記下的一個技術口徑。

這條口徑與上游後端是同一件事的兩端：上一視窗 llvm riscv 分支合入的 #30 把 IME 內建降到 SpacemiT A100 的點積指令，#31 給 A100 補了 HP/SP 與 pack/unpack 的降級路徑並做排程校準。一個是後端按暫存器做指令選擇與排程，一個是核心表達層按暫存器定向量尺寸。目前沒有文件說明兩處引數是否互為約束，也沒有在 K3 上做過交叉驗證；下一階段切到可伸縮向量（作者已說明是下一筆）時，LMUL 4 的分組假設會鬆動，這個口徑會不會跟著調整，是最值得觀察的點。

上游驗證與論文：arch-test 遷址後 30 筆，arXiv 全周無新增

日期：2026-10-23 至 10-30　來源：riscv/riscv-arch-test 提交列表、Sv 套件合併 #2981、arXiv 檢索

本週核查發現 riscv-arch-test/riscv-arch-test 原地址已返回 404，倉庫遷到 riscv/riscv-arch-test。遷移後的倉庫在週一視窗（10-23 至 10-25）有 30 筆提交，是全視窗最活躍的上游之一：一條線是把分散套件合併成一個（PMP #2996、Exceptions 各組併入統一套件、Sv 與 SvSm、SvZicbo、ExceptionsSv 併入統一 Sv 套件 #2981），同時把 CI 的排除清單改為一行一個條目；另一條線補特權級與虛擬化的空白（H 擴充套件的 CSR 與指令套件 #2982、hypervisor 的 M 模式測試併入 Sm 組 #2983、S 與 H 模式下的 VS/VU/VS 級中斷 #2911、Svinval 的 H 與 SmH 組 #2997、H_Zicntr 與 Sm_Zicntr_H 的計數器使能與 htimedelta #2998，以及 Shcounterenw 等六項 S 態約束與四項 Zic 基礎約束）。合併與補齊同時做，說明重組目標是先把結構理順、再往結構裡填內容。RuyiSDK support-matrix 與各家晶片的合規性判斷都以這套測試為準，遷址這件事本身需要記住。

arXiv 側全周無新增 RISC-V AI 預印本。最新兩篇是 10-27 的 SecDMP（資料訪存相關預取的可證明安全方案）與面向異構 TinyML 的輕量 C 程式碼生成器；10-23 兩篇為開放 ISA 超算路線比較與 LLM 輔助修 RISC-V 處理器缺陷；與本主題最貼的仍是 10-21 的《Reorienting the Vector Axis: Restructuring FlashAttention for Long-Vector Processors》，討論長向量處理器上按 64 lanes 分段、重構向量軸的做法，與 #1014 屬同一類問題，可惜視窗內沒有後續。

五、Buddy Compiler 動態（buddy-mlir 提交與釋出）

VIR：一夜七筆可伸縮向量，隔日補上 Python 繫結

日期：2026-10-26 至 10-27　來源：#1002 按 vscale 步進、#1007 統一索引約定、#1009 Python 繫結

10-26 22:48 至 10-27 03:22，同一作者連做七筆（#1002 至 #1008），全部是 [midend][VIR] 字首，圍繞同一個開關 use-scalable，可拆成三層。迴圈與尺寸層：#1002 修掉 strip-mining 的步長——此前 vir.set_vl 不帶結果時降成以常量 vector-width 為步長的主迴圈，每輪卻按 N 倍 vscale 條 lane 訪存，vscale 大於 1 時迭代會重疊；#1003 讓尺寸選擇在 RVV 上按 vscale = VLEN/64 計算，使 N 與 SEW 決定 LMUL 而不再退回定長向量；#1008 修掉索引向量沒有顯式寬度時的斷言崩潰。帶結果的 vir.set_vl：#1004 允許它降到可伸縮向量，#1005 進一步支援多維動態向量。訪存與置換：#1006 加上動態向量按行置換的 vir.shuffle，#1007 統一 vir.load 與 vir.store 的索引約定。

動機不是泛化的向量化改造，而是被具體運算元逼出來的：decode attention 裡 RoPE 的 rotate_half 要把 128 元素的頭按前後兩半互換再取負（即 [-x[1], x[0]]），本質是按行置換，而 VIR 此前無法表達動態向量的行置換，只能在外層用定長向量算好再把 query 帶進 region。於是 #1006 補置換、#1005 補多維動態向量、#1007 補索引入口，三筆合成一條「讓 decode attention 整套留在 VIR 裡」的路徑。

隔日 22:42 合入的 #1009（12 個檔案、+614/−1）補上 Python 繫結：此前 VIR 既沒有 Python 側的運算元構造入口、也沒有型別構造入口，運算元名與型別描述都要在字串裡手工拼，整套降級也只能在 buddy-opt 一個可執行檔案裡跑；實現走 ODS 定義運算元加 C API 加 nanobind 擴充套件，與倉庫裡 quant 等自帶型別的方言同構，分 Ops、Types 與 pass 註冊三塊。這一步的意義在可組合性——運算元描述、形狀推導、測試用例都可以寫在 Python 側，前端與 VIR 的對接不必再依賴 C++ 側加鉤子。

K3 解碼注意力搬上 VIR：數值位級一致、指令數相同、吞吐區間重疊

日期：2026-10-28　來源：PR #1014、K3 文件改動、測試檔案

#1014 在 09:36 合入（4 個檔案、+476/−14，其中核心 264 行、測試 152 行、降級流水線 10 行、文件 50 行），把 K3 w4g32 核心的解碼注意力整段搬到 VIR 方言上。這是第一次拿真實模型的核心做對賬——一邊是此前手工寫的 RVV 向量核心，一邊是用 Python 拼出來的 VIR 核心，比數值、比指令數、比板上吞吐。

實現四層：構造層不再手工拼運算元與型別，改走 buddy_mlir.dialects.vir 的 SetVLOp、load、shuffle、fma、reduce，一個 work item 就是一段 vir.set_vl 區域，長度取頭維一半（64 lanes），區域返回該頭的 (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 區域。流水線引數改為 rvv-vlen=1024、use-scalable=false，舊的 _attn_decode_fn 保留給 A210 核心。

驗證三條：測試對 _attn_decode_fn 做位級比對，覆蓋帶執行緒與不帶執行緒、起點 0/15/16/37/70，帶 q/k 歸一化時覆蓋 0/37，test_k3_w4_moe.py 的 qk_norm 路徑也跑 VIR 核心，check-buddy 239 加 401 全部透過；機器碼兩個並行體各 178 條向量指令，鍵值迴圈與舊版完全一致，只有兩處溢位暫存器過載位置變化，q 的旋轉從兩個 LMUL 2 半組上的運算變成 vfneg 加一次暫存器搬移；K3 上貪心解碼三檔序列長度吞吐全部區間重疊（數字見「本週要聞」）。PR 明確說這是把已關閉的 #998 重做一遍，重做的基礎是此後四筆（#1000、#1005、#1006、#1009），因此不是獨立最佳化，而是把前四筆的地基一次性壓測。

需要剋制：這次「效能持平」是在 K3 單板、貪心解碼、三段序列長度上得到的，作者也註明同一份程式碼兩次構建可差 2%。它證明的是 VIR 不再引入效能損失，而不是 VIR 已優於手寫核心；覆蓋面也只有一個核心，A210 仍用舊函式，MoE、量化與預填充路徑都還沒動。

buddy-server 新 ABI：56 個檔案把模態外掛收斂成統一介面

日期：2026-10-29　來源：PR #1015、提交 7d2ce844、RAX 打包與載入分析

15:08 合入的 #1015（56 個檔案、+3934/−1661）是本週整個棧裡改動面最大的一筆。PR 描述只有一句意圖：更新 buddy-server 解析 RAX 檔案時用的 ABI 介面，新介面為將來支援更多模型提供便利。

結構上是把「按模態各寫一套外掛控制代碼」換成「一套統一介面」：新增 ServerModelABI.h（392 行）、ServerModelABIConversion.h（179 行）、ServerModelPluginAdapters.h（742 行）、ModelError.h（57 行），刪除按模態拆分的 AudioTranscription、Embedding、MaskedLM、Resident 四組實現與 ModelPluginDiscovery，換成一個 350 行的 ServerModelPluginHandle 加 102 行標頭檔案，由適配層把各模態舊入口接回新 ABI；BuddyServerApp.cpp 單檔案 +446/−225。模型側同步改寫 bge_m3、deepseek_r1、llama31_tt、proteinglm、qwen3_vl、whisper 六個目錄的 Model 與 Plugin 成對調整。

測試側最值得關注：新增 ServerModelPluginHandleTest.cpp（325 行）與 ABI 錯誤、能力、併發、依賴四類整合測試，刪除四組按模態寫的單元測試（約 226 行）——測試重心從「每種模態各測一遍」轉到「統一 ABI 的橫切行為」，覆蓋面反而更寬。需要剋制的是：這是介面重構，PR 沒有給出效能資料，也沒有新增模型的支援證明，「為支援更多模型提供便利」要等下一個按新 ABI 接入的模型才算兌現。

釋出節奏：0.1.2 之後連出五個夜間版，下游錨點一路抬高

日期：2026-10-25 至 10-30　來源：Releases 列表、夜間版 v0.1.3.dev20261030、BUDDY MLIR 0.1.2

0.1.2 正式版在 10-25 06:18 釋出（release 說明為空、由自動流程生成，變更需從提交歷史反推），結束了連續五期的停頓；間隔七日，比 0.1.0 到 0.1.1 的兩日間隔更接近常規節奏。此後的夜間版恢復為每日一版：10-26 06:37 的 dev20261026（0.1.3 線首包）、10-27 08:26 的 dev20261027、10-28 07:56 的 dev20261028、10-29 08:21 的 dev20261029、10-30 08:49 的 dev20261030，共五個，全部標為預釋出。

出包與合入的時間差值得單獨記，因為它是這條棧的固定延遲結構：buddy-mlir 合入 → 次日夜間構建 → renovate 提出依賴更新 → triton-riscv 合入，三跳通常一到兩天。dev20261028 早於當日上午三筆合入（#1010 08:54、#1014 09:36、#1012 09:55），因此不含 K3 解碼注意力；dev20261029 早於 #1015 七小時，因此不含新 ABI；dev20261030 才同時帶上 #1014 與 #1015。0.1.3 線已連續五個夜間版沒有正式版，最近正式版仍是 0.1.2——#1015 這種規模的介面變更若要走正式版本，還得再等一輪。

六、社群與活動與官方主頁

雙週進展 079 期與論壇五帖

日期：2026-10-26 至 10-29　來源：雙週進展 079 期、RuyiAI 峰會回顧 #2899、香山如意生態大會轉載 #2898

論壇本週五個新帖。10-26 18:02 的 #2895 是雙週進展 079 期（報告期截至 10-22），也是本週唯一一份正式彙報，下一期按兩週節奏大約在 11 月上旬。10-27 10:45 的 #2896「lpi4a UEFI」由使用者釋出，附三張 1366×768 系統截圖與三張 1920×1440 實拍，正文說 9 月 26 日就發現有更新、忍了一個月才刷機，雖然目前還沒有匹配 UEFI 的 RevyOS 可用，「但至少有個希望」——這條記錄了 LPi4A 韌體生態的一個真實卡點：UEFI 韌體可刷入，配套發行版映象尚未跟上。

10-29 三帖集中在峰會餘波。#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 原生軟體棧」是同一論壇上被並置釋出的成果之一。另有 #2897 轉載包雲崗在峰會上的演講《十二年認知，十年展望》，本週日報未收，本期補錄。

官方主頁：三頁無變化，工程與傳播的落差繼續拉大

日期：2026-10-30（狀態）　來源：RuyiAI 官方主頁、部落格、文件

首頁、部落格、文件三頁的 sha256 與上一期一致：首頁索引 3 條、部落格 2 篇（Triton 的 RISC-V 適配、PyTorch RISC-V CI 實踐）、文件 23 章。已連續多個視窗沒有新增博文與章節。

本週可寫成技術博文的素材不少：VIR 從可伸縮向量到 Python 繫結再到 K3 效能對賬的完整鏈條、buddy-server 統一 ABI 的重構思路、ruyi-imager 1.1 的互動改造、ruyi 的宿主 ABI 探測提案——都停留在 PR 描述與倉庫文件裡，其中 #1014 的板上吞吐、指令數、位級一致三項資料本身就是一篇現成文章。對外呈現這條棧的入口仍只有兩篇 9 月的文章，與「每日有提交、每週有合入」的節奏不匹配。

外部新聞：定向查詢全周零命中

日期：2026-10-30（狀態）　來源：Google News RSS、openRuyi 發行版新聞頁

對 RuyiSDK、RuyiAI、如意 RISC-V、如意社群編譯器、openRuyi 的中英文定向查詢（含 when:3d）全週五期均為零命中。同期抓到的 RISC-V 相關新聞與如意社群無關，逐日記錄為：MIPS 的 RISC-V 平臺說明、達摩院玄鐵 C950 的報道、S2C 在 RISC-V 中國峰會的驗證與原型展示、中科通量的資料流智慧計算產品、deepin 在峰會的桌面生態進展、Pharo 14 的 RISC-V JIT、Tenstorrent 完成 15 億美元 E 輪融資、Microchip PIC64-HPSC 航天計算進展。這些條目不屬本主題，本週不收錄，僅作外部參照。

openRuyi 新聞頁：10 月兩篇已上線，2026.10 版本仍未發

日期：2026-10-31（核查）　來源：openRuyi 新聞頁、Ruyi Firmware 公告、生態基礎設施一文

本週複核發行版新聞頁時發現一處需要更正的口徑：此前五期日報均寫「新聞頁最新一篇仍是 2026.09 釋出公告（9-30）」，實際頁面 10 月已上線兩篇，均標註 2026 年 10 月 19 日釋出——「openRuyi-Project：RISC-V 軟體生態的公共基礎設施」與「openRuyi 釋出 Ruyi Firmware：為 RISC-V 平臺提供開放 UEFI 韌體方案」。兩篇都落在本週之前，不屬本週期內容，但說明發行版的內容側並非完全停更，此前的判斷應更正為「月度釋出公告未出，但 10 月已有兩篇專題文章」。

版本側結論不變：倉庫標籤止於 2026.09-experimental，2026.10 的釋出公告未出現；按 6-30、7-23、8-27、9-30 的月度節奏，10 月版已錯過月末視窗，成為下一週期的首要觀察項。

七、趨勢觀察

VIR 走完「表達—呼叫—對賬」，但結論只能是「不引入損失」

過去三週這條主線一直在補表達力：10-26 一夜七筆把可伸縮向量補進來，10-27 補上 Python 繫結，10-28 直接把 K3 的解碼注意力整段搬過去，並拿板上吞吐做對賬。三個數字合起來才是這周的意義——數值位級一致、向量指令數相同（各 178 條）、吞吐區間重疊。自研方言最容易卡在「能跑但慢」這一關，本週至少證明這一關暫時過了。

但把它讀成「VIR 已追平手寫核心」就過頭了。準確說法是「在 K3 解碼注意力這一段、在固定向量長度下不引入損失」。兩處缺口明確：覆蓋面只有解碼注意力，A210 核心、MoE、量化與預填充路徑都沒動；可伸縮向量被顯式關閉（use-scalable=false），下一筆開啟之後向量尺寸不再由編譯期決定，LMUL 4 的分組假設會鬆動，屆時數值與指令數能不能守住，需要重新對賬。作者自己也把同一份程式碼兩次構建的 2% 差異寫在 PR 裡，這個量級恰好說明「持平」結論的邊界。

分支治理分道：llvm 寫規則並取消預演，pytorch 靠重放與同步機器人

同一個月內兩條分支給出了兩種答案。llvm 的 riscv 分支補丁集大（26 筆）、外部貢獻多，衝突與歷史漂移是主要成本，於是值得寫文件（RISCV_CONTRIBUTING.md）與配工作流（autorebase.yml），並把「預演」這一步刪掉——成功即推送，把摩擦降到最低、把風險前移給貢獻者，靠 --force-with-lease 與 SHA 複檢兜底。pytorch 的 riscv 分支補丁集小（11 筆），維護者自己重放一次的成本低於維護流程的成本，於是繼續每日或隔日整枝重放，再加一個同步機器人把基線抬到上游最新。

兩者的共同點是「本地補丁集長期不變」：llvm 的 26 筆、pytorch 的 11 筆，本週都沒有新增功能。跟蹤這兩條分支的正確方式不是看 SHA 或提交數——重放會把提交者時間統一改寫、把提交數隨上游膨脹——而是看補丁標題集合，以及上游帶進來了什麼（本週是 17 個 pass 遷入 NewPM 與 P 擴充套件的 isel 補齊）。

判斷一條分支治理是否見效，可以看兩個可驗證的訊號：llvm 這邊，工作流上線後外部 PR 是否真的變多（若兩週內仍無人按新基線提交，說明瓶頸不在重基工具）；pytorch 這邊，重放是否重新穩定為每日（本週是七日靜默後一次補做，屬擇期而非流水）。

打包成為 RuyiAI 棧的真實瓶頸，爭論開始有價格

#1350 爭論了將近一個月，核心分歧是 buddy-mlir 自帶的 LLVM 要不要外接。上週的口徑還是「可以用 GCC，但至少 1.5 倍時間」，本週作者給出實測：riscv64 上 8814 秒變 24798 秒，2.81 倍，且用 GCC 那次在連結階段失敗。爭論的性質於是從技術偏好變成構建農場的排期算術——2.81 倍意味著機器佔用、超時策略與釋出視窗都要重算。

這條對整條棧的啟示在方法而非結論：RISC-V 發行版打包的許多分歧（是否 vendor、是否外接工具鏈、是否隨包分發 IR），最終都要落到「構建時間、映象體積、可復現性」三個可測的數字上。同一周裡 openRuyi 收回「隨包分發 LLVM IR」的路線（#1509），#1350 用 2.81 倍守住「LLVM 留在包內」，兩次判斷方向相反，依據卻是同一類成本核算。

更進一步看，#1350 本週的複核意見已經從設計路線轉到 spec 寫法（缺 BuildRequires、Provides 對齊、補丁格式、空 %check 註釋），說明「能不能被髮行版吞下」的問題已經變成「包本身夠不夠常規」。三處非常規點——buddy-mlir 自帶 LLVM、triton 依賴 git 可執行、tilelang 需要發現 buddy-mlir 工具鏈——每一處都需要補丁與解釋，每個解釋都要維護者花時間判斷。若希望三件套進入月度發行節奏，把它們收斂成一兩條明確的打包約定（例如統一由 buddy-mlir 提供工具鏈、統一用 git format-patch 的補丁堆疊），比逐條回應複核意見更省事。

月末承諾集體後移：發行版轉入「按月鋪量、按周清掃」節奏

本週兩個月末承諾同時落空：ruyi 0.54.0 仍只有 09-18 的 alpha，openRuyi 2026.10 未發。與之對應，openRuyi 主倉本週 234 筆提交裡，KDE 框架一次 64 包、Samba 全家聯動、qemu 11.1.2 與 libvirt 回移、12 個 C/C++ 安全更新——這是典型的「鋪量與清掃並行」，而不是「切版本前的凍結」。

兩條流水線的節奏差異也值得記：KDE 包有上游 spec 可參照、有既定版本節奏，重打包是機械動作，所以能在一天內完成 64 個包；而 RuyiAI 三件套是從零寫的 spec，既要解釋「為什麼把 LLVM 留在包內」，又要解釋「為什麼 %check 為空」，從 09-21 開到現在仍在返工。發行版的「按月鋪量」能力與「接納新包」的成本並不對稱，後者取決於包本身有多常規。

對讀者的實際含義：ruyi 使用者在 10 月底仍會拿到 0.53.0；若 0.54.0 在 11 月初發布，還要看 ISCAS 軟體源是否恢復，否則 ruyi update 看到的包清單會落後於倉庫實際狀態。這兩件事是下一週期的首要核實項。

缺陷發現依賴單一入口，驗收鏈比修復鏈更脆弱

本週三筆 triton-riscv 修復的共同來源不是測試套件，而是「把 FlagGems 運算元搬上 triton-riscv」這件事本身：張量填充值的掩碼載入、迴圈攜帶的 gather 偏移、雜湊運算元的重複索引比對，三者都落在降級層與驗證層的邊界上。這類缺陷在編譯器自己的 lit 套件里長不出來，得有一個真實運算元庫按批次方式往上壓。

順序問題隨之暴露：修復先落地，需要它們的遷移 PR #56 卻停在 09-16。一批「為某個用法準備的修復」暫時沒有對應的用法在跑，若 #56 恢復時 Triton 上游又換了幾輪，三筆修復是否還與新基線相容需要重新驗證；若長期不恢復，這套端到端驗收集等於停擺，下一批缺陷要等外部使用者撞上。週期末尾 #56 有一次更新（10-30 20:50），但仍未合入——這是下週期最值得盯的一處。

推論是可以落地的：對一個以「能跑真實模型」為目標的棧，把遷移做成常駐迴歸（哪怕只有幾十個運算元、每晚跑一次）比再多合幾筆修復更有價值。工具鏈層面的證據也在同一周出現——#83 的驗證是本週三筆裡最硬的一筆（lit 291 透過、18 項執行時檢查），而它恰好也是與真實運算元整合最深的一筆。

基準側長期空白，讓「最佳化是否有效」無法回答

VecIntrinBench 停在 02-13、cpuinfo 停在 05-20、IntrinTrans 停在 06-25、FBGEMM 停在 07-13——四個向量相關倉庫全周零提交，停更時長以月計。與此同時，本週的效能結論只能靠 K3 板上的吞吐區間，而作者明確寫下同一份程式碼兩次構建可差 2%；三筆修復的驗證也只給透過數，不給向量化質量的任何指標（指令條數、佔用 LMUL、暫存器溢位次數）。

這不是本週新增的問題，但三筆合入與一次效能對賬把它照得更清楚：一條以「向量能力上行」為目標的棧，缺少持續跑分的向量內建基準，就很難判斷後續最佳化是真提升還是波動。下一步真正該補的不是更多 lowering，而是一個每晚能跑、能給指令數與 LMUL 的基準——否則「效能持平」與「效能提升」在 2% 噪聲下無法區分。

附錄：素材與核查說明

素材清單

  • 2026-10-26 期：視窗 10-23 04:30 ~ 10-26 04:30（過去 3 天，覆蓋週六與週日）。
  • 2026-10-27 期：視窗 10-26 04:30 ~ 10-27 04:30。
  • 2026-10-28 期：視窗 10-27 04:30 ~ 10-28 04:30。
  • 2026-10-29 期：視窗 10-28 04:30 ~ 10-29 04:30。
  • 2026-10-30 期：視窗 10-29 04:30 ~ 10-30 04:30。
  • 週期邊界外（10-30 白天至 10-31 下午）的動態經組織倉庫、釋出頁與社群源核查後補入，見「本週補入的日報之外條目」。

核查方式與口徑

  • 組織核查（168 小時視窗）：覆蓋 RuyiAI-Stack、ruyisdk、buddy-compiler 三個組織的提交、PR 與釋出，走 Atom 與網頁雙通道，不依賴 API 限額；上游 fork（PyTorch riscv、LLVM riscv、LLVM main）的提交按 RISC-V、RVV、向量擴充套件、玄鐵相關關鍵詞過濾後收錄。
  • openRuyi 主倉統計：經 API 全量分頁複核，視窗起點為北京時間 10-26 00:00（UTC 10-25 16:00），終點 10-30 24:00，得 234 筆提交；按「提交者時間」換算北京時間的自然日計數為 80、36、36、73、9。合併 PR 用 is:merged merged:>= 檢索得 52 筆，開放佇列 58 筆。該口徑與日報各自的 24 小時視窗不同，故與單期日報數字不完全對應。
  • 重點倉庫補充核查：openRuyi-Project 的 openRuyi（逐日提交、PR、標籤）、homepage；ruyisdk 的 qemu（p-dev、ame-0.6）、llvm-project（AME）、linux-xuantie-kernel、riscv-gcc、wechat-articles、ruyi、ruyi-imager、packages-index、support-matrix、AME-operator；buddy-compiler 的 buddy-mlir；RuyiAI-Stack 的 pytorch（riscv 分支）、triton-riscv、tilelang-riscv、ruyiai-daily、ruyiai-stack.github.io。
  • 社群雙源：RuyiSDK 開發者社群論壇（最新主題列表，本週五帖）與 openRuyi 發行版新聞頁（含 10 月兩篇專題文章的日期複核）。
  • 官方主頁：www.ruyiai.org 首頁、部落格頁、文件頁三頁快照與 sha256 比對，附部落格與文件索引條目（部落格 2 篇、文件 23 章）。
  • 時間口徑：倉庫提交以提交者時間按北京時間換算；「每日」類描述以連續日曆日為準；週週期為 2026-10-26 至 2026-10-30 五個工作日。

本週補入的日報之外條目

  1. 10-30 20:14，triton-riscv 合入 #55「Support asin op via frontend patch」（前端補丁實現 asin 運算元），在 10-30 期日報視窗之後。
  2. 10-30 20:50，triton-riscv 的遷移 PR #56「Migrate additional FlagGems operators」恢復更新（仍為開放狀態），是 09-16 之後的首次動作。
  3. 10-30 08:49，buddy-mlir 釋出夜間版 v0.1.3.dev20261030，首次同時包含 #1014（K3 解碼注意力）與 #1015（新 ABI）。
  4. 10-31 13:15，triton-riscv 的 #91 合入，錨點升到 nightly/v0.1.3.dev20261030——三跳鏈條（合入、夜間構建、下游換錨）在本週最後一天打通。
  5. 10-30 23:00，llvm-project 的 riscv 分支再整枝重放一次（25 筆，提交者時間集中在 23:00:40 至 23:00:44）；10-31 03:00，pytorch 的 riscv 分支再整枝重放一次，頭部仍含 [SyncBots] Integrate PyTorch at 3afdbd3。
  6. 10-30 09:54，ruyisdk/ruyi 合併 #508「docs: update vendor naming list」，本週主倉共兩筆提交，仍無新版本。
  7. 10-30 12:39，openRuyi 的 #1514「ollama: Update to 0.40.7」帶 security-fixes 標記合入；同日前另有 clang-wrap 20261030（#1545）等，本週期合計 234 筆。
  8. 論壇 #2897「【轉載】十二年認知，十年展望：包雲崗在 2026 RISC-V 中國峰會縱論開源晶片的中國路徑」（10-29 釋出），本週日報未收，本期補錄。
  9. openRuyi 新聞頁口徑更正：10 月已上線兩篇專題文章（均標註 10-19 釋出），此前「最新仍為 2026.09 釋出公告」的表述有誤；2026.10 月度版本公告仍未出現。

信源核查表

信源 核查結果
RuyiAI-Stack 組織（全倉） pytorch：riscv 分支七日靜默（10-22 至 10-28）、10-29 14:06 整枝重放 11 筆、20:48 SyncBots 抬到上游 3afdbd3，主分支每日約 20 筆全為上游；llvm-project：riscv 分支 10-26、10-27 兩次換基（基線前移 221、237 筆），10-28 補 autorebase 工作流，10-29 重放並新增貢獻指南，上游 17 個 RISC-V pass 遷入 NewPM；triton-riscv：三筆降級修復合入、兩次錨點更新（#90 合入、#91 當日未合入）；tilelang-riscv 第十四日靜默；ruyiai-daily 五期；FBGEMM、cpuinfo、VecIntrinBench、IntrinTrans、torq-tile、pytorch-ci、dsh-osc 無提交
ruyisdk 組織（全倉） ruyi-imager：v1.1.0-rc.1 預釋出（10-29），本週另有 UFS/UEFI、對話方塊互動、術語統一等前序提交；ruyi 主倉兩筆（廠商命名清單文件、合併 #508），無新版本，0.54.0 僅 alpha 標籤；packages-index 一筆（revyos Milk-V Meles 映象與 uboot 抬到 20260504）；support-matrix 三份板卡報告（Jupiter2 Bianbu 4.0.1、K3 Pico-ITX Bianbu 4.0.8 評 good、VisionFive 2 Lite Ubuntu 24.04.5 評 basic）；wechat-articles、ruyisdk-website、docs、AME-operator 無視窗內提交
openRuyi-Project 組織 主倉 234 筆提交、52 筆合併 PR、58 筆開放；分類含 KDE Frameworks 6.31.0 批 64 筆、Samba 全家聯動、12 包安全更新、qemu 11.1.2、libvirt 兩筆、三筆 revert（收回 LLVM IR 分發）、13 個 Go 生態新增包、vkpeak 收錄；標籤止於 2026.09-experimental，2026.10 未發
buddy-compiler 組織 buddy-mlir：VIR 七筆（#1002 至 #1008）、Python 繫結 #1009、buddy-server 原始碼重組 #1010、Whisper x64 CI #1012、K3 解碼注意力 #1014、新 ABI #1015；正式版 0.1.2 與五個夜間版（dev20261026 至 dev20261030）；開放 PR 三筆停更在 10-28（#1011、#1013、#994）
riscv/riscv-arch-test 原 riscv-arch-test 組織路徑已 404，倉庫遷至 riscv 組織；週一視窗（10-23 至 10-25）30 筆提交，以套件合併與 H 擴充套件補齊為主
RuyiSDK 開發者社群論壇 本週五帖：079 期（10-26）、lpi4a UEFI（10-27）、RuyiAI 峰會回顧與香山如意生態大會轉載、包雲崗演講轉載（均 10-29）；080 期未出
openRuyi 發行版新聞頁 10 月兩篇專題文章（均標註 10-19 釋出）；月度釋出公告仍為 2026.09（9-30），2026.10 未發；倉庫標籤止於 2026.09-experimental
ruyi 包管理器 / 標籤 0.53.0 維持，0.54.0 只有 09-18 的 alpha；主分支本週兩筆提交；「10 月底釋出」的承諾截至 10-31 未兌現
ruyi-imager / Releases v1.1.0-rc.1 於 10-29 16:02 釋出（預釋出），含四條互動與 CLI 改動
官方主頁（ruyiai.org） 三頁無變化：首頁索引 3 條、部落格 2 篇、文件 23 章，sha256 與上一期一致
IREE 上游 視窗內提交無 RISC-V 專項改動
arXiv（RISC-V） 全周無新增；最新為 10-27 的 SecDMP 與 TinyML C 程式碼生成器，10-21 的長向量 FlashAttention 仍最貼 RVV
Google News RSS（中英文多組） RuyiSDK、RuyiAI、如意 RISC-V、openRuyi 定向查詢全週五期零命中；同期 RISC-V 新聞與如意社群無關，未收錄

完整信源清單

riscv PR #56 FlagGems 運算元遷移 — https://github.com/RuyiAI-Stack/triton-riscv/pull/56

.com/openRuyi-Project/openRuyi/tags>

ir K3 文件 — https://github.com/buddy-compiler/buddy-mlir/blob/main/docs/K3DeepSeekR1.md

資料來源：每日 RuyiAI 動態報告（2026-10-26 至 2026-10-30 共 5 期）及本週補強核查（組織倉庫、社群雙源、官方主頁）；報告週期為 2026-10-26 至 2026-10-30。