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

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

이번 호 인덱스

  • 오늘의 핵심: K3 디코드 어텐션을 VIR로 이전, 성능이 수작업 RVV 커널과 동등 (10-28)
    1. RuyiAI 스택 진행 상황 (PyTorch / Triton / TileLang RISC-V 적응)
      • 1.1 llvm-project: 더 이상 리베이스하지 않고, 「작성자 fork 원클릭 리베이스」 워크플로 추가 (10-28)
      • 1.2 pytorch: riscv 브랜치 7일째 조용, 메인 브랜치 20건은 여전히 업스트림 (10-28 상태)
      • 1.3 triton-riscv: 기준점 한 단계 더 상향, riscv64 CI 3건 대기 중 미응답 (10-28)
      • 1.4 tilelang-riscv: 메인 브랜치 13일째 조용 (10-28 상태)
    1. RuyiSDK 툴체인과 배포판
      • 2.1 openRuyi PR #1350: 커밋 3건 리베이스, GCC 빌드 비용 2.81배로 정량화 (10-28)
      • 2.2 openRuyi: 커밋 27건, PR 15건 병합, qemu 11.1.2 및 libvirt 백포트 적용 (10-28)
      • 2.3 심사 대기열: KDE Frameworks 6.31, 크로스 툴체인, Gradio 6.31 (10-28 상태)
      • 2.4 ruyisdk: 0.54.0 여전히 미출시, 패키지 목록과 지원 매트릭스 조용, 설치 프로그램 UI 용어 변경 (10-28 상태)
    1. 벡터 확장, 아키텍처 테스트 및 연산자 최적화
      • 3.1 벡터 저장소와 FBGEMM 3개 저장소 조용, cpuinfo 05-20에 정지 (10-28 상태)
      • 3.2 벡터 폭 기준: VIR 측 1024비트, 단일 헤드에 LMUL 4 그룹 하나 (10-28)
      • 3.3 arXiv 모니터링 기간 내 신규 없음, 10-21의 장벡터 FlashAttention이 여전히 RVV에 가장 부합 (10-28 상태)
    1. Buddy Compiler 동향
      • 4.1 K3 디코드 어텐션을 VIR로 이전: 수치 비트 단위 일치, K3 실측 처리량 동일 구간에 위치 (10-28)
      • 4.2 buddy-server 소스 재구성, Whisper 예제 x64 CI 진입 (10-28)
      • 4.3 심사 중 4건: int64 강제 변환, Whisper 전처리 재사용, 신규 ABI, llama-server 정렬 (10-28 상태)
      • 4.4 야간 빌드 dev20261028 출시, 당일 3건은 여전히 미포함 (10-28)
    1. 커뮤니티 및 활동 및 공식 홈페이지
      • 5.1 공식 홈페이지 3개 페이지 변화 없음, 블로그 2편, 문서 23장 (10-28 상태)
      • 5.2 포럼 모니터링 기간 내 신규 게시글 없음; 10-27의 LPi4A UEFI 실측 게시글 보충 기록 (10-27)
      • 5.3 ruyiai-daily 1회, ruyi-imager가 「제조사」를 「공급업체」로 변경 (10-28)
      • 5.4 외부 뉴스 전무, openRuyi 2026.10과 0.54.0 모두 미출시 (10-28 상태)
    1. 트렌드 관찰
      • 6.1 「표현 가능」에서 「똑같이 빠르게 실행」으로: VIR이 처음으로 실제 모델 커널로 성능 대조
      • 6.2 리베이스 비용이 패치 드리프트에서 거버넌스로 이동: 워크플로가 리베이스를 담당, 브랜치 자체는 여전히 사람에 의존
      • 6.3 배포 계층의 논쟁에 가격이 붙기 시작: 2.81배 빌드 시간이 「선호」보다 더 설득력 있음

오늘의 핵심: K3 디코드 어텐션을 VIR로 이전, 성능이 수작업 RVV 커널과 동등 (10-28)

날짜: 2026-10-28　출처: buddy-mlir PR #1014, K3 문서, triton-riscv PR #91, llvm-project 리베이스 워크플로

가장 실질적인 진전은 09:36에 있었습니다. buddy-mlir의 #1014 「K3: write the decode attention in the VIR dialect」가 머지되었습니다(4개 파일, +476/−14). 이는 K3 w4g32 커널의 디코드 어텐션 전체를 VIR 다이얼렉트로 옮긴 작업입니다. 이것은 또 한 번의 다이얼렉트 기능 보강이 아니라, 실제 모델의 커널을 처음으로 대조 검증한 것입니다. 한쪽은 이전에 수작업으로 작성한 RVV 벡터 커널이고, 다른 쪽은 Python으로 조립한 VIR 커널입니다. 수치, 명령어 수, 보드 위의 처리량을 비교합니다.

구현 방식은 네 계층으로 나눌 수 있습니다. 구성 계층은 더 이상 연산자와 타입을 수작업으로 조립하지 않고(이전에는 문자열 안에 연산자 이름과 타입 설명을 작성해야 했음), buddy_mlir.dialects.vir의 SetVLOp, load, shuffle, fma, reduce를 사용합니다. 하나의 work item은 하나의 vir.set_vl 영역이며, 길이는 헤드 차원의 절반(64 lanes)입니다. 각 헤드는 RoPE의 두 절반으로 조립된 확장 가능 벡터이고, 영역은 해당 헤드의 (max, sum)을 반환합니다. 로테이션 계층은 q를 영역 내에서 로드하고, 회전하고, 스케일링합니다. rotate_half는 하나의 vir.shuffle로 구현되고, cos/sin은 두 행의 동일 길이 데이터로 저장되므로 더 이상 vir.from_vector가 필요하지 않습니다. 메모리 뷰 계층은 memref.expand_shape를 사용하여 q, KV cache, 출력, q의 정규화 가중치를 마지막 차원 기준으로 2×64로 분할합니다. 정규화 계층(Qwen3의 q/k norm)은 별도의 1차원 vir.set_vl 영역을 열어 _head_rmsnorm 방식으로 두 절반의 제곱합을 구합니다.

파이프라인 파라미터도 함께 변경되었습니다. 커널 하향은 vector-width=128에서 rvv-vlen=1024, use-scalable=false로 바뀌었고, 벡터 크기는 A100의 레지스터를 기준으로 분석에 의해 결정됩니다. 영역 안에 vir.shuffle이 있기 때문에 각 헤드는 128개의 f32 벡터 그룹(LMUL 4)으로 유지됩니다. 작성자는 PR에서 명확히 밝혔습니다. use-scalable=true로 전환하는 것은 다음 작업이라고. 기존 _attn_decode_fn은 유지되며, A210 커널의 디코드 어텐션은 여전히 이를 사용합니다.

결과는 세 가지 모두 확실합니다. 수치적으로는 q/k 정규화를 포함하든 하지 않든 _attn_decode_fn과 비트 단위로 일치합니다. 기계어 수준에서는 두 병렬 본체가 각각 178개의 벡터 명령어이며, 키-값 루프는 이전 버전과 명령어가 동일하고, 오버플로 레지스터의 재로드 위치 두 곳만 바뀌었습니다. 보드 처리량(K3, buddy-cli 그리디 디코딩, 3회 교대, 9쌍 생성 텍스트 완전 일치)은 세 구간 모두 동일 범위에 들어갑니다. 63 token 후 28.26~28.49 대 28.10~28.58, 458 token 후 26.82~27.13 대 27.02~27.04, 900 token 후 25.37~25.41 대 25.29~25.77입니다. 작성자 스스로 명시했습니다. 동일한 코드를 두 번 빌드할 때의 차이는 최대 2%에 달할 수 있으며, 구간은 겹친다고.

같은 날 이 주제와 호응하는 두 건의 변경이 더 있었습니다. 하나는 llvm-project의 riscv 브랜치에 244줄의 자동 리베이스 워크플로를 추가한 것(상세는 1.1)으로, 「작성자 fork의 PR이 베이스라인을 따라가지 못하는」 문제를 수작업에서 Actions로 옮겼습니다. 다른 하나는 triton-riscv의 의존성 앵커가 renovate에 의해 dev20261028로 한 단계 더 올라간 것(상세는 1.3)입니다. 다만 이 야간 빌드의 패키지 생성 시각이 당일 오전 세 건의 머지보다 이르기 때문에, 이 의존성 업데이트가 머지되더라도 다운스트림에서는 아직 #1014를 받을 수 없습니다. 오늘의 성과를 사용하려면 다음 야간 빌드를 기다려야 합니다.

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

1.1 llvm-project: 더 이상 리베이스하지 않고, 「작성자 fork 원클릭 리베이스」 워크플로 추가(10-28)

날짜: 2026-10-28　출처: riscv 브랜치 커밋 cf00909d, 워크플로 전체, riscv 브랜치 커밋 목록

이전 회차의 「5일 만의 다섯 번째 전체 브랜치 재적용」과 달리, 이번 회차 riscv 브랜치의 로컬 패치셋은 한 건도 변동이 없습니다. 브랜치 헤드는 ed439f3e에서 한 커밋 앞으로 나아갔으며, 이전 회차 헤드와 비교하면 1건 앞서고 0건 뒤처지며 파일 1개만 변경되었습니다. 이번에 추가된 커밋(cf00909d, 작성 23:27, 커밋 23:54)은 순수 CI 자산인 .github/workflows/autorebase.yml이며, +244/−0입니다.

워크플로의 설계 의도는 주석에 적혀 있다: 작성자 소스 저장소의 기본 브랜치에 설치하고, Actions에서 대상 PR 번호를 수동으로 입력해 실행하며, 소스 저장소 자체의 GITHUB_TOKEN을 사용하고, 사용자 정의 키나 라벨이 필요 없다. 트리거 방식은 workflow_dispatch이며, 두 개의 입력이 있다 — PR 번호(필수)와 「미리보기만 하고 푸시하지 않기」(기본 활성화). 실행 환경은 ubuntu-24.04, 타임아웃은 90분; 주석은 「쓰기 권한을 보유한 상태에서 절대 PR 코드, 훅, 빌드 또는 서브모듈을 실행하지 말 것」을 명확히 요구하며, git 설정에서 hooksPath, attributesFile, fsmonitor를 모두 /dev/null로 지정하고, GIT_TERMINAL_PROMPT=0, GIT_EDITOR=true로 설정한다. 충돌 처리에는 전용 함수가 있다: -Xours로 처리할 수 없는 시나리오(수정-삭제 충돌 포함)는 개별적으로 ls-files --unmerged를 순회하며, 2단계가 있으면 로컬 것을 취하고 없으면 삭제한다; 리베이스 시에는 먼저 기준선이 이미 조상인지 판단하고, 「동등 패치」를 식별해 중복된 구 기준선 패치를 버린다.

이번 건이 해결하려는 것은 지난 여러 기간 반복적으로 나타난 구체적인 비용이다: 브랜치가 하루에 한 번 전체 리플레이되면 작성자 fork의 PR이 즉시 뒤처지고, 수작업으로 하나씩 리플레이하는 것은 느릴 뿐만 아니라 패치 집합을 쉽게 어지럽힌다. 경계를 명확히 해야 한다 — 그것이 리베이스하는 것은 다른 사람의 PR이며, 브랜치 자체의 일일 전체 리플레이는 여전히 유지관리자의 조작이 필요하다; 그것은 「기준선 따라가기」 비용을 수동 판단에서 미리보기가 포함된 한 번의 스케줄링으로 낮추지만, 자동화된 트리거 조건은 갖추지 않았다. 진정한 가치는 다음 외부 PR이 새 기준선으로 제출될 때에야 검증할 수 있다.

1.2 pytorch: riscv 브랜치 7일째 조용, 메인 브랜치 20건은 여전히 업스트림 (10-28 상태)

날짜: 2026-10-28(상태)　출처: pytorch riscv 브랜치, pytorch 메인 브랜치

riscv 브랜치 헤드는 여전히 10-22 03:00(베이징 시간)의 「Add riscv64 image locally (#51)」이며, 10-22부터 10-28까지 연속 7일째 커밋이 0건이다. RVV 기능 업스트림의 두 가지 메인라인 제안(#46 ATen 대상 벡터 확장 지원, #48의 RISC-V Vector CPU 기능)은 이번 기간에도 여전히 업데이트가 없다.

메인 브랜치는 같은 기간 20건으로, 전부 업스트림 동기화이며 RISC-V와 관련된 것은 한 건도 없다: CUDA 측 max_pool3d 슬라이스 내 64비트 인덱스 수정, 온라인 softmax 병합을 정확한 지수로 전환, symbolic shapes의 폐기 API 정리 롤백, inductor-benchmarks 이미지를 pytest 9.1.1로 고정, ATen 네이티브 연산자에 c10::irange 일괄 적용, ROCm의 rocSOLVER 배치 syevd 워크스페이스를 캐시 할당자에서 가져오도록 변경. 이 브랜치의 리듬은 지난 기간의 결론과 일치한다: 업스트림 추적은 일일 갱신, RISC-V 리플레이는 수동으로 시기 선택.

함께 읽을 만한 것은 배포 측이다: openRuyi의 #1352가 여전히 이 브랜치의 산출물을 python-torch-ruyiai 패키지로 만들고 있다(이번 기간 미갱신, 10-27에 정지). 브랜치는 움직이지 않고 패키지는 기다리고 있는데, 이것이 현재 pytorch 일선에서 가장 주시해야 할 어긋남이다 — 패키지가 병합될 때 브랜치가 이미 업스트림 기준선에 뒤처졌는지, 현재로서는 답이 없다.

1.3 triton-riscv: 앵커 한 단계 더 상향, riscv64 세 개 CI 큐 대기 미회신 (10-28)

날짜: 2026-10-28　출처: triton-riscv PR #91, PR #90, buddy-mlir 나이틀리 목록

18:51, renovate 봇이 #91을 열어 업스트림 buddy-mlir의 나이틀리 버전을 nightly/v0.1.3.dev20261027에서 nightly/v0.1.3.dev20261028로 올렸으며, 변경은 여전히 두 줄(+2/−2)이다. 지난 건과의 차이는 자동 병합되지 않았다는 점이다: 모니터링 기간 종료 시점까지 이 PR은 여전히 열린 상태이며, 병합 가능 상태는 unstable이다.

여덟 개 검사 중 여섯 개가 회신되었다: x64의 3.12, 3.13, 3.14 세 트랙 모두 성공, pre-commit과 clang-format 성공; riscv64의 3.12는 18:54부터 실행 중이며, 3.13, 3.14는 개설 이후 계속 대기 중이다. 같은 저장소의 지난 건(#90)은 개설 후 수 분 내에 자동 병합되었는데, 이번 건의 차이는 riscv64 측 실행 큐에 있다 — 이는 인프라 리듬에 속하며 의존성 자체의 문제는 아니다.

한 가지 시간 계산도 명확히 해야 한다: dev20261028 나이틀리 버전의 빌드 버킷은 당일 오전 세 건의 병합(#1010 08:54, #1014 09:36, #1012 09:55)보다 이르므로, 이 버전에는 K3 디코드 어텐션이 포함되지 않는다. 다운스트림이 #1014의 성과를 얻으려면 다음 나이틀리 빌드 + 또 한 건의 의존성 업데이트를 기다려야 하며, 빨라야 한 번의 빌드 주기가 필요하다.

1.4 tilelang-riscv: 메인 브랜치 13일째 정적(10-28 상태)

날짜: 2026-10-28(상태)　출처: tilelang-riscv 커밋 목록, 오픈 PR 목록, openRuyi PR #1350

메인 브랜치의 마지막 커밋은 여전히 10-16 10:52이며, 13일 연속 커밋이 없다. 오픈 PR #4도 09-28에 멈춰 있다. 저장소 측의 정적 상태는 triton-riscv 측과 대조를 이룬다. 후자는 최소한 의존성을 따라가고 있지만, 전자는 의존성 업데이트조차 움직임이 없다.

유일한 진전은 여전히 배포 측에 있다. #1350의 python-tilelang-ruyiai 스펙은 이번 기간에 PR 전체와 함께 리베이스되었으며(상세는 2.1 참조), 여전히 4개의 패치다. Apache TVM FFI 0.1.10 완화, 시스템 빌드 의존성으로 전환, buddy-mlir 툴체인 발견, z3 soname 재작성 건너뛰기다. 저장소는 정체되어 있고 패키지는 진행 중이라는, 이른바 “배포판 산출물로 저장소 반복을 대체하는” 상태가 거의 2주째 지속되고 있다.

2. RuyiSDK 툴체인과 배포판

2.1 openRuyi PR #1350: 커밋 3건 리베이스, GCC 빌드 비용 2.81배로 정량화(10-28)

날짜: 2026-10-28　출처: openRuyi PR #1350, 검토 코멘트, PR 커밋 목록

16:22, RuyiAI 3종 패키징 PR의 커밋 3건(buddy-mlir, python-triton-ruyiai, python-tilelang-ruyiai)이 같은 분 안에 모두 재작성되었으며, 명백히 최신 메인 브랜치로 리베이스된 것이다. 현재 규모는 9개 파일, +680/−0으로, 이전 기간 기록보다 14줄 늘었다. PR은 18:15에 검토 코멘트로 다시 갱신되었고, 총 코멘트 수는 13건이며 여전히 병합되지 않았다.

이번 기간 가장 정보량이 많은 항목은 작성자의 10:41 답변에서 나왔다. 이전 기간의 표현은 “GCC로 대체할 수 있지만 빌드 시간이 최소 1.5배”였는데, 이번 기간에는 실측치를 제시했다. riscv64 머신에서 buddy-mlir의 빌드를 LLVM에서 GCC로 바꾸면 시간이 8814초에서 24798초(약 2시간 27분 대 6시간 53분)로, 2.81배가 되며, 그 GCC 빌드는 링크 단계에서 실패해 완료되지 못했다.

이 항목은 논쟁을 입장 문제에서 비용 문제로 바꿔 놓았다. “buddy-mlir에 내장된 LLVM을 외부화할지”는 원래 두 기술 노선 간의 다툼이었지만, 이제 배포판 빌드 팜이 이해할 수 있는 숫자가 생겼다. 2.81배라는 것은 일정, 머신 점유, 타임아웃 전략을 모두 다시 계산해야 한다는 뜻이다. 작성자의 또 다른 이유도 이로써 더 설득력을 얻는다. buddy-mlir가 사용하는 LLVM은 자신의 패키지 안에서만 사용되며, 이 패키지들은 모두 구체적인 LLVM 커밋을 고정하고 있어 패키지 안에 두어야 재현 가능하다는 것이다. 동시에 그는 triton 업스트림의 setup.py에 git 실행 가능 여부를 강제로 검사하는 부분이 있어, git 빌드 의존성을 추가하거나 setup.py를 패치해야 한다고 설명했다(후자는 triton 업그레이드 시 무효화된다).

2.2 openRuyi: 커밋 27건, PR 15건 병합, qemu 11.1.2와 libvirt 백포트 적용(10-28)

날짜: 2026-10-28　출처: openRuyi 커밋 목록, PR #1520 qemu, PR #1519 libvirt, PR #1521 python 패키지, PR #1522 툴체인 매크로

이번 기간 메인 저장소는 27건의 커밋과 15건의 PR 머지가 있었으며, 9명이 참여했습니다: misaka00251 8건, Ruoqing He 4건, Sun Yuechi 4건, Jingiw 3건, Zheng Junjie 3건, Kimmy 2건, cl2t, Julian Zhu, YunQiang Su가 각 1건입니다. 모든 커밋은 11:20부터 20:49 사이에 집중되었으며, 그 이후 모니터링 기간 종료까지 신규 커밋은 없었습니다. 규모는 지난 기간(45건) 대비 명확히 줄어들었고, 성격도 “릴리스 전 정리”에서 일상적 추종으로 전환되었습니다.

가상화 측면은 이번 기간 가장 완결성 있는 그룹입니다. qemu는 11.1.x에서 11.1.2로 업그레이드되었으며(#1520, 13:28 머지), 지난 기간에는 “검토 대기열”에 있었으나 하루 만에 반영되었습니다. libvirt는 2건 머지되었습니다(#1519, 09:47): 첫째는 /var/lib/libvirt/secrets를 패키지와 함께 배포하여 virt-secret-init-encryption에 필요한 디렉터리가 존재하게 하고 virtsecretd가 기동할 수 있도록 한 것이고, 둘째는 Ceph 21에서 auth_supported 제거 이후 rbd 풀이 무효화되는 문제를 수정한 것을 백포트한 것입니다. 이 두 건 모두 “설치는 되지만 실행되지 않는” 유형의 문제를 해결하는 패치로, 배포판 품질의 핵심 지표에 해당합니다.

패키징 인프라 측면에도 내용이 있습니다. %toolchain_major_version 매크로가 머지되었으며(#1522, 12:36), gcc-15, gcc-16 또는 clang-22, clang-23 같은 툴체인 메이저 버전을 지정할 수 있습니다—이는 현재 검토 중인 크로스 툴체인 PR에 착지점을 제공합니다. python 패키지 빌드 실패 배치가 머지되었습니다(#1521, 14:02): scikit-build-core는 1.1.1로, cmake는 Python 배포 패키지 메타데이터를 보강하고, ml-dtypes는 0.6.0으로, charset-normalizer는 3.5.2로, httptools는 setuptools에 대한 버전 고정을 완화했습니다. scikit-build-core와 cmake 메타데이터 두 건은 RuyiAI 스택에 직접적 의미가 있습니다—triton과 tilelang 같은 CMake 확장의 wheel 빌드가 바로 이 경로를 따르기 때문입니다.

나머지 머지: attr 2.6.0으로 업그레이드, go 인덱스 최적화 백포트, python-backports-zstd 삭제, go 계열 패키지가 gcfg v2 개명을 따라 의존성 수정, python-graphql-core 3.2.13으로 다운그레이드, procps rpm 이름 수정 및 uptime 복원, krb5 빌드 옵션 그룹과 systemd 서비스, ceph 업스트림 스냅샷 추종, sql-migrate 신규 추가, rustvmm 4개 crate 의존성(linux-loader 0.14, vm-memory 0.18, kvm-ioctls 0.25, acpi-tables 0.2.1), 루트 디렉터리에 .gitignore 보충.

2.3 검토 대기열: KDE Frameworks 6.31, 크로스 툴체인, Gradio 6.31 (10-28 상태)

날짜: 2026-10-28 (상태)　출처: PR #1513 KDE, PR #1490 크로스 툴체인, PR #1516 qemu-rustsbi, PR #1532 Gradio

모니터링 기간 내 갱신된 오픈 PR은 총 9건입니다. KDE Frameworks 6.31.0의 WIP 업데이트는 00:04에 갱신되었으며(#1513), 여전히 WIP 표시입니다. 크로스 riscv64 툴체인(#1490, Z572)은 14:18에 갱신되었고 여전히 WIP입니다—이번 기간 머지된 툴체인 메이저 버전 매크로와 한 쌍을 이룹니다: 매크로는 전환 진입점을 제공하고, PR은 구체적 툴체인을 제공하며, 둘 다 갖춰져야 크로스 컴파일이 사용 가능해집니다. Gradio 6.31.0과 그 의존성 정렬(#1532), python-pyvex 10.0.5 업그레이드(#1533), graphql-core의 수동 provides 에포크 버전 수정(#1531) 세 건이 20:03부터 21:27 사이에 집중 갱신되었습니다. qemu-rustsbi(#1516)에는 두 건의 논의가 있으며, Rust로 작성된 SBI를 가상화 스택에 도입하기 위한 사전 작업입니다. 나머지는 vkpeak(#1349)와 Prometheus v3.13 모듈(#1441)입니다.

2.4 ruyisdk: 0.54.0 여전히 미출시, 패키지 목록과 지원 매트릭스 조용, 설치 프로그램 UI 용어 변경 (10-28 상태)

날짜: 2026-10-28 (상태)　출처: ruyi Releases, packages-index, support-matrix, ruyi-imager 커밋 a87b8dd9

패키지 관리자 ruyi의 메인 브랜치는 09-25 이후 커밋이 없으며, Release 최신 버전은 여전히 09-24의 0.53.0이고, 0.54.0은 09-18의 alpha 태그만 존재한다. 격주 진행 상황 079호의 기준은 “0.54.0은 릴리스 주기 조정으로 10월 말로 변경”이었으나, 월말까지 이틀밖에 남지 않은 시점에서 이번 호에도 beta나 후보 버전이 없어 이행 기간이 매우 좁아졌다.

packages-index는 모니터링 기간 내 커밋이 없다(최신은 10-26의 revyos Milk-V Meles 이미지 버전 상향에서 멈춤). 이는 079호에서 언급된 ISCAS 소프트웨어 소스 데이터 동기화 문제와 서로 부합한다 — 빌드가 완료된 패키지가 공개망에 갱신되지 않아, 목록 측에서도 자연히 일괄 업데이트가 없다. support-matrix도 모니터링 기간 내 커밋이 없으며, 지난 호의 두 보드(SpaceMiT K3 Pico-ITX의 Bianbu 4.0.8을 good으로 평가, VisionFive 2 Lite의 Ubuntu 24.04.5를 basic으로 평가)가 가장 최근 배치이다.

ruyi-imager에는 한 건이 있다: 15:46의 “Rename manufacturer labels to supplier in the GUI”로, 인터페이스의 “제조사”를 “공급업체”로 통일했다. 이는 릴리스 전 표현 기준 통일에 해당하며, 지난 호의 “선택 대화상자에서 사전 선택 제거”와 같은 부류로, 모두 설치기의 사용성 다듬기에 해당한다.

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

3.1 벡터 저장소와 FBGEMM 세 저장소 정숙, cpuinfo는 05-20에서 정지 (10-28 상태 States)

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

본 주제 관련 네 개 저장소 모두 모니터링 기간 내 커밋이 전무하며, 정숙 기간도 이미 짧지 않다: VecIntrinBench는 02-13, cpuinfo는 05-20, IntrinTrans는 06-25, FBGEMM은 07-13에서 정지했다. torq-tile은 04-09에서 정지, dsh-osc는 09-15에서 정지, pytorch-ci는 커밋 기록이 없다.

이는 이번 호의 벡터 측 진전이 모두 다른 곳에서 발생했음을 의미한다 — 표현 계층은 buddy-mlir의 VIR에서, 툴체인 계층은 llvm의 riscv 브랜치에서 이루어졌으며, 전용 벡터 내장 테스트 및 연산자 최적화 저장소에서는 아니다. “벡터 역량 상향”을 목표로 하는 스택에게 테스트 기준 측의 장기 부동은 위험 요소다: VIR이 이제 확장 가능 벡터를 표현할 수 있지만, 지속적으로 점수를 산출하는 벡터 내장 벤치마크가 없으면 이후 최적화가 실제 향상인지 변동인지 판단하기 어렵다(#1014에서 이미 “동일 코드의 두 빌드 간 2% 차이” 상황이 발생했으며, 이를 판단하려면 안정적인 기준이 바로 필요하다).

3.2 벡터 폭 기준: VIR 측 1024비트로 확정, 단일 헤드당 하나의 LMUL 4 그룹 (10-28)

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

#1014는 커널 하향 목표 벡터 길이를 1024비트로 정하고 확장 가능 벡터를 사용하지 않도록 요구하여, 각 헤드(128개의 f32)가 정확히 하나의 LMUL 4 벡터 그룹을 차지하고, 영역 내의 vir.shuffle도 정확히 그룹 내에서 완료된다 — 크기, 그룹화, 명령어 세 가지가 동일한 매개변수 그룹에 의해 제약되며, 이는 이번 호에서 기록할 만한 기술 기준이다.

이 기준은 업스트림 백엔드와 같은 사안의 양 끝단이다. 지난 모니터링 기간에 llvm riscv 브랜치에 병합된 #30은 IME 내장을 SpacemiT A100의 점곱 명령으로 내리고, #31은 A100에 HP/SP와 pack/unpack의 강등 경로를 추가하고 스케줄링 보정을 수행했다. 하나는 백엔드가 레지스터 기준으로 명령 선택과 스케줄링을 하는 것이고, 다른 하나는 커널 표현 계층이 레지스터 기준으로 벡터 크기를 정하는 것이다. 현재 두 곳의 파라미터가 서로 제약이 되는지 설명하는 문서가 없고, K3에서 교차 검증도 이루어지지 않았다. 다음 단계에서 확장 가능 벡터로 전환할 때(작성자는 다음 커밋이라고 밝혔다) 이 기준이 흔들릴지가 가장 주목할 만한 지점이다.

3.3 arXiv 모니터링 기간 내 신규 없음, 10-21의 장벡터 FlashAttention이 여전히 RVV에 가장 근접 (10-28 상태)

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

RISC-V에 컴파일러, 벡터, MLIR을 조건으로 한 검색에서 모니터링 기간 내 신규 논문은 없었다. 최신은 여전히 10-23의 개방 ISA 슈퍼컴퓨팅 아키텍처 비교와 10-22의 바이너리 리프팅에서 정규 컴파일러 IR로의 멀티 에이전트 프레임워크다. 이번 호 주제와 가장 근접한 것은 여전히 10-21의 「Reorienting the Vector Axis: Restructuring FlashAttention for Long-Vector Processors」다. 장벡터 프로세서에서의 FlashAttention 재구성으로, #1014가 디코딩 어텐션을 64 lanes로 분할하고 단일 헤드에 LMUL 4 그룹 하나를 쓰는 방식과 같은 종류의 문제에 속한다. 아쉽게도 모니터링 기간 내 후속은 없었다.

4. Buddy Compiler 동향

4.1 K3 디코딩 어텐션을 VIR로 이전: 수치 비트 단위 일치, K3 실측 처리량 동일 구간 (10-28)

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

지난 호에서는 #1009의 Python 바인딩을 “buddy-opt 전용에서 프로그래밍 가능한 다이얼렉트로” 기록했는데, 이번 호는 이 바인딩으로 작성된 첫 실제 결과물을 제시한다. #1014가 병합되었고(09:36), 4개 파일, +476/−14로 커널 구현 264줄 추가, 테스트 152줄, 강등 파이프라인 10줄, K3 문서 50줄이다.

기술적 요점은 「오늘의 중점」에서 다루었으므로 여기서는 검증 가능한 세부 사항 세 가지만 보충한다. 첫째, PR은 이것이 이미 닫힌 #998을 다시 수행한 것임을 명확히 밝히고 있으며, 재작업의 기반은 이후 네 건이다: 활성도 기준 크기 결정(#1000), 행(#1005), vir.shuffle(#1006), Python 바인딩(#1009) — 즉 이것은 독립적 최적화가 아니라 앞선 네 건의 토대를 한 번에 부하 테스트한 것이다. 둘째, 검증이 상당히 견고하다: 테스트는 _attn_decode_fn에 대해 비트 단위 비교를 수행하며, 스레드 사용/미사용, 시작점 0/15/16/37/70을 커버하고, q/k 정규화 시에는 0/37을 커버한다. test_k3_w4_moe.py의 qk_norm 경로도 VIR 커널을 실행한다. check-buddy 239 + 401 전부 통과했다. 셋째, 기계어 수준에서 두 병렬 바디는 각각 178개의 벡터 명령이며, 키-값 루프는 구 버전과 완전히 동일하고, 두 곳의 스필 레지스터 재로드 위치만 변했으며, q의 회전은 두 개의 LMUL 2 반그룹 상의 연산에서 vfneg와 레지스터 이동 한 번으로 바뀌었다.

한 가지 유의할 점: 이번 “성능 동등”은 K3 단일 보드, 그리디 디코딩, 세 가지 시퀀스 길이에서 얻은 것이며, 작성자도 동일 코드의 두 빌드가 2% 차이 날 수 있다고 명시했다. 이것은 VIR이 더 이상 성능 손실을 유발하지 않음을 증명하는 것이지, VIR이 수작성 커널보다 우수함을 증명하는 것은 아니다.

4.2 buddy-server 소스 재구성, Whisper 예제 x64 CI 진입 (10-28)

날짜: 2026-10-28　출처: PR #1010, PR #1012

#1010은 08:54에 병합되었고, 47개 파일, +349/−292로 이번 호에서 변경 규모가 가장 큰 건이다. 내용은 역할에 따라 buddy-server를 재정비하는 것이다. 프로덕션 소스는 HTTP, 프로토콜, 플러그인 세 블록으로 그룹화하고, 테스트는 단위, 통합, 패키징, 픽스처 디렉터리로 분류했다. buddy-server-core 라이브러리를 도입하여 테스트가 프로덕션 소스를 중복 컴파일하는 것을 피했고, 서비스 수명 주기와 라우트 등록을 BuddyServerApp으로 추출하여 실행 진입점에는 인자 파싱과 시작만 남겼다. 이런 종류의 리팩터링은 기능에 영향을 주지 않지만, 이후 인터페이스 변경을 위한 공간을 확보했다.

#1012는 09:55에 병합되었으며, 파일 4개, +92/−3으로 Whisper 예제에 출력 검증을 추가하고 이를 x64 CI에 연결했습니다. PR 설명에 따르면 이 PR은 issue #757의 Whisper와 x64 부분만 처리하며, 나머지 예제는 여전히 해당 issue에 남겨둡니다. 또한 로컬 검증이 #1011의 빌드 수정(확장 가능한 VIR의 조각 카운트를 int64로 강제 변환)에 의존한다고 명시했는데, 이 수정 자체는 아직 병합되지 않았습니다. 즉, 이 CI의 녹색 신호는 아직 메인 브랜치에 들어가지 않은 빌드 수정 위에서 얻어진 것입니다.

4.3 심사 중 네 건: int64 강제 변환, Whisper 전처리 재사용, 신규 ABI, llama-server 정렬 (10-28 상태)

날짜: 2026-10-28 (상태)　출처: PR #1011, PR #1013, PR #1015, PR #994

열린 PR 네 건이 모니터링 기간 내에 업데이트되었습니다. #1011은 컴파일 수정입니다: 저장소가 고정한 Clang/LLVM 버전에서 divideCeil이 부호 없는 값을 반환하는데, 집합 초기화가 이를 int64 필드에 넣으면 축소 오류가 발생하므로, 수정 방법은 명시적 변환을 사용하며 나눗셈, 벡터 폭, 마스크 및 레이아웃은 변경하지 않습니다(+4/−4, 파일 1개). 이 변경은 작지만 #1012가 실행될 수 있는 전제 조건입니다. #1013은 16:01에 갱신되었으며 Whisper의 전처리 결과를 재사용하여 중복 계산을 줄입니다. #1015는 22:53에 갱신되었으며 buddy-server에 신규 ABI를 적용합니다. #994는 15:35에 갱신되었으며 buddy-server의 인터페이스를 llama-server에 정렬하는 변경으로, 이 정렬 방향을 가장 먼저 제안한 PR이며 아직까지 병합되지 않았습니다.

4.4 야간 빌드 dev20261028 출시, 당일 세 건은 여전히 미포함 (10-28)

날짜: 2026-10-28　출처: 야간 빌드 dev20261028, Releases 목록

야간 빌드는 07:56에 릴리스되었습니다(v0.1.3.dev20261028). 빌드 시점이 당일 오전 세 건의 병합(#1010 08:54, #1014 09:36, #1012 09:55)보다 빨랐으므로, 이 버전에는 K3 디코드 어텐션도, buddy-server 재구성도, Whisper CI도 포함되지 않습니다. 0.1.3 라인은 네 번의 야간 빌드 연속으로 정식 버전이 없었으며(최근 정식 버전은 10-25의 0.1.2), 다음 야간 빌드가 #1014가 다운스트림에 진입하는 첫 지점입니다.

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

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

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

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

이 측면과 엔지니어링 측면의 격차는 이번 기간에 더욱 두드러졌습니다: 같은 날 VIR이 실제 모델 커널을 담고, llvm 브랜치가 리베이스 워크플로를 보완하고, 배포판에 15건이 병합되었지만, 공식 콘텐츠 페이지는 여전히 9월의 두 글에 머물러 있습니다. #1014의 K3 실측 데이터(보드 처리량, 명령어 수, 비트 단위 일치) 자체가 이미 완성된 기술 블로그 소재이지만, 현재 PR 설명과 저장소 문서에만 존재합니다.

5.2 포럼 모니터링 기간 내 신규 게시물 없음; 10-27의 LPi4A UEFI 실측 게시물 추가 기록 (10-27)

날짜: 2026-10-27　출처: lpi4a UEFI #2896, RuyiSDK 개발자 커뮤니티

포럼 모니터링 기간 내 신규 게시물은 없으며, 최신 게시물은 여전히 10-27의 #2896입니다. 여기서 한 가지를 정정합니다: 이전 회차에서 포럼 상태를 「최신 두 건이 10-22의 서밋 회고와 강좌 자료에 멈춰 있다」고 작성했는데, 10-26의 격주 진행 #2895(해당 항목은 10-27 회차에서 이미 다루어짐)와 10-27의 #2896을 누락했습니다. 후자는 두 모니터링 기간 사이에 건너뛰어졌으며, 이번 회차에서 추가 기록합니다.

#2896 「lpi4a UEFI」라는 제목으로 10-27 10:45에 lzzhzh가 게시했으며, 스크린샷 6장과 실사 사진이 첨부되었다. 1366×768 시스템 스크린샷 3장, 1920×1440 실사 사진 3장이다. 본문에 따르면 9월 26일에 이미 업데이트가 있음을 발견했고, 한 달을 참은 뒤에야 LPi4A에 롬을 올렸다. 현재 UEFI에 맞는 RevyOS는 아직 사용할 수 없지만 「적어도 희망은 있다」고 했다. Yuxi는 「좋지 좋지」라고 답했다. 이 글의 가치는 LPi4A 펌웨어 생태계의 실제 병목 지점을 기록했다는 데 있다. UEFI 펌웨어는 이미 플래시할 수 있지만, 여기에 맞는 배포판 이미지가 아직 따라오지 못한 것이다. 이는 바로 지원 매트릭스(support-matrix)가 수록해야 하지만 현재 모니터링 기간 내에는 커밋이 없는 그런 상태다.

5.3 ruyiai-daily 1회차, ruyi-imager가 「제조사」를 「공급업체」로 변경(10-28)

날짜: 2026-10-28　출처: ruyiai-daily, ruyi-imager 커밋 a87b8dd9

ruyiai-daily는 06:22에 「daily-news: 2026-10-28」 회차를 커밋하며 일별 아카이빙 정보 동향을 이어갔다.

ruyi-imager는 15:46에 커밋 하나를 올려 인터페이스의 「제조사」 라벨을 일괄적으로 「공급업체」로 변경했다. 변경은 작지만 방향은 명확하다. 설치 프로그램이 대상으로 하는 것은 보드 공급 측이지 칩 제조 측이 아니므로, 표현을 실제 의미에 맞게 정리한 것이다. 나머지 저장소는 모니터링 기간 내 커밋이 없다. harness는 10-27에, ruyisdk-website는 10-23에, wechat-articles는 10-26에 멈춰 있으며 docs와 attached-matrix-extension은 모두 움직이지 않았다.

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

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

Google News에서 RuyiSDK, RuyiAI, openRuyi 및 Ruyi RISC-V에 대한 중영문 타깃 검색은 모니터링 기간 내 제로 히트였다. 「Ruyi RISC-V」 검색 결과 중 최신 항목은 10-25의 정상 참가 보도(에이싱즈 인텔리전트)로, 모니터링 기간 밖에 있고 Ruyi 커뮤니티와 무관하므로 이번 회차에는 수록하지 않는다.

배포판 쪽 두 버전 모두 여전히 모니터링 기간 밖에 있다. openRuyi 뉴스 페이지의 최신 글은 여전히 2026.09 릴리스 공지(9-30)이며, 저장소 태그는 2026.09-experimental에서 멈춰 있고 2026.10은 미발표다. ruyi의 0.54.0은 09-18의 alpha 태그만 있으며, 정식 버전은 079호 기준대로라면 10월 말을 기다려야 한다. 지난 몇 달의 리듬(6-30, 7-23, 8-27, 9-30)에 따르면 10월 버전은 대체로 이번 달 말에 나올 가능성이 높다. 월말까지 이틀 남은 지금, 다음 회차가 이 일을 확인할 마지막 기회다.

6. 트렌드 관찰

6.1 「표현할 수 있음」에서 「똑같이 빠르게 달림」으로: VIR이 처음으로 실제 모델 커널로 성능 대조를 수행

지난 세 회차 동안 이 메인라인은 줄곧 표현력을 보강해 왔다. 10-26 하룻밤 일곱 건으로 확장 가능 벡터를 추가했고, 10-27에는 Python 바인딩을 보강했으며, 10-28에는 K3의 디코드 어텐션 전체 구간을 그대로 옮기고 보드 상의 스루풋으로 대조했다. 세 숫자를 합쳐야 이번 일의 의미가 완성된다. 수치 비트 단위 일치, 명령어 수 동일(각 178개), 스루풋 구간 중첩. 자체 개발 방언은 「돌아가지만 느림」이라는 관문에서 가장 자주 막히는데, #1014는 적어도 이 관문은 일단 통과했음을 증명했다.

하지만 이 스택이 정말로 수작업 커널을 대체할 수 있는지 판단하려면 아직 두 가지가 부족하다. 첫째는 커버리지다. 이번에는 디코드 어텐션만 옮겼고 A210 커널은 여전히 구 함수를 쓰며, MoE, 양자화, 프리필 경로는 아직 건드리지 않았다. 둘째는 확장 가능 벡터다. 이번 회차에서는 use-scalable을 명시적으로 껐는데, 다음 커밋에서 이를 켜면 벡터 크기가 더 이상 컴파일 시점에 결정되지 않고 LMUL 4의 그룹 가정이 흔들리게 된다. 그때 수치와 명령어 수를 지킬 수 있을지는 다시 대조해야 한다. 그 전까지는 「VIR이 이미 수작업 커널을 따라잡았다」를 결론으로 삼기에는 이르며, 정확한 표현은 「K3 디코드 어텐션 이 구간에서, 고정 벡터 길이 하에서 따라잡았다」이다.

6.2 기반 교체의 비용이 패치 드리프트에서 거버넌스로 이동: 워크플로가 리베이스를 인수하지만 브랜치 자체는 여전히 사람에 의존

같은 날 llvm의 riscv 브랜치는 전체 브랜치 재생을 중단하고 244줄짜리 자동 리베이스 워크플로를 추가하는 방식으로 바꿨다. 이 전환은 따로 기록할 만하다. 지난 5일의 리듬은 「하루 한 번 전체 브랜치 재생, 매번 스무 건의 커밋 흐름을 다시 씀」이었고, 작성자 시간은 그대로, committer 시간은 통일되었으며, 패치 집합 자체에는 새 기능이 없었다. 이 방식은 업스트림을 따라갈 수는 있지만, 대가로 외부 기여자의 PR은 영원히 한 칸 뒤처지게 되어 누군가 제출하려면 스스로 재생해야 한다.

새 워크플로는 이 작업을 “PR 번호 입력, 기본 사전 리허설, 원클릭 푸시”의 스케줄링으로 만들었고, 충돌은 일률적으로 riscv 측을 취하며, 중복 패치는 자동으로 폐기되고, PR 코드와 빌드는 절대 실행하지 않는다. 이는 브랜치 자체의 매일 추종을 해결하지는 않지만, “베이스라인 추종 비용”을 메인테이너의 수동 판단에서 일부 분리해냈다. 다음 단계에서 관찰할 것은 외부 PR이 정말로 이로 인해 많아지는지 여부다. 만약 워크플로가 출시된 후 2주 이내에도 여전히 새로운 베이스라인으로 제출된 외부 PR이 없다면, 병목이 리베이스 도구가 아니라 다른 곳에 있다는 뜻이다.

6.3 배포 계층의 논쟁에 가격이 붙기 시작하다: 2.81배의 빌드 시간이 “선호”보다 더 설득력 있다

#1350은 거의 한 달간 논쟁했으며, 핵심 쟁점은 buddy-mlir 자체의 LLVM을 외부화할지 여부였다. 지난 호의 입장은 여전히 “GCC를 쓸 수 있지만 최소 1.5배 시간이 든다”였는데, 이번 호 저자는 실측치를 제시했다. riscv64에서 8814초가 24798초로, 2.81배가 되었고, GCC를 사용한那次는 링크 실패로 완료되지 못했다. 논쟁의 성격은 이로 인해 바뀌었다. 기술적 선호에서 빌드 팜의 일정 산술로.

이 조항이 RuyiAI 스택에 주는 시사점은 결론이 아니라 방법에 있다. RISC-V 배포판 패키징의 많은 쟁점(vendor 여부, 툴체인 외부화 여부, IR 동봉 배포 여부)은 결국 “빌드 시간, 이미지 크기, 재현성”이라는 세 가지 측정 가능한 숫자로 귀결되어야 한다. 지난 호에서 openRuyi가 “LLVM IR 동봉 배포” 노선을 철회했고, 이번 호 #1350은 2.81배로 “LLVM을 패키지 내에 유지”를 지켰으니, 두 판단의 방향은 반대지만 근거는 동일한 유형의 비용 산정이다. 다음 관전 포인트는 이 PR이 이 숫자를 가지고 합류될 수 있는지 여부다. 만약 그럴 수 없다면, 배포판이 빌드 소요 시간에 대한 허용도가 저자의 예상보다 낮다는 뜻이며, 그것이야말로 진정으로 조정이 필요한 지점이다.

출처 검증표

출처 검증 결과
RuyiAI-Stack 조직 (전체 저장소) llvm-project: riscv 브랜치 1건 추가 (cf00909d, 리베이스 워크플로 +244/−0), 로컬 패치셋 변경 없음; pytorch: riscv 브랜치 연속 7일째 커밋 0건, 메인 브랜치 20건 전부 업스트림; triton-riscv: 의존성 업데이트 PR #91 1건 (미병합); tilelang-riscv 13일째 조용; ruyiai-daily 1건; harness, FBGEMM, cpuinfo, VecIntrinBench, IntrinTrans, torq-tile, pytorch-ci, dsh-osc, skills, SyncBots-DeepAgents, caffe, mxnet 모니터링 기간 내 커밋 없음
ruyisdk 조직 (전체 저장소) ruyi-imager 1건 (인터페이스 용어 통일); packages-index, support-matrix, docs, ruyisdk-website, wechat-articles, attached-matrix-extension, ruyici, AME-operator 모니터링 기간 내 커밋 없음; ruyi 메인 저장소 09-25 이후 커밋 없음, 새 Release 없음 (0.53.0 유지)
openRuyi-Project 조직 openRuyi 메인 저장소 27건 커밋 (misaka00251 8, Ruoqing He 4, Sun Yuechi 4, Jingiw 3, Zheng Junjie 3, Kimmy 2, 나머지 3인 각 1) + PR 15건 병합; qemu 11.1.2, libvirt 2건, 툴체인 메이저 버전 매크로, python 패키징 배치 포함; 오픈 PR 9건 업데이트 (RuyiAI 2건 포함, 그중 #1350은 커밋 3건 리베이스); 새 태그 없음 (2026.09-experimental이 최신)
buddy-compiler 조직 buddy-mlir 3건 병합 (#1014 K3 디코딩 어텐션, #1010 buddy-server 재구성, #1012 Whisper x64 CI) + 나이틀리 빌드 v0.1.3.dev20261028; 오픈 PR 4건 업데이트 (#1011, #1013, #1015, #994); buddy-benchmark, buddy-examples, compiler-eval, FeGen, gemmini, firesim 모니터링 기간 내 커밋 없음
RuyiSDK 개발자 커뮤니티 포럼 모니터링 기간 내 새 게시글 없음; 최신 #2896 “lpi4a UEFI” (10-27 10:45)는 지난 호 누락 건으로 이번 호에 보충 수록; 격주 진행 상황 079호 (10-26)가 최근 공식 보고이며, 080호는 11월 상순 예정
openRuyi 배포판 뉴스 페이지 새 글 없음, 2026.09 릴리스 공지 (9-30)가 여전히 최신; 저장소 태그는 2026.09-experimental에서 멈춤, 2026.10 미릴리스
ruyi 패키지 매니저 / Releases 0.53.0 유지, 새 alpha 또는 beta 없음 (0.54.0-alpha.20260918이 여전히 최근 버전); 메인 브랜치 09-25 이후 커밋 없음
공식 홈페이지 (ruyiai.org) 세 페이지 변화 없음: 홈페이지 인덱스 3건, 블로그 2편, 문서 23장, sha256이 지난 호와 동일
arXiv (RISC-V) 모니터링 기간 내 신규 없음; 최신은 10-23의 개방형 ISA 슈퍼컴퓨팅 비교와 10-22의 바이너리 향상에서 컴파일러 IR 프레임워크까지, 10-21의 장벡터 FlashAttention이 여전히 RVV에 가장 부합
Google News RSS (중영문 다중 그룹) RuyiSDK, RuyiAI, openRuyi, 루이 RISC-V 대상 쿼리 적중 0건; “루이 RISC-V” 최신 1건은 10-25의 서밋 참가 보도로 모니터링 기간 밖이며 루이 커뮤니티와 무관하여 미수록

전체 출처 목록