調研視窗：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 官方主頁三頁快照、arXiv 檢索、Google News RSS 中英文定向查詢（走代理）。

本期索引

  • 今日重點：triton-riscv 一日三筆合入，全部源自 FlagGems 運算元遷移暴露的降級缺陷（10-29）
  • 一、RuyiAI 棧進展（PyTorch / Triton / TileLang RISC-V 適配）
    • 1.1 pytorch：riscv 分支第七日靜默結束，整枝重放後抬到上游 3afdbd3（10-29）
    • 1.2 llvm-project：riscv 分支整枝重放，新增貢獻指南並取消預演開關（10-29）
    • 1.3 triton-riscv：三筆降級修復 80 分鐘內合入，依賴更新仍在開放（10-29）
    • 1.4 tilelang-riscv：主分支第十四日靜默（10-29 狀態）
  • 二、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）
  • 三、向量擴充套件、架構測試與運算元最佳化
    • 3.1 向量四倉繼續靜默，基準側缺口仍在（10-29 狀態）
    • 3.2 FlagGems 遷移成了 triton-riscv 的缺陷發現機制（10-29）
    • 3.3 arXiv 視窗內無新增，10-27 兩篇為最新（10-29 狀態）
  • 四、Buddy Compiler 動態
    • 4.1 buddy-server 新 ABI 合入：56 個檔案、模型外掛體系改為統一介面（10-29）
    • 4.2 夜間版 dev20261029 早於 #1015 出包，下游要等下一版（10-29）
    • 4.3 在審三筆停在 10-28，Whisper 與介面對齊均未動（10-29 狀態）
  • 五、社群與活動與官方主頁
    • 5.1 官方主頁三頁無變化，部落格兩篇、文件二十三章（10-29 狀態）
    • 5.2 論壇兩帖：RuyiAI 峰會回顧與香山如意生態大會轉載（10-29）
    • 5.3 ruyiai-daily 一期，情報口徑覆蓋 PyTorch、LLVM、Triton 與 RISC-V（10-29）
    • 5.4 外部新聞零命中，openRuyi 2026.10 與 0.54.0 均未發（10-29 狀態）
  • 六、趨勢觀察
    • 6.1 修復先於驗收：三筆修復靠遷移過程中攢下的問題單，不靠迴歸測試
    • 6.2 分支治理的兩種寫法：llvm 寫規則並取消預演，pytorch 靠整枝重放
    • 6.3 發行版按月鋪量，棧級三件套按月卡審

今日重點：triton-riscv 一日三筆合入，全部源自 FlagGems 運算元遷移暴露的降級缺陷（10-29）

日期：2026-10-29　來源：PR #58、PR #83、PR #82、提交列表

15:38 到 16:58 的 80 分鐘內，triton-riscv 主分支連續合入三筆，作者都是 maochuanjun，改的都是同一層——Triton 到結構化/非結構化 IR 的降級路徑。這在時間上並不尋常：該倉上一筆非依賴更新的程式碼提交是 10-09 的 #86，中間二十天只有 renovate 的夜間版錨點，而這三筆本身分別掛了 82 天、43 天、44 天才合入。

三筆各自對準一個具體缺陷。#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 迴歸。#82（15:38，1 個檔案、+23/−3）修雜湊測試的不確定性：原測試用隨機索引、允許重複目標位，非歸約雜湊下哪個源值勝出都合法，卻拿單一 PyTorch CPU 結果做精確比對；改法把 1D、2D 與原地比對改用唯一目標索引，另加六個重複索引用例（512、1023、1024 三檔長度，原地與非原地各一組），只校驗勝出值來自正確目標的源集合、未命中的目標保持原值。

三筆的動機都寫在 PR 描述裡，且都指向同一處：FlagGems 運算元遷移。#83 服務於 unique_dim 的實現，#58 服務於 broadcast_to（該核心此前為繞開這個誤編譯，把 range(MAX_DIMS) 換成了 tl.static_range），#82 是遷移過程中雜湊運算元比對失敗倒逼出來的測試修正。也就是說，這三筆不是迴歸測試發現的缺陷，而是「把一批 PyTorch 運算元搬到 triton-riscv 上跑」這件事逼出來的缺陷。

驗證強度值得記一筆。#83 明確寫在與 RuyiAI 相關的 riscv64 機器上驗證：新迴歸的三條 RUN/FileCheck 全過，全量 lit 291 透過、9 個預期失敗、0 個意外失敗，張量填充的執行時檢查 18 項透過（覆蓋結構化與 gather 兩條路徑、float32/float64/int64、空掩碼/部分掩碼/全掩碼、負零、NaN 與非法未命中 gather 偏移），與更新後的 unique_dim 整合 23 項透過。#58 只跑了針對性的 TritonToStructured 迴歸，#82 只跑該測試檔案（21 透過）——三筆的驗證深度並不齊平，前兩筆偏區域性、第三筆偏單檔案。

需要剋制的是因果順序：修復先落地，而需要這些修復的遷移 PR #56 仍停在 09-16，開放未合併。這意味著三筆合入後，broadcast_to 裡那個 tl.static_range 繞行可以撤回、unique_dim 可以按原寫法提交，但「整批運算元是否能在 riscv64 上跑通」這個問題本期沒有答案——要等 #56 恢復推進才能驗證。

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

1.1 pytorch：riscv 分支第七日靜默結束，整枝重放後抬到上游 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 又補一筆 [SyncBots] Integrate PyTorch at 3afdbd3，只改 cmake/Dependencies.cmake 一行：KINETO_SOURCE_DIR 的 cache 變數加上 FORCE。改動雖小，含義明確——分支的基線抬到了上游 3afdbd3，且這筆是同步機器人自動生成的，不需要人工判斷。

同時觀察到的錯位：分發側的 python-torch-ruyiai（openRuyi #1352）停在 10-27，本期未動；分支頭部已換成新基線。若該包按分支產物構建，包內鎖定的原始碼落點需要重新對齊一次，這一步目前沒有 PR 在做。七筆開放 PR（#23、#35、#36、#38、#43、#46、#48）的 updated 時間全部是 20:47:49，屬於分支推送觸發的批次重新整理，不能當作內容有更新；其中的 RVV 兩條主線（#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 秒內。重放內容裡有一筆是真的新東西——[workflows] Push rebased PRs directly and document contribution options（作者時間 10-29 09:59），改動兩個檔案：autorebase.yml 刪掉 8 行（去掉 dry_run 輸入與對應的預演分支），新增 82 行的 RISCV_CONTRIBUTING.md。

這份指南把「怎麼往 riscv 分支送東西」寫成了兩條路。路一是先開 issue、由維護者從當前 riscv 切一條 work/issue-NNN 工作分支，貢獻者往工作分支提 PR，維護者整合後併入 riscv——適合多人協作、需要穩定歷史的工作項。路二是直接向 riscv 提 PR，基線一變就手動觸發重基工作流：工作流跑在 PR 源倉庫、用源倉庫的 GITHUB_TOKEN、以 --force-with-lease 帶明確期望 SHA 推回源分支，衝突一律取 riscv 側（含改刪衝突中保留 riscv 側的刪除），等價補丁自動跳過，絕不改寫 riscv 本身、也絕不自動合併。

與上一期那份 244 行工作流相比，最大的變化是預演被取消：上一期預設「只預演不推送」，本期改成「成功即推送，沒有預覽選項」，文件裡也明寫了這一句。這是把摩擦降下來的同時把風險前移——貢獻者本地分支必須及時同步，否則舊基線歷史可能被推回去；文件裡專門有一段提醒儲存未提交工作、避免把舊基線推回遠端。另一處細節值得記下：文件明確說用 GITHUB_TOKEN 推送通常不會觸發後續的 push/PR 工作流，因此更新後的 SHA 上 CI 是否跑過需要人工確認。

1.3 triton-riscv：三筆降級修復 80 分鐘內合入，依賴更新仍在開放（10-29）

日期：2026-10-29　來源：PR #58、PR #83、PR #82、PR #91、PR #56

三筆修復的技術細節已在本期「今日重點」展開，這裡補三條狀態。其一，三筆合入後主分支在視窗內沒有新的程式碼提交，git log 的最新仍停在 #58，說明這是一次集中性清理而不是連續開發。其二，renovate 的 #91 把上游 buddy-mlir 夜間版從 nightly/v0.1.3.dev20261027 抬到 dev20261029（+2/−2，一個檔案），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：主分支第十四日靜默（10-29 狀態）

日期：2026-10-29（狀態）　來源：tilelang-riscv 提交列表、開放 PR 列表

主分支最後一筆提交仍是 10-16 10:52 的「Build Python extension in Buddy CI」，連續第十四日無提交。開放 PR 仍是兩筆：#2 停在 06-16、#4「RVV vector mask and max reduction lowering」停在 09-28，均無視窗內更新。

與 triton-riscv 本期三筆合入形成直接對照：同一組織、同一時期，一條分支在集中清理降級缺陷，另一條完全沒有動作。tilelang-riscv 目前唯一的下游存在感仍來自 openRuyi 的 python-tilelang-ruyiai 規格（#1350 四個補丁），即「以發行版產物代替倉庫迭代」的狀態已延續到第三週。

二、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 筆）翻近三倍，原因很集中：KDE Frameworks 6.31.0 一次性升級鋪了 64 個 kf6-* 包。這一整批在 15:11 的同一分鐘落地（#1513），從 kf6-kcoreaddons、kf6-kconfig 到 kf6-kio、kf6-ksvg、kf6-kwallet，基本覆蓋了 Plasma 6 依賴的框架全集。上一期這筆還標著 WIP、在審佇列裡，一天內翻成合入，說明桌面棧的版本跟隨具備批次重建能力。

其餘合入是常見的版本跟隨與打包修正：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 一分鐘、其餘 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

新增包一筆：vkpeak（#1349，16:38 合入），一個 Vulkan 峰值效能與裝置能力探測工具，對 RISC-V 板卡上的圖形與算力摸底有用，屬於「有硬體、缺測量工具」這一類補齊。打包基礎設施三筆：ecbuild 的 cmake 模組改安裝到 %{_libdir}（#1536），修正此前落到非標準路徑的問題；clang-wrap 跟到 20261029（#1535），保持與上游同日的包裝節奏；python-graphql-core 的 provides 紀元版本修正（#1531）。

另有三筆純依賴圖清理：#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 三件套）本期首次收到程式碼級複核：misaka00251 在 16:19 至 16:24 連發 5 條，全部指向 spec 寫法而不是設計路線——BuildOption(xxx) 之間不必插空行；python-triton-ruyiai 缺 BuildRequires: python3dist(wheel)、Provides 與實際包名要對齊；Conflicts: python-%{srcname} 的必要性需要說明；補丁要用 git format-patch 生成，且同一目錄裡還有一份補丁未被引用；空 %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）約七週。四條變更：映象選擇步驟加入下載動作（#12）、CLI 輸出對齊終端字符集並讓 JSON 保持 UTF-8（#14）、選擇對話方塊雙擊即確認（#19）、選擇對話方塊必須顯式選擇（#21）。四條都是可用性打磨，其中「雙擊確認」與「必須顯式選擇」是一對互補的互動約束，前者提速、後者防誤選。釋出說明還標註了一位首次貢獻者（qingwan12138），四筆裡有三筆來自同一人。同日 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 月倒數第二天，仍無候選版本——按 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.1 向量四倉繼續靜默，基準側缺口仍在（10-29 狀態）

日期：2026-10-29（狀態）　來源：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%」的噪聲，靠板上吞吐做結論本就吃緊；如果 VecIntrinBench 一側繼續不動，後續「最佳化是否真的提升」會長期只能靠人肉對賬。這不是本期新增的問題，但三筆合入把它照得更清楚。

3.2 FlagGems 遷移成了 triton-riscv 的缺陷發現機制（10-29）

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

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

這件事的方法論價值高於三筆修復本身：對一條以 Triton 為入口的 RISC-V AI 棧來說，FlagGems 遷移實際上充當了「端到端驗收集」，比編譯器的 lit 套件更接近真實負載。反過來說，本期也暴露了這個機制的單點依賴——遷移 PR #56 從 09-16 起就沒有更新，三筆修復合入後驗收流程反而停住了。若 #56 長期不推進，這套「缺陷發現機制」會跟著失效，下一批缺陷要等到別的使用者撞上才會被發現。

3.3 arXiv 視窗內無新增，10-27 兩篇為最新（10-29 狀態）

日期：2026-10-29（狀態）　來源：arXiv 檢索

以 RISC-V 加編譯器、向量、MLIR 為條件的檢索，視窗內無新論文。檢索到的最新兩篇都是 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 組的做法屬同一類問題；視窗內沒有後續。

四、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.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 一期，情報口徑覆蓋 PyTorch、LLVM、Triton 與 RISC-V（10-29）

日期：2026-10-29　來源：ruyiai-daily 提交列表、daily-news 2026-10-29

ruyiai-daily 在 10-29 06:42（北京時間）提交一期 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.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 三筆停在 10-28（#1011、#1013、#994），另有 #992、#993、#995、#997、#1001、#924、#928、#932、#838 無視窗內更新；buddy-benchmark、buddy-examples、compiler-eval、FeGen、gemmini、firesim 無視窗內提交
RuyiSDK 開發者社群論壇 視窗內兩帖：#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 釋出（預釋出），含四條互動與 CLI 改動
官方主頁（ruyiai.org） 三頁無變化：首頁索引 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 無關條目均未收錄

完整信源清單

openRuyi/pull/1536>

mpiler/buddy-mlir/pull/994>