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

本期索引

  • 今日重點：K3 解碼注意力搬上 VIR，效能與手寫 RVV 核心持平（10-28）
  • 一、RuyiAI 棧進展（PyTorch / Triton / TileLang RISC-V 適配）
    • 1.1 llvm-project：不再換基，補上「作者 fork 一鍵重基」工作流（10-28）
    • 1.2 pytorch：riscv 分支第七日靜默，主分支二十筆仍是上游（10-28 狀態）
    • 1.3 triton-riscv：錨點再抬一級，riscv64 三條 CI 排隊未回（10-28）
    • 1.4 tilelang-riscv：主分支第十三日靜默（10-28 狀態）
  • 二、RuyiSDK 工具鏈與發行版
    • 2.1 openRuyi PR #1350：三筆提交重基，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 狀態）
  • 三、向量擴充套件、架構測試與運算元最佳化
    • 3.1 向量倉與 FBGEMM 三倉靜默，cpuinfo 停在 05-20（10-28 狀態）
    • 3.2 向量寬度口徑：VIR 側定為 1024 位、單頭一個 LMUL 4 組（10-28）
    • 3.3 arXiv 視窗內無新增，10-21 的長向量 FlashAttention 仍最貼 RVV（10-28 狀態）
  • 四、Buddy Compiler 動態
    • 4.1 K3 解碼注意力搬上 VIR：數值位級一致，K3 實測吞吐落在同一區間（10-28）
    • 4.2 buddy-server 原始碼重組、Whisper 示例進 x64 CI（10-28）
    • 4.3 在審四筆：int64 強制轉換、Whisper 預處理複用、新 ABI、對齊 llama-server（10-28 狀態）
    • 4.4 夜間版 dev20261028 出包，仍不含當日三筆（10-28）
  • 五、社群與活動與官方主頁
    • 5.1 官方主頁三頁無變化，部落格兩篇、文件二十三章（10-28 狀態）
    • 5.2 論壇視窗內無新帖；補錄 10-27 的 LPi4A UEFI 實測帖（10-27）
    • 5.3 ruyiai-daily 一期，ruyi-imager 把「製造商」改成「供應商」（10-28）
    • 5.4 外部新聞零命中，openRuyi 2026.10 與 0.54.0 均未發（10-28 狀態）
  • 六、趨勢觀察
    • 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 lanes），每個頭是一個由 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），把「作者 fork 上的 PR 跟不上基線」這件事從手工搬進 Actions。二是 triton-riscv 的依賴錨點被 renovate 再抬一級到 dev20261028（詳見 1.3），但這版夜間構建的出包時間早於當日上午三筆合入，所以即便這筆依賴更新合入，下游也還拿不到 #1014——要用上今天的成果，得等下一版夜間構建。

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

1.1 llvm-project：不再換基，補上「作者 fork 一鍵重基」工作流（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，兩個輸入——PR 號（必填）與「只預演不推送」（預設開啟）。執行環境 ubuntu-24.04、超時 90 分鐘；註釋明確要求「絕不在持有寫許可權的情況下執行 PR 程式碼、鉤子、構建或子模組」，git 配置裡把 hooksPath、attributesFile、fsmonitor 全部指到 /dev/null，GIT_TERMINAL_PROMPT=0、GIT_EDITOR=true。衝突處理有專門函式：-Xours 處理不了的場景（含改刪衝突）逐個走 ls-files --unmerged，有第 2 階段就取本地、沒有就刪除；重基時先判斷基線是否已是祖先，能識別「等價補丁」並丟棄重複的舊基線補丁。

這筆要解決的是過去幾期反覆出現的一個具體成本：分支一天整枝重放一次，作者 fork 上的 PR 立刻落後，靠人工逐個重放既慢又容易把補丁集弄亂。需要說清邊界——它重基的是別人的 PR，分支自身每日整枝重放仍需維護者操作；它把「跟隨基線」的成本從人工判斷降為一次帶預演的排程，但並沒有自動化的觸發條件。真正的價值要等下一個外部 PR 按新基線提交時才能驗證。

1.2 pytorch：riscv 分支第七日靜默，主分支二十筆仍是上游（10-28 狀態）

日期：2026-10-28（狀態）　來源：pytorch riscv 分支、pytorch 主分支

riscv 分支頭部仍是 10-22 03:00（北京時間）的「Add riscv64 image locally (#51)」，10-22 至 10-28 連續第七日零提交。RVV 能力上行的兩條主線提案（#46 面向 ATen 的向量擴充套件支援、#48 的 RISC-V Vector CPU 能力）本期仍無更新。

主分支同期 20 筆，全部是上游同步，無一筆涉及 RISC-V：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 三條 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）。與上一筆的差別在於它沒有自動合入：到視窗結束時這筆 PR 仍處開放狀態，可合併狀態為 unstable。

八項檢查裡六項已回：x64 的 3.12、3.13、3.14 三檔全部成功，pre-commit 與 clang-format 成功；riscv64 的 3.12 自 18:54 起處於執行中，3.13、3.14 自開出起一直在排隊。同一倉庫上一筆（#90）是開出後數分鐘內自動合入的，本期這一筆的差別就落在 riscv64 側的執行佇列上——這屬於基礎設施節奏，不是依賴本身有問題。

還有一層時間賬要說清：dev20261028 這個夜間版的構建桶早於當日上午的三筆合入（#1010 08:54、#1014 09:36、#1012 09:55），所以這一版帶不到 K3 解碼注意力。下游要拿到 #1014 的成果，得等下一版夜間構建 + 再一筆依賴更新，最快也要一個構建週期。

1.4 tilelang-riscv：主分支第十三日靜默（10-28 狀態）

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

主分支最後一筆提交仍是 10-16 10:52，連續第十三日無提交；開放 PR #4 停更在 09-28。倉庫側的靜默與 triton-riscv 側形成對照：後者至少在跟依賴，前者連依賴更新都沒有動作。

唯一的進展仍在分發側。#1350 裡的 python-tilelang-ruyiai 規格本期隨整筆 PR 重基（詳見 2.1），仍是 4 個補丁：放寬 Apache TVM FFI 0.1.10、改用系統構建依賴、發現 buddy-mlir 工具鏈、跳過 z3 soname 重寫。倉庫停滯、包在推進，這種「以發行版產物代替倉庫迭代」的狀態已持續近兩週。

二、RuyiSDK 工具鏈與發行版

2.1 openRuyi PR #1350：三筆提交重基，GCC 構建代價量化為 2.81 倍（10-28）

日期：2026-10-28　來源：openRuyi PR #1350、複核評論、PR 提交列表

16:22，RuyiAI 三件套打包 PR 的三筆提交（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.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 八筆、Ruoqing He 四筆、Sun Yuechi 四筆、Jingiw 三筆、Zheng Junjie 三筆、Kimmy 兩筆，cl2t、Julian Zhu、YunQiang Su 各一筆。所有提交集中在 11:20 至 20:49 之間，此後到視窗結束無新提交。規模較上期（45 筆）明顯收斂，性質也從「發版前清掃」轉向常規跟隨。

虛擬化一側是本期最完整的一組。qemu 由 11.1.x 升到 11.1.2（#1520，13:28 合入），上一期還在「在審佇列」裡，一天內落地。libvirt 兩筆合入（#1519，09:47）：一是隨包分發 /var/lib/libvirt/secrets，讓 virt-secret-init-encryption 需要的目錄存在、virtsecretd 才能起；二是回移 Ceph 21 移除 auth_supported 後導致 rbd 池失效的修復。這兩筆都是「能裝上但跑不起來」類問題的補丁，屬於發行版質量的硬指標。

打包基礎設施一側同樣有內容。%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 的後設資料這兩條對 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 四個 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）三筆在 20:03 至 21:27 之間集中重新整理。qemu-rustsbi（#1516）有兩條討論，屬把 Rust 寫的 SBI 引入虛擬化棧的前置工作。其餘為 vkpeak（#1349）與 Prometheus v3.13 模組（#1441）。

2.4 ruyisdk：0.54.0 仍未發，包清單與支援矩陣靜默，安裝器改介面術語（10-28 狀態）

日期：2026-10-28（狀態）　來源：ruyi Releases、packages-index、support-matrix、ruyi-imager 提交 a87b8dd9

包管理器 ruyi 主分支自 09-25 無提交，Release 最新仍是 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.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 分段、單頭一個 LMUL 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 行。

技術要點已在「今日重點」展開，這裡只補三條可複核的細節。其一，PR 明確說這是把已關閉的 #998 重做一遍，重做的基礎是此後四筆：按活躍度定尺寸（#1000）、行（#1005）、vir.shuffle（#1006）、Python 繫結（#1009）——也就是說，這不是一次獨立最佳化，而是把前四筆的地基一次性壓測。其二，驗證做得比較硬：測試對 _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 單板、貪心解碼、三段序列長度上得到的，作者也註明同一份程式碼兩次構建可差 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、協議、外掛三塊分組，測試按單元、整合、打包、夾具分目錄；引入 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 在審四筆：int64 強制轉換、Whisper 預處理複用、新 ABI、對齊 llama-server（10-28 狀態）

日期：2026-10-28（狀態）　來源：PR #1011、PR #1013、PR #1015、PR #994

開放 PR 四筆在視窗內有更新。#1011 是編譯修復：倉庫釘住的 Clang/LLVM 版本下，divideCeil 返回無符號值，聚合初始化把它塞進 int64 的欄位會窄化報錯，改法顯式轉換，除法、向量寬度、掩碼與佈局都不動（+4/−4，一個檔案）——這筆雖小，卻是 #1012 能跑通的前提。#1013 在 16:01 重新整理，複用 Whisper 的預處理結果以減少重複計算。#1015 在 22:53 重新整理，給 buddy-server 換新 ABI。#994 在 15:35 重新整理，把 buddy-server 的介面向 llama-server 對齊，是最早提出這條對齊方向的一筆，至今仍未合入。

4.4 夜間版 dev20261028 出包，仍不含當日三筆（10-28）

日期：2026-10-28　來源：夜間版 dev20261028、Releases 列表

夜間版在 07:56 釋出（v0.1.3.dev20261028）。出包時間早於當日上午的三筆合入（#1010 08:54、#1014 09:36、#1012 09:55），因此這一版不含 K3 解碼注意力、也不含 buddy-server 重組與 Whisper CI。0.1.3 線已連續四個夜間版沒有正式版（最近正式版是 10-25 的 0.1.2），下一版夜間構建才是 #1014 進入下游的第一站。

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

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

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

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

這一側與工程側的落差本期更加明顯：同一天裡有 VIR 承載真實模型核心、有 llvm 分支補上重基工作流、有發行版 15 筆合入，官方內容頁卻仍停在 9 月的兩篇文章。#1014 的 K3 實測資料（板上吞吐、指令數、位級一致）本身就是一篇現成的技術博文素材，目前只存在於 PR 描述與倉庫文件裡。

5.2 論壇視窗內無新帖；補錄 10-27 的 LPi4A UEFI 實測帖（10-27）

日期：2026-10-27　來源：lpi4a UEFI #2896、RuyiSDK 開發者社群

論壇視窗內無新帖，最新一帖仍是 10-27 的 #2896。這裡要更正一處：上一期把論壇狀態寫成「最新兩條停在 10-22 的峰會回顧與課程講義」，漏了 10-26 的雙週進展 #2895（該條已在 10-27 期覆蓋）與 10-27 的 #2896，後者在兩個視窗之間被跳過，本期補錄。

#2896 題為「lpi4a UEFI」，10-27 10:45 由 lzzhzh 釋出，附六張截圖與實拍：三張 1366×768 的系統截圖、三張 1920×1440 的實拍照片。正文說 9 月 26 日就發現有更新，忍了一個月才刷 LPi4A，雖然目前還沒有匹配 UEFI 的 RevyOS 可用，「但至少有個希望」。Yuxi 回了一句「可以可以」。這條的價值在於它記錄了 LPi4A 韌體生態的一個真實卡點：UEFI 韌體已可刷入，但配套發行版映象尚未跟上——這正是支援矩陣（support-matrix）應當收錄、但目前視窗內無提交的那類狀態。

5.3 ruyiai-daily 一期，ruyi-imager 把「製造商」改成「供應商」（10-28）

日期：2026-10-28　來源：ruyiai-daily、ruyi-imager 提交 a87b8dd9

ruyiai-daily 在 06:22 提交「daily-news: 2026-10-28」一期，延續按日歸檔的情報動態。

ruyi-imager 在 15:46 提交一筆，把介面裡的「製造商」標籤統一改為「供應商」。改動很小，但方向明確：安裝器面向的是板卡供應方而非晶片製造方，措辭按實際語義收口。其餘倉庫視窗內無提交——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」返回的結果最新一條是 10-25 的峰會參展報道（奕行智慧），落在視窗之外且與如意社群無關，本期不收錄。

發行版側兩個版本仍在視窗外。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 月版大機率落在本月底；距月末兩天，下一期是核實這件事的最後一班。

六、趨勢觀察

6.1 從「能表達」到「跑得一樣快」：VIR 第一次拿真實模型核心做效能對賬

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

但要判斷這條棧是否真的可替代手寫核心，還缺兩件事。一是覆蓋面：這次只搬瞭解碼注意力，A210 核心仍用舊函式，MoE、量化與預填充路徑都還沒動；二是可伸縮向量：本期明確關掉了 use-scalable，下一筆開啟之後，向量尺寸不再由編譯期決定，LMUL 4 的分組假設會鬆動，屆時數值與指令數能不能守住，需要重新對賬。在此之前，把「VIR 已追平手寫核心」當成結論都過早，準確說法是「在 K3 解碼注意力這一段、在固定向量長度下追平」。

6.2 換基的成本從補丁漂移轉向治理：工作流接管重基，分支自身仍靠人

同一天裡，llvm 的 riscv 分支停止整枝重放，改為補一份 244 行的自動重基工作流。這個轉向值得單獨記一筆：過去五天的節奏是「一天一次整枝重放、每次重寫二十筆提交流」，作者時間不動、committer 時間統一，補丁集本身沒有新增功能。這種做法能跟住上游，但代價是外部貢獻者的 PR 永遠落後一格，誰要提交就得自己重放。

新工作流把這件事做成了「填 PR 號、預設預演、一鍵推送」的排程，衝突一律取 riscv 側、重複補丁自動丟棄、絕不執行 PR 程式碼與構建。它不解決分支自身的每日跟隨，但把「跟隨基線的成本」從維護者的手工判斷裡分出來一部分。下一階段要觀察的是外部 PR 是否真的因此變多——如果工作流上線後兩週內仍無外部 PR 按新基線提交，那說明瓶頸不在重基工具，而在別處。

6.3 分發層的爭論開始有價格：2.81 倍的構建時間比「偏好」更有說服力

#1350 爭論了將近一個月，核心分歧是 buddy-mlir 自帶的 LLVM 要不要外接。上一期的口徑還是「可以用 GCC，但至少 1.5 倍時間」，本期作者給出了實測：riscv64 上 8814 秒變 24798 秒，2.81 倍，且用 GCC 那次連結失敗沒跑完。爭論的性質於是變了——從技術偏好變成構建農場的排期算術。

這條對 RuyiAI 棧的啟示不在結論，而在方法：RISC-V 發行版打包的很多分歧（是否 vendor、是否外接工具鏈、是否隨包分發 IR），最終都要落到「構建時間、映象體積、可復現性」這三個可測的數字上。上一期 openRuyi 收回「隨包分發 LLVM IR」的路線，本期 #1350 用 2.81 倍守住「LLVM 留在包內」，兩次判斷方向相反，但依據是同一類成本核算。接下來的看點是這筆 PR 能否帶著這個數字合入——如果不能，說明發行版對構建時長的容忍度低於作者預期，那才是真正需要調整的地方。

信源核查表

信源 核查結果
RuyiAI-Stack 組織（全倉） llvm-project：riscv 分支 1 筆新增（cf00909d，重基工作流 +244/−0），本地補丁集未動；pytorch：riscv 分支連續第七日零提交，主分支 20 筆全為上游；triton-riscv：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 筆（介面術語統一）；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 兩筆、工具鏈大版本宏、python 打包批次；開放 PR 9 筆有更新（含 RuyiAI 兩筆，其中 #1350 三筆提交重基）；無新標籤（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 條、部落格 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」最新一條為 10-25 的峰會參展報道，落在視窗外且與如意社群無關，未收錄

完整信源清單

/pull/1524>

uyi/releases>