CPU 및 GPU 기능에 대한 소화 가능한 상위 수준 개요

The Die에서 일어나는 일에 대한 이해하기 쉬운 상위 수준 개요

이 기사에서는 GPU가 그래픽, 신경망 및 딥 러닝 작업에 적합하고 CPU가 다양한 순차적이고 복잡한 범용 컴퓨팅 작업에 적합한 이유를 이해하기 위해 몇 가지 기본적이고 낮은 수준의 세부 정보를 살펴보겠습니다. 이 게시물에 대해 조사하고 좀 더 세부적인 이해를 얻어야 하는 몇 가지 주제가 있었는데, 그 중 일부는 그냥 지나치면서 언급하겠습니다. 이는 CPU 및 GPU 처리의 절대 기본에만 집중하기 위해 의도적으로 수행되었습니다.

폰 노이만 아키텍처

이전 컴퓨터는 전용 장치였습니다. 하드웨어 회로와 논리 게이트는 특정 작업을 수행하도록 프로그래밍되었습니다. 새로운 작업을 수행해야 한다면 회로를 다시 배선해야 했습니다. "새로운 것"은 두 가지 다른 방정식에 대한 수학적 계산을 수행하는 것만큼 간단할 수 있습니다. 제2차 세계대전 동안 앨런 튜링(Alan Turing)은 에니그마(Enigma) 기계를 이기기 위해 프로그래밍 가능한 기계를 개발 중이었고 나중에 "튜링 머신(Turing Machine)" 논문을 출판했습니다. 비슷한 시기에 존 폰 노이만(John von Neumann)과 다른 연구자들도 근본적으로 제안하는 아이디어를 연구하고 있었습니다.

• 명령어와 데이터는 공유 메모리(내장 프로그램)에 저장해야 합니다.
• 처리 장치와 기억 장치는 분리되어야 합니다.
• 제어 장치는 처리 장치를 사용하여 계산을 수행하기 위해 메모리에서 데이터 및 명령을 읽는 작업을 담당합니다.

병목 현상

• 처리 병목 현상 - 처리 장치(물리적 논리 게이트)에는 한 번에 하나의 명령어와 해당 피연산자만 있을 수 있습니다. 명령어는 순차적으로 하나씩 실행됩니다. 수년에 걸쳐 프로세서를 더 작고, 더 빠른 클록 주기로 만들고, 코어 수를 늘리는 데 초점을 맞추고 개선해 왔습니다.
• 메모리 병목 현상 - 프로세서가 점점 더 빨라지면서 메모리와 처리 장치 간에 전송될 수 있는 데이터의 속도와 양이 병목 현상이 발생했습니다. 메모리는 CPU보다 몇 배 더 느립니다. 수년에 걸쳐 메모리 밀도를 높이고 더 작게 만드는 데 초점을 맞추고 개선해 왔습니다.

CPU

우리는 컴퓨터의 모든 것이 바이너리라는 것을 알고 있습니다. 문자열, 이미지, 비디오, 오디오, OS, 응용프로그램 등은 모두 1과 0으로 표현됩니다. CPU 아키텍처(RISC, CISC 등) 사양에는 CPU 제조업체가 준수해야 하는 명령어 세트(x86, x86-64, ARM 등)가 있으며 OS가 하드웨어와 인터페이스하는 데 사용할 수 있습니다.

데이터를 포함한 OS 및 응용 프로그램은 CPU에서 처리하기 위해 명령어 세트 및 바이너리 데이터로 변환됩니다. 칩 수준에서는 트랜지스터와 논리 게이트에서 처리가 수행됩니다. 두 개의 숫자를 추가하는 프로그램을 실행하면 추가("처리")가 프로세서의 논리 게이트에서 수행됩니다.

Von Neumann 아키텍처에 따른 CPU에서는 두 개의 숫자를 추가할 때 단일 추가 명령이 회로의 두 숫자에 대해 실행됩니다. 그 1000분의 1초 동안 처리 장치의 (실행) 코어에서는 추가 명령만 실행되었습니다! 이 세부 사항은 항상 나를 매료시켰습니다.

최신 CPU의 코어

위 다이어그램의 구성 요소는 자명합니다. 자세한 내용과 자세한 설명은 이 훌륭한 기사를 참조하세요. 최신 CPU에서는 단일 물리적 코어에 둘 이상의 정수 ALU, 부동 소수점 ALU 등이 포함될 수 있습니다. 다시 말하지만, 이러한 장치는 물리적 논리 게이트입니다.

GPU를 더 잘 이해하려면 CPU 코어의 '하드웨어 스레드'를 이해해야 합니다. 하드웨어 스레드는 CPU 클럭 주기마다 CPU 코어의 실행 단위로 수행될 수 있는 컴퓨팅 단위입니다 . 이는 코어에서 실행될 수 있는 가장 작은 작업 단위를 나타냅니다.

지시주기

위의 다이어그램은 CPU 명령 주기/머신 주기를 보여줍니다. 단일 명령어를 실행하기 위해 CPU가 수행하는 일련의 단계입니다(예: c=a+b).

• Fetch: 프로그램 카운터(CPU 코어의 특수 레지스터)는 어떤 명령어를 가져와야 하는지 추적합니다. 명령어를 가져와서 명령어 레지스터에 저장합니다. 간단한 작업의 경우 해당 데이터도 가져옵니다.

• 디코드: 연산자와 피연산자를 보기 위해 명령어가 디코드됩니다.

• 실행: 지정된 작업을 기반으로 적절한 처리 단위가 선택되고 실행됩니다.

• 메모리 액세스: 명령이 복잡하거나 추가 데이터가 필요한 경우(여러 요인으로 인해 발생할 수 있음) 실행 전에 메모리 액세스가 수행됩니다. (단순화를 위해 위 다이어그램에서는 무시되었습니다.) 복잡한 명령어의 경우 초기 데이터는 컴퓨팅 장치의 데이터 레지스터에서 사용할 수 있지만 명령어의 완전한 실행을 위해서는 L1 및 L2 캐시의 데이터 액세스가 필요합니다. 이는 컴퓨팅 장치가 실행되기 전에 약간의 대기 시간이 있을 수 있으며 하드웨어 스레드는 대기 시간 동안 컴퓨팅 장치를 계속 보유하고 있음을 의미합니다.

• 다시 쓰기: 실행으로 인해 출력이 생성되면(예: c=a+b) 출력이 레지스터/캐시/메모리에 다시 기록됩니다. (단순화를 위해 위 다이어그램이나 게시물의 뒷부분에서는 무시되었습니다.)

  
  

위 다이어그램에서는 t2에서만 계산이 수행됩니다. 나머지 시간에는 코어가 유휴 상태입니다(아무 작업도 수행하지 않습니다).

최신 CPU에는 본질적으로 클록 주기당 동시에 발생하는 단계(가져오기-디코딩-실행)를 활성화하는 HW 구성 요소가 있습니다.

이제 단일 하드웨어 스레드가 모든 클록 주기에서 계산을 수행할 수 있습니다. 이를 명령어 파이프라이닝이라고 합니다.

가져오기, 디코딩, 메모리 액세스 및 다시 쓰기는 CPU의 다른 구성 요소에 의해 수행됩니다. 더 좋은 표현이 없어서 "파이프라인 스레드"라고 부릅니다. 파이프라인 스레드는 명령 주기의 실행 단계에 있을 때 하드웨어 스레드가 됩니다.

보시다시피, t2에서 매 사이클마다 계산 출력을 얻습니다. 이전에는 3주기마다 한 번씩 컴퓨팅 출력을 얻었습니다. 파이프라이닝은 컴퓨팅 처리량을 향상시킵니다. 이는 Von Neumann Architecture에서 처리 병목 현상을 관리하는 기술 중 하나입니다. 비순차적 실행, 분기 예측, 추측 실행 등과 같은 다른 최적화도 있습니다.

하이퍼스레딩

이것이 결론을 내리고 GPU로 넘어가기 전에 CPU에 관해 논의하고 싶은 마지막 개념입니다. 클럭 속도가 증가함에 따라 프로세서도 더 빠르고 효율적이 되었습니다. 애플리케이션(명령어 세트) 복잡성이 증가함에 따라 CPU 컴퓨팅 코어는 충분히 활용되지 않았고 메모리 액세스를 기다리는 데 더 많은 시간을 소비했습니다.

따라서 메모리 병목 현상이 발생합니다. 컴퓨팅 장치는 메모리 액세스에 시간을 소비하고 유용한 작업을 수행하지 않습니다. 메모리는 CPU보다 몇 배 느리며 그 격차는 곧 줄어들지 않을 것입니다. 아이디어는 단일 CPU 코어의 일부 장치에서 메모리 대역폭을 늘리고 메모리 액세스를 기다리는 동안 컴퓨팅 장치를 활용할 수 있도록 데이터를 준비하는 것이었습니다.

하이퍼스레딩은 2002년 Intel이 Xeon 및 Pentium 4 프로세서에서 사용할 수 있게 되었습니다. 하이퍼스레딩 이전에는 코어당 하나의 하드웨어 스레드만 있었습니다. 하이퍼스레딩을 사용하면 코어당 2개의 하드웨어 스레드가 있습니다. 무슨 뜻이에요? 일부 레지스터, 프로그램 카운터, 페치 장치, 디코드 장치 등을 위한 이중 처리 회로

위 다이어그램은 하이퍼스레딩이 적용된 CPU 코어의 새로운 회로 요소를 보여줍니다. 이는 단일 물리적 코어가 운영 체제에 2개의 코어로 표시되는 방식입니다. 4코어 프로세서가 있고 하이퍼스레딩이 활성화된 경우 OS에서는 8코어로 표시됩니다 . L1 - L3 캐시 크기는 추가 레지스터를 수용하기 위해 증가합니다. 실행 단위는 공유됩니다.

a=b+c, d=e+f를 수행하는 프로세스 P1과 P2가 있다고 가정하면 HW 스레드 1과 2로 인해 단일 클록 주기에서 동시에 실행될 수 있습니다. 앞서 본 것처럼 단일 HW 스레드를 사용하면 불가능할 것입니다. 여기서는 처리 장치를 효율적으로 활용할 수 있도록 하드웨어 스레드를 추가하여 코어 내의 메모리 대역폭을 늘립니다. 이를 통해 컴퓨팅 동시성이 향상됩니다.

몇 가지 흥미로운 시나리오:

• CPU에는 정수 ALU가 하나만 있습니다. 하나의 HW 스레드 1 또는 HW 스레드 2는 한 클록 주기를 기다리고 다음 주기에서 계산을 진행해야 합니다.
• CPU에는 하나의 정수 ALU와 하나의 부동 소수점 ALU가 있습니다. HW 스레드 1과 HW 스레드 2는 각각 ALU와 FPU를 사용하여 동시에 추가를 수행할 수 있습니다.
• 사용 가능한 모든 ALU는 HW 스레드 1에서 활용되고 있습니다. HW 스레드 2는 ALU를 사용할 수 있을 때까지 기다려야 합니다. (위의 추가 예에는 적용되지 않지만 다른 지침에서는 발생할 수 있습니다).

전통적인 데스크탑/서버 컴퓨팅에서 CPU가 왜 그렇게 좋은가요?

• 높은 클럭 속도 - GPU 클럭 속도보다 높습니다. 이러한 빠른 속도와 명령 파이프라인을 결합한 CPU는 순차 작업에 매우 뛰어납니다. 대기 시간에 최적화되었습니다.
• 다양한 애플리케이션 및 컴퓨팅 요구 사항 - 개인용 컴퓨터와 서버에는 광범위한 애플리케이션 및 컴퓨팅 요구 사항이 있습니다. 이로 인해 복잡한 명령어 세트가 생성됩니다. CPU는 여러 가지 일을 잘해야 합니다.
• 멀티태스킹 및 다중 처리 - 컴퓨터에 너무 많은 앱이 있기 때문에 CPU 작업량에는 컨텍스트 전환이 필요합니다. 이를 지원하기 위해 캐싱 시스템과 메모리 액세스가 설정됩니다. 프로세스가 CPU 하드웨어 스레드에 예약되면 필요한 모든 데이터가 준비되고 계산 명령을 하나씩 빠르게 실행합니다.

CPU 단점

이 도움말을 확인하고 Colab 노트북 도 사용해 보세요. 행렬 곱셈이 병렬화 가능한 작업인 방법과 병렬 컴퓨팅 코어가 계산 속도를 높이는 방법을 보여줍니다.

• 순차 작업에는 매우 뛰어나지만 병렬 작업에는 좋지 않습니다.
• 복잡한 명령어 세트와 복잡한 메모리 액세스 패턴.
• CPU는 또한 컴퓨팅 외에도 컨텍스트 전환 및 제어 장치 활동에 많은 에너지를 소비합니다.

주요 시사점

• 명령 파이프라인은 컴퓨팅 처리량을 향상시킵니다.
• 메모리 대역폭을 늘리면 컴퓨팅 동시성이 향상됩니다.
• CPU는 순차적 작업에 적합합니다(대기 시간에 최적화됨). 사용할 수 없는(처리량에 최적화되지 않은) 많은 수의 컴퓨팅 장치와 하드웨어 스레드가 필요하므로 대규모 병렬 작업에는 적합하지 않습니다. CPU는 범용 컴퓨팅용으로 제작되었으며 복잡한 명령어 세트를 가지고 있기 때문에 이러한 기능을 사용할 수 없습니다.

GPU

컴퓨팅 성능이 향상됨에 따라 그래픽 처리에 대한 수요도 증가했습니다. UI 렌더링 및 게임과 같은 작업에는 병렬 작업이 필요하므로 회로 수준에서 수많은 ALU 및 FPU가 필요합니다. 순차 작업용으로 설계된 CPU는 이러한 병렬 작업 부하를 효과적으로 처리할 수 없습니다. 따라서 GPU는 그래픽 작업에서 병렬 처리에 대한 요구를 충족하기 위해 개발되었으며 나중에 딥 러닝 알고리즘을 가속화하는 데 채택할 수 있는 길을 열었습니다.

나는 다음을 강력히 추천합니다:

• 비디오 게임 렌더링과 관련된 병렬 작업을 설명하는 이 시청하세요.
• 변환기와 관련된 병렬 작업을 이해하려면 이 블로그 게시물을 읽으세요. CNN 및 RNN과 같은 다른 딥러닝 아키텍처도 있습니다. LLM이 전 세계를 장악하고 있기 때문에 변환기 작업에 필요한 행렬 곱셈의 병렬성에 대한 높은 수준의 이해는 이 게시물의 나머지 부분에 대한 좋은 맥락을 설정하는 데 도움이 될 것입니다. (나중에 트랜스포머를 완전히 이해하고 소형 GPT 모델의 트랜스포머 레이어에서 발생하는 일에 대한 소화 가능한 상위 수준 개요를 공유할 계획입니다.)

샘플 CPU 및 GPU 사양

코어, 하드웨어 스레드, 클럭 속도, 메모리 대역폭, CPU 및 GPU의 온칩 메모리는 크게 다릅니다. 예:

• Intel Xeon 8280 의 특징 :
  • 기본 2700MHz 및 터보에서 4000MHz
  • 28개 코어 및 56개 하드웨어 스레드
  • 전체 파이프라인 스레드: 896 - 56
  • L3 캐시: 38.5MB(모든 코어에서 공유) L2 캐시: 28.0MB(코어 간에 분배) L1 캐시: 1.375MB(코어 간에 분배)
  • 레지스터 크기는 공개적으로 제공되지 않습니다.
  • 최대 메모리: 1TB DDR4, 2933MHz, 6채널
  • 최대 메모리 대역폭: 131GB/s
  • 최고 FP64 성능 = 4.0GHz 2 AVX-512 장치 클록 주기당 AVX-512 장치당 8개 작업 * 28개 코어 = ~2.8 TFLOP [다음을 사용하여 파생됨: 최고 FP64 성능 = (최대 터보 주파수) (AVX-512 장치 수) ( 클록 사이클당 AVX-512 장치당 작업) * (코어 수)]

    • 범용 컴퓨팅의 최고 성능을 얻는 것은 매우 주관적이므로 이 숫자는 GPU와의 비교에 사용됩니다. 이 숫자는 이론적 최대 제한이며, 이는 FP64 회로가 최대한 활용되고 있음을 의미합니다.

      
      

• 엔비디아 A100 80GB SXM 의 특징 :
  • 기본 1065MHz 및 터보에서 1410MHz
  • SM 108개, SM당 64개의 FP32 CUDA 코어(SP라고도 함), SM당 4개의 FP64 Tensor 코어, SM당 68개의 하드웨어 스레드(64 + 4)
    • GPU당 전체: 6912 64 FP32 CUDA 코어, 432 FP 64 Tensor 코어, 7344(6912 + 432) 하드웨어 스레드
  • SM당 파이프라인 스레드: 2048 - 68 = SM당 1980
    • GPU당 전체 파이프라인 스레드: (2048 x 108) - (68 x 108) = 21184 - 7344 = 13840
    • 참조: cudaLimitDevRuntimePendingLaunchCount
  • L2 캐시: 40MB(모든 SM 간에 공유) L1 캐시: 총 20.3MB(SM당 192KB)
  • 레지스터 크기: 27.8MB(SM당 256KB)
  • 최대 GPU 메인 메모리: 80GB HBM2e, 1512MHz
  • 최대 GPU 메인 메모리 대역폭: 2.39TB/s
  • 최고 FP64 성능 = 19.5 TFLOP(모든 FP64 Tensor 코어만 사용). CUDA 코어에서 FP64만 사용하는 경우 9.7 TFLOP의 더 낮은 값입니다. 이 숫자는 이론적 최대 제한이며, 이는 FP64 회로가 최대한 활용되고 있음을 의미합니다.

최신 GPU의 핵심

CPU에서 본 용어가 항상 GPU로 직접 번역되는 것은 아닙니다. 여기서는 구성요소와 핵심 NVIDIA A100 GPU를 살펴보겠습니다. 이 기사를 조사하면서 제가 놀랐던 점 중 하나는 CPU 공급업체가 코어의 실행 단위에서 사용할 수 있는 ALU, FPU 등의 수를 공개하지 않는다는 것입니다. NVIDIA는 코어 수에 대해 매우 투명하며 CUDA 프레임워크는 회로 수준에서 완전한 유연성과 액세스를 제공합니다.

위의 GPU 다이어그램에서 우리는 L3 캐시가 없고, 더 작은 L2 캐시가 있고, 작지만 훨씬 더 많은 제어 장치 및 L1 캐시와 많은 수의 처리 장치가 있음을 알 수 있습니다.

다음은 초기 이해를 위한 위 다이어그램의 GPU 구성 요소와 그에 상응하는 CPU입니다. 저는 CUDA 프로그래밍을 해본 적이 없기 때문에 이를 CPU와 비교하는 것이 초기 이해에 도움이 됩니다. CUDA 프로그래머는 이것을 매우 잘 이해하고 있습니다.

• 다중 스트리밍 다중 프로세서 <> 다중 코어 CPU
• 스트리밍 멀티프로세서(SM) <> CPU 코어
• 스트리밍 프로세서(SP)/CUDA Core <> CPU Core 실행 단위의 ALU/FPU
• Tensor Core(단일 명령어에서 4x4 FP64 작업 수행 가능) <> 최신 CPU 코어의 SIMD 실행 장치(예: AVX-512)
• 하드웨어 스레드(단일 클록 주기에서 CUDA 또는 Tensor 코어에서 계산 수행) <> 하드웨어 스레드(단일 클록 주기에서 실행 단위(ALU, FPU 등)에서 계산 수행)
• HBM / VRAM / DRAM / GPU 메모리 <> RAM
• 온칩 메모리/SRAM(레지스터, L1, L2 캐시) <> 온칩 메모리/SRAM(레지스터, L1, L2, L3 캐시)
  • 참고: SM의 레지스터는 코어의 레지스터보다 훨씬 큽니다. 스레드 수가 많기 때문입니다. CPU의 하이퍼스레딩에서는 레지스터 수가 증가했지만 계산 단위는 증가하지 않았다는 점을 기억하십시오. 여기에서도 같은 원리가 있습니다.

데이터 및 메모리 대역폭 이동

그래픽 및 딥러닝 작업에는 SIM(D/T) [단일 명령 다중 데이터/스레드] 유형의 실행이 필요합니다. 즉, 단일 명령어에 대해 많은 양의 데이터를 읽고 작업하는 것입니다.

우리는 CPU의 명령 파이프라인과 하이퍼스레딩에 대해 논의했으며 GPU에도 기능이 있습니다. 구현 및 작동 방식은 약간 다르지만 원칙은 동일합니다.

CPU와 달리 GPU(CUDA를 통해)는 파이프라인 스레드에 대한 직접 액세스를 제공합니다(메모리에서 데이터를 가져오고 메모리 대역폭 활용). GPU 스케줄러는 먼저 계산 단위(연관된 공유 L1 캐시 및 계산 피연산자 저장을 위한 레지스터 포함)를 채우고 데이터를 레지스터 및 HBM으로 가져오는 "파이프라인 스레드"를 채우는 방식으로 작동합니다. 다시 한번 말씀드리지만, CPU 앱 프로그래머는 이에 대해 생각하지 않으며 "파이프라인 스레드" 및 코어당 컴퓨팅 단위 수에 대한 사양은 게시되지 않습니다. Nvidia는 이를 게시할 뿐만 아니라 프로그래머에게 완전한 제어권을 제공합니다.

이에 대해서는 CUDA 프로그래밍 모델 및 모델 제공 최적화 기술의 "배칭"에 대한 전용 게시물에서 자세히 설명하겠습니다. 여기서 이것이 얼마나 유익한지 확인할 수 있습니다.

위 다이어그램은 CPU 및 GPU 코어의 하드웨어 스레드 실행을 보여줍니다. 앞서 CPU 파이프라인에서 논의한 "메모리 액세스" 섹션을 참조하세요. 이 다이어그램은 그것을 보여줍니다. CPU의 복잡한 메모리 관리로 인해 이 대기 시간이 L1 캐시에서 레지스터로 데이터를 가져올 수 있을 만큼 충분히 작아집니다(몇 클럭 주기). L3 또는 메인 메모리에서 데이터를 가져와야 하는 경우 데이터가 이미 레지스터에 있는 다른 스레드(하이퍼스레딩 섹션에서 본)가 실행 단위를 제어합니다.

GPU에서는 초과 구독(많은 수의 파이프라인 스레드 및 레지스터) 및 간단한 명령 세트로 인해 실행 대기 중인 레지스터에서 이미 많은 양의 데이터를 사용할 수 있습니다. 실행을 기다리는 이러한 파이프라인 스레드는 하드웨어 스레드가 되며 GPU의 파이프라인 스레드가 가볍기 때문에 모든 클록 주기만큼 자주 실행을 수행합니다.

대역폭, 컴퓨팅 강도 및 지연 시간

오버골은 무엇인가요?

• 매 클록 주기마다 하드웨어 리소스(컴퓨팅 장치)를 완전히 활용하여 GPU를 최대한 활용하세요.
• 컴퓨팅 단위를 계속 사용하려면 충분한 데이터를 제공해야 합니다.

이것이 더 작은 행렬의 행렬 곱셈 지연 시간이 CPU와 GPU에서 거의 동일한 주된 이유입니다. 사용해 보세요 .

작업은 충분히 병렬적이어야 하며 데이터는 컴퓨팅 FLOP 및 메모리 대역폭을 포화시킬 만큼 커야 합니다. 단일 작업이 충분히 크지 않은 경우 하드웨어를 완전히 활용하려면 메모리를 포화시키고 계산하기 위해 여러 작업을 압축해야 합니다.

컴퓨팅 강도 = FLOP / 대역폭 . 즉, 초당 메모리가 제공할 수 있는 데이터 양에 대한 초당 컴퓨팅 단위로 수행할 수 있는 작업량의 비율입니다.

위 다이어그램에서는 대기 시간이 길고 메모리 대역폭이 낮을수록 컴퓨팅 강도가 증가하는 것을 볼 수 있습니다. 우리는 컴퓨팅이 완전히 활용될 수 있도록 이 숫자를 가능한 한 작게 만들고 싶습니다. 이를 위해서는 컴퓨팅이 빠르게 이루어질 수 있도록 L1/레지스터에 최대한 많은 데이터를 보관해야 합니다. HBM에서 단일 데이터를 가져오는 경우 가치를 높이기 위해 단일 데이터에 대해 100개의 작업을 수행하는 작업은 거의 없습니다. 100개의 작업을 수행하지 않으면 컴퓨팅 단위가 유휴 상태가 됩니다. GPU의 많은 수의 스레드와 레지스터가 작동하는 곳입니다. L1/레지스터에 최대한 많은 데이터를 보관하여 컴퓨팅 강도를 낮게 유지하고 병렬 코어를 계속 사용합니다.

CUDA 코어는 1x1 FP64 MMA를 하나만 수행할 수 있는 반면 Tensor 코어는 클록 주기당 4x4 FP64 MMA 명령을 수행할 수 있기 때문에 CUDA와 Tensor 코어 사이에는 컴퓨팅 강도에 4배의 차이가 있습니다.

주요 시사점

많은 수의 컴퓨팅 유닛(CUDA 및 Tensor 코어), 많은 수의 스레드 및 레지스터(구독을 통해), 명령 세트 감소, L3 캐시 없음, HBM(SRAM), 단순하고 높은 처리량의 메모리 액세스 패턴(CPU와 비교 - 컨텍스트 전환) , 멀티 레이어 캐싱, 메모리 페이징, TLB 등)은 병렬 컴퓨팅(그래픽 렌더링, 딥러닝 등)에서 GPU를 CPU보다 훨씬 더 좋게 만드는 원리입니다.

GPU를 넘어서

GPU는 그래픽 처리 작업을 처리하기 위해 처음 만들어졌습니다. AI 연구자들은 CUDA와 CUDA 코어를 통한 강력한 병렬 처리에 대한 직접 액세스를 활용하기 시작했습니다. NVIDIA GPU에는 텍스처 처리, 레이 트레이싱, 래스터, 다형성 엔진 등이 있습니다(그래픽별 명령어 세트라고 가정해 보겠습니다). AI 도입이 늘어나면서 딥러닝 전용인 4x4 행렬 계산(MMA 명령어)에 능한 텐서 코어가 추가되고 있다.

NVIDIA는 2017년부터 각 아키텍처의 Tensor 코어 수를 늘려 왔습니다. 그러나 이러한 GPU는 그래픽 처리에도 능숙합니다. GPU에서는 명령어 세트와 복잡성이 훨씬 적지만 딥 러닝(특히 Transformer Architecture) 전용은 아닙니다.

변환기 아키텍처를 위한 소프트웨어 계층 최적화(주의 계층의 메모리 액세스 패턴에 대한 기계적 공감) 인 FlashAttention 2는 작업 속도를 2배 향상시킵니다.

CPU 및 GPU에 대한 심층적인 첫 번째 원칙 기반 이해를 통해 우리는 변압기 가속기의 필요성을 이해할 수 있습니다. 전용 칩(변압기 작동 전용 회로), 병렬 처리를 위한 많은 수의 컴퓨팅 유닛, 축소된 명령어 세트, L1/L2 캐시, HBM을 대체하는 대규모 DRAM(레지스터), 트랜스포머 아키텍처의 메모리 액세스 패턴에 최적화된 메모리 장치. 결국 LLM은 인간(웹과 모바일 이후)의 새로운 동반자이며 효율성과 성능을 위해 전용 칩이 필요합니다.

일부 AI 가속기:

• AWS 인페렌시아
• 구글 TPU
• 세레브라 CS3

변압기 가속기:

• 그로크 LPU
• 실리콘에 에칭된 트랜스포머

FPGA 기반 변압기 가속기:

• 아크로닉스

참고자료:

• https://en.wikipedia.org/wiki/Von_Neumann_architecture
• https://chsasank.com/llm-system-design.html
• https://www.redhat.com/sysadmin/cpu-comComponents-functionity
• https://docs.wixstatic.com/ugd/56440f_e458602dcb0c4af9aaeb7fdaa34bb2b4.pdf
• https://www.nand2tetris.org/course
• https://cpu.land/
• https://en.wikipedia.org/wiki/Hyper-threading
• 비디오 게임 그래픽은 어떻게 작동하나요? -
• CPU vs GPU vs TPU vs DPU vs QPU - https://www.youtube.com/watch?v=r5NQecwZs1A
• GPU 컴퓨팅 작동 방식 | GTC 2021 | 스티븐 존스 - https://www.nvidia.com/en-us/on-demand/session/gtcspring21-s31151/
• 컴퓨팅 강도 - https://www.linkedin.com/pulse/threads-tensor-cores-beyond-unveiling-dynamics-gpu-memory-florit-smg2c/
• CUDA 프로그래밍 작동 방식 | GTC 2022년 가을 | 스티븐 존스 - https://www.nvidia.com/en-us/on-demand/session/gtcfall22-a41101/
• 신경망에 GPU를 사용하는 이유는 무엇입니까? - https://www.youtube.com/watch?v=GRRMi7UfZHg
• CUDA 하드웨어 | 톰 너칼라 | 테일러 대학 강의 - https://www.youtube.com/watch?v=kUqkOAU84bA
• https://ashanpriyadarshana.medium.com/cuda-gpu-memory-architecture-8c3ac644bd64
• https://colab.research.google.com/drive/1nw34aks9SdMwHXl9Gf5T9GPxRB9BIIyr
• https://developer.nvidia.com/blog/cuda-refresher-reviewing-the-origins-of-gpu-computing/