6 of 19

ML Framework

AI Ecosystem의

OS이자 (AI 가속기를 추상화된 computing resource로 제공)
Programming Language이자 (Model을 쉽게 작성할 수 있도록 API 제공)
Compiler (작성된 모델을 computing resource로 mapping)

다양한 기술적인 background가 혼재되어 있음!

머신러닝 프레임워크의 정의

파이토치(PyTorch), 텐서플로우(TensorFlow), 잭스(JAX) 등을 포함.
AI 에코시스템에서 AI 가속기를 위한 운영체제 역할.
프로그램 언어 제공 및 모델 작성 기능 제공.

프로그램 언어적 성격

모델을 직접 작성하고 제공하는 기능 (예: 파이토치, 텐서플로우).

컴파일러 역할

단순히 AI 가속기에 매핑하는 것이 아니라, 트랜스포메이션 과정을 통해 하드웨어 타겟에 최적화.
다양한 기술의 융합을 통해 컴파일러 기능을 수행.

ML Framework 와 Computer Science의 연관성

머신러닝 프레임워크는 여러 컴퓨터 과학 기술 영역과 겹침.
프레임워크의 발전은 이전의 연구와 산업적 결과들의 집적체.
중요한 기술적 흐름들이 융합되어 현재의 프레임워크가 형성됨.

강의 중 질문 및 답변 정리

질문:�파이토치(PyTorch)의 경우, ML 컴파일러의 이름이 있을까요?

답변:

컴파일러의 정의: 컴파일러가 무엇인지를 먼저 정의해야 함.
PyTorch 1.x:

torch.jit.trace 등 컴파일러 유사 기능이 포함되어 있었음.
당시에는 컴파일러 기능이 프레임워크의 중심이 아니었음.

PyTorch 2.0:

Dynamo: torch.jit.trace를 대체하는 컴파일러 유사 기능.
Inductor: 더욱 본격적인 컴파일러 역할을 수행.
Triton: 도메인 특화 언어로 컴파일러 기능에 포함.

따라서, PyTorch 2.0에서는 Dynamo과 Inductor가 주요 ML 컴파일러로 작동하며, Triton도 도메인 특화 언어를 통해 컴파일러 기능을 지원함.

7 of 19

오늘 다룰 topic들

ML Framework: background

Heterogeneous computing with GPU

Graphics

OpenGL (1992), DirectX (1995)

GPGPU

HLSL (2002), CUDA (2007), OpenCL (2009), HSA (2011)

Supercomputing

Fast multiplication - BLAS (1979), cuBLAS (2017), cuTLASS (2019)
Distributed programming - MPI (1992)

ML compiler

XLA (Google), TensorRT (Nvidia), TVM (OctoAI), Glow (Meta), etc

Numerical Computing for Data Science

Matlab (1970s), R (1993), NumPy (2005)

Design space

Two (or three) language problems
Eager vs. graph mode

Define-and-run and define-by-run

Interpretation vs. {just-in-time, ahead of time} compilation

Convergence on Pytorch

제가 정리해본 내용은 대략 이 정도인데요, 이 자료들을 한 장씩 넘겨 가면서 제가 생각하는 부분들을 공유해 드리려고 합니다. 우선 제가 전달하고 싶은 핵심 메시지는 “머신러닝 프레임워크란 게 그냥 갑자기 어디선가 뚝 떨어진 것이 아니라, 이전의 훌륭한 연구들과 산업적 성과가 축적되어 만들어진 결과물”이라는 점입니다. 그 역사와 과정을 하나씩 살펴보면, 굉장히 중요한 기술적 흐름들이 있었고, 결국 이런 흐름들이 합쳐져서 우리가 지금 쓰고 있는 머신러닝 프레임워크가 되었죠. 이 주제들을 한 장씩 보면서 같이 이야기 나누면 좋겠습니다.

그리고 제가 토픽을 하나씩 다룰 때마다 간단한 퀴즈나 질문을 드릴 텐데, 궁금하신 점이 있으시면 언제든 말씀해 주세요. 예를 들어 방금 “파이토치에 ML 컴파일러라는 이름이 있나요?”라는 질문이 나왔는데, 저도 좋은 질문이라고 생각합니다. 먼저 ‘컴파일러’가 정확히 뭘 의미하는지를 짚어봐야 하는데, 사실 파이토치 1.0에도 컴파일러와 비슷한 기능이 어느 정도 들어 있었습니다. 예를 들어, JIT 트레이스(JIT trace)로 모델을 추적하는 기능도 넓게 보면 일종의 컴파일러 역할을 한다고 볼 수 있으니까요. 다만 파이토치 1.x 시리즈는 주로 ‘이거(Eager) 모드’를 중심에 두고 있어서, ML 컴파일러 기능이 크게 부각되지 않았던 것 같습니다.

그런데 파이토치 2.0이 되면서는 이 부분이 크게 달라졌습니다. 파이토치 2.0에는 컴파일러라고 부를 수 있는 요소가 몇 가지 들어갔는데요, 먼저 기존 JIT 트레이스를 대체하는 ‘다이나모(Dynamo)’가 있고, 이 다이나모도 일종의 컴파일러 역할을 합니다. 그리고 더 본격적인 컴파일러라고 할 수 있는 ‘인덕터(Inductor)’도 추가되었죠. 게다가 그 사이에는 ‘트리톤(Triton)’이라는 도메인 특화 언어(DSL)와 그 컴파일러가 포함되어 있어서, 결국 이 모든 요소들이 합쳐져 파이토치 2.0에서의 컴파일러 스택을 이루게 됩니다.

8 of 19

Heterogeneous Computing with GPU

CPU와 GPU를 함께 활용, 더 빠르게 계산할 수 있도록 해주는 시스템

일반적으로 CPU가 특정 계산을 GPU에게 offloading함으로써 성능 향상

시작점은 GUI, 컴퓨터 게임 등을 위한 Graphics

OpenGL (1992) - 실리콘 그래픽스가 개발한 Graphics API
DirectX (1995) - Microsoft가 개발한 Graphics API

Windows PC의 보급과 함께 실질적인 업계 표준으로 자리잡음
Nvidia, ATI (2006년 AMD와 합병)등이 성장하게된 동력

2000년대 초 shader programming의 등장

Graphics 개발자가 high-level programming 언어를 사용, GPU를 programming하기 시작

DirectX 8부터 시작. DirectX 9에서 HLSL 정의

Nvidia의 GeForce 3 (2001) : shader programmable한 최초의 GPU

2007년 CUDA와 함께 GPGPU의 등장

Nvidia가 개발한 GPU를 위한 일반적인 parallel programming model
초기에는 High-Performance Computing (HPC) 시장을 타겟으로 함
Deep learning의 등장과 함께 AI 가속기를 위한 programming model로 진화
이후 Apple이 주도한 OpenCL (2008), AMD/ARM이 주도한 HSA (2011)도 등장

1. 개요

Heterogeneous Computing은 CPU와 GPU를 함께 활용하여 더 빠르게 계산할 수 있도록 해주는 시스템입니다.�이 개념은 일반적으로 CPU가 수행하던 계산 중 일부를 GPU에게 offloading하여 성능을 향상시키는 방식입니다.�오늘날 머신러닝 프레임워크에서도 이 기술은 매우 중요한 배경으로 자리 잡고 있습니다.�머신러닝 프레임워크의 핵심은 단순히 모델을 기술하는 것뿐 아니라 GPU와 같은 AI 가속기를 효과적으로 활용하는 것이기 때문입니다.�특히, CPU와 AI 가속기를 잘 결합하여 사용하는 것을 현대에는 Heterogeneous Computing이라고 부릅니다.

2. Heterogeneous Computing의 역사와 발전

이 기술은 **그래픽스(Graphics)**에서 시작되었다고 볼 수 있습니다. GPU가 초기에는 그래픽 처리에만 활용되었으나, 이후 범용 계산으로 확장되었습니다.

1992년 OpenGL�OpenGL은 실리콘 그래픽스에서 개발한 그래픽스 API로, 프로그래머가 그래픽스 연산을 소프트웨어적으로 프로그래밍할 수 있는 시작점이었습니다.�그러나 OpenGL 자체는 상업적으로 큰 성공을 거두지는 못했습니다.
1995년 DirectX�마이크로소프트가 Windows PC 환경에서 개발한 그래픽스 API입니다.�DirectX는 GPU의 성능 향상과 함께 주요 표준으로 자리 잡았으며, NVIDIA와 ATI(현재 AMD)의 성장을 촉진시킨 중요한 계기가 되었습니다.

3. 2000년대 초: Shader Programming의 등장

2000년대 초에는 GPU 프로그래밍에 큰 변화를 가져온 Shader Programming이 등장했습니다.�이전에는 GPU가 픽스트 펑션(fixed function)만 수행할 수 있었지만, 이제 개발자가 GPU를 프로그래밍 가능한 디바이스로 활용할 수 있게 되었습니다.

2001년 NVIDIA GeForce 3�최초로 Shader Programming을 지원한 GPU로, 하드웨어적으로 셰이더 기능을 도입했습니다.
DirectX 8과 HLSL�Microsoft는 DirectX 8에서 High-Level Shading Language(HLSL)를 정의하여 개발자들이 고급 언어로 GPU를 프로그래밍할 수 있도록 지원했습니다.

이 시기를 기점으로 GPU는 단순한 그래픽스 연산 디바이스에서 범용 연산에 적합한 프로그래머블한 디바이스로 진화했습니다.

4. 2007년: CUDA와 GPGPU의 등장

2007년 NVIDIA는 CUDA(Compute Unified Device Architecture)를 발표하며, GPGPU(General Purpose GPU)의 시대를 열었습니다.

CUDA의 초기 목적�초기 CUDA는 머신러닝보다는 고성능 컴퓨팅(HPC)을 위한 병렬 프로그래밍 모델로 설계되었습니다.�GPU의 성능이 슈퍼컴퓨터 수준에 가까워지면서, 이를 일반 개발자들이 활용할 수 있도록 CUDA를 도입한 것입니다.
GPGPU 생태계의 확장

Apple: OpenCL 발표 (2008년)
AMD/ARM: HSA(Heterogeneous System Architecture) 시도

그러나 OpenCL과 HSA는 상용화에서 한계를 보였고, CUDA가 사실상 표준으로 자리 잡았습니다.

5. 현대의 Heterogeneous Computing

CUDA의 등장 이후 Heterogeneous Computing은 GPU 가속기의 활용을 극대화하며 자리를 잡았습니다.�오늘날 PyTorch와 같은 머신러닝 프레임워크 내부에서도 CUDA 기반의 API가 광범위하게 사용되고 있으며,�많은 후발 주자들이 이를 기반으로 비슷한 구조를 구축하고 있습니다.

결론적으로, Heterogeneous Computing은 CPU와 GPU의 조화로운 결합을 통해 컴퓨팅 성능을 극대화하는 중요한 기술로 발전해 왔으며, 이는 오늘날의 머신러닝과 AI 기술 발전의 핵심 배경 기술로 자리 잡았습니다.

9 of 19

Supercomputing

엄청나게 복잡한 계산을 처리하기 위한 computing 기술

응용분야: scientific research and simulation (physics, astrophysics, climate modeling 등)

보통 많은 수의 컴퓨터를 네트워크로 연결하고 큰 계산을 나누어 처리

대규모 인터넷 서비스도 계산 총량은 엄청나지만 많은 수의 독립된, 간단한 계산을 처리하는 점이 다름
“Fault”의 처리가 수퍼컴퓨팅에서 매우 중요 (vs. 대규모 인터넷 서비스)

다양한 parallel/distributed programming model이 등장

개념적인 모델 - SIMD, SPMD, MIMD
구현 표준 - MPI, OpenMP

Matrix multiplication이 가장 중요한 요소

과학에서 다루는 많은 자연 현상들이 선형대수로 표현됨
선형대수의 가장 중요한 개념들은 결국 matrix multiplication로 귀결됨
자연스럽게, matrix multiplication을 빠르게 처리할 수 있는 다양한 최적화 기술들이 등장

Algorithmic efficiency 측면: Strassen algorithm, DeepMind’s AlphaTensor
큰 matmul에 최적화된 보편적인 library의 등장

Basic Linear Algebra Subprograms (BLAS, 1979)

다양한 linear algebra문제에 적용할 수 있는 low-level API
Matrix multiplication을 위한 GEMM 포함

각 HW vendor들은 그들의 HW에 최적화된 BLAS 구현 출시

Nvidia: cuBLAS (2017), cuTLASS (2018)

1. 슈퍼컴퓨팅이란

슈퍼컴퓨팅이란 엄청나게 복잡한 계산을 처리하기 위한 고성능 컴퓨팅 기술입니다. 최근에는 머신러닝이 슈퍼컴퓨팅의 대표적인 예시로 떠오르고 있지만, 20년 전만 해도 주로 과학 연구와 시뮬레이션 분야에서 사용되었습니다. 예를 들면 물리학 시뮬레이션, 천문학, 기후 모델링, 로켓 개발, 그리고 핵폭탄 연구 등이 이에 해당됩니다.

미국의 내셔널 랩(National Lab)에서는 이러한 슈퍼컴퓨터를 활용해 복잡한 과학적, 기술적 문제를 해결하는 데 주력하고 있습니다.

�2. 슈퍼컴퓨팅과 인터넷 서비스의 차이�

슈퍼컴퓨팅은 많은 수의 컴퓨터를 네트워크로 연결해 하나의 큰 계산을 분산 처리하는 방식으로 작동합니다. 구글의 데이터센터나 클라우드 기술도 유사한 구조를 가지고 있지만, 본질적인 차이가 존재합니다.

인터넷 서비스는 독립적이고 간단한 계산을 대량으로 처리하는 데 중점을 둡니다.

슈퍼컴퓨팅은 하나의 거대한 계산을 여러 컴퓨터에서 나누어 처리하며, 모든 작업이 연결되어 있습니다. 따라서 작업 중 하나라도 오류가 발생하면 전체 계산이 망가질 수 있습니다. 이는 인터넷 서비스에서는 덜 중요한 요소입니다.

이처럼, 슈퍼컴퓨팅에서는 장애(fault) 처리가 매우 중요합니다. 머신러닝의 경우에도 인퍼런스는 독립적인 작업이 많지만, 대규모 분산 학습에서는 하나의 작업이 매우 크기 때문에 fault 처리가 더욱 중요해집니다.

�3. 병렬/분산 프로그래밍 모델

슈퍼컴퓨팅의 발전과 함께 다양한 병렬 및 분산 프로그래밍 모델이 등장했습니다.

SIMD, SPMD, MIMD와 같은 개념적 모델들이 있으며, 이를 실제 구현한 표준으로는 MPI, OpenMP 등이 있습니다.

특히 MPI(Message Passing Interface)는 파이토치(PyTorch)에서 구현된 분산 프로그래밍 모델의 기반이 되기도 합니다.

4. 매트릭스 곱셈과 선형대수 (Matrix Multiplication)

슈퍼컴퓨팅에서 가장 중요한 요소 중 하나는 **매트릭스 곱셈(Matrix Multiplication)**입니다. 많은 자연 현상과 과학적 문제들이 선형대수로 표현되며, 선형대수에서 가장 중요한 연산이 바로 매트릭스 곱셈입니다.

매트릭스 곱셈의 연산량은 매트릭스 크기에 따라 큐빅(N^3)에 비례하기 때문에, 이를 얼마나 빠르게 처리할 수 있는지가 전체 시스템의 성능에 큰 영향을 미칩니다.

5. 매트릭스 곱셈의 최적화 기술

매트릭스 곱셈을 빠르게 수행하기 위한 다양한 알고리즘과 최적화 기술이 존재합니다.

Strassen 알고리즘: 매트릭스 곱셈의 복잡도를 낮추는 고급 알고리즘입니다.

DeepMind의 AlphaTensor: 최근 딥마인드에서 발표한 AlphaTensor는 매트릭스 곱셈 커널을 최적화하여 계산 속도를 크게 향상시켰습니다.

6. 매트릭스 곱셈 라이브러리 - BLAS

매트릭스 곱셈을 포함한 다양한 선형대수 문제를 해결하기 위한 표준 라이브러리로는 **BLAS(Basic Linear Algebra Subprograms)**가 있습니다.

1979년에 처음 발표된 BLAS는 저수준 API를 통해 다양한 선형대수 연산을 수행합니다. 매트릭스 곱셈을 위한 GEMM(General Matrix Multiply)도 BLAS에 포함되어 있습니다.

하드웨어 벤더들은 자사 하드웨어에 최적화된 BLAS 구현을 제공합니다. �예를 들면: NVIDIA의 cuBLAS (2017), cuTLASS (2018) → cuBLAS는 클로즈드 소스(closed-source)로 제공되지만, cuTLASS는 오픈소스 라이브러리로 누구나 접근 가능합니다.

10 of 19

ML Compiler

정적인 graph로 전환된 ML model을 특정 hardware에 맞게 최적화해주는 컴파일러

ML framework으로 개발자들이 표현한 model은 대부분 “동적"
ML compiler를 적용하기 위해선

동적으로 표현된 model을 특정한 “정적" model로 고정하고
이를 ML compiler가 이해할 수 있는 format으로 전환
최종적으로 HW가 실행할 수 있는 binary를 생성

서버에서 GPU로 훈련된 모델을 On-Device AI 가속기에서 수행하기 위해 많이 쓰임

Qualcomm Snapdragon
Samsung Exynos
Google Tensor

서버에서도 점점 활성화되고 있는 추세

Google TPU + {TensorFlow, JAX} + XLA
Nvidia GPU + {TensorFlow, Pytoch} + TensorRT
Rebellions NPU + { TensorFlow, Pytorch} + RBLN Compiler

Pytorch 2.0의 등장으로�더욱 가속화될 것

ML 컴파일러와 관련하여 PyTorch에서 해당 개념을 어떻게 구현하고 있는지 논의해보겠습니다.

ML 컴파일러란 무엇인가?�

일반적으로 ML 컴파일러는 정적 그래프 형태로 변환된 ML 모델을 특정 하드웨어에 최적화된 형태로 변환해주는 역할을 합니다.
PyTorch와 같은 동적 프레임워크에서는 모델의 표현 방식이 동적(dynamic)이라 이를 정적(static) 모델로 변환하고 최적화된 바이너리를 생성해야 합니다.

PyTorch 1.x와 ML 컴파일러�

PyTorch 1.0에서도 컴파일러와 비슷한 개념이 일부 있었습니다. 예를 들어 JIT(Just-In-Time) Trace가 이에 해당합니다.
JIT Trace는 모델을 정적 형태로 변환해주는 역할을 하지만, 본격적인 ML 컴파일러로서의 역할은 제한적이었습니다.
PyTorch 1.x 시대에는 ML 컴파일러에 대한 기능이 강조되지 않았습니다.

PyTorch 2.0에서의 변화�

PyTorch 2.0은 ML 컴파일러 기능을 대폭 강화한 버전으로, 아래와 같은 컴포넌트들이 추가되었습니다.

Dynamo:

JIT Trace를 대체하는 컴포넌트로, 컴파일러와 유사한 역할을 수행합니다.

Inductor:

본격적인 ML 컴파일러로, 모델 최적화 및 하드웨어 실행 효율화를 담당합니다.

Triton:

도메인 특화 언어(Domain-Specific Language, DSL)로, GPU를 위한 커널 최적화 작업에 활용됩니다.

PyTorch 2.0의 의의�

PyTorch 2.0에서는 Dynamo, Inductor, Triton 등의 컴포넌트가 결합되면서 본격적인 ML 컴파일러의 기능을 갖추게 되었으며, 다양한 하드웨어에서 더욱 효율적인 실행 환경을 제공합니다.

11 of 19

Numerical Computing for Data Science

Data science

통계, 컴퓨터 과학, 수학 등의 도구를 활용, 데이터를 분석하여 대상을 이해하는 융합 학문
많은 과학자 / 엔지니어들이 업무의 일부로 자연스럽게 data scientist 역할을 수행

Data scientist들은 손쉽게 접근할 수 있는 도구를 선호

Predefined math functions
Interactive mode
Visualization

Numpy의 등장과 함께 Python이 대세로 자리잡음

SAS (1966), SPSS (1968), Matlab (1970s), R(1993) 등이 선구적인 역할
Numpy(2005)의 등장과 함께 Python이 대세가 됨

SciPy, Matplotlib, pandas, scikit, …

Jupyter의 등장으로 더욱더 많은 사람들이 쉽게 접근할 수 있게 됨

ML도 사용성 측면에서 같은 추세

제 생각에 깊이 연관된 또 다른 도메인은 데이터 사이언스와 관련된 영역입니다. 흔히 “Numerical Computing”이라고 불리며, 데이터 사이언스라는 용어가 자주 사용되지만 사실 이를 정확히 정의하기는 쉽지 않습니다. 다소 추상적으로 "이런 거야"라고 이야기할 수는 있지만, 명확한 정의는 어렵죠.

저는 ChatGPT와 구글 검색을 통해 얻은 힌트를 바탕으로 데이터 사이언스를 이렇게 정의해보았습니다: 통계, 컴퓨터 과학, 수학 등 정량적인 도구들을 활용해 대량의 데이터를 분석하고 이해하는 융합 학문입니다. 이런 데이터를 다루는 전문가들을 '데이터 사이언티스트' 또는 '데이터 엔지니어'라고 부르는데, 이들은 전업으로 이 일을 하기도 하지만, 많은 엔지니어나 과학자들이 때때로 데이터 사이언티스트의 역할을 겸하기도 합니다.

데이터 사이언티스트들은 단순히 특정 프로그래밍 언어를 사용하는 것보다는, 이미 존재하는 데이터를 손쉽게 가공하고 필요한 정보를 얻어내는 데 더 관심을 둡니다. 특히 복잡한 수학 함수를 직접 구현하기보다는, 잘 만들어진 도구나 라이브러리를 활용하는 것을 선호합니다. 또한 긴 코드를 작성하고 실행하기보다는, 데이터를 즉시 처리하고 결과를 확인하면서 인터랙티브하게 작업하는 방식을 중요하게 생각합니다. 시각화 도구도 이들에게 매우 중요한 요소입니다.

데이터 사이언스를 위한 도구들은 오래전부터 존재했는데, 제가 학교 다닐 때 많이 사용했던 매트랩이 그 예입니다. 하지만 2000년대 초반부터 NumPy가 등장하며 데이터 분석 도구의 패러다임이 바뀌기 시작했습니다. 최근에는 PyTorch의 성장과 함께 NumPy도 꾸준히 발전하고 있으며, 많은 데이터 사이언티스트들이 PyTorch 기반 도구를 활용하고 있습니다. 여기에 더해, 피터 같은 인터랙티브 시각화 도구들이 등장하면서, 데이터 과학이 더욱 접근성 높은 분야로 변모하고 있습니다.

NumPy는 TensorFlow와 파이토치의 API 설계와도 밀접한 관련이 있습니다. 특히 텐서 연산 처리 방식 등에서 공통점이 많습니다. 이는 머신러닝 작업에서도 NumPy 스타일의 접근법이 사용성 면에서 탁월하다는 점을 보여줍니다.

흥미로운 점은, NumPy가 파이토치의 개발에 영향을 준 뒤, 최근에는 NumPy 창시자의 회사가 파이토치 2.0에 많은 기여를 하고 있다는 사실입니다. 이제 파이토치는 NumPy 코드를 네이티브로 지원하며, NumPy 코드를 GPU에서 가속 처리할 수 있게 되었습니다. 구체적으로, NumPy 코드를 수정 없이 작성하면, 이를 바이트코드로 동적으로 변환해 쿠다(CUDA) 코드로 컴파일한 뒤 GPU에서 실행할 수 있습니다. 이 기술은 '다이나모(Dynamo)'와 '인덕터(Inductor)' 같은 기술을 활용해 구현되었고, 현재는 파이토치의 업스트림에 포함되어 있습니다. 이러한 발전 덕분에, 앞으로 많은 사람들이 NumPy를 GPU에서 가속 처리하며 효율적으로 활용할 수 있을 것으로 기대됩니다.

12 of 19

Two (or More) Language Problems

Python의�성능 문제

해결책 #1

고성능 Python compiler를 개발

Cython 성능이 점점 좋아지고 있음
PyPy같은 대안 프로젝트도 존재

해결책 #2

Python 언어를 증강

Modular의 Mojo 프로젝트

해결책 #3

다른 언어로 작성된 모듈과 binding

pybind11: Python + C++11

Numpy, Pytorch

추가로 가속기로 offloading

그리고 또 하나, 지금까지는 프로그래밍 언어적인 문제보다는 다른 영역의 문제들을 다뤘는데, 이제부터는 프로그래밍 언어 쪽의 문제를 다루기 시작할 것 같습니다. 제가 다루기 시작한 기억이 맞다면, 혹시 "Two Language Problem"이라는 용어를 들어보신 적 있으신가요?

요즘에 Modular AI라는 회사를 알고 계신가요? Modular AI는 대표적으로 "Mojo"라는 프로그래밍 언어를 만들고 있는데, 이는 파이썬의 언어를 확장한 형태입니다. Mojo는 파이썬이 가지고 있는 고질적인 사용성 문제 중 하나인 Two Language Problem을 해결하는 솔루션으로 제시되었습니다.

파이썬뿐만 아니라 유사한 언어들이 가지고 있는 큰 문제는 쓰기 쉽고 접근하기 편하다는 점이 있지만, 성능이 나오지 않는다는 것입니다. 특히 복잡한 수식이나 알고리즘을 파이썬으로 작성하면 매우 느려집니다.

이를 해결하기 위해 NumPy 같은 프레임워크가 사용되는데, 현실적으로 가장 효과적인 방법은 2개의 프로그래밍 언어를 사용하는 것입니다. 실제 스크립트 인터페이스는 파이썬을 사용하지만, 중요한 함수들은 예를 들어 Pybind11 같은걸 활용하여 C++로 작성하여 PyTorch와 같은 라이브러리에서 파이썬에서 잘 활용할 수 있도록 합니다. 이렇게 하면 많은 문제들을 해결할 수 있습니다. Julia 같은 언어도 이런 접근 방식을 사용하고 있으며, Christopher Arthur Lattner(LLVM 개발자) 같은 분들도 Mojo와 같은 프로젝트를 진행하고 있습니다.

아무튼 파이썬이 가지고 있는 성능 문제를 해결하기 위한 방법을 크게 세 가지로 정리할 수 있을 것 같습니다. 첫 번째 방법은 실제 파이썬 컴파일러 자체를 개선하는 것입니다. 예를 들어, 제가 여기서 "Cython"이라고 했는데, 죄송합니다. "PyPy"이라고 해야겠네요. Cython는 파이썬의 기본 인터프리터라고 할 수 있습니다. 이 엔진도 성능이 점점 더 좋아지고 있으며, 어떤 분들은 농담으로 이 트렌드가 계속된다면 몇 년 후에는 파이썬의 성능이 C++보다 더 좋아질 것이라고 말하기도 합니다. 현재도 C++과 비교했을 때 파이썬의 성능 자체가 상당히 향상되고 있습니다.

두 번째 방법은 PyPy와 같은 프로젝트를 활용하는 것입니다. PyPy는 파이썬으로 파이썬 인터프리터를 만드는 프로젝트인데, 이들 또한 Cython보다 더 나은 성능을 제공하며 앞으로 더 크게 향상될 수 있다고 주장하고 있습니다. 이러한 프로젝트들이 존재함으로써 파이썬 자체의 성능을 높이는 해결책도 마련되어 있습니다.

세 번째 해결책은 가장 일반적이고 많은 사람들이 받아들이는 방식으로, 파이썬이 해야 할 일은 파이썬이 하고, 파이썬이 할 수 없는 일은 다른 언어로 넘기는 것입니다. 예를 들어, 제가 이전에 파이토치를 통해 GPU를 사용하는 방법에 대해 이야기했지만, 이는 주로 CPU에서 사용되었습니다. 이러한 문제를 해결하기 위해 C++ 바인딩을 사용하게 됩니다. PyTorch 같은 경우에도 마찬가지로 C++ 바인딩을 사용하지만, 예를 들어 CUDA를 사용하는 경우도 있습니다. 이렇게 생각해보면, 이는 Two Language 솔루션이 아니라 Three Language 솔루션이 되는 셈이죠. 이러한 문제가 있으며, PyTorch에서 이를 해결하는 방식과는 다른 여러 가지 대안들도 존재합니다. 이러한 대안들에 대해서 한번 짚고 넘어가고 싶었습니다.

또한, 그래프 모드에 대해서도 말씀드리겠습니다. 그래프 모드는 API를 호출하자마자 오퍼레이터가 즉시 실행되는 시멘틱을 가지고 있다고 생각하시면 됩니다.

13 of 19

Eager vs. Graph Mode

Eager mode와 graph mode의 차이

Eager mode

API 호출 → operator가 곧바로 실행됨

Graph mode

API 호출 → graph를 점진적으로 생성
Graph가 완성되면 목적에 맞게 변환 적용 후 수행

Back propagation을 위한 backward graph 생성
성능 향상을 위한 최적화 수행 (예: op fusion)

Graph mode를 접근하는 방법

TF1의 접근법 (define-and-run)

개발자에게 명시적으로 graph를 생성

Pytorch, TF2, JAX의 접근법 (define-by-run)

개발자는 eager mode를 가정하고 model 작성
개발자가 작성한 eager mode기반 model으로부터 graph를 추출

Eager, graph�모두 가능

Graph만 가능

graph mode는 API가 호출될 때 실질적으로 그래프가 점진적으로 생성되는 과정입니다. 각 계산이 끝날 때마다, 그때 만든 그래프를 한 번에 처리하여 작업을 진행하는 방식이라고 이해하시면 됩니다.

우리는 eager mode와 graph mode를 구분할 수 있기는 하지만 예를 들어, backward propagation을 실행하기 위해 forward graph를 eager mode로 돌리게 되면, 사실 두 가지를 동시에 하고 있다고 볼 수 있습니다.

Forward 단계에서는 eager mode로 계산이 진행되지만,
Backward 단계에서는 eager 로 계산하는 과정이 본인의 그래프 모드가 적용됩니다. backward 계산은 forward 계산과는 다르기 때문에, backward graph 모드가 필요합니다.

graph 모드에서는 계산을 위한 그래프를 만들어주는데, autograd 켜면 gradient 계산을 위한 그래프가 생성됩니다. 이 과정에서, forward 단계에서는 eager 모드를 사용하지만, backward 단계에서는 graph mode가 작동합니다.

graph 모드란, 계산을 위한 그래프를 만들기 위한 힌트를 제공하는 API를 사용하는 과정이라고 할 수 있습니다. 그 힌트를 바탕으로 실제 계산을 수행하는 것이 그래프 모드의 핵심입니다. graph 모드에 접근하는 방법은 여러 가지가 있으며, 이를 어떻게 해석하고 적용할지는 개인에 따라 다를 수 있습니다.

14 of 19

TF1 vs. Pytorch Examples

x1 = torch.rand(2, 3)

x2 = torch.rand(2, 3)

y = x1 + x2

print(y)

a = tf.constant([[3, 3]])�b = tf.constant([[2, 2]])�c = tf.matmul(a, b)��With tf.Session() as s:

print(c.eval())

TF1

Pytorch

“c”는 matmul의 결과를 의미하지만�실제 결과값을 알기위해선 “eval”을 호출하여 그래프를 실행해야함

“y”는 “+”가 실행된 결과를 가지고 있음. Pytorch eager mode에서는 별도의 그래프 실행 과정이 필요 없음

TensorFlow의 경우: TensorFlow 1.x 버전에서는 TF Constant와 TF Matmul과 같은 연산자를 사용하여 계산 그래프를 구성합니다. 이러한 연산자들은 실제 계산을 수행하지 않고, 계산 과정을 그래프로 만드는 역할을 합니다. 계산 그래프는 TF Session을 생성한 뒤에 실행(evaluate)할 수 있으며, 그래프를 실행하면 비로소 실제 계산 결과를 얻을 수 있습니다. 예를 들어, a, b, c라는 표현식에서 c를 평가하기 전까지는 c의 실제 값이 어떤 것인지 알 수 없습니다. c를 평가하면 그 결과가 나타나게 됩니다.

PyTorch의 경우: PyTorch에서는 eager mode라고 불리는 방식을 사용합니다. 이 모드에서는 각 줄의 연산을 즉시 수행하며, 결과를 바로 확인할 수 있습니다. 예를 들어, y = x1 + x2와 같은 연산을 수행하면, 각 단계별로 계산이 진행되며, print(y)를 사용하면 바로 결과를 출력할 수 있습니다. 이는 TensorFlow와 달리 별도의 계산 그래프를 미리 만들 필요가 없으며, 코드 한 줄 한 줄이 실시간으로 계산되고 결과를 반환합니다.

15 of 19

Graph Capture: TF2 | Pytorch 2

g = tf.Graph()

with g.as_default():

c = tf.constant(3)

assert c.graph is g

def Foo(x, y):

a = torch.sin(x)

b = torch.cos(y)

return a + b�

foo = Foo

x = torch.rand(3, 4)

y = torch.rand(3, 4)

traced_foo = torch.jit.trace(foo, (x, y))

traced_foo(x, y)��optimized_foo = torch.compile(foo)�optimized_foo(x, y)

TF2

Pytorch 1 & 2

이번에는 그래프 캡쳐에 대해 설명드리겠습니다. 그래프 모델에서는 어떻게 그래프를 뽑아낼 것인가가 매우 중요한데요. TF1의 경우에는 제가 앞서 말씀드렸듯이, 프로그래머들에게 명시적으로 그래프를 그려달라고 요청했습니다.

반면에 TF2나 PyTorch 2에서는 명시적으로 그래프를 그려달라고 하지는 않습니다. 대신 eager 모드로 모델을 만들어주면 거기서 자체적으로 그래프를 뽑아내는 방식을 사용하고 있죠. 이게 TF2나 PyTorch 1, 2가 채택한 방식입니다.

다만 TF2는 TF1의 흔적이 아직 남아있어서, 그래프를 명시적으로 construct한 다음 trace에 그 그래프가 있는 context로 묶어서 처리합니다. 이 context 안에서 eager 모드로 모델을 기술하면 그래프가 캡처되는 구조인데요. 어떻게 보면 좀 어정쩡한 느낌이 있습니다.

PyTorch 1과 2는 모두 100% eager 모드를 지원하는데, PyTorch 1에서는 제가 앞서 말씀드린 deep trace를 이용해서 trace를 뽑아 그래프 모듈을 수행하도록 되어 있습니다. PyTorch 2에서는 이를 더 범용적으로 사용할 수 있는 torch.compile을 도입했고, 특히 trace를 뽑아내는 기능은 Dynamo라는 기술을 개발해서 더 체계적으로 대응하고 있습니다. 이것이 PyTorch 1과 2의 주요 차이점이라고 할 수 있습니다.

16 of 19

This is not new

Trace scheduling for VLIW compiler (1981)
Out-Of-Order Execution in Pentium Pro (1995)
Trace cache (1996)
Chrome V8 Engine (2008)

Slide paper

https://ieeexplore.ieee.org/abstract/document/1675827?casa_token=SQLB1lJ6HkkAAAAA:UOXijGkcivDbmBIJ4bBItD1tH0MoW1baPwsGHDlZnMsRpL70AdEZZqYiP5Oo5oIxFeVM7uDa3aQ

요약

PGO(프로파일 가이드 최적화, Profile-Guided Optimization): 프로그램의 동적인 특성을 컴파일 타임에 활용해 최적화를 수행하는 더 넓은 개념.�

PGO는 프로그램 실행 중 수집된 데이터(예: 브랜치 예측, 실행 빈도 등)를 기반으로 최적화를 수행.

트레이스 스케줄링: PGO에서 사용하는 특정 기법 중 하나.�

동적인 실행 경로(Trace)를 추출하여 성능을 최적화.
브랜치 예측을 통해 자주 실행되는 경로를 추적하고, 이 경로에 최적화된 스케줄링을 수행.
핵심 요소:

양질의 프로파일 데이터 필요.
올바른 트레이스를 만들어 롤백 없이 효율적인 성능을 제공.

예: A와 B 중 A 경로가 더 자주 실행될 것이라 판단되면, 이를 기준으로 스케줄링.

관계:�

PGO는 더 광범위한 개념이며, 트레이스 스케줄링은 PGO의 구체적인 방법론 중 하나로 볼 수 있음.

17 of 19

Convergence on Pytorch

여기까지 했고 사실은 이게 아마 제 생각에는 마지막 페이지인 것 같아요. 더 있네요. 이게 거의 이제 마지막 페이지인데, 그래서 이런 머신러닝 프레임워크에 방대한 양의 백그라운드가 있긴 하지만, 그런 것들이 시간이 흘러감에 따라 점점 더 잘 정리되어 사람들이 "이런 문제는 이렇게 풀면 좋겠다"라고 하는 것이 5년, 10년 전보다는 지금 훨씬 더 잘 정립되어 있는 것 같아요. 그리고 그런 것들이 잘 통합되어 있는 형태가 파이토치인 것 같고요. 몇 년 전까지만 해도 사람들이 긴가민가했지만, 지금은 거의 파이토치로 표준화되고 있는 게 아닌가라는 생각이 듭니다. 그 한 예가 아마 여기 있는 분들이 거의 다 아실 만한 기술인데, VLM이라고 하는 기술이 있습니다.

파이토치 위에 올라가는 기술이라고 생각할 수 있는데, 이 VLM에 하드웨어를 붙이는 것이 요즘 모든 하드웨어 벤더들이 가장 유행처럼 시도하고 있는 작업 중 하나입니다. 그런데 이 VLM이 업스트림에서 하드웨어를 지원하기 위해서는 "일단 파이토치에 잘 붙여봐라"라고 하는 아주 구체적인 요구 조건을 내걸었어요. 그러면서 이를 대표하는 주요 이슈도 있었는데, 자기들은 앞으로 VLM이 하드웨어를 연결하는 주요한 기반으로 파이토치를 사용하겠다고 제시했습니다. 따라서 하드웨어 종속적인 부분들은 먼저 파이토치에 잘 통합하고, 그다음에 와서 자신들에게 제공하라는 정식 정책을 수립했습니다.

어떻게 보면 당연한 이야기일 수 있지만, 이 머신러닝 에코 시스템에서 방금 말씀드린 이 ‘네로우 웨이스트’는 다양한 하드웨어를 잘 추상화하고 단순화시키는 창구로 파이토치가 점점 더 보편적으로 받아들여지고 있는 것 같습니다.

18 of 19

Pytorch 2.0

NumPy-like experience
Heterogeneous computing as an underneath foundation
MPI-like distributed programming model
Integration with compute libraries / ML compiler
Three language layers: Python → C++ → kernel language (ex: CUDA, Trition)
Define-by-run /w graph capturing with TorchDynamo

Support both training and inference

Various backend integration points

Eager mode

As a new dispatch target

Graph mode

Both JIT (and AOT)
As a backend to TorchDynamo
As a backend to Inductor

그래서 종합적으로 제가 생각했을 때, PyTorch 2.0의 특징은 PyTorch 1.0의 성질을 거의 모두 inherit했으며, 이를 기반으로 개발자들이 NumPy를 사용하는 것과 비슷한 경험을 할 수 있도록 설계되었습니다. 실제로 텐서의 구조나 사전 정의된 수학 함수들이 잘 제공되고, 대화형 환경(interactive environment)도 지원합니다. 또한, Jupyter Notebook과 같은 데이터 과학자들이 많이 사용하는 도구들과의 호환성도 뛰어납니다. 이러한 측면에서 NumPy와 유사한 사용자 경험을 제공한다는 것이 PyTorch 2.0의 첫 번째 큰 특징입니다.

두 번째로는 Heterogeneous Computing(이기종 컴퓨팅)이 기본적인 기반으로 자리 잡고 있다는 점입니다. PyTorch 2.0은 다양한 하드웨어에서 효율적으로 동작할 수 있도록 설계되었습니다.

세 번째로는 Distributed Programming Model(분산 프로그래밍 모델)을 제공한다는 점인데, 이는 MPI(Message Passing Interface)와 유사한 기능을 PyTorch에서 기본적으로 지원하기 시작한 것입니다.

특히 PyTorch 1.0부터 Eager Mode에서는 컴퓨팅 라이브러리를 사용하고, 그래프 모드에서는 PyTorch 2.0에서 ML 컴파일러와의 통합(integration)을 매우 중요하게 다루고 있습니다. 이러한 지원이 잘 이루어지고 있다는 점도 큰 특징입니다.

또 다른 특징으로는 PyTorch가 단순히 제2 랭귀지가 아니라, 제3 랭귀지 또는 멀티 랭귀지 솔루션으로 자리 잡았다는 점입니다. 스크립팅은 Python으로 이루어지지만, 하위 레벨에서는 성능 최적화를 위해 C++로 전환됩니다. 특히 CUDA를 사용하는 경우 GPU, TPU, NPU 등의 하드웨어에서 최적화된 커널 레벨 성능을 제공합니다.

마지막으로, Define-by-Run 모드를 중심으로 가져가면서 그래프 모드를 부드럽게(smoothly) 지원하기 위해 Torch Dynamo라는 기술을 도입했습니다.

PyTorch 2.0은 트레이닝뿐만 아니라 인퍼런스에서도 잘 활용될 수 있도록 설계되었습니다. 어떻게 보면 PyTorch 2.0으로 넘어오면서 가장 크게 변화한 부분이 바로 이 점인 것 같습니다. 또한, 다양한 하드웨어와 원활히 연결될 수 있도록 통합 포인트(integration points)를 잘 정의하고 있습니다.

제가 생각했을 때, 이러한 여러 기술적 배경들을 종합하여 구현된 것이 바로 PyTorch 2.0이라고 할 수 있습니다.

19 of 19

향후 강의 계획

Pytorch internal: 기초 (3회)

Pytorch internal에 대한 개요
Pytorch eager mode
Pytorch graph mode
Putting things together: training, finetuning, inference

Pytorch internal: 심화 (8회)

Pytorch + Nvidia GPU
Pytorch + parallelism
Pytorch + LLM + inference
Pytorch + 리벨리온 NPU

앞으로의 강의 구성은 크게 파이토치 인터널의 '기초'와 '심화' 두 파트로 나누어 진행하고자 합니다.

기초 파트에서는 다음과 같은 순서로 진행됩니다: 먼저 전체 인터널이 어떻게 구성되어 있는지, 코드베이스는 어떻게 바라봐야 하는지에 대한 개요부터 시작하겠습니다. 그 다음 이거(eager) 모드에 대해 이야기를 하고, 이어서 그래프 모드를 공부해보겠습니다. 마지막으로 이러한 내용들이 실제 트레이닝, 파인튜닝, 인퍼런스에서 어떻게 활용되는지 다루어보겠습니다.

심화 파트는 네 가지 주요 토픽으로 구성했습니다:

현재 파이토치에서 가장 잘 통합되어 있고 사람들이 가장 잘 활용하고 이해하는 GPU와 파이토치의 연동 방식과 활용법
디스트리뷰티드 프로그래밍 위에서의 패러럴 프로그래밍을 파이토치로 어떻게 구현하는지
파이토치를 활용한 LLM 인퍼런스 방법
우리 랩의 정체성인 'PyTorch + NPU'에 맞춰, NPU(특히 리벨리온 관점)와의 연동에 대해 다루겠습니다.

이것이 제가 준비한 전체적인 강의 계획입니다. 시간이 약간 남았는데, 마무리하기 전에 오늘 다룬 내용이나 앞으로의 계획에 대해 종합적으로 궁금하신 점이나 코멘트가 있으시면 받도록 하겠습니다.

[Q&A 정리]

1. TorchScript와 Python/C++ 관계에 대한 질문

Q: "TorchScript는 Python과 C++ 사이에 위치해 있다고 봐도 되나요?"

A: 그렇게 보기는 어렵습니다. TorchScript는 SPIR-V와 같은 도구 언어와는 다른 차원의 문제입니다. TorchScript는 PyTorch에서 그래프 모드를 지원하기 위한 기술 중 하나로 보는 것이 더 적절합니다.

2. 강의 내용 공유 관련

Q: "오늘 했던 강의 내용들은 나중에 정리가 돼서 공유가 되나요?"

A: 강의 내용을 캡처하고 공유하는 방법에 대해 여러 옵션을 고려 중입니다: 강사가 직접 상세히 작성, AI 활용, 참가자들의 협력, 랩을 위한 블로그 개설 제안

3. CUDA와 Triton의 차이점

Q: "CUDA와 Triton은 어떻게 다른지 궁금합니다."

A: 주요 차이점:

라이선스: CUDA는 proprietary, Triton은 오픈소스
설계 목적: CUDA는 픽셀 단위의 fine-grained 스레드 처리, Triton은 코스 그레인한 데이터 청크 단위 처리
프로그래밍 모델: CUDA는 SPIR-V 기반, Triton은 Python 데코레이터 형태의 API 제공
최적화 방식: Triton은 컴파일러가 복잡한 최적화를 처리하는 전략 채택

4. Triton 관련 추가 설명

- Triton은 단순한 Python API가 아닌, Python 신택스를 사용한 도메인 특화 언어(DSL)로 보는 것이 더 정확함

- 원래 C 바인딩도 있었으나 현재는 Python 바인딩이 주로 사용됨

5. PyTorch Compute Shader 관련

Q: "PyTorch용 컴퓨팅 쉐이더라고 불러도 될까요?"

A: 네, 그렇게 볼 수 있습니다. PyTorch 2.0에서 기본으로 채택한 커널 프로그래밍 언어로 이해할 수 있습니다.