Research window: 2026-10-29 04:30 ~ 2026-10-30 04:30 (Beijing time, past 24 hours), directly contiguous with the previous issue (10-29 04:30 cutoff).

Sources: Full-repository review of GitHub organizations (RuyiAI-Stack, ruyisdk, openRuyi-Project, buddy-compiler, with commits, PRs, and Releases within the window checked repo by repo; upstream forks filtered by keywords such as RISC-V / RVV / XuanTie), openRuyi commit and PR merge statistics, Releases of the ruyi package manager and ruyi-imager, the RuyiSDK developer community forum, the ruyiai-daily daily intelligence archive, snapshots of three pages of the official RuyiAI homepage, arXiv searches, and targeted Google News RSS queries in Chinese and English (via proxy).

This Issue’s Index

  • Today’s Focus: Three triton-riscv merges in one day, all stemming from degradation defects exposed by FlagGems operator migration (10-29)
  • I. RuyiAI Stack Progress (PyTorch / Triton / TileLang RISC-V Adaptation)
    • 1.1 pytorch: riscv branch ends its seventh day silently; full-branch replay lifts it to upstream 3afdbd3 (10-29)
    • 1.2 llvm-project: riscv branch full-branch replay, adds contribution guide and removes dry-run switch (10-29)
    • 1.3 triton-riscv: three degradation fixes merged within 80 minutes, dependency update still open (10-29)
    • 1.4 tilelang-riscv: main branch silent on day fourteen (10-29 status)
  • II. RuyiSDK Toolchain and Distributions
    • 2.1 openRuyi: 76 commits, 10 merges; KDE Frameworks 6.31.0 lands 64 packages in one pass (10-29)
    • 2.2 openRuyi packaging: vkpeak included, cmake module path fixed, clang-wrap updated daily (10-29)
    • 2.3 openRuyi under review: #1350 first-round code-level review yields 18 items, ollama security update pending merge (10-29 status)
    • 2.4 ruyi-imager 1.1.0-rc.1 released; ruyi 0.54.0 still no beta (10-29)
    • 2.5 ruyi main repo: vendor naming list updated, ABI probing proposal appended (10-29 / 10-28)
  • III. Vector Extensions, Architecture Testing, and Operator Optimization
    • 3.1 Four vector repos remain silent, benchmark-side gaps persist (10-29 status)
    • 3.2 FlagGems migration has become triton-riscv’s defect discovery mechanism (10-29)
    • 3.3 No new arXiv entries in window; two papers from 10-27 remain latest (10-29 status)
  • IV. Buddy Compiler Updates
    • 4.1 buddy-server new ABI merged: 56 files, model plugin system switched to unified interface (10-29)
    • 4.2 Nightly dev20261029 packaged before #1015; downstream must wait for next release (10-29)
    • 4.3 Three under review stalled at 10-28; Whisper and interface alignment untouched (10-29 status)
  • V. Community, Events, and Official Homepage
    • 5.1 Official homepage unchanged across three pages; two blog posts, twenty-three documentation chapters (10-29 status)
    • 5.2 Forum: two posts—RuyiAI summit recap and XiangShan Ruyi ecosystem conference repost (10-29)
    • 5.3 ruyiai-daily one issue; intelligence coverage spans PyTorch, LLVM, Triton, and RISC-V (10-29)
    • 5.4 Zero external news hits; openRuyi 2026.10 and 0.54.0 both unreleased (10-29 status)
  • VI. Trend Observations
    • 6.1 Fixes precede acceptance: three fixes rely on issue tickets accumulated during migration, not regression tests
    • 6.2 Two approaches to branch governance: llvm writes rules and removes dry-run; pytorch relies on full-branch replay
    • 6.3 Distributions ship monthly by volume; the three stack-level pieces stall in review monthly

Today’s Focus: triton-riscv merges three PRs in one day, all stemming from lowering defects exposed by FlagGems operator migration (10-29)

Date: 2026-10-29　Source: PR #58, PR #83, PR #82, commit list

Within 80 minutes, from 15:38 to 16:58, the triton-riscv main branch merged three PRs in succession, all authored by maochuanjun, all touching the same layer—the lowering path from Triton to structured/unstructured IR. This timing is unusual: the repo’s previous non-dependency-update code commit was #86 on 10-09, and for the twenty days in between there were only renovate’s nightly version-bump anchors, while these three PRs themselves sat for 82, 43, and 44 days respectively before being merged.

Each of the three targets a specific defect. #83 (16:38, 4 files, +160/−16) fixes masked loads with non-uniform tensor fill values, i.e. the pattern tl.load(ptr, mask=mask, other=cur). The original implementation only recognized scalar or splat fill values; when given a real tensor it got stuck on scalar extraction, leaving unsupported pointer operations in the lowered IR. The fix supports tensor fills on both the structured-load and unstructured-gather paths, restoring missed lanes with arith.select(mask, loaded, other), while allowing scalar extraction to fail without erroring and handing control back to the caller. #58 (16:58, 2 files, +125/−0) fixes the loss of loop-carried gather offsets: once a tensor carried in an scf.for leaves structured form, the auxiliary state retains only a neutral placeholder, and rebuilding the loop result from it collapses gather/scatter into a contiguous tts.make_tptr, discarding all offsets accumulated in the loop. The fix first verifies that the analyzed operand is indeed the result of an scf.for; if so, it preserves the original loop result directly as the offset, and adds a loop_result_gather.mlir regression. #82 (15:38, 1 file, +23/−3) fixes nondeterminism in the scatter test: the original test used random indices and allowed duplicate destination slots, so under a non-reducing scatter any source value winning was legal, yet it compared exactly against a single PyTorch CPU result. The fix switches the 1D, 2D, and in-place comparisons to unique destination indices, and adds six duplicate-index cases (lengths 512, 1023, and 1024, one in-place and one out-of-place each), checking only that the winning value comes from the correct destination’s source set and that unmatched destinations retain their original values.

The motivation for all three is stated in the PR descriptions, and all point to the same place: FlagGems operator migration. #83 serves the unique_dim implementation; #58 serves broadcast_to (that kernel had previously replaced range(MAX_DIMS) with tl.static_range to work around this miscompile); #82 is a test fix forced by scatter-operator comparison failures during migration. In other words, these three were not defects found by regression tests, but defects forced out by “running a batch of PyTorch operators on triton-riscv.”

The verification strength is worth noting. #83 explicitly states it was verified on a RuyiAI-related riscv64 machine: all three RUN/FileCheck lines of the new regression pass; the full lit suite has 291 passing, 9 expected failures, 0 unexpected failures; the tensor-fill runtime checks pass 18 items (covering both the structured and gather paths, float32/float64/int64, empty/partial/full masks, negative zero, NaN, and invalid missed gather offsets); and integration with the updated unique_dim passes 23 items. #58 ran only the targeted TritonToStructured regression, and #82 ran only that test file (21 passing)—the verification depth across the three is uneven, with the first two more localized and the third confined to a single file.

One caveat on causal order: the fixes landed first, while migration PR #56, which needs them, is still stalled at 09-16, open and unmerged. This means that after these three merges, the tl.static_range workaround in broadcast_to can be reverted and unique_dim can be submitted as originally written, but the question of “whether the whole batch of operators runs on riscv64” has no answer this issue—it must wait for #56 to resume before it can be verified.

I. RuyiAI Stack Progress (PyTorch / Triton / TileLang RISC-V Porting)

1.1 pytorch: riscv branch ends seven days of silence, whole-branch replay lifts baseline to upstream 3afdbd3 (10-29)

Date: 2026-10-29　Sources: pytorch riscv branch, SyncBots commit 5a29c201, PR #51, PR #44

After seven consecutive days of zero commits, the riscv branch underwent a whole-branch replay at 14:06: the committer timestamps of the 11 existing patch commits on the branch were uniformly rewritten to between 14:06:44 and 14:06:45, while author timestamps were left unchanged—a typical trace of replaying onto a new baseline rather than new development. The replay preserved the original patch set, including “Add riscv64 image locally (#51)”, “Fix bytes_to_scalar for float/complex on RISC-V (#44)”, and earlier CI and test-tolerance changes.

At 20:48, another commit was added: [SyncBots] Integrate PyTorch at 3afdbd3, changing only one line in cmake/Dependencies.cmake: adding FORCE to the cache variable for KINETO_SOURCE_DIR. Small as the change is, its meaning is clear—the branch baseline has been lifted to upstream 3afdbd3, and this commit was auto-generated by the sync bot, requiring no human judgment.

A mismatch also observed: on the distribution side, python-torch-ruyiai (openRuyi #1352) remains at 10-27 with no movement this period; the branch head has already switched to the new baseline. If that package is built from branch artifacts, the source revision pinned in the package needs to be realigned once—a step no PR is currently handling. The updated timestamps of all seven open PRs (#23, #35, #36, #38, #43, #46, #48) are 20:47:49, a batch refresh triggered by the branch push and not indicative of content updates; the two main RVV lines (#46 for ATen vector extension support, #48 for RISC-V Vector CPU capability) still have no new commits this period.

1.2 llvm-project: riscv branch whole-branch replay, new contribution guide added and dry-run switch removed (10-29)

Date: 2026-10-29　Sources: riscv branch commit list, commit faf4def312, RISCV_CONTRIBUTING.md, autorebase workflow

Around 23:00, the riscv branch underwent a whole-branch replay: the committer timestamps of all 25 visible commits fall within the 4-second span from 23:00:40 to 23:00:44. Among the replayed content, one commit is genuinely new—[workflows] Push rebased PRs directly and document contribution options (author time 10-29 09:59), which modifies two files: autorebase.yml loses 8 lines (removing the dry_run input and the corresponding dry-run branch), and a new 82-line RISCV_CONTRIBUTING.md is added.

This guide lays out two paths for “how to send things to the riscv branch.” Path one: open an issue first, and a maintainer cuts a work/issue-NNN working branch from the current riscv; contributors submit PRs to the working branch, and the maintainer integrates and merges into riscv—suitable for multi-person work items that need stable history. Path two: submit a PR directly to riscv, and manually trigger the rebase workflow whenever the baseline changes: the workflow runs in the PR’s source repository, uses the source repository’s GITHUB_TOKEN, and pushes back to the source branch with --force-with-lease and an explicit expected SHA; conflicts always resolve in favor of the riscv side (including keeping the riscv-side deletion in modify/delete conflicts), equivalent patches are skipped automatically, and riscv itself is never rewritten nor auto-merged.

Compared with the 244-line workflow from the previous period, the biggest change is that dry-run has been removed: the previous period defaulted to “dry-run only, no push,” while this period changes to “push on success, no preview option,” and the documentation states this explicitly. This lowers friction while moving risk earlier—contributors’ local branches must be synced promptly, or old-baseline history may be pushed back; the documentation includes a dedicated section reminding contributors to save uncommitted work and avoid pushing the old baseline back to the remote. Another detail worth noting: the documentation explicitly states that pushing with GITHUB_TOKEN typically does not trigger subsequent push/PR workflows, so whether CI has run on the updated SHA requires manual confirmation.

1.3 triton-riscv: three regression fixes merged within 80 minutes, dependency update still open (10-29)

Date: 2026-10-29　Sources: PR #58, PR #83, PR #82, PR #91, PR #56

The technical details of the three fixes are expanded in this period’s “Today’s Highlights”; here we add three status notes. First, after the three merges, the main branch saw no new code commits within the window, with the latest commit list entry still at #58, indicating a concentrated cleanup rather than continuous development. Second, renovate’s #91 bumps the upstream buddy-mlir nightly from nightly/v0.1.3.dev20261027 to dev20261029 (+2/−2, one file); it was refreshed once after #58 merged at 10-29 16:58, remains open, and its mergeable status is unstable—this dependency update is the channel through which downstream receives #1015, see 4.2 for details. Third, among open PRs, #55 (the asin operator frontend patch) was refreshed at 18:06, #56 (FlagGems operator migration) has been stalled since 09-16, and #54, #57, #59, #72, #75, #85, #46 all saw no activity within the window—in particular #85 “softmax and matmul optimization” has not been updated since 10-18; this is the performance mainline and worth watching going forward.

1.4 tilelang-riscv: main branch silent for a fourteenth day (10-29 status)

Date: 2026-10-29 (status)　Sources: tilelang-riscv commit list, open PR list

The last commit on the main branch remains “Build Python extension in Buddy CI” from 10-16 10:52, marking fourteen consecutive days without commits. There are still two open PRs: #2 stalled since 06-16 and #4 “RVV vector mask and max reduction lowering” stalled since 09-28, neither updated within the window.

This stands in direct contrast with triton-riscv’s three merges this period: within the same organization and the same timeframe, one branch is doing a concentrated cleanup of regression defects while the other shows no activity at all. tilelang-riscv’s only downstream presence still comes from openRuyi’s python-tilelang-ruyiai spec (#1350, four patches), meaning the state of “distribution artifacts substituting for repository iteration” has now persisted into its third week.

II. RuyiSDK Toolchain and Distributions

2.1 openRuyi: 76 commits, 10 merged PRs, KDE Frameworks 6.31.0 rolls out 64 packages in one pass (10-29)

Date: 2026-10-29　Source: PR #1513 KDE Frameworks 6.31.0, PR #1532 Gradio, PR #1533 pyvex, PR #1531 graphql-core, main repo commit list

This period the main repo saw 76 commits and 10 merged PRs, with commit times running from 15:05 on 10-29 through 00:20 on 10-30 — nearly triple the previous period’s 27. The reason is concentrated: a single KDE Frameworks 6.31.0 upgrade rolled out 64 kf6-* packages. The entire batch landed in the same minute at 15:11 (#1513), from kf6-kcoreaddons and kf6-kconfig to kf6-kio, kf6-ksvg, and kf6-kwallet, essentially covering the full set of frameworks Plasma 6 depends on. Last period this PR was still marked WIP and sitting in the review queue; within a day it flipped to merged, showing that desktop-stack version tracking has batch rebuild capability.

The remaining merges are routine version bumps and packaging fixes: Gradio 6.31.0 and its dependencies (#1532, including gradio-client 2.7.2 and python-brotli 1.2.1), python-pyvex 10.0.5 (#1533), and a manual provides epoch-version fix for python-graphql-core (#1531). There are no direct RuyiAI stack components here, but this batch of Python-side metadata fixes rests on the same foundation as the later triton/tilelang wheel build path — last period’s scikit-build-core and cmake metadata work belongs to the same category.

Worth noting is the time distribution: the 64 KDE packages cluster in the single minute at 15:11, while the other 12 commits are scattered from 15:05 to 00:20 the next day, indicating this batch was a scripted bulk update with manual cleanup rather than package-by-package manual commits.

2.2 openRuyi packaging surface: vkpeak added, cmake module path fixed, clang-wrap daily bump (10-29)

Date: 2026-10-29　Source: PR #1349 vkpeak, PR #1536 ecbuild, PR #1535 clang-wrap, PR #1537, PR #1538, PR #1539

One new package: vkpeak (#1349, merged 16:38), a Vulkan peak-performance and device-capability probing tool, useful for assessing graphics and compute capability on RISC-V boards — filling the “hardware exists, measurement tools don’t” gap. Three packaging-infrastructure items: ecbuild’s cmake modules now install to %{_libdir} (#1536), fixing their previous placement in a non-standard path; clang-wrap bumped to 20261029 (#1535), keeping the same-day packaging cadence as upstream; and the provides epoch-version fix for python-graphql-core (#1531).

There are also three pure dependency-graph cleanups: #1537 removes a duplicate go-github-smartystreets-assertions package, resolving a multi-choice conflict; #1538 and #1539 add missing import-path provides for go-golang-x-text, go-github-hexops-gotextdiff, and go-github-magefile-mage. These issues won’t prevent a package from installing, but they can cause dnf to pick the wrong version during dependency resolution — a hidden long-term maintenance cost for a distribution.

2.3 openRuyi under review: #1350 gets first code-level review with 18 comments, ollama security update pending merge (10-29 status)

Date: 2026-10-29 (status)　Source: PR #1350 Ruyiai packages, PR #1514 ollama, PR #1490 cross toolchain, PR #1516 qemu-rustsbi

#1350 (the buddy-mlir, python-triton-ruyiai, python-tilelang-ruyiai trio) received its first code-level review this period: misaka00251 posted 5 comments in quick succession between 16:19 and 16:24, all aimed at spec style rather than design direction — no blank lines needed between BuildOption(xxx) entries; python-triton-ruyiai is missing BuildRequires: python3dist(wheel) and its Provides must match the actual package name; the necessity of Conflicts: python-%{srcname} needs justification; patches should be generated with git format-patch, and one patch in the same directory is unreferenced; empty %check sections need a comment explaining why. The PR has since grown to 10 files, +796/−0, with 18 review comments total, still unstable and unmerged.

Reading this round alongside previous ones, the center of debate is shifting: before 10-27 it was “should buddy-mlir’s bundled LLVM be externalized” (the author defended keeping it in-package with a 2.81x build-time argument); this period it moved to mechanical spec conventions. Such comments usually appear at the “direction accepted, wrapping up” stage, though they could also just be routine checking — whether it merges still depends on whether anyone approves in the next round.

Other items in the review queue: #1514 bumps ollama to 0.40.7 and tags it security-fixes, refreshed 10-30 02:04, +259/−3371 (the scale of removing the vendor directory), unmerged; #1516 qemu-rustsbi refreshed 22:36; #1540 Prometheus v3.13 dependency-fix batch refreshed 17:01; #1534 simdjson 5.0.8 with offline tests refreshed 16:27; #1490 cross riscv64 toolchain is still marked WIP and stalled at 10-28, leaving a “the entry point exists but the toolchain hasn’t arrived” state relative to the already-merged toolchain major-version macros.

2.4 ruyi-imager 1.1.0-rc.1 released, ruyi 0.54.0 still has no beta (10-29)

Date: 2026-10-29　Source: ruyi-imager v1.1.0-rc.1, commit 839a8f56, ruyi Releases, ruyi tags

At 16:02, ruyi-imager released v1.1.0-rc.1, about seven weeks after 1.0.0 (09-10). Four changes: the image-selection step gains a download action (#12); CLI output aligns with the terminal character set while keeping JSON as UTF-8 (#14); double-clicking confirms in the selection dialog (#19); the selection dialog requires an explicit choice (#21). All four are usability polish, and “double-click to confirm” and “explicit selection required” are complementary interaction constraints — the former speeds things up, the latter prevents mis-selection. The release notes also credit a first-time contributor (qingwan12138), who authored three of the four changes. A “Bump base version to 1.1.0” commit landed at 15:40 the same day, preparing the version slot before release.

Meanwhile, package manager ruyi’s 0.54.0 still has no beta: the tag list shows nothing after 0.54.0-alpha.20260918, the latest stable release remains 0.53.0 from 09-24, and the main branch has had no commits since 09-25. Biweekly progress issue 079 stated the release was moved to “end of October” due to a release-cycle adjustment; this window is already the second-to-last day of October with still no release candidate — given the monthly cadence of 6-30, 7-23, 8-27, and 9-24, this is the last window in which the “end of October” claim can be delivered.

2.5 ruyi main repo: vendor naming list updated, ABI probing proposal belatedly noted (10-29 / 10-28)

Date: 2026-10-29　Source: PR #508 vendor naming list, PR #507 ABI probing

#508 “docs: update vendor naming list” refreshed at 16:13; it’s a documentation-side change and the other end of the same effort as ruyi-imager’s switch from “manufacturer” to “vendor” in the UI this period — the installer changed its wording, and the docs-side vendor naming list follows suit to avoid inconsistent terminology between the two.

One proposal missed last period is noted here: #507, submitted 10-28 17:15, adds the ability to “probe host ABI compatibility for a given software package” to ruyi, at 43 files and +4023/−716 — the largest ruyi main-repo PR this month. It works by using the package’s embedded ELF ABI sidecar as a query plan, comparing architecture, ELF class, interpreter, shared libraries, symbol versions, unversioned symbols, and architecture attributes, with results in three states: compatible, incompatible, and undeterminable, plus a new ruyi admin check-abi subcommand; library resolution deliberately avoids loading candidate libraries and does not depend on the Ruyi process’s LD_LIBRARY_PATH. It turns “can this prebuilt RISC-V package install on this machine” from trial-and-error into an explainable check — for a binary-distribution-centric ecosystem like RuyiSDK, this pipeline is worth more than any single package version bump. It remains unmerged.

III. Vector Extensions, Architecture Testing, and Operator Optimization

3.1 The four vector repos remain silent, and the benchmark-side gap persists (10-29 status)

Date: 2026-10-29 (status)　Source: VecIntrinBench, IntrinTrans, FBGEMM, cpuinfo

All four vector-related repositories had zero commits during the window, and their silent durations are unchanged: VecIntrinBench last at 02-13, cpuinfo at 05-20, IntrinTrans at 06-25, and FBGEMM at 07-13. torq-tile last at 04-09, dsh-osc at 09-15, pytorch-ci has no commit records, and harness last at 10-27.

This issue period is exactly where this benchmark is most needed: all three triton-riscv fixes were validated using “number of lit tests passed + number of runtime test cases passed,” and none of them provided comparable numbers on vectorization quality (instruction count, LMUL used, register spill count). In the previous issue, #1014 already showed noise where “the same code differed by 2% between two builds,” so drawing conclusions from on-board throughput was already strained; if the VecIntrinBench side remains unchanged, then going forward “whether an optimization actually improves things” will, for a long time, have to rely on manual reconciliation. This is not a newly introduced problem in this issue, but the three merged changes cast a clearer light on it.

3.2 FlagGems migration has become a defect-discovery mechanism for triton-riscv (10-29)

Date: 2026-10-29　Source: PR #83, PR #58, PR #82, PR #56 FlagGems migration

Looking at the motivations behind the three fixes, their common source is not the test suite but the very act of “moving PyTorch operators onto triton-riscv batch by batch”: the tl.load in unique_dim with real tensor fill values, the loop-carried offset in broadcast_to, and the duplicate-index comparison in the scatter operator—none of these are at the RISC-V instruction level; they fall on the boundary between the lowering layer and the validation layer. Such defects are hard to grow naturally in unit tests—you need a real operator library pressing upward in batch fashion for them to surface.

The methodological value of this is higher than the three fixes themselves: for a RISC-V AI stack that uses Triton as its entry point, the FlagGems migration effectively serves as an “end-to-end acceptance set,” closer to real workloads than the compiler’s lit suite. Conversely, this issue also exposes the mechanism’s single-point dependency—migration PR #56 has not been updated since 09-16, and after the three fixes were merged, the acceptance process instead stalled. If #56 does not advance for a long time, this “defect-discovery mechanism” will fail along with it, and the next batch of defects will only be discovered when other users run into them.

3.3 No new arXiv entries in the window; the two from 10-27 are the latest (10-29 status)

Date: 2026-10-29 (status)　Source: arXiv search

A search filtered by RISC-V plus compiler, vector, and MLIR found no new papers in the window. The two most recent papers retrieved are both from 10-27: SecDMP: Provably Secure Data Memory-Dependent Prefetching and A lightweight C Code Generator for Heterogeneous TinyML Systems. The former relates to secure prefetching on the microarchitecture side, while the latter belongs to edge-side code generation; neither falls directly on the AI stack’s compilation path.

The one closest to this issue’s main thread is still the 10-21 paper Reorienting the Vector Axis: Restructuring FlashAttention for Long-Vector Processors—FlashAttention restructuring on long-vector processors, which belongs to the same class of problem as the 10-28 approach of segmenting decoding attention by 64 lanes with one LMUL 4 group per head; there were no follow-ups within the window.

IV. Buddy Compiler Dynamics

4.1 buddy-server new ABI merged: 56 files, model plugin system switched to a unified interface (10-29)

Date: 2026-10-29　Source: PR #1015, commit 7d2ce844, RAX Packaging and Loading Analysis doc

At 15:08, #1015 “Buddy-server new ABI” was merged: 56 files, +3934/−1661, the largest change in this entire stack for the period. The PR description states only one intent: to update the ABI interface buddy-server uses when parsing RAX files, with the new interface making it easier to support more models in the future; the actual change is far larger than that.

Structurally, it replaces “one set of plugin handles written per modality” with “one unified interface.” Four new runtime headers were added: ServerModelABI.h (392 lines), ServerModelABIConversion.h (179 lines), ServerModelPluginAdapters.h (742 lines), ModelError.h (57 lines); at the same time, the four modality-split implementations AudioTranscriptionModelPluginHandle, EmbeddingModelPluginHandle, MaskedLMModelPluginHandle, ResidentModelPluginHandle and ModelPluginDiscovery were removed, replaced by a 350-line ServerModelPluginHandle plus a 102-line header, with an adapter layer wiring each modality’s old entry points back to the new ABI. BuddyServerApp.cpp alone changed +446/−225, and SimpleHttpServer gained 25 lines (related to request parsing and error reporting).

On the model side, seven directories were rewritten in tandem: the Model and Plugin pairs for bge_m3 (embedding), deepseek_r1, llama31_tt, proteinglm (masked language model), qwen3_vl (vision-language), and whisper (audio transcription) were adjusted in pairs, each pair taking the form of “less written on the C++ side, more written on the common side”—this follows the same line as last issue’s #1010 source reorganization: first separate directories by responsibility, then converge the interfaces into a single layer.

The test side is the most noteworthy part of this change: added ServerModelPluginHandleTest.cpp (325 lines), BuddyServerAbiErrorIntegrationTest.py (184 lines), BuddyServerCapabilityIntegrationTest.py (135 lines), ServerModelConcurrencyFakePlugin.cpp (162 lines), ServerModelDependencyPlugin.cpp (38 lines), and ServerModelErrorFakePlugin.cpp (149 lines), and removed the four modality-specific unit test groups (about 226 lines total). In other words, the focus of testing shifted from “test each modality once” to “the four behavior classes of the unified ABI: errors, capabilities, concurrency, and dependencies,” which actually broadens coverage. On the docs side, RAXPackagingAndLoadingAnalysis.md and Runtime.md were updated as well.

One point to be restrained about: this is an interface refactor, and the PR provides no performance data and no proof of newly supported models; “making it easier to support more models” will only be delivered once the next model is integrated under the new ABI.

4.2 Nightly dev20261029 built before #1015, downstream must wait for the next build (10-29)

Date: 2026-10-29　Source: nightly dev20261029, Releases list, triton-riscv PR #91

Nightly v0.1.3.dev20261029 was released at 08:21, nearly seven hours before #1015 was merged (15:08), so this build does not include the new ABI. To get #1015, one must wait for the dev20261030 build, and then have triton-riscv’s renovate bump the anchor once (#91 is currently anchored at dev20261029 and remains open).

This timing account is worth recording separately, because it is the fixed latency structure of this stack: buddy-mlir merge → next-day nightly build → renovate proposes dependency update → triton-riscv merge. The three hops together typically take one to two days. The 0.1.3 line has gone five consecutive nightlies without a formal release; the most recent formal release is still 0.1.2 from 10-25; an interface change on the scale of #1015, if it is to go through a formal release, will require another round of waiting.

4.3 Three open PRs stalled at 10-28, Whisper and interface alignment both untouched (10-29 status)

Date: 2026-10-29 (status)　Source: PR #1011, PR #1013, PR #994, open PR list

After #1015 was merged, the previous “four open PRs” became three: #1011 (scalable VIR fragment count forced cast to int64), #1013 (reuse preprocessing within a single Whisper transcription), #994 (align buddy-server interface with llama-server). All three were last updated between 10-28 16:01 and 16:01, with no new activity in the window.

Among them, #1011’s situation is somewhat delicate: last issue’s #1012 x64 CI green light was obtained on top of it, yet it remains unmerged; and #1015 has already changed buddy-server’s plugin interface, so whether #994’s “align with llama-server” interface direction will conflict with the new ABI is not discussed in the PR. The open list also includes #993 (tile.upsample_nearest recognition), #1001 and #997 (prefill/decode optimization of Qwen3-0.6B and DeepSeek-R1-Distill-Qwen-1.5B on K3 A100), #995 (contiguous traversal for Cumsum on non-last axes), #992 (bn channel broadcast fix), #938, #932, #928, #924, #838, none of which had updates in the window.

V. Community, Events, and Official Homepage

5.1 Official homepage’s three pages unchanged; two blog posts, twenty-three documentation chapters (10-29 status)

Date: 2026-10-29 (status)　Source: RuyiAI official homepage, Blog, Documentation

The sha256 of the homepage, blog, and documentation pages match the previous issue: 3 entries in the homepage index, 2 blog posts (Triton’s RISC-V adaptation, PyTorch RISC-V CI practices), and 23 documentation chapters. No new blog posts or chapters have been added for several consecutive windows.

The gap with the engineering side persists. This issue has no shortage of material that could be written up as technical blog posts: the “non-uniform semantics” problem behind the three degradation fixes, the refactoring approach for buddy-server’s unified ABI, and the interaction overhaul in ruyi-imager 1.1 — all of which remain confined to PR descriptions and repository documentation. The only entry points presenting this stack to the outside world are still the two articles from September, which does not match the cadence of “commits daily, merges weekly.”

5.2 Two forum posts: RuyiAI summit recap and repost of the XiangShan-Ruyi ecosystem conference (10-29)

Date: 2026-10-29　Source: RuyiAI summit recap #2899, XiangShan-Ruyi ecosystem conference repost #2898, RuyiSDK developer community

The forum has two posts this issue, both published on 10-29. #2899 under the RuyiAI category, “RuyiAI appears at the 6th RISC-V China Summit, sharing AI system software stack practices from RVV to Matrix,” recaps the Shenzhen summit held 10-18 to 10-20: the team introduced the stack’s architecture and ways to participate through Tutorial sessions, poster displays, and booth discussions, and also took part in the concurrent AME technical workshop and the 10-21 RISC-V Hong Kong Day, with topics centered on matrix extensions and software support. The post body is thin, with the substantive content linked out to a WeChat official account article.

#2898 under the news and gossip category reposts a summit report: the afternoon session of the 10-20 XiangShan-Ruyi open source ecosystem forum focused on releasing “for the agent era” RISC-V full-stack hardware and software results, covering server-class chips, AI-native software stacks, processor multithreading architecture, AI-CPU agile development kits, memory consistency optimization, and EDA verification tool adaptation. For RuyiAI, this post provides an ecosystem-position coordinate — “AI-native software stack” is one of the results released side by side at the same forum, belonging to the same batch of narratives as server chips and multithreading architecture.

5.3 One issue of ruyiai-daily; intelligence coverage spans PyTorch, LLVM, Triton, and RISC-V (10-29)

Date: 2026-10-29　Source: ruyiai-daily commit list, daily-news 2026-10-29

ruyiai-daily committed one issue of daily-news-2026-10-29.md at 06:42 (Beijing time) on 10-29, continuing the daily archiving. This issue’s coverage spans five directions: the PyTorch ecosystem, LLVM/MLIR, Triton and TileLang, the RISC-V software stack and products, and AI models and industry. Three items are directly relevant to this repository: the PyTorch 2.15 release (NCCL rewritten as default, MPS extended to FP8), Buddy’s K3 VIR decode attention (i.e., #1014 from 10-28), and ruyi’s host ABI probing proposal (i.e., #507). This intelligence’s retrieval window is 10-28 05:14 to 10-29 06:00, offset by several hours from the daily report window; when citing, label items by their own dates.

5.4 Zero hits in external news; neither openRuyi 2026.10 nor 0.54.0 released (10-29 status)

Date: 2026-10-29 (status)　Source: Google News RSS, openRuyi distribution news page, openRuyi tags

Google News targeted queries (when:3d) in Chinese and English for RuyiSDK, RuyiAI, openRuyi, and the Ruyi community all returned zero hits within the window; the RISC-V topic candidate list also contained no entries related to the Ruyi community, so no external news is included in this issue.

On the distribution side, both versions remain outside the window. The latest article on the openRuyi news page is still the 2026.09 release announcement, and the repository tags stop at 2026.09-experimental, with 2026.10 unreleased; ruyi’s 0.54.0 has only the 09-18 alpha tag. Following the month-end cadence of previous months, the next two or three days are the release window for 2026.10 and 0.54.0, and the next issue needs to watch these two places.

VI. Trend Observations

6.1 Fixes Before Acceptance: Three Fixes Rely on Issues Accumulated During Migration, Not Regression Tests

This period’s three merged fixes expose an ordering problem: fixes came first, acceptance later. The tensor padding for unique_dim, the loop offset in broadcast_to, and the duplicate index in the scatter operator—none of these three defects were found by the compiler’s own tests; they were hit while porting FlagGems operators upward. The fixes were merged, but migration PR #56, which needs them, has sat untouched since 09-16. The result is a batch of “fixes prepared for a certain usage” with no corresponding usage currently running.

The risk in this state is not now but next month: if upstream Triton has cycled through several more rounds by the time #56 resumes, whether the three fixes remain compatible with the new baseline will need re-verification; and if #56 never resumes, this “end-to-end validation set” is effectively stalled, and the next batch of defects will have to wait for external users to hit them. For a stack whose goal is “running real models,” making migration a standing regression (even just a few dozen operators, run once nightly) is more valuable than merging a few more fixes.

6.2 Two Approaches to Branch Governance: llvm Writes Rules and Drops Dry Runs, pytorch Relies on Whole-Branch Replay

On the same day, two branches offered two governance answers. The llvm riscv branch was replayed in full, and what was genuinely new was a contribution guide: it splits “sending code to riscv” into two paths—”open a PR against the maintainer’s working branch” and “open a PR directly against riscv and manually trigger a rebase”—while also deleting the workflow’s dry-run switch: success means push, no preview. The pytorch riscv branch, by contrast, was merely replayed onto upstream 3afdbd3, with the sync bot adding a dependency cache fix, and no process documentation at all.

The two have different cost structures. The llvm branch has a large patch set and many external contributions, so conflicts and history drift are the main costs—hence rules are worth documenting and worth wiring into workflows; the pytorch branch has a small patch set (11 patches), and a single replay by the maintainer costs less than maintaining a process. The removal of dry runs bears watching: while lowering friction, it shifts the risk of “pushing the wrong history” forward to contributors, backstopped by --force-with-lease and status re-checks—the actual effect will show over the next one or two external PRs.

6.3 Distros Ship Monthly at Volume, While the Stack Trio Stalls in Review Month After Month

openRuyi had 76 commits and 10 merges this period, 64 of which were a batch of KDE framework upgrades; ruyi-imager went from 1.0.0 to 1.1.0-rc.1 in seven weeks, a normal cadence; meanwhile, on the other side of “distribution,” the packaging PR #1350 for the RuyiAI trio has been open since 09-21 and is still reworking at the spec-convention level. The difference between the two pipelines is not headcount but maturity: KDE packages have upstream specs to reference and an established version cadence, so repackaging is mechanical; the trio’s specs are written from scratch, having to explain both “why LLVM stays inside the package” and “why %check is empty.”

The lesson for RuyiAI is this: the prerequisite for being swallowed by a distro is that the package itself be sufficiently “conventional.” buddy-mlir bundles its own LLVM, triton depends on the git executable, and tilelang needs to discover the buddy-mlir toolchain—each of these three unconventional points requires its own patch and explanation, and each explanation costs maintainers time to judge. If the trio is to enter a monthly release cadence, converging these three unconventional points into one or two clear packaging conventions (e.g., a unified toolchain provided by buddy-mlir, unified patch stacking via git format-patch) would be less trouble than responding to review comments one by one.

Source Verification Table

Source Verification Result
RuyiAI-Stack org (all repos) pytorch: riscv branch replayed in full with 11 patches, SyncBots bumped to upstream 3afdbd3, main branch’s 20 commits all upstream; llvm-project: riscv branch replayed with 25 patches, new contribution guide (faf4def312, +82/−8), main branch’s 20 commits upstream; triton-riscv: 3 merges (#58, #83, #82), 3 nightly tag refreshes, 1 dependency PR open (#91); tilelang-riscv silent for the fourteenth day; ruyiai-daily one issue; harness, FBGEMM, cpuinfo, VecIntrinBench, IntrinTrans, torq-tile, pytorch-ci, dsh-osc, skills, SyncBots-DeepAgents, caffe, mxnet with no in-window commits
ruyisdk org (all repos) ruyi-imager: 1 commit (version bump to 1.1.0) + v1.1.0-rc.1 pre-release; ruyi main repo: 1 open PR refreshed (#508 vendor naming list), no commits, no new Release (0.53.0 maintained, 0.54.0 only an alpha tag); packages-index, support-matrix, docs, ruyisdk-website, wechat-articles, attached-matrix-extension, ruyici, AME-operator with no in-window commits
openRuyi-Project org openRuyi main repo 76 commits (KDE Frameworks 6.31.0 batch of 64, the other 12 being vkpeak, ecbuild, clang-wrap, Gradio, pyvex, graphql-core, and go package fixes) + 10 PR merges; 15 open PRs updated (including #1350’s first round of code-level review with 18 items, #1514 ollama security update); tags stop at 2026.09-experimental, 2026.10 not released
buddy-compiler org buddy-mlir 1 merge (#1015 new ABI, 56 files +3934/−1661) + nightly v0.1.3.dev20261029; three open PRs stalled at 10-28 (#1011, #1013, #994), plus #992, #993, #995, #997, #1001, #924, #928, #932, #838 with no in-window updates; buddy-benchmark, buddy-examples, compiler-eval, FeGen, gemmini, firesim with no in-window commits
RuyiSDK Developer Community Forum Two posts in window: #2899 “RuyiAI Appears at the 6th RISC-V China Summit” (10-29, RuyiAI category), #2898 “XiangShan Ruyi Ecosystem Conference: RISC-V Full-Stack Hardware and Software Results Released for the Agent Era” (10-29, repost); biweekly progress issue 080 not out
openRuyi distro news page No new articles, the 2026.09 release announcement remains latest; repo tags stop at 2026.09-experimental, 2026.10 not released
ruyi package manager / Releases 0.53.0 maintained, no new alpha or beta (0.54.0-alpha.20260918 remains the most recent); main branch with no commits since 09-25
ruyi-imager / Releases v1.1.0-rc.1 released 10-29 16:02 (pre-release), with four interaction and CLI changes
Official homepage (ruyiai.org) Three pages unchanged: homepage index 3 items, blog 2 posts, docs 23 chapters, sha256 identical to the previous issue
arXiv (RISC-V) No new additions in window; latest are SecDMP and the TinyML C code generator on 10-27, the 10-21 long-vector FlashAttention remains most relevant to RVV
Google News RSS (multiple Chinese and English queries) Zero hits for targeted queries on RuyiSDK, RuyiAI, openRuyi, Ruyi community; RISC-V topic candidates Qwenputer and unrelated Ruyi entries not included

Complete Source List