GenAI (생성형 AI)는 새로울지 모르지만, GPU는 그렇지 않습니다! 지난 수년간 많은 이들이 OpenCL부터 SYCL, oneAPI 등에 이르기까지 C++를 사용하여 이식 가능한 GPU 프로그래밍 모델을 만들고자 시도해 왔습니다. 이것들은 AI 컴퓨팅 (AI compute)의 민주화를 목표로 했던 가장 그럴듯한 CUDA 대안들이었지만, 여러분은 아마 들어본 적이 없을 수도 있습니다. 왜냐하면 이들은 AI 분야에서 유의미한 역할을 수행하는 데 실패했기 때문입니다.

이 프로젝트들은 모두 컴퓨팅에 의미 있는 기여를 해왔지만, 우리가 미래를 위한 AI 컴퓨팅을 실현하는 데 진지하게 임하고자 한다면, 단순히 성공을 축하하는 것뿐만 아니라 그들을 저해했던 실수들을 비판적으로 검토해야 합니다. 거시적인 관점에서 볼 때, 이러한 문제들은 산업계 참여자들이 협력하면서도 동시에 경쟁하는 "개방형 협력 경쟁 (open coopetition)"의 어려움과 그 과정에서의 구체적인 관리상의 실수에서 비롯됩니다.

자, 자세히 살펴봅시다. 🚀

CUDA C++ 대안: OpenCL, SYCL, 그리고 그 외

GPU 프로그래밍을 개방하는 것을 목표로 한 많은 프로젝트가 있었지만, 제가 가장 잘 아는 것은 OpenCL입니다. CUDA와 마찬가지로, OpenCL은 프로그래머들에게 GPU에서 실행되는 코드를 작성하기 위한 C++와 유사한 경험을 제공하는 것을 목표로 했습니다. 저에게 이 역사는 개인적인 의미가 있습니다. 2008년, 저는 Apple에서 OpenCL을 구현하는 주요 엔지니어 중 한 명이었습니다 (당시 제가 구축하던 Clang 컴파일러의 첫 번째 상용 사용 사례였습니다). 제품을 출시한 후, 우리는 산업 전반에 걸쳐 채택되고 표준화될 수 있도록 이를 Khronos Group에 기여하기로 하는 중대한 결정을 내렸습니다.

그 결정은 특히 모바일 및 임베디드 장치에서 OpenCL의 광범위한 산업적 채택으로 이어졌습니다 (로고 참조). 오늘날 OpenCL은 Android와 같은 플랫폼의 GPU 컴퓨팅뿐만 아니라 DSP와 같은 특수 애플리케이션에서도 구동되며 엄청난 성공을 유지하고 있습니다. CUDA와 달리 OpenCL은 처음부터 이식성을 위해 설계되었으며, CPU, GPU 및 기타 가속기 전반에 걸친 이기종 컴퓨팅 (heterogeneous compute)을 지원하는 것을 목표로 했습니다. 또한 OpenCL은 SYCL, Vulkan, SPIR-V, oneAPI, WebCL 및 기타 여러 시스템에 영감을 주었습니다.

하지만 기술적인 강점과 폭넓은 채택에도 불구하고, OpenCL은 결코 지배적인 AI 컴퓨팅 플랫폼이 되지 못했습니다. 여기에는 몇 가지 주요한 이유가 있습니다: 개방형 코피티션 (Coopetition, 협력적 경쟁)의 내재적 긴장 관계, 그로부터 파생된 기술적 문제들, 진화하는 AI의 요구 사항, 그리고 TensorFlow 및 PyTorch와 연계된 NVIDIA의 통합 전략입니다.

위원회 속도의 “코피티션 (Coopetition)”

2008년 당시 Apple은 PC 시장에서 작은 플레이어였으며, 산업 표준화가 더 많은 개발자에게 도달할 수 있게 해줄 것이라고 생각했습니다. 그러나 OpenCL이 하드웨어 제조사들 사이에서 폭넓게 채택되기는 했지만, 그 진화는 곧 커다란 장애물에 부딪혔습니다. 바로 위원회 주도 개발 (Committee-driven development)의 속도였습니다. Apple에게 있어 이 느리고 합의 중심적인 프로세스는 결정적인 결격 사유였습니다. 우리는 플랫폼을 빠르게 움직이고, 새로운 기능(예: C++ 템플릿 추가)을 추가하며, Apple 플랫폼만의 차별성을 표현하기를 원했습니다. 우리는 냉혹한 현실에 직면했습니다. 위원회 표준의 단점은 모든 일이 갑자기 위원회의 합의 속도로 움직인다는 것이었으며, 이는 마치 빙하가 움직이는 것처럼 느리게 느껴졌습니다.

하드웨어 벤더들은 통합된 소프트웨어 생태계의 장기적인 이점을 인식하고 있었지만, 단기적으로는 치열한 경쟁자였습니다. 이는 미묘하지만 중대한 문제로 이어졌습니다. 참여자들이 자신이 작업 중인 하드웨어 기능을 위원회에 알리는 대신(이는 경쟁자에게 선점 기회를 주는 격이 됩니다), 하드웨어가 출하될 때까지 혁신 기술을 비밀로 유지하다가, 해당 기능들이 범용화(Commoditized)된 이후에야 비로소 논의하는 방식(대신 벤더 전용 확장 기능(Vendor-specific extensions)을 사용하는 방식)을 취하게 된 것입니다.

이는 제품 출시를 통해 큰 반향을 일으키기 위해 비밀리에 빠르게 움직이고자 했던 기업인 Apple에게 엄청난 문제가 되었습니다. 이에 따라 Apple은 OpenCL을 포기하기로 결정했습니다. 대신 Metal을 도입했고, iOS에 OpenCL을 가져오지 않았으며, 나중에 macOS에서 OpenCL을 지원 중단(Deprecated)했습니다. 다른 회사들은 OpenCL을 고수했지만, 이러한 구조적 과제들은 최첨단 AI 및 GPU 혁신의 속도에 맞춰 진화하는 OpenCL의 능력을 계속해서 제한했습니다.

OpenCL의 기술적 문제들

Apple이 Kronos에 OpenCL 표준을 기여하기로 대담하게 결정했을 때, 그들이 모든 것을 쏟아부은 것은 아니었습니다. 그들은 OpenCL을 기술 사양 (technical specification)으로서 기여했지만, 완전한 참조 구현 (reference implementation)은 제공하지 않았습니다. 컴파일러 프런트엔드 (compiler front-end)의 일부(Clang)는 오픈 소스였지만, 공유된 OpenCL 런타임 (runtime)이 없었기 때문에 벤더들은 자신들만의 커스텀 포크 (custom forks)를 개발하고 컴파일러를 완성해야만 했습니다. 각 벤더는 자체적인 구현체(”fork”)를 유지해야 했고, 공유되고 진화하는 참조 모델이 없었기에 OpenCL은 벤더별 포크와 확장 기능 (extensions)이 뒤섞인 누더기 같은 상태가 되었습니다. 이러한 파편화 (fragmentation)는 결국 OpenCL이 가능하게 하려고 설계되었던 바로 그 핵심 가치인 이식성 (portability)을 약화시켰습니다.

게다가, 벤더들이 차별화된 기능들을 숨기거나 벤더 전용 확장 기능으로 격리하면서, 그 수가 폭발적으로 증가하고 OpenCL(및 그 파생물들)을 파편화시켰으며, 이는 벤더에 종속되지 않는 통합 플랫폼으로서의 능력을 침식시켰습니다. 이러한 문제들은 OpenCL의 호환성 (compatibility) 및 적합성 테스트 (conformance tests)의 취약성으로 인해 더욱 악화되었습니다. 설상가상으로, OpenCL은 이전에 논의했던 모든 “C++ 문제들”을 그대로 물려받았습니다.

개발자들은 안정적이고 지원이 잘 되는 도구를 원하지만, OpenCL의 파편화, 취약한 적합성 테스트, 그리고 일관성 없는 벤더 지원은 개발자들에게 좌절감을 주는 과정이 되었습니다. 한 개발자는 **OpenCL을 사용하는 것은 “선인장을 껴안는 것만큼이나 불편하다”**라고 요약하기도 했습니다! 아픕니다.

OpenCL이 파편화와 위원회 주도의 느린 진화로 고군분투하는 동안, AI는 소프트웨어 프레임워크와 하드웨어 역량 모두에서 급격히 발전하고 있었습니다. 이는 OpenCL이 제공하는 것과 현대의 AI 워크로드 (workloads)가 필요로 하는 것 사이에 훨씬 더 큰 격차를 만들어냈습니다.

진화하는 AI 연구 및 AI GPU 하드웨어의 요구사항

TensorFlow와 PyTorch의 등장은 개선된 인프라와 대기업(BigCo) 자금의 대규모 유입에 힘입어 AI 연구의 혁명을 일으켰습니다. 이는 OpenCL에 큰 도전 과제가 되었습니다. OpenCL은 GPU 연산 (compute)을 가능하게 했지만, 대규모 학습 (training) 및 추론 (inference)에 필요한 고수준 AI 라이브러리와 최적화 기술이 부족했습니다. CUDA와 달리, 행렬 곱셈 (matrix multiplication), Flash Attention, 또는 데이터센터 규모의 학습과 같은 핵심 연산에 대한 내장 지원이 없었습니다.

TensorFlow와 PyTorch를 OpenCL에서 사용할 수 있도록 확장하려는 산업 전반의 노력은 (명백하고 엄청난 수요가 있었음에도 불구하고) 근본적인 장애물에 빠르게 부딪혔습니다. 선인장을 계속 껴안고 있던 개발자들은 곧 가혹한 현실을 깨달았습니다. 새로운 하드웨어로의 이식성 (portability)은 해당 하드웨어의 전체 성능을 끌어낼 수 없다면 아무런 의미가 없다는 사실이었습니다. 이식 가능한 하드웨어 특화 성능 향상 (hardware-specific enhancements)을 표현할 방법이 없었고, 경쟁적 협력 (coopetition)이 협업을 짓눌리면서 발전은 정체되었습니다.

눈에 띄는 사례가 무엇일까요? OpenCL은 현대적인 GPU 및 AI 가속기에서 효율적인 행렬 곱셈을 수행하는 특화된 하드웨어 유닛인 텐서 코어 (Tensor Cores)에 대한 표준화된 지원을 여전히 제공하지 않습니다. 이는 OpenCL을 사용하는 것이 CUDA나 다른 파편화된 벤더 네이티브 소프트웨어를 사용하는 것에 비해 성능이 5배에서 10배까지 느려짐을 의미합니다. 연산 비용이 이미 천문학적인 생성형 AI (GenAI) 분야에서, 5배에서 10배의 성능 저하는 단순히 불편한 수준이 아니라 사업 자체를 불가능하게 만드는 결정적 요인 (dealbreaker)입니다.

TensorFlow 및 PyTorch에 대한 NVIDIA의 전략적 접근

OpenCL이 파편화된 거버넌스의 무게 아래 고전하는 동안, NVIDIA는 앞서 논의했듯이 매우 통제되고, 고도로 전략적이며, 무자비할 정도로 효과적인 근본적으로 다른 접근 방식을 취했습니다. NVIDIA는 CUDA의 고수준 라이브러리를 TensorFlow 및 PyTorch와 함께 적극적으로 공동 설계 (co-design)하여, 이들이 항상 NVIDIA 하드웨어에서 최적으로 실행되도록 보장했습니다. 이러한 프레임워크들이 CUDA를 기반으로 네이티브하게 구축되었기 때문에 NVIDIA는 엄청난 선점 효과를 누렸으며, 제품 출시와 동시에 성능을 최적화함으로써 그 우위를 더욱 공고히 했습니다.

NVIDIA는 형식적인 OpenCL 구현체를 유지했지만, 전략적으로 성능을 제한하여(예: TensorCores를 사용할 수 없게 함) CUDA 구현체가 항상 필요하도록 만들었습니다. 업계 내 NVIDIA의 지속적이고 상승하는 지배력은 CUDA 구현체에 항상 가장 많은 투자가 이루어질 수밖에 없는 경로를 확보했습니다. 시간이 흐르면서 OpenCL 지원은 약해지다 결국 사라졌고, 그동안 CUDA는 논란의 여지 없는 표준으로서 그 입지를 굳혔습니다.

이러한 C++ GPU 프로젝트들로부터 무엇을 배울 수 있는가?

위의 역사는 그 시대를 직접 겪은 우리에게는 잘 알려져 있지만, 진정한 가치는 과거로부터 배우는 데서 옵니다. 이를 바탕으로, 저는 성공적인 시스템이 반드시 다음과 같은 요건을 갖추어야 한다고 믿습니다:

• 단순히 논문 명세서와 "호환성" 테스트가 아닌, **참조 구현체 (reference implementation)**를 제공해야 합니다. 호환성을 정의하는 것은 PDF가 아니라, 실제로 작동하고 채택 가능하며 확장 가능한 구현체여야 합니다.
• 참조 구현체를 유지 관리하는 주체에 의해 추진되는 강력한 리더십과 비전을 가져야 합니다.
• 업계 선두 주자의 하드웨어에서 최고의 성능을 내야 합니다. 그렇지 않으면 업계를 통합할 수 있는 수단이 아닌, 항상 이등품 대안에 머물게 될 것입니다.
• 변화하는 요구사항에 맞춰 신속하게 진화해야 합니다. AI 연구는 정체되어 있지 않으며, AI 하드웨어 혁신은 여전히 가속화되고 있기 때문입니다.
• 뛰어난 사용성, 도구, 빠른 컴파일 시간을 제공함으로써 **개발자의 애정 (developer love)**을 구축해야 합니다. 또한, AI 분야에서 "C++ 같은" 방식은 딱히 매력적인 판매 포인트가 아닙니다!
• 개방형 커뮤니티를 구축해야 합니다. 광범위한 채택 없이는 기술적 탁월함도 의미가 없기 때문입니다.
• 파편화 (fragmentation)를 피해야 합니다. 서로 호환되지 않는 포크(fork)로 갈라지는 표준은 소프트웨어 개발자들에게 효과적인 통합 계층을 제공할 수 없습니다.

이것들이 바로 제가 OpenCL과 같은 위원회 중심의 노력이 결코 성공할 수 없다고 믿는 근본적인 이유입니다. 또한, 이것이 제가 Intel의 OneAPI(현재 UXL Foundation)와 같이 명목상으로는 개방되어 있지만, 실제로는 다른 모든 경쟁사와 경쟁하는 단일 하드웨어 벤더에 의해 통제되는 프로젝트들에 대해 더욱 회의적인 이유이기도 합니다.

AI 컴파일러(AI Compilers)는 어떠한가?

C++ 접근 방식이 하드웨어 제조사들을 위한 AI 연산(AI compute)을 통합하는 데 실패함과 동시에, AI 산업은 더 큰 과제에 직면했습니다. 바로 NVIDIA 하드웨어에서조차 CUDA를 사용하는 문제였습니다. 인간이 모든 코드를 수동으로 작성해야 한다면 어떻게 AI 연산을 확장할 수 있을까요? 칩은 너무 많고, AI 알고리즘도 너무 많으며, 수동으로 최적화하기에는 워크로드(workload)의 순열(permutations)이 너무나도 방대합니다.

AI의 지배력이 커짐에 따라, 저를 포함한 시스템 개발자들과 컴파일러 엔지니어(compiler engineers)들의 관심을 필연적으로 끌게 되었습니다. 다음 포스트에서는 TVM, OpenXLA, MLIR와 같이 널리 알려진 "AI 컴파일러" 스택을 깊이 있게 다루며, 무엇이 작동했고 무엇이 작동하지 않았는지, 그리고 우리가 앞으로 가져갈 수 있는 교훈은 무엇인지 살펴볼 것입니다. 불행히도, 그 교훈들은 앞서 언급한 내용들과 크게 다르지 않습니다.

역사는 그대로 반복되지는 않지만, 운율을 맞추듯 닮아간다. - Mark Twain

다음에 뵙겠습니다. 그때까지, FLOPS가 함께하기를! 👨💻

-Chris

다음 단계는?

MAX 플랫폼과 Mojo 프로그래밍 언어에 대해 더 자세히 알아보고, 차세대 AI 혁신의 물결을 만드는 데 동참하세요.

MAX로 시작하기 – 귀하의 AI 작업을 가속화할 수 있는 최신 플랫폼을 탐색해 보세요. - Mojo 매뉴얼을 확인하고 GPU 프로그래밍을 위한 차세대 언어를 시작해 보세요. - 이 포스트에 대한 의견이나 Chris에게 궁금한 점을 Modular 포럼에 공유해 주세요. Chris는 3월 10일 월요일에 열리는 다음 커뮤니티 미팅에서 이 시리즈에 대한 질문에 답변할 예정입니다.