PyTorch 내부 구조 01 - 왜 PyTorch internals를 알아야 하는가
PyTorch를 단순한 파이썬 라이브러리가 아니라 런타임으로 이해해야 성능과 확장 문제를 제대로 다룰 수 있다
텐서, autograd, CUDA extension을 이해하고 커스텀 커널을 실제 학습 코드에 연결하기
PyTorch를 이미 사용하고 있지만, 파이썬 API 아래에서 실제로 무슨 일이 일어나는지 알고 싶은 ML 엔지니어와 시스템 지향 개발자.
기본적인 PyTorch 학습 경험, 파이썬 숙련도, 그리고 텐서와 역전파에 대한 기초 이해.
PyTorch를 단순한 파이썬 라이브러리가 아니라 런타임으로 이해해야 성능과 확장 문제를 제대로 다룰 수 있다
텐서를 다차원 배열로만 보면 view와 layout 문제를 잘못 이해하게 된다
shape가 같아도 memory layout이 다르면 operator 선택과 성능이 달라지고 때로는 보이지 않는 복사가 생긴다
같은 operator 이름 아래 여러 backend와 여러 역할의 구현을 연결해 주는 중심 계층이 dispatcher다
autograd는 단순 미분 기능이 아니라 연산 그래프와 gradient propagation을 조직하는 런타임이다
custom autograd function은 빠른 실험 도구이기도 하지만 backward 책임을 직접 지는 계층이기도 하다
PyTorch의 CUDA 메모리는 단순 malloc/free가 아니라 caching allocator 위에서 재사용된다
PyTorch의 CUDA 연산은 기본적으로 비동기이기 때문에 실제 병목을 읽으려면 stream semantics를 알아야 한다
C++ extension은 PyTorch runtime과 사용자 정의 연산을 연결하는 첫 번째 실전 관문이다
CUDA kernel을 PyTorch operator로 만들려면 kernel 코드뿐 아니라 tensor contract와 runtime semantics를 함께 맞춰야 한다
custom op를 제대로 등록하려면 구현 이전에 schema와 dispatch 구조를 먼저 분명히 해야 한다
backward는 forward의 덧붙임이 아니라 어떤 중간값을 저장하고 어떤 계산을 다시 할지 결정하는 설계 문제다
fused op는 launch overhead 감소뿐 아니라 메모리 접근과 intermediate materialization을 줄이기 위해 설계된다
custom op가 실제 학습에 들어가려면 mixed precision 환경에서의 dtype 규칙과 안정성까지 고려해야 한다
internals를 이해하는 목적은 결국 profile에서 시간을 어디서 잃는지 읽고 바꿀 수 있게 되는 데 있다
최근 PyTorch internals를 이해하려면 eager 실행 경로뿐 아니라 compile 경로도 함께 봐야 한다
Triton은 별도 장난감 언어가 아니라 PyTorch의 modern kernel story와 직접 연결되는 계층이다
DDP와 FSDP는 autograd 바깥의 마법이 아니라 gradient readiness와 tensor state를 runtime 차원에서 가로채는 구조다
custom op는 로컬 실험에서 끝나지 않고 배포와 테스트, 버전 호환성까지 고려해야 비로소 실전 코드가 된다
internals 공부의 목적은 trivia 수집이 아니라 custom operator, kernel optimization, distributed runtime으로 자연스럽게 이어지는 감각을 만드는 데 있다