AICF v2 실행 과정 정리

여기서 컴파일러의 역할 요약

IR 로 표현된 모델 실행을, 런타임 판단 엇이 결정이 고정된 커널 시퀀스로 변환하고 그 결정 결과를 실행, 캡처, 리플레이까지 일관되게 유지하는 것

 

1. 전체 파이프라인 개요

Python Model
   ↓
[Trace]         symbolic IR 생성
   ↓
[Lower Stage A] 연산 분해 + dtype 기반 kernel_id 결정
   ↓
[Lower Stage B] shape / alignment 기반 kernel 업그레이드
   ↓
[Plan]          메모리/바인딩 결정
   ↓
[Exec]          kernel_id 기반 실행 (dispatch 금지)
   ↓
[Capture]       CUDA Graph 고정
   ↓
[Replay]        완전 결정 재사용

 

2. Trace 단계 — “의미”만 기록

역할

• Python 연산을 의미적 IR로 변환
• 실행하지 않는다
• shape, dtype, 의존성만 보존

특징

• Linear, ReLU, SgdStep 같은 고수준 의미 노드
• 아직 커널 개념 없음
• 동적 제어 흐름이 있어도 IR로 정규화 가능

결과물

• IRGraph
  • values (tensor spec)
  • nodes (semantic ops)

이 단계는 Framework 역할에 가깝다.

 

3. Lower Stage A — 연산 분해 + 1차 결정

역할

• IR 노드를 primitive op 시퀀스로 변환
• dtype 기반으로 kernel_id 1차 선택
• “이 op는 이 커널 계열을 쓴다”를 컴파일 타임에 결정

예시

 

Linear 
    → gemm + bias_add 
    → kernel_id = gemm_f16_tc_wmma_out_f16_v0

특징

• 런타임 dispatch 없음
• kernel_id가 문자열로 IR에 박힘
• 아직 성능 최적화는 최소한

이 시점부터 Compiler 영역에 진입한다.

 

 

4. Lower Stage B — 하드웨어 조건 기반 업그레이드

역할

• Stage A에서 결정된 kernel_id를
• shape / alignment / numel 조건을 보고 교체

대표 예시

• sgd_step_f16 → sgd_step_f16_half2
• bias_add_f16 → bias_add_f16_vec2
• relu_f16 → relu_f16_vec2

특징

• 동일 의미, 다른 커널
• 조건이 안 맞으면 교체 안 됨
• 교체 결과도 kernel_id로 고정

이 단계는 **전통적 컴파일러의 “target-specific lowering”**에 해당한다.

 

 

5. BindingPlan — 실행 환경 결정

역할

• 모든 value에 대해:
  • input / param / static 분류
  • 메모리 위치 결정
• 재사용 가능한 static buffer를 명시적으로 분리

중요한 점

• 여기서 alias / in-place 여부가 고정
• execution 중 메모리 판단 없음

결과

• BindingPlan
• 이후 실행은 plan을 그대로 따른다

 

 

6. Exec — 결정된 커널만 실행

핵심 정책

 

ExecOptions(require_kernel_id=True)

이 옵션의 의미는 매우 중요하다.

kernel_id 없는 op는 실행 자체를 금지한다

실행 방식

• _C.launch_by_id(kernel_id, kind, ...)
• _C.op_call (런타임 dispatch) 사용 금지

결과

• 실행 중:
  • kernel 선택 ❌
  • shape 판단 ❌
  • dtype 판단 ❌
• 오직 컴파일 결과만 사용

이 시점에서 AICF는 순수 실행 엔진이다.

 

 

7. Attr Schema — 파라미터도 컴파일 산출물

예: SGD lr

• lr을 Python에서 직접 넘기지 않음
• AttrBlob(schema_id="SGDS", payload=float32 lr)
• kernel은 schema_id 기반으로 파싱

의미

• 하이퍼파라미터도
• “런타임 변수”가 아니라 컴파일 입력

이것은 딥러닝 컴파일러에서 흔히 빠지는 부분을 정확히 잡고 있음

 

8. Capture / Replay — 실행 그래프의 고정

Capture

• 이미 kernel_id로 고정된 실행을
• CUDA Graph로 캡처

Replay

• 동일 graph를 반복 실행
• 결정 경로 완전 제거

중요한 점

• capture 시점에도 kernel_id가 동일
• replay 시점에도 변경 불가

여기서 비로소 **“실행 = 데이터만 바뀌는 과정”**이 된다.

 

9. Trace by ID — 검증 가능한 컴파일러

trace 결과 예

 

kid:sgd_step_f16_half2_v0 kind:sgd_step

의미

• “어떤 커널이 실행됐는지”를
• 정확히 재현 가능
• 성능·정확도 디버깅이 가능

이건 단순 로그가 아니라
컴파일 산출물의 실행 증명서다.

 

10. 지금 AICF v2의 Compiler적 정체성

정리하면 AICF v2는:

• ❌ 그래프 최적화 중심 컴파일러
• ❌ 자동 튜닝 시스템
• ❌ 런타임 적응형 엔진

대신

• ✅ 결정 시점이 명확한 컴파일러
• ✅ kernel selection을 컴파일 타임에 고정
• ✅ 실행/캡처/리플레이가 동일한 결과를 보장
• ✅ 디버깅 가능한 AI Compiler