모니터링 기간: 2026-10-29 04:30 ~ 2026-10-30 04:30(베이징 시간, 지난 24시간), 이전 기간(10-29 04:30 기준점)과 앞뒤로 연결됨.

출처: GitHub 조직 전체 저장소 점검(RuyiAI-Stack, ruyisdk, openRuyi-Project, buddy-compiler, 저장소별로 모니터링 기간 내 커밋, PR 및 Release 확인; 업스트림 fork는 RISC-V / RVV / XuanTie 등 키워드로 필터링), openRuyi 커밋 및 PR 병합 통계, ruyi 패키지 관리자와 ruyi-imager의 Release, RuyiSDK 개발자 커뮤니티 포럼, ruyiai-daily 데일리 인텔리전스 아카이브, RuyiAI 공식 홈페이지 3페이지 스냅샷, arXiv 검색, Google News RSS 중영문 타깃 쿼리(프록시 경유).

이번 호 인덱스

  • 오늘의 핵심: triton-riscv 하루에 세 건 병합, 전부 FlagGems 연산자 이전 과정에서 드러난 저하 결함에서 비롯(10-29)
    1. RuyiAI 스택 진척(PyTorch / Triton / TileLang RISC-V 적응)
      • 1.1 pytorch: riscv 브랜치 7일째 조용히 종료, 전체 브랜치 재적용 후 업스트림 3afdbd3으로 상향(10-29)
      • 1.2 llvm-project: riscv 브랜치 전체 재적용, 기여 가이드 추가 및 예행 스위치 해제(10-29)
      • 1.3 triton-riscv: 세 건의 저하 수정 80분 내 병합, 의존성 업데이트는 여전히 열림(10-29)
      • 1.4 tilelang-riscv: 메인 브랜치 14일째 조용(10-29 상태)
    1. RuyiSDK 툴체인 및 배포판
      • 2.1 openRuyi: 76건 커밋, 10건 병합, KDE Frameworks 6.31.0 한 번에 64개 패키지 전개(10-29)
      • 2.2 openRuyi 패키징 영역: vkpeak 수록, cmake 모듈 경로 수정, clang-wrap 일일 업데이트(10-29)
      • 2.3 openRuyi 심사 중: #1350 1차 코드 레벨 재검토 18건, ollama 보안 업데이트 병합 대기(10-29 상태)
      • 2.4 ruyi-imager 1.1.0-rc.1 출시, ruyi 0.54.0은 여전히 beta 없음(10-29)
      • 2.5 ruyi 메인 저장소: 벤더 명명 목록 업데이트, ABI 탐지 제안 보충 등록(10-29 / 10-28)
    1. 벡터 확장, 아키텍처 테스트 및 연산자 최적화
      • 3.1 벡터 4개 저장소 계속 조용, 벤치마크 측 공백 여전(10-29 상태)
      • 3.2 FlagGems 이전이 triton-riscv의 결함 발견 메커니즘이 됨(10-29)
      • 3.3 arXiv 모니터링 기간 내 신규 없음, 10-27 두 편이 최신(10-29 상태)
    1. Buddy Compiler 동향
      • 4.1 buddy-server 신규 ABI 병합: 56개 파일, 모델 플러그인 체계를 통합 인터페이스로 변경(10-29)
      • 4.2 야간 버전 dev20261029가 #1015보다 먼저 출시, 다운스트림은 다음 버전 대기 필요(10-29)
      • 4.3 심사 중 세 건은 10-28에 정체, Whisper와 인터페이스 정렬 모두 미동(10-29 상태)
    1. 커뮤니티 및 행사 및 공식 홈페이지
      • 5.1 공식 홈페이지 3페이지 무변화, 블로그 2편, 문서 23장(10-29 상태)
      • 5.2 포럼 2개 글: RuyiAI 정상회의 회고와 Xiangshan Ruyi 생태계 대회 전재(10-29)
      • 5.3 ruyiai-daily 1회, 인텔리전스 범위는 PyTorch, LLVM, Triton 및 RISC-V 포함(10-29)
      • 5.4 외부 뉴스 히트 없음, openRuyi 2026.10과 0.54.0 모두 미출시(10-29 상태)
    1. 트렌드 관찰
      • 6.1 수정이 검수보다 먼저: 세 건의 수정은 회귀 테스트가 아니라 이전 과정에서 쌓인 이슈 티켓에 의존
      • 6.2 브랜치 거버넌스의 두 가지 방식: llvm은 규칙을 쓰고 예행을 해제, pytorch는 전체 브랜치 재적용에 의존
      • 6.3 배포판은 월 단위로 물량 전개, 스택 레벨 3종 세트는 월 단위로 심사 지연

오늘의 핵심: triton-riscv 하루에 세 건 병합, 전부 FlagGems 연산자 이전 과정에서 드러난 저하 결함에서 비롯(10-29)

날짜: 2026-10-29　출처: PR #58, PR #83, PR #82, 커밋 목록

15:38부터 16:58까지의 80분 동안 triton-riscv 메인 브랜치에 세 건의 커밋이 연속으로 병합되었으며, 작성자는 모두 maochuanjun이고 모두 동일한 계층, 즉 Triton에서 구조화/비구조화 IR로의 하향 경로를 수정한 것이다. 이는 시간적으로 결코 평범하지 않다. 해당 저장소의 이전 비의존성 업데이트 코드 커밋은 10-09의 #86이었고, 그 사이 20일 동안은 renovate의 야간 버전 앵커만 있었으며, 이 세 건 자체는 각각 82일, 43일, 44일이 지나서야 병합되었다.

세 건은 각각 하나의 구체적인 결함을 겨냥한다. #83(16:38, 4개 파일, +160/−16)은 비균일 텐서 패딩 값을 가진 마스크 로드를 수정한다. 즉 tl.load(ptr, mask=mask, other=cur) 같은 표기법이다. 원래 구현은 스칼라 또는 splat 패딩 값만 인식했고, 실제 텐서를 만나면 스칼라 추출 단계에서 막혀 하향된 IR에 지원되지 않는 포인터 연산이 남았다. 수정 방식은 구조화 로드와 비구조화 gather 두 경로 모두에서 텐서 패딩을 지원하고, arith.select(mask, loaded, other)로 미스 채널을 복원하며, 동시에 스칼라 추출 실패를 오류 없이 허용하여 처리 권한을 호출자에게 돌려주는 것이다. #58(16:58, 2개 파일, +125/−0)은 루프 캐리 gather 오프셋 손실을 수정한다. scf.for 안에서 캐리되는 텐서가 구조화 형태를 벗어나면 보조 상태에 중립적 플레이스홀더만 남아, 이를 사용해 루프 결과를 재구성하면 gather/scatter가 연속적인 tts.make_tptr로 붕괴되어 루프에서 누적된 오프셋이 모두 사라진다. 수정 방식은 분석된 피연산자가 실제로 scf.for의 결과인지 먼저 검증하고, 맞으면 원본 루프 결과를 오프셋으로 직접 유지하며, 새로운 loop_result_gather.mlir 회귀 테스트를 추가하는 것이다. #82(15:38, 1개 파일, +23/−3)은 scatter 테스트의 비결정성을 수정한다. 원래 테스트는 무작위 인덱스를 사용하고 대상 위치 중복을 허용했으며, 비축소 scatter에서는 어떤 소스 값이 승리하든 합법인데도 단일 PyTorch CPU 결과로 정확히 비교했다. 수정 방식은 1D, 2D 및 제자리 비교를 고유 대상 인덱스로 변경하고, 6개의 중복 인덱스 사례(512, 1023, 1024 세 가지 길이, 제자리와 비제자리 각 한 그룹)를 추가하며, 승리한 값이 올바른 대상의 소스 집합에서 나왔는지, 미스 대상이 원래 값을 유지하는지만 검증하는 것이다.

세 건의 동기는 모두 PR 설명에 적혀 있으며, 모두 동일한 지점을 가리킨다. FlagGems 연산자 이전이다. #83은 unique_dim 구현을 지원하고, #58은 broadcast_to를 지원하며(해당 커널은 이전에 이 오컴파일을 우회하기 위해 range(MAX_DIMS)를 tl.static_range로 바꿨다), #82는 이전 과정에서 scatter 연산자 비교 실패로 인해 역으로 이끌어낸 테스트 수정이다. 즉, 이 세 건은 회귀 테스트가 발견한 결함이 아니라, “한 배치의 PyTorch 연산자를 triton-riscv 위에서 실행”하려는 작업이 강제로 드러낸 결함이다.

검증 강도는 기록할 만하다. #83은 RuyiAI 관련 riscv64 머신에서 검증했다고 명시되어 있다. 새 회귀 테스트의 세 가지 RUN/FileCheck가 모두 통과했고, 전체 lit 291개 통과, 9개 예상 실패, 0개 예상치 못한 실패, 텐서 패딩 런타임 검사 18개 통과(구조화 및 gather 두 경로, float32/float64/int64, 빈 마스크/부분 마스크/전체 마스크, 음의 영, NaN 및 불법 미스 gather 오프셋 포함), 업데이트된 unique_dim과의 통합 23개 통과. #58은 특정 TritonToStructured 회귀 테스트만 실행했고, #82는 해당 테스트 파일만 실행했다(21개 통과). 세 건의 검증 깊이는 고르지 않으며, 앞의 두 건은 국부적이고 세 번째는 단일 파일에 치우쳐 있다.

인과 순서에 대해서는 자제가 필요하다. 수정이 먼저 반영되었지만, 이 수정이 필요한 이전 PR #56은 여전히 09-16에 멈춰 있으며, 열려 있고 병합되지 않았다. 이는 세 건이 병합된 후 broadcast_to의 tl.static_range 우회를 철회할 수 있고 unique_dim을 원래 작성법대로 제출할 수 있지만, “전체 연산자 배치가 riscv64에서 실행 가능한가”라는 질문은 이번 호에서 답이 없다는 것을 의미한다. #56이 다시 진행되어야 검증할 수 있다.

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

1.1 pytorch: riscv 브랜치 7일째 조용히 종료, 전체 브랜치 재생 후 업스트림 3afdbd3으로 상향 (10-29)

날짜: 2026-10-29　출처: pytorch riscv 브랜치, SyncBots 커밋 5a29c201, PR #51, PR #44

7일 연속 커밋이 없던 후, riscv 브랜치는 14:06에 전체 브랜치 재적용을 수행했습니다. 브랜치의 기존 패치 커밋 11건의 committer 시간이 동일한 초(14:06:45)로 일괄 변경되었고, author 시간은 그대로 유지되었습니다. 이는 새로운 개발이 아니라 새로운 베이스라인으로 재적용된 전형적인 흔적입니다. 재적용은 기존 패치 세트를 그대로 유지했으며, 「Add riscv64 image locally (#51)」, 「Fix bytes_to_scalar for float/complex on RISC-V (#44)」 그리고 더 이전의 CI 및 테스트 허용 오차 변경을 포함합니다.

20:48에 [SyncBots] Integrate PyTorch at 3afdbd3 커밋이 추가로 들어왔으며, cmake/Dependencies.cmake 한 줄만 변경했습니다. KINETO_SOURCE_DIR의 cache 변수에 FORCE를 추가한 것입니다. 변경은 작지만 의미는 명확합니다. 브랜치의 베이스라인이 업스트림 3afdbd3으로 올라갔고, 이 커밋은 동기화 봇이 자동 생성한 것이므로 사람의 판단이 필요하지 않습니다.

동시에 관찰된 불일치: 배포 측의 python-torch-ruyiai(openRuyi #1352)는 10-27에 멈춰 있고 이번 기간에는 움직이지 않았으며, 브랜치 헤드는 새 베이스라인으로 교체되었습니다. 해당 패키지가 브랜치 산출물을 기반으로 빌드된다면, 패키지에 고정된 소스 지점을 다시 한 번 정렬해야 하며, 이 단계는 현재 어떤 PR에서도 진행되고 있지 않습니다. 열린 PR 7건(#23, #35, #36, #38, #43, #46, #48)의 updated 시간은 모두 20:47:49로, 브랜치 푸시로 촉발된 일괄 갱신이므로 내용이 업데이트된 것으로 간주할 수 없습니다. 그중 RVV 두 메인라인(#46의 ATen 대상 벡터 확장 지원, #48의 RISC-V Vector CPU 기능)은 이번 기간에도 새 커밋이 없습니다.

1.2 llvm-project: riscv 브랜치 전체 재적용, 기여 가이드 추가 및 사전 실행 스위치 제거 (10-29)

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

23:00 전후, riscv 브랜치는 전체 브랜치 재적용을 한 차례 수행했습니다. 확인 가능한 25건의 커밋은 committer 시간이 모두 23:00:40부터 23:00:44까지의 4초 안에 몰려 있습니다. 재적용 내용 중 한 건은 실제로 새로운 것입니다. [workflows] Push rebased PRs directly and document contribution options(author 시간 10-29 09:59)는 두 파일을 변경했습니다. autorebase.yml에서 8줄을 삭제하고(dry_run 입력과 해당 사전 실행 브랜치 제거), 82줄의 RISCV_CONTRIBUTING.md를 새로 추가했습니다.

이 가이드는 「riscv 브랜치에 어떻게 기여할 것인가」를 두 가지 경로로 정리합니다. 첫 번째 경로는 먼저 issue를 열고, 유지관리자가 현재 riscv에서 work/issue-NNN 작업 브랜치를 분기하며, 기여자가 작업 브랜치에 PR을 제출하고, 유지관리자가 통합한 뒤 riscv에 병합하는 방식입니다. 여러 사람이 협업하고 안정적인 이력이 필요한 작업 항목에 적합합니다. 두 번째 경로는 riscv에 직접 PR을 제출하고, 베이스라인이 바뀔 때마다 수동으로 리베이스 워크플로를 트리거하는 방식입니다. 워크플로는 PR 소스 저장소에서 실행되고, 소스 저장소의 GITHUB_TOKEN을 사용하며, --force-with-lease와 명시적 기대 SHA로 소스 브랜치에 다시 푸시합니다. 충돌은 일률적으로 riscv 측을 취하고(수정-삭제 충돌에서는 riscv 측의 삭제를 유지), 동등한 패치는 자동으로 건너뛰며, riscv 자체를 절대 재작성하지 않고 자동 병합도 절대 하지 않습니다.

이전 기간의 244줄 워크플로와 비교할 때 가장 큰 변화는 사전 실행이 취소된 것입니다. 이전 기간에는 기본이 「사전 실행만 하고 푸시하지 않음」이었으나, 이번 기간에는 「성공하면 푸시, 미리보기 옵션 없음」으로 바뀌었고 문서에도 이 문장이 명시되어 있습니다. 이는 마찰을 줄이는 동시에 위험을 앞당기는 것입니다. 기여자의 로컬 브랜치가 제때 동기화되어야 하며, 그렇지 않으면 구 베이스라인 이력이 다시 푸시될 수 있습니다. 문서에는 커밋되지 않은 작업을 저장하고 구 베이스라인을 원격에 다시 푸시하지 않도록 하는 주의 사항이 별도 단락으로 마련되어 있습니다. 또 하나 기록해 둘 세부 사항: 문서는 GITHUB_TOKEN으로 푸시하면 일반적으로 후속 push/PR 워크플로가 트리거되지 않는다고 명시하므로, 갱신된 SHA에서 CI가 실행되었는지는 사람이 확인해야 합니다.

1.3 triton-riscv: 세 건의 하향 수정 80분 내 병합, 의존성 업데이트는 여전히 열려 있음 (10-29)

날짜: 2026-10-29　출처: PR #58, PR #83, PR #82, PR #91, PR #56

세 건의 수정에 대한 기술적 세부 사항은 이번 호 「오늘의 포커스」에서 다루었으며, 여기서는 세 가지 상태를 보충한다. 첫째, 세 건이 병합된 후 메인 브랜치에는 모니터링 기간 내 새로운 코드 커밋이 없었고, git log의 최신 항목은 여전히 #58에 머물러 있어 이는 연속 개발이 아닌 일괄 정리였음을 보여준다. 둘째, renovate의 #91은 업스트림 buddy-mlir 야간 빌드 버전을 nightly/v0.1.3.dev20261027에서 dev20261029로 올렸으며(+2/−2, 파일 하나), 10-29 16:58에 #58이 병합된 후 한 차례 갱신되었고 여전히 열려 있고 병합 가능한 상태이나 unstable로 표시되어 있다. 이 의존성 업데이트가 바로 다운스트림이 #1015를 받는 경로이며, 자세한 내용은 4.2를 참조. 셋째, 열린 PR 중 #55(asin 연산자 프런트엔드 패치)는 18:06에 갱신되었고, #56(FlagGems 연산자 이전)은 09-16에 멈춰 있으며, #54, #57, #59, #72, #75, #85, #46은 모두 모니터링 기간 내 움직임이 없다. 특히 #85 「softmax 및 matmul 최적화」는 10-18 이후 업데이트가 없으며, 이는 성능 주제의 주요 라인으로 이후 주시할 가치가 있다.

1.4 tilelang-riscv: 메인 브랜치 열네 번째 날 침묵(10-29 상태)

날짜: 2026-10-29(상태)　출처: tilelang-riscv 커밋 목록, 열린 PR 목록

메인 브랜치의 마지막 커밋은 여전히 10-16 10:52의 「Build Python extension in Buddy CI」이며, 열네 번째 날 연속으로 커밋이 없다. 열린 PR은 여전히 두 건으로, #2는 06-16에, #4 「RVV vector mask and max reduction lowering」는 09-28에 멈춰 있으며 모두 모니터링 기간 내 업데이트가 없다.

이는 triton-riscv의 이번 세 건 병합과 직접적인 대조를 이룬다. 같은 조직, 같은 시기에 한 브랜치는 성능 저하 결함을 일괄 정리하고 있고, 다른 브랜치는 전혀 움직임이 없다. tilelang-riscv의 현재 유일한 다운스트림 존재감은 여전히 openRuyi의 python-tilelang-ruyiai 스펙(#1350 네 개 패치)에서 나오며, 즉 「배포판 산출물로 저장소 반복을 대체」하는 상태가 세 번째 주까지 이어지고 있다.

2. RuyiSDK 툴체인과 배포판

2.1 openRuyi: 76건 커밋, 10건 병합, KDE Frameworks 6.31.0 한 번에 64개 패키지 배치(10-29)

날짜: 2026-10-29　출처: PR #1513 KDE Frameworks 6.31.0, PR #1532 Gradio, PR #1533 pyvex, PR #1531 graphql-core, 메인 저장소 커밋 목록

이번 호 메인 저장소는 76건 커밋, 10건 PR 병합이며, 커밋 시각은 10-29 15:05부터 10-30 00:20까지 이어졌다. 규모는 지난 호(27건)의 거의 세 배로, 원인은 매우 집중되어 있다. KDE Frameworks 6.31.0 일괄 업그레이드가 64개의 kf6-* 패키지를 배치했기 때문이다. 이 전체 묶음은 15:11 같은 분에 반영되었으며(#1513), kf6-kcoreaddons, kf6-kconfig부터 kf6-kio, kf6-ksvg, kf6-kwallet까지 Plasma 6가 의존하는 프레임워크 전집을 대체로 포함한다. 지난 호에서 이 건은 아직 WIP로 검토 대기열에 표시되어 있었으나 하루 만에 병합으로 전환되었으며, 이는 데스크톱 스택의 버전 추종이 일괄 재빌드 능력을 갖추고 있음을 보여준다.

나머지 병합은 일반적인 버전 추종과 패키징 수정입니다: Gradio 6.31.0과 그 의존성(#1532, gradio-client 2.7.2, python-brotli 1.2.1 포함), python-pyvex 10.0.5(#1533), python-graphql-core의 수동 provides 에포크 버전 수정(#1531)입니다. 여기에는 RuyiAI 스택의 직접적인 컴포넌트는 없지만, python 쪽의 메타데이터 수정 묶음은 이후 triton/tilelang의 wheel 빌드 경로에 여전히 동일한 기반이 됩니다—지난 회차의 scikit-build-core와 cmake 메타데이터도 같은 종류의 작업이었습니다.

주목할 점은 시간 분포입니다: 64개의 KDE 패키지가 15:11 1분에 집중되고 나머지 12건은 15:05부터 다음 날 00:20까지 흩어져 있어, 이 제출들이 패키지별 수동 커밋이 아니라 스크립트화된 일괄 업데이트에 수동 마무리를 더한 것임을 보여줍니다.

2.2 openRuyi 패키징 영역: vkpeak 수록, cmake 모듈 경로 수정, clang-wrap 일일 업데이트 (10-29)

날짜: 2026-10-29　출처: PR #1349 vkpeak, PR #1536 ecbuild, PR #1535 clang-wrap, PR #1537, PR #1538, PR #1539

신규 패키지 1건: vkpeak(#1349, 16:38 병합)는 Vulkan 최대 성능 및 디바이스 기능 탐지 도구로, RISC-V 보드에서의 그래픽과 연산 능력 파악에 유용하며 「하드웨어는 있지만 측정 도구가 없는」 부류를 보완하는 것입니다. 패키징 인프라 3건: ecbuild의 cmake 모듈을 %{_libdir}에 설치하도록 변경(#1536)하여 이전에 비표준 경로에 떨어지던 문제를 수정; clang-wrap은 20261029로 추종(#1535)하여 업스트림과 같은 날의 패키징 리듬을 유지; python-graphql-core의 provides 에포크 버전 수정(#1531).

또한 순수 의존성 그래프 정리 3건: #1537은 중복된 go-github-smartystreets-assertions 패키지를 삭제하여 다중 선택 충돌을 해결; #1538, #1539는 go-golang-x-text, go-github-hexops-gotextdiff, go-github-magefile-mage에 누락된 import path provides를 보충. 이런 문제는 패키지 설치를 막지는 않지만 의존성 해석 시 dnf가 잘못된 버전을 선택하게 만들며, 배포판 장기 유지보수의 숨은 비용입니다.

2.3 openRuyi 심사 중: #1350 1차 코드 레벨 검토 18건, ollama 보안 업데이트 병합 대기 (10-29 상태)

날짜: 2026-10-29 (상태)　출처: PR #1350 Ruyiai packages, PR #1514 ollama, PR #1490 크로스 툴체인, PR #1516 qemu-rustsbi

#1350(buddy-mlir, python-triton-ruyiai, python-tilelang-ruyiai 3종 세트)은 이번 기간 처음으로 코드 레벨 검토를 받았습니다: misaka00251이 16:19부터 16:24까지 연속 5건을 올렸으며, 모두 설계 노선이 아닌 spec 작성법을 지적한 것입니다—BuildOption(xxx) 사이에 빈 줄을 넣을 필요가 없음; python-triton-ruyiai에 BuildRequires: python3dist(wheel) 누락, Provides와 실제 패키지명 정렬 필요; Conflicts: python-%{srcname}의 필요성 설명 필요; 패치는 git format-patch로 생성해야 하며 같은 디렉터리에 참조되지 않은 패치가 하나 더 있음; 빈 %check에는 이유를 설명하는 주석을 작성해야 함. PR 규모는 이에 따라 10개 파일, +796/−0으로 늘어났고 검토 코멘트 총 18건이며, 상태는 여전히 unstable, 미병합입니다.

이번 라운드를 앞선 여러 라운드와 함께 읽으면 논쟁의 중심이 이동하고 있음을 알 수 있다. 10-27 이전에는 「buddy-mlir에 내장된 LLVM을 외부화할 것인가」(작성자는 2.81배 빌드 시간으로 패키지 내 유지를 관철)였고, 이번 호는 spec의 기계적 규범으로 옮겨갔다. 이런 의견은 보통 「방향은 인정되었고 마무리 준비 단계」에서 나타나지만, 단순한 일상 점검일 가능성도 배제할 수 없다—병합 여부는 다음 라운드에서 approve를 주는 사람이 있는지에 달려 있다.

심사 대기열의 나머지 상태: #1514는 ollama를 0.40.7로 올리고 security-fixes를 표시했으며, 10-30 02:04 갱신, +259/−3371(vendor 디렉터리 삭제 규모), 미병합; #1516 qemu-rustsbi 22:36 갱신; #1540 Prometheus v3.13 의존성 수정 배치 17:01 갱신; #1534 simdjson 5.0.8과 오프라인 테스트 16:27 갱신; #1490 크로스 riscv64 툴체인은 여전히 WIP 표시, 10-28에 멈춰 있으며, 이미 병합된 툴체인 대버전 매크로와 함께 「진입점은 생겼으나 툴체인은 아직 도달하지 못한」 상태를 형성한다.

2.4 ruyi-imager 1.1.0-rc.1 배포, ruyi 0.54.0 여전히 beta 없음 (10-29)

날짜: 2026-10-29　출처: ruyi-imager v1.1.0-rc.1, 커밋 839a8f56, ruyi Releases, ruyi 태그

16:02, ruyi-imager가 v1.1.0-rc.1을 릴리스했다. 1.0.0(09-10) 이후 약 7주 만이다. 네 가지 변경: 이미지 선택 단계에 다운로드 동작 추가(#12), CLI 출력을 터미널 문자셋에 맞추고 JSON은 UTF-8 유지(#14), 선택 대화상자 더블클릭으로 확인(#19), 선택 대화상자에서 반드시 명시적 선택(#21). 네 가지 모두 사용성 다듬기이며, 그중 「더블클릭 확인」과 「반드시 명시적 선택」은 상호 보완적인 상호작용 제약으로 전자는 속도를 높이고 후자는 오선택을 방지한다. 릴리스 노트에는 첫 기여자(qingwan12138) 한 명이 표시되어 있으며, 네 건 중 세 건이 같은 사람에게서 나왔다. 같은 날 15:40에 「Bump base version to 1.1.0」 커밋이 있었는데, 이는 배포 전 버전 자리 준비였다.

한편 패키지 관리자 ruyi의 0.54.0은 여전히 beta가 없다: 태그 목록에서 0.54.0-alpha.20260918 이후 새 태그가 없고, 정식 버전 최신은 여전히 09-24의 0.53.0이며, 메인 브랜치는 09-25 이후 커밋이 없다. 격주 진행 079호에서 밝힌 입장은 「릴리스 주기 조정으로 10월 말로 변경」이었으며, 이번 모니터링 기간은 이미 10월의 끝에서 두 번째 날인데도 후보 버전이 없다—6-30, 7-23, 8-27, 9-24의 월간 리듬에 따르면, 이번 기간이 「10월 말」이라는 표현을 이행할 수 있는 마지막 창이다.

2.5 ruyi 메인 저장소: 벤더 명명 목록 갱신, ABI 탐지 제안 보충 기록 (10-29 / 10-28)

날짜: 2026-10-29　출처: PR #508 벤더 명명 목록, PR #507 ABI 탐지

#508 「docs: update vendor naming list」는 16:13 갱신되었으며 문서 측 변경으로, ruyi-imager가 이번 호에 인터페이스의 「제조사」를 「공급업체」로 바꾼 것과 같은 일의 양 끝이다—설치 프로그램이 표현을 바꾸자 문서 측 벤더 명명 목록도 이에 맞춰 정렬해 두 곳의 명칭 불일치를 피한다.

지난 호에 누락된 제안 한 건을 보충 기록한다: #507은 10-28 17:15 제출되어 ruyi에 「주어진 소프트웨어 패키지의 호스트 ABI 호환성 탐지」 기능을 추가하며, 규모는 43개 파일, +4023/−716으로 이번 달 ruyi 메인 저장소 최대 건이다. 방식은 패키지 내 ELF ABI sidecar를 조회 계획으로 삼아 아키텍처, ELF class, 인터프리터, 공유 라이브러리, 심볼 버전, 버전화되지 않은 심볼, 아키텍처 속성을 비교하고, 결과를 호환, 비호환, 판정 불가 세 상태로 나누며, 새로 ruyi admin check-abi 하위 명령을 추가한다; 라이브러리 해석은 의도적으로 후보 라이브러리를 로드하지 않고 Ruyi 프로세스의 LD_LIBRARY_PATH에 의존하지 않는다. 이는 「미리 컴파일된 RISC-V 패키지를 이 머신에 설치할 수 있는가」를 시행착오에서 설명 가능한 점검으로 바꾼다—바이너리 배포 중심의 RuyiSDK 생태계에서 이 경로의 가치는 어떤 단일 패키지 버전 업데이트보다도 높다. 현재까지도 미병합이다.

3. 벡터 확장, 아키텍처 테스트와 연산자 최적화

3.1 벡터 네 저장소 계속 조용, 벤치마크 측 공백 여전 (10-29 상태)

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

네 개의 벡터 관련 저장소는 모니터링 기간 내 커밋이 전부 0건이었고, 정지 기간도 변동이 없었다. 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% 차이’라는 노이즈가 나타났으며, 보드 실측 처리량으로 결론을 내리는 것 자체가 빠듯한 상황이다. VecIntrinBench 측이 계속 움직이지 않는다면, 이후 ‘최적화가 정말로 개선이 되었는가’는 장기적으로 수작업 대조에만 의존할 수밖에 없을 것이다. 이는 이번 기간에 새로 생긴 문제는 아니지만, 세 건의 병합이 이를 더 선명하게 비춰 주었다.

3.2 FlagGems 마이그레이션이 triton-riscv의 결함 발견 메커니즘이 되다 (10-29)

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

세 건의 수정 동기를 펼쳐 보면, 이들의 공통 출처가 테스트 스위트가 아니라 ‘PyTorch 연산자를 한 무더기씩 triton-riscv에 이식하는’ 작업 그 자체였음을 알 수 있다. unique_dim에서 실제 텐서 채움값을 동반한 tl.load, broadcast_to의 루프 전달 오프셋, 산입 연산자의 중복 인덱스 비교——이 세 가지는 모두 RISC-V 명령어 계층이 아니라 하강(lowering) 계층과 검증 계층의 경계에 위치한다. 이런 부류의 결함은 단위 테스트에서 자연스럽게 드러나기 어렵다. 실제 연산자 라이브러리를 갖추고 배치 방식으로 밀어붙여야만 노출된다.

이 일의 방법론적 가치는 세 건의 수정 자체보다 크다. Triton을 진입점으로 하는 RISC-V AI 스택에서 FlagGems 마이그레이션은 사실상 ‘엔드투엔드 검증 집합’ 역할을 하며, 컴파일러의 lit 스위트보다 실제 부하에 더 가깝다. 반대로 이번 기간에는 이 메커니즘의 단일 의존성도 드러났다. 마이그레이션 PR #56이 09-16 이후 갱신되지 않았고, 세 건의 수정이 병합된 뒤 오히려 검증 절차가 멈춰 버렸다. #56이 장기간 진전되지 않는다면 이 ‘결함 발견 메커니즘’도 함께 무력화되어, 다음 배치의 결함은 다른 사용자가 부딪힐 때까지 발견되지 않을 것이다.

3.3 arXiv 모니터링 기간 내 신규 없음, 10-27 두 편이 최신 (10-29 상태)

날짜: 2026-10-29 (상태)　출처: arXiv 검색

RISC-V에 컴파일러, 벡터, MLIR을 조건으로 한 검색에서 모니터링 기간 내 신규 논문은 없었다. 검색된 최신 두 편은 모두 10-27이다. SecDMP: Provably Secure Data Memory-Dependent Prefetching(데이터 메모리 접근 의존 프리페칭의 증명 가능한 보안 기법)과 A lightweight C Code Generator for Heterogeneous TinyML Systems(이기종 TinyML을 위한 경량 C 코드 생성기)이다. 전자는 마이크로아키텍처 측의 보안 프리페칭과 관련되고, 후자는 엣지 측 코드 생성에 속하며, 둘 다 AI 스택의 컴파일 경로에 직접 닿지는 않는다.

이번 기간의 주제와 가장 맞닿아 있는 것은 여전히 10-21의 Reorienting the Vector Axis: Restructuring FlashAttention for Long-Vector Processors——긴 벡터 프로세서상의 FlashAttention 재구성으로, 10-28에 디코딩 어텐션을 64 lanes로 분할하고 단일 헤드당 하나의 LMUL 4 그룹으로 처리한 방식과 같은 부류의 문제에 속한다. 모니터링 기간 내 후속은 없었다.

4. Buddy Compiler 동향

4.1 buddy-server 신규 ABI 병합: 56개 파일, 모델 플러그인 체계를 통합 인터페이스로 변경 (10-29)

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

15:08, #1015 “Buddy-server new ABI”가 머지되었으며, 56개 파일, +3934/−1661로 이번 기간 전체 스택에서 변경 규모가 가장 큰 건이다. PR 설명에는 buddy-server가 RAX 파일을 파싱할 때 사용하는 ABI 인터페이스를 업데이트하며, 새 인터페이스가 향후 더 많은 모델 지원에 편의를 제공한다는 의도 한 줄만 적혀 있지만, 실제 변경은 이보다 훨씬 크다.

구조적으로는 “모달리티별로 플러그인 핸들을 각각 작성”하던 방식을 “하나의 통합 인터페이스”로 교체한 것이다. 새로운 런타임 헤더 파일 네 개를 추가했다: ServerModelABI.h(392줄), ServerModelABIConversion.h(179줄), ServerModelPluginAdapters.h(742줄), ModelError.h(57줄). 동시에 기존에 모달리티별로 분리되어 있던 AudioTranscriptionModelPluginHandle, EmbeddingModelPluginHandle, MaskedLMModelPluginHandle, ResidentModelPluginHandle 네 그룹의 구현과 ModelPluginDiscovery를 삭제하고, 350줄의 ServerModelPluginHandle과 102줄의 헤더 파일로 교체했으며, 어댑터 계층이 각 모달리티의 기존 진입점을 새 ABI로 다시 연결한다. BuddyServerApp.cpp 단일 파일만 +446/−225 변경되었고, SimpleHttpServer에는 25줄이 보강되었다(요청 파싱, 오류 반환 관련).

모델 측면에서는 일곱 개 디렉터리를 동시에 재작성했다: bge_m3(임베딩), deepseek_r1, llama31_tt, proteinglm(마스킹 언어 모델), qwen3_vl(비전 언어), whisper(오디오 전사)의 Model과 Plugin을 쌍으로 조정했으며, 각 쌍은 모두 “C++ 측은 적게 작성, 공용 측은 많이 작성”하는 형태다. 이는 지난 기간 #1010의 소스 재구성과 같은 맥락이다: 먼저 디렉터리를 책임별로 분리하고, 그다음 인터페이스를 한 계층으로 수렴시키는 것이다.

테스트 측면이 이번 건에서 가장 주목할 부분이다: ServerModelPluginHandleTest.cpp(325줄), BuddyServerAbiErrorIntegrationTest.py(184줄), BuddyServerCapabilityIntegrationTest.py(135줄), ServerModelConcurrencyFakePlugin.cpp(162줄), ServerModelDependencyPlugin.cpp(38줄), ServerModelErrorFakePlugin.cpp(149줄)를 새로 추가했고, 모달리티별로 작성했던 네 그룹의 단위 테스트(총 약 226줄)를 삭제했다. 즉, 테스트의 중심이 “각 모달리티를 하나씩 테스트”에서 “통합 ABI의 오류, 기능, 동시성, 의존성 네 가지 행위”로 이동했으며, 오히려 커버리지는 더 넓어졌다. 문서 측면에서는 RAXPackagingAndLoadingAnalysis.md와 Runtime.md가 함께 업데이트되었다.

한 가지 유의할 점: 이는 인터페이스 리팩터링이며, PR에는 성능 데이터도, 새 모델 지원 증명도 없다. “더 많은 모델 지원에 편의를 제공”한다는 것은 다음에 새 ABI로 통합되는 모델이 나와야 실현되는 것이다.

4.2 야간 버전 dev20261029, #1015보다 먼저 패키징되어 다운스트림은 다음 버전을 기다려야 함 (10-29)

날짜: 2026-10-29　출처: 야간 버전 dev20261029, Releases 목록, triton-riscv PR #91

야간 버전 v0.1.3.dev20261029는 08:21에 릴리스되었으며, #1015의 머지 시간(15:08)보다 약 일곱 시간 앞서므로 이 버전에는 새 ABI가 포함되지 않는다. #1015를 적용하려면 dev20261030이 패키징되기를 기다린 후, triton-riscv의 renovate가 앵커를 한 번 올려야 한다(#91은 현재 dev20261029에 앵커되어 있으며 여전히 열려 있음).

이 시간 기록은 별도로 기록할 가치가 있다. 왜냐하면 이것이 이 스택의 고정 지연 구조이기 때문이다: buddy-mlir 머지 → 다음 날 야간 빌드 → renovate가 의존성 업데이트 제안 → triton-riscv 머지. 세 단계를 합치면 보통 1~2일이 걸린다. 0.1.3 라인은 이미 다섯 개의 야간 버전 연속으로 정식 버전이 없었고, 가장 최근 정식 버전은 여전히 10-25의 0.1.2이다. #1015와 같은 규모의 인터페이스 변경이 정식 버전으로 나가려면 한 라운드를 더 기다려야 한다.

4.3 심사 중인 세 건이 10-28에 멈춰, Whisper와 인터페이스 정렬 모두 움직임 없음 (10-29 상태)

날짜: 2026-10-29 (상태)　출처: PR #1011, PR #1013, PR #994, 오픈 PR 목록

#1015가 머지된 후, 기존의 “심사 중 네 건”은 세 건만 남았다: #1011(확장 가능한 VIR 조각 카운트 강제 int64 변환), #1013(Whisper 단일 전사 내 전처리 재사용), #994(buddy-server 인터페이스를 llama-server에 정렬). 세 건의 마지막 업데이트 시간은 모두 10-28 16:01에서 16:01 사이로, 모니터링 기간 내 새로운 움직임은 없었다.

그중 #1011의 상황은 다소 미묘하다: 이전 회차 #1012의 x64 CI 그린은 이 커밋 위에서 획득되었으나, 이 커밋은 아직 머지되지 않았다. 또한 #1015가 이미 buddy-server의 플러그인 인터페이스를 변경했는데, #994의 “llama-server 정렬” 인터페이스 방향이 새로운 ABI와 충돌할지에 대해서는 PR에서 논의되지 않았다. 오픈 목록에는 별도로 #993(tile.upsample_nearest 인식), #1001과 #997(K3 A100에서 Qwen3-0.6B와 DeepSeek-R1-Distill-Qwen-1.5B의 prefill/decode 최적화), #995(비말단 축 Cumsum 연속 순회), #992(bn 채널 브로드캐스트 수정), #938, #932, #928, #924, #838이 있으며, 모두 모니터링 기간 내 업데이트가 없다.

5. 커뮤니티와 활동 및 공식 홈페이지

5.1 공식 홈페이지 세 페이지 변화 없음, 블로그 2편, 문서 23장 (10-29 상태)

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

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

엔지니어링 측과의 격차는 계속 존재한다. 이번 회차에 기술 블로그 글로 쓸 수 있는 소재는 적지 않다: 세 건의 다운그레이드 수정 배후의 “비균일 의미” 문제, buddy-server 통합 ABI의 리팩토링 사고, ruyi-imager 1.1의 인터랙션 개편 — 모두 PR 설명과 저장소 문서에만 머물러 있다. 외부에 이 스택을 보여주는 진입점은 여전히 9월의 두 글뿐이며, 이는 “매일 커밋이 있고 매주 머지가 있다”는 리듬과 맞지 않는다.

5.2 포럼 두 게시글: RuyiAI 정상 회고와 샹산 루이이 생태 대회 전재 (10-29)

날짜: 2026-10-29　출처: RuyiAI 정상 회고 #2899, 샹산 루이이 생태 대회 전재 #2898, RuyiSDK 개발자 커뮤니티

포럼 이번 회차 두 게시글은 모두 10-29에 게시되었다. RuyiAI 카테고리의 #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 네이티브 소프트웨어 스택”은 같은 포럼에서 나란히 발표된 성과 중 하나이며, 서버 칩, 멀티스레드 아키텍처와 같은 배치의 서사에 속한다.

5.3 ruyiai-daily 1차, 정보 범위 PyTorch, LLVM, Triton 및 RISC-V 커버(10-29)

날짜: 2026-10-29　출처: ruyiai-daily 커밋 목록, daily-news 2026-10-29

ruyiai-daily는 10-29 06:42(베이징 시간)에 daily-news-2026-10-29.md 1차분을 커밋하며 일별 아카이빙을 이어갔다. 이번 회차의 범위는 PyTorch 생태계, LLVM/MLIR, Triton과 TileLang, RISC-V 소프트웨어 스택과 제품, AI 모델과 산업의 다섯 방향을 포괄하며, 이 저장소와 직접 관련된 세 가지는 PyTorch 2.15 릴리스(NCCL 재작성으로 기본화, MPS FP8 확장), Buddy의 K3 VIR 디코딩 어텐션(즉 10-28의 #1014), 그리고 ruyi의 호스트 ABI 프로빙 제안(즉 #507)이다. 이 정보의 검색 기간은 10-28 05:14부터 10-29 06:00까지로, 데일리 리포트 기간과 수 시간 어긋나므로 인용 시 항목 자체의 날짜로 표기해야 한다.

5.4 외부 뉴스 제로 히트, openRuyi 2026.10과 0.54.0 모두 미발표(10-29 상태)

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

Google News에서 RuyiSDK, RuyiAI, openRuyi 및 Ruyi 커뮤니티에 대한 중영문 표적 쿼리(when:3d)는 기간 내 모두 제로 히트였으며, RISC-V 주제 후보 목록에도 Ruyi 커뮤니티 관련 항목이 없어 이번 회차에는 외부 뉴스를 수록하지 않는다.

배포판 측 두 버전 역시 여전히 기간 밖이다. openRuyi 뉴스 페이지의 최신 글은 여전히 2026.09 릴리스 공지이며, 저장소 태그는 2026.09-experimental에서 멈춰 2026.10은 미발표다. ruyi의 0.54.0은 09-18의 alpha 태그만 있다. 이전 몇 달의 월말 리듬을 따른다면 앞으로 이틀 내지 사흘이 2026.10과 0.54.0의 릴리스 기간이므로, 다음 회차에는 이 두 곳을 주시해야 한다.

6. 트렌드 관찰

6.1 수정이 검증보다 먼저: 세 건의 수정은 회귀 테스트가 아닌 마이그레이션 과정에서 쌓인 이슈 목록에 의존

이번 회차 세 건의 병합은 한 가지 순서 문제를 드러냈다: 수정이 먼저, 검증이 나중. unique_dim의 텐서 패딩, broadcast_to의 루프 오프셋, 해시 연산자의 중복 인덱스—세 결함 모두 컴파일러 자체 테스트가 발견한 것이 아니라 FlagGems 연산자를 위로 옮기다가 부딪힌 것이며, 수정은 병합되었지만 이를 필요로 하는 마이그레이션 PR #56은 09-16에 멈춰 움직이지 않았다. 결과적으로 “특정 용도를 위해 준비된 수정” 묶음에 당장 대응하는 용도가 실행되지 않는 상태다.

이 상태의 위험은 현재가 아니라 다음 달에 있다: #56이 재개될 때 Triton 업스트림이 또 여러 차례 바뀌었다면 세 건의 수정이 새 베이스라인과 여전히 호환되는지 다시 검증해야 하며, #56이 계속 재개되지 않으면 이 “엔드투엔드 검증 집합”은 사실상 정지 상태가 되어 다음 결함 묶음은 외부 사용자가 부딪힐 때까지 기다려야 한다. “실제 모델을 돌릴 수 있다”를 목표로 하는 스택에게는 마이그레이션을 상시 회귀(비록 수십 개 연산자라도, 매일 밤 한 번 실행)로 만드는 것이 수정을 몇 건 더 병합하는 것보다 가치 있다.

6.2 브랜치 거버넌스의 두 가지 방식: llvm은 규칙을 쓰고 프리뷰를 없애며, pytorch는 전체 브랜치 재생에 의존

같은 날, 두 브랜치는 두 가지 거버넌스 답을 내놓았다. llvm의 riscv 브랜치는 전체 브랜치를 한 번 재생했고, 실제로 새로 추가된 것은 기여 가이드 한 부였다: “riscv에 코드를 보내는” 일을 “메인테이너 작업 브랜치에 PR 제출”과 “riscv에 직접 PR 제출 후 수동으로 리베이스 트리거”의 두 경로로 나누고, 동시에 워크플로의 프리뷰 스위치를 삭제했다—성공하면 즉시 푸시, 프리뷰 없음. pytorch의 riscv 브랜치는 업스트림 3afdbd3으로 재생하고 동기화 봇이 의존성 캐시 수정을 한 건 보충했을 뿐, 어떤 프로세스 문서도 없다.

양자의 비용 구조는 다르다. llvm 브랜치는 패치 집합이 크고 외부 기여가 많아 충돌과 히스토리 드리프트가 주요 비용이므로 규칙화하여 문서를 쓰고 워크플로를 구성할 가치가 있다. pytorch 브랜치는 패치 집합이 작아(11건) 메인테이너가 직접 한 번 재생하는 비용이 프로세스 유지 비용보다 낮다. 프리뷰를 없앤 점은 관찰이 필요하다: 마찰을 낮추는 동시에 “잘못된 히스토리 푸시” 위험을 기여자에게 앞당겨 전가하고 --force-with-lease와 상태 재확인으로 안전망을 치는 방식의 실제 효과는 다음 한두 건의 외부 PR을 봐야 한다.

6.3 배포판은 월 단위로 물량을 깔고, 스택급 3종 세트는 월 단위로 심사를 지연

openRuyi 이번 회차 76건의 커밋, 10건 머지, 그중 64건은 KDE 프레임워크 업그레이드 묶음이다. ruyi-imager는 1.0.0에서 1.1.0-rc.1까지 7주가 걸렸으니 정상적인 리듬이다. 반면 같은 ‘배포’의 다른 축인 RuyiAI 삼종 세트의 패키징 PR #1350은 09-21에 열린 이후 지금까지도 여전히 spec 규범 차원에서 재작업 중이다. 두 파이프라인의 차이는 인력이 아니라 성숙도에 있다. KDE 패키지는 참조할 업스트림 spec이 있고 정해진 버전 리듬이 있어 재패키징은 기계적인 작업이다. 삼종 세트는 처음부터 작성한 spec이라 ‘왜 LLVM을 패키지 안에 남기는가’를 설명해야 하고, ‘왜 %check가 비어 있는가’도 설명해야 한다.

이것이 RuyiAI에 주는 시사점은 배포판이 삼킬 수 있으려면 패키지 자체가 충분히 ‘관례적’이어야 한다는 전제다. buddy-mlir는 LLVM을 자체 포함하고, triton은 git 실행 파일에 의존하며, tilelang은 buddy-mlir 툴체인을 발견해야 한다. 이 세 가지 비관례적 지점은 각각 패치와 설명이 필요하고, 모든 설명마다 메인테이너가 시간을 들여 판단해야 한다. 삼종 세트가 월간 릴리스 리듬에 진입하기를 원한다면 이 세 가지 비관례적 지점을 한두 개의 명확한 패키징 규약으로 수렴시키는 것이(예를 들어 툴체인은 통일적으로 buddy-mlir가 제공하고, 패치는 통일적으로 git format-patch의 패치 스태킹을 사용) 검토 의견에 건별로 대응하는 것보다 수월하다.

출처 검증표

출처 검증 결과
RuyiAI-Stack 조직 (전체 저장소) pytorch: riscv 브랜치 전체 재생 11건, SyncBots를 업스트림 3afdbd3으로 승격, 메인 브랜치 20건 전부 업스트림; llvm-project: riscv 브랜치 25건 재생, 기여 가이드 신규 추가(faf4def312, +82/−8), 메인 브랜치 20건 업스트림; triton-riscv: 3건 병합(#58, #83, #82), 야간 태그 갱신 3건, 의존성 PR 1건 오픈(#91); tilelang-riscv 열네 번째 날 무소식; ruyiai-daily 1건; harness, FBGEMM, cpuinfo, VecIntrinBench, IntrinTrans, torq-tile, pytorch-ci, dsh-osc, skills, SyncBots-DeepAgents, caffe, mxnet 모니터링 기간 내 커밋 없음
ruyisdk 조직 (전체 저장소) ruyi-imager: 커밋 1건(버전 넘버 1.1.0) + v1.1.0-rc.1 프리릴리스; ruyi 메인 저장소: 오픈 PR 갱신 1건(#508 벤더 명명 목록), 커밋 없음, 신규 Release 없음(0.53.0 유지, 0.54.0은 alpha 태그만); packages-index, support-matrix, docs, ruyisdk-website, wechat-articles, attached-matrix-extension, ruyici, AME-operator 모니터링 기간 내 커밋 없음
openRuyi-Project 조직 openRuyi 메인 저장소 커밋 76건(KDE Frameworks 6.31.0 배치 64건, 나머지 12건은 vkpeak, ecbuild, clang-wrap, Gradio, pyvex, graphql-core 및 go 패키지 수정) + PR 병합 10건; 오픈 PR 15건 갱신됨(#1350 첫 번째 코드 수준 재검토 18건, #1514 ollama 보안 업데이트 포함); 태그는 2026.09-experimental에서 멈춤, 2026.10 미배포
buddy-compiler 조직 buddy-mlir 병합 1건(#1015 신규 ABI, 56개 파일 +3934/−1661) + 야간 빌드 v0.1.3.dev20261029; 오픈 PR 3건은 10-28에 멈춤(#1011, #1013, #994), 별도로 #992, #993, #995, #997, #1001, #924, #928, #932, #838은 모니터링 기간 내 갱신 없음; buddy-benchmark, buddy-examples, compiler-eval, FeGen, gemmini, firesim 모니터링 기간 내 커밋 없음
RuyiSDK 개발자 커뮤니티 포럼 모니터링 기간 내 게시글 2건: #2899 “RuyiAI, 제6회 RISC-V 중국 서밋에 등장”(10-29, RuyiAI 카테고리), #2898 “샹산 루이 생태계 대회: 에이전트 시대를 위한 RISC-V 소프트웨어·하드웨어 풀스택 성과 발표”(10-29, 재게시); 격주 진행 상황 080호 미발행
openRuyi 배포판 뉴스 페이지 신규 글 없음, 2026.09 배포 공지가 여전히 최신; 저장소 태그는 2026.09-experimental에서 멈춤, 2026.10 미배포
ruyi 패키지 관리자 / Releases 0.53.0 유지, 신규 alpha 또는 beta 없음(0.54.0-alpha.20260918이 여전히 최근 버전); 메인 브랜치는 09-25 이후 커밋 없음
ruyi-imager / Releases v1.1.0-rc.1이 10-29 16:02 배포됨(프리릴리스), 상호작용 및 CLI 변경 4건 포함
공식 홈페이지 (ruyiai.org) 세 페이지 변동 없음: 홈페이지 인덱스 3건, 블로그 2편, 문서 23장, sha256이 이전 호와 동일
arXiv (RISC-V) 모니터링 기간 내 신규 없음; 최신은 10-27의 SecDMP와 TinyML C 코드 생성기, 10-21의 장벡터 FlashAttention이 여전히 RVV에 가장 부합
Google News RSS (중영문 다중 그룹) RuyiSDK, RuyiAI, openRuyi, 루이 커뮤니티 대상 쿼리 적중 없음; RISC-V 주제 후보 중 Qwenputer, Ruyi 무관 항목 모두 미수집

전체 출처 목록

openRuyi/pull/1536>