YouTubeCaleb Writes Code·2026년 10월 30일·0

CUDA is hard..

Quick Summary

CUDA가 어려운 이유는 GPU의 메모리 계층과 수많은 스레드의 작업 배분을 함께 최적화하면서, 이를 여러 하드웨어와 응용 도구가 사용하는 플랫폼으로 연결해야 하기 때문이다.

영상 보기

클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.

원본 열기

🖼️ 인포그래픽

CUDA is hard.. 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

CUDA is hard..의 핵심 내용을 4단계로 요약한 인포그래픽
CUDA is hard.. 핵심 내용을 4단계로 압축한 4컷 인포그래픽

💡 한 줄 결론

CUDA가 어려운 이유는 GPU의 메모리 계층과 수많은 스레드의 작업 배분을 함께 최적화하면서, 이를 여러 하드웨어와 응용 도구가 사용하는 플랫폼으로 연결해야 하기 때문이다.

📌 핵심 요점

  1. 모델 실행은 데이터 이동에서 시작한다. SSD에 저장된 가중치를 CPU에서 동작하는 추론 엔진이 GPU로 옮기며, GPU 내부에서도 HBM·캐시·레지스터 등 여러 메모리 계층을 거친다.
  2. 실행 지점에 가까워질수록 메모리 용량이 작아지는 것은 하드웨어 자원 배분의 결과다. 스레드가 처리할 수 있는 연산량에 맞춰 저장 공간을 배치하고, 남는 트랜지스터를 다른 저장 공간에 활용한다는 설명이다.
  3. 병렬화만으로 성능이 완성되지는 않는다. 큰 연산을 수많은 스레드로 나누는 동시에, 제한된 메모리를 어떻게 공유하고 데이터를 공급할지 결정해야 한다.
  4. CUDA 커널은 작업 분할과 메모리 배분에 관한 구체적인 구현이다. 연산과 응용 분야마다 요구가 달라 다양한 커널과 cuBLAS·cuDNN 같은 라이브러리가 발전한다.
  5. CUDA는 라이브러리 모음을 넘어 컴파일러·런타임·드라이버와 PTX를 포함하는 플랫폼이다. GPU 세대 간 코드 활용을 지원하고, PyTorch·vLLM 같은 도구가 GPU를 활용하는 기반을 제공한다.

🧩 배경과 문제 정의

영상은 ‘CUDA는 어디서부터 이해해야 할지 막막하다’는 문제에서 출발한다. 익숙한 SSD·CPU·GPU 사이의 데이터 이동을 먼저 설명하고, 같은 관점을 GPU 내부의 메모리 계층으로 확장한다. 중심 질문은 거대한 연산을 수많은 스레드에 나누면서 제한된 메모리를 어떻게 활용할 것인가다. 이후 커널과 라이브러리, 외부 개발자 생태계, 다중 GPU 활용, 컴파일 구조로 시야를 넓혀 CUDA가 하드웨어와 소프트웨어를 연결하는 플랫폼임을 설명한다. 중간에는 AI 에이전트 기반 3D 제작 도구의 후원 시연이 포함된다.

🕒 시간순 섹션별 상세정리

1. 익숙한 컴퓨터 메모리에서 GPU 내부로

  • 인터넷에서 내려받은 모델은 SSD에 저장되고, 실행 시 CPU에서 동작하는 추론 엔진이 가중치를 GPU로 옮긴다. 영상은 이 흐름을 GPU 내부 메모리 계층을 이해하는 출발점으로 삼는다. [00:37]
  • SSD에서 HBM을 거쳐 실제 연산을 수행하는 스레드 쪽으로 갈수록 이용 가능한 메모리 용량이 작아진다는 점을 제시한다. 왜 작업이 이루어지는 곳에 가장 큰 메모리를 두지 않는지가 첫 질문이다. [01:10]
  • Steven Jones는 스레드의 저장 공간을 처리 가능한 연산량에 맞춰 설계한다고 보여준다. 활용할 수 없는 저장 공간을 과도하게 주기보다 트랜지스터를 다른 저장 공간에 쓰는 것이 낫다는 취지다. [01:32]

2. 행렬곱을 나누는 일과 데이터를 공급하는 일

  • HBM에 있는 가중치는 캐시 쪽으로 이동하고, 스레드는 필요한 데이터를 사용해 계산한다. 대규모 언어 모델의 순전파에 포함되는 행렬곱을 약 1억 회 연산의 예로 든다. [02:00]
  • 이론적으로 매우 짧은 시간에 처리하려면 작업을 작은 실행 단위로 나눠 수천 개 스레드가 병렬로 수행하게 해야 한다. 동시에 HBM에서 데이터를 가져오고 여러 스레드가 사용하는 메모리 공간을 효율적으로 배분해야 한다. [02:43]
  • 영상은 L2 50MB, SM 132개, SM별 L1 캐시·공유 메모리와 레지스터 파일을 예시로 제시한다. SM은 많은 스레드를 수용해 큰 작업을 작은 병렬 작업으로 실행하는 하드웨어 단위로 드러난다. [03:34]

3. CUDA 커널이 결정하는 작업 분할과 메모리 배분

  • HBM 80GB부터 더 작은 캐시·레지스터·공유 메모리로 이어지는 구조 위에서, 하나의 SM에 2,000개가 넘는 스레드가 동시에 존재할 수 있다고 보여준다. 제한된 메모리를 많은 스레드가 활용하도록 설계하는 것이 핵심 난제다. [04:20]
  • 커널마다 연산을 스레드에 나누는 방식과 메모리를 할당하는 방식이 달라질 수 있다. 영상은 132개 SM, 워프당 32개 스레드와 1.5GHz 클록 등을 이용해 약 1억 회 연산을 약 3,000사이클, 2마이크로초 미만으로 계산하는 이론적 예를 제시한다. [05:01]
  • 작업 분할에는 모든 경우에 통하는 한 가지 답이 없으므로 다양한 커널이 필요하다. 머신러닝에서는 토큰 생성 속도를 가능한 한 끌어올리려는 요구가 이러한 최적화를 밀어붙인다고 보여준다. [05:34]

4. 후원 구간의 AI 에이전트 기반 3D 제작 시연

  • 후원 구간에서는 Tripo의 3D 생성과 AI 에이전트를 결합하는 Char Crew를 보여준다. 생성된 캐릭터를 애니메이션이나 게임에 쓰려면 리깅과 표정 설정 등 추가 작업이 필요하며, 에이전트가 Blender를 조작해 이를 자동화하는 흐름을 보여준다. [06:20]
  • 사진을 바탕으로 초기 3D 모델을 생성한 뒤, 에이전트가 Blender에서 캐릭터 설정을 진행한다. 평가 기준으로 원본 모델의 형상·텍스처 품질, 리깅·표정의 동작, 사용 가능한 결과를 얻기 위한 수동 개입량을 제시한다. [07:07]
  • 생성 모델과 에이전트의 결합으로 기존 3D 제작 과정 중 얼마나 많은 부분을 자동화할 수 있는지 질문한다. 프로젝트와 서비스 링크 및 프로모션을 안내하며 후원 구간을 마친다. [07:47]

5. 산업별 라이브러리와 외부 생태계의 성장

  • GPU 가속 수요는 AI 외에도 그래픽스 등 여러 분야에 존재한다. 서로 다른 작업에 맞춘 커널 라이브러리의 예로 선형대수·행렬곱용 cuBLAS와 딥러닝용 cuDNN을 보여준다. [08:36]
  • 영상은 2012년 두 GTX 580을 사용한 신경망 학습을 발전 과정의 사례로 언급하고, Triton과 FlashAttention은 CUDA와 함께 쓰이거나 그 위에 구축되지만 CUDA 내장 라이브러리 자체는 아니라고 구분한다. [09:14]
  • Steven Jones는 외부 개발자가 만든 라이브러리와 프레임워크가 플랫폼의 중요한 부분이라고 강조한다. 여러 분야가 같은 기능을 반복 구현하면 이를 핵심 계층으로 가져와 중복 작업을 줄일 수 있으며, CUDA는 산업의 변화에 맞춰 기능의 위치와 범위를 조정해야 한다고 보여준다. [10:27]

6. 단일 칩을 넘어 인프라와 실행 플랫폼으로

  • 영상은 2020년 이후 모델 규모 확대와 함께 단일 GPU에 모델을 담기 어려워지는 흐름을 보여준다. 이에 따라 CUDA가 NVLink 등 관련 구성 요소와의 상호작용도 고려해야 한다고 드러낸다. [10:47]
  • 최적화 범위는 칩 내부 성능에서 인프라, 데이터센터의 GPU 배치, 모델 구조와 응용 계층의 사용 방식까지 넓어진다. CUDA는 서로 다른 세대의 NVIDIA GPU에서 코드를 활용하도록 지원하는 역할도 맡는다. [11:41]
  • CUDA는 커널을 GPU 기계어로 변환하는 컴파일 체계, 메모리와 커널 실행을 관리하는 런타임, 하드웨어와 소통하는 드라이버를 포함하는 플랫폼으로 압축된다. [12:03]

7. PTX를 통한 변환과 응용 도구의 연결

  • CUDA의 컴파일 과정을 중간 표현인 PTX와 GPU 아키텍처별 기계어로 나눠 보여준다. PTX가 추가로 변환되는 구조를 통해 Ampere·Hopper·Blackwell 등 여러 아키텍처에서 호환되는 커널을 활용한다고 보여준다. [12:37]
  • CUDA는 PyTorch·vLLM 같은 응용 도구가 그 위에 구축되어 GPU로 작업을 가속하도록 하는 연결 지점으로 압축된다. [12:52]
  • Steven Jones에게 감사를 전하고, 전체 인터뷰를 별도 영상으로 공개할 예정이라고 안내하며 마무리한다. [13:02]

🧾 결론

  • CUDA를 이해하는 출발점은 문법보다 데이터가 어디에 저장되고 어떤 경로로 연산 지점까지 이동하는지 파악하는 데 있다.
  • 커널 최적화의 핵심은 작업 분할과 메모리 사용을 함께 설계하는 것이다. 영상은 모든 작업에 통하는 단일한 분할 방식이 없다고 강조한다.
  • CUDA의 발전은 하드웨어 변화와 외부 개발자 생태계의 요구가 맞물리는 과정이다. 여러 분야에서 반복되는 기능을 핵심 계층으로 가져오는 판단도 플랫폼 설계에 포함된다.
  • 영상의 약 2마이크로초 계산은 이론적 예시다. 이를 실제 모델 추론 시간이나 특정 커널의 측정 성능으로 받아들이면 안 된다.

📈 투자·시사 포인트

  • GPU 경쟁력을 살필 때 연산 성능과 메모리 용량에 더해 컴파일러·런타임·라이브러리·응용 도구의 연결을 함께 검토필요가 있다. 영상이 설명하는 CUDA의 역할은 이 연결 전반에 걸쳐 있다.
  • 외부 개발자가 만든 라이브러리와 프레임워크는 플랫폼 활용 범위를 넓힌다. 생태계의 기여와 반복되는 요구를 핵심 기능으로 반영하는 능력이 관찰 포인트다.
  • 모델이 단일 GPU에 들어가기 어려워지면서 최적화의 범위도 통신·연결 구성과 데이터센터의 GPU 배치까지 확장된다. 개별 칩 사양만으로 실제 활용 성능을 판단하기 어렵다는 시사점이다.
  • 영상은 NVIDIA의 기술 플랫폼을 설명하지만 경쟁 제품과의 비교, 가격, 매출 또는 수익성 자료는 제공하지 않는다. 기술적 설명만으로 기업 가치나 투자 수익을 판단할 근거는 부족하다.

⚠️ 불확실하거나 확인이 필요한 부분

  • 약 1억 회 연산을 2마이크로초 미만에 처리한다는 계산은 영상에서도 이론값으로 제시된다. 연산 정밀도, 명령당 처리량, 데이터 이동과 실행 비용 등의 조건이 충분히 명시되지 않아 실측 성능으로 일반화하기 어렵다.
  • HBM 80GB, L2 50MB, SM 132개 등은 영상 속 예시 구성이다. 특정 GPU 모델이 명시되지 않으므로 모든 CUDA 지원 GPU의 공통 사양으로 해석하면 안 된다.
  • 앞부분의 SM당 256KB는 L1 캐시와 공유 메모리를 함께 설명하고, 뒷부분에서는 공유 메모리를 228KB로 제시한다. 두 수치가 가리키는 범위와 실제 사용 조건을 구분필요가 있다.
  • 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
  • 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
  • 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

  • 모델 가중치가 SSD에서 GPU로 이동한 뒤 HBM·캐시·스레드의 연산으로 이어지는 경로를 도식화하고, 각 메모리 공간의 역할을 구분한다.
  • 영상의 하드웨어 수치를 예시 사양으로 기록하고, 실제 사용할 GPU의 메모리 구성과 SM 수를 별도로 확인한다.
  • 행렬곱 작업 하나를 골라 스레드별 작업 분할과 메모리 사용 방식을 정리한 뒤, 실행 시간을 측정해 영상의 이론 계산과 구분한다.
  • cuBLAS·cuDNN, Triton·FlashAttention, PyTorch·vLLM이 영상에서 각각 어떤 역할로 소개되는지 정리한다.

❓ 열린 질문

  • 특정 커널에서 성능을 가장 크게 제한하는 것은 연산 처리량인가, 데이터 공급인가, 아니면 제한된 메모리 공간의 배분인가?
  • 여러 분야에서 반복되는 최적화를 CUDA 핵심 기능으로 편입할 기준은 무엇이며, 어떤 기능은 외부 생태계에 남겨두는 편이 유리할까?
  • 단일 GPU를 넘어설 때 커널 내부 최적화와 GPU 간 통신·데이터센터 배치 최적화의 중요도는 어떻게 달라질까?

관련 문서

공통 태그와 주제 흐름을 기준으로 같이 보면 좋은 문서를 이어서 제안합니다.