AICF 실행 흐름 ( nn - trace - IR - lower - plan - runtime - CUDA backend )

nn - trace - IR - lower - plan - runtime - CUDA backend 로 이어지는 실행 파이프라인의 이해 

 

1. nn (Frontend / UX Laayer)

역할 : 사용자 인터페이스 + 파라미터 보관

• PyTorch 와 유사한 API 를 제공, 실제 연산을 실행하진 않음
• 레이어는 다음만 책임
  • 파라미터 텐서
  • 정적 메타 정보
  • 호출 시 trace 에 연산 의도 기록

커널 선택, 타일링, fusion, epilogue 정보는 nn 레이어에 존재하지 않음

 

2. trace ( Graph Recoreding Layer )

역할 : 실행 의도의 선형 기록

• nn 레이어 호출 시 실제 계산 대신 IR op 기록
• 이 단계에서는
  • control flow 고정
  • shape / dtype 확정
  • side effect 제거

CUDA Graph capture 가능한 형태로 만들기 위한 첫 번째 관문

 

3. IR (Intermediate Represenation)

역할 : Source of Truth

• IR 은
  • 변경 가능
  • 최적화 대상
  • backend 비독립적
• 핵심 특징
  • 실행 순서가 명확
  • op 간 의존성 명시
  • 파라미터 / activation / grad 흐름이 드러남

이 시점부터 레이어 개념이 사라지고 IR 만 존재

 

4. lower ( IR Decomposition / Normalization )

역할 : 고수준 IR - 저수준 IR

• linear - gemm + bias_add
• optimizer - biascorr + adam_step
• epilogue 분리 / 결합
• backend 친화적 op 집합으로 정규화

커널과 1:1 대응되기 시작하는 구간

 

5. plan ( Execution Planning )

역할 : 실행 전략 확정

• 결정되는 것들
  • op - kernel variant 매핑
  • launch 순서
  • CUDA Graph capture boundary
• panner 는
  • IR 구조를 기반으로
  • backend registry 를 참고해
  • 캡처 가능한 고정 실행 플랜을 만든다

 

6. runtime / exec

역할 : 실행과 재현성 관리

• 기능
  • CUDA Graph capture / replay
  • 파라미터 restore
  • determinism 검증

 

7. CUDA backend ( Kernel Registry )

역할 : 실제 계산 수행

• 구성
  • 실제 CUDA 커널
  • launcher : ABI 고정된 호출 인터페이스
  • registry : op_kind - kernel 매핑
• 특징
  • IR 이 요청한 것만 수행
  • 상태 없음
  • 결정 로직 없음

 

핵심 설계 철학 요약

• nn 레이어는 실행하지 않음
• IR 은 유일한 진실
• 최적화는 IR 을 바꾸는 행위
• 커널은 IR 결정의 결과물
• CUDA Graph replay 는 python 을 우회한 실행