본문 바로가기

전체 글

 (1642)
AICF Emit IR - Classical Compiler IR 와의 대응 관계 정리 1. 목적과 배경AICF 의 emit 계층은 코드 생성 단계가 아닌, 의미가 이미 해석된 연산을 실행 단위로 고정하는 단계 2. 고전 컴파일러 관점에서의 IR 재정의2.1 고전적 IR 의 핵심 성질Classical Compiler 에서 Intermediate Representation 은 다음 성질을 가진다의미 보존적 Semantics-preserving명령 단위 표현 instruction-level입력과 출력의 명확한 관계타겟 독립성 또는 제한적 타겟 의존성최적화 패스의 입력으로 사용 가능 3. Emit IR 의 위치 정의 ( IR 레벨 구분 )AICF 는 다음 IR 계층을 가진다[ Python Layer / Builder 호출 ] ↓[ AICF Logical IR ] ← ..
Linear layer 를 통한 설계 의도 관찰 역할Linear 는 고수준 레이어지만, 실제 실행은 GEMM + (optional) BiasADd 의 emitter 시퀀스로 내려간다 y / y2 의 분리 이유 : 출력 버퍼 소유권과 후속 최적화 선택권을 planner 에게 넘김y = b.value(f"{self.name}.out", y_spec) # gemm outputy2 = b.value(f"{self.name}.out_bias", y_spec) # bias_add output이러한 두 개의 value 를 만든 의도는IR 상에서 데이터 흐름을 명확히 하기gemm 의 결과는 ybias_add 의 결과는 y2그래프를 보면 Linear 는 2-step 이 눈에 띄게 드러남inplace / alias 를 기본값이 아니라 플래너 결정으로 ..
lower / optimize_plan 제거 파이프 라인 기존 구조가 emit - lower - plan - runtime 이었음lower 가 사실상 이미 정해진 정보를 옮겨 적는 단계가 되면서 불필요해짐emitter 가 backend-ready 정보를 미리 채우고, compile 은 alias 정책 결정만 수행하는 방식 1) 생성되는 데이터 구조들1.1 Value ( Builder.values[] )Builder 내부에서 텐서 단위를 vid 로 관리한다.Value.vidValue.specValue.role : input | param | state | tmp | outputValue.producer_op, Value.users 1.2 Op ( Builder.ops[] )Layer / Emitter 가 연산을 추가하면 Op 가 쌓인다.기존에는 Op 에 ki..
AICF v2 실행 파이프라인 - 함수 단위 호출 트레이스 0. 사용자 진입점Model.add파일src/aicf_v2/model.py호출 흐름y = m.add(layer, *args)실제 동작return layer.emit(self.b, *args, ctx=self.ctx)BuilderEmitContext 를 Layer.emit 에 전달하는 조율자 역할 1. Layer 단계 ( 고수준 의미 - IR 노드 생성 )src/aicf_v2/layers/linear.pysrc/aicf_v2/layers/relu.pysrc/aicf_v2/layers/adam_step.py역할수학적 의미를 IR 로 분해shape / dtype / device 검증Value 생성어떤 emitter 를 쓸지 결정 생성 데이터valuevid = b.value(name, TensorSpec(.....
AICF v2 실행 파이프라인 ( optimize 생략 버전 ) 큰 그림Layer.emit / Model.addBuilder 에 value 와 Op 쌓음여기서 CUDA 호출에 필요한 불변 정보를 emitter 가 미리 쌓음compile_cudaBuilder - lower_ir_cuda 로 LoweredOp 생ㅅ어make_exec_plan_cuda 로 런타임 결정을 담은 ExecPlan 생성CudaExecutor.run / run_compiledfeed 로 들어온 tensor 를 value 슬롯에 bind / allocplan.alias 적용plan.lowered 순서대로 _C.op_call 실행선택적으로 CUDA Graph capture / replay 로 반복 실행 최적화 1) IR 생성 단계 Layer - BuilderModel.add 가 하는 일model.add..
Layer 내부에서의 emit 정의 및 사용 방식의 변경, 사전 정의 op emitter 의 생성으로 lower_ir_cuda 의 기능 축소, 전체 로직 간편화 핵심은Layer 는 의미 semantic 만 조립하고실제 emit 은 사전 정의된 op emitter 가 담당backend 지식을 갖고 있고, Builder.emit 에 캐시까지 채워 넣을 수 있음Layer 가 backend 를 모르는 것과 emit 단계에서 backend 정볼르 활용한 중복 제거를 동시 해결 1) OpEmitter 레이어의 생성레이어 / 역할 분리Layer : 그래프를 어떤 의미로 구성할지 결정OpEmitter : 특정 op 를 Builder 에 기록하는 표준 방식Registry / ABI : OpEmitter 가 사용Layer 는 다음과 같이 사용emitters.adam_step(b, P, G, M, V, bc1, bc2, outP, outM, outV, lr=..., beta1=...
compile 파이프 라인과 lower_ir_cuda 에서의 registry 탐색 ( b.ops 와 사전 정의한 registry 와의 매칭 compile 파이프라인에서 각 단계가 보는 것1) b0 = m.bLayer.emit 으로 쌓인 IR 의 원본 2) b1 = optimize_ir(b0)아직 identity 3) lowerd = lower_ir_cuda(b1, registry)핵심 IR - 실행 가능 단위 변환b1.ops 순회op.kind 를 registry 에서 탐색op.attrs 를 kernel ABI 가 요구하는 attr_blob 로 패킹lop 같은 lowered op 리스트 생성 4) plan = make_exec_plan_cuda(b1, lowered)여기서 plan 의 생성 메모리 / alias / workspace / 실행 순서이걸 executor 가 실행 5) plan = optimize_plan(plan)이것도 아직 ..
CUDA Graph Capture / Replay 설계 정리 torch.cuda.CUDAGraph 기반 실행 경로를 추가execution plan 을 한 번 캡처하고이후 반복 실행에선 graph.replay 로 커널 런칭 오버헤드 최소화tranining 모드에서는 optimizer step / param 이 feed 로 덮어써지지 않도록 안전한 포인터 / 복사 정책 보장 1. 전제 CUDA Graph 의 핵심 제약캡처 시점에 사용된 GPU 메모리 포인터가 replay 에서도 동일해야 한다는 제약매 step 마다 새로 생성되는 텐서를 그대로 입력으로 쓰면 포인터가 바뀌고 캡처 / 리플레이가 깨짐외부 입력을 직접 쓰는 것이 아닌 고정 버퍼로 copy 해서 사용한다. 2. 역할 분리 input / param / stateBuilder 에 externals 을 분리inp..

티스토리툴바