머신러닝 시스템 설계 - Chapter 7. 모델 배포와 예측 서비스

배포 (deploy)는 일반적으로 모델을 실행하고 액세스 가능하게 함을 의미하는 포괄적인 용어

모델은 보통 개발 환경에서 실행되지만 모델을 배포하려면 개발 환경에서 벗어나야 함

모델을 테스트하기 위해 스테이징 환경에 배포하거나 최종 사용자가 사용할 프로덕션 환경에 배포

 

다양한 모델 배포

 

프로덕션은 다양한 스펙트럼에서 정의될 수 있음

어떤 팀에게 프로덕션이란 비즈니스 팀에 보여줄 플롯을 생성하는 일이지만 어떤 팀에게는 하루 수백만 명 사용자를 위해 모델을 계속 가동하는 것을 의미

상황에 따라 프로덕션 환경도 매우 다양하지만 일반적으로 두 번째 팀에 가까운 상황일 때 '배포'가 중요

 

'어려운 부분을 모두 무시하면 배포가 쉽다'라는 말처럼 단순한 배포는 매우 쉬움

특히 최근 들어 간단한 배포를 위한 도구와 코드들이 많이 제공되고 있음

단순히 모델 '배포'를 경험해보고 싶다면 Flask나 FastAPI로 POST 요청 엔드 포인트로 예측 함수를 래핑하고 예측 함수를 실행시킬 수 있는 패키지들을 컨테이너 이미지(도커 등)로 만든 후 엔드포인트를 노출하면 끝

 

어려운 부분은 사용자 수백만 명이 모델을 밀리초 단위 latency와 99% 가동 시간으로 사용하도록 하고, 문제 발생 시 적절한 사람에게 즉시 알리도록 인프라를 설정하고, 잘못된 부분을 파악하고 문제를 수정하기 위한 업데이트를 원활히 배포할 수 있도록 설정하는 부분

 

배포는 쉽지만 원하는 성능을 맞추는 배포는 매우 어려운 일

특히 회사에 따라 모델을 개발한 사람이 직접 배포하기도 하지만 다른 팀에서 배포하는 경우도 많음

책임 소재가 분할되면 의사소통을 위한 시간이 많아지고 모델 업데이트가 느려지며 문제 발생 시 원인 파악도 어려움

모델 배포와 관계없는 직무와 할 지라도 모델이 사용되는 방식을 이해하면 모델의 제약 조건을 이해하고 목적에 맞게 조정하는데 도움이 됨

 

< Note >

모델 내보내기란 모델을 다른 어플리케이션에서 사용할 수 있는 형식으로 변환하는 일로 직렬화(Serialization) 이라고 부르기도 함

 

내보낼 때는 모델의 정의와 모델 매개변수값을 내보냄

모델 정의는 레이어 갯수와 각 레이어의 유닛 개수 같은 모델 구조

모델 파라미터는 유닛과 레이어에 대한 학습된 값

 

텐서플로는 tf.keras.Model.save( ) 를 사용해 텐서플로의 SaveModel 형식

파이토치는 torch.onnx.export( ) 를 사용해 ONNX 형식

 

7. 1 머신러닝 배포에 대한 통념

 

ML 모델을 배포하는 일은 전통적인 소프트웨어를 배포하는 일과는 매우 다른 프로세스

모델 배포 경험이 없는 사람들은 이런 프로세스를 두려워하거나 혹은 과소평가하기도 함

아래 내용은 그런 사람들이 자주하는 실수들에 대해 다룸

 

7.1.1 통념 1: 한번에 한 두가지 머신러닝 모델만 배포

소규모 프로젝트나 학교에서만 배운 사람들은 ML 프로덕션을 단일 모델 맥락에서 생각하는 경향이 있음

이런 생각으로 설계한 인프라는 한 두개 모델만 지원하므로 실제 애플리케이션에는 작동하지 않음

 

기업에서는 하나의 어플리케이션을 위해 수많은 ML모델을 사용함

애플리케이션에는 다양한 기능이 있고 각 기능에는 자체 모델이 필요함

아래 그림들처럼 단일 기능에 여러 모델이 필요할 수도 있고 모델 하나가 여러 기능에 사용되기도 함

 

넷플릭스에서 ML을 활용하는 여러 작업 (출처 - https://www.infoq.com/presentations/netflix-ml-infrastructure)

 

Application 내 다양한 모델들

 

우버는 실제 수천 개 모델을 프로덕션에 적용하고 구글은 수천 억 개의 매개변수를 가진 모델 수천 개를 동시에 학습

따라서 모델을 프로덕션에 배포하기 전에는 다양한 모델들 간의 연계와 인프라적인 고려도 반드시 이뤄져야 함

 

7.1.2 통념 2: 아무것도 하지 않으면 모델 성능은 변하지 않음

 

소프트웨어는 시간에 따라 성능이 저하됨

시간이 지남에 따라 소프트웨어 자체는 변화가 없더라도 성능이 저하되는 현상을 소프트웨어 부패 (Software rot) 혹은 비트 부패 (bit rot)라고 함

 

이는 ML프로그램 역시 마찬가지로 마주치는 문제

거기다 ML시스템은 프로덕션에서 모델이 접하는 데이터 분포가 훈련된 데이터 분포와 다를 때 데이터 분포 시프트 (data distribution drift; data drift)를 겪음

따라서 ML모델은 훈련 직후에 가장 잘 수행되고 점점 성능이 저하되는 경향이 있음

 

7.1.3 통념 3: 모델을 자주 업데이트할 필요 없음

보통 모델을 한번 배포하고 나면 업데이트는 필요하지 않다고 생각하는 경우가 많음

흔히 하는 질문이 바로 "모델을 얼마나 자주 업데이트해야 하나요?"이지만 실제로 해야 하는 질문은 "모델을 얼마나 자주 업데이트할 수 있나요?"에 가까움

 

모델은 보통 시간에 따라 성능이 저하되므로 여건이 허락하는 한 최대한 빨리 업데이트해야함

(경우에 따라 시간이 지나도 반드시 성능이 저하되지는 않음)

프로덕션 환경에 ML모델을 적용하고 있는 많은 기업들은 매우 짧은 주기로 재학습을 진행하고 있음

 

하지만 실제로 모델 재학습과 재배포가 원활히 이루어지기 위해선 기존 데브옵스의 CI/CD를 많이 참고해야 함

적절한 인프라와 도구가 구축되지 않으면 재학습과 재배포는 매우 어려운 과정일 수 있음

 

7.1.4 통념 4: 대부분의 머신러닝 엔지니어는 스케일에 신경 쓰지 않아도 됨

'스케일'이 의미하는 바는 애플리케이션마다 다르지만 보통 애플리케이션이 처리해야 할 throughput을 맞추기 위해 자원을 조정하는 일을 의미함

예를 들어 초당 수백 개의 쿼리를 처리하거나 한 달에 수 백만명의 사용자를 처리하는 시스템 등이 있음

 

ML을 다루는 많은 사람들은 스케일링은 본인의 영역이 아니라 소프트웨어 공학자의 영역이라고 생각하는 경우가 많음

하지만 ML시스템을 둘러싸고 있는 영역은 SE가 담당할 수 있어도 모델 자체는 결국 ML엔지니어의 영역

어떤 스케일을 목표로 하고 있냐에 따라 모델의 설계부터 서빙 방식까지 많은 영향을 미치므로 꼭 고려해야 함

 

7.2 배치 예측 vs. 온라인 예측

 

시스템에서 예측 결과를 생성해 최종 사용자에게 서빙하는 방법(배치 예측 혹은 온라인 예측)은 최종 사용자와 시스템에서 작업하는 개발자 모두에게 큰 영향을 미침

시스템이 예측을 생성해 사용자에게 전달하는 방식은 크게 3가지 방식이 존재

 

예측 방식과 사용되는 피처들

 

• 배치 피처만 사용하는 배치 예측
• 배치 피처만 사용하는 온라인 예측 (사전 계산된 모델 예측값 등)
• 배치 피처와 온라인 (스트리밍) 피처를 모두 사용하는 온라인 예측 (스트리밍 예측 이라고도 함)

온라인 예측은 예측에 대한 요청이 도착하는 즉시 예측이 생성되고 반환되는 경우를 말하며 예를 들어 구글 번역에 문장을 입력하면 원하는 언어로 번역이 되는 프로세스를 생각하면 됨

온라인 예측은 On-Demand 예측이라고도 하며 일반적으로 RESTful API를 통해 전달됨

이렇게 HTTP 요청을 통해 전송될 때 온라인 예측은 요청과 동기식으로 생성되므로 동기 (Synchronous) 예측이라고도 함

 

배치 예측은 예측이 주기적으로 혹은 트리거 될 때마다 생성되는 경우를 말하며 예측 결과는 SQL테이블이나 인메모리 데이터베이스 같은 곳에 저장되고 필요에 따라 검색해서 사용함

배치 예측은 요청과 비동기식으로 생성되므로 비동기 (Asynchronous) 예측이라고도 함

 

< 용어 혼란 >

 

온라인 예측과 배치 예측이라는 용어에는 혼란을 줄 수 있는 포인트가 존재함

둘 다 한 번에 여러 샘플에 대해서도, 하나의 샘플에 대해서도 예측을 수행할 수 있음

혼란을 줄이기 위해 동기 예측, 비동기 예측이라는 용어를 선호하는 사람들도 있음

하지만 엄밀히 말해서 RESTful API를 사용해도 비동기식으로 처리할 수도 있으므로 이 용어도 명확한 구분은 아님

 

배치 피처만 사용하는 배치 예측과 온라인 예측 예시 (출처 - 머신러닝 시스템 설계 p249 각색)

 

배치 피처는 데이터베이스나 데이터 웨어하우스 등 과거 데이터를 바탕으로 계산된 피처

스트리밍 피처는 스트리밍 데이터에서 계산된 피처로 실시간 전송 데이터

배치 예측에서는 배치 피처만 사용하며 온라인 예측에서는 배치 피처와 스트리밍 피처를 모두 사용할 수 있음

 

< 스트리밍 피처 vs. 온라인 피처 >

 

스트리밍 피처와 온라인 피처를 같은 의미로 말하지만 엄밀히 말하면 서로 다른 용어

온라인 피처는 보다 일반적인 용어로 온라인 예측에서 사용되는 모든 피처를 뜻하고 여기에는 메모리에 저장된 피처도 포함

스트리밍 피처는 스트리링 데이터에서 계산된 피처만을 의미

 

배치 피처와 스트리밍 피처를 모두 사용하는 온라인 예측 예시 (출처 - 머신러닝 시스템 설계 p250 각색)

 

위 그림은 간단한 온라인 예측 아키텍처이며 스트리밍 피처와 배치 피처를 모두 사용

일부 기업에서는 이런 예측을 스트리밍 예측을 사용하지 않는 온라인 예측과 구분하기 위해 스트리밍 예측이라고도 부름

 

온라인 예측과 배치 예측이 상호 배타적일 필요는 없음

하이브리드 설루션으로 인기 있는 쿼리에 대한 예측은 미리 계산한 다음 덜 인기있는 쿼리에 대한 예측을 온라인으로 생성하는 것

 

	배치 예측 (동기)	온라인 예측 (비동기)
얼마나 자주 처리하는가?	주기적으로 처리	요청이 오면 바로 처리
어디에 사용하는가?	즉각적인 결과가 필요하지 않아 누적된 데이터를 처리하는 경우 (예: 추천 시스템)	데이터 샘플이 생성되는 즉시 예측해야 하는 경우 (예: 이상 거래 탐지)
무엇을 최적화하는가?	높은 throughput	짧은 latency

 

온라인 예측과 배치 예측은 하나의 애플리케이션 안에서도 서로 다른 유스케이스에 나란히 사용됨

배치 예측은 다량의 데이터를 한꺼번에 처리할 수 있어 처리량을 높이는데 특화되어 있고 온라인 예측은 요청에 대한 응답을 빨리할 수 있음

 

온라인 예측은 입력을 배치로 처리하지 못하고 벡터화나 기타 최적화 기술을 사용하지 못하므로 비용과 성능 측면에서 배치 예측에 비해 비효율적이라고 생각하기도 함

하지만 모든 상황에서 반드시 맞는 명제는 아님

게다가 요청을 보내지도 않은 사용자에 대한 예측을 미리 생성하는 (배치 예측) 것 역시 낭비되는 연산

 

7.2.1 배치 예측에서 온라인 예측으로

 

일반적으로 학계에서 처음 ML을 접하는 사람이라면 온라인 예측이 보다 자연스러움

다만 온라인 예측은 모델이 예측을 생성하는데 시간이 너무 오래 걸릴 수 있다는 단점이 있음

 

배치 예측은 예측을 미리 계산해 데이터베이스에 저장하고 요청이 도착할 때 결과만 가져오는 방식

배치 예측을 사용하면 분산 기술로 대량의 샘플을 효율적으로 처리해 여러 입력에 대한 예측을 한 번에 생성할 수 있음

 

예측을 미리 계산하므로 모델이 예측을 생성하는 데 얼마나 오래 걸릴지 걱정할 필요가 없음

따라서 복잡한 모델의 추론 레이턴시를 줄기가 위한 트릭으로 볼 수도 있음

예측을 검색하는 데 걸리는 시간은 일반적으로 예측을 생성하는 데 걸리는 시간보다 짧음

따라서 배치 예측은 예측을 많이 생성하되 결과가 즉시 필요하지 않을 때 유용함

 

하지만 배치 예측은 모델이 사용자의 선호도 변화에 덜 민감하다는 문제가 있음

또 다른 문제로 예측을 생성할 요청을 미리 알아야 한다는 점

어떤 요청이 들어올지 모르는 경우에는 배치 예측을 적용하기 어려움

 

일반적으로 배치 예측이 심각한 장애를 유발하진 않지만 경우에 따라 심각한 문제를 발생시키는 경우도 존재

온라인 예측이 필수적인 예로는 이상 거래 탐지, 자율 주행 자동차, 생체 인식 (지문, 페이스 아이디 등) 등이 있음

 

배치 예측은 온라인 예측이 충분히 저렴하지 않거나 충분히 빠르지 않을 때 유용

비용과 속도는 동일하면서 필요에 따라 예측을 생성할 수 있다면, 굳이 많은 예측을 미리 생성해 놓을 필요가 없음

최근 더 맞춤화되고 강력한 하드웨어가 등장하고 기술이 발전함에 따라

더 빠르고 저렴한 온라인 예측이 가능해지면서 온라인 예측이 기본이 됨

 

온라인 예측의 레이턴시 문제를 극복하려면 두 가지 구성 요소가 필요

• 실시간 파이프라인 - 수신 데이터로 작업하고, 필요에 따라 스트리밍 피처를 추출하고, 모델에 입력하고, 실시간으로 예측을 반환
  (거의 실시간 파이프라인)
• 최종 사용자가 만족할 속도로 예측을 생성하는 모델 - 대부분의 경우에선 밀리초 수준

 

7.2.2 배치 파이프라인과 스트리밍 파이프라인의 통합

 

기존 데이터 처리는 대량 데이터를 효율적으로 주기적으로 처리할 수 있는 배치 시스템이 주

따라서 온라인 예측에서 스트리밍 기능을 사용하려면 별도의 스트리밍 파이프라인을 구축해야 함

 

구글 지도와 같은 애플리케이션에서 도착 시간을 예측하는 모델을 구축한다고 하면

예측은 사용자의 여정이 진행됨에 따라 계속 업데이트됨

이때 사용할 피처는 지난 5분 동안 해당 경로에서 이동 중인 모든 차량의 평균 속도

훈련에는 지난달의 데이터를 사용하고 훈련 데이터에서 이 피처를 추출하려면 모든 데이터를 데이터프레임에 넣어 동시에 여러 훈련 샘플에 대해 이 피처를 계산함

추론하는 동안에는 피처는 슬라이딩 윈도에서 계속 계산됨

즉, 훈련에서는 피처가 배치 계산되는 반면 추론 중에는 스트리밍 프로세스에서 계산됨

 

이렇게 두 가지 파이프라인으로 데이터를 처리하는 것은 ML프로덕션에서 버그가 생기는 원인이 됨

한 가지 원인은 한 파이프라인의 변경 사항이 다른 파이프라인에 제대로 복제되지 않아 두 파이프라인에서 서로 다른 피처 집합 두 개가 추출되는 경우 (이런 문제는 나도 실제로 겪었다..)

 

훈련과 추론에 서로 다른 파이프라인 (출처 - 머신러닝 시스템 설계 p254 각색)

 

특히 서로 다른 팀에서 각 파이프라인을 유지보수하는 경우 더 큰 문제가 될 수 있음

 

온라인 예측을 수행하는 ML시스템 데이터 파이프라인 (출처 - 머신러닝 시스템 설계 p255 각색)

 

위 그림은 온라인 예측을 수행하는 ML 시스템 데이터 파이프라인을 더 상세하게 그린 것

연구 박스는 주로 연구에서 접하는 것들

 

스트림 처리와 배치 처리를 통합하기 위한 인프라 구축은 최근 인기 있는 주제

아파치 플링크 등과 같은 스트림 프로페서로 배치 처리 및 스트림 처리 파이프라인을 구축하기도 함

또 Feature store 등을 활용하기도 함

 

7.3 모델 압축

 

배포한 ML모델이 예측을 생성하는 데 너무 오래 걸릴 때 추론 레이턴시를 줄이기 위한 세 가지 주요 접근 방식

1. 추론을 더 빠르게 하기
2. 모델을 더 작게 만들기
3. 배포된 하드웨어가 더 빠르게 실행하도록 하기

여기서 모델을 더 작게 만드는 과정을 모델 압축이라고 하며 추론을 더 빠르게 하는 과정을 추론 최적화 라고 함

모델 압축은 원래 모델을 에지 디바이스에 적합하게 만드는 것이지만 모델이 작아지면 더 빠르게 실행되기도 함

모델을 압축하기 위한 주요 접근 방법은 저 차원 인수분해, 지식 증류, 가지 치기, 양자화 등이 있음

 

7.3.1 저차원 인수분해

 

저차원 인수분해 (low-rank factorization)의 핵심 아이디어는 고차원 텐서를 저차원 텐서로 대체하는 것

예를 들어 소형 합성곱 필터(compact convolutional filter)는 매개변수가 너무 많은 합성곱 필터를 소형 블록으로 대체

 

모바일넷의 소형 합성곱 필터 (출처 - https://greeksharifa.github.io/computer%20vision/2022/02/01/MobileNetV1/#google_vignette)

 

저차원 인수분해는 표준 모델에 비해 작은 모델을 빠른 속도로 개발하는데 사용

하지만 특정 모델 유형에만 적용되는 경향이 있고 모델을 설계하는 데 모델 아키텍처에 대한 높은 이해가 필요해 널리 적용되진 않음

 

7.3.2 지식 증류

 

지식 증류(Knowledge distillation)은 작은 모델(학생)이 더 큰 모델이나 앙상블(교사)을 모방하도록 훈련하는 방법

배포할 대상은 작은 모델(학생)

보통 작은 모델이 사전 훈련된 큰 모델을 모방하는 경우가 많지만 둘을 동시에 훈련할 수도 있음

프로덕션에 활용되는 예로는 DistilBERT가 있으며 기존 BERT보다 매개변수는 40% 적으면서 97%의 성능을 유지하고 60% 더 빠름

 

지식 증류의 장점은 교사와 학생 네트워크 간에 아키텍처가 달라도 작동한다는 점

예를 들어 학생 모델로 랜덤 포레스트, 교사 모델로 트랜스포머로 둘 수 있음

 

단점은 교사 네트워크의 가용성에 크게 의존한다는 점

사용 가능한 교사 모델이 없다면 교사 네트워크부터 학습해야 하는 데, 이를 위해 더 많은 데이터와 시간이 걸림

또한 애플리케이션과 모델 아키텍처에도 민감해 프로덕션에 널리 사용되진 않음

 

7.3.3 가지치기

 

가지치기(pruning)은 중요하지 않은 트리 섹션을 제거하는 Decision tree에 널리 사용되는 방법으로 분류 작업에 중요하지 않거나 중복된 트리 부분을 제거하는 방법

신경망에서도 매개변수가 과도하게 많은 부분을 제거하는 방법으로 사용됨

 

신경망 맥락에서 가지치기는 두 가지 의미가 있음

먼저, 신경망 전체 노드를 제거함으로써 아키텍처를 변경하고 매개변수를 줄이는 방법

 

일반적인 방법은 예츠에 가장 덜 유용한 매개변수를 찾아 0으로 설정하는 방법

총 매개변수 개수를 줄이는 것이 아니므로 신경망의 아키텍처는 그대로 유지도미

 

가지치기를 하면 신경망이 더 희소해져 모델 크기를 줄이는데 도움을 줌

어떤 방법으로 가지치기를 해야 더 효율적인가에 대해서는 아직 연구중

 

7.3.4 양자화

 

양자화(quantization)은 가장 일반적이며 흔히 사용되는 모델 압축 방법

간단하게 사용할 수 있어 여러 작업과 아키텍처에 활용됨

 

양자화는 매개변수를 나타내는 데 더 적은 비트를 사용하는 방법

일반적으로 대부분 32비트로 부동 소수점을 표시하며 이를 단정밀도(single precision) 부동 소수점(FP32)라고 함

모델 매개변수가 1억 개이고 각각 32비트라면 400메가바이트를 점유함

이를 16비트로 나타내면 메모리 공간을 절반으로 줄일 수 있음

16비트로 부동 소수점을 나타내는 것을 반정밀도(half precision; FP16)이라고 함

 

부동 소수점을 사용하는 대신 모델을 정수(8비트)로만 구성할 수도 있음

이 방법은 고정 소수점(fixed point)이라고 함

 

양자화는 memory footprint를 줄이고 계산 속도도 향상함

양자화를 통해 배치 크기를 늘릴 수 있고, 훈련 시간과 추론 레이턴시를 단축시킬 수 있음

 

양자화의 단점은 숫자를 나타내는 비트 수를 줄이면 나타낼 수 있는 값의 범위 또한 줄어든다는 점

범위를 벗어난 값은 반올림하거나 범위 내로 스케일링해야 함

반올림 시에는 반올림 오차가 발생하는데, 작은 반올림 오차가 성능을 크게 변화시킬 수 있음

또한 숫자를 언더플로 혹은 오버플로로 반올림 혹은 스케일링해 0으로 만들 위험도 존재

효율적인 반올림 및 스케일링을 저수준에서 구현하는 것이 중요하며 주요 프레임워크에 기능이 내장되어 있음

 

양자화는 훈련과정(양자화를 고려한 훈련; quantization aware training) 혹은 사후 훈련(post-training) 과정에서 수행 가능

훈련 과정에서 양자화할 때는 모델을 낮은 정밀도로 훈련

사후 훈련은 양자화할 때 FP32로 훈련된 모델을 추론을 위해 양자화

훈련 과정에서 양자화를 사용하면 동일한 하드웨어로 더 큰 모델을 훈련할 수 있음

 

7.4 클라우드와 에지에서의 머신러닝

 

모델 배포에는 모델 계산을 클라우드와 에지 어디에서 수행할지도 고려해야 함

클라우드에서 수행한다면 모델 연산이 클라우드에서 많이 일어남을 의미하고 에지에서 계산을 수행한다면 브라우저, 휴대전화, 노트북 등
소비자 디바이스(에지 디바이스)에서 많은 계산이 수행됨을 의미

 

가장 쉬운 방법은 AWS나 GCP같은 관리형 클라우드 서비스로 모델을 패키징하고 배포하는 방법

하지만 클라우드 배포에는 단점도 존재

가장 대표적인 단점은 클라우드 비용 문제로 ML 모델은 많은 연산을 필요로 하므로 많은 비용이 듦

 

클라우드 비용이 증가함에 따라 많은 기업들이 에지 디바이스에서 컴퓨팅을 수행할 수 있는 방법을 연구중

계산을 에지에서 많이 수행할수록 클라우드 컴퓨팅 비용이 줄어들기 때문

 

에지 컴퓨팅은 비용 외에도 많은 장점이 존재함

먼저, 클라우드 컴퓨팅이 불가능한 곳에서도 애플리케이션이 실행된다는 점

퍼블릭 클라우드 상에 모델이 있다면 안정적인 인터넷 연결이 필수적이지만 에지 컴퓨팅이라면 굳이 상관없음

 

다음으로, 모델이 이미 소비자의 디바이스에 있다면 네트워크 레이턴시에 대한 우려가 줄어듦

보통 전체 레이턴시에서 네트워크 레이턴시가 추론 레이턴시보다 훨씬 큰 비중을 차지함

 

에지 컴퓨팅은 민감한 사용자 데이터를 처리할 때도 유용

클라우드 상에 모델이 있다면 추론을 위해 사용자 데이터를 네트워크를 통해 보내야 하므로 보안에 취약해짐

 

모델 계산을 에지로 이동하려면 에지 디바이스가 계산을 처리할 수 있을만큼 강력해야 하고, ML모델을 저장하고 메모리에 올라기에 충분한 메모리가 있어야 하며 배터리가 충분하거나 적절한 시간동안 애플리케이션에 전원을 공급해줄 수 있어야 함

예를 들어 전체 BERT를 휴대전화에서 실행하면 배터리가 매우 빨리 소모

 

에지 컴퓨팅이 클라우드 컴퓨팅에 비해 많은 이점을 지니므로 많은 기업에서 연구 개발 중

 

7.4.1 에지 디바이스용 모델 컴파일 및 최적화

 

특정 프레임워크에서 개발한 모델이 하드웨어 백엔드에서 실행되려면 하드웨어 공급업체에서 해당 프레임워크를 지원해야 함

예를 들어 TPU는 2018년에 개발되었지만 파이토치는 2020년에야 TPU를 지원

하드웨어 백엔드에서 프레임워크에 대한 지원을 제공하는 것은 엔지니어링 노력이 많이 드는 문제

 

CPU, GPU, TPU에 따른 다양한 계산 기본 단위와 메모리 레이아웃 (출처 - TVM: An Automated End-to-End Optimizing Compiler for Deep Learning)

 

위 그림처럼 하드웨어 자원에 따라 계산 기본단위가 다르므로 효율적으로 사용하기 위해선 각 특성에 맞는 설계가 필요함

신규 하드웨어에 ML모델을 배포하려면 새로운 컴파일러와 라이브러리를 새로 개발하는 수작업이 필요함

 

이런 수작업 대신 프레임워크와 플랫폼을 연결한 중개자(중간표현; IR)를 통하는 방법도 있음

프레임워크 개발자는 모든 하드웨어 유형을 직접 지원할 필요없이 프레임워크 코드를 중개자로 변환하고 하드웨어 공급자는 여러 프레임워크가 아니라 중개자 하나만 지원

이런 프로세는 고수준의 프레임워크 코드를 저수준의 하드웨어 네이티브 코드로 '낮춘다'는 의미로 로어링(lowering)이라고 함

일반적으로 고수준 IR은 ML모델의 계산 그래프

 

모델 최적화

 

선택한 하드웨어에서 모델을 실행하기 위해 코드를 낮추고 나면 성능 문제가 발생할 수 있음

생성된 기계 코드는 하드웨어에서 실행은 될 수 있지만 효율적인 방식은 아닐 수 있음

 

프레임워크 내 개별 함수들은 최적화됐어도 프레임워크 전반에 걸친 최적화는 전혀 수행되지 않을 수 있음

이렇게 모델을 하드웨어에 맞춰 최적화하는 직군이 바로 ML 최적화 엔지니어

최적화 엔지니어는 ML과 하드웨어 아키텍처 양쪽에 대한 전문지식이 필요

코드까지 최적화 하는 최적화 컴파일러도 대안이 될 수 있음

최적화 컴파일러는 ML모델 코드를 기계 코드로 낮추는 과정에서 ML모델의 계산 그래프와 모델을 구성하는 연산자를 통해 속도를 높일 수 있는 방법을 찾음(모델 최적화 과정을 자동으로 수행)

 

ML모델을 최적화 하는 방법은 로컬과 전역으로 나뉨

로컬 최적화는 모델의 연산자 또는 연산자 집합을 최적화하며 전역 최적화는 전체 계산 그래프를 end-to-end로 최적화

모델 속도를 높이는 표준 로컬 최적화 기법들은 보통 작업을 병렬화하거나 칩의 메모리 엑세스를 줄임

 

벡터화 (Vectorizatin)

루프나 중첩 루프가 있는 경우 한번에 하나씩 수행하는 대신 메모리에 인접한 여러 요소를 동시에 실행해 I/O로 인한 레이턴시 감소

 

병렬화 (Parallelization)

입력 배열이 주어지면 이를 독립적인 청크로 나눈 후 청크가 개별적으로 수행될 수 있도록 함

 

루프 타일링 (Loop tiling)

루프에서 데이터 액세스 순서를 변경해 하드웨어의 메모리 레이아웃과 캐시를 활용함 (하드웨어에 따라 다름)

 

연산자 융합 (Operator fusion)

중복 메모리 액세스를 방지하기 위해 여러 연산자를 하나로 통합

 

머신러닝을 사용해 머신러닝 모델 최적화 하기

 

전통적인 최적화 방법은 경험을 바탕으로 모델의 계산 그래프를 가장 잘 실행하는 방법에 대한 휴리스틱을 생각해내는 최적화 엔지니어를 고용하는 방법

하지만 수작업으로 만든 휴리스틱은 최적이라는 보장이 없고 새로운 프레임워크나 하드웨어가 나오면 반복해야 한다는 단점이 존재

 

좋은 휴리스틱을 생각해내기 어렵다면 가능한 모든 방법으로 계산 그래프를 실행하는 단순한 방법이 존재

그러나 가능한 조합이 매우 많으므로 전체 경로를 탐색하기는 어려움

ML은 난해한 문제에 대한 솔루션을 잘 근사하므로 ML을 통해 검색 공간을 좁힐 수 있음

 

ML 기반 컴파일러는 결과는 좋지만 속도가 느리다는 단점이 존재

ML 모델이 복잡하다면 최적화만 며칠씩 걸릴수도 있음

하지만 이는 일회성 작업이며 최적화 검색 결과를 캐시해 기존 모델을 최적화하는 데 사용하거나 향후 개선 시 활용 가능

 

7.4.2 브라우저에서의 머신러닝

 

모델을 브라우저에서 실행한다면 어떤 하드웨어 백엔드에서든 실행 가능한 코드 생성 가능

해당 브라우저를 지원하는 모든 기기에서 실행이 가능함 (심지어 chip이 바뀌어도 관계없음)

 

TensorFlow.js, Synaptic, brain.js와 같은 도구를 통해 모델을 자바스크립트로 컴파일할 수 있음

하지만 js는 느리고 데이터 피처 추출과 같은 복잡한 로직을 구현하기 힘듦

 

웹어셈블리 (WebAssembly; WASM)은 다양한 언어로 작성된 프로그램을 웹 브라우저 상에서 실행하도록 해주는 개방형 표준

사이킷런, 파이토치, 텐서플로와 같은 프레임워크에서 모델을 빌드하고 특정 하드웨어에서 실행되도록 컴파일하는 대신 모델을 WASM으로 컴파일하면 js와 함께 사용하는 실행 파일이 생성됨

 

WASM의 주요 단점은 브라우저에서 실행돼 속도가 느리다는 점

 

7.5 정리

 

온라인 예측을 사용하면 모델이 사용자의 선호도 변경에 더 잘 반응하지만 추론 레이턴시라는 문제 발생

배치 예측은 모델이 예측을 생성하는 데 너무 오래 걸릴 때 해결책이 되지만 모델 유연성이 떨어짐

 

클라우드에서 추론을 수행한다면 설정은 쉽지만 네트워크 레이턴시와 클라우드 비용이 커질 수 있음

에지에서 추론을 수행하려면 충분한 연산 성능, 메모리 및 배터리를 갖춘 에지 디바이스가 필요함

하드웨어가 더 강력해지고 ML에 최적화된다면 ML시스템은 온디바이스의 온라인 예측으로 갈 가능성이 높음

 

출처 - 머신러닝 시스템 설계 p276 각색

 

 

<참고자료 - 머신러닝 시스템 설계>