상용 딥러닝 프레임 워크는 Inference Runtime 기반 구조이다...!

딥러닝 프레임워크 (Pytorch, TensorFlow, JAX 등 )  은 본질적으로 inference 성능을 기준으로 설계된 runtime 구조를 가진다.

그 이유는 training 과 inference 이 시스템 관점에서 요구하는 특성이 다르기 때ㅜㅁㄴ

 

1.Training vs Inference 요구 조건의 차이

Training

• dynamic control-flow 필요
• autograd graph 매 iteration 새로 생성
• 메모리, CPU, GPU 모두 매우 복잡하게 움직임
• python-level branching, 반복, shape 변화가 자연스럽게 발생

Training = dynamic execution + autograd engine 중심 구조

Inference

• 동일한 연산 패턴 반복
• control-flow 거의 없음
• static shape 선호
• 빠르고, determinism 필요
• python 레이어 제거 선호

Inference = static, 고정된 실행 경로를 빠르게 돌리는 구조

상용 프레임워크는 이 inference 의 고정성과 단순성을 기준으로 내부 runtime 을 최적화한다.

 

상용 프레임워크의 기본 전제

"학습은 dynamic, 추론은 static"

• 학습 시에는 그래프가 매번 달라져도 됨
• 추론 시에는 그래프가 변경되어선 안 됨
• 그래야 최적화, fusion, kernel selection, scheduling 이 가능

추론 runtime을 중심으로 발전

 

상용 프레임워크마다 추론 runtime 이 따로 있다.

 

 

 

 

추론 Runtime 이란?

고정된 모델 그래프 + 학습된 파라미터를 실제 하드웨어에 맞춰 최대한 빠르고 안정적으로 실행시키는 엔진

실행 플랜을 만들고 돌리는 시스템 계층이 바로 runtime

 

추론 runtime의 핵심 책임들

그래프 로딩 & 준비

• 이미 학습된 모델을 static graph 형식으로 로딩
  • 예: ONNX graph, TorchScript graph, 내부 IR
• 이 시점에서:
  • 연산 노드: matmul, conv, add, relu…
  • edge: 텐서의 흐름
  • shape, dtype, layout 정보 포함

runtime의 첫 역할은 “이 그래프를 이해 가능한 내부 표현(IR)로 옮기는 것”

그래프 최적화 (Graph Optimization

여기서부터 “inference runtime 기반”이라는 말이 의미를 갖는다.

• 연산 fusion
  • GEMM + bias + activation → 하나의 kernel
  • Conv + BN + ReLU → 하나로 합치기
• constant folding
  • 변하지 않는 텐서/상수는 미리 계산해서 그래프에서 제거
• 불필요한 op 제거
  • identity, no-op cast, 중복 reshape 등 정리
• layout 변환
  • NCHW ↔ NHWC, etc. 하드웨어/커널에 맞게 맞춤

즉,
“고정된 그래프”라는 전제를 깔고, 이걸 한 번 싹 다 뜯어고쳐서 “GPU가 좋아하는 형태”로 변환하는 게 추론 runtime의 핵심 역할 중 하나다.

 

메모리 플래닝 (Memory Planning)

추론은 학습보다 간단하지만, 여전히 메모리가 크다.

• 각 노드의 입출력 텐서 크기 계산
• 텐서의 liveness 분석
• 가능한 동일 버퍼 재사용
• workspace 버퍼 할당
• 일부 텐서는 persistent, 일부는 매 요청마다 재사용

매번 동적할당을 하는 것이 아닌, 텐서 생애를 분석해서 메모리를 계획적으로 재사용하는 시스템

 

커널 선택과 디스패치 Kernel Dispatch

각 연산 노드는 실제로는 어떤 커널로 실행할지 선택해야 한다.

이 노드는 어떤 커널이 제일 빠른지를 결정해서 디스패치한다.

 

추론 runtime = IR 노드를 실제 컨러로 매핑하고, 선택/튜닝하는 층

 

실행 스케줄링 Execution Scheduling

그래프에는 dependency 가 있다. 이걸 보고 runtime 의 결정

• 특정 노드 실행 순서 topological order
• 병렬 가능한 노드를 어떤 stream 에 나눌지
• multi-stream / multi-GPU / multi-request 상황에서
  • 어느 시점에 어느 연산을 스케줄링할지
• CUDA Graph capture
  • 그래프 전체를 capture 하고 이후에는 replay 만 하도록

고정된 그래프 + 디바이스 조건에 의해 그대로 반복 재사용할 수 있다.