TensorFlow처럼 NVIDIA의 CUDA 독점도 깨질까요?

​지난 10년 동안 머신러닝 소프트웨어 개발 환경은 큰 변화를 겪었습니다. 많은 프레임워크가 등장했지만 대부분은 NVIDIA의 CUDA에 크게 의존하고 NVIDIA의 GPU에서 최고의 성능을 얻습니다. 그러나 PyTorch 2.0과 OpenAI Triton의 출시로 이 분야에서 Nvidia의 지배력이 무너지고 있습니다.

Google은 초기에는 머신러닝 모델 아키텍처, 훈련, 모델 최적화에서 큰 장점을 가지고 있었지만 이제는 이러한 장점을 완전히 활용하기가 어렵습니다. 하드웨어 측면에서는 다른 AI 하드웨어 기업이 엔비디아의 지배력을 약화시키기는 어려울 것이다. PyTorch 2.0과 OpenAI Triton이 등장할 때까지 기계 학습 모델의 기본 소프트웨어 스택은 더 이상 Nvidia의 비공개 소스 CUDA가 아닙니다.

TensorFlow 대 PyTorch

머신러닝 프레임워크에서도 유사한 경쟁이 발생합니다. 몇 년 전만 해도 프레임워크 생태계는 상당히 파편화되어 있었지만 TensorFlow가 선두 주자였습니다. 표면적으로 Google은 머신러닝 프레임워크 업계에 확고히 자리 잡은 것처럼 보입니다. TensorFlow를 사용하여 AI 애플리케이션 전용 가속기 TPU를 설계하여 선점자 이점을 얻었습니다.

그러나 이제 PyTorch가 승리했고 Google은 선점자 이점을 신흥 ML 산업에서 지배력으로 전환하지 못한 것으로 보입니다. Google은 PyTorch와 GPU를 사용하지 않고 자체 소프트웨어 스택과 하드웨어를 사용하기 때문에 요즘 기계 학습 커뮤니티에서 다소 고립된 것 같습니다. 실제로 Google은 TensorFlow와 직접 경쟁하는 두 번째 기계 학습 프레임워크인 JAX를 개발했습니다. 이는 전형적인 "Google 동작"입니다.

대규모 언어 모델, 특히 OpenAI의 대규모 언어 모델과 OpenAI API를 사용하여 구축된 다양한 언어 모델의 등장으로 인해 검색 및 자연어 처리 분야에서 Google의 지배력이 약해지고 있다고 믿는 사람들도 있습니다. 어쩌면 이 견해는 너무 비관적일 수도 있습니다. 결국 대부분의 최신 모델의 인프라는 여전히 Google이 개발한 변환기이기 때문입니다.

그렇다면 PyTorch가 왜 큰 승자가 될까요? 주된 이유는 PyTorch가 TensorFlow에 비해 유연성과 유용성이 더 높기 때문입니다. PyTorch와 TensorFlow의 주요 차이점은 Graph 모드 대신 Eager 모드를 사용한다는 것입니다.

Eager 모드는 일반적인 Python 코드와 다르지 않은 표준 스크립트 실행 방법이라고 할 수 있습니다. 이를 통해 사용자는 중간 작업의 결과와 모델이 실행되는 방식을 볼 수 있으므로 코드를 더 쉽게 디버깅하고 이해할 수 있습니다.

이에 비해 그래프 모드는 두 단계로 나누어져 있습니다. 첫 번째 단계는 작업이 수행되는 계산 그래프를 나타내며, 노드는 작업 또는 변수를 나타내고 노드 사이의 가장자리는 노드 사이의 데이터 흐름을 나타냅니다. 두 번째 단계는 계산 그래프의 최적화된 버전의 지연된 실행입니다.

이 2단계 접근 방식은 그래프 실행이 끝날 때까지 사용자가 무슨 일이 일어나고 있는지 볼 수 없기 때문에 코드를 이해하고 디버깅하는 것을 더욱 어렵게 만듭니다. 이는 Python 및 C++와 같은 "해석된" 언어와 "컴파일된" 언어와 유사하며, Python은 해석된 언어이기 때문에 디버깅이 더 쉽습니다.

TensorFlow는 이제 기본적으로 Eager 모드를 사용하지만 연구 커뮤니티와 대부분의 대규모 기술 회사에서는 PyTorch를 사용하기로 선택합니다.

기계 학습 훈련 구성 요소

기계 학습 모델 훈련이 가장 간단한 형태로 단순화되면 기계 학습 모델 훈련에 영향을 미치는 두 가지 주요 요소가 있습니다.

• 계산(FLOPS): 각 실행 밀도에서 레이어 내의 행렬 곱셈
• 메모리 대역폭.

이전에는 머신러닝 훈련 시간에 영향을 미치는 주요 요인은 시스템이 행렬 곱셈을 수행할 때까지 기다리는 계산 시간이었습니다. Nvidia GPU가 계속 발전함에 따라 이는 곧 더 이상 큰 문제가 되지 않을 것입니다.

NVIDIA는 무어의 법칙을 활용하여 FLOPS를 대폭 개선했지만 주요 아키텍처 변경 사항은 텐서 코어와 정밀도가 낮은 부동 소수점 형식이었습니다. 이에 비해 스토리지 측면에서는 큰 변화가 없습니다.

2018년 가장 발전된 모델은 BERT였으며 NVIDIA V100이 가장 발전된 GPU였습니다. 당시에는 행렬 곱셈이 더 이상 모델 성능을 향상시키는 주요 요소가 아니었습니다. 이후 모델의 매개변수 수는 3~4배 증가했고, 가장 빠른 GPU는 FLOPS가 1배 증가했습니다.

2018년에도 순수 컴퓨팅 중심 워크로드는 FLOPS의 99.8%를 차지했지만 런타임의 61%에 불과했습니다. 행렬 곱셈과 비교하여 정규화 및 포인트별 연산은 행렬 곱셈 FLOPS의 1/250 및 1/700만 사용하지만 모델 실행 시간의 거의 40%를 소비합니다.

Memory Wall

모델 크기가 계속 급증함에 따라 LLM(대형 언어 모델)에는 모델 무게에만 100GB 이상의 메모리가 필요합니다. Baidu와 Meta가 구축한 제품 추천 네트워크는 대규모 임베딩 테이블을 저장하기 위해 수십 테라바이트의 메모리가 필요합니다. 대규모 모델 학습/추론에서 대부분의 시간은 행렬 곱셈을 계산하는 데 소비되지 않고 데이터가 전송되기를 기다리는 데 사용됩니다. 분명히 문제는 설계자가 컴퓨팅에 더 많은 메모리를 배치하지 않는 이유이며 대답은 명백합니다. 바로 비용입니다.

가장 가까운 공유 메모리 풀은 일반적으로 동일한 칩의 SRAM입니다. 일부 기계 학습 ASIC은 거대한 SRAM 풀을 활용하여 모델 가중치를 유지하려고 합니다. 그러나 Cerebras의 대략 $5,000,000에 달하는 웨이퍼 규모 칩조차도 SRAM이 40GB에 불과합니다. 100B가 넘는 파라메트릭 모델의 가중치를 수용하기에는 메모리 용량이 부족합니다.

Nvidia는 훨씬 적은 온칩 메모리로 칩을 설계했습니다. A100은 40MB이고 H100은 50MB입니다. TSMC 5nm 칩의 1GB SRAM에는 약 200제곱밀리미터의 실리콘이 필요하며, 관련 제어 로직/구조를 구현하려면 400제곱밀리미터 이상의 실리콘이 필요합니다. A100 GPU의 가격이 10,000달러가 넘고 H100의 가격이 20,000달러에 가깝다는 점을 고려하면 이러한 접근 방식은 재정적 관점에서 실현 가능하지 않습니다. 데이터 센터 GPU에서 Nvidia의 대략 75%의 이윤폭을 무시하더라도 SRAM 메모리의 전체 생산 제품 가격은 여전히 ​​GB당 약 100달러입니다.

또한 기존 무어의 법칙 공정 기술이 축소되어도 온칩 SRAM 메모리 비용은 크게 줄어들지 않습니다. 동일한 1GB 메모리는 TSMC의 차세대 3nm 공정 기술을 사용하지만 비용은 더 높습니다. 3D SRAM은 SRAM 비용을 어느 정도 줄이는 데 도움이 되지만 이는 일시적일 뿐입니다.

메모리 계층의 다음 단계는 긴밀하게 결합된 오프칩 메모리 DRAM입니다. DRAM은 SRAM보다 지연 시간이 훨씬 높지만(~100ns 대 10ns) 훨씬 저렴합니다. DRAM은 수십 년 동안 무어의 법칙을 따라왔습니다. Gordon Moore가 이 용어를 만들었을 때 Intel의 주요 사업은 DRAM이었습니다. 트랜지스터 밀도와 비용에 대한 그의 예측은 일반적으로 2009년 이전 DRAM에 적용되었습니다. 하지만 DRAM 가격은 2012년 이후 거의 개선되지 않았습니다.

그러나 메모리에 대한 사람들의 수요는 더욱 늘어났습니다. DRAM은 이제 전체 서버 비용의 50%를 차지하며 점차 소위 '메모리 벽'을 형성하고 있습니다. NVIDIA의 2016년 P100 GPU와 최신 H100 GPU를 비교하면 메모리 용량은 5배(16GB → 80GB)로, FP16 성능은 46배(21.2 TFLOPS → 989.5 TFLOPS)로 향상된 것을 알 수 있습니다.

메모리 용량이 중요한 병목 현상이기는 하지만 또 다른 병목 현상인 메모리 대역폭도 매우 중요합니다. 병렬 처리를 통해 메모리 대역폭을 늘리는 경우가 많습니다. 오늘날 표준 DRAM의 비용은 GB당 몇 달러에 불과하지만 머신 러닝에 필요한 막대한 대역폭을 얻기 위해 Nvidia는 더 비싼 패키지가 필요한 3D 스택 DRAM 레이어로 구성된 장치인 HBM 메모리를 사용합니다. HBM의 비용은 패키징 및 볼륨 비용을 포함하여 GB당 약 $10-20입니다.

메모리 대역폭과 용량에 대한 비용 제약 문제는 Nvidia의 A100 GPU에서 특히 두드러집니다. 광범위한 최적화가 없으면 A100은 FLOPS 활용도가 매우 낮을 수 있습니다.

연구원들이 수많은 최적화를 했다고 해도 대형 언어 모델의 FLOPS 활용률은 60% 정도에 불과합니다. 메모리 병목 현상을 줄이기 위해 다른 컴퓨팅/메모리의 데이터를 기다리거나 적시에 결과를 다시 계산하는 데 많은 시간이 소요됩니다.

A100부터 H100까지 FLOPS는 6배 이상으로 늘어났지만, 메모리 대역폭은 1.65배로 늘어나는 데 그쳤습니다. 이로 인해 많은 사람들이 H100의 활용도가 낮을 ​​것이라는 우려를 갖게 되었습니다. A100은 메모리 벽을 벗어나기 위해 많은 트릭이 필요했고, H100은 달성하기 위해 훨씬 더 많은 트릭이 필요했습니다.

H100은 분산 공유 메모리와 L2 멀티캐스트를 Hopper 아키텍처에 제공합니다. 아이디어는 한 SM의 데이터를 다른 SM의 SRAM(공유 메모리/L1 캐시)에 직접 쓸 수 있도록 하는 것입니다. 이는 캐시 크기를 효과적으로 늘리고 DRAM 읽기/쓰기에 필요한 대역폭을 줄입니다. 미래의 아키텍처에서는 메모리 벽의 영향을 최소화하기 위해 메모리로 전송되는 작업 수를 줄일 것입니다. FLOPS는 매개변수 수의 세제곱으로 확장되어야 하고 메모리 대역폭과 용량 요구 사항은 2차로 확장되는 경향이 있기 때문에 모델이 클수록 활용도가 더 높아지는 경향이 있다는 점은 주목할 가치가 있습니다.

오퍼레이터 융합

모든 시간을 메모리 전송에 소비하는 경우(예: 메모리 대역폭 제한) GPU의 FLOPS를 늘리는 것은 도움이 되지 않습니다. 반면, 큰 matmu를 실행하는 데 모든 시간을 소비한다면 오버헤드를 줄이기 위해 모델 로직을 C++로 다시 작성하는 것조차 도움이 되지 않습니다.

PyTorch가 TensorFlow를 능가할 수 있는 이유는 Eager 모드가 유연성과 유용성을 향상시키기 때문입니다. 그러나 Eager 모드로 전환하는 것이 유일한 이점은 아닙니다. Eager 모드에서 실행할 때 각 작업은 메모리에서 읽어 계산된 후 다음 작업을 처리하기 전에 메모리로 전송됩니다. 광범위한 최적화가 없으면 메모리 대역폭 요구 사항이 크게 증가할 수 있습니다.

Eager 모드에서 실행되는 모델의 경우 주요 최적화 방법 중 하나는 연산자 융합입니다. Fusion 작업은 각 중간 결과를 메모리에 쓰는 대신 단일 패스로 여러 함수를 계산하여 메모리 읽기/쓰기를 최소화합니다. 운영자 융합은 운영자 스케줄링, 메모리 대역폭 및 메모리 크기 비용을 개선합니다.

이런 종류의 최적화에는 일반적으로 사용자 정의 CUDA 커널 작성이 포함되지만 이는 간단한 Python 스크립트를 사용하는 것보다 훨씬 어렵습니다. 시간이 지남에 따라 PyTorch에는 점점 더 많은 연산자가 꾸준히 구현되었으며, 그 중 다수는 단순히 여러 공통 작업을 더 복잡한 기능으로 결합합니다.

연산자를 추가하면 PyTorch에서 모델을 더 쉽게 생성할 수 있으며, Eager 모드는 메모리 읽기/쓰기 횟수가 적어 더 빠르게 수행됩니다. 단점은 PyTorch가 몇 년 내에 2000개 이상의 운영자로 폭발적으로 증가했다는 것입니다.

소프트웨어 개발자가 너무 게으르다고 할 수 있지만, 솔직히 게으르지 않은 사람이 누가 있겠습니까? PyTorch의 새로운 연산자에 익숙해지면 계속 사용합니다. 개발자는 성능이 향상되고 있다는 사실조차 깨닫지 못할 수도 있지만 더 많은 코드를 작성할 필요가 없기 때문에 연산자를 계속 사용합니다.

그리고 모든 오퍼레이터가 융합될 수는 없습니다. 칩 및 클러스터 수준에서 어떤 작업을 결합하고 어떤 작업을 특정 컴퓨팅 리소스에 할당할지 결정하는 데는 많은 시간이 걸립니다. 운영자를 통합하는 전략은 일반적으로 유사하지만 아키텍처의 차이로 인해 크게 달라질 수 있습니다.

NVIDIA WAS KING

각 운영자가 해당 아키텍처에 대해 빠르게 최적화되지만 다른 하드웨어에는 최적화되지 않기 때문에 운영자의 성장과 기본 상태는 NVIDIA에 이점이 됩니다. AI 하드웨어 스타트업이 PyTorch를 완전히 구현하기를 원한다면 이는 고성능으로 점점 늘어나는 2,000명의 운영자 목록을 지원하는 것을 의미합니다.

최대 성능을 추출하려면 많은 기술이 필요하기 때문에 GPU에서 FLOPS 활용도가 높은 대형 모델을 훈련하려면 점점 더 높은 수준의 재능이 필요합니다. 가산 연산자 융합의 Eager 모드 실행은 개발된 소프트웨어, 기술 및 모델이 현재 세대 GPU의 컴퓨팅 및 메모리 비율을 수용하기 위해 지속적으로 추진되고 있음을 의미합니다.

머신러닝 칩을 개발하는 모든 사람은 동일한 메모리 벽의 제약을 받습니다. ASIC은 가장 일반적으로 사용되는 프레임워크, 기본 개발 방법, GPU 최적화 PyTorch 코드, NVIDIA와 외부 라이브러리의 혼합을 지원함으로써 제한됩니다. 이 경우 더 많은 FLOPS와 더 엄격한 프로그래밍 모델을 선호하여 GPU의 다양한 비계산적 수하물을 피하는 아키텍처를 갖는 것은 거의 의미가 없습니다.

그러나 사용 편의성이 우선입니다. 악순환을 끊는 유일한 방법은 Nvidia의 GPU에서 모델을 실행하는 소프트웨어를 가능한 한 쉽고 원활하게 다른 하드웨어로 전송할 수 있도록 만드는 것입니다. PyTorch 2.0, OpenAI Triton 및 모자이크ML과 같은 MLOps 회사의 모델 아키텍처가 안정화되고 추상화됨에 따라 Nvidia의 고급 소프트웨어가 제공하는 사용 편의성보다는 칩 솔루션의 아키텍처와 경제성이 구매의 가장 큰 동인이 되기 시작합니다. .

PyTorch 2.0

몇 달 전 PyTorch 재단이 설립되어 Meta에서 분리되었습니다. 개방형 개발 및 거버넌스 모델에 대한 변경 사항 외에도 2.0은 초기 베타 버전으로 출시되었으며 3월에 일반 출시되었습니다. PyTorch 2.0은 많은 변화를 가져왔지만 가장 큰 차이점은 그래픽 실행 모델을 지원하는 컴파일 솔루션이 추가되었다는 것입니다. 이러한 변화를 통해 다양한 하드웨어 리소스를 보다 쉽게 ​​적절하게 활용할 수 있습니다.

PyTorch 2.0은 NVIDIA A100에서 훈련 성능을 86%, CPU에서 추론 성능을 26% 향상시킵니다. 이는 모델 학습에 필요한 계산 시간과 비용을 크게 줄여줍니다. 이러한 이점은 AMD, Intel, Tenstorrent, Luminous Computing, Tesla, Google, Amazon, Microsoft, Marvell, Meta, Graphcore, Cerebras, SambaNova 등의 다른 GPU 및 가속기로 확장됩니다.

PyTorch 2.0은 현재 최적화되지 않은 하드웨어에서 성능 개선의 여지가 더 큽니다. Meta와 다른 회사들은 수십억 달러 규모의 GPU 훈련 클러스터에서 더 적은 노력으로 더 높은 FLOPS 활용도를 달성하기를 원하기 때문에 PyTorch에 이렇게 큰 기여를 하고 있습니다. 이러한 방식으로 그들은 소프트웨어 스택을 다른 하드웨어에 더 쉽게 이식할 수 있도록 인센티브를 제공하여 기계 학습 공간에 경쟁을 도입합니다.

더 나은 API의 도움으로 PyTorch 2.0은 데이터 병렬성, 샤딩, 파이프라인 병렬성 및 텐서 병렬성을 지원하여 분산 교육을 향상시킬 수 있습니다. 또한 스택 전체에서 기본적으로 동적 모양을 지원하므로 다른 많은 예 중에서 LLM에 대해 다양한 시퀀스 길이를 더 쉽게 지원할 수 있습니다. 다음은 훈련에서 추론까지 Dynamic Shapes에 대한 첫 번째 주요 컴파일러 지원입니다.

PrimTorch

NVIDIA GPU를 제외한 모든 기계 학습 ASIC에 대해 PyTorch용으로 작성 완벽하게 지원하는 고성능 백엔드 2000명 이상의 운영자가 모두 쉬운 일은 아닙니다. PrimTorch는 PyTorch 최종 사용자에게 동일한 유용성을 유지하면서 운영자 수를 약 250명의 원래 운영자로 줄입니다. PrimTorch는 PyTorch의 다양한 비NVIDIA 백엔드 구현을 더 간단하고 더 쉽게 만듭니다. 맞춤형 하드웨어 및 시스템 공급업체는 소프트웨어 스택을 보다 쉽게 ​​출시할 수 있습니다.

TorchDynamo

그래프 패턴으로 전환하려면 신뢰할 수 있는 그래프 정의가 필요합니다. Meta와 PyTorch는 약 5년 동안 이러한 변화를 시도했지만 그들이 생각해낸 모든 솔루션에는 심각한 단점이 있었습니다. 마지막으로 TorchDynamo를 사용하여 문제를 해결했습니다. TorchDynamo는 외부 타사 라이브러리를 호출하는 스크립트를 포함하여 모든 PyTorch 사용자 스크립트를 수집하고 FX 그래프를 생성합니다.

Dynamo는 PrimTorch에서 모든 복잡한 연산자를 최대 250개의 기본 연산자로 줄입니다. 그래프가 형성되면 사용되지 않는 연산자는 삭제되고 그래프는 어떤 중간 연산자를 메모리에 저장하거나 기록해야 하는지, 어떤 연산자를 융합할 수 있는지를 결정합니다. 이는 모델 내의 오버헤드를 크게 줄이면서 사용자에게는 "완벽"합니다.

테스트된 7000개의 PyTorch 모델 중 TorchDynamo는 원래 코드를 변경하지 않고도 OpenAI, HuggingFace, Meta, NVIDIA, Stability.AI 등의 모델을 포함하여 99% 이상에서 이미 작동하고 있습니다. 테스트된 7000개 모델은 GitHub의 PyTorch를 사용하는 가장 인기 있는 프로젝트에서 무작위로 선택되었습니다.

Google의 TensorFlow/Jax 및 기타 그래프 모드 실행 파이프라인에서는 그래프를 캡처할 수 있도록 모델이 컴파일러 아키텍처에 적합한지 사용자가 확인해야 하는 경우가 많습니다. Dynamo는 부분 그래프 캡처, 보호된 그래프 캡처 및 즉시 다시 캡처를 활성화하여 이를 변경합니다.

부분 그래프 캡처를 통해 모델은 지원되지 않거나 Python이 아닌 구성을 포함할 수 있습니다. 모델 부분에 대해 그래프를 생성할 수 없는 경우 그래프 나누기가 삽입되고 부분 그래프 간 열성 모드에서 지원되지 않는 구성이 수행됩니다.

Protected 그래프 캡처는 캡처된 그래프가 실행에 유효한지 확인합니다. "보호"는 재컴파일이 필요한 변경을 의미합니다. 동일한 코드를 여러 번 실행해도 여러 번 다시 컴파일되지 않으므로 이는 중요합니다. 실시간 재캡처를 사용하면 캡처된 그래프가 실행에 유효하지 않은 경우 그래프를 다시 캡처할 수 있습니다.

PyTorch의 목표는 그래프 생성을 위해 Dynamo를 활용하는 원활한 UX로 통합된 프런트엔드를 만드는 것입니다. 솔루션의 사용자 경험은 변하지 않지만 성능은 크게 향상될 수 있습니다. 캡처 그래프는 대량의 컴퓨팅 리소스에서 병렬로 보다 효율적으로 실행될 수 있습니다.

Dynamo 및 AOT Autograd는 최적화된 FX 그래프를 PyTorch 기본 컴파일러 수준 TorchInductor에 전달합니다. 하드웨어 회사에서는 이 그래프를 자체 백엔드 컴파일러에 공급할 수도 있습니다.

TorchInductor

TorchInductor는 여러 가속기 및 백엔드를 위한 빠른 코드를 생성할 수 있는 Python 기본 딥 러닝 컴파일러입니다. 인덕터는 약 250명의 연산자가 포함된 FX 그래프를 가져와 약 50개의 연산자로 줄입니다. 다음으로 인덕터는 연산자가 융합되고 메모리 계획이 결정되는 스케줄링 단계에 들어갑니다.

그런 다음 Inductor는 CPU, GPU 또는 기타 AI 가속기에서 실행되는 코드를 생성하는 "Wrapper Codegen"으로 들어갑니다. 래퍼 Codegen은 컴파일러 스택의 인터프리터 부분을 대체하고 커널을 호출하고 메모리를 할당할 수 있습니다. 백엔드 코드 생성 부분은 GPU용 OpenAI Triton을 활용하고 PTX 코드를 출력합니다. CPU의 경우 Intel 컴파일러는 C++를 생성합니다(Intel이 아닌 CPU에서도 작동함).

향후 더 많은 하드웨어를 지원할 예정이지만, 중요한 점은 Inductor가 AI 하드웨어 가속기용 컴파일러를 만들 때 컴파일러 팀이 수행해야 하는 작업량을 크게 줄여준다는 것입니다. 또한 코드는 성능에 더욱 최적화되었으며 메모리 대역폭 및 용량 요구 사항이 크게 감소되었습니다.

연구자에게 필요한 것은 GPU만 지원하는 컴파일러만이 아니라, 다양한 하드웨어 백엔드를 지원하는 컴파일러입니다.

OpenAI Triton

OpenAI Triton은 NVIDIA의 폐쇄 소스 머신 러닝 소프트웨어에 획기적인 존재입니다. Triton은 Python에서 직접 데이터를 가져오거나 PyTorch Inductor 스택을 통해 데이터를 가져옵니다. 후자가 가장 일반적으로 사용됩니다. Triton은 입력을 LLVM 중간 표현으로 변환하고 코드를 생성하는 일을 담당합니다. NVIDIA GPU는 NVIDIA의 비공개 소스 CUDA 라이브러리(cuBLAS 등)를 건너뛰고 대신 오픈 소스 라이브러리(cutlass 등)를 사용하여 PTX 코드를 직접 생성합니다.

CUDA는 가속 컴퓨팅 세계에서 인기가 있지만 기계 학습 연구자와 데이터 과학자들 사이에서는 거의 알려지지 않았습니다. CUDA를 사용하면 문제가 발생할 수 있으며 하드웨어 아키텍처에 대한 깊은 이해가 필요하므로 개발 프로세스가 느려질 수 있습니다. 결과적으로 기계 학습 전문가는 CUDA 전문가의 도움을 받아 코드를 수정, 최적화 및 병렬화할 수 있습니다.

Triton은 이러한 단점을 보완하여 고급 언어가 저급 언어와 비슷한 성능을 달성할 수 있도록 해줍니다. Triton 커널 자체는 일반적인 ML 연구자에게 매우 명확하며 이는 유용성에 매우 중요합니다. Triton은 SM에서 메모리 통합, 공유 메모리 관리 및 스케줄링을 자동화합니다. Triton은 요소별 행렬 곱셈에 특별히 유용하지는 않지만 행렬 곱셈은 이미 매우 효율적으로 수행될 수 있습니다. Triton은 비용이 많이 드는 지점별 작업과 복잡한 작업의 오버헤드를 줄이는 데 유용합니다.

OpenAI Triton은 현재 공식적으로 NVIDIA GPU만 지원하지만 가까운 시일 내에 다른 여러 하드웨어 공급업체를 지원하도록 변경될 예정입니다. 다른 하드웨어 가속기는 Triton의 LLVM IR에 직접 통합될 수 있으므로 새 하드웨어용 AI 컴파일러 스택을 구축하는 시간이 크게 단축됩니다.

Nvidia의 거대한 소프트웨어 시스템은 통찰력이 부족하고 ML 하드웨어 및 소프트웨어의 큰 이점을 활용할 수 없으므로 기계 학습의 기본 컴파일러가 되지 못합니다. OpenAI와 Meta가 다른 하드웨어로 이식 가능한 소프트웨어 스택을 만들 수 있도록 하는 유용성에 대한 초점이 부족합니다.

원본 링크: https://www.semianalytic.com/p/nvidiaopenaitritonpytorch​

위 내용은 TensorFlow처럼 NVIDIA의 CUDA 독점도 깨질까요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!