경량화에 Nas가 필요한 이유

경량화에 Nas(Neural Architecter Search)가 필요한 이유는 연구의 흐름을 살펴봐야한다.
mobileNet을 필두로 squeeze and exited, effientNet 등등 경량화의 테크닉들이 점점 개발되었다.

경량화에 레이어 테크닉이 개발되면 이 레이어들을 어떻게 배치해서 최적의 아키텍처를 만들것인지 연구하는 게 자연스러운 흐름이였다.

인간이 직접 만든 아키텍처가 아닌 기계가 학습하여 자동으로 경량화 아키텍처를 만들자는 게 Nas와 경량화이다.

Nas와 model compression은 자연스럽게 같이 발전하였고 요즘 유행하는 attension과 transformer 또한 자연스럽게 편입되어 발전되었다.

현재 2024년 mobileNet v4를 기준으로 경량화엔 경량화 레이어와 테크닉, Nas, attension 등이 모두 포함하여 연구되고 있다.

따라서 경량화 연구와 아키텍처를 직접 구현하기 위해선 Nas를 이해하고 직접 구현해야 한다.

역경과 고난

그런데 이런 최신 경량화 아키텍처에서는 보통 Nas에 관한 직접적인 구현은 모델 공식 깃허브에 기재되어 있지 않다.

공식 깃허브 또는 사람들이 구현한 아키텍처의 경우 논문에서 직접 찾은 모델의 실제 레이어 구조만을 구현하고 있다.

예를 들어서 특정 블럭엔 레이어가 어떤 순서대로 들어가는지 실험값이 나왔다면 그걸 직접 손으로 구현하는 식이다.

이런 식의 구현이 대부분인데 Nas의 목적과 상반되는 구현이다.

내 플랫폼과 데이터셋에서 상업적으로 가장 최선의 아키텍처를 만드는 것이 경량화와 Nas의 목표인데 구글과 같은 연구소의 환경과 기업, 개인의 환경은 같지 않기 때문에 이런식의 구현은 쓸모가 없다.

하지만 대부분 구현은 Nas를 직접 구현하지 않은 경우가 대부분이고 인터넷에 자료 또한 없다.

그게 내가 지금 4개월이 지나도록 논문을 대충 100편 정도 읽으며 직접 구현할려고 삽질하는 이유다.

경량화에 관련된 Nas의 발전 흐름

경량화에 관련된 Nas의 모든 논문을 읽은 것은 아니나 현재 읽은 것을 토대로 발전 흐름을 설명하겠다.

weight shared

Nas의 경량화에 관한 연구의 시초는 Enas다.
초기 Nas는 아키텍처를 search 할 때 마다 파라미터와 weight를 매번 초기화 해서 자원의 소비가 심했다.

그래서 하나의 weight를 만들어 아키텍처를 뽑을때마다 계속 사용하고, 또 학습하는 식으로 초기화를 한 번만 하는 방식이 weight shared다.

이 방식으로 Nas의 경량화가 시작되었다.

platform aware Nas

경량화와 직접적으로 연관된 Nas의 시작은 Mnas에 있다.
물론 다른 nas가 사전에 있을 수 있으나 내가 사용하고 있는 플랫폼을 인지해서 아키텍처를 search하는 Mnas는 경량화 테크닉과 Nas가 함께 적용되는 nas의 시초이다.

mnas는 내가 사용하고 있는 기기에서 모델의 accuracy 뿐만 아니라 latency를 직접 측정하여 RL 방식으로 아키텍처를 search 하는데 사용하였다.

따라서 accuracy와 latency 간의 밸런스를 갖춘 model을 만들 수 있었다.

이 Mnas를 기점으로 많은 경량화 아키텍처에서 Mnas를 이용하여 자동으로 구조를 만들기 시작했다.

Darts

DARTS는 NAS를 연속적인 최적화 문제로 변환하여 차별화 가능한 방식으로 해결하는 아이디어를 제시했다. 기존 강화학습 기반 방식에 비해 훨씬 효율적이어서 NAS 연구의 큰 진전으로 평가받고 있다.

oneshot, single path one shot, proxyless, once_for_all

weight shared와 platform aware nas를 발전시킨 논문들로 random search, 메타 컨트롤러를 이용를 이용하던 기존의 nas 방식대신 supernet를 mask와 path pruning 등을 이용하여 좀 더 효율적으로 개선하였다.

실험에서 weight shared의 효용성, random search와 진화적 search의 비교등을 알아내었다.

프로젝트에 연관된 Nas

프로젝트에 연관된 Nas의 순서는 다음과 같다.

Enas - Mnas - oneshot - single path one shot - proxyless - once_for_all - tunas

대략적인 발행 순서와는 맞지 않겠지만 지금 생각엔 위와 같은 순서로 검토 후 tunas를 만들 것 같다.

시리즈의 부록인 Enas의 구현은 oneshot nas부터 무용지물이기 때문에 weight shared의 개념만 읽는 것을 추천한다.