모니터링 기간: 2026-10-28 07:00 ~ 2026-10-29 07:00 (베이징 시간, 24시간).

출처: GitHub tile-ai 조직 저장소별 점검(tilelang / TileOPs / TileFoundry / tilelang-ascend / tilelang-mlir-ascend / tilelang-hygon / tilelang-metax / tilelang-musa / TileRT / tilescale / DeepStack / 문서 사이트) + 머지 및 심사 중 실값 검색(머지 24건, 심사 중 업데이트 48건) + 신규 issue 전수 확인(6건) + 커밋 수준 diff 및 파일 목록 점검 + 릴리스 페이지 및 tag 점검 + 서드파티 백엔드 저장소 점검 + Google News 중국어·영어 6개 쿼리(프록시 경유) + Hacker News + arXiv.

이번 호 인덱스

  • 오늘의 핵심: Ascend 910 A2/A3의 NPUIR 백엔드가 mlir-ascend 메인라인에 병합되었고, 504개 자체 테스트 전부 통과; TileOPs 선택기가 피크 시간 기준으로 보정되도록 변경되어 manifest 미스율이 5.79%에서 0.48%로 감소; 24시간 동안 24건 병합, 48건 리뷰 중 업데이트, 신규 이슈 6건
    1. 핵심 프로젝트 진행 상황
      • 1.1 메인 저장소: 스칼라 읽기의 인덱스 계수가 더 이상 lane 수에 섞이지 않으며, 행 너비 32768 이상의 컴파일 크래시가 닫힘(#3453)(10-28)
      • 1.2 메인 저장소: 배치 all-reduce가 스칼라 브랜치로 스레드 구간을 파싱하며, batch>1일 때 2048개 출력이 전부 틀리던 문제 수정(#3341)(10-28)
      • 1.3 메인 저장소: SIMT 원자 영역의 형상 검증이 보강되어, 범위를 벗어난 영역은 컴파일 시점에 거부됨(#3465)(10-28)
      • 1.4 메인 저장소: 희소 MMA의 K 테일 블록이 더 이상 조용히 무시되지 않음(#3367)(10-28)
      • 1.5 메인 저장소: atomic_addx4의 대상 dtype이 float*로 좁혀짐(#3369)(10-28)
      • 1.6 메인 저장소: restrict가 아닌 파라미터의 handle 접미사가 더 이상 잘리지 않음(#3366)(10-28)
      • 1.7 메인 저장소: TMA 디스크립터가 검증된 이름만 기록함(#3484)(10-28)
      • 1.8 메인 저장소: profiler 출력 인덱스가 일괄 검증되며, 스칼라와 리스트 형식에 동일한 경계 규칙 적용(#3486)(10-28)
      • 1.9 메인 저장소: T.Parallel의 coalesced_width가 일괄적으로 IntImm으로 변환됨(#3374)(10-28)
      • 1.10 메인 저장소: 테스트 인프라에서 cache 민감 케이스가 without_kernel_cache로 변경됨(#3695 / #3696)(10-28)
      • 1.11 신규 결함 세 건: SM120에서 13개 예제 실패, IfStmtBinding 지수적 컴파일, without_kernel_cache가 강제 재컴파일하지 않음(#3701 / #3700 / #3699)(10-28)
    1. 다중 백엔드 적응(Ascend / Hygon / ROCm)
      • 2.1 Ascend: 910 A2/A3의 NPUIR 백엔드가 mlir-ascend 메인라인에 병합되었고, 504개 자체 테스트 전부 통과, 72개 예제 중 1건만 환경적 실패(#207)(10-28)
      • 2.2 Ascend 메인 저장소: Bisheng 빌드 아이덴티티가 바이너리 캐시 키에 포함됨(#3691)(10-28)
      • 2.3 Ascend 메인 저장소: 수기 파이프라인이 구성 레지스터 위상을 유지함(#3624)(10-28)
      • 2.4 Ascend 저장소 리뷰 중: W4A4 int4×int4 GEMM 결과 오류의 근본 원인과 수정 방법(#1731)(10-28)
      • 2.5 Ascend 저장소 리뷰 중: a2a3 스케줄러 마이그레이션, 100개 파일 18453줄(#1951)(10-28)
      • 2.6 Ascend 저장소 리뷰 중: Carver가 선택된 SDK에 따라 A3 리소스 예산을 읽음(#1955)(10-28)
      • 2.7 Ascend 저장소 리뷰 중: AI Core Exception Dump의 의존성이 CANN 9.2.0으로 낮아짐(#1956)(10-28)
      • 2.8 Ascend 저장소 리뷰 중: 문서가 T.Tensor로 전환되고 T.Buffer DSL 인터페이스 폐기(#1957)(10-28)
      • 2.9 Hygon: HCU 일반 복사의 LDS swizzle 기능 브랜치, 18개 파일에 5개 신규 테스트 포함(#30)(10-28)
      • 2.10 ROCm: pip 버전 SDK의 ROCm 10 지원 병합, MI355X가 더 이상 gfx900으로 오판되지 않음(#3549)(10-28)
    1. 생태계와 채택 측(TileOPs / TileFoundry)
      • 3.1 TileOPs: 선택기가 피크 시간 기준으로 보정되도록 변경되어 manifest 미스율 5.79%에서 0.48%로 감소(#2784)(10-28)
      • 3.2 TileOPs: 비 NT 레이아웃이 전치 영속 커널로 전환되어, 2112×7168×4096 TN이 195.3에서 175.3마이크로초로 감소(#2789)(10-28)
      • 3.3 TileOPs: cumsum 긴 행이 2단계 시드 스캔으로 전환되어, (8,65536)이 12.75에서 5.18마이크로초로 감소(#2790)(10-28)
      • 3.4 TileOPs: extrema 리덕션이 PTX의 max.NaN을 사용하도록 변경되어, NaN 전파는 동일하고 회귀는 사라짐(#2792)(10-28)
      • 3.5 TileOPs: 병렬 cumsum의 유효 행 tile, GDN 좁은 프리필 청킹 두 건(#2788 / #2786)(10-28)
      • 3.6 TileOPs 신규 이슈: 연속 호출 시 대형 GEMM 행이 최고 기준선보다 뒤처짐(#2791)(10-28)
      • 3.7 TileFoundry: ring 단계 바인딩과 컴파일 흐름 통합, 70개 파일(#277)(10-28)
      • 3.8 TileOPs 리뷰 중: 릴리스 이미지에 TileOPs 0.1.0과 TileFoundry 0.0.3을 함께 패키징(#2793)(10-28)
    1. 커뮤니티, 튜토리얼 및 이벤트
      • 4.1 문서 사이트 자동 업데이트 두 건(10-28)
      • 4.2 Ascend 저장소 문서 팩트 체크 및 설치 수정 일괄 리뷰 중, 일곱 건 동시 진행(10-28)
      • 4.3 Ascend 저장소 신규 연산자 예제 리뷰 중: GroupNorm과 fla

_청크 두 연산자(#1607 / #1953 / #1952)(10-28)

  • 4.4 서드파티: 커뮤니티 자동 튜닝 에이전트의 중국어 설명 갱신(#74), Hexagon 백엔드 저장소 메인 브랜치는 모니터링 기간 내 신규 커밋 없음(10-28)
  • 4.5 뉴스 측: Google News 6개 조(중문·영문) 질의, Hacker News 및 arXiv 모두 모니터링 기간 내 실질적 히트 없음(10-28)
    1. 트렌드 관찰
  • 부록. 자료 및 검증 설명

오늘의 핵심

오늘 모니터링 기간의 중심은 Ascend 측입니다. tilelang-mlir-ascend는 Ascend 910(A2/A3)의 NPUIR 백엔드 전체를 메인라인에 병합했습니다. 55개 파일, 21,490줄 추가의 단일 커밋으로, Python 측은 tilelang/ascend910 패키지(backend / adapter / codegen / compiler / execution_backend / jit / pipeline / runtime / target 및 language 아래의 kernel, copy, gemm, npuir 방언 면)이고, C++ 측은 src/ascend910/target 아래의 개발자·전문가 두 가지 emitter 세트, op 레이어와 LowerNpuirBlock, NpuLoopVectorize, RewriteFDivToMul 세 개의 pass이며, 런타임에는 npu_launcher.h와 npu_utils를 보강했고, 설치는 install_npuir.sh를 사용하며, target 별칭은 ascend910 / ascend-910 / a2 / a3 / npuir를 허용합니다. 작성자가 제시한 검수 결과는 저장소 자체의 두 가지 테스트 세트로, pytest testing/npuir 504개 항목 전부 통과, examples 72개 예제 중 71개 통과 및 0 타임아웃 0 오류였으며, 유일하게 실패한 deepseek_v32/fp8_lighting_indexer.py는 구 백엔드에서도 동일 머신에서 동일하게 실패하여 환경 및 허용 오차 문제입니다. 두 번째 커밋은 구 백엔드와의 동작 차이를 항목별로 정렬한 것으로, 핵심은 bf16 합법화(HIVM이 bf16 피연산자를 받지 않으므로 fp32로 계산한 뒤 명시적으로 변환)와 동적 extent의 copy 하강입니다.

TileOPs는 오늘 7건을 병합했으며, 두 가지 주요 라인 모두 성능 측입니다. 선택기는 더 이상 manifest에 밀착해 피팅하지 않고, 바쁜 시간(device_busy_ms) 기준으로 160개의 밀집 shape, 60개의 m 9–32 shape, 264개의 m≤8 shape로 재캘리브레이션하며, softmin 기대 로그 리그릿으로 좌표 하강을 수행합니다. 엔드투엔드 바쁜 시간 리그릿은 홀드아웃 manifest에서 5.79%에서 0.48%로, m≤8 홀드아웃 세트는 14.18%에서 1.79%로 낮아졌습니다. GEMM 측에는 coop2_swap이 추가되었는데, 비 NT 레이아웃을 전치된 영속 커널로 바꾸고, 두 소비자 warpgroup이 각각 128행을 보유하며, 꼬리 쓰기는 stmatrix.trans와 TMA 전치를 거쳐 되돌려 기록하고, 넓은/좁은 tile 혼합 배치(예: 2112 = 13×160 + 32를 160 너비 tile과 128 좁은 tile로 분할)를 지원하며, 2112×7168×4096 TN이 195.3마이크로초에서 175.3마이크로초로, 동일 머신의 다른 H200에서는 174.3에서 158.5마이크로초로 읽혀, 모두 QuACK의 187.9와 167.0마이크로초를 앞섰습니다.

리덕션 측은 같은 날 먼저 깨졌다가 수정되었습니다. 오전 #2787은 int32 키로 extrema 리덕션의 NaN 전파를 구현하고, #2788은 병렬 cumsum의 행 tile을 변경했으며, 두 커밋 모두 07시 전후에 반영되었고, 이후 #2790과 #2792가 각각 두 회귀를 정리했습니다. cumsum은 시드 기준 분할, 두 번의 발행으로 변경되었고((8,65536) float32가 12.75마이크로초에서 5.18마이크로초로, 동시에 메인라인의 65535 tile 초과 발행 실패도 수정), extrema는 PTX의 max.NaN / min.NaN으로 변경되고 16바이트 비정렬 벡터 행에서는 별도 커널을 사용합니다(amax (2048,4096) bf16이 8.352마이크로초에서 6.976마이크로초로 복귀, FlagGems보다 빠름). 이러한 “같은 날 도입 후 수정”의 리듬은 TileOPs의 야간 벤치마크가 회귀를 당일 차단하고 있음을 보여줍니다.

1. 핵심 프로젝트 진행

1.1 메인 저장소: 스칼라 읽기의 인덱스 계수가 더 이상 lane 수에 섞이지 않으며, 행 너비 32768 이상의 컴파일 크래시 종료(#3453)

10-28 11:06에 병합되었으며, 단일 파일 +8/-5입니다. 벡터화 방식으로 전체 행을 읽으면서 동시에 인덱스로 해당 행의 단일 요소를 읽는 kernel이, 행 너비를 65536으로 나눈 나머지가 32768 이상일 때 InternalError: Can’t fetch the lanes of a scalable vector를 컴파일 오류로 발생시킵니다. 근본 원인은 VectorTypeAccessChecker::OnArrayAccess에 있습니다. 이는 스칼라 읽기를 access_dtype.with_lanes(me->coeff)로 기록하는데, me->coeff는 인덱스를 읽는 모듈러스 계수이며 x[row, 0]의 경우 행 너비입니다. DataType의 lane 수는 16비트에 불과하고 int16으로 다시 읽히므로, 32768에서 65535는 확장 가능한 벡터로 간주되어 lanes()가 get_preferred_dtype에서 바로 오류를 던지고, 더 넓은 배수는 조용히 랩어라운드됩니다. 수정 방법은 계수를 별도의 int64_t에 저장하고, 호환성 판단에서 이를 사용해 모듈러스를 취하며, 스칼라 읽기의 dtype은 요소 타입만 유지하는 것입니다. 이 결함의 원래 트리거 시나리오는 TileOPs의 GroupNorm으로, Stable Diffusion의 40960과 163840 두 그룹 너비 모두에서 발생합니다. 검증은 두 번의 wheel 빌드 비교로 수행했습니다. 메인 브랜치는 32768과 40960 두 너비에서 컴파일 실패했고, 본 커밋은 모든 테스트 너비에서 빌드됩니다.

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

1.2 메인 저장소: 배치 all-reduce가 스칼라 분기에서 스레드 범위를 해석하도록 하여, batch>1일 때 2048개 출력이 전부 잘못되는 문제 수정 (#3341)

10-28 05:46에 병합되었으며, 2개 파일 +170/-8입니다. 스칼라 all-reduce 분기는 호출을 발행하기 전에 참여 스레드의 범위를 먼저 해석하지만(reducing_threads가 32보다 크고 대상이 명명된 펜스를 지원하면 ResolveAllReduceThreadRange를 사용), 배치 분기는 블록 경계를 오프셋과 펜스 너비로 직접 사용합니다. 감소 스레드가 [32, 96)처럼 0에서 시작하지 않는 부분 범위일 때, 배치 호출은 0번 스레드부터 인덱싱하고 전체 블록을 기준으로 펜스를 동일하게 적용하므로, 비참여 스레드의 초기화되지 않은 레지스터가 감소에 포함됩니다. batch=1은 정상이지만, batch=2에서는 동일한 kernel에서 2048개 출력 요소가 전부 잘못되며 최대 절대 오차는 1083이고 어떠한 진단도 없습니다. 수정 방법은 배치 분기가 스칼라 분기와 동일한 해석을 사용하도록 하고, 해석된 오프셋과 범위를 MakeBatchAllReduce에 전달하며, 작업 공간 stride는 여전히 블록 크기를 유지하는 것입니다. 새 테스트는 동일한 kernel에서 batch=1과 batch=2를 실행하고 torch 참조와 비교합니다.

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

1.3 메인 저장소: SIMT 원자 영역의 형상 검증 추가, 범위를 벗어난 영역은 컴파일 시점에 거부 (#3465)

10-28 08:14에 병합되었습니다. SIMT 원자 연산은 이전에 전달된 영역의 형상을 검증하지 않았으며, 형상이 맞지 않는 작성 방식은 codegen까지 진행되어 잘못된 결과를 보이거나 충돌했습니다. 본 커밋은 CUDA와 ROCm 두 경로 모두에서 영역 형상 검증을 보완하여, 잘못된 영역을 컴파일 시점에 조기에 거부합니다.

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

1.4 메인 저장소: 희소 MMA의 K 잔여 블록이 더 이상 조용히 통과되지 않음 (#3367)

10-28 16:01에 병합되었습니다. 희소 MMA는 K 방향에 처리되지 않은 잔여 블록이 있을 때 이전에는 오류를 내지 않고 전체 블록의 전송 및 계산 매개변수를 그대로 사용하여 수치가 조용히 편차를 보였습니다. 본 커밋은 이러한 K 잔여 블록을 명시적으로 거부하여 문제를 컴파일 시점으로 옮깁니다.

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

1.5 메인 저장소: atomic_addx4의 대상 dtype을 float*로 좁힘 (#3369)

10-28 16:08에 병합되었으며, 3개 파일 +27/-9입니다. CUDA의 atomic_addx4와 atomic_addx4_ret 범용 구현은 이전에 임의의 대상 포인터를 허용했으며, int32 또는 int64 대상은 float 의미론으로 처리되어 잘못 계산되었습니다. 본 커밋은 두 범용 오버로드를 float* 대상으로 제한하며, fp16과 bf16의 기존 특수화는 변경하지 않습니다. Python 측 API는 타입 중립을 유지하고, CPU 백엔드의 정수 대상은 영향을 받지 않습니다. CUDA 측에는 정수 대상 컴파일 실패 회귀 케이스를 추가하고, CPU C 백엔드에는 두 정수 너비의 누적 정확성 케이스를 추가했습니다.

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

1.6 메인 저장소: restrict가 아닌 매개변수의 handle 접미사가 더 이상 잘리지 않음 (#3366)

10-28 13:19에 병합되었습니다. 매개변수 중복 제거 시 _handle 접미사를 제거한 이름으로 비교하여, 동일한 커널에서 A와 A_handle 두 개의 서로 다른 매개변수가 동일한 것으로 간주되어 코드 생성이 한 번만 발행되었습니다. 수정 방법은 정확한 이름과 변수 신원으로 중복 제거하도록 변경하고, CUDA 측에 A와 A_handle이 공존하는 회귀 케이스를 추가했습니다.

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

1.7 메인 저장소: TMA 디스크립터가 검증된 이름만 기록 (#3484)

10-28 17:12에 병합되었습니다. TMA 디스크립터의 등록이 이전에는 검증 이전에 완료되어, 검증에 실패한 디스크립터 이름이 테이블에 남아 이후 동일한 이름의 정상 디스크립터가 중복으로 잘못 판정되었습니다. 본 커밋은 등록을 검증 이후로 옮깁니다.

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

1.8 메인 저장소: profiler 출력 인덱스 통합 검증, 스칼라와 리스트 형식에 동일한 경계 규칙 적용 (#3486)

10-28 19:24에 병합되었으며, 2개 파일 +15/-9, #2884 수정. profiler와 adapter 양측은 이전에 result_idx 처리 방식이 일치하지 않았습니다. 스칼라 형식은 경계 검사를 했지만 리스트 형식은 하지 않았고, 음수 인덱스도 정규화되지 않았습니다. 본 커밋은 BaseKernelAdapter와 Profiler가 하나의 규칙을 공유하도록 하여, None, 정수 또는 정수 리스트를 허용하고 -len(params)부터 len(params)-1까지로 판정하며, 정상적인 음수 인덱스는 정규화하고 범위를 벗어나거나 정수가 아닌 요소는 ValueError를 발생시킵니다. CPU 측 회귀 테스트 28건을 추가하여 스칼라와 리스트 두 경로를 모두 커버합니다.

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

1.9 메인 저장소: T.Parallel의 coalesced_width를 통합하여 IntImm으로 변환 (#3374)

10-28 16:27에 병합되었습니다. coalesced_width에 Python 정수를 전달할 때 일부 경로에서는 원시 정수 그대로 pass로 진입하여 이후 변환에서 타입 단언이 실패했습니다. 본 커밋은 언어 계층에서 통합적으로 IntImm으로 변환하여 작성 방식 차이로 인한 실패를 제거합니다.

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

1.10 메인 저장소: 테스트 인프라에서 cache 민감 케이스를 without_kernel_cache로 전환 (#3695 / #3696)

10-28 01:59와 09:19에 병합되었습니다. 어제 기록된 issue #3694(커널 캐시 적중이 콜드 컴파일을 가정한 테스트를 깨뜨림)를 이어받아, 두 커밋은 컴파일 산출물, 소스 코드 및 진단 정보를 검사하는 케이스를 without_kernel_cache() 또는 명시적 .compile(…)로 전환하여 단언이 프로세스 내 캐시의 이전 kernel이 아닌 이번 빌드의 결과를 보도록 합니다.

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

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

1.11 신규 결함 3건: SM120에서 13개 예제 실패, IfStmtBinding 지수적 컴파일, without_kernel_cache가 재컴파일을 강제하지 않음 (#3701 / #3700 / #3699)

세 개의 새로 열린 issue는 테스트와 컴파일 시간을 지적합니다. 첫째, #3701은 RTX PRO 6000 Blackwell(sm_120, 동적 공유 메모리 상한 99 KiB)에서 전체 examples 스위트를 실행한 결과, CUDA와 CuTeDSL 두 백엔드 모두 13 실패 199 통과 27 건너뛰기였으며 실패 집합은 문자 그대로 동일했습니다. 7건은 예제가 비 –tune 경로에서 Hopper 크기의 tile을 하드코딩한 경우(예: attention_sink는 163840 바이트, deepseek_mla 디코드는 231424 바이트 필요), 4건은 참조 구현인 flash-attn 2.5.8에 sm_12x 커널이 없는 경우, 나머지 두 건은 각각 ReduceOp 하강과 ThreadSync가 스레드 범위를 증명하지 못하는 경우입니다. 둘째, #3700은 루프 안에서 x = x + x를 반복 작성하고 i < N 가드를 추가할 때 tl.LayoutInference가 0.087초에서 118.5초로 증가하며, replayable bind 인라인을 끄면 0.100초로 되돌아간다고 보고합니다. 셋째, #3699는 without_kernel_cache()가 CacheState(디스크 캐시 읽기에서만 사용됨)만 뒤집고, @tilelang.jit 래퍼는 JITImpl.compile() 이전에 프로세스 내 _call_form_cache와 _kernel_cache도 조회하므로 해당 블록 내의 일반 호출이 재컴파일을 보장하지 않는다고 지적합니다.

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

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

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

2. 멀티 백엔드 적응 (Ascend / Hygon / ROCm)

2.1 Ascend: 910 A2/A3의 NPUIR 백엔드가 mlir-ascend 메인라인에 병합, 자체 테스트 504건 전부 통과, 72개 예제 중 1건만 환경적 실패 (#207)

10-28 08:04에 병합, 55개 파일 +21490/-1, 작성자 CeleNewYear, v0.1.15 기반 a35f8ddf, 두 커밋이 각각 백엔드 구현과 동작 정렬을 담당한다. 백엔드 측면은 tilelang/ascend910 아래의 backend, adapter, codegen, compiler, execution_backend, jit, pipeline, runtime, target과 language 아래의 kernel, copy, gemm, npuir 방언 면을 포함하며, C++ 측은 src/ascend910/target의 개발자·전문가 두 가지 런처, src/ascend910/op 연산자 계층과 src/ascend910/transform의 LowerNpuirBlock, NpuLoopVectorize, RewriteFDivToMul이다. 런타임은 npu_launcher.h, npu_utils.cpp, npu_utils.py를 통해 torch 호환 런치 래퍼를 생성하고 *_infer_workspace_shape_function에 따라 각 블록의 scratch를 추산한다. 빌드 측은 CMakeLists를 연결하고 install_npuir.sh에 –bishengir-path 옵션을 추가한다. target 별칭은 ascend910, ascend-910, a2, a3, npuir를 받아들이며, 모드 스위치 TILELANG_ASCEND_MODE는 expert 또는 developer를 받고 기본값은 expert이다. 검증 데이터: pytest testing/npuir 504 통과 0 실패; examples/run_all.py –sequential 72개 사례 중 71 통과 1 실패, 0 타임아웃 0 오류, 유일한 실패인 deepseek_v32/fp8_lighting_indexer.py는 구 백엔드에서도 동일 머신에서 똑같이 실패한다. 두 번째 커밋이 정렬한 차이는 bf16 합법화(HIVM이 bf16 피연산자를 거부하여 fp32 계산 후 명시적 변환으로 변경)와 동적 extent 영역의 카피 하강이다.

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

2.2 Ascend 메인 저장소: Bisheng 빌드 정체성을 바이너리 캐시 키에 포함 (#3691)

10-28 10:26에 병합. Ascend 측의 바이너리 캐시는 이전에 커널과 target으로만 키를 구성하여, Bisheng 툴체인 버전을 바꿔도 여전히 구 바이너리가 히트되었다. 이번 커밋은 빌드 정체성을 캐시 키에 포함시켜 툴체인이 변하면 즉시 무효화되어 재컴파일된다.

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

2.3 Ascend 메인 저장소: 수동 파이프라인이 구성 레지스터 위상을 보존 (#3624)

10-28 09:57에 병합. 수동 파이프라인이 재작성 단계에서 구성 레지스터의 위상 정보를 잃어, 동일한 구성이 올바른 사이클에 적용되지 않았다. 이번 커밋은 재작성 과정에서 위상을 보존하여 자동 파이프라인과 일치하는 타이밍 시맨틱을 복원한다.

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

2.4 Ascend 저장소 심사 중: W4A4 int4×int4 GEMM 결과 오류의 근본 원인과 수정 방법 (#1731)

심사 중, 7개 파일 +634/-24, #438 수정. 근본 원인은 전체 C++ 템플릿 스택이 sizeof(AscendC::int4b_t) == 1로 프랙탈 기하를 추론하는데, int4b_t가 니블 패킹 타입이라는 점이다: 32바이트 C0 블록의 올바른 원소 수는 32가 아니라 64이므로 모든 카피 stride, repeat 횟수, 바이트 카운트가 전부 2배 어긋난다. 세 계층이 겹쳐 있다. L1에서 L0A/L0B로의 LoadData 파라미터가 이 상수에서 도출되어 데이터가 잘못된 위치에 쌓인다. B 피연산자의 zN에서 nZ로의 전치가 s4 전용 명령 load_cbuf_to_cb_s4에 의해 조용히 꺼져 있어, LoadDataWithTranspose를 거쳐 load_cbuf_to_cb_transpose_s4로 바꿔야 하는데 그 파라미터 시맨틱은 CANN 헤더 파일에 문서화되어 있지 않아, 작성자는 프로브 커널로 디바이스에서 역공학할 수밖에 없었다(올바른 파라미터 repeatTimes = N/64, srcStride = roundUp16(K)/64, dstGap = 3, 그리고 s4 버전은 문서에 쓰인 512바이트 fractal이 아니라 2048바이트 블록 단위로 동작한다). UB에서 GM으로의 바이트 길이는 원소당 1바이트로 계산되어 각 행이 두 배로 옮겨지고 인접 행이 섞여 들어간다. mad_s4 명령 자체는 올바르며, 증상은 99.6% 불일치, 출력이 -501/627인데 정답은 641/1785이다.

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

2.5 Ascend 저장소 심사 중: a2a3 스케줄러 마이그레이션, 100개 파일 18453줄 (#1951)

심사 중, 100개 파일 +18453/-666, 작성자 erhsh. A2/A3의 스케줄러를 새 아키텍처로 마이그레이션하는 것으로, 모니터링 기간 내 가장 큰 심사 중 변경이다. PR 설명의 표가 작성되지 않았으므로 구체적 경계는 파일 목록으로 확인해야 한다.

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

2.6 Ascend 저장소 검토 중: Carver가 선택된 SDK에 따라 A3 리소스 예산을 읽음 (#1955)

검토 중, 3개 파일 +203/-27. Ascend910_9392에서 Carver가 Ascend910A로 폴백하여 256×256 FP32 누산기를 256 KiB L0C 예산에 배치하지만, 선택된 SDK는 128 KiB만 제공한다. 수정 방법은 9392와 9382 두 구체적 SKU를 식별하고 기존 ASCEND_HOME을 사용하여 각 플랫폼의 INI를 선택적으로 읽으며(크로스 컴파일용 명시적 파일 옵션 별도 제공), SDK 용량을 현재 백엔드 arena에 맞게 조정하면서 원본 용량, 구성 아이덴티티, BF16 지원, 코어 수 및 L2 속성을 유지하는 것이다. 6개의 타겟팅된 테스트 케이스가 디바이스, target 및 명시적 칩 프로빙, 초과 및 정상 L0 tile, 그리고 9382에서 BF16이 비활성화된 독립 구성을 커버한다. 저자가 제시한 회귀 결과는 네이티브 Ascend CI 메인 스위트 1352 통과 3 스킵, 예제 스위트 153 통과이다.

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

2.7 Ascend 저장소 검토 중: AI Core Exception Dump의 의존성이 CANN 9.2.0으로 하향 (#1956)

검토 중, 5개 파일 +49/-32. 이 기능은 이전에 CANN 9.3.0 의존성을 선언했으나, 저자가 9.2.0에서 검증 가능함을 확인하고 두 곳의 호환성을 수정했다. acldumpTensorInfo에 addrType=ACL_DUMP_ADDR_RAW, placement, shapeNum, originShapeNum 네 가지 필수 필드를 보완하고(9.2.0의 acldumpSaveExceptionInfo는 addrType을 강하게 검증하는데, 기존 구현은 calloc으로 0이 되어 ACL_DUMP_ADDR_PTR로 거부됨), NULL 주소 또는 크기가 0인 tensor를 건너뛴다. 또한 등록 인터페이스를 더 이상 사용되지 않는 aclrtSetExceptionInfoCallback에서 aclrtExceptionInfoCallbackRegister로 교체했다. 파싱 측은 msaicerr.py의 두 가지 산출물(9.2.0은 .npy, 구버전은 .bin)을 호환하며, 문서의 버전 요구사항도 CANN 9.2.0 이상으로 동기화되었다.

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

2.8 Ascend 저장소 검토 중: 문서가 T.Tensor로 전환, T.Buffer DSL 인터페이스 폐기 (#1957)

검토 중, 단일 파일 +124/-122. 프로그래밍 가이드 3.1절의 kernel 파라미터 정의를 업스트림 API와 정렬하여, 텍스트와 예제 모두 T.Tensor를 통일적으로 사용하고 T.Buffer(…) 및 T.Buffer[…]의 폐기가 TileLang DSL 인터페이스에만 해당하며 하위 TVM의 Buffer 타입과 개념은 폐기되지 않았음을 설명하는 문장을 추가했다. 근거는 ascendc_pto 브랜치의 tilelang/language/proxy.py에 있는 @deprecated 데코레이터이다.

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

2.9 Hygon: HCU 일반 복사 LDS swizzle 기능 브랜치, 18개 파일에 5개 신규 테스트 포함 (#30)

검토 중, 18개 파일 +2000/-84, 브랜치 Feat/hcu plain copy lds swizzle이 10-28 13:59에 푸시됨. 변경은 신규 gemm_lds_strategy_utils(+148/-0 및 +29/-0), annotate_mls_gemm_dep.cc(+332/-45), ds_read_format.cc(+61/-22)에 집중되며, copy와 merge_shared_memory_allocations에 소규모 동반 수정이 있다. 테스트 측에는 test_hcu_plain_copy_lds_swizzle(396줄), _formula(237), _formula_b8(220), fp8(200), _b8_write_phases(80)가 한 번에 추가되었다. 방향은 일반 복사 경로의 LDS 쓰기 단계와 swizzle 전략으로, b8/fp8 두 가지 데이터 폭을 지원한다.

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

2.10 ROCm: pip 버전 SDK의 ROCm 10 지원 병합, MI355X가 더 이상 gfx900으로 오판되지 않음 (#3549)

10-28 07:38에 병합되었으며, 2개 파일 +106/-19. ROCm 10.x의 rocm/pytorch 이미지는 ROCm을 Python wheel 형태(rocm-sdk 및 _rocm_sdk_devel)로 배포하며, /opt/rocm 디렉터리 트리도 rocm-* apt 패키지도 없다. get_rocm_arch()는 이전에 /opt/rocm 접두사를 하드코딩했고, 경로가 존재하지 않으면 gfx900으로 폴백했기 때문에 MI355X(gfx950)에서 rocwmma의 정적 단언이 바로 실패했다. ROCM_PATH를 설정해도 효과가 없었는데, TVM의 tvm_callback_rocm_get_arch가 기본 접두사로 해당 함수를 호출하기 때문이다. 수정 방식은 호출자 접두사, find_rocm_path(), torch의 gcnArchName, gfx900 폴백 순서로 해석하며, 매 rocminfo 탐지에 10초 타임아웃을 추가한다. 또한 docker/Dockerfile.rocm10을 새로 추가했는데, rocm/pytorch:rocm10.1.0_ubuntu24.04_py3.12 기반으로 rocm-*의 apt 설치를 제거하고, ROCM_PATH를 rocm-sdk path –root로 지정하며, 기본 이미지의 torch 빌드를 유지하고 import 자체 점검을 추가했다. 작성자는 MI355X에서 아키텍처 탐지가 gfx900에서 gfx950으로 변경됨을 실측했고, testing/python/amd 스위트가 올바른 아키텍처로 빌드되어 통과했다.

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

3. 생태계 및 도입 주체 (TileOPs / TileFoundry)

3.1 TileOPs: 선택기가 바쁜 시간 기준으로 보정하도록 변경, manifest 리그렛 5.79%에서 0.48%로 감소 (#2784)

10-28 10:51에 병합되었으며, 4개 파일 +259/-203. 덴스 선택기의 점수 계산이 하나의 tensor_core_tflops에 구조 인자를 곱하는 방식으로 변경되었다. 이전에는 구조 차이가 하나의 max()에만 반영되어 메모리 제약 shape가 basic, simple, coop2를 동점으로 만들었다. launch_us 항목은 삭제되었다(바쁜 시간에서 0으로 피팅됨). m≤8의 NT 밴드는 수동 측정 임계값을 스트리밍 모델로 대체했다. CTA당 레이트는 min(ns·rows·bk·2/latency, cta_gbps)를 취하고, 웨이브는 SMEM 제약 상주량으로 계산하며, DRAM 하한 n·k·2/dram_tbps와 split-K의 리덕션 항을 추가했다. TN/TT의 영속 커널 경로가 열렸으며(A/B의 SMEM tile이 저장 레이아웃을 따르고, transpose_A/B), 176/192 너비, 좁은 tile, ping-pong과 split-K는 여전히 NT로 제한된다. 보정은 바쁜 시간에서 수행하며, 세 그룹 그리드 160/60/264개 shape, 7라운드 인터리브 CUPTI 중앙값, softmin 기대 로그 리그렛을 좌표 하강법으로, tau 0.1→0.05→0.02 어닐링으로 진행했다. 엔드투엔드 결과: 홀드아웃 manifest 5.79%에서 0.48%, 보정 그리드 9.28%에서 2.65%, m 9–32 3.13%에서 2.09%, m≤8 11.20%에서 1.17%, m≤8 홀드아웃 세트 14.18%에서 1.79%.

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

3.2 TileOPs: 비-NT 레이아웃이 전치 영속 커널로 전환, 2112×7168×4096 TN 195.3에서 175.3마이크로초로 감소 (#2789)

10-28 21:06에 병합되었으며, 4개 파일 +620/-15, #2785 해결. coop2_swap을 새로 추가했다. TN/TT/NN에 대해 Cᵀ = op(B)ᵀ·op(A)ᵀ를 계산하고, 256×block_n tile로 영속 커널을 사용하며, 두 소비자 warpgroup이 각각 128행을 보유하고, 테일 쓰기는 stmatrix.trans와 TMA 전치로 되쓴다. 혼합 tile 너비(narrow_n과 row_mix)로 M이 패딩으로 낭비되지 않게 한다. 예를 들어 2112 = 13×160 + 32를 너비 160 더하기 좁은 128로 분할하며, 넓은 것이 먼저 실행되고 좁은 것이 마무리하며, 분할 지점은 coop2 좁은 tile의 _busiest_cta 지표를 따른다. 선택기는 NT 외에 coop2_swap의 block_n 128과 160, 구조 인자 1.2를 열거하고 바쁜 시간 기준으로 재피팅한다. H200 바쁜 시간: 2112×7168×4096 TN 195.3에서 175.3마이크로초로 감소(QuACK 187.9), 24576×1536×4096 TN 421.9에서 416.4마이크로초로 감소. 다른 H200에서는 각각 174.3에서 158.5로 감소(QuACK 167.0) 및 384–402마이크로초 구간. 행 그룹 규칙이 고정 4를 16으로 변경했으며, 24개 TN/TT/NN 보정 shape에서 group 4와 0.989–1.022배 차이를 보였다. 또한 9개 TN shape에서 혼합이 균일 coop2_swap보다 3.6%에서 11% 빨랐다.

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

3.3 TileOPs: cumsum 긴 행을 2단계 시드 스캔으로 변경, (8,65536) 12.75에서 5.18마이크로초로 감소 (#2790)

10-28 20:45 병합, 4개 파일 +255/-246. 소수의 긴 행 cumsum을 시드 세그먼트 스캔으로 전환하여 발행 횟수를 세 번에서 두 번으로 줄였으며, #2788에서 도입된 회귀를 제거하고 해당 레이아웃 실패도 수정했습니다. 규칙은 행 길이가 64 KiB 이상이고 행 수가 적을 때 세그먼트 스캔을 사용하며, cumprod는 변경 없음; 또한 메인 브랜치에서 행 수가 65535개 타일을 초과할 때(예: (1, 2**24) float32)의 발행 실패도 수정했습니다. H200 @1500 MHz 부하 시: (8,65536) float32 12.75에서 5.18마이크로초, (16,65536) 19.14에서 7.01마이크로초, (1,65536) bf16 9.03에서 3.45마이크로초, (3,8193) fp16 7.52에서 3.29마이크로초. 384개 shape 스캔에서 #2788 이전보다 느린 항목은 없었으며, CumsumFwdOp와 CumprodFwdOp의 manifest 행 모두 가장 빠른 대조 구현보다 빨랐습니다; 새로 추가된 few-long-seq 부하(8×65536 float32) 5.20마이크로초 대 FlagGems 6.30마이크로초.

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

3.4 TileOPs: extrema 리덕션을 PTX의 max.NaN으로 변경, NaN 전파 불변하면서 회귀 사라짐 (#2792)

10-28 23:31 병합, 4개 파일 +346/-119. amax/amin을 fp32에서 PTX의 max.NaN과 min.NaN으로 변경하고, #2787의 int32 키 방식을 더 이상 사용하지 않으며, NaN 전파 시맨틱은 불변하면서 당일 이른 시각의 회귀가 해소되었습니다; 전체 16바이트 벡터가 아닌 행은 별도의 extrema 행 커널로 처리하는데, T.reduce_max가 fp32에서 NaN을 잃기 때문입니다. H200 @1500 MHz: amax (2048,4096) bf16은 #2787 이전 7.008마이크로초, 메인 브랜치 8.352, 이번 커밋 6.976; fp16 7.008에서 7.775에서 6.944; amax (64,32768) bf16 3.552에서 4.544에서 3.520; amin 동일 형태 3.552에서 4.224에서 3.520.

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

3.5 TileOPs: 병렬 cumsum의 유효 행 타일, GDN 좁은 프리필 분할 두 건 (#2788 / #2786)

#2788은 10-28 07:13 병합되어 병렬 cumsum이 유효한 행 타일만 처리하도록 했으며, 전체 모니터링 기간 중 가장 이른 커밋이었고 이후 #2790에서 2단계 스캔으로 문제 경로가 교체되었습니다. #2786은 07:09 병합, 2개 파일 +30/-2, SM89에서 32열 GDN 프리필 계획을 기존의 융합 출력을 갖는 상태 스캔으로 전환하여 전체 블록 세그먼트와 테일 블록을 분리 처리하고, 준비 단계·출력·최종 상태 세 가지 인터페이스를 유지합니다; 선택 조건은 밀집 입력, batch 1, 16개 value head, 상태 폭 128, key major, 시퀀스 길이 16384 초과 65536 이하입니다. H=4일 때 중위 디바이스 실행 시간은 TileOPs 베이스라인 대비 13.65%에서 18.31% 감소, 디바이스 활동 범위는 13.48%에서 17.07% 감소; FLA와 교차 비교한 네 라운드에서 H=16, 길이 65536, BF16의 범위 차이는 -2.57%에서 +1.77% 사이로, 작성자는 해당 행이 측정 변동 범위 내에 있다고 밝혔습니다.

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

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

3.6 TileOPs 신규 이슈: 연속 호출 시 대형 GEMM 행이 최고 속도 베이스라인에 뒤처짐 (#2791)

신규 오픈, #2133과 #2789를 이어받음. bench_gemm은 단일 호출을 읽고 중간에 L2 플러시와 동기화가 있으며, 호출이 전력 상한 이하에서 시작하여 에너지 비용이 가려짐; 학습에서의 연속 백투백 호출로 변경한 후, 10개 manifest 대형 행 중 6개가 최고 속도 베이스라인에 뒤처졌습니다. 대표적인 행: prefill-o-proj 4096×7168×16384 NT 본 구현 1412.7마이크로초, QuACK 1371.1, cuBLAS 1360.1, DeepGEMM 1359.2, 비율 0.962. 방법은 단일 카드 H200, 클럭 언락, 1초 워밍업 후 1.5초 타이밍, 4라운드 교차 중위값.

출처: https://github.com/tile-ai/TileOPs/issues/2791

3.7 TileFoundry: ring 단계 바인딩 및 컴파일 흐름 통합, 70개 파일 (#277)

10-28 16:55 기준, 70개 파일 +1567/-1298, #276을 대체한다. 동기는 두 가지다. 바인딩되지 않은 ring 뷰와 단계 선택이 SSA 이름이 없는 뷰를 CUDA 피연산자까지 끌고 가는 문제, 그리고 세 개의 컴파일 진입점이 각자 서로 다른 pass 목록을 조립하는 문제다. 수정 방식은 ring 단계를 이미 바인딩된 TensorView 집합으로 저장하고, 각 소비 스코프에서 한 번만 바인딩하며, default_pipeline을 finalize, compile, scaffold 세 곳에서 공유하도록 만드는 것이다. 핵심 호스트 진입점 pass는 Target.resolve로 해석되고 CUDA가 @bind 구현을 제공한다. Module.entry가 호스트 시작점이 되고, 분석된 공유 메모리 피크가 호스트 시작으로 전달된다. 호출 체인의 모든 CPU 호스트가 링크에 참여하며, 루트 호스트가 맨 앞에 온다. 계약 변경: link_program에서 entries를 제거하고, 로더는 첫 번째로 링크된 호스트를 바인딩하며, build는 CPU 호스트 루트가 존재할 것을 요구한다. 남은 위험은 PR에 기록되어 있다. #278은 Broadcast 레이아웃 정규화를 추적하고, #255는 SymbolRef와 함수 참조를 추적한다.

출처: https://github.com/tile-ai/TileFoundry/pull/277

3.8 TileOPs 검토 중: 릴리스 이미지가 TileOPs 0.1.0과 TileFoundry 0.0.3을 함께 묶음 (#2793)

검토 중, 9개 파일 +120/-44. .github/runner/Dockerfile에 release 타깃을 추가하여 개발 이미지 위에 tileops와 tilefoundry의 PyPI 릴리스 버전을 설치하고, 이미지 이름은 TILEOPS_VERSION과 TILEFOUNDRY_VERSION으로 명명하며, ghcr.io/tile-ai/tileops-release:tileops0.1.0-tilefoundry0.0.3-cuda13.2-torch2.13-tilelang0.1.12로 푸시한다. 함께 제공되는 scripts/verify_release_image.sh는 이미지를 당긴 뒤 GPU에서 스택 및 베이스라인 검사, 패키징 테스트와 지정된 –bench 파일을 실행하며, 테스트 케이스는 이미지 내 tileops 버전에 대응하는 git tag에서 가져온다(wheel에는 테스트와 벤치마크가 포함되지 않음). 동시에 sgl-kernel 베이스라인을 제거한다. 더 이상 어떤 이미지도 이를 설치하지 않으며, bench_moe_permute_align은 계속 이를 건너뛴다.

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

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

4.1 문서 사이트 자동 업데이트 2건 (10-28)

tilelang.github.io는 10-28 08:20과 13:31에 각각 github-actions가 제출한 Update docs가 있으며, 내용은 문서 빌드 산출물이 메인 브랜치와 동기화된 것으로 독립적인 내용 변경은 없다.

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

4.2 Ascend 저장소 문서 사실 검증 및 설치 수정 일괄 검토 중, 7건 동시 진행 (10-28)

tilelang-ascend의 문서 사실 검증 파이프라인이 모니터링 기간 내 7건을 업데이트했다. T.tile.bitwise_lshift, bitwise_or, bitwise_and, fill, clear 다섯 API의 검증, clamp가 PTO에서 적용됨을 확인한 문서 검증(#1620), 그리고 axpy의 docstring 및 테스트 강화(#1600). 또한 #1943은 SHMEM 설치를 빌드 실패 시 중단하도록 변경했으며, #1942의 스냅샷 분석기 검증과 함께 로봇이 제출한 것이다.

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

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

4.3 Ascend 저장소 신규 연산자 예제 검토 중: GroupNorm과 fla_chunk 두 연산자 (#1607 / #1953 / #1952)

세 개의 예제类 PR이 모니터링 기간 내 업데이트되었다. #1607은 GroupNorm에 20개의 cann-bench 케이스를 추가하고, #1953은 fla_chunk_o 연산자와 테스트를 추가하며, #1952는 fla_chunk_intra_token_parallel 연산자와 테스트를 추가한다. 이는 1.1의 스칼라 읽기 크래시 결함의 원래 시나리오이기도 하다(GroupNorm이 각 행의 첫 번째 요소를 읽음).

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

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

4.4 서드파티: 커뮤니티 자동 튜닝 에이전트가 중국어 설명 갱신 (#74), Hexagon 백엔드 저장소 메인 브랜치 모니터링 기간 내 신규 커밋 없음 (10-28)

커뮤니티 저장소 cc-c122/TileLang-Remote-Autotuning-Agent가 10-28 09:21에 #74를 병합했으며, 현재 V2 워크플로에 따라 중국어 README를 갱신했다. 해당 저장소는此前 10-24에도 베이스라인 취소 상태와 mcprofiler 귀인 관련 병합이 한 차례 있었다. 또 다른 서드파티 백엔드 저장소 xwhzz/tilelang-hexagon의 조직 뷰에는 10-29 06:56 푸시 타임스탬프가 표시되지만, 메인 브랜치 최신 커밋은 08-24(CI 의존성 업그레이드)에 멈춰 있어 모니터링 기간 내 메인 브랜치에는 코드 커밋이 없으며, 어제의 15건은 피처 브랜치 활동에 속하므로 본 항목은 신규 내용으로 집계하지 않는다.

출처: https://github.com/cc-c122/TileLang-Remote-Autotuning-Agent/pull/74

출처: https://github.com/xwhzz/tilelang-hexagon

4.5 뉴스 측: Google News 6개 중영문 쿼리, Hacker News 및 arXiv 모두 모니터링 기간 내 실질적 적중 없음 (10-28)

6개 쿼리는 TileLang 정확어 + 2일, 중국어 연산자어 + 7일, 영문 GPU kernel DSL + 3일, 조직명 + 7일, 중국어 벤더어(Ascend / MetaX / Hygon) + 7일, 연산자 라이브러리어 + 2일을 포함한다. 반환 결과 중 TileLang 관련이면서 모니터링 기간에 해당하는 것은 전재 기사 한 편뿐이었다(Ascend 950PR 매트릭스 연산력 비교, 중고 시장 논평에 속하며 원본 데이터가 없어 수록하지 않음). 나머지는 DeepSeek 투자 및 기술 관련 일반 보도로, 제목 의미상 TileLang 관련 내용을 포함하지 않는다. 영문 쿼리는 전부 빈 반환. Hacker News 당일 항목은 Vu라는 새 언어 출시로 TileLang과 무관하다. arXiv에는 모니터링 기간 내 신규 tilelang 또는 tiled DSL 논문이 없다. 뉴스 측은 본일 GitHub 측과의 신호 강도 격차가 계속 확대되고 있으며, 데일리 리포트 본문은 여전히 저장소를 기준으로 한다.

출처: https://news.google.com/

5. 추세 관찰

Ascend 측의 추진 방식은 이틀간 이미 분명해졌다: 메인 저장소는 시간 단위로 소규모 수정(캐시 키, 레지스터 위상)을 병합하고, 전용 저장소 mlir-ascend는 2만 행 규모의 병합 한 번으로 910의 NPUIR 경로를 피처 브랜치에서 메인라인으로 옮겼으며, tilelang-ascend는 PTO와 AscendC 듀얼 백엔드의 기존 리듬에 따라 문서와 연산자를 보완하고 있다. 세 곳의 리듬은 다르지만 같은一件事를 가리킨다: 910의 컴파일러 경로가 “돌아간다”에서 “검수 가능”으로 전환되고 있으며, 504항목 자체 테스트와 71/72 예제가 이번에 제시된 검수 기준이다. 주목할 점은 심사 대기열에서 a2a3의 스케줄러 마이그레이션이 100개 파일을 차지한다는 것으로, 다음 단계의 변동량이 연산자 계층이 아니라 스케줄링 계층에 있음을 보여준다.

성능 측의 관전 포인트는 측정 기준 자체에 있다. TileOPs의 이번 두 건은 선택기와 GEMM의 결론을 모두 바쁜 시간(device_busy_ms) 기준으로 옮겼고, 같은 PR에서 단일 호출과 연속 호출의 차이를 제시했다: 단일 호출 기준에서는 본 구현이 QuACK를 앞서지만, 연속 호출·전력 상한 훈련 시나리오에서는 10개 대형 행 중 6개가 뒤처진다. 이는 “어떤 행이 몇 마이크로초 빨라졌는가”보다 더 중요한 신호인데, 훈련은 실제로 연속 호출이기 때문이다. #2791이 이 사안을 별도 항목으로立项한 것은 팀이 기준 문제를 벤치마크 편차로 포장하지 않고 제품 문제로 다루고 있음을 보여준다.

엔지니어링 위생 측면에서 오늘 기록할 만한 세 가지: 첫째, 같은 배치 내 자해와 자수정(#2787/#2788 오전 병합, #2790/#2792 오후 회수)은 야간 벤치마크의 안전망이 작동하고 있음을 보여주지만, 리덕션 코드의 의미 경계가 여전히 취약함도 보여준다. 둘째, without_kernel_cache()의 의미론적 허점(#3699)이 마이그레이션 과정에서 발견되었는데, 프로세스 내 2계층 캐시가 CacheState를 사용하지 않아 테스트가 콜드 컴파일이라고 착각하면서 실제로는 구 kernel을 가져오는 문제로, 이런 결함은 “우리 테스트는 모두 통과”를 무의미하게 만든다. 셋째, SM120에서 13개 예제 실패(#3701)는 예제가 Hopper 크기를 하드코딩한 문제를 드러냈으며, Blackwell 설치량이 늘어나면 이러한 “예제는 제품이 아니다” 부채가 반복적으로 계상될 것이다.

부록, 자료 및 검증 설명

출처 검증표

출처 검증 결과
GitHub tile-ai 조직 저장소별 (tilelang / TileOPs / TileFoundry / tilelang-ascend / tilelang-mlir-ascend / tilelang-hygon / tilelang-metax / tilelang-musa / TileRT / tilescale / DeepStack / 문서 사이트) 모니터링 기간 내 푸시 발생: tilelang, TileOPs, TileFoundry, tilelang-mlir-ascend, tilelang-hygon, tilelang.github.io; tilelang-metax, tilelang-musa, TileRT, tilescale, DeepStack, tilelang-puzzles는 모니터링 기간 내 메인 브랜치 커밋 없음
병합 실측 검색 (is:pr is:merged) 24건: tilelang 15, TileOPs 7, TileFoundry 1, tilelang-mlir-ascend 1
심사 중 실측 검색 (is:pr is:open updated) 48건, Ascend 저장소 문서 검증 배치 및 a2a3 마이그레이션 포함
신규 이슈 확인 6건, 그중 1건은 Ascend 저장소 일일 테스트 봇
메인 브랜치 커밋 단위 검증 tilelang 15건, TileOPs 7건, TileFoundry 1건, 문서 사이트 2건; 병합 수와 메인 브랜치 커밋 수 일치
릴리스 페이지 및 tag tilelang 최신은 여전히 v0.1.15 (09-30 릴리스), 모니터링 기간 내 신규 버전 없음; TileOPs 최신은 v0.1.0
서드파티 백엔드 저장소 Hexagon 백엔드 메인 브랜치 최신 커밋은 08-24에 멈춰 있으며 모니터링 기간 내 신규 커밋 없음; 자동 튜닝 에이전트 병합 중국어 설명 갱신; MetaX 저장소 6개 브랜치 모니터링 기간 내 커밋 없음
Google News (중영문 6개 그룹) 2차 전재 기사 1건만 관련, 원본 데이터 없어 미수록
Hacker News 당일 TileLang 관련 항목 없음
arXiv 모니터링 기간 내 신규 tilelang 또는 tiled DSL 논문 없음

전체 출처 목록