no image
PEFT를 위한 AdapterFusion, QLoRA 훑어보기
PEFT 간단 정리이전에 파라미터 효율적인 파인튜닝(Parameter Efficient Fine-Tuning, PEFT)에 대해 글을 쓴 적이 있습니다.[Note/Deep Learning] - [NLP] LLM의 효율적인 Fine-Tuning을 진행하는 방법 | Parameter Efficient Fine-Tuning, PEFT위 글에서는 간단 개념만 설명했어서 이번에는 조금 더 자세한 정리 및 더 심화된 개념을 정리해보려고 합니다. AdapterAdpater는 기존 학습 모델 사이에 Adapter 모듈을 삽입하는 것을 제안하였습니다.Adpater는 bottleneck과 skip-connection으로 구성되어 다음과 같은 역할을 수행할 수 있도록 하고 있습니다. (추정하건데 ResNet의 내용들에서 적..
2024.12.27
no image
모델 경량화를 위한 양자화 관련 기본 개념 정리 | Quantization
기본개념양자화(Quantization)는 숫자의 정밀도(precision)를 낮추면서 모델을 최적화하고 경량화시킬 수 있는 기법입니다. 숫자의 정밀도가 낮춘다는 의미는 데이터의 자료형의 크기를 줄인다라고 볼 수 있습니다. 보통 딥러닝 모델의 매개변수를 구성하는 값들은 32비트 크기의 실수 자료형 숫자인데, 이를 8비트 크기의 정수 자료형 숫자로 전환하면서 경량화가 가능해집니다. 숫자의 정밀도가 낮아지면 아래와 같은 현상이 발생합니다.계산속도 향상메모리 사용량 감소오차 발생 또는 증가위와 같은 장점과 단점을 고려했을 때 적절한 낮은 정밀도 값으로 바꿀 수 있도록 하는 함수(Quantization Mapping)이 필요하게 됩니다. 그리고 양자화된 값을 복원(de-quantization) 과정을 거치게 되는..
2024.12.26
no image
딥러닝 모델 경량화를 위한 Knowledge Distillation 기본 개념 정리 | 지식 증류, KD
지식 증류의 기본 개념Knowledge Distillation(KD, 지식 증류)는 고성능의 모델(Teacher)에서 지식을 전달 받아 상대적으로 간단한 모델(Student)을 학습시키는 방법입니다. 전달하는 지식의 종류나 Teacher 모델의 유형에 따라 분류가 가능합니다.우선 Teacher 모델이 내부 구조, 파라미터를 공개 여부에 따라 White-box, Black-box, Gray-box로 구분됩니다. Black-box는 결과만 확인 가능한 경우며 White-box는 Llama 처럼 오픈소스로 모델의 내부 구조나 파라미터를 전부 알 수 있는 경우입니다. Gray-box는 그 중간으로 일부만 공개되어 있는 경우죠. 이러한 Teacher 모델의 특징에 의해 KD에 활용할 수 있는 정보의 종류가 달라지..
2024.12.25
no image
딥러닝 모델 경량화를 위한 Pruning 기본 개념 정리
Pruning 기본 개념과 복권 가설딥러닝 모델의 경량화를 위해 제안된 여러 개념 중 Pruning이라는 것이 있습니다. 사전 의미로 가지치기라는 뜻처럼 Pruning은 딥러닝 모델에서 노드(뉴런)나 연결(시냅스)을 제거해 모델의 크기와 계산 비용을 줄이는 방법입니다.Pruning을 뒷바침하는 이론으로 복권 가설(Lottery Ticker Hypothesis, LTH)이 있습니다. 이는 신경망 모델에서 일부를 잘 가지치기를 하면, 원래 모델과 같은 정도의 학습으로 동일한 효과를 얻을 수 있다는 가설입니다. 성공적인 pruning이 가능한 경우를 당첨 복권(winning ticket)이라 하며, 이에 대해 존재함을 실험적으로 증명했습니다.[1]Pruning이 이뤄지는 일반적인 절차는 다음과 같습니다.초기 ..
2024.12.24
no image
[boostcamp] 부스트캠프 AI Tech 18주차 돌아보기
1. 잘한 것수업과 과제를 모두 제시간에 마치고 제출했습니다.배운 내용들을 바로 정리했습니다.Leetcode, 백준 등 코딩 테스트 문제를 매일 풀었습니다.컴퍼니데이에 앞서 팀 소개를 위한 자료를 제가 주도적으로 작성하고 있습니다.2. 부족한 것사용하고 있는 랩탑의 제한으로 docker engine이 계속 꺼져서 더 많은 것을 시도해보지 못한 것이 아쉽습니다.컴퍼니데이를 신청하지 못해서 다른 기업에 대한 이야기를 듣지 못한 점이 아쉽습니다.3. 배운 것📖 FastAPI 확장 기능, FastAPI 구현하기 실습📖 Docker 주요 개념 정리, Docker Image 용량 최적화 방법론📖 Airflow 기초 개념 공부📖 MLflow 튜토리얼4. 시도할 것GitHub Actions에 대해 좀 더 익숙해..
2024.12.20
no image
클라우드 서비스의 기본 기술 개념 정리
Computing Service연산을 수행하는 가상의 컴퓨터로 일반적으로는 서버를 말합니다. CPU, 메모리, GPU 등을 선택합니다. 당연하겠지만, 이들의 성능이 좋아질수록 과금되는 금액이 비쌉니다. 클라우드 서비스를 이용하기 위해서는 인스턴스를 생성 후 인스턴스에 들어가서 사용이 가능합니다. 여기서 인스턴스란 클라우드 서비스에서 제공하는 서버 리소스를 말합니다. [1]예시 : AWS(EC2), Google Cloud (Compute Engine)Serverless Computing 컴퓨팅 서비스와 유사하지만, 서버 관리를 클라우드 쪽에서 진행하는 것을 말합니다. 컴퓨팅 서비스는 서버에서 오류가 나면 이용자가 디버깅을 해야하지만, 서버리스는 그럴 필요가 없습니다. 사용하기 위해서는 코드를 클라우드에 제..
2024.12.18
no image
[boostcamp] 부스트캠프 AI Tech 17주차 돌아보기
1. 잘한 것- 새로운 데이터 유형에 대한 분석 및 프로젝트를 시작했습니다. - 매번 배운 내용을 바로 정리했습니다.- Leetcode, 백준 등 코딩 테스트 문제를 풀었습니다. 2. 부족한 것- 수업, 과제에 대해 많은 진도를 나가지 못했습니다.- 새로운 데이터 유형(시계열)과 딥러닝에 대해 제대로 이해하지 못했습니다. 3. 배운 것- 머신러닝, 딥러닝의 프로덕트 서빙과 디자인 패턴 📖 머신러닝 / 딥러닝의 Product Serving과 디자인 패턴 - 생성형 이미지 모델들의 변천사 및 평가지표📖 온라인 서빙을 위한 웹에 대한 기본 지식 정리 | REST API📖 [Fast API] 파이썬으로 웹 구현하기 (1) | Parameter, Form, File, Request & Response Bod..
2024.12.13
no image
온라인 서빙을 위한 웹에 대한 기본 지식 정리 | REST API
온라인 서빙고려사항온라인 서빙은 실시간으로 클라이언트 요청에 대한 서비스를 제공해야 하는 구조 입니다. 따라서 고객 경험을 좋게 하기 위해서는 지연 시간(Latency)를 최소화할 필요가 있습니다. 이를 위해 고려할만한 사항은 다음과 같은 방법을 고려할 수 있습니다.데이터 전처리 서버 분리 (Feature를 미리 가공 등)모델 경량화병렬 처리예측 결과 캐싱 방법론온라인 서빙을 구현하기 위해서는 크게 3가지 방법론이 있습니다. 먼저 직접 웹서버를 구축하는 방식입니다. 머신러닝, 딥러닝은 보통 파이썬을 통해 구현되므로 파이썬의 대표적인 웹 프레임워크인 Flask나 FastAPI를 활용하는 것입니다. 자체적으로 서비스를 빠르게 만들 필요가 있을 때 고려해볼만한 방법입니다. 다음으로는 클라우드 서비스를 활용하는..
2024.12.12
no image
머신러닝 / 딥러닝의 Product Serving과 디자인 패턴
전체 개요 정의일반적인 IT 제품들은 요청(Request)에 대해 결과(예를 들어, 웹이나 앱의 화면)를 클라이언트에 제공하는 방식으로 이뤄집니다. 이는 음식점에서 종업원이 손님에게 음식을 서빙하는 것처럼 IT Product Serving이라 얘기할 수 있습니다. 그리고 Product라고 하는 것은 개발자가 만든 어떠한 산출물일 것이고요.  이를 머신러닝과 딥러닝 분야로 적용시키면 다음과 같습니다. 머신러닝/딥러닝 분야에서 Product Serving이란 모델의 예측 결과를 클라이언트에 제공하는 방식일 것입니다. 이 분야에서 Product는 연구 및 개발(R&D)단계에서 만든 모델을 일반적으로 사용할 수 있도록 배포하는 것입니다.  디자인 패턴소프트웨어 개발에 있어서 디자인 패턴이란 소프트웨어가 어떻게 ..
2024.12.10
반응형

PEFT 간단 정리

생성 이미지

이전에 파라미터 효율적인 파인튜닝(Parameter Efficient Fine-Tuning, PEFT)에 대해 글을 쓴 적이 있습니다.

[Note/Deep Learning] - [NLP] LLM의 효율적인 Fine-Tuning을 진행하는 방법 | Parameter Efficient Fine-Tuning, PEFT



위 글에서는 간단 개념만 설명했어서 이번에는 조금 더 자세한 정리 및 더 심화된 개념을 정리해보려고 합니다.

Adapter

Adpater는 기존 학습 모델 사이에 Adapter 모듈을 삽입하는 것을 제안하였습니다.Adpater는 bottleneck과 skip-connection으로 구성되어 다음과 같은 역할을 수행할 수 있도록 하고 있습니다. (추정하건데 ResNet의 내용들에서 적용을 시도해본 것이 아닐까 생각이 들기도 합니다)

  • Bottleneck : 하나의 행렬(d x d)을 두개의 작은행렬의 곱으로 바꾸는 Reparametrization Trick(d x m, m x d의 행렬 곱으로 바꾸는 것)을 통해 차원의 축소와 복구가 이뤄지는 효과. feed-forward down project에서 차원 축소. 비선형성 적용 후 feedforward up-project에서 다시 차원 확장(복구)
  • Skip-connection : bottleneck 이전 입력값의 차원으로 복구 후 더해주면서 적용

여기서 Adapter 당 추가되는 매개변수의 총 수는 2md + m + d이며, m(랭크)에 대한 조절을 통해 매개변수를 조절할 수 있습니다. 이에 대한 전반적인 개요는 아래와 같이 요약될 수 있습니다.[1]

Adapter 구조 [1]

LoRA

LoRA(Low Rank Adaptation)은 트랜스포머 구조의 Adapater와 유사하게 랭크 분해 행렬을 통해 차원을 나누지만, 이를 병렬적으로 위치시켜서 추론 과정에서 효율을 달성한 방법입니다. Adapter에서 처럼 Reparametrization Trick을 사용하지만, 위의 구조와 아래의 LoRA 구조가 다른 것은 순차적으로 진행되는 것들이 없다는 것입니다. 그리고 그에 따라 비선형 함수나 bias 파라미터도 사용하지 않고 있는데, 이로 인해 속도 측면에서 효율적이죠.

LoRA 구조 [2]

심화 개념 1. AdapterFusion

AdapterFusion은 이름처럼 여러 Adapter들을 결합하여 다양한 task를 해결하는 모델을 구축하는 것입니다. Fine-Tuning의 역할은 일반적으로 학습된 사전학습 모델을 우리가 해결하고 싶은 세부 task에 맞춰서 좀 더 잘 해결할 수 있도록 하는 것이 목적입니다. 그러는 과정에서 좀 더 효율적인 Fine-Tuning의 방법론으로 Adapter로 다양한 문제에 대해 Fine-Tuning을 수행한 Adapter를 만들 수 있게 됐죠. 이렇게 만들어진 Adapter는 특정 작업에는 성능이 좋을지 모르겟지만 범용적으로 사용하기 위해선 제한점이 있는데 이를 해결하기 위해 등장한 것이 AdapterFusion 입니다.



Fusion은 크게 두가지 알고리즘의 조합으로 구축됩니다. 먼저 Knowledge Extraction입니다. 이는 여러 개의 문제를 동일한 개수의 Adapter 파라미터로 학습하는 과정입니다. 이는 앞서 Adapter를 활용하는 것과 동일합니다.



다음으로 Knowledge Composition입니다. 이는 입력에 따라 Adapter를 어떻게 합칠지 결정하는 모듈인데, 이를 위해 이전에 개발된 방법 Attention에서 아이디어를 얻어 제안하고 있습니다. 먼저 병렬적으로 수행한 Adapter 연산들의 출력값을 취합합니다. 그리고 최적의 출력 생성을 위해 Adapter Attention을 수행합니다. Adapter Attention은 아래와 같이 동작합니다.

1) 이미 학습된 Adpater와 모델 파라미터는 고정
2) Self-Attention 수행 : 어떤 Adapter에 해당하는지(Q), Adapter별 출력(V), Adapter별 키(K)로 설정해 QKV의 Attention 메커니즘 동작


전반적인 동작 방식은 아래 그림처럼 표현될 수 있습니다.

AdapterFusion 구조 [3]

심화 개념 2. QLoRA

QLoRA는 이름에서 유추할 수 있듯이 LoRA에 Q(양자화)가 추가된 것입니다. PEFT의 가장 널리 사용되고 효과적인 방법인 LoRA에 경량화를 위한 양자화까지 추가했기 때문에 모델의 경제성을 높이는데 도움이 될만한 방법입니다. 이를 위해 크게 아래 2가지 방법이 사용됩니다.



먼저, 양자화 기법을 사용하는 것입니다. LoRA의 경우 BF16(Brain Floating Point 16)을 사용한다고 합니다. 이는 16비트를 부호(1 bit), 지수(8 bit), 가수(7 bit)에 할당하는 방식입니다. 이런 BF16을 NF4(4-bit Normal Float), 즉 부호(1 bit), 지수(1 bit), 가수(2 bit)에 할당하도록 바꾸는 것입니다.



여기에 더해 Double Quantization이라는 기법도 사용합니다. 양자화에서는 복원을 위해 양자화 상수(s, z)가 필요합니다. 관련 링크 보통은 양자화 상수 값은 복원을 위해 높은 정밀도로 저장을 하는데, Double Quantization은 이러한 상수 저장에도 추한번 더 양자화를 진행하는 것입니다. 다만, 위에서 사용하는 양자화 기법만큼 획기적으로 용량을 감축하는 것은 아닙니다.

참고자료

[1] Parameter-Efficient Transfer Learning for NLP
[2] LoRA: Low-Rank Adaptation of Large Language Models
[3] AdapterFusion: Non-Destructive Task Composition for Transfer Learning
[4] QLoRA: Efficient Finetuning of Quantized LLMs
[5] 조현수. "모델 최적화 및 경량화". boostcamp AI Tech.

반응형
반응형

기본개념

양자화(Quantization)는 숫자의 정밀도(precision)를 낮추면서 모델을 최적화하고 경량화시킬 수 있는 기법입니다. 숫자의 정밀도가 낮춘다는 의미는 데이터의 자료형의 크기를 줄인다라고 볼 수 있습니다. 보통 딥러닝 모델의 매개변수를 구성하는 값들은 32비트 크기의 실수 자료형 숫자인데, 이를 8비트 크기의 정수 자료형 숫자로 전환하면서 경량화가 가능해집니다. 숫자의 정밀도가 낮아지면 아래와 같은 현상이 발생합니다.

  • 계산속도 향상
  • 메모리 사용량 감소
  • 오차 발생 또는 증가

위와 같은 장점과 단점을 고려했을 때 적절한 낮은 정밀도 값으로 바꿀 수 있도록 하는 함수(Quantization Mapping)이 필요하게 됩니다. 그리고 양자화된 값을 복원(de-quantization) 과정을 거치게 되는데, 이를 위해 필요한 매개변수는 다음과 같습니다.

  • 양자화 방식
  • Quantized value (q) : 양자화 결과 값
  • Scale factor (s) : 양자화 방식에 따라 달라지는 기울기 값
  • Zero point (z) : 0의 양자화 후 위치

이를 식으로 간단히 표현하자면 아래와 같습니다.

q = round( x / s ) * s + z  # 양자화
x_hat = q * s - z           # 복원

생성 이미지

Absmax Quantization

Absmax는 양자화했을 때 변환 값들의 범위가 좌우 대칭이 되도록 변환하는 방법입니다. 값이 -127 ~ 127 사이에 위치할 수 있도록 조정하며, 0을 항상 0으로 보내는 것이 효과적인 경우에 채택합니다. (예를 들어, 하이퍼볼릭 탄젠트 함수를 사용하는 경우) 적용 방식은 아래 처럼 사용할 수 있습니다.

s = max(abs(x)) / 127
z = 0

다만, 이 방법은 극단적인 값에 예민할 수 있어 이를 완화하기 위해 Clipping 라는 기술을 활용 가능합니다. Clipping 기술은 일정 범주를 넘어갈 경우 동일한 값으로 취급합니다. 예를 들어, -5 ~ 5 를 넘어가는 경우 5의 값을 활용하는 방식이죠. 다만, 이렇게 적절한 범주를 찾는 과정이 필요한데, 이를 calibration 라고 합니다.

Zero-point Quantization

Zero-point는 0을 고려하지 않고 전체 범위를 균일하게 변환하는 방법입니다. 데이터 분포가 비대칭적이거나 평균이 0 이 아닌 경우(예를 들어, ReLU를 사용하는 경우) 사용할 수 있습니다. 위와 다르게 -128 ~ 127 사이에 위치하도록 조정하는 방식이며, 식은 아래와 같이 사용할 수 있습니다.

s = (max(X) - min(X)) / 255
z = -128 - round(min (X) / s)

참고자료

[1] 조현수. "모델 최적화 및 경량화". boostcamp AI Tech.

반응형
반응형

지식 증류의 기본 개념

수업 관련 생성 이미지 (by Diffusion)

Knowledge Distillation(KD, 지식 증류)는 고성능의 모델(Teacher)에서 지식을 전달 받아 상대적으로 간단한 모델(Student)을 학습시키는 방법입니다. 전달하는 지식의 종류나 Teacher 모델의 유형에 따라 분류가 가능합니다.

우선 Teacher 모델이 내부 구조, 파라미터를 공개 여부에 따라 White-box, Black-box, Gray-box로 구분됩니다. Black-box는 결과만 확인 가능한 경우며 White-box는 Llama 처럼 오픈소스로 모델의 내부 구조나 파라미터를 전부 알 수 있는 경우입니다. Gray-box는 그 중간으로 일부만 공개되어 있는 경우죠. 이러한 Teacher 모델의 특징에 의해 KD에 활용할 수 있는 정보의 종류가 달라지게 됩니다.

증류할 지식의 종류에 따른 분류는 다음과 같습니다. Response-based는 Black-box나 gray-box에 활용하고, 별도로 특징을 뽑을 수 있는 White-box는 Feature-based 접근 방식이 가능합니다.

  • Response-based : Teacher 모델의 logit이나 output 같은 응답을 활용
  • Feature-based : Teacher 모델의 중간 레이어의 feature, representation을 활용

Logit-based KD

Logit-based KD는 Response-based의 한 갈래로 정규화되지 않은 예측값인 logit을 활용하는 방법입니다. 오답에도 약간의 점수를 주기 때문에 모델의 강건성을 향상시키고, 연속된 형태이기이에 더 높은 엔트로피를 갖고 있으며, 하나의 클래스에서 다양한 인스턴스 차이나 클래스 간 유사도를 인식하는 등 장점이 있기 때문에 선호되는 방식입니다.

학습 방법

Teacher 모델은 Hard label(정답 클래스)로 학습을 진행하고 logit을 별도로 뽑아둡니다. 우리가 관심있는 Student 모델은 Hard label에 대한 학습(BCE loss 등)과 Teacher 모델의 logit 값을 Soft label로 해서(KL divergence) 두 개의 loss를 바탕으로 학습합니다. 두 손실을 섞는 방법은 하이퍼 파라미터로 실험을 통해 적절한 값을 찾는 것이 필요합니다.

여기서 클래스 간 logit의 차이가 극명하게 나거나 별로 나지 않을 수도 있습니다. 목적에 따라서 제대로 훈련이 되지 않을 수도 있으니 모든 클래스의 logit에 동일한 값(temperature, T)를 나누고 softmax를 적용하는 방법이 있습니다. 이는 기존 확률분포의 차이를 극명하게 또는 완만하게 될 수 있도록 변형을 가합니다.

  • T < 1 : 차이를 극명하게 만들 경우
  • T > 1 : 차이를 완만하게 만들 경우

Feature-based KD

Feature-based는 Teacher 모델이 특징을 Student 모델에 직접 활용하는 방식으로 모델의 구조, 파라미터 등을 알아야 사용이 가능합니다. (즉, White-box 경우)

학습 방법

Student 모델은 Teacher 모델보다 작기 때문에 차원을 맞춰주기 위한 regressor 층에 매핑합니다. 그리고 Teacher 모델과 Student 모델의 중간 층 피쳐맵에서 Mean Squared Error를 계산해서 훈련을 진행합니다. 여기서 중간 층의 피쳐맵을 사용하는 이유는 수행하려는 작업 데이터의 특징들이 층마다 다르게 분포하게 되는데, 중간 층이 양 극단의 중간 성격으로 섞여 있기 때문에 지식 증류에 효과적이기 때문입니다.

다른 방법들

Imitation Learning

앞서 언급한 방법들은 logit이나 특징들을 가져다 써야 가능한 방법이지만, ChatGPT처럼 거대하면서 좋은 성능을 가진 모델들은 Black-box인 경우가 많습니다. 따라서 이러한 거대 모델들을 지식 증류에 활용하기 위해 고안된 방법론으로 모방이 등장했습니다.

Imitation Learning은 LLM처럼 거대한 모델을 Teacher 모델로 삼고 질문에 대한 답변을 (질문-답변) 쌍을 데이터베이스로 저장합니다. 그리고 저장한 데이터 중 불필요한 내용들을 전처리하여 Student 모델의 학습에 활용하는 방식입니다. 좋은 성능을 가진 거대모델들이 등장한 현 시점에서 데이터 증강의 한 방식으로 활용하는 것이죠.

Multi-Teacher

여러 데이터 분석에서 성능 향상을 위해 흔하게 사용되는 방법으로 앙상블이 활용되곤 합니다. 여러 모델들의 결과를 종합해서 결과를 내는 방식인데, 이를 지식 증류에서도 활요이 가능합니다. 단일 모델의 한계를 극복할 수 있도록 여러 Teacher 모델을 앙상블하는 방식을 채택해 이를 학습하도록 하는 것입니다.

Cross-modal

최근 딥러닝 분야의 트렌드 중 하나는 여러 감각이 종합된 Multi-modal입니다. 이러한 트렌드에 맞춰 다른 modality(시각 - 청각, CV - NLP 등)를 가진 Teacher 모델에서 학습을 진행하는 것이 Cross-modal 입니다.

참고자료

[1] 조현수. "모델 최적화 및 경량화". boostcamp AI Tech.

반응형
반응형

Pruning 기본 개념과 복권 가설

딥러닝 모델의 경량화를 위해 제안된 여러 개념 중 Pruning이라는 것이 있습니다. 사전 의미로 가지치기라는 뜻처럼 Pruning은 딥러닝 모델에서 노드(뉴런)나 연결(시냅스)을 제거해 모델의 크기와 계산 비용을 줄이는 방법입니다.

가지 치기 이미지 생성 모델

Pruning을 뒷바침하는 이론으로 복권 가설(Lottery Ticker Hypothesis, LTH)이 있습니다. 이는 신경망 모델에서 일부를 잘 가지치기를 하면, 원래 모델과 같은 정도의 학습으로 동일한 효과를 얻을 수 있다는 가설입니다. 성공적인 pruning이 가능한 경우를 당첨 복권(winning ticket)이라 하며, 이에 대해 존재함을 실험적으로 증명했습니다.[1]


Pruning이 이뤄지는 일반적인 절차는 다음과 같습니다.

  1. 초기 모델 존재
  2. 제거 가능한 파라미터 판별
  3. 파라미터 제거
  4. 파인튜닝(fine-tuning)
  5. 최종 모델 도출

위 과정 중 2~4 부분에 대해 Pruning을 적용할 수 있는데 각 절차나 방법론에 따라 다음과 같이 분류할 수 있습니다.

Pruning의 분류

Structure

Pruning 단위에 따라 Unstructred와 Structured로 구분을 할 수 있습니다. Unstructred는 개별 파라미터 단위로 값을 0으로 변경하는데, 그러다보니 모델 구조의 변경이 수반되지 않습니다. Structured는 모델의 특정 구조(계층 등) 단위로 통째로 제거하는 방식으로 가지치기를 실행합니다. 그러다보니, 모델 구조 변경이 발생합니다.

Scoring

중요도(점수)를 계산해 덜 중요한 파라미터를 선정하는 방식에 따른 분류입니다. 여기서 방식은 점수를 계산하는 방법과 점수를 어떻게 반영할 것인지에 대한 방법론으로 구분할 수 있습니다.


점수를 계산하는 대표적인 방법은 파라미터의 절대값에 따라 작은 순으로 제거하는 방법과 구조 단위(레이어)별 Lp-norm을 계산해서 작은 순으로 제거하는 방법이 있씁니다.


중요도를 반영하는 방법으로 전체에서 비율을 적용하는 Global Pruning과 단위별로 비율을 적용하는 Local Pruning이 있습니다.

Scheduling

Pruning에서 파인튜닝에 대한 방법론에 대한 구분입니다. Pruning을 한번만 하는 One-shot과 여러 번에 나눠서 진행하는 Recursive가 있습니다. One-shot으로 진행할 경우 시간은 절약되나 성능이 좋지 않게 되고(Pruning 비율이 낮아짐), Recursive로 진행하게 되면 시간이 오래걸리나 성능이 좋아집니다.

Initialization

딥러닝의 훈련에서도 초기화가 중요한 이슈였습니다. Pruning 이후에 재학습 및 파인튜닝을 할 때 파라미터 초기화 여부에 따라 분류할 수 있습니다. 기존 모델의 가중치를 그대로 유지하고 파인튜닝을 진행하는 방법은 수렴은 빠르지만 성능이 불안정하게 됩니다. 반면, 초기화를 진행하고 재학습하는 방식(rewinding)은 성능이 좋지만 재학습이 필요하기 때문에 추가적인 자원이 필요합니다.

추가 고려사항

Matrix Sparsity

Sparsity는 전체 중 0의 비율을 의미하는 것으로 얼마나 데이터가 희소하냐는 것을 의미합니다. 앞서 Unstructured pruning은 파라미터를 개별적으로 0으로 바꾸는 방식이기 때문에 행렬에서 여전히 0을 저장하고 곱하는 연산이 남아 있습니다. 따라서 효율성이 바로 개선되지는 않죠.


이러한 문제를 해결하기 위해 크게 두가지 방법이 고려될 수 있습니다. 우선 Sparse Matrix Representation가 있는데 이미지 분할 문제에서 RLE 데이터 포맷처럼 데이터를 저장하는 방식입니다. 0이 아닌 값과 좌표를 Row, Column, Value의 3개 행으로 이뤄진 행렬로 구성합니다. 하지만, Sparsity가 1/3 미만일 때만 효율적입니다.


하지만, sparsity가 1/3을 넘어가는 애매한 정도라면 전용 하드웨어를 사용하는 것이 더 바람직합니다. 하드웨어에 대한 전문적인 지식은 없지만 대략적인 구동 방식은 곱셈 수행 전에 0의 위치를 파악하고, 해당 위치를 건너뛰고 계산되도록 조정하는 방식으로 연산을 수행합니다.

Sensitivity

네트워크가 복잡하거나 층별 특성이 다를 경우(즉, 다른 작업을 수행하기 위한 목적이 있는 경우) 파라미터나 층을 pruning 했을 때 성능 저하 정도를 민감도로 해서 측정 및 분석을 수행합니다. 민감도 분석 결과에 따라 민감도가 높으면 pruning ratio를 낮추고 민감도가 낮은 부분은 pruning ratio를 높이는 방식으로 대응하는 것이죠.


보통 민감도 분석은 성능 저하 정도를 실험적으로 측정합니다. 성능 저하 허용 범위(t %)를 고정하고, 이를 기준으로 레이어나 파라미터 별 prune ratio를 결정하는 방식이죠. 통상적으로 입력에 가까울수록 민감도가 높을 수 있습니다. 이는 신경망을 거치면서 정보가 점차 추상화되는데, 입력층에서는 추상화되기 전이기 때문에 더 크게 반응할 수 있습니다.

딥러닝에서 실제 활용

  • CNN

Convolutional Neural Network(CNN)는 합성곱 연산이 이뤄지는 CONV 층과 분류와 같은 문제를 해결하는 Fully Connected(FC) 층으로 나눠볼 수 있습니다. 파라미터는 FC 층에 있고, 복잡한 합성곱 연산은 CONV 층에 있기 때문에 개별로 pruning이 필요합니다.


CONV 층을 거칠 때마다 나오는 피쳐맵은 이미지의 의미를 담고 있는데, 여기서 중요한 피쳐맵과 그렇지 않은 것을 구분하고 pruning하는 것이 필요합니다. sparsity가 높은 피쳐맵일수록 별 의미가 없는 정보인 경우가 많기 때문에 sparsity를 기준으로 가지치기가 필요합니다. (실무적으론 L2-norm으로 sparsity를 계산한다고 합니다)[3]


  • BERT

Bidirectional Encoder Representation from Transformer(BERT)는 LLM 이전의 주요 언어 모델로 여러 개의 트랜스포머로 구성되어 작은 형태(단어)와 큰 형태(문장)을 인식하게 됩니다. 다만, 층마다 sparsity가 일관되지 않아 Structured 방법은 위험할 수 있습니다. 대신 층별로 local pruning을 적용하고, 대부분 파라미터가 0에 가깝기 때문에 절대값 기준으로 scoring을 하는 방법을 채택합니다.

참고자료

[1] Jonathon Fankle, Michael Carbin. "The Lottery Ticket Hypothesis: Finding Sparse, Trainable Neural Networks". ICLR 2019.
[2] https://www.geeksforgeeks.org/sparse-matrix-representation/
[3] Pavlo Molchanov, Stephen Tyree, Tero Karras, Timo Aila, Jan Kautz. "Pruning Convolutional Neural Networks for Resource Efficient Inference". ICLR 2017.
[4] Mitchell A. Gordon, Kevin Duh, Nicholas Andrews. "Compressing BERT: Studying the Effects of Weight Pruning on Transfer Learning".
[5] 조현수. "모델 최적화 및 경량화". boostcamp AI Tech.

반응형
반응형

1. 잘한 것

  • 수업과 과제를 모두 제시간에 마치고 제출했습니다.
  • 배운 내용들을 바로 정리했습니다.
  • Leetcode, 백준 등 코딩 테스트 문제를 매일 풀었습니다.
  • 컴퍼니데이에 앞서 팀 소개를 위한 자료를 제가 주도적으로 작성하고 있습니다.

2. 부족한 것

  • 사용하고 있는 랩탑의 제한으로 docker engine이 계속 꺼져서 더 많은 것을 시도해보지 못한 것이 아쉽습니다.
  • 컴퍼니데이를 신청하지 못해서 다른 기업에 대한 이야기를 듣지 못한 점이 아쉽습니다.

3. 배운 것

📖 FastAPI 확장 기능, FastAPI 구현하기 실습
📖 Docker 주요 개념 정리, Docker Image 용량 최적화 방법론
📖 Airflow 기초 개념 공부
📖 MLflow 튜토리얼


4. 시도할 것

  • GitHub Actions에 대해 좀 더 익숙해지기 위해서 관련 자료, 적용해볼 수 있는 시도를 고민해볼 예정입니다.
  • 부스트캠프에서 익숙해진 이미지 데이터셋과는 다른 데이터셋(시계열 등)에 대한 분석 방법을 dacon의 best practice 클론 코딩을 진행해볼 계획입니다.
반응형
반응형

Computing Service

연산을 수행하는 가상의 컴퓨터로 일반적으로는 서버를 말합니다. CPU, 메모리, GPU 등을 선택합니다. 당연하겠지만, 이들의 성능이 좋아질수록 과금되는 금액이 비쌉니다. 클라우드 서비스를 이용하기 위해서는 인스턴스를 생성 후 인스턴스에 들어가서 사용이 가능합니다. 여기서 인스턴스란 클라우드 서비스에서 제공하는 서버 리소스를 말합니다. [1]

  • 예시 : AWS(EC2), Google Cloud (Compute Engine)

Serverless Computing 

컴퓨팅 서비스와 유사하지만, 서버 관리를 클라우드 쪽에서 진행하는 것을 말합니다. 컴퓨팅 서비스는 서버에서 오류가 나면 이용자가 디버깅을 해야하지만, 서버리스는 그럴 필요가 없습니다. 사용하기 위해서는 코드를 클라우드에 제출하면, 그 코드를 가지고 서버를 실행합니다. 요청 부하에 따라 자동으로 확장되는 기능인 Auto Scaling 옵션도 있습니다.

  • 예시 : AWS (Lambda), Google Gloud (Cloud Function)

Stateless Computing 

컨테이너 기반으로 서버를 실행하는 구조를 말합니다. 여기서 Stateless란 컨테이너 외부(DB, 클라우드 저장소 ) 데이터를 저장하고, 컨테이너는 데이터로 동작하는 것입니다. 서버리스와 유사하게 요청 부하에 따라 자동으로 확장되는 기능인 Auto Scaling 옵션도 있습니다.

  • 예시 : AWS (ECS), Google Gloud (Cloud Run)

Object Storage 

다양한 형태의 데이터를 저장할 수 있는 저장소입니다. 이미지, csv 어떤 형태든 저장이 가능하며, API를 사용해 데이터에 접근합니다.

  • 예시 : AWS (S3), Google Gloud (Cloud Storage

Database 

클라우드 서비스에서 제공하는 데이터 저장소입니다. 보통 웹이나 앱 서비스에 연결해서 사용됩니다. 

  • 예시 : AWS (RDS), Google Gloud (Cloud SQL)

Data Warehouse 

데이터 웨어하우스는 데이터 저장소라는 점에서 동일하지만, 데이터 분석이라는 목적이 분명합니다. 데이터 분석에 특화된 데이터베이스로 분석을 위해서 DB, Object Storage의 데이터를 이동시킵니다. 

  • 예시 : AWS (Redshift), Google Gloud (BigQuery)

AI Platform  

머신러닝, 딥러닝 등 AI에 대한 수요가 늘어나면서 AI 연구 및 개발 과정을 편리하게 해주는 서비스도 많아지고 있습니다. 이를 도울 수 있는 다양한 제품과 MLOps 서비스를 제공하는 것을 AI Platform이라 합니다.

  • 예시 : AWS (Lambda), Google Gloud (Cloud Function)

Virtual Private Cloud (VPC)

 

VPC는 논리적으로 격리된 가상 네트워크입니다. 같은 네트워크이지만 보안상 이유로 분리를 했기 때문에 여러 서버를 하나의 네트워크로 묶는 개념이라고 볼 수 있습니다. VPC에서 추가적인 개념인 서브넷(subnet)은 VPC 안에서 여러 망으로 쪼개는 것으로 외부에서 접근 가능한 public subnet과 접근 불가능한 private subnet 로 구분됩니다. 라우팅 테이블은 네트워크 트래픽이 전달되는 위치를 결정합니다. [2]

참고자료

[1] https://aws.amazon.com/ko/what-is/cloud-instances/

[2] https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/what-is-amazon-vpc.html 

[3] 변성윤. "[Product Serving] 클라우드 서비스". boostcamp AI Tech. 

반응형
반응형

1. 잘한 것

- 새로운 데이터 유형에 대한 분석 및 프로젝트를 시작했습니다. 

- 매번 배운 내용을 바로 정리했습니다.

- Leetcode, 백준 등 코딩 테스트 문제를 풀었습니다.

 

2. 부족한 것

- 수업, 과제에 대해 많은 진도를 나가지 못했습니다.

- 새로운 데이터 유형(시계열)과 딥러닝에 대해 제대로 이해하지 못했습니다.

 

3. 배운 것

- 머신러닝, 딥러닝의 프로덕트 서빙과 디자인 패턴 

📖 머신러닝 / 딥러닝의 Product Serving과 디자인 패턴

 

- 생성형 이미지 모델들의 변천사 및 평가지표
📖 온라인 서빙을 위한 웹에 대한 기본 지식 정리 | REST API

📖 [Fast API] 파이썬으로 웹 구현하기 (1) | Parameter, Form, File, Request & Response Body

 

4. 시도할 것

- 원하는 결과를 얻지 못하더라도 프로젝트 잘 마무리하기 (kats 라이브러리 사용해보기) 

- 다른 데이터셋에 대한 분석 및 머신러닝/딥러닝 사이클을 클론 코딩 

반응형
반응형

온라인 서빙

고려사항

온라인 서빙은 실시간으로 클라이언트 요청에 대한 서비스를 제공해야 하는 구조 입니다. 따라서 고객 경험을 좋게 하기 위해서는 지연 시간(Latency)를 최소화할 필요가 있습니다. 이를 위해 고려할만한 사항은 다음과 같은 방법을 고려할 수 있습니다.

  • 데이터 전처리 서버 분리 (Feature를 미리 가공 등)
  • 모델 경량화
  • 병렬 처리
  • 예측 결과 캐싱

 

방법론

온라인 서빙을 구현하기 위해서는 크게 3가지 방법론이 있습니다. 먼저 직접 웹서버를 구축하는 방식입니다. 머신러닝, 딥러닝은 보통 파이썬을 통해 구현되므로 파이썬의 대표적인 웹 프레임워크인 Flask나 FastAPI를 활용하는 것입니다. 자체적으로 서비스를 빠르게 만들 필요가 있을 때 고려해볼만한 방법입니다.

 

다음으로는 클라우드 서비스를 활용하는 것입니다. AWS의 SageMaker나 GCP의 Vertex AI 등이 대표적인 사례입니다. 이러한 서비스들은 클라우드 회사에서 구축해놓은 기능을 활용하는 것이기 때문에 인력이 부족한 경우 사용을 고려할 수 있습니다만, 이미 만들어놓은 서비스를 활용하는 만큼 많은 비용이 청구될 수 있습니다. 또 이미 만들어진 기능이기 때문에 자유도가 떨어지는 문제도 있습니다.

 

마지막으로 오픈소스를 활용하는 방식입니다. Tensorflow Serving, Torch Serve, MLFlow, BentoML 등을 활용하는 방식입니다. 모든 방식에 장단점이 존재하므로 잘 비교해서 활용하는 것이 필요합니다.

 

서버 아키텍처

모놀리스 아키텍처

모놀리스 아키텍처, 영어로는 Monolithic Architecture는 하나의 큰 서버로 모든 로직들이 거대한 코드 베이스 하나로 개발되고 저장됩니다. 클라이언트는 서버(또는 로드 밸런서)에 요청하고 서버 내부에서 처리하는 방식입니다. 이 아키텍처는 배포해야 할 코드 프로젝트는 하나이기 때문에 초기에는 편리하나, 향후에는 복잡도가 증가하기 때문에 규모나 단계에 따라 바뀌어야 할 수도 있는 방식입니다.

 

마이크로 서비스 아키텍처

Micro Service Architecture는 작은 여러 개의 서버로 개발되고, 모든 로직이 개별 코드에 저장되는 방식입니다. 클라이언트는 하나의 서버에 요청하고 이 요청을 내부 (기능) 서버로 요청한 후에 내부 서버에서 처리하고 요청했던 서버로 반환합니다. 머신러닝, 딥러닝은 이 경우를 채택하는 경우가 많을 수 있습니다.

 

REST API

Representational State Transfer(REST) API는 통신 규약인 HTTP을 기반으로 하는 웹 기술을 기반으로 하는 인터페이스인 Web API 중 하나입니다. REST API는 자원을 표현하고 상태를 전송하는 것에 중점을 둔 Web API입니다.

 

REST API의 사용

REST API는 서버에 요청을 보내는 메서드와 대상인 URL로 구성되어 있습니다. 메서드는 서버에 요청을 보내는 방식으로 GET(조회), POST(생성), PUT(전체 업데이트), PATCH(부분 업데이트), DELETE(삭제)가 있습니다.

 

URL은 인터넷 상 자원을 식별하기 위한 위치를 찾는 방식으로 프로토콜(HTTP와 같이 표기), 호스트(IP나 도메인으로 표기), 포트, URL 파라미터로 이뤄져 있습니다.

 

여기서 IP는 네트워크에 연결된 특정 PC의 주소 체계(Internet Protocl)을 말하며, 숫자 덩어리의 숫자에 따라 IPv4, IPv6로 구분됩니다. 그리고 IP 주소 뒤에 나오는 숫자인 포트는 PC에 접속할 수 있는 통로를 의미합니다.

 

URL 파라미터

URL 파라미터는 인터넷 상 자원의 위치를 찾기 위한 URL 내에서 특정 자원을 구분짓기 위한 방법입니다. 크게 쿼리 파라미터와 패스 파라미터가 있으며, 우선 쿼리 파라미터부터 살펴보겠습니다.

 

쿼리 파라미터는 URL 끝에 추가하면서 특정 리소스의 추가 정보 제공 또는 데이터를 필터링할 때 사용합니다. 이는 선택적 정보를 정렬, 필터링해야 하는 경우에 사용하면 좋습니다. 쿼리 파라미터는 아래와 같이 표현됩니다.

패스(Path) 파라미터는 리소스의 정확한 위치나 특정 리소스를 찾을 때 사용합니다. 패스 파라미터는 필수적인 정보에 대해 식별해야 하는 경우 사용하면 좋습니다. 패스 파라미터는 아래와 같이 표현됩니다.

 

HTTP 헤더와 페이로드

헤더는 클라이언트와 서버의 요청과 응답에서 주고받는 문자열의 리스트를 말합니다.[2] 페이로드(Payload)란 전송되는 데이터를 말합니다.[3] 아래 이미지에서 보면 헤더를 확인할 수 있습니다. 방법은 참고 자료를 보시면서 따라하면 됩니다. [4]

 

 

앞서 말한 메서드와 URL 외에도 헤더와 페이로드를 사용해서 요청도 가능합니다. 한번 예시를 들어보겠습니다. 각 요소들에 대한 설명은 아래에 첨부하겠습니다.

 

curl -X POST -H "Content-Type: application/json" -d '{"name":"who"}' http://localhost:8080/users

 

  • curl : 터미널에서 HTTP 요청할 때 사용하는 도구
  • -X POST : HTTP 메서드로 POST 사용
  • -H "Content-Type: application/json" : 헤더에 Content-Type: application/json 라는 key: value를 추가 
  • -d '{"name":"who"}' : 페이로드로 json을 추가 
  • http://localhost:8080/users : URL로 어디로 요청을 보낼까를 명시

 

참고자료

[1] 변성윤. "[Product Serving] 웹 프로그래밍 지식". boostcamp AI Tech.
[2] https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

[3] https://hanamon.kr/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-http-%ED%8E%98%EC%9D%B4%EB%A1%9C%EB%93%9C-payload%EB%9E%80/

[4] https://www.kyumin.blog/6

 

반응형
반응형

전체 개요 

정의

일반적인 IT 제품들은 요청(Request)에 대해 결과(예를 들어, 웹이나 앱의 화면)를 클라이언트에 제공하는 방식으로 이뤄집니다. 이는 음식점에서 종업원이 손님에게 음식을 서빙하는 것처럼 IT Product Serving이라 얘기할 수 있습니다. 그리고 Product라고 하는 것은 개발자가 만든 어떠한 산출물일 것이고요. 

 

이를 머신러닝과 딥러닝 분야로 적용시키면 다음과 같습니다. 머신러닝/딥러닝 분야에서 Product Serving이란 모델의 예측 결과를 클라이언트에 제공하는 방식일 것입니다. 이 분야에서 Product는 연구 및 개발(R&D)단계에서 만든 모델을 일반적으로 사용할 수 있도록 배포하는 것입니다. 

 

디자인 패턴

소프트웨어 개발에 있어서 디자인 패턴이란 소프트웨어가 어떻게 구성되고 작동할지에 대한 설계하는 공통적인 방식을 일컫습니다. 소프트웨어 개발은 기본적으로 귀찮은 것을 싫어하는 사람들이 많기에 코드의 재사용성, 가독성, 확장성을 높일 수 있도록 디자인 패턴들이 다양하게 고안됐습니다.

 

머신러닝/딥러닝 분야에서도 디자인 패턴이 있는데, 기존 소프트웨어 개발과 달리 데이터, 모델, 코드를 모두 고려해야 하는 특수성이 있습니다. 아래는 고려해야 하는 세부적 요소를 나열한 것 입니다.

  • 대용량 모델 로드
  • 모델 관리
  • 데이터 전처리
  • 이상치 제외
  • 모델 연산 시간

종류

머신러닝 / 딥러닝에서 Product Serving에는 크게 배치(Batch Serving)와 온라인(Online Serving) 두가지로 나눌 수 있습니다. 우선 배치는 데이터를 일정 묶음(배치)으로 나눠서 처리하는 방식이 있습니다. 예를 들어, 매월 말에 처리하는 방식이 있을 수 있습니다. 이는 실시간 응답이 중요하지 않고 대용량 데이터를 처리해야 할 필요가 있을 때 활용할 수 있습니다.

 

다음으로 온라인 방식은 실시간으로 클라이언트가 요청할 때 서빙하는 방식입니다. 예를 들어, 번역처럼 실시간 응답이 중요하거나 개별 맞춤,데이터가 실시간으로 변한다면 이 방식을 채택하는 것이 적절할 것입니다. 

 

그렇다면 위 두가지 방식에 대한 디자인 패턴 사례를 살펴보도록 하겠습니다. 소개할 방식은 배치 방식의 배치 패턴과 온라인 방식의 Web Single, Synchronous, Asynchronous 패턴입니다. 이외에도 다양한 패턴을 아래 링크에서 확인할 수 있습니다.

ml-system-design-pattern | System design patterns for machine learning

 

ml-system-design-pattern

System design patterns for machine learning

mercari.github.io

디자인 패턴 사례

Batch

배치 패턴은 주기적으로 예측 결과를 데이터베이스에 저장하고 활용하는 쪽은 데이터베이스에서 결과를 읽어서 사용하는 방식을 채택합니다. 패턴의 다이어그램은 다음과 같이 나타낼 수 있습니다.

 

배치 패턴 [2]

 

위 다이어그램에서 나타나는 것 중 주요 구성 요소는 다음과 같으며, 이에 대한 역할은 다음과 같습니다.

  • Job Management Server : 작업을 실행하는 서버, Apache Airflow 등을 주로 사용, 특정 시간에 Batch job 실행
  • Job : 어떤 작업 실행에 필요한 모든 활동(모델 로드, 데이터 로드 )으로 Python 스크립트로 실행하거나 Docker Image 실행
  • Data : 서비스에서 사용하는 DB 데이터 웨어하우스에 저장. 데이터를 불러오는 스케줄링 job 존재.

배치 패턴은 기존 코드를 재사용 가능하고, API 서버를 개발하지 않아도 되기 때문에 빠르게 제품을 출시하거나 테스트할 경우 유용합니다. 그리고 남는 서버 리소스를 추가 투입할 수도 있기 때문에 유연하게 서버 관리가 가능하다는 장점도 있습니다. 하지만, 별도의 스케줄러를 고려해야 한다는 단점도 있습니다. 

Web Single

Web Single 방식은 API 서버 코드에 모델을 포함시켜 배포하는 방식입니다. 이후에 예측이 필요한 곳(클라이언트, 서버 등)에서 필요할 때 직접 요청하는 방식으로 모델의 결과를 반환합니다. 패턴의 다이어그램은 다음과 같이 나타낼 수 있습니다.

 

Web Single 패턴 [3]

 

위 다이어그램에서 나타나는 것 중 주요 구성 요소는 다음과 같으며, 이에 대한 역할은 다음과 같습니다.

  • REST Server : API 서버가 실행될 모델을 로드하고 전처리도 같이 포함. FastAPI, Flask 단일 REST API 서버 개발 배포
  • Client : 앱에서 직접 요청하거나 서비스 서버에 요청해서 실행 가능.
  • Data : 요청할 같이 데이터를 담아 요청. 상황에 따라 데이터 용량 제한 가능.
  • Load Balancer : 트래픽을 분산시켜 과부하 방지 (Ngnix, Amazon ELB 사용)

Web Single 패턴은 하나의 프로그래밍 언어로 아키텍처를 단순하게 작성할 수 있습니다. 그렇기 때문에 빠른 출시와 실시간 결과를 얻을 때 활용할 수 있씁니다. 하지만, 구성 요소 중 하나만 바뀌어도 전체 업데이트가 필요하기 때문에 정식 제품으로 활용하기에는 유지-보수 관점에서 적절하지는 않습니다. 또한, 모델을 직접 로드하기 때문에 큰 모델의 경우 시간이 소요되고 서버 부하 가능성도 있어 모니터링이 필요합니다.  

Synchronous

동기(Synchronous) 방식은 Web Single과 거의 유사하며, 예측이 완료될 때까지 워크플로우를 중단합니다. 패턴의 다이어그램은 다음과 같이 나타낼 수 있습니다.

 

Synchronous 패턴 [4]

 

이 패턴은 Web Single과 거의 유사해서 아키텍처와 처리하는 입장에서 워크플로우가 단순합니다. 하지만, 예측 결과가 나오는 시간에 따라 워크플로우가 중단되기 때문에 병목현상이 발생할 수 있어서 많은 사람이 이용하는 서비스에는 사용이 적합하지 않습니다. 그래도 비교적 간단하게 예측 결과에 따라 클라이언트 로직이 달라져야 할 경우 사용하면 좋은 방식입니다. 

Asynchronous

이 패턴은 Synchronous가 하나의 작업이 시작하고 결과를 기다리는 동안의 문제를 해결하기 위해 등장한 것으로 그동안 다른 작업을 수행하는 패턴입니다. 패턴의 다이어그램은 다음과 같이 나타낼 수 있습니다.

Asynchronous 패턴 [5]

 

여기서 눈에 띄는 구성요소는 Queue로 클라이언트와 예측 서버 사이의 메시지 역할을 수행합니다. 이로써 클라이언트와 예측 프로세스를 분리하여 의존성을 해소하는 효과가 있지만, Queue라는 새로운 구성요소를 만들어야 하고 중간에 한번 거치는 것 때문에 완전한 실시간 예측이 불가능하다는 단점이 있습니다.

참고자료

[1] 변성윤. "[Product Serving] Serving의 정의와 다양한 패턴". boostcamp AI Tech.

[2] https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Batch-pattern/design_en.html

[3] https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Web-single-pattern/design_en.html

[4] https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Synchronous-pattern/design_en.html

[5] https://mercari.github.io/ml-system-design-pattern/Serving-patterns/Asynchronous-pattern/design_en.html

반응형