모니터링 기간: 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 / XuanTie 등 키워드로 필터링하고 커밋 비교 API로 재생과 신규를 구분), openRuyi 커밋 및 PR 병합 통계, ruyi 패키지 매니저와 ruyi-imager의 Release 및 태그, RuyiSDK 개발자 커뮤니티 포럼, ruyiai-daily 데일리 인텔리전스 아카이브, RuyiAI 공식 홈페이지 3페이지 스냅샷, openRuyi 배포판 뉴스 페이지, Google News RSS 중·영문 정방향 쿼리 (프록시 경유).

이번 호 인덱스

  • 오늘의 핵심: Buddy Compiler 0.1.3 정식 버전 출시, 16개 커밋 중 10개가 RVV 가변 벡터화, 릴리스 노트에는 서버 ABI만 기재 (10-31)
    1. 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: 2건 병합, 5건 신규 오픈, 별도로 1건 공식 Triton v3.8.0으로 리베이스 (10-30 ~ 11-01)
      • 1.4 tilelang-riscv: 메인 브랜치 17일째 조용, 오픈 PR은 1건만 남음 (11-01 상태)
    1. RuyiSDK 툴체인과 배포판
      • 2.1 openRuyi: 6개 커밋 전부 10-30에 위치, LLVM 23 및 ollama 보안 업데이트 병합 (10-30)
      • 2.2 openRuyi 심사 중: Prometheus 의존성 배치 13건, box64와 firecracker 대기열 추가 (10-30 ~ 11-01)
      • 2.3 Ruyiai 3종 세트 #1350: 2주째 여전히 spec 규범에 막힘, 10-30에 1회 리프레시 (10-30 상태)
      • 2.4 ruyi 0.54.0: 10월 말 기준 미달, 메인 브랜치에 문서 1건만 병합 (10-30)
      • 2.5 openRuyi 2026.10 미출시, 월간 릴리스 리듬에 공백 발생 (11-02 상태)
    1. 벡터 확장과 연산자 최적화 (VecIntrinBench / IntrinTrans / FBGEMM)
      • 3.1 세 벡터 저장소 이번 기간 전부 조용, 최신 커밋은 각각 02-13, 06-25, 07-13에 정지
      • 3.2 연산자 작업면이 전반적으로 triton-riscv의 강등 경로로 이동 (10-31 ~ 11-01)
      • 3.3 성능 메인라인 #85는 10-18에 정지, 강등 경로의 5건과 리듬 대조 형성
    1. Buddy Compiler 동향
      • 4.1 BUDDY MLIR 0.1.3: 16개 커밋, 136개 파일, 설명에는 ABI 1건만 기재 (10-31)
      • 4.2 야간 빌드와 다운스트림 앵커: 3-hop 지연이 이틀 내 마감, 앵커는 여전히 야간 빌드 (10-31)
      • 4.3 심사 중 3건 0.1.3 미포함, Whisper와 인터페이스 정렬 여전히 미결 (10-31 상태)
    1. 커뮤니티와 활동 및 공식 홈페이지
      • 5.1 공식 홈페이지 3페이지 무변화, 블로그 2편, 문서 23장 (11-02 상태)
      • 5.2 포럼 모니터링 기간 내 신규 게시글 없음, 격주 진행 080호 미출시 (11-02 상태)
      • 5.3 ruyiai-daily 2회, 인텔리전스 범위 PyTorch·Triton·KV 캐시 커버 (10-31, 11-01)
      • 5.4 외부 뉴스 제로 히트, 배포판 측 두 건의 월간 약속 동시 도래 (11-02 상태)
    1. 트렌드 관찰
      • 6.1 정식 버전의 설명과 코드 차집합 괴리, RISC-V 진행이 커밋 이력에 숨겨져 있음
      • 6.2 triton-riscv 「1건 수정 1건 병합」에서 「일괄 심사 제출」로 전환, 검수 측 여전히 부재
      • 6.3 배포판 측 월간 약속 연속 미달, 스택급 패키징 여전히 spec 계층에서 재작업 중

오늘의 핵심: Buddy Compiler 0.1.3 정식 버전 출시, 16개 커밋 중 10개가 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로 가는 하향 변환 경로에 집중된 것이지, 엔드투엔드 모델 성능 데이터가 아니다. 릴리스 노트에도 어떤 벤치마크도 제시되지 않았다. 벡터화 능력이 앞으로 나아갔다는 것은 검증 가능하지만, 얼마나 빨리 돌아가는가에 대해서는 이번 기에 답이 없다.

1. 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까지의 1~2초 안으로 일괄 변경되었고, 작성자 시간은 모두 원래대로 유지되었다. 헤드 커밋은 1867c9b8이며, 메시지는 여전히 [SyncBots] Integrate PyTorch at 3afdbd3이고, 이 동기화 커밋 자체의 작성자 시간은 10-29 12:48이다. 즉, 이번 재생은 베이스라인을 바꾸지 않았으며, 브랜치는 여전히 업스트림 3afdbd3에 머물러 있어 10-29那次 재생의 착점과 동일하다.

10-29那次와 비교하면 차이는 형식뿐이다: 지난 회차는 ‘7일 침묵 후 재생 + 동기화 로봇이 의존성 캐시 수정을 한 건 추가’였고, 이번 회차는 ‘3일 후 다시 한 번 재생, 내용은 그대로’이다. 브랜치의 패치 집합도 변하지 않았으며, 여전히 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 및 테스트 허용 오차 변경이다.

이러한 ‘베이스라인은 그대로, 커밋 시간만 변경’하는 재생은 보통 두 가지 원인이 있다: 첫째는 동일 베이스라인에 대한 서로 다른 패치 순서로 재생하여 충돌 마커를 제거하거나 히스토리를 정리하는 것이고, 둘째는 자동화 작업이 주기에 따라 무조건 재생하는 것이다. 어느 쪽이든 이번 회차 내용에는 증분이 전혀 없으며, 기록할 만한 것은 오직 리듬뿐이다 — 2주 안에 두 번의 전체 브랜치 재생이 있었고, 모두 새로운 업스트림 동기화를 동반하지 않았다.

여전히 주의해야 할 것은 그 어긋남이다: 배포 측의 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: 2건 병합, 5건 신규 개설, 추가로 1건이 공식 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으로 리베이스, 커밋 목록

메인 브랜치에는 모니터링 기간 내 2건이 병합되었으며, 모두 주말에 이루어졌다. 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 사이에 5건을 연달아 개설했으며, 모두 하향 변환과 분석 두 계층에 속한다:

  • #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), 중첩된 제로 스트라이드 처리.

5건의 제목 구성은 매우 정돈되어 있다: Conversion 3건, Analysis 2건이며, 모두 “특정 유형의 정보를 손실 없이 보존한다”는 표현이다. 이는 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가 병합되면 이후 5건의 적용 지점도 모두 한 번씩 이동해야 한다. 이는 #92와 #93~#97이 동시에 큐에 있으면서도 하나의 연속으로 병합되지 않은 이유이기도 하다. 리베이스는 선행 작업이므로 먼저 건드리지 않은 것이다.

1.4 tilelang-riscv: 메인 브랜치 17일째 정적, 열린 PR은 1건만 남음 (11-01 상태)

날짜: 2026-11-01 (상태)　출처: tilelang-riscv 커밋 목록, 열린 PR #4

메인 브랜치의 마지막 커밋은 여전히 10-16 10:52의 “Build Python extension in Buddy CI”이며, 17일 연속 커밋이 없다. 열린 PR은 2건에서 1건으로 줄어 #4 “RVV vector mask and max reduction lowering”(09-28에 중단)만 남았다. 이전의 #2 “Add Codex-compatible RISC-V operator workflow”는 더 이상 열린 목록에 없다.

같은 조직, 같은 기간 동안 triton-riscv는 사흘 만에 두 건을 머지하고 다섯 건을 열었지만, tilelang-riscv는 한 건도 없었다. 이러한 분화가 이미 3주째 이어지고 있어 「주말에는 아무도 없다」는 식으로 더는 설명할 수 없다. 외부에서 볼 수 있는 대체 경로는 하나뿐이다. openRuyi의 python-tilelang-ruyiai 스펙(#1350 세트에 포함)으로, 즉 배포판 산출물로 저장소 반복을 대체하는 방식인데, #1350 자체가 아직 재검토에서 막혀 있다. 두 경로가 동시에 멈춰 있다는 것은 이 컴포넌트가 이번 기간에 어떤 전진 방향도 없다는 것과 같다.

2. 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」이다. 이렇게 「하나의 의존성 그래프를 십여 건으로 나누어 계층별로 제출하는」 방식은 배포판에서 흔히 어쩔 수 없이 택하는데, 한 번에 제출하면 심사자가 분할을 요구하고, 계층별로 나누면 각 건이 독립적으로 빌드 검증될 수 있기 때문이다. 대가는 머지 기간이 길어진다는 것으로, 어느 한 계층이 막히면 뒤의 것들은 들어갈 수 없다.

2번째 군집은 가상화와 바이너리 번역이다: #1561에서 box64(RISC-V에서 x86-64 프로그램을 실행하는 동적 재컴파일러)를 새로 추가했고, #1559에서 firecracker(경량 마이크로 가상 머신)를 새로 추가했으며, #1516에서 qemu-rustsbi(RustSBI 작성자 luojia65가 커밋, 이미 5건의 논의 존재)를 새로 추가했다. 세 건을 겹쳐 보면 동일한 유형의 요구를 가리킨다. 즉 RISC-V 데스크톱에서 비네이티브 소프트웨어와 격리된 워크로드를 실행하는 것이다.

3번째 범주는 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: 2주째 여전히 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 기록이 하나 더 추가되었다. 지난 호에 기록한 18건의 재검토 의견은 모두 spec 작성 방식—BuildOption 사이에 빈 줄을 넣지 말 것, BuildRequires: python3dist(wheel) 누락, Provides는 실제 패키지 이름과 정렬해야 함, 패치는 git format-patch로 생성할 것, 빈 %check에는 주석을 작성할 것—을 가리켰으며, 이번 호에는 새로운 방향성 논쟁이 나타나지 않았다.

09-21에 시작되어 지금까지 이 PR은 이미 6주를 넘겼다. 지난 호에서는 이를 “제로에서 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월 말 기준 불발, 메인 브랜치에는 문서 한 건만 병합 (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이고 10월이 이미 끝났으므로 이 기준은 이미 불발되었으며, 새로운 기준도 제시되지 않았다.

주목할 점은 불발된 방식이다: 릴리스 실패도, 후보 버전 롤백도 아니고, 10월 하반기에는 코드 동작이 거의 없었다. #508은 문서 변경 한 건으로, 10월 말 그 기간 메인 브랜치에는 “릴리스 준비”조차 거의 없었음을 의미한다. 이는 0.53.0 이전의 리듬과 다르다—그때는 alpha, beta, 정식 버전이 연속 3단계였는데, 지금은 첫 단계조차 없다.

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——이 같은 10월 말에 각각 공개 월간 약속을 한 번씩 놓쳤으며, 두 라인의 코드 측면은 정체되었다고 할 수 없다(openRuyi 메인 저장소는 10-30에도 여섯 건의 커밋이 있었고, ruyi는 문서가 병합되었다). 이는 걸림돌이 개발이 아니라 릴리스 자체에 있음을 보여준다. 버전 동결, 공지 작성, 이미지 빌드와 릴리스 프로세스, 이 구간이 최근 두 달 동안 제때 작동하지 못했다.

3. 벡터 확장과 연산자 최적화(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가 거의 9개월간 멈춰 있는 것이 가장 설명이 필요한 지점이다. 벡터 내장 함수 벤치마크 라이브러리가 장기간 갱신되지 않으면, 그것이 측정하는 커버리지는 컴파일러가 실제로 지원하는 집합과 점점 더 멀어진다.

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가 이 누락을 보완한다.

다섯 개의 공통 배경은 같은一件事이다. 이 계층의 정확성은 회귀 테스트가 아니라 「실제 연산자를 가져와 돌려보는 것」으로 드러난다. 3주 동안 누적된 여덟 건(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개 연산자를 전부 이식해도 엔드투엔드 성능은 여전히 3주 전 수준에 머문다는 뜻입니다.

4. Buddy Compiler 동향

4.1 BUDDY MLIR 0.1.3: 16개 커밋, 136개 파일, 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의 커밋 차집합은 「오늘의 핵심」에서 이미 다룬 내용과 서로를 뒷받침하며, 여기서는 핵심에서 다루지 않은 세 가지 관찰을 보충합니다.

첫째, 이번 버전의 파일 범위는 커밋 수보다 큽니다. 16개 커밋이 136개 파일을 건드렸으며, 그중 상당 부분은 #1015의 인터페이스 리팩터링에서 비롯되었습니다(런타임 헤더 4개 추가, 모달리티별로 작성된 플러그인 핸들과 해당 단위 테스트 4조 삭제). 즉 0.1.3은 동시에 두 가지를 담았습니다. 벡터 다이얼렉트의 10건 연속 진전과 70여 개 파일에 걸친 플러그인 체계 정리이며, 두 가지는 시간상 겹쳤지만(VIR 10건은 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 야간 빌드와 다운스트림 앵커: 3단계 지연이 이틀 만에 마무리, 앵커는 여전히 야간 빌드 (10-31)

날짜: 2026-10-31　출처: 야간 빌드 dev20261030, triton-riscv PR #91, Releases 목록

지난 호에서 고정된 지연 구조를 기록했습니다. buddy-mlir 머지 → 다음 날 야간 빌드 → renovate의 의존성 업데이트 제안 → triton-riscv 머지로, 3단계는 보통 하루에서 이틀이 걸립니다. 이번 호에서 이 사슬이 한 차례 완전히 작동했으므로 각 단계의 실제 소요 시간을 확인할 수 있습니다.

#1015는 10-29 15:08에 메인 브랜치에 머지되었고, 야간 빌드 dev20261030은 10-30 08:49에 패키징되었으며(#1015 포함), renovate의 #91은 10-31 13:15에 triton-riscv에 머지되었습니다. 머지에서 다운스트림 확보까지 총 이틀 5분으로, 「하루에서 이틀」이라는 추정과 부합합니다.

다만 앵커의 형태는 바뀌지 않았다. 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. 커뮤니티와 활동과 공식 홈페이지

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, 제6회 RISC-V 중국 서밋 참가)이며, 이는 지난 기에 수록되었다. 직전 정식 보고는 10-26의 079호였고, 080호는 격주 리듬상 11월 상순에 발행되어야 하지만 이번 기에는 아직 나타나지 않았다.

설명이 필요한 것은 포럼의 활발도 분포다. 10-29의 세 게시글(#2897부터 #2899)은 모두 서밋 관련 내용이었고, 이후 나흘간 게시글이 없었다. 서밋 화제가 10월 말의 토론 할당량을 이미 다 써버렸고, 다음 물결은 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의 서밋 참가 보도(Evoletek Intelligence)로, 모니터링 기간 밖이며 루이 커뮤니티와 무관하다. “openRuyi”의 영문 검색은 4월의 오래된 글 하나만 반환했다.

외부에 보도가 없는 것은 2.4, 2.5의 관찰과 충돌하지 않는다. 두 건의 월간 약속 불이행은 모두 “일어나지 않은 일”에 속하므로, 애초에 뉴스가 나올 수 없다. 문제를 실제로 설명하는 것은 내부 신호이다. 패키지 관리자와 배포판이 동시에 10월의 릴리스 윈도를 놓쳤으나, 두 라인 모두 코드 측은 여전히 움직이고 있다.

6. 동향 관찰

6.1 정식 버전의 설명과 코드 차집합의 괴리, RISC-V 진전이 커밋 이력에 숨겨지다

0.1.3 사안의 방법론적 의미는 그 자체보다 크다. 프로젝트의 “대외 설명”과 “실제로 포함된 것”이 장기간 불일치하면, 외부의 판단은 커밋 이력을 역추적하는 수밖에 없다. 이번 회차의 구체적 양상은, 릴리스 노트에는 서버 측 ABI 리팩터링만 적혀 있으나 16건의 커밋 중 12건이 VIR 벡터 계층을 건드렸다는 점이다.

이러한 괴리에는 관성적 비용이 따른다. 다운스트림 입장에서 “업그레이드할지 여부”를 판단하려면 release notes, 커밋 차집합, 의존성 앵커 세 곳을 동시에 봐야 한다. 업스트림 입장에서는 실제로 보이기를 원하는 작업이 마땅히 보여야 할 페이지에 나타나지 않았다. 최근 3개월간 가장 체계적인 벡터화 진전이 블로그, 문서, 릴리스 노트 세 곳 모두에 대응 설명이 없다. “RVV에서 Matrix로”를 내러티브로 삼는 스택이 벡터화 진전을 커밋 이력의 열 줄짜리 제목으로 쓴 것은 낭비이다.

더 실질적인 위험은 리뷰 측에 있다. 버전 설명이 변경의 일부만 다루면, 검토자의 주의도 그 일부에 집중되고, 나머지 변경은 “이미 정식 버전에 포함된” 이후에는 아무도 다시 보지 않게 된다.

6.2 triton-riscv, “한 건씩 수정 후 병합”에서 “일괄 제출”로 전환, 검증 측은 여전히 부재

10-29의 세 건은 “80분 내 연속 병합”이었고, 이번 회차의 다섯 건은 “이틀 내 연속 개설, 아직 미병합”이다. 전자는 유지관리자가 명확한 결함 수정에 대해 빠른 통로를 가지고 있음을, 후자는 새 변경 배치가 아직 그 단계에 이르지 못했음을 보여준다. 두 리듬의 차이는 개발 강도가 아니라 리뷰 대역폭에 있다.

이 다섯 건에 10-29의 세 건을 더하면 3주 동안 동일 유형 수정이 여덟 건 누적되었으며, 모두 다운그레이드 경로의 정보 손실을 지적한다. 이 수치 자체가 신호이다. 이 경로에 체계적인 동등성 검사가 구축되지 않았고, 연산자 하나하나 부딪히고, 부딪힌 후에야 보수하는 방식에 의존할 수밖에 없음을 의미한다. 다운스트림에 가장 가치 있는 일, 즉 FlagGems의 604개 연산자 내보내기를 매일 밤 한 번씩 실행하는 상시 회귀로 만드는 작업은 여전히 이루어지지 않았다. PR #56은 09-16의 정체에서 회복되었으나(10-30 20:50에 한 차례 푸시, 규모가 156개 신규 파일로 확장, 내보내기 항목 468에서 604로), 여전히 오픈 상태이다.

검증이 파이프라인이 아니라 PR 안에 있는 한, “이 연산자 배치가 riscv64에서 돌아가는가”라는 질문은 반복적으로 미뤄질 것이다.

6.3 배포판 측 월간 약속 연속 불이행, 스택급 패키징은 여전히 spec 계층에서 재작업

10월의 마지막 사흘 동안 “배포”와 직접 관련된 두 라인이 동시에 윈도를 놓쳤다. ruyi 0.54.0의 “10월 말” 기준은 불이행되었고, openRuyi의 2026.10 버전은 11-02까지 발행되지 않았다. 두 라인 모두 코드 측이 멈춘 것은 아니다. openRuyi는 10-30에도 여섯 건의 커밋이 있었고, ruyi에는 문서 병합 한 건이 있었다. 따라서 병목은 릴리스 프로세스 자체에 있으며 개발에 있지 않다.

동시에 스택급 3종 세트 #1350은 이미 여섯 번째 주를 넘겼으며, 여전히 spec 규범 계층에서 재작업 중이다. 이 세 가지를 함께 놓으면 동일한 구조적 문제를 가리킨다. 이 생태계의 “만들어내기”와 “내보내기”는 두 가지 역량이며, 전자는 여러 저장소에서 동시에 추진되지만 후자는 최근 두 달간 한 번도 기한 내 완료된 적이 없다.

RuyiAI 입장에서 단기적으로 가장 실질적인 제안은 릴리스 독촉이 아니라, 2.3의 세 가지 비정형 지점(buddy-mlir 자체 LLVM, triton의 git 의존, tilelang의 툴체인 디스커버리 필요)을 패키징 약속으로 문서화하여 #1350의 검토가 매주 동일한 문제들을 재논의하지 않도록 하는 것이다. 왕복 비용을 낮춰야 월간 릴리스 리듬에 진입하는 것을 논할 수 있다.

출처 검증표

출처 검증 결과
RuyiAI-Stack 조직 (전체 저장소) pytorch: riscv 브랜치 11-01 03:00 두 번째 전체 정리 재생 20건, 헤드 커밋 1867c9b8, 베이스라인은 여전히 3afdbd3, 신규 패치 없음; llvm-project: riscv 브랜치 11-01 23:00 재생 26건, A100의 IME/AME 하향(#30, #31) 포함, 비교 인터페이스에서 업스트림 베이스라인에 10-30 커밋이 이미 포함된 것으로 표시; triton-riscv: 2건 병합(#55, #91), 5건 신규 오픈(#93~#97), 1건 리베이스(#92), #56은 10-30 20:50 푸시 재개; tilelang-riscv 17일째 무소식, 오픈 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이 여전히 최신 버전); 메인 브랜치는 문서 커밋 1건뿐
공식 홈페이지(ruyiai.org) 세 페이지 변화 없음: 홈페이지 인덱스 3건, 블로그 2편, 문서 23장, 스냅샷 해시가 이전 회차와 동일
ruyiai-daily 모니터링 기간 내 2회(10-31, 11-01), 기준은 본 보고서와 일치
Google News RSS(중영문 다중 조합) RuyiSDK, RuyiAI, openRuyi, Ruyi RISC-V 대상 검색 결과 없음; “Ruyi” 측 최신은 10-25의 서밋 참가 보도로 모니터링 기간 밖이며 Ruyi 커뮤니티와 무관하여 미수록

전체 출처 목록

23 — https://github.com/openRuyi-Project/openRuyi/pull/1424