모니터링 기간: 2026-11-05 07:00 ~ 2026-11-06 07:00 (베이징 시간, 24시간; 이전 기간 기준점은 11-05 07:00).

출처: GitHub tile-ai 조직 저장소별 점검(29개 저장소, 기간 내 푸시 10건) + 병합 및 심사 중 실값 검색(기간 내 병합 18건, 심사 중 업데이트 57건) + 신규 issue 5건 + 메인 브랜치 커밋별 점검(tilelang 5, TileOPs 9, TileFoundry 1, tilelang-ascend 2, tilelang-musa 1) + 비기본 브랜치 점검(tilelang-hygon의 feat/hcu-scaled-cast 브랜치 3건) + 릴리스 페이지 점검(tilelang / TileOPs / TileFoundry 세 저장소, 기간 내 신규 버전 없음) + 채택처 두 저장소 + 문서 사이트 및 야간 저장소 점검 + Google News 중영문 네 그룹 검색(프록시 경유) + Hacker News + arXiv. RISC-V 4개 출처 특별 순회 점검은 이번 기간 변동 없음.

이번 호 인덱스

  • 오늘의 핵심: TileOPs가 하루에 아홉 건을 병합하며 「브로드캐스트 인플레이스 읽기, 단일 웨이브 시작, 타일 선택」세 가지를 동시에 진전시켰다; 메인 저장소 다섯 건 병합 외에, 0.1.12부터 존재해 온 조용한 오류 CUDA 결함이 보고되었다; Ascend는 세그멘테이션 오류 하나를 수정했으나 동시에 threads=2에서 sin/cos가 97.1% 요소를 잘못 계산한다는 지적을 받았다
    1. 핵심 프로젝트 진행
      • 1.1 메인라인: TF32 변환 지원 round-to-nearest-even, SM90과 SM100 분리 진단 (#3714) (11-05)
      • 1.2 메인라인: host-mapped 버퍼 명시적 어노테이션 가능, CPU 텐서가 더 이상 디바이스 검사에서 거부되지 않음 (#3802) (11-05)
      • 1.3 메인라인: 스칼라 조건 내 cast가 더 이상 데이터 벡터 폭을 제한하지 않음 (#3759) (11-05)
      • 1.4 메인라인: Z3의 rlimit을 kernel별 구성 가능, 기본값은 여전히 십만 (#3752, tile-ai/tvm #91 의존) (11-05)
      • 1.5 메인라인: 중첩 T.macro가 변환 템플릿을 재사용, 프런트엔드 중복 컴파일 오버헤드 수렴 (#3760) (11-05)
      • 1.6 신규 issue: 조건 스칼라화 후 __syncthreads 누락, 0.1.12~0.1.15에서 조용히 잘못된 CUDA 생성 (#3808) (11-05)
      • 1.7 신규 issue: warp specialization 없을 때 T.Pipelined가 tcgen05 대기 전에 stage 재로드 (#3800) (11-05)
      • 1.8 심사 중: 네이티브 Apache TIRx로의 전체 마이그레이션 초안 (#3803); 공유 전치를 ldmatrix/stmatrix로 전환 (#3809) (11-05)
    1. 멀티 백엔드 적응
      • 2.1 Ascend: bitwise_rshift의 64비트 dtype을 명시적 오류로 변경, 더 이상 세그멘테이션 오류 없음 (#1954) (11-05)
      • 2.2 Ascend: A2/A3 성능 스킬을 Ascend950 워크플로에 정렬 (#1932) (11-05)
      • 2.3 Ascend: threads=2에서 tmp workspace가 무조건 절반으로 감소, sin/cos가 간접 주소 지정 tile에서 97.1% 요소 오계산 (#1991 / #1992) (11-05)
      • 2.4 Hygon: 브랜치 3건 LDS 위상 수정, 최초로 두 개의 PR 개설 (#33 / #34) (11-05)
      • 2.5 Moore Threads: README 문서 업데이트, 09-30 이후 침묵 종료 (11-05)
      • 2.6 MetaX와 mlir-ascend: MetaX 연속 세 번째 기간 푸시 없음; mlir-ascend 세 가지 TLIR 연산자 심사 중 (11-05)
    1. 생태계와 채택처
      • 3.1 TileOPs: 아홉 건 병합, 브로드캐스트 피연산자 인플레이스 읽기, GEMM 단일 웨이브 채우기, reduction 레이아웃 캐시 (11-05)
      • 3.2 TileOPs: roofline 과금 규칙 재작성, 세 개의 불가능한 대역폭 행이 합리적 구간으로 복귀 (#2830) (11-05)
      • 3.3 TileOPs: 두 건 병합이 2.5분 간격으로 이루어져 main의 GPU Smoke 실패, 당일 보수 (#2837) (11-05)
      • 3.4 TileOPs 심사 중: 3단계 타일 팩터, TN 단일 요소 수축, FP8 그룹 GEMM의 TMA 스케일 로드 (#2836 / #2838 / #2839) (11-05)
      • 3.5 TileFoundry: WGMMA 동기화 계획 병합 (#286), 부분 리덕션 완료 시맨틱 심사 중 (#288) (11-05)
      • 3.6 TileSight: H20의 WGMMA 능력 선언 수정, 저장소 최초 PR (#1) (11-05)
      • 3.7 채택처 및 제3자: TileKernels, FlashQLA 푸시 없음; 두 개의 새로운 제3자 저장소 등장 (11-05)
    1. 커뮤니티, 튜토리얼 및 활동
      • 4.1 문서 사이트 세 차례 업데이트; 야간 저장소 메인 브랜치 커밋 없음; Ascend 일일 테스트 3030건 전부 통과 (11-05)
      • 4.2 뉴스 측: 네 그룹 검색, Hacker News 및 arXiv 모두 기간 내 적중 없음 (11-05)
    1. 트렌드 관찰
  • 부록, 자료 및 점검 설명

오늘의 핵심

이날 가장 밀도 높은 산출물은 컴파일러가 아니라 연산자 라이브러리에서 나왔다. TileOPs는 21:06부터 22:46까지 한 시간 남짓 동안 여섯 건을 연속으로 머지했고, 여기에 14:01과 21:31의 두 건을 더해 하루 아홉 건을 기록했으며 모두 perf, fix, ci 태그가 붙었다. 세 가지 일이 동시에 진행됐다. 첫째는 브로드캐스트 피연산자 제자리 읽기로, lerp, where, clamp, masked_fill 다섯 종류의 연산자가 stride 0인 브로드캐스트 텐서를 먼저 출력 형상으로 전개하지 않게 되었고, 실측 결과 브로드캐스트 행 소요 시간이 메인라인의 0.13~0.44배로 떨어졌다(#2832). 둘째는 단일 웨이브 기동으로, 일원 원소별 연산이 “본문 내 최대 두 개의 저렴한 명령, 읽기/쓰기 총량이 L2의 4분의 3 이하”일 때 하나의 256 스레드 웨이브로 축소되며, 덤으로 ReLU가 NaN에 대해 0을 반환하던 오래된 문제도 수정됐다(#2829). 셋째는 타일 선택기로, 작은 M을 위한 NT GEMM에 한 웨이브를 채울 수 있는 너비의 네이티브 너비 타일을 만들어 decode-down이 뒤처지던 상태에서 가장 빠른 비교 항목보다 3% 앞서게 되었다(#2834). 세 가지 일의 공통점은 “더 빠르다”가 아니라, 매 건마다 재현 가능한 A/B 표를 동반하고 여전히 뒤처지는 행을 표시한다는 점이다.

두 번째는 신뢰성 문제이며, 두 저장소에 걸쳐 있다. 메인 저장소에 새 이슈 #3808이 열렸는데, 0.1.12에서 0.1.15까지 조건 관련 스칼라화 이후 공유 메모리 epilogue에서 __syncthreads()가 하나 빠졌고, 컴파일러는 오류를 보고하지 않으며 생성된 CUDA는 잘못되어 있다는 내용이다. 보고자는 완전한 재현 스크립트와 네 개의 버전 번호를 제시했으며, 이는 성능 저하가 아닌 “조용한 오류 코드”에 해당한다. 같은 모니터링 기간에 #3800은 또 다른 조용한 오류를 보고했다. warp specialization을 켜지 않으면 T.Pipelined가 T.tcgen05_gemm의 barrier 대기 이전에 다음 stage를 재적재하여, MMA가 읽는 operand가 이미 덮어써진 상태가 된다는 것이다. 이 두 건은 메인 저장소가 당일 머지한 #3759와 정확히 대조를 이룬다. #3759가 수정한 것은 “스칼라 조건 내 int64 cast가 데이터 벡터 너비를 16 lane에서 4 lane으로 압축하는 문제”로, 같은 스칼라화/벡터화 경계 지점에서 한쪽은 너비를 수정하고 다른 쪽은 동기화를 누락하고 있는 셈이다.

세 번째는 Ascend 측이다. tilelang-ascend가 #1954를 머지하여 T.tile.bitwise_rshift가 int64/uint64에서 컴파일 타임 세그멘테이션 오류를 일으키던 것을 명시적 ValueError로 바꾸었고, int16/uint16/int32/uint32만 허용한다. 이는 64비트 우측 시프트 지원을 새로 추가한 것이 아니라 “컴파일러가 크래시하는 것”을 “컴파일러가 거부하는 것”으로 바꾼 것이다. 같은 저장소에서 당일 같은 주제의 이슈 두 건(#1991, #1992)이 새로 열렸는데, 910_9362 / CANN 9.0.0, threads=2(C:V=1:2) 환경에서 AscendVidReduction이 kernel 내 모든 UB 할당을 무조건 절반으로 줄이고, 주입된 tmp workspace까지도 절반으로 줄여, 그 결과 sin/cos가 간접 주소 지정된 skip-set buffer에 작용할 때 3978/4096(97.1%)개의 원소가 잘못 계산되었으며, sigmoid/round는 AscendC의 calCount <= tmp 계약을 위반하여 범위를 벗어난 쓰기가 레이아웃 뒤쪽의 scratch에 떨어졌다. 이와 나란히 같은 날 #1988의 일일 테스트 보고서는 3030개 항목 전부 통과, 통과율 100%를 기록했다. 이 두 숫자를 함께 놓으면 한 가지를 말해준다. 기존 테스트가 “threads=2 + 간접 주소 지정”이라는 조합을 커버하지 못하며, 통과율을 정확성의 대체 지표로 삼을 수 없다는 것이다.

네 번째는 생태계 측의 움직임이다. Hygon 저장소는 “기능 브랜치에 네 건을 쌓아둔 채 PR을 열지 않은” 상태에서 정식 리뷰 진입으로 바뀌었다. feat/hcu-scaled-cast 브랜치가 당일 LDS 위상 수정 세 건(기본 swizzle을 64 bank에 적응, MN 슬라이스 소비 측 swizzle 계획 복원, K 파티션의 레이아웃 인식 읽기)을 추가로 반영하고, #33(scaled cast)과 #34(reduction의 lane swap과 제약 전파) 두 개의 PR을 열었다. Moore Threads는 09-30 이후의 완전한 침묵을 끝내고 메인 브랜치에 README의 설치 및 연산자 개발 설명 업데이트를 반영했다. 여기에 TileSight 저장소에 첫 PR(H20의 WGMMA 능력 선언 수정)이 등장하고 메인 저장소 #3803의 TIRx 마이그레이션 초안까지 더해지면서, 조직 차원의 세 축이 동시에 전개되는 것을 볼 수 있다. 국산 백엔드가 자체 개발 브랜치에서 공개 리뷰로 진입하고, 성능 모델링이 논문에서 저장소로 향하며, 컴파일러 기반이 vendored TVM을 교체할 준비를 하고 있다.

1. 핵심 프로젝트 진행 상황

1.1 메인라인: TF32 변환 round-to-nearest-even 지원, SM90과 SM100 분리 진단(#3714)

12:09에 병합되었습니다. 이전에는 T.cast를 tfloat32로 변환할 때 기본 TF32 근사 반올림 경로만 존재했고, ties-to-even을 원하면 CUDA helper를 직접 임포트해야 했습니다. 이번 변경은 round="rn"에 네이티브 lowering을 추가했습니다. 비포화 형식은 cvt.rn.tf32.f32를, 포화 형식은 cvt.rn.satfinite.tf32.f32를 발행하며, 기본 TF32 반올림 생성자를 우회하고 변환된 비트 패턴을 직접 보존합니다. 스칼라와 벡터 두 경로를 모두 커버하며, TF32의 lane 접근은 패킹된 벡터를 통해 이루어집니다. 아키텍처 진단은 형식별로 분리됩니다. 비포화 형식은 SM90 이상, 포화 형식은 SM100 이상을 요구하며, 충족하지 않으면 컴파일 시점에 오류를 발생시킵니다. rounding을 명시하지 않은 cast의 동작은 변경되지 않습니다. 보고자는 #3713을 종료한 요구사항 제기자로, “사용자가 더 이상 helper를 직접 가져올 필요가 없다”는 인터페이스 수렴에 해당합니다.

출처: https://github.com/tile-ai/tilelang/pull/3714

1.2 메인라인: host-mapped 버퍼를 명시적으로 어노테이션할 수 있게 되어 CPU 텐서가 더 이상 디바이스 검사에서 거부되지 않음 (#3802)

당일 생성, 당일 병합(12:08 제출, 16:02 병합). CUDA kernel은 GPU 주소 공간에 매핑된 host 메모리에 직접 접근할 수 있지만, TileLang의 기존 디바이스 검사는 텐서 파라미터가 모두 대상 디바이스에 상주한다고 가정했기 때문에 이런 CPU 텐서는 런칭 전에 거부되었습니다. 새로 추가된 T.annotate_host_mapped_buffers(*buffers)는 어노테이션된 파라미터의 인덱스를 PrimFunc의 tl.host_mapped_params 속성에 기록하며, 다중 버퍼를 지원하고 중복 선언을 병합하며 IR 직렬화와 kernel 캐시 복원을 통과할 수 있습니다. Cython과 TVM-FFI 두 launcher는 어노테이션된 파라미터에 대해 CPU 텐서를 허용하고, 나머지 dtype, 형상, 랭크, 스트라이드 검사는 그대로 유지됩니다. 디바이스 측 파라미터 검사는 여전히 현재 실행 디바이스에 정렬되며, host 텐서에는 CUDA 디바이스 번호를 제공하지 않습니다. 런타임에는 네이티브 helper가 추가되어 cuMemHostGetFlags로 등록 상태를 검증하고 cuMemHostGetDevicePointer로 디바이스 가시 주소를 해석하며, 일반 페이지 가능 메모리는 여전히 거부됩니다.

출처: https://github.com/tile-ai/tilelang/pull/3802

1.3 메인라인: 스칼라 조건 내 cast가 더 이상 데이터 벡터 폭을 제한하지 않음 (#3759)

19:27에 병합되었으며, 태그에 ascend가 포함되어 있습니다. 발단은 #3734가 DecoupleTypeCast 이후 데이터 cast의 폭 제한을 올바르게 강화했지만 조건 내의 cast까지 포함시킨 것이었습니다. T.assume(n % 16 == 0)으로 보호된 BF16 복사에서 조건에 T.Cast("int64", ...)가 있어 b5cb02633에서 16 lane에서 4 lane으로 축소되었으며, 조건이 16개 lane에서 일관되더라도 마찬가지였습니다. 수정 방법은 planner에 이미 존재하는 조건 일관성 분석을 재사용하여 cast 폭 면제를 버퍼 인덱스에서 조건으로 확장하는 것입니다. if 문, tirx.if_then_else, 스칼라 술어의 Select 조건은 별도로 접근되며 분기는 여전히 제한됩니다. lane 수준 벡터 술어 대상에서는 조건 cast의 제약이 여전히 유지됩니다. stochastic rounding의 rbits 그룹화도 폭 제약을 건너뛸 때 보존됩니다. 이번 변경은 모니터링 기간 내 두 개의 새 issue와 같은 영역에 해당하며, 스칼라화와 벡터화의 경계가 현재 결함의 고발 지대임을 보여줍니다.

출처: https://github.com/tile-ai/tilelang/pull/3759

1.4 메인라인: Z3의 rlimit을 kernel별로 구성 가능, 기본값은 여전히 십만 (#3752, tile-ai/tvm #91 의존)

23:05에 병합되었으며, 선행 조건은 fork의 tvm #91(23:03 병합)입니다. 변경은 Z3 솔버의 rlimit을 하드코딩된 100,000에서 kernel별로 커스터마이즈 가능하게 만들며, 구성하지 않으면 기존 기본값을 유지합니다. 작성자의 표현은 직접적입니다. “이것이 Z3 증명기와 관련된 많은 문제를 간접적으로 해결합니다.” 이런 변경의 의의는 “증명 예산 초과”를 조정 불가능한 환경 동작에서 조정 가능한 컴파일 파라미터로 바꾸는 데 있으며, 어제 Ascend 측에서 AutoSchedule 주기 하한을 강화하여 Z3 솔버 시간을 10.04% 줄인 것과 같은 방향의 두 가지 접근입니다. 하나는 검색 시작점을 바꾸고, 다른 하나는 검색 예산을 바꿉니다.

출처: https://github.com/tile-ai/tilelang/pull/3752, https://github.com/tile-ai/tvm/pull/91

1.5 메인라인: 중첩된 T.macro가 변환 템플릿을 재사용하여 프런트엔드 중복 컴파일 오버헤드 수렴 (#3760)

23:38에 병합되었습니다. 문제는 외부 함수가 실행될 때마다 중첩된 T.macro 정의가 소스 파싱, AST 재작성, Python 컴파일을 다시 수행한다는 점이었습니다. kernel 자체는 이미 캐시에 적중한 상태임에도 그렇습니다. 해결 방식은 컨텍스트와 무관한 변환 결과(바인딩되지 않은 코드와 재작성된 소스)만 저장하는 유계 프로세스 내 캐시를 도입하고, 각 매크로 인스턴스가 현재 globals와 클로저 값을 다시 바인딩하도록 하는 것입니다. 컨텍스트에 의존하는 변환은 기존 경로를 그대로 따르고, 래핑된 함수는 캐시를 우회합니다. 매크로 호출 지점과 kernel 캐시는 모두 변경되지 않습니다. 회귀 테스트는 새로운 클로저, globals, 캡처된 버퍼, 어노테이션, 컨텍스트 관련 폴백, 클로저 수명 주기를 커버하며, CPU 측 프런트엔드 검사는 통과했고 GPU 실행은 로컬에서 검증되지 않았습니다—작성자가 이 경계를 명확히 명시했습니다.

출처: https://github.com/tile-ai/tilelang/pull/3760

1.6 신규 issue: 조건 스칼라화 후 __syncthreads 누락, 0.1.12부터 0.1.15까지 조용히 잘못된 CUDA 생성 (#3808)

21:14에 생성되었으며, 이번 모니터링 기간에서 가장 중대한 결함 보고입니다. 재현 사례는 공유 메모리 epilogue를 사용하는 kernel로, 0.1.12, 0.1.13, 0.1.14, 0.1.15 네 버전 모두 조건 관련 스칼라화 이후 __syncthreads() 하나를 누락시키며, 컴파일러는 아무 오류도 내지 않고 생성된 CUDA는 직접적으로 잘못된 계산을 합니다. 보고자는 완전히 실행 가능한 Python 재현 스크립트와 환경(Python 3.14.9, CUDA 2.15.0+cu134)을 제공했습니다. 이런 문제의 파괴력은 네 개의 릴리스 버전에 걸쳐 있으며 어떠한 경고도 없다는 점에 있습니다—공유 메모리를 통해 단계 간 핸드오프를 수행하는 모든 kernel이 해당될 수 있으며, 사용자 측에서 보이는 것은 “결과가 틀리다”뿐입니다.

출처: https://github.com/tile-ai/tilelang/issues/3808

1.7 신규 issue: warp specialization이 없을 때 T.Pipelined가 tcgen05 대기 전에 stage를 재로드 (#3800)

08:44에 생성되었습니다. 트리거 조건은 warp specialization을 끈(tl.disable_warp_specialized=True) 상태에서 T.Pipelined와 T.tcgen05_gemm을 사용하는 루프를 실행하는 것으로, stage가 mbarrier_wait_parity 이전에 다음 라운드 복사로 덮어써져 MMA가 읽는 operand가 재작성된 상태입니다. 보고자는 lowering된 kernel 소스를 첨부하며 As의 쓰기와 tcgen05mma_ss의 읽기 사이에 순서 제약이 빠져 있다고 지적했습니다. #3808과 같은 “생성된 코드는 문제 없어 보이지만 실제로는 성립하지 않는” 부류에 속하며, 차이는 이 사안이 Blackwell의 tensor memory 경로에서 발생한다는 점입니다.

출처: https://github.com/tile-ai/tilelang/issues/3800

1.8 심사 중: 네이티브 Apache TIRx로의 전체 마이그레이션 초안 (#3803); 공유 전치 ldmatrix/stmatrix 경유로 변경 (#3809)

#3803은 이번 호에서 가장 비중 있는 심사 항목입니다: vendored된 TVM 컴파일러를 독립적인 Apache TIRx로 교체하고, 프런트엔드, IR 변환, 코드 생성, JIT 적응, 패키징을 모두 네이티브 객체 모델로 이전하며, apache/tvm-tirx의 7e49a148과 apache/tvm-ffi의 3e906bc6 두 업스트림 커밋을 pin하여 의존성 트리를 깨끗한 업스트림으로 유지하고 패치를 주입하지 않습니다. 작성자가 draft로 표시한 것은 그 자체로 “기반 세대 교체”의 공개적 준비입니다.

#3809(01:27 제출)는 또 다른 구체적인 사안을 다룹니다: T.transpose가 두 공유 버퍼 사이에서 계속 범용 SIMT 루프를 사용해 8비트와 16비트 타일이 공유 메모리 대역폭을 활용하지 못했고, examples/deepseek_v32의 FP8 희소 MLA는 16x16 레지스터 임시 저장을 직접 작성해 우회해야 했습니다. 또한 T.Pipelined가 소스 영역에 stage 축 한 차원을 추가한 후 랭크 불일치로 MakeIndices가 바로 실패하는 문제도 있었습니다. 해결 방식은 stmatrix를 지원하는 타깃(SM90 이상, CuTeDSL 제외)에서 먼저 warp-matrix lowering을 시도하는 것입니다: 16비트 타일은 각 8x8 블록마다 ldmatrix 한 번과 stmatrix.trans 한 번을 사용하고, 8비트 타일은 16x16 바이트 블록 기준으로 ldmatrix.trans 두 번과 __byte_perm 선택으로 네 행을 조합하며, 나머지 영역은 기존 SIMT 경로로 폴백합니다.

출처: https://github.com/tile-ai/tilelang/pull/3803, https://github.com/tile-ai/tilelang/pull/3809

2. 멀티 백엔드 적응

2.1 Ascend: bitwise_rshift의 64비트 dtype을 명시적 오류로 변경, 더 이상 세그멘테이션 폴트 없음 (#1954)

16:36에 병합되었습니다(ascendc_pto 브랜치). A2/A3에서 공개 API T.tile.bitwise_rshift로 int64/uint64 피연산자를 전달하면 컴파일러가 OptimizeForTarget 단계에서 바로 세그멘테이션 폴트를 일으킵니다. 수정 방법은 intrinsic을 생성하기 전에 dst와 src0의 dtype을 검사하여 int16/uint16/int32/uint32만 허용하고, 나머지는 실제 dtype과 지원 목록을 담은 ValueError를 던지는 것입니다. 시프트량 scalarValue는 표현식 dtype을 제한하지 않으며, Buffer와 BufferRegion은 통일하여 _underlying_buffer()를 사용합니다. 직접 API 진단 테스트와 서브프로세스 크래시 회귀 테스트를 새로 추가했습니다. 작성자는 경계를 명확히 밝혔습니다. 이번에는 64비트 오른쪽 시프트 지원을 추가하지 않으며, 하위 intrinsic을 직접 생성하는 경로도 변경하지 않습니다. 관련 #1720.

출처: https://github.com/tile-ai/tilelang-ascend/pull/1954

2.2 Ascend: A2/A3 성능 스킬을 Ascend950 워크플로에 정렬(#1932)

15:36에 병합되었으며, 순수한 스킬 및 프로세스 리팩터링입니다. A2/A3의 성능 튜닝 스킬을 A5(Ascend950) 워크플로 구조에 맞추어 정렬하고 통일했으며, 칩 유형 식별과 칩 정보 검색 두 가지 스킬을 새로 추가했습니다. 단독으로 보면 기능적 가치는 없지만, 성능 튜닝의 “운영 매뉴얼”이 칩 세대별로 분기되기 시작했다는 것을 의미합니다. 동일한 skill이 자신이 어느 세대에서 실행되는지 식별할 수 있어야 하며, 그렇지 않으면 튜닝 제안이 세대를 넘어 오용될 수 있습니다.

출처: https://github.com/tile-ai/tilelang-ascend/pull/1932

2.3 Ascend: threads=2에서 tmp workspace가 무조건 절반으로 감소, sin/cos가 간접 주소 지정 tile에서 97.1% 요소 오계산(#1991 / #1992)

17:03과 17:25에 동일한 주제의 issue 두 건이 연달아 열렸으며, 제목과 본문이 일치합니다(내용상 동일한 건이 두 번 제출된 것으로 볼 수 있음). 보고 환경은 910_9362 / CANN 9.0.0, threads=2(C:V=1:2)입니다. 근본 원인은 AscendVidReduction에 있습니다. 이는 kernel 내 모든 UB 할당을 무조건 절반으로 줄이는데, InjectTmpBuffer가 주입한 tmpspace도 포함됩니다. 그러나 skip-set buffer(GM 인덱스에 UB load가 포함된 간접 주소 지정, 예: T.copy(KV[b_i, idx_ub[bi_i], g_i, :D], kv_ub))는 형태가 전체 블록으로 유지되며 원래 vid 감소에 참여하지 않습니다. 결과는 두 가지 수준입니다. sin/cos는 직접 오계산되며(upstream HEAD에서 3978/4096개 요소 오류, 97.1%), sigmoid/round는 AscendC의 calCount <= tmp 계약을 위반하여 수치는 우연히 정확하지만 범위를 벗어난 쓰기가 레이아웃 뒤쪽의 scratch에 떨어지며, 레이아웃이 바뀌면 조용한 데이터 오염이 됩니다. 보고자는 이것이 #1897 review 중 발견되었으며, #1897의 수정은 count 측 의미(HasModifiedBuffer가 workspace 슬롯을 건너뛰는 것)만 커버했고 workspace 측은 여전히 처리되지 않았다고 설명했습니다.

출처: https://github.com/tile-ai/tilelang-ascend/issues/1991, https://github.com/tile-ai/tilelang-ascend/issues/1992

2.4 Hygon: 브랜치에 LDS 위상 수정 세 건, 처음으로 PR 두 건 개설(#33 / #34)

메인 브랜치는 여전히 11-02에 머물러 있으며, 당일 세 건 모두 feat/hcu-scaled-cast 브랜치에 올라갔고 작성자는 Hygon 측입니다(커밋 도메인 hygon.cn):

  • 10:06 fix(hcu): adapt default LDS swizzle to 64-bank phases
  • 14:04 fix(hcu): restore LDS swizzle planning for MN slice consumers
  • 19:49 fix(hcu): support K-partitioned layout-aware LDS reads

더 중요한 것은 리뷰 상태의 변화입니다. 09:08에 PR #33(scaled cast, 즉 브랜치 본체)이 열렸고, 19:52에 PR #34가 열렸습니다(reduction의 XOR shuffle을 DPP와 lane swap으로 최적화하고, “레이아웃 추론이 알려진 제약을 먼저 전파한 후 자유 후보를 할당”하는 수정 포함). 지난 리포트에서는 “네 건 모두 기능 브랜치에 있으며 아직 PR이 열리지 않음”이라고 썼는데, 이번 모니터링 기간의 두 PR로 Hygon은 자체 개발 브랜치에서 공개 리뷰 단계로 나아갔으며, 국산 백엔드 중 이 경로를 처음으로 완주한 곳입니다.

출처: https://github.com/tile-ai/tilelang-hygon/pull/33, https://github.com/tile-ai/tilelang-hygon/pull/34, https://github.com/tile-ai/tilelang-hygon/commit/07451160e5aa758419201adb598725cbef70e3a4

2.5 Moore Threads: README 문서 업데이트, 09-30 이후 침묵 종료 (11-05)

19:46 메인 브랜치에 docs: update README installation and operator development references 커밋이 올라갔으며, 이는 해당 저장소의 09-30 이후 첫 커밋이다. 같은 기간 6개의 잔여 PR(#1~#7 중 의존성 업그레이드, TileOPs 서브모듈, MUSA 통합의 증거 기준 문서)의 타임스탬프가 일괄 갱신되었으나, 내용은 여전히 04월에서 08월까지의 오래된 제안이며 이번 모니터링 기간에는 코드 변경이 없다. 판단은 보수적으로 해야 한다: 문서 커밋은 저장소가 유지보수되고 있음을 보여주지만 백엔드 개발 재개를 입증하기에는 부족하다. 진짜 신호는 이후 연산자나 lowering 커밋이 나타나는지 여부를 봐야 한다.

출처: https://github.com/tile-ai/tilelang-musa/commit/4cac45b859108a86ac9a0b1cbfdeb33da7711697

2.6 MetaX와 mlir-ascend: MetaX 3번째 모니터링 기간 연속 푸시 없음; mlir-ascend TLIR 연산자 3건 심사 중 (11-05)

tile-ai/tilelang-metax의 마지막 푸시는 여전히 10-26이며, 3번째 모니터링 기간 연속 침묵이다. tile-ai/tilelang-mlir-ascend 메인 브랜치에는 새 커밋이 없으나, TLIR 방언 기반 연산자 PR 3건이 진행 중이다: #203은 TLIR에 tl.sub/mul/div/max/min을 추가하고 TL에서 HIVM으로의 lowering을 보완했으며 01:42에 업데이트되었다; #211은 tl.shl 추가, #212는 tl.shr 추가로 두 건이 19:44와 20:58에 차례로 커밋되었다. 이 라인이 하는 일은 TileLang의 시맨틱을 한 층씩 MLIR 방언에 내리는 것으로, 속도는 느리지만 방향은 일관된다.

출처: https://github.com/tile-ai/tilelang-metax, https://github.com/tile-ai/tilelang-mlir-ascend/pull/203, https://github.com/tile-ai/tilelang-mlir-ascend/pull/211, https://github.com/tile-ai/tilelang-mlir-ascend/pull/212

3. 생태계와 도입 주체

3.1 TileOPs: 9건 병합, 브로드캐스트 피연산자 인플레이스 읽기, GEMM 단일 웨이브 채우기, reduction 레이아웃 캐시 (11-05)

9건은 14:01과 21:06~22:46 두 시간대에 집중되었으며, 건별로 핵심을 보면:

  • #2832 브로드캐스트 피연산자 인플레이스 읽기: LerpTensorFwdOp, WhereFwdOp, ClampTensorFwdOp, MaskedFillScalarFwdOp, MaskedFillTensorFwdOp 다섯 가지 연산자는 더 이상 stride 0인 브로드캐스트 텐서를 출력 형상으로 먼저 확장하지 않고, 하나의 kernel에서 stride 0을 기준으로 직접 읽습니다. 하나의 공유 builder가 다섯 가지 모두를 처리하며, 피연산자 형상은 하나의 루프 중첩으로 병합되고, 16바이트 이내의 벡터는 한 줄의 내부 루프에 유지되며, 각 연산자는 자신의 원소별 본체만 작성합니다. 브로드캐스트 행의 소요 시간은 메인라인의 0.13~0.44배로, torch-compile과 동등하거나 더 우수하며, 나머지 원소별 행은 메인라인과 바이트 단위로 일치합니다.
  • #2829 단항 원소별 단일 웨이브: 본체 내에서 최대 두 개의 연산이 각각 하나의 명령어로 축소되고, 읽기/쓰기 총량이 L2의 4분의 3을 넘지 않으며, 결과와 피연산자의 폭이 같을 때 256 스레드의 단일 웨이브로 축소됩니다. 부수적으로 ReLU가 NaN에 대해 0을 반환하던 문제를 수정했습니다(NaN 반환으로 변경, 16비트는 torch 비트 패턴, float32는 정규 NaN 사용). H200에서 327개 GPU 회귀 전부 통과, 13개 신규 케이스가 Compute Sanitizer memcheck를 통과했습니다.
  • #2834 소형 M NT GEMM의 네이티브 폭 타일: ds-v3-decode-down(128x7168x2048, NT)은 메인라인에서 132개 SM 중 112개만 사용하며, 112 폭 타일은 0.1.12에서 일곱 개의 n16 WGMMA로 분할되었습니다. 매 16개 K마다 타일 자체 폭의 WGMMA를 발행하도록 변경한 후, decode-down은 가장 빠른 비교 항목보다 3% 앞서고, gate-up-b32는 메인라인보다 1.4% 빠릅니다(cuBLAS보다는 여전히 0.5~1% 뒤짐). 새로 추가된 fill 타일은 96 < M <= 128이고 N이 8로 나누어지는 형상에만 활성화되며, 구조 인자 0.58은 별도로 피팅되었습니다.
  • #2835 reduction 레이아웃 캐시: 리덕션 kernel은 매 호출마다 축 치환과 출력 형상을 재구성하지만 ReduceCall은 고정되어 있습니다. 각 kernel 인스턴스마다 한 번만 계산하고 기존 텐서 어댑터와 순수 형상 helper를 공유하도록 변경했으며, 전역 캐시는 도입하지 않았습니다. 여섯 그룹의 FP32/BF16 VarMeanFwdOp 구성에서 전체 핫 호출 소요 시간이 4.33%에서 6.17% 감소했고, 생성된 CUDA와 호스트 소스는 완전히 동일합니다. 절감된 것은 호출 준비 비용이지 GPU 시간이 아닙니다.
  • #2833 CI 수정: GitHub가 runner 2.336.0을 폐기한 후 gpu-smoke가 전부 대기열에 쌓였고, entrypoint.sh에 --disableupdate가 있어 자체 업그레이드가 불가능했기에, RUNNER_VERSION을 2.336.0에서 2.338.2로 올렸습니다.

출처: https://github.com/tile-ai/TileOPs/pull/2832, https://github.com/tile-ai/TileOPs/pull/2829, https://github.com/tile-ai/TileOPs/pull/2834, https://github.com/tile-ai/TileOPs/pull/2835, https://github.com/tile-ai/TileOPs/pull/2833

3.2 TileOPs: roofline 산정 규칙 재작성, 불가능한 대역폭 행 세 개가 합리적 구간으로 복귀 (#2830)

야간 작업 41873301494에서 물리적으로 불가능한 roofline 세 행이 포착되었습니다: GQAVarlenFwdOp의 두 gpt-oss-serve-window 구성이 7.48과 7.50 TB/s를, GroupedGEMMFwdOp의 qwen3-30b-ep8-empty가 5.30 TB/s를 기록했습니다. 이번 변경은 산정 규칙을 “이번 호출이 실제로 얼마나 읽었는가”에 따라 재작성했습니다: GQA의 dense, varlen, paged 전방은 “query가 볼 수 있는 key 행”에 대해서만 K/V를, “key를 볼 수 있는 query 행”에 대해 q를, key가 실제로 도달한 절단 위치에 대해 RoPE 테이블을, key를 본 요청에 대해 FP8 스케일링을 계산합니다. GroupedGEMM은 새로운 grouped_gemm_roofline을 통해 batch_sizes에 따라 특정 행의 그룹을 계산합니다. NSA 압축, NSA 희소, DSA decode, MHA 페이지드, FP8 lightning indexer는 모두 실제로 읽는 위치에서만 과금되며, DSA는 추가로 is_causal=False를 인식합니다. 수정 후 세 행은 0.62, 0.62, 2.65 TB/s가 되었습니다. 부수적 이득으로 빈 K/V 저장소와 빈 페이지 풀의 0으로 나누기 문제도 수정되었습니다. 테스트 노드 16개 추가.

출처: https://github.com/tile-ai/TileOPs/pull/2830

3.3 TileOPs: 두 건의 머지가 2.5분 간격으로 이루어져 main의 GPU Smoke 실패, 당일 보수 (#2837)

22:46에 머지된 이 커밋 자체가 하나의 규율 기록이다. #2824는 21:06 머지 시 grouped GEMM의 roofline 행을 sizes를 반드시 선언하고 그로부터 G를 도출하도록 변경했다. #2830은 21:08에 머지되었는데, 여전히 G만 있고 sizes가 없었다. 두 커밋은 약 2.5분 간격이며 각자의 CI는 모두 통과했으나, 머지 후 main의 GPU Smoke가 즉시 RowError: row misses ['sizes']를 보고했다. 수정법은 _grouped의 G: 2를 sizes: [1, 0]으로 바꾸는 것이며, 단언된 바이트 수(24, 32)는 변하지 않는다. 이런 사고의 원인은 누군가 잘못 작성한 것이 아니라 병렬 머지에 post-merge 게이트가 없기 때문이다. 단일 커밋의 CI 통과로는 ‘두 커밋의 의미가 교차’하는 상황을 커버할 수 없으며, 머지 직후 전체 실행에 의존할 수밖에 없다.

출처: https://github.com/tile-ai/TileOPs/pull/2837, https://github.com/tile-ai/TileOPs/pull/2824, https://github.com/tile-ai/TileOPs/pull/2830

3.4 TileOPs 심사 중: 3단계 타일 팩터, TN 단일 요소 수축, FP8 그룹 GEMM의 TMA 스케일 로드 (#2836 / #2838 / #2839)

#2836은 coop2_swap의 3단계 타일에 별도 팩터(1.36)를 피팅한다. FLOP 기준으로는 4단계보다 빠르지 않지만, 바이트와 K 스텝 수 기준으로 약 10% 과대평가되어 결과적으로 160 너비 타일을 밀어내고 야간 성적이 1.005~1.011배에서 0.985~0.995배 QuACK로 떨어졌기 때문이다. 팩터는 그 42개의 off-manifest 형상에서만 피팅되었으며(플랫폼 구간 1.344~1.392), 44개 형상 스윕에서 선택기의 regret은 0.89%에서 0.06% 기하평균으로, 최대값은 5.04%에서 0.99%로 감소했다. #2838은 디스패처가 K를 연속 차원으로 취급하여 TN 레이아웃 K=1의 합법적 호출(A=[1,64], B=[1,64]에서 AᵀB를 계산하는 것은 원래 cp.async 내부 커널로 가능했음)을 거부하던 문제를 수정하며, 양쪽 피연산자의 물리적 연속 차원이 각각 최소 4바이트 행 너비를 가지는지 확인하는 폴백 검사로 바꾸고 24개의 테스트 노드를 추가했다. #2839(00:56 제출)는 FP8 그룹 GEMM이 TMA로 A의 스케일을 로드하도록 하며(박스당 4개 K 스텝, stage_scales 2, 3개 행에서 캘리브레이션), K <= 1536인 비융합 타이트 그룹 BF16/FP16 GEMM에 64x256 ping-pong 타일을 적용했다. FP8 qwen3-30b-ep8-skew-up은 0.973배에서 1.015배 DeepGEMM으로, BF16 skew-down은 0.962배에서 1.099배 QuACK로 상승했다. #2840(06:51 제출)은 SM89의 prefill sinks를 보완하고 sink의 유무를 컴파일 인스턴스 정체성에 포함시켰다.

출처: https://github.com/tile-ai/TileOPs/pull/2836, https://github.com/tile-ai/TileOPs/pull/2838, https://github.com/tile-ai/TileOPs/pull/2839, https://github.com/tile-ai/TileOPs/pull/2840

3.5 TileFoundry: WGMMA 동기화 계획 머지(#286), 부분 리덕션 완료 의미 심사 중(#288)

13:40에 머지된 #286은 지난 호 심사 중 항목으로, WGMMA의 비동기성을 다룬다. 명령이 발행된 후에도 공유 메모리와 레지스터를 계속 읽으므로, 후속 접근은 그 효과 뒤에 정렬되어야 한다. 방식은 각 피연산자 효과마다 완료 조건을 선언하고, fence, commit, wait를 이를 필요로 하는 HIR 노드에 연결하며, lowering이 명령 발행 지점에서 이 단계들을 소비한다. 후속 스코프가 집단 대기를 수용할 수 없으면 발행 스코프에서 완료한다. 동시에 레지스터 Reshard의 앨리어싱을 수정하여, 각 요소가 복사본을 보유한 각 스레드에서 동일한 레지스터에 유지되도록 하고, 이 저장 정체성으로 레지스터 의존성을 추적한다. SM90에서는 sm_90a로 별도 컴파일하여 WGMMA 그룹 단계를 발행하는 CUDA 유닛을 생성한다. 저자는 두 가지 리스크를 명시했다. 행렬 명령 발행기가 아직 연결되지 않았으므로 이 커밋은 실행 정확성을 증명하지 않으며 성능도 제공하지 않는다. TMA의 완료 의미는 별도로 다룬다. 20:12에 #288을 별도로 열어 ‘완료된 부분 리덕션’의 분석상 가격 책정을 다룬다.

출처: https://github.com/tile-ai/TileFoundry/pull/286, https://github.com/tile-ai/TileFoundry/pull/288

3.6 TileSight: H20의 WGMMA 능력 선언 수정, 저장소 첫 PR(#1)

14:37 커밋, 17:26 업데이트, tile-ai/TileSight(24 스타)의 첫 번째 PR입니다. 이 저장소는 07-24 arXiv 논문 《TileSight: A First-Principles Tile-Centric Analytical GPU Performance Model from Cores to Clusters》의 오픈소스 구현으로, 타일 형상, 데이터 이동, 소프트웨어 파이프라인, 하드웨어 프로파일로부터 CPU에서 연산자 비용, 캐시 트래픽, 실행 시간을 추정하며, CUDA/HIP 프로브가 대상 GPU를 별도로 측정합니다. 이번 변경은 작지만 방향은 명확합니다. H20은 Hopper/GH100으로, requires_arch=("wgmma",)가 있는 계획은 아키텍처 프로파일이 WGMMA 지원을 선언하지 않아 UnsupportedError를 던졌는데, 이제 support_wgmma=True로 설정하고 support_utcmma=False를 명시적으로 유지하여 이러한 계획은 수용되면서도 tcgen05 및 Tensor Memory 요구는 여전히 거부됩니다. 작성자는 또한 용량을 SKU별로 분리 처리해야 한다고 지적합니다(NVIDIA가 96 GB와 141 GB의 H20을 동시에 표기). 이번에는 능력 메타데이터만 변경되었고, 용량, 대역폭, 주파수, 처리량, 활용률 수치는 모두 그대로입니다. 검증은 CPU에서 847개 항목 전부 통과이며, “GPU 성능 검증이 아님”을 명확히 선언했습니다.

출처: https://github.com/tile-ai/TileSight/pull/1, https://arxiv.org/abs/2607.22432

3.7 채택자와 서드파티: TileKernels, FlashQLA 푸시 없음; 새로운 서드파티 저장소 두 개 등장(11-05)

deepseek-ai/TileKernels는 여전히 10-14에 멈춰 있고, QwenLM/FlashQLA는 10-30에 멈춰 있으며, 이번 모니터링 기간에는 모두 커밋이 없었고, FlashQLA의 최신 릴리스는 여전히 09-30의 v0.1.3입니다. 서드파티 측에는 새로운 소규모 저장소 두 개가 등장했습니다: Tianchen-ai/tilelang-weft-bench(“TileLang-Weft full CPU operator benchmarks using the shared Weft Bench engine”, 0 스타, CPU 측 연산자 벤치마크를 위한 통합 엔진 구축), flytiger-eco/tilelang-wrapper-for-sail(0 스타, 설명 없음). 둘 다 매우 초기 단계이므로 우선 관찰 명단에 기록하되, 기술적 진전으로 작성하기는 적절하지 않습니다.

출처: https://github.com/deepseek-ai/TileKernels, https://github.com/QwenLM/FlashQLA, https://github.com/Tianchen-ai/tilelang-weft-bench, https://github.com/flytiger-eco/tilelang-wrapper-for-sail

4. 커뮤니티, 튜토리얼 및 활동

4.1 문서 사이트 세 차례 업데이트; 야간 저장소 메인 브랜치 커밋 없음; Ascend 일일 테스트 3030개 전부 통과(11-05)

tile-ai/tilelang.github.io는 16:07, 19:33, 23:43에 각각 Update docs를 푸시했으며, 이는 메인 저장소의 당일 인터페이스 변경(host-mapped 어노테이션, TF32 rounding, Z3 설정)에 대응합니다. TileOPs-nightly는 브랜치 푸시만 있었고 메인 브랜치에는 새 커밋이 없었으며, TileOPs.github.io는 09:02에 한 차례 푸시가 있었습니다. Ascend 저장소의 일일 테스트 이슈 #1988은 11-05 08:16 회차에서 3030개 항목이 전부 통과, 통과율 100%를 기록했으며, 같은 날 새로 열린 #1991/#1992와 대조를 이룹니다(2.3 참조).

출처: https://github.com/tile-ai/tilelang.github.io, https://github.com/tile-ai/tilelang-ascend/issues/1988

4.2 뉴스 측: 네 개 쿼리 그룹, Hacker News와 arXiv 모두 모니터링 기간 내 적중 없음(11-05)

Google News의 네 가지 쿼리(영문 "TileLang" OR "tile-lang", TileLang GPU kernel, 중국어 TileLang 算子, TileLang 编译器)에서 가장 최근 적중 항목은 376시간 전의 SemiAnalysis 《The Huawei-DeepSeek Symbiosis》이며, 나머지는 09-30 무렵의 “DeepSeek, Ascend 버전 TileLang, DeepGEMM, DeepEP 오픈소스화” 보도(약 880시간 전)에 집중되어 있어 모두 이번 모니터링 기간보다 이전입니다. Hacker News에서 tilelang으로 검색한 결과 24시간 내 0건이었고, 수집된 세 개의 Show HN은 터미널 데이터 뷰어, 워크플로 엔진, macOS 파일 관리자로 주제와 무관합니다. arXiv의 all:tilelang 최신 적중은 11-03의 《Beyond Compression Ratio: High-Throughput KV Compression for Disaggregated LLM Serving》(모니터링 기간 외, TileLang을 인용한 작업)이며, 그 이전은 07-24의 TileSight 본체입니다. 따라서 리포트 본문은 여전히 전부 코드 측에서 비롯됩니다.

출처: https://news.google.com/, https://news.ycombinator.com/, https://arxiv.org/

5. 트렌드 관찰

첫째, 연산자 라이브러리의 경쟁 포인트가 이미 “연산자 수”에서 완전히 “선택기와 준비 비용”으로 옮겨갔습니다. 오늘 TileOPs의 아홉 건 중 실제로 GPU kernel을 수정한 것은 #2832(브로드캐스트 인플레이스 읽기)와 #2834(네이티브 폭 타일)뿐이며, #2835는 호출 준비 비용을 절감했고(4.33%에서 6.17%, 생성 소스 불변), #2836은 하나의 피팅 인자를 변경해 regret을 0.89%에서 0.06%로 낮췄습니다. 이는 성능 격차의 남은 여지가 주로 “어떻게 계산하느냐”가 아니라 “어느 타일을 선택하고 어떤 준비 작업을 덜 하느냐”에 있음을 보여줍니다. 이 경로의 끝에는 수동 조정 매개변수 더미가 아니라 캘리브레이션 계약으로 기술된 비용 모델이 있게 될 것입니다. 오늘 #2836의 “단독 피팅, 상수 하나만 변경”이 바로 그 형태의 초기 형태입니다.

둘째, 컴파일러 측의 현재 주요 결함 유형은 컴파일 실패나 성능 부족이 아니라 “조용히 잘못된 코드를 생성하는 것”입니다. #3808은 0.1.12부터 0.1.15까지 네 버전에 걸쳐 __syncthreads() 하나가 누락되었고, #3800은 Blackwell 경로에서 MMA가 덮어씌워진 operand를 읽게 했으며, #1991/#1992는 Ascend threads=2에서 sin/cos가 97.1%의 원소를 잘못 계산하게 했습니다. 세 가지 모두 오류를 보고하지 않고, 일반 테스트를 통과하며, 사람이 표적화된 재현을 작성해야만 잡을 수 있습니다. 이런 결함은 사용자에게 가장 큰 피해를 줍니다. “컴파일러가 올바른가”라는 전제를 검증이 필요한 가정으로 바꿔버리기 때문입니다. 이에 대응하는 엔지니어링 조치는 단위 테스트 수를 계속 늘리는 것이 아니라 형태 조합의 차분 테스트를 확대하는 것(대조군은 reference 구현으로 원소별 비교)이어야 합니다.

셋째, Ascend 측의 리듬이 “아키텍처 변경 후 회귀 정리”에서 “정확성 경계 정리”로 전환되었습니다. #3512 같은 구조적 변경이 가져온 네 가지 회귀가 지난 모니터링 기간에 막 정리되었고, 이번 기간의 두 건의 머지(세그멘테이션 오류를 오류 보고로 변경, 성능 스킬 세대 분기)와 두 개의 신규 이슈(tmp workspace 절반 감소, calCount <= tmp 위반)는 모두 경계 수렴에 속합니다. 주목할 점은 #1991의 보고자가 #1897의 리뷰어였고, #1897의 수정 방식은 count 측만 커버했다는 것입니다. 동일한 레이아웃 로직의 다른 측면이 2주 후에야 지적되었다는 것은 Ascend 백엔드의 레이아웃 불변량이 아직 검사 가능한 서면 계약으로 형성되지 않았음을 보여줍니다.

넷째, 국산 백엔드의 “공공화”가 가속화되고 있습니다. Hygon은 자체 개발 브랜치에서 두 개의 공식 PR로 나아갔고, Moore Threads는 문서 유지보수를 재개했으며, mlir-ascend는 세 개의 작은 PR로 산술 연산자를 하나씩 TLIR 방언으로 옮겼습니다. 세 라인의 공통점은 더 이상 “대형 백엔드를 한 번에 머지”하기를 기다리지 않고, 리뷰 가능한 최소 단위를 공공 저장소에 밀어 넣는다는 것입니다. 이는 업스트림에 좋은 일입니다. 리뷰어가 3만 줄을 한 번에 머지할 때가 아니라 일찍부터 레이아웃과 lowering 설계에 의견을 제시할 수 있기 때문입니다.

마지막 리스크 측면: 메인 저장소 #3803의 TIRx 마이그레이션이 진행되면 3rdparty/tvm의 vendored 구조가 두 개의 pin된 업스트림 커밋으로 대체되며, 그때 TVM 내부 API에 의존하는 모든 백엔드(Ascend, Hygon, mlir-ascend의 글루 레이어)가 함께 변경되어야 합니다. 초안에는 “의존성 패치를 주입하지 않음”이 명시되어 있는데, 이는 약속이자 제약입니다. 오늘 mlir-ascend가 BishengIR 어댑터를 contrib로 옮기고, Ascend가 성능 스킬을 칩 세대별로 분기한 것은 모두 이런 기반 전환을 위해预留한 교체 가능 면으로 볼 수 있습니다.

부록, 자료 및 검증 설명

출처 검증표

출처 검증 결과
tile-ai 조직(저장소 29개) 모니터링 기간 내 10개 저장소에 푸시 발생
메인 저장소 tilelang 메인 브랜치 5건 머지, 신규 이슈 2건(#3808, #3800), 심사 중 업데이트는 스칼라화, CuTeDSL, Profiler, Ascend 네 클러스터 중심
TileOPs 메인 브랜치 9건 머지, 심사 중 4건 신규 또는 업데이트, 신규 이슈 없음
TileFoundry 메인 브랜치 1건 머지(#286), 심사 중 1건(#288)
TileSight 최초 PR(#1), 메인 브랜치 커밋 없음
tilelang-ascend 기본 브랜치 ascendc_pto 2건 머지(#1932, #1954), 신규 이슈 3건(#1991, #1992는 동일 주제, #1988은 일일 테스트 리포트)
tilelang-mlir-ascend 메인 브랜치 신규 커밋 없음, #203, #211, #212 세 건의 TLIR 연산자 PR 진행
tilelang-hygon 메인 브랜치 신규 커밋 없음(11-02에 정지), feat/hcu-scaled-cast 브랜치 3건, 신규 PR #33, #34
tilelang-musa 메인 브랜치 문서 커밋 1건(09-30 이후 최초), 레거시 PR 6건 타임스탬프 갱신, 내용 변경 없음
tilelang-metax 모니터링 기간 내 푸시 없음(연속 세 번째 모니터링 기간)
TileOPs-nightly / TileOPs.github.io / tilelang.github.io 나이틀리 저장소 메인 브랜치 커밋 없음, TileOPs 문서 사이트 1회 푸시, tilelang 문서 사이트 Update docs 3회
릴리스 페이지(tilelang / TileOPs / TileFoundry) 모니터링 기간 내 신규 버전 없음, tilelang 최신은 여전히 09-30의 v0.1.15, TileOPs는 10-27의 v0.1.0, TileFoundry는 10-25의 v0.0.4rc1
TileKernels / FlashQLA 모니터링 기간 내 푸시 없음
TileLang×RISC-V 4개 소스 점검 변화 없음(4개 업스트림의 인용 및 PR 상태가 이전 스냅샷과 동일)
Google News(중영문 4개 그룹) / Hacker News / arXiv 모니터링 기간 내 실질적 적중 없음, 최신 적중은 376시간 전

전체 출처 목록

검증 설명

이번 호의 모든 병합, 심사 중, issue 및 커밋 수량은 모두 GitHub 검색과 원자 소스의 실측 출력에서 비롯되었다: 병합과 심사 중은 search API를 사용했으며(병합 18건, 심사 중 업데이트 57건, 신규 오픈 issue 5건), 커밋 제목은 각 브랜치의 commits atom을 사용했고(12개 브랜치, 21건이 모니터링 기간 내에 해당), 릴리스 버전은 releases atom을 사용했다. 조직 수준 익명 API는 수집 후반부에 시간당 한도에 도달했으며, 메인 브랜치 이외의 조직 목록은 웹페이지와 atom 소스를 교차 검증했고 추정치는 사용하지 않았다. #1991과 #1992 두 issue의 제목과 본문이 일치하여 “동일 제목 두 건”으로 기록했으며, 하나로 병합하지 않았다. Hygon 세 건과 Moore Threads 한 건은 미병합 커밋으로, 브랜치 수준 동향으로 서술하며 메인라인에 이미 병합되었음을 의미하지 않는다. TileSight와 TileFoundry의 WGMMA 관련 변경은 모두 작성자가 자술한 바에 따라 기능 메타데이터 또는 동기화 계획으로 한정되었으며, 실행 정확성이나 성능을 주장하지 않았고 보고서는 그 한정을 그대로 따른다. Google News, Hacker News 및 arXiv 세 뉴스 채널은 본 모니터링 기간 모두 히트가 없었다.