모니터링 기간: 2026-09-05 10:18 ~ 2026-09-06 10:18 베이징 시간 출처: GitHub(org: flagos-ai 52개 저장소 + commit search 21건 전량 + 기본 브랜치 per-repo 검증 + tags/releases 날짜 검증), Google News RSS(중영문 13개 쿼리, 프록시 경로 정상), HN Algolia, Tavily 검색, Zhiyuan 커뮤니티 hub.baai.ac.cn, FlagOS CSDN 공식 커뮤니티 계정(상세는 부록 참조)

인덱스

    1. 오픈소스 프로젝트 진행(GitHub 동향)
      • 1.1 FlagSparse「more backends」: 백엔드 매트릭스 5개사로 확대——MetaX 실장, Moore Threads/Ascend 등록, 디바이스 추상화 이관 269건(09-05)
      • 1.2 build-infra: vLLM 전달 라인——Enflame 듀얼 SDK 라인/Cambricon 이미지 tag 일괄 등록, wheel 빌드 host-side 패치 메커니즘으로 변경, Iluvatar CoreX FlagGems attention 경로 주입(09-05/09-06)
      • 1.3 build-infra: Cambricon 0.20.2 콜드 첫 실행 깨진 문자 근본 원인 규명——flag_gems copy_ 가 MLU 디바이스 상태를 오염, 블랙리스트 수정 후 실제 전달(09-05)
      • 1.4 build-infra: sglang 0.5.18 콜드 스타트 거버넌스——타임아웃 노브/레디니스 게이팅/watchdog 적용, Moore Threads 0.5.18 전달 기록 완비(09-05/09-06)
    1. 뉴스 보도와 생태계
      • 2.1 컴포넌트급 뉴스 연속 네 번째 조용한 기간, 검색 기간 내 적중 0건(09-05~09-06)
      • 2.2 생태계 참고: Zhiyuan 커뮤니티 SGLang 라운드테이블 대담 전재——「검증 가능성이 다음 병목」(09-05)
    1. 멤버 단위 심층 분석
      • 3.1 멤버 단위 기간 내 신규 동향 없음(09-05~09-06)
      • 3.2 FlagSparse 공동 빌드 팀 배경: 중국과학원 계산기술연구소 계열 AlphaSparse 듀얼 채널 지속 병합(09-05)
    1. 요약
  • 부록: 전체 출처 목록

1. 오픈소스 프로젝트 진행(GitHub 동향)

기간 총괄: org 내 52개 저장소 중 7개가 기간 내 푸시가 있었고, commit search 적중 21건 기간 내 커밋(build-infra 17건, FlagSparse 4건); tags/releases 검증 결과 기간 내 신규 tag 없음, 신규 release 없음(FlagSparse v0.3.0-rc0.post1은 09-01 게시로 기간 이전, vllm-plugin-FL v0.3.0-rc0은 08-24 게시, FlagGems v5.4.0.dev0, FlagTree v0.4.0 시리즈, build-infra v2.1.1 모두 그 이전); docs, release-info, sglang-plugin-FL, vllm-plugin-FL, FlagTree의 pushed_at 변화는 기본 브랜치 commits 검증 결과 모두 비기본 브랜치(PR 브랜치) 동작으로 기간 내 실질 병합 없음——2.2 릴리스 안정기 지속. 이번 기간 메인 라인: 첫째, FlagSparse(희소 연산자 라이브러리) 백엔드 매트릭스가 CUDA/DCU 듀얼 백엔드에서 5개 백엔드로 확대——”more backends”(PR #51)가 디바이스 추상화 이관(269건 CUDA-specific 호출 추상화) 완료, MetaX(MetaX MACA/Xiyun C550) 백엔드가 “CUDA로부터 이식 + 시뮬레이션 검증” 형태로 실장되어 spsv v0.1 구동 완료, Moore Threads(MUSA)와 Ascend(CANN)는 provisional 백엔드로 등록; 둘째, build-infra의 vLLM 전달 라인이 “콜드 스타트 의미 검증과 전달 감사” 단계로 진입——Cambricon 0.20.2 콜드 첫 실행 깨진 문자 근본 원인이 완전히 규명되고(flag_gems copy_ 가 MLU 디바이스 상태를 오염) 블랙리스트 반복 수정으로 실제 전달(08-26 무의미 게이트의 위양성 녹색 표시를 뒤집음); 셋째, Iluvatar CoreX 전달 경로가 F 경로(FlagGems) 우선으로 정형화——0.20.2 구 유지보수 라인 활성화 + VLLM_FL_USE_FLAGGEMS_ATTN=1 주입 + symm-mem 임포트 guard 패치, 09-04의 “T 경로 전달 불가” 판정과 함께 폐쇄 루프 형성.

1.1 FlagSparse「more backends」: 백엔드 매트릭스 5개사로 확대——MetaX 실장, Moore Threads/Ascend 등록, 디바이스 추상화 이관 269건(09-05)

출처: FlagSparse PR #51(dc076010b2), commit 41c7c102(spsv on metax v0.1), docs/METAX_TESTING.md, README 백엔드 매트릭스

  • 09-05 10:59~12:18, FlagSparse 기본 브랜치에 연속 4개의 커밋(직접 푸시 41c7c102/7f41348d + 업스트림 병합 0cad7f78 + PR #51 “more backends”이 12:18에 병합, 총 23개 파일), 모두 외부 희소 연산 팀 NCIA-AlphaSparse(커밋 이메일 도메인 ict.ac.cn, 중국과학원 계산기술연구소 배경; NCIC-AlphaSparse는 그 업스트림 org 미러, 3.2 참조)에서 비롯되었다. 이는 어제 리포트에서 누락된 09-04 11:11 커밋 fb18e881 “metax musa ascend added, need to check”(모니터링 기간 시작 전)의 반영판이다.
  • 백엔드 매트릭스와 디바이스 추상화 이전: README에 5개 백엔드 표가 새로 추가됨——CUDA / DCU(ROCm) / MetaX(MACA, Xiyun C550) / Moore Threads(MUSA) / Ascend(CANN 910B); sparse_operations/ 아래 269곳의 CUDA-specific 호출이 추상화 완료(189곳은 _ACCEL.*로, 82곳은 _is_accel_tensor()로 변경). CUDA/ROCm/MACA 세 가지의 _ACCEL은 모두 torch.cuda로 해석되어, 바이트 수준 동등, kernel 무변경; Moore Threads와 Ascend는 torch.musa/torch.npu가 CUDA-compatible 디바이스 유형이 아니므로 당분간 torch.sparse로 폴백(provisional 표기).
  • MetaX 감지 메커니즘: MACA는 CUDA와 소스 호환(머신에서 torch.version.cuda 값이 있고 torch.version.hip은 None), 기존 ROCm 판별 기준으로는 MetaX와 NVIDIA를 구분할 수 없음——감지는 FLAGSPARSE_BACKEND 환경 변수 → MetaX 전용 torch.version 속성 → MACA SDK 환경(MACA_PATH/HOME) → 디바이스 이름/C550 모델 문자열 순으로 단계적으로 진행되며, 문서에서는 실기에서 명시적으로 pin할 것을 권장(FLAGSPARSE_BACKEND=metax, FLAGSPARSE_MACA_MODEL=c550).
  • MetaX 실장 상태(솔직한 선언): 09-05 10:59 “spsv on metax v0.1”——희소 삼각 해석(spsv)이 MetaX 백엔드에서 첫 버전으로 동작(spsv.py 및 테스트 문서 변경); 그러나 새로 추가된 274줄 문서 METAX_TESTING.md에는 명확히 적혀 있다: MetaX 경로는 “실기에서 한 줄도 실행된 적이 없으며”, 코드는 CUDA 경로에서 이식되었고 임포트/구문/디스패치 경로 검사만 수행됨(NVIDIA 머신에서 FLAGSPARSE_BACKEND=metax로 시뮬레이션), 문서의 목적은 실기에서 구동하고 튜닝 파라미터를 실측값으로 교체하는 것이다.

해석: FlagSparse는 2.2 주기 내에서 RC tag(v0.3.0-rc0.post1, 09-01)를 가장 먼저 완료한 뒤 빠르게 백엔드 매트릭스를 보강했다——8/20부터 동일 외부 팀이 병합한 DCU 지원(cuda/dcu merge → dcu tests → dcu bsr spmv/spmm)이 MetaX/MUSA/Ascend 5개 백엔드로 확장되었다. 세 가지 주목할 점: 첫째, 디바이스 추상화 계층(_ACCEL 패턴)으로 “새 백엔드 추가”가 연산자 수정에서 감지와 디스패치 수정으로 바뀌었다는 점이며, 이는 희소 라이브러리 다중 칩화의 핵심 아키텍처 결정이다; 둘째, MetaX는 “CUDA 이식 + 시뮬레이션 검증”을 먼저 하고 실기 검증 문서화를 후속으로 진행하는데, 이는 FlagGems/build-infra의 “선등록 후검증” 엔지니어링 리듬과 일치하며, 명확히 표기된 provisional 릴리스이지 과장된 선언이 아니다; 셋째, 희소 라이브러리와 FlagTree(Qingwei DSA, 09-04), build-infra(이미지 매트릭스)가 동시기에 다중 칩화를 추진하고 있으며, FlagOS 2.2 주기의 “백엔드 확장”이 컴포넌트 계층 전반에서 전개되고 있다.

1.2 build-infra: vLLM 전달 라인 — Enflame 듀얼 SDK 라인/Cambricon 이미지 tag 일괄 등록, wheel 빌드 host-side 패치 메커니즘으로 변경, Iluvatar CoreX FlagGems attention 경로 주입 (09-05/09-06)

출처: #742(e810bc2362), #743(d8e6dba980), #744(6c8dddab33), #745(546d46e5ad), #750(0b8f6205ce), #753(f64f4af640)

  • 애플리케이션 이미지 tag 일괄 등록: 09-05 21:24/21:29 #742/#743에서 Enflame enflame-tops1.10.6 및 tops1.9.10 두 SDK 라인의 vllm app 이미지 tag 2.1.2-0.2.1_gc2e496d.d20260905를 동시에 등록(동일 플러그인 소스 fingerprint가 두 Enflame 툴체인 라인에 걸침); 22:01 #744에서 Cambricon cambricon-neuware4.4.3의 tag 2.1.2-0.2.1_gcab2270.d20260905 등록 — 해당 이미지는 1.3에서 서술한 난독화 수정 버전 전달(plugin wheel 0.2.1+gcab2270).
  • #745(22:08): vLLM wheel 빌드를 host-side source patch 메커니즘으로 변경 — 소스 tarball을 호스트에서 다운로드/압축 해제/패치 완료한 후, 빌드 컨테이너는 이미 패치된 소스 트리만 소비하여 empty wheel 빌드와 repack 수행(이미지 packaging/sglang 기존 메커니즘; 제약 명확: 컨테이너 내부에서 패치하지 않으며 변경은 빌드 감사 범위 내에 유지; 패치 hunk 무효화 시 loud fail로 패치되지 않은 wheel 유출 방지). 부수적으로 2026-08-23부터 nvidia도 empty(소스 빌드) 모드로 통일되었으며, 공식 wheel의 pip 다운로드 모드는 퇴역함을 확인. 첫 번째 패치 0001: vllm/distributed/parallel_state.py의 torch.distributed._symmetric_memory 최상위 부작용 임포트에 try/except guard 추가 — vendor torch가 2.8 미만(iluvatar corex 2.7.x)인 경우 해당 모듈이 없어 모듈 수준 임포트가 어떤 플러그인 guard보다 먼저 엔진 시작을 중단시킴; symm-mem은 명시적 opt-in 시에만 vLLM에서 사용되므로(배포 기본 비활성화) guard는 안전하고 범용적임.
  • Iluvatar CoreX(iluvatar) 전달 형태 확정: #750(23:32)에서 corex4.4.0의 vllm 0.20.2 구버전 유지보수 라인 app 활성화; #753(09-06 09:44)에서 corex4.4.0의 vllm app env에 VLLM_FL_USE_FLAGGEMS_ATTN=1 주입(FlagGems attention 강제 경유).

해석: 09-04 #722의 “iluvatar 0.24.0 T 경로 전달 불가” 판정과 함께 보면, build-infra는 수일 내에 Iluvatar CoreX를 위한 완전한 F 경로 우선 전달 형태를 구축했다: 구버전 유지보수 라인(0.20.2) app 활성화 + FlagGems attention 강제 주입으로 attention과 샘플링 연산이제조사 Triton 경로의 apply_top_k_top_p 결함을 우회하도록 함; #745의 symm-mem guard는 vendor torch 2.7.x 모듈 누락으로 인한 엔진 시작 즉시 크래시를 추가 해결. 이러한 우회는 모두 wheel 레벨(패치를 빌드에 반영)과 환경 레벨(env 주입)에서 발생하며, T 경로 자체의 수정은 여전히 플러그인 측 대기 항목임 — “F 전달 가능, T 수정 대기”의 분화가 지속적으로 누적되고 있음.

1.3 build-infra: Cambricon 0.20.2 콜드 첫 실행 깨진 글자 근본 원인 규명——flag_gems copy_가 MLU 디바이스 상태를 오염, 블랙리스트 수정 후 실제 딜리버리 (09-05)

출처: build-infra #748 (caccf829a3) (cambricon.md 재검증 기록 추가), vllm-plugin-FL PR #411

  • 사건 기점: cambricon-neuware4.4.3의 vLLM 0.20.2 딜리버리는 08-26에 “E2E 통과”로 표기됨——그러나 당시 시맨틱 게이트가 없었고, 매트릭스 녹색 표시는 실제로는 거짓 양성이었다. 09-05에 “콜드 첫 실행 시맨틱 앵커”(정답을 아는 프롬프트로 콜드 상태 시맨틱 대조)로 릴리스 버전 app 이미지를 재검증할 때 깨진 글자가 드러났고, 수정 후에야 진정한 딜리버리로 인정됨.
  • 근본 원인: flag_gems 5.3.5의 libentry.py LibTuner.run()이 config DB cache-miss 분기에서 활성 디코딩 텐서에 대해 온라인 타이밍 bench(triton do_bench의 reset-cache 폭풍)를 실행 → MLU 디바이스 상태 오염 → 콜드 첫 실행(빈 config DB) 시 출력 깨진 글자(재현 문자열 “enim enim enim…”); 웜 DB(cache 히트)는 깨끗함. 0.20.2 고유 문제——동일 runtime 하위 스택의 0.24.0은 깨끗함; 또한 argmax 문제 아님(블랙리스트에서 argmax 제외 후에도 깨진 글자 지속).
  • 수정 경로(사용자 결정): 저장소 기존의 블랙리스트 반복법으로 진행(오염 연산자를 하나씩 torch_mlu로 롤백), libentry bench 동작은 변경하지 않음——한 차례 반복에서 온라인 bench를 단일 비타이밍 launch(등가의 “최초 컴파일 가능 config” 경로)로 바꾸는 시도를 했고, 실측에서 깨진 글자가 제거되었으나 사용자에 의해 기각됨(업스트림 tuning 시맨틱을 수정하지 않음).
  • 판정 체인(콜드 = 매번 flag_gems config DB를 비움): index만 블랙리스트 → 여전히 깨진 글자; copy_+to_copy 제거 → 문자 단위 재현; copy_ 복원 → 깨끗함; copy_ 단독 / copy_+index → 깨끗함. 최소 오염 집합 = flag_gems copy_; to_copy/fill/add/sub/fused-norm은 요청 내에서 평소처럼 bench되지만 무해함.
  • 반영 및 딜리버리: vllm-plugin-FL PR #411(amend)에서 cambricon.yaml의 flagos_blacklist를 [index]에서 [index, copy_]로 확장 → head cab2270 → plugin wheel 0.2.1+gcab2270.d20260905; copy_를 torch_mlu로 롤백하는 것은 4.7.2/0.24.0에 대해 시맨틱 등가(공용 config, 다운스트림 감사 완료), 첫 요청 처리량 약 1.3 tok/s로 실질 손실 없음. 최종 딜리버리 app 이미지 2.1.2-0.2.1_gcab2270.d20260905(config 내장 형태, 블랙리스트 env 없음); 전면 콜드 상태 재검증(serve 전에 ~/.flaggems와 ~/.triton 삭제): 첫 요청 200/168초(형상별 컴파일 포함) 출력 깨끗함, 핫 요청 200/2초/7.75 tok/s; 해당 백엔드는 T-only 형태(4.4.3에는 FlagTree 없음).
  • 부수 경험: 4.4.3부터 serve는 반드시 /dev/cambricon_devN을 직접 마운트해야 하며, MLU_VISIBLE_DEVICES=N env 형태에서는 디바이스가 보이지 않아 조기 종료됨; 콜드 첫 실행 시맨틱 앵커는 libentry 온라인 bench 오염의 유일한 신뢰할 수 있는 판정 기준이며, 웜 요청으로는 노출될 수 없음; 근본 원인 측(libentry가 활성 텐서에서 타이밍 bench를 수행해서는 안 됨)은 업스트림 flag_gems 수정 대기 중이며, 블랙리스트는 과도기 방안임.

해석: 이는 build-infra가 “검증”을 녹색 표시/매트릭스 기록에서 콜드 상태 시맨틱 검증으로 승격시킨 상징적 기록이다——08-26의 시맨틱 게이트 부재로 인한 거짓 양성을 공개적으로 인정하고, 재현 가능한 판정 체인(c1-c7 문자 단위 재현)을 제시하며, 수정 경계를 명확히 그었다(블랙리스트는 과도기, 업스트림 시맨틱은 변경하지 않음, 근본 원인은 flag_gems에 위임). 이러한 “부정 기록 + 재검증 절차”야말로 멀티칩 딜리버리 신뢰도의 토대이며, 09-04 Iluvatar CoreX T 경로 딜리버리 불가 기록(#722)과 함께 2.2 주기의 엔지니어링 감사 주류에 속한다.

1.4 build-infra: sglang 0.5.18 콜드 스타트 거버넌스——타임아웃 노브/준비 게이트/워치독 적용, Moore Threads 0.5.18 딜리버리 기록 완비 (09-05/09-06)

출처: #737(6dd6e454d4), #738(c89a8e5e32), #739(db50808507), #740(11f18b8401), #741(a0df0db9b6), #747(5ce0796cc2), #749(1569ce4057), #751(e46627a1fa), #754(b353ca3181), #755(f9de45819c)

  • 콜드 스타트(cold-start) 검증 엔지니어링(09-05 12:28~18:15, #737-741): 배경은 sglang 0.5.18 애플리케이션 환경이 09-04 캠브리콘/엔플레임에 적용된 후, 콜드 첫 실행(빈 캐시)의 시작/준비 타이밍이 불안정해져 검증 스크립트가 “아직 warmup 중”과 “이미 멈춤”을 구분할 수 없게 된 것이다. 모니터링 기간 내 순차적으로 적용: #737 검증 스크립트에 콜드 스타트 타임아웃 노브 추가 → #738 캠브리콘 app verify 실제 인자 전달 → #739 준비 게이트가 warmup 이후의 첫 줄 출력만 인정 → #740 cold-start watchdog을 캠브리콘 sglang app 이미지에 직접 구워 넣음(컨테이너 내 자가 치유, 외부 스크립트에 의존하지 않음) → #741 캠브리콘/엔플레임의 콜드 스타트 현실 기록.
  • Moore Threads(mthreads) sglang 0.5.18 전달 마무리: #747(22:32) musa5.2.0의 sglang deps_app에서 compressed-tensors 버전 고정; #749(23:30) mthreads-musa5.2.0의 sglang app 이미지 tag 2.1.2-0.1.dev1_g607b9672c 등록; #751(23:49) mthreads 0.5.18 전달 기록(Moore Threads는 캠브리콘/엔플레임/메타엑스/어센드에 이어 sglang 0.5.18 전달 기록이 완비된 또 하나의 업체가 됨); #755(09-06 10:05) musa4.3.6 구 라인에도 마찬가지로 compressed-tensors 고정.
  • #754(09-06 09:54): 캠브리콘 neuware4.4.3에 sglang app config 추가(0.5.18 라인이 4.4.3 툴체인에서 계속 확장).

해석: sglang 다중 벤더 매트릭스는 09-03부터의 “등록-검증-수정” 롤링 상태에서 이번 모니터링 기간에 한 걸음 더 나아갔다 — cold-start 시맨틱이 검증 스크립트와 이미지 자체에 진입(노브 + 게이트 + 내장 watchdog 3계층)했으며, 1.3의 “콜드 첫 실행 시맨틱 앵커”와 동일한 방법론 업그레이드에 속한다: 멀티칩 추론 전달의 검증이 “시작 가능”에서 “콜드 상태 첫 요청 시맨틱 정확”으로 나아가고 있다. compressed-tensors가 mthreads 두 툴체인 라인(5.2.0/4.3.6)에서 동기 고정된 것은 전형적인 의존성 거버넌스 세부 사항이다.

2. 뉴스 보도와 생태계

2.1 컴포넌트 수준 뉴스 연속 네 번째 평온한 모니터링 기간, 모니터링 기간 내 검색 히트 제로(09-05~09-06)

  • gnews 중국어·영어 13개 쿼리(FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/FlagAttention/Zhiyuan 연구원/Zhiyuan 오픈소스/BAAI 등, when:7d-14d) 모니터링 기간 내 직접 적중 0건; 유일하게 반복 등장한 것은 09-01 Zhiyuan 커뮤니티 Day0 글(Qwen/GLM/Hunyuan 나흘 동안 세 번의 Day0)이 각 채널에 재게재된 것——새 내용이 아니며 이전에 이미 보도됨. “Zhiyuan 연구원 when:7d”의 도박 SEO 템플릿 오염 지속(Tiyu/Gelonghui 등 집계 출처, 제목이 “포르투갈 프리메이라리가 스코어 결과/Mile m6 온라인 공식 주소/Aiying 플레이어 선호 주소” 등 대체 단어 템플릿, 710B/GPT-4o 근접 등 설명은 2024년 옛 글의 파편, 전량 일괄 제거됨).
  • Tavily 검색: 모니터링 기간 내 FlagOS 관련 보도 없음; FlagOS CSDN 공식 커뮤니티 계정(flagos.csdn.net) 최신 콘텐츠는 09-01의 GLM-5.3-Flash Day0 9칩 적응 글과 09-03 라이브 다시보기로, 모두 모니터링 기간 이전이며 Zhiyuan 커뮤니티와 동일 출처.
  • HN Algolia: FlagOS/FlagGems/FlagSparse/FlagTree 쿼리 관련 적중 0건(feature-flag류 노이즈 위주), 이전 며칠과 일치.

2.2 생태계 참고: Zhiyuan 커뮤니티가 재게재한 SGLang 라운드테이블 대담——「검증 가능성이 다음 병목」(09-05)

출처: Zhiyuan 커뮤니티(원출처 Geek Park/Founder Park)

  • 09-05 Zhiyuan 커뮤니티가 Geek Park에서 정리한 AGI Playground 2026 라운드테이블 실록을 재게재: Axiom Math(공동창업자 겸 CTO Shubho Sangupta), Radixark(핵심 기술 멤버 Bao Ke, 오픈소스 프레임워크 SGLang을 핵심으로 하는 추론 인프라 회사), SoTALab(공동창업자 Yu Linxi) 대담 “검증 가능한 AI”——장기 작업 에이전트(작업 체인이 50단계를 넘으면 성공률이 절벽처럼 하락)는 단계별 검증과 세밀한 보상(Lean 정리 증명기식 피드백)이 필요하고, 추론 인프라는 프로덕션급 업그레이드(첫 토큰 지연, 토큰 간격 SLO, 스트레스 테스트)가 필요하며, 검증 가능성이 AI 발전의 다음 진짜 병목일 수 있다.

해석: FlagOS와는 약한 관련(SGLang은 sglang-plugin-FL의 업스트림 프레임워크)이나 생태계 배경으로 수록——1.3/1.4의 “콜드 스타트 의미론적 앵커 검증”과 함께 보면, “검증”이 동시에 추론 프레임워크 커뮤니티와 FlagOS 전달 엔지니어링의 키워드가 되고 있음, 방향은 일치(검증 가능하고 추적 가능하며 신뢰할 수 있는 전달), 다만 입자의 크기가 다름(전자는 결과 계층, 후자는 배포 계층).

3. 멤버 기관 심층 분석

3.1 멤버 기관 모니터링 기간 내 신규 동향 없음(09-05~09-06)

  • 어제(09-04/09-05 리포트) 이미 보도한 멤버 기관 메인라인——Enflame 공모가 확정과 흑자 전환 시간표, Moore Threads “Lushan” GPU와 H1 실적/Qujing PD 협력, MetaX와 Iluvatar CoreX의 장부상 흑자 전환 분해, Cambricon 소프트웨어 인재 채용——이번 모니터링 기간 모두 후속 신규 보도 없음. 뉴스 측 검색(멤버 기관 키워드 중국어·영어 쿼리 포함) 적중 0건.
  • 컴포넌트 측 멤버 기관 동향(본 리포트 1장에서 상세 기술): Cambricon(0.20.2/0.24.0/sglang 0.5.18 검증 및 난코드 수정 전달), Iluvatar CoreX(0.20.2 구 라인 활성화 + FlagGems attention 주입), Enflame(tops1.10.6/tops1.9.10 듀얼 SDK 라인 이미지 등록), Moore Threads(sglang 0.5.18 전달 + compressed-tensors 잠금), MetaX(FlagSparse MetaX 백엔드 등록, 1.1 참조) 모두 커밋급 동향——멤버 기관의 “진짜 동향”은 build-infra 전달 매트릭스와 연산자 라이브러리 백엔드에 집중되어 있어 뉴스 면의 조용함과 대조를 이룸.

3.2 FlagSparse 공동 구축 팀 배경: 중국과학원 계산기술연구소 계열 AlphaSparse 이중 채널 지속 병합(09-05)

  • 모니터링 기간 내 FlagSparse 전체 4건의 커밋은 외부 희소 계산 팀에서 나옴: 커밋 계정 NCIA-AlphaSparse, 이메일 도메인 ict.ac.cn(중국과학원 계산기술연구소), 그 org NCIC-AlphaSparse를 업스트림 미러로 사용(PR #51이 바로 NCIC-AlphaSparse/main에서 병합), 팀은 동시에 flagos-ai/FlagSparse 직접 푸시 권한 보유——”업스트림 미러 병합 + 저장소 직접 푸시” 이중 채널 공동 구축.
  • 타임라인: 8/20 “cuda and dcu merge” → 8/22 dcu tests(PR #45) → 8/24 dcu bsr spmv/spmm → 8/27 spsv/spmm 구조 병합 → 9/1 v0.3.0-rc0.post1 → 9/4-9/5 metax/musa/ascend 백엔드——DCU 이후의 모든 백엔드 역량이 이 팀에서 나옴, FlagOS”멤버 기관 + 연구기관 집단지성 공동 구축”의 희소 계산 방향 대표 사례(이전 데일리 리포트에서 이미 그 DCU 기여를 기록했으며, 이번 모니터링 기간에 팀 배경을 보완: 이메일 도메인 ict.ac.cn은 중국과학원 계산기술연구소를 가리킴).

4. 요약

이 모니터링 기간(09-05 10:18 ~ 09-06 10:18) 뉴스 측은 연속 네 번째 조용한 기간이었다(gnews/Tavily/HN 모두 기간 내 적중 0건, SEO 템플릿 오염과 구문 재전재만 존재). 그러나 GitHub 측은 2.2 주기의 엔지니어링 추진을 이어갔으며, 세 가지 주요 흐름은 다음과 같다:

  1. FlagSparse 백엔드 매트릭스가 다섯 곳으로 확대(PR #51, 09-05): 디바이스 추상화 이전 269건, MetaX(Moore Threads MACA/C550)는 “CUDA 이식 + 시뮬레이션 검증”으로 실장되어 spsv v0.1을 통과했고, Moore Threads/Ascend는 provisional 백엔드로 등록되었다——희소 연산자 라이브러리의 다중 칩화와 외부 큐(중국과학원 계산소 계열 AlphaSparse)가 계속 컴포넌트 버전 리듬(2.2 최초 RC tag 보유자)을 주도하고 있다.
  2. build-infra 전달 엔지니어링이 “콜드 스테이트 의미 검증”으로 업그레이드: Cambricon 0.20.2 콜드 첫 실행 글자 깨짐 현상의 근본 원인 규명 완료(flag_gems copy_ 오염, 블랙리스트 [index, copy_] 과도기 적용, 업스트림 수정 대기), 08-26 무의미 게이트 오탐을 공개적으로 반박; sglang 0.5.18 라인은 타임아웃 노브/레디니스 게이팅/내장 watchdog 3계층 콜드 스타트 거버넌스를 적용했다.
  3. Iluvatar CoreX 전달 경로가 F 경로 우선으로 확정: 0.20.2 구 라인 + VLLM_FL_USE_FLAGGEMS_ATTN=1 + symm-mem guard, T 경로(벤더 Triton) 수정은 플러그인 측으로 이관.

예측은 어제와 동일하다: 2.2 rc0 주기는 “검증-태깅-기록” 중간 단계에 있으며, 다음 릴리스 신호는 여전히 community 목록 저장소 동작과 build-infra의 version bump를 봐야 한다; 컴포넌트 뉴스 면의 다음 가능한 노드는 2.2 정식 rc 분기 또는 다음 Day0 모델 적응이다.

부록: 전체 출처 목록

출처 검증 결과
GitHub org repos API(flagos-ai, 52개 저장소) 7개 저장소가 기간 내 푸시됨; docs/release-info/sglang-plugin-FL/vllm-plugin-FL/FlagTree는 기본 브랜치 commits 검증 결과 PR 브랜치 동작으로 확인
GitHub commit search(org 전체, 21건) build-infra 17건, FlagSparse 4건; committer 시각과 내용을 건별로 검증 완료
GitHub tags API + 날짜 검증 기간 내 신규 tag 없음(FlagSparse v0.3.0-rc0.post1 09-01 이전, FlagTree v0.4.0 시리즈 2026-01, build-infra v2.1.1 08-03 등)
GitHub releases API 기간 내 신규 release 없음(FlagSparse v0.3.0-rc0.post1 릴리스 09-01 02:02 CST, 기간 이전)
FlagSparse PR #51 / commits / METAX_TESTING.md 백엔드 매트릭스, 디바이스 추상화 이전, MetaX 실장 상태와 감지 메커니즘(patch 전문 검증 완료)
build-infra commits #737-755 17건 건별 검증(vllm/sglang 이중 라인 전달 기록과 수정)
vllm-plugin-FL PR #411 cambricon 블랙리스트 [index, copy_] 등록(교차 저장소 참조 검증)
Google News RSS(중영문 13개 그룹, 프록시 경유) 기간 내 적중 0건; 도박 SEO 템플릿 오염 전량 제거; 09-01 Day0 구문 재전재는 신규 콘텐츠 아님
HN Algolia(4개 쿼리) 관련 적중 0건
Tavily web 검색(4개 그룹) 기간 내 FlagOS 보도 없음; flagos.csdn.net 최신은 09-01/09-03 콘텐츠
Zhiyuan 커뮤니티 hub.baai.ac.cn 09-05 Geek Park SGLang 라운드테이블 전재(생태계 참고, 약관련)