모니터링 기간: 2026-09-10 10:18 ~ 2026-09-11 10:18 베이징 시간 출처: GitHub(org: flagos-ai, 53개 저장소 pushed_at + 단일 commit search 60건 committer-date 기준 전수 검증 + per-repo commits 재확인 + 브랜치 API + commit 상세 및 패치), Google News RSS(중영문 13개 쿼리어, 프록시 경유), HN Algolia, Tavily/web 검색, FlagOS 공식 CSDN 계정, Zhiyuan 커뮤니티(부록 참조)

인덱스

    1. 오픈소스 프로젝트 진행 (GitHub 동향)
      • 1.1 FlagTree 버전 0.7.0으로 수렴: 29개 벤더 딜리버리 워크플로 일괄 전환 (09-10/09-11)
      • 1.2 build-infra: Ascend 910C 애플리케이션 계층 정식 개방, vLLM 듀얼 버전 4개 이미지 매트릭스 진입 (09-10)
      • 1.3 build-infra: sglang0.5.18 시작 문서 전 매트릭스 생성, sglang이 1급 애플리케이션 라인으로 승격 (09-10)
      • 1.4 build-infra: 패키징 채널 정책 문서화, 설치 채널 경계 고정 (09-10)
      • 1.5 FlagTensor: Hygon DCU와 Kunlunxin XPU 듀얼 백엔드 메인라인 병합, 설치 스크립트 수렴 (09-10)
      • 1.6 vllm-plugin-FL: XiWang Sunrise 어텐션 백엔드 vLLM 0.24.0으로 이식, Damo Academy XuanTie 정적 그래프 복구 (09-10)
      • 1.7 FlagGems: KMCompiler의 Ascend/MetaX 듀얼 라인 추진 및 설치면 결함 수정 (09-10)
      • 1.8 도메인 라이브러리와 툴체인: FlagGems-vllm Hygon 연산자, FlagDNN 백엔드 문서, FlagCX MUSA, Torch-FL DCU 라우팅 (09-10)
      • 1.9 FlagTree 엔지니어링면: Qingwei CI/CD 체계화, TLE NVIDIA 레이아웃 최적화 당일 병합 당일 롤백 (09-10)
    1. 뉴스 보도와 생태계
      • 2.1 컴포넌트급 뉴스 9번째 연속 정온 기간, 정보면 전부 코드 저장소에서 유래 (09-10)
    1. 멤버 단위 심층 분석
      • 3.1 Qingwei Intelligence: 컴파일러 라인 “백엔드 컴파일 가능”에서 “파이프라인 자체 유지”로 진입 (09-10)
      • 3.2 Hygon Information: 연산자, 텐서 라이브러리, 도메인 라이브러리 문서, 런타임 라우팅 4개 라인 동시 추진 (09-10)
      • 3.3 Kunlunxin: FlagTensor XPU 백엔드 병합, 4계층 작업면 병행 (09-10)
      • 3.4 XiWang Xinke와 Damo Academy XuanTie: 외부 추론 GPU와 PPU 백엔드 동일 기간 강화 (09-10)
      • 3.5 Zhiyuan(주도 기관): 딜리버리 파이프라인 버전 통일과 패키징 정책 두 가지 거버넌스 조치 (09-10)
    1. 요약
  • 부록: 전체 출처 목록

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

기간 총람: org 내 53개 저장소 중 13개가 기간 내 푸시됨; commit search 히트 60건 기간 내 커밋(단일 페이지 전수, committer-date 내림차순), per-repo commits 재확인으로 Megatron-LM-FL 1건 추가 편입(search 인덱스 지연으로 미수록), 합계 61건, 12개 저장소에 분포: build-infra 24, FlagGems 10, FlagTree 8, FlagTensor 5, vllm-plugin-FL 3, FlagDNN 3, FlagGems-vllm 2, Torch-FL 2, flir 1, FlagFFT 1, FlagCX 1, Megatron-LM-FL 1. 신규 저장소 없음, 신규 컴포넌트 릴리스 항목 없음.

본 기간 형태 = RC 테스트기의 “버전 수렴 + 칩 매트릭스 확장” 듀얼 라인: 컴파일러 측 FlagTree는 0.7.0 버전 번호 수렴을 완료하고 29개 벤더 딜리버리 파이프라인을 일괄 0.7.0으로 전환; 딜리버리 측 build-infra는 Ascend 910C를 “base/runtime 골격만 세움”에서 애플리케이션 계층 개방으로 진전시키고 sglang을 vllm과 나란한 1급 애플리케이션 라인으로 격상; 외부 생태계 측에서는 XiWang Sunrise의 컴포넌트급 백엔드 착지와 FlagTensor의 Hygon DCU, Kunlunxin XPU 듀얼 백엔드 병합이 등장. 직전 기간 “910C가 언제 deps_app를 보충해 app 빌드 매트릭스에 진입하는가”라는 예측이 본 기간에 실현됨.

1.1 FlagTree 버전 0.7.0으로 수렴: 29개 벤더 딜리버리 워크플로 일괄 전환 (09-10/09-11)

출처: FlagTree #1144 (09-10 23:38), #1151 (09-11 02:31)

  • 메인라인 버전 번호가 0.7.0으로 상향 (#1144): 버전 함수가 "0.7.0+" + flagtree_backend + 커밋 해시로 변경됨(백엔드 접미사가 없을 때는 0.7.0 + 해시 반환), 커밋 내에서 여섯 가지 부속 작업이 병행 반영됨——PPU/HCU의 qwen3.6 benchmark 성능 베이스라인 갱신, README에 tsingmicro3.6 설명 추가, wheel 내 LICENSE 보충, TileIR의 third_party 다운로드 수정, Iluvatar 워크플로의 라이브러리 경로 수정; README의 벤더/백엔드 표도 “Installation”에서 “User Guide”로 변경 및 확장.

  • 29개 벤더 딜리버리 워크플로 일괄 0.7.0으로 전환 (#1151): *_delivery.yml의 버전 입력 파라미터 기본값이 '0.6.0'에서 '0.7.0'으로 일괄 변경됨, 동시에 ppu3.6 핵심 테스트 워크플로도 갱신. 해당 29개 라인은: nvidia3.3/3.5/3.6/3.7/3.8, tileir3.6, amd3.6, ascend3.2/3.5, enflame3.5-gcu400/3.6-gcu400, iluvatar3.1/3.6, metax3.0/3.6, mthreads3.1/3.2/3.6, tsingmicro3.3/3.6, sunrise3.4, xpu3.0/3.6, hcu3.1/3.6, aipu3.3, thrive3.6, ppu3.6.

  • 브랜치 측 상태: 0.7.0-rc0-triton3.3/3.5/3.6 세 라인의 헤드는 각각 08-11, 08-27, 08-31에 정지; 0.7.0-rc1-triton3.3/3.5/3.6은 09-01, 09-04, 09-04이며, 그중 rc1-triton3.6의 헤드 커밋이 바로 [Tsingmicro] Add Tsingmicro backend integration (Triton 3.6)(#1071)임.

  • 공식 release는 아직 미등장: GitHub Releases에서 FlagTree 최신 항목은 여전히 0.6.0+triton3.x(2026-06-24)이며, 이번 모니터링 기간의 움직임은 “딜리버리 파이프라인 선행, 버전 번호 수렴”에 해당하며 공식 tag는 발행 대기 중.

해석: 0.7.0의 추진 방식은 RC 기간의 규율을 명확히 보여준다——코드 노선은 바꾸지 않고, 버전 번호와 딜리버리 진입점의 수렴만 수행: 먼저 main에서 패키지 버전을 0.6.0에서 0.7.0으로 올리고, 그다음 29개 벤더 딜리버리 파이프라인 전부가 0.7.0을 가리키도록 통일하여, RC1 목록의 “flagtree 세 라인 통일 0.7.0rc1.post1”이라는 앵커를 공식 버전으로 밀어냄. 추적할 만한 한 가지 어긋남은: build-infra의 configs.yaml에서 NVIDIA 라인이 여전히 flagtree==0.6.1에 pin되어 있다는 점, 즉 “이미 딜리버리된 이미지가 고정한 컴파일러 버전”과 “컴파일러 메인라인 버전” 사이에 한 버전의 추진 차이가 존재하며, 이것이 바로 GA 전에 메워야 할 틈새임.

1.2 build-infra: Ascend 910C 애플리케이션 레이어 정식 개방, vLLM 듀얼 버전 4개 이미지가 매트릭스에 진입 (09-10)

출처: build-infra #816 (09-10 18:36), #813 (15:07), #808 (11:00), #818/#819, #823/#824, #820, #825, #826, #828, #833, #834

  • 애플리케이션 계층 개방(#816, +257/-16): 커밋 설명에는 “910C의 runtime 이미지가 이미 빌드되어 푸시되었으므로, vllm 애플리케이션 라인을 두 개의 910C 라인(ascend-cann8.5.0-910c / ascend-cann9.0.0-910c)에서 개방할 수 있다”고 명시되어 있다. 동시에 4개의 changelog가 새로 추가되었다—vllm0.20.2와 vllm0.24.0이 각각 CANN 8.5.0과 9.0.0에 대응하며, 변경 사항은 vllm-app-image.yml, app/vllm/Containerfile, configs.yaml, docs/status-matrix.md, 두 개의 status_matrix.vllm*.yaml과 렌더링 스크립트를 포함한다.
  • 910C 애플리케이션 이미지 tag가 저장소에 기록되기 시작: #818/#819는 CANN 8.5.0-910c의 2.1.2-0.2.0_g2b6b635.d20260824와 2.1.2-0.2.0_gcf8998c.d20260818을 기록하고, #823/#824는 CANN 9.0.0-910c의 대응 tag를 기록한다.
  • 개방을 위한 안정화 작업: #808은 910C base 이미지에서 apt Post-Invoke 훅을 제거하고, #813은 Ascend 시작 템플릿이 전체 die 쌍을 노출하도록 하며(동일 die 내 두 카드가 쌍으로 가시화), #820은 ascend의 verify 실패 시 자가 진단을 가능하게 하고, #825는 runner 프록시를 verify 설치 단계로 포워딩하며, #826은 ruamel.yaml을 import할 수 있는 runner python을 선택하고, #828은 verify Step 2의 따옴표 이스케이프를 수정하며, #833은 대상 ref에 stub이 포함된 경우에만 flashinfer stub을 빌드하고, #834는 cell의 플러그인 pin을 vllm 애플리케이션 이미지 빌드로 전달한다.

해석: 이는 이전 모니터링 기간에 예측한 내용이 정확히 실현된 것이다. 09-10 리포트의 관찰 포인트는 910C가 “910B 라인 칩의 동형 변형 방식으로 접속되고, deps_app 부재로 app 매트릭스 밖에 차단되었다”는 것이었으며, 당시 “app 아티팩트가 산출되고 검증된 후에 다시 개방하자”고 예측했다. 이번 모니터링 기간의 #816이 바로 그 게이트가 열린 순간이다. 910C의 납품 형태가 “base/runtime 사용 가능”에서 “애플리케이션 사용 가능”으로 업그레이드되었으며, 한 번에 2개의 CANN × 2개의 vLLM 버전 = 네 개의 애플리케이션 이미지 항목을 제시했다. 함께 제공된 아홉 개의 verify/템플릿/이미지 수정은 바로 “새 적합성은 진입 가능하나, 새 기능은 진입 불가”라는 규율 아래의 마무리 작업임을 설명한다. 먼저 verify 자가 진단, 프록시 전달, 의존성 선택 같은 환경 문제가 더 이상 파이프라인을 차단하지 않도록 한 뒤, 매트릭스를 개방하는 것이다.

1.3 build-infra: sglang0.5.18 시작 문서 전체 매트릭스 생성, sglang이 일등 애플리케이션 라인으로 승격 (09-10)

출처: build-infra #831 (09-10 21:38), #817 (19:13), #821 (19:20), #829 (20:42), #830 (20:55)

  • #831 생성기 필터링 로직 수정 (+2862/-34): 커밋 설명에 따르면 생성기가 a in APP_IMAGE_DEFAULTS or a.startswith("vllm")로 deps_app 키를 필터링하여 sglang0.5.18이 렌더러에 진입하기 전에 제거되었으며, 이전에는 어떤 sglang 애플리케이션 이미지에도 시작 페이지가 없었다. 수정 후 모든 sglang 애플리케이션 이미지에 대해 중영문 이중 언어 시작 문서가 생성된다.
  • 커버된 sglang 애플리케이션 라인: ascend-cann8.5.0 / ascend-cann9.0.0(어센드), cambricon-neuware4.4.3 / 4.7.2(캄브리콘), enflame-tops1.9.10 / 1.10.6(엔플레임), hygon-dtk26.04(하이곤), iluvatar-corex4.5.0(일루바타 코어엑스), metax-maca3.7.2.1 / 3.8.1.3(메탁스) 등.
  • 함께 제공: #817이 iluvatar-corex4.5.0을 sglang 0.5.18 라인으로 끌어올림; #821이 sglang0.5.18-iluvatar-corex4.5.0 changelog 추가; #829가 changelog에서 불필요한 image 키 수정; #830이 app image tag 2.1.2-0.1.dev1_g201484665 기록.
  • 동시 이미지 설명 갱신: #810과 #814가 각각 base와 runtime 이미지의 2.1.2 설명 문안을 갱신하고, #815가 flaggems-release의 runtime:v1 이미지 tag를 configs.yaml에서 도출하도록 함.

해석: 이 항목은 표면적으로 보이는 것보다 중요하다. vllm과 sglang은 FlagOS가 대외적으로 추론 능력을 납품하는 두 가지 주 프레임워크 라인이며, 이전 매트릭스의 실제 형태는 “vllm 전량, sglang 산발적”이었다. 이번 모니터링 기간의 작업은 sglang0.5.18을 최소 10개 칩 라인에서 시작 문서와 changelog로 보완했으며, 이는 sglang이 납품 기준에서 이미 vllm과 병렬 위치에 있음을 의미한다. 이는 이번 모니터링 기간의 FlagGems-sglang 대회 라인, 09-07 리포트에 기록된 “KubeCon 오픈 AI 컴퓨팅 포럼”과 호응한다. 추론 프레임워크의 커버리지 범위가 점차 커뮤니티가 대외적으로 보여주는 주요 차원이 되고 있다.

1.4 build-infra: 패키징 채널 정책 문서화, 설치 채널 경계 고정 (09-10)

출처: build-infra #812 (09-10 21:45)

  • 문서 docs/content/en/usage/packaging-channels.md(122줄)와 docs/content/zh-cn/usage/packaging-channels.md(97줄)를 새로 추가했으며, 이전에 논의된 결론을 정책으로 고정했습니다. deb/rpm 채널은 순수 Python 패키지와 네이티브 라이브러리를 담당하고(대상 배포판별로 저장소 하나에 소스 하나), 각 벤더의 사설 PyPI 인덱스는 벤더 측 의존성을 담당하며, 두 경계가 명확히 기술되었습니다.

해석: 이는 2.2 GA 이전의 거버넌스형 커밋으로, 지난 모니터링 기간의 60개 app 이미지 changelog 기준선 + push 게이팅과 같은 맥락입니다. 먼저 “아티팩트가 어디서 오는지”를 설명하고, 그다음 “의존성을 어디서 설치하는지”를 설명하는 것입니다. 십여 개 칩 벤더의 사설 툴체인을 포괄해야 하는 소프트웨어 스택에게 설치 채널의 정책화는 멀티 벤더 배포가 규모화될 수 있는지의 전제 조건입니다.

1.5 FlagTensor: Hygon DCU와 Kunlunxin XPU 듀얼 백엔드 메인라인 병합, 설치 스크립트 통합 (09-10)

출처: FlagTensor #5153939 / #1be84f2 (09-10 10:37 각 1건), #81c6214 (10:39), #2f895c1 (10:47), #efed2c4 (10:48)

  • 두 신규 백엔드 병합: feat: merge Hygon DCU + Kunlunxin XPU backend support는 Hygon 브랜치(FlagTensor-haiguang의 적응 성과 포함)를 main에 병합했으며, 통계는 +4225/-168(4393줄)이고 변경의 본체는 benchmark와 백엔드 적응 계층입니다. 같은 분에 별도로 add Hygon DCU and Kunlunxin XPU backend support 한 건이 있습니다.
  • 설치와 문서 측면 통합: #2f895c1은 setup_muxi.sh를 통합 setup.sh --backend metax의 한 분기로 병합했습니다. #efed2c4는 독립 스크립트를 삭제했습니다. #81c6214는 MetaX 전용 성능 보고서 PERF_REPORT_metax.md를 제거했습니다.

해석: “백엔드 수 +2, 유지보수 면 -1 세트의 전용 스크립트”로 방향이 일치합니다. 한편으로는 Hygon DCU와 Kunlunxin XPU 두 종류의 신규 하드웨어를 텐서 라이브러리에 포함시키고, 다른 한편으로는 벤더 전용 설치 경로를 통합 진입점으로 수렴시켜 벤더 수 증가에 따라 선형으로 팽창하는 스크립트 유지보수 비용을 피합니다. FlagTensor는 6월 “과학 지능 기반” 발표의 6대 분야 라이브러리 중 하나이며, 그 멀티 백엔드 확장은 과학 계산 라이브러리가 여전히 “한 번 개발, 다중 칩 실행”이라는 목표에 따라 전개되고 있음을 보여줍니다.

1.6 vllm-plugin-FL: Sunrise 어텐션 백엔드 vLLM 0.24.0 이식, DAMO XuanTie 정적 그래프 복구 (09-10)

출처: vllm-plugin-FL #391 (09-10 20:01), #472 (10:33), #480 (18:22)

  • #391 (+37/-1): 제목은 “Sunrise 백엔드를 vLLM 0.24.0으로 이식”이며, 커밋 설명에는 대상이 Sunrise(Xiwang TANGRT 1.2.0)라고 명시되어 있고, 두 변경 모두 sunrise vendor 경로 아래에 있습니다. attention.py는 CUSTOM 모드로 어텐션 백엔드 등록을 수행하고, patch.py는 ptpu의 memory_stats 호환 계층을 추가합니다.
  • #472: DAMO XuanTie(thead) 백엔드의 정적 그래프 지원을 복구했습니다(이전 커밋에서 비롯된 회귀 수정).
  • #480: PR에 /rerun-failed-ci와 /cancel-ci 두 가지 댓글 명령을 추가했습니다. 저장소 README의 칩 벤더 표에는 이미 Sunrise가 Supported로 등록되어 있습니다.

해석: 이는 이번 모니터링 기간 외부 생태계에서 가장 실질적인 진전이다. 09-07/09-08 기간에 기록된 Xiwang의 진전은 “runner 환경 구성이 선행되었을 뿐, 아직 컴포넌트가 병합되지 않음”에 불과했지만, 이번 기간에는 컴포넌트 수준의 안착을 완료했다——Xiwang의 툴체인 버전(TANGRT 1.2.0)을 vLLM 0.24.0의 접속 전초 플러그인에 연결한 것이다. FlagOS 입장에서 이는 “신규 칩 접속”의 표준 경로(먼저 통합 환경으로 runner를 세우고, 이어서 vllm-plugin-FL에 vendor 백엔드를 안착시키는 것)가 한 차례 완주되었다는 뜻이며, 재사용 가능한 접속 템플릿이다. #480의 두 가지 CI 운영 명령과 build-infra의 verify 자가 진단은 모두 “다중 벤더 CI 유지보수 비용”의 엔지니어링 원가 절감에 속한다.

1.7 FlagGems: KMCompiler의 Ascend/MetaX 양방향 추진과 설치면 결함 수정 (09-10)

출처: #6138, #5821, #6155, #6160, #6156, #6157, #6146, #6087, #6147, #6131

  • KMCompiler 생성 경로: [KMCompiler][Ascend] Opt replication pad2d backward(#6138), [KMCompiler][Ascend] Add ascend backend for linalg_solve_triangular(#5821), [KMCompiler][MetaX] Fix gru bug(#6155)——”한 번 개발, 다중 백엔드 안착”이라는 연산자 신규 추가 방식을 이어갔다.
  • 벤더 CI 라인 축소: fix(.github): remove metax-maca3720 info(#6160), 앞서 CI 항목을 제거한 데 이어 잔여 정보를 정리했다.
  • 설치 및 실행 정확성 수정: #6146은 누락된 DSA/__init__.py를 보충하여 비편집 설치에서 해당 하위 패키지가 포함되도록 했다(다운스트림 플러그인의 설치 완전성과 직접 관련); #6087은 인덱스 연산자의 pid_p를 int64로 변환하여 int32 오프셋 오버플로를 수정; #6147은 adaptive_avg_pool3d_backward의 스케줄링 지정 오류를 수정; #6131은 irshift의 benchmark 명명을 수정.
  • 엔지니어링 측면: #6157은 init exports 검사를 확장; #6156은 서드파티 파일에 잘못 추가된 Apache 2.0 헤더를 정리.

해석: 이전 모니터링 기간이 “39건 중 KernelGen 대용량 연산자 입고가 주를 이룸”이었다면, 이번 기간 메인 저장소 커밋 수는 10건으로 줄었고 구조도 “물량 확대”에서 “커버리지와 내실 강화”로 전환되었다: 생성기 경로는 계속 Ascend, MetaX 백엔드를 보충하고, 나머지는 설치 완전성과 수치 정확성에 집중되었다. 그중 #6146과 같은 “하위 패키지가 설치되지 않음” 결함은 다운스트림에 대한 영향이 가장 크다——vllm/sglang 플러그인 모두 연산자 라이브러리의 완전한 설치면에 의존하며, 이러한 수정은 바로 RC 기간에 “돌아간다”를 “설치되고, 올바르게 돌아간다”로 바꾸는 전형적인 작업이다.

1.8 도메인 라이브러리와 툴체인: FlagGems-vllm Hygon 연산자, FlagDNN 백엔드 문서, FlagCX MUSA, Torch-FL DCU 라우팅 (09-10)

출처: FlagGems-vllm #736, #704, Torch-FL #270, #247, FlagCX #576, FlagDNN, FlagFFT, Megatron-LM-FL #148

  • FlagGems-vllm: #736 [AdvancedCompiler] add hygon fused_add_rms_norm, Hygon 전용 연산자 구현 325줄을 새로 추가하고 _hygon 백엔드에 등록했으며, 동시에 구버전 Triton을 위해 TensorDescriptor 임포트 보호를 추가; #704는 moe_sum에 pair-load 고속 경로를 추가.
  • Torch-FL: #270 perf: restore fused SDPA on the boxing route via a composite override (+658줄), 근본 원인은 커밋과 함께 제공된 문서(docs/bench_qwen3_dcu_route_perf.md)에 기록되어 있음 — aten::scaled_dot_product_attention은 composite op이고, 융합 백엔드 선택이 composite 내부에서 일어나며 leaf 단위로 분해되면서 융합 경로가 유실되었고, composite 레벨 오버라이드로 복구함; 이 작업은 명확히 DCU 라우트를 대상으로 함. 별도로 #247은 transformers 테스트의 자동 분류 파이프라인을 추가.
  • FlagCX: #576 [PAL] Link default device API backend for MUSA platform, Moore Threads MUSA 플랫폼에 기본 device API 백엔드를 연결(makefiles/musa.mk).
  • FlagDNN: 연속 세 건의 백엔드 문서 커밋 — Hygon readme 추가, Hygon readme 수정, Iluvatar CoreX readme 추가.
  • FlagFFT: README의 백엔드 지원 설명을 갱신하고 의존 관계를 명확히 함.
  • Megatron-LM-FL: #148 fix(platform): prefer native accelerator detection, 플랫폼 탐지 시 네이티브 가속기 인식을 우선하도록 변경.

해석: 이 그룹은 “도메인 라이브러리와 학습/추론 툴체인”의 횡적 확장이다: Hygon(연산자 + 텐서 라이브러리 + 도메인 라이브러리 문서 + 런타임 라우팅), Moore Threads(통신 라이브러리 플랫폼 연결), Iluvatar CoreX(문서)가 같은 모니터링 기간에 각각 움직임을 보였다. Torch-FL의 산출물은 독립적인 벤치마크 문서와 stub 소스를 포함하고 있어, 보기 드문 “성능 문제에 완전한 증거 체인을 동반한” 커밋이며, 학습/추론 경로에서의 성능 회귀가 정규 추적 대상에 포함되었음을 보여준다.

1.9 FlagTree 엔지니어링 측면: Qingwei CI/CD 본격화, TLE NVIDIA 레이아웃 최적화 당일 머지 당일 롤백 (09-10)

출처: FlagTree #1118, flir #69, #1047, #1139(revert), #1075, #1074, #1143

  • Tsingmicro 측의 컴파일러 인프라(#1118, +344/-10): tsingmicro 백엔드와 FLIR의 공동 빌드를 수정하고, 두 개의 워크플로를 새로 추가했다——tsingmicro3.6-build-and-test.yml(115행)과 tsingmicro3.6-delivery.yml(191행); CMake 측에는 FlagTreeOptions 스위치를 새로 추가했고, third_party/tsingmicro의 Tx81 런타임과 예제 테스트도 함께 수정했다; 커밋은 Tsingmicro 측 패치와 커뮤니티 봇이 공동 서명했다. FLIR 측 대응 커밋 #69는 Tsingmicro의 FLIR 패치를 동기화하여 LLVM 22를 지원한다(FLIR은 FlagTree의 IR 중간 계층으로, triton-shared에서 포크되었다).
  • TLE NVIDIA 레이아웃 최적화가 당일 머지되고 당일 롤백됨: #1047은 12:35에 “shuffle로 동일 warp 내 layout 변환을 하위 배치”를 머지했으나, 13:47에 #1139로 롤백되었다. 동일 모니터링 기간의 MTHREADS 측은 두 건의 실질적 머지를 유지했다: #1074(SQMMA 구성에서 순수 M-split을 선호), #1075(PH1의 swizzled 공유 메모리 접근을 LinearLayout으로 하위 배치).
  • 기타: #1143은 Enflame 경로에서 of 네임스페이스의 gcc7 컴파일 오류를 수정했다.

해석: Tsingmicro의 이 라인은 자체적으로 “빌드와 딜리버리 워크플로를 갖추는” 능력을 이미 보유했음을 보여준다——커뮤니티가 대신 배선해주기를 기다리는 것이 아니라. 이전에 FlagTree에서 Triton 3.3 백엔드 형태로만 존재했던 벤더에게 이것은 상당히 완성도 높은 진전이다. 반대로 TLE NVIDIA의 당일 롤백은 엔지니어링 리듬의 각주로 삼을 만하다: RC 동결 기간에 성능 최적화가 회귀를 초래하면, 문제를 안고 진행하는 것이 아니라 당일 롤백하는 방식으로 처리하며, 이는 “새 적응은 들어올 수 있으나 새 기능은 들어올 수 없다”는 규율과 일치한다.

2. 뉴스 보도와 생태계

2.1 컴포넌트급 뉴스 아홉 번째 연속 평온 모니터링 기간, 정보면 전부가 코드 저장소에서 나옴(09-10)

출처: Google News RSS 중영문 13개 쿼리(09-10 10:18 ~ 09-11 10:18, 프록시 경유)、HN Algolia、FlagOS 공식 CSDN 계정、Zhiyuan 커뮤니티

  • 컴포넌트 수준 쿼리 전부 제로 히트: FlagOS when:2d, FlagOS when:14d, FlagGems when:3d/14d, FlagScale when:3d, FlagTree when:7d, FlagCX when:14d, FlagAttention OR FlagPerf when:14d, KernelGen when:7d, BAAI open source when:2d, 沐曦 开源 算子 when:2d 등 중영문 쿼리 모두 히트가 없으며, 이는 컴포넌트 수준 검색의 아홉 번째 연속 평온 모니터링 기간을 구성한다.
  • 멤버 기관 키워드는 노이즈 또는 자본시장 콘텐츠: 摩尔线程 智源 when:2d는 12건 히트되었으며, 주체는 JD Cloud 10만 카드 클러스터의 전재 및 주가류 보도(09-09 모니터링 기간에 이미 기록된 내용의 연속), 그리고 도박류 SEO 기사이다. 智源研究院 开源 when:2d는 9건 히트되었으며, Zhiyuan 커뮤니티의 정규 기사와 도박 SEO(임바디드 인텔리전스류 커뮤니티 기사, AI 분쟁 재판 등 포함)로, FlagOS 기술 스택과 직접적 연관이 없어 기존 기준에 따라 전량 제외한다.
  • HN Algolia 히트는 부분 문자열 오매칭: FlagOS/FlagGems/FlagTree/FlagScale/BAAI 다섯 그룹 쿼리의 제목은 모두 flags/flagship류 무관 항목(예: “15x10 Pixel Flags”, Show HN 시리즈)으로, 본 기술 스택을 가리키는 항목이 하나도 없어 전량 제외한다.
  • 공식 콘텐츠 채널 신규 발행 없음: FlagOS 공식 CSDN 계정은 모니터링 기간 내 새 글이 없으며, 최신은 여전히 08-28의 GLM-5.3-Flash Day0 9개 칩 적응이다. 09-07의 KubeCon 동일 장소 포럼과 연산자 튜닝 주제 페이지는 계속 게시되어 있으나 발행 시점 업데이트는 없다. Zhiyuan 커뮤니티와 공식 웹사이트도 모니터링 기간 내 FlagOS 관련 신규 발행이 없다.

해석: 뉴스 측과 코드 측의 분화가 이번 모니터링 기간에 최근 최대치에 도달했다——61건의 커밋에는 버전 수렴, Ascend 910C 애플리케이션 계층 개방, sglang 전체 매트릭스 문서, 두 개의 신규 백엔드 병합 등 실질적 진전이 포함되어 있으나 외부 보도는 제로이다. 이는 FlagOS의 현재 대외 인지도가 엔지니어링 진척과 동기화되지 않음을 의미하며, 커뮤니티의 정보 발행은 여전히 “모델 Day0 적응”과 “대회 포럼” 두 가지 노드에 집중되어 있다. 이번 모니터링 기간의 진전은 딜리버리와 컴파일러 메인라인에서 읽어야 하며, 이 판단은 추적 리듬에 직접적 영향을 미친다.

3. 멤버 기관 심층 분석

3.1 Tsingmicro: 컴파일러 라인이 “백엔드 컴파일 가능”에서 “파이프라인 자립”으로 (09-10)

출처: FlagTree #1118, flir #69

  • 모니터링 기간 내 세 가지 조치는 동일한 사안을 가리킨다: FlagTree에 tsingmicro3.6의 build-and-test 및 delivery 두 워크플로 추가, FLIR과의 공동 빌드 수정, FLIR이 LLVM 22 지원을 위해 Tsingmicro 패치 동기화, FlagTree README 변경 로그에 “2026/09/10 Tsingmicro 백엔드 Triton 3.6으로 업그레이드 및 CI/CD 추가” 기록.
  • 딜리버리 측면: tsingmicro3.3과 tsingmicro3.6 두 라인 모두 이번 모니터링 기간의 0.7.0 통합 전환 목록에 포함되어 있다.

해석: Tsingmicro가 이전에 FlagTree에서 가진 형태는 “Triton 3.3 기반 백엔드 통합”이었으나, 이번 모니터링 기간 이후 “자체 빌드/딜리버리 워크플로를 갖추고 LLVM 22 및 Triton 3.6에 정렬된 정규 딜리버리 라인”으로 변화했다. 멤버에 대한 판단 가치는 다음과 같다: 컴파일러 계층에서 신세대 지원이 더 이상 커뮤니티 대행에 의존하지 않는다는 것은 Tsingmicro 측 컴파일러 팀이 독립 유지보수 능력을 갖추었음을 의미하며, 두 제품 라인이 동시에 딜리버리 매트릭스에 진입한 것은 세대 전환이 FlagOS의 정규 버전 리듬에 편입되었음을 의미한다.

3.2 Hygon: 연산자, 텐서 라이브러리, 도메인 라이브러리 문서, 런타임 라우팅 네 라인 동시 추진 (09-10)

출처: FlagTensor #1be84f2, FlagGems-vllm #736, Torch-FL #270, FlagDNN, build-infra #831

  • 이번 모니터링 기간 Hygon은 분산되어 있지만 같은 방향을 향한 네 가지 움직임을 보였다: FlagTensor에 DCU 백엔드 병합(+4225줄); FlagGems-vllm에 Hygon 전용 fused_add_rms_norm 추가(325줄); FlagDNN에 Hygon 백엔드 문서 추가; Torch-FL에서 DCU 라우팅을 대상으로 융합 SDPA를 복원하고 벤치마크 문서를 남겼다. 전달 측면에서는 별도로 sglang0.5.18-hygon-dtk26.04의 기동 문서가 전체 매트릭스에 진입했다.
  • 09-09 모니터링 기간에 기록된 “Hygon Token 운영 듀얼 칩 가속 방안”과 결합해 보면, Hygon의 소프트웨어 스택 내 움직임은 초기의 연산자 전용화에서 텐서 라이브러리 백엔드, 도메인 라이브러리 문서, 런타임 성능 라우팅으로 확장되었다.

해석: Hygon은 현재 FlagOS 내에서 작업 면이 가장 넓은 멤버 단위 중 하나이다——연산자 라이브러리, 텐서 라이브러리, 도메인 라이브러리 문서, 추론 플러그인(sglang 애플리케이션 라인), 그리고 Torch-FL의 런타임 라우팅까지 모두 진행 중인 작업이 있다. 상업적 서사(Token 팩토리)와 소프트웨어 스택 커버리지가 동시에 추진된다는 것은, FlagOS 내에서 Hygon DCU의 위치가 “적응 대상 칩”에서 “심층 공동 구축 멤버”로 전환되고 있음을 의미한다.

3.3 Kunlunxin: FlagTensor XPU 백엔드 병합, 4개 계층 작업면 병행 (09-10)

출처: FlagTensor #1be84f2, FlagTree 전달 라인 목록

  • 이번 모니터링 기간에 FlagTensor는 Kunlunxin XPU 백엔드와 Hygon DCU를 함께 메인라인에 병합했다; 전달 측면에서는 xpu3.0과 xpu3.6 두 워크플로가 0.7.0 통합 전환에 포함되었다.
  • 이전 기록과 연결해 보면: 09-02 모니터링 기간에 FlagGems에 Kunlunxin 백엔드 slice_scatter 범위 초과 수정이 있었고, 09-08 모니터링 기간에 FlagScale에 Kunlunxin P800의 학습 CI와 런타임 지원이 있었으며, 09-09 모니터링 기간에는 FlagGems-Experimental의 Kunlunxin KernelGen 연산자 대량 병합이 기록되었다.

해석: Kunlunxin은 현재 “텐서 라이브러리(FlagTensor), 연산자 라이브러리(FlagGems), 학습 프레임워크(FlagScale), 컴파일러 전달(FlagTree xpu 두 라인)” 4개 계층 모두에서 진행 중인 작업면을 가지고 있으며, 형태상 이미 심층 적응 벤더에 가깝다. Kunlunxin이 커뮤니티에 공개된 멤버 단위 명단에 없다는 점을 고려하면, 그 투입 강도는 외부 생태계 확장의 표본으로 지속 추적할 가치가 있다.

3.4 Xiwang Xinke와 Damo Academy Xuantie: 외부 추론 GPU와 PPU 백엔드 동일 모니터링 기간 강화 (09-10)

출처: vllm-plugin-FL #391, #472, FlagTree #1144

  • 쉬왕싱커(Sunrise): vllm-plugin-FL이 자사의 어텐션 백엔드를 vLLM 0.24.0(대상은 TANGRT 1.2.0 툴체인)에 이식하여 “runner 환경 전용”에서 “컴포넌트급 백엔드”로 도약했다. 전달 측면에서는 sunrise3.4가 0.7.0 전환에 포함되었고, 공식 칩 제조사 목록에 Sunrise가 등재되었다.
  • 다모원 쉬안톄(T-Head): vllm-plugin-FL #472가 자사의 백엔드 정적 그래프 지원을 복원했다. 전달 측면에서는 ppu3.6이 0.7.0 전환에 포함되었고, FlagTree #1144가 PPU의 qwen3.6 benchmark 성능 기준선을 동기 갱신했다.

해석: 두 곳 모두 “비회원 단위의 추론 측 투자”에 속한다. 쉬왕은 추론 GPU에 집중하는 중국 국내 제조사(제품 라인 S1/S2/S3는 추론 시나리오 대상)로, 업스트림을 따르는 플러그인 라인인 vLLM 0.24.0에서 안착하기로 선택한 것은 인터넷/클라우드 측 추론 배포 경로가 중국 국내 칩 제조사에 여전히 매력적임을 보여준다. 다모원 쉬안톄의 정적 그래프 수정과 PPU 전달 라인의 0.7.0 편입은, RISC-V 맥락에서 가장 대표적인 컴퓨팅 백엔드로서 FlagOS의 전달 매트릭스 내에서 정규 위치의 업데이트 리듬을 유지하고 있음을 보여준다.

3.5 즈위안(주도 기관): 전달 파이프라인 버전 통일과 패키징 정책 두 가지 거버넌스 조치(09-10)

출처: FlagTree #1151, build-infra #812, release-info

  • 주도 기관의 이번 모니터링 기간 조치는 기능이 아니라 거버넌스에 집중되었다. FlagTree의 29개 제조사 전달 워크플로 버전 번호를 통일하고(커뮤니티 측 유지관리자가 커밋), 패키징 채널 경계를 중영 이중 언어 문서 정책으로 작성했다.
  • 릴리스 목록 저장소 release-info는 모니터링 기간 내 내용 갱신이 없었다(여전히 초기 README만 존재). 이는 2.2의 공식 릴리스 목록이 아직 확정되지 않았음을 의미한다.

해석: 세 가지 정보를 종합하면, 2.2 GA(일정은 09-28) 이전 준비의 중심이 “기능과 적응”에서 “전달 기준과 설치 채널”로 이동했음을 알 수 있다. 버전 번호는 십여 개 제조사의 전달 라인을 정렬해야 하고, 의존성 출처는 정책적 근거가 있어야 하며, 릴리스 목록은 모든 아티팩트를 한 번에 명확히 설명할 수 있어야 한다. 이런 작업은 외부에 보이지 않지만, GA 당일 재현 가능한 전달 면을 제시할 수 있는지를 직접 좌우한다.

4. 요약

이번 모니터링 기간(09-10 10:18 ~ 09-11 10:18) GitHub 측은 모니터링 기간 내 커밋 61건, 푸시가 있는 저장소 13개로, 엔지니어링 측은 높은 수준의 활약을 유지했다. 뉴스 측 컴포넌트급 검색은 아홉 번째 연속평온 모니터링 기간으로, 외부 보도는 0건이며 모든 정보는 코드 저장소에서 나왔다. 네 가지 주요 흐름:

  1. FlagTree 0.7.0이 전달 수렴기에 진입(이번 모니터링 기간 가장 중요한 변화): 메인 라인 버전 번호가 0.6.0에서 0.7.0으로 올라갔고, 29개 제조사 전달 워크플로의 버전 입력 파라미터를 일괄 0.7.0으로 전환했다. NVIDIA의 여섯 개 triton 라인(TileIR 및 특수 형태 포함), AMD, Ascend, Enflame, Iluvatar CoreX, MetaX, Moore Threads, Tsingmicro, Sunrise, Kunlunxin XPU, HCU, AIPU, Thrive, PPU 등을 포함한다. rc0/rc1 3단계 브랜치(triton 3.3/3.5/3.6)는 이전에 이미 자리 잡았고, 공식 release tag는 아직 발표되지 않았다. 이는 2.2 RC 기간의 버전 수렴이 마지막 단계에 도달했음을 의미한다.
  2. Ascend 910C가 “base → app” 2단계 안착을 완료, sglang이 1급 애플리케이션 라인으로 승격: 910C의 runtime 이미지 빌드 푸시 후, vllm 애플리케이션 라인이 CANN 8.5.0과 9.0.0 두 가지 910C 라인에서 개방되었으며(vLLM 0.20.2와 0.24.0 네 개 애플리케이션 항목 포함), 아홉 가지 verify/템플릿/의존성 안정화 수정을 보완했다. 동시에 최소 10개 칩 라인의 sglang0.5.18에 대한 실행 문서와 changelog를 생성했으며, 추론 프레임워크 매트릭스가 “vllm 전체, sglang 산발적”에서 두 라인 병행으로 바뀌었다.
  3. 외부 및 비회원 제조사가 계속 투자를 확대: 쉬왕 Sunrise가 컴포넌트급 백엔드 안착을 완료(runner 환경에서 vLLM 0.24.0의 vendor 백엔드로 진전), Kunlunxin XPU와 Hygon DCU의 이중 백엔드가 FlagTensor에 병합, Tsingmicro가 신규 tsingmicro3.6 양방향 CI/CD를 추가하고 LLVM 22와 Triton 3.6에 정렬했다. 신규 칩 접속의 표준 경로(환경 선행 → 플러그인 백엔드 → 전달 라인 편입)가 복제 가능함이 검증되었다.
  4. RC 기간 규율이 엔지니어링 세부 사항에서 반복적으로 나타남: TLE NVIDIA의 레이아웃 최적화가 당일 병합 당일 롤백, FlagGems가 MetaX 잔여 CI 항목 제거, 설치 하위 패키지 무결성 수정, 패키징 채널 정책 문서화 — 동결기의 조치는 “정확성과 기준을 수정하고, 신규 기능은 넣지 않는다”이며, 당일 롤백과 설치 면 수정은 이 규율의 가장 직접적인 증거다.

예측: 향후 관찰 포인트 네 가지—첫째, 910C의 첫 번째 app image tag가 언제 registry 기록에 진입하고 status matrix의 “검증됨” 열에 나타나는지(이는 910C 딜리버리 사용 가능의 최종 표지이다); 둘째, FlagTree 0.7.0의 정식 release tag와 build-infra의 flagtree pin이 언제 뒤따를지(현재 NVIDIA 라인은 여전히 0.6.1에 pin되어 있어 한 버전의 어긋남이 존재한다); 셋째, 2.2 GA(09-28) 전의 rc1.postN 증분 리듬과 community/release-info 목록 조치; 넷째, Xiwang의 연동 경로가 vllm에서 sglang 라인으로 확장될지, 그리고 Kunlunxin이 공개 멤버 명단에 포함될지 여부이다.

한계 설명: 본 모니터링 기간의 전체 항목은 GitHub 커밋, 워크플로 파일 및 패치 내용에서 비롯되었다; 뉴스 측은 아홉 번째 연속 평온 기간으로, 독립적으로 교차 검증 가능한 제3자 보도가 없기에 “버전 수렴” “딜리버리 사용 가능화” 류의 판단은 모두 커밋 본문과 파일 변경을 기준으로 하였으며, 제3자 전언은 채택하지 않았다. Google News 중영문 13개 쿼리 전부 무적중, HN 적중은 부분 문자열 오매칭으로, 모두 부록에그대로 기록하였다.

부록: 전체 출처 목록

출처 검증 결과
GitHub org repos API(flagos-ai, 53개 저장소, pushed 기준 정렬) 13개 저장소가 모니터링 기간 내 푸시: build-infra(09-11 10:06), FlagTree(09-11 10:05), FlagBLAS(09-11 10:14, 기본 브랜치에 모니터링 기간 내 커밋 없음, 브랜치 작업으로 판정), vllm-plugin-FL, FlagGems, FlagGems-vllm, FlagDNN, Torch-FL, flir, FlagFFT, FlagCX, FlagTensor, Megatron-LM-FL; 신규 저장소 없음(최신 생성 저장소는 08-15)
GitHub commit search(org 전체, committer-date > 2026-09-10T02:18Z, 단일 페이지 60건 전체) committer 시간과 저장소 귀속을 건별 검증: build-infra 24 / FlagGems 10 / FlagTree 8 / FlagTensor 5 / vllm-plugin-FL 3 / FlagDNN 3 / FlagGems-vllm 2 / Torch-FL 2 / flir 1 / FlagFFT 1 / FlagCX 1
GitHub per-repo commits 재확인(Megatron-LM-FL, FlagBLAS, FlagGems-Experimental) Megatron-LM-FL #148(09-10 10:47)이 모니터링 기간에 포함됨, search 인덱스 지연으로 미수록, 추가 반영; FlagBLAS 기본 브랜치 최신 커밋은 09-09(모니터링 기간 외), 모니터링 기간 내 푸시는 브랜치에서 발생; FlagGems-Experimental 최신 커밋 09-10 09:11(모니터링 기간 외)
GitHub 브랜치 API(FlagTree) 0.7.0-rc0-triton3.3/3.5/3.6 헤드 시간 08-11 / 08-27 / 08-31; 0.7.0-rc1-triton3.3/3.5/3.6은 09-01 / 09-04 / 09-04(rc1-triton3.6 헤드가 곧 Tsingmicro 백엔드 통합 #1071)
GitHub commit 상세 및 패치 #1151 총 29개 딜리버리 워크플로 파일, 기본 버전 ‘0.6.0’ → ‘0.7.0’(커미터 zhengyang@baai.ac.cn); #816(273행, 4개 910C vllm changelog + status matrix); #831(2896행, sglang0.5.18 기동 문서 매트릭스); #1118(354행, Tsingmicro build-and-test + delivery); FlagTensor 백엔드 병합(4225행 / 4393행); vllm-plugin-FL #391(sunrise, 대상 TANGRT 1.2.0); FlagGems-vllm #736(Hygon op 325행); Torch-FL #270(658행, DCU 라우팅 벤치마크 문서 포함); FlagCX #576(MUSA PAL)
GitHub tags / releases API 이번 모니터링 기간 내 신규 release 없음. 최신 앵커: FlagGems v5.4.0-rc1.post1, FlagTree 0.6.0+triton3.x(Releases) / 딜리버리 라인은 0.7.0으로 전환, FlagCX v0.14.0-rc1.post1, FlagGems-vllm v0.2.0-rc1.post1, vllm-plugin-FL v0.3.0-rc1.post1, FlagBLAS v0.3.0-rc1.post1, FlagTensor v0.3.0-rc1.post1, FlagDNN v0.3.0-rc1.post1, FlagFFT v0.2.0-rc1.post1, Torch-FL v0.2.0-rc1.post1, FlagOS-Robo v0.1.0
raw.githubusercontent(FlagTree / vllm-plugin-FL / build-infra / flir의 README 및 configs.yaml) FlagTree 벤더 표에 NVIDIA(TileIR 포함), AMD, Enflame, Iluvatar CoreX, Hygon, Moore Threads, Damo Academy, Huixi Intelligence, MetaX, Xiwang, Kunlun Core, Damo Academy T-Head, Jindie SpaceTime, Tsingmicro 포함; vllm-plugin-FL 벤더 표에 Sunrise(Supported) 포함; build-infra configs.yaml의 NVIDIA 라인은 여전히 flagtree==0.6.1 pin, sunrise / tsingmicro / kunlun / hygon / mthreads / iluvatar / cambricon / metax / enflame 키 포함; flir는 FlagTree IR 중간 계층(triton-shared에서 fork)
Google News RSS(중영문 13개 쿼리어, 프록시 경유) 컴포넌트 레벨 쿼리 전부 제로 히트(아홉 번째 연속 평온 모니터링 기간); 멤버사 키워드 히트는 JD Cloud 십만 카드 클러스터
재전송, 주가/락업 해제 관련 및 도박 SEO 원고는 기존 기준에 따라 기술 항목에 포함하지 않음    
  HN Algolia(FlagOS / FlagGems / FlagTree / FlagScale / BAAI) 전부 flags/flagship/flocked 부분 문자열 오매칭된 무관 항목으로, 전체 배치 제거
  FlagOS 공식 CSDN 계정(flagos.csdn.net) 모니터링 기간 내 신규 글 없음, 최신은 여전히 08-28의 GLM-5.3-Flash Day0 9개 칩 적응; 09-07 KubeCon 동일 행사 포럼 페이지와 연산자 튜닝 주제 페이지는 게시 시점 업데이트 없음
  Zhiyuan 커뮤니티(hub.baai.ac.cn) 모니터링 기간 내 적중 항목은 커뮤니티 일반 콘텐츠(체화 지능, AI 거버넌스 등)로, FlagOS 기술 스택과 직접적 연관 없음
  Tavily / web 검색 XiWangXinKe 배경 검증(공식 웹사이트, QuantumBit, TMTPost 3개 출처); FlagOS 버전 주기 역사 기준점 검증(Zhongzhi FlagOS 1.6 / 1.5 공식 보도자료)