TVM 0.25의 TIRx가 Triton이 감춘 것을 드러낸다

Apache TVM이 막 공개한 커널 DSL은 대부분의 컴파일러가 자랑하는 방향과 정반대로 움직인다. 하드웨어 세부 사항을 자동화로 감추는 대신, TIRx는 의도적으로 그 통제권을 프로그래머에게 돌려준다.

TIRx는 무엇이고, 왜 TVM 0.25.0에 들어갔나?

TIRx는 Apache TVM의 차세대 커널 수준 컴파일러 구조다. 프로젝트 공식 문서에서는 기존 TVM 인프라 위에 구축된 "an open-source, hardware-native DSL and compiler for machine-learning kernels"라고 정의한다 . 이 기능은 PR #19581, "[TIRx] Bringup TIRx Infrastructure"를 통해 트리에 들어갔고, TVM 창시자 Tianqi Chen이 2026년 5월 18일 apache/tvm:main에 병합했다 . 이후 2026년 6월 19일자로 나온 v0.25.0 릴리스에 패키징됐다 .

짧게 답하면: TIRx는 Apache TVM의 하드웨어 네이티브 커널 DSL이자 컴파일러다. 2026년 5월 18일 PR #19581로 병합됐고, 2026년 6월 19일 v0.25.0에 포함됐다 . TensorIR의 자동 스케줄링과 달리, 루프와 동기화, 버퍼 레이아웃은 작성자가 쓴 코드 안에 그대로 둔다.

핵심은 아키텍처의 방향 전환이다. TensorIR이 성능 좋은 코드를 끌어내기 위해 자동 스케줄링 패스에 기대는 쪽이었다면, TIRx는 루프 구조, 동기화, 버퍼 레이아웃, 파이프라인 상태를 작성자의 소스에 남겨 둔다. 컴파일러는 반복되는 타일 수준 구조만 추론한다. 공식 개요는 이를 오케스트레이션은 "in hardware-native source code, while the recurring tile-level structure becomes visible to the compiler"라고 설명한다 . CUDA 네이티브 문서는 이 절충을 더 직설적으로 말한다. "no automatic scheduling", 즉 작성한 그대로 방출된다.

초기 타깃은 NVIDIA Blackwell급 GPU다. PR은 "low-level programming of Blackwell-class GPU architectures" 지원을 설명하며 WGMMA, tcgen05, TMA 같은 intrinsic을 노출한다고 밝힌다 . Bringup CI에서는 tests/python/tirx 기준 1,723개 통과 / 47개 건너뜀이 보고됐다 . 아직 초기 단계이더라도 표면 기능은 동작하고 있다는 신호다.

설치는 한 줄이면 된다. pip install apache-tvm==0.25.0. Python >=3.10이 필요하며 Windows x86-64, manylinux x86-64, manylinux ARM64, macOS 11.0+ ARM64용 빌드 휠이 제공된다 . 패키지는 Apache-2.0 라이선스이므로 따져야 할 가격 등급은 없다. 남는 질문은 이 명시적 제어 모델이 팀의 커널 작성 방식에 맞는지다.

TIRx와 Triton이 의도적으로 갈라지는 지점

TIRx와 Triton은 빠른 GPU 커널 작성이라는 같은 문제를 풀지만, 프로그래머와 컴파일러의 경계를 정반대 위치에 둔다. Triton은 높은 경계를 둔다. 블록 수준 추상화가 워프 조정, 공유 메모리 관리, 프리페치 스케줄링을 작성자에게서 숨기고, 컴파일러가 이를 오케스트레이션하게 한다. TIRx는 낮고 명시적인 경계를 둔다. 워프 ID, 동기화 호출, 버퍼 레이아웃, 파이프라인 단계가 모두 작성자가 쓴 하드웨어 네이티브 소스에 남는다. 공식 개요는 이 구분을 분명히 말한다. "orchestration stays in hardware-native source code, while the recurring tile-level structure becomes visible to the compiler" .

그 선택은 네이티브 계층에서 곧바로 결과를 낳는다. 오토스케줄러가 없다. 작성한 것이 그대로 방출된다. 루프 재정렬도, 컴파일러가 삽입하는 프리페치 힌트도, 암묵적 스레드 predication도 없다. CUDA 네이티브 기본 문서는 "no automatic scheduling"이 적용된다고 분명히 말하며, 아직 primitive가 없는 하드웨어 기능을 다뤄야 할 때 네이티브 계층으로 간다고 설명한다 . Triton이 블록 프로그램에서 스케줄을 추론하는 방식에 익숙한 엔지니어에게 이것은 의도적인 교환이다. 자동화의 편의성을 잃는 대신, 어떤 오토스케줄러보다 빠르게 변하는 하드웨어 위에서 예측 가능성을 얻는다.

이 설계는 명시적으로 프런티어 커널을 겨냥한다. 새 명령어, 메모리 공간, 협력 패턴, 알고리즘이 컴파일러가 안정적으로 자동화할 수 있는 속도보다 먼저 등장하는 경우다 . 안정적인 컴파일러가 아직 스케줄링 방법을 배우지 못한 명령어를 Blackwell급 GPU가 제공한다면, 명시적 경계는 백엔드 지원이 성숙하기를 기다리지 않고 오늘 바로 실리콘에 닿게 해준다.

두 번째 차이는 도구화다. TIRx는 재사용 가능한 연산을 검사 가능한 TilePrimitiveCall IR 노드로 기록하고, 이후 디스패치로 해석한다. 또한 Python, C++, Rust 전반의 TVM FFI를 통해 그 IR과 컴파일러 유틸리티를 노출한다 . 따라서 컴파일러 표면은 단일 Python 프런트엔드 뒤에 닫혀 있지 않고, 정적 분석기, 검증기, 프로그램 방식 작성기에도 열려 있다. TVM 창시자 Tianqi Chen이 강조하는 지점도 여기에 있다.

"에이전트는 최대한의 표현력을 제공하는 예측 가능한 DSL에 접근할 수 있어야 하며, 직접 열어 보고, 도구를 만들고, 개선할 수 있는 최소한의 컴파일러와 짝을 이뤄야 한다." — Apache TVM 창시자 Tianqi Chen (source: @tqchenml).

이 선택이 성공할지는 아직 입증되지 않았다. Triton의 더 높은 경계는 바로 그 점 때문에 대부분의 커널에서 생산적이며, TIRx는 NVIDIA의 CUDA Tile IR 백엔드를 포함해 2025-2026년에 Blackwell용 Triton 작업이 활발히 진행되는 경쟁적인 공간에 들어왔다 . 실질적인 질문은 어느 경계가 옳으냐가 아니라, 어느 쪽이 팀의 커널 작성 방식과 맞느냐다.

스코프 ID, 텐서 레이아웃, 타일 디스패치: TIRx IR의 구성 방식

TIRx는 실행 스코프, 텐서 레이아웃, 타일 프리미티브 디스패치라는 세 가지 문서화된 구성 요소를 중심으로 IR을 구성합니다. 이 셋이 함께 작동하면서 작성자는 하드웨어에 가까운 오케스트레이션을 직접 작성할 수 있고, 컴파일러는 재사용 가능한 타일 구조를 계속 추론할 수 있습니다 . 이 분리는 의도적입니다. 오케스트레이션은 작성자가 제어하는 소스 코드에 남고, 반복되는 타일 수준 구조만 컴파일러에 드러납니다. 이것이 앞에서 다룬 더 낮은 경계가 만들어지는 방식입니다.

실행 스코프는 암묵적인 스레드 프레디케이션이 아니라 일반적인 제어 흐름으로 어떤 하드웨어 참여자가 활성화되는지를 고릅니다. if wg_id == 0 또는 warp_id == ... 같은 스코프 ID intrinsic으로 작업을 제한하며, 이는 CUDA 워크그룹과 워프 역할에 직접 매핑됩니다 . 어떤 것도 스레드 전체에 자동 브로드캐스트되지 않습니다. 분기에서 이름을 지정한 참여자만 실행하며, 이후 정리 단계에서 이 스코프 ID들이 구체적인 스레드 축으로 낮아집니다 .

텐서 레이아웃은 저장소를 먼저 드러내는 인터페이스입니다. 논리 텐서가 전역 메모리, 공유 메모리, 레지스터, 가속기 SRAM 같은 물리 리소스에 어떻게 매핑되는지를 설명하며, 배치를 스케줄러에 맡기지 않습니다 . T.match_buffer로 버퍼를 선언하고 명시적 할당으로 스크래치 공간을 요청합니다. LowerTIRxCleanup 과정에서 TileLayout 버퍼 접근은 물리 주소 산술로 해소됩니다 . 작성한 레이아웃이 그대로 실행되는 레이아웃입니다.

타일 프리미티브 디스패치는 재사용 가능한 중간 지점입니다. copy나 gemm 같은 연산은 먼저 해소되지 않은 TilePrimitiveCall IR 노드로 기록되며, 이 노드는 프리미티브 타입, 실행 스코프, 피연산자 레이아웃, 대상 백엔드, 선택적 힌트를 함께 담습니다 . 그런 다음 LowerTIRx 패스가 TilePrimitiveDispatch를 실행해 각 노드를 해당 속성에서 선택된 구체적인 백엔드 디스패치 본문으로 바꿉니다 . 여기서 작성된 하나의 호출이 해소된 백엔드에 따라 TMA copy, 벡터화된 load, WGMMA, tcgen05가 될 수 있습니다.

작성 표면에서는 from tvm.script import tirx as T로 dialect를 가져오고, @T.prim_func 또는 @T.jit로 커널에 주석을 달며, T.device_entry()로 디바이스 경계를 표시한 뒤 일반적인 루프, 분기, 버퍼를 작성합니다. 컴파일은 tvm.compile(mod, target, tir_pipeline="tirx")를 거치며, 이 과정에서 타깃이 바인딩되고 TIRx 파이프라인으로 디스패치됩니다 . 세 구성 요소는 이 흐름에 깔끔하게 대응합니다. 스코프와 레이아웃은 작성자가 표현하는 것이고, 디스패치는 컴파일러가 내려가는 과정에서 해소하는 것입니다.

TIRx의 18단계 로어링은 이렇게 진행됩니다

tvm.compile(mod, target, tir_pipeline="tirx")가 호출되면, 프로그램은 명시적이고 하드웨어 네이티브인 소스를 CUDA 디바이스 코드로 바꾸는 18개의 모듈 수준 패스를 순서대로 통과합니다. 이 파이프라인은 결정적이며 처음부터 끝까지 문서화되어 있는데, 이는 TIRx가 전제로 삼는 에이전트 가시 워크플로에 중요합니다. 모든 변환이 숨은 휴리스틱이 아니라, 직접 살펴볼 수 있는 이름 있는 패스이기 때문입니다 . 전체 순서는 LowerTIRx, UnifyThreadBinding, StmtSimplify, LowerTIRxOpaque, FlattenBuffer, BF16ComputeLegalize, NarrowDataType(32), VectorizeLoop, UnrollLoop, 두 번째 StmtSimplify, CommonSubexprElim, FP8ComputeLegalize, VerifyMemory, AnnotateEntryFunc, SplitHostDevice, MakePackedAPI, FP8StorageLegalize, BF16StorageLegalize입니다 .

이 체인은 TIRx 전용 작업을 앞쪽에 배치합니다. LowerTIRx에서는 추상 타일 계층이 구체적인 코드로 접힙니다. 그 안의 TilePrimitiveDispatch 단계는 아직 해소되지 않은 TilePrimitiveCall IR 노드를 선택된 백엔드 디스패치 본문으로 바꾸고, LowerTIRxCleanup은 TileLayout 버퍼 접근을 물리 주소 산술로 해소하는 동시에 scope id를 thread axis로 낮춥니다 . 그 뒤의 패스는 대체로 표준 TIR 장치입니다. 버퍼 평탄화, 벡터화, 루프 언롤링, 공통 부분식 제거가 이제 백엔드별 코드가 된 대상 위에서 실행됩니다.

두 가지는 특히 자세히 볼 만합니다. 첫째, BF16과 FP8 합법화가 체인의 앞뒤를 감쌉니다. 계산 합법화(BF16ComputeLegalize, FP8ComputeLegalize)는 산술 중심 패스보다 앞서 이른 시점에 실행되고, 저장소 합법화(FP8StorageLegalize, BF16StorageLegalize)는 host/device 분리 뒤 마지막에 실행됩니다. 이 순서는 저정밀 타입이 CUDA PTX 코드 생성기가 받아들일 수 있는 형태로 도달하도록 보장합니다. 산술은 IR이 아직 값을 기준으로 추론할 때 합법화되고, 저장소 표현은 디바이스 함수가 확정된 뒤에야 고정됩니다 . 둘째, 파이프라인의 끝부분은 런타임 경계를 처리합니다. VerifyMemory는 코드 생성 전에 잘못된 메모리 접근 패턴을 잡아내고, SplitHostDevice는 호스트 함수와 디바이스 함수를 분리하며, MakePackedAPI는 디바이스 함수를 TVM의 런타임 호출 규약으로 감쌉니다 .

커널 엔지니어에게 실질적으로 중요한 점은 이렇습니다. 프로그래머와 컴파일러의 경계가 낮은 곳에 있기 때문에, 작성한 코드는 이 패스들을 거치면서 대부분 그대로 살아남습니다. 자동화가 개입하는 지점, 즉 디스패치, 합법화, 메모리 검증도 명시적이고 순서가 정해져 있으며 직접 확인할 수 있습니다 .

29개 타일 프리미티브와 백엔드별 낮추기 방식

TIRx는 29개의 타일 프리미티브를 제공하며, 각각은 src/tirx/op/tirx.cc에서 tirx.tile.<name> 형태로 등록되고, 그 위에 Python 래퍼와 TVMScript 빌더가 얹혀 있습니다 . 이들은 완전히 손으로 작성한 네이티브 코드와 더 높은 수준의 스케줄링 DSL 사이에서 재사용 가능한 중간 지점을 맡습니다. 작성자는 copy, copy_async, gemm, gemm_async, 리덕션, 캐스트, 원소별 수학 연산, 또는 퓨즈된 형태를 호출하고, 컴파일러가 나중에 구체적인 명령어를 결정합니다. 이 카탈로그는 커널의 전체 어휘가 아니라는 점도 분명히 합니다. 어떤 하드웨어 기능에 대응하는 프리미티브가 없다면 여전히 네이티브 레이어로 내려가야 합니다.

핵심 설계 선택은 늦은 디스패치입니다. 타일 프리미티브를 호출하면 즉시 낮춰지지 않고, 미해결 TilePrimitiveCall IR 노드로 기록됩니다 . 이 노드들은 LowerTIRx까지 IR 안에 남아 있다가, TilePrimitiveDispatch가 프리미티브 유형, 실행 스코프, 피연산자 레이아웃, 대상 백엔드, 선택적 힌트를 기준으로 고른 백엔드별 본문으로 각각을 대체합니다 . 실질적인 장점은 분명합니다. 작성자 코드 없이 디스패치 규칙만 바꾸면 같은 커널 소스를 다른 백엔드로 다시 겨냥할 수 있습니다.

하나의 프리미티브가 어떤 명령어로 매핑되는지는 최종적으로 해석된 대상에 전적으로 달려 있습니다.

따라서 소스의 copy는 어떤 대상에서는 TMA 벌크 전송이 되고, 다른 대상에서는 단순한 벡터화 로드가 될 수 있습니다. gemm 역시 호출을 다시 쓰지 않아도 WGMMA, Blackwell의 tcgen05 경로, 또는 시스톨릭 배열 명령어로 낮춰질 수 있습니다 . 이것이 TIRx가 말하는 "새 하드웨어를 단계적으로 올린다"는 주장 뒤의 메커니즘입니다. 새 가속기에는 새 커널이 아니라 새 디스패치 규칙이 필요합니다.

이 표면 위에 무언가를 만들기 전에 존중해야 할 주의점도 있습니다. 공식 타일 프리미티브 문서는 시그니처와 변형이 "may change"될 수 있다고 경고합니다 . 여기에 TIRx 문서는 0.26.dev0로 표시되어 있지만 배포된 휠은 0.25.0이라는 사실까지 함께 보면, v0.25.0의 29개 프리미티브 카탈로그는 안정화 전 API로 보는 편이 맞습니다. 실험에는 쓸 수 있지만, 프로덕션 커널을 고정해 의존할 만큼 얼어붙은 계약은 아직 아닙니다.

메가커널, 가속기 도입, 프로그래밍 가능한 IR 확장

TIRx는 명시적인 하드웨어 제어가 비용을 감수할 만큼 가치 있는 세 가지 워크로드를 겨냥합니다. 메가커널, 새 가속기 도입, 그리고 도구와 에이전트가 수행하는 프로그래밍 가능한 IR 확장입니다. 공식 개요는 메가커널을 "fine-grained dependencies and in-kernel scheduling"이 있는 작업을 퓨즈하는 방식으로 설명합니다 . 실제로는 작성자가 예를 들어 어텐션 계산과 정규화 단계를 하나의 커널 안에서 합칠 수 있다는 뜻입니다. 중간 텐서를 글로벌 메모리에 다시 쓰고 두 번의 별도 실행 사이에서 런타임 디스패치 오버헤드를 내는 대신, 커널 내부의 명시적 제어 흐름으로 의존성을 표현합니다.

두 번째 대상은 가속기 도입입니다. 커널 로직과 백엔드 디스패치가 분리되어 있기 때문에, 즉 타일 프리미티브가 미해결 노드로 기록되고 나중에 TilePrimitiveDispatch로 해석되기 때문에, 문서 표현대로 새 하드웨어 대상을 추가하는 일은 "a staged process rather than a redesign"이 됩니다 . 명령어나 메모리 공간에 대한 새 디스패치 규칙을 등록하면, 그것을 사용하는 커널을 다시 쓰거나 컴파일러를 포크하지 않아도 됩니다. TIRx는 하드웨어 기능이 컴파일러가 안정적으로 자동화할 수 있기 전에 "arrives before a compiler can reliably automate"될 때 선택하는 레이어가 바로 이것이라고 명시합니다 .

세 번째 워크로드인 에이전트형 커널 프로그래밍에서는 이 프로젝트의 문제의식이 가장 선명하게 드러납니다. TVM 창시자이자 Carnegie Mellon University 교수인 Tianqi Chen은 2026년 6월 출시를 에이전트 시대의 AI 컴파일러 역할과 연결하며, 에이전트에게는 다음이 필요하다고 설명했습니다.

"access to a predictable DSL that offers maximum expressiveness, paired with a minimal compiler they can directly open up, build toolings, and improve for," — Tianqi Chen, TVM creator and CMU faculty (source: @tqchenml, 2026-06).

그 주장을 뒷받침하는 구체적 메커니즘은 FFI 표면입니다. TIRx는 "IR and compiler utilities through TVM FFI across Python, C++, and Rust"를 노출하므로 , 도구나 LLM 에이전트가 IR을 블랙박스로 다루는 대신 직접 검사하고 확장할 수 있습니다.

에이전트 주도 커널 탐색을 실용적으로 만드는 것은 벤치마크 전에 작동하는 정적 피드백 루프입니다. 문서는 GPU 실행 전에 well-formedness, synchronization validity, race-freedom, value simulation 같은 피드백을 제공하는 구조화된 탐색 공간을 설명합니다 . 따라서 에이전트는 가속기 사이클을 낭비하지 않고도 탐색 시점에 잘못 구성되었거나 레이스가 있는 후보를 걸러낼 수 있습니다. 2차 보도에는 탐색 공간 수준 L1-L4가 언급되지만, 이 세부 내용은 공식 문서 페이지에는 나오지 않으므로 잠정적인 정보로 다루는 편이 맞습니다 .

TIRx 준비 상태 지표: 패키지된 휠과 문서가 엇갈리는 지점

v0.25.0의 TIRx는 완성된 제품이 아니라 상당한 규모의 초기 도입으로 보는 편이 맞습니다. PyPI에 apache-tvm==0.25.0로 올라온 패키지 휠은 2026년 6월 19일 릴리스되었고, 초기 TIRx 인프라와 후속 수정 사항을 함께 담고 있습니다. 여기에는 TIRx 스크립트 테스트에서 제거된 T.block API, dialect 리다이렉트 수정, bringup 이후의 S-TIR transform 테스트 복구가 포함됩니다 . 릴리스 페이지가 별도의 TIRx 전용 릴리스로 제목 붙어 있지는 않으므로, 0.25.0은 안정적인 독립 컴파일러라기보다 주요 TIRx bringup과 문서를 함께 실은 릴리스로 읽는 것이 정확합니다 .

가장 뚜렷한 차이는 버전입니다. TIRx 문서 페이지에는 tvm 0.26.dev0로 표시되어 있지만, 최신 stable 휠은 0.25.0입니다 . 문서에 나온 일부 표면 영역, 예를 들어 primitive 시그니처, builder API, pipeline pass 이름은 0.25.0 휠이 실제로 노출하는 내용이 아니라 0.25 이후 개발 상태를 반영할 수 있습니다. 프로덕션에서 TIRx API에 의존하기 전에는 문서만 보지 말고 v0.25.0 릴리스의 태그된 소스와 반드시 대조해야 합니다.

백엔드 범위에도 두 번째 주의점이 있습니다. PR 리뷰 댓글에는 AWS Trainium이 언급되지만, 공식 작성자 요약과 문서는 CUDA 및 Blackwell급 코드 생성에만 초점을 맞춥니다 . CUDA가 아닌 dispatch는 아직 확인되지 않은 것으로 취급해야 합니다. 오늘 검증할 수 있는 성숙도는 CUDA 경로입니다.

마지막으로, TIRx가 의도적으로 제거한 것이 무엇인지 기억해야 합니다. CUDA-native 계층은 자동 스케줄링이 없다고 명확히 말합니다. 작성자가 쓴 그대로 emitted됩니다 . 성능 이식성 보장은 없습니다. 생성되는 커널의 모든 속성, 즉 벡터화, 동기화, occupancy, 메모리 레이아웃은 컴파일러가 아니라 작성자의 책임입니다.

핵심은 이렇습니다. 오늘 TIRx를 탐색하려면 apache-tvm==0.25.0을 설치하되, 실제로 배포할 것은 태그된 소스에 맞춰 고정하고, 기대 범위는 CUDA/Blackwell로 한정하며, 성능을 처음부터 끝까지 직접 책임질 예산을 잡아야 합니다. Triton이 숨겨 두는 이 절충을 TIRx는 명시적으로 드러냅니다.

자주 묻는 질문

작성자 관점에서 TIRx는 Triton과 어떻게 다른가요?

둘 다 타일 기반 DSL이지만, 프로그래머와 컴파일러의 경계를 서로 다른 위치에 둡니다. Triton은 하드웨어 오케스트레이션을 block-level 추상화 뒤에 숨깁니다. 반면 TIRx는 loop 구조, warp ID, 동기화, pipeline 상태를 작성자의 소스 코드 안에 남겨 두고, 컴파일러는 재사용 가능한 tile 구조를 계속 추론할 수 있게 합니다. 공식 개요의 표현처럼, "orchestration stays in hardware-native source code, while the recurring tile-level structure becomes visible to the compiler"입니다 . 실제로 autoscheduler가 iteration 순서를 다시 쓰지는 않습니다. 작성자가 loop, branch, buffer, backend intrinsic을 직접 표현하고, 재사용 가치가 있을 때 tile primitive(copy, gemm, reduction)를 사용합니다.

"자동 스케줄링 없음"은 성능 측면에서 무엇을 뜻하나요?

작성한 것이 그대로 emitted된다는 뜻입니다. CUDA-native basics 페이지는 "no automatic scheduling"이라고 명확히 말합니다. TIRx는 작성자를 대신해 loop를 재정렬하거나 prefetch hint를 넣거나 암묵적인 thread predication을 추가하지 않습니다 . native 계층은 어떤 하드웨어 기능에 primitive가 없을 때 들어가는 곳입니다. 그 결과는 완전한 제어와 완전한 책임의 결합입니다. 벡터화, occupancy, 동기화, 메모리 레이아웃은 작성자가 인코딩하므로, 성능은 optimizer가 추론한 결과가 아니라 그 선택들이 만들어 내는 결과입니다.

v0.25.0에서 TIRx는 어떤 GPU 아키텍처를 지원하나요?

문서상 주요 대상은 NVIDIA Blackwell급 GPU입니다. dispatch 예시는 matrix multiply를 WGMMA 및 tcgen05 명령으로, copy를 TMA로 lowering합니다 . 2026년 5월 18일 병합된 PR #19581은 이 작업을 "Blackwell-class GPU architectures"의 저수준 프로그래밍으로 설명합니다 . AWS Trainium은 PR 리뷰 댓글에 등장하지만 공식 문서화되지는 않았고, CUDA가 유일하게 확인된 codegen 경로입니다. CUDA/Blackwell을 넘어선 백엔드 성숙도는 검증되지 않은 것으로 보아야 합니다.

TIRx는 지금 프로덕션에서 의존해도 될 만큼 안정적인가요?

아직 안정적인 독립 제품으로 보기는 어렵습니다. 2026년 6월 19일 릴리스된 v0.25.0 휠은 tests/python/tirx에서 1,723개 테스트를 통과했고 47개가 skipped되었습니다 . 이는 기본적인 soundness를 보여 주는 의미 있는 신호입니다. 하지만 TIRx 문서는 0.26.dev0로 표시되어 있는 반면 최신 stable 휠은 0.25.0입니다 . 또한 tile primitive 페이지는 시그니처와 variant가 바뀔 수 있다고 경고합니다 . 배포 전에는 apache-tvm==0.25.0에 고정하고, 모든 API를 태그된 소스와 대조해 확인해야 합니다.

TIRx는 IR을 프로그래밍 도구나 LLM 기반 작성자가 접근할 수 있게 어떻게 열어 두나요?

TIRx는 Python, C++, Rust 전반의 TVM FFI를 통해 IR node와 compiler utility를 노출하므로, 도구와 agent가 IR을 black box로 취급하지 않고 직접 열어 볼 수 있습니다 . Tile primitive 호출은 unresolved TilePrimitiveCall node로 기록되며 dispatch 전에도 inspect할 수 있습니다 . 문서는 GPU 실행 없이 동작하는 static feedback도 설명합니다. well-formedness, synchronization validity, race-freedom, value simulation이 여기에 포함되며, agent가 생성한 kernel을 search-time에 검증할 수 있게 합니다 .