모니터링 기간: 2026-10-28 06:00 ~ 2026-10-29 06:00 (베이징 시간, 24시간; 목요일 조간, 모니터링 기간은 직전 데일리 리포트 마감 시점부터 연속).

출처: GitHub (org: flagos-ai 61개 저장소 전수 점검, 커밋 검색 99건, 병합 PR 67건 및 심사 중 PR 288건 검색, org 이벤트 스트림 100건, 31개 저장소 Release/Tag 원자적 점검, 7개 저장소 원자적 보충 점검, 주요 PR 본문 및 산출물 규모 점검), Google News RSS (중영문 쿼리어 24개 조합, 프록시 경유), HN Algolia (8개 조합), CSDN FlagOS 칼럼, Zhiyuan 커뮤니티, 8개 회원사 공식 웹사이트 (상세 내용은 부록 출처 목록 참조).

금일 인덱스

  • 오늘의 핵심: Horizon Robotics BPU가 eager 연산자 백엔드로 연결; FlagCX가 v0.14.1 태그를 찍고 3개사 rpm 백엔드를 보완; Moore Threads가 Megatron-MUSA-Titan 오픈소스 공개 (10-28)
    1. 오픈소스 프로젝트 진척 (GitHub 동향)
      • 1.1 조직 리듬: 23개 저장소 푸시, 99건 커밋, 67건 병합, 심사 중 288건으로 감소 (10-28 ~ 10-29)
      • 1.2 버전 측면: FlagCX가 v0.14.1 태그, 디바이스 비트코드를 어댑터별 생성으로 변경 (10-28)
      • 1.3 FlagGems: Kunlunxin 스칼라 체인 융합 10배 속도 향상, Enflame 참조 구현 일괄 수정 심사 중 (10-28)
      • 1.4 FlagGems-sglang: AMD gfx1100 Mamba 연산자 보충, Enflame core_shapes 실제 적용 (10-28)
      • 1.5 컴파일러: FlagPrism Enflame 연결, Ascend TensorView 가져오기/저장 감소, FlagMega RDNA 디코딩 속도 향상 (10-28)
      • 1.6 추론 및 학습 스택: Enflame Qwen3.5 FP8 GCU 적용, 융합 All-Reduce RMSNorm FlagGems-vllm 진입 (10-28)
      • 1.7 빌드 및 릴리스: changelog 사이트 및 Harbor 게시, 한 번도 푸시되지 않은 Cambricon 이미지 2건 철회 (10-28)
      • 1.8 규칙 측면: FEP-0140 Implementable로 전환, FEP-0141 SGLang 0.5.18로 범위 축소 (10-28)
      • 1.9 기타 저장소: optest Enflame CI 연결, FlagTensor Ascend 상주 그리드, FlagQuantum 비트 일관성 (10-28)
    1. 뉴스 보도 및 생태계
      • 2.1 보도 측면: Moore Threads Megatron-MUSA-Titan 오픈소스 공개, 24개 조합 중 유효한 것은 이 한 건뿐 (10-28)
      • 2.2 채널 및 공식 웹사이트: CSDN 여전히 10-22에 정지, HN 및 Zhiyuan 커뮤니티 신규 히트 없음 (10-28)
    1. 회원사 및 백엔드 벤더 심층 분석
      • 3.1 Horizon Robotics: BPU 최초로 연산자 단위 실행 가능한 PrivateUse1 백엔드로 등극 (10-28)
      • 3.2 Kunlunxin: 스칼라 체인 융합 및 연속 세그먼트 커널, P800에서 세 곳 속도 향상 (10-28)
      • 3.3 Iluvatar CoreX: 컨볼루션 워크로드 등급 테이블 적용, conv3d 채널 제로 패딩 제거 (10-28)
      • 3.4 Enflame: Qwen3.5 FP8 GCU 적용, core_shapes 반영, FlagPrism 최초 연결 (10-28)
      • 3.5 Damo XuanTie: PPU의 MiniMax 희소 어텐션, 기하평균 1.8배 (10-28)
      • 3.6 Tsingmicro, Xiwang, Hygon: FlagCX rpm 패키징 3개 백엔드 보완 (10-28)
      • 3.7 Moore Threads: Megatron-MUSA-Titan 오픈소스 공개와 3분기 보고서 같은 날 (10-28)
    1. 요약 및 트렌드 관찰
  • 부록: 출처 점검표 및 전체 출처 목록

오늘의 핵심: Horizon Robotics BPU가 eager 연산자 백엔드로 연결; FlagCX가 v0.14.1 태그를 찍고 3개사 rpm 백엔드를 보완; Moore Threads가 Megatron-MUSA-Titan 오픈소스 공개 (10-28)

날짜: 2026-10-28　출처: Torch-FL PR #674 · FlagCX tag v0.14.1 · FlagCX PR #673 · IT之家 보도 · Megatron-MUSA-Titan 저장소 (전체 내용은 부록 참조)

  • 새 백엔드 측면: Torch-FL에 Horizon Robotics BPU의 연산자별 실행 계층이 병합되었다(#674, 31개 파일, 5698줄 추가 145줄 삭제). 기존에 BPU는 PrivateUse1에서 어떤 계산 연산자도 등록하지 않았다—hbDNNInferV2는 이미 컴파일된 전체 그래프만 받아들이므로, 모든 aten 호출이 cpu_fallback으로 떨어졌고 backends_bpu.conf는 비어 있었다. 이번 커밋은 누락된 중간 계층을 보완한다: 보드 외부의 x86 측에서 hbdk4로 단일 연산자 .hbm 산출물 라이브러리를 컴파일하고, 이 산출물을 제출하는 C++ 커널을 생성하며, drobotics conf 라우팅을 추가한다. 40개의 요소별 연산자(32개 단항, 8개 이항), 11개의 형상 버킷을 포괄하며, RDK S600에서 440개 산출물을 NumPy와 비교하여 차이 없음을 확인했다.
  • 버전 측면: FlagCX가 10-28 17:25에 v0.14.1 태그를 생성했다(commit 7ed4a82, 제목은 “어댑터별 디바이스 비트코드 생성, 더 이상 NVIDIA 하드코딩 안 함”, 즉 10-18에 병합된 #668). 해당 태그는 git tag만 있을 뿐 GitHub Release 본문이 없으며, 이전 버전 v0.14.0의 정식 Release는 9-28에 멈춰 있다. 같은 아카이브에서 v0.15.0.dev0 태그도 보인다(이 모니터링 기간 이전). 같은 기간에 0.14.0-rc2 라인을 위한 분산식 패치가 진행 중이다(#683, 심사 중).
  • 패키징 측면: FlagCX의 rpm 라인이 세 백엔드에서 여섯 개로 확장되었다(#673, 10개 파일, 295줄 추가 8줄 삭제). 새로 추가된 libflagcx-tsm(Tsingsemi), libflagcx-sunrise(Sunrise), libflagcx-du(Hygon DCU) 세 곳 모두 벤더 기본 이미지를 필요로 하지 않는다—SDK를 /opt 또는 /usr/local에 압축 해제하고 패키지 관리자를 호출하지 않으므로, openEuler 이미지에 파일 저장소만 더하면 완전한 빌드 환경이 된다; 벤더 soname은 Ascend의 기존 기준에 따라 통일적으로 필터링한다.
  • 뉴스 측면: Moore Threads가 10-28에 대규모 모델 훈련 인프라 Megatron-MUSA-Titan을 오픈소스로 공개한다고 발표했으며, 만 카드급 클러스터의 조 단위 파라미터 MoE 훈련에 초점을 맞추고 사전 훈련과 강화 학습을 포괄한다; 이미 자사의 만 카드 클러스터 사전 훈련에서 지속적으로 사용 중이며, blockwise FP8을 지원하고 DeepEP와 ACE 비동기 통신을 결합하여 전문가 병렬과 계산 중첩을 구현하며, slime, miles 강화 학습 프레임워크와 협력할 수 있다. 저장소 MooreThreads/Megatron-MUSA-Titan은 GitHub에 존재하지만 이 모니터링 기간 내에 푸시가 없다(마지막 푸시 10-16), “오픈소스 발표, 코드 미변동” 상태이다.
  • 판단: 세 라인이 각각 한 계층씩 전진한다—새 칩을 eager 경로에 연결(BPU), 통신 라이브러리의 제공 면을 소스 트리에서 태그와 배포 패키지로 확장(FlagCX), 훈련 스택의 오픈소스 서사를 FlagOS에서 멤버 기관 자체 개발 프로젝트로 확장(Megatron-MUSA-Titan). 이 스택과 직접 관련된 것은 처음 두 가지이며; 세 번째는 그 코드가 FlagOS가 재사용 가능한 훈련 컴포넌트로 환류되는지 관찰해야 한다.

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

1.1 조직 리듬: 23개 저장소 푸시, 99건 커밋, 67건 병합, 심사 중 288건으로 감소(10-28 ~ 10-29)

날짜: 2026-10-28 ~ 2026-10-29　출처: flagos-ai 조직 저장소 · 커밋 검색 · 병합 PR 검색 · 심사 중 PR 검색

  • 저장소 측면: 61개 저장소 중 23개 저장소에 모니터링 기간 내 푸시가 있었으며, 이는 최근 2주 중 가장 많은 수치(이전 기간 20개 저장소). 푸시 시간 기준 최근 순으로 docs, Trident, FlagQAI, Torch-FL, build-infra, FlagGems, FlagCX, FlagTree, release-info, FlagFFT, FlagGems-sglang, FlagQuantum, optest, FlagDNN, vllm-plugin-FL, FlagTrain, community, FlagGems-vllm, FlagAttention, sglang-plugin-FL, TransformerEngine-FL, FlagTensor, FlagGems-Experimental.
  • 커밋 측면: 커밋 검색 99건 적중, 저장소별로 FlagQuantum 33, FlagGems-sglang 17, FlagGems 10, build-infra 6, optest 5, FlagGems-vllm 5, Torch-FL 4, FlagTree 4, FlagCX 3, community 3, FlagTensor 3, FlagDNN 2, sglang-plugin-FL, vllm-plugin-FL, FlagTrain, FlagAttention 각 1.
  • 병합 측면: PR 병합 67건, 저장소별로 FlagGems 13, FlagGems-sglang 8, FlagTree 7, build-infra 6, FlagQuantum 6, optest 5, FlagGems-vllm 5, Torch-FL 4, FlagCX 3, community 3, vllm-plugin-FL 2, FlagTrain, FlagAttention, sglang-plugin-FL, TransformerEngine-FL, FlagTensor 각 1.
  • 리뷰 중 측면: 모니터링 기간 내 업데이트된 리뷰 중 PR 288건, 신규 101건. FlagGems 181건(신규 53), FlagTree 21건(신규 9), FlagGems-vllm 20건(신규 9), vllm-plugin-FL 12(4), FlagCX 8(2), FlagTrain 7(2), Torch-FL 6(5), sglang-plugin-FL 5(2), Trident 3(3), flir 3(1), FlagAttention 3(1), Megatron-LM-FL 3(0), FlagGems-sglang 3(3), TransformerEngine-FL 3(1), 나머지 각 저장소 1~2건.
  • 리듬 비교: 이전 24시간 모니터링 기간(20개 저장소, 102건 커밋, 98건 병합, 401건 리뷰 중, 269건 신규)과 비교하여 푸시 저장소 3개 증가, 커밋 거의 동일, 병합 32% 감소, 리뷰 중 28% 감소, 신규 62% 감소. 이전 기간 리뷰 중 급증은 FlagGems-Experimental의 일회성 135건 대량 커밋에서 비롯되었으며, 이번 기간 해당 저장소는 신규도 병합도 없어 리뷰 중이 정상 범위로 회귀.
  • 버전 및 이벤트 측면: 31개 저장소 Release 및 Tag 원자 검증, 모니터링 기간 내 신규 태그 1개(FlagCX v0.14.1); build-infra 최신 태그는 여전히 8월 3일의 v2.2.0. org 이벤트 스트림 100건: 푸시 51, 브랜치 생성 32, 브랜치 삭제 9, PR 리뷰 및 리뷰 코멘트 8, PR 개설/폐쇄 이벤트 없음—이벤트 구성은 브랜치 활동 위주로, FlagGems 측의 다수 fix/suiyuan-*, fix/blocked581-* 임시 브랜치 생성 및 삭제와 일치.
  • 브랜치 측면: 커밋 검색이 커버하지 못한 7개 푸시 저장소는 원자 보충 검증 필요. TransformerEngine-FL은 commits.atom으로 확인한 결과 모니터링 기간 내 커밋 1건(#150, 10-28 16:33); FlagFFT와 release-info는 비기본 브랜치 푸시(FlagFFT 측은 codex/musa-shortfall, codex/cuda-2d3d-opt); FlagGems-Experimental의 푸시는 dependabot 브랜치에서 비롯; docs, FlagQAI, Trident 세 저장소의 푸시는 모두 기능 브랜치에 있으며 기본 브랜치에는 신규 커밋 없음.

1.2 버전 측면: FlagCX v0.14.1 릴리스, 디바이스 비트코드를 어댑터별 생성으로 변경(10-28)

날짜: 2026-10-28　출처: FlagCX tags · FlagCX v0.14.1 태그 · FlagCX PR #668 · FlagCX PR #683 · build-infra PR #1546

  • 태그 사실: v0.14.1은 10-28 17:25에 생성되었으며, commit 7ed4a82를 가리키고, 커밋 제목은 「어댑터별로 디바이스 비트코드를 생성하고 더 이상 NVIDIA를 하드코딩하지 않음」(#668, 10-18 병합)이다. Releases API를 조회하면 해당 태그에 대해 404가 반환되는데, 이는 git 태그일 뿐 GitHub Release가 생성되지 않았음을 의미하므로 릴리스 노트 본문이 없다. 이전 버전 v0.14.0의 공식 Release는 여전히 9-28에 있으며, 본문은 FlagOS 2.2 릴리스 목록을 가리킨다.
  • 내용 측면: #668은 setup.py 비트코드 단계에서 하드코딩된 bindings/ir/nvidia를 어댑터별 조회 테이블(BITCODE_MAKEFILES)로 교체하여, 각 어댑터가 자체 Makefile과 아키텍처 변수를 선언하도록 한다. 이전에는 모든 비NVIDIA 어댑터가 RuntimeError를 발생시키거나 조용히 비트코드를 생성하지 못했으며, FlagTree의 iluvatar 백엔드는 FlagCX 소스 코드를 복사하여 자체적으로 다시 컴파일할 수밖에 없어 FlagCX가 마땅히 생성해야 할 비트코드를 소비할 수 없었다.
  • 부속 측면: build-infra는 봇이 flagcx wheel의 릴리스를 기록하며(#1546), wheel 전달을 태그, 패키징 라인과 하나로 연결한다. 같은 모니터링 기간에 열린 #683은 쿤룬싱의 cstddef 수정을 0.14.0-rc2 라인으로 백포트하며(심사 중), 이는 0.14 시리즈가 여전히 지원 모니터링 기간 내에 있음을 보여준다.
  • 관찰 필요: v0.14.1에는 Release 본문이 없어 v0.14.0의 「본문이 릴리스 목록을 가리킴」 방식과 일치하지 않는다. 만약 이후 2.3 주기가 v0.14.x로 전달된다면, 다운스트림이 태그만으로 내용을 추측하지 않도록 설명을 보충할 것을 권장한다.

1.3 FlagGems: 쿤룬싱 스칼라 체인 융합 10배 속도 향상, Enflame 참조 구현 일괄 수정 심사 중 (10-28)

날짜: 2026-10-28　출처: FlagGems PR #7617 · FlagGems PR #7600 · FlagGems PR #7850 · FlagGems PR #7803 · FlagGems PR #7036 · FlagGems PR #7061 · FlagGems PR #7223

  • 융합 커널: 쿤룬칩 XPU3 측에서 8개의 출위(out-of-place) 스칼라 체인 연산자에 백엔드 특화를 추가했습니다(#7617, 275줄). 동형 float 리스트는 하나의 융합 커널로 처리됩니다. 작은 형상은 단일 발사로 모든 포인터를 커널 파라미터로 넘겨 처리하고, 큰 형상은 스트리밍 청크 방식으로 처리합니다. 출력은 텐서마다 할당기를 한 번씩 호출하는 대신 한 번의 할당에 unbind를 적용해 얻습니다. 8개 연산자의 상대 소요 시간은 0.083~0.126에서 0.813~0.934로 향상되어 약 7~10배가 되었습니다.
  • 연속 구간 커널: batch-norm 추론과 QKV 변환 두 연산자를 「(n,c) 슬라이스마다 하나의 program」에서 「program마다 연속 BLOCK 원소 한 구간을 처리하고 플랫 인덱스로부터 채널 또는 패킹 행을 역산」하는 방식으로 변경했습니다(#7600). 집계 지표는 각각 0.228에서 1.357로, 0.260에서 5.062로 향상되었습니다. fp32 단정밀도 칸은 여전히 0.8 미만이며, 작성자는 집계 기준으로 판정했음을 본문에 명시했습니다.
  • 벡터화 수정: masked_fill의 정수 뷰 고속 경로는 arith.extsi에 벡터 형식이 없어 전체 커널이 스칼라로 남아 있었습니다(fp16 0.34, fp32 0.50). 이를 x*(1-m)+V*m의 f32 형식으로 재작성한 후 P800에서 0.577에서 0.829로 향상되었고, masked_fill_, masked_fill_scalar도 함께 개선되었으며 594개 테스트 케이스가 통과했습니다(#7850).
  • 임포트와 실행기: 쿤룬칩 백엔드가 master 최신 커밋에서 임포트 단계부터 실패했습니다. _result_dtype 헬퍼가 #7561과 함께 공유 실행기에서 제거되었는데 백엔드가 여전히 참조하고 있었습니다(#7803, 90줄). 임포트를 수정한 후 공유 실행기에서 다시 operand #0 does not dominate this use 오류가 발생했으며 이번 커밋에서 함께 수정했습니다.
  • 연산자 커버리지: KernelGen에 _indices_copy를 추가했으나(#7223, 250줄, H20 검증) 성능은 torch의 0.21배에 불과합니다. 커버리지 보완의 산물이며 단기적으로 가속 항목으로 볼 수는 없습니다. lighting_indexer의 참조 구현을 헤드별 누적으로 변경하여 피크 메모리를 약 8.6 GiB에서 낮추고 40 GiB 카드에서의 OOM을 해결했습니다(#5852).
  • 검토 중 측면: 이번 모니터링 기간에 신규 53건이 열렸으며, 대부분은 lukatao의 Enflame 참조 구현 수정입니다(#7890부터 #7908까지 연번). Kaiser/inplace ldexp, aminmax, special_round, LU, vander/slogdet, median/stacking/Lanczos, Adagrad, batch-norm ABI 등이 포함됩니다. 그 외 AMD 측 한 줄 수정(#7908)이 있습니다. AMD의 벤더 디스크립터가 디바이스 이름을 cuda로 설정하고 triton_extra_name을 제공하지 않아 pow, tanh, exp, rsqrt, erf, gelu 등이 모두 __nv_*를 거쳐 AMD 백엔드에서 거부되었습니다.

1.4 FlagGems-sglang: AMD gfx1100 Mamba 연산자 보완, Enflame core_shapes 실효화(10-28)

날짜: 2026-10-28　출처: FlagGems-sglang PR #231 · PR #232 · PR #229 · PR #233 · PR #237 · PR #236

  • AMD 측: RDNA3 등급을 위해 causal_conv1d_fn, chunk_state_varlen, bmm_chunk 세 가지 gfx1100 버전을 추가했으며(#231, 578줄), Radeon PRO W7900D에서 튜닝 및 테스트를 진행했습니다. 세 가지 모두 런치 파라미터만 변경했고 출력은 범용 커널과 비트 단위로 일치합니다. 타임 슬라이스는 고정 128 token×4 채널이 아니라 가장 긴 시퀀스를 따르며, dstate 128 이상에서는 더 작은 tile과 16 token의 K 스텝을 사용합니다.
  • Enflame 측: #229에서 _enflame/core_shapes.yaml을 추가했지만 저장소 내 어떤 코드도 이를 로드하지 않습니다——init_user_config()에는 하드코딩된 kunlunxin 분기만 있습니다(#232의 근본 원인 분석). #232는 형태 파일 조회를 「vendor_name으로부터 _<vendor>/core_shapes.yaml을 도출하고, 존재하면 사용하며 그렇지 않으면 공유 기본값으로 폴백」하는 방식으로 일반화했고, 겸사겸사 kunlunxin 경로가 무조건 설정되어 파일이 없으면 FileNotFound가 발생하는 잠재 문제도 수정했습니다.
  • 테스트 인프라: 후보 주입이 정확성 테스트와 벤치마크 사이에서 통일되었으며(#233, 9개 파일), 독립 벤치마크 세션은 이전에 --override를 등록하지 않았고 후보 전용 모드는 존재하지 않는 레지스트리 메서드를 호출했습니다. get_override()는 실제 후보를 노출하며, 일반 타이밍·사전 점검·프로파일링이 동일한 파서를 공유합니다. 또한 케이스별 dummy 후보 호출 검증(#237)과 패키지 수준 임포트 수정(#236, sys.modules 충돌 방지)을 추가했습니다.
  • 케이스 열거: silu 벤치마크는 텐서 없이 케이스를 열거하고 정확히 재생하는 것을 지원하며(#234), --list-cases는 238건 머지의 마무리로 페이지네이션됩니다.
  • 판단: 이 저장소는 이번 모니터링 기간에 17건의 커밋, 8건의 머지를 기록했으며, 모두 「벤더 형태 테이블과 후보 주입이 멀티 백엔드에서 동일한 체계로 말하게 하기」를 중심으로 하고 있어 새로운 연산자가 아닌 테스트 기준의 수렴에 해당합니다.

1.5 컴파일러: FlagPrism, Enflame 연동, Ascend TensorView 로드/스토어 감소, FlagMega RDNA 디코딩 가속(10-28)

날짜: 2026-10-28　출처: FlagTree PR #1239 · FlagTree PR #1426 · FlagTree PR #1439 · FlagTree PR #1456 · FlagTree PR #1454 · flir PR #86

  • 프로파일링 및 디버깅: FlagPrism의 디버거와 프로파일러를 Enflame 백엔드로 확장(#1239, 5개 파일, 119줄 추가 31줄 삭제). CMake와 Python 측에서 Enflame을 지원 목록에 추가하고 기본 활성화하며, 명시적 비활성화 항목과 Proton과의 상호 배제를 유지. 런타임에서는 디버그가 포함된 커널 런치를 FlagPrism 게이트웨이로 우회시키고, 메타데이터 캡처와 숨겨진 제어 버퍼 파라미터를 분리 처리하며, 일반 실행은 여전히 직접 전송 경로를 사용.
  • IR 및 로드/스토어: Ascend 백엔드에 TensorView 접근 경로 연결(#1426, 32개 파일, 4901줄 추가, triton_v3.5.x 브랜치에 병합). 커널은 세 가지 명시적 생성자로 기본 포인터 위에 인코딩 뷰를 구축한 뒤 인덱스에 따라 블록 단위로 로드/스토어. 경계를 벗어난 채널은 zero/nan/inf/-inf로 값을 채우거나 폐기하며, 백엔드는 CommonIR에서 HIVM 사이에서 인덱스 패턴에 따라 「인덱스별 페이로드 DMA」 또는 「원소별 제로 패딩 전송」을 선택.
  • AMD 디코딩: FlagMega 측에서 Qwen3-1.7B bf16용 batch-1 디코딩 최적화 수행(#1439, 44개 파일, feature/flagmega 브랜치에 병합). R9700(gfx1201)은 컨텍스트 1에서 154 tok/s, 1K에서 150, 4K에서 139, 8K에서 125; W7900(gfx1100)은 각각 167, 162, 149, 136 tok/s, 실측 대역폭 530~597 GB/s로 해당 카드의 실측 스트리밍 상한의 82%~87%에 도달.
  • 정확성: AMD 백엔드의 CanonicalizePointers가 더 이상 단언하지 않고 arith.select의 fat-pointer 속성을 병합하도록 변경(#1456); RLC 측에서는 레이아웃 변경이 불법이거나 안전하지 않은 producer에 더 이상 재라벨링하지 않음(#1454).
  • CI 및 심사 중: FlagGems의 CI 자산을 FlagTree로 이전(#1443, #1447); 심사 중 신규 9건 오픈, 포함: Tsingmicro 백엔드를 내부 Triton 3.6 개발 라인에 동기화(#1459, 27개 파일, 2264줄 추가, 발사별 정밀도 API 및 CoreIR 진입점 포함), rpm 라인을 이미 릴리스된 wheel 소비로 전환하여 Ascend 패키지 빌드(#1461, 최초로 벤더 SDK와 하드웨어 불필요한 라인), NVIDIA Hopper에서 4건의 소프트웨어 파이프라인 결함 수정(#1460, cp.async에 축출 정책 적용 시 ptxas 12.8~13.1에서 정의되지 않은 주소 디스크립터가 남는 문제), Ascend 구조적 순열 및 상주 루프 성능(#1466), P800 SDNN의 1차원 모듈로 로드(#1465), flir의 Ascend split/join 및 정적 순열 하강(#86).

1.6 추론 및 학습 스택: Enflame Qwen3.5 FP8 GCU 탑재, 융합 All-Reduce RMSNorm FlagGems-vllm 진입(10-28)

날짜: 2026-10-28　출처: vllm-plugin-FL PR #358 · PR #525 · FlagGems-vllm PR #773 · PR #1017 · TransformerEngine-FL PR #150

  • Enflame 추론: GCU 백엔드에 Qwen3.5 FP8 지원 추가(#358, 20개 파일 3367줄 추가, release/0.2 기반). W8A8 블록 스케일링 FP8 추론을 도입하고 GCU300/GCU400의 하드웨어 제약에 맞춰 커널 패치를 재작업하여 FP8 MoE 모델이 eager 및 전체 그래프 두 모드 모두에서 동작하도록 함.
  • 통신 배선: vLLM 플러그인이 설치된 패키지에서 FlagCX를 가져오도록 변경(#525, 11개 파일). flagcx wheel은 ctypes 파사드를 flagcx.api로 설치하고 libflagcx.so를 패키지 내 lib/에 배치하는데, wheel만 설치된 환경에는 FLAGCX_PATH가 가리킬 소스 트리가 없음. 이번 커밋은 flagcx.api를 우선 import로, FLAGCX_PATH 래퍼를 폴백으로 사용하며 호출 지점 세 곳(flagcx.py, flagcx_connector.py, sunrise/patch.py)을 동시에 수정.
  • 연산자 계층: FlagGems-vllm에 융합 전체-리듀스 RMSNorm 추가(#773, 6개 파일 3191줄 추가): all-reduce + 잔차 덧셈 + RMSNorm, 선택적 정적 양자화(FP8, SM100+는 NVFP4 지원), TP2/TP4/TP8의 FP16/BF16 지원, vLLM FlashInfer 구현과의 비교 벤치마크 및 GLM-5.2 대표 형상 포함. ihc_pre의 stage1 병합은 tl.atomic_add를 split 슬롯별 쓰기로 교체(#1017) — 원자적 덧셈은 결과가 블록 도착 순서에 의존하고 중복 발사 시 비트 단위로 일치하지 않았으나, 변경 후 결정성이 복원됨.
  • 의존성과 회귀: TransformerEngine-FL이 3rdparty/ 세 서브모듈을 업스트림 v2.17의 검증 베이스라인으로 롤백(#150): #129에서 실수로 cutlass를 240개 커밋 앞으로 전진시키고(4000+ 파일 영향), cudnn-frontend를 v1.25.0에서 미출시 스냅샷으로, googletest를 v1.14.0에서 master 헤드로 전진시킴.
  • 학습 측: FlagTrain에 FlagOS 테스트 스위트의 KMCompiler 설정 추가(#37); 리뷰 중인 7건은 여전히 각 벤더의 KMCompiler 연산자(scaled_masked_softmax, fused_proj_rms 순전파/역전파, bias_swiglu, fast_gelu, moe_gemm, tanh_soft_clamp).

1.7 빌드와 릴리스: changelog 사이트 반영과 Harbor, 푸시된 적 없는 Cambricon 이미지 2건 철회 (10-28)

날짜: 2026-10-28　출처: build-infra PR #1545 · PR #1547 · PR #1548 · PR #1549 · PR #1542 · PR #1543

  • 변경 기록 사이트 게시: 이제 각 이미지의 changelog가 사이트 페이지 말미에도 나타나고, Harbor 저장소 설명으로도 게시되어 3계층 릴리스에 반영됩니다(#1545, 455개 파일, 19080줄 추가). 이전에는 changelog가 저장소 내에만 작성되고 소비자가 없어 사이트 페이지, 저장소 내 readme, Harbor 설명 모두 이 부분이 빠져 있었고, 애플리케이션 계층에는 설명 줄조차 없었습니다. 블록은 “본문과 함께 렌더링하는 대신 재계산” 방식으로 구현했습니다. 페이지 본문은 각자의 생성기와 주기가 있어, 본문과 함께 출력되는 블록은 마지막 줄에 덮어써져 중간에 작성된 이유가 유실되기 때문입니다. 빈 대기 항목과 upstream_prs는 게시하지 않으며, 같은 모니터링 기간에 먼저 이유를 중영문 이중 언어로 작성했습니다(#1542).
  • 존재하지 않는 이미지 철회: Harbor에는 megatron_training0.18.2-cambricon-neuware4.7.2와 megatron_rl0.18.2-cambricon-neuware4.7.2 두 저장소가 없지만, 0.18.2의 두 상태 매트릭스 모두 image_tag: 2.2.0-0.3.0을 기록하고 있었습니다(#1547, 13개 파일, 29줄 추가, 496줄 삭제). 이 태그는 최초 매트릭스 생성 커밋에서 비롯된 것이지 기록 단계에서 작성된 것이 아니어서, 문서 파이프라인이 존재하지 않는 두 이미지에 대해 시작 페이지, readme, changelog를 게시했고, 이후 매번 pubdoc-app이 이 두 저장소에서 404를 반환했습니다(나머지 107개는 설명 PUT을 정상 수락).
  • 이미지 푸시 실패의 근본 원인: 0.18.2의 wheel에서 platform_register에 MLU 플랫폼이 없었고, torch_mlu의 gpu_migration이 CUDA 표면을 MLU로 별칭 처리한 후 선택된 것이 PlatformCUDA여서 파이프라인 병렬 그룹이 끝내 초기화되지 않았습니다. MLU 등록(MLF #125, #188/#190/#191 포함)은 release/0.2에만 반영되어 있고, v0.3.0, 0.3.0-rc2, main에는 해당 파일이 없으며 이관 작업도 진행 중이 아닙니다. 처리는 주장을 철회하는 것이지 억지로 맞추는 것이 아닙니다. 두 백엔드에서 image_tag를 제거하고 launch_docs: false로 설정하며, 동시에 두 changelog를 삭제하여 “changelog 파일 집합 == 게시된 집합”이 다시 성립하도록 했습니다(해당 집합은 총 151개이며, 이 블록만이 한 번도 전달되지 않은 것입니다).
  • 빌더 보완: amd-rocm7.2.4 런타임 이미지는 ubuntu 24.04 기반이며, 그 안에서 빌드된 FlagCX wheel이 GLIBC_2.38에 링크되어 wheel 라인의 22.04 게이트에 거부되었습니다(22.04-incompatible symbols: GLIBC_2.38, GLIBCXX_3.4.32, __isoc23_). 이번 커밋은 해당 라인에 자족적인 22.04 빌더를 구성하여 glibc 하한을 2.35로 되돌렸습니다. ROCm 7.2.4의 jammy 패키지(rccl/hip-dev 및 torch가 요구하는 hipsolver/hipfft/miopen-hip 헤더, graphics 저장소의 amdgpu-core), deadsnakes의 Python 3.12, 고정된 torch 2.11.0+rocm7.2를 설치합니다(#1548, 204줄).
  • 게이트 앞당김: 애플리케이션 계층 페이지에는 이전에 일관성 검증이 없었습니다. image_tag나 changelog 이유를 수정해도 페이지와 Harbor용 readme는 계속 이전 내용에 머물렀습니다(#1549, 6개 파일). 이제 gen_descriptions.py --app-only --check를 .githooks/pre-commit과 CI에 연결하여, 상태 매트릭스, 애플리케이션 changelog, 애플리케이션 페이지 또는 애플리케이션 readme가 변경되면 먼저 images.yaml을 재빌드한 후 비교합니다.
  • 검토 중: 재패키징 라인의 의존성 해석을 PEP 503 심플 인덱스를 직접 읽는 방식으로 변경했습니다(#1543). 기존 구현은 의존성마다 pip index versions 서브프로세스를 띄웠고 JSON API가 알리윤 미러에서 404를 반환하여, 0.28/0.32 재패키징에 약 2시간이 걸리고 300MB의 triton wheel을 헛되이 다운로드했습니다.

1.8 규칙 측면: FEP-0140 Implementable로 전환, FEP-0141 SGLang 0.5.18로 축소(10-28)

날짜: 2026-10-28　출처: community PR #159 · PR #160 · PR #161 · 2.3 일정

  • FEP-0140: 먼저 연산자 프로파일링의 범위와 검증 계획을 보완하고(#159), 상태를 초안에서 Implementable로 변경하며 Owner를 @ceci3(뤼멍쓰)로 설정했습니다(#160, 메타데이터 필드 두 개만 수정). 제안은 여전히 릴리스 수락 제약을 받으며, 추적 issue #151은 열린 상태로 유지됩니다.
  • FEP-0141: SGLang 0.5.18, 남은 Empty 통합 및 MetaX／Qingwei의 기본 기능으로 범위를 좁혔고, Owner를 @yixiaodapeng으로 설정했습니다(#161, 33줄 추가 144줄 삭제). 상세 플랫폼 진행 상황은 #152에 남겨 두었으며, 실행 가능한 회귀, 연산자 커버리지, 성능 및 안정성 검사와 wheel 빌드 명령을 유지하고, 과거 버전 매트릭스와 중복 배포 설명은 삭제했습니다.
  • 기준 명확화: DeepSeek-V4-Flash/Pro는 여전히 초기 W8A8 후보이며, 엔비디아 대비 처리량 10% 향상은 최적화 목표이지 고정된 수락 기준이 아닙니다. 이러한 한정어를 명시적으로 유지하여 이후에 목표를 기준으로 오독하는 일을 방지합니다.
  • 일정 확인: community/release/2.3 디렉터리에는 여전히 중영문 일정표만 있고 release 목록은 없으며, 2.2 디렉터리에는 rc0/rc1/rc2와 정식 목록 네 가지가 있습니다. 일정에 따르면 11-13은 FEP 머지 마감, 11-30은 rc0 생성입니다.

1.9 나머지 저장소: optest Enflame CI 연동, FlagTensor Ascend 상주 그리드, FlagQuantum 설정값 일관성 (10-28)

날짜: 2026-10-28　출처: optest PR #14 · optest PR #15 · FlagTensor PR #32 · FlagQuantum PR #945 · FlagQuantum PR #914 · FlagDNN 저장소

  • optest: 다섯 건 머지. Enflame S60을 FlagGems-vllm 및 FlagGems-sglang 변형 CI에 연결했으며, 연산자 목록은 FlagGems 본체에만 적용됩니다(#14). flagos-gpu-check를 단일 텍스트 요약 또는 단일 파싱 가능 JSON/YAML로 재작업했고(#15, 19개 파일 2947줄 추가), device, driver, runtime, runtime_version, device_count, memory_unit 등 정규화 필드를 새로 추가했으며, 텍스트 레이블을 Device:, Driver:, GPUs Usage:로 고정하고 런타임과 호스트 드라이버를 분리해 서술했습니다(#16에서 가속기 메타데이터를 테스트 요약에 포함).
  • FlagTensor: Ascend 측 상주 그리드 원소별 커널과 벤더 관련 튜닝을 머지했으며(#32, 24개 파일 1128줄 추가 139줄 삭제), 이후 Ascend 런타임 헬퍼를 flagtensor.runtime에 통합했습니다(#33, #32 시리즈 커밋).
  • FlagQuantum: 여섯 건 머지, 33건 커밋으로 여전히 전 조직 커밋 수 1위입니다. 핵심은 「샤딩된 MPS와 샤딩하지 않은 것이 동등한지」를 실행 가능한 증거로 만든 것입니다(#945). 동일 프로그램을 두 갈래로 실행합니다. max_bond 64에 정확한 그래디언트(레이아웃만 변경)와 max_bond 2에 근사 그래디언트(레이아웃과 절단이 함께 변경)를 사용하고, 두 갈래의 차이로 두 가지 기여를 분리합니다. 또한 공개 Module 학습 속도 향상 및 선언된 JAX 배치 VJP 보완(#914), 비유한 바인딩 각도 거부(#944), pytest 9.2로 인한 두 스위트 복구(#946), 상태 및 그래디언트 일관성 그리드(#947), 실패 원인을 도입 변경으로 귀속(#948)이 있습니다.
  • 기타: FlagDNN 두 건 모두 Hygon 수정(GPU 이름 및 성능)입니다. FlagAttention은 Damo Academy XuanTie PPU의 MiniMax 희소 어텐션을 머지했으며(#111, 6개 파일 4644줄 추가), FlagCX는 AMD 어댑터의 스트림 가드(#680)와 Kunlunxin 플랫폼 traits의 cstddef(#682)를 수정했습니다. FlagQAI의 #1은 여전히 검토 중이며, docs 두 건은 모두 로봇(魔搭 모델 목록 #545, #567)입니다. Trident 세 건은 검토 중입니다(Ascend LLVM 적응 #7, 사용자 제공 LLVM_ROOT #6, 신구 TVM FFI 헤더 레이아웃 #8).

2. 뉴스 보도와 생태계

2.1 보도 면: Moore Threads, Megatron-MUSA-Titan 오픈소스 공개, 24개 쿼리 중 유일하게 유효한 한 건 (10-28)

날짜: 2026-10-28　출처: IT之家 보도 · 新浪科技 전재 · Megatron-MUSA-Titan 저장소 · Google News RSS 검색

  • 사건: Moore Threads가 10-28 자사의 풀기능 GPU 기반 대규모 모델 학습 인프라 프로젝트 Megatron-MUSA-Titan을 오픈소스로 공개했다고 발표했다. 이는 만 카드급 클러스터의 조 단위 파라미터 MoE 학습을 겨냥하며, 사전 학습과 강화 학습 두 시나리오를 아우르고, MUSA 플랫폼의 학습 적응과 시스템 최적화를 제공한다.
  • 기술 포인트: 이미 만 카드 클러스터의 조 단위 파라미터 MoE 사전 학습에서 지속적으로 사용되고 있으며, 자체 설명에 따르면 높은 MFU와 장기 안정 학습 능력을 갖추고 있다. blockwise FP8 학습을 지원하며, DeepEP와 ACE 비동기 통신 엔진을 결합해 MoE의 Token 분배와 결과 병합을 가속하여 전문가 병렬과 연산 중첩을 구현한다. slime, miles 강화 학습 프레임워크와 협력하여 Megatron으로 학습하고 SGLang으로 샘플을 생성하며, 사전 학습과 강화 학습을 연결한다.
  • 코드 상태: 저장소 MooreThreads/Megatron-MUSA-Titan은 존재하며, README는 만 카드 클러스터에서의 1T+ 파라미터 모델 사전 학습 및 강화 학습 인프라를 겨냥한다고 자체 설명하고 있다. 마지막 푸시는 10-16이며, 이번 모니터링 기간 내 커밋은 없다 — 이는 「오픈소스 발표, 코드는 미변동」에 해당하며, 보도자료의 「오픈소스」 표현과는 시간적으로 분리해서 보아야 한다.
  • 후보 면: 24개 중국어·영어 쿼리어 조합이 모니터링 기간 내 49건의 후보를 반환했고, 1건(위 항목)을 채택했다. 컴포넌트명 쿼리(FlagOS, FlagGems, FlagScale, FlagTree, FlagPerf, FlagCX, KernelGen)는 중국어·영어 합계 12건이 계속 전부 0건을 기록했다.
  • 제외 항목: Moore Threads 3분기 실적 기사 10여 건(매출 15.5억 위안, 전년 동기 대비 1773.9% 증가, 분기 조정 후 순이익 흑자 전환, 홍콩 주식 발행 계획)은 재무 보고 및 시세 내용에 해당하여 3.7에서 멤버 단위 배경으로만 언급했다. Zhiyuan/BAAI 측 「源創計画」 1차 시행, AREX-2, SoulAgent 3건은 모델 및 커뮤니티 내용으로 소프트웨어 스택과 직접적 관계가 없다. Enflame 관련 20여 건은 주가 시세, 이사회 결의 및 ETF 기사였다. 清微의 「産投 28 計画」 기념 기사는 오픈소스 스택과 무관하다.

2.2 채널 및 공식 웹사이트: CSDN은 여전히 10-22 정체, HN과 Zhiyuan/BAAI 커뮤니티는 신규 적중 없음 (10-28)

날짜: 2026-10-28　출처: CSDN FlagOS 칼럼 · HN Algolia 검색 · Zhiyuan/BAAI 커뮤니티 · Moore Threads 뉴스 센터

  • CSDN: 칼럼 페이지의 기사 링크 51건 중 최신 확인 가능 날짜는 여전히 10-22(오픈 컴퓨팅 콘퍼런스 분과 포럼 다시보기 및 대학 라운드테이블)이다. 이전의 고관련 기사 3건(GLM-5.3-Flash Day0 9종 칩 적응, Qwen3.8-Flash-Next 첫날 8종 칩 적응, LightX2V FlagOS 연동)은 페이지별로 시간을 확인한 결과 모두 8월 하순으로, 모니터링 기간 내용이 아니다.
  • HN Algolia: 8개 쿼리가 4일 모니터링 기간 내 적중 수는 FlagOS 5, BAAI 30, FlagGems 1이었으며, 제목과 본문 키워드 엄격 매칭 후 직접 적중은 0건이었다.
  • Zhiyuan/BAAI 커뮤니티: 검색 페이지와 첫 페이지는 접근 가능하며, FlagOS 관련 신규 기사는 없다. 첫 페이지에 본 스택 컴포넌트 업데이트는 나타나지 않았다.
  • 멤버 공식 웹사이트: 8개사 점검 중 Moore Threads에 모니터링 기간 내 신규 항목이 있었다 — 10-28 《한 장으로 읽는 Moore Threads 2026년 3분기 보고서》로, 재무 보고 도해에 해당하며 소프트웨어 스택 변동을 다루지 않아 수록 기준에 따라 본문 항목에 포함하지 않았다(배경은 3.7 참조). MetaX, Iluvatar CoreX, Cambricon, Enflame, 清微 5개사 목록에는 10-28~10-29 신규 항목이 없었다. Hygon 페이지는 정적 페이지이며, Horizon Robotics는 수집에 실패하여 목록에서 보이는 내용을 기준으로 했다.
  • 판단: 뉴스 측은 연속 두 번째 모니터링 기간에 실질 항목이 1건뿐이었으며, 그 1건도 멤버 단위의 자체 개발 학습 스택에서 나온 것이지 본 스택 컴포넌트가 아니다. 이번 호의 주체는 여전히 코드와 릴리스 엔지니어링이다.

3. 멤버 단위 및 백엔드 벤더 심층 분석

3.1 Horizon Robotics: BPU가 처음으로 연산자별 실행 가능한 PrivateUse1 백엔드가 되다 (10-28)

날짜: 2026-10-28　출처: Torch-FL PR #674 · PR #676 · PR #678 · PR #673

  • 연동 방식: BPU의 실행 단위는 hbdk4가 생성하는 .hbm 산출물이며, hbdk4는 x86에서만 실행 가능하다. 보드에서는 컴파일할 수 없고, 저장소와 함께 전달되는 산출물도 없다. 이전의 결론은 “설계상 eager 불가”였으나, 이번 커밋은 이를 세 계층으로 분해한다. 보드 외부에서 단일 연산자 .hbm 라이브러리를 빌드하고, C++ 커널을 생성하여 이러한 산출물을 제출하며, drobotics conf 라우팅을 추가한다.
  • 커버리지 및 검증: 40개의 원소별 연산자, 11개의 형상 버킷에 대해 RDK S600에서 440개의 산출물 전부가 NumPy와 비교하여 차이 없음을 확인했으며, flagos 텐서 상의 aten 호출이 실제로 BPU에 도달함을 검증했다. 작성자는 동시에 두 가지 부정적 결론을 기록했다. libhbtl.so는 단지 CPU 참조 구현일 뿐이며(ldd에서 libc/libstdc++/libm만 확인됨, hbtl::ucp::Add의 cpu/wall이 1.00), 동적 형상은 HBRT 4.7.5에서 실행 불가능하다(로더가 해당 축을 stride 0으로 선언하고, 태스크 검증에서 64 이상을 요구함).
  • 마무리 세 건: #676은 kDrobotics에 dispatcher.h의 두 곳 switch를 보완했다. 이전에는 BPU 빌드의 디스패치 로그 이름이 일괄적으로 unknown으로 출력되었고, KernelSetOf가 BPU 자체의 커널 라이브러리를 소속 없음으로 보고했다. #678은 세 곳의 copy 브랜치가 무조건 CUDA로 box되는 문제를 수정했다. 기본 FlagGems 주도의 NVIDIA 및 Damo Academy XuanTie PPU wheel은 의도적으로 CPU 전용 pip torch를 링크하며, CUDA 복사 커널의 DispatchStub이 비어 있어 첫 호출 시 missing kernel for cuda가 발생한다. #673은 빌드 기록에서 벤더 이름과 플랫폼 id의 불일치(hygon/dcu, mthreads/musa, enflame/gcu, nvidia/cuda)를 수정했으며, 이는 Hygon DCU 레인에서 8개 단위 테스트 실패의 근본 원인이었다.
  • 심사 중: #672는 soft-lowp 행렬 연산자의 claim 세분화를 통일하고(conf 키로 선언, 패밀리로 디코딩), #677은 키워드 인자의 FlagGems 호출이 활성 백엔드로 가도록 하며, #680은 빌드 기록이 보유한 벤더에 따라 디바이스 별칭을 재설정하고, #681은 인터페이스 대상이 아닌 torch 접두사에서 libtorch_cuda 프로브를 읽도록 한다.
  • 판단: 이는 본 모니터링 기간 유일하게 “새 플랫폼이 사용 불가에서 사용 가능으로 전환”된 연동이며, 가치는 성능이 아닌 경로 개척에 있다. 40개의 원소별 연산자는 시작점일 뿐이며, 컨볼루션 등 주간 연산자는 여전히 torch.compile 전체 그래프 경로에 의존한다.

3.2 Kunlunxin: 스칼라 체인 융합 및 연속 세그먼트 커널, P800에서의 세 가지 가속 (10-28)

날짜: 2026-10-28　출처: FlagGems PR #7617 · PR #7600 · PR #7850 · PR #7803 · FlagCX PR #682

  • 스칼라 체인: 여덟 개의 아웃오브바운드 스칼라 체인 연산자의 융합 커널이 상대 소요 시간을 0.08~0.13에서 0.81~0.93으로 끌어올렸다(#7617). 이득은 주로 호스트 측에서 발생했다. 출력을 한 번 할당하고 unbind를 사용하여 텐서마다 할당기 호출을 하던 것을 대체했으며, 작은 형상에서는 단일 런치로 모든 포인터를 인자로 전달했다.
  • 연속 세그먼트: batch-norm 추론과 QKV 변환을 연속 세그먼트 커널로 변경한 후 집계 지표가 0.228→1.357과 0.260→5.062로 개선되었다(#7600). 기존 구현은 (n,c) 슬라이스 또는 2차원 tile로 구성되어 읽기/쓰기가 비연속적이었으며, 새 구현은 각 program이 연속 요소 세그먼트를 커버하고 평탄 인덱스로부터 채널을 역추론하거나 행을 패킹한다.
  • 마스크 채우기: masked_fill은 P800에서 0.577에서 0.829로 향상되었다(#7850). 방식은 정수 마스크의 부호 확장을 sitofp 후 0/1 부동소수점 곱셈으로 변경하여 전체 커널을 벡터화할 수 있게 한 것이다. 정밀도 면에서 m은 정확히 0/1이므로 결과가 비트 단위로 일치한다.
  • 유지보수성: #7803은 Kunlunxin 백엔드가 현재 master에서 임포트되지 않는 문제(공유 실행기에서 _result_dtype 헬퍼 제거됨)를 수정하고, 공유 실행기가 uni_sram에서 발생하는 지배 관계 컴파일 오류를 수정했다. 수정하지 않으면 어떤 Kunlunxin 테스트도 시작할 수 없다.
  • 통신 측: FlagCX의 Kunlunxin 플랫폼 traits가 cstddef를 __xpu__ 가드 밖으로 이동시켰다(#682). 이전에는 comm_traits.h에서 파싱할 때 size_t가 아직 보이지 않아 공용 디바이스 API의 호스트 측 컴파일이 직접 실패했다.

3.3 Iluvatar CoreX: 컨볼루션이 워크로드 등급표를 사용하고, conv3d에서 채널 제로 패딩 제거 (10-28)

날짜: 2026-10-28　출처: FlagGems PR #7036 · FlagGems PR #7061

  • conv_transpose2d: 범용 구현의 단일 기본 스케줄 (64,32,32,4)에 3x3/stride2 특례를 더한 것을, 데이터 타입, 커널 크기, 스트라이드, 출력 채널 수로 인덱싱되는 일곱 가지 하드웨어 튜닝 등급(BLOCK_NHW/CI/CO, num_warps, num_stages)으로 교체하고, 출력이 L2에 들어가는지 여부에 따라 두 커널 변형 사이를 전환한다. 직접 스캔 변형은 L2 내에서 더 빠르고, 위상 전용 변형은 출력이 L2를 초과한 후 더 안정적이다(#7036, 1886줄 추가).
  • conv3d: Iluvatar CoreX 측 BLOCK_CI는 이미 16 이상이고, FlagTree의 AABS도 축소된 tile을 16x16x16 하한으로 되돌리므로, 범용 경로에서 weight_c를 16으로 채널 제로 패딩하는 것은 순전히 호출마다 발생하는 할당 및 복사 오버헤드이다. 제거 후 출력이 비트 단위로 일치한다. 또한 BLOCK_NI_DO_HO_WO를 32와 64 두 등급의 소공간 tile로 보충하여 소형 형상도 디바이스를 채울 수 있게 했다(#7061).
  • 판단: 두 가지 모두 롱테일 튜닝에 속하며 방향이 일치한다. 즉 “범용적으로 정확하지만 느린” 경로를 로컬화된 스케줄로 교체하는 동시에 제로 패딩 같은 무수익 오버헤드를 삭제하는 것이다.

3.4 Enflame: Qwen3.5 FP8로 GCU에서, core_shapes 정리, FlagPrism 최초 통합 (10-28)

날짜: 2026-10-28　출처: vllm-plugin-FL PR #358 · FlagGems-sglang PR #232 · FlagTree PR #1239 · optest PR #14

  • 추론: GCU 백엔드에 Qwen3.5 FP8의 W8A8 블록 스케일링 추론을 추가하고, GCU300/GCU400 제약에 맞춰 커널 패치를 재작업하여 FP8 MoE를 eager와 전체 그래프 두 모드 모두에서 사용할 수 있게 함(#358, 20개 파일).
  • 형상 테이블: Enflame의 core_shapes.yaml은 1주일 동안 적용되지 않았음——저장소 내에 로딩 지점이 전혀 없었고, 벤치마크는 하드코딩된 kunlunxin 브랜치만 인식했음(#229 파일 추가, #232 로딩 수정). 수정은 조회를 임의 벤더로 일반화하고, kunlunxin 경로가 무조건 설정되어 발생하던 FileNotFoundError도 함께 해결함.
  • 툴체인: FlagPrism의 프로파일러와 디버거를 Enflame까지 확장하고 기본 활성화(#1239), 디버깅이 포함된 커널 런치는 게이트웨이를 경유하도록 변경, L2 캡처에 필요한 컴파일러 처리는 Enflame 백엔드 내부에 유지; optest는 S60을 FlagGems 두 변형의 CI에 연결(#14).
  • 검토 중: vLLM 0.28의 TXDA eager 백엔드 업그레이드(#642), TransformerEngine의 Enflame profiler와 runner(검토 중), 그리고 FlagGems 측 대량 참조 구현 수정(1.3 참조).

3.5 Damo XuanTie: PPU의 MiniMax 희소 어텐션, 기하평균 1.8배 (10-28)

날짜: 2026-10-28　출처: FlagAttention PR #111 · FlagAttention 저장소

  • 내용: Damo XuanTie PPU 백엔드에 MiniMax 희소 어텐션(MSA) 추론 연산자를 추가, 인덱스 스코어링, top-k 블록 선택, 희소 어텐션 자체를 포함하며 prefill과 decode 두 경로 모두 구현(6개 파일, 4644줄 추가).
  • 기능: 페이지드 KV 캐시, 인과 마스크, 강제 블록 선택 지원; 810E에 맞춰 행렬 연산 레이아웃과 커널 런치를 적응; prefill의 인덱스 스코어링은 KV 페이지 단위로 병렬화하여 query 측 병렬도 부족 문제 완화; FP8 입력은 BF16으로 변환하여 계산하며 네이티브 FP8 행렬 곱은 미사용.
  • 성능: SGLang 범용 Triton 구현을 베이스라인으로, 810E에서 prefill 21/21 통과, 기하평균 2.299배(최저 1.965, 최고 5.434), decode 18/18 통과, 기하평균 1.354배(1.289~1.485), 합계 39/39, 기하평균 1.800배.
  • 판단: PPU에서의 첫 번째 희소 어텐션 경로로, 같은 모니터링 기간 Torch-FL의 BPU 연동과 대조를 이룸——한쪽은 주력 연산자 커버리지를, 다른 쪽은 새 모델 구조의 특수 연산자를 보완.

3.6 Qingwei, Xiwang, Hygon: FlagCX rpm 패키징으로 세 백엔드 보완 (10-28)

날짜: 2026-10-28　출처: FlagCX PR #673 · FlagCX PR #681 · FlagTree PR #1459 · FlagDNN 저장소 · FlagAttention PR #117

  • Qingwei: libflagcx-tsm가 rpm 라인에 진입했으며, SDK는 두 개의 makeself 설치 프로그램으로 /usr/local/kuiper에 압축 해제됩니다(#673). FlagTree 측에서 심사 중인 #1459는 Qingwei 백엔드를 내부 Triton 3.6 개발 라인에 동기화합니다(27개 파일, 개별 발사 정밀도 API, 외부 CoreIR 진입점 및 런타임 어댑터 포함, Tx81 코드 생성 및 DMA/RDMA/WDMA의 CRT 결함 수정).
  • Xiwang: libflagcx-sunrise가 rpm 라인에 진입했으며, SDK는 tangtk --toolkit과 pccl을 통해 /usr/local에 배치됩니다. 이전에 Xiwang은 vllm-plugin-FL 측에서 0.28 적응이 심사 중이었습니다.
  • Hygon: libflagcx-du가 rpm 라인에 진입했으며, DTK tarball은 /opt/dtk에 압축 해제됩니다. FlagDNN의 두 건은 Hygon의 GPU 이름과 성능을 수정합니다. FlagAttention에서 심사 중인 #117은 Hygon BW3000(gfx936)을 위해 순수 Triton의 GLA 구현을 추가하여, 게이트 누적 합과 순환 상태 스캔을 하나의 파이프라인으로 결합하고 지원되는 추론 워크로드에 대해서만 특화 경로를 사용합니다.
  • 패키징 기준: 세 곳 모두 벤더 기본 이미지가 필요하지 않으며, openEuler 이미지에 파일 저장소를 더하면 완전한 환경입니다. 벤더 soname은 Ascend의 기존 방식을 따라 통일적으로 필터링됩니다(이 SDK들은 결코 RPM이 아니며, 어떤 저장소도 제공할 수 없습니다).

3.7 Moore Threads: Megatron-MUSA-Titan 오픈소스와 3분기 보고서 같은 날(10-28)

날짜: 2026-10-28　출처: IT之家 보도 · Megatron-MUSA-Titan 저장소 · Moore Threads 뉴스 센터 · sglang-plugin-FL PR #158

  • 훈련 스택: Megatron-MUSA-Titan은 만 카드 클러스터를 위한 조 단위 파라미터 MoE를 대상으로 하며, 사전 훈련과 강화 학습을 포괄합니다. blockwise FP8, DeepEP와 ACE 비동기 통신, 전문가 병렬과 계산 중첩을 지원하며, slime, miles와 협력할 수 있습니다(Megatron 훈련 + SGLang 샘플링). 이는 멤버 단위가 자체 개발한 Megatron 계열 훈련 스택으로, 본 스택의 Megatron-LM-FL과 같은 기원이나 다른 분기이며, 아직 코드 환류 징후는 없습니다(저장소 마지막 푸시 10-16).
  • 재무 배경: 같은 날 3분기 보고서를 발표하여 매출 15.5억 위안, 전년 대비 1773.9% 성장, 단일 분기 비경상이익 흑자를 실현했으며, 3분기 누적 매출 32.89억 위안, 모회사 순이익 3769.73만 위안을 기록하고 홍콩 주식 2차 상장을 추진하고 있습니다. 재무 보고서는 본 스택의 기술적 판단을 바꾸지 않지만, 오픈소스 리듬의 투자 능력을 설명합니다.
  • 추론 측: sglang-plugin-FL에서 심사 중인 #158은 MUSA에 MiniMax-M3 지원을 추가하며, #125는 S5000에서 Qwen3.6의 Triton 및 YAML 튜닝입니다. FlagGems-sglang 측은 이번 모니터링 기간에 MUSA 변경이 없습니다.
  • 판단: Moore Threads의 최근 2주간 움직임은 ‘훈련 + 추론 이중 스택 자체 개발 오픈소스’에 집중되어 있으며, 본 스택과의 교집합은 여전히 연산자와 플러그인 계층(FlagGems, sglang-plugin-FL)이지 훈련 프레임워크 계층이 아닙니다.

4. 요약 및 트렌드 관찰

  • 새로운 경로 개통: Horizon BPU가 「설계상 eager 불가」에서 연산자별 실행이 가능한 PrivateUse1 백엔드로 전환되었다(40개 요소별 연산자, 440개 산출물 무차이). 배포 로그 명명과 CUDA 복사 커널 가드도 함께 수정되었다. 이는 이번 모니터링 기간 내 가장 구조적으로 의미 있는 연동이지만, 요소별 연산자만 커버하며 메인라인은 여전히 전체 그래프 컴파일에 의존한다.
  • 통신 계층이 태그와 배포 패키지 단계로 진입: FlagCX가 v0.14.1을 릴리스했다(어댑터별 디바이스 비트코드 생성). rpm 라인이 세 백엔드에서 여섯 개로 확장되었고, wheel 배포도 build-infra에 기록되었다. 해당 태그에는 Release 본문이 없어 v0.14.0의 방식과 일치하지 않는다는 점에 주의해야 한다.
  • 릴리스 엔지니어링 보완 중: changelog 사이트 등재와 Harbor, 한 번도 푸시되지 않은 Cambricon megatron 이미지 2건 회수, 앱 페이지 일관성 검사 pre-commit 및 CI 편입, AMD 7.2.4에 22.04 빌더 추가. 이들은 새로운 역량을 산출하지 않지만 2.3 릴리스 목록의 자기 증명 가능 여부를 직접 결정한다.
  • 심사 중 구조 변화: 심사 중 건수가 401에서 288로, 신규 오픈이 269에서 101로 감소했으며, 지난 회차 FlagGems-Experimental의 135건 배치 커밋은 합입되지도 추가되지도 않았다. 현재 심사 중 주체는 FlagGems 181건이며, 그중 신규 오픈 53건은 대부분 Enflame 참조 구현 수정이다. 이는 다중 백엔드 검수의 병목이 연산자 공급이 아니라 참조 구현과 테스트 기준에 있음을 보여준다.
  • 다중 브랜치 기준 구분 필요: FlagGems는 master와 kernelgen-dev에 동시에 합입되었고(#7905, #7934), FlagTree의 합입은 triton_v3.5.x와 feature/flagmega 브랜치에 분산되어 있으며, FlagGems-Experimental의 기본 브랜치는 infra-ci이다. 기본 브랜치 기준 집계는 실제 작업량을 과소평가하고, 커밋 검색은 원자적 보충 저장소를 누락시킨다.
  • 관찰 필요 사항 세 가지: 첫째, v0.14.1 이후 Release 설명이 보충되어 2.3 목록에 포함되는지 여부. 둘째, BPU 경로가 요소별 연산자에서 컨볼루션 등 메인라인 연산자로 확장되는지 여부. 셋째, Megatron-MUSA-Titan의 코드가 모니터링 기간 이후 실제로 푸시되기 시작하는지, 그리고 Megatron-LM-FL과 재사용 관계를 형성하는지 여부.

출처 검증표

출처 검증 결과
GitHub 조직 저장소 61개 저장소 전수 검증, 23개 저장소가 모니터링 기간 내 푸시(지난 회차 20개 저장소)
GitHub 커밋 검색 99건 적중; 검색 인덱스가 당일 합입에 지연이 있어 합입량과 병기하여 제시
GitHub 병합 PR 검색 67건, 16개 저장소
GitHub 심사 중 PR 검색 288건(신규 오픈 101건), FlagGems 181건이 60% 차지
Release / Tag 원자 검증 31개 저장소; 모니터링 기간 내 신규 태그 1개(FlagCX v0.14.1, Release 본문 없음)
org 이벤트 스트림 100건: 푸시 51, 브랜치 생성 32, 브랜치 삭제 9, PR 리뷰 8, PR 개폐 이벤트 없음
버전 일정 community/release/2.3에 여전히 중영문 일정표만 존재; build-infra 최신 태그는 여전히 v2.2.0
Google News RSS 24개 쿼리, 49건 후보, 1건 채택(Megatron-MUSA-Titan)
HN Algolia 8개 쿼리, 4일 모니터링 기간 내 직접 적중 0건
CSDN FlagOS 칼럼 최신 검증 가능 기사가 10-22에 정지, 모니터링 기간 내 신규 원고 없음
Zhiyuan 커뮤니티 모니터링 기간 내 신규 원고 없음, 홈페이지에 본 스택 관련 업데이트 없음
회원사 공식 웹사이트 8개사 점검; Moore Threads 10-28 3분기 보고서 도해 1건; Horizon Robotics 수집 실패; 나머지 업데이트 없음

전체 출처 목록

FlagGems PR #7600 (쿤룬신 연속 구간 커널) — https://github.com/flagos-ai/FlagGems/pull/7600

github.com/flagos-ai/FlagTree/pull/1459>

infra/tags>

[92] Tsingmicro 공식 웹사이트 뉴스 — https://www.tsingmicro.com/news