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

출처: GitHub(org: flagos-ai 61개 저장소 전수 확인, 커밋 검색 189건, 병합된 PR 183건 및 심사 중 PR 253건 검색, org 이벤트 피드 100건, 31개 저장소 Release/Tag 원자적 확인, 5개 저장소 원자적 보완 확인 및 브랜치 대조, 주요 PR 본문 및 산출물 규모 확인), Google News RSS(중영문 검색어 24조, 프록시 경유), HN Algolia(8조), CSDN FlagOS 칼럼(기사 및 라이브 항목 페이지별 시각 확인), Zhiyuan 커뮤니티, 8개 회원사 공식 웹사이트(상세 내용은 부록 출처 목록 참조).

이번 호 인덱스

  • 오늘의 중점: Hygon DTK 26.10 3개 라인 접속(컨테이너, 컴파일, 통신); MiniCPM-OCR 듀얼 모델 Day0 12개 플랫폼 커버; 테스트 인프라 ref-as-candidate 2개 저장소 적용(10-29)
    1. 오픈소스 프로젝트 진행 상황(GitHub 동향)
      • 1.1 조직 리듬: 21개 저장소 푸시, 189건 커밋, 183건 병합, 심사 중 253건(10-29 ~ 10-30)
      • 1.2 버전 현황: FlagTree Qingwei 3.6 전용 번호 출시, FlagCX v0.14.1 태그에서 wheel 라인으로 전환(10-29)
      • 1.3 FlagGems: KernelGen 하루 22개 연산자 병합, Kunlunxin XPU3 foreach 융합 마무리(10-29)
      • 1.4 테스트 인프라: ref-as-candidate 2개 저장소 적용, 하루 57건 테스트 PR 마감(10-29)
      • 1.5 추론 및 학습 스택: GLM-5.3-Flash 및 Qwen3.8-Flash 듀얼 모델 플러그인 진입(10-29)
      • 1.6 컴파일 및 통신: Moore Threads 상주 GEMM 및 SPMC 메인라인 진입, FlagCX 2개사 디바이스 인터페이스 보완(10-29)
      • 1.7 빌드 및 릴리스: Hygon DTK 26.10 8건 병합, Ascend rpm 타깃 및 2.3.0 이미지 설명(10-29)
      • 1.8 양자 라인: FlagQuantum 60건 커밋, CS-01~CS-07 합성 파이프라인 관통(10-29)
      • 1.9 기타 저장소: OpenCourse 교재 재구성, FlagScale 및 TransformerEngine-FL CI 수렴(10-29)
    1. 뉴스 보도 및 생태계
      • 2.1 MiniCPM-OCR 듀얼 모델 Day0 12개 플랫폼 적응, Damo Academy XuanTie 처리량 네이티브 대비 98.7% 달성(10-29)
      • 2.2 CSDN 기술 라이브: 플러그인 하나로 10개 칩의 추론 적응 연결(10-29)
      • 2.3 채널 확인: HN 및 Zhiyuan 커뮤니티 신규 히트 없음, CSDN 칼럼 신규 기사 1건 및 라이브 1건 추가(10-29)
    1. 회원사 및 백엔드 벤더 심층 분석
      • 3.1 Hygon: DTK 26.10 컨테이너에서 wheel까지 전 체인 적용(10-29)
      • 3.2 Qingwei: Triton 3.6 백엔드 동기 병합 및 전용 태그 출시(10-29)
      • 3.3 Kunlunxin: XPU3의 foreach 융합 체인 및 상수 그리드 마무리(10-29)
      • 3.4 MetaX: 그룹 GEMM의 INT8 및 FP8 경로, TP2 디코딩 스케줄링(10-29)
      • 3.5 Moore Threads: TLE 상주 GEMM 및 SPMC 동기 메인라인 진입(10-29)
      • 3.6 Enflame, Ascend, Damo Academy XuanTie: 어텐션 및 정규화 연산자 4개 라인(10-29)
      • 3.7 Iluvatar CoreX: TianGai 300 최초 실기 시연 공개, 단일 카드 처리량 H200 대비 1.05배 주장(10-28)
    1. 요약 및 트렌드 관찰
  • 부록: 출처 확인 표 및 전체 출처 목록

오늘의 중점: Hygon DTK 26.10 3개 라인 접속(컨테이너, 컴파일, 통신); MiniCPM-OCR 듀얼 모델 Day0 12개 플랫폼 커버; 테스트 인프라 ref-as-candidate 2개 저장소 적용(10-29)

날짜: 2026-10-29　출처: build-infra PR #1554 · build-infra PR #1562 · build-infra PR #1563 · MiniCPM-OCR Day0 적응 · FlagGems PR #7630 · FlagGems-sglang PR #249(전체 내용은 부록 참조)

  • 빌드 측면: Hygon DTK 26.10이 하루 만에 8건의 병합을 완료했습니다. 기본 컨테이너(#1554, 78줄 추가), 런타임 구성(#1555, 21줄 추가), 가용성 수정(#1558, /opt/dtk를 dtk-26.10으로 지정하고 runner 커버리지 보충), FlagTree의 cp312 hcu 빌더(#1562, 4개 파일에 342줄 추가), FlagCX의 dtk2610 wheel 라인(#1563, 3개 파일에 185줄 추가), 기본 이미지에 libopenmpi3t64 보충(#1564), 빌더에 libopenmpi3 보충(#1565), hcu-dtk2610을 FlagTree wheel 릴리스 라인에 추가(#1566)입니다. 이는 이 스택이 처음으로 새로운 버전의 벤더 SDK를 위해 컨테이너, 컴파일러 빌더, 통신 라이브러리 패키징의 세 라인을 동시에 수정한 것으로, DTK 26.10이 런타임을 python 3.12와 torch==2.13.0+dtk2610(cp312 전용)에 고정했기 때문에 기존 cp310의 hcu wheel은 해당 런타임에서 전혀 해석되지 않기 때문입니다.
  • 뉴스 측면: Zhongzhi FlagOS 커뮤니티가 ModelBest와 OpenBMB가 오픈소스로 공개한 MiniCPM-OCR 1.0(1.3B)과 MiniCPM-OCR Jev(2B)를 위해 Day0 크로스칩 적응을 진행했으며, Damo Academy XuanTie, NVIDIA, Huawei Ascend, Hygon, Kunlunxin, MetaX, Moore Threads, Qingwei Intelligent, Iluvatar CoreX, Xiwang, Mac(ARM), This Core Technology 등 총 12개 플랫폼을 지원합니다. 평가에서 제시한 기준은 하드웨어 최대 연산 성능으로 정규화한 처리량입니다. Jev는 Damo Academy XuanTie에서 실제 계산 처리량이 NVIDIA 네이티브의 98.7%에 달했고, OCR 1.0의 단위 최대 연산 성능 P50 처리량은 단일 문서 시나리오에서 NVIDIA 네이티브의 169.3%, 배치 시나리오에서 137.1%에 달했습니다.
  • 테스트 측면: FlagGems의 --ref-as-candidate와 명시적 get_candidate 선택이 메인라인에 진입했으며(#7630, 9개 파일), FlagGems-sglang은 같은 날 #239부터 #249까지 11건으로 모든 정확성 스위트를 get_candidate로 변경하고 매일 master에서 kernelgen-dev로의 자동 동기화 PR을 추가했습니다. 두 저장소를 합친 효과는 다음과 같습니다. 참조 구현이 외부 후보 파일 없이도 직접 후보로 삼아 통과할 수 있으며, 테스트는 더 이상 “연산자가 있느냐”의 스위치가 아니라 “참조와 구현이 일치하느냐”의 비교가 되었습니다.
  • 판단: 세 라인은 같은 한 가지를 가리킵니다. 소프트웨어 스택의 병목이 “연산자를 작성하는 것”에서 “새 SDK의 빌드 가정, 참조 구현의 실행 경로, 모델의 크로스칩 비교 가능성”이라는 세 가지 엔지니어링 규율을 고정하는 것으로 이동하고 있습니다. DTK 26.10의 8건 병합은 하드웨어 세대 전환 비용이 거의 전부 패키징과 종속성 해석에 있으며 커널 자체에는 있지 않다는 것을 보여줍니다. MiniCPM-OCR의 평가는 처음으로 정규화 처리량과 엣지 지연 두 세트의 비교 가능한 수치를 제시했습니다.

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

1.1 조직 리듬: 21개 저장소 푸시, 189건 커밋, 183건 병합, 심사 중 253건(10-29 ~ 10-30)

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

  • 저장소 측면: 61개 저장소 중 21개 저장소에 모니터링 기간 내 푸시가 있었습니다(이전 기간 23개 저장소). 푸시 시각 기준 최근에서 과거 순으로 FlagGems, Torch-FL, FlagGems-sglang, FlagQuantum, vllm-plugin-FL, FlagQAI, FlagTree, FlagScale, OpenCourse, build-infra, FlagCX, FlagGems-vllm, FlagSparse, release-info, docs, optest, FlagTrain, FlagOps, FlagFFT, FlagAttention, TransformerEngine-FL입니다.
  • 커밋 측면: 커밋 검색 히트 189건으로 최근 2주 중 최고치입니다(이전 기간 99건). 저장소별로는 FlagQuantum 60, FlagGems 43, build-infra 15, FlagGems-sglang 14, FlagQAI 11, FlagGems-vllm 9, FlagAttention 8, Torch-FL 6, FlagTree 5, FlagTrain 4, vllm-plugin-FL·FlagCX·OpenCourse 각 3, optest·FlagOps 각 2, FlagScale 1입니다. FlagQuantum과 FlagGems 두 저장소가 103건을 차지했습니다.
  • 병합 측면: PR 병합 183건(이전 기간 67건, 1.7배 증가). 저장소별로는 FlagGems 92, build-infra 16, FlagQuantum 15, FlagGems-sglang 11, FlagGems-vllm 9, FlagAttention 8, Torch-FL 6, FlagTree 5, vllm-plugin-FL 4, FlagQAI 4, FlagCX 4, FlagTrain 4, optest 2, FlagScale·FlagOps·TransformerEngine-FL 각 1입니다.
  • 심사 중 측면: 모니터링 기간 내 업데이트된 심사 중 PR 253건(이전 기간 288건), 신규 오픈 84건(이전 기간 101건). FlagGems 129, FlagTree 22, FlagGems-vllm 15, vllm-plugin-FL 10, Megatron-LM-FL 10, FlagTrain 9, FlagAttention 8, FlagScale 7, sglang-plugin-FL 6, Torch-FL 5, FlagGems-sglang 5, flir 5, FlagCX 4, docs 4, 나머지 저장소는 각 1~2건입니다.
  • 리듬 비교: 이전 24시간 모니터링 기간(23개 저장소, 커밋 99건, 병합 67건, 심사 중 288건)과 비교해 푸시 저장소 2개 감소, 커밋 91% 증가, 병합 173% 증가, 심사 중 12% 감소, 신규 오픈 17% 감소했습니다. 병합량의 급증은 주로 FlagGems의 연산자 물량(92건)과 FlagQuantum의 합성 파이프라인(15건)에서 비롯된 것이며, 심사 기준이 완화된 것은 아닙니다——같은 기간 심사 중 총량은 여전히 감소하고 있습니다.
  • 버전 및 이벤트 측면: 31개 저장소의 Release와 Tag를 원자적으로 점검한 결과, 모니터링 기간 내 신규 태그 1건(FlagTree의 Qingwei 3.6 전용 번호, 10-29 11:09)이 있었습니다. FlagCX v0.14.1의 아카이브 시각은 10-29 10:55로 앞당겨졌으며, #683이 0.14.0-rc2로 백포트된 병합 시각과 동일합니다. org 이벤트 스트림 100건: PR 리뷰 코멘트 34, PR 이벤트 34, 푸시 13, 브랜치 생성 8, 이슈 코멘트 9, 브랜치 삭제 1, fork 1로, 구성이 이전 기간(푸시 51, 브랜치 생성 32) 대비 뚜렷하게 심사 활동으로 전환되었으며, 병합량 증가와 일치합니다.
  • 브랜치 측면: 커밋 검색이 커버하지 못한 5개 푸시 저장소를 원자적으로 보완 점검했습니다——TransformerEngine-FL은 모니터링 기간 내 커밋 1건(#142의 FlagCICD v1, 10-29 09:51)이 있었습니다. FlagFFT의 푸시는 codex/musa-shortfall 기능 브랜치에 있었으며(10-28 여러 차례 푸시, 기본 브랜치 최신 커밋은 여전히 10-15), release-info의 푸시는 gh-pages 브랜치(배포 사이트 자동 배포)에 있었습니다. docs와 FlagSparse는 PR 브랜치 및 이슈 코멘트 활동에 해당하며, 기본 브랜치에는 신규 커밋이 없습니다.

1.2 버전 측면: FlagTree, Qingwei 3.6 전용 번호 태그, FlagCX v0.14.1 태그에서 wheel 라인으로 전환(10-29)

날짜: 2026-10-29　출처: FlagTree Qingwei 3.6 전용 태그 · FlagTree PR #1459 · build-infra PR #1553 · build-infra PR #1556 · build-infra PR #1563

  • FlagTree 태그: 10-29 11:09에 Qingwei 3.6 전용 태그가 생성되었으며, 10-26의 Moore Threads 3.6 전용 태그와 동일한 “제조사별 분할 3.6 프리릴리스 라인”에 속한다. 이 태그는 Releases API에서 릴리스 본문이 없으며(404 반환), 이는 설명이 포함된 Release가 아닌 태그 아카이브임을 의미한다. 같은 날 병합된 #1459는 바로 Qingwei 백엔드를 내부 Triton 3.6 개발 라인에 동기화한 커밋이다.
  • FlagCX 전달 범위: v0.14.1은 이전 모니터링 기간에 git 태그 형태로 등장했으며(Release 본문 없음), 이번 모니터링 기간에 build-infra의 wheel 디렉터리에 정식 등록되었다. 로봇이 릴리스를 기록하고(#1553), 수동으로 5개의 빈 설명을 보완하고 flagcx==0.14.1+rocm7.2.4라는 AMD 행을 추가했으며(#1556, 10개 파일 28줄 추가 16줄 삭제), 이어서 hygon-dtk26.10 라인을 flagcx==0.14.1+dtk2610에 고정했다(#1563). 이로써 0.14.1의 전달 범위는 cuda12.8, cuda13.3, corex4.4.0, corex4.5.0, xre5.37.1, rocm7.2.4 및 새로 추가된 dtk2610을 포함한다.
  • Issue 기반 수정: FlagTree #1481은 이슈 #1473을 해결하기 위해 Metax에서 CompiledKernel의 메타데이터 검사를 수정했으며(1개 파일, 2줄 추가 1줄 삭제), FlagGems #7989는 Ascend cat 연산자를 수정했고(57줄 추가 36줄 삭제), FlagTree #1468과 #1470은 Enflame을 위해 CI와 TLE 단위 테스트를 보완했다.
  • 관찰 사항: FlagTree의 3.6 라인은 “제조사별 태그 하나씩” 방식으로 진행되고 있으며, 0.7.1a1에는 아직 통합 릴리스 노트가 없다. 만약 2.3 주기가 이 라인대로 전달된다면, 다운스트림은 태그 이름에서 백엔드와 Triton 버전을 역추론해야 하며, 이는 FlagCX v0.14.1의 본문 누락과 같은 종류의 문제이다.

1.3 FlagGems: KernelGen 하루 만에 22개 연산자 병합, Kunlunxin XPU3 foreach 융합 마무리 (10-29)

날짜: 2026-10-29　출처: FlagGems PR 목록 · PR #7116 · PR #6950 · PR #6530 · PR #7989

  • KernelGen 측면: 92건의 병합 중 22건이 [KernelGen][Nvidia] 자동 생성 연산자로, 희소 텐서(sparse_csc_tensor_unsafe, sparse_bsc_tensor_unsafe, sparse_resize_), 컨볼루션 및 풀링(nnpack_spatial_convolution, thnn_conv2d, fractional_max_pool3d_backward, mkldnn_reorder_conv2d_weight), 선형 대수(cholesky, frobenius_norm, chain_matmul) 및 일련의 주변 연산자(argwhere, _indices, make_dual_copy, flatten_dense_tensors, combinations, empty_per_channel_affine_quantized)를 포괄합니다. 하루 배치는 해당 라인에서 최근 가장 밀집한 것이었으며, 같은 날 #8009부터 #8013까지 5건이 추가로 열려 대기열이 계속 이어지고 있습니다.
  • 쿤룬신 측면: XPU3의 foreach 퓨전 체인이 하루 만에 마무리되었습니다——cos/exp/sin/addcdiv/lerp의 List 실행기(#7116), ceil의 무마스크 퓨전 커널(#7604), tanh/expm1의 인플레이스 퓨전 커널(#7608); 이어서 네 건의 정확성 수정이 있었습니다: fmin을 상수 발행 그리드로 변경(#7966), t_copy 1차원 경로도 상수 그리드로 변경(#7973), foreach 스칼라 dtype 분기를 상호 배타적으로 변경(#7974), foreach add의 리스트 슬롯을 program_id(0)에서 가져오도록 변경(#7968). euclidean_dist, is_same_size, layer_norm_backward도 XPU 최적화가 이루어졌습니다(#7907).
  • 메타엑스 측면: INT8 및 FP8용 grouped_mm_w8a8이 추가되었습니다(#6950, 7개 파일에 1220줄 추가). 벤치마크는 GLM-5.2를 PPU SGLang TP=8에서 수집한 실제 호출 형태를 MetaX C550에서 재생하여 수행했습니다——28건의 시나리오 기록, 26개의 고유 (M,N,K,E) 형상, 324만 회 호출, 257개 전문가.
  • 기타: AMD W7900(gfx1100)의 연산자 정밀도 수정(#6530); 어센드 log_ 그리드 채우기 재실행의 벤더 로컬 구현을 5.4.0-rc2로 백포트(#6586); CI 측에서 임포트 순서 수정(#7951), 릴리스 빌드를 제거된 cp38에서 cp310으로 교체(#7975), 벤더명을 런타임 버전에 따르도록 변경(#7961), FP8 MM 테스트를 등록된 백엔드에 따라 건너뛰도록 변경(#7812).
  • 판단: 연산자 물량은 이미 KernelGen이 담당하고 있으며, 인적 투입은 두 가지에 집중되어 있습니다——새 백엔드의 발행 매개변수 정확성(쿤룬신 네 건)과 테스트 실행 가능성(1.4 참조). 이는 92건의 병합 중 핵심 의미 변경이 거의 없는 이유를 설명합니다.

1.4 테스트 인프라: ref-as-candidate 듀얼 저장소 도입, 하루 57건 테스트 PR 마무리(10-29)

날짜: 2026-10-29　출처: FlagGems PR #7630 · FlagGems-sglang PR #239 · FlagGems-sglang PR #241 · FlagGems-sglang PR #249 · FlagGems-sglang PR #242

  • 메커니즘: --ref-as-candidate는 정확성 테스트와 벤치마크가 명시적으로 선언된 참조 구현을 후보로 실행할 수 있게 한다(get_candidate("negative", reference=torch.negative)). 더 이상 외부 후보 파일에 의존하지 않는다. 참조 누락, 참조 호출 불가, 테스트 본문이 실제로 후보를 호출하지 않은 경우 모두 명시적으로 실패한다. 스킵과 xfail은 계약 오류를 감출 수 없으며, 전부 스킵된 경우는 유효한 실행으로 집계하지 않는다. 검증은 26건의 호스트 회귀와 master 및 PR 병합 프리뷰에 대한 32건의 검사로 구성된다.
  • 적용 범위: FlagGems-sglang은 같은 날 11건의 커밋으로 모든 정확성 스위트를 get_candidate로 전환하고(#241), 참조 선언을 보완하고(#240, #244), 벤치마크 케이스 열거와 재생을 추가하고(#239), definitions 디렉터리와 silu_and_mul 예제를 추가하고(#245), mrotary_embedding 후보 비교와 이식 가능한 참조 및 크로스 디바이스 네이티브 검증을 보완했다(#247, #249).
  • 규모: 하루 동안 동일 작성자가 제출한 57건의 테스트 수정이 병합되었다(대부분 각 백엔드의 참조 계약, 픽스처, 벤치마크 진입점 수정). Ascend, MetaX(MUSA), Enflame, Kunlunxin, NVIDIA의 스킵 조건과 참조 ABI를 포괄한다.
  • 자동화: 매일 master에서 kernelgen-dev로의 자동 동기화 PR(#242)이 추가되었으며, 당일 로봇이 이미 두 건의 동기화를 생성했다(#243, #246). 이 체인은 “업스트림 메인라인”과 “KernelGen 개발 라인”의 드리프트를 수동 rebase에서 매일 한 번 감사 가능한 병합으로 전환한다.
  • 판단: 테스트가 “통과 가능”에서 “비교 가능”으로 전환된 이후, 테스트 자체가 참조 구현의 계약을 필요로 하기 시작했다. 이것이 오늘 57건 수정의 실제 내용이다. 테스트를 보충한 것이 아니라 참조를 보충한 것이다.

1.5 추론 및 학습 스택: GLM-5.3-Flash와 Qwen3.8-Flash 듀얼 모델 플러그인 진입(10-29)

날짜: 2026-10-29 ~ 2026-10-30　출처: vllm-plugin-FL PR #455 · vllm-plugin-FL PR #454 · vllm-plugin-FL PR #615 · FlagTrain PR #35 · FlagGems-vllm PR #1025

  • Qwen3.8-Flash: vllm-plugin-FL에 Qwen3.8-Flash-Next 및 Qwen4의 체크포인트 로딩과 모델 통합 추가(#455, 65개 파일 11226줄 추가 109줄 삭제), HC, PLE, QSA 및 멀티모달 연결 포함, 수치 연산자는 FlagGems-vllm 사용. FP8은 역량 게이팅 적용: 플랫폼이 네이티브 지원하면 네이티브 커널 유지(엔비디아는 컴퓨팅 능력 8.9 이상 요구, AMD는 vLLM의 ROCm 구현 판단에 위임), 미지원 시 BF16 선형 및 MoE 경로로 폴백하고 --dtype bfloat16 강제.
  • GLM-5.3-Flash: 다음 날 새벽 순수 공개 연산자 구현 병합(#454, 90개 파일 19140줄 추가 280줄 삭제). 인덱서 정밀도는 캐시 할당보다 먼저 선택: 엔비디아 SM89 이상, Moore Threads MP31 이상 및 GCU capability 4 이상은 FP8 유지, 그 외 벤더와 미확인 능력은 BF16 사용; BF16의 MetaX와 Kunlunxin은 해당 radix 컴파일 경로를 다운그레이드할 수 없어 기존 Torch TopK, scatter 및 sort 경로로 전환.
  • 런타임 측면: 네이티브 CUDA의 vLLM 0.32 적응(#615, 57개 파일 3408줄 추가 1044줄 삭제)으로 스택을 vLLM 0.32.0+cu129, PyTorch 2.13.0+cu129, CUDA 12.9 및 python 3.12.3에 고정, FlagGems는 5.4.0 개발 커밋, FlagTree는 0.7.0 개발 커밋 사용(Triton 3.6 제공); 기존 NVIDIA CI 추론 6건과 서비스 3건 모두 통과.
  • 학습 측면: FlagTrain에 multi_tensor_adam 추가(#35, 6개 파일 1093줄 추가), 한 번의 Triton 런치로 다중 텐서 Adam 업데이트를 배치 완료, 백엔드는 엔비디아, Hygon, MetaX, PPU(다모아카데미 XuanTie) 및 Iluvatar CoreX 지원; 동일 모니터링 기간에 fused_proj_rms 순전파/역전파(#38), fast_gelu(#33) 및 deepspeed 의존성(#42)도 있음. 원본 H20 벤치마크에서 fp32 65536 요소 구간은 DeepSpeed CUDA 베이스라인 대비 2.24배, 1024 요소 소구간은 오히려 0.76배로 느림.
  • 추론 최적화: FlagGems-vllm 측, MetaX TP2 packed decode의 Split-KV 스케줄링과 컴퓨트 tile 재배열(#1025); FP8 W8A16의 게이티드 증분 네트워크 및 동적 상태 양자화(#988); MUSA의 FP8 가변 길이 어텐션을 현재 CI 컴파일러에 맞춰 재조정(#970); fused_q_kv_rmsnorm은 Ascend(#872)와 다모아카데미 XuanTie(#888)에서 동시에 구현.

1.6 컴파일 및 통신: Moore Threads 상주 GEMM과 SPMC 메인라인 진입, FlagCX 두 업체 디바이스 인터페이스 보완(10-29)

날짜: 2026-10-29　출처: FlagTree PR #1294 · FlagTree PR #1459 · FlagCX PR #678 · FlagCX PR #681 · FlagCX PR #679

  • Moore Threads: [MThreads][TLE]의 상주 GEMM 파이프라인과 SPMC 동기화가 메인라인에 진입(#1294, 63개 파일 +6192줄 -403줄). 이 커밋은 기존 파일을 옮긴 것이 아니라 현재 main의 pipe, warp specialize 및 SQMMA 표현을 기반으로 재이전한 것이며, 기존에 두 세트로 나뉘어 있던 컴파일러(공통 버전은 addmm/baddbmm용, SPMC 버전은 bmm용)를 하나의 슈퍼셋으로 통합했다: 동적 루프 내 stage와 phase 진행, 단일 생산자 대 다수 소비자, 명명된 읽기와 암시적 읽기, 세그먼트 완료와 소비자 에포크 도출, 그리고 단일 발행, 융합 소비자 및 16 warp 상주 경로를 지원한다.
  • Tsingmicro: 백엔드를 내부 Triton 3.6 개발 라인에 동기화(#1459, 27개 파일 +2264줄 -407줄), third_party/tsingmicro/만 수정 — FlagGems 측의 벤더 연산자 디스패치에 필요한 발행별 정밀도 인터페이스, 외부 CoreIR 진입점 및 런타임 어댑터를 보완하고, Tx81 코드 생성과 DMA, RDMA, WDMA의 CRT 결함을 수정했다.
  • Kunlunxin: FlagCX에 XPU의 디바이스 IR 진입점을 추가하여 FlagTree 링크를 지원(#678, 5개 파일 +178줄 -21줄).
  • Iluvatar CoreX: FlagCX의 Device API 백엔드에 Atomic::load의 획득 의미론을 보완(#681, 3개 파일 +359줄 -37줄). 이전에는 load(..., Acquire)와 load(..., Relaxed)가 동일한 명령을 발행하여, 관찰자가 플래그를 본 후 무효화 배리어가 없었다. 이번 커밋은 읽기 후 펜스, 스코프별 강도 선택으로 변경하고, launchKernel의 주소 공간 기호와 getLastError 슬롯을 보완했다. 시스템 스코프는 아직 구현되지 않았는데, ivcore11에 해당 메모리 배리어 명령이 없기 때문이다.
  • AMD: ROCm에서 SGLang의 텐서 병렬을 구동 성공(#679, 6개 파일 +77줄 -19줄) — eventElapsedTime 구현 보완, torch.bool을 flagcxUint8에 매핑, USE_AMD 테스트 빌드 분기 추가; R9700 듀얼 카드에서 AllReduce, ReduceScatter, AllGather, Broadcast, Send/Recv 및 그래프 캡처의 AllReduce 결과가 정확하며, Qwen3.5-9B와 Qwen3.6-35B-A3B-FP8이 TP=2에서 서비스 가능하다.

1.7 빌드와 릴리스: Hygon DTK 26.10 8건 병합, Ascend rpm 목표와 2.3.0 이미지 설명 (10-29)

날짜: 2026-10-29　출처: build-infra PR #1554 · build-infra PR #1558 · build-infra PR #1565 · build-infra PR #1566 · build-infra PR #1557 · build-infra PR #1560

  • DTK 26.10 전체 체인: 여덟 건의 머지 순서 자체가 하나의 트러블슈팅 체인입니다. 첫 버전 컨테이너와 구성이 반영된 후(#1554, #1555), 이미지는 여전히 빌드도 스케줄도 불가능했습니다. #1558은 base/hygon-dtk26.10이 여전히 /opt/dtk를 dtk-26.04로 가리키고 있으며, .github/build-config.yml에 해당 항목의 runner 오버라이드가 없으면 h20 기본값으로 되돌아간다고 지적했습니다. 이어서 torch 2.13.0+dtk2610의 libtorch_global_deps.so가 libmpi.so.40과 libibverbs.so.1을 직접 링크하는데, 26.04의 wheel은 이 두 soname을 패키지 내부에 해시해 넣었기 때문에, 이 라인은 기본 이미지에 libopenmpi3t64를 보강하고(#1564), 빌더에 libopenmpi3를 보강해야 합니다(#1565).
  • 버전 라인: 동일 런타임이 python 3.12로 고정되어 기존 cp310의 hcu wheel을 해석할 수 없게 되었습니다. #1562는 deadsnakes 3.12로 cp312의 hcu 빌더를 재구성하고 DTK 26.10의 Ubuntu22.04 SDK를 설치했으며, #1566은 다시 hcu-dtk2610을 wheel 릴리스 라인의 대상 옵션에 추가하여 flagtree==0.7.0+hcu3.6이 일반 flagtree로 Hygon 소스에 릴리스될 수 있게 했습니다.
  • Ascend rpm: FlagTree의 Ascend rpm 대상이 새로 추가되었습니다(#1557, 44줄 추가 4줄 삭제). 컴파일 대상은 Ascend 전달 파이프라인이 산출한 cp311과 aarch64 wheel이며, 이는 openEuler 24.03의 aarch64에 정확히 대응하므로 한 줄만 활성화했습니다. 이는 벤더 SDK와 하드웨어에 의존하지 않는 첫 번째 rpm 라인이기도 합니다.
  • 2.3.0 징후: 런타임 이미지 설명이 09:44와 18:26에 두 차례 갱신되었으며(#1552, #1561), changelog 날짜는 hygon-dtk26.10 기준으로 기록되었습니다(#1560). 그러나 community 저장소의 release/2.3/release-2.3.yaml은 여전히 404로, 2.3의 릴리스 목록이 아직 수립되지 않았음을 보여주며 현재 진행 상황은 빌드 단계에 머물러 있습니다.
  • 릴리스 효율: 그 외에 vllm 재패키징 의존성이 PEP 503 페이지 파싱으로 전환되었고(#1543), actions/setup-python이 7.0.0에서 7.1.0으로 업그레이드되었습니다(#1550).

1.8 양자 라인: FlagQuantum 60건 커밋, CS-01부터 CS-07까지 합성 파이프라인 관통(10-29)

날짜: 2026-10-29　출처: FlagQuantum 저장소 · FlagQuantum PR #960 · FlagQuantum PR #964 · FlagQuantum PR #966 · FlagQuantum PR #967 · FlagQAI 저장소

  • 규모: FlagQuantum은 하루 60건의 커밋, 15건의 병합으로, 모두 동일한 라인인 양자 회로 합성(CS 시리즈)에 집중되었습니다. 저장소 내 docs/roadmap/와 docs/api-changes/에는 FQ-SYNTH-CS01..CS07-20261029 기준으로 10건의 사양 및 인도 문서가 아카이빙되었습니다.
  • 파이프라인: CS-01은 코히런트 정수 구성의 의미 경계 정의와 검증, CS-02는 순수 산술 커널로 코히런트 덧셈을 낮추기, CS-03은 곱셈과 코히런트 다항식 처리, CS-04는 제한된 Python 워크플로우 연결, CS-05는 라이프사이클과 워크스페이스 스케줄링 추가, CS-06은 세 단계(실행 계약, 후보 비용 선택, 단일 사용자 워크플로우)로 나누어 구현, CS-07은 레지스터 의미와 프로그램 수용 단계로 진입했습니다. 같은 날 이식 가능한 .fqx 실험 파일의 저장 및 로드(#960)와 fq.run의 검사된 프로그램 실행(#964)도 추가되었습니다.
  • 검토 중: CS07-C의 제한된 네이티브 Qmod 프런트엔드(#967)가 17:30에 개설되어, 출력이 하나뿐인 부호 없는 main을 기존 컴파일러의 레지스터 및 표현식 모델로 번역하며, 텍스트를 실행하지 않고, Python 호출 가능 객체를 생성하지 않으며, 백엔드를 선택하지 않습니다.
  • 동반 FlagQAI: 동일 소스의 FlagQAI(10-10 저장소 생성)는 하루 11건의 커밋, 4건의 병합으로, 로컬 양자 워크벤치 웹 페이지와 네이티브 Agent 통합(#3), 새로고침 후 팔로우 환경설정 유지 수정(#4)을 추가했습니다. 저장소 내 README는 “의도로부터 회로 합성”을 제품 방향으로 명시할 뿐 완료된 역량으로는 규정하지 않으며, 현재 검증 범위는 로컬 회로 시뮬레이션과 하나의 고정 안자츠(ansatz) 2비트 변분 경로뿐입니다.
  • 판단: 이 라인은 본 스택에서 독립도가 가장 높습니다—멀티칩 적응은 하지 않고, “과학 문제를 실행 가능한 회로로 번역”하는 미들 레이어만 담당합니다. 그 가치는 2.x 주기에 칩과 무관한 소프트웨어 스택 사용 사례를 제공한다는 데 있습니다.

1.9 나머지 저장소: OpenCourse 교재 재구성, FlagScale과 TransformerEngine-FL CI 수렴 (10-29)

날짜: 2026-10-29　출처: OpenCourse 커밋 · FlagScale PR #1315 · TransformerEngine-FL PR #142 · optest PR #18 · FlagOps PR #18

  • OpenCourse: 세 건의 커밋으로 과정 자원 재구성(17:07, 19:59)과 교사 발전판 목차 명칭 변경(21:53)을 수행하고, 실험 메인라인(lab mainline)을 추가했습니다. 이는 커뮤니티가 지속적으로 추진하는 글로벌 교사 발전 계획과 같은 배치입니다.
  • FlagScale: 테스트 전략, 영향받는 라우팅, 실행 증거 게이트를 하나의 세트로 통일했습니다(#1315). 검토 중인 측면에서는 새로운 훈련 스택 작업이 보입니다: DeepSeek-V4의 업스트림 동기화 1/N과 2/N, 그리고 HF와 MCore의 DCP 경량 상호 변환(#1319).
  • TransformerEngine-FL: FlagCICD v1을 구현하고 L0~L4 테스트 등급과 계획 기반 실행을 도입했습니다(#142).
  • optest와 FlagOps: optest는 CI의 대상 참조와 연산자 테스트 진단 정보를 수정하고(#18), README를 재작성했습니다(#17). FlagOps의 견고한 체크아웃은 강제 종료된 fetch가 남긴 오래된 git 잠금을 정리했습니다(#18).

2. 뉴스 보도와 생태계

2.1 MiniCPM-OCR 듀얼 모델 Day0 12개 플랫폼 적응, Damo Academy XuanTie 처리량 네이티브 대비 98.7% 달성 (10-29)

날짜: 2026-10-29　출처: FlagOS Day0 적응 MiniCPM-OCR & Jev · FlagRelease 모델 카드 입구 · vllm-plugin-FL 문서 · Torch-FL 문서

  • 모델: 몐비즈니스 인텔리전스가 OpenBMB와 함께 MiniCPM-OCR 시리즈를 오픈소스로 공개했다. 1.3B의 MiniCPM-OCR 1.0은 스캔, 촬영, 휘어짐, 재촬영 등 실제 문서 시나리오를 대상으로 하며, 텍스트·수식·복잡한 표 파싱과 핵심 정보 추출을 지원한다. 공식 평가에서 Real5-OmniDocBench 93.68점을 기록했고, DSpark 디코딩 가속 백엔드를 도입해 엔드투엔드 효율이 55% 향상되었다. 2B의 MiniCPM-OCR Jev는 “AI 품질 검사원” 역할을 맡아 파싱 결과에 대한 신뢰도 점수를 산출하고 서로 다른 OCR 모델과 연동할 수 있으며, JevOCRBench에서 전체 AUROC 0.936으로 Qwen3.5-397B-A17B의 0.938에 근접했다.
  • 플랫폼 및 경로: Damo Academy XuanTie, NVIDIA, Huawei Ascend, Hygon, Kunlunxin, MetaX, Moore Threads, Qingwei Zhineng, Iluvatar CoreX, Xiwang, Mac(ARM), Bitsy Technology 등 12개 플랫폼을 지원한다. Jev는 Torch-FL로 연동되고, OCR 1.0은 추론 프레임워크 플러그인(vLLM-plugin-FL 또는 SGLang-plugin-FL)으로 연동되며, 하부는 모두 FlagGems의 연산자 구현과 FlagTree의 컴파일 지원을 사용한다. 버전 기준은 vLLM v0.24.0, vllm-plugin-FL v0.3.0, FlagGems v5.4.0이다.
  • 성능 기준: Jev는 NVIDIA에서 Torch-FL + FlagGems + FlagTree 경로로, 12개 샘플, batch 1, 단일 카드 BF16 환경에서 평균 판별 시간 76.2밀리초, 네이티브 62.7밀리초로 실제 연산 처리량은 네이티브의 82.3%이다. Damo Academy XuanTie에서는 평균 63.56밀리초로 처리량이 NVIDIA H100 네이티브의 98.7%에 달한다. OCR 1.0은 Damo Academy XuanTie에서 vLLM-plugin-FL + FlagGems + FlagTree 경로로, 양측 모두 단일 카드 BF16(피크 연산 성능은 989 TFLOPS와 123 TFLOPS 기준)이며, 피크 기준 정규화 후 단일 문서 P50 처리량은 네이티브의 169.3%, 배치 시나리오는 137.1%이다.
  • 엣지 디바이스: ARM 측은 Mac과 Bitsy Technology를 지원한다. Jev는 M5 CPU만 사용하여 12개 샘플에서 평균 단일 페이지 블록 판별 1.2초, 중위값 895밀리초이며, 선행 전체 페이지 OCR 파싱은 포함하지 않는다. 구현상 BF16 가중치와 판별 헤드를 유지하고, SME2 매트릭스 명령으로 주요 선형 레이어를 가속하며, Triton TLE Raw를 통해 연산자 실행 경로에 연동한다.
  • 관찰: 이는 최근 첫 번째로 “크로스 칩 처리량”과 “엣지 지연 시간”을 동일 기준 아래 제시한 적응 설명이다. 98.7%는 실제 처리량 비율이고, 169.3%는 피크 연산 성능으로 정규화한 비율로, 두 값은 서로 대체할 수 없다. 또한 글에서는 169.3%가 성립하는 전제가 단일 카드가 더 빠르다는 것이 아니라 저피크 연산 성능 플랫폼의 활용률이 더 높다는 점임을 사실대로 밝히고 있다.

2.2 CSDN 기술 라이브: 하나의 플러그인으로 열 개 칩의 추론 적응 구현 (10-29)

날짜: 2026-10-29　출처: 라이브 페이지: 대형 모델 추론 구원투수 — 하나의 플러그인으로 다중 칩 적응 해결

  • 사실: FlagOS 커뮤니티가 10-29 16:25에 등록하고 19:00에 방송을 시작한 기술 라이브로, 주제는 sglang-plugin-FL의 크로스 칩 추론 _적응_이다. 이 플러그인은 SGLang 위에 구축된, 커널 소스 코드를 침투하지 않는 out-of-tree 외부 추론 플러그인이다.
  • 기술 요점(페이지 요약): ATen 연산자 교체, 융합 연산자 스케줄링, 통합 통신 추상화, PD 분리 하의 KV Cache 전송, Empty 모드의 의존성 분할 등의 메커니즘을 통해 서로 다른 하드웨어와 연동_한다. 소개 기준으로 Ascend, Hygon, Kunlunxin 등 열 개 칩 플랫폼에 _적응 완료했다고 밝히고 있다.
  • 대응 코드 측면: 이번 모니터링 기간 내 sglang-plugin-FL에는 6건의 검토 중 PR 업데이트가 있었으며, Ascend와 Iluvatar CoreX의 SGLang 0.5.18 기반 Empty 런타임 적응(#160, #139), Kunlunxin의 0.5.18 업그레이드(#155), 그리고 네이티브 Mooncake PD 제어를 재사용하여 범용 FlagCX 전송으로 전환(#142) 등이 포함된다. 라이브 내용과 코드 진행 방향은 일치한다.
  • 관찰: 커뮤니티 측 콘텐츠 리듬은 “발표회식 강연”에서 “플러그인별로 분해한 단일 기술 라이브”로 전환되었으며, 이번 방송은 10-22의 대학 라운드테이블, 10-15의 연산자 바운티 챌린지와 함께 연속적인 기술 전파 라인을 구성한다.

2.3 채널 검증: HN과 Zhiyuan 커뮤니티 신규 히트 없음, CSDN 칼럼에 신규 기고 1건·라이브 1건 추가 (10-29)

날짜: 2026-10-29　출처: HN Algolia · Zhiyuan 커뮤니티 · CSDN FlagOS 칼럼

  • CSDN 칼럼: 페이지의 15개 항목을 페이지별로 확인한 결과, 모니터링 기간 내에 두 건이 새로 추가된 것을 확인했다. 10-29 11:19에 게시된 MiniCPM-OCR 및 Jev의 Day0 적응 기사(2.1 참조), 그리고 10-29 16:25에 등록되어 19:00에 방송된 sglang-plugin-FL 라이브(2.2 참조)이다. 페이지 상단에 위치한 GLM-5.3-Flash(8-28), Qwen3.8-Flash-Next(8-27) 및 LightX2V 접목 관련 세 건의 기사는 8월 하순의 오래된 기사로, 모니터링 기간에 포함되지 않는다.
  • HN: 8개 쿼리(FlagOS, FlagGems, FlagScale, FlagTree, BAAI, FlagQuantum, FlagSparse, flagos-ai)가 4일 모니터링 기간 내에 6~30건 적중했으나, 제목과 본문 직접 일치 기준으로는 모두 0건으로, 동명이인 오적중에 해당한다.
  • Zhiyuan 커뮤니티: 홈페이지와 검색 페이지 모두 모니터링 기간 내 소프트웨어 스택 관련 신규 항목이 없다. 검색 페이지는 클라이언트 렌더링 방식이라 항목 목록을 수집할 수 없어, 홈페이지 확인을 기준으로 한다.
  • gnews: 24개 중영문 쿼리가 모니터링 기간 내 총 30건 적중했으며, 제목과 본문을 기준으로 건별 필터링한 결과 FlagOS와 관련된 것은 단 한 건이다. JuShenZhiJia 10-29의 HuiXi Intelligent 참석 기사로, 내용은 10-17부터 10-18까지 열린 2026 인공지능 오픈 컴퓨팅 콘퍼런스 겸 ZhongZhi FlagOS 기술 콘퍼런스를 가리키며, 회의 후 확산 기사에 해당하여 모니터링 기간 내 신규 이벤트가 아니므로 별도 항목으로 기재하지 않는다. 나머지는 커촹반 시황, 이사회 결의, 단지 투자 유치 및 펀드 보유 관련 기사로, 제목 키워드 기준 일괄 제외한다.
  • 멤버 공식 웹사이트: 8개사 점검 중 MetaX 공식 웹사이트에 10-29 신규 항목 《Token 효율에서 오픈소스 협업까지, AI Infra의 다음 10년을 함께하다｜MetaX CNCC 2026 분과 포럼 리뷰》가 있으며, 회의 리뷰에 해당하여 소프트웨어 스택 변경과는 무관하다. Moore Threads 공식 웹사이트 최신 항목은 10-28의 3분기 보고서 도해이다. Iluvatar CoreX, Hygon, Cambricon, Enflame, QingWei 5개사 목록에는 10-29부터 10-30까지 신규 항목이 없다. Horizon Robotics는 수집에 실패하여 목록에 보이는 내용을 기준으로 한다.

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

3.1 Hygon: DTK 26.10, 컨테이너부터 wheel까지 전 체인 적용(10-29)

날짜: 2026-10-29　출처: build-infra PR #1554 · build-infra PR #1558 · build-infra PR #1562 · build-infra PR #1563 · build-infra PR #1565 · FlagAttention PR #109 · FlagTrain PR #35

  • 컨테이너 계층: DTK 26.10의 기본 컨테이너와 런타임 구성을 추가했습니다(#1554 +78줄, #1555 +21줄). 최초 반영 시 “FlagCX가 아직 빌드되지 않았으므로 이번 단계에서는 포함하지 않는다”고 명시했습니다. 수정 커밋 #1558은 두 가지 블로커를 한 번에 해결했습니다: base/hygon-dtk26.10이 /opt/dtk를 dtk-26.04로 가리키는데 SDK는 실제로 /opt/dtk-26.10에 풀리는 문제, 그리고 빌드 매트릭스에 해당 항목의 runner 커버리지가 없어 h20으로 폴백되는 문제입니다.
  • 의존성 계층: torch 2.13.0+dtk2610의 전역 의존성이 libmpi.so.40을 직접 링크하는데, 24.04 기본 이미지에는 이를 제공하는 패키지가 없으므로 libopenmpi3t64를 보충했습니다(#1564). FlagCX의 빌더는 22.04 자체 포함 환경을 사용하고 패키지명이 libopenmpi-dev이므로 별도로 보충했습니다(#1565). 같은 커밋은 26.04의 wheel이 libmpi와 libibverbs를 패키지 내부에 해시로 포함하므로 기존 빌더가 이 두 시스템 라이브러리를 전혀 필요로 하지 않았다는 점도 지적했습니다—이는 버전 간 빌드 가정 변화의 직접적인 증거입니다.
  • 컴파일 및 통신 계층: FlagTree에 cp312용 hcu 빌더를 추가하고 DTK 26.10 SDK를 설치했으며(#1562), hcu-dtk2610이 wheel 릴리스 대상에 진입했습니다(#1566). FlagCX의 dtk2610 wheel 라인은 flagcx==0.14.1+dtk2610으로 시작했습니다(#1563).
  • 연산자 측: FlagAttention은 Hygon에서의 FP8 MSA 경로를 제거하고 테스트 임포트를 수정했습니다(#109). FlagTrain의 multi_tensor_adam은 Hygon을 1급 백엔드로 포함했습니다(#35). 심사 중인 측면에서는 FlagCX에 Hygon bitcode 빌드가(#667), FlagScale에 DCU 하드웨어 상태 샘플링이(#1299) 있습니다.
  • 판단: Hygon 라인의 가치는 새로운 기능이 아니라, “새 SDK가 가져온 soname 및 인터프리터 버전 변화”를 하루 만에 컨테이너, 빌더, wheel 세 곳에서 수정하고 재사용 가능한 진단 경로를 남긴 데 있습니다(#1558과 #1565의 본문이 바로 그 경로의 기록입니다).

3.2 Tsingmicro: Triton 3.6 백엔드 동기화 병합 및 전용 태그 발행 (10-29)

날짜: 2026-10-29　출처: FlagTree PR #1459 · FlagTree 태그 · FlagTree PR #1468 · vllm-plugin-FL PR #642

  • 병합 내용: Tsingmicro 백엔드를 내부 Triton 3.6 개발 라인과 동기화했습니다(#1459, 27개 파일 +2264줄 -407줄). third_party/tsingmicro/만 수정했습니다: 벤더 연산자 배포에 필요한 발사별 정밀도 API(precision.py), 외부 CoreIR 진입점과 런타임 어댑터를 보충하고, Tx81의 여러 코드 생성 문제를 수정했으며, DMA, RDMA, WDMA, gather-scatter 및 산술 관련 CRT 결함을 수정했습니다.
  • 버전 조치: 같은 날 11:09에 Tsingmicro 3.6 전용 태그를 발행했으며, 10-26의 Moore Threads 3.6 태그와 동시기 시퀀스를 구성합니다.
  • 심사 중 및 생태계: vllm-plugin-FL의 심사 중인 #642는 Tsingmicro의 eager TXDA 백엔드를 vLLM 0.28.0에 적응시킵니다. FlagGems 측의 Tsingmicro 참조 구현은 10-29에 여러 건의 테스트 픽스처 수정이 있었습니다(1.4 참조).
  • 판단: Tsingmicro는 “내부 개발 라인”을 직접 오픈소스 백엔드에 동기화하는 소수 벤더 중 하나입니다. 대가는 매 동기화의 큰 규모(이번 27개 파일)와 벤더 SDK 시맨틱에 따라 검토해야 한다는 점이고, 이점은 FlagGems와 FlagTree의 인터페이스 약정이 벤더 내부 진행에 맞춰 앞서 나갈 수 있다는 점입니다.

3.3 Kunlunxin: XPU3의 foreach 융합 체인과 상수 그리드 마무리 (10-29)

날짜: 2026-10-29　출처: FlagGems PR #7116 · FlagGems PR #7968 · FlagGems PR #7973 · FlagGems PR #7974 · FlagCX PR #678 · FlagGems-sglang PR #248

  • 퓨전 커널: foreach 패밀리가 XPU3에서 「개별 연산자 구현」에서 「List 실행기」로의 수렴을 완료했다——cos/exp/sin/addcdiv/lerp는 통합 실행기를 사용하고(#7116), ceil은 마스크 없는 퓨전 커널을 사용하며(#7604), tanh/expm1은 인플레이스 퓨전 커널을 사용한다(#7608).
  • 런치 정확성: 이어서 네 건의 수정이 런치 파라미터에 집중되었다——fmin과 t_copy의 1차원 경로는 상수 런치 그리드로 전환하고(#7966, #7973), foreach의 스칼라 dtype 분기는 상호 배타적으로 변경하며(#7974), foreach add의 리스트 슬롯은 program_id(0)에서 도출하도록 변경했다(#7968). 이는 성능 최적화가 아니라 「동일한 연산자가 다중 분기에서 잘못된 슬롯을 선택하는」 정확성 수정이다.
  • 인터페이스 표면: FlagCX는 FlagTree 링크용 XPU 디바이스 IR 진입점을 추가했으며(#678), FlagGems-sglang의 fill_bonus_tokens는 새로운 tle.raw 방언 API에 적응했다(#248).
  • 심사 중: vllm-plugin-FL의 P800의 vLLM 0.28.0 대응(#585), sglang-plugin-FL의 Kunlunxin 0.5.18 업그레이드(#155), 그리고 FlagGems 측의 일련의 P800 정확성 이슈.

3.4 MetaX: 그룹 GEMM의 INT8 및 FP8 경로, TP2 디코드 스케줄링 (10-29)

날짜: 2026-10-29　출처: FlagGems PR #6950 · FlagGems-vllm PR #1025 · FlagAttention PR #108 · FlagTree PR #1481 · FlagTree PR #1471

  • 그룹 GEMM: grouped_mm_w8a8는 INT8과 FP8을 동시에 지원합니다(#6950, 7개 파일에 1220줄 추가). 벤치마크의 형태는 GLM-5.2가 PPU SGLang TP=8에서 수집한 실제 호출 재생에서 비롯되었으며, 288만에서 324만 회 호출의 두 그룹 형상으로, 총 26개의 고유 지오메트리와 257개의 전문가를 포함합니다. 베이스라인은 벤더 라이브러리의 ContinuousGroupedGEMM이며, 양측은 동일한 INT8 입력, FP32 스케일링 및 전문가 그룹화를 받습니다.
  • 디코딩 스케줄링: FlagGems-vllm 측은 TP2 packed decode의 Split-KV 스케줄링과 컴퓨트 타일 재배치(#1025)를 진행하며, 목표는 좁은 타일에서의 디코딩 처리량입니다.
  • 어텐션: FlagAttention은 C550에서 Triton 융합 AttnRes 포워드(#108, 3개 파일에 268줄 추가)를 새로 추가했으며, FP16과 BF16, 선택적 출력 RMSNorm과 어텐션 가중치를 지원하고, RMS 스코어링, 온라인 softmax 및 잔차 집계를 융합하며 TLE에 의존하지 않습니다. D=7168, BF16에서 (2,1)의 0.075밀리초에서 (9,8192)의 1.496밀리초까지이며, 작성자는 FLA를 사용할 수 없으므로 속도 향상 비율을 주장하지 않는다고 명시했습니다.
  • 컴파일러: FlagTree는 Metax에서의 CompiledKernel 메타데이터 검사(#1481, 관련 이슈 #1473)를 수정했으며, 심사 중인 #1471은 MetaX의 CommonIR에 set_layout과 레이아웃 자동 튜닝을 추가합니다.
  • 벤더 측: MetaX 공식 웹사이트는 10-29에 CNCC 2026 분과 포럼 회고 《Token 효율성에서 오픈소스 협업까지, AI Infra의 다음 10년으로 함께 나아가다》를 게시했으며, 이는 회의 측 내용에 속합니다.

3.5 Moore Threads: TLE 상주 GEMM과 SPMC 동기화 메인라인 진입 (10-29)

날짜: 2026-10-29　출처: FlagTree PR #1294 · FlagGems-vllm PR #970 · FlagTree PR #1451 · vllm-plugin-FL PR #575

  • 컴파일러: [MThreads][TLE]의 상주 GEMM 파이프라인과 SPMC 동기화가 메인라인에 진입했습니다(#1294, 63개 파일에 6192줄 추가 403줄 삭제). 이전에 각각 addmm/baddbmm과 bmm을 서비스하던 두 컴파일러 세트를 하나의 슈퍼셋으로 통합했으며, 기능으로는 동적 루프에서의 stage와 phase 진행, 단일 생산자 다중 소비자, 명명된 읽기와 암시적 읽기, 분할 및 그룹 완료, 소비자 에포크 추론, 그리고 단일 발사, 융합 소비자 및 16 warp 상주 경로가 포함됩니다. PR 본문은 이번 변경이 컴파일러, 프론트엔드 및 테스트만 포함하며 FlagGems 연산자 코드는 포함하지 않는다고 명시했습니다.
  • 추론: FlagGems-vllm 측은 현재 CI 컴파일러에 맞춰 MUSA의 FP8 가변 길이 어텐션(#970)을 재조정했습니다.
  • 심사 중: FlagTree의 #1451은 WGMMA의 warp 선택을 업스트림 MMAv3에 정렬합니다. vllm-plugin-FL의 #575는 MUSA를 vLLM 0.28.0에 적응시킵니다. 또한 MUSA의 단축 형상 폴백 브랜치(FlagFFT의 codex/musa-shortfall)가 기능 브랜치에서 진행 중입니다.
  • 판단: Moore Threads의 투자 중심은 연산자 수량보다 컴파일러 측에 있습니다. 상주 GEMM과 SPMC는 addmm/bmm 같은 주력 연산자가 MUSA에서 사용 가능한 성능에 도달하기 위한 전제이며, 이 역량은 Ascend와 MetaX의 TLE 라인에서도 동시에 재사용됩니다.

3.6 Enflame, Ascend, Damo XuanTie: 어텐션과 정규화 연산자의 네 갈래 라인 (10-29)

날짜: 2026-10-29　출처: FlagAttention PR #104 · FlagAttention PR #106 · FlagAttention PR #116 · FlagAttention PR #103 · FlagGems PR #6586 · Torch-FL PR #683 · FlagGems-vllm PR #888

  • Enflame: FlagAttention에 같은 날 세 건 병합 — MiniMax M3 희소 어텐션의 prefill 및 decode 최적화(#104, 2개 파일 +2873줄 -2516줄), chunk KDA 연산자 최적화(#106), 융합 어텐션 잔차 연산자(#116); FlagTree 측은 Enflame CI(#1468)와 TLE 단위 테스트(#1470)를 보완했으며, #1405에서 swiglu의 정밀도 오차 수정을 심사 중이다.
  • Ascend: Parallax 어텐션의 3단 구현(prefill, decode, kvcache, #103, 10개 파일 +2738줄)을 신규 추가, 인과 마스크, 슬라이딩 윈도, GQA 및 가변 길이 입력을 지원하며 FLA 대비 대부분의 학습 형상에서 1.0~8.74배 가속; FlagGems는 cat(#7989)과 log_ 그리드 패딩 재실행(#6586, 5.4.0-rc2 백포트)을 수정; FlagGems-vllm은 fused_q_kv_rmsnorm을 Ascend에 이식하고(#872), lightning-indexer의 사용자 정의 연산자 이름을 tle_raw.call로 변경(#944); Torch-FL은 Ascend가 FP32 matmul 정밀도를 따르도록 하고 그래디언트 상주를 유지(#683).
  • 다모아카데미 XuanTie: fused_q_kv_rmsnorm이 다모아카데미 XuanTie 플랫폼에도 이식됨(#888, 17:07 병합); PPU 측은 10-29에 FlagTrain의 multi_tensor_adam 전 백엔드 지원(#35, PPU는 1급 백엔드)과 심사 중인 PPU GLA 최적화(FlagAttention #117은 Hygon, PPU는 별도 브랜치)가 있음; MiniCPM-OCR의 Day0 적응으로 다모아카데미 XuanTie의 처리량이 NVIDIA 네이티브의 98.7%까지 상승(2.1 참조).
  • 판단: 세 곳이 같은 날 각각 하나의 어텐션 경로를 선택했다 — Enflame은 희소 및 KDA, Ascend는 Parallax와 융합 RMSNorm, 다모아카데미 XuanTie는 융합 RMSNorm과 단말 측 디코딩. 어텐션 계층의 파편화는 여전히 심화되고 있으며, 아직 크로스 벤더 통합 하향 구현은 등장하지 않았다.

3.7 Iluvatar CoreX: Tiangai 300 최초 실기 시연 공개, 단일 카드 처리량 H200의 1.05배 주장(10-28)

날짜: 2026-10-28(시연) / 2026-10-29(보도)　출처: Pandaily 보도 · South China Morning Post 보도 · FlagCX PR #681 · sglang-plugin-FL PR #139

  • 데모 사실: Iluvatar CoreX가 10-28 상하이 미디어 오픈 데이에서 톈가이 300 범용 GPU를 처음으로 실기 시연했다. 이전에 회사가 이 칩에 대해 공개한 자료는 아키텍처와 로드맵 위주였으며, 실행 가능한 시스템은 없었다.
  • 주장과 기준: 회사는 톈가이 300이 최초로 실측 성능이 NVIDIA H200 수준에 도달한 국산 범용 GPU라고 주장하며, 제3자 테스트 환산 기준 단일 카드 전체 처리량이 H200의 1.05배이고 텍스트-이미지, 텍스트-비디오 등 복잡한 멀티모달 작업에서도 H200을 초과한다고 밝혔다. 이 수치는 회사 측 기준이며, 테스트 방법, 사용 모델, 워크로드 조건은 모두 공개되지 않아 검증할 수 없다.
  • 스택 측 대응: FlagCX는 같은 날 Iluvatar를 위해 Device API의 획득 의미론을 보완했으며(#681, 1.6 참조), sglang-plugin-FL의 심사 중인 #139는 Iluvatar를 SGLang 0.5.18의 Empty 런타임에 적응시켰고, FlagTrain의 multi_tensor_adam은 이미 Iluvatar를 지원 백엔드로 등재했다(#35).
  • 판단: 하드웨어 기준의 대외 발표와 소프트웨어 스택 적응은 서로 다른 리듬의 두 축이다. 전자는 한 번의 발표회로 완료되지만, 후자는 Device API의 메모리 순서부터 추론 프레임워크의 런타임 적응까지 계속 보완해야 한다. 이번 모니터링 기간에 확인된 것은 후자가 지속적으로 보완되고 있다는 점이며, 전자의 수치는 여전히 검증 가능한 조건이 부족하다.

4. 요약 및 동향 관찰

  • 하드웨어 세대 전환 비용은 빌드 측면에 집중된다: DTK 26.10의 8건 머지 중 커널을 수정한 것은 한 건도 없으며, 전부 컨테이너 경로, 인터프리터 버전, runner 커버리지, soname 의존성이다. python 3.12와 torch 2.13.0+dtk2610은 기존 cp310 빌더를 전면 무효화했고, 26.04에서 26.10 사이에 libmpi와 libibverbs는 「휠에 해시로 포함」에서 「런타임 링크」로 바뀌었으며, 이런 변화는 노드별 실측으로만 발견할 수 있다.
  • 모델 Day0의 서사는 비교 가능한 숫자로 전환된다: MiniCPM-OCR의 적응 설명은 실제 처리량 비율(98.7%), 피크 정규화 처리량 비율(169.3%), 엣지 지연 시간(M5에서 1.2초, 중앙값 895밀리초)을 각각의 전제와 함께 제시했다. 이는 이 스택에서 최근 처음으로 「네이티브에 따라잡음」과 「활용률이 더 높음」을 분리해 서술한 자료이며, 단일 배수보다 참고 가치가 크다.
  • 테스트 인프라가 독립적인 주류로 부상한다: ref-as-candidate가 FlagGems와 FlagGems-sglang 두 저장소에 적용되었고, 같은 날 57건의 테스트 수정과 kernelgen-dev의 일일 자동 동기화가 함께 진행되면서 테스트는 「연산자 존재 여부」에서 「참조와 구현의 일치 여부」로 바뀌었다. 이 축의 산출물은 연산자 수에 드러나지 않지만, 이후 모든 백엔드 정렬의 신뢰성을 결정한다.
  • 양자 축은 자체 체계를 이룬다: FlagQuantum은 하루 60건의 커밋으로 CS-01부터 CS-07까지의 회로 합성 규격과 전달 문서를 체계적으로 아카이빙했고, FlagQAI는 동시에 로컬 워크벤치를 구축했다. 이는 다중 칩 적응과 무관하며, 2.x 주기에서 하드웨어와 분리된 유일한 소프트웨어 스택 주류다.
  • 관찰할 세 가지: 첫째, community 저장소의 release/2.3 목록은 아직 구축되지 않았지만 빌드 측면은 이미 2.3.0으로 회계 처리 중인데, 릴리스 노트가 보완될지 여부. 둘째, FlagCX v0.14.1과 FlagTree의 벤더별 3.6 태그 모두 Release 본문이 없어 다운스트림은 태그 이름에서 내용을 역추론할 수밖에 없는 점. 셋째, Megatron-LM-FL의 DeepSeek-V4 업스트림 동기화가 이미 [1/N]과 [2/N]을 열었는데, 두 주간 멈춰 있던 이 학습 스택이 실제로 푸시를 재개했는지 여부.

출처 검증표

출처 검증 결과
GitHub org 전체(61개 저장소) 21개 저장소가 모니터링 기간 내 푸시됨; 16개 저장소에 커밋 있음; 5개 저장소는 원자 보충 검증 경유(1개 저장소 커밋 있음, 1개 저장소는 gh-pages, 1개 저장소는 기능 브랜치, 2개 저장소는 PR 브랜치 및 이슈 활동)
커밋 검색 189건; FlagQuantum 60건, FlagGems 43건이 양대 대종
병합 PR 검색 183건; FlagGems 92건, build-infra 16건, FlagQuantum 15건
심사 중 PR 검색 253건 업데이트, 신규 오픈 84건; Megatron-LM-FL 10건은 최근 2주 만에 처음으로 규모 있는 업데이트
Release / Tag 원자 검증 31개 저장소; 모니터링 기간 내 신규 태그 1개(FlagTree Qingwei 3.6 전용 번호, 릴리스 본문 없음); FlagCX v0.14.1 아카이브 시간 10-29 10:55로 업데이트
org 이벤트 스트림 100건: PR 리뷰 코멘트 34건, PR 이벤트 34건, 푸시 13건, 이슈 코멘트 9건, 브랜치 생성 8건, 브랜치 삭제 1건, fork 1건
Google News RSS(중영문 24개 그룹) 30건 적중, 유효 1건(Huixi Intelligence 참가 기사, 10-17~10-18 대회를 지칭, 회의 후 확산 기사로 별도 기재하지 않음)
HN Algolia(8개 그룹) 4일 모니터링 기간 내 6~30건 적중, 제목과 본문 직접 일치 0건
CSDN FlagOS 칼럼 신규 글 1편(MiniCPM-OCR Day0, 10-29 11:19), 라이브 1회(10-29 19:00); 고관련 기존 글 3편의 검증 시점이 8월 하순으로 집계 제외
Zhiyuan 커뮤니티 홈페이지에 모니터링 기간 내 소프트웨어 스택 항목 없음; 검색 페이지는 클라이언트 렌더링으로 목록 추출 불가
회원사 공식 웹사이트(8개사) MetaX 10-29 회의 회고 1건 있음; Moore Threads 최신은 10-28 실적 도표 해설; Iluvatar CoreX, Hygon, Cambricon, Enflame, Qingwei 신규 항목 없음; Horizon Robotics 추출 실패

전체 출처 목록

lagos.csdn.net/6ae2bb2740858c2d8817187c.html>