调研窗口：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 的峰会参展报道，落在窗口外且与如意社区无关，未收录

完整信源清单