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

完整信源清单