調研視窗：2026-10-30 04:30 ~ 2026-11-02 04:30（北京時間，過去 3 天，覆蓋週六週日；與上一期 10-30 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 官方主頁三頁快照、openRuyi 發行版新聞頁、Google News RSS 中英文定向查詢（走代理）。

本期索引

  • 今日重點：Buddy Compiler 0.1.3 出正式版，十六筆提交裡十筆是 RVV 可伸縮向量化，釋出說明只寫了服務端 ABI（10-31）
  • 一、RuyiAI 棧進展（PyTorch / Triton / TileLang RISC-V 適配）
    • 1.1 pytorch：riscv 分支 11-01 凌晨第二次整枝重放，基線仍停在 3afdbd3（11-01）
    • 1.2 llvm-project：riscv 分支 11-01 深夜重放，A100 的 IME/AME 下調在列（11-01）
    • 1.3 triton-riscv：兩筆合入、五筆新開，另有一筆重基到官方 Triton v3.8.0（10-30 至 11-01）
    • 1.4 tilelang-riscv：主分支第十七日靜默，開放 PR 只剩一筆（11-01 狀態）
  • 二、RuyiSDK 工具鏈與發行版
    • 2.1 openRuyi：六筆提交全部落在 10-30，LLVM 23 與 ollama 安全更新合入（10-30）
    • 2.2 openRuyi 在審：Prometheus 依賴批次十三筆，box64 與 firecracker 補進佇列（10-30 至 11-01）
    • 2.3 Ruyiai 三件套 #1350：第二週仍卡在 spec 規範，10-30 有一次重新整理（10-30 狀態）
    • 2.4 ruyi 0.54.0：十月末口徑落空，主分支只合入一筆文件（10-30）
    • 2.5 openRuyi 2026.10 未發，月度發版節奏出現空檔（11-02 狀態）
  • 三、向量擴充套件與運算元最佳化（VecIntrinBench / IntrinTrans / FBGEMM）
    • 3.1 三個向量倉本期全部靜默，最新提交分別停在 02-13、06-25、07-13
    • 3.2 運算元工作面已整體移到 triton-riscv 的降級路徑（10-31 至 11-01）
    • 3.3 效能主線 #85 停在 10-18，與降級路徑的五筆形成節奏反差
  • 四、Buddy Compiler 動態
    • 4.1 BUDDY MLIR 0.1.3：十六筆提交、一百三十六個檔案，說明只寫了 ABI 一項（10-31）
    • 4.2 夜間版與下游錨點：三跳延遲在兩天內閉合，錨點仍在夜間版（10-31）
    • 4.3 三筆在審未進 0.1.3，Whisper 與介面對齊仍懸空（10-31 狀態）
  • 五、社群與活動與官方主頁
    • 5.1 官方主頁三頁無變化，部落格兩篇、文件二十三章（11-02 狀態）
    • 5.2 論壇視窗內無新帖，雙週進展 080 期未出（11-02 狀態）
    • 5.3 ruyiai-daily 兩期，情報口徑覆蓋 PyTorch、Triton 與 KV 快取（10-31、11-01）
    • 5.4 外部新聞零命中，發行版側兩條月度承諾同時到期（11-02 狀態）
  • 六、趨勢觀察
    • 6.1 正式版的說明與程式碼差集脫節，RISC-V 進展被藏在提交歷史裡
    • 6.2 triton-riscv 從「修一筆合一筆」轉向「批次提審」，驗收側仍缺位
    • 6.3 發行版側的月度承諾連續落空，棧級打包仍在 spec 層返工

今日重點：Buddy Compiler 0.1.3 出正式版，十六筆提交裡十筆是 RVV 可伸縮向量化，釋出說明只寫了服務端 ABI（10-31）

日期：2026-10-31　來源：BUDDY MLIR 0.1.3、v0.1.2 與 v0.1.3 的提交差集、PR #999 rvv-vlen、PR #1003 scalable vector 寬度選擇

11-01 07:01（北京時間），buddy-mlir 釋出正式版 0.1.3，上一個正式版是 10-25 的 0.1.2，中間隔了五個夜間版。釋出說明只展開了一項內容：buddy-server 的新 ABI（#1015），即把按模態各寫一套的模型外掛控制代碼收斂成統一介面，外加統一的載入、狀態查詢、呼叫、流式與取消路徑。

但把 v0.1.2 與 v0.1.3 的提交差集拉出來看，這一版實際裝了十六筆提交、一百三十六個檔案，其中十筆是 [midend][VIR] 下一整段 RISC-V 向量化工作：

  • #999 引入 (rvv-vlen)，把可伸縮向量長度作為向量化目標屬性；
  • #1000 在巢狀迴圈裡統計活躍向量數，作為向量寬度選擇的輸入；
  • #1002 讓可伸縮 strip-mining 迴圈按 vscale 步進；
  • #1003 為 RVV 選擇可伸縮向量寬度；
  • #1004 把帶結果的 set_vl 降級成可伸縮向量；
  • #1005 處理 set_vl 中多維動態向量帶結果的情形；
  • #1006 新增動態向量行級 vir.shuffle；
  • #1007 統一 vir.load / vir.store 的索引約定；
  • #1008 自動推導索引向量的寬度；
  • #996 新增 vir.from_vector 並減少重結合。

另有二筆同屬 VIR 線但不在 [midend] 字首下：decode attention 的 VIR 方言實現（[frontend][tools]）與 VIR 的 Python 繫結（#1009）。也就是說，十六筆裡有十二筆動的是向量方言這一層，而發行說明一個字都沒提 RISC-V 或 RVV。

這個落差值得記一筆，因為它改變了「這份棧的 RISC-V 進展在哪裡」這個問題的答案。此前幾期的判斷是：buddy-mlir 的 RISC-V 工作主要走夜間版，正式版被 ABI 重構這類通用工作佔住，下游要拿到 RVV 改動只能錨夜間標籤。0.1.3 證明這條判斷只對了一半——正式版確實把 RVV 那一段收進來了，但版本說明沒有跟著更新，看釋出頁的人會以為 0.1.3 只是一次服務端重構，而實際拿到的是一個可伸縮向量化能力顯著前移的版本。

對下游的直接含義是：triton-riscv 在 10-31 13:15 把依賴錨點抬到了 nightly/v0.1.3.dev20261030（PR #91），這個夜間版的日期早於 0.1.3 正式版的出包時間，但兩者內容同源（0.1.3 從 10-29 的主分支頭部切出），所以 RVV 那十筆已經在下游生效；真正沒跟上的是「錨點仍寫夜間標籤」這件事——按現有的 renovate 節奏，切到 release/v0.1.3 還要再等一輪。

需要剋制的是覆蓋面：這十筆集中在 VIR 方言的可伸縮向量化，即從 set_vl 到 scalable vector 的降級鏈路，不是端到端模型效能資料；釋出說明裡也沒有給出任何基準。向量化能力前移是可核實的，能跑多快這一期沒有答案。

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

1.1 pytorch：riscv 分支 11-01 凌晨第二次整枝重放，基線仍停在 3afdbd3（11-01）

日期：2026-11-01　來源：pytorch riscv 分支、PR #51 riscv64 本地映象、PR #44 bytes_to_scalar 修正、開放 PR 列表

11-01 03:00，riscv 分支做了一次整枝重放：分支上二十筆提交的提交時間被統一改寫到 03:00:26 至 03:00:27 這一兩秒內，作者時間全部保持原樣。頭提交是 1867c9b8，資訊仍是 [SyncBots] Integrate PyTorch at 3afdbd3，而這筆同步提交本身的作者時間是 10-29 12:48——也就是說，這次重放沒有換基線，分支仍停在上游 3afdbd3，與 10-29 那次重放落點相同。

與 10-29 那次相比，差別只在形式：上一期是「七日靜默後重放 + 同步機器人補一筆依賴快取修正」，這一期是「三日後再重放一次、內容不動」。分支上的補丁集也沒有變化，仍是 Add riscv64 image locally (#51)、Fix bytes_to_scalar for float/complex on RISC-V (#44)、Scope linear cross entropy ULP tolerance to RISC-V (#42)、inductor opinfo blocklist (#50) 以及更早的 CI 與測試容差改動。

這種「基線不動、只改提交時間」的重放通常有兩種成因：一是重放到同一基線的不同修補順序上，用來消掉衝突標記或清理歷史；二是自動化任務按週期無條件重放。無論哪種，對本期的內容是零增量，值得記的只有節奏——兩週內兩次整枝重放，且都沒有伴隨新的上游同步。

需要留意的仍是那條錯位：分發側的 python-torch-ruyiai（openRuyi #1352）按分支產物構建，分支頭部每次重放都會換 SHA，包內鎖定的來源落點就得重新對齊；這一期沒有看到對齊動作。

1.2 llvm-project：riscv 分支 11-01 深夜重放，A100 的 IME/AME 下調在列（11-01）

日期：2026-11-01　來源：llvm-project riscv 分支、RISCV_CONTRIBUTING.md、重基工作流

11-01 23:00，riscv 分支同樣做了一次整枝重放，二十六筆分支自有提交的提交時間被統一改寫到 23:00:22 至 23:00:26。頭提交是 afdd0982，內容是 [workflows] Push rebased PRs directly and document contribution options（作者時間 10-29 01:59），即上一期記的那筆「取消預演、新增貢獻指南」的改動——它仍然是分支頭部，本期沒有更新的東西壓在上面。

分支裡與本棧最相關的仍是 A100 那兩筆：[RISCV] Lower IME intrinsics to SpacemiT A100 dot instructions (#30) 與 [RISCV] Add A100 HP/SP and pack/unpack lowering with calibrated scheduling (#31)。前者把 IME 內建函式降到 A100 的點積指令，後者補上 HP/SP 兩種精度形態的 pack/unpack 降級並帶校準後的排程模型；再往下一層是 [AME] Update BOSC AME instructions (#29) 與 [RISCV] Update xtame design (#27)，構成「AME 設計文件 → 指令定義 → 內建函式 → 降級與排程」的完整鏈路。這條鏈路服務於矩陣擴充套件，是 RuyiAI「從 RVV 到 Matrix」敘事在編譯器側的落點。

一處需要下一期複核的不一致：分支上最近一條 [SyncBots] Integrate LLVM at b3b5e33 的作者時間停在 09-29，但把當前頭提交與上一期頭提交做提交比較，返回的差集裡包含 10-30 的上游提交（如 [clang][AST] Don't give NestedNameSpecifier pointer identity in DynTypedNode (#233153)、[libc] Add truncation casts to avoid warnings in file_test.cpp (#237262)）。兩者放在一起只有一種解釋：這次重放在改寫歷史的同時把上游基線前移了，而同步機器人的記錄沒有隨之新增一條。同步記錄與實際基線脫節，會讓「這條分支基於哪個上游」這類判斷只能靠比較介面反推，建議後續在分支上補一條顯式的基線說明。

1.3 triton-riscv：兩筆合入、五筆新開，另有一筆重基到官方 Triton v3.8.0（10-30 至 11-01）

日期：2026-10-30 至 2026-11-01　來源：PR #55 asin 前端補丁、PR #91 依賴更新、PR #92 重基到 Triton v3.8.0、提交列表

主分支在視窗內合入兩筆，都在週末。10-30 20:14，[patches] Support asin op via frontend patch (#55) 合入——這是把 asin 運算元用前端補丁的方式接進來，繞開後端不支援反三角函式的限制，屬於「用一個前端改寫換一個運算元可用」的典型做法。10-31 13:15，renovate 的 #91 把 buddy-mlir 依賴從 nightly/v0.1.3.dev20261029 抬到 dev20261030。此後主分支沒有新的程式碼提交。

真正的變化在 PR 佇列。maochuanjun 在 10-31 15:20 至 11-01 17:36 之間連開五筆，全部落在降級與分析兩層：

  • #93 [Conversion] Preserve scalar load/store masks（10-31 15:20），標量訪存的掩碼保持；
  • #94 [Analysis] Preserve lane offsets in mixed pointers（10-31 21:57），混合指標裡的 lane 偏移保持；
  • #95 [Conversion] Lower tensor gathers（10-31 23:41），張量 gather 的降級；
  • #96 [Analysis] Preserve incomplete tensor masks（11-01 17:29），不完整張量掩碼的保持；
  • #97 [Conversion] Handle stacked zero strides（11-01 17:36），堆疊零步長的處理。

五筆的標題構成很整齊：三筆 Conversion、兩筆 Analysis，且都是「保持某類資訊不丟」的表述。這與 10-29 那三筆修復（張量填充、迴圈攜帶偏移、雜湊測試）是同一個問題族的延續——降級路徑在把 Triton IR 翻成結構化/非結構化形態時，反覆丟掉掩碼、偏移、步長這類邊界資訊，每丟一種就要補一筆。

另有一筆方向不同：#92 [triton] Rebase integration onto the official Triton v3.8.0 release（jason-hue，10-31 12:57 更新）。這不是缺陷修復，而是把整條 RISC-V 整合搬到官方 Triton 3.8.0 上。此前該倉的整合基線停在 [triton] Update integration for latest upstream (#76)（09-02），中間兩個月只做補丁不做重基；#92 一旦合入，後面五筆的落點都要跟著挪一次。這也解釋了為什麼 #92 與 #93 至 #97 同時在佇列裡而沒有被合併成一串——重基是前置動作，先不動。

1.4 tilelang-riscv：主分支第十七日靜默，開放 PR 只剩一筆（11-01 狀態）

日期：2026-11-01（狀態）　來源：tilelang-riscv 提交列表、開放 PR #4

主分支最後一筆提交仍是 10-16 10:52 的「Build Python extension in Buddy CI」，連續第十七日無提交。開放 PR 從兩筆降到一筆，只剩 #4「RVV vector mask and max reduction lowering」（停在 09-28）；此前那筆 #2「Add Codex-compatible RISC-V operator workflow」已不在開放列表中。

同一組織、同一視窗，triton-riscv 在三天裡合入兩筆、開出五筆，tilelang-riscv 一筆沒有。這種分化已經持續三週，不能再用「週末沒人」解釋。從外部能看到的替代路徑只有一條：openRuyi 的 python-tilelang-ruyiai 規格（在 #1350 三件套裡），即以發行版產物代替倉庫迭代——而 #1350 本身還卡在複核。兩條路同時停著，等於這個元件本期沒有任何前進方向。

二、RuyiSDK 工具鏈與發行版

2.1 openRuyi：六筆提交全部落在 10-30，LLVM 23 與 ollama 安全更新合入（10-30）

日期：2026-10-30　來源：PR #1424 LLVM 23、PR #1514 ollama 安全更新、PR #1545 clang-wrap、主倉提交列表

視窗內的六筆提交全部集中在 10-30 一天，之後整個週末零提交。三筆 PR 合入：

11:20 合入 #1424，新增 llvm23 包，版本 23.1.4。這是把 LLVM 23 作為並存包引入，而不是把預設工具鏈整體升上去，對發行版來說是低風險做法：需要新版本的專案顯式依賴 llvm23，其餘仍走原預設，不會因為一次大版本跳躍把所有構建面拖下水。對 RISC-V 側的意義在於工具鏈版本的可選性——此前想測新 LLVM 後端只能自建。

12:39 合入 #1514，ollama 升到 0.40.7 並標 security-fixes。這筆在上一期還掛在在審佇列裡（寫作時 +259/−3371，刪掉的是 vendor 目錄），本期合入，意味著那批安全修復已經進主線。同一分鐘還落了三筆 go 生態包：go-github-tree-sitter-cpp、go-github-tree-sitter-go-tree-sitter、go-github-mattn-go-pointer，都是給已有包補依賴閉包。

17:39 合入 #1545，clang-wrap 跟到 20261030。這個包保持與上游同日節奏已連續多期，屬於發行版裡少數「每天都有事」的規格。

六筆提交裡沒有一筆直接改 RuyiAI 三件套，也就是說發行版這一側本期做的是「把地基往前挪」，而不是「把棧裝進去」。

2.2 openRuyi 在審：Prometheus 依賴批次十三筆，box64 與 firecracker 補進佇列（10-30 至 11-01）

日期：2026-10-30 至 2026-11-01　來源：PR #1561 box64、PR #1559 firecracker、PR #1516 qemu-rustsbi、PR #1562 binutils RISC-V 測試跟蹤、PR #1547 至 #1557 Prometheus 批次

開放佇列在視窗內有二十四筆更新，規模比上一期大，結構化特徵也明顯：

最大一簇是 Prometheus v3.13 的模組依賴批次，共十三筆（#1540、#1441、#1547 至 #1557），全部由同一作者按 DAG 順序分批提交，標題統一為「Add Prometheus v3.13 modules - DAG dependency batch NN」。這種「把一張依賴圖切成十幾筆按層提交」的做法，在發行版裡通常是不得不為之——一次性提交會被審查者要求拆分，而按層拆又能保證每筆可獨立構建驗證。代價是合入視窗被拉長，任何一層卡住後面的都進不去。

第二簇是虛擬化與二進位制翻譯：#1561 新增 box64（在 RISC-V 上跑 x86-64 程式的動態重編譯器）、#1559 新增 firecracker（輕量微虛擬機器）、#1516 新增 qemu-rustsbi（RustSBI 作者 luojia65 提交，已有五條討論）。三筆疊起來看，指向的是同一類需求——在 RISC-V 桌面上跑非原生軟體與隔離負載。

第三類是與 RISC-V 直接相關的維護項：#1562 binutils: Track RISC-V pr19719 test failures，把 binutils 裡一個 RISC-V 相關的已知測試失敗登記成跟蹤項，而不是直接修。這種做法在發行版裡意味著「構建能過、測試不全綠」，對下游用 binutils 做連結的人是有用資訊。

其餘是三筆常規版本跟隨：#1563 把 Node.js 升到 26.13.0 並改用系統庫、#1544 把 firefox 升到 159、#1421 給 qemu 開啟一批 GUI 測試用的特性。

2.3 Ruyiai 三件套 #1350：第二週仍卡在 spec 規範，10-30 有一次重新整理（10-30 狀態）

日期：2026-10-30（狀態）　來源：PR #1350 Add Ruyiai packages、PR #1352 python-torch-ruyiai

#1350（buddy-mlir、python-triton-ruyiai、python-tilelang-ruyiai 三件套）在 10-30 16:16 有一次重新整理，仍未合入，時間線上多出一條 10-30 的記錄。上一期記的十八筆複核意見全部指向 spec 寫法——BuildOption 之間不必插空行、缺 BuildRequires: python3dist(wheel)、Provides 要與實際包名對齊、補丁要用 git format-patch 生成、空的 %check 要寫註釋——這一期沒有新的方向性爭議冒出來。

從 09-21 開到現在，這筆 PR 已經跨過第六週。上一期把它歸因為「從零寫 spec，每個非常規點都要解釋」，本期再看還有一層：三件套裡 buddy-mlir 自帶 LLVM、triton 依賴 git 可執行、tilelang 需要發現 buddy-mlir 工具鏈，三處非常規點在複核裡被分別提出，但沒有一份統一的打包約定文件把它們收在一起。結果是每輪複核都要重新解釋一遍同一批問題，返工成本落在往返而不是寫作上。

同一批裡的 #1352（python-torch-ruyiai）本期沒有動作，仍停在 10-27。它與 1.1 裡 pytorch 分支的重放是同一個懸而未決的問題：分支每次重放都換 SHA，包裡的來源落點要不要跟著改，沒人給出結論。

2.4 ruyi 0.54.0：十月末口徑落空，主分支只合入一筆文件（10-30）

日期：2026-10-30　來源：PR #508 廠商命名清單、ruyi 標籤、ruyi Releases

10-30 09:54，ruyi 主分支合入 #508「docs: update vendor naming list」，給廠商命名文件補上 BananaPi、OrangePi、XiangShan、ZhiheComputing 四個標識。文件側的這次對齊與 ruyi-imager 把介面「製造商」改成「供應商」是同一件事的兩端，避免兩處叫法不一致。

除此之外，0.54.0 的狀態沒有變化：標籤列表裡 0.54.0-alpha.20260918 之後仍無新標籤，正式版最新仍是 09-24 的 0.53.0，主分支自 09-25 起除這筆記文件外無提交。雙週進展 079 期給的口徑是「因發版週期調整改到 10 月底」，今天是 11-02，十月已經過完，這個口徑已經落空，且沒有新的口徑頂上來。

值得注意的是落空的方式：不是發版失敗、不是候選版本回退，而是十月下半月幾乎沒有程式碼動作。#508 是一筆文件改動，意味著 10 月底那段時間主分支上連「為發版做的準備」都很少。這與 0.53.0 之前的節奏不同——那時 alpha、beta、正式版是連續三跳，現在第一跳都沒有。

2.5 openRuyi 2026.10 未發，月度發版節奏出現空檔（11-02 狀態）

日期：2026-11-02（狀態）　來源：openRuyi 新聞頁、openRuyi 主倉

openRuyi 發行版的新聞頁最新一篇仍是「openRuyi 2026.09 釋出」（09-30），2026 年 10 月的發版公告頁返回 404。前四個月的發版日分別是 6-30、7-23、8-27、9-30，雖然不嚴格在同一天，但沒有整月缺版的先例；10 月這一版到 11-02 仍未出現。

這條與 2.4 並讀，構成了本期最值得留意的一組事實：同屬「RuyiSDK 生態分發」的兩條流水線——包管理器 ruyi 與發行版 openRuyi——在同一個十月末各自錯過了一次公開的月度承諾，而兩條線的程式碼側都不算停滯（openRuyi 主倉 10-30 還有六筆提交，ruyi 有文件合入）。這說明卡點不在開發，在發版本身：版本凍結、公告撰寫、映象構建與釋出流程，這一段在近兩個月都沒有按期跑通。

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

3.1 三個向量倉本期全部靜默，最新提交分別停在 02-13、06-25、07-13

日期：2026-11-01（狀態）　來源：VecIntrinBench、IntrinTrans、FBGEMM

組織內三個以「向量」為主題的倉庫本期都沒有視窗內提交，且它們的最新提交時間分佈在三個不同的季度：VecIntrinBench 停在 02-13，IntrinTrans 停在 06-25，FBGEMM 停在 07-13。三者分別是向量內建函式基準、內建函式翻譯、量化運算元後端，原本構成「測什麼、怎麼翻、運算元怎麼實現」的三角。

這個三角現在整體停擺，且停的時間點各不相同，說明不是一次統一的專案終止，而是各自自然冷卻。VecIntrinBench 停了近九個月是最值得說明的一處——一個向量內建函式基準庫如果長期不更新，它測到的覆蓋率就與編譯器實際支援的集合越差越遠。

3.2 運算元工作面已整體移到 triton-riscv 的降級路徑（10-31 至 11-01）

日期：2026-10-31 至 2026-11-01　來源：PR #93、PR #94、PR #95、PR #96、PR #97

既然三個專用倉都停了，運算元層的實際工作面只能從 triton-riscv 的 PR 佇列看。本期五筆新開的 PR 全部圍繞「資訊保持」，逐筆拆開是這樣：

#93 處理標量 load/store 的掩碼——標量訪存路徑在降級時最容易把掩碼當成常量真值丟掉，一旦丟掉，帶條件的標量讀寫在結構化 IR 裡就變成無條件，越界訪問不會報錯而是讀到髒資料。#94 處理混合指標裡的 lane 偏移，即一個指標表示式裡既有基址又有逐 lane 偏移時，分析階段只保留基址、把偏移當常數；#96 處理不完整的張量掩碼，即掩碼形狀小於張量形狀時的廣播語義；#97 處理堆疊零步長，即多個維度都為零步長時降級後可能被摺疊成一個維度。

#95 是唯一一筆「新增能力」而非「保持資訊」的：把張量 gather 降級出來。此前 gather 只能走非結構化路徑，結構化路徑沒有對應實現，#95 補的是這條缺失。

五筆的共同背景是同一件事：這一層的正確性靠「把真實運算元搬上來跑」暴露，而不是靠迴歸測試。三週裡累積的八筆（10-29 三筆 + 本期五筆）都屬這一類。這套機制有效，但成本高——每搬一批運算元就要修一串邊界情況，且修完的驗證強度參差（10-29 那三筆裡，一筆跑了全量 lit 291 項，一筆只跑針對性迴歸，一筆只跑單檔案）。

3.3 效能主線 #85 停在 10-18，與降級路徑的五筆形成節奏反差

日期：2026-10-18（狀態）　來源：PR #85 softmax 與 matmul 最佳化

#85「softmax 及 matmul 最佳化」自 10-18 23:55 之後沒有更新，本期仍停在原位。這是該倉唯一一條明確以效能為目標的開放 PR，與降級路徑的五筆構成清晰反差：正確性方向一週能提五筆，效能方向半個月沒有動靜。

對一個要「跑真實模型」的棧來說，這個反差有具體後果：掩碼、偏移、步長這些正確性修復決定「能不能算對」，softmax 與 matmul 的最佳化決定「算得夠不夠快」。前者在快速推進，後者停著，意味著即使把 604 個運算元全部搬通，端到端效能也還停在三週前的水平。

四、Buddy Compiler 動態

4.1 BUDDY MLIR 0.1.3：十六筆提交、一百三十六個檔案，說明只寫了 ABI 一項（10-31）

日期：2026-10-31　來源：BUDDY MLIR 0.1.3、提交差集 v0.1.2…v0.1.3、PR #1015 buddy-server 新 ABI、PR #1009 VIR Python 繫結

0.1.3 的提交差集與「今日重點」裡已展開的內容互為印證，這裡補三點不在重點裡的觀察。

其一，這一版的檔案面比提交數更大：十六筆提交動了 136 個檔案，其中相當一部分來自 #1015 的介面重構（新增四個執行時標頭檔案、刪除四組按模態寫的外掛控制代碼與對應單測）。也就是說 0.1.3 同時裝了兩件事——向量方言的十筆連續推進，與一次跨七十餘個檔案的外掛體系收斂——兩件事在時間上重疊（VIR 十筆在 10-25 至 10-27，#1015 在 10-29），在評審上卻是分開走的。

其二，[frontend][tools] Implement the decode attention in the VIR dialect 這筆容易被忽略，但它指向的方向與前面的 VIR 降級不同：把 decode attention 寫成 VIR 方言裡的實現，等於給「注意力解碼」這個具體負載建了一條從方言到向量化的直通路。這是 VIR 從「通用向量方言」走向「按負載最佳化」的第一筆。

其三，VIR 的 Python 繫結（#1009）意味著這套方言可以被 Python 側構造與檢查，對下游的直接好處是 triton-riscv 一類專案可以在 Python 層生成 VIR 做單元驗證，而不必每次走完整編譯鏈。

4.2 夜間版與下游錨點：三跳延遲在兩天內閉合，錨點仍在夜間版（10-31）

日期：2026-10-31　來源：夜間版 dev20261030、triton-riscv PR #91、Releases 列表

上一期記過一條固定延遲結構：buddy-mlir 合入 → 次日夜間構建 → renovate 提出依賴更新 → triton-riscv 合入，三跳通常一到兩天。這一期這條鏈完整跑通了一次，可以核對每一步的實際耗時：

#1015 在 10-29 15:08 合入主分支；夜間版 dev20261030 在 10-30 08:49 出包（含 #1015）；renovate 的 #91 在 10-31 13:15 合入 triton-riscv。從合入到下游拿到，總共兩天零五分鐘，與「一到兩天」的估計相符。

但錨點的形態沒變：triton-riscv 依賴的仍是夜間標籤 nightly/v0.1.3.dev20261030，而不是 10-31 23:01 出的正式版 release/v0.1.3。兩個標籤的內容同源（0.1.3 從 10-29 主分支頭部切出，dev20261030 也是），差別在可復現性——夜間標籤會被後續構建覆蓋引用，正式標籤不會。對一個要進發行版的棧來說，長期錨夜間版意味著包內鎖定的來源不可長期復現，這與 2.3 裡「補丁要用 git format-patch 生成」屬同一類訴求。

4.3 三筆在審未進 0.1.3，Whisper 與介面對齊仍懸空（10-31 狀態）

日期：2026-10-31（狀態）　來源：PR #1011、PR #1013、PR #994、開放 PR 列表

0.1.3 的十六筆提交裡沒有 #1011、#1013、#994 三筆，說明它們仍未被收進正式版本。三筆的性質分別是：#1011 把可伸縮 VIR 片段的計數強制轉 int64（與本期 VIR 十筆同屬向量寬度這條線）、#1013 讓 Whisper 單次轉寫內複用預處理、#994 把 buddy-server 介面向 llama-server 對齊。

三筆裡最尷尬的是 #994：它想對齊的 llama-server 介面，正好是 #1015 重構掉的那一層。0.1.3 已經把按模態拆分的外掛控制代碼收斂成統一 ABI，#994 若按原方向合併，等於在一個剛被重寫的介面上再疊一層相容層。PR 裡沒有討論這個衝突，這一期也沒有看到它被關閉或改向——它現在的狀態是「既不在版本里，也沒有被否掉」。

#1011 的處境類似但方向相反：它是向量寬度這條線的收尾項，而同期十筆 VIR 工作已經進了 0.1.3。收尾項落在版本外面，意味著 0.1.3 的可伸縮向量化在「片段計數超過 32 位」這個邊界上仍未有定論。

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

5.1 官方主頁三頁無變化，部落格兩篇、文件二十三章（11-02 狀態）

日期：2026-11-02（狀態）　來源：RuyiAI 官方主頁、部落格索引、文件索引

官方主頁三頁在視窗內均無變化，快照雜湊與上一期一致：首頁索引 3 條，部落格索引 2 篇（「Triton 的 RISC-V 適配」與「PyTorch RISC-V CI 實踐」），文件 23 章。這一狀態已連續保持多期，本期沒有新增文章或章節。

與 4.1 對照看，這個靜默有點特殊：0.1.3 裡那十筆 RVV 向量化工作是近三個月裡最成體系的一段進展，部落格側卻沒有對應的解讀文章。官網部落格的兩篇都是「適配實踐」類，缺的正是「向量化能力到哪一步」這類階段性說明。

5.2 論壇視窗內無新帖，雙週進展 080 期未出（11-02 狀態）

日期：2026-11-02（狀態）　來源：RuyiSDK 開發者社群、帖 #2899、雙週進展 079 期 #2895

論壇在視窗內沒有新帖，最新一帖仍是 10-29 的 #2899（RuyiAI 亮相第六屆 RISC-V 中國峰會），該條已在上一期收錄。上一篇正式彙報是 10-26 的 079 期，080 期按雙週節奏應在 11 月上旬釋出，本期尚未出現。

需要說明的是論壇的活躍度分佈：10-29 三帖（#2897 至 #2899）全是峰會相關內容，之後四天零帖。峰會話題已經把十月底的討論額度用完，下一波要等 080 期。

5.3 ruyiai-daily 兩期，情報口徑覆蓋 PyTorch、Triton 與 KV 快取（10-31、11-01）

日期：2026-10-31、2026-11-01　來源：ruyiai-daily

每日情報倉在視窗內提交兩期（daily-news: 2026-10-31 與 daily-news: 2026-11-01），仍是每天 22:20 至 22:40 之間的固定節奏。11-02 那一期按其釋出習慣要到當日夜間才出現，視窗內沒有。

這兩期是本報告的交叉核對源之一：其中關於 PyTorch 上游同步、Triton 降級路徑的條目與本報告 1.1、1.3 的判斷一致，沒有出現口徑衝突。

5.4 外部新聞零命中，發行版側兩條月度承諾同時到期（11-02 狀態）

日期：2026-11-02（狀態）　來源：Google News RSS、openRuyi 新聞頁

RuyiSDK、RuyiAI、openRuyi 三組中英文定向查詢在視窗內零命中。中文側唯一帶「如意」的結果仍是 10-25 的峰會參展報道（奕行智慧），落在視窗外且與如意社群無關；「openRuyi」的英文查詢只返回一條四月的舊文。

外部沒有報道，與 2.4、2.5 的觀察並不衝突——兩條月度承諾落空都屬於「沒有發生的事」，本來就不會有新聞。真正說明問題的是內部訊號：包管理器與發行版同時錯過十月的發版視窗，而兩條線的程式碼側都還在動。

六、趨勢觀察

6.1 正式版的說明與程式碼差集脫節，RISC-V 進展被藏在提交歷史裡

0.1.3 這件事的方法論意義大於它本身：一個專案的「對外說明」與「實際裝進去的東西」如果長期不一致，外部對它的判斷就只能靠提交歷史反推。這一期的具體表現是，釋出說明只寫了服務端 ABI 重構，而十六筆提交裡十二筆動的是 VIR 向量層。

這種脫節有慣性代價。對下游而言，判斷「要不要升級」需要同時看 release notes、提交差集與依賴錨點三處；對上游而言，真正想被看見的工作沒有出現在該出現的頁面上——近三個月最成體系的向量化進展，在部落格、文件、發行說明三處都沒有對應描述。一個以「RVV 到 Matrix」為敘事的棧，把向量化進展寫成提交歷史裡的十行標題，是一種浪費。

更實際的風險在評審側：如果版本說明只覆蓋一部分改動，那麼複核者的注意力也會集中在那一部分，另一部分改動在「已經被裝進正式版」之後就不再有人回頭看了。

6.2 triton-riscv 從「修一筆合一筆」轉向「批次提審」，驗收側仍缺位

10-29 那三筆是「80 分鐘內連續合入」，本期五筆是「兩天內連續開出、尚未合入」。前者說明維護者對明確的缺陷修復有快速通道，後者說明新一批改動還沒走到那一步。兩種節奏之間的差別不在開發強度，而在評審頻寬。

這五筆加上 10-29 的三筆，三週裡累積八筆同類修復，全部指向降級路徑的資訊丟失。這個數量本身是訊號：說明這條路徑沒有建立起系統性的等價性檢查，只能靠逐個運算元撞、逐個撞完補。而對下游最有價值的一件事——把 FlagGems 那 604 個運算元的匯出做成每晚跑一次的常駐迴歸——仍然沒有做。PR #56 雖然從 09-16 的停滯裡恢復（10-30 20:50 有一次推送，規模已擴充套件到 156 個新檔案、匯出條目從 468 到 604），但它仍是開放狀態。

只要驗收還在 PR 裡而不在流水線裡，「這批運算元能不能在 riscv64 上跑通」這個問題就會反覆被推遲。

6.3 發行版側的月度承諾連續落空，棧級打包仍在 spec 層返工

十月的最後三天裡，兩條與「分發」直接相關的線同時錯過了視窗：ruyi 0.54.0 的「10 月底」口徑落空，openRuyi 的 2026.10 版本到 11-02 未發。兩條線的程式碼側都不算停——openRuyi 在 10-30 還有六筆提交，ruyi 有一筆文件合入——所以卡點在發版流程本身，而不在開發。

與此同時，棧級的三件套 #1350 已經跨過第六週，仍在 spec 規範層面返工。這三件事放在一起，指向同一個結構性問題：這個生態的「把東西做出來」與「把東西發出去」是兩套能力，前者在多個倉庫同時推進，後者在近兩個月裡沒有一次按期完成。

對 RuyiAI 而言，短期最實際的建議不是催發版，而是把 2.3 裡那三處非常規點（buddy-mlir 自帶 LLVM、triton 依賴 git、tilelang 需要工具鏈發現）寫成一份打包約定，讓 #1350 的複核不必每週重新討論同一批問題——把往返成本降下來，才談得上進入月度發行節奏。

信源核查表

信源 核查結果
RuyiAI-Stack 組織（全倉） pytorch：riscv 分支 11-01 03:00 第二次整枝重放二十筆，頭提交 1867c9b8、基線仍為 3afdbd3，無新增補丁；llvm-project：riscv 分支 11-01 23:00 重放二十六筆，A100 的 IME/AME 下調（#30、#31）在列，比較介面顯示上游基線已含 10-30 提交；triton-riscv：兩筆合入（#55、#91）、五筆新開（#93 至 #97）、一筆重基（#92）、#56 於 10-30 20:50 恢復推送；tilelang-riscv 第十七日靜默，開放 PR 僅剩 #4；VecIntrinBench、IntrinTrans、FBGEMM、harness、cpuinfo、torq-tile、pytorch-ci、dsh-osc、skills、caffe、mxnet 無視窗內提交
ruyisdk 組織（全倉） ruyi 主倉：1 筆提交（#508 廠商命名清單），無新 Release，0.54.0 仍只有 09-18 的 alpha 標籤，正式版維持 0.53.0；packages-index、support-matrix、docs、ruyisdk-website、ruyi-imager、wechat-articles、attached-matrix-extension、ruyici、AME-operator 無視窗內提交
openRuyi-Project 組織 主倉 6 筆提交（全部在 10-30）＋ 3 筆 PR 合入（#1424 LLVM 23、#1514 ollama 0.40.7、#1545 clang-wrap 20261030）；開放 PR 24 筆有視窗內活動（Prometheus 批次 13 筆、#1561 box64、#1559 firecracker、#1516 qemu-rustsbi、#1562 binutils RISC-V 測試跟蹤、#1563 Node.js、#1544 firefox、#1421 qemu GUI、#1350 Ruyiai 三件套）；2026.10 版本未發，發版頁 404
buddy-compiler 組織 buddy-mlir：正式版 0.1.3 於 10-31 23:01 UTC 釋出（v0.1.2 至 v0.1.3 共 16 筆提交、136 個檔案，其中 10 筆為 [midend][VIR] RVV 向量化）＋ 夜間版 dev20261030；主分支視窗內無提交（最新 10-29 07:08）；#1011、#1013、#994 未進 0.1.3
RuyiSDK 開發者社群論壇 視窗內無新帖，最新仍為 10-29 的 #2899；雙週進展 079 期（10-26）為最近正式彙報，080 期未出
openRuyi 發行版新聞頁 無新文，2026.09 釋出公告（09-30）仍為最新；2026-10 與 2026-11 的發版路徑均返回 404
ruyi 包管理器 / Releases 0.53.0 維持，無新 alpha 或 beta（0.54.0-alpha.20260918 仍為最近一版）；主分支僅一筆文件提交
官方主頁（ruyiai.org） 三頁無變化：首頁索引 3 條、部落格 2 篇、文件 23 章，快照雜湊與上一期一致
ruyiai-daily 視窗內兩期（10-31、11-01），口徑與本報告一致
Google News RSS（中英文多組） RuyiSDK、RuyiAI、openRuyi、如意 RISC-V 定向查詢零命中；「如意」側最新為 10-25 的峰會參展報道，落在視窗外且與如意社群無關，未收錄

完整信源清單

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

l/1011>