調研視窗：2026-10-30 05:00 ~ 2026-11-02 05:00（北京時間，72 小時，覆蓋週末）。

信源：Google News 聚合（中英文 27 組查詢，走代理）、Hacker News、Phoronix、CNX Software、LinuxGizmos、LWN、riscv.org 官方部落格、openRuyi 官網新聞頁與主倉、RISC-V 國際基金會會員企業官網巡檢（391 家）、riscv100.top 榜單巡檢，以及 GitHub 上香山 XiangShan／NEMU／difftest／XSCache／GEM5、CORE-V CVW／CVA6、達摩院玄鐵、奕斯偉、算能、芯來、樂鑫、進迭時空與 spacemit-robotics、矽速、revyos、openRuyi-Project、Radxa Linkr 等組織與重點倉庫的提交與釋出檢索。

本期索引

  • 今日重點：Linux 7.4 把「快非對齊訪問」改為執行期探測，發行版核心可吃到最多 11% 頻寬收益（10-30）
  • RISC-V 100 榜單動態
    • 榜單新增 10-17 記錄：XSCC 2.0 on 香山 KMHv3 RTL 3GHz，int 68.41、fp 76.95（11-02 巡檢）
    • 兩條舊記錄下榜：LLVM 22.1.0 on 進迭 K3 X100、XSCC 1.1 on 知合 A210 C908（11-02 巡檢）
  • 一、開源社群與軟體生態
    • 香山前端引入 FtqPrefetchQueue，iprefetch 重構第一步（10-30）
    • 香山修 MBTB 對隱藏 VBTB 分支的分配抑制（10-30）
    • 香山把 prefetch.i/r/w 解碼為 LSU 預取操作（10-30）
    • 香山 CI 效能流啟用 lightSSS，GEM5 周測切到 261013 配置（10-30）
    • difftest 兩天九筆：MMA 後端把 FP8 乘積打包進 cache word（10-30 至 11-01）
    • NEMU 為 AME 補 replay 狀態回滾，修 hosttlb 矩陣暫存器選擇符（10-30、10-31）
    • XSCache 修 CoupledL2 另一路 hint 被持續阻塞（10-30）
    • openRuyi 引入 llvm23 23.1.4，riscv64-openruyi-linux 預設 RVA23U64（10-30）
    • CORE-V CVW 按 Svvptc 不再快取無效 PTE（10-30）
    • CORE-V CVW 修 trace 的 VM 欄位與 quad 溢位檢測，rv64gc 覆蓋率達 100%（10-30）
  • 二、產品與生態動態
    • Qwenputer 把 RV32IM 編譯進 Qwen3.5-4B 權重，用注意力狀態當 RAM（10-30）
    • 進迭時空建 Bianbu AgentOS 傘倉，端側 agent 棧按子模組鎖定（10-30）
    • 進迭時空 docs-chip 移除 P1S 文件，docs-product 更新 K3 Pico 資源連結（10-30）
    • Radxa Linkr 增 OBS 瀏覽器採集指南，初始化 linkr-now-skill（10-30）
  • 三、國內團隊深挖
    • 芯來發布 Nuclei Studio VS Code IDE 預覽版，工具指南同步到 2026.10（10-30）
    • 算能 LLM-TPU 支援 InternVL3／LLaMa3，修 Qwen3-ASR 解碼退化（10-30）
    • 達摩院玄鐵與奕斯偉視窗內組織級零新開發（11-02）
  • 四、具身智慧與機器人專章
    • 進迭時空新增統一機械臂控制框架，85 檔案落標定／診斷／運動學（10-30）
    • 進迭時空 dice_arena 加入整合骰子游戲應用（10-30）
    • 進迭時空 docs-ros 補英文 RealSense 指南，對齊中英文件（10-30）
  • 五、總結與趨勢觀察
  • 附錄：完整信源清單與信源核查表

今日重點：Linux 7.4 把「快非對齊訪問」改為執行期探測，發行版核心可吃到最多 11% 頻寬收益（10-30）

Linux 7.4 的 RISC-V 架構改動已併入主線，其中一條最佳化值得單獨記：跳過軟體對齊的判定從編譯期挪到了執行期。

這條最佳化的來路分兩步。Linux 7.3 由 Tenstorrent 提交的改動，讓「為支援快速非對齊記憶體複製的 RISC-V 硬體編譯的核心」跳過軟體對齊，Tenstorrent 自測頻寬提升最高 11%。但 7.3 要求該能力在編譯時開啟，而一個發行版核心要服務一批硬體，其中總有慢速非對齊訪問的晶片，於是這條收益只能留在定製核心裡，通用構建吃不到。7.4 把判定改掛到 HAVE_EFFICIENT_UNALIGNED_ACCESS 上做執行期探測：只有探測到硬體確實支援快速非對齊訪問，使用者態複製才跳過軟體對齊。這樣一來，發行版 RISC-V 核心與其它通用構建都能預設帶上這條最佳化，而不必為老硬體保留一份特製映象。

同批併入 7.4 的 RISC-V 改動還有：crash 熱插拔支援、部分頁表函式走最佳化路徑、上下文切換的一處最佳化、「B」擴充套件進入 hwcap 與 hwprobe 上報，以及 Zic64b 擴充套件的上報支援。這幾條單看都不大，但合起來是「核心把 RISC-V 平臺能力摸清並交給自己排程」的一步——尤其是 hwprobe 側的上報，正是執行期探測這類最佳化的前提。

社群討論裡有一個值得記錄的判斷：Hacker News 上有讀者問快速非對齊訪問是否只屬伺服器 CPU，回覆指出除 SiFive 外幾乎各家都支援，SiFive 只在新一代效能核上支援。這提示發行版開啟這條最佳化後，實際受益面取決於晶片是否在 hwprobe 裡如實上報，而不是取決於產品定位。

日期：2026-10-30　來源：Phoronix：RISC-V Has A Nice Portable Performance Optimization With Linux 7.4、Hacker News 討論

RISC-V 100 榜單動態

本期巡檢（跨過週末，距上次 10-28 巡檢四天）發現榜單有實質變化，按使用者口徑置於正文靠前。

榜單新增（跨架構 · SPEC CPU2006 與 RISC-V 頻道 · SPEC CPU2006 各一條）：10-17｜香山編譯器團隊（XSCC）｜XSCC 2.0 on 香山 KMHv3 RTL 3GHz｜int 68.41、fp 76.95（speed/ref，Completed）；較同編譯器上一記錄（10-15，XSCC 2.0）int +0.8%、fp +0.5%。這條記錄的日期是 10-17，早於本次巡檢日，屬補錄上榜——10-28 巡檢時兩張 CPU2006 榜的榜首還是 10-15 的 int 67.85、fp 76.54。

下榜兩條：跨架構 · SPEC CPU2006 的 07-27 記錄「LLVM 22.1.0 on 進迭 K3 X100 2.4GHz」下榜；RISC-V 頻道 · SPEC CPU2006 的 08-05 記錄「XSCC 1.1 on 知合 A210 C908 1.9GHz」下榜。兩處下榜與一條補錄同時發生，更像榜面整理而非新測量——同編譯器口徑下 +0.8%／+0.5% 的差異也在噪聲量級，不宜單獨解讀為架構改進。

日期：2026-11-02　來源：riscv100.top 跨架構 SPEC CPU2006 榜、riscv100.top RISC-V 頻道 SPEC CPU2006 榜

一、開源社群與軟體生態

香山前端引入 FtqPrefetchQueue，iprefetch 重構第一步（10-30）

第 6691 號是香山前端本輪最重的一筆，16 個檔案、+471/−198。改動核心是新增 FtqPrefetchQueue，把取指預取從 ICache-top 上收到 FTQ 側統一排程。

原設計的三個問題寫得很直白。其一，FTQ 只負責 FDIP，來自 memblock 的 Zicbop 軟體預取 prefetch.i 由 ICache-top 處理，每週期只能收 1 個請求，且總是把軟體預取排在高優先順序——同一週期多條 prefetch.i 只有 1 條生效，其餘被靜默丟棄，效能收益低於預期。其二，密集 prefetch.i 會阻塞 FDIP 請求，反過來拉低效能。其三，prefetchPipe 要麼處理 1 條 prefetch.i、要麼處理 1 至 2 條 FDIP，即使兩者在 SRAM 上並不衝突也不能並行，流水線利用率偏低。

新佇列的做法是：先快取軟體預取請求，緩解丟失；再按佇列空位與當前 FDIP 距離選擇出隊來源，解決阻塞；並允許 FDIP 與預取在同一週期並行發射，解決利用率。作者還留了擴充套件口——後續可以把 PDIP 一類演算法的結果直接塞進同一佇列。這是把預取從「一條通路」變成「一級可排程資源」的改法，比單純調優先順序更接近長期方案。

日期：2026-10-30　來源：XiangShan #6691

香山修 MBTB 對隱藏 VBTB 分支的分配抑制（10-30）

第 6750 號修的是預測器後設資料互相壓制的問題。VBTB 在預測時只暴露最早命中的那一條分支，但訓練階段仍可能命中一條「隱藏分支」——這條分支在預測時沒被看到，卻因為訓練命中而抑制了 MBTB 的分配，結果是同一條分支反覆預測失敗。

改法分三處：只有在「預測時確實暴露過、且訓練時仍駐留」這兩個條件同時成立時，才因 VBTB 駐留而抑制 MBTB 寫入；把全部 NumWay+1 條後設資料條目傳給 AlignBank，以便區分「VBTB 預測命中」與「SRAM 命中」；條件分支載荷只在真正 taken 時寫入，因為 not-taken 的解決路徑攜帶的是順序下一條 PC 而非分支目標。最後一條同時施加於 MBTB 與 VBTB，並保留計數器訓練與 IFU 失效請求（attribute=None）。改動只有 2 個檔案、+33/−19，但屬於「預測器越複雜、後設資料口徑越要對齊」的典型修復。

日期：2026-10-30　來源：XiangShan #6750

香山把 prefetch.i/r/w 解碼為 LSU 預取操作（10-30）

第 6735 號改軟體預取指令的處理流程：prefetch.i、prefetch.r、prefetch.w 在譯碼階段被識別為 LSU 的預取操作，並從 CROB 中排除。這一步與第 6691 號的佇列化改動配套——只有先把預取從「普通訪存指令」裡分出來，FTQ 側的預取佇列才有獨立的請求來源，不必再與 load/store 爭同一條提交路徑。

日期：2026-10-30　來源：XiangShan #6735

香山 CI 效能流啟用 lightSSS，GEM5 周測切到 261013 配置（10-30）

第 6802 號在 gsim 流程裡升級 difftest 版本並讓 CI 啟用 lightSSS，跑分與驗證共用同一套快照機制，省去重複構建。同視窗 OpenXiangShan/GEM5 的第 1274 號把每週 XSCC 測試切到 261013 配置檔。兩筆都屬基礎設施維護：前者決定「出錯時能不能快速回放」，後者決定「周測跑的是哪一版編譯器與負載組合」，不改變 RTL 行為。

日期：2026-10-30　來源：XiangShan #6802、GEM5 #1274

difftest 兩天九筆：MMA 後端把 FP8 乘積打包進 cache word（10-30 至 11-01）

difftest 在三天裡提交 9 筆，全部圍繞 MMA（矩陣乘加）驗證的效能，節奏上是一次集中攻堅。

最技術的一筆是第 1023 號：把相鄰的 FP8 乘積記錄塞進同一個 cache word 的低 16 位與高 16 位，省一半暫存器；每個 word 先用偶數 lane 初始化，解碼前對兩個半字分別掩碼，保證相鄰符號欄位互不串擾，長度為奇數的尾塊也照此處理。第 1021 號把比對搬到 GPU 上（11 檔案、+420/−90）：DUT 快照上傳與參考計算解耦，活躍結果行直接在 GPU 上比對，成功只回傳狀態位元組，僅失配時才下載參考結果做診斷；回退路徑用 memcpy 替代較慢的 SSE2 streaming-store；複用連續熱槽並從 CUDA 服務直接上傳其區間；去掉每個字首的 ready／enqueue 確認，同時保住 LightSSS 會話生命週期。第 1018 號把 CUDA 傳輸、計算與結果校驗流水化，第 1017 號讓 LightSSS 支援 CUDA 後端，第 1020 號把 XDMA 中繼請求打包以降延遲，第 1019 號簡化有符號 INT8 參考歸約，第 1016 號複用運算元槽的連續活躍字首，第 1004 號隔離 Delta 與 AXI 時序。方向很清楚：驗證器不再只求「算得對」，還要「算得起」。

日期：2026-10-30 至 2026-11-01　來源：difftest 提交記錄、#1023、#1021

NEMU 為 AME 補 replay 狀態回滾，修 hosttlb 矩陣暫存器選擇符（10-30、10-31）

第 1255 號新增 replay_state.c（178 行），透過 replay state API 對矩陣暫存器、token 計數器、AMU 控制與同步事件做快照與恢復，並在 AME_MEM_ACCESS_CHECK 開啟時同時跟蹤矩陣與標量／向量儲存，在 AME_TILEREG_UB_CHECK 開啟時跟蹤 tile 暫存器定義區；快照刻意獨立於矩陣儲存提交佇列，避免回滾時被未提交的寫操作汙染。第 1274 號修一個簽名不一致導致的功能錯誤：矩陣讀寫定義與呼叫方用的是 char m_name，公開標頭檔案卻宣告為 bool isacc，於是經由標頭檔案呼叫時 A/B/C 選擇符一律被轉成 true；修正兩處宣告，並在 host-tlb.c 裡引入公共頭，讓今後再出現簽名不匹配直接編譯失敗。

日期：2026-10-30、2026-10-31　來源：NEMU #1255、NEMU #1274

XSCache 修 CoupledL2 另一路 hint 被持續阻塞（10-30）

第 48 號只改一行：CoupledL2 裡防止某一路 hint 被另一路持續阻塞。前一日第 46 號已把提示仲裁從固定優先順序改為輪詢，這一筆是同一條線的收尾。快取層級裡的餓死類問題通常只在長時間壓力測試下顯形，一行改動背後是一次不易復現的驗證。

日期：2026-10-30　來源：XSCache #48

openRuyi 引入 llvm23 23.1.4，riscv64-openruyi-linux 預設 RVA23U64（10-30）

六筆提交裡最重要的是新增 llvm23 包（1220 行 spec 加兩個補丁）。補丁做的事情比版本號更有資訊量：給 LLVM 增加 openruyi 這一 vendor，並把 riscv64-openruyi-linux 三元組的預設 ISA 級別直接定為 RVA23U64——也就是說不額外傳 -march 時，編譯器按 RVA23 生成程式碼。這對發行版是一個明確表態：RVA23 不再是「可選最佳化檔」，而是預設基線；同時補丁也把 openruyi-linux 三元組接進 x86_64 與 riscv64 兩套 Triple 處理路徑，保證交叉構建可用。

其餘五筆是滾動維護：ollama 升到 0.40.7 並標註 security-fixes；clang-wrap 更新到 20261030；新增 tree-sitter 的 C++ 與 Go 兩個 Go 語言繫結包以及 go-pointer 依賴。官網新聞頁最新仍是 2026.09 版（9-30 釋出），10 月版尚未釋出，10-19 的兩篇（Ruyi Firmware、社群公共基礎設施）已在 10 月中旬報告中收錄，本期不重複。

日期：2026-10-30　來源：openRuyi 提交記錄、llvm23 spec

CORE-V CVW 按 Svvptc 不再快取無效 PTE（10-30）

第 1974 號修的是一個只在 RVA23 選項下才暴露的死鎖：此前 HPTW 會把「遍歷落在 V=0 的葉或非葉 PTE 上」的結果寫進 ITLB/DTLB，之後命中該快取項時一直從快取條目觸發 page fault，直到執行 SFENCE.VMA 才恢復。問題在於 Svvptc（RVA23 的可選項）允許處理程式把 V 置 1 後直接重試、不發 SFENCE.VMA——在這種合法用法下，快取了無效 PTE 的實現會永久 fault。改法是讓遍歷器自己走既有 FAULT 路徑從 LEAF 報錯，不往 TLB 寫任何東西，下一次訪問重新遍歷即可看到更新後的 PTE；相應地 tlbcontrol 不再檢查 PTE.V，ITLB 的 ENVCFG_ADUE_1 覆蓋排除也從第 18 行移到第 16 行。這是「規範給了你一個可選項，實現必須為它的合法用法留出通路」的典型案例。

日期：2026-10-30　來源：CVW #1974

CORE-V CVW 修 trace 的 VM 欄位與 quad 溢位檢測，rv64gc 覆蓋率達 100%（10-30）

CVW 視窗內 19 筆提交，除 Svvptc 外還有三條值得記。第 1909 號修 wallyTracer 的 RVVI 跟蹤欄位：pte、頁型別、ppn、虛擬／實體地址與訪問型別的上報此前會帶上「上一次遍歷」的陳舊值（TLB 命中時常常是陷阱處理程式的內碼表），導致 ACT 功能覆蓋被錯誤記錄——現在改為上報本次訪問實際使用的翻譯，ITLB 與 DTLB 的遍歷分開捕獲，RV64 上按 TLB 項影子化 PTE[60:54]，A/D 更新鎖存器在每次遍歷結束時清零，32 位指令跨兩個 parcel 取指時按第一段報 PC。第 1906 號修 quadword cacheline 溢位檢測（align.sv）並補一條迴歸用例。第 2004 號把程式碼覆蓋率改成按配置統計，rv64gc 達到 100%；此外還把 riscv-arch-test 升到 act4 775be78d4，並同步 act／sail 的 yaml 配置。

日期：2026-10-30　來源：CVW #1909、CVW #1906、CVW #2004

二、產品與生態動態

Qwenputer 把 RV32IM 編譯進 Qwen3.5-4B 權重，用注意力狀態當 RAM（10-30）

開發者 Divyansh Agrawal 於 10-22 釋出的實驗模型 Qwenputer，10-30 經中文媒體轉述後進入大眾視野。做法是把 RV32IM 指令集及擴充套件「編譯」進 Qwen3.5-4B 的權重，用模型自帶的 Gated DeltaNet 狀態充當可精確定址的 RAM，從而在前向傳播裡跑真正的程式——不需要訓練，編譯器直接寫出每個權重：注意力頭做查表、前饋單元以查詢表實現算術、DeltaNet 頭持有記憶體。

可核對的收益集中在精確算術：大整數乘法從原版 55.0% 升到 97.5%，大整數除法 72.5% 到 97.5%，加減 87.5% 到 97.5%，多次乘除的更長鏈路 90.0% 到 100%，合成整數算術 75.0% 到 97.5%；長整數基準 NUPA 從 48.6% 到 100%。專案自述該 CPU 透過官方 RISC-V 測試，連續執行約 1,800 萬條指令無錯；還實驗性地做了「模型內檔案系統」，在 GDN 狀態裡存最多 512 個檔案、約 5.3 萬詞元。

代價同樣明確：模型體積漲到約 18.8GB（接近原版兩倍），每條 CPU 指令要生成多個詞元，原本毫秒級的計算可能拖到數秒，執行還需專用驅動，不能像普通模型那樣直接載入；專案已在 Hugging Face 與 GitHub 開源，可在單張 24GB 視訊記憶體顯示卡上跑。這條對 RISC-V 圈的意義不在效能，而在於「RISC-V 作為確定性執行層被另一種系統借用」——它驗證了 RV32IM 這套極簡 ISA 適合被形式化地嵌入異構載體。

日期：2026-10-30　來源：IT之家報道（搜狐轉載）、技術解析

進迭時空建 Bianbu AgentOS 傘倉，端側 agent 棧按子模組鎖定（10-30）

spacemit-com 新開 bianbu-agentic 傘倉並完成 bootstrap：它本身不 vendor 程式碼，只用子模組為每個元件釘住一個 commit，使整機映象可以從單個 SHA 復現。倉內列出的元件構成一套完整的端側 agent 作業系統：agent runtime（YAML 驅動的會話事件流、生命週期、模型呼叫、工具／外掛執行與安全邊界，Python）、agent-security（工具審批、按 agent 同步能力、securityd 簽名清單，含 Debian 打包）、agent-memory（Rust，L1 會話抽屜／L2 工作抽屜／L3 長期抽屜）、bibit-intent（意圖路由與工具執行：確定性規則 → 本地推理 → 雲端升級）、BiBit GUI（基於 Jan 的桌面前端，Tauri）、bibit-voice（KWS 喚醒、VAD、ASR，經 /run/bibit/audio.sock 提供服務）、bibit-filesearch（本地語義檔案檢索，資料不出機器）與 lxqt-schedule。

這套劃分值得注意的地方是「記憶」被做成了獨立子系統並分三層，而「安全」被做成帶簽名清單的常駐守護程序——兩者都是把 agent 從演示品做成可交付系統時才會出現的部件。對 K 系列這類 RISC-V 端側平臺，這意味著廠商的軟體重心正從「驅動與 ROS 文件」上移到「執行時與系統服務」。

日期：2026-10-30　來源：bianbu-agentic 倉庫、README

進迭時空 docs-chip 移除 P1S 文件，docs-product 更新 K3 Pico 資源連結（10-30）

docs-chip 刪除了 P1S 產品文件及其評審工具引用：中英文 power_stone 目錄下的 P1S 頁面、導航連結，以及文件評審 agent 裡的 casing 檢查、晶片路徑查詢、術語表、system prompt、實體後設資料與 Copilot 指令一併清理。docs-product 合併第 153 號，更新 K3 Pico 的硬體資源連結。前者是產品線收斂的訊號（文件與工具鏈同時去掉一條產品），後者屬交付文件的常規維護。

日期：2026-10-30　來源：docs-chip 提交、docs-product #153

Radxa Linkr 增 OBS 瀏覽器採集指南，初始化 linkr-now-skill（10-30）

Radxa 的瀏覽器遠端管理產品線視窗內 4 倉有推送：docs 增加 OBS 瀏覽器採集（browser capture）指南，linkr-docs 與 linkr-docs-en 同步更新，linkr-now-skill 完成初始化（Go）。Linkr 面向開發板與 NAS 的遠端帶外管理，OBS 採集指南說明其影片通路開始被當作直播／錄製源使用，屬使用場景擴充套件而非核心或韌體變更。

日期：2026-10-30　來源：linkr docs 提交、linkr-now-skill

三、國內團隊深挖

芯來發布 Nuclei Studio VS Code IDE 預覽版（10-30）

芯來 10-30 在深圳釋出 Nuclei Studio VS Code IDE，官方開發工具從此有 Eclipse 與 VS Code 兩種形態。當前是 Windows 開發者預覽版 0.1.0，中英文介面，以 VSIX 裝進現有 VS Code（要求 1.134.0 以上），與已裝擴充套件不衝突；底層仍依賴 Nuclei Studio IDE 2025.10。

相容策略是「不重寫、儘量照搬」：VS Code 版可直接匯入 Eclipse 版工程，內建 cproject 相容處理，開啟即可開發；新建工程嚮導與 Eclipse 版一致（選廠商、SoC、開發板、SDK），SDK 與 BSP 仍以 NPK 包分發，兩版可互換。除錯支援 OpenOCD、J-Link、QEMU 與 NucleiModel 四種方式，統一走 CDT gdbtarget，斷點、單步、變數、呼叫棧、記憶體與外設暫存器檢視、串列埠監視器、反彙編齊備，並新增 Live Watch。AI 側不設牆：常規 AI 程式設計助手裝上即用，相容 Kimi、GLM、DeepSeek、Qwen；官方演示用 Kimi Code 以 @helloworld 接管工程，一句話把 CoreMark 專案改成 AES-256-CBC 演示，隨後直接在 QEMU 裡除錯並由串列埠列印 PASS。路線圖列出 Linux 與 macOS 支援、profiling、程式碼覆蓋率、ETrace、flash 程式設計與更多 AI 助手。

對國內 RISC-V 開發者生態而言，這一步的實際意義是「入口遷移」：Eclipse 啟動慢、笨重是長期抱怨，而 VS Code 側又能順手接上本地或雲端模型。工具鏈文件同步跟上 2026.10 釋出——xlmodel 文件、工具鏈文件、QEMU XEC 乙太網指南英文化、Studio 的 npk／gdb trace／大端除錯說明，以及 xxlvfbf／xxlvw／xxlvqmacc 自定義擴充套件文件的英文化，共 5 筆。

日期：2026-10-30　來源：Design & Reuse 釋出稿、nuclei-tool-guide 提交

算能 LLM-TPU 支援 InternVL3／LLaMa3，修 Qwen3-ASR 解碼退化（10-30）

LLM-TPU 合入第 178 號（支援 InternVL3、LLaMa3，並最佳化 Qwen2_VL）與第 182 號。後者是一個值得記錄的實際缺陷：forward_next 把 lm_head 的輸出經 d2d 拷進 embed_cache 的 input_ids。當 --do_sample 且 lmhead_with_topk=false 時，lm_head 輸出的是完整的 [1,151936] logits（607232 位元組），把它拷進 4 位元組的 token-id 緩衝，會在每個解碼步破壞 embedding 查表，輸出退化成重複垃圾 token（例如把 language Chinese<asr_text> 變成 languagelanguage...）。修法是在該分支改喂 greedy_head 的 token_id（4 位元組），與 Qwen2_VL 的 forward_next 對齊；作者在 CV84X6 與 1684X 兩塊板上與 HF 逐 token 比對一致，回滾改動可復現原垃圾輸出，確認因果。

另有一筆 sophon-tools 的更新：se-rag-core 把狀態標記改為 24 小時自動重新整理，版本升到 1.5.4。同視窗 sophgo 的 libsophon、middleware、osdrv、linux_5.10、build、sophpi、sophon-tools 等 10 個倉庫在 10-31 同一分鐘批次推送，屬 SDK 側的整批同步，未見單項功能說明。

日期：2026-10-30　來源：LLM-TPU #182、LLM-TPU #178、sophon-tools 提交

達摩院玄鐵與奕斯偉視窗內組織級零新開發（11-02）

XUANTIE-RV 在視窗內零推送，最近一次是 torq-tile 的 10-29 14:14（北京時間，早於視窗起點），llvm-project 與 bcc 分別停在 10-27 與 10-21；奕斯偉 eswincomputing 最近推送是 10-19 的 linux-stable。兩家在 72 小時視窗內沒有可核對的新開發成果。需要說明的是，這並不代表產品線靜默——玄鐵在 10-19 峰會公佈的 C950 多核互聯／AI 推理／伺服器 Java 進展與車規 E908A，已在 10 月下旬各期報告中收錄，本期不重複。

日期：2026-11-02　來源：XUANTIE-RV、eswincomputing

四、具身智慧與機器人專章

進迭時空新增統一機械臂控制框架，85 檔案落標定／診斷／運動學（10-30）

spacemit-robotics/manipulation 一次性提交 85 個檔案、+8605 行，建立了統一的機械臂控制框架。目錄結構按能力切分：calibration 含 charuco 標定、手眼標定 CLI 與取樣工具，diagnostics 有 arm_check 與操作員 CLI，kinematics 提供基於 URDF 的正解，motion 是裝置服務與 CLI（device_service.cpp 234 行），bindings/python 給出 spacemit_manipulation 客戶端與運算元支援層，構建側用 CMake 的 driver_modules 組織驅動模組。

這個結構透露的判斷是：廠商把機械臂當成「有標定、有診斷、有運動學、有服務介面」的系統部件，而不是一段示例程式碼。手眼標定與 charuco 是實機部署繞不開的前置工序，arm_check 與裝置服務是把機械臂接入 agent／上層排程所需的最小介面。對 RISC-V 機器人棧來說，這類「工程骨架」比單個演算法 demo 更能說明落地進度。

日期：2026-10-30　來源：manipulation 提交

進迭時空 dice_arena 加入整合骰子游戲應用（10-30）

dice_arena 新增一個整合式骰子游戲應用，同批還有 pyagxarm（機械臂 SDK 繫結）與 humanoid 相關倉庫的推送。就內容看，dice_arena 屬演示型應用，用低自由度任務串起感知—決策—執行鏈路，價值在於給整套棧一個可復現的端到端樣例。

同時需說明口徑：spacemit-robotics 視窗內 5 個倉庫的 pushed_at 有更新，但 humanoid_common 與 humanoid_unitree_g1 在 main 分支上沒有視窗內新提交，屬其它分支推送；humanoid_common 的實體提交應以前一週期記錄為準，本期不重複計數。

日期：2026-10-30　來源：dice_arena 提交、spacemit-robotics

進迭時空 docs-ros 補英文 RealSense 指南，對齊中英文件（10-30）

docs-ros 新增英文版 RealSense 指南並對齊文件結構。此前該站的深度相機內容以中文為主，英文側缺對應條目；這次補齊後，K3 平臺上的視覺感知鏈路（相機接入、標定、與 ROS 2 節點的對接）在中英文兩側口徑一致。對海外開發者與國內做出口方案的團隊，這類文件對齊常是先決條件。

日期：2026-10-30　來源：docs-ros 提交

五、總結與趨勢觀察

一、核心側的關鍵詞從「支援」轉向「按硬體能力排程」。 Linux 7.4 把快非對齊訪問的判定從編譯期挪到執行期，一條 7.3 時代只能留在定製核心裡的最佳化，現在發行版核心預設就能帶上，Tenstorrent 自測的頻寬收益上限是 11%。同批併入的 hwcap／hwprobe 的「B」擴充套件與 Zic64b 上報，正是這類執行期決策的資料來源。對國內幾家 RISC-V 發行版，這是零成本收益，但前提是晶片在 hwprobe 裡如實上報——硬體廠把能力報全，比多做一次微架構最佳化更能讓使用者立刻受益。

二、香山前端進入「預取佇列化」階段。 第 6691 號把 iprefetch 從 ICache-top 的「每週期 1 條」邏輯上收到 FTQ，先解決丟失與阻塞，再談 PDIP 一類演算法；配套的 MBTB／VBTB 修正說明瓶頸已從「取指頻寬」轉向「後設資料精度」。兩條線合起來看，前端最佳化正在從加緩衝轉向「把預取當成一級可排程資源」，這類改動的收益要靠長期負載才能驗出來，短期跑分未必好看。

三、差分驗證開始為加速器運算元付效能成本。 difftest 三天 9 筆全部圍繞 MMA：FP8 乘積打包、GPU 側比對、CUDA 流水化、XDMA 中繼打包、LightSSS 支援 CUDA 後端。RISC-V AI 核要走量產，驗證吞吐必須跟上運算元複雜度，否則「算得對」會變成「算不完」。這組改動的方向比單筆收益更值得記錄。

四、工具鏈兩側同時定基線。 openRuyi 引入 llvm23，並把 riscv64-openruyi-linux 三元組的預設 ISA 定到 RVA23U64；芯來把 IDE 從 Eclipse 遷到 VS Code，並把 xlmodel、工具鏈與大端除錯文件同步到 2026.10。前者定「預設生成什麼程式碼」，後者定「開發者從哪裡進來」，兩者都屬於長週期決定，短期看不到效果，但會影響此後一兩年的預設選擇。

五、國內側本週期產出集中在算能與芯來，路線從板卡上移到系統棧。 算能的實質工作是模型支援與一個解碼退化 bug 的修復（logits 拷進 4 位元組 token 緩衝，導致每步解碼破壞查表），這類缺陷只有真機逐 token 比對才能定位；芯來把工具鏈入口換到 VS Code 並順手補齊 AI 助手接入。玄鐵與奕斯偉在視窗內空檔，進迭時空則同時推進 Bianbu AgentOS 傘倉與機械臂控制框架——一家公司把「端側 agent 執行時」和「機械臂標定／診斷／運動學」並列推進，說明其 RISC-V 軟體棧的重心正從驅動與文件轉向可交付的系統層。本期新聞側偏薄：中英文查詢去重後實質新增只有 Linux 7.4、Qwenputer、Nuclei Studio 三條，其餘為股市稿、消費電子與舊文重發；開源側仍是主體。

附錄

完整信源清單

b.com/XUANTIE-RV>

信源核查表

信源 核查結果
Google News（中英文 27 組查詢） 視窗內去重後實質新增 3 條：Linux 7.4、Qwenputer、Nuclei Studio；其餘為股市行情稿、消費電子、舊文重發與博彩類噪音，已剔除
Hacker News 2 條：Linux 7.4（有效）；RVA23 之後演進的 Ubuntu 部落格（原文 9-15，屬舊文，不計條目）
Phoronix 視窗內 RISC-V 專項 1 條（Linux 7.4）；其餘為顯示卡與儲存子系統
CNX Software、LinuxGizmos、LWN 視窗內無 RISC-V 專項命中
riscv.org 官方部落格 無新文；首頁橫幅為北美峰會徵稿截止提示
openRuyi 官網新聞頁 最新仍為 2026.09 版（9-30）；10 月版未釋出，10-19 兩篇已在前序報告收錄
openRuyi 主倉 6 筆提交，含 llvm23 23.1.4 新增與 ollama 0.40.7 安全修復
riscv100.top 巡檢 顯著：新增 1 條 10-17 記錄（XSCC 2.0 on 香山 KMHv3 RTL 3GHz，int 68.41、fp 76.95），下榜 2 條；What’s New 與委員會成員無變化
RISC-V 會員企業官網巡檢 巡檢 391 家（67 家抓取失敗），更新項均為高校與機構首頁常規內容，無實質產品、融資或架構動態
GitHub 重點倉庫 香山 4 筆、difftest 9 筆、NEMU 2 筆、XSCache 1 筆、GEM5 1 筆、CVW 19 筆、CVA6 0 筆、openRuyi 6 筆、算能 5 筆、進迭時空 11 筆、芯來 5 筆、Radxa Linkr 4 筆
樂鑫（espressif） 視窗內 58 倉推送，屬按日批次同步，未見 RISC-V 專項變更
達摩院玄鐵、奕斯偉 視窗內組織級零推送，最近提交分別為 10-29 與 10-19