报告周期：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 新闻与如意社区无关，未收录

完整信源清单

数据来源：每日 RuyiAI 动态报告（2026-10-26 至 2026-10-30 共 5 期）及本周补强核查（组织仓库、社区双源、官方主页）；报告周期为 2026-10-26 至 2026-10-30。