CUDA Rust의 두 갈래, cuda-oxide와 cutile-rs
NVIDIA가 CUDA Rust를 발표했다. 호스트에서 다른 언어 커널을 호출하는 래퍼가 아니다. GPU에서 도는 커널 자체를 Rust로 쓰고, 네이티브 PTX로 컴파일하는 경로다.
2026년 9월 발표이며, CUDA C++·CUDA Python만큼 성숙한 도구 체인은 아직 아니다. NVIDIA는 2027년 이후에도 CUDA Rust를 키울 계획이라고 밝혔다.
배경은 단순하다. 추론 엔진, 서빙 인프라, 드라이버, 에이전트 런타임 같은 AI 시스템 계층에서 Rust가 늘고 있다. NVIDIA도 Nova Linux 드라이버를 Rust로 쓰고, Dynamo를 Rust 코어 위에 올렸으며, NVTX에 Rust 바인딩을 제공한다. 다만 GPU 커널만은 예외였다. Rust에서 커널을 실행할 수는 있어도, 커널 본문은 다른 언어로 쓰는 경우가 많았다. CUDA Rust는 그 틈을 메운다.
두 갈래: SIMT와 Tile
CUDA 자체에도 실행 모델이 둘 있다. CUDA Rust도 그대로 따른다.
SIMT는 스레드 하나가 할 일을 적고, 수천 개를 띄우는 방식이다. CUDA C++와 numba-cuda가 쓰는 모델이다.
Tile은 데이터를 타일(묶음) 단위로 나눠 계산을 적고, 실제 GPU 스레드에 어떻게 배치할지는 Tile IR 컴파일러에 맡긴다. C++와 Python에서도 쓸 수 있다.
NVIDIA의 권고는 분명하다. 먼저 Tile을 보고, 아키텍처별 제어나 메모리·스레드를 직접 다뤄야 할 때 SIMT로 내려가라. Tile은 컴파일러가 GPU 세대에 맞는 배치를 정하므로, 소스에 아키텍처별 분기를 덜 넣어도 된다.
언어와 실행 모델은 따로 고를 수 있다. 스택이 이미 C++이면 CUDA C++를, Python이면 CUDA Python을 쓰면 된다. 아래 두 프로젝트는 그 스택이 Rust일 때 쓰는 경로다. NVIDIA는 Rust / C++ / Python 사이 상호운용도 지원할 계획이다.
| cuda-oxide (SIMT) | cutile-rs (Tile) | |
| 작성 단위 | 스레드 하나 | 데이터 타일 |
| 스레드 배치 | 개발자가 직접 | 컴파일러 |
| 컴파일 | rustc 백엔드 → MIR → Pliron → LLVM → PTX | 커널 AST를 호스트에 넣고, 첫 실행 때 Tile IR로 JIT |
| Rust | 지정된 nightly | stable 1.89+ |
| CUDA | Toolkit 12.x 이상 | 13.3 |
| GPU | compute capability 8.0 이상 | 동일 |
| OS | 현재 Linux | 현재 Linux |
| 성숙도 | 초기 알파 | 더 앞섬. crates.io 공개, 외부 사용 중 |
| 시작 | cargo oxide new / cargo oxide run | cargo add cutile |
두 프로젝트 모두 프로덕션용은 아니다. API도 바뀔 예정이다.
cuda-oxide: 스레드를 직접 다루는 SIMT
cuda-oxide는 rustc에 붙는 코드 생성 백엔드다. #[kernel] 함수만 GPU 경로로 보내고, 나머지는 표준 백엔드에 맡긴다.
컴파일 흐름은 이렇다.
Rust → Rust MIR → Pliron IR → LLVM IR → PTX
호스트 코드와 GPU 커널을 한 파일에 쓰고, 별도 커널 크레이트 없이 한 명령으로 빌드할 수 있다.
안전성의 핵심은 출력 버퍼 타입이다. 모든 스레드에 같은 &mut [f32]를 넘기면 Rust가 거부한다. 그래서 DisjointSlice가 하나의 가변 빌림을 스레드별 영역으로 나눈다. 각 스레드는 자기 원소만 독점한다. 인덱스는 전용 타입이고, 범위를 벗어나면 Option이 나온다.
실행 조건은 #[launch_contract]로 선언한다. 실제 실행 전에 설정이 이 조건과 GPU 제한에 맞는지 검사하고, 검증을 통과한 뒤에만 안전한 실행 메서드를 호출할 수 있다. 계약을 안 적은 커널은 unsafe 실행만 열린다.
환경은 cargo oxide doctor로 점검한다. Linux, compute capability 8.0 이상 GPU, CUDA Toolkit 12.x 이상, clang/libclang, 지정된 nightly Rust가 필요하다. 첫 실행은 코드 생성 백엔드를 빌드하느라 오래 걸리고, 이후에는 캐시를 재사용한다.
현재 공유 메모리 사용에는 unsafe가 필요하다. 고성능 SIMT 커널의 핵심 기능이라, 이 경로를 안전하게 만드는 작업이 진행 중이다.
cutile-rs: 타일과 소유권으로 실행을 정하는 Tile
cutile-rs는 개별 값이 아니라 데이터 타일을 계산 단위로 쓴다. 각 타일 블록의 코드는 단일 논리 스레드처럼 적는다. 이를 실제 GPU 스레드 몇 개로 돌릴지는 컴파일러가 정한다.
#[cutile::module] 매크로가 커널의 구문 트리를 호스트 바이너리에 넣고, 처음 필요할 때 CUDA Tile IR로 JIT 컴파일한다.
쓰기 가능한 출력 텐서는 호스트에서 겹치지 않는 부분으로 나눈 뒤 커널에 넘긴다. 각 타일은 자기 영역에 대한 독점 접근권을 받는다. 타일 폭과 전체 크기에서 실행 격자도 같이 정해진다. SIMT처럼 격자를 따로 계산하고 인덱싱과 맞출 필요가 없다. 별도의 DisjointSlice도 없다. Rust의 &mut가 이미 가진 독점 규칙을 그대로 쓴다.
매크로가 만든 실행 함수는 텐서 소유권을 받아 GPU 작업이 끝난 뒤 돌려준다. 예제에서는 텐서 생성, 커널 호출, 결과 복사를 지연 작업으로 이어 두고, .sync_on(&stream)에서 한꺼번에 실행하고 동기화한다.
요구 사항은 SIMT보다 가볍다. Linux, compute capability 8.0 이상 GPU, CUDA 13.3, stable Rust 1.89 이상. nightly나 직접 준비한 LLVM은 필요 없다. crates.io에 올라가 있어 cargo add cutile로 넣을 수 있다.
Hugging Face의 Grout 추론 엔진과 mistral.rs에서 이미 쓰이고 있다. 그래도 기능은 아직 불완전하고 API는 바뀔 예정이다.
컴파일러가 막는 실수
두 방식 모두 입력은 여러 곳에서 읽되, 출력 영역은 한 쓰기 주체가 독점하도록 설계됐다.
GPU에서는 수천 개 스레드가 같은 버퍼에 정해진 순서 없이 접근한다. 둘 이상이 같은 주소에 닿고 그중 하나가 쓰면, 결과에 순서가 개입한다. 이런 버그는 재현이 어렵고, 테스트를 통과한 뒤 운영에서 터지기도 한다.
그래서 출력 버퍼를 동시에 입력으로 넘기면 컴파일 단계에서 거부된다.
- cuda-oxide: 같은 버퍼를 불변 참조와 가변 참조로 동시에 빌릴 수 없다.
- cutile-rs: 이미 소유권을 넘긴 텐서를 다시 쓸 수 없다.
cuda-oxide는 개별 커널 실행 호출을 검사한다. cutile-rs는 실행 경계를 넘어 텐서 소유권을 추적한다. 후자가 더 강한 주장이다.
Tile은 공유 메모리와 스레드 인덱싱을 컴파일러가 맡긴다. 개발자가 그걸 직접 다루다 실수할 여지는 줄지만, 세부 제어권도 같이 넘긴다. SIMT는 제어권을 유지하는 대신, 지금은 공유 메모리에 unsafe가 필요하다.
아직 초기이고, 혼자 시작한 일도 아니다
Cargo와 크레이트를 쓰는 일반적인 Rust 개발만큼 시작하기 쉬운 환경을 만드는 것도 과제다. SIMT 경로의 nightly 고정도 줄이려 한다.
Rust GPU 개발이 이번에 처음 시작된 것은 아니다. NVIDIA는 기존 커뮤니티 작업을 바탕으로 협력한다고 밝혔다. cuda-oxide 문서 부록은 Rust-GPU, rust-cuda, CubeCL 등과의 위치를 설명한다. rust-cuda 유지관리자와 협력 중이며, rust-gpu, cudarc, VectorWare 팀의 선행 작업도 방향에 영향을 주고 있다.
커뮤니티 반응은 갈린다. CUDA 벤더 종속을 걱정하는 쪽과, 커널 실행을 한 표현으로 적고 컴파일러가 실수를 잡아 주는 쪽이 CUDA의 강점이라고 보는 쪽이 있다. VectorWare 창업자는 NVIDIA와 협업 중이며, 두 접근은 상호 보완이라고 했다.
지금 해볼 수 있는 것
- SIMT: cargo oxide new로 프로젝트를 만들고 cargo oxide run
- Tile: 저장소에서 cargo run -p cutile-examples --example hello_world
- 문서: cuda-oxide book, cuTile Rust 문서
- 논문: Fearless Concurrency on the GPU
- 이슈·Discussion: cuda-oxide, cutile-rs
한 줄로 정리하면
NVIDIA는 Rust를 GPU 커널 작성 언어로 공식 축에 올렸다. 래퍼가 아니라 PTX까지 가는 네이티브 경로다.
기본값은 Tile(cutile-rs)이다. 스레드와 메모리를 직접 쥐어야 하면 SIMT(cuda-oxide)로 내려간다. 둘 다 빌림과 소유권으로 입력·출력 버퍼가 같은 메모리를 잘못 가리키는 일을 컴파일 시점에 막는다.
지금은 초기 단계다. 다만 “Rust에서 커널을 호출할 수는 있어도, 커널은 다른 언어로 쓴다”는 전제는 깨지기 시작했다.
내 생각
MS도 Rust를 Tier-1 언어로 지정하고, 리눅스도 Rust를 도입하고, Ubutu는 26.04에서 sudo를 Rust로 재작성하더니 26.10에서 mv와 cp같은 명령어도 Rust로 재작성을 하고 있다.
이번에는 NVIDIA가 CUDA 프로그래밍으로 사용할 수 있는 언어로 Rust를 추가함으로 인해, 더 많은 분야에서 Rust를 활용하고 있는 사례가 늘어나고 있는 것으로 보입니다.
Rust를 지원하지 않아 하지 못했던 분야들에 대해서도, 점차 범위를 넓혀가서, 해당 언어에 대한 지식만 있다면 쉽게 Rust를 활용해서 프로젝트를 진행할 수 있게 될거 같습니다.
'리뷰 > 테크 블로그' 카테고리의 다른 글
| Rust, Microsoft의 Tier-1 언어가 되다 (0) | 2026.09.13 |
|---|---|
| Tokio 생태계에 등장한 새로운 웹 풀스택 프레임워크, Topcoat (0) | 2026.07.26 |
| Bun은 왜 RIIR를 선택했을까 (0) | 2026.07.12 |
| 왜 kt cloud는 FastAPI 대신 Robyn을 선택했을까? (0) | 2026.04.16 |
댓글