임종국 (제이마플)
limjk@jmarple.ai
2021. 12. 04 @MODUCON 2021
실용적인 딥러닝 모델 경량화 &
최적화를 해보았습니다
논문에서는 좋다는데 정말 좋은가요?

J.Marple 은 뭐하는 회사죠?
• 우리는 어려운 문제를 해결하는 전략 AI 기술을 연구 개발합니다.
• 우리 기술의 첫 번째 응용 분야는 무인기용 전략 AI 입니다.
제이마블 아닙니다. 제이마플 입니다.
- 드론에 AI 를 입히려면 딥러닝 모델이 필요합니다.
- 전략 AI 기술이 되려면 속도가 빨라야 합니다.
- 드론은 배터리를 사용하여 비행 합니다.
- 딥러닝 모델은 대체적으로 큽니다.
- 딥러닝 경량화가 필요합니다.
저희가 더 궁금하시다면 아래 링크를 방문해주세요.
https://jmarple.notion.site

경량화 하면 뭐가 좋나요?
비용이 감소합니다. 성능이 증가합니다.
같은 작업을
더 적은 서버의 수로
할 수 있습니다.
배터리를
아낄 수 있습니다.
더 오래 일을 시킬 수 있습니다.
속도가 빨라집니다.
일을 빨리하니 더 많은 일을
줄 수 있습니다.
네트워크 트래픽을
감소시킬 수 있습니다.

우리가 생각하는 경량화와 실제 적용되는 경량화
• Pruning 은 경량화에 도움이 될까요? ▵
• Quantization 은 경량화에 도움이 될까요? ▵
일부 경량화 방법은 하드웨어와 밀접한 관계를 가지기 때문에
원하는 목표 디바이스에서 실용적인지 확인이 필요합니다.
* INT8 quantization 으로 경량화 했는데,
V100 에서 모델이 돌아간다면?

딥러닝 경량화 기술과 하드웨어
Low-precision support (Quantization)
i.e. XNOR-Net - bit operation 으로 좋은 성과를 보여주었습니다.
- 실제 적용은?
-> CPU, GPU 에서 다시 형변환을 거쳐 연산 후, 다시 형변환
이상 현실
형변환 XNOR 연산 bit 형변환
최근 칩 제조회사에서 딥러닝 가속 프로세서를 별도로 두는 것이 대세가 됐으니,
언젠가 XNOR-Net 같은 모델도 가속화가 지원되겠죠?
[1] Mohammad Rastegari, Vicente Ordonez, Joseph Redmon, Ali Farhadi, XNOR-Net: ImageNet Classification Using Binary Convolutional Neural Networks, 2016

딥러닝 경량화 기술과 하드웨어
Sparse Tensor (Pruning)
i.e. The Lottery Ticket Hypothesis - 다수의 weight을 pruning 해도
성능이 잘나온다는 것을 보여주었습니다.
- 실제 적용은?
-> 0을 포함한 모든 tensor 그대로 연산
[2] Jonathan Frankle, Michael Carbin, The Lottery Ticket Hypothesis: Finding Sparse, Trainable Neural Networks, 2018
이상
Pruning 되지 않은
weight 만 연산
0
0
현실
그냥 0이
많은 모델
속도 ⬆
용량 ⬇
속도 -
용량 -
GPU의 연산 방식 특성상 Pruning을
가속화하기 어렵습니다.
Q) 그러면 Pruning은
실용적이지 못한가요?
A)

딥러닝 경량화 기술과 하드웨어
Depthwise Separable Convolution 은 항상 빠를까요?
이론적으로는 그럴 것 같습니다.
- 실제 적용은?
-> 하드웨어가 한번에 계산할 수 있는 양에 따라 다릅니다.
[3] Andrew G. Howard, Menglong Zhu, Bo Chen, Dmitry Kalenichenko, Weijun Wang, Tobias Weyand, Marco Andreetto, Hartwig Adam, MobileNets: Efficient
Convolutional Neural Networks for Mobile Vision Applications, 2017
128x256x3x3 = 294,912 128x256x3x3 = 33,920
연산 요청 연산 요청 연산 요청
이미 레이어가 많이 작다면
일반 Convolution이 더 빠를 수 있습니다.

딥러닝 경량화 기술과 하드웨어
CNN vs Transformer
Transformer 는 이제 대세라고 불려도 될 듯 합니다. 경량화에 적합할까요?
i.e. MobileViT
- 실제 적용은?
-> 하드웨어와 소프트웨어 둘 다 아직까지는 CNN 연산에 맞는
최적화가 더 많이 되어 있기 때문에 아직은 지켜봐야 할 것 같습니다.
성능은 경량 모델로서 잘 나오지만 CNN에 비해 속도가 많이 느립니다.
속도가 중요하다면 조금 더 지켜보는 것도 좋습니다.
[4] Sachin Mehta, Mohammad Rastegari, MobileViT: Light-weight, General-purpose, and Mobile-friendly Vision Transformer, 2021

딥러닝 경량화 기술과 소프트웨어
• 소프트웨어로 경량화를 하는 법 2가지
1. 새로운 아키텍쳐를 만듭니다.
- Domain-dependent (Mostly)
- MobileNet, MobileViT, …
2. 이미 만들어진 아키텍쳐를 압축합니다.
- Domain-independent
- Pruning, Quantization, Tensor
decomposition, …
FPGA를 하지 않는 이상, 우리가 하드웨어를 고칠 수 없습니다.
할 수 있는걸 합시다.
새로운 아키텍쳐를 만드는게 쉬운일이 아닐텐데요?
- AutoML 로 원하는 모델을 찾아보도록 하겠습니다.
(이걸로는 논문 쓰기 쉽지 않을거에요.)
아까 Pruning 쓸모 없다고 한 것 같은데…
- 잠시 뒤에 공개 됩니다.

아키텍쳐를 자동으로 찾아봅시다.
새로운 딥러닝 블럭을 만드는 것은 쉬운일이 아닙니다.
하지만 이미 공개되있는 블럭 중 무엇이 우리가 원하는 목표에 맞는지 자동으로 찾아본다면 어떨까요?
import optuna
def objective(trial):
x = trial.suggest_float('x', -10, 10)
return (x - 2) ** 2
study = optuna.create_study()
study.optimize(objective, n_trials=100)
study.best_params # E.g. {'x': 2.002108042}
Hyper-parameter search에 유용한 프레임워크지만
유연하게 사용이 가능하여 AutoML 로 활용
Optuna로 만들어진 모델을
weights & biases 에서 관리

아키텍쳐를 자동으로 찾아봅시다.
AutoML 을 활용하여 경량화를 하기 위해서는 아래 2가지 조건을 만족시켜야 했습니다.
1. 자동으로 모델을 찾으려면 자동으로 다양한 모델을 만들수가 있어야 합니다.
2. 만들어진 모델을 다른 프로젝트에서도 쉽게 불러와 다양한 시도를 할 수 있어야 합니다.
Optuna를 활용하여 AutoML 을 하려니 문제가 있습니다.
자동으로 모델을 생성하도록 만들기가 쉽지 않습니다.
- 모든 레이어의 입력 channel 수가 어떻게 되는지 계산 해야합니다.
- 이미지 사이즈에 맞게 입력 channel 바뀌는 경우도 있습니다.
- 그 외에 고려해야 할 사항이 너무 많습니다.
YOLOv5 는 yaml 으로 모델을 만드는데 이걸 일반화시키면 좋지 않을까요?

아키텍쳐를 자동으로 찾아봅시다.
Yaml 파일로 모델 쉽게 만들기 (https://limjk.ai/kindle)
- 매번 계산하기 번거러웠던 image size, 입력 channel 을 자동으로 계산합니다.
- yaml 으로 모델을 구성하기 때문에 모델 변경이 쉽습니다.
- 새로운 모듈이 필요하면 python 코드 또는 yaml 파일로 만들 수 있습니다.
- pip install kindle 로 설치가 쉽기 때문에 다양한 프로젝트에서 사용이 가능합니다.
input_size: [32, 32]
input_channel: 3
depth_multiple: 1.0
width_multiple: 1.0
backbone:
[
[-1, 1, Conv, [6, 5, 1, 0], {activation: LeakyReLU}],
[-1, 1, MaxPool, [2]],
[-1, 1, nn.Conv2d, [16, 5, 1, 2], {bias: False}],
[-1, 1, nn.BatchNorm2d, []],
[-1, 1, nn.ReLU, []],
[-1, 1, MaxPool, [2]],
[-1, 1, Flatten, []],
[-1, 1, Linear, [120, ReLU]],
[-1, 1, Linear, [84, ReLU]],
]
head:
[
[-1, 1, Linear, [10]]
]
from kindle import Model
model = Model("example.yaml"), verbose=True)
자세한 내용은 https://github.com/JeiKeiLim/kindle을 참고해주세요.

아키텍쳐를 자동으로 찾아봅시다.
이제 자동으로 모델을 만들기가 쉬워졌습니다.
어떻게 찾아야할까요?
Width Depth Resolution
[5] Mingxing Tan, Quoc V. Le, EfficientNet: Rethinking Model Scaling for Convolutional Neural Networks, 2020
Block
EfficientNet 사용하는 3가지 파라미터 + 찾고자 하는 블럭의 종류
Time # param Metric
S E A R C H 2. 모델 자동 생성
4. 평가
1. Search space 정의
3. 학습

아키텍쳐를 자동으로 찾아봅시다.
이제 자동으로 모델을 만들기가 쉬워졌습니다.
어떻게 찾아야할까요?
Width Depth Resolution
[5] Mingxing Tan, Quoc V. Le, EfficientNet: Rethinking Model Scaling for Convolutional Neural Networks, 2020
Block
EfficientNet 사용하는 3가지 파라미터 + 찾고자 하는 블럭의 종류
Time # param Metric
S E A R C H 2. 모델 자동 생성
4. 평가
1. Search space 정의
3. 학습
시간이 너무 오래 걸리는데
여러 머신에서 동시에 찾을 수는 없을까요?

아키텍쳐를 자동으로 찾아봅시다.
그래도 시간이 너무 오래 걸리네요. 더 빨리 모델을 찾아볼 수는 없을까요?
1. 데이터가 충분하다면 학습 데이터셋을 줄여서 학습 해봅니다.
2. epochs를 적게 사용 합니다.
- 될성 부른 나무는 떡잎부터 좋더라구요.
3. Search space 를 줄여봅시다.
- AutoML 을 하는 이유는 데이터만 주면 알아서 좋은 모델을 찾기 위한게 아닙니다. (그러면 좋겠지만요)
- 검증해봐야할 가설은 많은데 일일히 검증하기 어려우니 자동으로 찾아보는 시각으로 접근하는게 좋습니다.
- 내가 퇴근하고 잠자는 도중에도 컴퓨터가 나 대신 일하고 있는 기분을 느껴봅시다.

만들어진 모델을 압축해봅시다.
Tucker Decomposition
- 하나의 큰 Tensor X를 모사하는 여러개의 Tensor들로 쪼개는 역할을 합니다.
i.e. 128x256x3x3 Convolution은 128x64x1x1 · 64x32x3x3 · 32x256x1x1 으로 표현이 가능합니다.
Parameter 수 비교
- 128x256x3x3: 294,912
- 128x64x1x1 · 64x32x3x3 · 32x256x1x1: 34,816
약 88% 감소
실제로 적용해보니?
- 성능이 많이 안좋았습니다.
모든 Convolution Layer를 Decomposition 하니
정보 손실이 너무 심했기 때문입니다.
͌
128x256x3x3 128x64x1x1 · 64x32x3x3 · 32x256x1x1

만들어진 모델을 압축해봅시다.
Tucker Decomposition
모든 Convolution Layer를 Decomposition 적용해서 정보 손실이 심한게 문제라면
Decomposition 이후에도 정보 손실이 적은 Layer에만 Decomposition 을 적용하면 되지 않을까요?
Random Tensor
𝔁
Original
Convolution
Layer
Decomposed
Convolution
Layer
ŷ ỹ
Error(ŷ-ỹ) 가
낮은 Layer만 사용
Parameter 수는 이전보다 적게 줄어들었지만 성능 저하가 현저히 줄어듬
원본 대비 파라미터 수 약 40% 감소
성능 저하 COCO val2017 기준 mAP50 약 1% 저하

0
0
만들어진 모델을 압축해봅시다.
Tucker Decomposition + Pruning
Decomposition은 결국 Convolution layer의 weight을 모사하는 과정입니다.
Weights 내부에 0이 많으면 더 작은 사이즈의 Tensor 로도 Decomposition이 가능하지 않을까요?
Random Tensor
𝔁
Original
Convolution
Layer
Decomposed
Convolution
Layer
ŷ
ỹ
Error(ŷ-ỹ) 가
낮은 Layer만 사용
Pruning
이전과 동일한 레이어를 Decomposition 하는
경우에도 파라미터 수 감소효과를 보임.
약 5% 정도 추가 감소

0
0
만들어진 모델을 압축해봅시다.
Tucker Decomposition + Pruning Ratio Binary Search
파라미터 수 감소 효과는 대부분 Pruning의 비율과 비례하였습니다.
레이어 별로 Pruning을 많이 해도 되는 레이어가 있고,
그렇지 않은 레이어가 있지 않을까요?
Random Tensor
𝔁
Original
Convolution
Layer
Decomposed
Convolution
Layer
ŷ
ỹ
Error(ŷ-ỹ) 에 따라서
Pruning ratio 조정
Pruning
Binary Search 를 이용한
Pruning ratio 결정
약 2% 정도 추가 감소

만들어진 모델을 압축해봅시다.
Tucker Decomposition + Pruning Ratio Binary Search 결과는?
원본 모델: YOLOv5x
# param: 86,705,005
Inference time(COCO val2017): 295.2s
mAP50(COCO val2017): 68.1%
Decomposed 모델
# param: 54,451,160
Inference time(COCO val2017): 255.611
mAP50(COCO val2017): 68.1%
파라미터 수 약 37.2% 감소
추론 속도 약 13.4% 감소
finetune 없이 성능 저하 없음
Finetune과 소폭의 성능 저하를 허용한다면 더 적은 수의 파라미터로 압축이 가능합니다.

더 빠르게 할 수 없을까요?
1. GPU에서 FP16을 지원한다면 Half Precision 만 사용해도 속도 향상을 얻을 수 있습니다.
2. CPU-GPU 병렬화를 고려해주세요.
- CPU-GPU 간 메모리 이동을 정말 필요한 경우 아니면 지양 해주세요.
- 불가피 하다면 Threading 으로 처리하여 병목 현상이 안생기도록 해주세요.
- Threading 으로 처리한다면, 메모리 이동 중에 Tensor 의 값이 바뀌지 않는지 주의해주세요.
3. TensorRT 를 사용할 수 있다면 반드시 적용하는게 좋습니다.
4. TensorRT를 못쓴다면, libtorch C++ 을 사용해도 속도 향상을 볼 수 있습니다.
5. 각 Layer 별로 속도 profiling 을 하여 병목 현상이 생기는 지점이 있는지 확인해주세요.

마무리
모델 경량화가 잘 되었어도, 최적화 여부에 따라 실제 성능은 천차만별
이미지 디코딩은 어디서?
CPU? GPU?
전처리는 어디서?
CPU? GPU?
멀티 코어 활용
CPU가 일한다고
GPU를 놀게 하지 맙시다.
모델 추론
이미지 캐싱 여부
• 결국 Trade-off 를 잘 설정해야 만족스러운 경량화를 달성할 수 있습니다.
- 목표 어플리케이션과 하드웨어의 스펙에 맞는 목표 설정 필요
- E.g., INT8, FP16 연산 지원 및 연산자 개수, 가용 메모리, CPU 코어 개수 등 ...
• CPU-GPU 자원 분배 적절하게
• 디스크 <-> CPU 메모리 <-> GPU 메모리 간의 이동 속도 프로파일링
• 실용적인 딥러닝 경량화는 엔지니어링임을 잊지 맙시다.

감사합니다.