[Paper 리뷰] Fast Hardware-aware Neural Architecture Search

Fast Hardware-aware Neural Architecture Search

---

• 다양하고 많은 양의 hardware에 대해 최적의 convolutional neural architecture를 설계하는 것은 어려움
• Neural Architecture Search (NAS)는 이러한 hardware 다양성 문제를 고려해야함
• HURRICANE
  • 더 큰 search space를 통한 automatic hardware-aware search
  • Two-stage search algorithm을 통한 다양한 hardware 맞춤형 최적화
• 논문 (CVPRW 2020) : Paper Link

---

1. Introduction

• 다양한 유형의 hardware device와 막대한 search cost는 NAS 적용의 주요한 걸림돌임
• Unaware of Hardware Diversity
  • 기존 NAS는 가장 정확한 모델을 찾는 것에 중점을 두지만, 동시에 추론 효율성을 보장하고자 함
  • 모델의 FLOP 제한
    - 가장 일반적인 방식이지만 GPU, DSP, FPGA 등 다양한 설계를 가진 hardware의 AI 가속기에 대응하기 어려움
    - FLOP은 다양한 hardware에서 효율적인 search를 하는데 적합하지 않음
  • FLOP의 부정확성
    : Hexagon 685 DSP, Snapdragon 845 ARM CPU, Movidius MyriadTM X VPU에서 neural network operator 성능 비교
    1. 비슷한 FLOP을 가지고 있어도 서로 다른 processor에서 서로 다른 추론 latency를 보임
       - Choice_3와 Choice_3_SE는 비슷한 FLOP을 가지지만 DSP에 비해 VPU는 24배의 latency 차이를 보임 (그림 a)
       - FLOP은 서로 다른 hardware에서 추론 latency를 측정을 위한 올바른 기준이 아님
    2. Processor 마다 효율적인 operator도 서로 다름
       - Choice_3는 CPU에서 latency가 가장 짧고, SEP_3는 DSP에서 가장 효율적임 (그림 a) 
       - 각 processor의 trade-off에 맞는 서로 다른 operator를 선택할 수 있어야함
    3. 동일한 operator의 연산 복잡도와 latency는 실행 환경에 영향을 받음
       - Input feature map shape, channels 등 (그림 b)
       - 동일한 유형의 hardware라도 최적의 operator는 network의 layer마다 달라질 수 있음

각 processor에서 network operator 성능 비교

-> 그래서 다양한 hardware의 특성에 대응하는 hardware-aware NAS인 HURRICANE을 제안

 

• HURRICANE
  • Hardware 다양성을 커버하기 위해 큰 규모의 candidate operator pool를 구성하고 각 유형의 hardware에 특화된 search space를 자동으로 생성
    - Search cost를 늘리지 않고 hardware-efficient하고 정확한 candidate architecture를 search space에 포함하는 것이 목표
  • One-shot NAS에 대한 two-stage search algorithm
    - sub-network를 순서대로 search하는 방식
    - 각 layer는 latency와 accuracy에 대해서 서로 다른 영향력을 가지기 때문 (layer 다양성)

< Overall of HURRICANE >

• 최소한의 설계로 target hardware에 대한 최적의 search space를 자동으로 생성
• 더 깊은 layer에서 더 많은 architecture를 탐색하여 search space를 줄임

Overall of HURRICANE

2. Methodology

• 주어진 hardware platform $h$ (CPU, DSP,NPU, VPU..)와 latency 상수 $\tau^{(h)}_{c}$에 대해, 아래의 목표를 만족하도록 함
  : (목표) 제약조건 $\tau^{(h)}_{c}$ 보다 작은 추론 latency $\tau(a,h)$에서, 최대의 validation accuracy $ACC_{val}(a)$를 달성하는 architecture $a$를 search하는 것

HURRICANE의 목표

- Hardware-aware Search Space

• Layer-level hierarchical search sapce 디자인을 따름
  • 첫번째와 마지막 3개의 고정 layer를 제외하고 learnable layer는 candidate pool에서 각 operator를 선택함
  • 각 traget hardware에 대해 특화된 search space를 one-shot NAS를 위해 over-parameterized supernet으로 encoding
  • Diverse Candidate Operators Pool
    - 큰 규모의 candidate pool : 다양한 계산 및 메모리 복잡도를 가진 최대 32개의 operator로 구성
    - 4개의 basic structure
    1. SEP : depthwise-separable convolution
       -> 다른 structure에 비해 FLOP이 크지만 메모리 복잡도가 낮음
    2. MB : mobile inverted bottleneck convolution
       -> Shortcut으로 인해 중간 정도의 메모리 비용을 가짐
       -> Kernel size $k$와 exapnsion rate $e$에 의해 결정
    3. Choice : ShuffleNetV2의 basic building block
       -> FLOP이 낮지만 channel split과 concat으로 인해 메모리 복잡도가 높음
    4. SE : squeeze-and-excitation network
       -> 계산 비용은 삽입 위치에 따라서 달라지지만, 메모리 비용은 상대적으로 낮음
       -> Reduction rate $r$을 4로 설정하고, sigmoid를 hswish로 변경
       $hswish[x] = x\frac{ReLU6(x+3)}{6}$

Candidate operator들의 목록

Candidate operator들의 구조

• 큰 candidate operator pool은 hardware의 다양성을 포함하지만, search space도 크게 증가함
  - Search 비용의 증가와 one-shot NAS에서 비수렴 문제를 일으킬 수 있음
• Layer-wise hardware aware search space generation
  • Search space의 효율성을 개선하면서 비용을 줄이고 target hardware에 특화된 search space를 생성하기 위해 제안
    - Hardware deployment score를 활용해 각 layer에서 가장 효율적인 operator를 선택
    - 32개의 operator를 layer 별로 벤치마킹하고 각 layer의 candidate operator를 아래 score를 활용해 non-increasing order로 정렬
  • $score^{(i)}_{op} = (F_{op} \times P_{op})^{\alpha}(\tau_{l_{i}(a)} = _{op}(a,h))^{-1}$
    - $F_{op}$, $P_{op}$ : operator $op$의 FLOP, parameter 수
    - $l_{i}(a) = _{op}$ : $i$-번째 learnable layer가 $op$인 architecture $a$
    - $\alpha$ : 음이 아닌 상수
    - $score^{(i)}_{op}$ : representation capacity와 hardware 성능을 고려한 $i$-번째 learnable layer에서 candidate operator $op$의 score
  • Reduced search space를 구성하기 위해 각 layer에 대해 가장 높은 score를 가지는 first $p$ operator를 선택했을 때, search space의 크기는 $n^{p}$가 됨
    - $n$ : learnable layer의 수
    - 실험에서는 다른 NAS search space와 유사한 크기를 유지하기 위해 $p = 4$로 설정
• Exploring operator
  • 일반적으로 출력에 가까운 layer는 latency에 적은 영향을 주지만 정확도에는 큰 영향을 줌
    - 이러한 learnable layer에는 first $p$ operator 외에 exploring operator를 추가해서 사용
  • Exploring operator는 정확도 향상에 목적을 두기 때문에 score가 높지 않음
  • Hardware 별로 3개의 서로 다른 search space를 구성
    - $n=20$개의 learnable layer를 포함하고 4 / 5개의 candidate operator를 선택 가능
    - $4^{16} \times 5^{4} \approx 10^{13}$개의 possible architecture로 구성

Hardware 별 search space

- Two-Stage NAS Acceleration

• Accuracy와 latency의 layer diversity를 활용하고 one-shot NAS의 비용을 줄이기 위해 제안
• Layer Grouping
  • 서로 다른 CNN layer는 accuracy에 대해 서로 다른 sensitivity를 보임
    - 중요하지 않은 layer에 대한 operator 선택은 최종 성능에 영향이 적음
    -> NAS는 중요한 layer에 대해 최적의 operator를 선택하는 것에 집중해야함
  • NAS에서 개별 layer에 대한 accuracy sensitivity를 분석하는 것은 어려움
    - 초반부 layer : input에서 저수준의 feature를 추출하고, 계산 집약적이고, 수렴하는데 많은 데이터를 요구함
    - 후반부 layer : 고수준의 class별 feature를 캡처하고, 덜 계산 집약적임
    -> 후반부 layer에 대한 operator 선택이 초반부 layer보다 중요함
  • CNN 모델의 $n$ layer를 두개의 그룹으로 분할
    - 초반부 $t$ layer (비교적 덜 중요함)
    - 후반부 $n-t$ layer (중요함)
• Two-Stage Search Algorithm
  • 각 단계는 서로 다른 winning architecture로 시작해 one-shot NAS를 통하여 learnable layer의 target group을search 함
    - Winning architecture의 layer operator를 활용하고 나머지는 non-active fixed layer로 취급
    - 모든 layer에서 가장 높은 score를 받은 operator를 initial winning architecture $a_{win0}$로 설정
  • Stage 1.
    1. $a_{win0}$에 대해 후반부 $n-t$ layer를 search
    2. $n-t$ layer를 active로 표시하고 이전 $t$ layer를 non-active로 표시
    3. non-active layer는 architecture $a_{win0}$의 해당 layer에 고정됨
    4. active layer는 생성된 operator list $l_{i}(A)$에서 search 됨
    5. One-shot NAS는 FLOP 이외에 hardware latency로 search space를 제한
    6. One-shot NAS를 통해 새로운 winning architecture $a_{win1}$ 생성
  • Stage 2.
    1. 새로운 winning architecture $a_{win1}$으로 시작해 이전 $t$ layer를 search
    2. $n-t$ layer는 $a_{win1}$의 해당 layer로 고정되고 이전 $t$ layer는 One-shot NAS를 위해 active됨
    3. Stage 2.를 통해 최종 architecture $a_{win2}$를 return

Two-Stage NAS Acceleration

• Layer grouping boundary $t$는 acceleration의 성능에 영향을 미침
  • $t=0$일 때 전체 $n$개의 learnable layer를 search하므로 NAS 비용이 줄어들지 않음
  • $t$가 크면 supernet 학습 시간이 줄어들지만 최적 architecture search가 어려울 수 있음
    - 논문에서는 $t=8$로 설정

3. Evaluation

- Settings

• Mobile hardware
  - DSP : Qualcomm Hexagon 685 DSP
  - CPU : Qualcomm Snapdragon 845 ARM CPU
  - VPU : Intel MovidiusTM MyriadTM X Vision Processing Unit
• Latency 제약
  - CPU : 310ms
  - DSP : 17ms
  - VPU : 36ms
• 1000개 architecture에 대한 evolutionary search

- Searching on ImageNet Dataset

• HURRICANE는 76.67%의 top-1 accuracy를 달성하여 MobileNetV2와 비교해 모든 hardware platform에서 2.59%~4.03%의 성능 차이를 보임
• Latency 측면에서는 DSP에서 16.5ms를 달성하여 FBNet에 비해 6.35배 빠른 속도를 보임
• 동일한 target hardware에 대해서 기존의 SOTA NAS 방법들보다 높은 성능을 보임

ImageNet에서 성능 비교

• HURRICANE이 동일 수준 CPU에서 가장 높은 accuracy를 달성하고 1.62~2.77배 낮은 추론 시간을 보임

CPU에서 성능 비교

- Ablation Study and Analysis

• Hardware 특화 search space는 수동으로 설계한 search space 보다 훨씬 짧은 latency를 보임

Search space 별 latency 비교

• Hardware-aware search space를 사용했을 때 직접 설계한 search space 보다 높은 accuracy을 보임
  • DSP에서는 +0.87%, CPU에서는 +0.5%, VPU에서는 +0.31%

Search space 별 accuracy 비교

• Hardware Insight
  • Hexagon 685 DSP
    - 작은 kernel convolution ($k \leq 3$)에 최적화되어 있음
    - Search space에 작은 kernel이 있는 복잡한(큰 FLOP을 가지는) operator를 포함함
    -> HURRICANE-DSP가 다른 NAS 모델들보다 빠르지만 FLOP이 큰 원인
  • Myriad X VPU
    - SE 모듈은 VPU에서 지원되지 않으므로 효율성이 낮음
    - 큰 kernel ($k = 7$)의 convolution은 다른 hardware 보다 효율적으로 수행됨
  • Snapdragon 845 ARM CPU
    - ShuffleNetV2에서 사용된 모듈(Choice 3)이 가장 효율적인 operator

Hardware별로 search된 network architecture

• 전체 learnable layer ($n=20$)을 전역적으로 search하는 기존 NAS와는 달리 two-stage algorithm은 12개의 후반부 layer와 8개의 전반부 layer로 그룹화함
  • Stage1만으로도 비슷한 top-1 accuracy를 달성할 수 있고, train iteration은 60%~77.5% 감소함
  • Stage2까지 적용하는 경우, accuracy는 0.14%~1.06% 향상됨
    - train iteration은 4.0%~8.8% 밖에 추가되지 않음

Two-stage Algorithm의 효과 비교