Rich Matrix Optimizer Fusion 현 방식 요약 + 개선 로드맵

1) 목적

그래프 내에서 퓨전 가능한 연산 묶음을 찾아 Forward 를 통합하고, Backward 훅을 주입해 커널 / 런타임 최적화를 하기 위한 규칙 엔진

 

2) 현재 방식 : 행렬 기반 패턴 매칭 + 비트 마스크는 보조 필터

2.1 데이터 모델

• 노드: builder.ops[i] 
• 값 : vid 로 식별, val_to_producer[vid] = producer_op_index
• edge : producer i -> consumer j 

 

2.2 A_rich (rich adjacency)

• A_rich[i, j] 의 data 에 edge 조건 플래그를 bitset 으로 저장

즉, 지금 비트마스크는 엣지 i -> j 가 안전 / 유효한가 만 담고 있음

 

2.3 S(kid) (opkind 선택 행렬)

• S[kid] 는 대각 행렬로, 특정 kind_id 를 갖는 노드만 선택하는 마스크 역할

여기서 Gemm - Bias - Relu 가 명시적으로 kind_id 에 박혀버림

 

2.4 패턴 탐색 방식

• A_valid : A_rich 에서 required bit 만족하는 에싲만 남겨 0/1 인접 행렬로 만든 것
• 그 다음
  • G - B 연결
  • B - R 연결
  • G - B - R 경로 존재
• nonzero 를 뽑아 (i, j, k) 패턴으로 복원

 

2.5 리라이트

• op_g 를 fused op 로 치환
• bwd_emit_fn 훅 주입
• 중간 노드를 nop 로 무효화

 

3. 현재 방식의 장점

• 패턴 탐색이 선언적
• 엣지 필터링은 빠름
• 구현 난이도 대비 결과가 즉시 나옴

 

4. 현재 방식의 한계

4.1 룰이 kind_id 에 강결합

• S 로 노드를 고르는 순간, 룰은 opkind 기반 패턴 매칭이 됨
• 새로운 변형을 늘릴수록 S 종류가 늘고 룰이 분기 폭발

 

4.2 비트 마스크가 엣지 조건에만 국한

• 실제 퓨전 가능성은 노드 특성 쪽이 더 크고 복잡
• 현재는 dtype 정도만 부분적 반영

 

4.3 SAFE_NODE 정의가 거침

• out-degree <= 1 은 분기 없음 힌트 일 뿐이고
  • view / alias,
  • in-place
  • 저장 / 재사용
  • side effect

같은 것들을 충분히 대표하지 못함

 

4.4 행렬곱 방식은 정밀 검증이 약하다

• G - B - R 경로가 있어도
  • 진짜 bias 인지
  • Relu 가 Gemm 출력만 소비하는지
  • 중간 텐서가 다른 곳에서도 쓰이는지
  • shape 일치 / 타입 일치

같은 조건을 별도 검증하지 않으면 오탐 가능

 

4.5 리라이트 안정성

 

 

5. 개선 방향 : 비트마스크 기반 후보 필터 + 로컬 구조 탐색 + 정밀 검증으로 전환

• S 제거 혹은 최소화
• kind_id 가 아니라 속성으로 룰을 정의
• 탐색은 CSR 기반 이웃 순회로 구현
• 최종 fuse 는 정밀 검증을 통과한 경우만 적용