“실행을 신뢰하는 대신 검증한다”라니, 이제 Nvidia조차 Claude가 전부 쓴 글을 내놓는 모양임.

왜 “Nvidia조차”임? 거의 모든 일에 AI를 쓰자고 전폭적으로 나서는 회사임. “McDonald's조차 건강에 나쁜 음식을 내놓는다”는 것과 다를 게 없음.

이제 인간은 뭘 위해 존재하는 걸까? LLM과 대화만 하는 존재가 되는 게 우리의 미래인가? 정말 점점 그렇게 느껴짐.

글을 읽기 전에 이 댓글부터 봐서, 라이브러리가 전부 LLM으로 생성됐기 때문에 NVIDIA도 검증은 했지만 신뢰하지는 않는다는 뜻으로 오해했음.

Nvidia 직원들은 별로 신경 쓰지 않는 듯함. 1년도 더 전부터 일부 소규모 프로젝트에서 AI가 통째로 쓴 “문서”를 봤는데, 그때는 그런 방식이 조금이라도 괜찮은 선택이 되기 전이었음.

이제 NVIDIA가 Hugging Face를 소유하고 있고, Hugging Face에는 Rust 추론용으로 훌륭한 Candle 크레이트가 있으니, 제대로 된 네이티브 Rust 커널로 가는 좋은 발걸음으로 보임. https://github.com/huggingface/candle

커널을 Rust로 작성하는지는 아무도 신경 쓰지 않음. 커널은 C로 작성하도록 만들어졌고, 더 높은 수준의 추상화를 원한다면 타일 크기 등을 잘 추상화하는 Triton 같은 DSL을 쓰면 됨.

CUDA를 정말 싫어함. 이런 독점 소프트웨어를 C++ 코드베이스에 한 번 들이면 걷어내기 매우 어렵고, 결국 특정 업체에 종속되거나 #ifdef 지옥에 빠지며, 대개 둘 다 겪게 됨.
GPU는 CPU와 다른 기계라는 사실을 받아들이고, Metal·OpenCL·D3D12처럼 커널을 별도 파일에 작성해 직접 실행하는 게 가장 좋은 GPU 프로그래밍 방식임. 요즘은 Triton 같은 DSL도 있어서, Rust로 기대할 수 있는 것보다 훨씬 편하게 커널을 작성할 수 있음.

진심으로 궁금한데, 왜 그냥 “crap”이라고 쓰지 않는 건가? 심한 욕도 아니고, 이런 자기 검열의 의미를 모르겠음. 욕하기 싫으면 욕이 아닌 단어를 쓰면 됨.

독점 기술을 코드베이스에 도입하는 일은 어디서나 늘 해왔고, 사업의 일부일 뿐임. 여기에 감정을 쏟는 건 에너지 낭비로 느껴짐.
Win32 API가 독점적이라면 직접 쓰거나, 래퍼·UI 프레임워크를 쓰거나, Windows용 개발을 안 하면 됨. 임베디드 개발이라면 제조사 매뉴얼의 명세대로 구현하거나, HAL이 있으면 쓰거나, 그 일을 안 하면 되는 더 단순한 선택임.

커널을 별도 파일에 작성하고 직접 실행하는 게 보통 CUDA 코드를 작성하는 방식 아닌가?

Mojo를 쓰면 하나의 언어로 모든 대상을 지원할 수도 있음.

스텁이나 래퍼를 두고 추상화하면 됨. 전형적인 결합도 문제이지, CUDA만의 문제가 아님.

LLM이 모든 걸 작성하는 시대가 되면서 Rust를 배울 의욕이 조금 꺾였는데, 이걸 보고 다시 관심이 생김. 적어도 LLM이 아직 이것을 학습하지 않았다는 이유만으로도 흥미로움!

LLM이 라이브러리를 잘 쓰려면 반드시 그 라이브러리를 학습해야 하는 건 아님. 결국 LLM이 잘 아는 Rust 코드임.

정확히 무엇이 학습을 막는 건가? LLM 전에도 당신보다 Rust를 훨씬 잘 작성하는 인간은 있었고, 이제는 LLM이 있을 뿐임. 차이는 비용과 작업 시간뿐임.
Rust에 관한 모든 질문에 답해줄 훌륭한 교사인 LLM까지 생겼는데도 배우지 않을 핑계를 찾는 건가? 어느 순간에는 배우기 귀찮았을 뿐이고 LLM은 핑계라는 걸 인정해야 함.

안정화되면 써보고 싶음! 현재 그래픽에는 WGPU, CUDA에는 cudarc를 사용 중임.
Cuda-oxide는 Cudarc의 호스트 구성 요소와 비슷하지만 Rust 스타일의 커널 방언을 사용함. 호스트와 장치 사이에서 구조체를 공유할 수 있다는 장점이 있지만, 표준 CUDA 커널 대신 아직 개발 중인 새 방언을 써야 한다는 단점도 있음.
타일 API도 아직 안 써봤지만 기대 중임. 마지막으로 확인했을 때 Cuda Oxide는 Linux 전용이고 비동기 처리가 필수여서 아직 사용하지 못했음.

cudarc의 일대일 대응이 특히 좋았음. 기존 예제나 참고 자료를 찾기 쉽고, 거기 나온 내용이 코드와 그대로 대응됨. CUDA 자체도 어려운데 방언까지 쓰면 기존 작업물을 참고하기가 조금 더 어려워짐.
그래도 이번에 소개한 두 접근법 모두 cudarc보다 전반적으로 사용하기 편해 보이고, 빌드 구성과 환경 조정도 덜 필요해 보여서 반가움.

그러면 Linux에서 TJunc 핫스폿 온도도 조회할 수 있게 되는 건가?

AI가 찍어낸 저질 글인데, 어떻게 신뢰할 수 있겠나?

이 글을 보니 Nvidia 내부에서 아무도 이 프로젝트에 관심이 없는 것처럼 느껴짐. 관심이 있었다면 적어도 발표문은 사람이 직접 쓰게 했을 것임.

우선 1.0 이전 버전이고, cuda-oxide의 SIMT 경로를 선택하면 Rust 나이틀리 컴파일러가 필요하므로 안정적이지 않은 소프트웨어임.
커널에 문제가 생기거나 Rust로 사용자 정의 커널을 작성하려면 원인이 cuda-oxide(SIMT), Rust, CUDA, 또는 타일 경로를 선택했을 때의 Tile 중 어디에 있는지 진단해야 함.
의존성이 하나 더 늘어나는 셈이며, CUDA 자체를 제외하면 모두 오픈 소스임. 결국 CUDA 계층에 문제가 생기면 업체가 고쳐줄 때까지 기다릴 수밖에 없음.