새로운 NVIDIA–Hugging Face 논문이 GPU 프로그래머들이 10년간 불가능하다고 여겨온 주장을 내놓았습니다. Rust의 빌림 검사기(borrow checker)를 디바이스 수준까지 그대로 가져가면서도 그 비용은 거의 0에 가깝다는 것입니다.
cuTile Rust의 작동 방식: CUDA 타일 프로그램 안에서의 빌림 검사기 규칙
cuTile Rust는 타일 기반의 Rust DSL 및 런타임으로, CPU 측에서 CUDA 호출을 감싸는 방식이 아니라 Rust의 소유권과 빌림 검사 규칙을 CUDA 타일 프로그램 내부까지 확장합니다. 2026년 6월 arXiv 논문 "Fearless Concurrency on the GPU"(Elibol et al., NVIDIA and Hugging Face)의 핵심 결과에 따르면, 안전한(safe) 지속형 f16 GEMM(M=N=K=8192)이 B200에서 2.07 PFlop/s를 달성했으며, 이는 cuBLAS의 약 96.4%이고 비안전(unsafe) 저수준 Tile IR 변형과의 차이는 0.3% 이내입니다 . 즉, 안전성 메커니즘은 측정 가능한 런타임 오버헤드를 전혀 유발하지 않습니다. 이것이 바로 역사적으로 안전 언어 기반 GPU 프로그래밍을 현실적으로 불가능하게 만들었던 바로 그 '세금'입니다.
한눈에 보기: cuTile Rust는 Rust의 빌림 검사기를 CUDA 디바이스 코드 내부까지 밀어 넣어, 데이터 레이스를 컴파일 타임에 원천 차단합니다. 성능 손실이 없다는 증거: B200에서 안전한 f16 GEMM이 2.07 PFlop/s — cuBLAS의 96.4% — 를 기록했습니다 (arXiv:2606.15991, NVIDIA/Hugging Face, 2026년 6월).
이 연구의 핵심은 Rust가 CUDA를 호출할 수 있다는 사실이 아닙니다. 호스트 측 Rust 엔진은 이미 그렇게 해왔습니다. 핵심은 '별칭(aliasing) XOR 가변성(mutability) 불변 원칙' — 참조는 유일하게 가변이거나 자유롭게 공유되거나 둘 중 하나이며, 절대 동시에 둘 다일 수 없다는 원칙 — 을 커널 내부 구조적으로 강제한다는 데 있습니다. cuTile Rust는 가변 출력 텐서를 타일 프로그램별로 서로 겹치지 않는 하위 텐서로 분할하고, 불변 읽기는 모든 프로그램에 브로드캐스트합니다 . 생성된 런처는 GPU 작업이 진행되는 동안 데이터 소유권을 보유하므로, 커널이 아직 소유한 버퍼에 호스트가 접근할 수 없습니다.
단일 프로그램 내부의 순서는 Tile IR '토큰(token)'이 처리합니다. 이 토큰이 메모리 연산의 순서를 강제하여 읽기와 쓰기가 레이스 상태로 재정렬되는 것을 막습니다. 커널은 CUDA Tile IR을 거쳐 하강(lower)하며, 이 논문의 특별한 점은 Tile IR의 약한 순서(weakly-ordered) 메모리 모델에 대해 안전 API의 데이터 레이스 부재를 수학적으로 증명한다는 것입니다. 이 형식 논증은 부록 A에 수록되어 있습니다 . 레이스는 런타임에 사후 감지하는 것이 아니라 컴파일 타임에 설계 단계에서 제거됩니다.
"우리는 빌림 검사기의 별칭 XOR 가변성 불변 원칙을 GPU 실행에 매핑하고, 안전 API가 Tile IR의 약한 순서 메모리 모델에 대해 데이터 레이스 자유를 가짐을 증명합니다"라고 arXiv:2606.15991의 저자들 — Elibol, Roesch, Gelado, Garland(NVIDIA)와 Eric Buehler(Hugging Face) — 은 밝힙니다.
이 연구와 함께 두 가지 산출물이 공개됩니다. cuTile Rust 자체는 NVlabs/cutile-rs로, 그 위에 구축된 Qwen3 추론 엔진인 Grout는 huggingface/grout로 공개되었습니다 . 이어지는 섹션에서는 그 96% 수치가 실제로 어디까지 유효한지, 그리고 안전성 보장이 어디서 cuBLAS로 조용히 넘어가는지를 살펴봅니다.
GEMM과 대역폭: B200에서 cuTile Rust 대 cuBLAS
NVIDIA B200에서 안전한 cuTile Rust 커널은 동일 하드웨어의 가장 빠른 비안전 코드와 몇 퍼센트 이내의 차이를 보입니다. 안전한 지속형 f16 GEMM(M=N=K=8192)은 2.07 PFlop/s를 기록했으며, 이는 cuBLAS의 약 96.4%이고 저수준 Tile IR 변형과의 차이는 0.3% 이내입니다 . 이 논문의 핵심 주장은 바로 이 격차에 있습니다. 런치 경계를 넘어 적용된 빌림 검사기 안전성이 타일 추상화에서 측정 가능한 처리량 손실을 전혀 유발하지 않는다는 것입니다.
메모리 바운드 작업도 동일한 결과를 보입니다. 원소별 덧셈(element-wise add)은 이론적 최고 대역폭 약 7.68 TB/s 대비 7.02 TB/s — 약 91.4% — 를 달성했으며, 전반적인 측정 결과는 GEMM에서 약 2 PFlop/s, 원소별 연산에서 약 7 TB/s 수준입니다 . NVlabs/cutile-rs의 벤치마크 폴더가 커밋되어 있어 논문의 정확한 설정으로 재현할 수 있으며, 이는 대부분의 벤더 벤치마크 발표보다 훨씬 투명한 방식입니다.
| 커널 (B200, cuTile Rust v0.2.0) | 안전한 cuTile Rust | 저수준 Tile IR | cuBLAS | 기준 대비 % |
|---|---|---|---|---|
| 지속형 f16 GEMM (M=N=K=8192) | 2.07 PFlop/s | ~2.07 PFlop/s (+0.3%) | ~2.15 PFlop/s | cuBLAS의 96.4% |
| 원소별 덧셈 (대역폭) | 7.02 TB/s | — | — | 최고 대역폭 ~7.68 TB/s의 ~91.4% |
짚어둘 만한 세부 사항은 왜 오버헤드가 거의 0에 가까운가 하는 점입니다. 논문은 이 부분에서 신중하며, 독자도 마찬가지여야 합니다. 이 결과는 구조적 필연이 아니라 실증적 측정값입니다 . 타일 추상화는 스레드 수준 안전 모델이 필요로 하는 세밀한 동기화를 피할 수 있는 단위로 작동합니다. 하위 텐서 분할과 Tile IR 토큰 순서 지정이 컴파일 타임에 처리되므로, 런타임에 지불할 가드 비용이 존재하지 않습니다. 하지만 저자들은 안전성 오버헤드가 구조적으로 불가능하다고 주장하지 않습니다. 이 특정 추상화에서, 이 커널들에 대해, 측정 결과 0으로 나왔다고 주장합니다. 이는 "안전은 무료다"라는 주장보다 더 좁고 더 정직한 진술입니다.
따라서 96.4% 수치는 실측값이며 잘 검증되어 있지만, 이는 커널 코어를 설명하는 것이지 엔드-투-엔드 엔진을 설명하는 것이 아닙니다. 2.07 PFlop/s를 기록한 GEMM은 하나의 큰 크기에서 깔끔하고 규칙적인 형태입니다. 다음 섹션에서는 이 수치를 Grout의 디코드 루프까지 따라가며, 안전한 경로가 가장 큰 GEMM을 어디서 조용히 cuBLAS로 넘겨주는지를 살펴봅니다.
Grout는 Qwen3 디코드용 실험 엔진입니다 — 스케줄러가 아닙니다
Grout는 cuTile Rust 위에서 전체를 Rust로 작성한 Qwen3 추론 엔진으로, 2026년 6월 16일 기준 커밋 6개, 태그된 릴리스 없이 huggingface/grout로 공개되었습니다 . 프로젝트 README에는 이 엔진을 서빙 스택이 아닌 cuTile Rust 커널을 검증하는 테스트베드로 명시하고 있으며, 이를 기준으로 관련 수치를 해석하는 것이 올바른 접근입니다.
"Grout는 범용 서빙 엔진이 아닌 LLM 추론 테스트베드입니다." — 프로젝트 README, huggingface/grout.
이 범위 지정이 중요한 이유가 있습니다. Grout는 엔드투엔드로 순수 안전한(safe) Rust만 사용하는 것이 아닙니다. GEMM 코어를 둘러싼 퓨즈드 연산과 모델 특화 연산에는 안전한 cuTile Rust 커널을 사용하지만, 대규모 행렬 곱셈은 cuBLAS에 위임하고 그 외 구간에서는 로우 포인터 커널과 unchecked_accesses를 활용합니다 . 즉 이 엔진은 혼합 안전성 하네스입니다. 안전한 경로는 논문이 부각하려는 커스텀 연산을 담당하고, 무거운 선형대수 연산은 다른 모든 엔진이 사용하는 것과 동일한 벤더 라이브러리에서 실행됩니다.
기능 부재도 마찬가지로 의도적입니다. Grout에는 연속 배칭, 프리픽스 캐시, 분산 병렬 처리, OpenAI 호환 엔드포인트가 없습니다. vLLM과 SGLang을 프로덕션 프레임워크로 정의하는 스케줄링 메커니즘 자체가 존재하지 않습니다 . 남은 것은 단일 요청 디코드 루프뿐입니다. 보고된 수치 — RTX 5090에서 Qwen3-4B 171 토큰/초, B200에서 Qwen3-32B 82 토큰/초 — 는 배치 크기 1의 단일 요청 측정값입니다 .
이렇게 보면 Grout는 스케줄링이나 다중 사용자 처리량이 아닌 cuTile Rust 연산을 독립적으로 검증하는 도구입니다. '안전한 커널이 깔끔한 디코드 루프에서 토큰 단위로 따라잡는가?'라는 질문에는 답하지만, '엔진이 다수의 요청을 스케줄링할 수 있는가?'는 다루지 않습니다. 이 구분이 다음 질문으로 이어집니다. 크로스 엔진 비교에서 부하 상황에서 vLLM과 SGLang을 빠르게 만드는 바로 그 캐시를 왜 비활성화했는가.
Grout 디코드 비교에서 프리픽스 캐시를 비활성화한 이유
크로스 엔진 수치는 경쟁 엔진의 가장 빠른 경로를 비활성화한 상태에서 수집되었습니다. vLLM 0.18.0은 CUDA 그래프와 프리픽스 캐시를 비활성화한 채 실행되었고, SGLang 0.5.9는 RadixAttention과 프리픽스 캐시를 비활성화했습니다 . 이는 설계에 의한 것이지 실수가 아닙니다. 안전한 cuTile Rust 커널이 디코드 루프 내에서 수동 튜닝된 CUDA와 속도를 맞추는지 묻기 위해서는 커널이 아닌 모든 것 — 캐싱, 그래프 캡처, 스케줄러 트릭 등 커널 수준 차이를 가릴 수 있는 요소 — 을 제거해야 했습니다.
측정 지표가 이 범위를 명확히 합니다. 크로스 엔진 수치인 request_gen_tps는 생성된 토큰 수를 엔드투엔드 총 요청 소요 시간으로 나눈 값입니다 . 각 요청은 콜드 상태로 하나씩 측정됩니다. 따라서 이 비교는 실제 프로덕션 처리량을 결정하는 메커니즘을 의도적으로 제외합니다:
- PagedAttention — 여러 시퀀스가 GPU 메모리를 공유할 수 있도록 비연속 KV 캐시를 할당하는 vLLM 기능 .
- 연속 배칭(Continuous batching) — 새 요청과 처리 중인 요청을 교차 처리해 GPU가 토큰 사이에 유휴 상태에 빠지지 않도록 함.
- 프리픽스/캐시 재사용 — 프롬프트가 겹칠 때 재계산을 건너뛰는 RadixAttention과 프리픽스 캐싱.
- 콜드 스타트 상각 — 서버가 워밍업되어 동시 트래픽으로 포화되면 사라지는 비용.
이 기능들을 비활성화하면 Grout, vLLM, SGLang은 사실상 동일한 조건으로 수렴합니다. 단일 요청, 배치 크기 1로 각 엔진이 디코드 커널을 통해 얼마나 빠르게 토큰을 생성하는지 측정하는 것입니다. 이는 커널 경쟁력을 공정하게 검증하는 테스트이며, 논문이 설계한 바로 그 테스트입니다. 스케줄러 테스트도 아니고 서버 처리량 테스트도 아닙니다.
"vLLM 및 SGLang과 경쟁력 있음"이라는 표현은 이 관점에서 읽어야 합니다. 이 주장은 커널이 병목인 배치 크기 1의 콜드 스타트 디코드에서 성립하며, Grout의 안전한 cuTile Rust 연산이 기존 엔진과 몇 퍼센트 차이 내에 들어옵니다 . 다중 사용자 부하에 대해서는 아무것도 말하지 않습니다. 바로 그 상황에서 PagedAttention과 연속 배칭이 vLLM과 SGLang을 앞서게 합니다. 캐시 비활성화 각주 없이 헤드라인만 읽으면, 논문이 한 번도 주장하지 않은 프로덕션 서빙 성능으로 좁고 정직한 커널 결과를 과장하게 됩니다. 다음 섹션의 CSV 마진이 배치 크기 1 창이 얼마나 좁은지 보여줄 것입니다.
CSV로 본 Grout 디코드 성능: RTX 5090·B200 격차 해부
커밋된 CSV는 배치-1 우위가 얼마나 미미한지를 정확히 수치화한다: Grout이 앞서지만, 격차는 한 자릿수 퍼센트에 불과하다. GeForce RTX 5090에서 Qwen3-4B를 pp=18/tg=36으로 실행했을 때, 중앙값 request_gen_tps는 Grout이 170.52 tok/s, vLLM 163.63, SGLang 162.52로, 가장 근접한 경쟁자 대비 4.2% 우위를 보인다 . 동일 설정으로 HGX B200에서 Qwen3-32B를 구동하면, Grout는 80.85를 기록해 vLLM의 78.31, SGLang의 75.49를 앞서며 3.2% 격차를 유지한다 . 이 수치는 Grout 커밋 4631fb0, vLLM 0.18.0, SGLang 0.5.9 기준으로 측정되었다 .
| 하드웨어 / 모델 | 설정 (pp/tg) | Grout | vLLM 0.18.0 | SGLang 0.5.9 |
|---|---|---|---|---|
| RTX 5090 / Qwen3-4B | 18 / 36 | 170.52 | 163.63 | 162.52 |
| RTX 5090 / Qwen3-4B | 18 / 8192 | 154.75 | 151.26 | 154.26 |
| B200 / Qwen3-32B | 18 / 36 | 80.85 | 78.31 | 75.49 |
| B200 / Qwen3-32B | 18 / 512 | ~81.56 | — | — |
중앙값 request_gen_tps (생성 토큰 수 / 엔드투엔드 요청 시간), 배치-1 디코드 .
주목할 패턴은 두 가지다. 첫째, 'B200에서 Qwen3-32B가 82 tok/s'라는 헤드라인 수치는 pp=18/tg=36 결과가 아니다 — tg=512에서 Grout의 최고치인 약 81.56 tok/s를 반올림한 값이다 . 둘째, 시퀀스가 길어질수록 격차가 줄어든다. RTX 5090에서 tg=8192 기준으로 Grout(154.75)와 SGLang(154.26)의 차이는 초당 0.5 토큰 미만이며, vLLM은 151.26이다 .
프리필 양상도 이와 일치한다: RTX 5090에서 짧은 프롬프트일 때 Grout의 지연 시간 우위가 가장 뚜렷하며, B200에서는 시퀀스가 길어질수록 세 엔진이 수렴한다 . CSV를 있는 그대로 읽으면, Grout는 단일 요청 디코드에서 세 엔진 중 가장 빠른 것이 맞다 — 다만 4~7%의 격차는 실재하되 좁으며, 긴 컨텍스트에서는 사라진다. 이는 커널 품질에 대한 신뢰할 수 있는 신호이지, 서빙 처리량에 대한 판정은 아니다.
Fearless Concurrency on the GPU (arXiv:2606.15991)와 커밋된 벤치마크 CSV를 통해 누구나 이 수치를 직접 재현할 수 있다.
cuTile Rust v0.2.0: 대형 GEMM·SIMT 연산에서 드러나는 경쟁 안전 보장의 한계
안전 보장은 부분적이며, 그 한계는 트랜스포머 연산이 가장 집중되는 지점에 정확히 위치한다. 트랜스포머 순전파에서 가장 많은 비중을 차지하는 대형 행렬 GEMM은 안전한 cuTile Rust 커널 대신 cuBLAS로 폴백되므로, 공식적으로 증명된 데이터 경쟁 자유는 가장 핵심적인 경로를 보장하지 않는다. Grout의 공식 README는 안전 커널과 unchecked_accesses, 원시 포인터 커널, cuBLAS GEMM 폴백이 혼용됨을 명시하고 있다 . cuTile Rust는 현재 GEMM 핵심 주변의 커스텀 퓨전 연산과 모델별 연산을 다루지만, GEMM 자체는 포함되지 않는다.
이 추상화는 SIMT 수준의 제어도 포기한다. 워프 프리미티브와 명시적 공유 메모리 관리는 타일 모델 범위 밖에 있으며, 지원되지 않는 하위 수준 케이스는 unsafe 경로와 기능적으로 동일한 명시적 opt-out을 사용한다 . 워프 셔플이나 수작업 공유 메모리 스테이징을 활용하는 커널 작성자에게 타일 DSL은 아직 대체제가 아니다 — 해당 제어권을 구조적 경쟁 보장과 맞바꾼 상위 추상 레이어일 뿐이다. Tensor API 지원도 불완전하며, 대규모 배치 서빙 비교나 서드파티 재현 결과도 아직 없다.
성숙도 역시 또 다른 제약이다. NVlabs는 cuTile Rust를 버그 발생이 예상되고 기능이 불완전하며 API 변경이 있을 수 있는 초기 단계 연구로 분류하고 있으며, v0.2.0이 2026년 6월 16일 기준 최신 릴리스였다 . 툴체인 요구 사항은 다음과 같이 제한적이다:
- GPU: NVIDIA
sm_80+(Ampere 이상) - CUDA: 13.3 권장
- Rust: 1.89+
- OS: Ubuntu 24.04에서 테스트됨 — Windows 및 macOS 지원은 문서화되지 않음
이를 종합하면, 96.4% cuBLAS GEMM 결과와 부분적 안전 보장이 상충하지 않는 이유가 설명된다: cuTile Rust는 자신이 커버하는 타일 API에 대해 경쟁 자유를 증명한 뒤, 그 증명이 미치지 않는 대형 GEMM은 cuBLAS에 넘긴다. 보장은 적용 범위 안에서 실재하며, Tensor API와 SIMT 지원이 확충됨에 따라 그 범위가 핵심 관전 포인트다.
cuTile로 Rust CUDA 연산을 작성해야 할까? 솔직한 평가
답은 전적으로 독자가 누구냐에 달려 있다. GPU 커널 연구자와 컴파일러 제작자라면 지금 바로 NVlabs/cutile-rs를 주목할 만하다: 호스트/디바이스 런치 경계를 넘어 Rust의 aliasing-XOR-mutability 불변성을 확장하고, Tile IR의 약순서 메모리 모델에 대해 안전 API의 데이터 레이스 자유를 증명한 것은 Grout의 디코드 마진과 무관하게 진정한 기여다 . cuBLAS GEMM 결과의 96.4% 수준이라는 결과는 타일 추상화에서 안전성 비용이 거의 0에 가까울 수 있음을 보여준다 — 이것이 핵심 발견이다.
프로덕션 LLM 서빙에 대한 권고는 다르다: Grout는 바로 교체할 수 있는 대안이 아니다. 이 비교는 vLLM과 SGLang의 핵심 기능인 PagedAttention, 연속 배치, 프리픽스 캐싱, 멀티 GPU 분산을 범위 밖으로 뒀기 때문에 이 글에서 그것들을 검증하지 않는다. Grout 개발자들 스스로 이 맥락을 명확히 밝히고 있다.
"Grout는 추론 테스트베드이지, 범용 서빙 스택이 아닙니다." — Grout 개발자 (source: huggingface/grout README)
이 연구를 별도의 Rust 네이티브 엔진인 rvLLM (m0at/rvllm)과 혼동하지 말아야 한다. rvLLM의 '안전성'은 호스트 측 엔지니어링 규율, 즉 Result 기반 오류 처리와 unwrap() 금지를 통해 CUDA를 호출하는 방식으로, 디바이스 코드 소유권 증명이 아니다. 설계 방향이 달라 H100에서 배치 128 기준 5,802 tok/s를 기록하며 vLLM의 4,689와 비교된다 . 이는 대규모 배치 처리량이며, cuTile 논문은 배치-1 디코드를 측정한다. 두 프로젝트 모두 신뢰할 수 있는 Rust 신호지만, 서로 다른 질문에 답한다.
다음 릴리스에서 주목할 것: cuTile Rust의 v0.3.0 GEMM 커버리지, Tensor API 완성도, 그리고 가장 결정적인 — 서드파티 팀이 양쪽에 프리픽스 캐시를 활성화한 상태에서 Grout의 마진을 재현하는지 여부다. 그때까지의 구체적인 결론: 컴파일 타임 레이스 자유가 필요한 융합 모델 특화 커널 작성에는 지금 바로 cuTile Rust를 채택하고, 가장 큰 GEMM에는 cuBLAS를, 실제 트래픽 서빙에는 vLLM이나 SGLang을 유지하라.
자주 묻는 질문
Grout는 vLLM이나 SGLang의 대체재인가?
아니다. Grout의 README는 이를 명시적으로 추론 테스트베드로 규정하며, 범용 서빙 스택이 아니다 . 연속 배치, 프리픽스 캐시, 멀티 GPU 병렬 처리가 없어 vLLM과 SGLang이 핵심으로 삼는 프로덕션 스케줄링 기능이 빠져 있다. 논문 벤치마크는 vLLM의 CUDA 그래프와 프리픽스 캐시를 비활성화하고, SGLang의 RadixAttention을 비활성화한 상태에서 실행됐기 때문에 이 비교는 배치-1 단일 요청 디코드이며, 프로덕션 서빙의 동등 비교가 아니다 . 실제 트래픽에는 vLLM이나 SGLang을 유지하라.
cuTile Rust가 호스트 측 Rust CUDA 래퍼와 다른 점은?
기존 Rust-CUDA 래퍼는 Rust에서 디바이스 코드를 호출하지만 GPU 타일 프로그램 내부의 메모리 안전성에 대해 아무것도 강제하지 않는다. cuTile Rust는 Rust의 빌림 검사기 의미론을 호스트/디바이스 런치 경계를 넘어 유지한다: 가변 출력 텐서는 타일 프로그램마다 분리된 하위 텐서로 분할되고, 불변 읽기는 모든 프로그램에 브로드캐스트된다 . 그 결과 데이터 레이스는 컴파일 타임에 구조적으로 제거되며, 논문은 부록 A에서 안전 API의 데이터 레이스 자유를 Tile IR의 약순서 메모리 모델에 대해 형식적으로 증명한다 .
Grout는 왜 대규모 GEMM에 cuBLAS로 폴백하나?
cuTile Rust의 Tensor API가 v0.2.0에서 미완성이고, 트랜스포머 레이어의 지배적 연산인 대규모 행렬 곱셈이 아직 안전한 타일 추상화로 처리되지 않기 때문이다 . 따라서 Grout는 가장 큰 GEMM을 cuBLAS로 라우팅하고, 나머지에서는 원시 포인터 커널과 비검사 접근을 사용해 종단 간 순수 안전 Rust가 아니다 . cuTile Rust는 GEMM 코어 주변의 커스텀 융합·모델 특화 연산을 처리하고, 무거운 행렬 곱셈은 여전히 cuBLAS가 담당한다.
rvLLM은 cuTile Rust 및 Grout와 어떤 관계인가?
두 프로젝트는 안전성 모델이 다른 별개의 프로젝트로, 혼동해선 안 된다. rvLLM (m0at/rvllm)은 CUDA를 호출하는 호스트 측 Rust 엔진으로 Docker, conda, PyTorch, vLLM 없이 동작한다. 안전성은 엔지니어링 규율, 즉 unwrap() 금지와 Result 기반 오류 처리에서 비롯되며, 형식적 디바이스 코드 소유권 증명이 아니다 . H100에서 배치-128 기준 5,802 tok/s를 기록하며 vLLM의 4,689와 비교된다 . 반면 NVIDIA/Hugging Face의 작업은 GPU 디바이스 코드 자체의 형식적 안전성을 다룬다.
cuTile Rust에 필요한 하드웨어와 소프트웨어는?
cuTile Rust는 NVIDIA sm_80+ GPU(Ampere 이상), CUDA 13.3 권장, Rust 1.89+ 환경이 필요하며, 테스트는 Ubuntu 24.04에서 진행됐다. 2026년 6월 16일 기준 최신 릴리스는 v0.2.0이다 . 논문의 주요 벤치마크는 HGX B200의 Blackwell SXM 하드웨어를 사용한다 . NVlabs는 현 단계에서 예상되는 버그, 미완성 기능, API 파손을 고지하고 있으므로, cuTile Rust는 프로덕션 인프라가 아닌 연구 수준의 도구로 취급해야 한다.
