보고 기간: 2026년 10월 26일(월)부터 10월 30일(금)까지, 총 5영업일.

자료 출처: 본 간행물의 데일리 RuyiAI 동향 리포트 5회(2026-10-26 ~ 2026-10-30, 각 회차 모니터링 기간은 전일 04:30부터 당일 04:30까지이며, 월요일은 지난 3일간·주말 포함); additionally RuyiAI-Stack, ruyisdk, buddy-compiler 세 조직의 168시간 저장소 점검, openRuyi-Project 메인 저장소의 일별 커밋 및 병합 PR 전수 통계(API 페이지네이션 재확인), RuyiSDK 개발자 커뮤니티와 openRuyi 배포판 뉴스 페이지 이중 출처 재확인, 그리고 RuyiAI 공식 홈페이지 3페이지 스냅샷(점검은 10-31 오후까지 포함).

편집 설명: 이번 주에는 네 가지 주제가 병렬로 진행되었다. 첫째, 벡터화 중간 표현 VIR이 “표현—호출—대조” 3단계를 완료했다: 하룻밤 사이 일곱 건의 커밋으로 확장 가능 벡터를 보완하고, 다음 날 Python 바인딩을 추가했으며, 사흘째에는 K3의 디코드 어텐션 전체를 VIR로 이식하고 보드 상 처리량으로 대조했다. 둘째, 두 riscv 브랜치의 거버넌스 방식이 갈렸다: llvm 쪽은 일일 전체 브랜치 재생을 중단하고 기여 가이드와 자동 리베이스 워크플로를 작성했으며 예행 스위치를 제거했고, pytorch 쪽은 여전히 7일 침묵 후 일괄 재생 방식이다. 셋째, openRuyi 메인 저장소는 이번 주 234건 커밋, 52건 병합 PR, KDE Frameworks 6.31.0을 한 번에 64개 패키지로 배포했으며, 동시에 세 건의 revert로 “패키지 동봉 LLVM IR” 노선을 철회했다. 넷째, 월말 릴리스 창이 빗나갔다: ruyi 0.54.0과 openRuyi 2026.10은 이번 주말까지 모두 미발표 상태다. 위클리 리포트는 데일리 자료 외에 여덟 가지 점검 신규 발견 사항(대부분 데일리 모니터링 기간 이후 또는 주기 경계)을 부록에 추가했다.

1. 주간 주요 뉴스

  • VIR이 사흘 만에 “표현—호출—대조” 완료: 확장 가능 벡터, Python 바인딩, K3 디코드 어텐션 순차 적용: 10-26 22:48부터 10-27 03:22까지 buddy-mlir에서 동일 저자가 연속 일곱 건(#1002 ~ #1008)을 수행해 strip-mining의 vscale 단위 스테핑, 벡터 크기의 VLEN/64 계산, 결과를 반환하는 vir.set_vl의 확장 가능 벡터화, 동적 벡터 행 치환과 인덱스 규약을 한 번에 보완했다; 10-27 22:42에 #1009(12개 파일, +614/−1)를 병합해 VIR에 buddy_mlir.dialects.vir 모듈을 추가, 이전에는 buddy-opt에서만 실행 가능했던 이 방언을 Python에서 직접 생성·하향할 수 있게 했다; 10-28 09:36에 #1014(4개 파일, +476/−14)를 병합해 K3 w4g32의 디코드 어텐션 전체를 VIR로 이식했다. 출처: #1002 vscale 단위 스테핑, #1009 Python 바인딩, #1014 K3 디코드 어텐션

  • K3에서의 대조 세 항목 모두 견고: 수치 비트 단위 일치, 벡터 명령 각 178개, 처리량 구간 중첩: #1014의 커널은 64 lanes로 분할, 단일 헤드는 128개 f32의 LMUL 4 벡터 그룹이며, 하향 목표를 vector-width=128에서 rvv-vlen=1024로 변경하고 확장 가능 벡터를 비활성화했다. q/k 정규화 포함과 미포함 모두 기존 _attn_decode_fn과 비트 단위 일치; 기계어는 두 병렬 본체 각각 178개 벡터 명령, 키-값 루프는 기존 버전 명령과 동일하며 단 두 곳의 오버플로 레지스터 재적재 위치만 달라졌다; K3에서 그리디 디코딩 세 구간 처리량 모두 중첩—63 token 후 28.26~28.49 대 28.10~28.58, 458 token 후 26.82~27.13 대 27.02~27.04, 900 token 후 25.37~25.41 대 25.29~25.77. 저자는 동일 코드의 두 빌드 간 2% 차이가 발생할 수 있음을 명시했다. 출처: #1014, K3 문서

  • llvm riscv 브랜치가 「매일 전체 리베이스 재실행」에서 「규칙 작성」으로 전환: 244줄 자동 리베이스 워크플로에 기여 가이드 추가, 사전 리허설 폐지: 이번 주 첫 이틀 동안 브랜치는 여전히 리베이스 중이었고(10-26 221건 이동, 10-27 237건 이동), 10-28부터 .github/workflows/autorebase.yml(+244/−0)을 추가했으며, 10-29에 다시 RISCV_CONTRIBUTING.md(+82/−8)를 반영하고 워크플로의 dry_run 입력을 삭제했다. 성공하면 작성자 브랜치로 바로 푸시되며 미리보기는 없다. 가이드는 두 가지 기여 경로를 제시한다. 유지관리자가 work/issue-NNN 작업 브랜치를 만들거나, riscv에 직접 PR을 올린 후 수동으로 리베이스를 트리거하는 것이다. 워크플로 충돌은 전부 riscv 측을 취하고, 동등한 패치는 자동으로 폐기하며, PR 코드와 빌드는 절대 실행하지 않는다. 출처: autorebase.yml, RISCV_CONTRIBUTING.md, 커밋 faf4def312

  • triton-riscv 세 건의 다운그레이드 수정이 80분 내에 머지, 동기 전부 FlagGems 연산자 이관에서 비롯: 10-29 15:38부터 16:58까지 #82(해시 테스트용 고유 대상 인덱스, 1개 파일 +23/−3), #83(마스크 로드가 텐서 패딩 값 지원, 4개 파일 +160/−16), #58(루프 전달 gather 오프셋 보존, 2개 파일 +125/−0)이 차례로 머지되었다. #83은 riscv64 머신에서 검증했다. 신규 회귀 세 건의 RUN/FileCheck 모두 통과, 전체 lit 291 통과, 예상 실패 9건, 예상치 못한 실패 0건, 런타임 검사 18항목 통과. 세 건은 각각 82일, 43일, 44일이 지나서야 머지되었으며, 이들을 필요로 하는 이관 PR #56은 당시 여전히 09-16에 멈춰 있었다. 출처: PR #83, PR #58, PR #82

  • openRuyi 이번 주 234건 커밋, 52건 머지 PR, KDE Frameworks 6.31.0 1분 만에 64개 패키지 배포: 베이징 시간 기준 일별 집계로 10-26부터 10-30까지 각각 80, 36, 36, 73, 9건이었으며, 작성자는 Leetfs(87건), KiritakeKumi(65건), misaka00251(17건)이 주를 이뤘다. 10-29 15:11 같은 분에 64개의 kf6-* 패키지가 반영되어 Plasma 6가 의존하는 프레임워크 전체를 거의 커버했다. 이번 주에는 별도로 Samba 제품군 전체를 한 번에 4.25.1로 교체했고(tevent 0.17.2, tdb 1.4.15, talloc 2.5.0 포함, jack2와 rpm-config-openruyi를 Waf 빌드로 전환), qemu 11.1.2와 libvirt 두 건을 백포트했다. 출처: openRuyi 커밋 목록, PR #1513 KDE, PR #1428 Samba

  • RuyiAI 3종 패키지가 「노선 논쟁」에서 「규격 재작업」으로 전환, 빌드 비용이 2.81배로 정량화: PR #1350은 한 번의 커밋으로 buddy-mlir, python-triton-ruyiai, python-tilelang-ruyiai 세 가지 spec을 제출했고, 9-21에 시작된 후 거의 한 달간 중단되었다가 10-27에 작성자가 세 가지 재검토 의견에 하나씩 대응했으며, 10-28에 「GCC로 빌드 전환」을 실측한 결과 8814초에서 24798초로 늘어났다(약 2시간 27분 대 6시간 53분, 해당 빌드는 링크 단계에서 실패). 10-29에 첫 번째 코드 수준 재검토 18건을 받았으며, 모두 spec 작성 방식(누락된 BuildRequires, Provides와 패키지명 정렬, 패치를 git format-patch로 생성해야 함, 빈 %check에는 주석을 작성해야 함)을 지적했다. 이번 주 종료 시점까지 여전히 오픈 상태이며, 규모는 10개 파일, +838/−0. 출처: PR #1350, PR #1352 PyTorch 패키지

  • 월말 약속 미이행: ruyi 0.54.0은 여전히 09-18의 alpha, openRuyi 2026.10 미출시: 격주 진행 상황 079호에서 패키지 관리자 0.54.0을 릴리스 주기 조정으로 10월 말로 변경했으나, 10-31 오후 기준 태그 목록은 여전히 0.54.0-alpha.20260918에 머물러 있고 정식 버전 최신은 09-24의 0.53.0이다. openRuyi 저장소 태그는 2026.09-experimental에서 멈췄고 뉴스 페이지에 2026.10 릴리스 공지가 없다. 메인 저장소의 이번 주 마지막 두 커밋은 10-29의 벤더 명명 목록 문서와 10-30에 병합된 #508이며, 모두 릴리스 작업이 아니다. 출처: ruyi Releases, ruyi 태그, openRuyi 태그

  • pytorch riscv 브랜치 7일간 침묵 후 일괄 재생, SyncBots가 기준선을 업스트림 3afdbd3으로 상향; tilelang-riscv는 14일째에도 커밋 없음: pytorch의 riscv 브랜치는 10-22부터 7일 연속 커밋이 없다가, 10-29 14:06에 기존 11개 패치의 커밋터 시간을 일괄 재작성하여 재생을 완료했고, 20:48에 동기화 로봇이 [SyncBots] Integrate PyTorch at 3afdbd3 한 건을 추가했다(cmake/Dependencies.cmake 한 줄의 FORCE만 변경). tilelang-riscv 메인 브랜치의 마지막 커밋은 여전히 10-16 10:52이며, 오픈 PR #4는 09-28에 갱신이 멈췄고, 이번 주 유일한 존재감은 배포판의 python-tilelang-ruyiai 규격에서 비롯되었다. 출처: pytorch riscv 브랜치, SyncBots 커밋 5a29c201, tilelang-riscv

2. RuyiAI 스택 진행 상황(PyTorch / Triton / TileLang RISC-V 적응)

모니터링 기간 개요: RuyiAI-Stack 조직(18개 저장소)의 이번 주 활동은 llvm-project(처음 이틀간 두 차례 리베이스, 이후 사흘간 거버넌스 자산과 전체 브랜치 재생으로 전환), pytorch(7일 침묵 후 재생), triton-riscv(세 건의 다운그레이드 수정과 두 차례 앵커 업데이트), ruyiai-daily(5회 연속), 사이트 저장소(기여자 데이터 로봇 갱신)에 집중되었다. tilelang-riscv, FBGEMM, cpuinfo, VecIntrinBench, IntrinTrans, torq-tile, pytorch-ci, dsh-osc는 주중 커밋이 없다.

llvm-project riscv 브랜치: 5일간 5회 리베이스 후 중단, 거버넌스 자산이 이어받아

날짜: 2026-10-26 ~ 10-30　출처: riscv 브랜치 커밋 목록, autorebase 워크플로, RISCV_CONTRIBUTING.md

이번 주의 리베이스 시퀀스는 10-25의 474건, 10-26의 221건, 10-27의 237건이었습니다. 세 번의 재적용에서 공통 특징은 일관되었습니다. 선두 제목은 여전히 「[RISCV] Add A100 HP/SP and pack/unpack lowering with calibrated scheduling (#31)」이며, 뒤처진 26건은 정확히 로컬 패치 집합의 개수와 같았고, 항목별로 제목과 순서를 비교한 결과 변경이 없었습니다. 10-27의 경우 20건의 로컬 커밋이 같은 분 안에 재작성되어 재푸시되었으며(커미터 시간이 15:00:29부터 15:00:31에 집중), 작성자 시간은 7월 1일부터 10월 3일까지 분포했습니다. 즉, 이 사흘간의 작업은 기존 패치 집합을 새 베이스라인으로 옮기는 것이었고, 기능 증분은 전부 업스트림에서 왔습니다.

10-28부터 리듬이 바뀌었습니다. 브랜치는 cf00909d 한 건만 앞으로 나아갔으며, 내용은 .github/workflows/autorebase.yml(+244/−0)입니다. 작성자 소스 저장소의 기본 브랜치에 설치되고, workflow_dispatch로 트리거되며, 두 개의 입력은 PR 번호와 「예행 실행만 하고 푸시하지 않음」(기본 활성화)이고, 실행 환경은 ubuntu-24.04, 타임아웃은 90분입니다. 주석은 쓰기 권한을 보유한 상태에서 PR 코드, 훅, 빌드 또는 서브모듈을 절대 실행하지 말 것을 명확히 요구하며, git 설정은 hooksPath, attributesFile, fsmonitor를 모두 /dev/null로 지정합니다. 충돌 처리는 -Xours로 덮을 수 없는 시나리오에 대해 개별적으로 ls-files --unmerged를 수행하고, 2단계가 있으면 로컬을 취하고 없으면 삭제하며, 「동등 패치」를 식별하여 중복된 구 베이스라인 패치를 버릴 수 있습니다.

10-29 23:00의 전체 브랜치 재적용에서 실제로 새로 추가된 것은 [workflows] Push rebased PRs directly and document contribution options(작성자 시간 10-29 09:59) 한 건입니다. autorebase.yml에서 8줄을 삭제하고(dry_run 입력과 예행 실행 브랜치 제거), 82줄의 RISCV_CONTRIBUTING.md를 추가했습니다. 가이드는 두 가지 경로를 제시합니다. 먼저 이슈를 열고 유지관리자가 현재 riscv에서 work/issue-NNN 작업 브랜치를 분기하며 기여자가 작업 브랜치로 PR을 제출하는 방법, 또는 riscv에 직접 PR을 제출하고 수동으로 리베이스를 트리거하면 워크플로가 --force-with-lease와 명시적 기대 SHA를 사용하여 소스 브랜치로 푸시백하는 방법입니다. 문서는 또한 GITHUB_TOKEN으로 푸시하면 일반적으로 후속 push/PR 워크플로가 트리거되지 않으므로, 갱신된 SHA에서 CI가 실행되었는지 수동으로 확인해야 한다고 언급합니다.

판단: 이 브랜치의 일상적 작업은 이전에 이미 완전히 「베이스라인 따라가기」로 변했습니다. 닷새에 다섯 번, 로컬 패치는 전혀 변하지 않았습니다. 이번 주의 새로운 정보는 거버넌스 방식이 바뀌었다는 것입니다. 외부 기여자의 「영원히 한 칸 뒤처지는」 비용을 유지관리자의 수동 판단에서 분리하여, 명확한 경계(PR 코드 미실행, riscv 자체 미변경, 자동 병합 없음)를 가진 스케줄링으로 만들었습니다. 예행 실행을 취소하여 마찰을 낮추는 동시에 「잘못된 이력 푸시」 위험을 기여자에게 전가했으며, 효과는 다음 한두 개의 외부 PR을 거쳐야 검증될 수 있습니다.

llvm-project 업스트림: 17개의 RISC-V pass가 한 시간 만에 NewPM으로 이전

날짜: 2026-10-26　출처: InsertVSETVLI 이전, PreAllocZilsdOpt 이전, DeadRegisterDefinitions 이전

10-26 리베이스로 들어온 221건의 업스트림 커밋 중 RISC-V 관련은 21건이었고, 그중 17건이 NewPM 이식으로, 작성자는 모두 Aiden Grossman이며 시간은 12:59부터 13:55(베이징 시간)까지 한 시간이 채 걸리지 않았습니다. 목록은 백엔드 주요 pass를 망라합니다. 명령 선택 후 VSETVLI 삽입, CSR 읽기/쓰기와 VXRM 쓰기, VMV0 제거, 압축 명령 생성, 스택 푸시/팝 최적화, 베이스 주소 병합, LoadStore 최적화, Zilsd 사전 할당, 분기 최적화와 QCRelax 마킹, 그 외 레지스터 사망 정의 제거, 중복 복사 제거, 간접 점프 추적, 랜딩 패드 설정, 상수 승격이 포함됩니다.

나머지 네 개 커밋은 세 가지 방향에 속한다. vxrm-pipeline-flush 속성은 VXRM의 투기적 쓰기를 플러시 보장이 있는 루프 내로 제한한다. LSR은 Zibi 타깃에서 등가 비교를 루프 종료 조건으로 우선 선택한다. GlobalISel은 G_FPTOSI_SAT와 G_FPTOUI_SAT의 합법화를 보완하여 부동소수점에서 정수로의 포화 변환이 전역 명령 선택 경로에서 사용 가능하게 한다. 또 하나는 수집-산포 하향과 VL 옵티마이저의 분석 사용을 지연 요청으로 변경한다.

의미는 단일 변경에 있는 것이 아니라 파이프라인 귀속에 있다. 이 pass들은 오랫동안 LegacyPM에 매달려 있었는데, NewPM으로 이전한 후 새로운 pass manager의 분석 캐시, pass 순서, 디버깅 인터페이스와 정렬된다. 다운스트림 fork에 대한 직접적 영향은 베이스를 교체할 때마다 이 변경 세트가 따라온다는 것이며, -passes= 이름과 pipeline 구성도 함께 올라간다. 이는 이번 주 riscv 브랜치가 “베이스는 바뀌었지만 패치는 그대로”일 때 실제 내용이 변한 소수의 지점 중 하나이기도 하다.

pytorch: 7일 침묵 후 전체 브랜치 재적용, SyncBots가 베이스를 3afdbd3으로 상향

날짜: 2026-10-29　출처: pytorch riscv 브랜치, SyncBots 커밋 5a29c201, 오픈 PR 목록

riscv 브랜치 헤드는 10-22 03:00 이후 연속 7일간 변화가 없었고, 7개의 오픈 PR(#23, #35, #36, #38, #43, #46, #48)은 업데이트 시간 기준으로 전주 조회 결과 0건이었다. 그중 #46 “RISC-V Vector Extension support for ATen”과 #48 “Add RISC-V Vector CPU capability”는 RVV 기능 상향의 두 가지 주요 제안이며, 상태는 3주 전과 동일하다.

10-29 14:06에 브랜치가 전체 재적용되었다. 11개 기존 패치의 커미터 시간이 14:06:44에서 14:06:45로 일괄 재작성되었고, 작성자 시간은 원래대로 유지되었으며, 패치 세트는 riscv64 로컬 이미지(#51), bytes_to_scalar 부동소수점 수정(#44), inductor opinfo blocklist(#50), linear cross entropy의 ULP 허용 오차(#42)와 CI 시리즈를 유지한다. 20:48의 [SyncBots] Integrate PyTorch at 3afdbd3는 단 한 줄만 변경한다. KINETO_SOURCE_DIR의 cache 변수에 FORCE를 추가하는 것으로, 이는 브랜치 베이스가 업스트림 동기화 봇을 따라 자동으로 전진한다는 의미이다.

메인 브랜치는 같은 기간 매일 약 20개의 커밋이 모두 업스트림 동기화이며, 이번 주 내용은 Dynamo의 VariableTracker 생성 수렴(#200473, #200472, #199832, #199831, #199830, #199829 일괄), CUDA의 max_pool3d 64비트 인덱스 수정과 온라인 softmax 병합의 정확 지수 사용으로 집중되며, RISC-V와 관련된 커밋은 하나도 없다.

함께 읽어볼 만한 것은 배포 측의 불일치이다. openRuyi의 #1352는 이 브랜치의 산출물을 python-torch-ruyiai로 패키징하고 있는데, 해당 PR은 10-27에 멈춰 있고 브랜치 헤드는 이미 새 베이스로 교체되었다. 패키지가 브랜치 산출물 기준으로 빌드된다면 패키지 내에 고정된 소스 위치를 다시 한 번 정렬해야 하며, 이 단계는 현재 어떤 PR도 하고 있지 않다.

triton-riscv: 세 건의 하향 수정 80분 만에 병합, 앵커 두 단계 연속 상향

날짜: 2026-10-27 ~ 10-29　출처: PR #90 앵커 업데이트, PR #83, PR #58

세 갈래가 같은 날 교차했다. 첫째는 의존성이다. 10-27 19:43에 renovate의 #90이 병합되었고(+2/−2), buddy-mlir 앵커가 nightly/v0.1.1.dev20261017에서 nightly/v0.1.3.dev20261027로 곧바로 이동하여 0.1.2 정식 버전과 두 개의 야간 빌드를 건너뛰었다. 이는 10-26 밤의 7개 VIR 확장 가능 벡터 변경이 이번 호부터 다운스트림 빌드 체인에 진입함을 의미한다. 10-28 18:51의 #91은 앵커를 dev20261028로 다시 올렸으나, riscv64 세 개 CI가 대기 중이라 응답이 없어 당일 병합되지 않았다.

둘째는 코드다. 10-29의 세 건 하향 수정이며, 세부 사항은 “이번 주 주요 소식”을 참조한다. 세 건의 검증 깊이는 균일하지 않다. #83은 전체 lit와 18개 런타임 검사를 실행했고, #58은 표적 회귀만 실행했으며, #82는 단일 파일만 실행했다(21개 통과).

세 번째는 상태 불일치입니다. 세 건의 수정이 먼저 반영되었지만, 이를 필요로 하는 마이그레이션 PR #56「Migrate additional FlagGems operators」는 여전히 09-16에 멈춰 있어 주간 내내 병합되지 않았습니다. 열린 PR 중 #55(asin 연산자 프런트엔드 패치)는 10-30 20:14에 병합되었고, #85「softmax 및 matmul 최적화」는 10-18 이후 업데이트가 없습니다. 앵커 업데이트는 「사용 가능 여부」만 해결할 뿐 「이미 사용 중」을 의미하지는 않습니다. 10-28의 야간 빌드는 같은 날 오전의 세 건 병합보다 이르므로, 다운스트림이 #1014와 #1015를 받으려면 야간 빌드 한 버전과 의존성 업데이트 한 건을 더 기다려야 합니다.

tilelang-riscv: 열네 번째 날 무소식, 배포판 경로 하나만 남아

날짜: 2026-10-30 (상태)　출처: tilelang-riscv 커밋 목록, 열린 PR #4, openRuyi PR #1350

메인 브랜치의 마지막 커밋은 여전히 10-16 10:52의 「Build Python extension in Buddy CI」이며, 10-30까지 열네 번째 날 연속으로 커밋이 없습니다. 열린 PR은 두 건입니다. #2는 06-16에 멈춰 있고, #4「RVV vector mask and max reduction lowering」는 09-28에 멈춰 있으며 이번 주에는 업데이트가 없습니다. 같은 시기 triton-riscv에서 세 건이 병합된 것과 직접적인 대조를 이룹니다. 같은 조직, 같은 시기에 한쪽은 성능 저하 결함을 집중 정리하고 있고, 다른 한쪽은 전혀 움직임이 없습니다.

유일한 다운스트림 존재감은 openRuyi의 python-tilelang-ruyiai 스펙에서 나옵니다(#1350 내 4개 패치: Apache TVM FFI 0.1.10 완화, 시스템 빌드 의존성으로 전환, buddy-mlir 툴체인 발견, z3 soname 재작성 건너뛰기). 「배포판 산출물로 저장소 반복을 대체」하는 상태가 세 번째 주까지 이어지고 있으며, 이 라인의 회복 신호는 두 곳을 봐야 합니다. 저장소에 언제 새 커밋이 생기는지, 그리고 해당 패키지가 언제 병합되는지입니다.

3. RuyiSDK 툴체인과 배포판(패키지 관리자, 배포판, 미러 및 지원 매트릭스)

openRuyi 메인 저장소: 234건 커밋, 52건 병합, KDE 프레임워크 64개 패키지 일괄 반영

날짜: 2026-10-26 ~ 10-30　출처: openRuyi 커밋 목록, PR #1513 KDE Frameworks 6.31.0, 병합 PR 목록

커밋 작성자 시간 기준 일별 집계로 10-26부터 10-30까지 각각 80, 36, 36, 73, 9건으로 총 234건입니다. 같은 기간 병합된 PR은 52건이며, 열린 대기열은 지난주 71건에서 58건으로 줄었습니다. 작성자는 주로 Leetfs(87건), KiritakeKumi(65건), misaka00251(17건), Jingwiw(12건), KimmyXYC(11건)입니다.

일별 성격 차이가 뚜렷합니다. 10-26은 보안 정리였습니다. 보안 수정 31건(약 40%), Rust crate 신규 18건, 버전 업데이트 14건으로 48개 패키지에 걸쳐 있으며, 보안 버전을 nats-server 2.15.1, moby 29.9.2, fzf 0.74.5, etcd 3.7.2, containerd 2.4.2로 올렸고, openjdk-latest는 27.0.1.0.2.1로 밀어올리며 소스 체크섬을 갱신했으며, 별도로 sequoia 전체 OpenPGP 도구 세트, fwupd-efi와 Cloudmux 의존성 집합이 저장소에 들어왔습니다. 같은 날 #1512는 Go 메인라인의 Zvk SHA-2 지원을 백포트했으며, 이번 주 유일하게 RISC-V 명령어 집합과 직접 관련된 배포판 변경입니다.

10-27은 연동 업그레이드입니다: Samba 제품군이 동일 시점에 정렬되었습니다(samba 4.25.1, tevent 0.17.2, tdb 1.4.15, talloc 2.5.0, cmocka 2.0.2). 이 세 가지 ABI에 의존하는 모든 패키지는 함께 재빌드해야 합니다. 보안 라인은 #1506이 한 번에 12개 패키지를 가져왔습니다(sysrepo 5.2.27, libzip 1.12.1, libyang 6.4.13, libical 4.0.7, vim 9.2.1201, squashfuse 0.6.5, simdutf 9.3.2, pcre2 10.49, libheif 1.23.6, imagemagick 7.1.2.34, cups 2.4.20, cpp-httplib 0.63.0). 신규 13개 패키지는 Go 생태계가 주를 이루며(go-git 세 건, goldmark-highlighting-v2, go-udev, go-evdev, gonetworkmanager-v2, ghw, go-pinyin, kustomize 등), dms-shell이 패키징된 Go 의존성으로 내장 vendor bundle을 교체하는 것과 동일한 사안의 양면입니다.

10-28은 가상화로 전환합니다: qemu가 11.1.x에서 11.1.2로 업그레이드되고, libvirt 두 건이 백포트되었습니다(/var/lib/libvirt/secrets를 패키지와 함께 배포, Ceph 21에서 auth_supported 제거 후 rbd 풀 무효화 수정). %toolchain_major_version 매크로가 병합되어 gcc-15, gcc-16, clang-22, clang-23 간 전환이 가능합니다. 또한 여러 python 패키지 빌드 수정이 있으며, 그중 scikit-build-core 1.1.1과 cmake의 Python 배포 패키지 메타데이터는 triton, tilelang 같은 CMake 확장의 wheel 빌드 경로에 직접적인 영향을 미칩니다.

10-29는 이번 주기의 정점입니다: 76건의 커밋 중 64건이 KDE Frameworks 6.31.0으로, 모두 15:11 같은 분에 몰려 있습니다. kf6-kcoreaddons, kf6-kconfig부터 kf6-kio, kf6-ksvg, kf6-kwallet까지 Plasma 6가 의존하는 프레임워크 전체를 거의 포괄합니다. 나머지는 Gradio 6.31.0, python-pyvex 10.0.5, graphql-core의 provides 에포크 수정, 신규 vkpeak(Vulkan 피크 성능 및 디바이스 기능 탐지), 그리고 ecbuild의 cmake 모듈 경로 수정, clang-wrap 일일 업데이트, Go 의존성 그래프 정리 세 건(중복 패키지 삭제, import path provides 보충)입니다.

openRuyi 패키징 노선: Samba 연동 업그레이드와 LLVM IR 배포 노선 철회

날짜: 2026-10-27　출처: PR #1509 Revert llvm ir, PR #1428 Samba, PR #1511 dms-shell

지난 몇 회의 openRuyi 키워드는 「보충」이었습니다: 패키지 보충, 보안 보충, Rust crate 보충. 이번 주에 처음으로 명확한 마이너스가 등장했습니다. 15:15에 병합된 #1509는 단 세 건의 커밋에 순삭제 105줄(+5/−105)로, 세 가지 실험적 패키징을 철회했습니다: gsl의 llvmir feature, pixman을 clang으로 빌드하도록 변경하고 패키지와 함께 IR을 산출하던 것, libjpeg-turbo가 LLVM IR을 패키지와 함께 배포하던 것.

PR 본문에는 이유가 적혀 있지 않습니다. 내용으로 보아 방향은 라이브러리를 LLVM IR로 컴파일하여 패키지와 함께 배포함으로써 재최적화나 지연 코드 생성을 위한 인터페이스를 남기는 것이었습니다. 이 노선 전체가 릴리스 전에 철회된 것은 해당 노선이 패키지 크기, ABI 및 디버그 심볼 일관성, 인프라 협조 세 측면에서 연쇄 비용이 단기적으로 이익을 형성하기 어렵다는 것을 보여줍니다. RISC-V 배포판 입장에서 이는 기록할 만한 취사선택입니다: IR 배포는 이론적으로 업스트림 최적화를 재사용할 수 있지만, 이를 뒷받침하는 툴체인이 없으면 비용을 사용자에게 전가할 뿐입니다.

다른 쪽의 플러스는 「연동 업그레이드」입니다: Samba와 세 가지 의존 라이브러리가 동시에 버전을 교체하며, tevent/tdb/talloc ABI에 의존하는 모든 패키지는 함께 재빌드해야 합니다. 이는 배포판에서 가장 전형적인 일괄 작업입니다. 같은 주에 「일관성을 위해 패키지 전반을 재빌드」하는 플러스와 「유지보수성을 위해 실험 노선 하나를 잘라내는」 마이너스가 함께 있었다는 것은, 유지보수의 중심이 「더 많은 패키지 커버」에서 「기존 패키지의 품질 경계 수호」로 이동하고 있음을 보여줍니다.

RuyiAI 3종 패키징: #1350, 노선 논쟁에서 spec 규범 재작업으로 전환

날짜: 2026-10-27 ~ 10-29　출처: PR #1350, PR #1350 리뷰 코멘트

#1350은 이번 주 배포 계층에서 가장 중요한 건입니다. 하나의 PR이 동시에 세 개의 패키지, 즉 buddy-mlir, python-triton-ruyiai, python-tilelang-ruyiai를 추가합니다. 타임라인은 다음과 같습니다. 9-21에 PR 개설(세 건의 커밋이 09:46부터 09:48 사이에 올라감), 9-24에 메인테이너 Z572가 세 가지 수정 요구를 제기, 9-28에 작성자가 두 건을 수정한 뒤 약 한 달간 중단, 10-27 17:55부터 18:54까지 세 건의 답변을 연속 게시하여 항목별로 명확히 설명, 10-28 16:22에 세 건의 커밋을 같은 분에 최신 메인 브랜치로 리베이스, 10-29 16:19부터 16:24까지 첫 번째 코드 수준 리뷰 다섯 건을 수령.

논쟁의 중심이 이동하고 있습니다. 10-27 이전에는 「buddy-mlir에 내장된 LLVM을 외부화할 것인가」였습니다. 작성자가 제시한 근거는 이 패키지들이 항상 특정 LLVM 커밋에 고정되며 LLVM은 해당 패키지 내부에서만 사용되므로, 패키지 내에 두어야 재현 가능하다는 것이었습니다. 또한 triton 업스트림의 setup.py가 git 실행 가능 여부를 강제로 검사하므로, git 빌드 의존성을 추가하거나 setup.py를 패치해야 합니다(후자는 triton 업그레이드 시 무효화됨). 10-28에 작성자는 「GCC 빌드로 전환」의 비용을 수치화했습니다. riscv64에서 8814초가 24798초로, 2.81배가 되며, 해당 빌드는 링크 단계에서 실패하여 완료되지 못했습니다. 이 숫자가 논쟁을 기술적 선호에서 빌드 팜의 일정 산술로 바꾸었습니다. 2.81배는 머신 점유, 타임아웃 정책, 릴리스 윈도우를 모두 재계산해야 함을 의미합니다.

10-29의 리뷰는 기계적 규범으로 전환되었습니다. BuildOption(xxx) 사이에 빈 줄을 넣을 필요가 없다, python-triton-ruyiai에 BuildRequires: python3dist(wheel)이 빠졌다, Provides가 실제 패키지 이름과 정렬되어야 한다, Conflicts: python-%{srcname}의 필요성을 설명해야 한다, 패치는 git format-patch로 생성해야 하며 동일 디렉토리에 참조되지 않은 패치가 있다, 빈 %check에는 이유를 설명하는 주석을 작성해야 한다. 이러한 의견은 보통 「방향이 승인되고 마무리 준비 단계」에 나타납니다. 이번 주 종료 시점 PR 규모는 10개 파일, +838/−0, 리뷰 코멘트 18건, 여전히 열려 있음.

PyTorch 별도 패키지화: #1352의 패치 목록과 RVV 게이팅

날짜: 2026-10-27(상태)　출처: PR #1352, python-torch-ruyiai spec

#1352는 RuyiAI-Stack/pytorch를 별도로 python-torch-ruyiai로 패키징합니다(8개 파일, +783/−0). #1350과 같은 날 개설되고 같은 날 업데이트되었으며, 유일한 커밋은 9-21 11:22에 멈춰 있어 주중 내내 움직이지 않았습니다.

패치 세트는 완전한 배포판 적응 목록으로 읽힙니다. 2001은 OpenBLAS가 cblas 복소수 내적을 사용하도록 강제, 2003은 시스템 fmt로 전환, 2005는 시스템 cmake 의존성으로 전환, 2006은 불필요한 서브모듈 사전 빌드 검사 건너뛰기, 2011은 RVV kernel을 대상 벡터 능력에 따라 게이팅, 2012는 scikit-build-core 내장. 또한 pytorch-smoke-test.py가 첨부되어 설치 후 스모크 테스트를 한 번 실행해야 통과합니다. 2011은 이 중 가장 가치 있는 항목입니다. RVV kernel의 활성화 조건을 「컴파일 시 지원 가정」에서 「대상 벡터 능력에 따른 게이팅」으로 변경한 것으로, RVA20 등 벡터 확장이 없는 대상에서 「패키지는 설치되지만 실행 즉시 크래시」하는 오래된 문제에 정확히 대응합니다. 이러한 수정은 보통 사용자가 보드에서 문제를 겪은 후에야 추가되지만, 이제 패키징 패치에 미리 포함되었습니다.

위험도 명확합니다. 브랜치가 이번 주에야 새 베이스라인으로 전체 재배치되었으므로, 패키지 내에 고정된 소스 위치를 다시 정렬해야 합니다. #1352는 10-27에 멈춰 있어 브랜치 재배치(10-29)보다 이틀 빠릅니다.

ruyi 패키지 관리자: 0.54.0의 월말 약속 미이행

날짜: 2026-10-30(상태)　출처: ruyi Releases, ruyi 태그 목록, ruyi 커밋 목록

격주 진행 079호에서 제시한 기준은 「릴리스 주기 조정으로 인해 0.54.0은 10월 말 릴리스 예상」이었습니다. 10-31 오후 기준, 태그 목록은 여전히 0.54.0-alpha.20260918 이후 새 태그가 없으며, 정식 버전 최신은 09-24의 0.53.0이고, 메인 브랜치는 이번 주에 두 건만 있습니다. 10-29의 「docs: update vendor naming list」와 10-30에 병합된 #508이며, 모두 릴리스 작업이 아닙니다. 09-17 베타, 09-24 정식 버전이라는 이전 라운드의 리듬에 따르면, 0.54.0이 기한을 맞추려면 먼저 베타가 나온 후 릴리스 프로세스에 진입해야 하므로, 이번 주에는 여유가 없습니다.

같은 기간에 기록할 만한 제안과 문서가 두 건 있습니다. #507은 10-28에 제출되어 ruyi에 「주어진 소프트웨어 패키지의 호스트 ABI 호환성 탐지」 기능을 추가합니다(43개 파일, +4023/−716). 방식은 패키지 내 ELF ABI sidecar를 쿼리 계획으로 삼아 아키텍처, ELF class, 인터프리터, 공유 라이브러리, 심볼 버전, 아키텍처 속성을 비교하고, 결과를 호환·비호환·판정 불가의 세 가지 상태로 나누며, ruyi admin check-abi 서브커맨드를 새로 추가합니다. #508의 벤더 명명 목록 갱신과 ruyi-imager가 인터페이스의 「제조사」를 「공급사」로 바꾼 것은 같은 일의 양 끝으로, 두 곳의 명칭이 어긋나지 않게 합니다. 전자는 「미리 빌드된 RISC-V 패키지를 이 머신에 설치할 수 있는가」를 시행착오에서 설명 가능한 검사로 바꾸는 것으로, 바이너리 배포 중심인 RuyiSDK 생태계에서 그 가치는 어떤 단일 패키지의 버전 업데이트보다도 높으며, 현재까지도 머지되지 않았습니다.

ruyi-imager 1.1.0-rc.1, packages-index와 지원 매트릭스

날짜: 2026-10-26 ~ 10-29　출처: ruyi-imager v1.1.0-rc.1, support-matrix K3 Pico-ITX 커밋, packages-index

ruyi-imager는 10-29 16:02에 v1.1.0-rc.1을 릴리스했으며, 1.0.0(09-10)으로부터 약 7주 만입니다. 네 가지 변경은 모두 사용성 다듬기입니다. 이미지 선택 단계에 다운로드 동작 추가(#12), CLI 출력을 터미널 문자 집합에 맞추고 JSON은 UTF-8을 유지(#14), 선택 대화상자에서 더블클릭으로 확인(#19), 선택 대화상자에서 반드시 명시적으로 선택(#21)입니다. 이 중 「더블클릭 확인」과 「반드시 명시적 선택」은 서로 보완하는 제약으로, 전자는 속도를 높이고 후자는 오선택을 막습니다. 릴리스 노트에는 첫 기여자 한 명이 표기되어 있으며, 네 건 중 세 건이 같은 사람에게서 나왔습니다. 이번 주에는 그 외에도 K3 UFS 및 UEFI 플래싱 지원(10-23, 월요일 모니터링 기간 내), 선택 대화상자 더블클릭과 키보드 확인, 인터페이스 용어를 「제조사」에서 「공급사」로 변경하는 등 사전 작업이 있었습니다.

packages-index는 이번 주 단 한 건입니다. 10-26에 revyos의 Milk-V Meles 이미지와 관련 uboot를 20260504로 올렸습니다. 건수가 적은 것은 079호의 설명과 일치합니다. ISCAS 소프트웨어 소스가 최근 2주간 데이터 동기화 문제를 겪어, 이미 빌드가 완료된 패키지가 공용망에 갱신되지 못했고 패키지 목록 쪽에는 자연히 대량 업데이트가 없었습니다. 이로 인해 예상 가능한 어긋남이 생깁니다. 만약 0.54.0이 릴리스되었는데 소프트웨어 소스가 복구되지 않았다면, 사용자가 ruyi update로 보는 내용은 저장소의 실제 상태보다 뒤처지게 됩니다.

지원 매트릭스는 이번 주 세 건의 보고서가 있으며, 작성자는 같지만 결론은 다릅니다. Milk-V Jupiter2의 Bianbu 4.0.1(출하 시 사전 설치 이미지, USB-PD 65W 또는 ATX 2-pin 12V 전원 공급, 첫 부팅 시 설정 마법사 진행), SpacemiT K3 Pico-ITX의 Bianbu 4.0.8(LXQt 변형, 상태 good, 데스크톱 기능 완전하고 블로킹 없음), StarFive VisionFive 2 Lite의 Ubuntu 24.04.5(공식 사전 설치 서버 버전 이미지, SFFB로 fastboot 진입 후 플래싱, USB-to-TTL 시리얼, 상태는 basic에 그침)입니다. 뒤의 두 건은 같은 날 머지되었고 작성자도 같으며, 등급 차이는 현시점 RISC-V 배포판의 실제 사용 가능성이 단순한 커널 지원이 아니라 벤더 이미지의 적응 깊이에 달려 있음을 정확히 보여줍니다.

격주 진행 079호: 릴리스 주기 조정과 개발 중 사항 세 가지

날짜: 2026-10-26　출처: 격주 진행 079호, 079호 파일

079호는 10-26 18:02에 커뮤니티 포럼에 게시되었으며, 보고 기간은 10-22까지로 보고 기간보다 나흘 늦습니다. 패키지 관리자 측의 변화가 가장 직접적입니다. 0.54.0은 릴리스 주기 조정으로 10월 말로 옮겨졌고, 현재 정식 버전은 여전히 0.53.0이며, 커뮤니티 소프트웨어 소스는 상시 유지보수를 유지하고 최근 세 개 정식 버전과의 호환을 약속합니다.

개발 중 사항은 세 가지입니다. 소프트웨어 패키지와 현재 시스템의 ABI 호환성 탐지, 더 많은 공식 유지보수 소프트웨어 패키지의 macOS 패키징, SpacemiT K1/K3 대상 툴체인 적응입니다. 기반 컴포넌트 측에서는 glibc가 sinh, sinhf, sinpi를 libmvec 벡터 수학 프레임워크에 이식했고, newlib은 acosf, logf, asinf, asinhf, asinpif, atanf 여섯 개의 벡터 수학 함수를 보강했습니다. GCC 측은 기본 Zvdota/Zvbdota 지원, Ztt 확장의 Md 지원 추가, 그리고 P 확장 지원을 0.6 버전으로 갱신했습니다. 세 가지 개발 중 사항과 0.54.0의 시간 기준은 함께 다음 호의 관찰 지점을 이룹니다. ABI 탐지는 이미 #507 제안이 있고, K1/K3 적응은 툴체인 패키지 형태를 봐야 하며, macOS 패키징은 비 RISC-V 호스트에서의 사용 가능성과 관련됩니다.

4. 벡터 확장과 연산자 최적화 (VecIntrinBench / IntrinTrans / FBGEMM)

이 스택의 벡터 관련 4개 저장소가 주중 내내 조용했고, 벤치마크 측 공백이 세 건의 수정으로 드러났다

날짜: 2026-10-30 (상태)　출처: VecIntrinBench, IntrinTrans, FBGEMM, cpuinfo

벡터 관련 4개 저장소 모두 주중 커밋이 전혀 없었고, 조용한 기간은 계속 길어지고 있다: VecIntrinBench는 02-13에, cpuinfo는 05-20에, IntrinTrans는 06-25에, FBGEMM은 07-13에 멈춰 있다; torq-tile은 04-09에, dsh-osc는 09-15에 멈춰 있고, pytorch-ci는 커밋 기록이 없으며, harness는 10-27(월요일의 플러그인 분할)에 멈춰 있다.

이번 주에 벤치마크가 가장 필요한 지점이 바로 나타났다: triton-riscv 수정 세 건은 모두 “lit 통과 건수 + 런타임 케이스 통과 건수”로 검증되었고, 벡터화 품질을 비교할 수 있는 수치(명령어 개수, 점유 LMUL, 레지스터 스필 횟수)를 제시한 곳은 한 군데도 없었다; #1014의 성능 대조도 동일한 코드를 두 번 빌드했을 때 2% 차이가 난다는 점을 명확히 인정했다. 보드 상의 처리량으로 결론을 내리는 것 자체가 빠듯한데, 벤치마크 측이 계속 움직이지 않으면 이후 “최적화가 정말로 향상시켰는가”는 장기적으로 수작업 대조에만 의존할 수밖에 없다. 이는 이번 주에 새로 생긴 문제는 아니지만, 세 건의 머지와 한 번의 성능 대조가 이를 더 선명하게 비춰 주었다.

FlagGems 마이그레이션이 triton-riscv의 결함 발견 메커니즘이 되었다

날짜: 2026-10-29　출처: PR #83, PR #58, PR #56 FlagGems 마이그레이션

세 건의 수정 동기를 펼쳐 보면, 공통된 출처는 테스트 스위트가 아니라 “PyTorch 연산자를 한 무리씩 triton-riscv 위로 옮기는” 일 자체다: unique_dim의 실제 텐서 패딩 값을 동반한 tl.load, broadcast_to의 루프 캐리 오프셋, 산포 연산자의 중복 인덱스 비교 — 이 셋은 모두 RISC-V 명령어 계층에 있지 않고, 하강 계층과 검증 계층의 경계에 놓여 있다. 이런 결함은 단위 테스트에서 자연스럽게 자라나기 어렵다 — 실제 연산자 라이브러리가 배치 방식으로 위에서 압박을 가해야만 드러난다.

방법론적 가치는 세 건의 수정 자체보다 높다: Triton을 진입점으로 삼는 RISC-V AI 스택에게 FlagGems 마이그레이션은 사실상 종단 간 검증 집합 역할을 하며, 컴파일러의 lit 스위트보다 실제 부하에 더 가깝다. 반대로 이번 주에는 이 메커니즘의 단일 지점 의존성도 드러났다 — #56은 09-16부터 갱신이 없었고, 세 건의 수정이 머지된 뒤 오히려 수용 절차가 멈춰 버렸다; 장기간 추진되지 않으면 다음 결함 무리는 다른 사용자가 부딪혀야만 발견될 것이다. 주기 말에 긍정적인 신호가 하나 나타났다: #56은 10-30 20:50에 한 차례 갱신이 있었다(부록 참조), 그러나 여전히 머지되지 않았다.

벡터 폭 기준: 1024비트, 헤드당 하나의 LMUL 4 그룹

날짜: 2026-10-28　출처: buddy-mlir PR #1014, llvm 커밋 1811501f, llvm 커밋 ed439f3e

#1014는 커널 하강의 대상 벡터 길이를 1024비트로 정하고 가변 길이 벡터를 사용하지 않도록 요구한다. 따라서 각 헤드(128개의 f32)가 정확히 하나의 LMUL 4 벡터 그룹을 차지하고, 영역 안의 그 vir.shuffle도 그룹 내에서 완료된다 — 크기, 그룹화, 명령어 셋이 동일한 매개변수 집합에 의해 제약되며, 이는 이번 주에 기록해 둘 만한 기술적 기준이다.

이 기준은 업스트림 백엔드와 동일한 사안의 양 끝단이다. 이전 모니터링 기간에 llvm riscv 브랜치에 병합된 #30은 IME 내장 명령을 SpacemiT A100의 점곱 명령으로 낮췄고, #31은 A100에 HP/SP와 pack/unpack의 하향 경로를 보완하고 스케줄링 교정을 수행했다. 하나는 백엔드가 레지스터에 따라 명령 선택과 스케줄링을 하는 것이고, 다른 하나는 커널 표현 계층이 레지스터에 따라 벡터 크기를 정하는 것이다. 현재 두 곳의 파라미터가 서로 제약 관계인지 설명하는 문서가 없고, K3에서 교차 검증도 수행되지 않았다. 다음 단계에서 확장 가능한 벡터로 전환하면(작성자가 다음 변경 사항이라고 이미 밝힘) LMUL 4의 그룹화 가정이 흔들리게 되는데, 이 기준이 함께 조정될지가 가장 주목할 만한 지점이다.

업스트림 검증 및 논문: arch-test 이전 후 30건, arXiv 전 주간 신규 없음

날짜: 2026-10-23 ~ 10-30　출처: riscv/riscv-arch-test 커밋 목록, Sv 스위트 병합 #2981, arXiv 검색

이번 주 점검에서 riscv-arch-test/riscv-arch-test 원래 주소가 404를 반환하며 저장소가 riscv/riscv-arch-test로 이전된 것을 확인했다. 이전된 저장소는 월요일 모니터링 기간(10-23 ~ 10-25)에 30건의 커밋이 있어 전체 모니터링 기간 중 가장 활발한 업스트림 중 하나였다. 한 축은 분산된 스위트를 하나로 병합하는 것(PMP #2996, Exceptions 각 그룹을 통합 스위트로 병합, Sv와 SvSm, SvZicbo, ExceptionsSv를 통합 Sv 스위트 #2981로 병합)과 동시에 CI의 제외 목록을 한 줄에 하나씩 항목으로 변경하는 것이다. 다른 축은 특권 레벨과 가상화의 공백을 보완하는 것(H 확장의 CSR과 명령 스위트 #2982, hypervisor의 M 모드 테스트를 Sm 그룹 #2983에 병합, S와 H 모드의 VS/VU/VS 레벨 인터럽트 #2911, Svinval의 H와 SmH 그룹 #2997, H_Zicntr와 Sm_Zicntr_H의 카운터 활성화와 htimedelta #2998, 그리고 Shcounterenw 등 여섯 가지 S 상태 제약과 네 가지 Zic 기초 제약)이다. 병합과 보완을 동시에 진행한 것은 재편의 목표가 먼저 구조를 정리하고 그 구조에 내용을 채워 넣는 것임을 보여준다. RuyiSDK support-matrix와 각 칩의 규정 준수 판단은 모두 이 테스트를 기준으로 하므로, 이전 자체를 기억해 둘 필요가 있다.

arXiv 측은 전 주간 RISC-V AI 프리프린트가 신규로 없었다. 최신 두 편은 10-27의 SecDMP(데이터 접근 관련 프리페치의 증명 가능한 보안 방안)와 이기종 TinyML을 위한 경량 C 코드 생성기이며, 10-23의 두 편은 개방형 ISA 슈퍼컴퓨팅 노선 비교와 LLM 지원 RISC-V 프로세서 결함 수정이다. 본 주제와 가장 밀접한 것은 여전히 10-21의 《Reorienting the Vector Axis: Restructuring FlashAttention for Long-Vector Processors》로, 긴 벡터 프로세서에서 64 lanes 단위로 분할하고 벡터 축을 재구성하는 접근을 논의하며 #1014와 같은 종류의 문제에 속한다. 다만 모니터링 기간 내 후속은 없었다.

5. Buddy Compiler 동향(buddy-mlir 커밋 및 릴리스)

VIR: 하룻밤 사이 확장 가능한 벡터 7건, 다음 날 Python 바인딩 보완

날짜: 2026-10-26 ~ 10-27　출처: #1002 vscale 스텝, #1007 인덱스 규약 통일, #1009 Python 바인딩

10-26 22:48부터 10-27 03:22까지 같은 작성자가 연속으로 일곱 건(#1002~#1008)을 처리했으며, 모두 [midend][VIR] 접두사가 붙고 동일한 스위치 use-scalable을 중심으로 하며 세 계층으로 나눌 수 있다. 루프와 크기 계층: #1002는 strip-mining의 스텝을 수정했다. 이전에는 vir.set_vl이 결과를 동반하지 않을 때 상수 vector-width를 스텝으로 하는 메인 루프로 낮아졌지만, 매 회차마다 N배 vscale 개의 lane으로 메모리에 접근했기에 vscale이 1보다 크면 이터레이션이 겹쳤다. #1003은 크기 선택이 RVV에서 vscale = VLEN/64로 계산되도록 하여 N과 SEW가 LMUL을 결정하고 더 이상 고정 길이 벡터로 되돌아가지 않게 했다. #1008은 인덱스 벡터에 명시적 폭이 없을 때 발생하는 단언 크래시를 수정했다. 결과를 동반하는 vir.set_vl: #1004는 확장 가능 벡터로 낮아지는 것을 허용하고, #1005는 추가로 다차원 동적 벡터를 지원한다. 메모리 접근과 치환: #1006은 동적 벡터의 행 단위 치환을 위한 vir.shuffle을 추가하고, #1007은 vir.load와 vir.store의 인덱스 규약을 통일했다.

동기는 일반화된 벡터화 개조가 아니라 구체적인 연산자에 의해 강제된 것이다. decode attention에서 RoPE의 rotate_half는 128개 원소의 헤드를 앞뒤 두 반으로 교환한 뒤 부호를 반전해야 하며(즉 [-x[1], x[0]]), 본질적으로 행 단위 치환인데 VIR은 이전에 동적 벡터의 행 단위 치환을 표현할 수 없어 외부에서 고정 길이 벡터로 계산한 뒤 query를 region에 가져와야 했다. 그래서 #1006은 치환을, #1005는 다차원 동적 벡터를, #1007은 인덱스 진입점을 보완했고, 세 건이 합쳐져 「decode attention 전체를 VIR 안에 유지」하는 경로가 되었다.

다음 날 22:42에 병합된 #1009(12개 파일, +614/−1)는 Python 바인딩을 보완했다. 이전에는 VIR에 Python 측 연산자 생성 진입점도, 타입 생성 진입점도 없어 연산자 이름과 타입 설명을 문자열로 수작업 조합해야 했고, 전체 하향도 buddy-opt 실행 파일 하나에서만 실행할 수 있었다. 구현은 ODS 정의 연산자에 C API와 nanobind 확장을 더하는 방식으로, 저장소 내 quant 등 자체 타입을 가진 방언과 동일한 구조를 따르며 Ops, Types, pass 등록 세 부분으로 나뉜다. 이 단계의 의미는 조합 가능성에 있다. 연산자 설명, 형상 추론, 테스트 케이스를 모두 Python 측에서 작성할 수 있어 프런트엔드와 VIR의 연동이 더 이상 C++ 측 훅 추가에 의존하지 않아도 된다.

K3 디코드 어텐션을 VIR로 이관: 수치 비트 단위 일치, 명령어 수 동일, 처리량 구간 중첩

날짜: 2026-10-28　출처: PR #1014, K3 문서 변경, 테스트 파일

#1014는 09:36에 병합되었으며(4개 파일, +476/−14, 그중 커널 264줄, 테스트 152줄, 하향 파이프라인 10줄, 문서 50줄), K3 w4g32 커널의 디코드 어텐션 전체 구간을 VIR 방언으로 이관했다. 이는 처음으로 실제 모델의 커널로 대조한 사례다. 한쪽은 이전에 수작업으로 작성한 RVV 벡터 커널이고, 다른 쪽은 Python으로 조립한 VIR 커널로, 수치를 비교하고 명령어 수를 비교하고 보드에서의 처리량을 비교한다.

구현은 네 계층이다. 구성 계층은 더 이상 연산자와 타입을 수작업 조합하지 않고 buddy_mlir.dialects.vir의 SetVLOp, load, shuffle, fma, reduce를 사용한다. 하나의 work item은 하나의 vir.set_vl 영역이며, 길이는 헤드 차원의 절반(64 lanes)을 취하고, 영역은 해당 헤드의 (max, sum)을 반환한다. 회전 계층은 q를 영역 내에서 로드하고 회전하고 스케일링하며, rotate_half는 하나의 vir.shuffle로 떨어지고, cos/sin은 같은 길이의 두 행 데이터로 저장되어 더 이상 vir.from_vector가 필요 없다. 메모리 뷰 계층은 memref.expand_shape를 사용해 q, KV cache, 출력 및 q의 정규화 가중치를 마지막 차원 기준으로 2×64로 분할한다. 정규화 계층은 Qwen3의 q/k norm에 대해 별도로 1차원 vir.set_vl 영역을 연다. 파이프라인 파라미터는 rvv-vlen=1024, use-scalable=false로 변경되었으며, 기존 _attn_decode_fn은 A210 커널용으로 유지된다.

검증 세 가지: 테스트는 _attn_decode_fn에 대해 비트 단위 비교를 수행하며, 스레드가 있는 경우와 없는 경우, 시작점 0/15/16/37/70을 포함하고, q/k 정규화가 있을 때는 0/37을 포함하며, test_k3_w4_moe.py의 qk_norm 경로도 VIR 커널을 실행하고, check-buddy 239개에 401개를 더한 전부가 통과했다. 기계어는 두 병렬 바디가 각각 178개의 벡터 명령을 가지며, 키-값 루프는 구버전과 완전히 일치하고, 단지 두 곳의 오버플로 레지스터 재적재 위치만 달라졌으며, q의 회전은 두 개의 LMUL 2 절반 그룹에서의 연산에서 vfneg에 레지스터 이동 한 번을 더한 것으로 바뀌었다. K3에서 그리디 디코딩의 세 가지 시퀀스 길이 처리량은 전 구간이 겹친다(수치는 「이번 주 주요 뉴스」 참조). PR은 이것이 이미 닫힌 #998을 다시 하는 것임을 명확히 밝히고 있으며, 재작업의 기반은 그 이후의 네 건(#1000, #1005, #1006, #1009)이므로, 독립적인 최적화가 아니라 앞선 네 건의 토대를 한 번에 부하 테스트한 것이다.

절제가 필요하다: 이번 「성능 동등」은 K3 단일 보드, 그리디 디코딩, 세 구간 시퀀스 길이에서 얻어진 것이며, 작성자도 동일한 코드라도 두 번 빌드하면 2% 차이가 날 수 있다고 명시했다. 이것이 증명하는 것은 VIR이 더 이상 성능 손실을 초래하지 않는다는 것이지, VIR이 이미 수작성 커널보다 우수하다는 것이 아니다. 적용 범위도 커널 하나뿐이며, A210은 여전히 구 함수를 사용하고, MoE, 양자화, 프리필 경로는 아직 건드리지 않았다.

buddy-server 새 ABI: 56개 파일로 모달리티 플러그인을 통합 인터페이스로 수렴

날짜: 2026-10-29　출처: PR #1015, 커밋 7d2ce844, RAX 패키징 및 로딩 분석

15:08에 머지된 #1015(56개 파일, +3934/−1661)는 이번 주 전체 스택에서 변경 범위가 가장 큰 건이다. PR 설명에는 의도가 한 문장뿐이다: buddy-server가 RAX 파일을 파싱할 때 사용하는 ABI 인터페이스를 업데이트하며, 새 인터페이스는 향후 더 많은 모델 지원을 위한 편의를 제공한다.

구조적으로는 「모달리티별로 각각 플러그인 핸들을 작성하는 방식」을 「하나의 통합 인터페이스」로 바꾼 것이다: ServerModelABI.h(392줄), ServerModelABIConversion.h(179줄), ServerModelPluginAdapters.h(742줄), ModelError.h(57줄)를 신설하고, 모달리티별로 분리되어 있던 AudioTranscription, Embedding, MaskedLM, Resident 네 그룹 구현과 ModelPluginDiscovery를 삭제하고, 350줄의 ServerModelPluginHandle과 102줄의 헤더 파일로 교체했으며, 어댑터 계층이 각 모달리티의 구 진입점을 새 ABI로 연결한다. BuddyServerApp.cpp는 단일 파일에서 +446/−225. 모델 측도 bge_m3, deepseek_r1, llama31_tt, proteinglm, qwen3_vl, whisper 여섯 디렉터리의 Model과 Plugin을 쌍으로 동시에 수정했다.

테스트 측에서 가장 주목할 점: ServerModelPluginHandleTest.cpp(325줄)와 ABI 오류, 기능, 동시성, 의존성 네 가지 유형의 통합 테스트를 신설하고, 모달리티별로 작성된 네 그룹의 단위 테스트(약 226줄)를 삭제했다 — 테스트의 중심이 「각 모달리티를 하나씩 테스트」에서 「통합 ABI의 횡단적 동작」으로 옮겨갔으며, 적용 범위는 오히려 더 넓어졌다. 절제가 필요하다: 이것은 인터페이스 리팩터링이며, PR은 성능 데이터를 제시하지 않았고 새 모델 지원을 증명하지도 않았다. 「더 많은 모델 지원을 위한 편의」는 다음에 새 ABI로 통합되는 모델이 나와야 실현된다.

릴리스 리듬: 0.1.2 이후 다섯 개의 야간 버전 연속 출시, 다운스트림 앵커는 계속 상향

날짜: 2026-10-25 ~ 10-30　출처: Releases 목록, 야간 버전 v0.1.3.dev20261030, BUDDY MLIR 0.1.2

0.1.2 정식 버전이 10-25 06:18에 릴리스되었다(릴리스 노트는 비어 있고 자동 프로세스로 생성되었으며, 변경 사항은 커밋 이력에서 역추적해야 함). 이로써 연속 다섯 기간의 중단이 끝났다. 간격은 7일로, 0.1.0에서 0.1.1까지의 이틀 간격보다 일반적인 리듬에 더 가깝다. 이후 야간 빌드는 다시 일일 1회로 복귀했다: 10-26 06:37의 dev20261026(0.1.3 라인의 첫 패키지), 10-27 08:26의 dev20261027, 10-28 07:56의 dev20261028, 10-29 08:21의 dev20261029, 10-30 08:49의 dev20261030, 총 다섯 개로 모두 사전 릴리스로 표시되었다.

패키지 생성과 병합 사이의 시간 차이는 별도로 기록할 가치가 있는데, 이것이 이 스택의 고정 지연 구조이기 때문이다: buddy-mlir 병합 → 다음 날 야간 빌드 → renovate가 의존성 업데이트 제안 → triton-riscv 병합, 이 세 단계는 보통 1~2일이 걸린다. dev20261028은 같은 날 오전의 세 건 병합(#1010 08:54, #1014 09:36, #1012 09:55)보다 앞서므로 K3 디코드 어텐션을 포함하지 않는다. dev20261029는 #1015보다 7시간 앞서므로 새 ABI를 포함하지 않는다. dev20261030에 이르러서야 #1014와 #1015를 동시에 포함한다. 0.1.3 라인은 이미 다섯 개의 야간 빌드 연속으로 정식 버전이 없으며, 최근 정식 버전은 여전히 0.1.2이다. #1015와 같은 규모의 인터페이스 변경이 정식 버전으로 나가려면 한 라운드를 더 기다려야 한다.

6. 커뮤니티와 활동과 공식 홈페이지

격주 진행 상황 079호와 포럼 다섯 개 글

날짜: 2026-10-26 ~ 10-29　출처: 격주 진행 상황 079호, RuyiAI 서밋 회고 #2899, 샹산루이 생태계 대회 전재 #2898

포럼에는 이번 주 다섯 개의 새 글이 올라왔다. 10-26 18:02의 #2895는 격주 진행 상황 079호(보고 기간은 10-22까지)이며, 이번 주 유일한 공식 보고서이다. 다음 호는 2주 리듬에 따라 대략 11월 상순이 될 것이다. 10-27 10:45의 #2896 「lpi4a UEFI」는 사용자가 게시했으며, 1366×768 시스템 스크린샷 세 장과 1920×1440 실사 촬영 세 장을 첨부했다. 본문에 따르면 9월 26일에 이미 업데이트가 있음을 발견하고 한 달을 참은 뒤에야 플래싱했는데, 현재 UEFI에 맞는 RevyOS는 사용할 수 없지만 「적어도 희망은 있다」고 한다. 이 글은 LPi4A 펌웨어 생태계의 실제 병목을 기록한다: UEFI 펌웨어는 플래싱할 수 있지만, 이에 맞는 배포판 이미지는 아직 따라오지 못했다.

10-29의 세 글은 서밋 여파에 집중되었다. #2899 「RuyiAI, 제6회 RISC-V 중국 서밋에 등장, RVV에서 Matrix까지의 AI 시스템 소프트웨어 스택 실천 공유」는 10-18부터 10-20까지의 선전 서밋을 회고한다: 팀은 Tutorial 특별 세션 공유, 포스터 전시, 부스 교류를 통해 스택의 아키텍처와 참여 경로를 소개했고, 같은 기간의 AME 기술 워크숍과 10-21의 RISC-V 홍콩 데이에 참가했으며, 주제는 행렬 확장과 소프트웨어 지원을 중심으로 했다. 글 본문은 다소 빈약하고 실질적인 내용은 위챗 공식 계정 기사로 외부 링크되어 있다. #2898은 샹산루이 오픈소스 생태계 포럼 오후 세션의 보도를 전재한다: 10-20에 「에이전트 시대를 향하여」 RISC-V 소프트웨어·하드웨어 풀스택 성과를 집중 발표했으며, 서버급 칩, AI 네이티브 소프트웨어 스택, 프로세서 멀티스레딩 아키텍처, AI-CPU 애자일 개발 키트, 메모리 일관성 최적화, EDA 검증 도구 적응을 아우른다. RuyiAI 입장에서 이 글은 생태계 좌표를 제시하며, 「AI 네이티브 소프트웨어 스택」은 같은 포럼에서 나란히 발표된 성과 중 하나이다. 또 다른 #2897은 바오윈강이 서밋에서 한 강연 《12년의 인식, 10년의 전망》을 전재한 것으로, 이번 주 데일리 리포트에는 수록되지 않아 이번 호에 보충 수록한다.

공식 홈페이지: 세 페이지 변화 없음, 엔지니어링과 전파의 격차는 계속 벌어져

날짜: 2026-10-30(상태)　출처: RuyiAI 공식 홈페이지, 블로그, 문서

홈페이지, 블로그, 문서 세 페이지의 sha256은 이전 호와 동일하다: 홈페이지 인덱스 3건, 블로그 2편(Triton의 RISC-V 적응, PyTorch RISC-V CI 실천), 문서 23장. 이미 여러 기간 연속으로 새 블로그 글과 장이 추가되지 않았다.

이번 주 기술 블로그 글로 쓸 수 있는 소재는 적지 않다: VIR이 확장 가능한 벡터에서 Python 바인딩, 다시 K3 성능 대조까지 이어지는 전체 체인, buddy-server 통합 ABI의 리팩터링 사고, ruyi-imager 1.1의 인터랙션 개편, ruyi의 호스트 ABI 탐지 제안 등은 모두 PR 설명과 저장소 문서에 머물러 있으며, 그중 #1014의 보드 처리량, 명령 수, 비트 수준 일치라는 세 가지 데이터 자체가 이미 완성된 글 한 편이다. 이 스택을 외부에 보여주는 창구는 여전히 9월의 두 기사뿐으로, 「매일 커밋이 있고 매주 병합이 있다」는 리듬과 맞지 않는다.

외부 뉴스: 지정 조회 전 주간 제로 히트

날짜: 2026-10-30(상태)　출처: Google News RSS, openRuyi 배포판 뉴스 페이지

RuyiSDK, RuyiAI, Ruyi RISC-V, Ruyi 커뮤니티 컴파일러, openRuyi에 대한 중영문 타깃 조회(when:3d 포함)는 전주 다섯 기간 모두 제로 히트였다. 같은 기간 수집된 RISC-V 관련 뉴스는 Ruyi 커뮤니티와 무관하며, 일별 기록은 다음과 같다: MIPS의 RISC-V 플랫폼 설명, Damo Academy XuanTie C950 보도, S2C의 RISC-V 중국 서밋 검증 및 프로토타입 전시, Zhongke Tongliang의 데이터 흐름 지능형 컴퓨팅 제품, deepin의 서밋 데스크톱 생태계 진전, Pharo 14의 RISC-V JIT, Tenstorrent의 15억 달러 E 라운드 투자 완료, Microchip PIC64-HPSC 우주 컴퓨팅 진전. 이 항목들은 본 주제에 속하지 않아 이번 주에는 수록하지 않으며, 외부 참조로만 남긴다.

openRuyi 뉴스 페이지: 10월 두 편 게시 완료, 2026.10 버전은 여전히 미출시

날짜: 2026-10-31 (확인)　출처: openRuyi 뉴스 페이지, Ruyi Firmware 공지, 생태계 인프라 글

이번 주 배포판 뉴스 페이지를 재검토하면서 정정이 필요한 기준을 발견했다: 이전 다섯 기간 데일리 리포트는 모두 “뉴스 페이지 최신 글은 여전히 2026.09 릴리스 공지(9-30)”라고 썼으나, 실제 페이지에는 10월에 두 편이 이미 게시되었으며 모두 2026년 10월 19일 발표로 표기되어 있다——”openRuyi-Project: RISC-V 소프트웨어 생태계의 공공 인프라”와 “openRuyi, Ruyi Firmware 출시: RISC-V 플랫폼에 오픈 UEFI 펌웨어 솔루션 제공”. 두 편 모두 이번 주 이전에 게시되어 본 모니터링 기간의 내용은 아니지만, 배포판의 콘텐츠 측면이 완전히 멈춘 것은 아님을 보여준다. 이전 판단은 “월간 릴리스 공지는 나오지 않았으나 10월에 두 편의 특집 기사가 이미 있다”로 정정해야 한다.

버전 측면의 결론은 변함없다: 저장소 태그는 2026.09-experimental에서 멈춰 있고, 2026.10 릴리스 공지는 나타나지 않았다. 6-30, 7-23, 8-27, 9-30의 월간 리듬에 따르면 10월 버전은 이미 월말 창을 놓쳤으며, 다음 모니터링 기간의 최우선 관찰 항목이 되었다.

7. 트렌드 관찰

VIR은 “표현—호출—대조”를 완주했지만, 결론은 “손실을 도입하지 않음”일 수밖에 없다

지난 세 주 동안 이 주류는 계속 표현력을 보강해 왔다: 10-26 하룻밤 일곱 건의 커밋으로 확장 가능 벡터를 추가했고, 10-27 Python 바인딩을 보강했으며, 10-28에는 K3의 디코딩 어텐션 전체 구간을 그대로 옮기고 보드 상 처리량으로 대조했다. 세 숫자를 합쳐야 이번 주의 의미가 완성된다——수치 비트 수준 일치, 벡터 명령 수 동일(각 178개), 처리량 구간 중첩. 자체 방언은 “돌아가지만 느림”이라는 관문에서 가장 쉽게 막히는데, 이번 주는 최소한 이 관문을 일시적으로 통과했음을 증명했다.

그러나 이를 “VIR이 수작성 커널을 따라잡았다”로 읽으면 지나치다. 정확한 표현은 “K3 디코딩 어텐션 이 구간에서, 고정 벡터 길이 하에서 손실을 도입하지 않았다”이다. 두 가지 공백이 명확하다: 적용 범위는 디코딩 어텐션뿐이며, A210 커널, MoE, 양자화 및 프리필 경로는 건드리지 않았다. 확장 가능 벡터는 명시적으로 비활성화되어 있으며(use-scalable=false), 다음 커밋에서 이를 켜면 벡터 크기가 더 이상 컴파일 시점에 결정되지 않고 LMUL 4의 그룹화 가정이 흔들리게 된다. 그때 수치와 명령 수를 지킬 수 있을지는 재대조가 필요하다. 작성자도 같은 코드를 두 번 빌드할 때의 2% 차이를 PR에 적어 두었는데, 이 정도 규모가 바로 “동등” 결론의 경계를 보여준다.

브랜치 거버넌스의 분기: llvm은 규칙을 쓰고 사전 리허설을 없앴으며, pytorch는 재적용과 동기화 로봇에 의존

같은 달 안에 두 브랜치가 두 가지 답을 내놓았다. llvm의 riscv 브랜치는 패치 집합이 크고(26건) 외부 기여가 많아 충돌과 히스토리 드리프트가 주요 비용이므로, 문서를 쓰고(RISCV_CONTRIBUTING.md) 워크플로를 구성하며(autorebase.yml) “리허설” 단계를 삭제할 가치가 있다——성공하면 바로 푸시하여 마찰을 최소화하고 리스크를 기여자에게 앞으로 넘기며, --force-with-lease와 SHA 재검사로 안전망을 둔다. pytorch의 riscv 브랜치는 패치 집합이 작아(11건) 유지관리자가 직접 한 번 재적용하는 비용이 절차 유지 비용보다 낮으므로, 계속 매일 또는 격일로 브랜치 전체를 재적용하고 동기화 로봇을 추가해 기준선을 업스트림 최신으로 끌어올린다.

두 가지의 공통점은 “로컬 패치 집합이 장기간 불변”이라는 점이다: llvm의 26건, pytorch의 11건 모두 이번 주에 새 기능이 추가되지 않았다. 이 두 브랜치를 추적하는 올바른 방법은 SHA나 커밋 수를 보는 것이 아니라——재적용은 커밋 작성자 시간을 일괄 재작성하고 커밋 수를 업스트림에 따라 부풀린다——패치 제목 집합과 업스트림이 무엇을 가져왔는지를 보는 것이다(이번 주는 17개 pass의 NewPM 이전과 P 확장 isel 보완).

브랜치 거버넌스가 효과를 보는지는 두 가지 검증 가능한 신호로 판단할 수 있다: llvm 쪽은 워크플로 게시 후 외부 PR이 실제로 늘었는지(2주 내에 새 기준선으로 제출하는 사람이 여전히 없다면 병목은 리베이스 도구가 아니다), pytorch 쪽은 재적용이 다시 매일로 안정화되었는지(이번 주는 칠일 침묵 후 한 번 보충한 것으로, 정기적이 아니라 일회성이다)이다.

패키징이 RuyiAI 스택의 실제 병목이 되었고, 논쟁에 가격이 붙기 시작했다

#1350 거의 한 달 동안 논쟁이 이어졌고, 핵심 쟁점은 buddy-mlir가 자체 포함한 LLVM을 외부화할지 여부였습니다. 지난주 입장은 여전히 “GCC를 쓸 수는 있지만 최소 1.5배 시간이 걸린다”는 것이었고, 이번 주 저자는 실측치를 제시했습니다: riscv64에서 8814초가 24798초로 늘어나 2.81배가 되었으며, GCC를 사용한那次는 링크 단계에서 실패했습니다. 논쟁의 성격은 이에 따라 기술적 선호에서 빌드 팜의 일정 산술로 바뀌었습니다—2.81배는 머신 점유, 타임아웃 정책과 릴리스 윈도우를 모두 다시 계산해야 함을 의미합니다.

이 사안이 전체 스택에 주는 시사점은 결론이 아니라 방법에 있습니다: RISC-V 배포판 패키징의 많은 쟁점(벤더링 여부, 툴체인 외부화 여부, IR 동봉 배포 여부)은 결국 “빌드 시간, 이미지 크기, 재현성”이라는 세 가지 측정 가능한 숫자로 귀결됩니다. 같은 주에 openRuyi는 “LLVM IR 동봉 배포” 노선을 철회했고(#1509), #1350은 2.81배로 “LLVM을 패키지 내에 유지”를 지켰습니다. 두 판단의 방향은 반대이지만 근거는 같은 종류의 비용 회계입니다.

더 나아가 보면, #1350의 이번 주 리뷰 의견은 이미 설계 노선에서 spec 작성 방식(누락된 BuildRequires, Provides 정렬, 패치 형식, 빈 %check 주석)으로 옮겨갔습니다. 이는 “배포판이 삼킬 수 있느냐”는 문제가 “패키지 자체가 충분히 관례적인가”로 바뀌었음을 보여줍니다. 세 가지 비관례적 지점—buddy-mlir의 LLVM 자체 포함, triton의 git 실행 파일 의존, tilelang의 buddy-mlir 툴체인 발견 필요—은 각각 패치와 설명이 필요하고, 각 설명마다 메인테이너가 판단하는 시간이 듭니다. 세트가 월간 릴리스 리듬에 들어가길 원한다면, 이를 한두 개의 명확한 패키징 규약(예: 툴체인은 일괄적으로 buddy-mlir가 제공, 패치는 일괄적으로 git format-patch 스택 사용)으로 수렴시키는 것이 리뷰 의견에 하나하나 대응하는 것보다 수월합니다.

월말 약속 집단 지연: 배포판, “월간 물량 확보, 주간 정리” 리듬으로 전환

이번 주 두 개의 월말 약속이 동시에 지켜지지 않았습니다: ruyi 0.54.0은 여전히 09-18의 alpha만 있고, openRuyi 2026.10은 발표되지 않았습니다. 이에 대응하여 openRuyi 메인 저장소의 이번 주 234건 커밋 중에는 KDE 프레임워크 64개 패키지 일괄, Samba 패밀리 연동, qemu 11.1.2와 libvirt 백포트, 12개의 C/C++ 보안 업데이트가 있었습니다—이는 전형적인 “물량 확보와 정리 병행”이며, “버전 컷 전 동결”이 아닙니다.

두 파이프라인의 리듬 차이도 기록할 만합니다: KDE 패키지는 참조할 업스트림 spec과 정해진 버전 리듬이 있어 재패키징이 기계적 작업이므로 하루 만에 64개 패키지를 완료할 수 있었습니다. 반면 RuyiAI 세트는 처음부터 작성한 spec이라 “왜 LLVM을 패키지 내에 두는가”와 “왜 %check가 비어 있는가”를 모두 설명해야 하며, 09-21에 시작해 지금까지도 재작업 중입니다. 배포판의 “월간 물량 확보” 능력과 “새 패키지 수용” 비용은 대칭적이지 않으며, 후자는 패키지 자체가 얼마나 관례적인지에 달려 있습니다.

독자에게 실질적 의미: ruyi 사용자는 10월 말에도 여전히 0.53.0을 받게 됩니다. 0.54.0이 11월 초에 릴리스되더라도 ISCAS 소프트웨어 소스가 복구되었는지 봐야 하며, 그렇지 않으면 ruyi update에서 보이는 패키지 목록이 저장소 실제 상태보다 뒤처집니다. 이 두 가지가 다음 주기의首要 확인 항목입니다.

결함 발견이 단일 진입점에 의존, 수용 체인이 수정 체인보다 취약

이번 주 세 건의 triton-riscv 수정의 공통 출처는 테스트 스위트가 아니라 “FlagGems 연산자를 triton-riscv에 올리는” 작업 자체였습니다: 텐서 채움 값의 마스크 로드, 루프 전달 gather 오프셋, 산포 연산자의 중복 인덱스 비교—세 가지 모두 하강 계층과 검증 계층의 경계에 있습니다. 이런 결함은 컴파일러 자체의 lit 스위트에서는 자라날 수 없으며, 실제 연산자 라이브러리가 배치 방식으로 위로 압박해야 합니다.

순서 문제도 이에 따라 드러났습니다: 수정이 먼저 반영되었지만, 이를 필요로 하는 마이그레이션 PR #56은 09-16에 멈춰 있습니다. 한 배치의 “특정 용도를 위해 준비된 수정”에 당장 대응하는 용도가 돌지 않고 있으며, #56이 재개될 때 Triton 업스트림이 또 몇 차례 바뀌었다면 세 수정이 새 베이스라인과 여전히 호환되는지 재검증해야 합니다. 장기간 재개되지 않으면 이 종단 간 수용 세트는 사실상 정지 상태가 되고, 다음 배치의 결함은 외부 사용자가 부딪히기를 기다려야 합니다. 주기 말에 #56이 한 번 업데이트되었지만(10-30 20:50) 여전히 병합되지 않았습니다—이는 다음 주기에 가장 주목할 지점입니다.

추론은 실행 가능합니다: “실제 모델을 돌릴 수 있는” 것을 목표로 하는 스택에서는 마이그레이션을 상시 회귀(수십 개 연산자라도 매일 밤 한 번 실행)로 만드는 것이 수정을 몇 건 더 병합하는 것보다 가치 있습니다. 툴체인 계층의 증거도 같은 주에 나타났습니다—#83의 검증은 이번 주 세 건 중 가장 견고한 건(리트 291 통과, 런타임 검사 18항목)이며, 그것이 바로 실제 연산자 통합이 가장 깊은 건이기도 합니다.

벤치마크 측 장기 공백, “최적화가 효과적인가”에 답할 수 없게 함

VecIntrinBench는 02-13에, cpuinfo는 05-20에, IntrinTrans는 06-25에, FBGEMM은 07-13에 멈춰 있습니다—벡터 관련 네 저장소 모두 주간 커밋이 0이며, 업데이트 중단 기간은 월 단위입니다. 동시에 이번 주 성능 결론은 K3 보드의 처리량 구간에만 의존할 수 있으며, 저자는 같은 코드를 두 번 빌드하면 2% 차이가 날 수 있다고 명시했습니다. 세 수정의 검증도 통과 수만 제공할 뿐 벡터화 품질에 대한 어떤 지표(명령어 수, 점유 LMUL, 레지스터 스필 횟수)도 주지 않습니다.

이는 이번 주에 새로 생긴 문제는 아니지만, 세 건의 병합과 한 번의 성능 대조가 이를 더 선명하게 비춥니다: “벡터 능력 상향”을 목표로 하는 스택에서 지속적으로 점수를 매기는 벡터 내장 벤치마크가 없으면 이후 최적화가 실제 향상인지 변동인지 판단하기 어렵습니다. 다음 단계에서 진짜 보완해야 할 것은 더 많은 lowering이 아니라, 매일 밤 돌 수 있고 명령어 수와 LMUL을 제공할 수 있는 벤치마크입니다—그렇지 않으면 “성능持平”과 “성능 향상”은 2% 노이즈 아래에서 구분할 수 없습니다.

부록: 자료 및 검증 설명

자료 목록

  • 2026-10-26 호: 모니터링 기간 10-23 04:30 ~ 10-26 04:30 (지난 3일, 토요일과 일요일 포함).
  • 2026-10-27 호: 모니터링 기간 10-26 04:30 ~ 10-27 04:30.
  • 2026-10-28 호: 모니터링 기간 10-27 04:30 ~ 10-28 04:30.
  • 2026-10-29 호: 모니터링 기간 10-28 04:30 ~ 10-29 04:30.
  • 2026-10-30 호: 모니터링 기간 10-29 04:30 ~ 10-30 04:30.
  • 주기 경계 외(10-30 낮부터 10-31 오후)의 동향은 조직 저장소, 릴리스 페이지 및 커뮤니티 출처를 확인한 후 추가 반영하였으며, 「이번 주 추가 반영된 데일리 리포트 외 항목」을 참조.

확인 방식 및 기준

  • 조직 확인(168시간 모니터링 기간): RuyiAI-Stack, ruyisdk, buddy-compiler 세 조직의 커밋, PR 및 릴리스를 대상으로 Atom과 웹페이지 이중 채널을 통해 진행하며 API 제한에 의존하지 않음; 업스트림 fork(PyTorch riscv, LLVM riscv, LLVM main)의 커밋은 RISC-V, RVV, 벡터 확장, XuanTie 관련 키워드로 필터링한 후 수록.
  • openRuyi 메인 저장소 통계: API 전체 페이지네이션 재확인을 거쳐, 모니터링 기간 시작점은 베이징 시간 10-26 00:00(UTC 10-25 16:00), 종료점은 10-30 24:00으로, 총 234건의 커밋을 확인; 「커미터 시간」을 베이징 시간으로 환산한 자연일별 집계는 80, 36, 36, 73, 9. 병합된 PR은 is:merged merged:>=로 검색하여 52건, 오픈 대기열은 58건. 해당 기준은 데일리 리포트 각각의 24시간 모니팅 기간과 다르므로 단일 호 데일리 리포트 수치와 완전히 일치하지는 않음.
  • 주요 저장소 추가 확인: openRuyi-Project의 openRuyi(일별 커밋, PR, 태그), homepage; ruyisdk의 qemu(p-dev, ame-0.6), llvm-project(AME), linux-xuantie-kernel, riscv-gcc, wechat-articles, ruyi, ruyi-imager, packages-index, support-matrix, AME-operator; buddy-compiler의 buddy-mlir; RuyiAI-Stack의 pytorch(riscv 브랜치), triton-riscv, tilelang-riscv, ruyiai-daily, ruyiai-stack.github.io.
  • 커뮤니티 이중 출처: RuyiSDK 개발자 커뮤니티 포럼(최신 주제 목록, 이번 주 5개 게시물)과 openRuyi 배포판 뉴스 페이지(10월 두 편의 특집 기사 날짜 재확인 포함).
  • 공식 홈페이지: www.ruyiai.org 홈페이지, 블로그 페이지, 문서 페이지 세 페이지 스냅샷 및 sha256 비교, 블로그 및 문서 인덱스 항목 첨부(블로그 2편, 문서 23장).
  • 시간 기준: 저장소 커밋은 커미터 시간을 베이징 시간으로 환산; 「매일」류 설명은 연속 달력일 기준; 주기는 2026-10-26부터 2026-10-30까지 5영업일.

이번 주 추가 반영된 데일리 리포트 외 항목

  1. 10-30 20:14, triton-riscv에 #55 「Support asin op via frontend patch」(프런트엔드 패치로 asin 연산자 구현)가 병합되었으며, 이는 10-30 데일리 리포트 모니터링 기간 이후입니다.
  2. 10-30 20:50, triton-riscv의 마이그레이션 PR #56 「Migrate additional FlagGems operators」가 업데이트를 재개했습니다(여전히 오픈 상태). 이는 09-16 이후 첫 번째 움직임입니다.
  3. 10-30 08:49, buddy-mlir가 나이틀리 버전 v0.1.3.dev20261030을 릴리스했으며, 처음으로 #1014(K3 디코딩 어텐션)와 #1015(신규 ABI)를 동시에 포함했습니다.
  4. 10-31 13:15, triton-riscv의 #91이 병합되어 앵커가 nightly/v0.1.3.dev20261030으로 올라갔습니다——세 단계 체인(병합, 나이틀리 빌드, 다운스트림 앵커 교체)이 이번 주 마지막 날에 연결되었습니다.
  5. 10-30 23:00, llvm-project의 riscv 브랜치가 다시 한 번 전체 정리 및 재적용되었으며(25건, 커밋 작성자 시각이 23:00:40부터 23:00:44에 집중됨). 10-31 03:00, pytorch의 riscv 브랜치가 다시 한 번 전체 정리 및 재적용되었으며, 헤드에는 여전히 [SyncBots] Integrate PyTorch at 3afdbd3가 포함되어 있습니다.
  6. 10-30 09:54, ruyisdk/ruyi가 #508 「docs: update vendor naming list」를 병합했습니다. 이번 주 메인 저장소에는 총 두 건의 커밋이 있으며, 여전히 새 버전은 없습니다.
  7. 10-30 12:39, openRuyi의 #1514 「ollama: Update to 0.40.7」가 security-fixes 태그와 함께 병합되었습니다. 같은 날 별도로 clang-wrap 20261030(#1545) 등이 있었으며, 이번 모니터링 기간 합계 234건입니다.
  8. 포럼 #2897 「[전재] 12년의 인식, 10년의 전망: 바오윈강이 2026 RISC-V 중국 서밋에서 논한 오픈소스 칩의 중국 경로」(10-29 게시)는 이번 주 데일리 리포트에 수집되지 않아 이번 호에 추가 수록합니다.
  9. openRuyi 뉴스 페이지 기준 정정: 10월에 이미 두 편의 특집 기사가 게시되었으며(모두 10-19 게시로 표기), 이전의 「최신은 여전히 2026.09 릴리스 공지」라는 표현은 잘못되었습니다. 2026.10 월간 버전 공지는 여전히 나타나지 않았습니다.

출처 검증표

출처 검증 결과
RuyiAI-Stack 조직 (전체 저장소) pytorch: riscv 브랜치 7일간 정적 (10-22~10-28), 10-29 14:06 전체 브랜치 재적용 11건, 20:48 SyncBots가 업스트림 3afdbd3으로 리베이스, 메인 브랜치는 매일 약 20건 전부 업스트림; llvm-project: riscv 브랜치 10-26, 10-27 두 차례 리베이스 (베이스라인 221, 237건 전진), 10-28 autorebase 워크플로 추가, 10-29 재적용 및 기여 가이드 신규 추가, 업스트림 RISC-V pass 17개 NewPM으로 이관; triton-riscv: 하향 수정 3건 병합, 앵커 업데이트 2회 (#90 병합, #91 당일 미병합); tilelang-riscv 14일째 정적; ruyiai-daily 5회; FBGEMM, cpuinfo, VecIntrinBench, IntrinTrans, torq-tile, pytorch-ci, dsh-osc 커밋 없음
ruyisdk 조직 (전체 저장소) ruyi-imager: v1.1.0-rc.1 프리릴리스 (10-29), 이번 주 추가로 UFS/UEFI, 다이얼로그 상호작용, 용어 통일 등 선행 커밋; ruyi 메인 저장소 2건 (벤더 명명 목록 문서, #508 병합), 신규 버전 없음, 0.54.0은 alpha 태그만; packages-index 1건 (revyos Milk-V Meles 이미지 및 uboot 20260504로 리베이스); support-matrix 보드 리포트 3건 (Jupiter2 Bianbu 4.0.1, K3 Pico-ITX Bianbu 4.0.8 good 평가, VisionFive 2 Lite Ubuntu 24.04.5 basic 평가); wechat-articles, ruyisdk-website, docs, AME-operator 모니터링 기간 내 커밋 없음
openRuyi-Project 조직 메인 저장소 234건 커밋, 52건 병합 PR, 58건 오픈; 분류로는 KDE Frameworks 6.31.0 배치 64건, Samba 전반 연동, 12개 패키지 보안 업데이트, qemu 11.1.2, libvirt 2건, revert 3건 (LLVM IR 배포 회수), Go 생태계 신규 패키지 13개, vkpeak 수록; 태그는 2026.09-experimental에서 멈춤, 2026.10 미출시
buddy-compiler 조직 buddy-mlir: VIR 7건 (#1002~#1008), Python 바인딩 #1009, buddy-server 소스 재구성 #1010, Whisper x64 CI #1012, K3 디코딩 어텐션 #1014, 신규 ABI #1015; 정식 버전 0.1.2 및 나이틀리 5개 (dev20261026~dev20261030); 오픈 PR 3건 10-28에 업데이트 중단 (#1011, #1013, #994)
riscv/riscv-arch-test 기존 riscv-arch-test 조직 경로는 404, 저장소는 riscv 조직으로 이전; 월요일 모니터링 기간 (10-23~10-25) 30건 커밋, 주로 스위트 병합 및 H 확장 보완
RuyiSDK 개발자 커뮤니티 포럼 이번 주 5개 글: 079회 (10-26), lpi4a UEFI (10-27), RuyiAI 서밋 회고 및 샹산 루이 생태계 대회 전재, 바오윈강 연설 전재 (모두 10-29); 080회 미게시
openRuyi 배포판 뉴스 페이지 10월 특집 기사 2편 (모두 10-19 게시 표기); 월간 릴리스 공지는 여전히 2026.09 (9-30), 2026.10 미출시; 저장소 태그는 2026.09-experimental에서 멈춤
ruyi 패키지 매니저 / 태그 0.53.0 유지, 0.54.0은 09-18 alpha만 존재; 메인 브랜치 이번 주 커밋 2건; “10월 말 릴리스” 약속은 10-31까지 이행되지 않음
ruyi-imager / Releases v1.1.0-rc.1 10-29 16:02 게시 (프리릴리스), 상호작용 및 CLI 변경 4건 포함
공식 홈페이지 (ruyiai.org) 3개 페이지 변화 없음: 홈 인덱스 3건, 블로그 2편, 문서 23장, sha256 이전 회차와 동일
IREE 업스트림 모니터링 기간 내 커밋에 RISC-V 전용 변경 없음
arXiv (RISC-V) 주중 신규 없음; 최신은 10-27의 SecDMP 및 TinyML C 코드 생성기, 10-21의 장벡터 FlashAttention이 여전히 RVV에 가장 부합
Google News RSS (중영문 다중 그룹) RuyiSDK, RuyiAI, 루이 RISC-V, openRuyi 타깃 검색 주중 5회 전부 0건; 동기 RISC-V 뉴스는 루이 커뮤니티와 무관, 미수록

전체 출처 목록

riscv PR #56 FlagGems 연산자 이관 — https://github.com/RuyiAI-Stack/triton-riscv/pull/56

ir K3 문서 — https://github.com/buddy-compiler/buddy-mlir/blob/main/docs/K3DeepSeekR1.md

데이터 출처: 일일 RuyiAI 동향 보고서(2026-10-26~2026-10-30 총 5회) 및 이번 주 보강 검증(조직 저장소, 커뮤니티 이중 출처, 공식 홈페이지); 보고 기간은 2026-10-26~2026-10-30입니다.