AICF 초기 프레임워크 구조 정립 및 커널 관측에 대한 기록 - 초기 Pytorch 구현 이유, 실제 커널 실행 흐름 관찰

1. 문제 의식

AICF 를 구성하면서 초기엔 다음과 같은 질문

• Python 프레임워크 스켈레톤이 먼저 필요한지?
• C++ / CUDA 커널 중심 개발 이후 Python 확장 가능?
• CUDA Graph Capture 를 전제로 할 때, 현재 구조에서 전체 흐름 검증이 가능한지

기존 ge_v2 에서는 Python 레벨에서

• 모델 구성
• 실행 흐름
• capture 조건

을 실시간 검증해서 구조가 직관적으로 느껴졌음

반면 AICF 에서는 초기부터 디테일한 조건을 먼저 고려하다보니 전체 구조에 대한 감각 오류

 

2. 구조에 대한 재인식 Torch backend 는 관측 장치

의도적으로 Torch backend 를 유지한 채 Nsight Compute 를 사용

Torch backend 는 단순임시 구현이 아닌, GPU 커널 실행의 기준 상태 reference 를 제공하는 관측 장치

[Python Framework]
  └─ Module / Trainer / Optimizer
       └─ Backend (TorchBackend)
            └─ torch eager + autograd
                 └─ cuBLAS / CUDA kernels

 이 구조에서 Torch 는

• 정답 구현
• 성능의 기준선
• 커널 흐름의 기준 상태

를 동시에 제공한다.

 

3. NCU 를 통해 확인한 사실

3.1 Torch 연산도 완전히 커널 단위로 관측 가능

Nisght Compute 를 통해 확인한 .ncu-rep 파일에는 다음과 같은 커널들이 등장

• GEMM 계열 ( ampere_sgemm_*, splitKreduce_kernel )
• elementwise 연산 ( vectorized_elementwise_kernel )
• reduction / loss 관련 커널
• autograd backward 경로에서 생성된 커널들

Torch 연산은 블랙박스가 아니라 AICF 커널과 동일한 관점에서 비교 가능한 대상이다.

 

 4. 향후 커널 교체 과정

Torch 커널이 전부 한 번에 AICF 커널로 교체되는 것이 아닌, 점진적 / 혼합적인 교체 과정이다

4.1 교체는 레이어별 / 연산별로 진행됨

초기 단계

• Forward GEMM - AICF 커널
• 나머지 = Torch 커널 유지

중간 단계

• Forward + 일부 backward - AICF
• Loss / optimizer 일부 - Torch

최종 단계

• Forward / Backward / Update 대부분이
  • AICF 커널
  • AICF runtime
  • CUDA Graph replay

4.2 NCU 에서의 변화

• ampere_sgemm_* r감소
• aicf_gemm_* 증가
• Torch elementwise / reduce 감소
• AICF fused kernel 증가

 

5. 구조적 결론

1. Python 프레임워크 스켈레톤은 필요함 - 교체 가능한 frontend 로서의 역할
2. Torch backend 는 기준선
3. 커널 교체는 보이는 상태에서 진행

 

Torch 를 쓰기 위해서가 아닌 Torch 가 실제로 실행하는 커널을 정확히 보기 위해서임