da2so

[파리] 헬스장 Neoness Paris 리뷰

Sin-Han Kang — Mon, 12 May 2025 19:17:00 +0900

파리 여행을 2025년 4월 29일부터~5월5일까지 다녀왔습니다.

호텔은 오페라 가르니에(Palais Garnier) 근처였고 파리의 헬스장을 가려고 와이프 허락받고 갓다왔습니다.ㅋㅋ

그럼 이제 Neoness Paris 헬스장 리뷰를 해봅니다.

Neoness Paris는 체인점이기 때문에 파리 곳곳에 있을겁니다. 저는 그 중에 Neoness Paris 9 Saint-Lazare 헬스장을 다녀왔습니다.

1. 가격

Day pass 가격은 당시에 15유로였습니다. (카드, 현금 모두 가능)

그리고 직원분이 타월 필요하냐고 물어봤는데 필요없다고 했습니다. 타월을 필요로 하면 추가요금이 있을 수도 있습니다. 가실 때 하나 챙겨가면 좋을것같네요. 타월없이도 입장은 가능했습니다. ㅎㅎ

(여담으로 Fitness Park 헬스장에서는 Day pass가 20유로였고 타월이 8유로 달라그랬는데 타월 없으면 못드간다 해서 안가긴했습니다...)

2. 시설

시설은 총 2층으로 구분되어 있었습니다. 1층은 웨이트 + 스트레칭 존, 2층은 유산소 + 복싱 존 이었습니다.

1층부터 설명드리면 1층은 2개의 파트로 나눠져있습니다. 첫 번째 파트는 입구(1.5층)에서 내려가면 바로 보이는 머신 존 + 스트레칭 존입니다.

스트레칭 존

머신 존

두번 째 파트는 스트레칭존 쪽으로 쭉 드가면 있는데요. 프리웨이트 + 몇몇의 머신이 있었습니다. (아래 사진 뒤쪽에 프리웨이트 더 할수있는 공간이 있습니다.)

프리웨이트 + 머신 존

그리고 이제 2층으로 가보면 이제 유산소 존이 있습니다. 보통 한국 헬스장에 있는 유산소 운동기구와의 종류는 비슷한데 기능이 좀 다른게 있습니다. 유산소 기구들에서 제공하는 기능이 많아요. 화면에서 (자기 계정 로그인해서) netflix, instagram, youtube, X 등등 다 할수가 있더라고요. 블루투스도 되고 머 여러개 더 많은데 사진이 없네요. 여튼 유산소 기구는 한국보다 훨씬 좋다고 느꼈습니다.

유산소존

3. 추가 정보

- 전체적으로 헬스장에 냄새 안남

- 바닥은 한국 헬스장보다 더러움

- 사람들 착함

- 금요일 오후 4~6시에 이용해서 그런지 사람이 적은거 같았음

VMAF Optimization과 VMAF NEG 이해

Sin-Han Kang — Thu, 1 Feb 2024 20:04:46 +0900

지난 글에서 VMAF(Video Multimethod Assessment Fusion)에 대해 알아보았습니다. 그리고 2020년에 기존 VMAF의 성능을향상시킨 방법들을 오늘 소개합니다. (해당 글을 참고하였습니다.)

Speed Optimization
New libvmaf API
"No Enhancement Gain” Mode: VMAF NEG

1. Speed Optimization

기존의 VMAF 을 사용하는 데 있어서 단점은 VMAF score를 구하는데 time cost가 크다는 것이었습니다. Time cost를 줄이기 위해 다음과 같은 방법을 개발해왔습니다.

Low-level code optimization and vectorization (2016년): python + C에서 standalone C++로 변경
- 기존 VMAF보다 4배 빨라짐
Frame-level multi-threading and frame skipping (2018년): 각 frame별로 vmaf를 구할때 multi-threading을 활용하였고 특정 frame을 skip하여 vmaf구하는 방법 사용
- 4k videos를 대상으로 real time으로 VMAF측정 가능
Floating-point based representation을 fixed-point로 변경 (2020년): 실수를 표현하는 방법이 단순한 방법인 fixed-point를 사용하기 때문에 속도가 빠름 (대신 precision이 floating-point보다는 떨어짐)
Vectorization on the fixed-point data piepline (2020년): fixed-point data에 대해 vectorization

위의 3,4번 항목을 이용하게 된다면 VMAF 측정하는 속도가 평균적으로 2배정도 빨라집니다. 다만, fixed-point로 계산하기 때문에 VMAF score값은 완전히 정확하지는 않지만 소수점 첫째자리까지는 같다고 합니다.

아래 그림을 통해 Intel AVX2(Advanced Vector Extension 2), Intel AVX-512에서 2018년 기준의 VMAF구하는 방식보다 몇배 빨라졌는지 알 수 있습니다.

2. New libvmaf API

FFMPEG의 license가 Apache 2.0에서 BSD+Patent로 변경되면서 다른 open source project들과 호환이 가능해졌습니다. 그래서 대대적으로 API의 개조하여 libvmaf v2.0.0을 relesae하였습니다. 아래와 같은 API가 새롭게 사용가능해졌습니다.

위 표에 대한 특징은 다음과 같습니다.

API를 손상시키지 않고 확장가능
새로운 feature extractor를 추가하기 쉬워짐 → 미래의 새로운 VMAF 알고리즘을 쉽게 support가능
Memory 할당이 유연해지고 frame-level에서 점진적으로 VMAF 계산 가능
- 해당 feature는 encoding loop에서 VMAF를 integrate 가능토록 함

3. "No Enhancement Gain” Mode: VMAF NEG

VMAF의 고유 특징 중 하나는 전통적인 방법들(e.g. PSNR, SSIM)과 다르게 image enchancement operations(e.g. sharpen)으로부터의 visual gain을 확인가능하다는 것입니다. Image enchancement operations은 사람에 의해 인식되는 주관적인 품질 향상을 목표로 하는 operations을 뜻합니다.)

예시로 위그램에서 (a)는 원본 image를 encoding하고 VMAF score를 구한것이고 (b), (c)는 enhacnement operations preprocessing을 거친 후 encoding을 한 image이며 그에 대해 VMAF값을 구한것입니다. Enhacnement operations을 통해 visual gain(improvement)가 생겼기 때문에 (A)보다 (B),(C)의 VMAF 값이 더 높게 측정되는 것을 확인가능합니다.

최근에는 libaom library에서 tune=vmaf mode라는 option으로 사용가능한데 이것은 quality-optimized AV1 encoding을 수행합니다. 해당 모드는 BD-rate gain을 가져오면 video compression전에 frame-based image sharpening을 수행합니다. 위 그림에서 해당 모드 사용 유무에 따른 결과 차이를 볼 수 있습니다.

하지만 codec evaulation을 위해 pre-processing동안의 image enhancement으로부터 생긴 visual gain을 제외한 gain만을 측정할 필요가 종종 있습니다. 위 그림과 같이 encoder는 pre-process과정과 encode과정을 모두 포함하기 때문에 encode 과정에서 발생된 순수(pure) compression gain을 VMAF를 통해서 평가하기 힘듭니다.

그래서 Netflix는 image enhancement operations으로부터의 visual gain을 제외한 pure compression gain만을 측정할 수 있는 VMAF NEG 모드를 개발하였습니다. (NEG는 no enhancement gain을 의미합니다.)

VMAF NEG mode는 어떻게 작동하는 가?

Image enchancement로부터 발생된 VMAF gain을 측정가능하며 해당 gain을 기존 측정방식에서 subtract해준다고 합니다. 그 예시로 위 그림 (f)에서 tune=vmaf 모드를 사용해서 발생된 image sharpening의 magnitude를 grayscale map으로 표현하였습니다. 그리고 (a)~(e)까지 VMAF NEG score를 보았을 때 image enhancement의 gain효과가 제거된 score가 측정된 것을 확인가능합니다.

Rate-Perception Optimized Preprocessing for Video Coding 논문 리뷰

Sin-Han Kang — Sun, 31 Dec 2023 11:02:38 +0900

오늘 리뷰할 논문은 Rate-Perception Optimized Preprocessing for Video Coding으로 Bilibili 에서 나온 논문입니다. Bilibili는 동영상 플랫폼 회사로 중국의 유튜브로 생각하시면 편합니다.

논문 내용을 요약하면 다음과 같습니다.

Video의 각 frame(image)에 대해 preprocessing을 적용하여 image quality는 그대로 유지하되 image size를 최대한 줄여서 최종적으로 video size를 줄이는 것을 목적
Preprocessing은 Rate-Perception Optimized Preprocessing (RPP) model을 통해 적용됨

RPP 적용 전(a), 후(b)

1. Introduction

HD 비디오는 고객 전체 internet traffic 중 80%이상을 차지할 정도로 엄청나게 큰 bandwidth를 사용함
그래서, traditional codec(e.g. H.264, H.265, H.266, AV1)은 efficient video compression system을 만들려고 노력해 옴
- 기존 codec들은 대부분 handcrafted modules (e.g. DCT, intra/inter prediction, block partition)로 이루어져 있음
더 효과적인 compression을 위해 codec의 encoder, decoder를 DL model로 대체하는 방식이 최근에 연구됨
- DL model을 사용하기 때문에 image quality나 encoding size면에서는 기존 codec들보다 성능은 우수하지만 inference cost가 너무 큼
- 심지어, decoder side에서 보면 모든 고객의 핸드폰이나 컴퓨터에 해당 model이 deploy되어야 하기 때문에 model이 클 경우 사용 불가함
그래서, 해당 논문은 Rate-Perception optimized Preprocessor (RPP) model을 사용하여 image frame의 image quality는 그대로 유지하되 encoding size를 최소화시키는 것을 목적함
- 기존의 codec의 encoder을 사용하기 전에 각 image frame에 preprocessing을 적용하여 새로운 image frame을 생성
- 기존 codec의 decoder를 그대로 사용하므로 DL model의 decoder와 다르게 inference cost가 상대적으로 매우 낮음
- Bitrate compression은 Discrete Cosine Transform (DCT) loss를 통해 적용
- Image quality 보존은 MS-SSIM loss을 이용한 perceptual loss, 원본 frame과 생성된 frame간의 MSE loss을 적용한 reconstruction loss로 적용

RPP 모델 process

2. Method

2.1 Overview

RPP model의 목적은 preprocessed input frame을 제공하는 것이며 preprocessing을 통해 bitrate 감소, 동일한 image quality를 유지시킴
Bitrate를 감소시키기 위해 adaptive DCT Loss 제안
- Spatial redundancy를 감소시키고 high frequency 영역 중 중요 한 부분만 남도록 학습
원본 input frame과 동일한 quality를 유지하기 위해서 IQA model인 MS-SSIM을 이용한 perceptual loss제안
원본 input frame에 대해 high-order degradation을 training input data로 사용함으로써 real world image랑 비슷하게 만들고 모델의 perceptual quality를 향상시키도록 함
Lightweight CNN model로 RPP model을 구성하여 효율성을 극대화
Deployment 시에는 input frame $ f_i $가 RPP model에 의해 preprocessing되어 $ f_o $가 되고 이는 기존 codec(e.g. H.264, H.265)에 encoding 됨

RPP model framework

2.2 Adaptive Discrete Cosine Transform Loss

기존 codec 대부분은 encoding과정에 DCT(Discrete Cosine Transform)을 사용
- 2D DCT의 basis function은 Eq. (1), 2D DCT는 Eq. (2)로 수식화됨

\[
B^{i,j}_{h,w} = cos \frac{h \phi}{H} ( i+ \frac{1}{2}) + sin \frac{w \phi}{H} ( j + \frac{1}{2}) \quad \cdots Eq.(1)
\]

\[
F_{h,w} = \sum^{H-1}_{i=0} \sum^{W-1}_{j=0} f_{i,j} B^{i,j}_{h,w} \quad \cdots Eq. (2)
\]

\[
s.t. \quad h \in \{ 0, 1, \cdots, H-1 \}, w \in \{ 0, 1, \cdots, W-1 \}
\]

$ F \in \mathbb{R}^{H \times W} $는 2D DCT frequency spectrum이며 $ f \in \mathbb{R}^{H \times W} $는 input image임
보통은 $ H $와 $ W $는 같은 size를 가지므로 $ N $으로 표기

Input image를 2D DCT을 거치고 나면 frequency domain으로 변환됨
- 2D DCT의 왼쪽 위부분이 low frequecny영역이고 오른쪽 밑부분이 high frequency 영역
- 이미지를 구성하는 대부분 중요한 energy는 low freqeucny 영역에 포함되어 있음

High frequency영역의 (coefficient) 값은 이미지를 구성하는 데 상대적으로 덜 중요한 역할을 하기 때문에 본 논문에서는 high frequecny 영역 중 중요하지 않은 영역의 값을 제거하도록 RPP model을 학습
- 중요하지 않는 영역을 전체 high frequency평균값보다 낮은 영역의 값으로 정의함
위의 내용을 수식화 하기위해 먼저 2D DCT에서 high frequency영역만을 추출하기 위해 $ I $를 도입
- Zig-Zag order traversal 을 이용하여 위 그림처럼 high frequency영역만 추출

\[
F'_{h,w} = F_{h,w} \ast I_{h, w} \quad \cdots Eq. (3)
\]\[
where \quad I_{h, w}= \left\{ \begin{array}{ll} 0, & if (h+w) < S, \cr
1, & if (h+w) \geq S.
\end{array} \quad \cdots Eq .(4) \right.
\]

\[
S \in \{ 0, 1, \cdots, (H-1)(W-1) \}
\]

high frequency영역 중 중요하지 않는 영역을 절댓값을 취한 뒤 전체 high frequency 평균값보다 낮은 영역의 값으로 정의
- high frequecny영역의 평균값을 threshold $T$로 정의

\[
T = \frac{1}{H \cdot W} \sum^{H-1}_{h=i} \sum^{W-1}_{w=j} ( | F'_{h,w} | ) \quad \cdots Eq. (5)
\]\[
where \quad i + j \geq N
\]

$T$보다 작은 $ F'_{h,w} $ 은 high frequency 영역 중에서도 중요하지 않은 값들이므로 제거하기 위해 해당 값들을 $ F''_{hw} $으로 정의
- $ | F''_{h,w} | $값들을 0으로 만들기 위해 아래와 같은 DCT loss 제안
- 즉, 중요치 않은 high frequency영역의 값들을 0으로 만들어 encoding size를 줄여 bitrate 줄이는 목적을 달성

\[
L_{dct} = \sum^{H-1}_{h=i} \sum^{W-1}_{w=j} ( | F''_{h,w} - 0 | ) \quad \cdots Eq. (6)
\]\[
F''_{h,w} \in \{ F'_{h,w} < T \} \quad and \quad i + j \geq N
\]

2.3 Network and Image Degradation

Network는 light-weight architecture로 구성함
- Channel attention module로 SE block을 사용
- Efficient sub-pixel convolution(torch.nn.PixelUnshuffle)를 사용
RPP model로부터 image quality가 높아진 image가 출력되도록 학습하기 위해 일부러 원본 image를 degradation하여 RPP model 입력으로 사용함
- 4 가지의 image degradation 방법 사용
  1. Blur: Isotropic and anisotropic Gaussian filter
  2. Noise: Gaussian and Poisson noise
  3. Upsampling and Downsampling: Area, bilinear, and bicubic operations
  4. JPEG Compression: jpeg quality를 낮게 설정 (blocking and ringing artifact 유도)

2.4 Loss Functions

위에서 정의된 $ L_{dct} $이외에 2개의 loss를 제안함
1. Reconstruction loss $ L_r $을 제안하여 RPP model로 출력된 output frame $ \hat{f} $ 가 입력 frame $ f $의 image quality와 같아지도록 학습함

\[
L_{r} = \frac{1}{HW} \sum^{H-1}_{i=0} \sum^{W-1}_{j=0} | f^{GT}_{i,j} - \hat{f}_{i,j} | \quad \cdots Eq. (7)
\]

$ f^{GT} $는 Ground Truth(GT)인 $f $을 shapren processing한 것
- Sharpen은 이미지의 (high frequency영역의) contrast나 edge성분을 더 돋보여주게 함
- Contrast나 edge성분은 인간의 인지 시스템과 high correlation을 가지므로 GT에 sharpen을 사용함
2. Perceptual loss $ L_p $을 제안하여 reconstruction loss와 같은 목표를 가짐
- MS-SSIM metric을 이용하여 원본 image의 high frequency영역의 structural information과 contrast가 잘 보존되도록 함

\[
L_{p} = 1 - L_{ms-ssim} (f^{GT}_{i,j}, \hat{f}_{i,j} ) \quad \cdots Eq. (8)
\]

결론적으로, 모든 loss를 종합하면 아래와 같음

\[
L_{all} = \lambda_1 L_{dct} + \lambda_2 L_{p} + L_{r} \quad \cdots Eq. (9)
\]

3. Experiment

3.1 Experiment Setup

3.1.1 Datasets

Training으로 DIV2K and Flickr2K datasets을 사용
- DIV2K는 2k resolution image로 구성, 데이터 수는 1,000
- Flickr2K는 2k resolution image로 구성, 데이터 수는 2,650
Testing으로 UVG, HEVC Standard 1080p Test Sequences, and MCL-JCV datasets을 사용
- 해당 dataset들은 video compression algorithm을 평가하기 위해 널리 사용됨

3.1.2 Implementation Detatails

RPP model을 학습하기 위해 two stages training 사용
1. warm-up stage
  - $L_r$ loss만 사용
  - initial lr: 1e-3
  - 600k iterations training
2. Main stage
  - $ L_{all} $ loss 사용 ( $ \lambda_1 $: 10, $ \lambda_2 $: 0.1 )
  - initial lr: 1e-4
  - 700k iterations training
Batch size: 32
Image resolution: 128x128
N (DCT loss계산시의 block size): 8 or 16
Adam optimizer ($ \beta_1 $: 0.9, $ \beta_2 $: 0.999)
Inference 시에는 RPP output image의 intensity를 조절하기 위해 hyperparameter $ \alpha $을 사용
- $f_p = \alpha f_o + (1 - \alpha ) f_i $로 최종 성능을 표기한다는 뜻...
  - $ f_o $는 RPP model의 output frame이고 $ f_i $ 는 input frame
  - 모든 test dataset에 똑같은 $ \alpha $사용하는것이 아니고 dataset마다 다른 값을 사용..
  - HEVC and MCL-JCV datasets에는 $ \alpha $ = 0.5, UVG dataset에는 $ \alpha $= 1 사용
  - 꼼수라고 보면 됨...
RPP model을 TensorRT로 변환하여 속도 측정시 single RTX3090로 1080p 동영상에 대해 87.7FPS 성능

3.2 Experiment Results

기존 codec(e.g. H.264, H.265)에 RPP model적용 시 아래와 같이 BD rate 성능 향상

같은 VMAF, MS-SSIM값 기준으로 3 datsets에 대해 아래와 같은 BD rate saving

[NVIDIA] DALI multi-GPU 사용법 with PyTorch

Sin-Han Kang — Thu, 22 Jun 2023 13:39:31 +0900

※ 해당 글은 vision ai, classification task 관련된 내용만 다룹니다.

오늘은 이전 글에 이어서 DALI dataloader를 multi-gpu로 load하는 방법을 설명드리고 single-gpu와 multi-gpu간의 속도 차이를 확인해보겠습니다. 그리고 이전 글에서 추가된 부분만 설명드리도록 하겠습니다.

0. Experiment Setup

DALI를 적용해볼 data type은 image와 video 이며 실험환경은 다음과 같습니다.

PyPI
- PyTorch: 1.10.0
- DALI: 1.6
- decord: 0.6.0
- OpenCV: 4.5.3.56
Hardware
- CPU: Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz
- GPU: Tesla V100-PCIE-32G
Dataset
- Image: 21,453 VOC images
- Video: 173 random sampled videos
  - Info: 300 frames, 1080p

아래 설명에 사용한 모든 코드는 여기에 올려두었습니다.

1. Multi-GPU DALI Image Loader

# multigpu_dali_imageloader.py
import os
import argparse
import time

import torch
import torch.distributed as dist

from nvidia.dali import pipeline_def
from nvidia.dali.plugin import pytorch
import nvidia.dali.fn as fn
import nvidia.dali.types as types

LOCAL_RANK = int(os.getenv('LOCAL_RANK', -1)) 
RANK = int(os.getenv('RANK', -1))
WORLD_SIZE = int(os.getenv('WORLD_SIZE', 1))

@pipeline_def
def image_pipe(file_root: str,
               local_rank: int,
               world_size: int,
               image_size: int=640):
    jpegs, labels = fn.readers.file(file_root=file_root,
                                    initial_fill=1024,
                                    random_shuffle=True,
                                    shard_id=local_rank, # added for multi-gpu
                                    num_shards=world_size, # added for multi-gpu
                                    name="Reader")
    images = fn.decoders.image(jpegs, 
                               device="mixed", 
                               output_type=types.RGB)
    
    images = fn.resize(images, 
                       device="gpu", 
                       size=[image_size, image_size],
                       interp_type=types.INTERP_LINEAR)
    return images, labels[0]

class DALIImageLoader():
    def __init__(self, 
                 path: str, 
                 batch_size: int, 
                 num_threads: int,
                 local_rank: int,
                 world_size: int):
        pipe = image_pipe(batch_size=batch_size,
                          num_threads=num_threads, 
                          device_id=local_rank, # added for multi-gpu
                          local_rank=local_rank,
                          world_size=world_size,
                          file_root=path,
                          seed=123456)
        pipe.build()

        self.dali_iterator = pytorch.DALIGenericIterator(pipe,
                                                         ["data", "label"],
                                                         reader_name="Reader",
                                                         last_batch_policy=pytorch.LastBatchPolicy.PARTIAL,
                                                         auto_reset=True)
    def __len__(self):
        return int(self.epoch_size)

    def __iter__(self):
        return self.dali_iterator.__iter__()

if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument('--local_rank', type=int, default=-1, help='Automatic DDP Multi-GPU argument, do not modify')
    parser.add_argument('--device', default='6,7', help='cuda device, i.e. 0 or 0,1,2,3')
    parser.add_argument('--batch_size', type=int, default=32, help='total batch size for all GPUs, -1 for autobatch')
    parser.add_argument('--num_threads', type=int, default=8, help='number of threads')
    parser.add_argument('--data_dir', type=str, default='/usr/src/app/da2so/datasets/VOC/images', help='dataset directory')    
    args = parser.parse_args()

    os.environ['CUDA_VISIBLE_DEVICES'] = args.device 
    torch.cuda.set_device(LOCAL_RANK)
    device = torch.device('cuda', LOCAL_RANK)
    os.environ['NCCL_BLOCKING_WAIT'] = '1'  # set to enforce timeout
    dist.init_process_group('nccl' if dist.is_nccl_available() else 'gloo')

    daliloader = DALIImageLoader(path=args.data_dir,
                                 batch_size=args.batch_size,
                                 num_threads=args.num_threads,
                                 local_rank=LOCAL_RANK,
                                 world_size=WORLD_SIZE)
    if RANK == 0:
        start_time = time.time()
        for idx, inp in enumerate(daliloader):
            print(f'image shape: {inp[0]["data"].shape}')
            print(f'label shape: {inp[0]["label"].shape}')
        print(f'[Multi-GPU {args.device} DALI Imageloader] time: {time.time() - start_time}')

Multi-GPU를 사용하기 위해 기존 DALIImageLoader에서 추가된 arugments는 local_rank, world_size 2개입니다. Multi-GPU학습에 익숙하신분들은 아시겠지만 local_rank는 사용되는 GPU number(id)를 뜻하고 world_size는 사용되는 GPU 전체 개수를 의미합니다. 해당 인자들은 DALIImageLoader의 image_pipe함수에 사용됩니다.

image_pipe
- device_id=local_rank: local_rank에 해당하는 하나의 GPU를 할당
  - 해당 인자는 @pipeline_def decorator의 파라미터임

device_id=local_rank을 통해 각 GPU로 pipeline을 실행할 수 있게 되었습니다. 여기서 추가적으로 각 GPU가 서로 다른 samples을 managing할 수 있도록 하는 기술인 sharding을 사용합니다. Dataset을 여러 parts(shards)로 나누어 각 GPU는 고유의 shard로 data load를 진행하게 됩니다.

Sharding

fn.readers.file
- shard_id=local_rank: 각 GPU가 고유의 shard_id를 가지도록 함
- num_shards=world_size: 사용하는 총 shard개수를 지정

이제 위 코드를 torchrun --standalone --nnodes=1 --nproc_per_node=2 multigpu_dali_imageloader.py --device=0,1 명령어로 실행시켜봅니다. GPU 2개를 사용하여 각 GPU당 32 batch size으로 설정하였고 image는 640으로 resize 하였습니다.

총 21,453개의 image를 load하는데 3.1초 정도밖에 걸리지 않네요!

2. Multi-GPU DALI Video Loader

Video loader부분에 대한 설명은 위의 image loader부분과 내용이 다수 겹치고 기존 single-gpu video loader부분과도 유사한 부분이 많아 바뀐 코드만 보여드립니다.

... 생략

@pipeline_def
def video_pipe(filenames: List[str],
               labels: List[int], 
               sequence_length: int,
               stride: int,
               local_rank: int,
               world_size: int):

    videos, label = fn.readers.video(device="gpu", 
                              filenames=filenames,
                              labels=labels, 
                              sequence_length=sequence_length,
                              normalized=False, 
                              random_shuffle=True, 
                              image_type=types.RGB,
                              dtype=types.UINT8,
                              initial_fill=16,
                              num_shards=world_size, # added for multi-gpu
                              shard_id=local_rank, # added for multi-gpu
                              stride=stride,
                              name="Reader")
    return videos, label[0]

... 생략

image loader와 다른점은 fn.readers.video 함수의 인자로 shard_id와 num_shards를 인자를 추가해주어야 한다는 점입니다.

Multi-GPU DALI video loader에서도 위 코드를 torchrun --standalone --nnodes=1 --nproc_per_node=2 multigpu_dali_videoloader.py --device=0,1 명령어로 실행시켜봅니다. GPU 2개로 각 GPU당 8 batch size를 가지도록 하였습니다.

총 173개의 video를 load하는데 48.2초 소요되었습니다.

2. Single-GPU vs Multi-GPU DALI Loader 시간 비교

해당 섹션에서는 GPU개수에 따른 DALI Loader의 시간 측정을 진행합니다. 추가적으로 Pytorch dataloader의 data load시간을 baseline으로 잡고 진행하였습니다.

Experiment Setting
- [DALI, PyTorch] batch size = 32(image), 8(video)
  - 각 GPU당 batch size임
- [DALI] num threads = 8
- [PyTorch] num workers = 8
- [PyTorch] pin_memory = True

	Time cost for image loader (s)	Time cost for video loader (s)
PyTorch CPU	101.06	59.01
DALI 1-GPU	6.24	97.45
DALI 2-GPU	3.07	48.28
DALI 4-GPU	1.57	21.34

Image loader 결과
- CPU로 data load하는 PyTorch보다 DALI사용 시 data load속도가 훨씬 빠름
- GPU가 배로 늘어날수록 속도도 비례하여 빨라짐
Video loader 결과
- CPU로 data load하는 PyTorch보다 Single GPU를 사용하는 DALI가 더 느림
- 하지만, GPU 2개이상 사용시 PyTorch data loader보다 빨라짐
- Image loader와 동일하게 GPU 개수에 따라 속도도 비례하게 빨라짐

[NVIDIA] DALI 사용법 with PyTorch

Sin-Han Kang — Sun, 18 Jun 2023 07:27:34 +0900

※ 해당 글은 vision ai, classification task 관련된 내용만 다룹니다.

오늘은 DALI를 사용하는 방법을 알아보고 DALI를 사용했을 때와 사용하지 않았을 경우의 time cost차이를 직접 측정해보도록 하겠습니다.

1. DALI 란?

Data Loading Library (DALI)는 DNN을 training할때 data loading 및 pre-processing을 GPU을 사용할 수 있도록 하는 GPU-accelerated library
- 그래서 CPU를 사용할 때보다 훨씬 빠르게 training이 가능
DALI는 자체적인 execution engine을 가지며 input pipeline의 throughput을 최대화 시키기위해 설계됨
DALI는 portable하기 때문에 PyTorch, TensorFlow, MXNet에 쉽게 integrated 가능
다양한 data format 지원: TFRecord, COCO, JPEG, JPEG 2000, WAV, FLAC, OGG, H.264, VP9 and HEVC
여러 GPUs에 scaleable가능

2. DALI 사용법

2.1 Experiment Setup

DALI를 적용해볼 data type은 image와 video 이며 실험환경은 다음과 같습니다.

PyPI
- PyTorch: 1.10.0
- DALI: 1.6
- decord: 0.6.0
- OpenCV: 4.5.3.56
Hardware
- CPU: Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz
- GPU: Tesla V100-PCIE-32G
Dataset
- Image: 21,453 VOC images
- Video: 173 random sampled videos
  - Info: 300 frames, 1080p

아래 설명에 사용한 모든 코드는 여기에 올려두었습니다.

2.2 DALI Image data loading

DALI를 이용하여 Image data를 loading하는 방법을 소개드립니다.

import time

from nvidia.dali import pipeline_def
from nvidia.dali.plugin import pytorch
import nvidia.dali.fn as fn
import nvidia.dali.types as types

@pipeline_def
def image_pipe(file_root: str,
               image_size: int=640):
    jpegs, labels = fn.readers.file(file_root=file_root,
                                    initial_fill=1024,
                                    random_shuffle=True,
                                    name="Reader")
    images = fn.decoders.image(jpegs, 
                               device="mixed", 
                               output_type=types.RGB)
    images = fn.resize(images, 
                       device="gpu", 
                       size=[image_size, image_size],
                       interp_type=types.INTERP_LINEAR)
    return images, labels[0]

class DALIImageLoader():
    def __init__(self, 
                 path: str, 
                 batch_size: int, 
                 num_threads: int):
        pipe = image_pipe(batch_size=batch_size,
                          num_threads=num_threads, 
                          device_id=0, 
                          file_root=path,
                          seed=123456)
        pipe.build()
        self.dali_iterator = pytorch.DALIGenericIterator(pipe,
                                                         ["data", "label"],
                                                         reader_name="Reader",
                                                         last_batch_policy=pytorch.LastBatchPolicy.PARTIAL,
                                                         auto_reset=True)
    def __len__(self):
        return int(self.epoch_size)

    def __iter__(self):
        return self.dali_iterator.__iter__()

if __name__ == "__main__":
    start_time = time.time()
    daliloader = DALIImageLoader(path='/usr/src/app/da2so/datasets/VOC/images',
                                 batch_size=32,
                                 num_threads=8)
    for inp in daliloader:
        print(f'image shape: {inp[0]["data"].shape}')
        print(f'label shape: {inp[0]["label"].shape}')
    print(f'[DALI Imageloader] time: {time.time() - start_time}')

위 코드에서는 batch_size를 32로 고정하여 DALIImageLoader를 intialization하는 것을 시작으로 daliloader를 통해 data load하는 데까지 소요되는 시간을 측정하는 코드입니다. 이제 그럼 DALIImageLoader에 대해 하나하나 자세히 살펴보죠.

DALIImageLoader
- image_pipe 함수 호출을 통해 DALI의 pipeline object을 initalization
- pipe.build() 를 통해 pipeline build
- torch.DALIGenericIterator는 build한 pipeline을 대상으로 Pytorch용 DALI iterator 생성
  - 즉, DALI pipeline으로 load된 data가 gpu device로 mapping된 tensor를 형태를 가지게 됨
  - last_batch_policy: data수가 정확히 batch로 나눠지지 않을경우 마지막 batch를 어떻게 처리할 지 정함
    - PARTIAL은 마지막 batch가 setting한 batch 수보다 작을 경우에 그대로 작은 batch로 data load해줌
    - 예를 들어 전체 data가 10개이고 batch가 4라면 마지막 iteration에서는 batch가 2로 설정
  - auto_reset=True: DALI iterator의 마지막 iteration에서 StopIteration이 발생하고 자동적으로 reset() 호출해줌
image_pipe
- @pipeline_def라는 decorator를 사용해서 DALI pipeline구성하게 해줌
  - 해당 decorator를 arugment로 image_pipe함수의 batch_size, num_threads, device_id
  - device_id: gpu device id를 의미
- fn.reader.file: file 또는 directory경로를 입력으로 image content와 label을 return (아래 그림 참조)
  - 해당 process는 cpu로 동작함
  - file_root: data files을 담고있는 directory
  - initial_fill: shuffling에 사용될 buffer_size
  - random_shuffle: data shuffling 유무
  - name: torch.DALIGenericIterator의 reader_name과 일치되는 이름
- fn.decoders.image: image content를 decoding하는 processing
  - device='mixed': cpu와 gpu를 mix해서 사용
    - jpeg인 경우 nvJPEG library(or libjpeg-turbo)을 사용하고 다른 image format일 경우 OpenCV사용
  - fn.resize: batch로 data load하기위해 image size를 동일시 함
    - device='gpu'은 gpu를 통해 resize operation진행함

fn.reader.file return 형식

위 코드 실행하면 아래와 같이 정상적으로 실행되는 것을 확인가능합니다. 총 21,453개의 image를 load하는데 6.2초 정도밖에 걸리지 않네요!

아래사진을 통해서는 DALIImageLoader를 실행시킴으로써 GPU memory를 사용하는 것을 확인가능합니다.

2.3 DALI Video data loading

이번에는 DALI를 이용하여 video를 load하는 방법을 소개드립니다. Image를 load하는 부분과 동일한 부분은 생략하고 설명드리도록 하겠습니다.

import os
import time
import glob
from typing import List
from pathlib import Path

from nvidia.dali import pipeline_def
from nvidia.dali.plugin import pytorch
import nvidia.dali.fn as fn
import nvidia.dali.types as types

VID_FORMATS = 'avi', 'm4v', 'mkv', 'mov', 'mp4', 'mpeg' # include video suffixes

@pipeline_def
def video_pipe(filenames: List[str],
               labels: List[int], 
               sequence_length: int,
               stride: int):

    videos, label = fn.readers.video(device="gpu", 
                              filenames=filenames,
                              labels=labels, 
                              sequence_length=sequence_length,
                              normalized=False, 
                              random_shuffle=True, 
                              image_type=types.RGB,
                              dtype=types.UINT8, 
                              initial_fill=16,
                              stride=stride,
                              name="Reader")
    return videos, label[0]

def video2label_paths(video_path: List) -> List:        
    return [int(Path(x).parts[-2]) for x in video_path]


class DALIVideoLoader():
    def __init__(self, 
                 path: str, 
                 batch_size: int, 
                 num_threads: int,
                 sequence_length: int,
                 stride: int):
        
        try:
            f = [] # video files 
            for p in path if isinstance(path, list) else [path]:
                p = Path(p) 
                if p.is_dir():  # dir
                    f += glob.glob(str(p / '**' / '*.*'), recursive=True)
                elif p.is_file():  # file
                    with open(p) as t:
                        t = t.read().strip().splitlines()
                        parent = str(p.parent) + os.sep
                        f += [x.replace('./', parent) if x.startswith('./') else x for x in t]  # local to global path
        except Exception as e:
            raise Exception(f'Error loading data from {path}: {e}\n')
        self.vd_files = sorted(x.replace('/', os.sep) for x in f if x.split('.')[-1].lower() in VID_FORMATS)
        assert self.vd_files, f'No videos found'
        self.labels = video2label_paths(self.vd_files)
        assert len(self.vd_files) == len(self.labels), f'The number of video files are not matched with label files'

        pipe = video_pipe(batch_size=batch_size, 
                          num_threads=num_threads, 
                          device_id=0, 
                          filenames=self.vd_files,
                          labels=self.labels,
                          stride=stride,
                          sequence_length=sequence_length,
                          seed=123456)
        pipe.build()

        self.dali_iterator = pytorch.DALIGenericIterator(pipe,
                                                         ["data", "label"],
                                                         reader_name="Reader",
                                                         last_batch_policy=pytorch.LastBatchPolicy.PARTIAL,
                                                         auto_reset=True)
    def __len__(self):
        return int(self.epoch_size)

    def __iter__(self):
        return self.dali_iterator.__iter__()

if __name__ == "__main__":
    start_time = time.time()
    daliloader = DALIVideoLoader(path='./videos',
                                 sequence_length=60,
                                 stride=5,
                                 batch_size=8,
                                 num_threads=8)
    for inp in daliloader:
        print(f'video shape: {inp[0]["data"].shape}')
        print(f'label shape: {inp[0]["label"].shape}')
    print(f'[DALI Videoloader] time: {time.time() - start_time}')

Image파트와 비슷하게 DALIVideoLoader를 intialization하고 data load하는 데까지 소요되는 시간을 측정하는 코드입니다. 여기서 DALIVideoLoader의 __init__함수에서 image_pipe 아닌 video_pipe를 호출하는 것과 path를 입력으로 video files과 그에 대한 labels를 추출하는 것 말고는 DALIImageLoader와 크게 다르지 않습니다.

DALIVideoLoader
- self.vd_files: path directory에 포함된 모든 video files path
- self.labels: video파일에 대응되는 labels
video_pipe
- sequence_length: video에서 가져올 frame 수
- stride: 가져올 frame간의 interval
- normalized: video영상을 normalize 할건지
- image_type: video의 각 frame(image)의 type을 명시

위의 sequence_length가 60, stride가 5라는 것은 video로부터 1, 5, 10, 15, ...,295, 300 번째 frames(총 60 frames)을 data load하겠다는 의미입니다. 위 파일을 실행시키면 아래 사진과 같이 정상적으로 실행이 됨을 확인가능합니다. 하지만 video가 173개 load하는 데 97초나 걸리네요... (많이 느리네요..ㅠ)

Video load할 경우에 GPU memory를 사용하긴 하는데 GPU utils이 image loader랑 다르게 너무 낮은 느낌이... 있네요.

2.4 DALI vs OpenCV(decord) 속도 비교

해당 section에서는 DALI를 이용한 GPU data load방식과 CPU data load방식을 사용하였을때의 data load time cost를 비교하겠습니다. 비교를 위해서 GPU 1개만 사용하였고 CPU는 모두 사용하였습니다. CPU image data load는 OpenCV를, CPU video data load는 decord(cpu version)를 사용하였습니다.

2.4.1 DALI vs OpenCV

Tim cost비교를 위해 21,453 VOC images를 사용하였고 OpenCV를 이용한 Dataloader는 기본적인 torch.utils.data.dataloader.DataLoader를 사용하였습니다. (image size는 640으로 resize함)

위 결과로부터 DALI ImageLoader가 약 16배 정도 빠른것을 알 수 있습니다.

2.4.2 DALI vs decord

Time cost비교를 위해 173개의 video를 사용하였고 image부분과 동일하게 decord를 이용한 Datloader는 torch.utils.data.dataloader.DataLoader를 사용하였습니다.

위 결과를 보시면 GPU를 사용한 DALI가 약 2배정도 더 느린것을 알 수 있습니다. DALI를 이용하여 GPU 1개로 video load하는 것은 cpu보다 느리네요... 하지만, training시에 CPU data loader를 사용하였을 경우 CPU → GPU → CPU로 context switching이 많이 일어나기 때문에 이 부분에 대 한 고려를 했을 때 비슷해지지않을까 싶습니다.

다음 글에서는 multi-gpu를 사용한 DALI에 대해 설명드리겠습니다.

[BentoML] ML model serving 방법 (feat. YOLOv8)

Sin-Han Kang — Mon, 22 May 2023 08:32:54 +0900

오늘은 BentoML을 이용한 model serving 방법을 설명드리려고 합니다. 정확히는 BentoML을 사용하여 model serving을 위한 model prediction api를 생성하는 것을 목표로 하겠습니다.

1. BentoML이란?

Model serving 방법을 설명드리기 전 BentoML에 대해 간단히 알아보죠. BentoML의 Bento는 일본어이며 한국어로는 도시락을 의미합니다.

BentoML: ML-powered prediction service 생성을 쉽게 해주는 framework
- BentoML의 Bento는 일본어이며 한국어로는 도시락을 의미
- 도시락이 밥과 반찬이 모두 있는 것처럼 BentoML은 model serving에 필요한 요소들을 모아주기 때문에 이와 같이 naming
BentoML 장점
- 실제 production service에 ML model을 serving하는 데 있어서 필요한 지식과 시간을 최소화시켜주는 도구
  - 다수의 ML 개발자들은 API, docker 사용법을 잘 모른다는 문제를 해소시켜줌
- ML model의 production에 deploy하기까지의 process를 accelerate 및 standarize 함
- Scalable하고 high performance의 prediction service 제공
- 지속적으로 prediction service에 대해 deploy, monitor, operate 가능

2. Environment Setup

Model serving에 필요한 BentoML version 및 사용한 enviornment입니다. 오늘 serving할 모델은 YOLOv8을 사용할 것입니다.

BentoML version: 1.0.19 (중요!)
Torch version: 1.9.0
Model: YOLOv8s
Docker
CPU: Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz
GPU: Tesla V100-PCIE-32GB

3. Model serving with BentoML

BentoML을 이용한 YOLOv8s을 serving하는 방법을 설명드리도록 하겠습니다. 전체 코드는 여기서 확인 가능하십니다.

3.1 Saving a Model

BentoML을 이용하여 YOLOv8s 모델을 BentoML전용 model store 저장합니다. 따로 model store(in local dir)에 저장하는 이유는 모델 버전 관리 및 meta data를 같이 저장하기 위함입니다.

# bentoml_packer.py
import bentoml
from ultralytics import YOLO

model = YOLO("yolov8s.pt").model
model.eval()
saved_model = bentoml.pytorch.save_model(name='yolov8s_model',
                                         model=model,
                                         signatures={"__call__": {"batchable": False}})
print(saved_model)

위와 같이 bentoml.pytorch.save_model 함수를 통해 load한 YOLOv8s model을 yolov8s_model 이라는 이름으로 저장합니다. signatures parameter에 batchable을 False로 하여 batch를 1만 사용하도록 제한하였습니다.

위 파일을 실행시키면 아래와 같이 정상적으로 model saving되는 것을 확인가능합니다. Tag부분을 보면 docker에 image_name:tag와 똑같이 model_name:tag(yolov8s_model:ukgv3lhwxstqdibw)형태로 저장됩니다. 그리고 bentoml models list cli를 통해 저장된 model size나 생성 시간 등을 확인가능합니다.

3.2 Creating a Service

Service는 BentoML의 core component이며 model serving의 logic을 담는 주체입니다. YOLOv8 모델을 통해 detection (inference)할 수 있도록 하는 api endpoint를 쉽게 만들 수 있으며 해당 endpoint의 input과 output의 type, shape을 정의가능합니다. 또한 model inference에 필요한 코드도 아래와 같이 작성하면 됩니다.

# service.py
... 생략 ... 

import bentoml
from bentoml.io import Image, JSON

yolov8s_runner = bentoml.pytorch.get("yolov8s_model:latest").to_runner()
svc = bentoml.Service("yolov8s_svc", runners=[yolov8s_runner])

def encode_image(input_img):
    ratio = 3  # 0~9
    encode_param = [cv2.IMWRITE_PNG_COMPRESSION, ratio]
    encoded_img = base64.b64encode(cv2.imencode(".png", input_img, encode_param)[1])

    return encoded_img.decode("utf8")
... 생략 ...

@svc.api(input=Image(),
        output=JSON())
def predict(f: Image):
    img_origin, img_tensor = pre_processing(f=f)
    out = yolov8s_runner.run(img_tensor)
    out_bbox_info, out_img = post_processing(img_origin=img_origin,
                                             img_tensor=img_tensor,
                                             out=out)
    enc_out_img = encode_image(out_img) 
    cls = out_bbox_info.cls.detach().cpu().numpy()
    conf = out_bbox_info.conf.detach().cpu().numpy()
    coord = out_bbox_info.data[:,:4].detach().cpu().numpy()

    res = {'enc_out_img': enc_out_img, 'cls': cls, 'conf': conf, 'coord': coord}
    return res

BentoML 코드에만 초점을 맞추어 설명드리기 위해 YOLOv8을 위한 process는 위 코드에서 생략하였습니다.

저장한 yolov8s_model을 load하기위해 bentoml.pytorch.get 함수를 사용하였습니다. 그리고 to_runner 함수를 통해 모델을 실행(inference)할 수 있는 하나의 computation unit로 만듦
- Runner는 remote python worker에서 실행되며 scaling기능을 가지고 있음
bentoml.Service 함수를 통해 yolov8s_svc이름의 service 생성함
- Service를 handling하는 주체는 svc variable
- runners인자에 위의 정의한 runner인 yolov8s_runner를 넣어줌
@svc.api(input=Image(), output=JSON()) 을 통해 svc service의 inference api endpoint를 만듦
- Input의 type을 Image형태로 받을 것이고 output은 Json형태임을 명시함
- predict(f: Image)을 통해 inference api endpoint 이름은 predict로 정의하고 f라는 parameter를 통해 Image을 받음
predict 함수 내에서 inference를 위한 service logic을 구현함
- pre_processing 함수를 통해 PIL형태의 image를 torch tensor로 바꿈
- 위의 bentoml.Service에서 runners의 인자로 들어간 yolov8s_runner의 run함수를 실행하여 inference진행
- post_processing 함수를 통해 detection result image와 detection result info(bbox, class, confidence)를 출력
- endpoint선언 시 output은 JSON형태로 보내기로 선언했기 때문에 encoding한 detection result image와 detection result info를 json형태로 보냄
  - detection result image인 out_img를 그대로 json형태로 보낼 경우에 out_img의 data size가 크기 때문에 response time이 느려지는 문제가 발생하므로 encoding하여 보냄

위 코드에 대해 service 테스트해보도록 하겠습니다. bentoml serve service:svc cli 을 입력하면 serving 테스트진행하게 됩니다. service:svc에서 service는 service.py를 의미하고 svc는 service.py내의 service 주체인 svc variable을 의미합니다.

위와 같이 출력된다면 정상적으로 service가 실행 중입니다. 위의 log를 살펴보면 http://0.0.0.0:3000으로 service:svc을 listening(요청을 받음)하는 것을 알 수 있습니다. 기본적으로 bentoml service에서 사용되는 port는 3000입니다. 그렇다면 http://0.0.0.0:3000에 inference를 담당하는 predict api가 정상적으로 작동하는지 테스트하기 위해 다른 terminal를 실행시켜 아래 코드를 실행시켜 봅니다.

# request.py
... 생략 ...

PREDICT_API = "http://0.0.0.0:3000/predict"
ORI_IMG_PATH = './bus.jpeg'

data = subprocess.run(shlex.split(f"curl -F 'fileobj=@{ORI_IMG_PATH};type=image/jpeg' {PREDICT_API}"), stdout=subprocess.PIPE).stdout
dict = json.loads(data)  

def decode_image(input_img):
    output_img = np.frombuffer(base64.b64decode(input_img.encode('utf8')), np.uint8)
    output_img = cv2.imdecode(output_img, cv2.IMREAD_COLOR)
    
    return output_img

out_img = decode_image(dict['enc_out_img'])
cv2.imwrite('./recv_out_img.jpg', out_img)
for coord, cls, conf in zip(dict['coord'], dict['cls'], dict['conf']):
    print(f'bbox: {[int(x) for x in coord ]}, class: {int(cls)}, confidence: {conf:.2f}')

curl 을 통해 image를 predict endpoint에 보냄
- predict endpoint인 http://0.0.0.0:3000/predict에 image(bus.jpeg)를 post
- response받은 dict['enc_out_img']은 encoded image이므로 decoded하여 저장하였음

위와 같이 정상적으로 predict api에 image가 post되어 YOLOv8s모델을 통해 detection 된 결과를 받을 수 있습니다. 왼쪽 log에는 detection result info을, 오른쪽 사진은 detection result image를 나타내었습니다. (Class 0은 person, class 5은 bus를 의미합니다.)

3.3 Building a Bento

위의 테스트가 A라는 서버에서 정상적으로 이루어졌다고 가정하고 만약 해당 서비스를 B라는 서버에서 하고 싶다면 어떻게 해야 할까요? B에 가서 A와 똑같은 환경을 만들고 위의 과정을 반복해야 할까요? 이렇게 하는 것은 불필요한 작업 및 시간을 필요로 하고 에러도 발생 시킬 수 있습니다.

그래서 이를 해결하기 위해 BentoML을 이용하여 service를 실행시키기 위한 모든 것을 dockerizing하게 됩니다. 구체적으로 dockerizing은 model, service 파일, source code, service에 필요한 환경(PyTorch, Numpy 등등)을 모두 모아 놓는 것이기 때문에 Bento(도시락)를 만든다고도 말할 수 있습니다.

# bentofile.yaml
service: "service:svc"  # Same as the argument passed to `bentoml serve`
labels:
   owner: da2so
   stage: dev
include:
- "*.py"  # A pattern for matching which files to include in the bento
- "*.yaml"
exclude:
- "*.pyc"
python:
    packages:
    - torch==1.9.0+cu111
    - torchvision==0.10.0+cu111
    - PyYAML==6.0
    - loguru
    - pandas==1.5.2
    - Pillow==9.3.0
    - numpy==1.23.5
    - opencv-python==4.5.3.56
    - thop
    - py-cpuinfo
    - psutil
    - seaborn==0.12.2
    - tensorboard==2.8.0
    - pybboxes==0.1.6
    - tqdm
    extra_index_url:
    - "https://download.pytorch.org/whl/cu111"
docker:
    distro: debian
    python_version: "3.8"
    cuda_version: "11.2.2"
    setup_script: "./setup.sh"

위의 yaml 파일을 통해 bento만드는 데 필요한 것을 모두 명시해야합니다.

service: "service:svc"
- 서비스하고자 하는 service file:service class(service:svc)을 명시
labels
- meta data를 입력
include / exclude
- include는 bentofile.yaml가 존재하는 directory 위치에 있는 파일 들중 포함하고자 하는 파일을 의미하고 exclude는 그 반대
python
- 서비스에 필요한 python package를 명시
docker
- docker base image에 대한 내용으로 debian os를 사용할 것이며 python, cuda version을 명시할 수 있음
- setup_script에는 docker image에 setup되어야 하는 명령어들이 포함된 쉘 스크립트를 의미함

bentoml build cli 입력하면 benfile.yaml을 기반으로 bento를 만들어 줍니다.

Log를 보면 model store에 저장된 yolov8s_model:ukgv3lhwxstqdibw를 load하여 packing하는 것을 알 수 있고 service:svc에서 정의한 service 이름인 yolov8s_model을 기반으로 tag(slops5xxc2yhdibw)도 생성되었음을 알 수 있습니다. 위의 과정을 통해 무엇이 생성되었는 지 알려드리기 위해 ~/bentoml/bentos/yolov8s_svc/slops5xxc2yhdibw/ (~/bentoml/bentos/${SERVICE_NAME}/${SERVICE_TAG}) 디렉토리로 가봅니다.

위와 같은 파일들이 docker build를 통해 생성되는 것을 알 수 있습니다.

3.4 Generating Docker Image from Bento

생성된 bento 파일들을 기반으로 최종적으로 docker image를 만들어봅니다. DOCKER_BUILDKIT=0 bentoml containerize ${service_name}:${service_tag} 명령어를 사용합니다.

성공적으로 완료되었으니 docker images 명령어를 통해 생성된 docker image를 확인합니다.

해당 docker image로 container를 생성하여 container에서도 서비스가 정상적으로 작동되는 지 확인해 보겠습니다. 저는 docker run -it --gpus "device=0" --ipc=host --name yolov8s_model -p 3000:3000 yolov8s_svc:slops5xxc2yhdibw 명령어로 container를 생성하였습니다.

docker image를 통해 서비스를 생성하니 전과 다르게 [api_server:${number}] 부분과 [runner:yolov8s_model:${number}] 부분이 추가되었습니다. api_server는 request를 받는 api server를 의미하고 그에 대한 ${number}는 몇번째 api server인지를 나타냅니다. 그리고 runner:yolov8s_model는 runner를 의미하고 그에 대한 ${number}는 몇번째 runner인지를 나타냅니다. 아래 사진은 api server가 3개인 경우와 runner가 1개인 경우의 서비스를 의미합니다. (다음 글에서는 서비스 성능 최적화를 위해 api server개수와 runner개수를 조절하는 방법을 알아보도록 할게요!)

BentoML service architecture

3.2에서 만든 request.py으로 테스트 다시 해보면 이전과 똑같이 inference api가 정상적으로 작동하는 것을 확인할 수 있습니다.

서비스가 실행되는 container(request 받는 side)의 log를 보면 api_server:48를 통해 정상적으로 request받아서 runner:yolov8s_model:1으로 inference진행완료한 것을 알 수 있습니다!

LoRA: Low-Rank Adaptation of Large Language Models 논문 리뷰

Sin-Han Kang — Tue, 16 May 2023 18:23:15 +0900

Microsoft에서 나온 논문인 LoRA를 오늘 리뷰해 봅니다. LoRA는 GPT와 같은 Large Language Models(LLM)을 특정 task에 fine-tuning(adaptation)하는 데 있어서 time, resource cost가 너무 크다는 단점을 해결하기 위한 방법입니다.

1. Introduction

LLM은 기본적으로 pre-trained model로부터 특정 task(e.g. summarization, question and answering, ...)에 adaptation하기 위해 fine-tuning을 해야 합니다. Fine-tuning을 하면서 LLM모델의 weight parameters를 모두 다시 학습하게 되는데 이게 엄청난 cost!!입니다. 예를 들어 GPT-2(or 3), RoBERTa large모델의 경우 fine-tuning만 몇 달이 걸리게 됩니다.

그래서 이를 해결하기 위해 해당 논문에서는 Low-Rank Adaptation(LoRA)를 제안하게 됩니다. 이름에서 유추가능하듯이 LoRA는 Low-Rank 방법을 이용하여 time, resource cost를 줄이게 됩니다.

Low-Rank 방법을 사용하게 된 motivation 및 basis는 "Measuring the Intrinsic Dimension of Objective Landscapes" 논문과 "Intrinsic Dimensionality Explains the Effectiveness of Language Model Fine-Tuning." 논문에서 말하길 "over-parameterized model은 low intrinsic dimension으로 존재하고 있다"라는 사실에서 기반하고 있습니다. 그래서 저자들은 model adaptation동안의 weight change에도 low intrinsic rank를 가질 거라고 가정하게 되고 Low-Rank 방법을 사용하게 됩니다.

LoRA는 기존 pre-trained weights는 frozen해두고 몇 개의 dense(fc) layers만 학습하는 것인데 이때 학습방법이 dense layer의 weight을 low rank로 decomposition한 matrices만을 optimization하는 것입니다.

그래서 위 Figure 1과 같이 fine-tuning시에 pre-trained weights $ W $는 frozen해두고 low rank decomposition된 weights $A$, $B$만 학습하고 $ W $에 summation하게 됩니다. Low rank로 decomposition된 weights는 당연하게도 기존 $W$보다 훨씬 작은 크기의 weight이기 때문에 time, resource cost를 줄일 수 있게 됩니다. 또한 pre-trained model을 가지고 있는 상태에서 특정 task에 adaptation하기 위해서 $A$와 $B$만 storage에 저장하면 되고 다른 task에 adaptation하기 위해 또 다른 $A'$, $B'$만 갈아 끼우면 되기 때문에 storage, task switching면에서 매우 효율적입니다. 추가적으로 inference시에도 fine-tuned model의 latency성능이 낮아지지도 않습니다.

1.1 Terminologies and Conventions

$ d_{model} $: Transformer의 input, output dimension size
$ W_q, W_k, W_v, W_o $: Self-attention moduel의 query/key/value/output projection matrices
$W $ or $W_0 $: Pre-trained weight
$ \Delta W $: Adaptation동안의 accumulated gradient update
$ r $: LoRA module의 rank
Model optimization방법으로 Adam을 사용
Transformer MLP feedforward dimension: $d_{ffn} = 4 \times d_{model} $

2. Problem Statement

LoRA방법은 training objective에 상관없이 모두 사용가능(agnostic)하지만 해당 논문에서는 LLM에 focus맞추어 설명합니다.

$ \Phi $로 parameterized되어 있는 pre-trained language model $ P_{\Phi} (y| x) $가 주어졌다고 가정합니다. $ P_{\Phi} (y| x) $는 GPT와 같은 generic한 multi-task learner입니다.

해당 pre-trained language model을 downstream text generation task에 adaptation 하는 상황을 생각해봅시다. Downstream task의 예시로는 summarization, natural language to SQL (NL2SQL) 등이 있습니다. Adaptation을 위해 각 downstream task은 context-target pair의 training dataset $ Z = \{( x_i , y_i) \}_{i=1, \ldots, N} $을 가집니다. ( $x_i $와 $y_i $는 token sequences) NL2SQL task의 경우 $x_i $은 natural language query이고 $ y_i $은 그에 대한 SQL command일 것이고 summarization task의 경우에는 $x_i $은 article 내용이고 $y_i $는 그에 대한 요약내용이겠죠.

기존의 full fine-tuning이라면 model은 pre-trained weights $ \Phi_0 $으로 initialized될 것이고 아래와 같은 conditional language modeling objective를 minimize하기위해 $ \Phi_0 + \Delta \Phi $을 update 합니다:

\[
max_{\Phi} \sum_{ (x,y) \in Z} \sum^{ |y|}_{t=1} log(P_{\Phi} (y_t | x, y_{ < t} ))\quad \cdots Eq. (1)
\]

위의 full fine-tuning을 사용할 경우에 "각" downstream task를 위해 $ | \Phi_0 | $ dimension과 같은 크기의 $ | \Delta \Phi |$을 매번 재학습해야 한다는 문제점을 가집니다. GPT-3와 같이 1,750억개의 weights를 가진 pre-trained model을 사용하게 되면 엄청난 cost가 들것입니다.

이를 해결하기위해 LoRA는 update해야하는 parameter를 $ \Delta \Phi = \Delta \Phi ( \Theta ) $와 같이 encode하여 훨씬 작은 size의 parameter $ \Theta $로 대체 학습하는 것입니다( $ | \Theta | \ll | \Phi_0 | $ ). 그래서 최적의 $ \Delta \Phi $를 찾는 task는 $ \Theta $를 optimization하는 것으로 대체됩니다:

\[
max_{\Phi} \sum_{ (x,y) \in Z} \sum^{ |y|}_{t=1} log(P_{\Phi_0 + \Delta \Phi ( \Theta ) } (y_t | x, y_{ < t} ))\quad \cdots Eq. (2)
\]

위와 같은 LoRA방식으로 GPT-3을 fine-tuning할 경우 기존 full fine-tuning보다 학습해야 할 parameter수가 전체의 0.01%로 줄어듭니다. 아래 section에서는 LoRA방법에서 정확히 어떻게 $ \Theta $가 표현되는지 얼마나 작은 size로 encode되는 지 알아보도록 하죠!

3. Our method

3.1 Low-Rank Parameterized Update Matrices

리마인드하면 LoRA는 adaptation 동안에 low intrinsic rank를 가진 weight로 update하는 방법입니다. 수학적으로 pre-trained weight matrix $ W_0 \in \mathbb{R}^{d \times k } $ 에 대해 $ W_0 + \Delta W = W_0 + BA $로 update하는 것입니다. 즉, $ W_0 $은 frozen되고 low rank로 decomposition된 $B \in \mathbb{R}^{d \times r} $와 $ A \in \mathbb{R}^{r \times k} $만을 학습하는 것입니다(rank $r \ll min(d,k) $을 만족함 ).

그리고 $W_0 $와 $ \Delta W = BA $는 같은 input에 곱해지고 그들의 output vector는 coordinate-wise하게 합(summation)해집니다. 이에 대해 forward pass를 표현하면 다음과 같습니다:

\[
h = W_0 x + \Delta W x = W_0 x + BAx \quad \cdots Eq. (3)
\]

$A$는 random Gaussian initialization되고 $B$는 0으로 initialization됩니다. 그래서 training 시작 시에 $ \Delta W = BA $또한 0입니다. 그리고 $ \Delta W x$는 $ \frac{ \alpha}{r} $으로 scaling됩니다. Adam으로 optimization 할 때 $ \alpha $를 tuning하는 것은 learning rate를 tuning하는 것과 같이 하였습니다. 그래서 $ \alpha $을 처음 $ r$값으로 정하였다고 합니다. Scaling은 $r$값을 변화 시킬때 hyperparameter를 재조정할 필요를 줄이는 데 도움이 됩니다.

위는 실제 LoRA코드를 snippet한 것인데 위에 설명드린 수식과 내용과 일치하는 것을 알 수 있습니다. (코드에서 확인해보니 $r, \alpha $값은 보통 (8, 16) 또는 (16, 32)을 사용하였습니다.)

3.1.1 No additional Inference Latency

LoRA를 사용하여 inference하려고 할 때는 기존 pre-trained weight $W_0$에 학습한 $BA$를 더해주고 사용하면 되기 때문에 infernece latency성능 하락은 전혀 없습니다. 그리고 $W_0$을 기반으로 또 다른 task로 학습한 $B'A'$가 있을 경우 $BA$을 빼주고 $B'A'$을 더해주어 사용하면 되기 때문에 reusability이 좋습니다.

3.2 Applying LoRA to Transformer

논문에서는 trainable weight를 최소화하기위해 LoRA를 모든 layer 및 module에 적용하지않습니다. 오직 LoRA를 Transformer의 attention weights인 $W_q$또는 $W_k $, $W_v$에만 적용하였고 나머지 MLP module에는 적용하지 않았습니다. (실제 성능 실험에서는 $W_q $와 $W_v$에만 LoRA적용하였습니다.) 이렇게 셋팅하고 진행함으로써 1,750억개의 parameter를 가진 GPT-3에 대해 fine-tuning시에 원래 VRAM를 1.2TB사용하던 것이 LoRA를 통해 350GB로 줄어들었습니다. 또한 training speed또한 25%가량 줄었다고 합니다.

4. Experiment Results

GPT-2기준 성능비교 시 기존 방법들보다 trainable weight도 적으며 다양한 데이터셋에 대해 성능도 잘 나온것을 확인가능합니다. (실험에 대한 더 많은 내용은 논문 참조부탁드립니다. ㅠ)

Segment Anything 논문 리뷰

Sin-Han Kang — Fri, 7 Apr 2023 15:26:40 +0900

오늘은 Meta AI의 Segment Anything논문을 리뷰합니다. 논문 이름이 목적과 내용을 뜻하는 논문 이네요. 아래 사진과 같이 어떤 이미지든(zero-shot) segment할 수 있다는 것을 의미합니다. Zero-shot transfer이 가능하며 어떤 task에도 generalization될 수 있다는 점에서 ChatGPT와 같이 이러한 모델을 foundation model이라합니다.

Segment Anything은 원하는 모든 object를 segmentation 해줌...

1. Introduction

ChatGPT와 같은 Large Language Models (LLM)은 (1) zero-shot generalization이 뛰어나고 (2) hand-crafted 질문 text을 입력으로 아주 적절한 대답(response)을 즉각적으로 출력할 수 있는 prompt engineering이 가능합니다.
- 이러한 모델을 foundation model이라고 지칭
- 전체적인 학습 flow는 web-scale의 dataset으로 pre-trained하고 특정 task(e.g. QA, translation)에 맞춰 fine-tuning
해당 논문의 목표: LLM과 비슷한 학습 방법을 사용해서 image segmentation용 foundation model을 만들어 보자!
- 하지만... 다음과 같은 문제가 있음
  1. 어떤 task가 zero-shot generalization을 가능하게 할까?
  2. 어떤 model architecture을 사용해야할까?
  3. 어떤 data가 해당 task와 model에 적합할까?

위의 문제를 해결하기 위해 논문에서 해당 방법론 제안

1. Task

LLM에서 사용하는 방식과 비슷하게 prompting technique을 기반으로 promptable segmentation task 제안
목표는 어떠한 형태의 segmentation prompt가 주어져도 valid한 segmentation mask(result)을 출력하도록 하는 것
Segmentation prompt는 아래 사진과 같이 segment할 image object에 대한 spatial 또는 text information이 기만 하면 됨
- 아래 사진에서 가능한 segmentation prompt 종류가 명시됨: points, boxes, segment mask, text
심지어 해당 prompt가 애매모호(ambiguity)하거나 여러 object를 지칭해도 됨
- 예를 들어 prompt 중 한종류인 point label이 shirt를 가리키고 있을 때 실제 의도는 shirt그 자체일 수도 있지만 shirt를 입고있는 사람이 될 수 도 있음
- 해당 prompt가 여러 object를 지칭해도 model의 output은 반드시 여러 object중 하나의 reasonable mask를 뽑아내도록 학습할 것임

promptable segmentation

2. Model

다음과 같은 3가지 constraints를 만족하는 model을 만들어야 함
- Flexible prompts를 지원
- interactive하게, real-time으로 segmentation mask를 compute 가능
- (prompt에 대한) ambiguity-aware한 특성
위 constraint을 만족시키는 모델 Segmen Anything Model (SAM) 제안
- SAM은 image encoder, prompt encoder, mask decoder로 구성 됨
  - Image encoder: image을 입력으로 image embedding 출력
  - Prompt encoder: prompt를 입력으로 prompt embedding 출력 (flexible!)
  - Mask decoder: 위의 두 embedding값을 입력으로 segmentation mask 출력 (fast!)
- Input image는 같고 prompt가 다를 경우 image embedding reuse가능
- Prompt는 point, box, mask, text를 받을 수 있도록 flexible하게 구성
- 하나의 prompt입력에 대해 여러 segmentation mask를 출력할 수 있도록 하여 ambiguity-aware특성 만족

Segment Anything Model (SAM)

3. Data engine

SAM model이 strong generalization을 얻기 위해서는 방대한 dataset이 필요함
이를 위해 data engine을 구축
- Model-in-the-loop dataset annotation을 사용하는 방식
Data engine은 총 3가지 strategy로 구성
- Assisted-manual: 기존의 annotation task와 비슷하게 SAM이 annotator를 assist하는 형식
- Semi-automatic: prompting하여 선택된 objects들 중 subset만 SAM이 automatic하게 mask를 생성해주고 나머지는 annotator가 진행
- Fully-automatic: foreground points들의 regular grid prompt를 입력으로 SAM이 이미지당 100개까지의 high-quality mask를 생성 (아래 왼쪽 그림 참조)

4. Dataset

Data engine의 fully automatic strategy로 생성된 최종 dataset이 SA-1B
- 1B masks와 11M의 licensed, privacy-preserving images로 구성됨

SA-1B dataset examples

2. Segment Anything Task

2.1 Task

Segment Anything Task인 promptable segmentation task에 대해 더 자세히 설명드리겠습니다.

본 논문에서는 promptable segmentation task을 주어진 어떠한 prompt라도 valid한 segmenation mask를 출력하는 것으로 정의합니다. 여기서 'valid'의 정의는 ambiguous(모호한)해도 되고 여러 물체를 가리키고 있어도 괜찮습니다. 다만 반드시 여러 물체 중 하나를 꼭 가리키는 segmentation mask이어야합니다. 이렇게 task를 정의한 이유는 이 방법이 natural pre-training algorithnm이며 prompt를 이용한 zero-shot transfer하기에 가장 general한 방법이기 때문입니다.

2.2 Pre-training

Pre-training은 image와 prompts(points, boxes, masks)을 입력으로 하여 나온 model output인 predicted segmentation mask와 ground truth의 차이를 최소화하도록 학습합니다. 여기서의 주된 목적은 prompt가 ambiguous해도 어떤 prompt에 대해서도 valid한 mask를 prediction하도록 하는 것이 목적입니다. 그래서 model의 prediction이 ambiguity를 포함하게 되는데 이게 user가 사용하기에 효과적이고 data engine의 automatic annotation에도 flexible하게 사용가능하게 합니다.

2.3 Zero-shot transfer

어떠한 prompt에도 적절하게 pre-training되기 때문에 특정 task에 zero-transfer하기 용이합니다. 예를 들어 '고양이'를 detect하는 bounding box detector를 한 유저가 가지고 있는 상태에서 '고양이'를 segmentation하고 싶다면 SAM모델에 bounding box output을 prompt로 주는 방식으로 해결할 수 있습니다. (SAM은 bounding box를 prompt로 입력받아 pre-training되어있기 떄문입니다.)

3. Segment Anything Model (SAM)

Promptable segmentation task을 위한 SAM모델은 (1) Image encoder, (2) flexible prompt encoder, (3) fast mask decoder 로 이루어져 있습니다.

3.1 Image Encoder

Pre-trained Vision Transfomer(ViT)의 하나인 Masked autoencoders (MAE)의 enocder 사용하여 image encoder를 구성하였습니다. MAE는 high-resolution Input을 process하기위해 적용되었습니다. Image에 대해 여러 prompt가 존재한다면 Image encoder는 image당 한번만 실행됩니다.

MAE architecture

3.2 Prompt encoder

Prompt를 (1) sparse(points, boxes, text)와 dense(mask)으로 나누어 정의하였습니다.

Sparse set에 해당하는 points와 boxes 는 learned embeddings으로 합산된 positional encodings을 사용하여 표현하고 text는 CLIP으로부터 상용화된 text encoder로 text를 표현합니다. Dense set은 convolutions과 image embedding(from image encoder)과 함께 summed element-wise으로 embedding됩니다.

3.3 Mask decoder

Mask decoder의 역할은 image embedding, prompt embedding과 output token을 효과적으로 segmentation mask에 mapping하는 것입니다. Mask decoder는 transformer decoder block과 dynamic mask prediction head를 사용하였습니다. 해당 decoder block은 전체 embedding을 update하기위해 prompt self-attention과 cross-attention을 2가지 방향으로 사용하였습니다. ([1] prompt-to-image, [2] image-to-prompt embeddings) 아래와 그림과 같이 2개의 blocks이후에는 image embedding을 upsampling하고 MLP는 output token을 dynamic linear classifier에 mapping하게 됩니다. 그리고 각 image location에 대해 mask foreground probability를 계산합니다.

3.4 Resolving ambiguity

SAM은 하나의 prompt에 대해 여러개의 output masks를 predict하도록 합니다. 아래 사진과 같이 3개의 mask outputs이면 대부분 cases을 처리할 수 있다는 것을 발견하여 한 prompt에 대해 총 3개의 output masks를 예측하도록 학습하였습니다. Training시에 masks에 대해 minimum loss만 backprop하였다고 합니다. 그리고 3개의 masks에 대해 rank를 매기기 위해 confidence score(estimated IOU)를 예측하도록 하였습니다.

3.5 Losses and training

Focal loss와 Dice loss의 linear comibation으로 mask prediction에 대해 supervise learning진행하였습니다. 그리고 여러 geometric prompts를 섞어서 training 진행하여 단일로 prompt를 사용했을 때보다 robust하게 학습되도록 하였습니다. (text prompt사용 시에만인듯 합니다?) Mask마다 총 11번의 random sampling prompts를 진행하여 data engine에 SAM 모델이 integrate되도록 하였습니다.

4. Segment Anything Data Engine

Data engine은 3가지 stage로 구성: (1) model-assisted manual annotation stage, (2) semi-automatic stage, (3) fully automatic stage 되어있습니다.

4.1 Assisted-mamanual stage

전문적인 annotator들이 SAM을 기반한 browser-based segmentation tool을 통해 foreground/ background object를 클릭해가며 labeled mask를 만드는 stage입니다. (노가다ㅠ..) Labeling시에 object의 semantic constraints를 따로 두지않았다고 하며 stuff, things에 대해 자유롭게 labeling하도록 하였다고 합니다.

이 stage에 사용되는 SAM은 public segmentation datasets으로 학습되었으며 어느정도 충분한 data가 더 쌓이면 SAM을 retrain하였다고 합니다. 그리고 더 많이 쌓였다면 image encoder를 ViT-B에서 더 큰 모델인 ViT-H로 변경하였다고 합니다. 총 6번의 retraining작업을 진행하였습니다. (retraining이 진행됨에 따라 annotation속도가 빨라진다고 하네요) 이 stage에서 총 120k images에 대해 4.3M masks를 얻었다고 합니다.

4.2 Semi-automatic stage

이 단계에서는 masks의 다양성을 높여 SAM의 성능을 향상시키는 데 목표합니다. Annotator들에게 SAM으로부터 어느정도 masks labeling이 되어있는 이미지를 주고 annotate되지않은 부분을 추가적으로 annotate하도록 합니다. 즉, 덜 중요한 object들에 대해 초점을 더 맞춘것입니다. Confident mask를 detect하기 위해 첫 번째 stage에서 얻은 masks에 대해 generic object category를 이용하여 detect하도록 bounding box detector(Faster R-CNN)를 학습하였습니다. 해당 stage에서는 추가적으로 180k images에 대해 5.9M masks를 만들었습니다.

4.3 Fully automatic stage

여기서부터는 annotator들이 없습니다. 이전 2개의 stage을 통해 충분히 다양한 masks을 모아서 모델의 성능을 향상시켰고 여기서는 ambiguity-aware model을 만듭니다. 즉, 애매모호한 prompt가 입력으로 들어와도 납득할만한 masks를 출력하도록 합니다. 32x32의 regular grid에 point prompt을 입력으로 넣어 각 point에 대해 valid object를 segment하도록 합니다. 예를 들어, 한 point가 물체의 part 또는 subpart에 놓여있다면 SAM은 subpart, part, 전체 object에 대한 masks를 출력하도록 하는 것입니다. 그리고 IOU prediction module을 사용하여 confident(stable) masks만 선택되도록 합니다. (0.5-threshold부터 0.5+threshold값안에 속하는 것만 stable하다고 정의) 마지막으로 non-maximal suppression (NMS)을 통해 duplicate된 mask결과를 filtering합니다. 작은 masks를 찾기 위해 여러개의 overlapping zoomed-in image crop방식도 사용했다고 합니다. 이렇게 하여 총 11M image에 대해 1.1B masks를 생성해내었다고 합니다. (이 결과가 그대로 SA-1B dataset이 된것은 아닙니다!)

5. Segment Anything Dataset

5.1 Images

1,100만개의 image는 license가 있다고 하며 high-resolution(평균 3300x4950사이즈)이라고 합니다. 해당 이미지들을 SA-1B dataset으로 release할때는 1500 pixels까지 downsampling하였다고 합니다.

5.2 Masks

11억개의 masks를 만들었으며 그중 99.1%가 automatic하게 생성된 것이라 합니다. Automatic하게 생성된 masks가 사람이 annotate한 결과와 별반 다르지 않았다고 하여 SA-1B dataset은 오직 automatic하게 생성된 masks로만 구성되어있다고 합니다.

5.3 Mask properties

아래 사진은 SA-1B dataset과 다른 segmentation dataset간의 object center의 spatial distribution을 나타낸것입니다. SA-1B가 다른 dataset에 비해 image corner의 coverage가 뛰어난 것을 알 수 있습니다. 특히 COCO나 Open Images dataset은 중앙에 편향된 masks만 가진것을 볼 수 있습니다.

아래 Fig 6의 legend에서는 다른 dataset들간의 크기를 비교하였습니다. SA-1B가 2번째로 큰 Open Images dataset보다 11배 많은 image, 400배 많은 masks를 가진다고 합니다. Fig 6 왼쪽에서는 image당 mask의 distribution을 비교하였습니다. SA-1B가 다른 dataset들에 비해 한 image에 더 많은 mask label이 있는 것을 알 수 있습니다. Fig 6 중앙에서는 SA-1B가 masks의 개수가 많기 때문에 다른 dataset들에 비해 small, midium size의 masks가 많습니다. 마지막으로 Fig 6 오른쪽에서는 masks shape의 complexity를 측정한 표입니다. Complexity를 측정하기 위해 mask concavity(오목함)를 측정하였고 SA-1B dataset에는 작은 masks가 많지만 다른 dataset들과 비슷하게 concavity을 가진다는 것을 알 수 있습니다.

GPT-1: Improving Language Understanding by Generative Pre-Training 논문 리뷰

Sin-Han Kang — Mon, 13 Feb 2023 21:19:55 +0900

오늘은 OpenAI의 GPT-1 논문을 리뷰하겠습니다.

1. Introduction

Natural Language Processing (NLP)를 포함한 대부분의 deep learning methods는 supervised learning을 통해 뛰어난 성능을 내는 모델을 만들었습니다. 뛰어난 성능을 내려면 기본적으로 많은 양의 labeled data을 필요로 합니다. 하지만 현실적으로 labeling은 사람이 하다 보니 정말~~ 많은 양의 labeled data는 구하기 힘들게 됩니다. 그에 비해 unlabeled data는 엄청 많습니다!

그래서, GPT-1은 수많은 unlabeled data로 unsupervised pre-training을 하고 labeled data로 supervised fine-tuning을 진행하는 semi-supervised방법을 사용하게 됩니다.

그럼 학습하는 데 unlabeled data 쓰는 게 어려움이 없냐?? 당연히 있습니다. Unlabeled data는 word-level information이상으로 활용하기가 어렵습니다.(성능 향상에 쓰이기 어렵다) 그 이유는 크게 2가지입니다.

특정 task(e.g. translation, question answering)에 transfer하기에 유용하다고 여겨지는 text representation을 학습하는 데 있어서 어떤 optimization objective이 효과적인지 알기 힘듦
학습된 text representation을 target task에 효과적으로 transfer하기 위한 일치된 의견(consensus)가 없음. 즉, 이러한 uncertainties가 language processing에서 semi-supervised learning방법을 발전시키기 어려움

이를 해결하기 위해 본 논문에서는 semi-supervised learning에서 다양한 task에 transfer하기에 적합한 universal representation을 학습하는게 목적입니다. 즉, 어떤 특정한 task를 수행하는 모델을 만들기 위해 해당 task와 관련된 domain의 unlabeled corpus를 필요로 하지 않습니다. GPT-1의 training은 two-stages procedure를 거칩니다.

Two-stages Training Procedure
1. Model의 initial parameters를 학습하기 위해 unlabeled data에 대해 language modeling objective를 사용
2. 학습된 initial parameters을 target task에 적용시키기 위해 supervised learning 학습

GPT-1의 기본 model architecture는 Transformer를 사용합니다. Transformer는 long-term dependencies을 제어하기 위해 structured memory를 제공할 수 있고 이 구조는 다양한 task에 transfer하기 용이합니다. Transfer(fine-tuning) 할 때는 traversal-style approach를 기반으로 하는 task-specific input adaptations을 사용합니다. 이 approach는 structured text input을 하나의 contiguous sequence of tokens으로 만들 게 되고 이를 통해서 모델의 최소한의 변경만으로 효과적인 성능을 얻을 수 있습니다.

Traversal-style approach란?
아래 그림과 같이 다양한 task의 입력을 start token, delimiter(문장 구분), end tokens(Extract)으로 이루어지도록 하는 것. 이를 통해 모델의 최소한의 변경만으로 효과적인 fine-tuning가능함

Traversal-style approach for effective fine-tuning

2. Methods

Training procedure는 two-stages로 나뉩니다. (1) 수많은 unlabeled text data로 high-capacity language model을 학습하는 1번째 stage, (2) labeled data을 통해서 특정 task에 맞게 fine-tuning하는 2번째 stage를 거칩니다.

2.1 Unsupervised pre-training

Unlabeled된 token corpus $ U = \{ u_1, \ldots, u_n \} $이 주어졌을 때 다음과 같이 likelihood를 최대화하기 위한 standard language modeling objective를 사용합니다.

\[
L_1(U) = \sum_i log P( u_i | u_{i-k}, \ldots, u_{i-1} ; \Theta) \quad \cdots Eq. (1)
\]

$ k $는 context window size, $ P $는 conditiional probability이며 이는 $ \Theta $ parameters로 구성된 network로 모델링되어있습니다. 해당 식을 풀이하자면 어떤 단어들을$u_{i-k}, \ldots, u_{i-1} $을 입력으로 주었을 때 그다음으로 나올 단어가 $ u_i $일 확률이 높도록 $ \Theta $을 학습하는 것입니다. 해당 network는 SGD optimizer로 학습했다고 합니다.

Language model로는 multi-layer Transformer Decoder를 사용하였습니다. Transformer Decoder는 기존의 Transformer의 encoder-decoder구조에서 encoder module을 제거하고(parameter반으로 줌) 원래의 input, output sentence를 a single sentence로 합쳐 해당 sentence를 모델의 입력으로 사용하는 구조입니다. 예를 들어, sequence-transduction data $ (m^1, \ldots , m^n) \mapsto (y^1, \ldots, y^{\gamma} ) $을 $ (w^1, \ldots ,w^{n+\gamma+1}) = (m^1, \ldots , m^n, \delta, y^1, \ldots, y^\gamma) $ 로 치환하는 것을 의미합니다. ( $ \delta $는 separator token)

Transformer architecture and training objectives

해당 모델은 context tokens을 입력으로 multi-headed self-attention operation을 적용하였고 position-wise feed-forward layer를 통해 target token에 대한 output distribution을 산출하였습니다.

\[
\begin{array}{l} h_0 = U W_e + W_p , \cr h_l = transformer_block (h_{l-1} \forall i \in [1,n] , \cr P(u) = softmax(h_n W^T_e) \end{array} \quad \cdots Eq. (2)
\]

$ U = (u_{-k} , \ldots , u_{-1} ) $은 tokens의 context vector, $n$은 layer 수, $W_e $는 token embedding matrix, $W_p $ 은 position embedding matrix입니다.

2.2 Supervised Learning

Eq (1)을 통해 unsupervised learning을 완료했다면 supervised target task에 맞게 fine-tuning하게됩니다. 논문에서는 labeled dataset $ C $을 가정합니다. (각 instance는 input tokens $x_1, \ldots, x_m $과 label $y$으로 이루어짐) Input tokens은 pre-trained model의 입력으로 들어가 마지막 transformer의 activation $ h^m_l $을 출력해 내고 (target task을 위해) 추가된 linear output layer( with parameter $W_y $ )을 거쳐 최종 output $ y $를 predict하게 됩니다.

\[
P(y | x^1 , \ldots , x^m ) = softmax(h^m_l W_y)\quad \cdots Eq. (3)
\]

Eq. (3)을 통해 나온 output $ P(y | x^1 , \ldots , x^m ) $은 아래와 같은 objective function을 maximize하도록 학습됩니다.

\[
L_2 (C) = \sum_{(x,y)} log P (y| x^1 , \ldots , x^ m) \quad \cdots Eq. (4)
\]

추가적으로 (1) supervised model의 generalization ability를 향상시키고 (2) convergence를 가속화시키기 위해 fine-tuning시에 auxiliary objective function을 사용하였습니다. 아래와 같이 기존의 unsupervised learning에 사용했던 loss term $ L_1(C) $도 추가하여서 supervised, unsupervised learning의 task모두 잘할 수 있도록 합니다. ( $ \lambda $는 weight parameter입니다.)

\[
L_3 (C) = L_2(C) + \lambda L_1(C) \quad \cdots Eq. (5)
\]

2.3 Task-specific input transformations

Text classfication같은 task경우 위의 방법 그대로 fine-tuning가능하지만 question answering, textual entailment와 같은 다른 task에는 고유한 structured input을 필요로 합니다. 그렇다고 각 task의 input 형태에 따라 모델을 크게 변경해야 한다면 이는 customization하는 cost가 많이 듭니다. 이를 해결하기 위해 traversal-style approach를 사용합니다. 해당 방법은 structured input을 unsupervised learning을 통해 pre-trained model에 process할 수 있도록 ordered sequence로 바꾸게 됩니다.

아래와 같이 모든 task에 대해 input transformations은 랜덤하게 initialized start, end tokens ( $ \langle s \rangle ,\langle e \rangle $ ) 을 포함합니다.

Traversal-style approach for effective fine-tuning

2.3.1 Textual Entailment

위 그림과 같이 premise $ p $와 hypothesis $ h $ token sequence들을 concatenate 합니다. 두 tokens을 구분하기 위해 delimiter(구분자) token $ $ $을 사용합니다.

2.3.2 Similarity

해당 task에서는 두 문장 사이에 가능한 ordering모두 고려하여 input transformations하여 두 개의 input을 만들고 각각 독립적으로 transformer의 output representations $ h^m_l $을 뽑아내고 element-wise하게 add operation하고 linear output layer을 거쳐 최종 output을 얻습니다.

2.3.3 Question Answering

Document $z$, question $q$와 가능한 answer set $ { a_k} $가 주어질 때 document context와 question을 한 묶음하고 각 가능한 answer을 delimiter token을 이용해 concatenate합니다. 즉, $ [z; q; $; a_k] $형태의 여러 개의 input을 만듭니다. 각 input sentence는 독립적으로 model을 거친 다음 sofmax layer을 통해 normalize시켜 possible answer들에 대해 output distribution을 얻습니다.

3. Experiment

3.1 Setup

Unsupervised learning에 BooksCorpus dataset을 사용하였습니다. 7000개의 미출판된 책의 내용을 담고 있으며 장르도 어드벤쳐, 판타지, 로맨스로 다양합니다. 대체가능한 dataset으로는 1B Word Benchmark이며 sentence-level로 shuffled되어 long-range structure를 없앴습니다. Unsupervised learning을 통해 해당 corpus에서 18.4이라는 낮은 token level perplexity(복잡성)을 도출하였다고 합니다. (저 perplexity 어떻게 scoring하는 지 아시는 분 있으신가요..?)

It contains over 7,000 unique unpublished books from a variety of genres including Adventure,

Fantasy, and Romance. Crucially, it contains long stretches of contiguous text, which allows the

generative model to learn to condition on long-range information. An alternative dataset, the 1B

Word Benchmark, which is used by a similar approach, ELMo [44], is approximately the same size

3.1.1 Model specifications

모델은 original transformer의 decoder부분만 사용하였습니다. masked self-attention heads(768 dim and 12 attentions heads)가 포함된 12 layer로 이루어져 있습니다. Position-wise feed-forward networks을 위해 3,072 dimension의 inner state를 사용하였습니다.

Model: original transformer의 decoder부분
- Masked self-attention heads(768 dim and 12 attentions heads)가 포함된 12 layers
- Position-wise feed-forward networks을 위해 3,072 dimension의 inner state를 사용
- Layer-Norm 사용됨
- N(0, 0.02)로 weight initialization
- Activation function으로 Gasuusian Error Linear Unit (GELU)사용
Optimizer: Adam
Learning rate: 2.5e-4
Scheduler: cosine annealing
Epochs: 100
Batch size: 64
Token length: 512
bytepair encoding (BPE) vocabulary 사용
- 40,000 merges와 residual, embedding, attention dropouts 포함
- 0.1 regularization
modified L2 regularization 사용
- 모든 non biasd와 gain weights에 대해 w=0.01
ftfy library을 사용하여 BooksCorpus의 raw text를 정리
spaCy tokenizer 사용

3.2.2 Fine-tuning details

명시되지 않았으면 unsupervised pre-training에 썼던 hyperparameter를 그대로 사용
0.1 rate의 dropout을 classifier에 추가
Learning rate: 6.25e-5
Batch size: 32
Epochs: 3 (3이면 충분하다고 합니다.)
Scheduler: linear learning rate decay
0.2%의 warm-up training
$ \lambda $: 0.5

3.2 성능

성능은 기존보다 당연히 좋을 거라 제 관심사가 아니므로 결과표만 보여드립니다.

Per-shot Encoding 설명

Sin-Han Kang — Mon, 6 Feb 2023 23:15:18 +0900

※ 해당 블로그를 reference하였습니다.

1. Per-shot Encoding 이란?

Conventional Encoding 방법은 하나의 video에 대하여 압축의 정도를 결정하는 Quantization Parameters(QPs)(e.g. CRF)값 '하나'을 인자로 encoding하는 방법을 취합니다. (CRF값이 클수록 compression을 많이 하게 되고 visual quality는 낮아집니다.)

하지만 이는 video내의 frame간의 특성을 고려하지 않은 채 단일한 QPs로 encoding하기 때문에 B(Bitrate)-D(Distortion) rate관계에서 최적의 성능을 뽑아내지 못합니다. 예를 들어, 한 video내의 초중반 frame들은 flat region이 많고 motion vector의 값이 작은 경우이고 중후반 frame들은 그 반대일 경우 하나의 CRF값으로 해당 video를 encoding하는 것은 효율적이지 않겠죠.

이를 해결하기 위해 Per-shot Encoding은 하나의 video를 여러 개의 shot으로 split한 다음에 각 shot마다 적절한 CRF, Resolution값을 encoding하고 concatenate하는 방법을 의미합니다. 각 shot마다 적절한 CRF와 Resolution을 주어 encoding가능하므로 B-D rate효율이 좋을 것입니다. Per-shot Encoding은 Dynamic Optimizer라고도 명명하며 Netflix에서 제안한 방법입니다.

Conventional Encoding vs Per-shot Encoding

또 다른 특징으로는 per-shot encoding은 shot마다 병렬적으로 encoding처리가 가능하고 하나의 shot에서 encoding error가 발생해도 오류가 발생한 shot만 다시 encoding하면 된다는 장점을 가집니다.

이후에는 좀 더 구체적으로 (i) 어떤 방법으로 video을 여러 개의 shot으로 나누는 지? (ii) 각 shot마다 적절한 CRF 값은 어떻게 찾는 지에 대한 방법은 Per-shot Encoding 알고리즘을 설명하면서 공유드리겠습니다.

2. Per-shot Encoding 알고리즘

Per-shot Encoding은 video을 입력으로 (1) Scene Detection을 통해 여러 개의 shot으로 나누고 (2) 각 shot별로 다양한 encoding configurations(e.g. CRF, Resolution, ...)을 인자로 encoding합니다. (3)

2.1 Scene(Shot) Detection

Per-shot Encoding은 video을 입력으로 받아 scene detection을 통해 여러 개의 shot으로 나누게 됩니다. 여기서 scene detection은 ffmpeg에서 제공하는 방법을 사용합니다.

ffmpeg -i ${input_video} -filter_complex "select='gt(scene, ${threshold})',metadata=print:file=${output_file}" -vsync vfr img%03d.png

위의 ${threshold}값은 0~1사이의 값이고 해당 값이 클수록 frame간의 변화가 커야 scene split이 일어납니다.

Scene Detection

2.2 Encoding shots with various encoding parameters

각 shot에 대해서 여러 CRF와 Resolution 값에 대해 모두 encoding합니다. CRF값과 resolution의 값이 정확히 어떤 범위 및 값인지는 확인할 수는 없지만 해당 Netflix 논문을 참고했을 때 CRF는 16, 20, 24, 28, 32, 36, 40, 44, 48이고 resolution은 1080p, 720p, 540p, 432p, 360p, 270p, 216p를 사용하였습니다.

CRF는 9개, resolution은 7개입니다. 예를 들어 shot의 개수가 10개라면 총 encoding trial 횟수는 9*7*10=630번입니다. 그래서 해당 부분의 processing이 시간이 많이 듭니다.

2.3 Evaluating each encoded shots using VMAF

각각 shot에 대해 여러 CRF와 resolution값으로 encoding했다면 각 encoding된 shot이 원본과 비교했을 때 (1) 얼마나 distortion되었는 지, (2) 얼마나 압축되었는지 측정해야합니다. Distortion 측정 방법으로는 Netflix에서 제안한 VMAF를 사용하고 압축정도는bitrate로 계산합니다. 여기서 VMAF값은 0~100사이의 값을 가지고 값이 높을 수록 원본으로부터 distortion(왜곡)이 "안된것"입니다. 그래서 그대로 VMAF값을 사용하면 distortion의미와 반대이므로 아래와 같이 둘 중에 하나의 값으로 distortion 정도를 계산합니다.

$ D_{Linear} (VMAF) = 100 - VMAF$
$ D_{Inverse} (VMAF) = \frac{1}{1+VMAF} $

Calculate bitrate and VMAF for each encoded shot

하나의 shot에 대해 여러 CRF, resolution으로 encoding하고 각각 encoded shot에 대해 bitrate, VMAF값을 구한 뒤에 R-D points를 graph로 visualization하면 다음과 같을 것입니다.

(R,D) points for a certain single shot

2.4 Extracting convex hull points for (R, D) points of each shot

위 그래프는 하나의 예시이지만 거의 대부분 shot에 대해서 convex hull모양의 R-D rate 그래프를 얻을 것입니다. 그럴 경우 Distortion T값을 기준으로 했을 때 a값을 가지는 180p가 b값을 가지는 144p보다 bitrate가 더 작은 것을 확인가능합니다. 즉, convex hull에 포함되는 point들이 특정 bitrate에서 가장 distortion이 낮은 것을 의미하고 또한 특정 distortion에서 가장 bitrate가 낮은 것을 의미합니다.

convex hull points들이 각 axis에서 가장 효율적인 encoded shot이므로 아래와 같이 convex hull points들만 뽑도록 합니다.

Convex hull of (R, D) points for a certain single shot

위 그래프처럼 convex hull points들만 뽑기 위해서 scipy.spatial.ConvexHull를 사용하시면 됩니다.

2.5 Constant slope principle for convex hull points of all shots

이제 아래와 같이 각 shot마다 convex hull points를 뽑인 상태입니다.

이 상태에서 각 shot마다 "최적의 encoded shot을 뽑아"서 concatenate하여 최종 per-shot encoding의 결과를 만들게 됩니다. 그렇다면 어떻게 최적의 encoded shot을 뽑을까요?

바로 constant slope principle을 이용하게 됩니다. Constant slope principle은 Integer Programming(IP) 문제랑 거의 같습니다. (저는 그냥 같다고 봅니다..ㅋㅋ) 그래서 풀어얘기하자면 constraint(e.g. 93 VMAF)를 만족하면서 objective function(e.g. bitrate 최소화)을 최대 or 최소화 시키는 알고리즘입니다. 즉, 각 shot마다 어떤 convex hull point을 골라야 (concatenate했을 때) 위의 constraint를 만족하면서 objective function을 최적화할 수 있는 지 알려주는 알고리즘이 constant slope priciple입니다.

(아시겠지만 convex hull points들이 continous한 값을 가지지 않고 discrete한 값을 가지므로 IP 문제입니다.)

Integer Programming 예시

Example of integer programming

per-shot enocoding으로 예를 들면 problem은 선택된 encoded shot들의 bitrate합이 Minimize되도록 할 것이고 subject to로는 선택된 encoded shot들의 평균 VMAF값이 93으로 설정하면 됩니다.

위 그림처럼 constraint를 bitrate로 주었을 때는 파란색 경로를 따라 평균 visual quality가 가장 높도록(distortion이 낮도록) 각 encoded shot들이 선택된 것을 볼 수 있지만 반대로 constraint를 visual quality로 주었을 때 빨간색 경로를 따라 평균 bitrate가 가장 낮도록 encoded shot들이 선택된 것을 볼 수 있다.

(constraint는 개발자가 주는 특정한 값입니다.)

2.6 concatenate selected convex hull points

마지막으로 위의 constant slope principle을 통해 선택된 (각 shot별로) encoded shot을 concatenate하면 최종 per-shot encoding의 결과물 video가 생성된다.

3. Results

Conventional encoding(Fixed Q)과 비교했을 때 per-shot encoding(Dynamic Optimizer)의 성능은 아래와 같다고 합니다. 같은 distortion기준으로 per-shot encoding의 bitrate가 15~20%정도 적은 것을 확인가능합니다. 굳!

The Forward-Forward Algorithm: Some Preliminary Investigations 논문 리뷰

Sin-Han Kang — Sat, 28 Jan 2023 17:11:28 +0900

오늘은 Hinton님의 The Forward-Forward Algorithm: Some Preliminary Investigations 논문을 리뷰입니다!

해당 논문의 목적은 기존 deep learning model의 학습방법인 backpropagation에 대한 단점을 지적하고 새로운 학습방법인 Forward-Forward 알고리즘을 제안하였습니다.

1. What is wrong with Backpropagation

Deep learning model의 backpropagation은 인간의 뇌가 학습하는 방법과 유사하게 설계되어있다고 알고 계신분들이 많은데요. 실제로 그렇지 않다고 하고 근거는 아래와 같습니다.

Backward pass를 하기위해 neural activity를 저장하거나 error derivate를 전파하는 과정이 인간의 뇌에서 일어나지 않았고 그런 증거가 발견되지 않았다고 함
인간의 뇌는 중단되는 시간이 따로 없이 다른 sensory processing stage을 통해서 sensory data을 전달할 필요가 있고 그때 그때 봐가며 learning이 될 수 있어야 함
- Error derivatives를 propagate하기위해 중단되는 시간이 생김
Backpropagation으로는 real time으로 inference와 learning이 불가함
Backprogation은 모델의 forward계산의 정확한 knowledge가 필요. 즉, differentiable할 수 없는 black-box에 대해 forward-pass한다면 backpropatgation못하는 문제점이 있음
- 이에 대한 방안으로 강화학습이 있지만 강화학습은 high variance를 가진다는 문제점을 가짐

그래서, 해당 논문의 주요 목적은 unknown non-linearities가 포함된 neural network에 강화학습을 사용할 필요가 없고 Foward-Foward algorithm(FF)을 사용하면 된다는 것입니다. 그리고 FF는 neural acitivities를 저장하지 않거나 error derivatives를 propagate하지 않고도 sequential data를 pipelining하면서 학습가능하다는 장점을 가집니다.

그럼 FF가 장점만 가지냐? 그건 아닙니다. 단점은 아래와 같습니다.

FF는 어떤 때에는 backpropagation보다 느림
Generalized되지않았기 때문에 다양한 task, application에 사용하기 아직 힘듬
- 큰 dataset으로 학습된 큰 model의 학습능력을 내기위해서는 backpropagation을 사용해야함

FF가 backpropagation보다 우수할 수 있는 두 가지 영역은 cortex안에서 model의 학습과 강화학습에 의존하지 않고 매우 낮은 전력의 analog hardward를 사용하는 방법입니다.

2. The Forward-Forward Algorithm

Forward-Forward Algorithm (FF)는 Boltzmann machine과 Noise Contrastive Estimation의 영감을 받은 greedy multi-layer learning방법입니다. 아이디어는 backpropagation의 forward, backward passes를 2개의 forward passes로 대체하는 것입니다.

FF의 첫 번째 forward는 기존과 같이 top-down 형식으로 forward를 진행하고 두 번째 forward는 각 layer에서 weight update를 진행합니다.

기존과 다른 또다른 점은 contrastive learning을 하는것입니다. 즉, positive pass와 negative pass를 나누어 weight를 update합니다. Positive pass는 real(positive) data에서 작동하며 매 hidden layer에서 goodness(잘햇어!)을 향상시키기 위해 weight를 조절합니다. 반대로 negative pass에서는 negative data에서 작동하며 매 hidden layer에서 goodness를 낮추기 위해 weight를 조절합니다. 그래서, FF를 사용하기 위한 충분 조건은 different data와 opposite objectives를 가져야하는 것입니다.

그럼 각 layer마다 goodness function을 어떻게 정의할까요? 해당 논문에서는 해당 layer안에서 rectified linear neurons의 activities의 제곱(square)의 합으로 정의한다고 합니다. FF learning은 real data에 대해서는 특정 threshold보다 높게 goodness가 출력되도록 하고 negative data에 대해서는 threshold보다 낮게 측정되도록 하는게 목적입니다. 이를 수식화하면 다음과 같습니다.

\[
p(positive) = \sigma ( \sum_j y^2_j - \theta ) , \quad \cdots Eq. (1)
\]

$ \sigma $는 logistic function(i.e. sigmoid)이며 $ \theta $는 threshold이며 $ y_j $는 layer normalization전의 $ j $번째 hidden unit의 acitivity값입니다. 위의 objective function이 loss function이 되고 Pytorch기준으로 loss.backward, optimizer.step을 통해 weight update합니다.

그리고 negative data는 외부에서 제공되거나 neural net의 top-down connection을 이용해서 predict되어 생성가능하다 합니다.

2.1 Learning multiple layers of representation with a simple layer-wise goodness function

만약 first hidden layer의 acitivities를 second hidden layer의 input으로 사용하고 싶다면 어떻게 해야할까?

FF는 first hidden layer의 hidden vector의 length을 normalize하여 second layer의 input으로 보낸다고 합니다. 이렇게 하면 first hidden layer에서 goodness를 계산하기 위해 사용했던 정보를 제거할 수 있고 next hidden layer에 first hidden layer의 relative acitivities의 정보를 사용할 수 있도록 합니다. (즉, relative acitivies는 layer normalization에 영향을 받아 없어지거나 하지 않는 것) 달리 표현하면 first hidden layer의 activity vector는 length와 orientation을 가지고 length(before layer normalization)는 그 layer의 goodness를 define하는데 사용되고 orientation(after layer normalization)은 next layer에 전달하기위해 사용됩니다.

3. Some experiments with FF

FF가 small neural network에서 어떻게 작동하지 설명하도록 합니다.

3.1 The backpropagation baseline

새로운 learning 알고리즘을 설명하고 성능을 확인하기에 가장 적합한 MNIST에 대해 실험하려고 합니다. 그 전에 backpropagation을 사용했을 때 성능에 대해 이야기합니다. CNN을 사용하면 0.6% test error을 가진다고 합니다. 그리고 permutation-invarient task에서는 FC layer와 ReLU를 사용하면 1.4% test error를 가진다고 합니다. 즉, complicated regularizer사용 없이 backpropagation을 사용하면 1.4% test error 성능을 가지게 됩니다.

permutation-invarient task란?
입력 벡터 요소의 순서와 상관없이 같은 출력을 생성하는 모델을 뜻하며 대표적인 모델로는 MLP이다. permuation-invarient task가 아닌 모델로는 입력 이미지의 픽셀의 순서를 고려하는 CNN이 있다.

3.2 A simple supervised example of FF

※ 해당 글에서는 unsuperivsed, nlp, reccurent net에 대한 내용은 skip하고 supervised에 대한 내용만 다루겠습니다.

Supervised leraning은 single task, small model을 사용하고 싶을 때 유용한 방법입니다. 이를 FF에 적용하기 위해서는 input에 label을 포함시키는 방법을 사용합니다. Positive data에는 옳바른 label을 포함하고 있는 input image들로 구성되고 negative data는 틀린 label을 포함하고 있는 input image들로 구성됩니다. Positive, negative data의 다른 점은 오직 label이기 때문에 FF알고리즘은 label과 연관되어 있지 않은 image의 feature 정보는 모두 무시할 것입니다.

그럼 label을 어떻게 data에 포함할까요?
MNIST기준으로 설명드리면 class가 10개이므로 image의 첫 10 pixels에 label정보를 기입하는 것입니다. 이렇게 하여 논문에서는 60 epochs, 4 hidden fc layers, 2000 ReLUs로 구성된 network로 1.36% test errors를 얻었다고 합니다. 해당 결과는 backpropagation을 사용했을 때는 20 epoch으로 낼 수 있는 성능이라고 합니다.

FF로 training하고 나면 inference는 어떻게 진행할까요?
Inference시에는 test image의 첫 10 pixel에 neutral label(모두 0.1값)을 포함시켜서 single forward pass를 통해 classify한다고 합니다. 첫 번째 hidden layer의 activities(features)을 제외하고 다른 모든 hidden layer의 acitivities값에 대해 softmax을 적용하고 다 더해줍니다. 더했을 때 가장 큰 값을 가진 class index가 model의 최종 output class가 됩니다.

(이 부분이 제가 읽은 책중에 천개의 뇌 이론과 비슷하더라고요. 책에서는 수많은 뇌세포가 투표를 통해 객체가 무엇인지 판단한다고 하는데 각 뇌세포를 layer의 node라고 생각한다면 여러 layer의 여러 nodes의 acitivity값의 합(투표)으로 최종 class를 결정하니 비슷하네요)

이 방법은 neutral label을 사용하기 때문에 빠르지만 sub-optimal한 방법입니다. 그래서 논문에서는 input image에 특정한 하나의 label을 가진 input을 사용하는 것이 좋다고 합니다. 0 label을 가진 image, 1 label을 가진 image, ...., 9 label을 가진 image를 개별적으로 넣어보고 더했을 때 가장 높은 gooodness를 가진 label을 최종 output class 선택합니다.

추가적으로 해당 논문에서는 FF를 위한 data augmentation방법인 image jitttering을 제안하였습니다. 각 image마다 모든 방향으로 최대 2 pixels까지 shifting하여 총 25개의 다른 image를 생성하게 됩니다.

Image jittering

Image jittering을 통하여 pixel간의 spatial layout knowledge를 학습하도록 하게 하였고 결론적으로 permutation invariant을 없앴다고 합니다. 해당 augmentation과 함께 500 epochs을 학습하였을 때 CNN과 비슷한 test error인 0.64%을 도출하였다고 합니다.

그리고 흥미로운 결과로는 first hidden layer의 recpetive field를 보았을 때 아래와 같이 image의 첫 10 pixels에서 class label이 학습되는 것을 볼수 있습니다.

ML/DL Experiments and Analysis

Sin-Han Kang — Tue, 10 Jan 2023 10:37:06 +0900

A. Model & Module

Pyramid Pooling Module(PPM): 기존의 local feature(b)와 pooling을 통한 global feature(c의 색깔 있는 output들)을 모두 학습하기 위함
1. 서로 다른 kernel size로 여러 차례 avg pooling(논문에서 1x1, 2x2, 3x3, 6x6 kernel size 사용)
  - 1x1 size의 feature map은 가장 global feature이고 feature map size가 커질수록 local feature에 가까워짐
2. 1x1 convolution을 통해 channel 수를 조정
  - pooling layer의 개수를 N이라고 할 때, 출력 channel 수 = 입력 채널 수 / N
3. input size에 맞춰 feature map을 upsample(bilinear interpolation)
4. 원래의 feature map과 생성된 새로운 feature map들을 concatenate

SE(Squeeze & Excitation) Module: channel relationship에 초점을 맞추어 학습에 중요한 channel에 가중치를 주는 방법
1. $U $의 $C $는 각각이 고유한 특징을 가짐, $ U $에 대해 squeeze operation(global avg pool)을 진행하여 $ U$를 대표하는 feature vector $ 1 \times 1 \times C $을 뽑음
2. Channel간의 relationship을 feature map $ U $에 적용시키기위해 다음과 같이 Excitation operation 진행
  - Excitation은 FC1(T) - ReLU(T) - FC2(C) - Sigmoid(C)로 구성 (각 layer옆은 output channel을 의미, $T < C $)
  - FC1 layer와 ReLU을 통해 $C$보다 작은 $T$채널로 수축시켜 channel간의 관계를 고려할수 있게 함
  - FC2 layer를 통해 원래 채널수 $ C $로 돌려놓고 sigmoid를 통해 가중치 형태인 0~1값 갖도록 하여 $ U $에 곱해줌

B. Loss

Focal loss: CE에서 well-classified(easy sample)에 대해서는 loss를 더 작게 만들기 위해 $ (1 - p_t)^\gamma $을 추가
- 아래는 label이 1인 경우의 loss식이며 $ p_t $가 1에 가까울 수록 $ \gamma $에 의해 loss가 exponential 하게 작아지게하여 상대적으로 easy sample의 loss를 CE때보다 급격히 줄임
- $ \gamma $가 0일때 CE랑 같음

CIoU loss: 겹치는 영역(IoU), 중심점 사이의 거리, 종횡비 세가지 메트릭을 동시에 고려한 것 (DIoU의 확장버전)
- $ CIoU = 1- IoU + \frac{\rho^2(b, b^{gt})}{c^2} + \alpha v $

C. Optimizer

D. Data Augmentation

CutMix (CVPR 2019): 모델이 객체의 차이를 식별할 수 있는 부분에 집중하지 않고, 덜 구별되는 부분 및 이미지의 전체적인 구역을 보고 학습도록 하여 일반화와 localization 성능을 높이는 방법.
- OOD(out-of-distribution)와 이미지가 가려진 sample, adversarial sample에서의 robustness도 좋은 성능

Copy & Paste (CVPR 2021) : Segmentaiton에서 사용가능

Copy and Paste

E. Engineering

Pytorch training 최적화: 요기
Pytorch output slicing을 통한 loss 계산시(graident에 사용되는) 주의점
- If the shape of output is (4(B), 2(C), 320(W), 320(H)]
- Wrong → out1 = output[:, 0, :, :], out2 = output[:, 1, :, :]
- Correct → out1 = output[:, :1, :, :], out2 = output[:, 1:, :, :]
SOD에서 encoder(i.e. resnet, efficientnet)의 low level feature는 너무 많은 details을 가지는 반면에 high level feature는 rough한 결과를 내뽑음 (Reference: Pyramid Feature Attention Network for Saliency detection)
- Low level feature에는 detail이 많고 sod는 boundary를 찾는 게 목적이니 spatial attention을 사용
- High level feature에는 rough한 영역이 많으니 channel attention을 통해 high response를 내는 channel에 가중치 줌 (salient object찾는데 좋음)
- Low level feature + high level feature를 aggregation하고 channel attention, spatial attention한 논문이 Tracer(AAAI 2022)

Per-title Encoding 설명

Sin-Han Kang — Sat, 3 Dec 2022 19:44:54 +0900

※ 해당 블로그를 reference하였습니다.

Per-title Encoding은 Netflix에서 제안한 video encoding방식입니다. 말 그대로 per-title encoding은 title에 따라 encoding을 다르게 하겠다라는 말입니다. 이는 video가 속한 title(category)에 따라 특성이 다르다는 것을 의미하며 title에 따라 encoding 압축율을 다르게 하겠다는 것입니다.

1. 기존의 Encoding 방식

Netflix에서는 2010년 후반부터 H.264/AVC를 사용하기 시작하면서 engineer들은 각 resolution에 따라 경험적으로 optimal한 bitrate를 찾는 데 수많은 실험을 하였습니다. Codec parameters(e.g. crf, QPs, resolution, profile)을 바꿔가면서 compression rate(bitrate)과 visual quality의 trade-off을 최소화 시킬수 있는 bitrate-resoultion pairs(bitrate ladder 라고 명명)을 아래 표와 같이 찾아 내었습니다.

Fixed bitrate ladder

위의 표를 해석하면 320x240 resolution으로 encoding하기에는 235 kbps bitrate면 충분하다라는 의미입니다. 위 표처럼 resolution에 따라 bitrate가 정해진 표를 fixed bitrate ladder라고 합니다.

하지만 하나의 resolution에 대해 동영상들을 모두 같은 bitrate로 압축하는 것은 각 동영상들의 특성을 고려하지 않는 것이며 이는 압축 효율이 떨어진다고 말할 수 있습니다. 그래서 동영상마다의 특성을 고려해서 bitrate ladder을 구해보자! 라는 생각에서 Per-title encoding이 개발되었습니다.

2. Per-title Encoding 이란?

Animation이라는 title을 가진 동영상의 경우 대부분 content가 simple합니다. Simple하다는 것은 flat region이 많으며 frame사이의 minimal한 motion만 존재한다는 뜻입니다. 이러한 특성때문에 animation이라는 title을 가진 동영상은 low bitrate를 가져도 visual quality(e.g. PSNR, VMAF)가 크게 낮아지지 않습니다. 그래서 title마다 성격을 고려하여 bitrate ladder를 구성하는 것이 per-title encoding입니다.

2.1 Algorithm

per-title encoding bitrate ladder을 구성하기 위해 각 title category마다 아래와 같은 finite set으로 encoding configuration을 제한하였습니다.

Resolution
- 1920x1080, 1280×720, 720×480, 512×384, 384×288 and 320×240
QPs
- bitrate간의 간격이 5%정도가 될 수 있도록 하는 QPs선택
  - bitrate interval examples: 100, 105, 110.25, ...
  - 5%의 차이가 시각적인 JND(Just Noticeable Difference)를 느낄 수 있는 수치임
    (1 JND가 vmaf값 6정도차이를 말함)
  - 정확히 어떤 QPs값을 사용하였는지는 모름...ㅠ

위의 셋팅으로 encoding진행하였을 때 아래와 비슷한 PSNR(quality)-bitrate rate 그래프를 얻을 수 있었습니다. (아래는 설명을 위한 예시 그래프입니다.)

파란색 점: encoding point, 빨간색 커브: the PSNR-bitrate convex hull.

PSNR과 bitrate의 trade off관계를 봤을때 위 사진의 빨간색 커브에 속하는 점들이 optimal encoding configuration이고 A, B점은 sub-optimal한 점들입니다. (위 그래프의 한정으로) 1920x1080 resolution으로 높은 range의 bitrate(1500~3000kbps)에 대해 encoding할 경우 optimal하지만 낮은 range의 bitrate(0~1000kbps)에 대해서는 1280x720이나 720x480 resolution이 optimal한 점입니다.

이러한 특성을 종합하였을 때 결론적으로 quality-bitrate relationship은 아래와 같은 형태를 띈다고 실험적으로 증명하였습니다.

Convex hull for bitrate-quality graph

Convex hull에 포함되는 점들이 optimal한 encoding configuration이고 convex hull points들은 Pareto efficiency(trade-off관계를 가진다고 이해)를 가집니다. 그래서 Per-title encoding에서는 convex hull에 포함되는 bitrate-resoultion pair를 선택할 수 있도록 하였습니다.

최종적으로 algorithm process를 정리하면 다음과 같습니다.

Title별로 video를 분류
위에서 언급한 finite한 resolution, QPs set으로 encoding하여 bitrate와 quality을 측정
bitrate-quality relationship그래프에서 각 candidate resolution마다 convex hull에 근접한 point들을 골라 bitrate ladder를 구성함

2.2 Quantitative Results

Fixed QP encoding과 비교하였을 때 Per-title Encoding의 성능개선 결과를 정량적으로 보여드립니다. 특히나, Anmation title(flat region이 많고 frame간의 움직임이 적음)을 가진 video에 대한 per-title encoding성능을 측정 및 비교하였습니다.

Per-title encoding performance for an animation title

1920x1080 resolution기준으로 per-title encoding의 A는 2350 kbps로 encoding했을때 PSNR가 46정도로 high visual quality를 가지지만 fixed QP encoding의 B나 C는 A보다 bitrate는 훨씬 높지만 비슷한 visual quality을 가집니다. 또한 A와 D를 비교했을 때 fixed QP encoding의 D는 A와 비슷한 bitrate를 가지지만 PSNR점수가 훨씬 낮으므로 per-title encoding이 fixed QP encoding보다 좋은 성능을 내었음을 알수 있습니다.

2.3 Qualitative Results

(왼쪽) fixed bitrate ladder으로 480p resolution에 대해 encoding한 경우 1750 kbps의 bitrate를 가지지만 (오른쪽) per-title bitrate ladder을 사용시에는 1080p resolution에 대해 1540 kbps의 bitrate를 가집니다. 즉, per-title bitrate ladder를 사용하였을 경우 더 좋은 visual quality와 compression efficiency을 가지는 것을 볼 수 있습니다.

PyTorch training/inference 성능 최적화 (2/2)

Sin-Han Kang — Tue, 22 Nov 2022 23:09:46 +0900

이전 글에서 Pytorch framework에서 성능 최적화하는 방법을 소개해드렸습니다. 이번 글에서는 설명드린 각 방법들이 얼마만큼 time cost 성능 최적화가 되는지 실험해보도록 하겠습니다. 실험 코드는 여기서 확인가능합니다.

실험해볼 최적화 방법 목록입니다.

Data Loading 최적화
- num worker 설정
- pinned memory 사용
Data Operation 최적화
- tensor.to(non_blocking=True) 사용
Training 최적화
- Architecture design과 batch size를 8의 배수로 설정
- Mixed Precision Training 사용
- Optimizer로 weight를 update하기 전에 gradient을 None으로 설정
- Gradient accumulation 사용
Inference 최적화
- Inference시에 gradient calculation 끄기
CNN 최적화
- torch.backends.cudnn.benchmark = True 사용
- 4D NCHW tensors에 대해 channel_last memory format를 사용

0. 실험 환경

Device 및 PyPI
- CPU: Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz (가상 core수: 56)
- GPU: Tesla V100
- CUDA: 11.2
- Driver Version: 460.73.01
- torch: 1.8.1
Dataset
- CIFAR10
  - shape: 32(H)x32(W)x3(C)
Model
- ResNet18, 50, 101
- MobileNetv2
기본 Config
- num_workers=4, pin_memory=True
- batch_size=128
- epochs=5

※ 모든 실험의 결과의 단위는 초(s)이며 5번의 epoch에 대한 평균치를 낸 것입니다. (첫 epoch제외)

1. DataLoading 최적화

1.1 & 1.2 num_workers와 pinned_memory의 사용

num_workers와 pinned_memory 설정은 각각 단독으로 사용하기보다는 같이 사용합니다. 그렇기 때문에 두 설정을 동시에 사용했을 때와 그렇지 않을 때의 성능 차이를 보도록 하겠습니다. 사용 방법은 아래와 같습니다.

# Use num_workers=4 and pin_memory=True
Dataloader(dataset, num_workers=4*num_GPU, pin_memory=True)

	ResNet18	ResNet50	ResNet101	MobileNetv2
num_workers=0, pin_memory=False	train: 36.5s test: 2.8s	train: 74.2s test: 5.1s	train: 113.0s test: 7.3s	train: 35.8s test: 2.8s
num_workers=4, pin_memory=True	train: 20.5s test: 1.5s	train: 58.0s test: 3.6s	train: 96.8s test: 5.8s	train: 20.1s test: 1.4s
num_workers=8, pin_memory=True	train: 20.9s test: 1.8s	train: 58.2s test: 3.8s	train: 97.2s test: 6.0s	train: 20.5s test: 1.7s

위의 결과를 분석하자면 다음과 같다.

num_workers와 pin_memory 설정을 사용하였을 때 time cost가 줄어든 것을 확인 가능
data loading에 최적화된 방법이므로 model에 상관없이 고정된 time cost 성능 효과를 보임
(GPU 1개 기준) num_workers의 optimal한 값은 4이고 그 이상인 경우(i.e. 8) 성능 효과가 보이지 않음

2. Data operation 최적화

2.1 tensor.to(non_blocking=True) 사용

non_blocking에 대한 설정은 아래와 같이 input, target(label)에서 가능합니다.

for input, target in Dataloader:
    # 아래 2 lines을 통해 non-blocking과 overlapping이 진행
    input = input.to('cuda:0', non_blocking=True)
    target = target.to('cuda:0', non_blocking=True)
    
    # 해당 구간에서 input과 target의 변수가 사용되지 않는 선에서 코딩을 할경우
    # 비동기적으로 실행되므로 execution time을 줄일 수 있음 
    
    # synchronization시점으로 위의 2 lines을 기다리는 구간
    output = model(input)

	ResNet18	ResNet50	ResNet101	MobileNetv2
w/o non_blocking	train: 20.4s test: 1.4s	train: 58.1s test: 3.6s	train: 96.9s test: 5.8s	train: 20.1s test: 1.4s
w non_blocking	train: 20.4s test: 1.4s	train: 57.9s test: 3.6s	train: 97.0s test: 5.8s	train: 20.0s test: 1.4s

위 결과를 분석하면 다음과 같습니다.

성능 효과가 없는 것으로 보임
구글링해보니 설정으로 time cost성능 효과를 내지 못한 경우가 있다고 함..ㅠ
- 이에 대해 더 궁금한 점은 패트릭형님의 답변을 보세용.

3. Training 최적화

3.1 Architecture design과 batch size를 8의 배수로 설정

기존의 network보다 input, output channel을 1씩 줄이고 batch size는 1을 올려서 실험하였습니다. (이에 해당하는 모델들은 아래 표에서 rec model이라고 명명하고 기존 모델을 base model이라고 칭하겠습니다.) 일반적으로 생각하면 batch가 클수록 channel수가 작을수록(model이 작을수록) time cost가 줄어야 하지만 해당 최적화 방법에 근거하면 batch size와 channel수가 8의 배수가 아닐 경우 NVIDIA GPU 최적화가 되어있지 않아 있으므로 time cost가 늘어나게 됩니다.

	ResNet18	ResNet50	ResNet101	MobileNetv2
base model	train: 20.4s test: 1.5s	train: 57.9s test: 3.6s	train: 96.9s test: 5.8s	train: 19.9s test: 1.4s
rec model	train: 22.7s test: 1.5s	train: 59.9s test: 3.7s	train: 103.0s test: 5.8s	train: 20.0s test: 1.4s

위 결과를 분석하면 다음과 같습니다.

batch size가 커지고 channel수가 줄어듬에도 불구하고 training time이 느려지는 것을 확인 가능!

3.2 Mixed Precision Training 사용

import torch

scaler = torch.cuda.amp.GradScaler() # Training시에 생성

for data, label in data_iter:
   optimizer.zero_grad()
   with torch.cuda.amp.autocast(): # Mixed precision으로 operation들을 casting 
      outputs = model(data)

   scaler.scale(loss).backward() # Loss를 scaling한 후에 backward진행
   scaler.step(optimizer) # 원래 scale에 맞추어 gradient를 unscale하고 optimizer를 통한 gradient update
   scaler.update() # 다음 iteration을 위해 scale update

	ResNet18	ResNet50	ResNet101	MobileNetv2
w/o mixed precision	train: 20.4s test: 1.4s	train: 58.0s test: 3.6s	train: 97.1s test: 5.8s	train: 20.4s test: 1.5s
w mixed precision	train: 10.4s test: 1.4s	train: 25.9s test: 3.6s	train: 43.9s test: 5.8s	train: 22.2s test: 1.5s

위 결과를 분석하면 다음과 같습니다. (해당 방법은 training time성능에만 영향을 미침)

mixed precision사용 시 50%정도의 training time cost성능 향상을 보임
MobileNetv2과 같은 depthwise conv가 있는 경우 또는 작은 model인 경우에는 time cost가 줄어들지 않고 늘어나는 것으로 추측

3.3 Optimizer로 weight를 update하기 전에 gradient을 None으로 설정

# gradient를 None으로 설정 (PyTorch >= 1.7)
optimizer.zero_grad(set_to_none=True)

	ResNet18	ResNet50	ResNet101	MobileNetv2
w/o gradient none	train: 20.5s test: 1.4s	train: 58.0s test: 3.5s	train: 97.2s test: 5.8s	train: 20.3s test: 1.4s
w gradient none	train: 20.0s test: 1.4s	train: 57.2s test: 3.7s	train: 95.9s test: 5.8s	train: 19.6s test: 1.4s

위 결과를 분석하면 다음과 같습니다. (해당 방법은 training time성능에만 영향을 미침)

모델이 작을 경우 time이 거의 줄지 않지만 모델이 커질수록 해당 설정으로 인한 time cost성능 향상 효과를 보임

3.4 Gradient accumulation 사용

for i, (input, target) in enumerate(dataloader):
    output = model(features)
    loss = criterion(output, target)
    loss.backward()
    
    # 매 2번의 iteration이 끝난 뒤에 weight를 update하여 batch size가 doubled되어 학습하는 효과를 줌 
    if (i+1) % 2 == 0 or (i+1) == len(dataloader):
        optimizer.step() # weight update
        optimizer.zero_grad(set_to_none=True)

	ResNet18	ResNet50	ResNet101	MobileNetv2
w/o gradient accumulation	train: 20.2s test: 1.4s	train: 57.5s test: 3.6s	train: 96.2s test: 5.8s	train: 19.8s test: 1.4s
w gradient accumulation	train: 19.9s test: 1.4s	train: 56.9s test: 3.6s	train: 95.3s test: 5.8s	train: 19.4s test: 1.4s

위 결과를 분석하면 다음과 같습니다. (해당 방법은 training time성능에만 영향을 미침)

모델에 커짐에 따라 조금의 time cost향상이 보임
- 위의 근거를 뒷받침하기에는 실험이 적으므로 더 큰 모델로 실험해볼 필요가 있음

4. Inference 최적화

4.1 Inference시에 gradient calculation 끄기

# inference코드에서 (decorator) torch.no_grad() 사용
@torch.no_grad()
def validation(model, input):
    output = model(input)
return output

	ResNet18	ResNet50	ResNet101	MobileNetv2
w/o no_grad	test: 1.4s	test: 3.6s	test: 5.8s	test: 1.4s
w no_grad	test: 1.4s	test: 3.6s	test: 5.7s	test: 1.4s

위 결과를 분석하면 다음과 같습니다. (Inference에 대한 최적화이므로 test에 대한 수치만 표시함)

time cost의 성능에 향상은 없다고 보임
아마.. memory cost측면에서 성능 개선이 있을 것으로 추측

5. CNN 최적화

5.1 torch.backends.cudnn.benchmark = True 사용

torch.backends.cudnn.benchmark = True

	ResNet18	ResNet50	ResNet101	MobileNetv2
w/o cudnn. benchmark	train: 20.2s test: 1.4s	train: 55.1s test: 3.6s	train: 93.8s test: 5.7s	train: 19.8s test: 1.4s
w cudnn. benchmark	train: 20.2s test: 1.4s	train: 55.2s test: 3.6s	train: 93.8s test: 5.8s	train: 19.7s test: 1.4s

위 결과를 분석하면 다음과 같습니다.

cudnn.benchmark사용설정을 해도 time cost성능 효과는 없어 보입니다..ㅠㅠ

5.2 4D NCHW tensors에 대해 channel_last memory format를 사용

inputs = inputs.to(self.device, memory_format=torch.channels_last)

	ResNet18	ResNet50	ResNet101	MobileNetv2
w/o channel_last	train: 10.4s test: 1.4s	train: 26.0s test: 3.6s	train: 46.3s test: 5.8 s	train: 22.1s test: 1.4s
w channel_last	train: 10.0s test: 1.4s	train: 22.8s test: 3.6s	train: 40.8s test: 5.8s	train: 20.9s test: 1.4s

위 결과를 분석하면 다음과 같습니다. (test때는 channel last를 안썻습니다..ㅋㅋ)

모델의 크기가 증가할수록 memory format의 설정이 time cost를 줄이는 데 효과적임

PyTorch training/inference 성능 최적화 (1/2)

Sin-Han Kang — Sun, 13 Nov 2022 12:58:50 +0900

오늘은 해당 블로그의 내용을 베이스로 하여 PyTorch framework에서 training/inference 성능 최적화를 하는 것을 목적으로 설명드릴 것입니다.

성능이라 함은 1. speed, 2. memory에 대한 성능을 뜻합니다. speed에 대한 성능이 좋다함은 training 및 inference time cost가 적다는 것이고 memory에 대한 성능이 좋다는 것은 training 및 inference에 사용되는 memory가 적다는 것입니다.

오늘 소개할 최적화 방법에 대한 목록은 다음과 같다.

Data Loading 최적화
- num worker 설정
- pinned memory 사용
Data Operation 최적화
- torch.Tensor 사용과 device 할당
- CPU와 GPU간의 data transfer 줄이기
- tensor.to(non_blocking=True) 사용
Training 최적화
- Architecture design과 batch size를 8의 배수로 설정
- Mixed Precision Training 사용
- Optimizer로 weight를 update하기 전에 gradient을 None으로 설정
- Gradient accumulation 사용
Inference 최적화
- Inference시에 gradient calculation 끄기
CNN 최적화
- torch.backends.cudnn.benchmark = True 사용
- 4D NCHW tensors에 대해 channel_last memory format를 사용
- Conv-BN 구조에서 Conv의 bias 사용하지 않기

1. Data Loading 최적화

1.1 num worker 설정 (time cost ↓)

Dataloader의 parameter인 num_workers는 data loading 및 augmentation을 cpu작업을 통해 하는 데 몇 개의 cpu core를 사용할 것인지 결정합니다. num_workers=0 은 weight update나 전에 실행되었던 process가 끝난 뒤에만 data loading을 하게 됩니다. 이는 동기적(synchronuous)으로 작동하기 때문에 speed성능측면에서 좋지 않습니다. 그래서 num_workers >0으로 설정 하여 data loading 및 augmentation 작업이 비동기적(asynchronuous)으로 가능해지기 때문에 training시에 time cost를 줄이게 됩니다. 그렇다고 num_workers의 값을 너무 크게 준다면 memory 사용에 overhead를 주기 때문에 num_workers=4*num_GPU가 실험적으로 적절한 값이라고 합니다.

Dataloader(dataset, num_workers=4*num_GPU)

1.2 pinned memory 사용 (time cost ↓)

아래 왼쪽 사진과 같이 GPU는 CPU의 pageable memory에 direct로 접근이 불가하며 staging memory(a.k.a pinned memory)를 거쳐서 data에 접근가능합니다. 이렇게 거쳐서 간다면 time cost가 오르겠죠. 해당 문제를 해결하기 위해 pin_memory=True를 사용하여 data를 CPU위의 staging memory(a.k.a pinned memory)에 할당합니다. 이렇게 되면 pageable memory가 staging memory를 거쳐가는(transfer) 시간을 줄이게 됩니다. 해당 옵션은 위의 num_worker와 같이 사용되는 파라미터입니다.

https://miro.medium.com/max/1400/1*M8mejDZ5WbnFl8h59UfjCg.png

Dataloader(dataset, pin_memory=True)

2. Data Operation 최적화

2.1 torch.Tensor 사용과 device 할당 (time cost ↓)

Data를 정의하거나 만들때 torch.Tensor를 사용하고 device를 torch.Tensor사용시에 할당하는 것이 효율적이다. 반대로 말하면 data를 정의할때 Python이나 Numpy를 사용해서 만들지 말라는 것이다. 모델을 학습할 경우 대부분 GPU를 통해 학습할텐데 Python이나 Numpy를 통해 만들고 torch.Tensor로 transfer한다면 CPU로 만들고 GPU로 변환하는 과정을 겪기때문에 time cost가 더 늘어난다. 하지만 torch.Tenosr로 즉시 GPU device에 할당하여 data를 정의한다면 time cost가 최적화된다.

# np.random.rand([10,5])와 같음
tensor = torch.rand([10, 5], device=torch.device('cuda:0'))

# np.random.randn([10,5])와 같음
tensor = torch.randn([10, 5], device=torch.device('cuda:0'))

2.2 CPU와 GPU간의 data transfer 줄이기 (time cost ↓)

I/O cost를 최대한 줄이기위해 아래와 같은 CPU와 GPU간의 data transfer를 자제하는 것이 좋습니다.

# BAD! AVOID THEM IF UNNECESSARY!
print(cuda_tensor)
cuda_tensor.cpu()
cuda_tensor.to_device('cpu')
cpu_tensor.cuda()
cpu_tensor.to_device('cuda')
cuda_tensor.item()
cuda_tensor.numpy()
cuda_tensor.nonzero()
cuda_tensor.tolist()

2.3 tensor.to(non_blocking=True) 사용 (time cost ↓)

아래 사진과 같이 tensor.to(non_blocking=True)으로 설정하면 data transfer가 비동기적으로 진행되어 execution time을 줄일 수 있다.

https://miro.medium.com/max/1390/1*no-gQHz8daJbmYhCfAGNOA.png

for input, target in Dataloader:
    # 아래 2 lines을 통해 non-blocking과 overlapping이 진행
    input = input.to('cuda:0', non_blocking=True)
    target = target.to('cuda:0', non_blocking=True)
    
    # 해당 구간에서 input과 target의 변수가 사용되지 않는 선에서 코딩을 할경우
    # 비동기적으로 실행되므로 execution time을 줄일 수 있음 
    
    output = model(input)# synchronization시점으로 위의 2 lines을 기다리는 구간

3. Training 최적화

3.1 Architecture design과 batch size를 8의 배수로 설정 (time cost ↓)

GPU의 computation efficiency를 최대화 하기위해서는 모델의 input과 output의 size, channel 수, batch size모두를 8의 배수로 설정해야한다. 그 이유로는 Nvidia GPU의 Tensor core들이 8의 배수로 matrix로 align되어있을때 가장 optimal한 성능을 내기 때문이다.

해당 실험에서 보이듯이 output size와 batch size를 8의 배수(i.e. 33712, 4088, 4096)으로 설정하였을 때 8의 배수가 아닌 수(i.e. 33708, 4084, 4095)로 설정하였을 때보다 1.3~4배정도 computation이 빨랐다고 합니다. 이렇게 속도 차이를 나게하는 주 component는 process type(e.g. forward pass, gradient calculation)와 cuBLAS version입니다.

3.2 Mixed Precision Training 사용 (time, memory cost↓)

Mixed Precision Training은 single-precision(FP32)와 half-precision(FP16) format을 결합하여 사용하여 training하는 방식을 말합니다. 기존의 FP32만 사용하는 방식보다 data size가 작은 FP16을 섞어 사용하기 때문에 memory 사용이나 training 속도면에서도 이득을 취할 수 있습니다.

해당 방법에 대한 자세한 내용은 이전 글에서 읽어보시고 사용하시면 됩니다.

3.3 Optimizer로 weight를 update하기 전에 gradient을 None으로 설정 (time cost ↓)

기존처럼 model.zero_grad()나 optimizer.zero_grad()함수를 통해 gradient를 0으로 설정하는 것은 모든 파라미터에 memset을 실행시키고 reading과 writing operations으로 gradient을 update하는 것이다. 하지만 graident를 None으로 설정하게 되면 memse함수를 실행하지 않고 writing operation만으로 gradient를 update가능하다. 그래서 optimizer.zero_grad()를 사용하는 것보다 gradient를 None으로 설정하는 것이 더 빠르다.

# gradient를 None으로 설정 (PyTorch < 1.7)
for param in model.parameters():
    param.grad = None

# gradient를 None으로 설정 (PyTorch >= 1.7)
optimizer.zero_grad(set_to_none=True)

3.4 Gradient accumulation 사용 (time cost ↓)

Gradient accumulation은 한 batch에서 계산된 loss을 통해 바로 gradient를 update하는 것이 아닌 여러 batch으로부터 gradient을 쌓은(accumulation) 뒤에 gradient를 update하는 방법이다. 이는 Input data의 size가 너무 크거나 GPU memoy가 작아서 batch size를 작게 설정하였을 때 사용하면 time cost는 줄일 수 있고 accuracy성능은 올릴 수 있는 방법이다.

for i, (input, target) in enumerate(dataloader):
    output = model(features)
    loss = criterion(output, target)
    loss.backward()
    
    # 매 2번의 iteration이 끝난 뒤에 weight를 update하여 batch size가 doubled되어 학습하는 효과를 줌 
    if (i+1) % 2 == 0 or (i+1) == len(dataloader):
        optimizer.step() # weight update
        optimizer.zero_grad(set_to_none=True)

4. Inferecne 최적화

4.1 Inference시에 gradient calculation 끄기 (time, memory cost↓)

inference시에는 training하는 것이 아니므로 gradient에 대한 계산이 불필요하므로 gradient-involved된 operation을 disable시킨다.

# inference코드에서 (decorator) torch.no_grad() 사용
@torch.no_grad()
def validation(model, input):
    output = model(input)
return output

5. CNN 최적화

5.1 torch.backends.cudnn.benchmark = True 사용 (time cost ↓)

Training loop전에 torch.backends.cudnn.benchmark = True 으로 설정할 경우 computation을 가속화가능하다. cuDNN algorithm의 성능은 변화하는 서로 다른 kernel size에 따라 달라지기 때문에 auto-tuner는 best algorithm을 찾기위해 benchmark를 실행한다. Input size가 변화하지 않는 구조에서 해당 setting이 유효하므로 CNN모델을 학습할 경우 사용해야한다.

torch.backends.cudnn.benchmark = True

5.2 4D NCHW tensors에 대해 channel_last memory format를 사용 (time cost ↓)

https://miro.medium.com/max/1400/1*yZF37VL9xLoYs6EpwpnyqQ.png

원래 이미지는 NCHW 형태로 (memory상에서) RGB 각 채널별로 clustering되어 있다. 이를 x = x.to(memory_format=torch.channels_last) 통해 memory상에서 NHWC로 바꾸게 되면 위 그림과 같이 RGB layer가 교차되어 표현가능하다. NHWC format은 Mixed Precision Training와 같이 사용할 경우에 NHWC format보다 7~19%의 speed up 효과를 가져온다고 합니다.

memory상에서의 pixel표현 방식이 다른것이지 실제 데이터의 shape은 바뀌지 않는다.

N, C, H, W = 10, 3, 32, 32
x = torch.rand(N, C, H, W)

# Stride는 한 element와 다은 element사이의 gap(distance)을 나타냄
print(x.stride()) # shape: (3072, 1024, 32, 1)

x2 = x.to(memory_format=torch.channels_last) # memory상에서 NHWC format으로 변경
print(x2.shape)  # shape은 (10, 3, 32, 32)으로 변경되지 않음
print(x2.stride())  # NHWC로 바꾸면서 stride결과(3072, 1, 96, 3)가 작아짐
print((x==x2).all()) # 해당 값은 True로 value자체는 변경되지 않음 오직 memory상에서의 format이 변경

5.3 Conv-BN 구조에서 Conv의 bias 사용하지 않기 (time, memory cost ↓)

Batch Normalization(BN)에 대해 이론적으로 잘 아시는 분은 아시겠지만 BN layer에 bias weight가 들어가있기 때문에 Conv의 bias을 사용한다고 해서 성능이 오르지 않고 그저 중복된 weight값이 되버린다. 그래서 Conv-BN구조에서는 Conv의 bias을 사용하지 않는다.

nn.Conv2d(..., bias=False)

오늘은 이렇게 PyTorch framework에서 사용가능한 성능 최적화 방법을 알아보았습니다. 다음 글에서는 해당 방법들을 실제로 사용하였을 때 얼마나 빨라지는 지 확인해보겠습니다.

Mixed Precision Training 이해 및 설명

Sin-Han Kang — Wed, 2 Nov 2022 16:52:10 +0900

1. Mixed Precision Training 이란?

대부분의 deep learning framework(e.g. PyTorch, TensorFlow)들은 모델을 training할 때 float32(FP32) data type을 사용하게 됩니다. 즉, 모델의 weight와 input data가 모두 FP32(32bit)의 data type을 가진다는 뜻입니다. 이와 다르게 Mixed-precision training은 single-precision(FP32)와 half-precision(FP16) format을 결합하여 사용하여 모델을 training하는 방식입니다.

(FP16 data type은 FP32와 다르게 16bit만을 사용하게 됩니다.)

Mixed-precision training방식을 통해 다음과 같은 장점을 가집니다.

FP32로만 training한 경우와 같은 accuracy 성능을 도출
Training time이 줄음
Memory 사용량이 줄음
- 이로 인해 더 큰 batch size, model, input을 사용 가능하게 함

Mixed-precision training은 NVIDIA에 의해 처음 제안되었고 Automatic Mixed Precision(AMP)라는 feature를 개발하였습니다. AMP feature는 특정 GPU operation을 FP32에서 mixed precision으로 자동으로 바꿔주었으며 이는 performance를 향상시키면서 accuracy는 유지하는 효과를 가져왔습니다.

PyTorch 1.6부터는 PyTorch 안에 AMP package(torch.cuda.amp)를 추가하였습니다. 아래와 같이 torch.cuda.amp는 기존의 NVIDIAd의 AMP의 pain point를 보완하였습니다.

Window OS 지원
DataParallel과 intra-process model parallelism 지원 (Multi-GPU 지원)
Gradient penalty (double backward) 지원
- e.g) L1 regularization, L2 regularization, ...
sparse gradient 지원

그리고 PyTorch에서 FP16과 FP32으로 autocast가능한 CUDA operation은 아래와 같습니다. 보시면 모델의 구성 layer(e.g. conv, linear, LSTMCell, ...)들은 FP16으로 auto cast가능하신것을 알 수 있습니다.

https://pytorch.org/docs/stable/amp.html#cuda-ops-that-can-autocast-to-float16

2. Mixed Precision Training 사용 예제

※ 저는 PyTorch framework에서만 사용하는 예제를 설명드립니다.

import torch

scaler = torch.cuda.amp.GradScaler() # Training시에 생성

for data, label in data_iter:
   optimizer.zero_grad()
   with torch.cuda.amp.autocast(): # Mixed precision으로 operation들을 casting 
      outputs = model(data)

   scaler.scale(loss).backward() # Loss를 scaling한 후에 backward진행
   scaler.step(optimizer) # 원래 scale에 맞추어 gradient를 unscale하고 optimizer를 통한 gradient update
   scaler.update() # 다음 iteration을 위해 scale update

위에서 mixed precision은 오직 with torch.cuda.amp.autocast(): context안에서만 일어나게 되고 이를 통해 위에서 말씀드린 performance효과를 보게 됩니다. 그럼 scaler라는 class instance는 어떤 역할을 하는 것일까요?

2.1 Scaler의 역할

Forward-pass시에 FP16으로 계산된 결과를 통해 backward-pass에서도 FP16으로 계산됩니다. 이 때 gradient의 값이 작아 float16으로 표현할 수 없다면 underflow가 발생하게 됩니다. 이런 문제점을 해결하기 위해 loss를 scale factor(이는 GradScaler()를 초기화할때 설정가능)와 곱하여 loss의 값을 크게 만드는 scaler.scale(loss).backward()를 사용하게 됩니다. loss의 값이 커지게 되면 자연스럽게 underflow문제점이 사라지겠죠.

Loss가 scale factor와 곱해졌었는데 weight update전에 원래 scale로 돌려놓기 위해 위의 scale factor만큼 나누어 주어 unscale하게 되는 과정은 scaler.step(optimizer)에서 진행됩니다. 이때, 이미 scaled gradient가 inf, NaN값을 가지면 optimizer.step() 함수는 skip되고 해당 gradients는 weight update에 사용되지 않고 버리게 됩니다.

그리고 scaler.update()를 통해 다음 iteration을 위한 scale factor를 업데이트합니다.

3. Mixed precision training 실험

PyTorch framework안에서 mixed precision training을 사용했을 경우와 아닌 경우의 time cost를 비교하려고 합니다. cifar10 dataset을 사용하여 ResNet18, 50, 101, MobileNetv2의 성능을 비교해보겠습니다.

실험에 사용한 코드는 해당 url 에서 사용가능합니다.

아래 표는 한 epoch당 소요되는 training/test 시간(단위 seconds)을 나타낸것입니다. 사용된 GPU는 V100 1개입니다.

	ResNet18	ResNet50	ResNet101	MobileNetv2
w/o mixed precision	train: 20.4s test: 1.4s	train: 58.0s test: 3.6s	train: 97.1s test: 5.8s	train: 20.4s test: 1.5s
w mixed precision	train: 10.4s test: 1.4s	train: 25.9s test: 3.6s	train: 43.9s test: 5.8s	train: 22.2s test: 1.5s

위의 결과를 통해 mixed precision training을 사용하였을 때 time cost가 적게 드는 것을 확인가능합니다.

전문연구요원 훈련소 준비물 및 후기

Sin-Han Kang — Tue, 1 Nov 2022 13:57:58 +0900

저는 2022년 10월 7일자로 논산 훈련소를 들어가 10월 27일에 훈련소 수료를 마친 전문연구요원입니다. 오늘은 훈련소에서 겪은 일들과 그에 대한 꿀팁을 알려드릴려고 합니다!

※ 내용은 26연대를 기준으로 말씀드립니다.

준비물

훈련소의 생활관안에서 사회에서 사용하는 물품들을 사용할 수 있으므로 다음과 같은 준비물을 챙기시면 좋습니다. 참고로 챙겨간 물품을 입소시에 검사를 제대로 하지 않기때문에 물품은 너무 크지 않는 선에서 다 가져갈 수 있는것 같습니다. (제 생활관 동기중에는 담배를 가져왔는데 검사 시에 걸리지 않았습니다.)

세면 도구: 샴푸, 바디워시 또는 올인원
- 칫솔, 치약은 줍니다.
스킨, 로션
책, 논문
- 불침번동안이나 주말에 읽기 좋습니다.
물티슈
필기도구
이어플러그
텀블러
선크림
신분증
커피 스틱
깔창
등.. 아무거나ㅋㅋㅋ

그리고 머리는 25mm~30mm로 짜르면 안전빵이고 몇몇분들은 더 길게 하시는분들도 있었습니다.

1 주차: 코로나 걸렸다고 말하지마!

큰 체육관에서 코로나검사를 먼저 실시하고 분대장(조교)이 저에게 코로나 걸린 적있냐고 물어보았습니다. 저는 9월 5일 즉, 입소하기 한달 전에 걸렸다고 말씀드렸죠. 그러더니 분대장이 저를 대부분의 사람들이 앉아있는 자리와 다른 자리에 저를 앉혔습니다. 이 때부터 슬슬 불길한 예감이... 역시는 역시나 코로나를 입소전 45일이내에 걸린사람들만 모아놓은 자리였고 그 자리에 있던 사람들은 제 생활관 동기가 되었습니다. 저희는 1생활관으로 기확진자 모아놓은 생활관이었습니다. 소대장은 우리에게 와서 너희는 슈퍼면역자이니 우리 좀 도와서 일좀 하게 될거라고 하였고 보상은 많이 주겠다고 하였습니다. (물론 보상이 많을거란 기대는 거의 없었죠... 하지만 이렇게 시키는 일이 많을 지는 몰랐습니다..)

그럼 1주일동안 무슨 일을 시켰는가?!

설거지 (아침, 점심, 저녁)
- 1~4중대 인원이 식사한 모든 설거지거리를 처리했습니다..
- 저는 하루에 숫가락 약 3천개를 닦았습니다.
짐나르기
- 물 옮기기
- 음식 및 부식 옮기고 배분
- 훈련 준비 용품 가져오기
배식 하기

1주차는 코로나 격리주이기 때문에 생활관 내에서 밥을 먹고 훈련이 없습니다. 하지만 저희는 위와 같은 일을 하느라 몸이 망가지고 있었죠... ㅠㅠ (설거지로 인해 생활관 동기 3명은 허리디스크터지고 저는 발가락에 피가 터졌습니다.) 보상은 핸드폰 시간을 많이 주는 것이었습니다. 26연대 기준으로 코로나 격리주에는 모든 생활관 인원에게 하루에 15~30분 핸드폰시간을 주었지만 저희 생활관은 하루에 30~1시간정도 주었습니다.

결론은 절대 입소기준 45일이내 기확진자라고 말하지 마세요!

2주차: 훈련 시작

1주차의 악몽같은 설거지가 끝나니 저희 생활관 사람들의 몸은 하자가 생겨있었습니다..ㅠ 코로나 격리주가 끝났기 때문에 본격적으로 훈련을 시작하였습니다. 또한 각 생활관마다 담당 업무를 맡게 되는데 우리는 세척(설거지)을 1주일동안했기때문에 소대장이 세척은 제외할 수 있도록 해주었고 그나마 편한 업무를 배정받았습니다.

1차 체력 검정: 3km 달리기, 윗몸일으키기, 팔굽혀펴기
- 해당 체력 검정으로 등급을 나누게 되는 데 3급이상 받으면 치킨 or 햄버거을 주니 잘하시면 좋습니다.
- 6급이하이면 매일매일 체력 보충을 하게되니 운동 조금 하고 가세요
화생방 훈련
- 방독면 마스크의 성능을 직접느껴보기위해 cs탄이 퍼져있는 컨테이너를 그냥 들어갔다가 나오는것을 합니다.
- 아프다고 열외했다면 보충훈련을 토요일에 받습니다.
수류탄 훈련
- 손에 터져도 괜찮은 수류탄으로 합니다.
- 이 훈련도 안했다면 보충훈련받았던걸로 기억....?
사격 훈련
- 재밌습니다.
- 잘 못쏘면 보충훈련받습니다.

그리고 2주차부터는 핸드폰을 사용하지 못하며 야외에서 아침점호를 하게되고 밥이 맛없어지고 많이 남기게됩니다.ㅋㅋㅋ 그리고 주말에는 정말 많은 시간이 남기때문에 티비를 많이 보았습니다. 책도 읽고 생활관 사람들이랑 마피아도 하고... 여튼 주말에 시간이 많습니다!

3주차: 언제 집 가지..?

이제 각개전투와 행군이 남았습니다. 밥도 맛없고 시간도 많이 남아서 집에 가고싶은 욕구가 엄청난 시기입니다. 각개전투와 행군은 저는 발가락 부상으로 하지는 않았지만 하신분들 보면 그렇게 까지 힘들어하시지 않았습니다. 또한 2차 체력검정도 실시하였는데 위와 동일하게 3급이상 받으면 인센티브를 주었습니다. 다만 2차 체력검정에서는 5급이하면 체력보충을 매일 나가게 됩니다. 수료식은 아침 10시에 시작하여 10시 20분~30분에 끝나고 핸드폰은 오전 9시즈음 받았습니다.

다들 부상없이 잘 마시고 오셨으면좋겠습니다. 전문연분들 화이팅하십숑~

OpenVINO 뽀개기 (3) OpenVINO Quantization

Sin-Han Kang — Mon, 22 Aug 2022 00:06:52 +0900

OpenVINO 모델을 optimization하기 위한 방법으로 Quantization에 대해 설명드립니다.

1. Quantization이란?

기존 Torch, ONNX model의 parameters(i.e. weights, bias)들은 각각이 float32로 표현되어 있습니다. Quantization은 float32의 data를 그 보다 낮은 bit(e.g. float16, int8)로 표현시켜 경량화시킵니다. 이렇게 함으로써 (1) inference time, (2) model size를 줄일 수 있다는 장점을 가집니다. 단점으로는 data의 정보손실이 발생하므로 Accuracy, mAP는 떨어지게 됩니다.

그럼, 다음과 같은 2가지 궁금증이 생기실 겁니다. 질문과 함께 답변드려볼게요.

몇 bit로 줄일 거냐?
- 기본적으로 TFLite에서 제공하는 타입 및 bit수는 float16(16bit), int8(8bit), uint8(8bit).
어떻게 줄일 거냐?
- float32로 표현된 parameters들을 줄이고자 하는 bit에 맞춰 mapping시킴.

2번에 대해 좀더 설명하기 위해 아래 uint8로 Quantization하는 예시를 보여드립니다.

오늘은 OpenVINO Quantization의 2가지 방법에 대해 설명드리겠습니다. 1번째는 FP16 Quantization, 2번째 Post-training Quantization입니다.

2. 환경 설정

OpenVINO모델을 optimization하는 방법을 설명드리기 위해서 사용한 model, device, package 정보는 다음과 같습니다.

Packages
- openvino: 2022.1.0
- openvino-dev: 2022.1.0
CPU: Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz (가상 core수: 56)
Model: yolov7 OpenVINO model
- yolov7.xml
- yolov7.bin

3. FP16 Quantization

원래 FP32로 표현되던 weight를 FP16으로 변경하는 것은 ONNX모델을 OpenVINO로 converting하는 CLI 명령어의 parameter로 줄 수 있습니다.

mo --input_model ${onnx_path} --output_dir ${output_dir} --data_type ${d_type}
# Ex) mo --input_model yolov7.onxx --output_dir yolov7_openvino_fp16 --data_type FP16

Successfully converted into FP16 OpenVINO

위와 같이 출력된다면 정상적으로 변환 된것입니다. 여기서 실제로 inference와 model size가 줄어드는 지 확인하기 위해 Torch(FP32), OpenVINO(FP32)와 비교해보았습니다. Inference time은 총 50번 실행에 대해 평균을 내었습니다. 성능 측정코드는 이전 글을 참조바랍니다.

Model (data_type)	File size(MB)	Inference time (s)
Yolov7 Torch (FP32)	147.7	1.093
Yolov7 OpenVINO (FP32)	148.1	0.118
Yolov7 OpenVINO (FP16)	74.4	0.116

FP16으로 data type이 변경되면서 당연하게도 model size는 50% 정도로 줄어들었지만 Inference time은 거의 비슷함을 확인가능합니다. (Inference time도 줄어들었으면 좋앗을 걸..)

4. Post-Training Quantization

Post-Training Quantization(PTQ)는 말 그대로 Training이 끝난 모델에 대해 Quantization하겠다는 말입니다. OpenVINo의 PTQ는 int8 Quantization이 가능하므로 inference time과 model size모두 줄일 수 있습니다.

PTQ process in OpenVINO

위는 PTQ process를 보여주는 그림으로 Quantization을 하고자 하는 모델을 training하는 데 사용된 dataset을 필요로 하는 것을 알 수 있습니다. (Label은 필요하지 않음.) 또한 PTQ를 하기위해서는 유저가 직접 DataLoader에 대한 구현이 필요합니다.

그렇다면 왜 PTQ을 하는데 dataset을 필요로 할까요?

Int8 Quantization은 float32인 data size를 int8로 줄이는 작업이기 때문에 정보의 손실이 상대적으로 크겠죠. 그만큼 Quantization을 잘해야 기존의 Accuracy(or mAP) 성능이 떨어지지 않겠죠. 그러기 위해서는 각각의 weight에 대해 적절한 rmin/rmax (Quantization mapping range)를 선택하는 것이 중요하게 됩니다. 그래서 실제 input data들을 model에 흘려보내면서 Accuracy(or mAP)성능을 떨어트리지 않는 적절한 rmin/rmax를 찾기위해 dataset이 필요하게 됩니다.

전체적인 PTQ process flow는 다음과 같습니다.

Data와 dataset interface를 준비
Quantization parameter를 설정
Quantization process 실행

4.1 Data and Dataset Interface 준비

제가 사용한 yolov7 모델은 COCO dataset을 사용했으므로 COCO training data를 준비하였습니다. 그리고 openvino.tools.pot.DataLoader interface를 통해 dataloader를 구성하여야합니다. 그리고 해당 DataLoader class에서 구현해야 할 함수는 다음과 같습니다.

__len__(): dataset의 크기를 return
__getitem__(): index에 의해 data에 access해야하는 데 model-specific한 preprocessing후에 (data, annotation)을 return
- data: numpy.array이거나 dictionary형태여야 함
- annotation: quantization에 사용되지 않으므로 None값을 줌

import os
import numpy as np
import cv2 as cv
from openvino.tools.pot import DataLoader

class ImageLoader(DataLoader):
    def __init__(self, dataset_path):
        # folder로 부터 image files 이름 가져오기
        self._files = []
        all_files_in_dir = os.listdir(dataset_path)
        for name in all_files_in_dir:
            file = os.path.join(dataset_path, name)
            if cv.haveImageReader(file):
                self._files.append(file)

        # model input의 shape정의
        self._shape = (640, 640)

    def __len__(self):
        """ dataset의 총 image file 개수 return """
        return len(self._files)

    def __getitem__(self, index):
        """ 
        index에 의해 image data return  (NCHW shape)
        """
        if index >= len(self):
            raise IndexError("Index out of dataset size")

        image = cv.imread(self._files[index]) # read image with OpenCV
        image = cv.resize(image, self._shape) # resize to a target input size
        image = np.expand_dims(image, 0)  # add batch dimension
    	image = image.astype(np.float32) # input data type to float32
        image /= 255. # normalize
        image = image.transpose(0, 3, 1, 2)  # convert to NCHW layout
        return image, None   # annotation is set to None

data_loader = ImageLoader(${coco_dataset_path})
# Ex) data_loader = ImageLoader("/usr/src/app/datasets/coco/images/val2017/")

위와 같이 COCO dataset용으로 DataLoader를 구성하였습니다. 마지막 줄 예시에서도 보이듯이 저는 COCO validation set을 load하였습니다.

4.2 Quantization Parameter 설정

PTQ를 진행하기 위한 parameter설정에 코드입니다.

q_params = [{
      	"name": "DefaultQuantization",
        "params": {
            "target_device": "CPU",
            "preset": "performance",
            "stat_subset_size": 1000},
        }]

"name": "DefaultQuantization"
- DefaultQuantization은 PTQ의 가장 기본적인 방법이며 fast하며 accurate한 결과를 제공한다고 함
"target_device": "CPU"
- target device에 대한 명시이며 다른 옵션으로는 "GPU", "ANY"이 가능함
"preset": "performance"
- preset은 quantization mode로 performance값은 weight와 activation모두 symmetric quantization을 하며 모든 HW에 성능이 가장 우수함
"stat_subset_size": 300
- 위의 입력한 dataset path(validation set)에서 얼마만큼의 data를 사용할 건지 명시
- 300이라는 값이 OpenVINO에서 실험해보았을 때 가장 최적의 값이었다고 함

4.3 Quantization Process 실행

from openvino.tools.pot import IEEngine
from openvino.tools.pot import load_model, save_model
from openvino.tools.pot import compress_model_weights
from openvino.tools.pot import create_pipeline

model_config = {
    "model_name": "yolov7",
    "model": "/usr/src/app/yolov5_inference/yolov7_openvino_fp32/yolov7.xml",
    "weights": "/usr/src/app/yolov5_inference/yolov7_openvino_fp32/yolov7.bin",
}
engine_config = {"device": "CPU"}

# Step 1: Load model
model = load_model(model_config=model_config)

# Step 2: Device, data loader config와 함께 engine을 초기화
engine = IEEngine(config=engine_config, data_loader=data_loader)

# Step 3: PTQ parameter와 함께 pipeline생성 및 실행
pipeline = create_pipeline(q_params, engine)
compressed_model = pipeline.run(model=model)

# Step 4 (Optional): .bin file size를 줄이기 위해 model weight를 compress함
compress_model_weights(compressed_model)

# Step 5: save_path에 model_name이름으로 PTQ진행한 model 저장 
compressed_model_paths = save_model(
    model=compressed_model,
    save_path="yolov7_openvino_ptq",
    model_name="optimized_yolov7",
)

load_model: PTQ를 진행하고자 하는 model을 load함
lEEngine: PTQ에 필요한 device정보와 DataLoader를 입력하여 PTQ engine초기화
create_pipeline: 위에서 설정한 PTQ parameter를 입력으로 pipeline생성
pipeline.run: PTQ를 실행!
save_model: PTQ가 완료된 모델을 저장

위의 코드를 실행하여 PTQ가 완료되면 아래와 같이 정상적으로 int8로 quantization된 OpenVINO 모델이 생성된다.

PTQ OpenVINO model

model size면에서는 FP32모델(148MB)에 비해 거의 2배줄은 것을 위로부터 확인가능합니다. 50번의 inference에 대해 평균을 내어 inference time을 측정하였습니다. 그리하여 기존 모델들과 비교했을 때 아래와 같이 PTQ를 사용하여 생성된 int8 quantized모델이 뛰어난 성능을 보임을 알 수 있습니다.

Model (data_type)	File size(MB)	Inference time (s)
Yolov7 Torch (FP32)	147.7	1.093
Yolov7 OpenVINO (FP32)	148.1	0.118
Yolov7 OpenVINO (FP16)	74.4	0.116
Yolov7 OpenVINO (int8)	38.0	0.073

추가적으로 int8로 quantized되었다면 mAP성능이 하락할 수도 있는데 해당 문제가 있는 지 확인하기위해 Yolov7 OpenVINO (FP32)모델의 detection결과와 비교를 해보았습니다. (detection에 사용한 코드와 모델은 Appendix에서 확인가능합니다.)

Detection result comparison between yolov7 FP32 and yolov7 Int8

INT8로 quantization된 모델은 FP32의 모델의 detection결과에서 사람중에 하나를(빨간색 박스) detection하지 못하는 것을 볼 수 있다. INT8로 quantization하여 mAP성능이 조금 떨어짐을 볼 수 있다. 좀 더 정확하게 bbox의 좌표와 confidence를 비교해보겠습니다.

Second detection result comparison between yolov7 FP32 and yolov7 Int8

위의 결과를 보시면 INT8로 quantization되면서 조금씩 bbox 좌표와 confidence가 달라짐을 볼 수 있고 사람 하나를 detection못하였기 때문에 Detect 9에 대한 정보가 없음을 알 수 있다. 특징점은 FP32모델에서 confidence가 작은 Detect 9가 INT8에서 없어진 것을 보면 quantization을 통한 정보손실은 decision boundary근처에서 많이 일어나는 것을 추측가능하다.

Appendix

FP16, INT8로 quantization된 모델은 여기서 다운가능하고 detection에 사용한 코드와 파일은 여기에서 받으세요.

OpenVINO 뽀개기 (2) OpenVINO Inference

Sin-Han Kang — Tue, 16 Aug 2022 22:57:06 +0900

저번 글에 이어 이번에는 OpenVINO모델을 Inference하는 방법에 대해 설명드리도록 하겠습니다.

1. OpenVINO Runtime

OpenVINO (IR)모델을 inference할 수 있도록 하는 것이 OpenVINO runtime입니다.

OpenVINO Runtime

OpenVINO runtime은 C, python의 binding과 함께 C++ library로 구현되어 있습니다. 그리고 위 그림에서 알 수 있듯이 OpenVINO runtime을 통해 IR모델 뿐만아니라 ONNX, PaddlePaddle(바이두)모델도 Inference가능하도록 API를 제공합니다. 또한 plugin architecture를 사용하기 때문에 해당 plugin들은 각 hardware device에 맞춰진 complete한 구현이 되어있습니다.

OpenVINO runtime을 사용하기 위해서 openvino PyPI을 설치하였습니다.

2. OpenVINO Inference

2.1 환경 설정

이전 글에서 생성한 yolov7 OpenVINO모델을 사용하여 infernece를 진행할 것이며 inference환경은 다음과 같습니다.

openvino: 2022.1.0 (from PypI)
CPU: Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz (가상 core수: 56)
Model: yolov7 OpenVINO model
- yolov7.xml
- yolov7.bin

2.2 Load OpenVINO model

먼저 OpenVINO model을 load해봅니다.

from openvino.runtime import Core

model_path = "./yolov7_openvino/yolov7.xml"
ie = Core() # initialize inference engine
network = ie.read_model(model=model_path, weights=Path(model_path).with_suffix('.bin'))
executable_network = ie.compile_model(model=network, device_name="CPU")

ie=Core()
- inference engine을 초기화 함
ie.read_model()
- Core클래스 함수의 read_model함수로 OpenVINO model을 read함
- Model인자의 값으로 model topology가 담긴 xml파일을, weights에는 weight(bias) binary 파일을 넣어줌
ie.compile_model()
- 지정한 device(CPU)에서 model을 compile시켜 inference가능한 형태로 만들어 줌

2.3 Inference OpenVINO model

im = np.random.randn(1,3,640,640) #random input
output_layer = next(iter(executable_network.outputs)) # OpenVINO model의 output layer를 가져옴
y = executable_network([im])[output_layer] # Inference 실행하여 output_layer에 해당하는 output을 y에 할당

next(iter(executable_network.outputs))
- yolov7 OpenVINO모델의 outputs중 가장 첫 번째 output을 가져와 output_layer에 할당 (아래 사진 참조)
executable_network([im])[output_layer]
- Inference 실행하여 output_layer에 해당하는 output을 y에 할당

debugging for output_layer

2.4 Torch와 OpenVINO 모델 inference time 비교

OpenVINO모델로 inference해보았으니 Torch모델과 비교했을 때 Intel cpu에서 얼마나 빨라는 지 확인해보았습니다. 사용한 cpu는 Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz (가상 core수: 56)이며 총 50번의 inference에 대해 평균을 내어 결과를 도출하였습니다. Torch, OpenVINO 모델 모두 weight의 data type은 FP32입니다. OpenVINO 모델은 여기서 다운 가능하며 Torch모델은 yolov7 공식 repo에서 받으시면 됩니다.

start = time.time()
y = executable_network([im])[output_layer
prinf(f'time lapse: {time.time()-start}')

Model	File size(MB)	Inference time (s)
Yolov7 Torch	147.7	1.093
Yolov7 OpenVINO	148.1	0.118

두 모델의 file size는 비슷한데 Inference time의 경우에는 OpenVINO모델이 10배정도 빠른 것을 알 수 있다!!

2.5 Batch 수에 따른 Inference time비교

from openvino.runtime import Core, PartialShape
ie = Core()
network = ie.read_model(model=model_path, weights=Path(model_path).with_suffix('.bin'))

batch = 2
inputs = next(iter(network.inputs))
new_shape = PartialShape([batch, 3, 640, 640]) # batch 2
network.reshape({inputs.any_name: new_shape}) # reshape batch size of input

executable_network = ie.compile_model(model=network, device_name="CPU")

im = np.random.randn(batch, 3, 640, 640)    
output_layer = next(iter(executable_network.outputs))
y = executable_network([im])[output_layer]

PartialShape과 network.reshape을 통해 network의 input batch size를 변경 가능합니다.

위의 코드는 batch가 2일 경우입니다. 위의 코드를 기반으로 Batch가 1, 2, 4, 8인 경우를 모두 측정하여 아래와 같은 결과를 보여드립니다. (50번의 inference에 대해 average하였습니다.)

Batch size	Inference time (s)
1	0.118
2	0.229
4	0.480
8	0.935

결과표를 보시면 아시겠지만 batch 수에 비례하여 inference time이 늘어나는 것을 확인 가능합니다. (완전한 정비례는 아니네요..)

OpenVINO 뽀개기 (1) OpenVINO 이해 및 변환

Sin-Han Kang — Sun, 14 Aug 2022 20:50:07 +0900

1. OpenVINO란?

OpenVINO는 intel에서 주도적으로 진행 중인 프로젝트입니다. OpenVINO는 다양한 Deep Learning(DL) framework(e.g. PyTorch, TF)의 모델들을 OPenVINO 모델로 변환하여 intel device에 최적화된 inference를 할 수 있도록 해줍니다. 그래서 intel cpu나 gpu에서 DL 모델을 inference할 경우가 생기신다면 OpenVINO를 사용하셔야 latency성능이 좋아집니다!

OpenVINO 목표

추가적으로 OpenVINO는 다음과 같은 특성은 제공합니다.

Pruning, Quantization을 통한 model size 및 inference 최적화
Model의 preprocessing, postprocessing 기능 제공
intel cpu뿐만이 아닌 arm cpu, mac m1 chip에 대한 연산 지원

위의 특성에 대해서는 이후 글에서 차차 알아보고 오늘은 (1) OpenVINO변환을 어떻게 하는 지 (2) 변환된 OpenVINO 모델이 어떤 특성을 갖는지 설명드리겠습니다.

2. OpenVINO 모델 변환

2.1 환경 설정

저는 ONNX모델을 input 모델로 사용하여 OpenVINO형태의 모델로 변환할 것이고 제가 사용한 intel cpu정보와 OpenVINO toolkit의 버전은 아래와 같습니다.

openvino-dev: 2022.1.0 (from PypI)
CPU: Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz (가상 core수: 56)
Model: yolov7 ONNX model (for detection task)
- ONNX 정보: 1.9.0 version, 12 opset

2.2 OpenVINO Model Converting

ONNX모델을 OpenVINo로 변경하는 방법은 엄청 간단합니다. CLI하나면 끝납니다.

mo --input_model ${onnx_path} --output_dir ${output_dir} 
# Ex) mo --input_model yolov7.onxx --output_dir yolov7_openvino

openvino-dev PyPI를 설치하셨다면 mo 명령어를 사용 가능합니다. 그래서 --input_model에는 onnx model의 path를 --output_dir에는 OpenVINO 모델이 저장될 directory를 의미합니다.

명령어가 정상적으로 실행되었다면 아래와 같은 결과를 볼 수 있습니다.

OpenVINO model converting

위의 출력을 통해 다양한 정보를 알 수 있습니다.

OpenVINO모델 변환 시 weight type은 따로 지정하지 않았으므로 default인 FP32로 변환됨
OpenVINO모델은 Intermediate Representation(IR)이므로 여러 DL framework들을 하나의 OpenVINO모델로 변환 가능하게 하는 이유기도 함
- version은 11
OpenVINO의 IR은 yolov7_openvino 폴더에 yolov7.xml, yolov7.bin파일로 생성
- yolov7.xml: model의 topology를 표현
  - Topology란 model내의 layer 순서, layer의 특성 등을 포함함
- yolov7.bin: model의 weight와 bias값을 binary형태로 가짐

아래는 yolov7.xml의 내용을 부분적으로 보여드립니다.

OpenVINO xml file

마지막으로 ONNX모델과 OpenVINO model size차이를 비교해봅니다. 모델은 여기서 다운 가능하십니다.

Model Type	Model size (MB)
ONNX	147.7
OpenVINO	bin:147.6 xml:0.4

다음 글에서는 OpenVINO모델을 inference 하는 글을 작성하겠습니다. 수고하셨습니다~

TFLite 뽀개기 (4) XNNPACK 이해 및 성능 비교

Sin-Han Kang — Wed, 10 Aug 2022 00:35:20 +0900

1. XNNPACK이란?

XNNPACK은 아래와 같은 다양한 device(architecture)를 위해 floating-point neural netowrk의 inference operator를 최적화한 library입니다. (floating-point란 fp32, fp16 모델만 가속화 가능하다는 뜻입니다.) 한마디로 DL 모델의 inference속도를 가속화 해주는 library입니다.

Desktop기준으로 XNNPACK을 사용하기 위해서는 bazel build할때 XNNPACK사용에 대한 명시를 해주어야 합니다. 그리고 TFLite모델에만 사용이 가능합니다. 또 다른 특징으로는 XNNPACK은 PAD operator와 CONV_2D operator(with VALID padding)을 감지하여 하나의 convolution operator로 fusing해주는 역할도 합니다.

1.1 Supported architectures

ARM64 on Android, Linux, macOS, and IOS
ARMv6 (with VFPv2) on Linux
x86 and x86-64 (up to AVX512) on Windows, Linux, macOs, Android, and IOS simulator
WebAssembly MVP and SIMD
RISC-V
...

위와 같이 XNNPACK의 지원범위는 넓네요. ARM CPU, Intel CPU, Chrome과 같이 web에서 사용되는 WebAssembly 심지어 축소된 명령어 세트로만 설계된 RISC-V에도 XNNPACK이 사용가능합니다. (XNNPack이 구현되어있는 neural network operator는 공식 repo 참고하세요! CNN계열은 거의 다 있네요...) 다양한 device환경에서 모두 사용될 수 있다는 점에서 generality가 좋고 실제로 사용해보면 inference time성능이 매우 좋아집니다.

이번 글에서는 benchmark tool 를 통해 XNNPACK을 사용하였을 때와 아닐 때를 비교하며 inference time에 대한 성능비교를 해보겠습니다.

2. XNNPACK 성능 비교

2.1 Environment Setting

2.1.1 Docker environment

bazel build를 통해 TFLite모델을 benchmark할 수 있는 환경을 docker image로 만들어놓았습니다. 해당 benchmark tool을 통해 XNNPACK사용 했을 경우와 아닌경우의 inference time차이를 볼것이며 profiling기능까지 제공하므로 profile을 통해 각 모델에 대한 inference time에 대한 분석 또한 해보겠습니다.

docker image는 아래 명령어로 받을 수 있습니다.

docker pull da2so/tf_bazel:latest

해당 image를 다운받으셨다면 아래 명령어를 통해 container를 만들어 들어가서 benchmark tool을 실행 해봅시다!

# Option 1: GPU 있을 시 
docker run -it -d --gpus '"device=0"' --ipc=host --name da2so_test -p 3322:3322 -v /test/:/usr/src/app da2so/tf_bazel:latest /bin/bash
# Option 2: GPU 없을 시
docker run -it -d --ipc=host --name da2so_test -p 3322:3322 -v /test/:/usr/src/app da2so/tf_bazel:latest /bin/bash

docker attach da2so_test

# in container
cd tensorflow_src
bazel-bin/tensorflow/lite/tools/benchmark/benchmark_model --help

정상적으로 동작했다면 아래와 같을 것입니다. 저는 GPU를 사용하는 option으로 docker container를 생성하였습니다.

check benchmark tool

2.1.2 Models

XNNPACK inference time성능 비교에 사용된 TFLite 모델은 다음과 같습니다.

Classification
- MobileNetv2, v3 모두 depth multiplier 0.75사용

Model (data type)	Model size (MB)
MobileNetv2 (FP32)	10.6
MobileNetv2 (FP16)	5.3
MobileNetv3 (FP32)	16.0
MobileNetv3 (FP16)	8.1
EfficientNetv2_B0 (FP32)	28.5
EfficientNetv2_B0 (FP16)	14.3

Object detection

Model (data type)	Model size (MB)
yolov5s (FP32)	29.0
yolov5s (FP16)	14.5
yolov7 (FP32)	147.7
yolov7 (FP16)	73.9

모든 모델은 여기서 다운받을 수 있습니다.

2.1.3 Device info

Inference에 사용되는 device정보는 다음과 같습니다.

CPU: Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz (56 core)

2.2 Benchmark tool로 inference time 측정 예시

Benchmark tool로 yolov5s (fp32) 모델의 inference time을 측정하는 예시를 보여드립니다. bazel-bin/tensorflow/lite/benchmark/benchmark_model 명령어로 모델의 inference time을 측정가능합니다. 아래에서는 XNNPACK을 사용하지 않았으며 warm up으로 10번 후, average inference time을 재기위해 100번 inference진행하였습니다.

Benchmark tool result

위의 결과를 보시면 yolov5s의 model path, model size, inference time, memory footprint까지 출력되는 것을 알 수 있습니다. CPU로 측정된 yolov5s (fp32)의 average inference time은 513.534ms (0.5초정도) 인것을 확인가능합니다.

※ 참고로 use_gpu옵션을 주어 gpu acceleration을 할 수 있는 데 gpu acceleration은 Android 또는 iOS platform에서 사용가능하다고 하네요.

GPU delegate is only supported on specific platforms

2.3 XNNPACK 성능비교

아래 명령어를 통해 위에서 언급드린 TFLite모델들에 대해 XNNPACK을 사용했을 경우와 아닌 경우에 대한 inference time 성능 비교를 해보겠습니다. 추가로 thread수를 늘렸을 때 성능또한 어떻게 변화하는 지 알아보도록 하죠!

bazel-bin/tensorflow/lite/tools/benchmark/benchmark_model \
--graph=${model_path} \
--use_xnnpack=true (or false) \
--warmup_runs=10 \
--num_runs=100 \
--num_threads=1 (or 2, 4)

2.3.1 Classifcation Results

아래는 thread수를 1기준으로 측정하였습니다.

Model (data type, model size)	USE_XNNPACK	Inference time (ms)
MobileNetv2 (FP32, 10.6MB)	True	11.746 ± 0.1
MobileNetv2 (FP32, 10.6MB)	False	24.344 ± 2.5
MobileNetv2 (FP16, 5.3MB)	True	11.745 ± 0.3
MobileNetv2 (FP16, 5.3MB)	False	23.677 ± 1.5
MobileNetv3 (FP32, 16MB)	True	10.346 ± 0.3
MobileNetv3 (FP32, 16MB)	False	20.946 ± 1.1
MobileNetv3 (FP16, 8.1MB)	True	10.444 ± 0.4
MobileNetv3 (FP16, 8.1MB)	False	20.745 ± 1.3
EfficientNetv2_B0 (FP32, 28.5MB)	True	38.183 ± 3.1
EfficientNetv2_B0 (FP32, 28.5MB)	False	68.230 ± 3.2
EfficientNetv2_B0 (FP16, 14.3MB)	True	37.895 ± 1.0
EfficientNetv2_B0 (FP16, 14.3MB)	False	69.594 ± 2.7

위의 결과에서 분석 내용은 다음과 같습니다.

XNNPACK을 사용하였을때 2배이상 inference 속도가 빨라짐을 확인
FP32와 FP16간의 model size는 차이가 많이 나지만 실제 inference 속도는 거의 비슷함
MobileNetv3가 MobileNetv2에 비해 model size는 더 크지만 inference 속도가 더 빠름

2.3.2 Object detection Results

Model (data type, model size)	USE_XNNPACK	Inference time (ms)
yolov5s (FP32, 29.0MB)	True	403.578 ± 5.5
yolov5s (FP32, 29.0MB)	False	512.900 ± 19.9
yolov5s (FP16, 14.5MB)	True	407.494 ± 18.5
yolov5s (FP16, 14.5MB)	False	516.036 ± 34.6
yolov7 (FP32, 147.7MB)	True	2420.893 ± 41.0
yolov7 (FP32, 147.7MB )	False	2199.132 ± 41.1
yolov7 (FP16, 73.9MB)	True	2424.714 ± 41.3
yolov7 (FP16, 73.9MB)	False	2232.653 ± 54.3

위의 결과에서 분석 내용은 다음과 같습니다.

yolov5s 모델의 경우 XNNPACK을 사용했을 때 inference 속도가 빨라짐
- classification모델의 경우 2배정도 inference time이 줄었는데 모델이 커져서 XNNPACK의 효과가 작아진 건가..?
yolov7 모델의 경우는 XNNPACK의 효과가 없는 것으로 보임
- 모델이 너무 커서 그런것인가..?

2.3.3 Thread 수에 따른 inference time results

thread 수에 따른 inference time을 비교하기 위해 yolov5s 모델 기준으로 측정해보았습니다.

Model (data type, model size)	USE_XNNPACK / Thread num	Inference time (ms)
yolov5s (FP32, 29.0MB)	True / 1	403.578 ± 5.5
yolov5s (FP32, 29.0MB)	True / 2	228.207 ± 16.8
yolov5s (FP32, 29.0MB)	True / 4	142.095 ± 11.6
yolov5s (FP32, 29.0MB)	False / 1	1022.063 ± 7.5
yolov5s (FP32, 29.0MB)	False / 2	733.723 ± 17.7
yolov5s (FP32, 29.0MB)	False / 4	513.892 ± 15.0
yolov5s (FP16, 14.5MB)	True / 1	407.494 ± 18.5
yolov5s (FP16, 14.5MB)	True / 2	231.054 ± 10.7
yolov5s (FP16, 14.5MB)	True / 4	138.392 ± 8.2
yolov5s (FP16, 14.5MB)	False / 1	1020.223 ± 6.4
yolov5s (FP16, 14.5MB)	False / 2	734.001 ± 21.5
yolov5s (FP16, 14.5MB)	False / 4	506.902 ± 15.4

위의 결과에서 분석 내용은 다음과 같습니다.

(A) XNNPACK을 사용하지 않고 thread를 4개를 쓴 경우가 (B) XNNPACK을 사용하고 thread수가 1일경우보다 inference time오래 걸림을 알 수 있음
- (A)'s inference time: 513.892 ± 15.0 (FP32), 506.902 ± 15.4 (FP16)
- (B)'s inference time: 403.578 ± 5.5 (FP32), 407.494 ± 18.5(FP16)
XNNPACK을 사용하고 thread num이 4인경우가 가장 inference time 성능이 가장 좋음 (초록색)

[NVIDIA] TensorRT inference 코드 및 예제 (feat. yolov7)

Sin-Han Kang — Fri, 29 Jul 2022 09:22:32 +0900

이전의 TensorRT plugin 사용하는 방법을 설명드렸는데요. TRT모델로 inference하는 코드에 대한 설명이 부족하고 저도 잘 이해하지 못한 부분이 있어 이번 글에서 설명드립니다.

0. Inference용 모델 및 개발 환경

Inference를 위해 사용한 모델은 YOLOv7 모델입니다. 모델은 yolov7.trt 다운가능하며 input의 shape은 (1,3,640,640)로 설정하였으며 output은 총 4개로 나뉘면 각각 num_detections(detection된 object개수), nmsed_boxes(object의 bounding box 좌표), nmsed_scores(object의 confidence score), nmsed_classes(object의 class)입니다. output shape은 아래와 같습니다.

output shape of yolov7 with NMSPlugin

개발 환경은 다음과 같습니다. (Docker container에서 구축했습니다.)

onnx: 1.8.0
torch: 1.9.0a0+df837d0
onnx-graphsurgeon: 0.2.8
tensorrt: 7.2.2.3
CUDA: 11.2
Driver Version: 460.73.01
GPU: Tesla V100

Input image는 아래 사진을 사용하였습니다.

horse.jpg

1. TensorRT Inference

python 환경에서 TRT 모델을 inference하겠습니다. 코드 한줄씩 설명드리며 어떻게 TRT 모델이 작동하는 지 봐보죠!

아래에 사용된 코드와 전체 코드는 여기서 확인가능합니다.

1.1 Load TensorRT model

    def load_model(self):
        TRT_LOGGER = trt.Logger(trt.Logger.WARNING)
        runtime = trt.Runtime(TRT_LOGGER) # serialized ICudEngine을 deserialized하기 위한 클래스 객체
        trt.init_libnvinfer_plugins(None, "") # plugin 사용을 위함
        with open(self.model_path, 'rb') as f:
            self.engine = runtime.deserialize_cuda_engine(f.read()) # trt 모델을 읽어 serialized ICudEngine을 deserialized함
        
        self.context = self.engine.create_execution_context() # ICudEngine을 이용해 inference를 실행하기 위한 context class생성
        assert self.engine 
        assert self.context

trt.Runtime: Serialized된 ICudaEngine을 deserialized하기 위한 클래스 객체
- 기본적으로 .trt 파일은 serialized 즉, bytestream으로 저장되어 있음
runtime.deserialize_cuda_engine: .trt 모델을 읽어 serialized ICudEngine을 deserialized함
- bytestream인 ICudaEngine을 deserailized하게 되면 아래와 같이 self.engine에 ICudaEngine 클래스 객체가 생성됨
- ICudaEngine는 아래의 사진과 같이 모델의 다양한 정보를 가짐
  - device_memory_size: trt 모델을 실행시키는 데 필요한 총 memory 양
  - max_batch_size: 최대 batch 수
  - num_bindings: I/O binding의 수 (Input 수 1개 + Output수 4개=5)
  - num_layers: trt 모델의 layer개수

ICudaEngine class

self.engine.create_execution_context: ICudEngine을 이용해 inference를 실행하기 위한 IExecutionContext class생성
- 해당 class의 함수로 이후에 Inference 실행

IExecutionContext

1.2 Setup I/O binding

I/O binding이란 trt모델의 Input과 Output의 정보를 저장하고 이는 이후에 GPU연산을 위해 또한 Inference에 사용됩니다.

    def alloc_buf(self):
        self.inputs = []
        self.outputs = []
        self.allocations = []

        for i in range(self.engine.num_bindings): # input과 output의 개수만큼
            is_input = False
            if self.engine.binding_is_input(i): # i번째 binding이 input인지 확인
                is_input = True 
            name = self.engine.get_binding_name(i) # i번째 binding의 이름
            dtype = np.dtype(trt.nptype(self.engine.get_binding_dtype(i))) # i번째 binding의 data type
            shape = self.context.get_binding_shape(i) # i번째 binding의 shape

            if is_input and shape[0] < 0:
                assert self.engine.num_optimization_profiles > 0
                profile_shape = self.engine.get_profile_shape(0, name)
                assert len(profile_shape) == 3  # min,opt,max
                # Set the *max* profile as binding shape
                self.context.set_binding_shape(i, profile_shape[2])
                shape = self.context.get_binding_shape(i)
            if is_input:
                self.batch_size = shape[0]
            size = dtype.itemsize # data type의 byte수
            for s in shape:
                size *= s # data type의 byte수 * 각 shape(e.g input의 경우 [1,3,640,640]) element 을 곱하여 size에 할당

            allocation = cuda.mem_alloc(size) # 해당 size만큼의 GPU memory allocation함
            host_allocation = None if is_input else np.zeros(shape, dtype)
            binding = {
                "index": i,
                "name": name,
                "dtype": dtype,
                "shape": list(shape),
                "allocation": allocation,
                "host_allocation": host_allocation,
            }
            self.allocations.append(allocation)
            if self.engine.binding_is_input(i): # binding이 input이면
                self.inputs.append(binding)
            else: # 아니면 binding은 모두 output임
                self.outputs.append(binding)

self.engine.binding_is_input(i): i번째 index를 가진 binding이 input을 의미하는 지 확인
self.engine.get_binding_name(i): i번째 index binding의 name
self.engine.get_binding_dtype(i): i번째 index binding의 data type
- trt.nptype: 해당 함수를 통해 trt의 data type을 numpy type으로 바꿔줌
self.context.get_binding_shape(i): i번째 index binding의 shape
size = dtype.itemsize, size *= s: i번째 index를 가진 binding의 data shape과 data type에 따른 data size할당
- Input shape이 (1, 3, 640, 640)인경우 (data type의 byte수(4byte) x 1 x 3 x 640 x 640)를 size에 할당
cuda.mem_alloc(size): GPU memory에 해당 size만큼 allocation(할당)함
host_allocation = None if is_input else np.zeros(shape, dtype): GPU로 inference후의 cpu host로 output의 정보를 받기위한 allocation된 배열

아래 사진은 1번째, 2번째 index를 가진 binding에 대한 정보를 출력한 것입니다. 1번째는 input에 해당하는 binding이며 2번째는 num_detections에 대한 output에 해당하는 binding입니다. Num_detections에 대한 binding은 host_allocation을 가진다는 것을 알 수 있습니다.

I/O Binding examples

1.3 Inference TRT model

Setup완료하였으니 이제 inference해보죠.

    def inference(self, input_image):
        image = input_image.transpose(0, 3, 1, 2) # NHWC to NWHC
        image = np.ascontiguousarray(image) 
        cuda.memcpy_htod(self.inputs[0]['allocation'], image) # input image array(host)를 GPU(device)로 보내주는 작업
        self.context.execute_v2(self.allocations) #inference 실행!
        for o in range(len(self.outputs)):
            cuda.memcpy_dtoh(self.outputs[o]['host_allocation'], self.outputs[o]['allocation']) # GPU에서 작업한 값을 host로 보냄
        
        num_detections = self.outputs[0]['host_allocation'] # detection된 object개수
        nmsed_boxes = self.outputs[1]['host_allocation'] # detection된 object coordinate
        nmsed_scores = self.outputs[2]['host_allocation'] # detection된 object confidence
        nmsed_classes = self.outputs[3]['host_allocation'] # detection된 object class number
        result = [num_detections, nmsed_boxes, nmsed_scores, nmsed_classes]
        return result

cuda.memcpy_htod(self.inputs[0]['allocation'], image): input image array(host)를 GPU(device)를 copy하여 보냄
- htod: h(host) to d(device)
self.context.execute_v2(self.allocations): 실제 Inference를 진행하는 함수
cuda.memcpy_dtoh(self.outputs[o]['host_allocation'], self.outputs[o]['allocation']): GPU device에서 진행한 inference값을 host로 copy하여 보냄
self.outputs[i]['host_allocation']: i번째 output의 값이 저장되어 있는 변수

yolov7 model의 output인 num_detections, nmsed_boxes, nmsed_scores, nmsed_classes에 대한 값과 그에 대한 설명은 다음과 같습니다.

yolov7 with NMSPlugin의 output

1.4 detection 결과 및 inference 속도

horse.jpg에 대한 detection 결과는 아래와 같습니다.

그리고 V100으로 측정한 yolov7 모델의 inference 속도는 7.552ms입니다. 20번의 warm-up하고 iteration 200번에 대해 평균을 낸 속도입니다. 또한 Host2Device와 Device2Host에 대한 Memory copy가 포함된 inference time입니다.

yolov7 with NMSPlugin model inference time

[NVIDIA] TensorRT plugin 사용 및 예제 (feat. yolov7)

Sin-Han Kang — Mon, 25 Jul 2022 23:10:19 +0900

1. TensorRT Plugin이란?

TensorRT는 C++ library이고 nvidia GPUs와 deep learning accelerator를 제공함으로써 뛰어난 performance를 제공합니다. 그래서 nvidia GPU가 장착된 서버를 쓰신다면 TensorRT(.trt)모델로 변환하여 inference하는 것이 효과적입니다.

추가로 TensorRT에서는 plugin기능을 제공하는데요. Plugin을 사용하여 model의 추가적인 연산(preprocess, postprocess)를 C++, cuda programming 으로 대체할 수 있어서 (1) 코드의 간결화 (2) 연산속도의 효율의 장점이 있습니다. 대표적인 예시로 대부분의 AI개발자분들은 detection model의 NMS(Non Maximum Suppression) 코드를 python으로 개발하실텐데 TensorRT에서는 detection model의 뒤에 NMS plugin을 붙일 수 있어서 model의 output이 NMS를 통과한 output으로 간결화되고 python이 아닌 C++이기때문에 연산속도의 효율도 가지게 됩니다.

TensorRT에서 제공하는 plugin은 아래의 그림을 통해 확인 가능하며 사용 가능한 모든 plugin은 여기서 보시면 됩니다.

TensorRT plugins

2. TensorRT plugin 예제 및 실습

최근에 새로나온 yolov7 model에 batchedNMSPlugin을 추가해보는 실습을 해보겠습니다. batchedNMSPlugin은 NMS step을 C++언어와 GPU로 inference가능하다는 장점이 있습니다. 개발 환경은 다음과 같습니다.

onnx: 1.8.0
torch: 1.9.0a0+df837d0
onnx-graphsurgeon: 0.2.8
tensorrt: 7.2.2.3
CUDA: 11.2
Driver Version: 460.73.01

2.1 batchedNMSPlugin 이란?

일단 먼저 batchedNMSPlugin의 input, output 형태가 어떤 지 알아봅시다. 해당 plugin의 input 형태는 yolov7모델의 output과 동일해야 해당 plugin을 사용가능하다는 것을 말합니다. 그리고 output형태는 해당 plugin의 결과 의미합니다.

Input
- Boxes input: [batch_size, number_boxes, 1, number_box_parameters]
  - number_box_parameters는 bbox의 정보를 담고 있는데 [x1, y1, x2, y2]으로 (x1, y1), (x2,y2)는 각각 왼쪽 위, 오른쪽 아래 bbox좌표를 나타냄
- Scores input: [batch_size, number_boxes, class_with_confidence]
  - class_with_condience = number_classes(각 클래스의 확률) * confidence(objectness)를 의미함
Output
- num_detections: [bacth_size]
  - batch마다 detection된 object수를 나타냄
- nmsed_boxes: [batch_size, keepTopK, 4]
  - NMS를 통과한 bounding box 좌표 [x1, y1, x2, y2]
- nmsed_scores: [batch_size, keepTopK]
  - NMS를 통과한 bounding box score
- nmsed_classes: [batch_size, keepTopK]
  - NMS를 통과한 bounding box class

그리고 batchedNMSPlugin에 필요한 parameter(중요한 것은 highlight)은 다음과 같습니다.

batchedNMSPlugin parameters

2.2 Torch모델 ONNX모델로 변환

TensorRT Plugin을 사용하기 위해서는 TRT모델로 만들어야 합니다. TRT모델은 ONNX모델으로부터 생성 가능하므로 Torch모델을 ONNX모델로 변환해보죠. 하지만 YOLOv7 모델의 output shape은 [1, 25200, 85]이기 때문에 batchedNMSPlugin의 input shape으로는 맞지 않습니다. 그래서 아래의 코드를 통해 YOLOv7의 output shape을 바꿔보죠.

    class ProcModel(nn.Module):
        def __init__(self, model, class_num):
            super(ProcModel, self).__init__()
            self.model = model
            self.class_num = class_num
        def forward(self, x):

            out = self.model(x)[0] # out shape = [batch, num_object, 85], 85 = class_num(80)+bbox(4)+confidence(1)
            bbox_out = torch.unsqueeze(out[:,:,:4], 2) # bbox_out shape = [batch, num_object, 1, bbox], bbox = [cx,cy,w,h]

            x1 = bbox_out[:,:,:,0] - bbox_out[:,:,:,2] / 2
            y1 = bbox_out[:,:,:,1] - bbox_out[:,:,:,3] / 2
            x2 = bbox_out[:,:,:,0] + bbox_out[:,:,:,2] / 2
            y2 = bbox_out[:,:,:,1] + bbox_out[:,:,:,3] / 2
            bbox_out = torch.stack((x1,y1,x2,y2), dim=3) # bbox_out shape = [batch, num_object, 1, bbox], bbox = [x1,y1,x2,y2]

            conf_out = out[:,:,4] # [batch, num_object, 1]

            conf_out = torch.reshape(conf_out, (conf_out.shape[1],)) # [batch, num_object]
            class_out = torch.mul(out[:,:,5:].transpose(1,2) , conf_out).transpose(1,2) # [batch, num_object, num_classes]
            return [bbox_out, class_out]

    procmodel = ProcModel(model, 80)

위와 같이 YOLOv7의 output shape을 batchedNMSPlugin의 input shape에 맞춰 변환하였습니다. YOLOv7 모델은 coco dataset(class num: 80)으로 학습되었으므로 bbox_out의 shape은 [1, 25200, 1, 4]이고 class_out의 shape은 [1,25200, 80]입니다. (bbox_out은 batchedNMSPIugin의 input중 하나인 Boxes input에 대응되고 class out은 Scores out에 대응됨)

이제 torch.onnx.export함수를 통해 ONNX 모델로 변환해봅시다.

    f = str(weights).replace('.pt', '.onnx')  #  yolov7.pt -> yolov7.onnnx
    input_names = ['images']
    output_names = ['bbox_out','class_out']
    train = False
    opset_version = 12

    torch.onnx.export(procmodel, img, f, verbose=False, opset_version=opset_version,
                      training=torch.onnx.TrainingMode.TRAINING if train else torch.onnx.TrainingMode.EVAL,
                      do_constant_folding=not train,
                      input_names=input_names,
                      output_names=output_names,
                      dynamic_axes=None)

opset은 12를 기준으로 하였고 training이 아닌 eval버전으로 export하였습니다. 그리고 output_names=[bbox_out, class_out]인것을 기억해야 합니다. 다음 스텝에서 중요한 요소이거든요.

위의 코드를 실행 시키면 ONNX 모델의 output이 잘 바뀐 것을 확인 가능합니다. (전체 변환 코드는 export.py에서 확인합니다.)

yolov7 onnx model output

2.3 onnx_graphsurgeon사용하여 batchedNMSPlugin추가

ONNX모델로 변환하면 ONNX 모델의 output shape이 위에서 설명드린 batchedNMSPlugin의 input shape과 같은 형태로 변환되었을 것입니다. 이제 onnx모델을 TRT모델로 변환하는 CLI인 trtexec를 사용하기 전에 onnx_graphsurgeon으로 ONNX 모델에 batchedNMSPlugin을 추가해주어야 합니다.

onnx_graphsurgeon는 TensorRT/tools/onnx-graphsurgeon에서 제공하는 TensoRT tool로 ONNX model에 ONNX graph를 추가하거나 수정 가능하게 해 줍니다. 해당 폴더에서 1. make install 2. make build 명령어로 쉽게 설치 가능합니다. (저는 release/7.2 version을 설치하였습니다)

이제 batchedNMSPlugin을 추가하는 코드를 설명드립니다.

import onnx_graphsurgeon as gs

def create_attrs(input_h, input_w, topK, keepTopK):
    attrs = {}
    attrs["shareLocation"] = 1
    attrs["backgroundLabelId"] = -1
    attrs["numClasses"] = 80
    attrs["topK"] = topK
    attrs["keepTopK"] = keepTopK
    attrs["scoreThreshold"] = 0.25
    attrs["iouThreshold"] = 0.6
    attrs["isNormalized"] = False
    attrs["clipBoxes"] = False

    # 001 is the default plugin version the parser will search for, and therefore can be omitted,
    # but we include it here for illustrative purposes.
    attrs["plugin_version"] = "1"

    return attrs

graph = gs.import_onnx(onnx.load('yolov7.onxx')) # load onnx model

batch_size = graph.inputs[0].shape[0]
input_h = graph.inputs[0].shape[2]
input_w = graph.inputs[0].shape[3]
tensors = graph.tensors()

boxes_tensor = tensors["bbox_out"] # match with onnx model output name
confs_tensor = tensors["class_out"] # match with onnx model output name
topK = 100
keepTopK = 50

num_detections = gs.Variable(name="num_detections").to_variable(dtype=np.int32, shape=[batch_size, 1]) # do not change
nmsed_boxes = gs.Variable(name="nmsed_boxes").to_variable(dtype=np.float32, shape=[batch_size, keepTopK, 4])  # do not change
nmsed_scores = gs.Variable(name="nmsed_scores").to_variable(dtype=np.float32, shape=[batch_size, keepTopK])  # do not change
nmsed_classes = gs.Variable(name="nmsed_classes").to_variable(dtype=np.float32, shape=[batch_size, keepTopK])  # do not change
new_outputs = [num_detections, nmsed_boxes, nmsed_scores, nmsed_classes]  # do not change

nms_node = gs.Node( # define nms plugin
    op="BatchedNMSDynamic_TRT", # match with batchedNMSPlugn
    attrs=create_attrs(input_h, input_w, topK, keepTopK), # set attributes for nms plugin
    inputs=[boxes_tensor, confs_tensor],
    outputs=new_outputs)

graph.nodes.append(nms_node) # nms plugin added 
graph.outputs = new_outputs

graph = graph.cleanup().toposort()

onnx.save(gs.export_onnx(graph), 'yolov7_gs.onnx') # save model

create_attrs 함수를 통해 위에서 표로 설명드린 batchedNMSPlugin의 parameter를 설정함
- numClasses는 coco dataset를 사용하므로 80
- keepTopK를 50으로 설정하여 한 이미지 당 detect 가능 object개수 제한
- isNormalized를 False를 설정하여 yolov7의 bbox 좌표 output이 normalized안되어 있음을 명시
gs.import_onnx 함수를 통하여 onnx model를 변경할 수 있도록 graph형태로 생성
tensors['bbox_out'] , tensors['class_out']은 ONNX model로 변환 시에 output_names로 명시한 이름
gs.Variable을 통해 batchedNMSPlugin의 output형태를 만듦
gs.Node를 통해 추가하는 batchedNMSPlugin의 노드를 만듦
- op에 BatchedNMSDynamic_TRT은 노드 이름이며 이후 trtexec cli실행 시에 해당 이름을 보고 plugin 구현체 만듦
- 여기서 attrs인자의 값으로 위의 create_attrs함수의 리턴 값을 넘김
graph.nodes.append(nms_node)으로 ONNXM model의 뒤에 batchedNMSPlugin삽입
- 여기서 중요한 것은 batchedNMSPlugin의 노드의 이름, 입출력 형태, 해당 노드의 속성만 정의한 것임
- 그래서 실제 batchedNMSPlugin의 구현체는 trtexec를 통해 TRT모델로 변환 시에 생성됨

그래서 위 코드를 기반으로 실행하면 yolov7_gs.onnx파일이 새로 생성되었으며 netron으로 까 보면 위에서 정한 노드 이름(BatchedNMSDynamic_TRT)으로 추가된 output 노드를 볼 수 있다. (전체 코드는 add_nmsplugin.py 확인!)

yolov7_gs.onxx: onnx_graphsurgeon으로 추가된 노드

2.4 ONNX모델 TRT모델로 변환

드디어 TRT모델을 만들어 볼 시간입니다. trtexec명령어로 ONNX 모델을 TRT모델로 변경해보죠.

trtexec --onnx=yolov7_gs.onnx --fp16 --workspace=1024 --saveEngine=yolov7_gs.trt

--onnx: input model이며 BatchedNMSDynamic_TRT node가 추가된 ONNX model path
--fp16: weight의 data type을 fp16으로 함
--workspace: workspace의 최대 크기를 정함 (클수록 성능이 올라갈 수 있다 함)
--saveEngine: TRT모델이 저장될 path

위 CLI를 실행하고 출력된 부분을 보았을 때 아래와 같이 plugin이 정상적으로 생성됨을 알 수 있다.

BatchedNMSDynamic_TRT plugin added successfully

해당 CLI의 동작은 기기마다 다르겠지만 10~30분 걸릴 것이니 직접 하신 다면 편안하게 기다리시죠. 기다리고 나면 yolov7_gs.trt모델이 생성될 것입니다.

2.5Plugin 추가된 TRT모델 실행

이제 batchedNMSPlugin이 추가된 TRT모델이 정상적으로 detection 되는지 확인해보죠. TRT모델을 Load하고 inference하는 코드는 이번 글의 목적은 아니니 자세히 설명드리지는 않습니다. (다음 글에서 설명드릴게요!) batchedNMSPlugin이 잘 작동하여 위에서 말씀드린 output대로 잘 나오는지 detection이 잘 되는 지 확인하는 것을 목적으로 합니다.

TRT모델로 detection 하는 코드는 detect_trt_plugin.py 확인 가능합니다.

2.5.1 batchedNMSPlugin의 output 확인

yolov7 모델의 input image는 아래와 같이 horse.jpg입니다.

Input image for yolov7 with batchedNMSPlugin

TensorRT모델을 통해 inference 하는 (부분) 코드입니다.

        image = input_image.transpose(0, 3, 1, 2) # NHWC to NWHC
        image = np.ascontiguousarray(image) 
        cuda.memcpy_htod(self.inputs[0]['allocation'], image) # input image array(host)를 GPU(device)로 보내주는 작업
        self.context.execute_v2(self.allocations) #inference 실행!
        for o in range(len(self.outputs)):
            cuda.memcpy_dtoh(self.outputs[o]['host_allocation'], self.outputs[o]['allocation']) # GPU에서 작업한 값을 host로 보냄
        
        num_detections = self.outputs[0]['host_allocation'] # detection된 object개수
        nmsed_boxes = self.outputs[1]['host_allocation'] # detection된 object coordinate
        nmsed_scores = self.outputs[2]['host_allocation'] # detection된 object confidence
        nmsed_classes = self.outputs[3]['host_allocation'] # detection된 object class number
        result = [num_detections, nmsed_boxes, nmsed_scores, nmsed_classes]

batchedNMSPlugin의 output은 위와 같이 총 4개이며 각각이 제대로 출력되는지 확인해봅니다.

yolov7 with NMSPlugin의 output

위를 통해 총 6개의 object가 detection 되었고 각 object의 좌표는 nms_boxes에서 확인 가능하며 nms_scores와 nmsed_classes 또한 순차적으로 object의 confidence와 class를 나타냅니다.

2.5.2 detection결과 확인

위의 output기반으로 detection결과를 확인하면 아래와 같습니다.

batchedNMSPlugin이 추가된 상태로 잘 detection 되는 것을 확인 가능합니다! 아래는 실제 yolov7 repo(pytorch 모델 + python NMS code)에서 제공하는 horse.jpg에 대한 결과입니다.

yolov7 result (pytorch model + python NMS)

YOLOv7: Trainable bag-of-freebies sets new state-of-the-art for real-time object detectors 논문 리뷰

Sin-Han Kang — Fri, 22 Jul 2022 09:47:32 +0900

오늘은 현시점에서 YOLO계열 중 가장 성능이 좋은 YOLOv7 논문 리뷰해보겠습니다.

1. Introduction

논문 제목을 보았을 때 가장 먼저 눈에 띄는 것은 "bag-of-freebies"일텐데요. 이게 무엇이냐!?

bag-of-freebies란?
inference시에 추가적인 cost비용 없이 네트워크의 성능을 향상하기 위한 방법
(e.g. reparameterization, data augmentation, bbox regression, label smoothing)

그래서 저자들은 inference cost를 증가시키지 않는 training optimization 방법들을 제안하여 성능을 올리 는 것을 목적으로 합니다.(해당 optimization은 cost가 들 수 있음) 그래서 해당 방법들이 적용된 모델이 YOLOv7이며 GPU device 타겟으로 real-time object detection이 가능하게 합니다.

그렇다면 어떤 bag-of-freebies방법을 사용하였을까요?

Model reparameterization: Training시에 여러 개의 layer(Conv or BN)들을 학습하고 inference시에는 해당 layer들을 하나의 layer로 fusing함
- 대표적인 예시: RepVGG, Conv-BN folding
- YOLOv7에서는 RepVGG를 (조금!) 변형시킨 형태의 reparameterziation방법 제안
Label assignment: Ground truth를 그냥 사용하는 것이 아닌 모델의 prediction, ground truth의 distribution을 고려하여 새로 soft label을 만들어냄
- 대표적인 예시: ATSS, OTA, SimOTA(in YOLOX)
- YOLOv7에서는 기존의 label assignment방법들이 다른 branch에서 도출되는 output(output이 두갈래)에 대해 dynamic target을 assignment할 수없다는 것을 문제 삼아 이를 해결함

위의 두가지 bag-of-freebies가 큰 contribution을 가지며 이외에도 아래 섹션에서 자잘한 방법들도 소개됩니다. 또한 model scaling에 있어서 자체적으로 parameter와 computation을 고려한 방법을 제시하 다양한 계열의 YOLOv7을 제공합니다. 결과적으로 YOLOv7는 설명드린 방법들을 통해 아래와 같이 뛰어난 성능을 보입니다.

2. Architecture

2.1 Extended efficient layer aggregation networks

Device의 memory cost나 computational density를 줄이기 위해 많은 연구에서 efficient한 architecture구조를 제안해왔습니다. 아래와 같이 VoVNet, CSPVoVNet, ELAN이 그에 대한 예시이며 YOLOv7 모델의 base line 구조입니다.

기존의 연구들에서 제안한 구조와 그에 대한 특징 및 장점을 소개합니다.

VoVNet
- DenseNet과 다르게 input channel수가 일정하다는 장점이 있음
- Input channel수가 일정하기 때문에 DenseNet과 다르게 1x1 Depthwise conv를 사용안하기 때문에 Inference time이 더 빠름 (1x1 depthwise conv는 하드웨어 상으로 대부분의 GPU에 가속화되기힘든 구조)
CSPVoVNet
- VoVNet에 Cross Stage Partial(CSP)구조를 추가한것으로 input channel을 반으로 나누어(partial) 왼쪽의 $c$는 그대로 transition layer에 더해짐
- 나눠진 $c$때문에 기존보다 gradient flow가 truncate되어 과도한 양의 gradient information을 방지함
- 뿐만 아니라 $c$를 나누고 transition layer에서 병합하기 때문에 gradient path는 2배로 증가하여 다양한 features를 학습할 수 있음
- VoVNet의 장점은 그대로 가져감
ELAN
- 기존의 CSPVoVNet의 장점은 그대로 가져감
- CSPVoVNet의 가장 짧고 그리고 가장 긴 gradient path 차이를 더 극대화 시키고 이로 인해 모듈 간소화
- 가장 짧고 그리고 가장 긴 gradient path를 controll하여 deep한 네트워크도 학습가능하고 수렴도 효과적으로 잘되게함
- 단점: Computation block을 어느정도 많이 쌓아도 잘 학습됨 하지만 무한대 가까이로 쌓을 경우 stable state가 망가질것이며 이는 parameter utilization이 낮아짐

위의 ELAN의 단점때문에 YOLOv7에서는 마음껏 쌓아도 학습이 잘되도록 하기 위해 E-ELAN을 제안합니다.

E-ELAN (YOLOv7)
- Expand, shuffle, merge cardinality를 통해 compuational block을 많이 쌓아도 학습능력이 뛰어남
- 오직 computational block만 바뀌고(scaling에 따라) transition layer는 절대 바뀌지 않음
- Process
  1. computational block들에 대해 channel수를 multiplier 하는 Group conv를 적용 (with $g$ group parameter)
  2. CSP로 나눠진 feature와 computational block의 output feature들이 shuffle후 concatenate됨
  3. Merge cardinality 수행

2.2 Model scaling for concatenation-based models

기존의 EfficientNet같은 경우 model scaling(e.g. EfficientNet-b0, b1,...)을 width, depth, resolution을 조절해 가며 진행하였습니다. 하지만 위에서 제안한 E-ELAN과 같이 concatenation-based architecture는 scaling-up 또는 down시에 transition layer의 input degree(channel)이 증가하게 됩니다. (아래그림 참조)

scaling up시에 width(channel 수)도 자동적으로 변경되어 scaling factor에 대한 분석이 힘듬

이는 transition layer의 input, output channel이 모두 변경되고 output channel이 변경된다는 것은 그 다음 transition layer의 input channel또한 증가하여 이는 반복적으로 발생하며 scaling factor에 대해 분석이 불가능하게 됩니다.

그래서 이러한 문제점을 해결하기 위해 YOLOv7은 다음과 같은 compound model scaling method를 제안합니다.

Computation block에만 depth scaling up을 적용하고 이에 맞춰 output channel 변경
Computation block의 output channel이 늘어났으므로 transition layer의 width scaling up적용
Partial 부분의 input feature는 전 transition layer의 output feature(scaled up)이므로 똑같이 partial 부분도 width scaling up됨

3. Trainable bag-of-freebies

3.1 Planned re-parameterized convolution

YOLOv7은 RepVGG의 변형을 사용하였습니다. RepVGG는 reparameterization방법을 사용한 것으로 아래와 같이 training시에는 병렬적으로 여러개의 conv+BN들을 학습하다가 inference시에 해당 conv+BN들을 하나의 conv로 reparameterization(fusing)합니다.

RepVGG

하지만 RepVGG의 RepConv의 identity connection은 ResNet의 residual이나 DenseNet의 concatenation을 destroy하게 됩니다. (d)를 예시로 볼때 RepConv의 identity connection과 맨 위의 input $c$에서 오는 residual(or concatenation) connection이 중복됨

그래서 YOLOv7에서는 RepConv에서 identity connection이 없는 RepConvN을 제안합니다. 그래서 residual이나 concatenation connection은 reparameterization되는 구조입니다.

3.2 Coarse for auxiliary and fine for lead loss

Deep supervision은 network의 중간에 auxiliary head를 추가하여 assistant loss를 도입하게 되고 이렇게 추가된 assistant loss를 통해 효과적으로 성능을 올릴 수 있습니다. 아래는 object detector는 deep supervision을 사용했을 경우와 아닌 경우를 직관적으로 보여줍니다.

Deep supervision for object detector

해당 논문에서는 원래의 final output을 lead head, 추가된 output을 auxiliary head라 명명합니다.

위와 같이 YOLOv7은 deep supervision을 사용하게 되는 데 문제점이 발생합니다. 바로 대부분의 기존 label assignment방법들은 lead와 auxiliary head와 같이 2가지 head가 동시에 있을 경우 soft label을 만들어 낼 수 없습니다.

YOLO의 label assignment의 example
→ prediction한 bounding box와 ground truth의 IoU를 objectness의 soft label로 사용하여 오직 ground truth를 사용한것 보다 성능이 향상

그나마 아래와 같이 lead head와 auxiliary head를 독립적으로 계산하여 label assignment를 구현한 것이 최근의 연구입니다.

YOLOv7에서는 (1) lead head prediction을 사용하여 lead head와 auxiliary head학습하거나 (2) lead head prediction을 guidance로 사용하여 coarse-to-fine hierarchical labels을 생성해냅니다. coarse-to-fine hierarchical labels은 auxiliary head와 lead head 학습에 사용됩니다. 제안하는 2가지 Deep supervision label assignment의 구조는 아래와 같습니다.

Deep supervision label assignment

3.2.1 Lead head guided label assigner

위에서 말씀드렸듯이 lead head의 prediction과 ground truth을 기반으로 soft label을 생성해냅니다. 해당 soft label은 모델의 auxiliary, lead head의 training에 사용됩니다.

이렇게 lead head의 prediction만 이용한 이유는 lead head가 상대적으로 강한 learning capability를 가지고 있어 prediction과 ground truth의 distribution이나 correlation을 더 잘 표현가능하기 때문입니다. 또한 auxiliary head가 lead head가 학습했던 내용을 학습할 수 있으므로 lead head는 학습하지 못한 다른 featurea를 학습할 수 있는 residual learning이 가능합니다.

3.2.2 Coarse-to-fine lead head guided label assigner

해당 방법도 lead head와 ground truth를 이용해 soft label을 생성합니다. 그러나 여기서는 두가지 다른 set의 soft label을 만들어냅니다.

Coarse label: grid를 좀 더 positive target으로 여겨지도록 하여 생성된 label
- Positive sample assignment process의 constraint를 완화시키는 방법으로 만듬
- constraint를 완화했다는 것은 coarse positive grids(label)가 fine label(soft label)처럼 완벽하고 섬세한 label을 만들어 지지 않게 함
- Auxiliary head의 학습에만 사용
Fine label: 위의 lead head guided label assigner와 같은 soft label
- Lead head의 학습에 사용

Lead head는 high recall, precision을 모두 가능하지만 auxiliary head는 그럴 능력이 없기 때문에 coarse label만 학습하게 하여 recall에만 optimization하는것을 목적으로 합니다. ( auxiliary head를 학습하는데 coarse label을 fine label처럼 만들면 결국 bad prior만 학습하게된다고 하네요.)

3.3 Other traininable bag-of-freebies

총 3가지의 추가적인 bag-of-freebies방법을 사용하였습니다.

Batch normalization in conv-bn-activation topology
- Conv와 BN의 연결은 선형식이므로 fusing함
- 이는 RepConv에서도 수행
Implicit knowledge (아래 그림 참조)
- 관찰(입력데이터)과 상관없이 모델에 내재된 지식을 뜻함
- YOLOR에서 제안된 방법으로 convolution feature map에 Implicit knowledge로 학습된 vector를 곱(or 더)해줌으로써 성능향상에 도움을 줌
- 해당 Implicit knowledge또한 inference시에는 이전 또는 이후 convolution layer와 fuisng 됨 (선형적인 vector의 곱셈 또는 덧셈이므로)
EMA(Expoinential Moving Average) model
- 원래(이전의) 학습하던 방향에서 급격하게 다른 방향으로 학습하지 못하게 하여 일정한 학습방향성을 유지시켜주는 방법

Implicit knowledge

4. Experiments

4.1 Experimental setup

COCO dataset에 대해 성능 평가를 진행하였으며 제안한 YOLOv7모델은 pretrained model을 사용하지 않았다고 합니다. validation set을 통해 hyperparameter를 조정하였습니다.

Edge GPU, normal GPU, cloud GPU용 모델을 각각 YOLOv7-tiny, YOLOv7, YOLOv7-W6이라고 지칭
- YOLOv7-tiny는 leaky ReLU사용
- 나머지는 다 SiLU사용
YOLOv7기준으로 Neck부분에 제안한 compound scaling up을 한것이 YOLOv7-X
YOLOv7-W6기준으로 compound scaling up한것이 YOLOv7-E6, YOLOv7-D6
YOLOv7-E6에 E-ELAN을 사용한 모델이 YOLOv7-E6E

4.2 Comparison with Baselines

Comparison with Baselines

4.3 Comparison with state-of-the-arts

Comparison with state-of-the-arts

More comparison for YOLOv7

[NVIDIA] DeepStream 이해 및 설명

Sin-Han Kang — Wed, 13 Jul 2022 00:29:57 +0900

1. DeepStream이란?

Deepstream은 SDK형태로 제공하며 Vision AI application과 service를 쉽고 빠르게 개발할 수 있게 해줍니다. 그리고 DeepStream은 multi-platform, scaleablity를 제공하며 on-premise, on-edge, cloud환경 모두에서 deploy가능합니다.

Multi-platform: window, mac, linux 등의 다양한 플랫폼을 의미
Scaleability: 유저수나 트래픽이 많아져도 application이 잘 작동함을 의미

흠... 여기까지 들었을때는 그래서 DeepStream이 먼지 모르시겠죠? 쉽게 설명을 위해 NVIDIA 세계관(?)의 End-to-END AI Development는 아래와 같습니다. 빨간색 부분이 DeepStream이며 해당부분(3번)에서 알 수 있듯이 만들어진(training이 끝난) ML 모델을 특정 application이나 service에 deploy하기 위해 사용되는 것이 DeepStream입니다.

End-to-END AI Development in NVIDIA

그래서 DeepStream은 (1)입력 데이터(e.g. 드론이 찍은 항공이미지, 로봇의 카메라, 미디어 동영상)를 받아 (2)ML 모델의 입력 shape이나 특성에 맞게 preprocess를 하고 (3)ML 모델로 inference를 하고 (4)postprocess까지 한 뒤 (5)분석 및 시각화까지 하는 것을 목적으로 합니다.

DeepStream SDK

2. DeepStream을 왜 써야할까?

DeepStream만의 강점은 다음과 같습니다.

Seamless Development
- C/C++, Python, low-code graphical programming(Graph Composer)와 같이 다양한 development를 제공
- DeepStream ships은 다양한 hardware accelerated plugins를 제공
- 다양한 pretrained된 ML model(e.g. SSD, YOLO, MaskRCNN)을 제공
- Custom function과 libraries과 통합가능
- TensoRT를 이용하여 multi-GPU, mult-stream, batch support 등 다양한 옵션을 제공하여 극대화된 performance를 제공
Low-Code Programming with Graph Composer
- Graph Composer는 low-code graphical progamming을 제공을 통해 손쉽게 복잡한 pipelines을 만들어 줄 수 있음
- 위의 pipelining을 docker container builder를 통해 processing 및 deploy 가능

Graph Composer를 통한 pipelining예시

Securely Manage Apps & Services
- DeepStream SDK은 cloud 또는 edge system에 유연하게 실행될 수 있음
- 안전한 IoT device communication을 위해 two-way TLS authentication(with SSL certificates)을 제공
- IoT 통합 인터페이스를 Redis, Kafka, MQTT, and AMQP와 함께 제공
- Containerized apps을 관리하기위해 Kubernetes와 Helm Charts 사용
DeepStream SDK plug-ins
- Stereo Camera 지원
- H.264, H.265 video decoding
- JPEG decoding
- Metadata generation and encoding
- Metadata serialization/deserialization
- Stream aggregation and batching
- Object tracking 지원
- Accelerated X11/EGL-based rendering
- Scaling, format conversion, and rotation
- Filtering based on Region of Interest (ROI)
- Audio/Video Template Plug-In
- ...

3. DeepStream의 Performance

DeepStream을 이용했을 때 end-to-end application performance를 측정하였습니다. End-to-end application에는 data ingestion, decoding, image processing이 포함되어있고 1080p/30fps streams을 input으로 사용하였습니다.

Performance of Deepstream

다양한 task의 application과 다양한 모델에 대해 model inference속도(FPS)를 측정한 것을 알 수 있습니다. 이 Performance가 좋은 것은지는 다른 framework/system이랑 비교를 통해 확인해봐야겟지만 그래두 좋다는 거겠죠? ㅋㅋ

다음 글에서는 DeepStream을 실제로 사용하는 방법 및 코드를 설명드리도록 하겠습니다. 감사합니다~~

4. Reference

https://developer.nvidia.com/deepstream-sdk

NVIDIA DeepStream SDK

Build and deploy AI-powered Intelligent Video Analytics apps and services. DeepStream offers a multi-platform scalable framework to deploy on the edge or connect to any cloud.

developer.nvidia.com

https://www.nvidia.com/en-us/on-demand/session/gtcspring22-s41777/

How To Develop and Optimize Edge AI apps with NVIDIA DeepStream | NVIDIA On-Demand

Learn how the latest features of DeepStream are making it easier than ever to achieve real-time performance even for complex video AI applications

www.nvidia.com

VMAF score 란?

Sin-Han Kang — Sat, 9 Jul 2022 17:32:26 +0900

해당 글은 Netflix의 VMAF post를 참고 및 번역하였으며 VMAF의 이해와 사용 방법에 대해 적어보려 합니다. 목차는 다음과 같습니다.

Video Quality Metric이란?
기존의 Video Quality Metric 방법들과 문제점
VMAF란?
VMAF의 사용 방법

1. Video Quality Metric 이란?

우리는 .png, .jpg와.mp4와 같은 이미지/비디오 파일을 많이 봐왔을 것입니다. 해당 확장자를 가진 파일들은 원본 이미지/비디오 파일을 의미하는 것이 아닌 encoding된 파일을 의미합니다. 원본 파일의 모든 픽셀값을 그대로 local/cloud storage에 저장하는 것은 용량에 부하가 크기 때문에 해당 문제를 해결하기 위해 encoding이라는 압축방법을 사용하며 encoding된 파일을 담는 그릇 개념의 확장자가 .mp4입니다. (encoding은 코덱으로 진행가능하며 대표적인 방법으로는 H.264, H.265 가 있습니다.)

Encoding 즉, 압축을 하는 방법은 여러가지 일텐데 각 방법들이 압축을 잘하고 있는지(인간의 눈에 맞춰진 압축인지) 비교 및 확인하려면 어떻게 해야 할까요? 바로 그 확인을 Video Quality Metric을 통해 하게됩니다. 그렇기 때문에 Video Quality Metric이 정확해야 각 encoding방법들이 효과적인지 판단하는 지표가 됩니다.

1.1 Dataset

Video Quality Metric을 측정하기 위한 데이터가 필요할 텐데요. 그래서 Netflix에서는 자신들이 가진 다양한 장르와 다양한 화질의 비디오를 이용해 dataset을 구성하였습니다. 정확히 총 34개의 clip으로 이루어진 reference video로 dataset을 구성하였으며 자세한 특성은 다음과 같습니다.

Dataset(videos)에는 high-level features와 low-level features가 모두 포함됨
- High-level features: animation, indoor/outdoor, camera motion, face close-up, people, water, number of objects
- Low-level features: film grain noise, brightness, contrast, texture, motion, color variance, color richness, sharpness
H.264/AVC로 encoding 및 decoding
- 384x288 ~ 1920x1080사이의 다양한 해상도 사용
- 375 kbps ~ 20,000 kbps사의 bitrates를 가짐
- 해당 codec을 거친 video을 distorted videos라 명명
- 총 300개의 distorted video생성

1.2 Differential Mean Opinion Score (DMOS)

기존의 Video Quality Metric들과 제안하는 VMAF가 실제 인간이 보는 시선과 같은 지 확인하기 위해 사람들에게 distorted video가 reference video로부터 얼마나 손상(impairment)되었는 지 측정하도록 하였습니다. 손상이 클수록 0점에 가깝고 작을수록 100점에 가깝도록 기록하였습니다. 여러 사람의 해당 기록을 모아 평균하여 점수로 표현한 것이 DMOS이며 이는 ground truth(label)로 사용됩니다.

2. 기존의 Video Quality Metric 방법들과 문제점

기존에 자주 쓰이는 Video Quality Metric은 아래와 같습니다.

PSNR(Peak signal to noise ratio)
- 최대 전력에 대한 잡음의 전력을 의미하며 distorted video와 reference video의 차이(MSE)을 잡음이라 정의하여 구함
- 값의 차이만 구하기 때문에 실제 사람의 인지 시각을 정확히 반영하지 못함
SSIM(Structural Similarity Index)
- 시각적 화질 차이를 평가하기위한 방법으로 Luminance, Contrast, Structural 이 3가지 측면에서 품질을 평가함.
Multiscale FastSSIM
PSNR-HVS

위의 metric들은 실제 사람이 평가한 DMOS와 비교했을 때 문제점을 갖습니다.

2.1 Qualitative Comparison

DMOS와 PSNR을 정성적으로 비교해보았습니다. 아래와 같이 4개의 distorted video가 존재할 때 위쪽의 두 video은 PSNR이 31dB가 측정되었고 아래 두 개의 video는 PSNR이 34dB로 측정되었습니다.

Distorted video examples

사람이 보기에 왼쪽의 Crowd 사진에서는 위아래 사진이 별 차이가 없기 때문에 위 사진이 DMOS가 82, 아래가 96이 기록되었습니다. 하지만 오른쪽 fox 사진은 사람이 보기에도 차이가 분명하기 때문에 위 사진은 DMOS가 27, 아래가 58로 기록되어 큰 차이를 보입니다. 즉, PSNR의 값차이가 DMOS차이와 사진에 따라 다를 수 있으므로 적절한 video quality metric이 아님을 알 수 있습니다.

2.2 Quantative Comparison

여기서는 위의 각각의 4가지 metric을 DMOS와의 상관관계를 측정하였으며 다수의 distorted video을 대상으로 진행하였습니다. 각각의 video quality metric이 optimal 하다고 하면 DMOS와 정비례 관계가 되어야 합니다.

The points with the same color correspond to distorted videos stemming from the same reference video. Due to subject variability and reference video normalization to 100, some DMOS scores can exceed 100.

하지만 위 그림처럼 각각의 기존 metric들은 DMOS와 정비례 관계가 아님을 알 수 있으며 이는 적절한 video quality metric 또한 아님을 말합니다.

추가로 video의 성격을 나누어 DMOS와 각각의 metric을 측정하였을 경우에도 정비례가 관계가 아닙니다. (video의 성격은 아래와 같이 High Noise, CG Animation, TV Drama로 구분하였습니다.) 예를 들어 PSNR의 경우 TV Drama에 대해 32~36 dB사이의 값 안에서만 측정되어 비슷한 quality의 동영상들이라고 말하고 있지만 실제 사람들이 측정한 DMOS경우 20~100까지의 폭넓은 범위를 가지며 각기 다른 화질의 비디오들이라고 판단하게 됩니다.

Previous video quality metrics comparison by title

3. VMAF란?

Video Multimethod Assessment Fusion (VMAF)는 Netflix에서 개발한 video quality metric으로 ML을 이용합니다. 기존의 여러 개의 video quality metric들을 가중치의 합(weighted sum)을 하여 나온 score를 VMAF라고 합니다. 여기서 각각의 기존 video quality metric을 elementary metric이라고 명시합니다.

그럼 여기서 궁금증은 3개로 나뉠 것이고 그에 대한 답은 아래와 같습니다.

왜 weighted sum을 하는가?
- 기존의 각각의 elementary metric은 각각 장단점을 가지고 있기 때문에 weighted sum을 통해 장점만 보존하여 점수를 도출하도록 함
어떻게 weigthed sum 을 하는가?
- 각 elementary metric의 learninable parameter가 하나씩 곱해질 것이고 이는 Support Vector Machine (SVM) regressor으로부터 학습을 함
- SVM학습을 위한 dataset 구성을 위해 위의 언급해드린 dataset을 train, test dataset으로 나누고 ground truth(label)은 사람이 측정한 값인 DMOS로 함
VMAF에 사용되는 기존의 elementary metric은 무엇인가?
- VMAF(0.3.1)기준으로 총 3가지를 사용함 → [Visual Infromation Fidelity(VIF), Detail Loss Metric (DLM), Motion]
- VIF: reference video에 존재하는 정보량과 distorted video의 정보량을 비교하여 품질을 평가 (두 비디오가 공유하는 엔트로피를 계산)
- DLM: video의 content visibility나 사람의 집중도를 방해하는 redundant impairment를 평가
- Motion: 인접하는 frame간의 temporal difference(시간상의 다름?)을 측정

위와 같은 방식으로 VMAF를 구성하고 Section 2번과 같이 DMOS와 VMAF가 정비례를 가지는 지 확인하는 실험을 하였습니다. 기존의 PSNR-HVS와 비교했을 때 확연히 VMAF가 DMOS와의 정비례 관계를 가지는 것을 확인가능합니다. 그리고 이는 VMAF score가 사람의 인지하는 화질과 매우 유사하고 잘 반영하고 있다고 말 할수 있습니다. 또한 video의 성격을 나누어 측정하였을 때에도 정비례 관계를 가집니다.

VMAF performance results

[Torch2TFLite] Torch 모델 TFLite 변환 (feat. yolov5)

Sin-Han Kang — Sun, 26 Jun 2022 18:20:57 +0900

AI 개발자라면 가장 많이 사용하는 framework는 Torch이나 TensorFlow일것입니다. 저는 Torch을 조금 더 주력으로 사용합니다. (대부분 연구자 분들도 Torch를 사용하시겠죠) 하지만 Torch 모델은 Arm cpu를 사용하는 device에서는 최적화되지않아 inference 속도가 다소 느립니다. 그래서 Torch모델을 Arm cpu 연산에 최적화된 TFLite 모델로 변환시키는 방법에 대해 말씀드리도록 하겠습니다.

Torch모델을 TFLite로 변환시키는 과정은 다음과 같습니다.

Torch 모델 → ONNX 모델
ONNX 모델 → OpenVINO 모델
OpenVINO모델 → TFLite 모델

Torch모델은 detection 모델 중 하나인 yolov5를 사용하겠습니다. 위의 과정을 거치면서 변환이 정상적으로 되었는 지 확인하기 위해서 Torch모델일때의 detection결과와 변환과정에서 생긴 모델들의 detection결과와 같은 지 확인하면서 진행하겠습니다.

실험에 사용한 환경은 다음과 같습니다.

Enviornment
- torch: 1.10.1+cu111
- tensorflow: 2.4.1
- onnx: 1.8.0
- openvino-dev: 2022.1.0
- openvino2tensorflow: 1.31.3

위의 사용된 환경꼭 맞춰주셔야 코드 정상실행됩니다. (특히 torch버전 맞춰주세요!) 사용된 모든 코드는 여기서 사용가능합니다.

1. Torch 모델 → ONNX 모델

Torch 모델을 OpenVINO 또는 TensorFlow(TFLite)모델로 변환하기 위해서는 ONNX(Open Neural Network Exchange)라는 중간자적 모델을 거치게 됩니다. 그래서 Torch 모델을 ONNX모델로 변환하기 위해서는 다음과 같은 코드를 사용합니다.

# yolov5_convert.py
model = attempt_load(save_path, device=device, inplace=True, fuse=True)  # load FP32 model
nc, names, stride = model.nc, model.names, model.stride

gs = int(max(model.stride))  # grid size (max stride)
imgsz = [check_img_size(x, gs) for x in imgsz]  # verify img_size are gs-multiples
im = torch.zeros(bs, 3, *imgsz).to(device)  # image size(1,3,640,640) BCHW iDetection

# torch2onnx.py
def torch2onnx(model, im, save_path, train, dynamic):
    try:
        logger.info(f'ONNX: starting export with onnx {onnx.__version__}...')
        torch.onnx.export(model, im, save_path, verbose=False, opset_version=12,
                            training=torch.onnx.TrainingMode.TRAINING if train else torch.onnx.TrainingMode.EVAL,
                            do_constant_folding=not train,
                            input_names=['images'],
                            output_names=['output'],
                            dynamic_axes={'images': {0: 'batch'},  # shape(1,3,640,640)
                                        'output': {
                                            0: 'batch',
                                            }  # shape(1,25200,85)
                                        }if dynamic else None)
		...

yolov5 공식 repo에서는 attempt_load 함수로 model을 load한다는 것만 알아두시고 직접 모델을 load하고 싶으시면 자신만의 방법 (e.g. torch.load)으로 model을 load하시면 됩니다. Torch모델을 ONNX모델로 변환하기 위해서 torch.onnx.export함수를 사용하시면 됩니다. 중요하게 볼 parameter는 아래와 같습니다.

model: Torch model
im: 모델의 input image shape을 결정하는 dummy tensor
do_cosntant_folding: True로 설정 할 경우 Conv-BN layers가 Conv하나로 folding(fusing)되어 graph 최적화함
dynamic_axes: batch size에 대한 static한 설정을 할지 말지를 결정 (저는 dynamic변수에 False를 할당했습니다)

위의 함수를 통해 yolov5s Torch모델을 ONNX모델로 변환하는 CLI와 그에 대한 결과는 다음과 같습니다. 아래와 같이 ONNX 모델로 변환된것을 확인 가능하며 ONNX모델로 detection한 결과가 Torch모델로 detection한 결과와 같은 것을 확인가능합니다.

ONNX 변환 확인

2. ONNX 모델 → OpenVINO 모델

OpenVINO는 Intel에서 개발한 AI 모델 inference와 deploy에 특화된 toolkit입니다. 아래와 같이 OpenVINO형태로 변환된 AI모델은 Intel CPU 대상으로 최적화된 연산이 가능합니다. 또한 다른 framework의 모델로부터 변환이 자유롭게 "잘" 된다는 특징때문에 저는 ONNX 모델에서 OpenVINO를 거쳐 TensorFlow 모델로 변환을 할 것입니다.

출처: https://www.intel.com/content/www/us/en/developer/tools/openvino-toolkit/overview.html

ONNX모델에서 OpenVINO모델로 변환하는 주요 코드는 다음과 같습니다.

def onnx2openvino(model, onnx_path, save_path, data_type):
    try:
        logger.info(f'OpenVINO: starting export with openvino {ie.__version__}...')
        f = str(save_path).replace('.pt', f'_openvino_model{os.sep}')

        cmd = f"mo --input_model {onnx_path} --output_dir {f} --data_type {'FP16' if data_type=='fp16' else 'FP32'}"
        subprocess.check_output(cmd.split())  # converting

	...

OpenVINO모델로 변환하기 위해서 CLI를 사용하게 됩니다. CLI는 python의 subprocess를 통해 실행하였고 mo라는 명령어를 통해서 ONNX모델에서 OpenVINO모델로 변환하였습니다. (mo는 openvino-dev PyPI가 설치되어 있어야 함!) 변환에 필요한 parameter는 다음과 같습니다.

--input_model: ONNX model이 저장된 path
--output_dir: OpenVINO모델이 저장될 directory
- 기본적으로 OpenVINO모델은 .xml파일과 .bin파일로 나누어 저장됨
- .xml 파일은 모델의 meta data를 저장한 파일, .bin파일은 모델의 weight값을 저장한 파일
--data_tpye: Converting시에 weight의 data type을 결정
- 저는 Float32을 사용하였음.

위의 함수를 통해 yolov5s ONNX모델을 OpenVINO모델로 변환하는 CLI와 그에 대한 결과는 다음과 같습니다. 아래와 같이 OpenVINO 모델이 잘 생성된것을 확인 가능하며 OpenVINO모델로 detection한 결과가 Torch모델로 detection한 결과와 같은 것을 확인가능합니다.

OpenVINO 변환 확인

3. OpenVINO 모델 → TFLite 모델

이제 우리가 원하는 TFLite로 모델로 변환하는 과정만 남았습니다. OpenVINO모델을 TFLite모델로 변환하기위해 PINTO님의 openvino2tensorflow PyPI를 사용할 것입니다. 변화 코드는 다음과 같습니다.

def openvino2tflite(model_name, openvino_path, save_dir):
    try:
        logger.info(f'TFLite: starting starting export with TF {tf.__version__}...')
        if not Path(openvino_path).is_file():
            openvino_path = next(Path(openvino_path).glob('*.xml'))  # get *.xml file from *_openvino_model dir

        saved_model_path = str(save_dir / 'model_float32.tflite')
        cmd = f'openvino2tensorflow --model_path {openvino_path} --model_output_path {save_dir}\
                --output_no_quant_float32_tflite  --weight_replacement_config ./data/convert/replace_{model_name}.json'
        
        subprocess.check_output(cmd.split())        
    ...

이번에도 CLI를 통해서 변환을 합니다. openvino2tensorflow 명령어를 사용하며 주요 parameter는 다음과 같습니다.

--model_path: OpenVINO 모델(.xml, .bin)이 저장된 directory
--model_output_path: TFLite모델이 저장될 directory
--output_no_quant_float32_tflite: Float32 data type을 TFLite모델로 변환함을 명시
--weight_replacement_config: OpenVINO 모델에서 TFLite변환시 수정해야하는 configuration
- 주로 Transpose나 Reshape연산을 할 때 차원 axis가 안맞을 경우 수동으로 convert시에 axis값을 수정해줘야함
- 이는 OpenVINO와 TensorFlow간의 모델선언의 차이로 생기는 문제로 수동으로 수정해서 해결해줘야함

--weight_replacement_config가 이해가 잘 안되실 테니 좀 더 설명드립니다. TFLite 모델로 정상적으로 변환하기 위해서는 transpose연산의 dimension axis를 기존 [0,1,3,4,2]에서 [0,3,1,2,4]로 바꿔줘야 합니다. 그렇게 하기위해서 --weight_replacement_config의 parameter값으로 ./data/convert/replace_yolov5s.json을 설정하는데 해당 파일안의 내용은 아래와 같이 변경하고 싶은 layer_id를 선택하고 "values"의 key값으로 변경하려 하는 dimension axis를 설정해주면 됩니다. (아래는 하나의 transpose operation에 대한 dimension axis를 변경하는 내용을 설명드린것이고 전체 파일 내용은 제 github의 ./data/convert/replace_yolov5s.json을 참고해주세요.)

--weight_replacement_config 인자 설명

위의 openvino2tflite 함수를 통해 yolov5s OpenVINO모델을 TFLite모델로 변환하는 CLI와 그에 대한 결과는 다음과 같습니다. 아래와 같이 TFLite 모델이 잘 생성된것을 확인 가능하며 TFLite모델로 detection한 결과가 Torch모델로 detection한 결과와 같은 것을 확인가능합니다.

TFLite 변환 확인

4. 각 모델 별 Inference 속도 비교

속도 비교에 사용한 desktop의 spec은 다음과 같습니다. inference 속도를 측정하는데 사용되는 이미지는 2장(위의 bus.jpg와 zidane.jpg)입니다. Inference속도는 CPU, Float32 data type기준으로 출력하였습니다.

Device
- CPU: Intel(R) Xeon(R) Silver 4210R CPU @ 2.40GHz (40core)
- GPU: GeForce RTX 3080 (4개)

inference 속도 비교

위의 그림의 inference 속도에 대한 평균을 내어 정리한 테이블은 아래와 같습니다. 확실히 inference에 사용한 device의 cpu가 intel이므로 OpenVINO모델에서 가장 빠른것을 알 수 있고 arm cpu에 최적화된 TFLite 모델은 inference가 느린 것을 확인가능합니다.

Model type	Inference speed (s)
Torch	0.088s
ONNX	0.077s
OpenVINO	0.042s
TFLite	0.360s

이후에는 arm cpu에 대해서도 inference비교할 것이며 quantization사용 시에 따른 속도 비교또한 진행하도록 하겠습니다. 감사합니당~~

[MobileOne] An Improved One millisecond Mobile Backbone 논문 리뷰

Sin-Han Kang — Sat, 25 Jun 2022 17:03:30 +0900

2022년 6월 Apple에서 mobile friendly한 모델을 제안하는 논문인 An Improved One millisecond Mobile Backbone 을 리뷰해보도록 하겠습니다.

1. Introduction

저자들은 실제 mobile에서 latency(inference speed)를 최적화시키는 것을 목표로 하고 있으며 기존의 논문들이 제안했던 mobile-friendly하다는 모델들에 대해 아래와 같은 단점을 지적하였습니다.

FLOPs와 parameter수가 (상대적으로) 작다고 하여 실제 latency가 빠르지 않음
skip-connection과 branching은 많은 memory access cost를 발생시키므로 latency가 최적화되지 않음

skip connection & branching examples

그래서 저자들은 (1) mobile device에서 latency의 bottleneck 요인을 분석하고 이를 바탕으로 (2) mobile device에서 inference 속도를 최적화한 모델인 MobileOne을 제안하게 됩니다. MobileOne은 아래와 같이 SOTA accuracy와 latency performance를 도달하였으며 전에 제가 리뷰한 MobileViT-S보다 5배 빠르다고 하네요! latency cost는 CoreML을 이용하여 IPhone12 device에서 측정하였다고 합니다.

Comparisons of Top-1 accuracy on image classification vs latency on an iPhone 12

2. Method

2.1 Metric Correlations

모델의 efficiency를 측정하는 (기존의) metric인 parameter수와 FLOPs가 실제 latency와 correlation이 있는 지 확인하였습니다. 저자들은 PyTorch 모델들을 ONNX 형태로 1차 변환하였고 ONNX 모델을 CoreML tool을 이용해 coreml package형태로 2차 변환하여 IPhone12에서 latency를 측정하였습니다.

실제로 실험해보니 아래와 같이 대다수의 모델이 parameter수가 높은 반면에 latency는 낮게 측정되었습니다. FLOPs와 latency관계에서도 비슷한 경향을 보인다는 것도 확인하였습니다. 또한 MobileNet이 Transformer계열 모델들과 FLOPs와 parameter 수는 비슷하지만 latency가 낮은 것을 확인하였다고 합니다.

또한 아래와 같이 Spearman rank correlation측정시에도 latency와 FLOPs는 어느 정도만의 correlation이 존재하고 parameter와 latency는 correlation이 적다는 것을 확인하였습니다. 뿐만 아니라 desktop CPU에서 측정하였을 때도 correlation이 낮게 나오는 것을 알 수 있습니다.

Spearman rank correlation coefficient between latency-flops

위 실험들을 통해 FLOPs(parameter수)와 latency는 correlation이 적다는 것을 확인하였습니다.

2.2 Key Bottlenecks

해당 섹션에서는 latency에 악영향을 미치는 network architecture 및 operation에 대해 분석합니다.

2.2.1 Activation Fucnctions

30 layers구조의 CNN을 구성하였고 해당 CNN에서 activation function에 따른 latency 측정 실험을 하였습니다. 최근에 efficient하다고 제안된 SE-ReLU, Dynamic Shift-Max, DynamicReLUs들은 모두 hardware acceleration에 최적화되지 않아 latency가 높게 측정되었습니다. 그에 비해 ReLU와 GELU는 latency가 낮게 측정됨을 확인하였고 그래서 저자들은 MobileOne에 ReLU activation만 사용한다고 합니다.

Comparison of latency on mobile device of different activation functions

2.2.2 Architectural Blocks

Runtime performance에 큰 (악) 영향을 끼치는 요인은 memory access와 degree of parallelism입니다. memory access는 multi-branch network 구조인 경우에 크게 상승한다고 말합니다. 이유는 각 branch로부터 activation들이 다음 tensor를 연산하기 위해서 저장해야하기 때문입니다. 또한 Squeeze-Excitation(SE) block에서 사용되는 global pooling operation은 synchronization cost가 크기 때문에 runtime performance에 악영향을 줍니다.

그래서 위의 내용을 정량적으로 확인하기 위해 30 layers구조의 기본적인 CNN에서 skip-connection과 SE block을 추가했을 때 inference time을 측정하였습니다. 아래와 같이 skip-connection과 SE block이 추가되었을 때 latency가 높아지는 것을 확인하였으며 이를 바탕으로 MobileOne에서는 skip-connection을 완전히 제거하였고 SE block사용은 최대한 제한하였습니다. (SE block이 accuracy 향상에 좋다고 하여 쓴다고는 하네요)

Ablation on latency of different architectural blocks

2.3 MobileOne Architecture

MobileOne의 구조는 위의 분석을 통해 디자인되기도 하였지만 또 다른 중요한 구조는 re-parameterization이 가능한 형태를 사용하여 training-time과 inference-time구조가 다르다는 점입니다.

2.3.1 MobileOne Block

아래 그림에서 보이듯이 RepVGG논문에서는 training시에는 multi-branch구조로 있다가 inference-time에는 여러 branch의 layer(또는 operation)을 하나의 conv layer로 reparameterization하게 됩니다. 이렇게 reparameterization하게 되면 하나의 con layer로 연산 가능하기 때문에 inference time에는 memory access을 많이 하는 multi-branch구조를 제거시킵니다.

Structural re-parameterization of a RepVGG block

RepVGG에서는 reparameterization을 Standard Conv layer에 적용하였는데요. MobilONE은 RepVGG와 다르게 MobileNet-V1 의 block인 3x3 depthwise conv와 1x1 pointwise conv로 block을 구성하였습니다. 해당 block으로 RepVGG처럼 reparameterizable한 skip-connection추가 된 형태로 training하게 되고 testing때는 reparameterization하게됩니다.

MobileOne block has two different structures at train time and test time

그리고 저자들은 over-parameterization branch를 제안하였는데 위 그림과 같이 over-parameterization factor $k$ 추가하여 해당 (depthwise or pointwise) conv-BN을 연속해서 $k$개 쌓도록 하였습니다. Conv-BN이 여러 개 쌓인 구조는 사이에 비선형 함수인 activation이 없기 때문에 결국 linearlity성격을 가지므로 하나의 conv로 치환(fusing) 가능하기 때문에 저자들은 이와 같이 over-parameterization방법을 제안하게 되었습니다. $k$는 hyperparameter로 1~5 사이의 값을 가집니다.

Conv-BN이 어떻게 folding(fusing) 될 수 있는지 수학적으로 알아봅니다.

$ W' \in \mathcal{R}^{C_{out} \times C_{in} \times K \times K}, b' \in \mathcal{R}^D $: Weight and bias
- $C_{out}$ ,$C_{in}$: Output and input channel dimension
- $K$: Kernel size

Conv-BN layer는 linear operations으로만 구성되어 있기 때문에 위의 Conv layer의 weight $W'$가 아래와 같이 하나의 Conv weight로 folding가능합니다.

$ \widehat{W} = W' * \frac{\gamma}{\sigma}, \widehat{b} = ( b' - \mu ) * \frac{\gamma}{\sigma} + \beta $

결국, inference시에 모든 branch안의 존재하는 batch norm layer는 이전 Conv layer에 folding됩니다.

또한 skip connection(multi-branch)은 RepVGG의 reparameterization방법을 통해 folding된다. 즉, 1x1 conv은 $K-1$ zero padding이 추가되어 $K \times K$ Conv과 똑같은 shape으로 만들어 여러 skip connection(multi-branch)는 하나의 Conv layer weight로 합(summation)쳐진다. 수식으로 표현하면 $W = \sum^M_i \widehat{W}_i, b= \sum^M_i \widehat{b}_i $ 와 같고 $M$은 branch의 수를 의미합니다.

저자들이 주장하는 Reparameterization과 over-parameterization의 효과를 주장하기 위해 아래와 같은 실험을 진행하였습니다.

Effects for  Reparameterization & over-parameterization

Table 6을 통해 over-parameterization factor $k$에 변화에 따른 성능 비교를 하였을 때 MobileOne의 scale이 큰 경우(MobileOne-S1) $k$이 커짐에 따라 큰 성능 향상 효과를 보지 못했지만 MobileOne의 scale이 작은 경우에는(MobileOne-S1) $k$가 4일때 0.5%의 성능향상 효과를 보았습니다.

Table 7을 통해서는 reparameterizable한 branch를 추가하였을 때 model의 scale variant에 상관없이 성능이 더 높게 나왔다는 결과를 보여주고 Figure 4에서는 multi-branch를 사용하고 k가 4일 경우 train, validation loss가 가장 낮게 학습된다는 실험 결과를 보여주었다. 위의 3개의 실험결과를 통해 저자들은 주장한 방법론에 대한 성능 검증을 하였습니다.

2.3.2 Modle Scaling

저자들은 width scale에 따라 5개의 MobileOne 버전을 아래와 같이 제안하였다.

MoblieOne network specifications

2.4 Training

작은 모델일수록 regularization이 크면 underfitting되기 때문에 regularization을 약하게 주어야 합니다. 그래서 저자들은 regularization term인 weigt decay coefficient의 값을 annealing하게 됩니다. (weight decay을 아예 없애는 것이 아닌!) 저자들은 learning rate에 cosine annealing scheduler를 사용할 뿐만 아니라 weight decay에 똑같은 scheduling을 적용하였다고 합니다. 추가적으로 (Exponential Moving Average)EMA와 progressive learning curriculum 방법을 추가하여 성능을 아래와 같이 높였다고 합니다.

EMA: training parameter들이 moving average를 유지시키는 방법으로 원래 잘 학습하던 방향에서 크게 벗어나지 않도록 함
Progressive learning: epoch이 증가할수록 input image size가 커지며 augmentation강도가 커지게 하여 점점 어려운 이미지의 특성을 학습하도록 하는 방법론

Ablation on various train settings for MobileOne-S2 showing Top-1 accuracy on Imagenet

2.5 Benchmarking

iPhone12으로 latency를 측정하는 데 있어서 모델 그 자체만 실행되는 시간을 측정하는 것은 불가능하다고 합니다. 그래도 최대한 모델의 latency를 정확히 측정하기 위해 아래와 같은 셋팅으로 실험 진행하였습니다.

Benchmarking하기 전에 model graph을 load하고 input tensor를 preallocate하였으며 model warmup을 한번 진행함
Benchmarking시에는 모델을 1000번 run하여 lowest, highest latency를 측정함
Benchmarking시에는 다른 모든 application은 종료하였음
모든 모델의 latency 측정 결과는 lowest latency임
- lowest latency가 다른 process의 interrupt를 받지 않았다고 가정하기 때문에 해당 결과로 표를 작성함

그리고 Desktop CPU latency도 측정하였는데 이는 Ubuntu desktop(2.3 GHz Intel Xeon Gold 5118 processor)에서 결과를 도출하였습니다.

3. Experiments

3.1 Image Classification on ImageNet-1K

실험셋팅은 다음과 같습니다.

300 epochs
256 batch sizes
SGD optimizer with momentum
Cross entropy loss with label smoothing (0.1 smoothing factor)
Initial learning rate 0.1 with cosine annealing scheduler
Initial weight decay 1e-4 and annealed to 1e-5 with cosine annealing scheduler
AutoAugmentation for MobileOne-S2, 3, 4
Standard augmentation for MobileOne-S0, 1
EMA weight averaging with decay constant of 0.9995

MobileOne의 성능 비교 및 결과는 아래와 같습니다. CNN기반의 모델과 Transformer계열 네트워크 모두와 비교하였습니다.

Performance of various models on ImageNet-1k validation set

Comparison of Top-1 Accuracy on ImageNe

3.2 Object detection on MS-COCO

SSDLite의 backbone을 MobileOne으로 변경하여 성능 비교를 하였습니다. Input resolution은 320x320이며 200 epochs 학습하였다고 합니다. (자세한 training configuration은 논문 참고 바랍니다!) 성능 측정은 MS COCO validation set을 사용하였으며 mAP@IoU 0.50:0.05:0.95 기준으로 하였습니다. 아래 backbone에 따른 성능 비교 테이블을 확인하였을 때 MobileOne의 퍼포먼스가 가장 뛰어남을 확인 가능합니다.

Quantitative performance of object detection on MS-COCO

3.3 Semantic Segmentation on Pascal VOC and ADE 20k

Deeplab V3의 backbone을 MobileOne으로 변경하여 semantic segmentation성능 비교를 하였습니다. VOC와 ADE 20k dataset에 대해 모두 50 epochs 학습하였으며 자세한 training configuration은 논문 참고 바랍니다) 성능 측정은 mean intersection-over-union (mIOU)기준으로 하였으며 아래와 같이 MobileOne이 좋은 성능을 내었습니다.

Quantitative performance of semantic segmentation on Pascal-VOC and ADE20k datasets

라인플러스 AI개발자 면접 및 이직 후기

Sin-Han Kang — Fri, 17 Jun 2022 00:43:48 +0900

1. 서론..

저는 고려대에서 석사를 마치고 스타트업 노타에서 전문 연구요원 복무를 시작하게 되었습니다. (석사기간에는 Explainable AI주제로 논문을 썼었고 노타에서는 On-device 경량화 플랫폼 서비스 개발을 하였습니다.) 그러다가 시간이 지난 후... 여러 가지 이유로 인해 이직을 결심하게 되었고 LINE PLUS의 AI 개발자로 이직을 하게 되었습니다. 그래서 LINE PLUS의 면접 프로세스와 이직에 대한 후기를 적어 보려고 합니다. (아래 내용에서 문제가 될 만한 내용이 있다면 댓글로 알려주세요!)

저는 서류전형 > 온라인 코딩 테스트 > Pre-test+1차면접 > 2차 면접 > 레퍼 체크 및 처우 협의 > 최종 합격의 프로세스를 거쳤습니다. AI개발자 또는 전문 연구요원으로 이직을 준비하시는 분들께 많은 도움이 되었으면 하고 다른 분들도 참고하시면 좋을 것 같습니다!

2. 서류전형

서류전형은 당연하게도 경력사항에 제가 속해있던 팀에서 어떤 일을 했는지 적었고 포트폴리오와 운영하는 블로그의 url을 첨부하였습니다.

"대표적인 프로젝트 세 가지를 적어 주시돼, 각각의 프로젝트에서 어떤 기술을 활용하여 어떤 방식으로 개발했는지 구체적으로 설명해 주세요."라는 직무 질문 있었습니다. 여기에 당연하게도 지원하는 직무와 관련된 내용으로 써 내려갔습니다. 한 프로젝트당 10~14줄 정도 적었던 것 같네요..

3. 온라인 코딩 테스트

LINE PLUS의 코딩 테스트는 조금 길었습니다. 3시간 30분이었습니다..(4시간이었나?) 총 4문제로 구성되어있었습니다.

저는 AI개발자다 보니 python을 많이 쓰기 때문에 python으로 코딩 테스트를 진행하였습니다.

저는 총 4문제 중 2문제를 맞히고 2문제는 풀긴 했는데 모든 테스트에 통과하지 못하였습니다. 못 푼 문제 각각에서 몇 개의 테스트는 통과하고 몇 개는 테스트를 통과하지 못했는데요. 모두 runtime error가 떠서.. 제 머리로는 왜 틀렸는지 1차 면접 볼 때까지 몰랐습니다. (1차 면접에서 면접관님이 왜 runtime error가 발생했는지 알려주셨답니다..ㅎㅎ 감사합니당 사이다...)

runtime error때문에 코딩 테스트 결과를 조마조마하며 기다렸고 결국 통과하였습니다!

4. Pre-test+1차 면접

Pre-test와 1차 면접은 온라인으로 진행되었습니다. Pre-test의 내용은 발설하면 안 될것 같아 말씀 못 드리지만 제 역량을 평가하기 위한 test였습니다.. 나름 석사 생활이 그리워지는 test였습니다.

1차 면접은 60분 동안 진행되었습니다. 1차 면접은 기술 면접으로 면접관님들은 3분이 들어오셨습니다. 제 자기소개를 하는 것을 시작으로 면접관님들도 자기소개를 친절하게 해 주셨습니다. 제가 쓴 이력서에 대한 내용 을 질문해주셨고 지원한 직무에 대한 이해도가 있는지에 대한 질문도 하셨습니다. 당연히 지원한 직무와 관련한 논문도 읽고 관련 블로그도 찾아보고 했기 때문에 생각보다 수월하기 답할 수 있었습니다.

그리고 제 블로그 내용에 대한 질문도 하시면서 주로 어떤 (AI) 분야에 관심이 있는 지 블로그 글에 대해 얼마나 이해하고 있는 지 물어보셨습니다. (모르는 것은 모른다고 말씀드렸습니다ㅎㅎ..)추가로 이직 사유와 지원 이유를 여쭤봐 주셨고 마지막으로 제가 하고 싶은 질문을 하면서 마무리하였습니다.

대체적으로 만족스럽게 잘 답변하였다고 생각하며 이번에도 좋은 결과를 기대하였습니다...!

5. 2차 면접

2차 면접 또한 60분으로 진행한다고 안내가 되었습니다. 2차 면접은 면접관 1분이 들어오셨고 기술+인성 면접 느낌이었습니다. 1차와 비슷하게 자기소개를 시작으로 이력서에 대해 간단한 질문을 해주셨습니다. 그리고 석사생활이나 직장생활하면서 겪은 문제점이나 해결방안을 얘기하면서 스무스 하게 진행하였습니다. 그리고 제가 궁금한 내용을 질문드리며 면접을 마무리하였습니다. (60분 예정이었던 면접은 30분만에 끝났습니다. ) 1차와 비슷하게 면접관님이 친절하고 잘 대해주셔서 편안하게 진행 할 수 있었던 면접이었습니다.

2차 면접에서 기술+인성 질문에 대해 답변을 자연스럽게 잘 하였다고 생각하였고 2~3일 뒤에 아래와 같이 합격 소식을 듣게 되었습니다. (2차 면접합격은 메일로 합격메일이 오기전에 인사 담당자 분이 전화가 오시더라고여..ㅎㅎ)

6. 레퍼 체크 및 처우 협의

2차 합격 후에 레퍼 체크를 진행하는데 이 과정에서 재직 중인 회사(노타)사람들이 많이 알게 되면서 눈치가 보였습니다... 그리고 레퍼체크까지 잘 마무리되고 처우 협의를 LINE PLUS 인사담당자분과 잘 진행하였습니다.

7. 최종합격

약 한달~한달반 정도 진행된 면접 프로세스를 통해 결국 최종합격되었고 LINER가 되었습니다.

마지막으로 제가 면접을 진행하면서 이직 할 때 중요하게 준비했던 것들은 아래와 같습니다! (개인적인 의견임을 알려드립니다.)

지원하는 직무와 지금 하고 있는 직무의 연관성이 있어야 함
지원하는 직무 에 대해 공부하고 알아보는 게 당연시 되어야함
- 지원하는 회사와 직무에 대해 잘 모르는 것으로 보이면 어떤 면접관도 좋아하지 않겟죠
이력서에 쓴 내용은 물론이고 관련된 방법론과 결과는 모두 정리정돈 되어 있어야 하고 잘 말할 수 있어야 함
"자기소개 > 이직 사유 > 해당 직무 지원이유 > 궁금한 점"이 스토리 텔링 되면 좋음
결국 면접은 (1) 면접관님이 질문한 내용을 잘 이해하고 (2) 그에 대한 대답을 설득력있게 전달하면 끝
- 설득력 있다는 것은 결국 내 생각(의견)과 함께 그에 알맞는 근거를 같이 말씀드리는 것이라 생각합니다!
만약 면접에서 떨어졌다면 왜 떨어졌는 지 자기분석하고 분석한 내용을 바탕으로 성장해야함

EfficientFormer: Vision Transformers at MobileNet Speed 논문 리뷰

Sin-Han Kang — Wed, 8 Jun 2022 15:00:15 +0900

2022년 Snap Inc. 에서 게재한 논문인 EfficentFormer 논문을 리뷰합니다.

1. Introduction

해당 논문은 주요 내용은 다음과 같습니다.

"Vision Transformer(ViT)가 high performance를 내면서 (mobile device에서) mobilenet만큼 빨라질 수 있을까"에 대한 의문점에서 시작
- 기본적으로 VIT는 accuracy 성능은 좋은데 lightweight CNN(e.g. MobileNet)보다 느리다는 단점을 가짐
그 의문점을 풀기 위해 기존 ViT의 inefficient한 구조에 대해 분석
Efficient한 구조를 갖는 dimension-consistent한 ViT 모델(EfficientFormer) 을 제안
- 특히나, 해당 논문은 FLOPs나 parameter수가 아닌 inference speed에 초점을 맞춤

위의 EfficientFormer 모델은 아래 그림에서 보이듯이 inference speed도 빠르면서 좋은 accuracy성능을 보임을 알 수 있습니다.

All models are trained on ImageNet-1K and inference speeds are measured by iPhone 12 with CoreMLTools

2. On-device Latency Analysis of Vision Transformers

기존 ViT의 구조중 어떤 operation이나 architecture가 on-device inference speed에 악영향을 주는지 확인하기 위해 실험 및 분석을 하였고 아래와 같은 4가지 observations을 확인하였습니다. 아래 그림은 iPhone12 device에서 latency profiling을 진행한 결과를 나타냅니다.

Latency profiling on iPhone 12 with CoreML. The accuracy is measured on ImageNet-1K. LeViT uses GeLU activation this is because HardSwish is not supported bty CoreML.

Observation 1: 큰 kernel과 stride를 갖는 patch embedding이 mobile device의 inference speed에 악영향을 줌.

Patch Embedding in ViT

위의 그림에서 Patch Embedding은 일반적으로 non-overlapping convolution layer로 구현되는데 non-overlapping하게 하기 위해 large kernel과 stride를 사용하게 됩니다. 하지만 대부분의 compiler에서는 large kernel convolution을 지원하지 않고 large kernel convolution은 기존의 acceleration algorithm(e.g. Winograd)으로부터 가속화 되지 않습니다. 위의 latency profiling그림에서 실제로 일반적인 transformer의 patch embedding이 inference하는데 시간을 많이 잡아먹는 것을 확인 가능합니다.

저자들은 기존의 non-overlapping patch embedding을 여러 개의 3x3 convolutions(hardware-efficient한 구조)으로 대체하여 모델을 design하겠다고 합니다.

Observation 2. token mixer의 선택에 consistent feature dimension이 중요하고 Multi-Head Self Attention(MSHA)이 주된 speed bottleneck아님.

Token mixer란 말 그대로 token간의 information을 섞는 역할을 하며 token mixer의 대표적인 예시로는 MSHA가 있고 아래 그림에서 보이듯이 transformer variant 논문들에서는 token mixer을 spatial MLP나 Pooling layer을 사용함을 알 수 있다.

Token mixer and its examples

저자들은 token mixer의 선택으로 머가 좋은 지 분석하기 위해 pooling과 MSHA를 비교 실험하였습니다. (token mixer을 shifted window attention을 사용한 논문이 있는데 해당 모듈은 대부분의 mobile compiler에서 지원하지 않는다고 하여 비교 안 하였음)

pooling을 사용하는 PoolFormer-s24, MSHA를 사용하는 LeViT-256를 비교
- LeViT는 4D tensor에 대해 Conv연산후, MSHA연산을 하는데 MSHA는 3D tensor에 대해 연산하므로 reshape이 빈번하게 필요함. 헌데 reshape연산이 inference speed의 bottleneck으로 작용(위의 latency profiling그림 참고!)
- PoolFormer는 4D tensor에 대해 Conv연산후 4D tensor대상으로 연산하는 Pooling을 사용하기 때문에 reshape이 필요 없고 결과적으로 PoolFormer가 LeViT보다 빠름
- 여기서, 4D tensor 연산에서 3D tensor연산으로 바뀌지 않고 그대로 4D에서 4D tensor연산하는 것을 "consistent feature dimension" 하다고 함
DeiT-S와 LeViT-256를 비교했을 때 3D연산을 하는 MSHA자체는 inference speed에 대해 큰 overhead를 가져오지 않음을 확인
- 오직 빈번한 reshape 연산이 없을 경우에만!

위의 분석을 통해서 token mixer선택에 있어서 consistent feature dimension을 유지하기 위해서 reshape operation을 거의 사용하지 않도록 하는 dimension-consistent network를 제안하게 됩니다. 제안하는 EfficientFormer는 token mixer선택에 있어서 4D tensor연산을 하는 pooling과 3D tensor연산을 하는 MSHA를 모두 사용하게 됩니다. (자세한 EfficientFormer의 내용은 뒤에서...)

Observation 3: Conv-BN이 LN(Layer Normalization)-Linear보다 latency-favorable하며 Conv-BN을 사용했을 경우 Accuracy drop이 acceptable함

기본적으로 Layer Normalization(LN)-Linear구조는 3D linear projection을 하게 되므로 MSHA와 같이 사용됩니다. 하지만 LN은 전체 network inference time 중 10~20% 정도를 차지하는 것을 위의 latency profiling 그림에서 볼 수 있습니다. 이는 LN이 inference를 잴 경우에 running statistics를 collect 해야 하기 때문에 생기는 시간입니다.

이에 반해, Conv-BN구조는 4D tensor에 대해 연산을 하고 inference시에 BN이 Conv구조에 folding 될 수 있으므로 latency를 낮추는 데 더 용이합니다. 하지만 Conv-BN은 LN-Linear보다는 "조금" accuracy성능이 낮게 나온다고 하네요.

그래서 EfficientFormer가 token mixer가 pooling일 때는 Conv-BN구조를 사용할 것이고 MSHA일 경우는 LN-Linear를 사용하도록 할 것입니다.

Observation 4: nonlinearity(activation function)의 latency는 hardware와 compiler에 의존적

"Towards efficient vision transformer inference: a first study of transformers on mobile devices." 논문에서는 GeLU가 hardware에 inefficient 하다고 했지만 실제로 저자들이 iPhone12에서 실험해봤을 때 GeLU가 ReLU만큼 느리지 않다는 것을 확인하였습니다. 반대로, HardSwish는 iPhone12에서 느린 것을 확인하였습니다. (LeViT-256에서 HardSwish 사용 시: 44.5ms, GeLu사용 시: 11.9ms)

그래서, EfficientFormer에서는 GeLU을 사용합니다.

3. Design of EfficientFormer

EfficientFormer 구조.

위의 observations을 기반으로 저자들은 EfficientFormer을 제안하게 됩니다. EfficientFormer는 patch embedding($PatchEmbed$)와 여러 개로 쌓은 meta block($MB$)로 구성됩니다.

\[
Y = \prod^m_i MB_i (PatchEmbed(X^{B,3,H,W}_0 )). \quad Eq.(1)
\]

$X_0$: Input image
- $B$, $H$, $W$: Batch size, Height, Width
$Y$: Output
$m$: transformer block 총 개수

그리고 $MB$는 token mixer($TokenMixer$)와 $MLP$ block으로 표현됩니다.

\[
X_{i+1} = MB_i (X_i) = MLP(TokenMixer(X_i)). \quad Eq.(2)
\]

여기서 $X_{i | i >0 } $은 $i^{th} MB$으로부터 forward된 intermediate feature를 뜻합니다.

추가로 저자들은 Stage($S$)를 정의하였는데요. Stage는 여러개의 MetaBlock들로 구성되어 있고 각 Stage는 같은 spatial size를 가지며 각 Stage가 가진 MetaBlock의 수를 $N_i \times$로 표현한다고 하네요. 총 stage개수는 4개이며 각 stage 사이마다 embedding operation($Embedding$)이 있습니다. Embedding operation은 embedding dimension으로 project시키기 위함과 token 길이를 downsample하기위해 사용됩니다.

아래부터는 EfficientFormer의 상세한 구조 디자인 설명을 드리도록 하겠습니다.

3.1 Dimension-consistent Design

Section 2에서 말씀드린 observation을 통해 dimension consistent design을 제안하게 됩니다. 위의 그림에서 보이듯이 4D partition부분과 3D partition부분으로 나누는데 처음에는 4D partition으로 stage를 시작하고 마지막부분에 3D partition부분을 수행하여 reshape연산을 최소화하여 dimension consistent design을 구성하게됩니다.

4D partition: $MB^{4D} $로 표현되며 Conv-net style과 token mixer로 pooling layer 사용하여 구현
3D partition: $MB^{3D} $로 표현되며 linear projection과 token mixer로 MSHA 사용하여 구현

위의 EfficientFormer구조 그림은 예시일 뿐이며 실제 4D, 3D partition길이는 NAS를 통해 찾는다고 합니다!

먼저 , input image는 patch embedding에 의해 processing된다고 말씀드렸는데 observation 1에 근거하여 patch embedding은 2개의 3x3 convolution(stride 2)으로 구현됩니다.

\[
X_i^{B,C_{j|j=1}, \frac{H}{4}, \frac{W}{4} } = PatchEmbed(X^{B,3,H,W}_0). \quad Eq.(3)
\]

$C_j$는 j-th stage의 channel 수를 의미합니다. 그다음으로 $MB^{4D} $는 $Pool$ mixer를 사용하여 다음과 같이 표현됩니다.

\[
\begin{array}{l} I_i = Pool(X_i^{ B,C \frac{H}{2^{j+1}},\frac{W}{2^{j+1}}}) + X_i^{ B,C \frac{H}{2^{j+1}},\frac{W}{2^{j+1}}} \cr X_i^{ B,C \frac{H}{2^{j+1}},\frac{W}{2^{j+1}}} = Conv_B(Conv_{B,G} ( I_i ) ) + I_i \end{array} \quad Eq.(4)
\]

$ Conv_{B,G} $는 연속된 Conv-BN-GeLU을 의미합니다. $MB^{4D} $ block 연산후에는 한번의(one-time) reshape 연산으로 4D에서 3D로 feature dimension을 변경합니다. 해당 feature를 입력으로 $MB^{3D}$는 다음과 같이 연산합니다.

\[
\begin{array}{l} I_i = Linear(MSHA(Linear(LN(X_i^{B, \frac{HW}{4^{j+1}},C_j})))) + X_i^{B, \frac{HW}{4^{j+1}},C_j}, \cr X_i^{B, \frac{HW}{4^{j+1}},C_j} = Linear(Linear_G(LN(I_i))) + I_i \end{array} \quad Eq.(5)
\]

$Linear_G$는 Linear-GeLU를 의미하고 MSHA연산은 다음과 같다.

\[
MSHA(Q,K,V)= Softmax(\frac{Q \cdot K^T}{\sqrt C_j } +b ) \cdot V. \quad Eq.(6)
\]

$Q, K,V$는 각각 query, key, value를 뜻하며 linear projection으로부터 학습되는 variable이다. 또한 $b$는 parameterized attention bias로 position encoding역할로 사용된다.

3.2 Latency Driven Slimming

3.2.1 Design of Supernet

dimension-consistent design을 하기위해 저자들은 supernet으로부터 architecture search를 하는 NAS방법을 사용한다. Supernet는 다음과 같은 MetaPath($MP$)을 정의하여 구성됩니다.

\[
\begin{array}{l} MP_{i,j=1,2} \in \{ MB^{4D}_i , II_i \}, \cr MP_{i,j=3,4} \in \{ MB^{4D}_i , MB^{3D}_i II_i \}. \end{array} \quad Eq.(7)
\]

여기서 $ II $은 identity path을 의미하고 $j$는 $j^{th}$ stage, $i$는 $i^{th}$block을 의미한다. 즉, supernet의 training시에 stage 1,2에는 $MB^{4D}_i$ 또는 $II_i$이 선택될 수 있는 것이고 stage 3,4에는 $MB^{4D}_i$, $MB^{3D}_i$ 또는 $II_i$이 선택 가능하다는 것이다.

여기서 stage 3,4에서만 $MB^{3D}_i$ 이 추가된 이유는 아래와 같다.

MSHA는 token 길이에 따라 quadratic(4배)하게 computation cost가 커지므로 상대적으로 token 길이가 작은 뒤쪽의 stage를 사용
초기 stage에는 low-level feature를 학습하고 마지막 stage들은 long-term dependencies을 학습한다는 측면에서 뒤쪽의 stage에 MSHA를 적용하는 게 옳음

3.2.2 Search Space

$C_j $: 각 stage의 channel 수
$ N_j$: 각 stage의 block의 수
$\mathcal{N} $: $MB^{3D}$에 적용할 마지막 block수

3.2.3 Search algorithm

NAS에서는 supernet을 학습을 완료하고 나면 어떤 path(subnet)가 best인지 찾는 search algorithm이 필요합니다. 저자들은 supernet의 학습이 완료되면 바로 어떤 path가 best인지 알 수 있는 efficient한 gradient-based search algorithm을 제안합니다.

해당 search algorithm은 3가지 step을 수행합니다.

(1) supernet training시에 Gumble Softmax sampling을 함께 사용하여 선택된 $MP$의 importance score을 측정합니다.

\[
X_{i+1} = \sum_n \frac{e^{ ( \alpha^n_i + \epsilon^n_i )} / \tau }{\sum_n e^{ ( \alpha^n_i + \epsilon^n_i ) / \tau }} \cdot MP_{i,j} \cdot (X_i). \quad Eq.(8)
\]

$\alpha$는 trainable parameter로 MP의 importance score를 나타내고 해당 block이 선택될 확률을 뜻한다. $ \epsilon \sim U(0,1)$은 exploration역할을 하게 되고 $ \tau$는 temperature, $n$은 선택 가능한 block은 type을 의미한다.

(2) 16배수로 나누어진 channel(width)들을 가지는 여럿 $MB^{4D}$와 $MB^{3D}$의 on-device latency lookup table을 구축한다.

(3) single-width를 가지는 supernet기준으로 채널 수를 조절하는 gradual slimming 을 진행한다.

supernet를 구성할 때 각 MP에 대해 여럿 다양한 channel(width) 수 path가 없었는데 그 이유는 저자들은 single-width supernet구조에서 channel수를 줄이는 작업을 진행하였다. (이는 여럿 다양한 channel수에 대한 search도 supernet training시에 할 경우 memory-consuming이 크기 때문)

Gradual slimming은 다음과 같이 수행됩니다.

$S_{1,2}, S_{3,4}$의 각 $MP_i$에 대해 importance score을 $ \frac{\alpha^{4D}_i}{\alpha^I_i}, \frac{\alpha^{4D}_i+ \alpha^{3D}_i}{\alpha^I_i} $로 정의
각 stage에 대한 importance score를 구하기 위해 각 stage안에 포함되는 $MP_i$의 importance score를 summation
다음 3가지 옵션에 대해 action(수행)해보면서 per-latency accuracy drop $ \frac{- \%}{ms}$을 기준으로 3개 중 1개의 옵션을 취함
1. Option 1: 가장 낮은 importance score를 가지는 $MP$에 대해 $II$)(identity)를 선택
2. Option 2: 첫 번째 $MB^{3D}$를 제거
3. Option3: 가장 낮은 importance score를 가지는 $MP$에 대해 channel수를 16으로 나눔 (16으로 나눈 $MP$에 대해 latency lookup table이 존재하므로 해당 latency 사용)

위의 gradual slimming에 대한 algorithm은 아래를 참고하시면 됩니다.

gradual slimming algorithm

위의 graudal slimming을 수행 완료하여 최종 선택된 EfficientFormer 구조는 아래와 같습니다.

4. Experiments and Discussion

저자들은 PyTorch 1.11과 Timm library를 통해 EfficientFormer를 구현하였고 mobile speed는 A14 bionic chip이 장착되고 NPU사용이 가능한 iPhone12에서 1000번 inference하고 평균을 내어 결과를 내었다고 합니다. CoreMLToolssms run-time model을 deploy하기 위해 사용하였습니다.

4.1 Image classifciation

ImageNet-1K dataset에 대해 실험하였고 300 epochs 학습 기준으로 결과를 비교하였습니다. EfficientFormer는 AdamW optimizer를 사용하였으며 5 epochs의 warm-up training과 consine annealing scheduler적용하였습니다. 또한 initial learning rate는 $10^{-3} \times (batch sizze / 1024) $, minimum learning rate는 $10^{-5}$이며 distillation을 위한 teacher model을 RegNetY-16GF(82.9% top-1 accuracy on ImageNet-1k)으로 설정하였습니다.

EfficientFormer results in ImageNet-1K

4.2 EfficientFormer as Backbone

Detection이나 segmentation task에서도 performance가 뛰어난지 확인하기 위해 EfficientFormer를 backbone으로 사용하였습니다. Mask-RCNN에 EfficientFormer을 combine하였고 COCO-2017 dataset기준으로 결과를 측정하였습니다. EfficientFormer의 weight는 ImageNet-1K pretrained weight로 initialization하였고 AdamW optimizer와 initial learning $ 1 \times 10^{-4} $을 사용하였고 12 epochs만 학습했다고 합니다.

EfficientFormer results in COCO 2017

Python (2) Dict와 Set 차이

Sin-Han Kang — Sun, 22 May 2022 21:00:29 +0900

Dict과 Set은 특정 데이터를 unique하게 참조할 수 있는 별도 객체가 있는 자료구조입니다. 데이터를 참조하는 일명 참조 객체는 키(key), 데이터를 '값(value)'이라고 한다. (Set에서 key-value쌍이 없고 참조 객체 key만 있습니다.) 하나의 참조하는 객체 키는 일반적으로 문자열을 사용하지만 hashable하다면 어떤 타입이든 상관없습니다.

hashable 타입은 __hash__ 매직함수 그리고 __eq__또는 __cmp__ 매직함수를 구현한 타입입니다. 파이썬 내부 타입은 모두 매직함수가 구현되어져 있다.

Dict과 Set은 모두 유일한 키를 가지므로 주어진(찾고싶은) 색인(객체)을 O(1) 시간복잡도로 찾을 수 있습니다. (리스트는 선형탐색의 경우 O(n)이 걸리는데 말이죠) 그래서 주어진 색인을 빠르게 찾을 수 있다는 것인 Dict과 Set의 특징점이자 장점입니다. 하지만 Dict과 Set은 메모리를 많이 사용하고 hash함수에 의존적이므로 hash 함수가 느리다면 Dict과 Set연산도 느려질 수 있다는 단점을 가집니다.

1. Dict과 Set의 차이

Dict과 Set의 차이는 Set에서는 값(Value)이 없다는 점이다. 즉, Set은 유일한 키를 저장하는 자료구조이며 이는 집합 연산에 유용하다는 것을 의미합니다.

프로그래밍적으로는 다음과 같은 선언 차이가 있습니다.

a = {1: 'a', 2: 'b'} #Dict
b = {1,2,'a','b'} #Set

위에서 알수 있듯이 Set과 Dict모두 중괄호({ })로 정의 되지만 key와 value쌍으로 정의되면 dict type을 가지고 key만 주어지면 set type을 가집니다. (마지막에 보이듯이 빈 중괄호(c={})는 dict type으로 정의됩니다.)

2. Dict과 Set의 동작 원리

파이썬 내부적으로 Dict과 Set의 동작원리에 알고싶다면 계속 읽으시면 좋을 것 같습니다!

위에서 말씀드렸듯이 Dict과 Set은 모두 hashtable을 사용한다고 말씀드렸습니다. 좀 더 구체적으로 hashtable이 어떻게 사용되는 지 알 아보죠.

Dict의 hashtable은 key, value, hash 을 (메모리에) 저장합니다.
Set의 hashtable은 key, hash을 (메모리에) 저장합니다.

hash값은 어떻게 계산되는지부터 알아보면 hash값은 key 데이터를 입력으로 hash function의 결괏값을 의미합니다. 여기서 중요한 점은 우리가 입력할 수 있는 수 만 가지(실제로 더 많죠 ㅎ) key값이 있을 텐데... 이 수만 가지의 key값을 입력으로 서로 다른 hash값을 내뱉을 수 있어야 합니다. (이를 만족하는 것을 최소 충돌이라 합니다.) key의 고유한 hash값이 존재해야 O(1) 시간 복잡도로 색인 탐색이 가능하니까요!

실제로 hash function을 거친 output값(hash 값)과 mask와의 연산을 해야 하는데 해당 부분 내용이 많아질 거 같아 생략합니다. 간단하게 말씀드리면 mask는 hash 값이 할당된 메모리 블록의 수보다 작아지도록 조정하는 데 사용됩니다.

그래서 해시 함수는 entropy(엔트로피)가 커지도록 설계해야합니다. entropy는 불확실성을 의미하니 불확실성이 클수록 고르고 균일한 분포의 hash값을 만들어 낼 것입니다. (entropy에 더 궁금하시면 구글링 해보세요 Machine Learning하시는 분이라면 다 이해하실거라 생각하며 저는 넘어갑니다) 그리고 엔트로피가 최대가 되는 hash fucntion은 최소 충돌을 보장하며 Complete hash function이라 합니다.

이제는 hash table이 데이터를 어떻게 저장하는지 알아보죠! 그러려면 옛날 버전 python의 hash table 구조부터 알아보죠. (Dict에 대한) 연속된 메모리 주소에 hash, key, value를 저장하는 것을 보실 수 있죠.

--+-------------------------------+
  |    hash       key     value
--+-------------------------------+
0 |    hash0      key0    value0
--+-------------------------------+
1 |    hash1      key1    value1
--+-------------------------------+
2 |    hash2      key2    value2
--+-------------------------------+
. |           ...
__+_______________________________+

그리고 다음과 같이 dictionary를 정의하였다면

my_info = {'name': 'sinhan', 'birth': '1995-06-23', 'gender': 'male'}

hash table은 다음과 같이 데이터를 저장합니다.

entries = [
    ['--', '--', '--']
    [-230273521, 'birth', '1995-06-23'],
    ['--', '--', '--'],
    ['--', '--', '--'],
    [1231236123, 'name', 'sinhan'],
    ['--', '--', '--'],
    [9371539127, 'gender', 'male']
]

위에서 아시겠지만 index 0, 2, 3, 5번 index에는 ['--', '--', '--'] 와 같이 불필요한 데이터가 저장되고 있습니다. 이는 hash table의 데이터 저장이 비효율 적인 것을 알 수 있습니다. (실제로는 index가 더 많을 것이니 해당 문제가 더 심각해지겟죠!)

그래서 현재 pyhton은 index와 (hash, key, value)을 분리시켜 메모리 효율성을 올렸습니다.

Indices
----------------------------------------------------
None | index | None | None | index | None | index ...
----------------------------------------------------

Entries
--------------------
hash0   key0  value0
---------------------
hash1   key1  value1
---------------------
hash2   key2  value2
---------------------
        ...
---------------------

그래서 위 예제의 hash, key, value값은 아래와 같이 효율적으로 저장됩니다.

indices = [None, 1, None, None, 0, None, 2]
entries = [
    [-230273521, 'birth', '1995-06-23'],
    [1231236123, 'name', 'sinhan'],
    [9371539127, 'gender', 'male']
]

그래서 index 1, 4에 해당하는 [hash, key, value]는 각각 [1231236123, 'name', 'sinhan'], [-230273521, 'birth', '1995-06-23']이 되겠죠. 이를 통해 hash table의 데이터 저장 구조도 알아보았습니다.

Python (1) List와 Tuple 차이

Sin-Han Kang — Fri, 20 May 2022 12:57:57 +0900

Machine learning이 대부분 python기반이다 보니 python을 더 정진하면 좋겠다는 생각에 시작합니다. 가시죠!

List와 Tuple은 배열이라는 자료구조 특성을 가집니다. 아래 그림은 배열이 메모리에 할당되는 방식입니다. 배열이 연속적인 메모리에 정렬되있음을 알 수 있다.

배열이란? 정해진 고유의 순서에 따라 데이터를 나열한것을 말합니다. 순서가 있기 때문에 배열 내 특정 위치의 데이터를 O(1) 시간 복잡도로 접근 가능합니다.

배열 메모리 할당 방식

그래서 시작주소를 알고 있고 순서에 따라 나열되어있기 때문에 특정 위치의 데이터에 바로 접근가능합니다. 예를 들어 3번째 위치의 데이터에 접근하고 싶으면 0x06에서 2칸떨어진 0x08위치의 값을 읽으면 됩니다.

그렇다면 List와 Tuple의 차이는 멀까?

List: 저장하는 데이터나 배열 크기를 변경할 수 있는 동적 배열
Tuple: 내용이 고정된 변경 불가능한 정적 배열

1. List

List는 동적 배열임을 기억하자! 그래서 저장 용량을 늘리거나 줄일 수도 있다. 추가적으로 수정이 가능하다는 것이 특징입니다.

수시로 데이터가 변경되거나 추가되고 삭제되는 내용을 나타내려면 리스트를 사용해야 합니다.

a = [1, 'a', 2, 'b']
a.append(3)

위의 코드에서 보이듯이 list는 대괄호([ ])로 선언 가능하며 데이터 타입을 섞어서 사용할 수 있고 (뒤에서 말하겠지만 물론 tuple도 가능하다) append함수로 데이터를 추가 가능합니다. 이는 동적 배열이 배열의 크기를 변경하는 resize 연산을 지원하기 때문입니다.

특징점은 배열의 크기가 $N$일때 1개의 요소가 더 추가될 때 배열의 크기가 $N+1$이 되는 것이 아니라 나중을 위한 여유분으로 $N$보다 큰 $M$만큼의 메모리를 할당한다. 이는 데이터가 추가될 때마다 메모리 할당과 복사 요청을 줄이기 위함이에요. (복사 비용이 큽니다!)

다음은 파이썬 3.7기준으로 리스트 크기 할당 방정식이에요. 해석하자면 $N$이 현재 리스트 안의 데이터의 개수(크기)이고 $M$은 해당 리스트의 할당된 메모리 크기이다.

M = (N>>3) + (3 if N < 9 else 6)

# N | 0 | 1-4 | 5-8 | 17-25 | 26-35| ... | 991-1120|
# M | 0 |  4  |  8  |   25  |  35  | ... |   1120  |

예를 들어 현재 리스트 크기가 4이고 하나의 데이터를 더 추가하게 되면 8개의 메모리 크기를 가진 새로운 리스트를 생성하게 됩니다! (만약 우리가 데이터를 991개만 사용하는 리스트를 반복적으로 새로운 변수에 할당하는 프로그램이 있다면 사실상 각 변수는 메모리를 1120개 데이터를 사용하는 것과 같으므로 리스트를 사용할때는 조심해야하는 부분이다. 손해다..ㅠ)

2. Tuple

Tuple은 정적 배열이며 내용을 바꾸거나 크기를 변경하지 못합니다. Tuple은 소괄호('( )')로 선언가능합니다.

b = (1, 'a', 2, 'b')
b[1] = 'c' # error

위와 같이 Tuple이 크기를 변경할 순 없어도 두 개의 튜플을 새로운 튜플로 합칠 수 있습니다. 이는 정확히 합친 만큼의 메모리를 할당하는 것이기 때문에 List와 달리 여유공간 메모리를 주지 않습니다.

b1 = (1,2,3,4)
b2 = (5,6,7,8)
b3 = b1 + b2 # b3 is (1,2,3,4,5,6,7,8)

그래서 Tuple이 정적인 데이터를 쓸 때(e.g. 주민등록번호, 여권번호) 더 가볍고 효과적입니다.

그리고 정적이기 때문에 파이썬이 내부적으로 수행하는 리소스 캐싱이 가능하다는 것이 특징입니다. 파이썬은 Garbage Collection(GC)을 통해 더 이상 사용되지 않는 변수에 할당된 메모리를 반환해 해제합니다. 하지만 크기가 20이하인 Tuple은 크기별로 최대 2만개(e.g. 크기가 1인 tuple 2만개, 2인 tuple 2만개, ....)까지 즉시 해제하지 않고 나중을 위해 저장해둡니다. 그래서 나중에 다시 필요해지면 OS에서 메모리를 새로 할당받지 않고 기존에 할당해둔 메모리를 재사용합니다.

아래는 캐싱의 차이를 보여주기 위해 list와 tuple 차이 예시입니다.

timeit모듈은 작은 python code의 execution time을 측정하는 것입니다. 위 그림으로부터 List와 Tuple의 할당을 100,000번 실행한 결과를 볼 수 있습니다. List는 100,000번 운영체제에서 새롭게 메모리를 할당받아 실행하고 해제하는 것을 반복하지만 Tuple은 한번 메모리를 할당하고 해제하지 않기 때문에 바로 캐싱을 통해 메모리를 재사용합니다. 그래서 속도 차이를 보면 Tuple이 List보다 약 6배 빠른 것을 볼 수 있습니다.

Learning Features with Parameter-free Layers 논문 리뷰

Sin-Han Kang — Thu, 28 Apr 2022 10:01:50 +0900

이번에는 ICLR 2022에 accept된 Naver clova 논문인 Learning Features with Parameter-free Layers 을 리뷰하도록 하겠습니다. 해당 논문은 accuracy성능은 유지하면서 latency을 상당히 줄일 수 있는 (operation)layer를 제안하는 데 기여하였습니다.

1. Introduction

기존의 많은 논문들이 efficient한 operation 또는 layer들을 제안하였습니다. 여기서 efficient의 의미는 accuracy성능은 향상시키거나 유지하면서 적은 parameter와 낮은 latency를 도달할 수 있다라는 것입니다. (기존의 efficient한 operation 또는 layer는 뒤에서 더 자세히 설명드리겠습니다.)

해당 논문은 기존 논문들에서 제안한 operation 또는 layer의 단점을 보완할 수 있는 operation(layer)을 제안하게 됩니다. 그래서 parameter를 사용하지 않는 parameter-free operation을 제안합니다. 제안한 parameter-free operation을 적용했을 때 trainable layers을 사용했을 때만큼의 accuracy 성능을 도달할 수 있는 지 많은 실험하였고 증명하였습니다.

더하여 제안한 Parameter-free operation이 search space에 포함되었을 때 Neural Architecture Search(NAS)에서 해당 operation이 잘 찾아지는 지 보아 제안한 operation의 효용성을 판단하였습니다.

2. Preliminaries

해당 논문에서 제안한 parameter-free operation을 설명하기전에 알아야할 기본적인 convolution layer(or block)부터 기존 논문들에서 제안한 efficient한 layer까지에 대해 설명드리겠습니다.

2.1 Basic block

2.1.1 Convolution layer

기본적인 convolution operation은 matrix multiplication으로 표현가능합니다. $f \in \mathcal{R}^{c_{in} \times H \times W} $을 input feature, kernel size $k$, stride $s$가 주어 질 때 convolution operation은 다음과 같습니다.

\[
y_{o, i, j} = \sigma ( \sum^{ \lfloor k/2 \rfloor}_{ h,w = - \lfloor k/2 \rfloor } \sum^{ c_{in} }_{u=1} W_{o, u, h, w} \cdot f_{u, r*i+h, r*j+w} ), \quad Eq. (1)
\]

위에서 $W$는 weight matrix를 의미하고 $ \sigma $는 activation function(e.g. ReLU)을 의미합니다. 여기서는 BN layer는 표현하지는 않았습니다.

2.1.2 Bottleneck block

Bottleneck block부터는 efficiency를 목적으로 제안된 것입니다. 아래의 그림과 같이 conv 1x1 operation을 통해 채널 수를 줄인 다음 conv3x3 operation을 진행하는 것이 1x1 conv없이 홀로 큰 채널을 가지고 conv 3x3 operation을 수행하는 것보다 효율적(efficiency)임을 보여줍니다.

Bottleneck block

위의 bottleneck block을 수식적으로 표현하면 다음과 같습니다.

\[
y_{o, i, j} = \sigma ( \sum^{ \rho c_{in} }_{v=1} P_{o,v}\cdot \sigma ( \sum^{ \lfloor k/2 \rfloor}_{ h,w = - \lfloor k/2 \rfloor } \sum^{ \rho c_{in} }_{u=1} W_{v, u, h, w} \cdot g_{v, r*i+h, r*j+w} )), \quad Eq. (2)
\]

여기서 $ g_{v, r*i+h, r*j+w} = \sigma ( \sum^{c_{in}}_{u=1} Q_{o,u} \cdot f_{u,i,j} ) $, 행렬 $ P $와 $Q$는 1x1 convolution의 weight를 의미한다. 1x1 conv에서 height, width은 유지한채 오직 output channel수를 $\rho c_{in}$만큼으로 줄이도록 하여 3x3 conv가 처리해야할 channel연산을 줄이게 됩니다. 그래서 해당 bottleneck 구조에서 efficiency는 3x3 conv에서 연산해야할 channel개수인 $\rho c_{in}$으로 결정됩니다. 저자들은 efficiecny가 오직 $\rho c_{in}$으로 결정된다는 것을 문제점으로 삼습니다.

2.2 Efficient Building Blocks

2.2.1 Inverted Bottleneck

bottleneck구조안에 depthwise convolution을 추가한 구조인 inverted bottleneck은 기존 bottleneck의 3x3 conv가 depthwise로 변경되면서 채널에 대한 연산수가 줄게 되고 accuracy성능은 높아집니다. 추가적으로 기존과 다르게 적은 channel수의 feature map을 입력으로 1x1 conv로 channel수를 늘리게 되고 그 다음 depthwise conv를 거친다는 특징을 가집니다.

Inverted bottleneck을 수식적으로 표현하면 아래와 같습니다.

\[
y_{o, i, j} = \sigma ( \sum^{ \rho c_{in} }_{v=1} P_{o,v} \cdot \sigma ( \sum^{ \lfloor k/2 \rfloor}_{ h,w = - \lfloor k/2 \rfloor } W_{v, h, w} \cdot g_{v, r*i+h, r*j+w} )), \quad Eq. (3)
\]

수식에서 알수 있듯이 Eq (2)와 다르게 channel에 대한 summation 연산이 제거되었습니다. 이 작은 차이가 generalization 효과를 더 극대화 시켜 좋은 성능을 얻은것입니다. 해당 inverted bottleneck도 efficient하지만 narrow에서 wide로 갈때 channel수가 늘어나는 정도(expansion ratio)에 따라 efficiecny가 결정된다는 문제점은 여전히 똑같습니다.

2.2.1 Variants of Inverted Bottleneck

Inverted Bottleneck보다 더 효율적인 layer또는 module을 제안한 기존 논문들은 다음과 같습니다.

VersatileNet: 기존의 conv를 여러개의 convolutional filter로 구성된 filter로 교체
GhostNet: 기존 layers들을 regular conv와 추가적인 depthwise conv의 concatenate로 교체
EfficientNetv2: pointwise와 depthwise conv를 하나의 regular conv로 fusing시킴
ShiftNet: depthwise operation을 shift operation으로 대체함

ShiftNet의 수식은 다음과 같습니다.

\[
y_{o, i, j} = \sigma ( \sum^{ \rho c_{in} }_{v=1} P_{o,v} \cdot \sigma ( \sum^{ \lfloor k/2 \rfloor}_{ h,w = - \lfloor k/2 \rfloor } W_{v, h, w} \cdot g_{v, r*i+h, r*j+w} )), \quad Eq.(4)
\]

해당 수식에서 Eq (3)과 다른점은 여기에서 $W_{v, h, w}$은 각 채널 $v$에 대해 $h$와 $w$가 1과 0의 값을 가진다는 것이다. 해당 operation을 shift라 명칭하였으며 해당 shift operation은 parameter-free으로 즉, parameter를 사용하지 않는다는 efficiency를 가진다. 하지만 문제점으로는 여전히 expansion ratio가 커야 accuracy성능이 보장되고 실제로 해당 operation을 구현했을때 최적화 되지 않음을 보였다고 합니다. (CUDA 구현에서도 똑같이 최적화 안된다고 하네여)

3. Efficient Building Block with Parameter-free operations

이제부터 논문에서 제안한 parameter-free operation에 대해 설명드리도록 하겠습니다.

3.1 Motivation

기존 연구에서 ResNet의 layer들은 학습에 기여하지 않기 때문에 해당 layer들을 제거해도 된다는 사실을 근거하여 저자들은 기존 residual block중 몇 개를 parameter free operation으로 대체하기로 합니다.

3.2 Rethinking parameter-free operations

ShiftNet의 Eq (4)는 그저 $W_{v, h, w}$을 1또는 0의 값으로 할당하였는데요. 본 논문에서는 그렇게 하지 않고 함수 $ s(\cdot) $을 제안 및 적용하여 $W$가 feature map $g $의 의존성을 가지도록 합니다. (i.e., $ W_{v, h, w} = s(g_{v, r*i+h, r*j+w} ) $)

여기서 의존성을 가지게 하기 위해 함수 $s(\cdot) $는 각 channel $v$에 대해 모든 $h$, $w$ 범위 안에서 feature map $g$의 가장 큰값만 취하도록 하였습니다. 마치 impulse 함수처럼 말이죠. 수식적으로 표현하면 $ W_{v,h^{\ast},w^{\ast}}= 1 $ , $(h^{\ast}, w^{\ast}) =argmax_{ (h,w) } g_{v, r*i+h, r*j+w} $ 이며 다른 이외의 $ W_{v,h,w} $ 의 값은 0으로 할당합니다. 실제로 함수 $s$는 max pooling layer으로 대체하여 사용하였다고 합니다.

즉, parameter-free을 만족시키며 feature map의 의존성을 고려한 operation을 제안하는 것입니다.

3.3 Empirical Studies

3.3.1 On a Single Bottleneck

ResNet의 하나의 bottleneck block에 대해 제안한 parameter-free operation을 사용했을 때 효용성이 있는 지 실험하였습니다. 다음과 같은 서로 다른 조건으로 학습시킨 모델들의 성능을 비교합니다.

Channel expansion ratio: [0.25, 0.5, 1.0, 2.0]
Base channel width: [32, 64]
Optimizer: [SGD, AdamW, AdamP]
비교 operation: [conv, dwconv, max]
- max: 논문에서 제안한 Parameter-free operation

즉, 4x2x3x3=72개의 모델을 비교했을때 아래와 같은 결과를 보았습니다.

Single bottleneck study for top-1 accuracy

위의 결과에서 알 수 있듯이 channel expansion ratio가 작을때 regular conv와 parameter-free operation이 거의 비슷한 성능을 냄을 알 수 있다는 것을 보여주었다. 이는 parameter-free가 regular conv를 대체가능하다는 것을 의미한다.

3.3.2 On Multiple Bottlenecks

이번에는 여러개의 bottleneck에 parameter-free operation을 적용했을때도 효과적인지 검증하는 실험입니다. ResNet-26기반으로 depthwise conv와 parameter-free operation을 비교하였다고 합니다.

Multiple bottlenecks study

결과적으로 비슷한 top-1 accuracy를 보이지만 inference speed차이에 있어서 parameter-free operation이 월등히 빠름을 보여주고 있습니다. (parameter 수와 FLOPs는 비슷하지만요!)

3.3.3 On Neural Architecture Searches (NAS)

NAS의 search space에 parameter-free operation을 넣었을때 해당 operation이 search되는지 확인하고 성능을 검증하는 실험입니다. 실험을 위해 DARTS라는 NAS방법을 사용하였으며 CIFAR10 dataset에 대해 진행하였습니다. 실험 환경은 다음과 같습니다.

모든 normal cell을 각각 찾도록 하였음.
DARTS의 operation search space를 아래와 같이simplify시킴
- search space: [MAX_POOL 3x3, AVG_POOL 3x3, CONV 1x1, CONV 3x3, DW_CONV 3x3, ZERO, SKIP_CONNECT]
- simplify시켜도 위의 operation들의 조합으로 DARTS의 operation search space를 만들수 있으므로 이렇게 진행
search를 3번을 진행하여 지속적으로 parameter free operation이 선택되는 지 확인

3번 search했을 때 모두 normal cell에 parameter-free operation(max pooling)이 선택되었음을 알 수 있고 DARTS와 유사한 결과인 첫번째 행과 비교했을때도 성능이 비슷함을 볼 수 있다. 또한 재밌는 것은 node의 수가 증가할 수록(모델이 커질 수록) parameter-free cell이 많이 선택됨을 알 수 있다. 즉, NAS에서도 parameter-free operation이 효과적으로 사용될 수 있음을 알 수 있다.

4. Designing Efficient Deep Neural Networks

위에서 parameter-free operation의 효용성은 실험적으로 확인하였으니 이제 CNN과 ViT에서 parameter-free operation이 들어간network design을 해보죠.

4.1 Efficient CNN Architecture

4.1.1 Hybrid Architecture with Efficient Bottlenecks

기존의 연속적인 3x3 conv, BN와 ReLU 연산을 parameter-free operation인 max pool operation으로 대체시켜 공간적인(spatial) feature를 추출하도록 한다. Base가 되는 모델은 ResNet50이며 기존의 bottleneck과 max pool operation이 들어간 efficient bottleneck의 조합으로 새로운 모델을 제안한다.

위의 NAS실험에서 알 수 있듯이 normal cell에서만 parameter-free operation이 사용되었으므로 여기서도 downsampling block이 아닌 오직 normal block에만 parameter-free operation이 사용되도록 하였습니다. 해당 모델을 Hybrid architecture라고 명칭하네요!

4.1.2 Architecture Study

ResNet50을 기준으로 efficient block을 여러가지의 경우의 수로 나누어 실험했을 경우 측정한 accuracy, latency 성능을 비교하였습니다.

Model Study on ResNet50

$ B \rightarrow B \rightarrow B \rightarrow B $는 regular bottleneck만 사용한 baseline ResNet50모델이고 $ E / B $는 regular bottleneck과 efficient bottleneck을 번갈아가며 사용한 것을 의미한다. 또한 $ E \rightarrow E \rightarrow E \rightarrow E $는 오직 efficient bottleneck만 사용한 것을 의미한다. 그결과 $ E / B $인 hybrid architecture가 baseline 모델과 비슷한 성능을 도출해내면서 latecny 성능 향상을 이뤗음을 보여준다. (모든 모델은 ImageNet dataset으로 90epochs학습함.)

4.2 Efficient ViT Architecture

ViT 구조에서 self-attention layer를 대신하여 parameter-free operation을 적용하였다고 합니다. 그리고 ViT의 classification token을 사용하지 않고 global average pooling (GAP)를 사용하였는데 이는 classification token은 self-attention layer없이는 사용이 불가하기 때문입니다. 기본적인 ViT말고도 Pooling-based Vision Transformer (PiT)에도 Parameter-free operation을 적용하였습니다.

5. Experiments

Classification task용 dataset인 ImageNet과 object detection용인 COCO2017 dataset을 사용하여 제안한 efficient architecture의 성능결과를 보여줍니다.

먼저 ImagNet에 대한 성능 비교입니다. max는 parameter-free operaion만 사용하는 efficient block만 있는 것이고 hybrid는 regular와 efficient block을 번갈아 사용한것이고 deform_max는 deformable max pool operation만 사용한것이다. ( $\dagger $는 training trick을 쓴 결과입니다.)

ImageNet results for proposed ResNet and others

ImageNet performance of CNN models

ImageNet performance of ViTs.

COCO dataset에 대한 성능 비교입니다.

COCO object detection results

Lite Pose 논문 리뷰

Sin-Han Kang — Mon, 18 Apr 2022 22:14:01 +0900

이번 글에서는 CVPR 2022에 accept된 논문인 Lite Pose: Efficient Architecture Design for 2D Human Pose Estimation 을 리뷰하도록 하겠습니다.

해당 논문은 기존 2D Human Pose Estimation task를 수행하는 모델들이 high computational cost를 가진다는 문제점을 해결하고자 합니다. 그래서 Lite Pose라는 모델을 제안하여 low latency와 small parameter numbers를 가지면서 좋은 성능(mAP)을 얻어냈다는 성과를 보여주었습니다.

1. Introduction

Lite Pose는 기존의 bottom-up 방식의 architecture인 (Higher)HRNet의 단점을 보완한 모델입니다. 기존 HRNet은 multi-branch 구조를 사용하여 다양한 image scale에 대해 학습할 수 있도록 하였습니다. 이는 mAP성능을 높이는 데 기여하게 됩니다. 하지만 muti-branch인 구조이다 보니 당연히 model의 크기도 커지고 latency도 높아지게 되는 문제점을 가지죠.

이를 해결하기 위해 저자들은 gradual shrinking을 이용한 single-branch구조를 사용하여 latency와 parameter수를 모두 줄이게 됩니다. gradual shrinking은 말그대로 "점차적으로 줄이기"을 뜻하며 multi-branch(a)를 아래와 같이 점차 줄여가는 모듈 구조(shrink1, 2, 3)를 말합니다. 모듈 구조를 줄였는데도도 좋은 성능을 얻었다고 합니다.

그리고 multi-branch에서는 scale variation에 영향이 거의 없지만 single-branch에서는 scale variation prolbem이 있기 때문에 이를 해결하기위해 fusion deconv head와 large kernel conv를 제안하게 됩니다. 마지막으로는 Neural Architecture Search (NAS)를 통하여 model architecture를 최적화 하여 최종적으로 Lite Pose 모델을 완성하게 됩니다. (자세한 설명은 아래의 Method에서 하도록 할게여!!) 그리하여 아래와 같이 LitePose는 기존 pose estimation 모델들보다 좋은 성능과 빠른 latency를 가지게 됩니다.

Comparison results between LitePose and other pose estimation models

2. Rethinking the Efficient Design Space

제안하는 LitePose의 상세한 architecture design에 대해 설명드리도록 하겠습니다.

2.1 Redundancy in High-Resolution Branches

맨위의 그림에서 보이듯이 HRNet은 multi-branch 구조를 가집니다. 구체적으로 각 $n$ stage마다 $n$개의 다른 branch를 가지는데 이는 $n$개의 다른 resolution의 input feature를 받기 때문에 다양한 image scale에 대한 학습이 가능하게 되고 이는 mAP성능향상에 큰 도움을 주었죠. 하지만 multi-branch이다 보니 수많은 parameter를 사용하게 되고 이는 Latency를 느리게하는 주범이 됩니다.

이러한 multi-branch구조는 edge device에서 사용할 수 없다는 것을 지적하였고 이를 해결하기 위해 gradual shrinking방법을 통해 multi-branch구조가 redundancy를 가진다는 것을 증명하였습니다. gradual shrinking방법은 맨위 사진에서 보여드린 3가지(shrink 1,2,3) configuration입니다. 저자들은 3가지 configuration과 HRNet구조의 성능비교를 해보았을 때 아래와 같이 shrinking 될수록 mAP성능이 높아짐을 확인하였습니다.

Comparison performances between gradual shrinking and HigherHRNet

결론적으로 single branch에 가까워 질수록 성능은 높아졌다는 것입니다.

2.1.1 Gradual Shrinking

Gradual shrinking에 대해 수학적으로 풀어보죠. 기존의 HRNet의 branch와 block은 다음과 같이 정의됩니다.

$A_n = [ a_1 , \cdots, a_n] $: 각 branch에서 사용되는 block 수
$A = \{ A_1, A_2, A_3, A_4 \} $: 전체 multi-branch 구조

그리고, gradual shrinking방법으로 정의된 branch와 block은 다음과 같습니다.

$ A'_i= [ a'_1, \cdots, a'_i ] $ : $ A_i $로 부터 줄어든(shrinking) block수
- $ s.t. \forall j \in \{1, \cdots, i\}, a'_j \leq a_j $
- $ A'_i \leq A_i $
$ [C_1 , \cdots , C_m] s.t. C_{i+1} \leq C_i $ : gradual shrinking의 sequence configurations
- C1: HigherHRNet
- C2: Shrink1
- C3: Shrink2
- C4: Shrink3

2.2 Fusion Deconv Head: Remove the Redundancy

single-branch를 사용하여 기존 multi-branch의 redundancy를 줄였지만 single-branch는 scale variation problem이라는 단점을 가집니다. 이를 해결하기위해 저자들은 fusion deconvolutional layers을 제안하였습니다.

Fusion deconvolutional layer는 직접적으로 이전의 Stage들로부터 생성된 low-level high resolution feature를 head layer의 output에 concatenate하는 방법입니다. 기존의 HR Fusion과 다르게 추가적인 conv연산을 없앳다는 점에서 efficiency를 가집니다. 아래와 같이 Litepose network에서 head layer인 각 deconv layer와 final layer의 output에 이전 stage의 output을 concatenate한 것입니다. 위의 (b)사진에서 보이듯이 기존의 deconv보다 제안한 fusion deconv가 높은 mAP를 도출하는데 큰 기여를 한것을 알 수 있습니다.

LitePose Architecture

2.3 Mobile Backbone with Large Kernel Convs

위의 LitePose구조에서 알 수 있듯이 backbone은 변형한 MobileNetv2를 사용하였습니다. 변형한 것은 마지막의 down-sampling layer을 제거한 것이고 해당 layer가 high resolution의 정보를 없애기 때문에 없앳다고 합니다. 또한 특별하게 pose estimation task에서는 기존 image classification과 다르게 kernel size를 7x7로 했을 때 성능이 좋게 나왔다고 하여 LitePose에서의 7x7 kernel size의 convolution layer를 사용하였습니다.

k는 kernel size를 뜻함.

3. Neural Architecture Search (NAS)

마지막으로 LitePose모델을 만드는데 있어서 최적의 input resolution과 channel size를 찾기 위해 NAS의 한 방법인 Once-for-all을 사용하였습니다. (Once-for-all은 저자 중 한명이신 song han님의 NAS논문이고 자세히 알고싶으시면 논문 찾아보시는 것을 추천합니다. 좋은 논문이거든요ㅎㅎ..) 그래서 NAS를 통하여 4개의 LitePose모델: LitePose XS, S, M and L 을 찾아내었습니다.

NAS에 사용된 방법내용은 다음과 같습니다.

3.1 Optimization goal

기존 LitePose는 $K$개의 layer를 가지며 각 layer가 $ \{ c_k\}^K_{k=1} $channels 을 가진다고 할 때, NAS의 optimization 목표는 best mAP는 유지하면서 기존보다 채널수를 작게하고 $ \{ c'_k\}^K_{k=1} $ ( $c'_k \leq c_k$ )와 기존 input resolution 보다 작도록 하는 $ r' < r $ 것입니다.

3.2 One-shot Supernet Training

NAS에서 supernet을 학습할때 one-shot방법을 사용하게 됩니다. 서로 다른 channel number configurations는 weight sharing을 하게 됩니다. 각 training iteration마다 하나의 channel configuration은 uniform sampling으로 선택되도록 하였고 선택된 configuration만 training되도록 합니다. 또한 grouping을 위한 associate embedding를 학습하기 위해 pretrained weight로 supernet의 weight를 초기화하였습니다. (associate embedding은 "Associative Embedding: End-to-End Learning for Joint Detection and Grouping"논문을 참고해주세요)

3.3 Search & Fine-tune

supernet에서 최적의 sub-network를 찾기위해 evolutionary algorithm을 사용하게 되고 찾아진 sub-network는 Fine-tuning을 통해 최종 performance를 뽑아내게 됩니다.

4. Experiment

4.1 Dataset & Evalution Metrics

Dataset
- Microsoft COCO: 20,000 images, 17 keypoints
- CrowdPose: 20,000 images, 14 keypoints
Evalution metrics
- Object Keypoint Similarity (OKS)
  - OKS는 가우시안 분포를 따르며 $ -d^2_i $는 평균, $ 2s^2 k^2_i $는 분산을 의미함.
  - $ d_i $는 $i$-th keypoint에 대해 ground truth와 prediction의 distance
    (distance $d_i $가 0이면 OKS값이 1이 되므로 가장 최적의 성능을 뜻함)
  - $v_i $는 ground truth의 visibility flag을 의미하고 $ \delta (v_i > 0) $는 $ v_i $가 1인 instance에만 측정하겠다는 것을 의미함.
  - $ s$는 object scale을 의미하게 되는데 object의 크기가 작을수록 작은 distance차이도 크게 작용해야 하도록 하는 변수
  - $ k_i $는 keypoint마다 중요도를 constant(상수)로 표현 (예를 들어 눈,코,입은 조금 틀려도 되지만 허리,팔은 Pose estimation에 중요하므로 조금 틀려도 안됨)

OKS

4.2 Experiment Setting

Data Augmentation
- Random rotation [-30, 30]
- Random scale [0.75, 1.5]
- Random translation [-40, 40]
- Random flip
Pre-training Details
- Associative Embedding loss없이 heatmap loss(ground truth랑 prediction의 Distance구하는 간단한 식)를 통해서만 supernet을 학습하여 supernet의 weight initialization으로 사용
  - Microsoft COCO dataset으로 100 epochs 학습
Supernet Training Setting
- Training SuperNet for LitePose-L/M/S/XS on CrowdPose dataset
  - LitePose-L/M/S에 대해 800 epochs, batch size 32, lr = 0.001 사용
  - LitePose-XS에 대해 2400 epochs, batch size 128, lr = 0.004 사용
- 각 training step마다, 모델 구조는 uniform sampling을 통해 선택
Fine-tuning Setting
- NAS로 찾아진 최적의 sub-network에 대해 아래와 같이 설정
  - CrowdPose dataset에 대해 200 epochs, batch size 32, lr = 1e-3 (각 50, 180 epoch에서 1e-4, 1e-5사용)
  - COCO dataset에 대해 500 epochs, batch size 32, lr = 1e-3 (각 350, 480 epoch에 1e-4, 1e-5 사용)
Search Details
- NAS는 CrowdPose dataset에 사용하였으며
  - LitePose-L/M/S Supernet 학습시 input resolution search space는 [512, 448], channel width ratio는 [1.0, 0.75, 0.5]로 설정
  - LitePose-XS Supernet 학습시 input resolution search space는 [512, 448, 384, 320, 256], channel width ratio는 [1.0, 0.75, 0.5, 0.25]로 설정

4.3 Main Result

당연히 기존의 pose estimation model들보다 뛰어난 mAP와 낮은 Latency를 갖게되었음을 보여준다.

On CrowdPose dataset, Comparison performance between LitePose and other pose estimation models

Results on COCO val/test-dev set

TensorFlow.js (4) YOLOv5 Live demo

Sin-Han Kang — Mon, 11 Apr 2022 23:30:46 +0900

YOLOv5로 실시간으로 detection하는 방법을 공유해보도록 하겠습니다. YOLOv5는 ultralytics회사에서 주도적으로 개발하는 object detection model입니다. detection 성능은 현재 2022년까지 최상의 성능을 내고있습니다. 오늘은 YOLOv5모델 중 YOLOv5n를 사용해 live demo를 진행해보도록 하겠습니다.

해당 블로그에서 실시간으로 demo가 가능하므로 카메라를 요청할수 있어요! 카메라로 어떤 정보나 해킹은 없으니 안심하고 사용하세요! ㅠㅠ

1. YOLOv5n TensorFlow.js 변환

YOLOv5에서는 다음 명령어로 TensorFlow.js모델로 변환하는 코드를 간단하게 제공하고 있습니다.

git clone https://github.com/ultralytics/yolov5.git
python export.py --weights yolov5n.pt --include tfjs

변환이 잘되었다면 다음과 같이 파일들이 생성되었을 것입니다.

yolov5n tensorflow.js

.bin파일들은 모델의 weight를 저장하는 것이며 model.json은 모델의 구조를 담고 있는 파일입니다.

변환 과정에 대해 조금 설명하겠습니다. 이후에 tensorflow.js코드에 필요한 정보라서요! export.py 코드에서는 yolov5n을 다음과 같은 변환을 거칩니다.

PyTorch -> TensorFlow -> TensorFlow.js

이때 TensorFlow로 변환될 때 agnosticNMS를 추가해주었기 때문에 output의 형태가 [boxes, scores, classes, valid_detections]가 됨을 아셔야하는데요. 그 이유는 TensorFlow.js로 변환하고 난 뒤 tensorflow.js 코드에서 yolov5n모델의 결과(output)를 웹상에 그려줘야하기 때문입니다! (output형태가 실제로 어떻게 변화하는 지 코드로 보고싶으면 여기로 -> TensorFlow변환시 output변화 )

output의 의미는 다음과 같습니다.

boxes: detect된 물체의 bounding box position (x1, y1, x2, y2)
- x1: bounding box의 왼쪽 x좌표
- y1: bounding box의 위 y좌표
- x2: bounding box의 오른쪽 x 좌표
- y2: bounding box의 아래 y좌표
scores: detect된 물체의 confidence score
classes: detect된 물체의 class index
valid_detections: nms를 통한 최종 detect된 물체 총 개수

2. YOLOv5n Live demo

이전글들에서 live demo를 해보았기때문에 해당 글에서는 YOLOv5모델을 돌리기 위한 중요한 코드만 설명드릴게요. 티스토리블로그에서 돌릴 수 있는 전체 코드는 다음 github tfjs_tutorial 에서 찾아 보시면 됩니다.

2.1 HTML skeleton

<body>
  <div id="main">
    <div class="container">
      <div class="canvas-wrapper">
        <canvas id="output"></canvas>
        <video id="video" playsinline style="
          -webkit-transform: scaleX(-1);
          transform: scaleX(-1);
          visibility: hidden;
          width: auto;
          height: auto;
          ">
        </video>
      </div>
    </div>
  </div>
</body>

<script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs@latest"></script>

html코드에 대한 내용입니다. video element를 통해 실시간으로 camera를 읽어오는 것이고 canvas element를 통해 model detection한 결과를 camera화면 위에 그릴 것입니다. 그리고 아래의 script element를 보면 tfjs를 cdn을 통해 import하여 tfjs의 모듈들을 사용함을 정의하였습니다.

2.2 javascript 기본구조

javascript 큰 구조는 다음과 같습니다. 아래의 함수들을 통해 live로 yolov5 detection을 진행할 것입니다.

async function app() {
  camera = await Camera.setupCamera(); //camera setup
  detector = await createDetector(); //load yolov5n model
  renderPrediction(); //draw detection result into canvas
};
app();

2.3 Load Model

이제부터 javascript코드를 작성할것입니다.

const yolov5n_weight = "https://raw.githubusercontent.com/da22so/tfjs_models/main/yolov5n_web_model/model.json"

async function createDetector() {
  return tf.loadGraphModel(yolov5n_weight);
}

위에서 만들어진 yolovn5의 model.json과 .bin파일들은 위의 github url에 올려놓은 것이며 tf.loadGraphModel을 통해 model을 load하게 됩니다.

2.4 Model input shape에 맞게 stream image 변환

실시간으로 들어오는 image stream을 yolov5n모델의 input shape에 맞춰 주기위해 다음과 같은 코드를 추가하였습니다.

  let [modelWidth, modelHeight] = detector.inputs[0].shape.slice(1, 3); //get model's input shape
  const input = tf.tidy(() => {
    return tf.image.resizeBilinear(tf.browser.fromPixels(camera.video), [modelWidth, modelHeight])
      .div(255.0).expandDims(0);
      // 실시간으로 들어오는 camera.video를 model input shape에 맞게 변환
      // normalize를 위해 255로 나눠줌
      // 3차원을 4차원으로 변환
  });

2.5 object detection from yolov5n

아래의 코드로 detection하게 됩니다.

      detect_res = await detector.executeAsync(input,); //detection!!

2.6 detection result를 canvas에 그리기

위의 detect_res의 값이 아래 res와 동일한데요. 위에서 tensorflow로 변환시에 output shape이 [boxes, scores, classes, valid_detections]이었음을 기억하면 아래의 코드가 이해되실거예여!

const [boxes, scores, classes, valid_detections] = res;
    const boxes_data = boxes.dataSync();
    const scores_data = scores.dataSync();
    const classes_data = classes.dataSync();
    const valid_detections_data = valid_detections.dataSync()[0];
    tf.dispose(res);
    var i;
    for (i = 0; i < valid_detections_data; ++i) { // valid_detections수만큼 물체 인식
      let [x1, y1, x2, y2] = boxes_data.slice(i * 4, (i + 1) * 4); //slicing을 통한 한 물체의 bounding box좌표 가져오기
	  ...// 생략
      const width = x2 - x1; 
      const height = y2 - y1;
      const klass = coco_names[classes_data[i]]; // class index를 coco class이름으로 매칭
      const score = scores_data[i].toFixed(2); 

      // bounding box 그리기
      this.ctx.strokeStyle = "#00FFFF";
      this.ctx.lineWidth = 4;
      this.ctx.strokeRect(x1, y1, width, height);

      // label과 confidence score 그리기
      this.ctx.fillStyle = "#00FFFF";
      const textWidth = this.ctx.measureText(klass + ":" + score).width;
      const textHeight = parseInt(font, 10); // base 10
      this.ctx.fillRect(x1, y1, textWidth + 4, textHeight + 4);
    }
	...//생략
    }

3. YOLOv5 Live demo 결과

webcam사용을 승낙하셧다면 아래에 detection결과가 짜짠!!!!!

TensorFlow.js (3) TensorFlow.js 변환

Sin-Han Kang — Sun, 3 Apr 2022 15:26:15 +0900

이번 글에서는 tf saved model(.pb)을 TensorFlow.js model(.json)으로 변환시키는 것을 목적으로 합니다. 2021년 google에서 나온 Efficientnetv2을 대상으로 TensorFlow.js로 변환하고 웹사이트에서 Efficientetv2으로 classification까지 해보죠! (만약 Efficientnetv2에 대해 알고싶다면 EfficientNetv2 논문 리뷰 참고해주세요~)

0. keras model를 tf saved model로 변환

TensorFlow.js 변환 하기 전에 EfficientNetv2는 keras model로 제공하고 있기 때문에 tf saved model로 변환부터 해보죠.

(변환만 관심 있으시면 넘어 가시면 돼요!!)

해당 github을 clone하여 필요한 lib들을 설치하고 save_to_pb.py파일을 실행시켜 efficientnetv2-b0를 tf saved model로 변환해봅시다. (save_to_pb.py는 제가 efficientnetv2-b0모델을 tf saved model로 변경하기 위해 만든 코드입니다.)

git clone https://github.com/da2so/efficientnetv2.git
cd efficientnetv2
pip install -r requirements.txt

python save_to_pb.py

위의 명령어가 모두 정상적으로 동작했다면 다음과 같이 model(.pb)와 폴더가 생성되어야 합니다.

save_to_pb.py의 (중요 부분) 코드는 다음과 같습니다.

def main(_) -> None:
    model = build_tf2_model() #build efficientnetv2-b0 model 
    input = tf.keras.Input(shape=(224,224,3), batch_size=1) # input shape: (1x3x224x224)
    
    keras_model = tf.keras.Model(inputs=[input], outputs=tf.nn.softmax(model.call(input, training=False))) #keras model
    keras_model.save('./efficientnetv2-b0_saved_model', save_format='tf') #save to tf saved model

efficientnetv2-b0을 keras model로 만들 때 softmax부분을 추가해주었고 save함수을 통해 tf saved model 형태로 저장하였습니다.

1. TensorFlow.js model로 변환

TensorFlow.js로 변환하는 방법은 아주 간단합니다. 먼저 tensorflowjs를 설치합니다.

pip install tensorflowjs

이제 tf saved model을 tensorflowjs_converter명령어를 통해 TensorFlow.js 모델로 변환해봅시다.

tensorflowjs_converter --input_format=tf_saved_model efficientnetv2-b0_saved_model  efficientnetv2-b0_web_model

--input_format: 입력 모델 형식
- tf saved model -> tf_saved_model (제가 사용한 옵션)
- keras model(.h5) -> keras
- frozen model -> tf_frozen_model

옵션에 대한 설정이 끝났으면 다음으로는 source_model인 efficientnetv2-b0_saved_model을 설정하고 마지막은 TensorFlow.js파일들이 저장될 디렉토리(efficientnetv2-b0_web_model)을 설정합니다. 위의 명령어가 정상적으로 작동했다면 다음과 같이 모델의 구조를 담는 model.json과 weight를 담고 있는 bin파일들로 저장됩니다.

Efficientnetv2-b0_web_model

2. EfficientNetv2 웹사이트에 deploy

EfficientNetv2를 TensorFlow.js 형태로 만들었으니 실제 웹사이트에서 inference가 잘 작동하는 지 확인해 봐야겠죠?? 저는 javascript기반 react를 기반으로 코딩하였습니다. 직접 자신의 웹사이트에서 작동 확인하시려면 제 github을 clone: git clone https://github.com/da2so/tfjs-efficientnetv2.git 하셔서 사용하시면됩니다.

(npm사용해서 localhost에서 실습하시거나 github page deploy사용하시면 됩니다.)

TensorFlow.js 모델을 react코드에서 어떻게 load하고 inference하는 지 중요한 부분만 골라서 알려드리겠습니다.

const weights = 'https://raw.githubusercontent.com/da22so/tfjs_models/main/efficientnetv2-b0_web_model/model.json';

... //생략
class App extends React.Component {
  state = {
    model: null,
	... //생략
  };
  componentDidMount() {
    tf.loadGraphModel(weights).then(model => { //Efficientnetv2-b0 모델 load
      this.setState({
        model: model
      });
    });
  }
  this.state.model.executeAsync(input).then(res => { // classification execute! 
  ... //생략
  const pred = res;
  const pred_data = pred.dataSync(); // classification compelete done!

tf.loadGraphModel: TensorFlow.js모델을 Load하는 함수
- .json 확장자 파일을 입력으로 받으며 해당 json파일은 위에서 만든 model.json이랑 같음
- url을 통해서만 TensorFlow.js model을 load하는 함수임
- load된 모델은 this.state.model에 할당
this.state.model.executeAsync(input): model의 inference을 execute하는 함수
- input은 입력 이미지(1x3x224x224)를 말함 (자세한거는 코드에서 확인해주세요!)
- classification결과는 res에 할당되지만 javascript 특성상 비동기적이므로 classification이 execute되고 complete되면 pred_data에 할당함

여기서 tfjs-efficientnetv2 실습 EfficientNetv2-b0을 실제로 사용해보실 수 있게 해 놓았으니 이미지 업로드해보세요~~ 저는 저희 집 고양이인 코넛이 사진을 넣어 classification해보았습니다!

Efficientnetv2-b0 example

MobileViT 논문 리뷰

Sin-Han Kang — Mon, 28 Mar 2022 10:24:26 +0900

ICML 2022에 accept된 Apple직원분들의 논문인 MOBILEVIT: LIGHT-WEIGHT, GENERAL-PURPOSE,

AND MOBILE-FRIENDLY VISION TRANSFORMER 을 리뷰해보겠습니다!

1. Introduction

MobileViT는 mobile과 같은 하드웨어의 자원이 제한된 곳에서 사용할 수 있도록 만든 작고(Light-weight) 빠른(low-latency) ViT(Visual Transformer) 모델입니다. 위와 같은 성능을 도출하기위해 MobileViT는 CNN과 ViT의 장점을 결합하였다고 합니다.

CNN의 장점
- spatial(local) inductive bias
- data augmentation에 덜 민감
ViT의 장점
- input-adaptive weighting
- global processing (spatial inductive bias와 대비되는 특성)

Inductive bias란?? ML 모델에 대해 정확한 예측을 위해 사용하는 추가적인 가정임.
예를 들어 CNN은 convolution filter가 Window sliding을 하기 때문에 local한 영역에서 spatial한(공간적인) 정보를 뽑아내는데요. 이는 "Vistion task는 local한 영역에서 정보를 얻을게 많다"라고 inductive bias가 들어가게 되는 것입니다. 이러한 가정이 옳기 때문에 CNN은 효과적인 성능을 보이는 것입니다. RNN 또한 모델설계과정에서 sequential한 inductive bias가 들어간것입니다.

그래서 MobileViT block은 local, global한 information모두 효과적으로 encoding할 수 있으므로 accuracy도 높고 latency도 낮습니다.

그럼 결합은 어떻게 했느냐?? 물론 기본적으로 CNN을 쓰기도 했지만 MobileViT는 기존 ViT와 ViT의 variants(다른 논문들)과 다르게 global representation을 학습하기 위해 기존의 convolution의 연산을 변경하였습니다. 기본적으로 standard 한 convolution은 unfolding, local processing, folding의 순차적 operation을 포함하지만 MobileViT block은 local processing 부분을 transformer를 이용한 global processing으로 대체하였습니다. 이를 통해 해당 block은 CNN의 특성과 ViT의 특성 모두 가지게 되고 이는 적은 parameter와 간단한 training recipe(basic augmentation)으로도 좋은 성능을 가져왔다고 말합니다.

2. MobileViT: A Light-weight Transformer

MobileViT의 구조를 알아보기 전에 ViT먼저 간단하게 알아보고 가죠!

2.1 ViT(Visual Transformer)

아래오 같이 ViT는 이미지 $ X \in \mathbb{R}^{ H \times W \times C } $가 sequential한 flatten된 patches $ X_f \in \mathbb{R}^{ N \times PC } $ 로 reshape됩니다. 그리고 $X_f $는 linear layer을 통해 $ X_p \in \mathbb{R}^{ N \times d }$로 linear projection되어 fixed된 $d$-dimension을 가지게 됩니다. 그리고 $X_p $을 입력으로 $L$개의 transformer block을 학습하게 됩니다. $C, H, W$은 각각 image의 channel, height, width을 의미하고 $ P=wh $은 임의의 height $h$와 $w$을 가지는 patch안의 image pixel을 말하고 $N $은 patch의 개수를 의미합니다.

예를 들어 아래의 이미지가 15(H)x15(W)x(3)이라면 9개의 patch로 나눠지는 것이고 각 patch는 h = 15(H)/3 = 5, w= 15(W)/3 =5 를 가지며 flatten되어 5(h)*5(w) 25의 차원을 가지게 됩니다. 즉, $X_f \in \mathbb{R}^{ 9(N) \times 25(P)* 3(C) } $의 형태를 가지게 됩니다. 그리고 $ X_f $ (보라색 부분!) 는 linear layer의 weight와 곱해져서 $d$ dimension으로 표현됩니다. linear projection을 통해 sequential한 정보를 학습할 수 있도록 positional encoding하는 것입니다. (아래의 extra learnable class embedding은 class에 대한 정보를 학습할 parameter라고 인지하시면 됩니다. )

https://github.com/gupta-abhay/pytorch-vit

기본적으로 ViT는 CNN이 가지는 spatial inductive bias를 가지지 못합니다. 그래서 visual representation을 학습하기 위해서는 수많은 데이터를 필요로 하는 문제점을 발생시키죠. 이러한 문제점을 해결하기 위해 MobileViT를 제안하게 되는 것이죠!

2.2 MobileViT Architecture

MobileViT block

MobileViT block은 적은 parameter로 input tensor $X \in \mathbb{R}^{ H \times W \times C} $의 local, global information을 모두 학습할 수 있도록 하는 것을 목표로 합니다. 먼저, Input tensor을 입력으로 MobileViT는 $ n \times n $의 convolution과 point-wise (or 1x1) convolution을 적용하여 local spatial information을 학습하게 되는 것이죠. Convolution울 적용한 Ouput은 $ X_L \in \mathbb{R}^{ H \times W \times d } $이며 $ d > C $을 만족합니다.

그리고 MobileViT이 long-range non-local dependencies를 가지게 하기 위한 모델링을 하게됩니다.

long-range란? patch간의 position이 멀리 떨어져있어도 서로 간의 정보를 주고 받을 수 있도록 함. 반대로 RNN과 같이 단어(token)간의 거리가 멀 경우 서로의 정보를 교환 및 학습하기 힘든 것을 short-range라고 함.

long-range dependency modeling을 위해서는 가장 흔히 쓰는 방법 중 하나는 dilated convolution입니다. 하지만 이러한 방법은 dilation rate에 따라 성능이 크게 좌우되므로 좋지 않죠. 다른 좋은 solution으로는 self-attention방법론이 있는데 이 중에 하나가 ViT의 multi-head attention입니다. 하지만 기존의 ViT는 parameter도 많고 sub-standard optimizability를 가지게 되고 이는 ViT가 spatial inductive bias를 가지지 못하는 이유가 됩니다.

그래서 저자들은 ViT의 multi-head attention으로 long range dependency를 만족시키고 더하여 MobileViT block을 제안하여 기 spatial inductive bias까지 가지도록 하게 하는 것을 목적으로 하는 것입니다. 그래서 $ X_L $을 unfold시켜 image와 같은 3차원의 non-overlapping flattend patches $ X_U \in \mathbb{R}^{P \times N \times d } $를 만들어 냅니다. $N = \frac{HW}{P} $는 patch의 수, $P = wh $는 각 patch의 dimension이며 $ h \leq n$과 $ w \leq n$을 만족합니다. (위에서 n=3임을 기억!) 각 $ p \in \{ 1, ... , P\}$에 대해, inner-patch간의 relationship은 $L$개의 transformer를 거쳐 encoding되면서 global information을 학습하게 됩니다. encoding된 ouput은 $X_G \in \mathbb{R}^{ P \times N \times d} $입니다. (기존 ViT와 다르게 positional encoding이 없다는 것을 확인!)

\[
X_G(p) = Transformer(X_U (p)), 1 \leq p \leq P , \quad \cdots Eq. (1)
\]

$n \times n$ convolution을 거쳐나온 $X_U(p)$는 $n \times n$크기의 local information을 encode하고 있으며 $X_G(p)$는 하나의 $p$-th location에 대해 다른 $P$ patch들간의 global infromation을 encoding하고 있으므로 $X_G(p)$의 각 pixel은 $X$의 모든 pixel을 encoding한다고 말할 수 있으며 이는 MobileViT의 effective한 receptive field의 크기는 $H \times W$입니다.

그렇기 때문에 MobileViT는 각 patch의 patch order와 pixel의 spatial order 모두 잘 학습되는 것입니다. 그리고 다시 $X_G$를 fold시켜 $ X_F \in \mathbb{R}^{H \times W \times d} $를 얻습니다. $X_F $는 다시 원래의 $C$-dimension으로 projection 시키기 위해 point-wise convoution을 사용하게 되고 해당 output은 $X$와 concatenation operation을 통해 결합됩니다. 이후 $n \times n$ convolution을 사용해 concatenated된 features들을 Fusing하게 되죠.

2.2.1 MobileViT architecture

MobileViT architecture

위는 MobileViT의 전체 구조입니다. MobileViT의 첫번째 layer는 strided 3x3 convolution을 사용하고 다음으로는 MobileNetv2 (or MV2) blocks과 MobileViT blocks을 사용합니다. activation function은 swish를 사용하였고 $h = w =2$로 설정하였습니다. 그리고 MobileViT는 3가지 다른 사이즈의 모델이 있습니다. S: small, XS: extra small, XXS: extra extra small입니다.

2.2.1 Light weight

기존의 ViT는 spatial inductive bias가 없으므로 model의 capacity를 올려 visual representation을 학습하도록 하였습니다. 하지만 MobileViT는 spatial inductive bias를 포함하므로 model의 capacity를 낮출 수 있습니다. 그래서 transformer layer $L = \{2, 4, 3 \} $, dimension $d = \{ 96, 120,144\}$로 설정하였고 각 spatial level은 $32 \times 32$, $16 \times 16$, $8 \times 8$으로 셋팅하였습니다. (기존의 ViT-based 모델 DeIT는 $L=12, d=192$을 사용했었음)

2.3 Multi-scale Sampler for Training Efficiency

기존 ViT-based model은 multi-scale representation을 학습하기위해 fine-tuning을 진행했었죠. 이는 기존의 ViT모델의 positional embedding이 input size에 따라 interpolated되어야 하기때문입니다. (다양한 size의 input을 받아야 성능이 높아지는 구조라고 이해하시면 됩니다.) 하지만, MobileViT는 CNN과 비슷하므로 postional embedding이 필요없는 것이고 이는 Fine-tuning이 필요없다는 뜻입니다.

다만, multi-scale training은 기존 CNN의 성능에도 효과적이므로 저자들은 MobileViT에도 해당 방법론을 사용하게 됩니다. spatial resoltuion $ S = \{ (H_1, W_1), ... , (H_n, W_n) \} $이 정렬된 채로 주어집니다. 그리고 $t$-th training iteration에서 각 GPU마다 하나의 spatial resoultion을 랜덤하게 sampling $ (H_t, W_t) \in S $되고 batch size는 \(b_t = \frac{H_n W_n b}{H_t W_t}를 갖습니다. 그 결과 작은 spatial resolution을 가질경우 큰 batch size이 사용됩니다. 이는 optimization update를 감소시키므로 빠르게 training할 수 있게 합니다.

위의 그림은 standard한 sampler와 multi-scale을 비교한것인데 (b)에서 알 수 있듯이 update되는 횟수가 적으므로 epoch time도 적은것을 알 수 있습니다. 또한 Multi-scale sampler를 통해 0.5%의 성능 향상도 보았다고 합니다.

3. Experiment results

3.1 Experiment setting for classification

ImageNet-1K dataset
300 epoch
1024 batch size with AdamW optimizer and label smoothing cross entropy(smoothing=0.1)
multi-scale sampler $S = \{ (160,160), (192,192), (256,256), (288,288), (320,320) \} $
learning rate from 0.0002 to 0.002 for the first 3k iteration, annealed to 0.0002 using consine scheduler
0.01 L2 weight decay
basic data augmentation (i.e. random resized cropping, horizontal flipping)

3.2 Experiment result for classification

3.3 Experiment setting for object detection

MS-COCO dataset
SSD-Lite의 backbone으로 MobileViT사용
- 다른 backbone들과 성능 비교
- SSD-Lite는 기존 SSD head의 conv를 separable convolution으로 바꾼 것
320 x 320 input resolution
AdamW optimizer
smooth L1 (localization용) and cross entropy (classification용)

3.4 Experiment setting for object detection

EfficientNetv2 논문 리뷰

Sin-Han Kang — Thu, 24 Mar 2022 16:54:50 +0900

ICML 2021에 accept된 구글 논문인 EfficientNetV2: Smaller Models and Faster Training을 리뷰해보겠습니다!

1. Introduction

EfficientNet의 후속모델로 EfficientNetv2는 기존 모델보다 다음과 같은 목적성을 이룰려고 하고 이루게 됩니다.

More efficient Training time
More efficient Parameter number
More efficient Accuracy

실제로 아래그림은 EfficientNetv2의 결과인데 보면 위의 목적성을 모두 잘 이뤗네요. 역시 구글..

그럼 EfficientNetv2의 어떤 contribution이 있었기에 이런 결과를 도출해냈을까요? (1) EfficientNet을 기반으로하는 search space를 구성하여 NAS search (Training-aware NAS)를 통해 EfficientNetv2 구조를 찾아 내었고 (2) image size에 따라 augmentation magnitude를 달리하는 Progressive Learning을 제안하였습니다.

2 EfficientNetV2 Architecture Design

2.1 Depthwise convolutions are slow in early layers but effective in later stages

기존 EfficientNet의 extensive depthwise convolution (MBConv)은 training의 bottleneck을 가져왔습니다. MBConv는 paramter수와 FLOPs낮지만 최신 (movbile or server) accelerators를 온전히 활용하지 못하는 문제가 있기 때문에 training에 악영향을 끼쳤습니다.

그래서 EfficientNetv2에서는 Fused-MBConv를 추가하게 됩니다. Fused-MBConv는 MBConv의 depthwise conv3x3 and expansion conv 1x1을 하나의 conv 3x3으로 바꾼 것입니다.

그래서 stage1-3까지 Fused-MBConv를 적용했을때 적은 parameter수와 FLOPs를 유지하면서 training speed도 함께 줄었습니다. (stage4-7까지는 기존의 MBConv를 사용) 그렇지만 staget1-7에 paramter수와 FLOPs, 그리고 training speed모두에 좋지 않았다고 하네요. 아래는 Fused를 사용하지 않았을때와 특정 범위에 Fused를 사용했을때의 성능 결과입니다.

각 stage마다 둘중 어떤 모듈을 사용하는 것이 최적인지 사람이 직접찾기 힘드니 여기서! NAS를 사용하게 됩니다.

2.2 Training-Aware NAS and Scaling

제안된 Training-Aware NAS는 EfficientNet을 backbone으로 사용하여 Search space을 구성하였습니다.

Search space
- convolution operation types: {MBConv, Fused-MBConv}
- the number of layers
- kernel size: {3x3, 5x5}
- expansion ratio: {1, 4, 6}

기존의 EfficientNet의 pooling이나 skip ops에 대한 search는 수행하지 않았다고 하며 EfficientNet의 channel size을 그대로 사용하였다고 합니다. 그리고 기존의 MnasNet의 RL 방법론을 search strategy로 설정합니다.

구체적으로, search space로부터 1000개의 모델을 뽑고 reduce된 image사이즈로 10 epoch만 Training하게 됩니다. MnasNet의 RL방법론은 보상(reward)를 최대화 시키도록 RNN을 학습시켜 최적으로 network를 찾게됩니다. 보상(reward)은 $A \cdot S^w \cdot P^v $ 으로 설정됩니다. $ A $는 model accuracy, $ S $는 normalized training step time과 parameter size인 $ P $으로 구성됩니다. 그리고 $ w $ = -0.07, $ v$ =-0.05으로 설정된다고 합니다.

그렇게 해서 찾은 EfficientNetv2 은 아래와 같습니다. stage1~3은 Fused-MBConv가 사용됨을 볼 수 있네요!

2.3 EfficientNetV2 Scaling

EfficientNetV2-S부터 EfficientNetv2-M/L의 차이를 주기 위해 EfficientNet에서 사용했던 compound scaling을 사용합니다. 다만, 빠른 training time을 위해 image maximum size를 480으로 제한하였고 뒤 쪽의(stage 5,6)에 점차적으로 layer의 추가 했다고 하네요. (heuristic하게 함)

3. Progressive Learning

저자들의 가설은 다음과 같습니다 "training image size에 따라 fixed된 regularization은 accuracy 성능에 악영향을 미칠 것이야!" 입니다. image size이 작으면 network의 output feature map이 작아지고 이는 Network의 capacity가 작아지므로 작은 Image에는 regularization을 약하게(weak)주어야 한다는 말입니다. 그 반대도 마찬가지고요. image size가 크면 overfitting될 수 있으니 강하게(strong) regularization을 주어야한다는 것이죠.

그래서 해당 가설을 증명하기위해 저자들은 search space에서 샘플링된 model에 대해 image size와 RandAugmentation의 magnitude(regularization)을 달리했을 때 성능 결과를 보았고 가설은 맞아떨어졌습니다! image size가 작을때 magnitude를 작게 줘야 성능이 높았고 image size가 클때는 magnitude가 커야 성능이 좋았습니다.

3.1 Progressive Learning with adaptive Regularization

위의 결과를 통해 Progressive Learning은 다음과 같은 프로세스를 진행합니다.

초기 training epoch에는 smaller image size와 weak regularization을 준 상태로 training 진행
- image size가 작으니 빠르게 학습되고 simple한 representation을 학습하게 해줌
점차적으로 image size와 strong regularization을 주어 training 진행

progressive learning

수식적으로 표현해보죠. 전체 training은 총 $ N $ 번의 step을 가지며 target image size는 $S_e $, regularization magnitude list $ \Phi_e = { \phi^k_e } $로 정의합니다. $ k$는 regularzation type으로 dropout, mixup, randaugmentation중 하나 입니다.

Augmentation type

그리고 training을 총 $ M $ stage 으로 나누게 됩니다. 각 stage마다 같은 image size $S_i $와 regularization $ \phi^k_i $을 사용하겠죠. 그리고 저자들은 heuristic하게 $S_0 $와 $ \phi^k_0 $을 정했고 stage가 올라갈때마다 linear interpolation을 사용하여 더 큰 image size와 strong regularization을 주었습니다. 다음은 위의 progressive learning 프로세스를 알고리즘으로 표현한 것입니다.

4. Experiment setting for ImageNet

ImageNet dataset에 대해 RMSProp optimizer를 상요하였고 0.9 decay, 0.9 momentum, batch norm momentum 0.99와 weight 1-5을 주었습니다. 그리고 350epoch으로 학습하였고 batch size는 4096입니다. learning rate는 0에서 0.256까지 설정하였고 2.4 epoch마다 0.97씩 learning rate를 decay하였습니다. 추가적으로 exponential moving average with 0.9999 decay rate, RandAugment , Mixup, Dropout, and stochastic depth( 0.8 survival probability)을 사용하였습니다. 다음은 네트워크 설정입니다.

5. Result for ImageNet

TensorFlow.js (2) - WebGL 기반 hand pose detection

Sin-Han Kang — Wed, 23 Mar 2022 23:16:35 +0900

0. WebGL 기반 hand pose detection

오늘은 TensorFlow.js의 backend가 무엇이 있는 지 알아보고 사용가능한 backend 중 하나인 WebGL을 기반으로 hand pose detection을 해볼것입니다.

hand pose detection만 하면 재미가 없으니 hand pose 에 따라 다음과 같이 이모티콘을 보여줄 수 있도록 해봅니다. 엄지를 위로 올리면 엄지척하는 이모티콘이 나오도록 하고 아래로 내리면 OMG하는 이모티콘을 나오도록 하겠습니다.

1. TensorFlow.js backend

TensorFlow.js에는 다양한 backend가 존재합니다. 일단 backend란 모델 그래프의 연산들을 수행하는 내부적인 플랫폼이라고 이해하시면 됩니다. 그래서 어떤 backend를 사용하느냐에 따라 같은 모델이라도 inference time 성능에 영향을 미치게 되는 것이죠!

1.1 CPU (순수 javascript)

CPU backend는 가장 기본적인 backend입니다. 가용성과 보편성을 가지고 작은 오버헤드와 자동으로 메모리관리를 해주는 장점을 갖지만 단일 thread로 실행되므로 하드웨어 가속의 장점은 가져갈 수 없습니다. 가용 리소스는 javascript runtime에 의해 제한되는 것도 문제이죠. 결국 많이 느리다는 문제로 일반적으로 웹 애플리케이션에서 사용되지 않는 backend입니다.

1.2 WebGL

WebGL API를 사용하는 backend입니다. WebGL은 웹에서의 그래픽 처리에 사용되는 표준 API입니다. 고수준의 병렬 처리로 가능한 작업들을 활용할 수 있도록 Shader 프로그램을 사용하여 커널 연산들을 구현합니다. WebGL backend는 텐서를 GPU에 올릴 수 있는 텍스쳐 형식으로 저장하고 각 텍스쳐 좌표마다 GPU를 통해 병렬로 처리하게 되는 것입니다. 그래서 WebGL backend사용시 cpu보다 100배 빠르다고 하네요!

Shader란? 컴퓨터 그래픽스 분야에서 그래픽 하드웨어의 랜더링 효과를 계산하는 데 쓰이는 소프트웨어 명령의 집합

또 다른 특징으로는 TensorFlow.js는 shader 자원을 최대한 활용하기 위해 미리 컴파일된 shader 프로그램을 따로 캐시에 저장둡니다. 그래서 model의 inference을 수행하기 전 준비 프로세스는 컴파일된 코들르 캐시에 복사해 둡니다. 그리고 캐시에 저장된 코드는 이후 연산의 실행이 발생할 때마다 재사용하여 shader 컴파일 과정의 오버헤드를 줄이게 됩니다. 특히나 ML 어플리케이션의 경우 같은 연산을 반복하는 경우가 많기 때문에 해당 특징은 inference time을 줄이는 데 효과적입니다.

1.3 Node.js

Node.js는 서버 사이드 javascript 플랫폼이며 웹 어플리케이션 만들때 사용많이합니다. javascript 런타임으로 v8을 사용합니다.

v8이란? V8 엔진은 구글이 만들었으며 오픈소스이고 C++로 제작됩니다. 구글크롬에서 사용 중입니다.

Node.js는 이벤트 중심의 I/O를 사용하여 여러 네트워크 연결을 범위성 있게 다룰 수 있도록합니다. 이러한 동시 연결 모델은 ML과 같이 CPU자원을 집중적으로 사용하는 작업일 경우 좋은 선택지는 아닌데 TenosorFlow.js에서 Node.js backend를 선택한 이유는 Node.js의 잠재력때문입니다.

Node.js backend는 Node.js를 C언어로 확장한 것인데 이 backend는 Tensorflow의 C언어 API를 사용가능하도록 하기 때문에 GPU와 TPU 사용 측면에서 많은 잠재력을 지닙니다. Tensorflow의 C언어 구현부는 하드웨어 가속에 최적화 되어있기때문에 Node.js backend만 잘 갖춰진다면 웹어플리케이션 배포까지의 최적화가 모두 이루어지는 것입니다.

2. hand pose detection 코드

오늘 사용할 model은 tfjs-models에서 제공하는 model을 사용할것이고 webcam을 통해서 live로 hand pose detection을 수행하도록 하겠습니다. 해당 detection은 위에서 말씀드린 webGL backend을 사용하게 됩니다. 추가적으로 손모양에 따라 이모티콘이 보여질 수 있도록 하는 것을 목적으로 합니다.

2.1 HTML skeleton

HTML를 통해 뼈대부터 만들어보죠.

<div id="main">
<div class="container">
<div class="canvas-wrapper">
	<canvas id="output"></canvas>
	<video id="video" 
    	playsinline=""
    	style="-webkit-transform: scaleX(-1);
		transform: scaleX(-1); 
 		visibility: hidden; 
		width: auto; height: auto;">
	</video>
</div>
<div id="emo">&nbsp;</div>
</div>
</div>

중요하게 보실 내용은 다음과 같습니다.

output Id를 가지는 canvas를 통해 hand pose detection의 결과가 webcam 위에 그려짐
video element를 통해 webcam이 실시간으로 streaming됨
- -webkit-transform과 transform을 통해 좌우반전시킴
emo id를 가지는 div를 통해 hand pose에 따라 이모티콘 출력

2.2 CDN을 통한 필요한 javascript import

<!-- Require the peer dependencies of hand-pose-detection. -->
<script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs-core"></script>
<script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs-converter"></script>
<!-- You must explicitly require a TF.js backend if you're not using the TF.js union bundle. -->
<script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs-backend-webgl"></script>
<script src="https://cdn.jsdelivr.net/npm/@tensorflow-models/hand-pose-detection"></script>

WebGL backend를 사용하기 위해 3번째 script 코드를 작성하였고 4번째 script 코드는 저희가 사용할 hand pose detection model을 사용하려면 필요한 javascript입니다. 해당 javascript사용하기 위해 tfjs-core와 tfjs-converter가 필요하기 때문에 위의 2개 script코드를 추가하였습니다.

2.3 webcam을 통한 hand pose detection javascript

app이라는 function을 다음과 같이 만들어 큰 틀부터 잡고 시작하죠!

<script>
async function app() {

  camera = await Camera.setupCamera(); //webcam 셋팅

  detector = await createDetector(); // hand pose detection model 셋팅
  console.log(tf.getBackend()); // 사용되는 TensorFlow.js backend확인
  renderPrediction(); // detection을 통한 result를 draw
};
app(); // app function 실행
</script>

해당 script를 통해 app함수가 실행될 건데 해당 함수에서는 webcam과 detection model을 load하고 webcam을 입력으로 detection model이 도출한 결과를 renderPrediction을 통해 보여지는 flow를 가집니다.

이제 하나하나 위의 함수에 대한 구현부와 그에 대한 주석을 보면서 이해해보죠. (함수들의 구현부를 모두 보여드리는 것은 너무 길어서 중요부분만 보여드리고 설명 할수도 있다는 점 알려드릴게요. 그래두 전체 코드는 제 github tfjs_tutorial 에 올려두었으니 걱정마세여)

2.3.1 webcam 설정 및 활성화

function isiOS() {
  return /iPhone|iPad|iPod/i.test(navigator.userAgent);
}
function isAndroid() {
  return /Android/i.test(navigator.userAgent);
}
function isMobile() { // mobile인지 확인
  return isAndroid() || isiOS();
}
class Camera {
  constructor() {
    this.video = document.getElementById('video'); //video id를 가진 HTML code의 element가져옴
    this.canvas = document.getElementById('output');
    this.ctx = this.canvas.getContext('2d');
  }

  static async setupCamera() {
	... //생략

    const $size = { width: 640, height: 480 }; //desktop용 사이즈
    const $m_size = { width: 360, height: 270 }; //mobile용 사이즈
    const videoConfig = {
      'audio': false,
      'video': {
        facingMode: 'user',
        width: isMobile() ? $m_size.width : $size.width,
        height: isMobile() ? $m_size.height : $size.height,
      }
    };
    const stream = await navigator.mediaDevices.getUserMedia(videoConfig);
    const camera = new Camera();
    camera.video.srcObject = stream; // webcam의 live stream을 video id가진 HTML코드의 video element에 할당

    await new Promise((resolve) => {
      camera.video.onloadedmetadata = () => {
        resolve(video);
      };
    });
    camera.video.play(); 

    const videoWidth = camera.video.videoWidth; 
    const videoHeight = camera.video.videoHeight;
    camera.video.width = videoWidth; 
    camera.video.height = videoHeight;
    // canvas는 나중에 detection result를 그리는데 사용 됨 
    camera.canvas.width = videoWidth; // videoWidth와 일치시켜 detection result가 video cam위에 맵핑되도록함
    camera.canvas.height = videoHeight;
    const canvasContainer = document.querySelector('.canvas-wrapper');
    canvasContainer.style = `width: ${videoWidth}px; height: ${videoHeight}px`; // css부분도 video cam과 같은 크기로 할당

    // 기본적으로 camera가 mirroring되어있으므로 horizontal flipping함
    camera.ctx.translate(camera.video.videoWidth, 0);
    camera.ctx.scale(-1, 1);

    return camera;
  }

코드의 설명은 주석으로 이해하시면 되고 중요 내용은 다음과 같습니다.

document.getElementById를 통해 해당 Id를 가진 HTML element를 가져옴
desktop용, mobile용 webcam사이즈를 달리함
video와 canvas의 크기 설정을 동일시함
webcam이 mirroring되어있으므로 horizontal flipping

2.3.2 hand pose detection model 셋업

async function createDetector() {
  const hands = handPoseDetection.SupportedModels.MediaPipeHands; //mediapipe에서 제공하는 hand pose detection model사용

  return handPoseDetection.createDetector(hands, {
    runtime: 'tfjs', //runtime을 tfjs로 설정함에 따라 webGL을 Default로 사용함
    modelType: 'full', //full(큰 모델) or lite(작은 모델)
    maxHands: 1, // or 2~10 : detect할 손의 개수
  })
}

runtime을 tfjs설정하면 자동으로 webGL backend가 사용됩니다. HTML skeleton에서 작성했던 console.log(tf.getbackend())의 결과를 먼저 보여드리면 다음과 같이 webGL을 사용하는것을 알 수 있습니다.

console.log(tf.getbackend()) 결과

2.3.3 hand pose detection

async function renderResult() {
  ... // 생략
  let hands = null;

  if (detector != null) {
    try {
      hands = await detector.estimateHands( 
        camera.video,
        { flipHorizontal: false }); //hand pose detection 결과를 hands에 반환
    } catch (error) {
      detector.dispose(); //detector에대한 tensor memory를 없앰
      ... // 생략
    }
  }
  ... // 생략
  if (hands && hands.length > 0) {
    camera.drawResults(hands); // detection결과인 hands를 인자로 결과를 visualize하는 drawResults 실행
  }
}

async function renderPrediction() {
  await renderResult();
  rafId = requestAnimationFrame(renderPrediction); //실시간으로 renderPrediction을 계속 실행
};

HTML skeleton 에서 renderPrediction에 대한 함수입니다. 해당 함수에서는 renderResult함수를 지속적으로 실행시키게 됩니다. renderResult는 실제 hand pose detection을 실행하며 결과를 web에 그려주기 위해 drawResults를 호출하게 됩니다.

2.3.4 detection result 그리기

detection result를 그리는 코드를 알아보기전에 hand pose detection의 결과값의 의미부터 해석해보시죠.

detection결과에서 중요하게 볼것은 왼손인지 오른손인지 handness로 확인가능하며 keypoints 배열에 각 hand keypoint에 대한 이름과 좌표를 담고 있습니다. 총 hand keypoint는 0~20까지 이므로 총 21가지 존재하겠죠. 이제 위의 결과를 이해하셨다면 코드를 보러 가보죠.

const fingerLookupIndices = {
  thumb: [0, 1, 2, 3, 4],
  indexFinger: [0, 5, 6, 7, 8],
  middleFinger: [0, 9, 10, 11, 12],
  ringFinger: [0, 13, 14, 15, 16],
  pinky: [0, 17, 18, 19, 20],
}; // 각 keypoint(손가락)을 이어주는 연결을 표현하기 위함

class Camera {
  ... //생략
  
  static async setupCamera() {
  ... //생략
  }
  
  drawResults(hands) {
    ... // 생략 
    for (let i = 0; i < hands.length; ++i) { 
      this.drawResult(hands[i]); //detection된 모든 hand에 모두에 대해 
    }
  }
  drawResult(hand) {
    if (hand.keypoints != null) {
      this.drawKeypoints(hand.keypoints, hand.handedness); 
      const emo_type = this.drawEmoticon(hand.keypoints) // keypoints을 Parsing해서 emo_type을 반환합니다.
      //위의 drawEoticon은 github에서 확인하세여
      if (emo_type == 'up') { // 엄지가 위로 올라갈경우 따봉 이모티콘
        emo.innerHTML = '<figure contenteditable="false" data-ke-type="emoticon" data-ke-align="alignCenter" data-emoticon-type="friends1" data-emoticon-name="032" data-emoticon-isanimation="false" data-emoticon-src="https://t1.daumcdn.net/keditor/emoticon/friends1/large/032.gif"><img src="https://t1.daumcdn.net/keditor/emoticon/friends1/large/032.gif" width="150" /></figure>';
      }
      else if (emo_type == 'down') { //엄지가 아래로 내려갈경우 OMG 이모티콘
        emo.innerHTML = '<figure contenteditable="false" data-ke-type="emoticon" data-ke-align="alignCenter" data-emoticon-type="niniz" data-emoticon-name="029" data-emoticon-isanimation="false" data-emoticon-src="https://t1.daumcdn.net/keditor/emoticon/niniz/large/029.gif"><img src="https://t1.daumcdn.net/keditor/emoticon/niniz/large/029.gif" width="150" /></figure>'
      }
      else { // 이외일 경우 아무것도 보여주지 않음
        emo.innerHTML = '<p></p>' 
      }
    }
  }
  drawKeypoints(keypoints, handedness) {
    const keypointsArray = keypoints;
    this.ctx.fillStyle = handedness === 'Left' ? 'Red' : 'Blue'; //왼손, 오른손에 따라 색 구분
    this.ctx.strokeStyle = 'White'; // keypoints를 이어주는 색을 흰색으로
    this.ctx.lineWidth = 2;

    for (let i = 0; i < keypointsArray.length; i++) {
      const y = keypointsArray[i].x;
      const x = keypointsArray[i].y;
      this.drawPoint(x - 2, y - 2, 3);
    }

    const fingers = Object.keys(fingerLookupIndices);
    for (let i = 0; i < fingers.length; i++) {
      const finger = fingers[i];
      const points = fingerLookupIndices[finger].map(idx => keypoints[idx]); //기준 keypoint와 연결된 keypoint들을 맵핑
      this.drawPath(points, false);
    }
  }

  drawPath(points, closePath) { // hand keypoints끼리 연결된 경우 연결(Path)을 시각화
    const region = new Path2D();
    region.moveTo(points[0].x, points[0].y);
    for (let i = 1; i < points.length; i++) {
      const point = points[i];
      region.lineTo(point.x, point.y); // points[0]과 연결된 points[1:]의 path를 그림
    }
	... // 생략
  }

  drawPoint(y, x, r) { // hand keypoint(Point)을 시각화
    this.ctx.beginPath();
    this.ctx.arc(x, y, r, 0, 2 * Math.PI);
    this.ctx.fill();
  }
}

많은 부분이 생략되었지만 제가 생각하기에 중요한 부분은 모두 주석으로 설명드린거 같네요. 정리하면 다음과 같습니다.

drawResults는 detect된 손의 수만큼을 rendering함
drawResult는 (1) detect된 손의 keypoint와 keypoint간의 연결을 그리는 drawkeypoints함수, (2)손의 모양에 따라 emoticon을 보여줄 수 있는 drawEmoticon함수를 사용
- drawPoint는 hand keypoint자체를 시각화
- drawPath는 hand keypoint간의 연결된 부분을 시각화 (이때 fingerLookupIndices를 참조)
- emo.innerHTML을 통해 emo라는 id를 가지는 HTML element에 할당된 HTML code(이모티콘)를 넣음

이제 코드는 모두 설명드렸습니다. 생략된부분이 모두 포함된 코드는 tfjs_tutorial 에 hand_pose_detection.html이라는 파일에 모아두었습니다.

3. hand pose detection 결과

webcam사용을 승낙하셧다면 아래에 detection결과가 짜라짠짜!!!! 엄지를 위로 하는 따봉이나 엄지를 아래로 하는 hand pose를 취하시면 이모티콘이 나타나실거예요!!

TensorFlow.js (1) - TensorFlow.js 이해 및 detection 예제

Sin-Han Kang — Thu, 17 Mar 2022 13:27:13 +0900

1. TensorFlow.js 란??

TenosorFlow.js는 javascript를 기반으로 하여 웹환경에서 사용되는 머신러닝 라이브러리입니다.

1.1 TensorFlow.js의 특징

Web 기술과의 통합
- TensorFlow.js는 javascript로 작성되므로 웹 브라우저에서 ML model을 별도의 수정없이 동작가능하게 해줌
- ML 애플리케이션 배포에 용이
Web browser 상에서의 다수의 backend 지원
- WebGL [GPU]: 웹 브라우저에서 GPU를 사용할 수 있게 해주는 표준 명세서로 GPU acceleration가능함. (3MB 이상의 ML모델에 적합)
- Web Assembly (WASM) [CPU]: CPU performance의 향상시킬수 있다는 특징. (3MB 이하의 ML 모델사용 시 WASM이 WebGL보다 빠름)
- CPU execution: CPU로 inference가 진행되며 3중에 가장 느림
TensorFlow python API와의 호환
- TensorFlow로 학습된 모델과 호환되도록 API도 지원
data privacy
- TensorFlow.js의 client-side machine learning 기술이 서버로 data나 model을 전송하지 않고 ML service를 사용할 수 있게끔 해줌

1.2 TensorFlow.js는 어디에 사용하지??

Javascript를 기반으로 하기 때문에 다양한 platform에서 쉽게 TensorFlow.js를 사용가능합니다.

Client-side in the web browser (using Javascript)
Server-side even IoT devices (using Node.js)
Desktop apps (using Electron)
Native mobile apps (using React Native)

2. TensorFlow.js 설치

TensorFlow.js의 설치방법은 2가지입니다.

CDN(content delivery network)을 통해 배포되넌 축소된(minified) javascript code 사용
- 설치: <script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs/dist/tf.min.js" type="text/javascript"></script>
- CDN service는 빠르며 정적인 리소스를 사용자들에게 제공하기에 안정적
- 공유 네트워크를 사용할 수 있는 환경에 적합 (인터넷이 되어야한다고 이해하세용ㅎ)
npm 같이 package manager를 통해 배포되는 번들(bundle) package 사용
- 설치: npm install @tensorflow/tfjs
- 공유 네트워크 사용할 수 없는 환경에서 사용되며 애플리케이션에 TensorFlow.js를 직접 포함시키는 방법

둘중에 한 방법으로 설치를 하셨다면 TensorFlow.js의 각종 클래스는 tf라는 이름의 namespace하위에서 찾을 수 있음을 알아두시면 됩니다. (저는 CDN방법으로 실습을 이어나갈 예정입니다.)

3. TensorFlow.js를 이용한 Detection model 예제

오늘 알려드릴 detection model 실습은 TensorFlow.js 에코시스템을 기반으로 진행하므로 먼저 TensorFlow.js 에코시스템부터 알아보져!

3.1 TensorFlow.js 에코시스템

TensorFlow.js의 에코시스템을 통해 다양한 고수준 라이브러리를 사용할 수 있으며 이는 새로운 연구 성과(ML model, algorithm, ...)을 빠르게 도입할 수 있게 해줍니다. 고수준 라이브러리 중에서는 pretrained된 ML모델을 제공하는 tfjs-models이 있고 다양한 종류의 데이터셋을 불러올 수 있는 tfjs-data도 있고 AI 비전공자도 쉽게 ML framework를 사용할 수 있게 해주는 ML5.js도 있습니다.

저는 이중에서 tfjs-models 라이브러리에서 제공하는 detection model(ssdlite)을 사용하여 실습을 진행할것입니다.

3.2 TensorFlow.js 으로 detection model inference

웹브라우저를 통해 inference를 하기 위해서는 html, javascript, css code가 필요합니다. (사실 실습을 진행하는 데 javascript(React) code가 거의 다입니다ㅎㅎ..) 저는 이번에 티스토리 블로그 글에 맞는 inference 코드를 만들어보겠습니다.

먼저 HTML skeleton 부터 보시죠!

<p data-ke-size="size16">&nbsp;</p>

<noscript>
<!--클라이언트 사이드 스크립트(client-side scripts)를 사용하지 않도록 설정했거나
스크립트를 지원하지 않는 브라우저를 위한 별도의 콘텐츠를 정의할 때 사용합니다. -->
      You need to enable JavaScript to run this app.
</noscript>
<div id="inference">&nbsp;</div>

블로그용이다 보니까 <html>...</html>, <head>...</head>과 <body>...</body>에 대한 DOM(Document Object Model)을 글안에 작성안해도 이미 들어가있습니다!! (짧아서 좋구만 허허)

문서 객체 모델(DOM)이란?
문서 객체 모델(DOM)은 XML이나 HTML 문서에 접근하기 위한 일종의 인터페이스입니다. 이 객체 모델은 문서 내의 모든 요소를 정의하고, 각각의 요소에 접근하는 방법을 제공합니다. (e.g. <html>, <a>, <p>, <div>, ...)

"<div>의 inference라는 id를 가지는 element는 머하는 얘지??"하는 생각하실텐데요. 뒤의 react코드를 작성해보면 알게되니 기억해두고 다음을 읽어봅시다! 먼저 react를 쓰기위해 필요한 javascript들을 CDN(Contents Delivery Network)으로 가져와보죠.

<!-- react에 필요한 javascript -->
<script src="https://unpkg.com/react@17/umd/react.development.js"></script>
<script src="https://unpkg.com/react-dom@17/umd/react-dom.development.js"></script>
<!-- html에서 react compile에 필요한 javascript -->
<script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
<!-- tensorflow.js 사용하기 위한 javascript -->
<script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs@1.0.1"> </script>
<script src="https://cdn.jsdelivr.net/npm/@tensorflow-models/coco-ssd"> </script>

사용되는 javascript의 역할은 주석으로 써놓았습니다. 이제야 필요한 준비물이 모두 갖추어 졌으니 react로 가즈아! (부분부분 단락나눠가면서 설명 진행할게여)

<script type="text/babel">
      class App extends React.Component {
        //React.createRef() 는 특정 노드나 컴포넌트에 레퍼런스 값을 만들어주는 것
        //Ref를 통해 인스턴스를 생성 후 render 코드 블록 쪽만 리랜더링후 다시 실행
        videoRef = React.createRef();
        canvasRef = React.createRef();

<script type="text/babel"> 의 text/babel은 react(javascript)를 compile을 담당하고 아래부터 react code입니다. App이라는 class이름을 설정하고 React의 component로 지정합니다. 그리고 videoRef는 실시간으로 들어오는 webcam의 stream값을 받아 지속적으로 리랜더링 (task A라 칭함)하고 canvasRef는 detection 결과를 visualization하는 역할(task B라 칭함)라 칭함)을 합니다.

        componentDidMount() {
          if (navigator.mediaDevices && navigator.mediaDevices.getUserMedia) {
            const webCamPromise = navigator.mediaDevices //웹캠 사용하기
              .getUserMedia({
              	//가져올 미디어에 대한 설정
                audio: false,
                video: {
                  facingMode: "user"
                }
              })
              .then((stream) => {
                window.stream = stream;
                this.videoRef.current.srcObject = stream; //웹캠 stream을 videoRef에 할당
                return new Promise((resolve, reject) => {
                  this.videoRef.current.onloadedmetadata = () => {
                    resolve();
                  };
                });
              });
            const modelPromise = cocoSsd.load(); //detection 모델 로드
            Promise.all([modelPromise, webCamPromise])
              .then((values) => { //values: [modelPromise, webCamPromise]
                this.detectFrame(this.videoRef.current, values[0]);
              })
              .catch((error) => {
                console.error(error);
              });
          }
        }

componentDidMount() 는 클래스를 생성하고 한번만 실행되는 함수인데 DOM을 제어가능한 생성자입니다.

if구문을 통해 navigator.mediaDevices.getUserMedia 을 통해 유저에게 webcam을 사용요청을 하게 되고 요청을 승락하면 해당 getUserMedia함수를 실행시켜 반환값을 stream이라는 arugment로 넘겨 위에서 만든 videoRef.current.srcObject에 할당하게 되면서 task A역할을 수행하게 되는 것이죠.

그리고 cocoSsd.load()을 통해 coco dataset으로 학습된 ssd 라는 detection 모델을 가져오게됩니다. 그리고 다음 Promise.all을 통해 인자안의 모든 promise인 modelPromise와 webCamPromise가 준비될때까지 기다리게 됩니다. 준비가 완료되면 .then을 통해 modelPromise와 webCamPromise가 values라는 이름으로 wrapping됩니다. (values[0] 은 modelPromise임) 마지막으로 이제 webcam의 stream(videoRef.current)와 detection model(values[0]을 인자로 주어 detectFrame을 실행합니다.

        detectFrame = (video, model) => {
          model.detect(video).then((predictions) => { //model.detect(video)의 return은 predictions으로 전달
            this.renderPredictions(predictions);
            requestAnimationFrame(() => { //지속적으로 detectFrame함수 을 실행시킴
              this.detectFrame(video, model);
            });
          });
        };

detectFrame이라는 함수선언을 한것이고 (video, model)이라는 이름의 2가지 인자를 받는다고 정의한 것이고 해당 인자들로 detect를 실행하고 반환값인 predictions을 인자로 renderPredictions함수를 호출하게 됩니다. 여기서 detect는 webcam의 실시간 frame image을 입력으로 ssd모델의 detection을 수행하는 것이죠. requestAnimationFrame()을 통해 지속적으로 wrapping되어 있는 detectFrame함수를 실행을 하게합니다.

        renderPredictions = (predictions) => {
          const ctx = this.canvasRef.current.getContext("2d");
          ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height);
          // 폰트 설정
          const font = "16px sans-serif";
          ctx.font = font;
          ctx.textBaseline = "top";
          predictions.forEach((prediction) => {
            const x = prediction.bbox[0];
            const y = prediction.bbox[1];
            const width = prediction.bbox[2];
            const height = prediction.bbox[3];
            // bounding box 그리기
            ctx.strokeStyle = "#0072B5";
            ctx.lineWidth = 2;
            ctx.strokeRect(x, y, width, height);
            // label background 그리기
            ctx.fillStyle = "#0072B5";
            const textWidth = ctx.measureText(prediction.class).width;
            const textHeight = parseInt(font, 10); // base 10
            ctx.fillRect(x, y, textWidth + 4, textHeight + 4);
          });

          predictions.forEach((prediction) => {
            const x = prediction.bbox[0];
            const y = prediction.bbox[1];
            // label text 그리기
            ctx.fillStyle = "#000000";
            ctx.fillText(prediction.class, x, y);
          });
        };

위에서 말씀드린 task B를 하도록 하기위해 canvasRef를 여기서 사용하게 됩니다. predictions이라는 인자를 받아 detection result을 그리는 renderPredictions함수입니다. 한 frame image에 여러 detect결과값이 있을 수 있으므로 forEach를 사용한것입니다.

prediction.bbox: detection된 객체의 bounding box의 정보를 담고 있음
- prediction.bbox[0]: bounding box의 x축 좌표의 center값
- prediction.bbox[1]: bounding box의 y축 좌표의 center값
- prediction.bbox[2]: bounding box의 width(너비)
- prediction.bbox[3]: bounding box의 height(높이)
- prediction.class: bounding box의 클래스 이름

        render() {
          return (
            <div>
              <video
                autoPlay
                playsInline
                muted
                ref={this.videoRef}
                width="600"
                height="450"
              />
              <canvas
                className="tfjs_1_size"
                ref={this.canvasRef}
                width="600"
                height="450"
              />
            </div>
          );
        }
      }

      const rootElement = document.getElementById("inference");
      ReactDOM.render(<App />, rootElement);

render() 함수를 통해 html에 랜더링하게 되는 부분입니다. webcam의 실시간 frame image을 담는 videoRef는 ref인자로 들어가 video라는 DOM을 실행하게 되는것이고 detection result를 기록하는 canvasRef는 canvas를 실행하게 됩니다.

inference라는 id를 가진 element(html skeleton에서 만든 element)를 가져와 rootElement에 할당하고 해당 element를 대상으로 App라는 클래스의 render함수의 return값으로 html을 rendering시키는 것입니다. 이제 마지막으로 css부분만 작업하면 끝!!

.tfjs_1_size {
  position: relative;
  top: -450px;
  left: 0;
}

css작업인데요. 위 canvas에서 className과 동일한 이름으로 해당 css를 canvas에 적용하게됩니다. 블로그 특성상 video라는 element밑에 canvas가 위치하게되는데 이는 canvas와 video가 겹치게 보이지 않아 detection되지 않는 것처럼 보이게 되죠. 그래서 이를 위해 위의 css가 필요합니다. 그래서 video의 height만큼 canvas의 위치를 올려주면 완료되는 코드입니다.

이제 모든것이 완료되었습니다. 위에 설명드린 코드는 tfjs_tutorial 에 ssd_detection.html이라는 파일에 모아두었습니다.

3.3 detection 결과

webcam사용을 승낙하셧다면 아래에 detection결과가 짜짠!!!! (가끔 detection이 안될경우가 있는데 새로고침하시면 될거예요..ㅠ)

Airflow (2) - DAG workflow 작성 및 실행

Sin-Han Kang — Wed, 16 Mar 2022 01:45:41 +0900

1. Workflow(DAG) 작성 및 실행

이제부터 직접 python을 통해 workflow를 DAG형태로 만들어보고 해당 workflow를 airflow에서 실행하고 이해해봅시다. airflow안에서 yolov5 model으로 inference하는 것을 목적으로 하겠습니다. 따라오시죠!

1.1 실행 환경 준비

실행 환경을 다음과 같이 셋팅합니다.

airflow webserver 실행 (localhost의 8080포트로 연결)
- airflow webserver -p 8080
airflow scheduler 실행
- airflow scheduler
DAG file을 생성할 저장소 생성 (맥북 기준)
- cd ~/airflow/
- mkdir dags

참고로 airflow.cfg 는 Airflow 관련 설정에 대한 파일, airflow.db은 sqlite database파일이며 이는 airflow설치 시 자동으로 사용되는 db이다.

1.2 workflow 정의

이전 글에서 workflow 즉, DAG를 실행시키고 싶은 지에 대한 정의는 python 파일을 통해 가능하다고 말씀드렸죠. 그래서 이번에 python을 통해 다음과 같은 workflow를 만들 수 있도록 해보겠습니다.

해당 workflow의 목적은 다음과 같습니다.

목적: 랜덤하게 사람 이미지를 다운로드하고 해당 이미지를 yolov5 model로 inference하고 해당 결과를 저장
- make_image_store: 이미지가 저장될 장소를 만듬
- download_person_image: unsplash으로부터 사람(person) 사진을 이미지 저장소에 저장
  - unsplash에서는 무료로 사진을 다운받을 수 있음
- Inference_using_yolov5: yolov5 model을 다운받아 위의 이미지로 inference하고 결과를 이미지 저장소에 저장함
- 해당 workflow는 한번만 실행되도록 schedule_interval을 None으로 설정함

2. workflow 작성 in Python

2.1 DAG 정의

위에서 만든 ~/airflow/dags폴더안에 workflow가 정의된 python파일을 만들면 webserver에서 자동으로 해당 DAG를 등록해줍니다. (만들고 webserver에 등록되는(보여지는) 데 30초정도 걸려요!) 그럼 이제 해당 폴더안에 yolov5_inference.py라는 파일을 만들겠습니다. 그리고 다음과 같이 작성해봅시다.

#yolov5_inference.py
from datetime import datetime
from pathlib import Path
from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.operators.bash import BashOperator


# DAG 정의
dag = DAG(
        dag_id="yolov5_inference", # dag의 고유 이름 (webserver에 표시될 dag 이름)
        description="Download person picture and inference it using yolov5", # dag 설명
        start_date=datetime(2022, 1, 1), #해당 pipeline 실행 시작 시간
        tags=["yolov5"],
        schedule_interval=None, #해당 pipeline 실행 주기 (None으로 한번만 실행하도록 함)
        catchup=False # 이전에 실행되지 않았던 dag를 실행할지 말지 결정
        )

위에서 중요하게 볼 요소는 4가지입니다.

dag_id: dag의 고유 이름
start_date: dag의 실행 시작 날짜
schedule_interval: dag의 실행 주기
- None일 경우 한번만 실행됨
catchup: 이전에 실행되지 않았던 dag를 실행할지 말지 결정
- False 값은 실행을 안함을 명시

start_date와 schedule_interval의 이해

다음과 같이 start_date를 2022년1월1일 0시, schedule_interval이 @daily(하루마다 실행)이고 실제 dag를 trigger run하는 시간도 2022년1월1일 0시이라면 실제 dag가 실행되는 시간은 (start_date + schedule_interval)2022년1월2일 0시가 됩니다. 그리고 schedule_interval이 daily이므로 2022년1월3일 0시에는 2번째 dag run이 실행됩니다.

아래는 schedule interval의 가능한 다른 옵션과 그에 대한 의미는 다음과 같습니다.

catchup 이해

만약 2022년1월1일부터 하루마다 주기로(@daily) dag run이 실행되고 있다가 2,3일에 서버가 다운되거나 dag의 코딩오류와 같은 특정 이유로 dag가 run이 되지않았다고 하였다고 해봅시다. 그리고 1월 4일에 해당 dag를 다시 실행시킬려고 할때 catchup를 True로 할경우 이전에 실행되지 않았던(2일,3일) dag run을 실행하면서 catchup하는 것입니다.

2,3일에 실행되지 않았던 dag run때문에 2,3일에 대한 workflow 결과물이 없습니다. 이런 문제점을 해결하기 위해 4일에 catchup을 True로 해놓으면 실행되지 않았던 2,3일에 대한 dag run을 하면서 해당 날짜들에 결과물도 얻을 수 있는 것입니다.

2.2 DAG의 task 정의 (make_image_store+ download_person_picture)

이제 task들을 만들어 볼텐데요. task는 operator를 wrapping하고 있으며 실제로 operator를 통해 task가 이루어진다고 생각하시면 됩니다. 먼저 이미지를 저장할 저장소를 만들어 주기 위해 make_image_store의 task는 pythonOperator를 사용하게됩니다. pythonOperator는 python함수를 실행시킬 수 있는 operator입니다. 그리고 이미지를 저장소를 만들어주었다면 해당 저장소에 이미지를 다운로드하는 것은 Bash 명령어를 사용하게 되므로 BashOperator을 사용하게 됩니다. (다음 코드는 위의 DAG정의 뒤에 붙여주시면 됩니다.)

IMAGE_DIR = '/tmp/images' # image 저장 장소 지정 (원하는 곳으로 지정)
def _make_img_store():
    Path(IMAGE_DIR).mkdir(exist_ok=True, parents=True)  # image가 저장될 장소 만듬

# task 정의
make_image_store = PythonOperator(
        task_id="make_image_store",
        python_callable=_make_img_store,
        dag=dag
    )
# task 정의
download_person_picture = BashOperator(
    task_id="download_person_picture",
    bash_command=f"curl -L https://source.unsplash.com/random?person --output {Path(IMAGE_DIR)/'image.png'}",  # download person pic
    dag=dag,
)

make_image_store >> download_person_picture

make_image_store: pythonOperator를 사용하여 python 함수 실행(make_img_store)
- role: /tmp/images 디렉토리를 생성함
download_person_picture: BashOperator를 사용하여 curl 명령어 사용
- role: unsplash를 이용하여 random한 사람이미지를 다운로드하여 /tmp/images에 저장
make_image_store >> download_person_picture: task간의 dependency를 나타냄
- make_image_store가 실행되고 나서야 download_person_picture이 실행됨

위처럼 코딩해놓았다면 webserver에 접속해보면 dag_id(yolov5_inference)이름으로 dag가 등록되어있음을 확인가능합니다.

생성한 yolov5_inference dag에서 tree 메뉴와 graph메뉴를 눌러보면 다음과 같은 화면을 확인가능하다.

뿐만아니라 code 메뉴를 통해 우리가 만든 코드는 확인가능하다.

DAG run

webserver 오른쪽에 보면 실행버튼이 있을텐데 눌러서 이제 직접 dag run을 해보자. 정상적으로 실행되었다면 다음과 같은 화면으로 변경된다. 저는 2월 14일에 dag run을 시켰으므로 해당 시간으로 기록되고 schedule_interval이 None이므로 dag run을 한 시간에 한번만 실행되고 종료된다. (dependency에 따라 make_image_store가 실행되고 download_person_picture이 실행된다.)

정상적으로 실행됨을 확인 했으니 실제로 /tmp/images에 이미지가 잘 저장되었는지 확인해보자.

현재까지 dag를 정의하고 task를 정의하고 task들이 실행됨을 확인하였다. 뒤에서 yolov5 task를 추가하고 새로 dag run을 위해 기존의 dag run의 record를 삭제(초기화)해보자. (cmd창에서하세용)

airflow dags delete yolov5_inference -y #yolov5_inference는 위에서 정의한 dag_id

2.3 DAG의 task 정의 (inference_using_yolov5)

yolov5s model로 다운로드한 random한 person 이미지를 inference하기 위해 다음과 같은 shell script(yolov5_inference.sh)를 ~/airflow/dags/에 작성합니다.

#yolov5_inference.sh
git clone https://github.com/ultralytics/yolov5.git #yolov5 repo을 clone함
cd yolov5 # clone한 repo 폴더로 접속
curl -L https://github.com/ultralytics/yolov5/releases/download/v6.0/v61_yolov5s.pt --output v61_yolov5s.pt # yolov5s model(.pt)를 다운로드함
pip install -r requirements.txt # inference(detect)를 위한 library설치
python3 detect.py --weights v61_yolov5s.pt --source $1 --project /tmp/images --name result # 첫번째 인자로받은($1) image를 입력으로 yolov5s model로 inference

위의 shell script 명령어의 의미를 주석으로 적어놓았고 자세한 특징점은 다음과 같다.

v6_yolov5s.pt로 저장된 model은 coco dataset으로 학습됨
- coco dataset에는 person detection을 위한 class도 포함
python3 detect.py ...의 $1의 값은 shell script을 실행하는 인자로 받음을 명시
- 인자로 받은 path는 image path가 될것이며 이는 detection model의 입력 source로 들어감
- detect하는 데 사용되는 모델은 다운받은 v61_yolov5s.pt가 됨
- 해당 명령어의 --project와 --name의 value값을 detection 결과 이미지 저장 디렉토리로 지정함
  - 저장 장소: /tmp/images/result/

위와 같이 shell script를 작성했다면 이제 dag의 task를 추가 정의해보자.

# task 정의
inference_using_yolov5 = BashOperator(
    task_id="inference_using_yolov5",
    bash_command=f"sudo sh ~/airflow/dags/yolov5_inference.sh {Path(IMAGE_DIR)/'image.png'}",  # inference person image using yolov5
    dag=dag,
)

make_image_store >> download_person_picture >> inference_using_yolov5

보시면 아시겠지만 yolov5_inference.sh를 실행시키기 위해 BashOperator를 사용하는 것이고 인자값으로 다운로드한 random한 image의 path가 들어간다. 그럼 이제 다시 webserver에 접속해 해당 task가 추가되었는지 확인한다.

잘 생성되었음을 확인하고 해당 dag trigger run을 해보자!

dag run이 정상적으로 확인되었음을 확인가능하다. 그렇다면 /tmp/images/result 폴더에 가서 detection이 잘 되었는지 확인한다. (새롭게 run시킨것이기 때문에 위에서 보여드린 여자분 사진으로 detection을 진행되지 않았습니다.)

추가로 webserver에서 다음과 같이 task를 누르고 log를 누르면 task에 대한 log도 확인가능하며 이는 만약 dag run을 하면서 fail될때 유용하게 사용될 것입니다.

이렇게 해서 우리가 원했던 workflow pipeline을 작성하고 실행하는 법을 알아보았습니다. 해당 예제 코드는 airflow_tutorial에서 사용가능합니다.

Airflow (1) - Airflow 이해 및 설치

Sin-Han Kang — Wed, 16 Mar 2022 01:27:40 +0900

0. Machine Learning pipelining

(ML pipelining 필요성 및 동기에 대한 밑의 단락입니다 읽어보세용!)

기업에서 ML model을 서비스할 경우 정제되어 있는 데이터셋은 없으며, 주기적으로 라벨이 수정되거나 새로운 데이터가 끊임 없이 계속 쌓이거나 바뀌게 됩니다. 그때마다 새로 training dataeset을 구성해야 하며, validation set 또한 주기적으로 업데이트해야 할 것입니다. 또한, 좀 더 유저 경험을 고려한 새로운 evaluation metrics를 개발해야 하며 model serving이나 monitoring, data와 model의 버전 컨트롤까지 고려해야합니다. 그래서 data가 업데이트될 때마다, model이 변경될 때마다, error가 발생하거나 원하는 수준의 성능이 나오지 않을 때마다, 매번 일일이 dataset을 다시 구성하고 학습 스크립트를 실행하고, 평가를 진행하는 등 모든 과정에서 많은 노력과 시간을 필요로 하게 됩니다.

이를 해결하기 위해 각 과정들의 in/out만 표준화 하고 각 task의 결과에 따른 조건부 처리 및 trigger설정하여 pipeline에 맞춰 실행하는 workflow를 만든다면 반복적인 과정을 줄일수 있으며 이는 engineer/scientist가 model 개선과 연구에만 집중가능하게 합니다.

1. Airflow란?

Apache airflow는 python기반의 workflow mangement platform으로 여러가지 tasks을 일련의 그래프로 연결하고 스케줄링, 모니터링 등 piepline 관리를 위한 다양한 기능을 제공합니다. 즉, airflow는 data processing tool이 아니며 data processing하는 데 있어서 필요한 서로 다른 task를 orchestrating하는 것입니다.

Airflow는 다음 그림과 같이 task(compoenent)들이 directed acyclic graph(DAG)형태로 구성되어있습니다. 그래서 전체 task들은 순환(cyclic) 구조를 가지지않으며 각 task는 하나의 node를 뜻하며 edge를 통해 task간의 의존성을 나타냅니다.

1.1 Airflow를 써야하는 이유

batch-oriented task를 서비스할 경우 사용합니다. (아래 그림 참조)
- batch-oriented란 특정 size만큼(batch)의 데이터를 처리하는 것을 반복
- 실시간 데이터를 처리하는 streaming pipeline서비스를 처리할경우 airflow는 적합하지 않을 수 있음
python code로 복잡한 pipeline을 implement가능합니다.
Airflow이 python 기반이므로 많고 다양한 system(DB, cloud services, ...)과의 integration 및 extension이 가능합니다.
일정 interval마다 pipeline을 스케줄링가능하며 backfilling을 통하여 historical data를 쉽게 re(process)가능합니다.
- backfill에 대해서는 추후에 더 자세하게!!
web interface를 제공하며 이는 pipeline의 결과를 모니터링하고 디버깅하기 좋습니다.

batch processing

1.2 Airflow pipelinling 정의 방법

Airflow는 pipeline을 DAG형태로 구성합니다. DAG는 DAG files안의 python code를 사용해서 정의가능합니다. python code로 각 task(node)를 정의할수 있으며 task간의 dependency와 해당 pipeline의 실행 시간,주기까지 설정가능합니다. python code를 통해 DAG를 만들어 보는 것은 다음 글에서 진행해보도록 하겠습니다.

1.3 Airflow 구조

위에서 정의된 pipeline은 airflow가 어떻게 실행시키는 지 알려면 airflow의 구조를 이해하셔야합니다. Airflow는 크게 다음과 같이 3가지의 main components로 구성되어있습니다.

Airflow scheduler
- DAG를 parsing하며 해당 pipeline의 실행 start와 interval을 scheduling을 하여 Airflow worker(s)에게 task를 전달
Airflow worker
- 각 task를 실제로 실행시키는 주체
Airflow webserver
- parsing된 DAG를 시각화하며 DAG의 실행과 결과에 대해 모니터링가능하게 해줌

Airflow system

Airflow scheduler는 Airflow의 핵심이며 우리가 설계해놓은 pipeline을 처리하는 시간 및 방법을 모두 결정하게 됩니다. 조금 더 디테일하게 scheduler내부 동작 방식을 보면 다음과 같습니다.

scheduler는 유저가 만든 DAG file을 읽음
DAG file에 정의된 execution start time과 interval에 맞춰 DAG task들을 스케줄링
스케줄링된 task(A)가 다른 task(B)에 의존성 판단
task A가 task B에 의존되어있고 task B가 완료된 경우 queue에 task A 추가
의존하고 있는 task B가 끝나지 않은 경우 일정 시간 기다림

위의 모든 과정 및 결과들은 airflow의 metastore에 저장되므로 유저는 task의 진행상황이나 로그들을 metastore와 연동되어있는 airflow webserver interface를 통해 확인가능하다.

2. Airflow 설치

MacOS 12.1, anaconda, python 3.9, airflow 2.2.3 환경에서 실습을 진행함을 알려드립니다.

먼저 anaconda에서 실습을 진행하기 때문에 다음과 같이 pip가 anaconda에서 사용됨을 확인하고 airflow을 설치합시다.

pip --version
pip install apache-airflow

설치가 다 되었다면 airflow version 명령어를 통해 설치가 잘 되었는 지 확인합니다. 그리고 default로 airflow 디렉토리는 home디렉토리에 저장되기때문에 다음과 같이 확인가능합니다.

2.1 Airflow DB initialize

DB를 초기화 합니다. 이를 통해서 예제 pipeline들이 생겨나기도 합니다.

airflow db init

2.2 Airflow scheduler 실행

위에서 설명드린 airflow scheduler를 실행하는 명령어 입니다.

airflow scheduler

2.3 Airflow webserver 실행

airflow webserver를 실행시킵니다. -p옵션은 port를 의미합니다.

airflow webserver -p 8080

위의 명령어가 정상적으로 작동되었다면 이제 웹에서 localhost:8080에 들어가보면 다음과 같은 화면이 나오는지 확인합니다.

webserver에 접속하니 airflow의 username과 password가 필요합니다. 그렇다면 airflow cli를 통해 유저를 생성해봅시다.

airflow users create --role Admin --username admin --email admin.com --firstname sinhan --lastname kang --password admin

Admin계정으로 user를 생성하였고 username과 password는 동일하게 admin으로 지정하였습니다. 생성된 유저 정보는 airflow users list명령어로 확인가능합니다. 확인하였다면 webserver에 만든 유저 정보로 다음과 같이 로그인가능하게 됩니다.

위 그림에서 DAG의 example과 각 column이 의미하는 내용을 적어놓았습니다. schedule부분에서 crontab형태로 나타냅니다. (모르시면 구글링!) 다음과 같은 그리고 example_bash_operator를 클릭하고 'Graph'라는 menu선택을 하면 다음과 같이 해당 workflow의 DAG를 확인가능합니다.

해당 example들은 db initialize를 통해 생성된 것이며 airflow dags list명령어를 통하여 webserver에서 보이는 example들을 terminal에서 볼 수 있습니다.

다음 글에서는 위의 예제와 같이 DAG를 python code로 만드는 법과 실제로 workflow를 실행시켜보면서 결과를 얻어보도록 하겠습니다.

Appendix

혹시 다음과 같은 warning이 뜬다면 sqlalchemy버전이 너무 높아 생기는 것이므로 다음과 같은 명령어로 warning을 해결가능합니다.

# warning: add the parameter 'overlaps="dag_run"' to the 'SerializedDagModel.dag_runs' relationship
pip uninstall sqlalchemy
pip install 'sqlalchemy < 1.4.0'

Docker/Kubernetes - (12) Kubernetes Ingress

Sin-Han Kang — Tue, 15 Mar 2022 22:30:27 +0900

Environment: Ubuntu 18.04

1. Ingress

Ingress network는 외부에서 서버로 들어오는 트래픽을 처리하며 네트워크 7계층 레벨에서 정의되는 k8s object입니다. 주요 기능은 다음과 같습니다.

외부 요청의 라우팅
- /request, /request/you 등과 같이 특정 경로로 들어오는 요청을 어떠한 service로 전달할지 결정
가상 호스트의 요청 처리
- 같은 IP에 대해 다른 도메인 이름으로 요청이 도착했을 때, 어떻게 처리할 지 정의
SSL/TLS 보안 연결 처리
- 여러개의 서비스로 요청을 라우팅할 때, 보안 연결을 위한 인증서를 쉽게 적용

1.1 Ingress 사용 이유

구체적으로 기존에 설명하였던 NodePort, LoadBalancer타입의 service도 위와 같은 기능을 구현가능하지만 Ingress를 사용하는 이유는 다음과 같습니다.

왼쪽 그림처럼 기존의 NodePort 또는 LoadBalancer타입의 service는 deployement 3개를 외부에 노출해야한다면 service가 3개필요합니다. 그리고 service마다 세부적인 설정을 할때 추가적인 복잡성이 발생하게 되고 SSL/TLS 보안 연결, 접근 도메인 및 클라이언트 상태에 기반한 라우팅을 구현하려면 각 service와 deployement에 일일이 설정해야합니다.

하지만 오른쪽과 같이 Ingress를 사용하면 3개의 service에 각각 URL이 존재하지 않고 Ingress에 접근하기위한 단 하나의 URL만 존재합니다. 그래서 클라이언트는 Ingress의 URL로 접근하게 되며 해당 요청은 Ingress에 정의된 규칙에 따라 처리된뒤 deployment에 전달됩니다. 이 과정에서 라우팅 정의나 보안 연결 등과 같은 세부 설정은 Ingress에서 수행됩니다.

1.2 Ingress 구조

kubectl get ing으로 ingress의 목록을 확인가능하다. 확인 시 ingress목록이 없으니 ingress-example.yaml파일로 생성해보자.

#ingress-example.yaml  
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-example
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: da2so.com
    http:
      paths:
      - path: /hostname
        pathType: Prefix
        backend:
          service:
            name: hostname-svc
            port:
              number: 8080

host: 해당 도메인 이름으로 접근하는 요청에 대해서 처리 규칙을 적용
- 여러개의 host를 가질 수 있음
path: 해당 경로에 들어온 요청은 어느 서비스로 전달할지 정의
- 위에서는 /etc-hostname으로 온 요청을 backend에 정의된 service에 전달
pathType: 경로의 유형
- Prefix: URL 경로의 접두사를 / 를 기준으로 분리한 값과 일치시킴 (/hostname, /hostanme/ 가능)
- Exact: URL 경로의 대소문자를 엄격하게 일치시킴 (/hostname 만 가능)
service: path로 들어온 요청이 전달될 내용을 담고있다
- name, port.number: service 이름, port 번호

minimal-ingress라는 이름으로 ingress를 생성했지만 이는 단지 요청을 처리하는 규칙을 정의하는 선언적인 object이다. 그래서 외부 요청을 받아들일 수 있는 실제 서버가 아니기 때문에 Ingress Controller라는 특수한 서버에 적용해야만 그 규칙을 사용가능하다. 즉, 실제로 외부 요청을 받아들이는 것은 Ingress controller server이며 이 서버가 ingress 규칙을 로드해 사용합니다.

그래서 k8s의 ingress는 반드시 ingress controller를 필요로하며 우리는 nginx 웹서버를 사용하므로 Ngnix 웹서버 Ingress controller를 사용합니다. Kong이라는 API gateway나 GKE의 클라우드 플랫폼에서 제공되는 ingress controller도 있음을 알아두면 좋다. Nginx 웹서버 Ingress controller는 다음과 같은 명령어로 Nginx ingress controller와 관련된 resource를 다운받습니다. (제가 사용한 k8s 버전이 1.23인데 이는 controller 버전 1.1.1과 연동가능합니다. )

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.1/deploy/static/provider/cloud/deploy.yaml

위의 그림은 ingress controller의 역할 및 관계를 나타낸 그림(A라 명칭)이다. 이제 kubectl get all -n ingress-nginx명령어로 생성한 ingress-controller에 의해 생성된 ingress-nginx namespace의 모든 object를 확인가능합니다.

여기서 default로 ingress-nginx-controller의 service type이 LoadBalancer로 되어있는데 저는 NodePort service로 진행할것이기 때문에 kubectl -n ingress-nginx edit service/ingress-nginx-controller명령어를 통해 다음과 같이 해당 내용을 수정해줍니다. 그리고 다시 ingress-nginx-controller의 service type이 NodePort로 변환된것을 확인가능합니다.

이제 A 그림에서 hostname-service-nodeport 서비스 부분과 deployment에 대한 yaml을 다음과 같이 작성합니다.

#ingress-deployment-service.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webserver
  template:
    metadata:
      name: my-webserver
      labels:
        app: webserver
    spec:
      containers:
      - name: my-webserver
        image: nginx:1.10
        ports:
        - containerPort: 80
          name: nginx-port
---
apiVersion: v1
kind: Service
metadata:
  name: hostname-svc
spec:
  ports:
    - name: web-port
      port: 8080
      targetPort: 80
  selector:
    app: webserver
  type: NodePort

kubectl apply -f ingress-deployment-service.yaml명령어로 object들을 실행시키고 나면 다음과 같이 deployment와 NodePort타입의 service가 생성된다.

마지막으로 현재 예시는 on-premise환경이기 때문에 마스터노드에서 /etc/hosts파일에 IP와 도메인을 설정해 임시로 동작 여부를 테스트하도록한다. 다음과 같이 /etc/hosts에 da2so.example.com과 워커 노드 IP와 연결한다. 이는 ingress controller는 기본적으로 도메인 이름으로 연결되기 때문에 도메인을 IP연동시켜줘야하는 부분이다.

위와 같이 도메인과 IP를 연결해주는 내용을 추가해주면 ingress의 address에 ingress controller service clusterIP로 연결이 되었다. nginx ingress controller는 항상 ingress 리소스의 상태를 지켜보고 있으며 기본적으로 모든 namespace의 ingress리소스를 읽어와 규칙을 적용하게 되는 것입니다. 위의 모든 설정을 그림으로 나타내면 아래와 같고 외부에서 da2so.com:30172/hostname에 접속하는 것은 다음과 같은 프로세스를 거친다.

외부에서 da2so.com:30172/hostname로 request
1. 일반적으로 외부에서 request가 들어오지만 저는 예시를 위해 마스터노드에서 request를 진행
2. 마스터노드의 /etc/hosts 에 da2so.com을 worker node ip와 연결시켜놓은 상태
3. 그래서 외부에서 접속되는 경우에는 일반적으로 router에다가 ingress에서 설정한 domain과 ip를 연결시켜줘야함
da2so.com:30172는 ingress controller service로 보내짐
1. nodeport 타입의 service를 가지는 ingress controller이기 때문에 port(30172)를 지정하였음
ingress controller의 ingress규칙에 따라 da2so.com:30172/hostname은 da2so.com은 worker node ip에 연결되고 해당 request는 hostname-svc:8080라는 service로 전달됨
hostname-svc는 nginx:1.10 image기반인 pod와 연결되므로 해당 pod의 80번 Port에 접근하여 웹서비스 request를 받음

1.3 Ingress 세부 기능: annotation을 이용한 설정

위의 ingress-example.yaml에서 annotation부분에 대해 설명하지 않았는데 여기서 설명하겠다. 다음은 위에서 작성한 anntotation부분을 가져온 것이다.

#ingress-example.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-example
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
...
      paths:
      - path: /hostname
...

kubernetes.io/ingress.class
- ingress 규칙을 어떤 ingress controller에 적용할것인지 정함 (Ex: Nginx, Kong, GKE, ...)
nginx.ingress.kubernetes.io/rewirte-target
- nginx ingress controller에서만 사용가능하며 ingress에 정의된 경로로 들어오는 요청을 rewrite-target에 설정된 경로로 전달합니다.
- 위에서는 path에 적힌 /hostname으로 접근하면 hostname-svc에는 / 경로로 전달됩니다.

그리고 다음(yaml)과 같이 정규식으로 설정할 경우 ingress에 요청온 path는 hostname-svc으 다음(밑의 그림)경로로 전달됩니다.

#ingress-example.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-example
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2 # path의 (.*)에서 전달받은 경로로 전달합니다.
    kubernetes.io/ingress.class: "nginx"
...
      paths:
      - path: /hostname(/|$)(.*) # (.*)을 통해 경로를 얻습니다.
...

참고! Nginx Ingress Controller는 bypassing이라는 기능을 통하여 application pod에 트래픽을 직접 전달합니다. 해당 Pod의 Service를 경유해야 하는 네트워크 홉을 줄이게 됩니다.

1.4 Nginx ingress controller에 SSL/TLS보안 연결 적용

Ingress의 장점은 ingress controller에서 편리하게 SSL/TLS 보안 연결을 설정할 수 있다는 것입니다. 즉, Ingress controlller지점에서 인증서를 적용해 두면 요청이 전달되는 application에 대해 모두 인증서 처리가능하다. 이번 글에서는 직접 서명한 루트 인증서를 통해 nginx ingress controller에 적용해보자.

보안 연결에 사용할 인증서와 비밀키를 생성해보자.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=da2so.com/O=da2so"

tls.key라는 비밀키와 tls.crt라는 인증서가 생성되었습니다. 그리고 secret object를 다음과 같이 만든다.

 kubectl create secret tls tls-secret --key tls.key --cert tls.crt

tls을 적용한 ingress를 작성하기 전에 위에서 사용한 ingress-deployment-service.yaml을 통해 service와 deployment를 실행시키자.

이제 tls가 적용될 ingress yaml을 다음과 같이 작성한다. 그리고 해당 ingress을 생성하고 생성한 ingress의 정보와 nginx ingress controller의 https(443port)의 정보를 확인한다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-example
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - da2so.com
    secretName: tls-secret
  rules:
  - host: da2so.com
    http:
      paths:
      - path: /hostname
        pathType: Prefix
        backend:
          service:
            name: hostname-svc
            port:
              number: 8080

spec.tls.hosts: 보안 연결을 적용할 도메인 이름
spec.tls.secretName: 위에서 생성하였던 tls 타입의 secret 이름

위의 그림에서 알 수 있듯이 ingress의 정보에 tls연결 정보가 새로 생긴것을 확인가능하며 tls보안이 있기때문에 https로 접속해야하는데 https로 접속하기 위한 ingress controller의 https포트는 31355인것을 알 수 있다. 즉, https://da2so.com:31355는 https와 31355와 맵핑되는 443포트(https)를 통해 ingress controller의 https로 접근을 명시하는 것이고 그다음은 위에서 설명한것과 같이 ingress controller에게 da2so.com과 연결되는 ip주소에 접속하도록 요청하는것이다. 다음 명령어를 통해 https연결을 통해 web service에 접속해보자.

curl https://da2so.com:31355/hostname -k
# -k 옵션은 신뢰할 수 없는 인증서로 보안연결을 위함이다.

Docker/Kubernetes - (11) Kubernetes 리소스의 관리와 설정

Sin-Han Kang — Tue, 15 Mar 2022 21:55:40 +0900

Environment: Ubuntu 18.04

1. Namespace: 리소스를 논리적으로 구분하는 장벽

k8s에서 용도에 따라 container와 그와 관련된 리소스를 구분 지어 관리할 수 있는, 하나의 논리적인 그룹을 제공하기 위해 Namespace라는 object를 사용합니다. 예를 들어 모니터링을 위한 리소스들은 monitoring이라는 이름의 namespace로 생성될수 있고 테스트를 위한 리소스들은 test라는 namespace를 생성가능합니다.

1.1 Namespace 이해

Namespace는 namespace(ns)라는 이름으로 k8s에서 사용가능하며 다음과 같이 namespace목록을 확인가능하다.

기본적으로 3개의 namespace가 존재하는데 각각의 namespace는 논리적인 리소스 공간이기 때문에 pod, replicaset, service와 같은 리소스가 따로 존재합니다. 예로 default라는 이름의 namepspace에 생성된 pod를 확인하려면 다음과 같이 --namespace또는 -n옵션을 사용한다.

kubectl get po -n default

default는 자동으로 사용하도록 설정되는 namespace로 kubectl 명렁어로 k8s 리소스를 사용할때 default namespace를 사용합니다. 즉, --namespace옵션을 명시하지 않으면 기본적으로 default namespace를 사용한다는 것이다. 이전 글에서 사용했던 명령어는 모두 default namespace를 사용한것과 같다.

위와 같이 kube-system namespace는 k8s 클러스터 구성에 필수적인 컴포넌트들과 설정값이 존재한는 namespace입니다. 위의 namespace는 pod에 관한 것들이지만 당연하게도 service, replicaset에도 별도의 namespace를 가지고 있습니다. 예로 다음은 kube-system namespace에는 k8s의 pod, service을 이름으로 찾을 수 있게 하는 DNS 서버의 service가 기본적으로 생성되어있습니다.

namespace는 k8s의 리소스를 논리적으로 묶을 수 있는 가상 클러스터처럼 사용할수 있고 여러명이 사용한다면 사용자마다 namespace를 별도로 취할수있습니다. 하지만 중요한 점은 논리적으로 구분된것이므로 물리적으로 격리된것이 아니기때문에 서로 다른 namespace에서 생성된 pod라도 같은 node에 존재가능합니다. 기존의 배웠던 label과의 차이점 및 장점은 다음과 같습니다.

ResourceQuota object를 이용해 특정 namespace에서 생성되는 pod의 자원 사용량을 제한
애드미션 controller 기능을 이용해 특정 namespace에서 생성되는 pod에서는 항상 사이드카 container붙이도록 할수있음
사용목적에 따라 pod, service등의 리소스를 격리하여 구분가능

1.2 Namespace 사용

namespace는 다음과 같이 production-ns.yaml을 통해서나 kubectl create namespace로 생성가능합니다.

#production-ns.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: production

# from yaml
kubectl apply -f production-ns.yaml
# from create
kubectl create namespace production

그리고 해당 namespace에 리소스를 생성하는 방법은 다음과 같이 metadata.namespace 항목에 만들어놓은 namespace를 입력하면 됩니다.

#deployment-nginx-svc-ns.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-nginx-svc-ns
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      name: my-nginx-pod
      labels:
        app: my-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.10
        ports:
        - containerPort: 80
--- 
apiVersion: v1
kind: Service
metadata:
  name: svc-clusterip-ns
  namespace: production
spec:
  ports:
    - name: web-port
      port: 8080
      targetPort: 80
  selector:
    app: my-nginx
  type: ClusterIP

---을 통해 여러개의 리소스를 정의를 한 것이고 각 리소스에 namespace를 production으로 설정하고 다음과 같이 apply해보면 service와 deployment가 해당 production namespace에 생성된것을 확인가능합니다.

1.3 Namespace의 service에 접근

다른 namespace에 존재하는 service에는 service이름만으로 접근 불가하게 됩니다. 예를 들어 다음과 같이 테스트용으로 만든 임시용 pod는 default namespace를 사용하므로 production namespace의 service에 접근하지 못합니다.

# run ubuntu pod for testing and connect to it
kubectl run -i --tty --rm debug --image=ubuntu:16.04 --restart=Never -- bash

#install curl
sudo apt-get update
sudo apt-get install curl

# http request to service of production namespace
curl svc-clusterip-ns:8080

하지만 $<$service 이름$>$$<$namespace 이름$>$.svc와 같이 service이름 뒤에 namespace를 붙이면 다른 namespace에 접근가능합니다.

namespace는 kubectl delete -f [yaml 파일] 또는 kubectl delete namespace명령어로 삭제가능하며 namespace삭제시 해당 namespace에 존재하는 리소스도 함께 삭제됩니다.

1.4 namespace에 종속되는 k8s object와 독립적인 object

A라는 namespace에 존재한는 pod는 A namespace에서만 보이고 B namespace에는 보이지 않습니다. 이를 object가 namespace에 속한다(namespaced)라고 표현합니다. namespace에 속하는 object의 종류는 kubectl api-resources --namespaced=true로 확인가능합니다.

위에서 설명한 pod, service, deployment가 namespace에 속하는 것을 확인가능하다. 그럼 반대로 속하지 않는 object로는 다음과 같이 node, namespace그 자체도 포함이다. 그래서 namespace에 포함하려해도 포함되지 않는다.

2. Configmap, Secret: 설정값을 Pod에 전달

대부분의 application은 설정값을 가지고 있습니다. 예를 들어 application loggin level을 정의하는 LOG_LEVEL=INFO와 같이 단순한 key-value형태의 설정을 사용할 수 있습니다. 이를 위해 k8s는 pod를 정의하는 YAML파일에 환경변수를 직접 적어놓은 하드 코딩방식을 사용할 수 있습니다. 아래는 기존에 사용하던 deployment-nginx.yaml에 env환경변수를 추가해 env-deployment-nginx.yaml로 만든 예시입니다.

#env-deployment-nginx.yaml
...
  spec:
    containers:
    - name: nginx
      env:
      - name: LOG_LEVEL
        value: INFO
      image: nginx:1.10
...

위는 pod의 LOG_LEVEL이라는 이름의 환경변수를 INFO라고 설정한 것입니다. 이렇게 환경 변수를 직접 pod template에 명시해두 되지만 운영 및 개발 환경에서 각각 다른 deplotment를 생성해야한다면 환경변수가 서로 다르게 설정된 두 가지 버전의 YAML이 필요하게 됩니다. k8s에서는 YAML파일과 설정값을 분리 할 수 있는 Configmap과 Secret의 object를 제공합니다. Configmap은 설정값을, Secret은 노출되어서는 안되는 비밀 값을 저장합니다.

그래서 configmap을 이용한다면 1개의 pod YAML파일만을 사용하되 환경에 따라 다른 configmap을 생성해 사용할 수 있다. 즉, 환경 변수나 설정값까지 k8s object에서 관리하므로 이러한 설정값 또한 YAML파일로 pod와 함께 배포가능하다는 장점이 있다.

2.1 Configmap 사용

일반적인 설정값을 담아 저장할 수 있는 k8s object이고 namespace에 속하기 때문에 namespace별로 configmap이 존재한다. YAML을 사용해서 configmap을 생성할 수 있지만 kubectl create cm [configmap 이름] $[$각종 설정값들$]$ 을 통해 쉽게 생성가능하다. (cm은 configmap과 동일)

다음과 같이 --from-literal옵션을 여러번 사용함으로써 여러 개의 key-value을 configmap에서 사용하도록 할수 있습니다. 그리고 configmap에 저장된 설정값은 kubectl describe cm과 kubectl get cm -o yaml으로 확인 가능하다.

configmap의 설정값을 pod에 적용해보기 전에 어떤 방법으로 configmap이 사용되는지를 알아보죠.

configmap의 값을 container 환경 변수로 사용
- 위와 같은 그림이 해당 예시입니다. container내부의 환경변수 key-value값으로 설정하는 경우입니다.
configmap의 값을 pod 내부의 파일로 마운트해 사용
- configmap의 값을 pod container내부의 특정 파일로 마운트합니다.
- 예를 들어 LOG_LEVEL=INFO라는 값을 가지는 configmap을 /etc/config/log_level이라는 파일로 마운트하면 log_level파일에 INFO라는 값이 저장됩니다.

config map의 데이터를 container 환경 변수로 가져오기

이제 실제로 configmap의 설정값을 pod에 적용해보기 위해 다음과 같은 내용으로 env-configmap.yaml을 만들어보죠.

#env-configmap.yaml
apiVersion: v1
kind: Pod
metadata:
  name: container-env-configmap
spec:
  containers:
    - name: my-container
      image: busybox
      args: ['tail', '-f', '/dev/null']
      envFrom:
      - configMapRef:
          name: log-level-configmap
      - configMapRef:
          name: start-k8s

configmap과 연동되는 부분이 envFrom과 configMapRef 항목입니다. 이전에 생성한 log-level-configmap과 start-k8s라는 configmap의 값을 가져와 환경변수로 설정하는 YAML입니다. envFrom은 하나의 configmap에 여러 개의 key-value 쌍이 존재하더라도 모두 환경변수로 가져올수 있게 하고 configMapRef하위항목의 name와 매칭되는 configmap을 명시하게 됩니다.

그리고 다음과 같이 envFrom과 다르게 valueFrom, configMapKeyRef으로는 key값도 넣어서 해당 configmap에 해당하는 key값을 선택하여 그에 대한 value값을 환경변수로 설정하게됩니다. 그래서 아래를 보면 ENV_KEYNAME_1이라는 환경변수 key값을 만들고 그에 대한 value값을 log-level-configmap의 LOG_LEVEL의 value값으로 설정합니다.

#env-valuefrom-configmap.yaml
apiVersion: v1
kind: Pod
metadata:
  name: container-valuefrom-env-configmap
spec:
  containers:
    - name: my-container
      image: busybox
      args: ['tail', '-f', '/dev/null']
      env:
      - name: ENV_KEYNAME_1 #container에 새롭게 등록될 환경 변수 key값
        valueFrom:
          configMapKeyRef:
            name: log-level-configmap
            key: LOG_LEVEL
      - name: ENV_KEYNAME_2
        valueFrom:
          configMapKeyRef:
            name: start-k8s
            key: k8s

configmap의 내용을 파일로 pod 내부에 마운트

application이 nginx.conf와 같은 특정 파일로부터 설정값을 읽어올 수 있습니다. 예를 들어, 다음과 같은 YAML파일은 start-k8s configmap에 존재하는 모든 key-value 쌍을 /etc/config 디렉터리에 위치시킵니다.

#env-volume-configmap.yaml
apiVersion: v1
kind: Pod
metadata:
  name: volume-env-configmap
spec:
  containers:
    - name: my-container
      image: busybox
      args: [ "tail", "-f", "/dev/null" ]
      volumeMounts:
      - name: configmap-volume          # volumes에서 정의한 컨피그맵 볼륨 이름 
        mountPath: /etc/config             # 컨피그맵의 데이터가 위치할 경로

  volumes:
    - name: configmap-volume            # 컨피그맵 볼륨 이름
      configMap:
        name: start-k8s

volumeMounts와 volumes라는 항목은 다음과 같은 역할을 수행합니다.

spec.volumes: YAML파일에서 사용할 볼륨의 목록을 정의합니다.
- 위에서는 start-k8s라는 configmap을 통해 configmap-volume을 정의하였습니다.
spec.containers.volumeMounts: volume 항목에서 정의된 볼륨을 container내부의 어떤 디렉터리에 마운트할것인지 명시
- 위에서는 /etc/config 디렉터리에 configmap의 값이 담긴 파일이 마운트됨

위처럼 /etc/config라는 폴더에 start-k8s의 key값들로 파일을 만들고 해당 파일내용에는 value값이 들어간다. 그리고 다음과 같이 volumes항목을 다음과 같이 바꾸면 원하는 key-value쌍만 가져올수 있습니다.

#env-volume-configmap.yaml (원하는 key-value선택)
...
  volumes:
    - name: configmap-volume            # 컨피그맵 볼륨 이름
      configMap:
        name: start-k8s
        items:
        - key: k8s
          path: k8s_fullname

items: configmap에서 가져올 key-value의 목록을 뜻함
path: 최종적으로 디렉터리에 위치할 파일의 이름을 입력

파일로부터 configmap 생성

실제 환경에서는 설정 파일 그자체를 configmap으로 사용하는 경우가 많습니다. 이를 위해 기존의 configmap생성시 --from-literal옵션 대신 --from-file이라는 옵션을 통해 파일로 부터 configmap을 생성가능합니다.

kubectl create configmap <configmap 이름> --from-file <파일 이름>

위와같이 index.html에서 별도의 key를 정의하지 않았으므로 파일 이름(index.html)이 key이고 해당 value는 파일내용이됩니다. 그리고 --from-env-file옵션으로 여러개의 key-value형태로 구성된 설정파일을 한번에 가져올 수 있습니다.

#file-configmap.env
a=1
b=2
c=3

kubectl create configmap file-env-configmap --from-env-file file-configmap.env

정적 파일을 pod에 제공하려면 --from-file을 사용하고 여러개의 환경 변수를 pod로 가져올 경우는 --from-env-file을 쓰시면 됩니다.

3. Secret

Secret은 ssh key, 비밀번호와 같은 보안이 필요한 정보를 저장하기 위해 사용되는 object입니다. 사용방법은 configmap과 유사하다.

3.1 image registry 접근을 위한 docker

다음과 docker hub에 private한 docker image를 올렸습니다. (직접 예제를 진행해보려면 docker hub에서 image push하셔야 하시고 private로 변경해야합니다.) 해당 private docker image를 pull받으려면 해당 docker image를 소유하는 계정의 id, password가 필요하겠죠.

그러면 지금부터 secret object로 id, password에 대한 정보를 생성하고 이를 deployment를 만드는 yaml에 해당 secret정보를 넣어 pod를 만드는 예제를 진행해보죠. secret키를 만드는 명령어는 다음과 같습니다.

kubectl create secret docker-registry registry-auth --docker-username=das2o --docker-password=<비밀번호>

docker-registry: secret 타입으로 이외의 다른것(Opaque)등이 존재
registry-auth: secret 이름

위와 같이 kubectl get secret [secret 이름] -o yaml로 .dockerconfigjson이라는 데이터를 확인가능하고 해당 데이터는 base64로 인코딩되어있으므로 다음과 같이 디코딩가능하다. 디코딩해보면 secret을 만들때의 정보들을 볼 수 있다.

그리고 다음은 deployment를 생성하는 yaml이다. 해당 object에서는 private image를 pull하기위해서 secret object를 지정해줘야만 한다. 다음과 같이 정의해주면 secret object의 key-value값을 통하여 계정 인증을 하고난뒤 private image pull이 가능해지는 것이다.

#deployment-secret.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-secret
spec:
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      name: mypod
      labels:
        app: myapp
    spec:
      containers:
      - name: test-container
        image: da2so/test_repo:0.0
        args: ['tail', '-f', '/dev/null']
      imagePullSecrets:
      - name: registry-auth

4. 리소스 정리

위의 예제들은 생성한 리소스가 많을텐데 다 지우고 싶으면 다음과 같은 명령어를 사용한다.

kubectl delete deployment --all
kubectl delete pod --all
kubectl delete configmap --all
kubectl delete secret --all

Docker/Kubernetes - (10) Kubernetes 이해 및 사용

Sin-Han Kang — Tue, 15 Mar 2022 17:30:27 +0900

Environment: Ubuntu 18.04

1. Kubernetes(k8s) 이해

Kubernetes(k8s)이 가지는 고유한 특성에 대해 알아봅시다.

1. 모든 리스소는 object형태로 관리됨

이전 글에서 swarm mode의 container 집합을 service(서비스)라고 하였습니다. K8s은 이러한 개념을 폭넓고 세밀한 단위로 사용하기 위해 object라는 개념을 사용합니다. 예로 container 집합(Pods), Pods을 관리하는 컨트롤러(Replica Set), 사용자(Service Account), 노드(Node) 모두를 하나의 object로 사용가능합니다.

사용가능 한 object는 kubectl api-resources명령어로 확인가능합니다.

2. YAML파일을 통한 k8s 사용

swarm mode의 container service를 생성하는데 사용했던 docker service create명령어와 같이 k8s은 kubectl을 사용합니다. swarm mode의 stack과 같이 k8s에서도 YAML파일을 사용가능하며 많이 사용합니다. YAML파일을 통해 container뿐만 아니라 거의 모든 리소스 object들에 사용될 수 있다는 장점을 가집니다. 또한 kubectl 명령어가 아닌 여러 개의 YAML파일을 정의해 서비스를 k8s에 적용시킬 수 있습니다.

3. 여러 개의 컴포넌트로 구성됨

k8s에서 노드의 역할은 크게 마스터와 워커로 나뉘어져 있습니다.

마스터 노드: clutser를 관리
워커 노드: apllication container생성

swarm mode에서 단일 docker daemon만을 설치한 것과 다르게 k8s는 docker를 포함한 많은 컴포넌트들을 설치 및 실행하게 됩니다. 예로 마스터 노드에서는 API 서버(kube-apiserver), 컨트롤러 매니저(kube-controller-manager), 스케줄러(kube-scheduler), DNS서버(coreDNS)등이 실행되며, 모든 노드에서는 네트워크 구성을 위해 프락시(proxy)와 네트워크 플러그인(calico, flannel 등)이 설치 및 실행됩니다.

그리고 k8s clutser 구성을 위해 kubelet이라는 agent가 모든 노드에서 실행됩니다. kubelet은 container 생성, 삭제뿐만 아니라 마스터와 워커 노드간의 통신 역할을 함께 담당하는 agent입니다. k8s입장에서 docker daemon도 하나의 컴포넌트로 인식한다는 것도 알아두면 좋겠네요.

2. Pod: container를 다루는 기본 단위

2.1 Pod 사용

container applicaton의 기본 단위를 Pod라고 부르며 Pod는 1개 이상의 container로 구성된 container집합입니다. 예로 Nginx 웹 서비스를 k8s에서 생성하려고 다음 그림과 같이 pod 1개에 nginx 1개만을 포함하도록 생성가능합니다.

이제 실제로 Nginx container로 구성된 pod을 생성해봅시다. nginx-pod.yaml파일에 다음 내용을 담도록 합시다.

# nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
      protocol: TCP

apiVersion: YAML 파일에서 정의한 object의 API 버전
kind: 리소스의 종류
- 사용가능한 목록은 kubectl api-resources명령어의 KIND항목에서 확인 가능
metadata: 라벨, 주석, 이름과 같은 부가 정보를 입력
- name항목을 통해 pod의 고유 이름을 지정함
spec: 리소스를 생성하기 위한 정보를 입력
- containers 항목을 입력해 다음과 하위항목을 지정
- image: docker image
- name: container 이름
- ports: nginx container가 사용할 port번호

이제 해당 YAML파일을 통해 kubectl apply -f명령어를 통해 pod를 생성한다. 그리고 생성 확인을 위해 k8s에 존재하는 pod를 출력하는 kubectl get pods명령어를 사용합니다.

위의 YAML에서 사용할 포트(containerPort)는 정의하였지만 아직 외부에서 접근할 수 있도록 노출 된 상태는 아닙니다. 그래서 pod의 Nginx server로 요청을 보내려면 pod container내부 ip로 접근해야합니다. 생성된 리소스의 자세한 정보를 가져올 수 있는 명령어인 kubectl describe을 이용해 해당 pod의 ip주소를 확인합니다.

위에서 주목해야할 부분은 2개인데요. 하나는 IP주소입니다. 저희가 이전 글에서 설치했을때 설정한 k8s container의 네트워크 대역폭(172.31.0.0/16)대로 IP주소가 할당된 것을 확인가능하며 2번째는 마스터 노드에서 kubectl명령어를 사용했지만 할당된 노드는 워커 노드(worker2)인것을 확인할 수 있습니다.

본론으로 돌아와서 위의 IP주소는 172.31.189.65인데요 이는 외부에서 접근가능한 IP가 아니기때문에 cluster 내부에서만 접근가능합니다. 외부, 내부 모두에서 pod에 접근하려면 service라고 하는 object를 생성해야하지만 지금은 IP만으로 nginx pod에 접근해보죠. worker3에서 nginx pod의 ip로 http 요청을 전송해보고 잘 다음과 같이 잘되는 지 확인합니다.

이제 다음명령어로 worker2가 아닌 마스터 노드에서 pod container내부로 직접 들어가봅시다.

kubectl exec -it my-nginx-pod bash

bash를 셸을 실행시키고 -it옵션은 셸을 유지할수 있게 해줍니다. 또한 kubectl logs [pod 이름]을 통해 pod의 로그도 확인가능합니다.

k8s object는 kubectl delete -f명령어로 삭제가능합니다.

2.2 pod vs docker container

k8s에서 container가 아닌 pod를 사용하는 이유는 container runtime의 interface 제공 등 여러가지 이유가 있지만 그 중 하나는 여러 리눅스 네임스페이스(namespace)을 공유하는 여러 container들을 추상화된 집합으로 사용하기 위함입니다. 예제를 위해 다음과 같이 nginx-ubuntu-pod.yaml파일을 작성해보죠.

#nginx-ubuntu-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-ubuntu-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
      protocol: TCP

  - name: ubuntu-container
    image: ubuntu:16.04
    command: ["tail"]
    args: ["-f", "/dev/null"] # 포드가 종료되지 않도록 유지합니다

전과 같이 kubectl apply -f명령어로 해당 YAML을 k8s에 적용시켜 2개의 container가 실행중인 nginx 포드를 실행시킵니다.

위와 같이 container2개를 생성했으므로 READY항목의 값이 2인것을 확인가능합니다. 그리고kubectl exec로 ubuntu container에 접속합니다. -c 옵션은 pod의 어떤 container에 대해 명령어를 수행할 지 명시합니다.

ubuntu container안에서 다음 명령어를 입력합니다.

# curl install
apt-get update
apt-get install curl -y

# http request to localhost
curl localhost

위와 같이 localhost로 http 요청을 했는데도 응답이 도착합니다. ubuntu container가 nginx 서버를 실행하고 있지 않는데도 말이죠. 이는 pod내의 container들이 namespace등과 같은 linux namespace을 공유하기 때문입니다. container 네트워크 타입은 네트워크 namespace를 container간에 공유해 사용할 수 있도록 설정하기 때문에 여러개의 container가 동일한 네트워크 환경을 가지게 됩니다.

2.3 완전한 application로서의 pod

실제 k8s환경에서 1개의 container로 구성된 pod를 사용하는 경우가 많습니다. 이는 하나의 pod는 하나의 완전한 application이라는 점에 그렇습니다. 그러나 nginx container가 실행되기 위해 다른 부가적인 기능이 필요할 경우에는 pod의 주 container는 nginx가 되고 기능 확장을 위한 추가 container를 함께 pod에 포함할 수 있습니다. 부가적인 container를 sidecar container라고 부릅니다. pod에 포함된 container들은 모두 같은 워커 노드에서 함께 실행되고 이러한 구조 및 원리에 따라 pod에 정의된 여러개의 container는 하나의 완전한 application으로 동작하게 됩니다.

3. Replica set: 일정 개수의 pod를 유지하는 controller

3.1 Replica set 사용 이유

다음과 같이 여러개의 동일한 container를 생성한 뒤 외부 요청이 각 container에 적절히 분배될 수 있도록 하는 마이크로서비스 구조에서 k8s는 replica set을 사용합니다.

즉, replica set이라는 object를 통해서 다음과 같은 역할을 수행하도록합니다.

정해진 수의 동일한 Pod가 항상 실행되도록 관리
노드 장애 등의 이유로 pod를 사용할수 없다면 다른 노드에서 pod를 다시 생성함

3.2 Replica set 사용

nginx pod를 생성하는데 replica set을 사용해보겠습니다. 다음과 같은 내용으로 replicaset-nginx.yaml을 만들어봅시다.

#replicaset-nignx.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-nginx-pods-label
  template:
    metadata:
      name: my-nginx-pod
      labels: 
        app: my-nginx-pods-label
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

spec.replicas: 동일한 pod을 몇개 유지 시킬 것인지 설정
spec.template 아래 내용들: pod생성할 때 사용할 template정의
- pod 생성에 사용했던 내용을 동일하게 replicaset에서도 정의하여 pod의 구성 내용을 담음

리소스의 고유한 이름은 모든 object에 설정가능하므로 replicaset의 name을 replicaset-nginx로 설정하였습니다. 위 내용의 파일로 replicaset을 만들어보죠.

kubectl get po와 kubectl get rs으로 정상적으로 3개의 pod가 생성되었는지 확인합니다. po는 pods alias, rs는 replicasets의 alias로 사용됩니다.

여기서 pod의 개수를 4개로 늘리고 싶다면 YAML파일에서 replicas의 숫자를 4로만 변경하고 다시 kubectl apply -f명령어를 사용합니다.

3.3 replicaset 동작원리

pod와 replicaset은 느슨한 연결(loosely coupled)을 유지하며 이러한 느슨한 연결은 pod와 replicaset의 정의 중 Label Selector를 이용해 이뤄집니다. 위에서 만든 YAML을 봐봅시다.

위에서 replicaset영역과 pod영역에 정의된 highligt된 label은 서로 다른 object가 서로를 찾기 위해 사용됩니다. replicaset은 spec.selector.matchLabel에 정의된 label을 통해 생성해야하는 pod를 찾습니다. 즉, app:my-nginx-pods-label label을 가지는 pod의 개수가 replicas 항목에 정의된 숫자인 3개와 일치하지 않으면 pod을 정의하는 pod template항목의 내용으로 pod를 생성합니다.

그래서 app:my-nginx-pods-label이라는 label을 가지는 pod를 미리 생성해두고 replicaset을 생성하면 어떻게 될까요? 먼저 해당 label을 가지는 pod을 수동으로 생성해보죠.

#nginx-label-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-pod
  labels:
    app: my-nginx-pods-label
spec:
  containers:
  - name: my-nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

이 상태에서 replicaset을 생성해보죠.

replicaset의 selector.matchLabel에 정의된 app:my-nginx-pods-label을 가지는 label을 이미 1개(my-nginx-pod) 존재하기 때문에 template에 정의된 pod설정을 통해 3개의 pod만 생성된다. 그리고 수동으로 생성된 pod를 삭제하면 다음과 같이 replicaset이 알아서 새로운 pod를 생성해줍니다.

만약 replicase이 생성해 놓은 pod의 label을 삭제하면 예상하셨듯이 label을 통해 replicaset 숫자를 결정하므로 app:my-nginx-pods-label이름의 label을 가지는 새로운 pod가 생성됩니다. 예시를 위해 kubectl edit명령어을 사용하여 pod 중 하나의 label을 삭제해봅니다. label삭제는 아래 그림과 같이 label에 대한 정보를 담는 내용을 삭제하면 됩니다.

# replicaset-nginx-vmnrz는 pod의 이름 중 하나임
kubectl edit pods replicaset-nginx-vmnrz

edit한 부분을 저장하면 다시 pod의 목록을 보면 새로운 하나의 pod가 생성되었고 label의 정보를 삭제한 pod는 label 정보가 사라졌음을 알 수 있습니다. 그리고 label이 없는 pod는 kubectl delete rs명령어로부터 삭제되지 않으므로 직접 삭제해주어야 합니다.

그리고 중요한 특징 중 하나로 replicaset은 다음과 같은 YAML파일에서 표현식(matchExpressions)으로 정의가능합니다.

# nginx-expression-pod.yaml
...
spec:
  replicas: 3
  selector:
    matchExpressions:
      - key: app
        values:
          - my-nginx-pods-label
          - your-nginx-pods-label
        operator: In

위의 예시는 key가 appd인 label을 가지고 있는 pod들 중에서 values항목에 정의된 값들이 존재(In)하는 pod들 대상으로하겠다는 말으로 my-nginx-pods-label뿐만 아니라 your-nginx-pods-label이라는 label을 가진 pod또한 replicaset 관리하에 놓이게 됩니다.

4. Deployment: replicaset, pod의 배포를 관리

4.1 Deployment 사용

실제 k8s 운영환경에서 replicaset을 YAML파일에서 사용하는 경우는 없습니다. 대부분은 replicaset과 pod의 정보를 정의하는 Deployment라는 object를 YAML파일에 정의해 사용합니다.
Deployment는 replicaset의 상위 object이기 때문에 deployment생성시 자동으로 대응되는 replicaset도 생성됩니다. 다음과 같은 deployment-nginx.yaml로 deployment를 생성해봅니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      name: my-nginx-pod
      labels:
        app: my-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.10
        ports:
        - containerPort: 80

보시면 아시겠지만 replicaset과 비교했을 때 kind부분만 Deployement로 바뀌었지 다른변화는 거의 없습니다. 일단 deployment을 생성해보죠.

kubectl get deploy로 deployment의 실행을 확인하고 replicaset셋 또한 생성됨을 확인하자.

deployement로 생성하였지만 replicaset과 크게 다르지 않는 데 차이점이라고는 NAME항목에서 중간에 해시값(6b4b7f7cdc)이 포함되어있는데 이는 pod를 정의하는 template으로부터 생성된 것인데 자세히는 뒤에서 설명할것이므로 기억해두자. deployment삭제는 다음 명령어로 진행한다.

kubectl delete deploy my-nginx-deployment

4.2 Deployment 사용 이유

Deployment를 사용하는 큰 이유 중 하나는 application의 업데이트와 배포 및 관리를 해준다. 예로 application을 업데이트할 때 replicaset의 변경사항을 저장하는 revision을 남겨 rollback를 가능하게 해주고 무중단 서비스를 위해 Pod의 롤링 업데이트 전략을 지정가능하다.

Deployment을 이용해 application의 버전을 업데이트해 배포하는 예시를 알아보자. 위의 deployment-nginx.yaml을 이용해 다시 deployment을 실행하자. --record옵션을 통해 deployment의 변경사항을 저장하도록 한다.

kubectl apply -f deployment-nginx.yaml --record

이제 만약 당신이 nginx:1.10 을 nginx:1.11로 업데이트하고 싶다고 할때 deployment에서 생성된 pod의 image을 kubectl set image명령어로 업데이트 가능하다.

kubectl set image deployment my-nginx-deployment nginx=nginx:1.11 --record

위에서 알 수 있듯이 기존의 사용되었던 nginx:1.10이미지를 가지는 replicaset의 해시값은 (6b4b7f7cdc)이며 기존의 replicaset의 값이 0으로 설정된 것을 보아 정지된 것을 알 수 있고 새로 nginx:1.11로 실행되는 replicaset과 그에 대한 해시값(55bbf495bd)을 확인가능하다. 그리고 이는 이전 버전의 replicaset을 삭제하지 않고 남겨두고 있는것을 말하고 이전의 정보를 리비전으로서 보존하는 것입니다. kubectl rollout history deploy명령어로 리비전 정보를 확인하자.

CHANCE-CAUSE에 나오는 명령어들은 --record에 의해 저장된 것이며 이제 nginx:1.10으로 다시 롤백을 해보자. --to-revision옵션의 값으로 되돌리고자하는 revision번호의 값을 설정하면 된다.

kubectl rollout undo deploy my-nginx-deployment --to-revision 1

롤백이 잘된것을 확인가능하다. 생성된 모든 리소스를 삭제하려면 kubectl delete deploy,po,rs --all를 사용한다.. 정리하자면 deployment를 통해 replicaset의 리비전 관리뿐만 아니라 다양한 pod의 롤링 업데이트 정책을 사용할수 있으므로 deployment를 통해 application을 서비스하자.

5. Service: pod를 연결하고 외부에 노출

deployment을 실행시키기 위해 사용한 YAML에서 pod를 외부로 노출하지 않았으므로 외부에서 접근이 불가하다. Ngnix의 containerPort항목은 80번 port로 웹서버로 제공하기 때문에 설정한 값일뿐이기 때문에 해당 Nginx pod가 외부로 노출되는 것은 아닙니다. 그래서 외부에서 pod에 접근하기 위해 서비스(service) object를 생성해야 합니다. service의 핵심 역할은 다음과 같습니다.

여러 개의 pod에 쉽게 접근할수 있도록 고유한 domain 이름을 부여
여러 개의 pod에 접근할 때 요청을 분산하는 로드 밸런서 기능을 수행
클라우드 플랫폼의 로드 밸런서, 클러스터 노드의 Port등을 통해 포드를 외부로 노출

5.1 service 종류

k8s 서비스는 pod에 어떻게 접근할 것이냐에 따라 종류가 여러개로 세분화 되어있는데 다음과 같은 특징을 고려하여 서비스 종류를 고르셔야합니다.

Clutser IP
- k8s 내부에서만 pod들에 접근할 때 사용함, 외부로 pod가 노출되지 않음
NodePoint
- pod에 접근할 수 있는 port를 클러스터의 모든 노드에 동일하게 개방함 외부에서 접근 가능
- 접근 가능한 port는 랜덤으로 정해지지만 특정 Port로 접근하도록 정할 수 있음
LoadBalancer
- 클라우드 플랫폼(AWS, GCP)에서 제공하는 로드 밸런서를 동적으로 프로비저닝하여 pod에 연결, 외부에서 접근 가능
- 실제 운영 환경에 많이 사용

Clutser IP

먼저 지금부터 deployment를 설명할때 사용했던 deployment-nginx.yaml과 함께 예제를 진행할 것입니다. 다음과 같이 svc-clusterip.yaml을 생성해봅시다.

# svc-clusterip.yaml
apiVersion: v1
kind: Service
metadata:
  name: svc-clusterip
spec:
  ports:
    - name: web-port
      port: 8080
      targetPort: 80
  selector:
    app: my-nginx
  type: ClusterIP

spec.selector: 해당 label을 가지는 pod에 접근하게 함
- my-nginx는 deployment설명 때 사용한 deployment-nginx.yaml의 nginx container의 label이름
spec.ports.port: k8s 내부에서만 사용할 수 있는 고유한 IP(ClusterIP)를 할당 받음
- 서비스의 IP에 접근할 때 사용하는 port설정 값
spec.ports.targetPort: selector항모게서 정의된 label에 의해 접근 대상이 된 pod들이 사용하는 내부 port번호
- deployment-nginx.yaml의 containerPort항목의 값을 입력해야 함.
spec.type: 서비스의 타입을 입력

deployment-nginx.yaml을 통해 deployment를 실행시키고 svc-clusterip.yaml로 service를 생성해보자. 그리고 kubectl get svc명령어로 생성된 service의 목록을 확인한다.

svc-clutserip라는 이름으로 service를 생성하였습니다. kubectl run명령어를 통해 임시 ubuntu pod를 만들고 출력된 CLUSTER-IP와 PORT(S)로 curl를 통한 http 요청을 보내면 응답받을 수 있습니다. 또한 service이름 자체로도 접근가능한데 이는 k8s가 application이 service나 pod를 쉽게 찾을 수 있도록 내부 DNS를 구동하고 있고 pod들은 자동으로 이 DNS을 사용된다.

# run ubuntu pod and connect to it
kubectl run -i --tty --rm debug --image=ubuntu:16.04 --restart=Never -- bash

#install curl
sudo apt-get update
sudo apt-get install curl

# http request using cluster ip + port
curl 10.99.228.48:8080
# http request using inner DNS
curl svc-clusterip:8080

서비스를 삭제하기 위한 명령어는 다음과 같습니다.

kubectl delete svc svc-clusterip

NodePort

다음과 같은 svc-nodeport.yaml을 작성(ClusterIP와 비교했을 때 type만 다릅니다.)하고 apply시켜 service를 생성해봅니다.

# svc-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
  name: svc-clusterip
spec:
  ports:
    - name: web-port
      port: 8080
      targetPort: 80
  selector:
    app: my-nginx
  type: NodePort

Cluster IP와 다르게 PORT(S)항목에서 32453라는 숫자가 생겼고 이는 모든 노드에서 동일하게 접근 가능한 port를 의미합니다. (해당 Port는 랜덤으로 정해집니다.) 즉, 클러스터의 모든 노드에 내부 IP또는 외부 IP를 통해 32453 port로 접근하면 동일한 service에 연결가능합니다. 또한 가상머신을 아닌 제 맥북에서도 응답을 받을 수 있습니다. 당연히 nodeport를 삭제하면 연결은 끊기고 response를 받을 수 없을 것입니다.

추가로 NodePort는 ClusterIP를 가지고 있음을 알 수 있는데 이는 NodePort는 ClusterIP의 기능을 포함하고 있기 때문이다. 다음은 NodePort의 정리 그림이다.

외부에서 pod에 접근하기 위해 각 노드에 개방된 port로 요청을 전송함. 위 그림에서 32453 port로 들어온 요청은 service와 연결된 pod 중 하나로 라우팅됩니다.
클러스터 내부에는 ClusterIP의 service와 동일하게 접근할 수 있다.

실제 운영에서는 NodePort service 그 자체를 통해 service를 외부로 제공하기 보다는 인그레스(ingress)라고 부르느 object에서 간접적으로 사용을 많이 합니다.

LoadBalancer

해당 type의 service는 로드밸러서를 동적으로 생성하는 기능을 제공하는 환경(AWS, GCP)에서만 사용가능하다. 지금 제가 하는 진행하는 가상 환경이나 on-premise에서는 사용이 힘들 수 있습니다. 개념만 알아두자면 nodeport와 유사하지만 External IP가 클라우드 플랫폼에 맞춰 설정된다는 점이 다릅니다.

externalTrafficPolicy: 트래픽 분배를 결정하는 service 속성

LoadBalanacer service를 사용하면 외부로부터 들어온 요청은 각 노드 중 하나로 보내지며 그 노드에서 다시 pod 중 하나로 전달됩니다. NodePort 타입을 사용했을 때도 각 노드로 들어오는 요청은 다시 pod 중 하나로 전달됩니다. 그렇지만 이러한 요청 전달 원리는 경우에 따라 효율적이지 않은데 해당 예시를 위해 다음과 같은 상황을 가정합니다.

모든 노드에서 31000번 port가 개방되어 pod에 접근할수 있으며, 워커 노드 A, B에 pod가 각각 생성되어 있다고 가정해봅시다. 이때 워커 노드 A로 들어오는 요청은 (1) A에 위치한 a pod 또는 (2) B에 위치한 b pod중 하나로 전달됩니다. 이 때 A 노드로 들어오는 요청이 굳이 a pod로 전달되지 않고 b pod로 전달된다면 네트워크 hob이 한단 계 더 발생합니다. 그리고 노드 간의 redirect가 발생하게 되어 트래픽이 출발지 주소가 바뀌는 SNAT현상이 발생하게 되고 이로 인해 client IP주소 또한 보존되지 않습니다.

이러한 요청 전달 메커니즘은 service 속성 중 exeternalTrafficPolicy 항목에 정의되어있습니다. kubectl get -o yaml 명령어로 service의 모든 속성을 출력해 보면 externalTrafficPolicy가 Cluster로 설정되어있는 것을 알 수 있습니다.

Cluster값은 default설정값으로 클러스터의 모든 노드에 랜덤한 port를 개방하는 기존 방식입니다. 다음 service YAML 파일처럼 externalTrafficPolicy를 Local로 설정하면 pod가 생성한 노드에서만 pod로 접근할 수 있게하며 이는 추가적인 네트워크 hob이 발생하지 않으며 전달되는 요청의 client IP또한 보존됩니다.

# svc-local-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
  name: svc-local-nodeport
spec:
  externalTrafficPilicy: Local
  ports:
    - name: web-port
      port: 8080
      targetPort: 80
  selector:
    app: my-nginx
  type: NodePort

위의 yaml로 service을 실행시키면 다음과 같은 차이점을 보이게 됩니다.

ExternalName: 요청을 외부로 redirect하는 service

k8s를 외부 시스템과 연동해야할 때 사용하는 타입의 service입니다. External타입을 사용해 service를 생성하면 service가 외부 도메인을 가리키도록 설정가능하다. 예를 들어 아래의 설정대로 한다면 k8s 내부의 pod들이 externalname-svc라는 이름으로 요청을 보낼 경우, k8s의 DNS는 my.database.com으로 접근할 수 있도록 CNAME 레코드를 반환합니다. 즉, externalname-svc로 요청을 보내면 my.database.com에 접근하게 되는 것이다. 해당 service는 k8s와 별개로 레거시 시스템에 연동하는 경우에 사용된다.

CNAME은 Canonical Name의 약자로 도메인 주소를 또 다른 도메인 주소로 매핑 시키는 형태의 DNS 레코드 타입

# svc-external.yaml
apiVersion: v1
kind: Service
metadata:
  name: svc-externalname
spec:
  type: ExternalName
  externalName: my.database.com