모니터링 기간: 2026-10-22 06:00 ~ 2026-10-23 06:00 (베이징 시간, 24시간; 금요일 조간 보고서, 기간은 이전 데일리 리포트 마감 시점부터 연속됨).

출처: GitHub (org: flagos-ai 61개 저장소 전수 검증, 커밋 검색 135건, 병합 PR 163건 및 심사 중 PR 183건 검색, org 이벤트 스트림 100건, 31개 저장소 Release/Tag 원자 검증, 4개 저장소 Atom 폴백), Google News RSS (중영문 쿼리어 24조, 프록시 경유), HN Algolia (8조), CSDN FlagOS 칼럼, Zhiyuan 커뮤니티, 구신지자(JuShen ZhiJia) 및 Pandaily 원고 (상세 내용은 부록 출처 목록 참조).

이번 호 인덱스

  • 오늘의 핵심: 163건 병합으로 최근 일주일 최고치 경신; Hygon의 vLLM 0.28과 SGLang 0.5.18 듀얼 스택 당일 병합, FEP-0140과 FEP-0141 각각 첫 단계 이행; FlagQuantum이 M3 중성 원자를 설계 계약에서 실행 가능한 네이티브 Rydberg 동역학으로 격상 (10-22)
    1. 오픈소스 프로젝트 진행 (GitHub 동향)
      • 1.1 조직 리듬: 16개 저장소 푸시, 135건 커밋, 163건 병합, 대기열 정리 중, 신규 증가 수렴 (10-22)
      • 1.2 vLLM 0.28과 SGLang 0.5.18의 Hygon 라인 당일 병합 (10-22)
      • 1.3 FlagQuantum: 53건 커밋, 20건 병합, 네이티브 Rydberg 계약에서 코드로 전환 (10-22)
      • 1.4 FlagQuantum: 배포 거부, 벤더 퇴장 및 터미널 샘플링 제안 (10-22)
      • 1.5 FlagGems: 91건 병합, KernelGen 39건 배치 적용과 Kunlunxin 13건 최적화 병행 (10-22)
      • 1.6 FlagGems 테스트 메인라인: lukatao 61건, 철야로 14건 배치 개시하여 “직접 연결 후보”로 변경 (10-22 ~ 10-23)
      • 1.7 build-infra: Kunlunxin이 FlagTree 일곱 번째 백엔드로, flagcx 0.14.0을 전체 백엔드에 고정 (10-22)
      • 1.8 Torch-FL: Qingwei가 rocprofiler-sdk 연결, Kunlunxin 크로스 카드 복사가 peer 원시 연산으로 변경 (10-22)
      • 1.9 FlagTree: AMD RDNA prefill 경로 보완, MUSA 복사별 TME 캐시 (10-22)
      • 1.10 기타 저장소: FlagBLAS Iluvatar 및 Moore Threads GEMM, 대회 채널 2건, optest wheel 패키징 (10-22)
    1. 뉴스 보도와 생태계
      • 2.1 Pandaily가 영어로 FlagOS 2.2 체계 전환: 1454개 연산자, 약 27% 크로스 칩 향상, KernelGen 765개 신규 연산자 (10-22)
      • 2.2 Cross Dimension Intelligence가 Zhongzhi FlagOS 가속 계획 입안 선정: FlagOS-Robo와 AlohaMini 엣지 시연 (10-22)
      • 2.3 채널 검증: 후보 17건 중 2건 유효, CSDN 대학 원탁 라이브 추가, Zhiyuan 커뮤니티는 프레임워크 페이지만 확보 (10-22)
    1. 회원 기관 및 백엔드 벤더 심층 분석
      • 3.1 Hygon: 두 추론 플러그인 저장소 당일 업스트림 버전 정렬 완료 (10-22)
      • 3.2 Kunlunxin: 13건 연산자 최적화, FlagTree 일곱 번째 백엔드 추가 (10-22)
      • 3.3 Qingwei: 디바이스 타임라인 torch.profiler 진입, TX8110 실측 (10-22)
      • 3.4 Moore Threads와 Enflame: MUSA 캐시 지속성, GEMM 및 Enflame 전체 배치 업데이트 (10-22)
      • 3.5 Ascend, Iluvatar, MetaX 및 기타: 백엔드별 분산 소규모 진행, Horizon Robotics와 Cambricon 무소식 (10-22)
    1. 요약 및 트렌드 관찰
  • 부록: 출처 검증표 및 전체 출처 목록

오늘의 핵심: 163건 병합으로 최근 일주일 최고치 경신; Hygon 듀얼 스택 당일 정렬, 양자 스택이 M3를 계약에서 실행 가능 상태로 격상 (10-22)

날짜: 2026-10-22　출처: vllm-plugin-FL PR #576 · sglang-plugin-FL PR #138 · FlagQuantum PR #700 · build-infra PR #1468 (전체 내용은 부록 참조)

  • 리듬 측면: 61개 저장소 중 16개 저장소에 모니터링 기간 내 푸시가 있었고, 커밋 검색 135건, 병합 PR 163건, 리뷰 중 PR 183건이 모니터링 기간 내 업데이트되었습니다(이 중 신규 오픈 90건). 이전 기간(10-21: 22개 저장소, 164건 커밋, 151건 병합, 154건 리뷰 중, 64건 신규 오픈)과 비교하면 병합 8% 증가, 리뷰 중 19% 증가, 신규 오픈 41% 증가, 푸시 저장소 27% 감소, 커밋 18% 감소 — 대기열은 정리되고 있고, 신규 개발은 줄어들고 있습니다.
  • 버전 측면 첫 실현: Hygon의 vLLM 0.28.0과 SGLang 0.5.18 두 업스트림 버전 적응이 같은 날 병합되었습니다. 이는 10-21에 병합된 FEP-0140(vLLM 세 버전 라인)과 FEP-0141(SGLang 0.5.18 열 개 벤더) 이후 처음으로 「FEP 매트릭스에 따라 칸별로 착지」하는 실증이 나타난 것입니다.
  • 양자 스택이 설계 단계를 넘어섬: FlagQuantum 53건 커밋, 20건 병합. Core 측의 네이티브 Rydberg 프로그램, Simulation 측의 plan 1.7 동역학, Examples 측의 이동 원자 펄스 훈련 세 블록이 같은 날 병합되었습니다. 어제까지만 해도 두 개의 설계 계약서에 불과했던 중성 원자 노선이 오늘은 이미 실행 가능한 CPU 경로와 검수 수치를 갖추게 되었습니다.
  • 빌드 측 일곱 번째 백엔드: build-infra가 Kunlunxin(XPU)을 FlagTree 빌드 라인과 일상 빌드 행에 연결하여 enflame, hcu, tsingmicro, mthreads 이후 일곱 번째 백엔드가 되었습니다. PR 자기 설명은 「현재 집합의 마지막 행」이며, 같은 날 flagcx 0.14.0을 nvidia 전용에서 전체 백엔드의 명시적 의존성으로 고정했습니다.
  • 테스트 인프라 동시 개편: optest가 스크립트 집합에서 설치 가능한 wheel과 console commands로 바뀌었습니다. FlagGems 측에서는 한 사람이 61건을 병합했으며, 그중 23:40부터 23:47까지 한 번에 10건의 배치 PR을 열어 테스트 케이스를 래퍼 함수에서 직접 연산자 호출 또는 후보 주입 방식으로 변경했습니다.
  • 뉴스 측 이번 모니터링 기간 두 건의 유효 기사: 영문 매체 Pandaily가 2.2를 체계적으로 전언했고, 국내에서는 FlagOS-Robo의 정부 가속 계획 입안 사례가 나타났습니다. 소프트웨어 스택 외부의 이 두 건은 이번 모니터링 기간 유일하게 GitHub에서 오지 않은 정보 증분입니다.

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

1.1 조직 리듬: 16개 저장소 푸시, 135건 커밋, 163건 병합, 대기열 정리·신규 감소(10-22)

날짜: 2026-10-22　출처: flagos-ai 조직 저장소 · 커밋 검색 · 병합 PR 검색

  • 저장소 측면: 61개 저장소 중 16개 저장소에 모니터링 기간 내 푸시가 있었으며, 커밋 수 기준으로 FlagQuantum 53, FlagGems 29, build-infra 13, Torch-FL 12, FlagGems-sglang 8, FlagTree 5, FlagGems-vllm 4, FlagBLAS 3, optest 3, FlagTrain 2, FlagOps 2, FlagDNN 1 순입니다. docs, release-info, sglang-plugin-FL, vllm-plugin-FL 네 저장소의 푸시는 비기본 브랜치에 있었으며, 메인 브랜치에는 새로운 커밋이 없습니다.
  • 병합 측면: 병합된 PR은 163건이며, 저장소별로 FlagGems 91, FlagQuantum 20, build-infra 13, Torch-FL 12, FlagTree 6, optest 4, vllm-plugin-FL 4, FlagGems-vllm 4, FlagGems-sglang 3, FlagTrain 2, FlagBLAS 2, FlagOps 1, sglang-plugin-FL 1입니다. FlagGems와 FlagQuantum이 합계 68%를 차지합니다.
  • 심사 중 측면: 모니터링 기간 내 업데이트된 open PR은 183건이며, 그중 새로 열린 것이 90건입니다. 저장소 분포는 FlagGems 86, FlagGems-vllm 18, Torch-FL 13, vllm-plugin-FL 12, FlagTree 11, FlagTrain 6, FlagGems-Experimental 6, sglang-plugin-FL 5입니다. FlagGems-vllm과 TransformerEngine-FL의 신규 증가분은 벤더 측 융합 연산자에 집중되어 있습니다.
  • 생산성 측면: lukatao는 FlagGems에 61건을 병합했으며(해당 저장소의 67%), 전부 테스트 및 테스트 케이스 계약입니다. FlagQuantum 계정은 20건을 병합했습니다. tengqm은 build-infra 13건을 전담했습니다. lvyufeng은 Torch-FL에 11건을 병합했습니다. lvxu2020은 Kunlunxin XPU 라인에 6건을 병합했습니다.
  • 버전 측면: 모니터링 기간 내 새로운 릴리스는 없습니다. 최근 세 태그는 여전히 FlagTree의 0.7.1.dev1과 0.7.1.dev1+ppu3.6(10-20 20:11) 그리고 0.7.1a1+ascend3.5(10-19 13:01)이며, 모두 이전 각 호에 포함됩니다.
  • 이벤트 측면: org 이벤트 스트림 100건 중 PR 이벤트 43, 푸시 27, 브랜치 삭제 12, 브랜치 생성 9, 코멘트 4, 리뷰 3, 팔로우 2입니다. 브랜치 삭제 12건과 새 배치 PR이 같은 날 나타난 것은 “배치 브랜치는 병합 즉시 삭제”라는 파이프라인 관행을 반영한 것이며, 기능 롤백이 아닙니다.
  • 판단: 병합, 심사 중, 새로 열림 세 항목이 동시에 상승한 반면 커밋과 푸시 저장소 수는 하락한 것은 이번 분기에 드문 조합입니다. 이는 심사 처리량이 전 이틀(10-20~10-21 합계 약 300건 병합)의 적체를 소화하고 있음을 의미하며, 개발자가 당일 새로 작성한 코드량은 축소되었습니다. 이러한 리듬은 일반적으로 마일스톤 마감 전후에 나타납니다.

1.2 vLLM 0.28과 SGLang 0.5.18의 Hygon 라인 당일 병합(10-22)

날짜: 2026-10-22　출처: vllm-plugin-FL PR #576 · sglang-plugin-FL PR #138 · vllm-plugin-FL 저장소 · sglang-plugin-FL 저장소

  • vLLM 측(#576, 19개 파일, +1436/−288): Hygon BW1000 플러그인을 vLLM 0.28.0으로 업그레이드했으며, 배포 패키지 식별자는 0.28.0+empty, 모듈 버전은 0.28.0, 소스 베이스라인은 2cf0a6915이다. 검증 환경은 카드당 64 GiB, 컨테이너 내 일반 wheel 설치(편집 가능 설치 미사용), TP=2, 최대 모델 길이 4096, 최대 시퀀스 수 8, VRAM 활용률 0.85이며, eager와 FULL_AND_PIECEWISE 두 가지 그래프 모드를 각각 한 번씩 실행했다. 통신은 벤더 HIP/RCCL을 사용하며 FLAGCX_PATH는 설정하지 않았다.
  • 버전 퍼즐: PyTorch는 벤더 2.10.0(+das.opt1.dtk2604, DTK 26.04 유지)을 사용하고, FlagTree는 0.6.0+hcu3.6(wheel SHA256 접두사 0fd81f0e), Triton 배포판은 3.6.0+gitc73250c4.staging으로 벤더 Triton과 공존한다. 런타임 이미지는 vllm-plugin-fl:v0.28.0-hygon-ci이다.
  • 비교 가능성: 저장소는 설치된 1,944개의 FlagGems 소스 파일과 패키지 파일을 파일별로 대조했으며, 전부 e12a220 커밋과 일치했다(CRLF/LF 줄바꿈 차이만 존재). 그러나 설치 메타데이터의 버전은 여전히 0.1.0이다. 즉 버전 번호는 신뢰할 수 없고 내용은 검증 가능하며, 이처럼 ‘VCS 메타데이터 대신 내용으로 확인하는’ 방식은 최근 여러 차례 반복해서 나타났다.
  • SGLang 측(#138, 65개 파일, +4940/−369): Hygon BW1000의 empty 백엔드를 SGLang 0.5.18로 업그레이드했으며(tag 소스 71de97b, HCU 전용 Quark 임포트 패치 추가), attention, FLA 및 MoE 인터페이스에 적응하고 파이프라인 병렬화 환경의 협조적 종료 문제를 수정했다. 검증은 단일 머신 TP2의 eager 및 전체 디코드 그래프, 그리고 물리적 2노드 TP4/PP1 및 TP2/PP2의 eager 케이스를 포함한다. 파이프라인 게이트는 BF16, 컨텍스트 4096, 최대 동시성 16, VRAM 비율 0.70을 사용했다.
  • 버전 퍼즐: FlagTree 0.6.1+hcu3.6(Triton은 FlagTree가 제공하며 별도 Triton 미설치), FlagGems 5.4.0.dev0, 네이티브 FlagCX 0.13.0, 벤더 sglang-kernel 0.4.2.post2, flash-attn 2.8.3. CI 이미지는 sglang-plugin-fl:0.5.18-hygon-ci-20261015이며 sha256으로 고정했다.
  • 판단: 두 PR 모두 ‘empty 런타임 + 벤더 스택’ 노선을 따르며, 수용 대상은 ‘이미 적응됨’ 같은 모호한 표현이 아니라 구체적 버전 번호와 구체적 그래프 모드로 명시했다. FEP-0140에 따르면 vLLM 0.28은 11월의 메인 릴리스 버전이며 목표는 10개 벤더이다. FEP-0141에 따르면 SGLang 0.5.18은 10개 벤더를 커버하며 노드는 12월 중순 이전이다. Hygon은 첫 번째로 점등된 칸일 뿐, 나머지 9개 벤더가 이미 준비되었다는 의미는 아니다. 다음 관찰 지점은 동일한 0.28.0 버전이 Qingwei, MetaX, Enflame, Kunlunxin에서 같은 설치 경로를 재사용하는지 여부이다.

1.3 FlagQuantum: 53건 커밋, 20건 병합, 네이티브 Rydberg가 계약에서 코드로 (10-22)

날짜: 2026-10-22　출처: FlagQuantum 커밋 · PR #700 · PR #707 · PR #714

  • 총량: 53건 커밋, 20건 머지. 커밋은 전체 조직의 40%를 차지하며 머지 수는 두 번째로 많다. 직전 기간(84건 커밋, 34건 머지) 대비 규모는 절반으로 줄었으나 성격이 달라졌다. 직전 기간이 동적 회로의 Program IR과 다이어그램 생성 보완이었다면, 이번 기간은 중성 원자 물리가 문서에서 실행으로 내려온 것이다.
  • Core 프론트엔드(#700, 22개 파일, +2198/−16): 네이티브 Rydberg 제어가 더 이상 회로 어댑터를 빌려 쓰지 않고, Core가 ProgramRecord 위에서 직접 프론트엔드를 제공한다. 레코드에 타입화된 context와 control 필드가 추가되었고, 기존 검증기는 하나의 물리 profile만 받아들이며 CFG/SSA 검사를 재사용한다. 연속 경로 안전성은 인코딩 좌표상의 정확 산술로 판정하며 수치 해석과 분리된다. 소스 인코딩은 기존 스칼라 코덱을 재사용하고, 네이티브 전용의 엄격한 필드와 규범 검사는 어떤 텐서 디코딩보다도 먼저 불법 입력을 거부한다. 새로운 IR 계층, 바인더, 솔버, 레지스트리, 루트 익스포트는 도입되지 않았다.
  • 사용자 API: RydbergProgram은 원자, 사이트, 길이와 시간 단위, C6, 손실률, 최소 간격, 전송 채널과 구동 채널로 구성되며, move, pulse, to_ir 세 가지 동작을 제공한다. 예시 출력은 원자 식별자 ('a','b'), 차원 (3,3), 제어 위치 (3.0,0.0), 생존 연산자 형상 (9,9)이다. PR에는 “제어 위치가 물리적 존재를 의미하지 않는다”고 명시되어 있다.
  • Simulation(#707, 19개 파일, +1488/−188): 네이티브 Rydberg 프로그램이 기존의 Lindblad 계획, 실행, 초기 밀도 수반 진입점을 사용할 수 있으며, 사용자가 원자, 선형 전송, 펄스, 흡수 손실을 선언하면 Simulation이 구간 행렬을 자체적으로 조립한다. plan 1.7은 정확히 일곱 개의 외부 필드로 봉인되며 런타임 시 소스를 재컴파일하지 않는다. 실험적 수치 경로는 CPU-only이며 하나에서 두 개의 g/r/lost 역할을 지원하고, 더 큰 규모는 지수적 메모리 할당 전에 거부된다. 기하는 선형 경로를 적용하는 구간 중점 근사이며, 격자 수렴 증거와 솔버 정밀도는 별도로 기록된다.
  • Examples(#714, 3개 파일, +217): 두 개의 펄스 진폭 바인딩을 훈련하고 원자 쌍을 이동시키며, 40스텝, 128구간의 실측 출력은 다음과 같다. 무조건 RR은 0.0431에서 0.1228로 상승, 생존 조건 RR 0.1500, no-flag 선택 RR 0.1439, 정확 수치 재생 성립. 로컬 기본 전체 14,584 통과, 167 스킵, 약 518초. 첫 회차 64구간에서는 2.28e-10에서 그래디언트 하나가 실패했으나, 128구간으로 세분화한 후 솔버와 단언을 변경하지 않고 통과했다.
  • 판단: 하루 만에 양자 스택이 “원자와 펄스를 선언할 수 있다”에서 “동역학을 계산할 수 있다”, 나아가 “제어 파라미터를 훈련할 수 있다”는 세 단계를 연결했으며, 각 단계마다 능력 경계를 명시했다(샘플링 이벤트, 피드백, 가열, 양자 운동, GPU, 분산을 주장하지 않으며 M3 완료도 주장하지 않는다). 이는 이번 분기 가장 정보량이 많은 단일 저장소 추진 방식이다. 먼저 계약을 거부 가능한 구현으로 작성하고, 그 다음 블록별로 개방하는 것이다.

1.4 FlagQuantum: 배포 거부, 벤더 퇴장, 터미널 샘플링 제안(10-22)

날짜: 2026-10-22　출처: PR #701 · PR #705 · PR #716 · PR #720

  • 배포 측 거부(#701, 3개 파일, +78/−1): 원시 물리 프로그램은 디지털 회로가 아니며, 패키지 빌더가 기존에 ProgramRecord에서 회로 메타데이터를 읽을 때 AttributeError를 발생시켰고, Pauli 패키지 빌더는 방향성이 없는 TypeError를 발생시켰습니다. 이제 두 진입점 모두 백엔드 선택, 컴파일 및 발사 이전에 Core의 거부 로직으로 전달되어 통일적으로 CapabilityError를 발생시키며, “원시 Rydberg 타임라인은 회로로 실행할 수 없습니다. flagquantum.lindblad를 사용하세요”라고 안내합니다. 네 개의 새로운 회귀 테스트는 수정 전에 모두 실패했고, 수정 후 세 개의 Python 버전에서 각각 39개 테스트가 통과했습니다.
  • 공급자 퇴장(#705, 17개 파일, +159/−621): 범용 NeutralAtomProvider는 대응하는 외부 서비스나 작업 프로토콜이 없었으며, 로컬 기하만 파싱하고 항상 제출을 거부했습니다. 제안 082에 따라 해당 모듈과 두 Remote 네임스페이스의 내보내기를 직접 삭제하며, 별칭도 빈 껍데기 어댑터도 남기지 않습니다. Core의 기하, RydbergProgram과 기존 계획/소스 펌웨어는 변경되지 않습니다.
  • 터미널 샘플링 제안(#716, 4개 파일, +379): #707 이후 제안 083을 제출하여 Runtime의 sample_terminal 원시 연산을 정의합니다——정렬된 전공간 텐서 Kraus 브랜치를 소비하고, SuperOperator, 기존 밀도 검증, 현재 MeasurementResult, Core 텐서 인코딩과 Torch 난수 소스를 재사용합니다. 예시에서는 존재성 레이블 ('no_flag','flag')과 확률 0.68/0.32, Fock 수 레이블 0/1/2와 확률 0.6/0.3/0.1을 제시하며, 끝부분에 “Framework terminal instrument API: proposed, not implemented”를 명확히 출력합니다. PR 본문에는 제안 083이 아직 승인되지 않았고 아직 구현되지 않았음을 명시합니다.
  • 기타 지선: #710은 사용자 정의 연산자 등록 시 Circuit 메서드를 동기적으로 설치합니다. #711은 Circuit 수반에서 비유니타리 행렬을 거부합니다. #712는 극히 작은 비영(non-zero) 게이트를 정확히 보존합니다(임계값으로 인해 0으로 접히지 않음). #713은 동적 회로 승격 준비 감사입니다. #720은 측정 용량이 랭크에 따라 변하는 것과 표현 일관성 구간입니다. #721은 제어 명령이 자체적으로 피연산자를 갖도록 합니다. #722는 주입 클록에서 엔진 정렬을 캘리브레이션하여 간헐적 실패를 제거합니다.
  • 판단: 이번 기간 퀀텀 스택의 합입량 중 절반은 “거부”와 “삭제”에 사용되었습니다——물리 프로그램을 회로로 패키징하는 것을 거부하고, 외부 서비스가 없는 공급자를 삭제하며, 승인되지 않은 샘플링 인터페이스를 동결합니다. 이러한 조치는 능력을 추가하지 않지만, 이후 M3의 경계가 신뢰할 수 있는지를 결정합니다.

1.5 FlagGems: 91건 합입, KernelGen 39건 배치 적용과 Kunlunxin 13건 최적화 병행 (10-22)

날짜: 2026-10-22　출처: FlagGems 커밋 · PR #7077 · PR #7107 · PR #7424

  • 총량: 29건의 커밋, 91건의 머지로 전체 조직 머지의 56%를 차지합니다. 전체 조직의 163건 머지를 제목 키워드 기준(중복 가능)으로 집계하면: 테스트류 47, KernelGen 39, 쿤룬신 13, 승등 또는 NPU 9, 하이광 또는 DCU 7, 엔플레임 또는 GCU 5, 무어 스레즈 또는 MUSA 5, CI 4, 무시 3이며, 이 중 FlagGems 저장소에 포함된 것은 쿤룬신 10건, 승등 7건, 무어 스레즈 4건, 엔플레임 2건, 하이광 2건입니다.
  • KernelGen 일괄 반영: 14개의 Nvidia 연산자가 세 배치로 나뉘어 머지되었으며, 배치 내 타임스탬프 밀도는 개별 리뷰가 아닌 승인 후 묶음 단위로 머지되었음을 보여줍니다.
  • 10:43 배치: _copy_from_and_resize, ger, sparse_bsc_tensor;
    _nested_tensor_from_tensor_list.
  • 15:23 배치: _values_copy, _fw_primal_copy, _shape_as_tensor;
    _nested_tensor_storage_offsets, _convert_indices_from_csr_to_coo.
  • 22:23 배치: swapdims, _nnz, moveaxis, _dimI 및 view_as_complex_copy.
  • 엔플레임 전체 배치(#7077, 26개 파일, +3520/−511): 벤더의 10-13 전체 업데이트가 한 번에 메인 브랜치로 반영되었으며, 제목에는 “update from enflame 20261013”만 기재되어 있고 PR 본문에는 Operator와 “결함 수정 및 성능 최적화”만 표기되어 있을 뿐 항목별 세부 내역은 없습니다. 이는 최근 일주일간 단일 건으로는 가장 큰 코드량을 가진 벤더 측 변경 중 하나입니다.
  • 쿤룬신 융합 MoE(#7107, 13개 파일, +496/−123): XPU3의 fused_experts_impl, inplace_fused_experts, outplace_fused_experts 세 연산자와 dispatch_fused_moe_kernel을 보완했으며, 앞 세 개의 집계 점수는 각각 1.327, 1.329, 1.324입니다(bf16 평균 1.346~1.351, fp16 평균 1.302~1.306). PR은 두 가지 유보 사항을 명시했습니다. 첫째, 공식 계약 기준선은 vLLM 자체의 fused_experts_impl인데 이 기준선은 XPU 스택에서 빌드할 수 없으므로 쿤룬신은 대체 비계약 기준선(전문가별 index_select + matmul)과만 비교했으며, 세 수치는 “융합이 비융합을 이긴다”로만 읽어야 합니다. 둘째, dispatch_fused_moe_kernel의 집계 0.626은 0.8 임계값에 미달하므로 달성을 주장하지 않습니다.
  • CI 3건: #7424는 cuda12 의존성 오류를 수정하기 위해 flagcx를 비활성화했습니다(nvidia133 백엔드에서 mm_w8a8_fp8 실패). #7500은 환경 변수 위치 오류를 수정했습니다. #7420은 robust-checkout 타임아웃을 60초로 늘렸습니다.
  • 판단: 91건 중 실제로 연산자 역량을 늘린 것은 20% 미만이며, 주체는 자동화 산출물(39건)과 테스트 계약(47건) 두 부류입니다. 쿤룬신 라인은 이미 “벤치마크 집계 점수 기준으로 항목별로 조정”하는 단계에 들어섰고, 기준선의 비교 가능성 결함을 스스로 표기하기 시작했습니다. 이는 숫자 자체보다 기록할 가치가 있습니다.

1.6 FlagGems 테스트 메인 라인: lukatao 61건, 밤새 14건 배치로 “직접 연결 후보” 변경 (10-22 ~ 10-23)

날짜: 2026-10-22 ~ 2026-10-23　출처: PR #7543 · PR #7552 · PR #7556 · optest 저장소

  • 규모: lukatao 한 사람이 61건을 병합해 FlagGems 당일 커밋의 67%, 전체 조직의 37%를 차지했다. 그중 56건의 제목은 테스트, 수정, 검증 또는 동기화 유형이었고, 신규 연산자는 한 건도 없었다.
  • 배치 이슈 생성: 10-22 23:40부터 23:47까지 7분 동안 10건의 PR이 생성되었다. foreach 오버라이드 “직접 라우팅” 배치 01~09(#7543~#7551)와 #7552 “마지막 아홉 개 연산자 스위트를 공용 후보 API 경유로 전환”이 그것이다. 이 변경들은 테스트 케이스를 use_gems() 래핑에서 flag_gems.* 직접 호출 또는 후보 구현 주입 방식으로 바꾸었으며, 이는 “어느 구현을 테스트할지”를 암시적에서 명시적으로 전환한 것과 같다.
  • 철야 병합: 모니터링 기간 마지막 네 건의 희소 스위트 이식이 새벽에 연달아 반영되었다. #7553(01:00, 희소 log-softmax 크로스 백엔드 이식 가능), #7554(02:51, 희소 검증기 펌웨어와 직접 벤치마크 후보 호출), #7555(04:38, 압축 희소 검증기), #7556(05:47, 공용 희소 블록 생성자)이 그것이다. 마지막 두 건은 이 리포트 마감 시점까지 30분이 채 남지 않은 시점에 반영되었다.
  • 백엔드 스킵 관리: Ascend와 Moore Threads의 스킵은 각각 사유를 명시하고 입력 도메인을 한정했다(#7483 linalg_vander 복소수 입력, #7485 logdet 복소수, #7492 row_stack_out 메모리 포맷, #7496 trapz complex32, #7502 orgqr MUSA 0열, #7503과 #7504 MUSA qint32, #7505 Hygon cuDNN 검증). Hygon 측은 #7460에서 FP8 희소 합계 역방향 입력 펌웨어를 수정했다.
  • 판단: 이 흐름은 외부로 노출되는 어떤 기능도 만들어내지 않지만, FlagOS 멀티 백엔드 신뢰성의 토대이다. 동일한 PyTorch 테스트 케이스가 십수 개 백엔드에서 설명 가능한 통과 또는 스킵 결과를 내야 하며, 각자 수정된 테스트를 따로 유지해서는 안 된다. optest도 같은 날 툴체인을 설치 가능한 wheel로 만들고(#4), src 레이아웃으로 전환하고(#5), console commands를 노출했으며(#6), 이는 FlagGems의 테스트 케이스 개편과 같은 일의 양 끝이다.

1.7 build-infra: Kunlunxin, FlagTree 일곱 번째 백엔드로 등극, flagcx 0.14.0 전 백엔드에 고정 (10-22)

날짜: 2026-10-22　출처: PR #1468 · PR #1471 · PR #1459 · PR #1462

  • 총량: 13건의 커밋, 13건의 병합, 전부 tengqm이 수행했으며, 해당 기간 플랫폼 영역에서 가장 집중도가 높은 저장소입니다.
  • 일곱 번째 백엔드(#1468, 3개 파일, +428/−9): packaging/flagtree/kunlunxin은 최근 백엔드와 동일한 형태의 2단계 Containerfile을 채택했습니다. --target builder는 배포 가능한 빌드 환경(순수 ubuntu 22.04에 apt 툴체인, 사전 빌드 입력을 FlagTree 오프라인 캐시에 임시 저장)이며, 마지막 단계에서 그 위에 wheel을 빌드합니다. Kunlunxin에는 다섯 가지 고유 제약이 있습니다. 첫째, 사전 빌드 입력이 열 개이고 캐시가 디렉터리 이름으로 매칭되는데, 두 개의 LLVM 19 패키지가 tarball 루트 xtdk-llvm19-ubuntu2004_x86_64를 공유하므로 xtdk-llvm19와 xtdk-llvm19-printf로 나뉘며, 따라서 filestore 이름에 버전 접미사가 붙습니다. 오직 triton 툴 패키지만 .triton/을 루트로 하여 --strip-components가 필요합니다. 둘째, 프런트엔드는 환경 변수로 선택되며 LLVM_SYSPATH는 반드시 설정되지 않은 상태로 유지해야 합니다. 공용 LLVM은 검증된 브랜치이고 XTDK는 폴백입니다. 셋째, pybind11은 정확히 3.0.1로 고정합니다. 3.0.4는 internals 생성자를 변경하여 디스패처가 SIGSEGV를 일으키기 때문입니다. 넷째, apt의 patchelf를 사용하지 않고 PATH 또는 공용 LLVM 패키지에 내장된 사본에서 해석하며, 벤더 CI와 동일한 경로를 사용합니다. 다섯째, TRITON_APPEND_CMAKE_ARGS=-DCMAKE_BUILD_TYPE=Release를 추가하지 않습니다. Kunlunxin이 배포하는 벤더 wheel 자체가 rel-with-asserts이므로, 외부 컴파일러 입장에서 최적화 수준은 패키징 세부 사항이 아니기 때문입니다.
  • 통신 의존성(#1471, 3개 파일, +60/−4): flagcx==0.14.0은 이전에 nvidia-cuda12.8과 nvidia-cuda13.3 두 줄에만 pin이 있었고, 나머지 열여덟 개 백엔드는 여전히 triton/_C에서 해석했습니다. 이번에 나머지 열여덟 개 백엔드에 정확한 pin을 추가했으며, 태그는 백엔드 키에서 유도하지 않고 벤더 인덱스가 실제로 제공하는 값을 사용합니다(hygon-dtk26.04가 배포하는 것은 +dtk2604). spacemit과 thead-ppu2.0.0은 고정하지 않습니다. 두 인덱스에 flagcx wheel이 없기 때문입니다. 같은 PR에서 이로 인해 낡아버린 문서 설명 두 곳도 함께 수정했습니다.
  • 문서 라인: vllm-plugin-FL, FlagTree, FlagCX, FlagGems, FlagLibs, Megatron, SGLang, verl 여덟 개 컴포넌트의 설계 기록과 사이트 페이지가 12:50부터 17:42 사이에 연속으로 병합되었으며(#1462~#1470), 이번 분기 처음으로 “빌드 설계”를 검색 가능한 사이트 콘텐츠로 작성한 사례입니다.
  • 기타: #1459는 낡은 벤더 접두사 hygon wheel 줄을 삭제했고, #1461은 호출자가 manifest 다운로드 모드를 좁힐 수 있게 했습니다.
  • 판단: 빌더가 여섯 백엔드에서 일곱 백엔드로 확장되었고, 같은 날 통신 라이브러리를 “두 개의 nvidia 줄에 대한 특례”에서 모든 백엔드의 명시적 의존성으로 변경했습니다. 후자가 더 실질적인 변화입니다. 백엔드를 교체할 때 통신 계층이 여전히 동일한 설치 및 심볼 해석 경로를 따르는지를 결정하기 때문입니다.

1.8 Torch-FL: Qingwei가 rocprofiler-sdk에 연결, Kunlunxin 크로스 카드 복사가 peer 원시 연산으로 전환(10-22)

날짜: 2026-10-22　출처: PR #630 · PR #634 · PR #632 · PR #629

  • 총량: 12건의 커밋, 12건의 머지, MPS, 쿤룬신, 승등/하이광/무시/PPU, GCU, 칭웨이 여섯 플랫폼에 걸쳐 있음.
  • 칭웨이 디바이스 분석(#630, 15개 파일, +1383/−39): 칭웨이에서 torch.profiler는 이전까지 CPU 활동만 출력했음——플랫폼이 unavailable 스텁으로 라우팅되었고, PrivateUse1에 디바이스 프로파일러가 등록되지 않아 kernel 이벤트도, CPU에서 kernel로의 화살표도 없었으며, self_device_time_total은 항상 0이었음. 본 PR은 rocprofiler-sdk 기반의 DeviceTracer와 독립 프로파일링 도구 libtorch_fl_profiler.so를 추가하여, 각 NPU kernel을 이를 발기한 aten op에 다시 연결하고 CUDA trace의 CPU/device 레이아웃에 따라 렌더링함; 동시에 TX8110에서 실측하고, 칭웨이에 FLAGOS_BUILD_VENDOR=ON을 고정함(벤더 디렉터리에 난수 커널이 들어 있음), 설치 및 프로파일링 문서를 보완함. 프로파일링을 요청하지 않을 때는 동작이 변하지 않음.
  • 쿤룬신 크로스카드 복사(#634, 3개 파일, +55): CrossDeviceMemcpy가 같은 카드 시맨틱의 xpu_memcpy(XPU_DEVICE_TO_DEVICE 타입)를 호출하여, 두 카드의 포인터를 전달하면 −801을 반환하고 대상이 기록되지 않아, 임의의 flagos:N → flagos:M 전송이 조용히 무효화되었음. SDK의 peer 프리미티브 xpu_memcpy_peer로 전환함. 문제는 P800에서 마지막 bert 실패로 발견되었으며, 동기 호출이 이를 가리지 않으므로 타이밍 문제가 아니라 바이트가 기록되지 않은 것임을 보여줌.
  • 프리로드 순서(#632): liblaunch_shared.so가 undefined symbol: cudaMemcpy를 보고했으며, 해당 심볼은 /usr/local/xcudart/lib/libcudart.so.12에서 버전화된 정의로 존재하여 Triton 런처가 dlopen된 이후에만 해석 가능하므로, 쿤신의 CUDA 호환 런타임을 미리 로드함.
  • 기타: #629는 cuda/dcu/metax/ppu에 convolution_overrideable 예외를 보충함; #626은 Qwen3.5의 메타데이터 뷰를 MPS에 남겨둠; #635는 FlagGems 주도의 CUDA 빌드에서 타입 변환을 디바이스로 옮김; #631은 MPS 테스트를 Apple runner에 남겨둠; #618은 GCU의 capability AssertionError에 임시 진단 설명을 추가함.
  • 판단: 당일의 주된 흐름은 성능이 아니라 두 가지 기본 역량의 가용성——관측성(칭웨이가 처음으로 디바이스 타임라인을 볼 수 있게 됨)과 멀티카드 정확성(쿤룬신 크로스카드 복사가 이전까지 계속 틀려 있었음)임. 이러한 수정은 어떤 벤치마크 표에도 나타나지 않지만, 상위 계층의 모든 멀티카드 실험 결론을 재계산하게 만듦.

1.9 FlagTree: AMD RDNA에 prefill 경로 보완, MUSA는 복사마다 TME 캐시 (10-22)

날짜: 2026-10-22　출처: PR #1365 · PR #1385 · PR #1278 · PR #1415

  • AMD prefill(#1365, 66개 파일, +3163/−260): #1364의 M=1 디코드 경로 위에 M>1 프리필 실행을 추가했습니다. 여기에는 dense Qwen3 임포터의 프리필 모드, M>1 렌더링 코드 생성(WMMA lm_head 포함), matmul + RMS-norm-stats 커널 융합 및 gather-reduce 정규화 마무리, 프리필 토큰별 KV 쓰기를 위한 독립 캐시 슬롯, 그리고 「프리필은 마지막 토큰의 logits만 출력」—lm_head 이전 위치만 슬라이스하고 전체 위치를 구체화하지 않음—이 포함됩니다. RDNA의 프리필 WMMA GEMM 마이크로커널은 M>1에서 GEMV 루프 대비 10~30배 빨라지며 M에 따라 자동 선택됩니다. 디코드 측 split-K는 lm_head를 17.0에서 14.9 ms/token으로, 레이어별 와이드 프로젝션을 14.9에서 10.5 ms/token으로 낮췄습니다. W7900(gfx1100)과 R9700(gfx1201)에서 새로 컴파일한 후 프리필은 유한하며, argmax=241이 torch 참조와 일치하고(최대 오차 약 0.5, bf16 근접 동률에 해당), 디코드 next_token=25는 변하지 않았습니다.
  • 나머지 다섯 건: #1278은 outlined helper 호출 간 펜스 정렬 오류를 수정했고, #1385는 MUSA에 복사별 TME 캐시 지속성을 추가했으며, #1424는 간헐적 버스 오류로 인해 Enflame CI에서 02-sparse-mla 케이스를 비활성화했고, #1415는 minimax_m3 index_topk의 block_size_k를 수정했으며, #1427(10-23 00:06)은 Enflame vllm benchmark 파라미터를 업데이트했습니다.
  • 판단: AMD 노선은 「단일 카드에서 디코드 가능」에서 「단일 카드에서 프리필 가능」으로 진전했으며, 성능 수치는 전체 모델 비교가 아닌 커밋별 기준(17.0→14.9→10.5 ms/token)이어서 검증 가능성이 비교적 높습니다. 이 노선은 여전히 Qwen3 dense 모델만을 유일한 검증 대상으로 하며 MoE와 긴 컨텍스트는 다루지 않습니다.

1.10 기타 저장소: FlagBLAS Iluvatar 및 Moore Threads GEMM, 대회 채널 2건, optest wheel 패키징(10-22)

날짜: 2026-10-22　출처: FlagBLAS PR #153 · FlagGems-sglang PR #205 · FlagGems-vllm PR #977 · optest PR #4

  • FlagBLAS(2건): #153 Iluvatar L1 계층 연산자 최적화; #152 Moore Threads의 GEMM 구현 추가. 두 PR 모두 벤더 측 커밋이며 크로스 저장소 변경은 없음.
  • FlagGems-sglang(3건): #205는 AMD RDNA3 아키텍처 계층(_amd/rdna3/ops/)에 fused_moe_gemm, fused_moe_router_tensorcore, fused_moe_router_cudacore의 gfx1100 버전을 추가하고 W7900D에서 튜닝, 3개 파일 +1310; WMMA 커널은 K 블록별로 fp32에서 단일 내적을 누적하는데, K 블록 간에 WMMA 누산기를 사용하면 gfx1100에서 정밀도가 떨어지기 때문. 나머지 두 건은 FlagOS 대회 Track1 작품: #204 fused_pack_qkv, #201 fused_sigmoid_mul로 모두 Triton 커널이며, 대회 산출물이 제출물에 머물지 않고 이미 메인라인에 진입하기 시작했음을 보여줌.
  • FlagGems-vllm(4건): #977은 MetaX 퓨전 MoE에 TP=2 구성 추가(Qwen3.6-35B-A3B의 w1=(256,512,2048), w2=(256,2048,256)), C550에서 14개 M 값 평균 1.065배 속도 향상, M≥4096일 때 98304바이트 공유 메모리 구성을 선택해 발생하던 OutOfResources 수정; 동시에 vLLM의 out, workspace13, workspace2를 받아들여 전체 출력 복사를 방지. #936은 Ascend의 청크 게이트 델타 규칙(chunk gated delta rule) 포워드를 tle.dsa의 슬라이스 및 동기화 인터페이스로 전환; #929는 KMCompiler에서 qwen_qsa_prepare 추가; #777은 Hopper에서 가변 길이 flash attention 보완.
  • FlagTrain(2건): #16은 multi_tensor_lion 추가(Nvidia, Hygon, Metax, Thead 4개 백엔드, KMCompiler 접두사); #26은 quick_gelu 추가.
  • optest(4건): #4는 도구를 설치 가능한 wheel로 패키징, #5는 src 레이아웃으로 변경, #6은 설치된 도구를 console commands로 노출, #2는 CI 작업명이 <repo> (<backend>)를 표시하도록 변경.
  • 검토 중 주목할 사항: flir #83은 TensorView 방언과 tile.load / tile.store 뷰 추가(CommonIR 방향의 실질적 움직임); verl-FL #22는 Biren SUPA 플랫폼 지원 추가; FlagOS-Compressor #13은 CLI에 다중 디바이스 MSE 양자화와 BF16 변환 추가; sglang-plugin-FL #149는 23:36에 Hygon eager Qwen3.6 MTP 디코딩 신규 개설; TransformerEngine-FL #144~#146 세 건이 같은 날 NPU를 지향(get_num_cublas_streams, cuDNN 버전 기능 질의, bshd/thd 레이아웃).
  • 판단: 이 저장소들은 모두 ‘인터페이스 추가’ 단계에 있음 — flir는 IR 방언 추가, verl은 하드웨어 백엔드 추가, 컴프레서는 CLI 추가, 컴파일 연산자는 4개 백엔드로 확장. 아직 모델 검증 메인라인에는 진입하지 않았으나, flir와 컴프레서의 움직임은 2.3 주기에서 FlagTree와 신규 모델 도입의 경계를 직접 결정할 것임.

2. 뉴스 보도와 생태계

2.1 Pandaily, FlagOS 2.2를 영어로 체계적 전달: 1454개 연산자, 약 27% 크로스칩 향상, KernelGen 765개 신규 연산자 (10-22)

날짜: 2026-10-22　출처: Pandaily 보도 · FlagOS 문서

  • 사실 골격: 2.2는 9월 30일 릴리스되었고 10월 17일 2026 인공지능 오픈 컴퓨팅 콘퍼런스에서 전시되었다. 9개 연산자 라이브러리 합계 1,454개 연산자, FlagGems 및 관련 라이브러리의 공개 연산자는 564개에서 1,454개로 증가(890개 신규). FlagGems-SGLang 라이브러리 신규 추가, 40개 멀티칩 연산자 포함, attention, Mamba 상태 업데이트, MoE, LoRA, 샘플링 및 양자화 커버. 10종 AI 하드웨어, 수천 개 연산자에서 전체적으로 약 27% 향상.
  • 자동화 기준(이번 호 신규 세부 사항): KernelGen은 이미 9종 AI 칩을 지원하며, 이번 분기 765개 신규 연산자 생성, 그중 416개가 최소 5종 국산 칩에서 정밀도 검사를 통과하고 네이티브 연산자의 80% 이상 성능에 도달. FlagPrism은 Triton 소스, 컴파일러 IR 및 디바이스 실행 데이터를 연결하며, Ascend, Iluvatar CoreX, Moore Threads, NVIDIA 및 Enflame 지원.
  • 압축 및 배포: FlagOS-Compressor는 W8A8로 Qwen3.5-397B-A17B를 처리, 모델 파일이 751.41 GB에서 382.45 GB로 감소(−49.1%), GPQA-Diamond 점수 84.85%. vLLM, Megatron-LM, SGLang 등 프레임워크 플러그인과 함께, 신규 모델은 릴리스 후 하루 내 최대 12개 칩 플랫폼에 적응.
  • 기존 컴퓨팅 사례: Ascend 910B에서 GLM-5.3-Flash의 논리 서비스 처리량이 8.52k에서 17.36k tokens/s로 상승(2.04배). China Telecom Xing4.0-29B-A4B는 10개 칩 플랫폼에 적응, 장입력 테스트의 첫 토큰 지연이 네이티브 연산자 대비 19.87% 감소(이 수치는 공개 보도에서 처음 등장).
  • 한계: BAAI 자체 진술 문제는 시점에 있음 — 이미 배포된 컴퓨팅 중 80% 이상이 최신 세대가 아니며 모델 세대 교체는 빠름. 본문의 모든 수치는 BAAI 자체 측정에서 나온 것이며, 실제 서비스 성능은 여전히 부하에 달려 있음.
  • 판단: 이는 2.2의 첫 영어 체계적 전달이며, 기준은 국내 기사와 일치하고, 실질적 신규는 19.87%라는 지연 수치와 KernelGen의 분기 산출량뿐이다. 해외 독자에게 주는 의미가 커뮤니티에 대한 정보 증분보다 크다. 그것은 2.2를 중국어 기술권의 한 발표회에서 외부에서 인용 가능한 영어 자료로 전환한다. 앞선 10-20 보도는 이미 2.2의 이익을 검증 가능한 사례로 분해했으며, 본 조항은 수치 대조를 반복하지 않는다.

2.2 Crossdim Intelligent, 중즈 FlagOS 가속 계획 입안 예정 선정: FlagOS-Robo 및 AlohaMini 엣지 디바이스 시연(10-22)

날짜: 2026-10-22　출처: Jushen Home 보도 · FlagOS-Robo 문서 입구

  • 입안 사실: 9월, 베이징시 과학기술위원회, 중관춘 과학기술단지 관리위원회가 2026년도 「중앙 유도 지방」 및 「차세대 정보통신 기술 혁신」 특별 중즈 FlagOS 가속 계획 방향 입안 예정 과제 공시 통지를 발표. Crossdim Intelligent 산하 Crossdim Zhixin(베이징) 로봇 기술 유한회사가 신청한 《FlagOS-Robo 기반 AlohaMini 임바디드 인텔리전스 로봇 엣지 디바이스 배포 및 응용 시연》이 공시 명단에 선정됨.
  • 프로젝트 내용: 임바디드 인텔리전스 로봇 오픈소스 알고리즘 재현, 실제 본체 배포, 국산 AI 칩 엣지 디바이스 적응 및 시나리오 응용 검증을 대상으로, AlohaMini 오픈소스 로봇과 FlagOS-Robo 툴체인을 기반으로 모델 학습 적응, 멀티칩 추론 배포, 고속·저속 시스템 일체화 운용 및 다중 시나리오 시연을 수행, 목표는 재현 가능, 배포 가능, 평가 가능, 확산 가능한 오픈소스 방안 형성.
  • 검수 항목: 모델 측에서는 임바디드 모델 학습 적응 및 추론 배포, 국산 AI 칩의 로봇 엣지 디바이스 응용 추진, 멀티칩 추론 정밀도 일관성 테스트로 칩 간 성능 검증. 시스템 측에서는 임바디드 모델, 운전 제어 소뇌 및 본체 제어 협력 추진, 이해·계획·실행 연결. 시나리오 측에서는 다중 시나리오 실체 평가 체계 구축.
  • 전정: Crossdim Intelligent는 2.2의 생태 기준에서 이미 신규 파트너 중 하나였으며, 10-13 예고된 임바디드 인텔리전스 분과 포럼 명단에도 등장. 본 조항의 차이는 「정부 특별 — 오픈소스 툴체인 — 오픈소스 본체 — 평가 체계」 네 가지 세트의 입안이며, 포럼 등장이 아님.
  • 판단: 가속 계획은 FlagOS-Robo와 국산 칩 엣지 디바이스를 동일한 과제서에 넣었으며, 이는 임바디드 인텔리전스 방향에 외부 검수자를 설정한 것과 같다. 커뮤니티에 있어 이는 세 번째 납품물 제약이 있는 외부 프로젝트(앞의 두 개는 FEP 매트릭스와 대회)이며, 이후 공개된 칩 모델과 정밀도 일관성 결과가 있는지 추적할 가치가 있다.

2.3 채널 검증: 17개 후보 중 2개 유효, CSDN 신규 대학 원탁 라이브, Zhiyuan 커뮤니티는 프레임 페이지만 확보(10-22)

날짜: 2026-10-22　출처: Google News RSS · CSDN FlagOS 칼럼 · HN Algolia

  • 쿼리 측면: 24개 중영문 쿼리어, 컴포넌트명(FlagOS, FlagGems, FlagScale, FlagTree, FlagPerf, FlagAttention, FlagCX, KernelGen)은 14일, 멤버 및 산업 키워드(Zhiyuan Research Institute 오픈소스, Zhiyuan Research Institute 칩, 국산 컴퓨팅 파워 오픈소스 소프트웨어 스택, Enflame, MetaX, Moore Threads, Tsingwei, Hygon 등)는 7일로 설정, 모니터링 기간 내 총 17건 확인.
  • 유효 2건: Pandaily의 2.2 영문 전재와 Jushen Home의 FlagOS-Robo 프로젝트 착수 기사(2.1, 2.2 참조). 나머지 15건은 시세, 펀딩 및 인재 관련 기사로, Enflame과 Tsingwei의 개별 종목 페이지 및 과창선봉 사례, Huixi Intelligence 펀딩, Moore Threads 「공모가 하회」 및 국산 컴퓨팅 파워 실적 기사, Zhiyuan 커뮤니티가 전재한 Huang Renxun 컴퓨팅 클러스터 기사 등이며, 컴포넌트, 버전 또는 칩 적응과 관련된 내용은 단 1건도 없음.
  • 채널 검증: HN Algolia 8개 쿼리 중 FlagOS 4건, FlagGems 2건 확인되었으나 제목에 직접적 일치 없음. CSDN 칼럼 홈페이지 51개 링크 중 최신 오리지널 기사는 여전히 08-28의 GLM-5.3-Flash Day0 적응 기사이나, 10-22 19:00 대학 라운드테이블 라이브(「공동으로 개방형 AI 교육 생태계 구축」, 10-22 14:24 생성)가 신규 추가됨. 내용은 FlagOS 글로벌 AI 개방형 컴퓨팅 교원 발전 계획 하의 다국적 대학 교원 교수법 실행 사례로, 기술 발표가 아닌 커뮤니티 활동임. Zhiyuan 커뮤니티 검색 페이지는 클라이언트 렌더링 방식으로 프레임 페이지만 확인 가능.
  • 공백 설명: 본 모니터링 기간의 뉴스 측면은 2건의 외부 기사로 지지되며, 그중 1건은 이전 발행된 영문 전재이므로 「기술적 기준」은 여전히 전적으로 GitHub에서 비롯됨. 수집 규율에 따라 이는 「뉴스 측면에 의존하지 않고平静을 판단」하는 요건을 충족하나, 이를 근거로 대외 전파 리듬이 가속화되고 있다고 판단해서는 안 됨.

3. 멤버 기관 및 백엔드 제조사 심층 분석

3.1 Hygon: 두 추론 플러그인 저장소, 동일자 상위 버전 정렬 완료 (10-22)

날짜: 2026-10-22　출처: vllm-plugin-FL PR #576 · sglang-plugin-FL PR #138 · FlagGems PR #7460 · FlagDNN 커밋

  • 듀얼 스택: vLLM 0.28.0과 SGLang 0.5.18이 동일자 병합, 총 84개 파일, 순증 약 5,700줄로 당일 코드량 최대의 제조사 측 투입. 두 건 모두 physics31415926이 제출, 검증 환경은 동일하게 단일 카드 64 GiB의 BW1000 클러스터.
  • vLLM 측 요점: 배포 패키지는 0.28.0+empty, ModelRunnerFL 경유 및 V2 model runner 비활성화; 그래프 모드는 eager 및 FULL_AND_PIECEWISE 지원; 플러그인 wheel은 CI가 PR merge ref에 따라 재빌드하여 이미지 내 구버전 교체.
  • SGLang 측 요점: 단일 노드 TP2 외에 물리적 2노드 TP4/PP1 및 TP2/PP2 실행, 파이프라인 병렬 협력 종료 수정; FlagGems 5.4.0.dev0 및 FlagCX 0.13.0을 기반으로 하며 독립 Triton 미도입.
  • 기타: FlagGems #7460 Hygon FP8 희소 합계 역방향 입력 펌웨어 수정; FlagDNN 「fix for hygon」 1건; build-infra #1459 구식 제조사 접두사 hygon wheel 라인 삭제(패키징이 통합 명명으로 수렴되었음을 시사).
  • 판단: Hygon은 해당 기간 유일하게 두 추론 플러그인 저장소에서 동시에 상위 버전 정렬을 완료한 제조사로, 작업량이 연산자 수보다 「버전 매트릭스 + 그래프 모드 + 다중 노드 병렬」에 집중됨. 재사용 가치는 empty 백엔드의 업그레이드 프로세스를 버전 테이블 포함 템플릿으로 작성한 점에 있으며, 타 제조사가 이를 따라 추진 가능.

3.2 Kunlunxin: 연산자 최적화 13건, FlagTree 일곱 번째 백엔드 추가 (10-22)

날짜: 2026-10-22　출처: FlagGems PR #7107 · FlagGems PR #7462 · build-infra PR #1468 · Torch-FL PR #634

  • 병합량: 제목에 쿤룬신 또는 XPU가 포함된 전체 조직 병합 13건(FlagGems 10, Torch-FL 2, build-infra 1)으로, 벤더 중 가장 많은 연산자 측 산출이며, 그중 lvxu2020 혼자 6건으로 전부 XPU 커널을 겨냥했다.
  • 연산자 최적화: #7463은 elu, special_i1e, foreach_erf와 foreach_zero를 최적화했고, #7462는 tile, dot, index_put을 최적화했으며, #7452는 융합 커널로 isfinite를 최적화했고, #7470은 kl_div의 XPU 오버라이드를 추가하고 isfinite를 다시 최적화했으며, #7351은 less_equal 텐서 비교에 적응형 tile 고속 경로를 추가했고, #7406은 te_rmsnorm_fwd 비마스크 행 커널의 열 루프를 전개했으며, #7390은 isneginf, nan_to_num_과 log_sigmoid_backward를 최적화했고, #7466은 조정 설정의 tile을 확대해 baddbmm 시작 타임아웃을 수정했다.
  • 융합 MoE: #7107은 3개 연산자 집계 점수 1.324에서 1.329로, 동시에 기저를 대체 구현으로 자발적으로 선언했으며 dispatch_fused_moe_kernel 0.626은 미달이라고 밝혔다(1.5 참조).
  • 빌드와 런타임: #1468은 쿤룬신을 FlagTree의 일곱 번째 백엔드로 만들었고(다섯 가지 고유 제약은 1.7 참조), Torch-FL #634는 크로스 카드 복사를 xpu_memcpy_peer로 변경했으며, #632는 프리로드 순서를 수정했다.
  • 판단: 쿤룬신의 당일 움직임은 연산자, 빌드, 런타임 세 계층에 걸쳐 있어 세 축에서 동시에 구조적 변경이 있는 유일한 벤더다. 진짜 위험 지점도 연산자 측에 있다. 대부분의 변경이 「같은 연산자의 또 다른 tile 또는 융합」이며 통일된 성능 게이트가 없고, 집계 점수 기준도 기저 대체로 인해 벤더 간 비교가 불가능하다.

3.3 칭웨이: 디바이스 타임라인이 torch.profiler에 진입, TX8110 실측 (10-22)

날짜: 2026-10-22　출처: Torch-FL PR #630 · build-infra PR #1459

  • 역량 보완: 칭웨이(TX8)는 이전에 디바이스 측 프로파일링이 전혀 없었다. PrivateUse1에 프로파일러 등록이 없어 kernel 이벤트와 디바이스 시간이 모두 비어 있었다. 이 PR은 rocprofiler-sdk로 DeviceTracer와 독립 프로파일링 라이브러리를 구현해 NPU kernel을 aten op에 다시 연결하고 CUDA 레이아웃으로 표시하며, TX8110에서 실측 통과했다. 동시에 칭웨이에 FLAGOS_BUILD_VENDOR=ON을 고정했고(벤더 디렉터리에 난수 커널 포함), 설치 가이드와 호환성 매트릭스를 「런타임 전용」에서 프로파일링 포함으로 업데이트했다.
  • 영향 범위 자술: flagos_kineto_profiler.cc의 변경은 모든 백엔드의 런타임 슬라이스 위치와 디바이스 행 명명에 영향을 주지만, 칭웨이 하드웨어에서만 재검증했다. 이것이 PR 스스로 명시한 잔여 위험이다.
  • 기타: FlagGems 측에는 칭웨이 전용 병합이 없다. build-infra의 flagcx 0.14.0 통일 pin으로 칭웨이 백엔드도 명시적 통신 의존성을 확보했다.
  • 판단: 칭웨이가 최근 사흘 연속 보완한 것은 「빌드, 난수, 프로파일링」 세 가지 인프라 약점이며 연산자 커버리지가 아니다. 이런 순서는 후발 주자에게 가장 참고 가치가 있다. 먼저 CI에서 빌드되고, 다음으로 난수성을 재현하고, 그다음 성능을 볼 수 있어야 마지막에 최적화를 논할 수 있다.

3.4 Moore Threads와 Enflame: MUSA 캐시 지속성, GEMM과 Enflame 일괄 업데이트 (10-22)

날짜: 2026-10-22　출처: FlagTree PR #1385 · FlagBLAS PR #152 · FlagGems PR #7077 · FlagTree PR #1424

  • Moore Threads: FlagTree #1385는 MUSA에 복사 단위 TME 캐시 지속성을 추가했으며, 이는 텐서 메모리 엔진에 대한 컴파일 측면의 증분입니다. FlagBLAS #152는 GEMM 구현을 추가했습니다. FlagGems 측에서는 제목 관련 5건의 병합이 MUSA의 테스트 스킵과 입력 도메인 제한(#7502~#7504)에 집중되어, 해당 백엔드의 실패 면이 여전히 구현 오류보다는 “입력 미지원” 위주임을 보여줍니다.
  • Enflame: FlagGems #7077은 벤더의 10-13 전체 업데이트(26개 파일, +3520/−511)를 한 번에 메인에 반영했으며, 이는 당일 단일 최대 벤더 측 변경입니다. FlagTree #1424는 간헐적 버스 오류로 CI에서 02-sparse-mla 케이스를 비활성화했고, #1427은 vllm benchmark 파라미터를 업데이트했습니다. 두 건의 CI 조정을 합치면 Enflame 측의 안정성 문제가 여전히 제품 계층이 아닌 케이스 계층에 있음을 보여줍니다.
  • 판단: 두 회사의 당일 산출물 성격은 다릅니다. Moore Threads는 캐시와 선형대수 같은 “재사용 가능한 역량”을 보강하고 있고, Enflame은 전체 업데이트를 전달하며 CI 노이즈를 처리하고 있습니다. 전자는 누적 가능하지만, 후자는 검증 가능한 상세 내역이 한 번 필요합니다. 그렇지 않으면 “전체 업데이트”는 후속 리포트에서 블랙박스로만 기록될 수 있습니다.

3.5 Ascend, Iluvatar CoreX, MetaX 및 기타: 백엔드별로 분류된 소규모 진전, Horizon Robotics와 Cambricon은 침묵(10-22)

날짜: 2026-10-22　출처: FlagGems-vllm PR #936 · FlagBLAS PR #153 · FlagGems-vllm PR #977 · FlagGems-vllm PR #777

  • Ascend: FlagGems-vllm #936은 Ascend의 청크 게이티드 델타 규칙 포워드(chunk gated delta rule)를 tle.dsa의 슬라이스 및 동기화 인터페이스로 전환했습니다. FlagGems 내 제목에 Ascend 또는 NPU가 포함된 7건의 변경은 대부분 테스트 스킵과 케이스 동기화입니다. TransformerEngine-FL은 같은 날 NPU 관련 PR 3건(#144 get_num_cublas_streams, #145 cuDNN 버전 기능 조회, #146 bshd/thd 레이아웃)을 새로 열었으며, 아직 병합되지 않았습니다.
  • Iluvatar CoreX: FlagBLAS #153은 L1 계층 연산자를 최적화했습니다. FlagCX #670의 Iluvatar CoreX 단위 테스트 파이프라인과 이미지는 여전히 검토 중입니다. sglang-plugin-FL #139의 0.5.18 empty 런타임 적응은 여전히 검토 중입니다(10-15 생성).
  • MetaX: FlagGems-vllm #977은 TP=2 구성을 보완했습니다(평균 1.065배, 1.10 참조). FlagGems #7454의 MetaX 수정은 검토 중입니다. build-infra의 flagcx 통합 pin이 MetaX 백엔드를 포함합니다.
  • Hygon 외 DCU 및 PPU 측: Torch-FL #629는 cuda/dcu/metax/ppu 네 가지 백엔드에 convolution_overrideable 예외를 추가했으며, 동일한 수정의 일괄 적용입니다.
  • Horizon Robotics와 Cambricon: 당일 조직 내에서 두 회사 전용 저장소의 푸시와 병합이 확인되지 않아 이틀 연속 침묵입니다.
  • 판단: Hygon과 Kunlunxin을 제외하면 나머지 다섯 회사는 당일 모두 “하나의 경로 또는 하나의 연산자” 수준의 진전으로, 구조적 변경은 없습니다. Horizon Robotics와 Cambricon의 연속 침묵은 이번 모니터링 기간 유일하게 제기할 만한 공백입니다. 다음 주에도 움직임이 없다면 위클리 리포트에 리스크 항목으로 기재해야 합니다.

4. 요약 및 트렌드 관찰

  • 생산능력 구조: FlagGems 한 곳이 56% 병합을 차지하고, 퀀텀 스택이 40% 커밋을 차지하며, 빌드와 런타임이 각각 10분의 1을 차지한다. 병합량은 최근 일주일 최고치를 기록한 반면 커밋량은 감소해, 당일의 주된 흐름이 확장이 아니라 적체 해소였음을 보여주며, 이는 10-20, 10-21 이틀 연속 대규모 병합 이후의 상태와 일치한다.
  • 2.3 주기의 첫 칸: FEP-0140과 FEP-0141이 10-21에 병합되자, 10-22에 Hygon이 vLLM 0.28.0과 SGLang 0.5.18 두 버전을 동시에 구현했다. 이 사슬은 「행렬을 문서에 적는 것」에서 「첫 실측 통과」까지 하루밖에 걸리지 않아, 이번 분기 가장 빠른 요구사항-증거 폐루프였다. 남은 아홉 개 사와 두 버전 라인이 이후 6주간의 주된 작업량이다.
  • 빌드 계층 수렴: Kunlunxin이 FlagTree의 일곱 번째 백엔드가 되고, flagcx 0.14.0이 스무 개 백엔드에 고정되며, optest가 설치 가능한 패키지가 되었다. 세 가지를 합친 효과는 「백엔드를 교체할 때 더 이상 설치 스크립트를 수정하지 않는 것」이며, 이는 어떤 단일 성능 향상보다도 2.3의 전달 속도를 더 크게 결정한다.
  • 관측 가능성이 새로운 약점으로 부상: Tsingmicro가 처음으로 기기 타임라인을 확보했고, Kunlunxin의 카드 간 복사는 이전까지 조용히 실패해 왔다. 이 두 가지는 다중 백엔드가 「작동」한 이후 첫 번째 관문이 관측 가능성과 재현 가능성이며, 더 빠른 것이 아니라는 점을 시사한다. 지난 2주간의 테스트 이식과 케이스 계약 개편(lukatao 혼자 61건)은 바로 같은 판단의 또 다른 표현이다.
  • 위험점 1: FlagQuantum의 20건 병합이 모두 단일 계정으로 완료되었고, 새로 추가된 네이티브 Rydberg 경로는 CPU와 한두 개 역할만 커버한다. 물리 의미 검증이 같은 인력이 테스트와 구현을 작성하는 데 의존해 외부에서 독립적으로 재검토할 수 없다. 제안 083(터미널 샘플링)이 아직 승인되지 않았으며, 빠르게 추진될 경우 Runtime, 측정 결과, 난수 소스 세 곳을 동시에 변경하게 된다.
  • 위험점 2: Enflame #7077 같은 「일괄 업데이트」는 대조 가능한 세부 내역이 없어, 26개 파일과 +3520줄을 구체적 연산자와 구체적 이익에 대응시킬 수 없다. Kunlunxin 융합 MoE의 세 가지 성능도 대체 베이스라인으로 측정되었다. 둘 다 이후의 크로스 벤더 비교를 왜곡시킬 것이다.
  • 관찰점: vLLM 0.28의 다음 벤더(Tsingmicro 또는 MetaX)가 Hygon의 empty 백엔드 템플릿을 재사용할지; FlagTree 0.7.1 개발 빌드(10-20의 0.7.1.dev1)가 2.3 이전에 정식 버전으로 전환될지; TransformerEngine-FL의 NPU PR 세 건이 주말 전에 병합될 수 있을지; Horizon Robotics와 Cambricon의 침묵이 다음 주 위클리 리포트까지 이어질지.

부록: 출처 검증표와 전체 출처 목록

출처 검증표

출처 검증 결과
조직 저장소 API 61개 저장소 전수 검증, 16개 저장소에 모니터링 기간 내 푸시 있음
커밋 검색 135건 적중, 12개 저장소 분포, FlagQuantum과 FlagGems 합계 82건
병합 PR 검색 163건이 모니터링 기간 내 병합, 13개 저장소로 분류
심사 중 PR 검색 183건이 모니터링 기간 내 업데이트, 그중 신규 개설 90건
Release 및 빌드 태그 31개 저장소를 일일이 검증, 모니터링 기간 내 신규 버전 없음; 최근은 10-20의 FlagTree 개발 빌드
org 이벤트 스트림 100건, 그중 PR 이벤트 43, 푸시 27, 브랜치 삭제 12, 브랜치 생성 9, 코멘트 4, 리뷰 3, 팔로우 2
브랜치급 보완 docs, release-info, sglang-plugin-FL, vllm-plugin-FL 네 저장소가 비기본 브랜치 푸시이며, 메인 브랜치에는 신규 커밋 없음
Google News RSS 24개 중영문 쿼리, 17건 후보, 2건 유효
HN Algolia 8개 쿼리, FlagOS 4건, FlagGems 2건, 모두 제목 직접 일치 없음
CSDN FlagOS 컬럼 첫 페이지 51개 링크, 최신 독자 기고글은 08-28; 10-22 19:00 대학 라운드테이블 라이브 추가
Zhiyuan 커뮤니티 검색 페이지가 클라이언트 렌더링으로 프레임 페이지만 확보
영문 매체 Pandaily 1건의 2.2 시스템 전언, 표현은 국내와 일치하며 19.87% 지연 수치 추가
국내 매체 Embodied Home 1건의 FlagOS-Robo 착수 기고, 원출처는 Cross Dimension

전체 출처 목록

/pull/977>