모니터링 기간: 지난 24시간 (2026-09-15 10:18 ~ 2026-09-16 10:18, 베이징 시간) 출처: GitHub (org: flagos-ai, 53개 저장소 pushed_at 전수 검증 + 단일 commit search 119건 committer-date 기준 검증 + 주요 저장소 기본 브랜치 커밋 재검토 + 각 저장소 releases/tags 메타데이터 + community 릴리스 목록과 공개 일정 raw 직접 조회 + 주요 커밋 패치 상세), Google News RSS (중영문 24개 쿼리어, 프록시 경유), HN Algolia, MetaX 공식 홈페이지, Guandian.com, Sina Finance, 21 Finance, Cailian Press, QbitAI, XinhuaNet, BAAI 커뮤니티, CSDN FlagOS 커뮤니티 등 (상세 내용은 부록 출처 목록 참조)

이번 호 인덱스

  • 오늘의 핵심: Torch-FL 6개 플랫폼 FlagGems-first로 전환——PPU 라우팅 항목이 11건에서 435건으로 확대 (09-15/09-16)
    1. 오픈소스 프로젝트 진행 상황 (GitHub 동향)
      • 1.1 2.2 RC2 2차: FlagGems v5.4.0-rc2.post2로 상향, 목록 항목 버전 교체 (09-15)
      • 1.2 Open3D-PIMC 최초 코드 반영: 단일 커밋 662개 파일, 컴파일 계층과 런타임 도착 (09-16)
      • 1.3 Torch-FL: 6개 플랫폼 동시에 FlagGems-first로 전환 (09-15/09-16)
      • 1.4 FlagAttention: SageAttention과 GDN2 동시 반영, Ascend 버전 별도 구현 (09-15)
      • 1.5 FlagGems 양자화 연산자 라인: Hygon W8A8 INT8 GEMM, Moore Threads W8A16 FP8 RMSNorm (09-15)
      • 1.6 FlagGems KernelGen 대량 반영: 20개 Nvidia 연산자와 Kunlunxin tle.gpu 마이그레이션 (09-15/09-16)
      • 1.7 추론 플러그인 라인: Ascend SparseAttnSharedKV, persistent_topk와 vLLM 0.24 적응 (09-15/09-16)
      • 1.8 build-infra: FlagCX wheel 패키징 라인 개통, 6개 vLLM 애플리케이션 이미지 tag 기록 (09-15)
      • 1.9 community: 2.2 릴리스 거버넌스 자동화, 상태를 연결 PR에서 도출하도록 변경 (09-15/09-16)
      • 1.10 FlagSparse: 외부 브랜치 메인 저장소로 병합, Ascend 정밀도 마무리 (09-15)
      • 1.11 FlagQuantum: Twin 증거를 회로 토폴로지 기준으로 등급 분류 (09-15)
      • 1.12 기타 동향: FlagTree, flir, FlagDNN, FlagCX (09-15/09-16)
    1. 뉴스 보도와 생태계
      • 2.1 컴포넌트 수준 검색 열두 번째 연속 조용한 모니터링 기간: 적중이 컴포넌트가 아닌 회원사에 집중 (09-15~09-16)
      • 2.2 MetaX, Shanghai AI Laboratory ATRIA Dawn Preview의 Day0 적응 완료 (09-15)
      • 2.3 Enflame STAR Market 상장: 자본 측면 해석과 생태계 포지션의 두 가지 읽기 (09-15)
      • 2.4 Open3D-PIMC 발표에서 코드까지: 미디어 측과 코드 측의 48시간 시차 (09-14~09-16)
    1. 회원사 심층 분석
      • 3.1 Qingwei Intelligent: Open3D-PIMC 코드 반영과 3D 재구성 가능 노선의 합류 (09-16)
      • 3.2 Hygon: 양자화 연산자, CI 이미지, FlagCX wheel 삼선 병행 (09-15)
      • 3.3 Moore Threads: W8A16 FP8 RMSNorm과 MUSA 라우팅 양방향 조정 (09-15)
      • 3.4 MetaX: metax rc2 이미지 재빌드 기록과 Day0 적응 서사 (09-15)
      • 3.5 Enflame: S60 vLLM 0.24 라인 진입과 GCU CI 파이프라인 (09-15)
      • 3.6 Iluvatar CoreX: iluvatar3.6 백엔드와 FlagTree 0.6.1 바인딩 (09-15)
      • 3.7 Kunlunxin: sum을 tle.gpu로 이전과 paged-KV 규약 수정 (09-15)
      • 3.8 BAAI (주도 기관): RC2 거버넌스 자동화와 2.2 진행 상황 대조 (09-15/09-16)
    1. 요약과 트렌드 관찰
  • 부록: 전체 출처 목록

오늘의 핵심: Torch-FL 6개 플랫폼 FlagGems-first로 전환——PPU 라우팅 항목이 11건에서 435건으로 확대

날짜: 2026-09-15 ~ 2026-09-16　출처: Torch-FL #290 PPU 라우팅, Torch-FL #276 CUDA FlagGems-first, Torch-FL 연산자 지원 문서

Torch-FL에서 이 창구에서 가장 집중적인 엔지니어링 작업이 발생했습니다. 이 레이어는 PyTorch 연산자 호출을 각 칩 백엔드로 디스패치하는 어댑터 역할을 하며, 24시간 이내에 12건의 커밋을 받아 6개 플랫폼을 동시에 ‘FlagGems 우선’으로 이끌었습니다. 그중 PPU(Damo Academy XuanTie) 한 곳의 라우팅 테이블 변화가 가장 컸습니다. FlagGems 라우팅 항목이 11개에서 478개로 확장되었고, 467개의 오버로드가 cuda에서 flaggems로 이동했으며, 역방향 이동은 하나도 없었습니다. 이후 실행 가능성 전수 조사, CI에서 노출된 두 차례의 라우팅 관련 실패, 그리고 소스 수준 감사를 거쳐 435개의 FlagGems / 1601개의 cuda로 확정되었습니다. 즉 FlagGems가 커버하는 482개 연산자 중 47개가 벤더 커널에 남겨졌습니다(전수 조사에서 적발된 라우팅 관련 실패 33개, mm/bmm 패밀리, 5개의 addmm 오버로드, _conj, 4개의 반사 패딩 라우팅).

이번 변경은 또한 구조적 문제 하나를 함께 해결했습니다. PPU의 연산자 전체 집합은 원래 backends_cuda.conf에서 읽어왔는데, codegen_ops.py가 이 파일을 재작성하기 때문에 PPU의 연산자 유니버스가 다른 플랫폼 라우팅 테이블의 함수가 되는 셈이었습니다. 이제는 csrc/aten/generated/register.inc를 읽도록 변경했습니다. 이는 CUDA 라인과 PPU 라인이 공동으로 컴파일하는 등록 테이블이며, 변경 후 9개 conf를 재생성한 결과 전부 바이트 단위로 동일하여 순수 출처 추적 교체임이 증명되었습니다. 저장소는 또한 남겨진 47개 연산자를 하나씩 BOXING_TRITON_GAPS에 기록하고 실패 설명을 첨부했으며, 설정 파일의 SHA-256도 재현성을 보장하기 위해 기록했습니다.

나머지 5개 플랫폼은 같은 방향의 다른 단면입니다. CUDA 라인(#276, 18개 파일, +1660/-533)은 작업 내에서 FlagTree 0.6.2a2와 FlagGems master를 설치하고 FlagGems C++ 연산자 컴파일을 담당하도록 변경했으며, 워크플로 타임아웃은 이에 맞춰 60분에서 120분으로 늘렸습니다. DCU(#277)는 FlagTree와 FlagGems를 기본 활성화했습니다. GCU(#285)는 FlagGems와 벤더 폴백을 사용합니다. Ascend(#288)는 파이프라인을 FlagTree로 전환하고 dtype 폴백을 유지합니다. MUSA(#286)는 원래 공백 메우기로 판정되었던 4개 항목을 FlagGems 라우팅으로 다시 승격했습니다.

이 라인을 FlagOS의 명제로 되돌아보면, 이는 어떤 단일 연산자 등록보다도 핵심 목표에 더 가깝습니다. FlagOS의 논지는 ‘하나의 연산자 라이브러리를 여러 칩에서 재사용한다’인데, 이 논지의 성립 여부를 결정하는 것이 바로 디스패치 레이어입니다. 얼마나 많은 연산자가 실제로 FlagGems를 거치는지, 아니면 조용히 벤더 커널로 되돌아가는지가 관건입니다. 이 창구가 내놓은 답은 다음과 같습니다. 벤더 커널이 여전히 큰 부분을 담당하지만(PPU에서 1601 대 435), 추세는 명확하고 모든 예외에는 명시적인 이유가 있습니다.

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

창구 개요: org 내 53개 저장소 중 20개가 창구 기간 내에 푸시되었습니다. 단일 commit search로 창구 기간 내 커밋 119건이 검색되었으며(4페이지, committer-date 내림차순), 17개 저장소에 분포합니다. FlagGems 43, build-infra 14, community 13, Torch-FL 12, FlagSparse 11, FlagGems-vllm 5, FlagGems-sglang 4, FlagQuantum 3, FlagAttention 3, sglang-plugin-FL 2, vllm-plugin-FL 2, FlagTree 2, 그리고 flir, FlagGems-Experimental, FlagCX, Open3D-PIMC, FlagDNN 각 1건입니다. 추가로 docs, release-info, FlagBLAS 세 저장소는 창구 기간 내 푸시가 있었으나 기본 브랜치에는 창구 기간 내 신규 커밋이 없습니다(태그 또는 사이드 브랜치 푸시에 해당하며, docs와 release-info는 릴리스 산출물 사이트 동기화를 담당합니다).

이번 창구의 형태 = ‘디스패치 레이어 재구성’ + ‘양자화 및 어텐션 연산자 강화’ 두 라인의 병행: 거버넌스 측은 FlagGems의 두 번째 RC2 태깅과 community의 릴리스 프로젝트 자동화로 2.2 마무리를 추진합니다. 엔지니어링 측의 중점은 ‘연산자를 채워 넣기’에서 ‘연산자가 실제로 사용되게 만들기’로 전환되었습니다. Torch-FL의 6개 플랫폼 FlagGems-first가 주축이며, FlagGems의 양자화 연산자(W8A8 / W8A16)와 FlagAttention의 SageAttention, GDN2가 신규 생산량입니다. 또한 Open3D-PIMC가 창구 끝자락에 첫 코드를 반영했으며, 이는 이번 기간의 유일한 신규 코드 저장소 작업입니다.

1.1 2.2 RC2 두 번째 라운드: FlagGems가 v5.4.0-rc2.post2로 상향, 매니페스트 항목 버전 교체(09-15)

날짜: 2026-09-15　출처: community 커밋 #110, FlagGems v5.4.0-rc2.post2

09-15 11:21, Release Manager가 release(2.2-rc2): bump flaggems to v5.4.0-rc2.post2 (#110)를 커밋했으며, 매니페스트에는 단 한 줄의 변경만 있습니다. FlagGems가 v5.4.0-rc2.post1에서 v5.4.0-rc2.post2로 교체되었습니다. 커밋 설명에는 버전 변경을 이끈 두 가지 수정 사항이 명시되어 있습니다. flash_attention_backward 호환(#6253)과 flagtree/3.5 라인에서 tl.map_elementwise에 게이팅 추가(#6236)이며, 새 태그는 브랜치 헤드 88acc0f7d를 가리킵니다. 태그 타임라인을 확인하면 rc2.post1과 rc2.post2는 모두 해당 브랜치의 검증 스냅샷이며, 매니페스트 내 나머지 24개 항목은 여전히 rc2.post1을 가리킵니다. 이는 2.2 RC2의 두 번째 태깅이며, 09-28 GA까지 13일이 남았습니다.

1.2 Open3D-PIMC 최초 코드 착수: 단일 커밋에 662개 파일, 컴파일 계층과 런타임 완비 (09-16)

날짜: 2026-09-16　출처: Open3D-PIMC 최초 커밋, 프로젝트 README

09-16 09:30, org 내에서 08-15에 생성된 이후 계속 비어 있던 Open3D-PIMC 저장소가 유일한 루트 커밋을 받아 한 번에 662개 항목을 가져왔습니다. 디렉터리 구조는 이것이 제안 문서가 아니라 사용 가능한 엔지니어링임을 보여줍니다. source/raisa-inductor/는 컴파일 계층(compiler.py, graph_manager.py, graph_executor.py, 그리고 passes/ 아래의 통신 연산자, 융합, 서브그래프 세 가지 pass와 utils/_graph_hash.py의 컴파일 캐시 키)이고, runtime/rcs2/는 C++ 런타임(engine.cpp, l1_workspace.cpp, CMake와 kernel.cmake)이며, 별도로 demo/test_compiler.py, envsetup.sh와 아키텍처 다이어그램 두 장이 포함되어 있습니다. README는 프로젝트의 네 가지 보완 과제를 명확히 기술하고 있습니다. 메모리 계층의 표현력, 샤딩과 토폴로지의 괴리, 동적 추론과 전체 그래프 컴파일의 충돌, 컴파일 산출물의 재사용입니다. 이에 대응하는 해법은 계층적 샤딩, 3D-DRAM 데이터 상주, 객체 수명 주기와 Graph/Eager 경계를 검증 가능하고 변환 가능하며 최적화 가능한 IR 시맨틱으로 승격하는 것입니다. 이는 09-14 China Computing Power Conference의 오픈소스 발표를 이어받아 “오픈소스 선언”에서 “코드 출시”로의 착수를 완성한 것입니다.

1.3 Torch-FL: 여섯 플랫폼이 함께 FlagGems-first로 전환 (09-15/09-16)

날짜: 2026-09-15 ~ 2026-09-16　출처: Torch-FL #290, Torch-FL #276, Torch-FL #285

자세한 내용은 “오늘의 중점”을 참조하십시오. 두 가지 세부 사항을 보충합니다. 첫째, PPU 작업의 환경 재현성이 완전히 재작성되었습니다. 기존에는 러너 pod의 /workspace/FlagGems 호스트 마운트를 통해 FlagGems를 임포트했는데, pod에 해당 마운트가 없으면 set_env_ppu.sh가 환경 준비 단계에서 “FlagGems source is not available”로 종료되어 작업이 연산자 단계까지 진행되지 못했습니다. 이제는 FlagOS 인덱스에서 FlagTree(0.6.2a2+ppu3.6)를 설치하고 git에서 FlagGems master를 설치하도록 변경되어, 환경이 이미지와 두 인덱스에만 의존합니다. 둘째, mm/bmm은 여전히 벤더 커널에 고정되어 있는데, 그 이유는 FlagGems의 _hygon 커널이 Triton의 mm_kernel에 num_ldmatrixes 키워드를 전달하지만 PPU 버전 Triton이 이를 인식하지 못하기 때문이며, 이미 FlagGems #6225로 보고되었습니다.

1.4 FlagAttention: SageAttention과 GDN2가 같은 날 저장소에 반영, Ascend 버전은 별도 구현 (09-15)

날짜: 2026-09-15　출처: FlagAttention #43 SageAttention, FlagAttention #44 GDN2, FlagAttention #62 Ascend 버전

하루 만에 두 개의 신규 버전 연산자가 병합되었다. #43은 SageAttention의 Triton 구현을 도입했으며(10개 파일, +862/-7): QK는 INT8 블록별 양자화, PV는 FP16 순전파를 사용하고, QK 양자화와 어텐션 순전파 두 커널 모두 triton.experimental.tle.language를 사용하며, 1K에서 32K 시퀀스 길이를 커버하는 벤치마크 스크립트와 헤드별 참조 구현을 대조하는 정밀도 테스트가 포함된다. #44는 최적화된 GDN2 연산자로, 선형 어텐션 방향의 현재 핫스팟이다. #62는 Ascend를 위해 GDN2와 SageAttention을 별도로 구현했는데: 진입점이 torch.npu.is_available()에 따라 _ascend 백엔드로 자동 라우팅되고, 범용 경로는 다시 이 구현을 가리키도록 하여 두 곳의 코드가 어긋나는 것을 방지한다; Ascend 벤치마크 스크립트는 AscendC 연산자와 동일한 형태 집합을 대상으로 측정한다. 이 세 가지를 함께 보면, FlagAttention이 “어텐션 변형 보충”에서 “최신 추론 모델의 구조적 핫스팟 추종”으로 전환했음을 보여준다.

1.5 FlagGems 양자화 연산자 라인: Hygon W8A8 INT8 GEMM, Moore Threads W8A16 FP8 RMSNorm (09-15)

날짜: 2026-09-15　출처: FlagGems #6185 Hygon W8A8, FlagGems #6210 Moore Threads W8A16

Hygon 라인은 mm_w8a8_int8과 mm_w8a8_int8_out 두 개의 비-ATen 양자화 행렬곱 연산자를 새로 추가했다(5개 파일, +871): 입력은 이미 양자화된 INT8 행렬이며, 스칼라 또는 행/열별 스케일링 FP32 scale과 선택적 bias가 함께 제공되고, 양자화 자체는 연산자 외부에서 수행되며, 커널 구현의 핵심은 INT8 내적에서의 긴 K 리덕션 오버플로 보호이다; 동시에 conf/operators.yaml 규격에 따라 연산자 등록을 보완했고 stage는 5.4로 표기하여 현재 RC 브랜치와 정렬했다. Moore Threads 라인은 W8A16 FP8 RMSNorm 경로를 최적화했다(#6210). 또한 fix: enable TLE for Hygon(#6247)은 Hygon을 TLE 활성화 명단에 추가했는데, 이는 해당 백엔드가 Triton의 언어 확장을 사용하기 시작했음을 보여준다. 세 가지를 함께 보면, 양자화(W8A8 / W8A16)가 이번 라운드 연산자 확장의 주된 흐름이 되고 있다.

1.6 FlagGems KernelGen 대량 입고: 스무 개의 Nvidia 연산자와 Kunlunxin tle.gpu 마이그레이션 (09-15/09-16)

날짜: 2026-09-15 ~ 2026-09-16　출처: FlagGems #5722, FlagGems #6311 Kunlunxin, FlagGems #6188 backends.yaml

KernelGen이 산출한 Nvidia 연산자가 이번 모니터링 기간에 메인 저장소로 대량 입고되었으며, 대략 스무 개로 세 가지 범주를 커버한다: 선형대수 범주(cond, solve, eigvals, vander, multi_dot, powsum 등 linalg 계열), 특수 함수 범주(entr, 체비쇼프 다항식 등), 그리고 어텐션 및 학습 관련 범주(네이티브 멀티헤드 어텐션, 양자화 GRU, grid_sampler 2D 샘플링, 3D 업샘플링 역방향, 다수의 의사양자화와 임베딩 백 희소 역방향, 배치 정규화 역방향 리덕션 등). KMCompiler 라인은 추가로 unsafe_index_put(Nvidia와 Ascend), rnn_tanh 성능 최적화, 그리고 _dim_arange를 보충했다. Kunlunxin 측은 sum과 sum_dim을 tle.gpu로 마이그레이션했고(#6311), 르장드르 다항식 연산자를 하나 새로 추가했다. 품질 측면에서는 linalg_svd의 16×16 행(hang)(#6301), addmv 스칼라 bias의 dtype 불일치(#6149), CI 컨테이너의 shm/ipc 옵션을 수정하고 Hygon 이미지를 갱신했다(#6304); backends.yaml도 iluvatar 백엔드를 flagtree==0.6.1+iluvatar3.6으로 갱신했다(#6188).

1.7 추론 플러그인 라인: Ascend SparseAttnSharedKV, persistent_topk 및 vLLM 0.24 적응 (09-15/09-16)

날짜: 2026-09-15 ~ 2026-09-16　출처: FlagGems-vllm #792 SparseAttnSharedKV, vllm-plugin-FL #464, sglang-plugin-FL #75 Hygon DCU CI

이번 모니터링 기간 단일 최대 코드량은 Ascend의 SparseAttnSharedKV(#792, 5개 파일, +9637)에서 나왔다. 이는 DeepSeek-V4 희소 어텐션 공유 KV 구조의 Ascend상 Triton 구현으로, 여섯 가지 형상을 고정 검증한다——3개의 decode 케이스 KV 길이 8193, 3개의 prefill 케이스 Q=KV=8192, 상수는 64개 Q 헤드, 1개 KV 헤드, 헤드 차원 512, 페이지 크기 128에 집중되며, 정밀도 임계값은 2e-2이고, 속도 측정은 동일 디바이스 AscendC 연산자를 기준으로(5회 워밍업, 20회 샘플링) 기록만 하고 단언하지 않는다——즉 정밀도를 수용 기준으로 삼는다. 같은 라인에서 Ascend persistent_topk(segment-sort + merge 두 경로)도 보충하고 벤더 fused_moe / persistent_topk를 ops/ 아래로 수납했으며, 동시에 pre-commit 설정을 gitcode 미러로 전환하여 국내 네트워크에 적응했다. 플러그인 측 두 가지 업그레이드: vllm-plugin-FL은 Enflame S60을 vLLM 0.24 라인에 적응시키고(#464) Kunlunxin을 vLLM 0.24.0으로 올렸으며(#516), sglang-plugin-FL은 Hygon DCU(BW1000)와 Enflame GCU(S60) 각각에 CI 파이프라인을 구축했다(#75/#88). 그중 Hygon 라인은 AMD adaptor로 FlagCX v0.13.0을 빌드하며(DCU는 HIP 계열, DTK에 librccl 내장), e2e 케이스 매트릭스를 Ascend, MUSA와 정렬했다. FlagGems-sglang 측은 업스트림 FlagGems의 테스트 도구와 conftest를 저장소에 내장했다(#76).

1.8 build-infra: FlagCX wheel 패키징 라인 개통, 6개 vLLM 애플리케이션 이미지 tag 기록 (09-15)

날짜: 2026-09-15　출처: build-infra #886, build-infra #895, build-infra #888

모니터링 기간 내 build-infra는 14개 커밋으로 두 번째로 활발한 저장소가 되었으며, 주된 내용은 두 가지다. 첫째는 새로 개통한 FlagCX wheel 패키징 라인(#886 빌드·검증·릴리스 3단계 추가, #896 scm 노드 너비 pin 및 MACA에 cu-bridge의 CUDA_PATH 설정, #897 과도한 주석 롤백, #899 vllm-plugin wheel 빌드가 wheel을 run artifact로 보존하도록 함)이다. 그중 #895는 한 가지 환경 함정을 기록했는데: torch의 설치된 헤더가 gflags를 강제 요구한다——torch/headeronly/macros/cmake_macros.h가 C10_USE_GFLAGS를 직접 정의하므로 c10/util/Flags.h가 모든 소비자에 대해 <gflags/gflags.h>를 include하지만, 어떤 런타임 이미지에도 해당 헤더가 없다(Hygon 런타임 이미지에서 /usr/include/gflags 부재 실측). 이로 인해 Hygon 빌드가 backend_flagcx.cpp 컴파일 시 실패했기에 빌드 이미지 내에 libgflags-dev와 libgoogle-glog-dev를 추가 설치했다. 둘째는 6개 vLLM 애플리케이션 이미지 tag를 장부에 기록한 것으로, 통일하여 2.1.2-0.2.2rc2.post1_gdb28502.d20260915이며 각각 metax-maca3.8.1.3, metax-maca3.7.2.1, ascend-cann9.0.0, ascend-cann8.5.0 및 두 개의 910c 변형에 대응한다(#888~#893). 또한 metax/ascend 0.20.2 rc2 재빌드 changelog(#887)와 Kunlunxin paged-KV 규약 수정 기록(#898)을 보충했다.

1.9 community: 2.2 릴리스 거버넌스 자동화, 상태를 연관 PR에서 도출하도록 변경 (09-15/09-16)

날짜: 2026-09-15 ~ 2026-09-16　출처: community 2.2 프로젝트 동기화 워크플로, community 커밋 29a04c6e

체크리스트와 라벨링 외에도, community 저장소의 이 모니터링 기간 13개 커밋은 거의 전부 2.2의 릴리스 상태를 수동 보드에서 자동화로 옮기는 데 사용되었다. 새로 추가된 flagos-2.2-project-sync.yml은 15분마다 실행되며, flagos2.2-rc0/rc1/rc2 레이블이 붙은 issue(열림/닫힘 상태 무관)를 조직의 GitHub Project #9에 동기화한다. 기본 Actions 토큰과 구 조직 토큰 모두 Projects 권한이 없기 때문에, 워크플로는 project scope를 가진 전용 토큰을 명시적으로 요구한다. 이후 하루의 커밋은 같은 체인을 따라 수정되었다: issue 동기화, 연관 PR로 릴리스 상태 추론, 상태와 연관 PR 정렬, 대사(reconciliation) 강화, 수동으로 연기된 issue 보존, 할당된 triage issue 승격, 스케줄 주기 표준화, Actions 스케줄 하트비트 검증, 그리고 RC 검증 규칙을 명시한 설명 추가. 이 체인을 RC2의 두 차례 라벨링과 함께 읽으면, 2.2의 Go/No-Go가 “사람이 체크리스트를 보는 것”에서 “issue와 PR 상태로 추론하는 것”으로 바뀌고 있음을 알 수 있다. 이는 이 모니터링 기간에 체크리스트가 버전을 바꿀 때마다 30분 이내에 레이블에 반영된 이유이기도 하다.

1.10 FlagSparse: 외부 브랜치 메인 저장소 병합, Ascend 정밀도 마무리 (09-15)

날짜: 2026-09-15　출처: FlagSparse 커밋 목록

FlagSparse의 이 모니터링 기간 11개 커밋은 모두 하나의 외부 협업 라인에서 왔다: 메인 저장소가 병합 커밋 방식으로 NCIC-AlphaSparse/main 브랜치를 도입했으며(#60), 내용은 Ascend 정밀도 조정(ascend accuracy refine, ascend refines), CI 세분화(두 차례 ci refine), wrapper와 문서 업데이트, 그리고 여러 차례의 크로스 저장소 동기화 병합이다. 이는 희소 연산자 라이브러리의 진전이 외부 팀 주도로 메인 저장소가 이를 이어받는 구조임을 보여주며, FlagAttention이 org 내부 메인라인에서 진전되는 것과 대조적인 분업 구도를 형성한다.

1.11 FlagQuantum: Twin 증거를 회로 토폴로지별로 등급화 (09-15)

날짜: 2026-09-15　출처: FlagQuantum #45, FlagQuantum #46

이전 모니터링 기간의 Twin API 동결을 이어받아, FlagQuantum은 이 모니터링 기간에 세 번 커밋했다: 회로 간 Twin 후보 비교(#44), 회로 토폴로지별 Twin 증거 등급화(#45), 인접한 연결 Twin 영역 조합(#46). 이 세 단계를 합치면 양자 프로세서 디지털 트윈의 동등성 판정을 “단일 회로 비교”에서 “토폴로지별 증거 집합 구성”으로 진전시키는 것으로, 히스토리 시퀀스 관리 이후의 방법론 보완에 해당한다.

1.12 기타 동향: FlagTree, flir, FlagDNN, FlagCX (09-15/09-16)

날짜: 2026-09-15 ~ 2026-09-16　출처: FlagTree #1178, FlagTree #1169, flir #75, FlagCX #599

FlagTree 두 건: fix(hcu): allow extract_tile in the TLE whitelist(#1169)는 Hygon 라인의 extract_tile을 TLE 화이트리스트에 넣었으며, FlagGems 측의 “Hygon을 위한 TLE 활성화”와 같은 방향이다. [Triton] Use triton version instead of llvm22 version(#1178)은 버전 식별 기준을 통일했다. 동일한 변경이 flir(FlagTree IR, microsoft/triton-shared에서 유래)에도 적용되었다(#75). FlagDNN은 Nvidia 백엔드의 연산자 구현을 수정했다. FlagCX의 #599는 성능 보고 기준을 수정했다: KV 등가 처리량이 더 이상 고정 텍스트 상자 값을 사용하지 않고, 실측된 요청당 KV 바이트 수로 계산하도록 변경되었다.

2. 뉴스 보도와 생태계

2.1 컴포넌트 수준 검색 열두 번째 연속 평온 구간: 적중이 컴포넌트가 아닌 회원 단위에 집중되다 (09-15~09-16)

날짜: 2026-09-15 ~ 2026-09-16　출처: Google News RSS

FlagOS, FlagGems, FlagScale, FlagTree, FlagPerf, FlagCX, KernelGen, Open3D-PIMC 및 BAAI 측 단어의 중영문 조합 총 24개 쿼리(중문 17개, 영문 7개, when:7d와 when:14d 두 단계)로 검색한 결과, 컴포넌트 이름 쿼리는 해당 구간 내 전부 제로 적중이었다. 회원 단위와 산업 단어로 확장한 후 총 13건의 구간 내 결과를 얻었으며, 그중 MetaX의 Day0 적응과 Enflame의 상장 시세 및 생태계 관련 건만이 관련성이 있고 나머지는 주식 시세, 금융 기사 또는 무관한 내용이었다. HN Algolia의 FlagOS, FlagGems, FlagScale, BAAI 쿼리 역시 유효한 기술 토론이 없었다. 이는 컴포넌트 수준 뉴스 검색의 열두 번째 연속 평온 구간이며, 이번 기간 기술 정보면은 여전히 기본적으로 전부 코드 저장소에서 나왔고, 처음으로 Torch-FL의 디스패치 계층 변경이 독립적인 기술 서사를 제공했다.

2.2 MetaX, 상하이 인공지능 연구소 ATRIA Dawn Preview의 Day0 적응 완료 (09-15)

날짜: 2026-09-15　출처: MetaX 공식 웹사이트, Guandian.com

09-14 상하이 인공지능 연구소가 ATRIA Dawn Preview 모델을 오픈소스로 공개했고, MetaX는 같은 날 자체 개발 범용 GPU와 MXMACA 소프트웨어 스택을 바탕으로 해당 모델의 Day0 적응을 선도적으로 완료했다고 발표했다. 회사 측은 두 가지 누적 데이터를 제시했다: 2025년 12월 이후 37개 주류 플래그십 모델의 Day0 적응을 완료했으며, Zhipu, 알리바바 Qwen, MiniMax, DeepSeek, StepFun, 텐센트 Hunyuan 등을 커버한다; MXMACA 소프트웨어 스택은 40여 종의 AI 프레임워크, 1000여 개 모델과 호환되며, 6000개 이상의 오픈소스 프로젝트 테스트에 적응했고, PyTorch 2.8의 2410개 GPU 연산자를 전량 지원한다. 구분해야 할 점은: 이 적응은 제조사 자체 소프트웨어 스택을 사용한 것으로, FlagOS 내 metax 백엔드(Torch-FL의 metax 라우팅, FlagGems의 metax 백엔드)와는 두 개의 병행 경로이다; 둘을 함께 읽어야 회원 단위가 「자체 스택으로 Day0 경쟁」과 「통합 스택 공동 구축」에서의 이중 투자를 볼 수 있다.

2.3 Enflame 테크놀로지 STAR Market 상장: 자본 측 관점과 생태계 포지션의 두 가지 읽기 (09-15)

날짜: 2026-09-15　출처: 21차이징, 동화순, 차이롄서

Enflame 테크놀로지가 09-11 STAR Market에 상장한 후, 관련 해석이 모니터링 기간 내 계속 확산되었다: 발행가 142.18위안, 상장 첫날 시초가 410위안, 시초가 상승률 188.37%, 장중 최고 475위안, 종가 397위안, 상승률 179.22%, 대응 시가총액 1708.5억 위안, 조달 자금 614억 위안; 2023~2025년 매출 3.01억, 7.22억, 9.90억 위안, 2026년 상반기 11.20억 위안, 전년 대비 279.08% 증가, 3년간 지배주주 귀속 순손실 합계 43억 위안 초과, 미보전 결손 44.41억 위안, 회사 자체 추정 2026년 또는 2027년 흑자 가능성. FlagOS 회원 단위로서 Enflame의 생태계 측 대응 동작은 시세가 아닌 코드이다: 본 모니터링 기간에 그 enflame 백엔드는 FlagGems 연산자 라인, vLLM 0.24 적응 라인, sglang의 GCU CI에 동시에 등장했다. 자본 서사가 답하는 것은 「지속 투입이 가능한가」이고, 코드 커밋이 답하는 것은 「투입이 어디에 떨어지는가」이며, 둘 다 이번 기간 클라우드 추론을 가리킨다.

2.4 Open3D-PIMC, 발표에서 코드까지: 미디어 측과 코드 측의 48시간 시차 (09-14~09-16)

날짜: 2026-09-14 ~ 2026-09-16　출처: 신화망, 저장소 최초 커밋

09-14 중국 컴퓨팅 파워 콘퍼런스에서 Open3D-PIMC 오픈소스 릴리스를 발표했을 당시 저장소 내에는 코드가 없었다. 09-16 09:30이 되어서야 유일한 루트 커밋이 나타났고, 한 번에 662개 항목(컴파일 레이어, C++ 런타임, 예제 및 아키텍처 다이어그램)을 가져왔다. 미디어 측의 표현은 “코드가 이미 오픈소스 커뮤니티에 공개되었다”, “올해 4분기에 글로벌 최고 기술 컨퍼런스에서 3D 칩 컴퓨팅 파워를 위한 최신 최적화 성과를 발표할 예정이다”였지만, 코드 측 타임스탬프는 공개가 발표 후 약 44시간 뒤에 이루어졌음을 보여준다. 이는 모순을 구성하지는 않지만 하나의 읽기 방식을 시사한다. 차세대 칩 형태를 겨냥한 프로젝트에서 그 “릴리스”는 노선 선언이며, 진정한 사용 가능성은 저장소의 후속 커밋 리듬을 봐야 한다는 것이다. 본 리포트는 이후 이를 정규 점검에 포함할 것이다.

3. 멤버사 심층 분석

3.1 칭웨이즈넝(Qingwei): Open3D-PIMC 코드 안착과 3D 재구성 가능 노선의 합류 (09-16)

날짜: 2026-09-16　출처: Open3D-PIMC README, 칭화대학교 공식 웹사이트

칭웨이즈넝이 이번 기간 org 내에서 한 움직임은 Open3D-PIMC의 최초 코드 커밋이다. 안착된 내용을 보면, 그 기술적 주장은 회사의 재구성 가능 노선과 같은 선상에 있다. README는 3D-DRAM 적층 이후의 핵심 문제를 “데이터가 어느 메모리 계층에 거주하는가, 텐서가 Chiplet/Die/Tile 간에 어떻게 분포되는가, 연산과 통신이 올바른 시점에 협력 스케줄링될 수 있는가”로 규정하며, 더 이상 단일 연산자 처리량이 아니다. 제시된 해법은 계층적 샤딩, N3D 데이터 상주, 객체 수명주기와 Graph/Eager 경계를 IR에 기록하고, 벤더가 플러그인 형태로 비용 모델, 스케줄러, 코드 생성을 제공할 수 있도록 하며, 프런트엔드, IR, 런타임 ABI 호환성을 유지하는 것이다. raisa-inductor라는 명명과 runtime/rcs2의 C++ 엔진은 자체 개발 컴파일 및 런타임 스택의 외부 오픈소스 버전이 안착되었음을 보여준다. 공개 정보가 제시한 로드맵(2세대 3D 재구성 가능 칩 곧 양산 테이프아웃, 누적 컴퓨팅 파워 카드 주문 3만 장 초과, 10여 개 성급 지역의 천 카드급 지능형 컴퓨팅 센터 안착)과 결합하면, 칭웨이의 FlagOS 생태계 내 위치는 여전히 일관된다. 보완형 연산자 기여자가 아니라 차세대 칩 형태에서 소프트웨어 정의권을 확보하려는 것이다.

3.2 하이광(Hygon): 양자화 연산자, CI 이미지, FlagCX wheel 삼선 병행 (09-15)

날짜: 2026-09-15　출처: FlagGems #6185, FlagGems #6247, build-infra #895

하이광은 이번 모니터링 기간 엔지니어링 작업이 가장 분산되어 있으면서도 가장 완결성 있는 기업이다. 연산자 측에서는 W8A8 INT8 양자화 행렬 곱(_out 변형 포함)을 추가하고 하이광을 TLE 활성화 명단에 포함시켰다. FlagTree 측에서는 하이광 라인을 위해 extract_tile 화이트리스트를 허용했다. CI 측에서는 컨테이너의 shm/ipc 옵션을 복원하고 이미지를 업데이트했다. 패키징 측에서는 하이광 빌드가 backend_flagcx.cpp 컴파일 시 gflags 헤더 파일이 없어서 libgflags-dev를 FlagCX의 wheel 빌드 이미지에 추가했다. 또한 Torch-FL의 DCU 라인에서도 FlagTree와 FlagGems를 기본 활성화로 설정했다. 다섯 곳을 함께 읽으면, 하이광의 현재 병목은 “연산자 부족”이 아니라 툴체인과 패키징 환경의 적응에 있다. 이런 문제는 수가 많고 단일 지점의 가치는 낮지만, 바로 이것이 크로스 칩 사용 가능성의 실질적 문턱이다.

3.3 Moore Threads: W8A16 FP8 RMSNorm과 MUSA 라우팅 양방향 조정 (09-15)

날짜: 2026-09-15　출처: FlagGems #6210, Torch-FL #286

Moore Threads의 이번 기간 두 가지 움직임은 방향은 반대지만 논리는 일관된다. 첫째는 FlagGems 측에서 W8A16 FP8의 RMSNorm 경로를 최적화하는 것으로, 기존 연산자를 더 깊게 다듬는 것에 속한다. 둘째는 Torch-FL 측에서 이전에 “MUSA 채우기”로 판정되었던 네 개 항목을 다시 FlagGems 라우팅으로 승격시킨 것으로, 즉 이전에 벤더 커널에 넘겼던 연산자를 다시 회수한 것이다. 전자는 생산량이고 후자는 커버리지이며, 둘을 합치면 MUSA 백엔드가 이미 “돌아가는” 단계를 넘어 디스패치 레이어의 예외 목록을 처리하기 시작했음을 보여준다.

3.4 MetaX: metax rc2 이미지 재빌드 기록과 Day0 적응 서사 (09-15)

날짜: 2026-09-15　출처: build-infra #888, build-infra #887, MetaX 공식 웹사이트

MetaX는 이번 기간 org 내에서의 움직임이 릴리스 산출물에 집중되었다. build-infra는 metax-maca3.8.1.3과 metax-maca3.7.2.1 두 런타임 조합에 대해 각각 하나의 애플리케이션 이미지 tag를 기록했고, metax/ascend 0.20.2 rc2 재빌드의 changelog 항목을 보강했다——두 MACA 버전 라인이 나란히 등재되었다는 것은 해당 드라이버 스택의 지원 폭이 명확히 유지되고 있음을 의미한다. 나흘 전 vllm-plugin-FL의 metax CI와 vLLM 0.24.0 업그레이드 역시 동일한 추론 스택 노력의 일환이다. 대외적으로는 2.2항에 기술된 Day0 적응으로, 자체 MXMACA 스택을 사용한다. FlagOS에게 더 중요한 것은 앞의 항목이다. 이미지 tag의 등재로 metax 측의 멀티칩 검증이 재현 가능한 기준을 갖추게 되었다.

3.5 Enflame: S60의 vLLM 0.24 라인 및 GCU CI 파이프라인 진입 (09-15)

날짜: 2026-09-15　출처: vllm-plugin-FL #464, sglang-plugin-FL #88

Enflame의 이번 기간 두 건은 모두 적응 작업이다. vllm-plugin-FL은 Enflame S60을 vLLM 0.24 라인에 적응시키고, sglang-plugin-FL은 GCU(S60)를 위한 CI 파이프라인을 구축했다. 두 건을 함께 보면, FlagOS 내에서 S60의 추론 경로 커버리지가 vLLM에서 sglang으로 확장되었으며, 둘 모두 CI를 동반한다——이는 이번 모니터링 기간의 전반적 리듬과 일치한다. 멤버 기관의 신규 칩 접속은 더 이상 연산자 등재로 끝나지 않고, 실행 가능한 엔드투엔드 파이프라인을 동시에 제공해야 한다. 2.3의 자본 측 정보와 결합하면, 그 R&D 투자의 착지점을 이런 종류의 커밋에서 직접 읽어낼 수 있다.

3.6 Iluvatar CoreX: iluvatar3.6 백엔드와 FlagTree 0.6.1 바인딩 (09-15)

날짜: 2026-09-15　출처: FlagGems #6188

Iluvatar CoreX의 이번 기간 움직임은 하나의 CI 구성 커밋이다. FlagGems의 backends.yaml이 해당 백엔드를 flagtree==0.6.1+iluvatar3.6으로 업데이트하여, iluvatar 백엔드를 FlagTree의 지정 빌드 버전과 바인딩했다. 단일 커밋의 정보량은 크지 않지만, 이는 2.2 검증 매트릭스를 이해하는 하나의 단서다——각 업체의 백엔드 가용성은 실제로 ‘FlagGems 버전 + FlagTree 빌드 변형 + 업체 드라이버’ 세 가지 조합에 달려 있으며, 이런 조합들이 재현성을 보장하기 위해 하나씩 구성에 기록되고 있다.

3.7 Kunlunxin: sum의 tle.gpu 이전 및 paged-KV 규약 수정 (09-15)

날짜: 2026-09-15　출처: FlagGems #6311, build-infra #898, vllm-plugin-FL #516

Kunlunxin의 이번 기간 세 건의 움직임은 방향이 일치한다. FlagGems 측에서는 sum과 sum_dim을 tle.gpu 경로로 이전하고, special_legendre_polynomial_p 연산자를 신규 추가했다. 추론 측에서는 vllm-plugin-FL을 vLLM 0.24.0으로 업그레이드했다. build-infra는 해당 paged-KV 규약의 수정을 기록했다. sum과 같은 기초 리덕션 연산자가 범용 구현에서 TLE 경로로 이전되었다는 것은, Kunlunxin 백엔드가 단순히 가용성만 추구하는 단계를 넘어 ‘언어 확장으로 성능을 압박하는’ 단계에 진입했음을 의미한다.

3.8 Zhiyuan(주관 기관): RC2 거버넌스 자동화 및 2.2 진행 상황 대조 (09-15/09-16)

날짜: 2026-09-15 ~ 2026-09-16　출처: community 커밋 목록, 2.2 릴리스 일정표

주도측이 이번 모니터링 기간에 보인 움직임은 전부 거버넌스 측면에 집중됐다. 먼저 FlagGems의 RC2 두 번째 재태깅(체크리스트 한 줄, 태그 한 번으로 30분 이내 완료)이 있었고, 이어서 13건의 community 커밋이 2.2 릴리스 상태 동기화를 GitHub Project로 옮기고 연관 PR로부터 도출되도록 만들었다. 일정표와 대조하면 현재는 여전히 테스트 및 안정화 기간(09-01~09-24)이며, GA는 09-28로 정해졌고 졸업 기준은 각 FEP의 실행 가능한 Test Plan이 다중 칩 매트릭스에서 검증을 통과하는 것이다. 이번 거버넌스 개편의 한 가지 세부 사항은 기록해 둘 만하다. 워크플로가 project scope가 있는 전용 토큰을 명시적으로 요구하는데, 기본 토큰과 구 조직 토큰 모두 Projects 권한이 없기 때문이다. 이런 “프로세스를 코드로 쓰는” 변경은 어떤 릴리스 노트에도 나타나지 않지만, RC 기간에 25개 항목을 항목별로 추적할 수 있는지를 결정한다.

4. 요약 및 동향 관찰

  • 디스패치 계층이 이번 기간의 주 전장이 됐다: Torch-FL은 하루 만에 여섯 개 플랫폼을 FlagGems-first로 밀어붙였고, PPU는 라우팅을 11개에서 435개로 확장하면서 벤더 커널에 남겨둔 47개 연산자와 그 이유를 항목별로 기록했다. FlagOS의 핵심 약속은 “하나의 연산자 라이브러리를 여러 칩에서 재사용”이며, 디스패치 계층은 바로 이 약속이 이행되는 지점이다. 이번 기간에 이 계층에 대한 완전하고 감사 가능한 정량적 기준이 처음 등장했다.
  • 양자화 연산자와 어텐션 변형이 신규 생산능력의 양 끝이다: FlagGems 측의 Hygon W8A8 INT8 GEMM과 Moore Threads의 W8A16 FP8 RMSNorm, FlagAttention 측의 SageAttention(QK INT8 블록별 양자화)과 GDN2, Cambricon 측의 SparseAttnSharedKV(DeepSeek-V4 희소 어텐션, 헤드 차원 512)가 그것이다. 이 연산자들의 공통점은 테스트 스위트의 커버리지가 아니라 현재 추론 모델의 실제 구조에 직접 대응한다는 점이다.
  • 릴리스 거버넌스가 체크리스트에서 자동화로 이동한다: RC2의 두 번째 태깅은 체크리스트 한 줄만 바꿨고, 곧이어 new 워크플로가 이슈 상태를 연관 PR과 정렬시켰다. Go/No-Go의 근거가 “사람이 체크리스트를 보는 것”에서 “상태를 도출할 수 있는 것”으로 바뀌고 있다. 09-28 GA까지 아직 13일 남았으며, 이 체인이 마지막 주에 안정적으로 작동하는지 지켜볼 만하다.
  • 생태계 측이 “칩 적응”에서 “하드웨어 형태 정의”로 가는 두 번째 단계: Open3D-PIMC는 릴리스 44시간 후 코드 구현을 마치고 3D-DRAM 근접 메모리 컴퓨팅을 위한 계층적 IR, 컴파일 계층, C++ 런타임을 들여왔다. 이는 2.2의 검증 범위에 들어가지 않지만, 차세대 칩 형태에서 FlagOS의 위치를 결정한다.
  • 뉴스 측면에서 열두 번째 연속 조용한 기간: 컴포넌트 수준 검색은 제로 히트였고, 멤버사 측의 가시적 뉴스는 자본시장과 자체 스택의 Day0 적응에 집중됐다. 기술 진전의 관찰 창은 완전히 코드 저장소로 옮겨갔으며, 이는 데일리 리포트의 가치가 “요약 보도”에서 “커밋 해석”으로 바뀌고 있음을 의미한다.

부록: 출처 검증표

출처 검증 결과
GitHub org flagos-ai 53개 저장소의 pushed_at 전수 검증, 20개가 모니터링 기간 내 푸시 있음. commit search는 모니터링 기간 내 커밋 119건을 포착, 17개 저장소에 분포
GitHub releases / tags FlagGems, FlagTree, FlagCX, FlagAttention, vllm-plugin-FL, FlagSparse, FlagScale, KernelGen, Torch-FL, FlagQuantum, build-infra, community 열두 개 저장소 확인. 모니터링 기간 내 신규 태그는 FlagGems v5.4.0-rc2.post2. 신규 GitHub Release 없음
community 릴리스 체크리스트 2.2 RC2 체크리스트 25개 항목(L0~L3 네 계층), FlagGems는 rc2.post2로 재태깅, 나머지는 여전히 rc2.post1 지칭. 일정표상 GA는 09-28
Google News RSS(중문 17그룹) 컴포넌트명 검색 제로 히트. 멤버사 및 산업 용어로 모니터링 기간 내 결과 13건 확보, 시세 및 무관 기사 제외 후 2건 유지
Google News RSS(영문 7그룹) FlagOS, FlagGems, BAAI FlagOS, flagos-ai 등 검색은 모니터링 기간 내 제로 히트
HN Algolia FlagOS, FlagGems, FlagScale, BAAI 검색에 모니터링 기간 내 유효한 기술 논의 없음
BAAI 커뮤니티(hub.baai.ac.cn) 직접 접속 가능, 검색 및 홈페이지 모두 FlagOS 관련 모니터링 기간 내 항목 없음
CSDN FlagOS 커뮤니티 직접 접속 가능, 최신 글 날짜는 09-10에서 멈춤, 모니터링 기간 내 업데이트 없음
MetaX 공식 사이트 / Gankun / Sina Finance ATRIA Dawn Preview의 Day0 적응 확인(이벤트 09-14, 보도 09-15 11:17 모니터링 기간 내)
21 Caijing / Tonghuashun / Cailian Press / Hangzhou Net Enflame Science and Technology Innovation Board 상장 첫날 데이터 확인(이벤트 09-11, 해설 기사가 모니터링 기간 내 지속)
Xinhua Net Open3D-PIMC가 중국 컴퓨팅 파워 대회에서 오픈소스로 발표(09-14), 09-16 코드 구현과 대조 형성

전체 출처 목록

[22] FlagGems #6149 (addmv dtype 불일치 수정) — https://github.com/flagos-ai/FlagGems/pull/6149