[ML] 머신러닝 시스템 설계 : 7장 모델 배포와 예측 서비스

gunny·2023년 5월 24일

Designing Machine Learning Systems 머신러닝 시스템 설계 머신러닝 시스템 설계 7장 머신러닝 시스템 설계 7장 모델 배포와 예측 서비스 모델 배포와 예측 서비스

ML

목록 보기

7/17

해당 게시물은 ML 프로덕션 환경 속에 있는 내가 모델 개발에만 열중하고 전반적인 시스템 설계에 대한 배경지식이 없었던 와중에 옆자리 팀원한테 추천 받아서 읽게된 한빛미디어의 "머신러닝 시스템 설계"를 공부하면서 요약한 게시물로, 저작권은 한빛미디어에게 있겠습니다.

7. 모델 배포와 예측 서비스

배포(deploy)는 '모델을 실행하고 액세스 가능하게 함' 을 의미하는 포괄적인 용어
-모델은 개발 중에는 보통 개발 환경에서 실행되지만 모델을 배포하려면 개발 환경에서 벗어난다.
테스트를 위해 모델을 스테이징 환경에 배포하거나, 최종 사용자가 사용할 프로덕션 환경에 배포한다.
프로덕션은 다양한 스펙트럼에서 정의 될 수 있는데, 어떤 팀에게 프로덕션은 비즈니스 팀에게 보여줄 플롯을 생성하는 것이고 어떤 팀에게는 수백만 명 사용자를 위해 모델을 계속 가동하는 것을 의미한다.
단순하게 플라스크나 FastAPI로 POST 요청 엔드 포인트로 예측 함수를 래핑하고 배포하는 것은 쉽지만, 사용자 수백만 명이 모델을 밀리초 단위 레이턴시와 99% 가동 시간으로 사용하게 하고, 문제 발생 시 적절한 사람에게 즉시 알리도록 일프라를 설정하고 잘못된 부분을 파악하여 문제를 수정하기 위해 업데이트를 원활하게 하는 부분은 어렵다.
모델을 개발한 사람이 직접 배포하기도 하고, 배포 준비를 마치면 모델을 보내서 다른 팀에서 배포하기도 하는데 후자처럼 분리하면 팀 간에 소통 하는데 드는 시간이 많아지고 모델 업데이트가 느리지며 문제 발생 시 디버깅시 어려워진다.

모델 내보내기
=> 모델을 다른 애플리케이션에서 사용할 수 있는 형식으로 변환(직렬화 serialization)
모델의 정의와 모델 매개변숫값을 내보내는데, 모델 정의는 히든 레이어 개수나 각 레이어의 유닛 개수 같은 모델 구조를 정의하고 모델 매개변숫값은 이러한 유닛과 레이어에 대한 값을 제공함.

7-1. 머신러닝 배포 통념

ML 모델 배포는 전통적인 소프트웨어 프로그램 배포와 다름

통념 1. 한 번에 한두 가지 머신러닝 모델만 배포함
: 학계 사람들은 ML 프로덕션을 단일 모델 맥락에서 생각하는 경향이 있음
기업에서는 수많은 ML 모델을 보유하고 있음
예를 들어 우버같은 경우 이동 수요, 운전사 가용성, 예상 도착 시간, 동적 가격 책정, 이상 거래, 고객 이탈 등 각 요소를 예측하는 모델이 필요함
앱이 20개 국가에서 운영된다면 국가마다 고유한 모델 세트가 필요하여, 일반화 되는 모델을 만들 수 있을 때까지 국가가 20개, 국가마다 모델이 10개로 모델은 벌써 200개가 됨
실제로 우버에서도 수천 개 모델을 프로덕션에 적용함.
구글은 항상 수천 억 개의 매개변수 크기를 가진 모델 수천 개를 동시에 훈련함

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

소프트웨어는 숙성되지 않고 노화됨
시간에 따라 소프트웨어 프로그램이 변화가 없어 보여도 성능이 저하되는 현상을 소프트웨어 부패(sofrtwar rot), 비트 부패(bit rot) 라고 함
ML 시스템도 마찬가지임. ML 시스템은 프로덕션에서 모델이 접하는 데이터 분포가 훈련된 데이터 분포와 다를 때 데이터 분포 시프트(data distribution shift)라는 문제를 겪음
ML 모델은 훈련 직후에 가장 잘 수행되고 점점 성능이 저하되는 경향이 있음

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

모델을 얼마나 자주 업데이트 해야 하나요? 가 아니라 '모델을 얼마나 자주 업데이트 할 수 있나요?' 임
모델 성능은 시간에 따라 저하되어 최대한 빨리 업데이트 해야 함
엣시는 하루에 50회, 넷플릭스는 하루에 수천 회, aws는 11.7초마다 배포함
많은 회사가 한 달에 한 번 분기에 한 번만 모델을 업데이트 하지만, 웨이보에서는 ML 모델을 10분마다 업데이트하고 알리바바나 바이트댄스 등도 비슷함

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

'스케일'이 의미하는 바는 애플리케이션마다 다르지만, 초당 수백 개의 쿼리를 처리하거나 한 달에 수백만 명의 사용자를 처리하는 시스템이 있음
ML 애플리케이션을 확장할 수 있어야 하므로, ML 엔지니어는 스테일에 신경써야 함

7-2. 배치 예측 VS 온라인 예측

시스템이 예측 결과를 생성해 최종 사용자에게 서빙하는 방법(배치 예측 또는 온라인 예측)은 최종 사용자와 시스템에서 작업하는 개발자 모두에게 영향을 미침
배치 피처만 사용하는 배치 예측, 배치 피처만 사용하는 온라인 예측(예: 사전 게산된 임베딩), 배치 피처와 스트리밍 피처를 모두 사용하는 온라인 예측(스트리밍 예측)
온라인 예측은 예측에 대한 요청이 도착하는 즉시 예측이 생성되고 반환되는 경우로, 구글 번역에 영어 문장을 입력하는 즉시 프랑스어 번역문이 들어오는 것이다. 온라인 예측을 온디맨드(ON-DEMAND) 예측이라고 함
일반적으로 온라인 예측을 수행할 때는 RESTFul API를 통해 요청이 예측 서비스로 전송됨. 예측 요청이 HTTP 요청을 통해 전송될 때 온라인 예측은 요청과 동기식으로 생성되므로 동기(synchronous) 예측이라고도 함
배치 예측은 예측이 주기적으로 혹은 트리거 될 때마다 생성되는 경우임.
예측 결과는 SQL 테이블이나 인메모리(in-memory) 데이터베이스 같은 곳에 저장되고 필요에 따라 검색됨
넷플릭스는 네 시간마다 모든 사용자에 대한 영화 추천을 생성하고, 사용자가 넷플릭스에 로근할 때 사전 계산된 추천을 가져와서 표시해줌
배치 예측은 요청과 비동기식으로 생성되므로, 비동기(asynchronous) 예측이라고 함

용어 혼란
온라인 예측과 배치 예측이라는 용어는 혼란을 야기할 수 있음
둘다 한 번에 여러 샘플(배치 처리)에 대해서도 하나의 샘플에 대해서도 예측을 수행할 수 있음
그래서 때때로 동기 예측과 비동기 예측이라는 용어를 선호하는데, 다만 온라인 예측이 실시간 전송으로 모델에 예측 요청을 보낼 때는 요청과 예측이 기술적으로 엄밀히 말하자면 비동기식이라 이렇나 구분도 완벽하지는 않음
배치 피처는 데이터베이스나 데이터 웨어하우스의 데이터 같은 과거 데이터에서 계산된 피처임
스트리밍 피처는 스트리밍 데이터에서 계산된 피처, 즉 실시간 전송 데이터로 배치 예측에서는 배치 피처만 사용하며 온라인 예측에서는 배치 피처와 스트리밍 피처를 모두 사용할 수 있음
예를 들어 음식 배달 플랫폼 도어대시(DoorDsh)에서 사용자가 음식을 주문했다면 배송 시간을 추정하는데 다음 피처 가 필요 함
배치 피처 : 과거 이 식당의 평균 음식 준비 시간
스트리밍 피처 : 지난 10분 동안 해당 건 외에 들어온 주문 건수, 가용한 배달 인력 명수

스트리밍 피처 vs 온라인 피처

스트리밍 피처와 온라인 피처를 같은 의미로 사용하기도 하지만 두 용어는 사실 서로 다름
온라인 피처는 보다 일반적인 용어로 온라인 예측에 사용되는 모든 피처를 의미하고 여기에는 메모리에 저장된 배치 피처도 포함됨
온라인 예측은 특히 세션 기반 추천에 사용되는 매우 일반적인 유형의 배치 피처는 아이템 임베딩(item embedding)임
아이템 임베딩은 보통 배치 처리로 사전 계산해 온라인 예측에 필요할 때마다 가져옴. 이 때 임베딩은 스트리밍 피처가 아닌 온라인 피처로 간주됨
스트리밍 피처는 스트리밍 데이터에서 계산된 피처만을 의미함
온라인 예측과 배치 예측이 상호 배타적일 필요는 없고, 한가지 하이브리드 솔루션은 인기 있는 쿼리에 대한 예측을 미리 계산한 다음 덜 인기 있는 쿼리에 대한 예측을 온라인으로 생성하는 방법도 있음
온라인 예측과 배치 예측에 대해 고려해야 할 핵심 사항으로는
- 배치 예측 (동기) : 주기적으로 처리(예 4시간 마다), 즉각적인 결과가 필요하지 않아 누적된 데이터를 처리하는 경우(추천 시스템), 높은 스루풋을 최적화
- 온라인 예측(비동기) : 요청이 오면 바로 처리, 데이터 샘플이 생성되는 즉시 예측해야 하는 경우(예: 이상거래 탐지), 짧은 레이턴시
많은 애플리케이션에서 온라인 예측과 배치 예측은 서로 다른 유스 케이스에 나란히 용됨
도어대시나 우버이츠 같은 음식 배달 앱은 식당 추천을 생성할 때 배치 예측을 사용하고, 식당이 많으므로 온라인으로 추천을 생성하려면 너무 오래 걸림.
한 편 특정 식당을 클릭하면 온라인 예측으로 음식 항목 추천이 생성됨
많은 사람들은 온라인 예측이 배치 예측보다 비용과 성능 면에서 비효율적이라고 생각하는데, 입력을 배치 처리하지 못하고 벡터화나 기타 최적화 기술을 활용할 수 있기 때문이다. 그러나, 반드시 맞지는 않다
온라인 예측을 사용하면 사이트를 방문하지 않는 사용자에 대해 예측을 생성할 필요가 없다. 모든 사용자에 대한 예측을 생성하면 사용된 연산은 낭비됨

<배치 예측에서 온라인 예측>

학계의 ML에서는 온라인 예측이 보다 자연스러움
모델에 입력을 제공하면 곧바로 예측이 생성되는데, 이러한 방식은 프로토타입을 만드는 동안 모델과 상호작용 하는데 사용하고 처음 모델을 배포하는 회사에서도 수행하기 보다 쉽다.
모델을 내보내고 아마존 세이지메이커나 구글 앱 엔진에 업로드한 다음 노출된 엔드포인트를 반환한다. 해당 엔드포인트에 입력이 포함된 요청을 보내면 엔드포인트에서 생성된 예측이 다시 전송됨
다만 온라인 예측은 모델이 예측을 생성하는데 너무 오래 걸릴 수 있다는 문제가 있다. 요청이 도착하는 대신 즉시 예측을 생성하는 대신, 예측을 미리 계산에 데이터베이스에 저장하고 요청이 도착할 때 가져오는 것이 바로 '배치 예측'이 하는 일이다.
이 방법을 사용하면 분산 기술로 대량의 샘플을 효율적으로 처리해서 여러 입력에 대한 예측을 한 번에 생성할 수 있다
예측이 미리 계산되어 모델이 예측을 생성하는데 얼마나 오래 걸릴지 걱정할 필요가 없는데, 배치 예측은 복잡한 모델의 추론 레이턴시를 줄이기 위한 트릭으로 볼 수도 있다. 예측을 검색하는데 걸리는 시간은 일반적으로 예측을 생성하는 데 걸리는 시간보다 짧기 때문임
배치 예측은 예측을 많이 생성하되 결과가 즉시 필요하지 않을 때 유용함. 생ㅅ어된 예측을 모두 사용할 필요는 없음.
예를 들어 전체 고객 대상으로 신제품을 구매할 가능성을 예측해서, 그중 가능성이 높은 상위 10%에게만 추천을 보낼 수도 있음
다만 배치 예측은 모델이 사용자의 선호도 변화에 덜 민감하다는 문제가 있음
또한 배치 예측은 예측을 생성할 요청을 미리 알아야한 다는 점인데, 사용자에게 영화를 추천할 경우 몇 명을 대상으로 추천할지 미리 알 수 있지만, 예측할 수 없는 쿼리가 있는 경우 (영어를 프랑스로 번역하는 시스템에서 존재하는 모든 영어 텍스트를 미리 번역해놓기 어려우므로) 온라인 예측으로 요청이 올 때 까지 예측을 생성해야 함
넷플릭스와 같은 영화 추천 배치 예측은 심각한 장애를 유발하지는 않지만 약간의 불편함(사용자 참여 및 리텐션과 밀접)을 유발한다.
그러나, 배치 예측으로 인행 심각한 장애가 발생하거나 작동하지 않는 애플리케이션도 있는데 온라인 예측이 필수인 고빈도 매매(high frequency trading), 자율 주행 자동차, 음성 비서, 얼굴이나 지문을 사용한 휴대 전화 잠금 해제, 노인 낙상 감지, 인상 거래 탐지 등이 있다.
배치 예측은 온라인 예측이 충분히 저렴하지 않거나 충분히 빠르지 않을 때 유용하다. 비용과 속도는 동일하면서 필요에 따라 예측을 생성할 수 있다면 굳이 예측을 백만 개씩 생성할 필요가 없다.
강력한 하드웨어가 등장하고 기술이 발전해 더 빠르고 저렴한 온라인 예측이 가능해지면서 온라인 예측이 기본이 됐다.
온라인 예측의 레이턴시 난제를 극복하려면 두 가지 구성요소가 필요하다.
(1) 거의 실시간에 가까운 파이프라인.
수신 데이터로 작업하고 필요에 따라 스트리밍 피처를 추출하고, 모델에 입력하고 거의 실시간으로 예측을 반환함. 실시간 전송과 스트림 계산 엔진이 있는 스트리밍 파이프라인이 도움이 됨
(2) 최종 사용자가 만족할 만한 속도로 예측을 생성하는 모델. 대부분의 소비자 앱에서 밀리초 수준을 의미

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

배치 예측은 대부분 레거시 시스템의 산물임
지난 10년 동안 빅데이터 프로세싱은 맵리듀스나 스파크 같은 배치 시스템으로 대량의 데이터를 매우 효율적이고 주기적으로 처리 했음
기업들은 ML을 시작할 때 기존 배치 시스템을 활용해 예측을 수행했고, 기업에서 온라인 예측에 스트리밍 기능을 사용하려면 별도의 스트리밍 파이프라인을 구축해야 함

구글 지도 같은 애플리케이션을 위해 도착 시간을 예측하는 모델을 구축한다고 가정하면, 예측은 사용자의 여정이 진행됨에 따라 계속 업데이트 되어야 함.
사용할 피처는 지난 5분 도안 해당 경로에서 이동 중인 모든 차량의 평균속도임.
훈련에는 지난 달의 데이터를 사용함. 훈련 데이터에서 이 피처를 추출하려면 모든 데이터를 데이터프레임에 넣어 동시에 여러 훈련 샘플에 대해 이 피처를 계싼함
추론 하는 동안 피처는 슬라이딩 윈도에서 계속 계산됨
훈련에서 피처가 배치 계산되는 반면 추론 중에서는 스트리밍 프로세스에서 계산됨
두 가지 파이프라인으로 데이터를 처리하는 것은 ML 프로덕션에서 버그가 생기는 원이 되는데, 한 가지 원인은 한 파이프라인의 변경 사항이 다른 파이프라인에 제대로 복제되지 않아 두 파이프라인에서 서로 다른 피처 집합 두 개가 추출되는 경우다. 특히 서로 다른 팀에서 각 파이프라인을 유지보수 하는데 흔히 나타나는데, 배포 팀이 추론을 위해 스트림 파이프라인을 유지보수하는 동안 ML 팀이 훈련을 위해 배치 파이프라인을 유지 보수함
스트림 처리와 배치 처리를 통합하기 위한 인프라 구축은 최근 ML 커뮤니티에서 인기 있는 주제로 우버, 웨이보 등은 아파치 플링크 같은 스트림 프로세서로 배치 처리 및 스트림 처리 파이프라인을 통합하기 위해 주요 인프라를 정비했음
일부 기업은 피처 스토어를 사용해 훈련되는 배치 피처와 예측에 사용되는 스트리밍 피처 간의 일관성을 보장했음

7-3. 모델 압축

스트리밍 파이프라인은 ML 시스템이 수신 데이터에서 스트리밍 피처를 추출하고 (거의) 실시간으로 ML 모델에 입력하게 함
하지만 실시간에 가까운 파이프라인 만으로 온라인 예측에 충분하지 않은데, ML 모델의 빠른 추론을 위한 기술이 필요함
배포할 모델이 예측을 생성하는 데 너무 오래 걸릴 때 추론 레이턴시를 줄이기 위한 세 가지 주요 접근 방식이 있음
(1) 추론을 빠르게 하거나, (2) 모델을 작게 만들거나 (3) 배포된 하드웨어가 더 빠르게 실행되게 하거나
모델을 작게 만드는 과정을 모델 압축 이라고 하고 추론을 더 빠르게 하는 과정을 추론 최적화 라고 함
'모델 압축'의 본래 의도는 모델을 에지 디바이스에 적합하게 만드는 것이지만 모델이 작아지면 종종 더 빠르게 실행됨
모델 압축에 대한 논문이 증가하고 기성(off-the-shelf) 유틸리티가 급증하고 있는데, 수많은 신규 기술이 개발되는 가운데 가장 자주 접할 수 있는 유형은 '저차원 인수분해', '지식 증류', '가지치기', '양자화' 이다.

<모델 압축 1 - 저차원 인수분해>

저차원 인수분해(low-rank factorization) 의 핵심 아이디어는 고차원 텐서를 저차원 텐서로 대체하는 것이다.
소형 합성곱 필터(compact convolution filter)로 매개변수 개수를 줄이고 속도를 높이기 위해 과도하게 매개변수화된(매개변수가 너무 많은) 합성곱 필터를 소형 블록으로 대체함

예를 들어 스퀴즈넷(squeezeNet)은 3X3 합성곱을 1X1 합성곱으로 대체하는 등 여러 전략을 사용해 50배 적은 매개변수로 이미지넷에서 알렉스넷 수준의 정확도를 달성함

모바일넷(MobileNet)은 KXKXC인 표준 합성곱을 깊이별 합성곱(depthwise convolution)과 점별 합성곱(pointwise convolution(1x1xC)으로 분해함.
k : 커널의 크기, C: 채널의 개수
각각의 새로운 합성곱이 매개변수를 k^2C개가 아니라 k^2 + C개만 사용함
K=3이면 매개변수 개수가 8~9개 감소함
이 방법은 표준 모델에 비해 작은 모델을 빠른 속도로 개발하는데 사용하고 있따. 특정 모델 유형에만 적용되는 경향이 있고 (소형 합성곱 필터는 합성곱 신경망에만 적용), 모델을 설계하는데 더 많은 아키텍처 지식이 필요해 아직 널리 적용되지 않음

<모델 압축 2 - 지식 증류>

지식 증류(knowledge distillation)는 작은 모델이 더 큰 모델이나 모델의 앙상블을 모방하도록 훈련하는 방법으로, 배포할 대상은 더 작은 모델임
작은 모델이 큰 모델을 따라 훈련하는 경우가 있지만, 둘이 동시에 훈련할 수도 있음
프로덕션에 사용되는 증류 네트워크로 DistillBERT가 있으며, BERT 모델보다 매개변수는 40% 적으면서 언어 이해 능력(NLU)는 97% 성능을 유지하고 60% 빠름
이 접근 방식의 장점은 작은 모델과 큰 모델 네트워크 간에 아키텍처가 달라도 관계없이 작동한다는 점이다.
예를 들어 작은 모델로 랜덤 포레스트를, 큰 모델을 트랜스포머로 훈련할 수 있다. 단점은 큰 모델의 네트워크의 가용성에 크게 의존한다느 점임
사전 훈련된 모델을 교사 모델로(큰 모델)로 사용한다면 학생 네트워크(작은 모델)로 훈련하는데 필요한 데이터가 적고 훈련이 더 빠름.
반면 사용 가능한 교사 모델이 없다면 학생 네트워크를 훈련하기 전에 교사 네트워크를 훈련해야 하는데, 교사 네트워크를 훈련하는 데 더 많은 데이터가 필요하고 훈련이 더 오래 걸림
- 애플리케이션과 모델 아키텍처에도 민감해 프로덕션에서는 널리 사용되지 않음

<모델 압축 3 - 가지치기>

가지치기(prunnig)는 원래 중요하지 않은 트리 섹션을 제거하는 의사 결정 트리에 사용되는 방법으로, 분류 작업에 중요하지 않거나 중복된 트리 부분을 제거함
-그러나 신경망이 널리 채택되면서 신경망 매개변수가 과도하게 많음을 알게 되어, 워크로드를 줄일 방법을 찾기 시작함
신경망 맥락에서 가지치기에는 신경망 전체 노드를 제거함으로써 아키텍처를 변경하고 매개변수를 줄이는 것을 의미한다.
일반적으로 예측에 가장 덜 유용한 매개변수를 찾아 0으로 설정함. 총 매개변수 개수를 줄이는 것이 아니라 0이 아닌 매개변수 개수만 줄임. 즉, 신경망의 아키텍처는 그대로 유지되는데, 가지치기를 하면 신경망이 더 희소해지며 희소 아키텍처는 밀집 구조보다 저장 공간이 덜 필요한 경향이 있으므로 모델 크기를 줄이는데 도움이 됨
가지치기 기술은 훈련된 네트워크에서 0이 아닌 매개변수를 90% 이상 줄여, 전체 정확도를 손상하지 않으면서 스토리지 요구 사항을 줄이고 추론 계산 성능을 개선함.
가지치기가 효과가 있다는데 공감대가 형성되어 있지만, 실제 가치에 대해서는 많은 논의가 오가고 있는데 가지치기의 주요 가치는 상속된 '중요한 가중치'가 아니라 가지치기된 아키텍처 자체에 있다고 주장하는 의견도 있음
어떤 경우에는 가지치기가 아키텍처 검색 패러다임으로 유용하며 가지치기된 아키텍처는 밀집 모델(dense model)로서 처음부터 재훈련해야 함
반면 다른 연구에서는 가지치기 후의 큰 희소모델이 재훈련된 밀집 모델보다 성능이 우수함을 보여준 경우도 있음

<모델 압축 4 - 양자화>

양자화(quantization)은 가장 일반적이며 흔히 사용되는 모델 압축 방법으로, 수행하기 간단하며 여러 작업과 아키텍처에서 사용됨
양자화는 매개변수를 나타내는 데 더 적은 비트를 사용함으로써 모델의 크기를 줄임. 기본적으로 대부분의 소프트웨어 패키지는 32비트로 부동 소수점 수를 표시하고, 이를 단밀정도(single oercusuib) 부동 소수점(FP32)라고 함
모델 매개변수가 1억 개이고 각각을 32비트로 저장한다면 400메가바이트를 점유하게 됨. 이때 16비트로 나타내면 메모리 공간을 절반으로 줄일 수 있음.
16비트로 부동 소수점을 나타내는 것을 반정밀도(half precision, FP16)이라고 함
부동 소수점을 사용하는 대신 모델을 정수로만 구성할 수 있는데, 각 정수를 나타내는데 8비트만 사용함. 이 방법을 '고정 소수점(fixed point)' 라고 함
양자화는 메모리 풋프린트(memeory footprint)를 줄일 뿐 아니라 계산 속도도 향상함. 배치 크기를 늘릴 수 있고, 정밀도가 낮을 수록 계산 속도가 빨라져 훈련 시간과 추론 레이턴시가 더욱 단축됨
그러나 숫자를 나타내는 비트 수를 줄이면 나타낼 수 있는 값의 범위가 줄어즐어, 범위를 벗어난 값은 반올림하거나 범위 내로 스케일링 해야 함
숫자를 반올림하면 반올림 오차가 발생하는데, 작은 반올림 오차가 성능을 크게 변화시킬 수 있음
숫자를 언더플로 혹은 오버플로로 반올림 혹은 스캐일링해 0으로 만들 위험이 있음. 효율적인 반올림 및 스케일링을 저수준에서 구현하는 것이 중요하고, 다행히 주요 프레임워크에는 이 기능이 내장되어 있음
양자화는 훈련 과정(양자화를 고려한 훈련 quantization aware training) 혹은 사후 훈련(post-training)에 서 수행할 수 있음
훈련 과정에서 양자화할 때는 모델을 낮은 저임ㄹ도로 후련하며, 사후 훈련 과정에서 양자화할 때는 FP32로 훈련된 모델을 추론을 위해 양자화함
훈련 중 양자화르 사용하면 각 매개변수에 더 적은 메모리를 사용하므로 동일한 하드에서 더 큰 모델을 훈련할 수 있음
최근에는 최신 훈련 하드웨어 지원으로 저정밀도 훈련이 일기를 끌고 있고, 엔비디아가 혼합 정밀도 훈련을 지원하는 텐서 코어(Tensor Core)를 도입했꼬 구글 TPU(Tensor Processing Units)은 클라우드 tpu 고성능 비결이라고 칭한 Bfloat16을 사용한 훈련을 지원함
고정 소수점 훈련은 아직 대중적이지는 않지만 매우 좋은 성과를 거두고 있음
고정 소수점 추론은 업계 표준이 되어, 일부 에지 디바이스는 고정 소수점 추론만 지원하고 온디바이스 ML 추론에 인기 있는 프레임워크는 구글 텐서플로 라이트, 페이스북 파이토치 모바일, 엔비디아 텐서 RT는 사후 훈련 양자화를 무료로 제공함

사례 연구

로블록스의 사례 연구는 프로덕션에서 모델을 최적화하는 방법을 이해하는데 도움이 되는데, 연구에서 CPU에서 요청을 매일 10억개 이상 처리하도록 BERT를 스케일링 했다. 로블록스의 많은 NLP 서비스들은 20밀리초 미만 레이턴시로 초당 2만 5,000건 이상의 추론을 처리해야 했는데, 서비스들은 고정 길이 입력값(fixed shape input)을 지원하는 대형 BERT 모델을 베이스라인으로 시작하고, 이후 BERT 모델을 DistillBERT로 대체하고, 고정 형상 입력값을 동적 길이 입력값으로 대체하고 마지막은 양자화를 수행했음.
성능은 양자화에서 가장 크게 향상됐고, 32비트 부동 소수점 수를 8비트 정수로 변환하면 레이턴시가 7개 감소하고 스루풋이 8개 증가함
이러한 기법들은 레이턴시를 개선할 가능성이 매우 높지만 각 시나리오에서 성능 향상 후 결괏값의 품질 변화에 대한 언급이 없다는 것을 감안해야 함

7-4. 클라우드와 에지에서의 머신러닝

모델 계산을 클라우드와 에지 중 어디에서 수행해야 할지 고려해야 함
클라우드에서 계산을 수행함은 클라우드(퍼블릭 클라우드/프라이빗 클라우드)에서 많은 계산이 수행됨을 의미하고, 에지에서 수행함은 소비자 디바이스(에지 디바이스)라인 휴대전화, 브라우저, 노트북, 스마트워치, 자동차 등 에서 많은 계산이 수행됨을 의미함
가장 쉬운 방법은 AWS나 GCP 같은 관리형 클라우드 서비스로 모델을 패키징하고 배포하는 것임. 많은 기업이 ML을 시작할 때 클라우드 서비스로 배포하는데 ,클라우드 서비스는 ml 모델을 프로덕션에 쉽게 배포하도록 해줌
그러나, 클라우드 배포는 비용이라는 단점이 존재하는데, ML 모델은 많은 연산을 필요로 하므로 비용이 많이 듦.
크라우드 비용이 증가함에 따라 많은 기업들이 에지 디바이스에서 컴퓨팅을 수행할 방법을 찾고 있는데, 계산을 에지에서 많이 수행할수록 클라우드 컴퓨팅이 덜 필요해 서버 비용이 적게 들기 때문임
에지 컴퓨팅은 비용 측면 외에도 클라우드 컴퓨팅이 불가능한 곳에서 애플리케이션을 실행한다는 점의 장점이 있음
모델이 퍼블릭 클라우드에 있다면 데이터와 클라우드 간 데이터 전송에 안정적인 인터넷 연결이 필요하지만, 에지 컴퓨팅을 이용하면 시골이나 개발 도상국처럼 인터넷 연결이 없거나 불안정한 상황에도 모델이 작동한다
또 한 에지 컴퓨팅은 이미 소비자 디바이스에 있으면 네트워크 레이턴시에 대한 우려가 줄어들어, 네트워크를 통해 데이터를 전송해야 하는 경우 일부 유스 케이스가 불가능해짐.
많은 사례에서 네트워크 레이턴시가 추론 레이턴시보다 큰 병목인데, 레스넷-50 추론 레이턴시를 30밀리초에서 20밀리초로 줄일 수 있찌만 네트워크 레이턴시는 사용자의 위치와 서비스에 따라 최대 몇 초까지 증가할 수 있음
에지에 모델을 배치하는 것은 민감한 사용자 데이터를 처리할 때도 매력적임. ML 모델이 클라우드에 있으면 시스템이 네트워크를 통해 사용자 데이터를 보내야 하므로 보안에 취약함. 클라우드 컴퓨팅을 사용하면 종종 많은 사용자 데이터를 동일한 장소에 저장하게 되는데 클라우드 데이터 침해는 많은 사람들에게 영향을 미칠 수 있음
시큐리티 매거진에서는 '지난 18개월 동안 기업의 거의 80%가 클라우드 데이터 침해를 경험함'
에지 컴퓨팅은 개인정보보호법(GDPR)과 같은 사용자 데이터 전송 또는 저장 방법에 대한 규정을 준수하기가 용이한데, 에지 컴퓨팅이 개인 정보 보호 문제를 경감하지만 아예 제거하지는 않음
모델 계산을 에지로 이동하려면 에지 디바이스가 계산을 처리할 수 있을만큼 강력해야 하고 ML 모델을 저장하고 메모리에 올리기에 충분한 메로리가 있어야 하며, 배터리가 충분하거나 적절한 시간 동안 애플리케이션에 전원을 공급할 수 있는 에너지원에 연결되어야 함
BERT를 예로 들면 휴대 전화에서 전체 크기의 BERT를 실행하면 배터리가 매우 빨리 소모됨
에지 컴퓨팅이 클라우드 컴퓨팅에 비해 이점을 지녀서 기업은 다양한 ML 유스케이스에 최적화된 에지 디바이스를 개발하고 있음

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

특정 프레임워크, 텐서플로나 파이토치로 빌드한 모델이 하드웨어 백엔드에서 실행되려면 하드웨어 공급업체에서 해당 프레임워크를 지원해야 함
-TPU는 2018년 2월에 공개됐지만 파이토치는 2020년 9월에 TPU를 지원함. 그전에는 TPU를 사용하려면 TPU가 지원하는 프레임워크를 사용해야 했음
하드웨어 백엔드에서 프레임워크에 대한 지원을 제공하는 것은 엔지니어링 노력이 많이 들어가서 시간이 걸림. ML 워크로드에서 하드웨어 백엔드로 매핑하려면 해당 하드웨어 설계를 이해하고 활용할 줄 알아야 하는데 하드웨어 백엔드에 따라 메모리 레이아웃과 계산 기본 단위가 다름
CPU는 계산 기본 단위가 수치(스칼라), GPU는 1차원 벡터였지만 TPU는 2차원 벡터(텐서)임.
1차원 벡터의 합성곱 연산자를 수행하는 일은 2차원 벡터와 매우 다르고, CPU, GPU, TPU를 효율적으로 사용하려면 서로 다른 L1, L2, L3 레이아웃과 버퍼 크기를 고려해야 함
프레임워크 개발자는 소수의 서버급 하드웨어 지원에만 집중해서, 하드웨어 공급업체는 일부 프레임워크에만 자체 커널 라이브러리를 제공하는 경향이 있음. ML 모델을 신규 하드웨어에 배포하려면 상당한 수작업이 필욯마
이러한 모든 신규 하드웨어 백엔드를 위한 새로운 컴파일러와 라이브러리를 직접 개발하는 대신 프레임워크와 플랫폼을 연결할 중재자(middleman)을 만들면, 프레임 워크 개발자는 모든 하드웨어 유형을 지우너할 필요 없이 프레임워크 코드를 이 중개자로 변환하기만 하면 됨
이러한 중개자를 중간 표현(IR) 이라고 하는데, IR은 컴파일러 작동 방식의 핵심에 있음. 모델의 원래 코드에서 컴파일러는 하드웨어 백엔드에 네이티브 코드를 생성하기 위해 일련의 고수준 및 저수준 IR을 생성하여 하드웨어 백엔드에서 실행하도록 함
고수준의 프레임워크 코드를 저수준의 하드웨어 네이티브 코드로 '낮춘다는' 의미로 로어링(lowering) 이라고 하는데, 프레임워크 코드와 네이티브 코드 간에 일대일 매핑을 하는 것은 아니므로 번역이라고 할 수 없음
고수준 IR은 일반적으로 ML 모델의 게산 그래프로 계산 실행 순서를 설명함

<모델 최적화>
선택한 하드웨어에서 모델을 실행하기 위해 코드를 '낮추'고 나면 성능 문제가 발생하는데, 생성된 기계 코드는 하드웨어 백엔드에서 실행될 수는 있지만 효율적으로 실행되지 않을 수 있음
코드가 데이터 지역성과 하드웨어 캐시를 활용하지 않거나 코드 속도를 향상하는 벡터나 병렬 작업 등 고급 기능을 활용하지 않을 수 있음
일반적인 ML 워크플로는 많은 프레임워크와 라이브러리로 구성됨. 프레임워크 내 개별 함수들은 최적화돼도 프레임워크 전반에 걸친 최적화는 거의 혹은 전혀 수행되지 않을 수 있음
계산을 위해 이러한 함수들 간에 데이터를 나이브하게 이동시키면 전체 워크플로우에 엄청난 속도 저하를 초래함
많은 회사에서 데이터 과학자와 ML 엔지니어가 개발하는 모델은 개발 단계에서 제대로 작동하는 것처럼 보이지만 배포하면 너무 느려져서 모델을 하드웨어에 맞춰 최적화 하기 위해 최적화 엔지니어를 고용한다.
최적화 엔지니어는 ML과 하드웨어 아키텍처 양쪽에 대한 전문 지식을 갖춰야 함
이때 최적화 컴파일러, 코드까지 최적화 하는 컴파일러가 대인이 되는데, 모델 최적화 과정을 자동화 할 수 있음. 컴파일러는 ML 모델 코드를 기계 코드로 낮추는 과정에서 ML 모델의 게산 그래프와 모델을 구성하는 연산자(합성곱, 루프, 교차 엔트로피 등)을 보고 속도를 높일 방법을 찾음
ML 모델을 최적화하는 방법은 로컬과 전역 두가지가 있는데, 로컬 최적화는 모델의 연산자 또는 연산자 집합을 최적화하며 전역 최적화는 전체 계산 그래프를 엔드-투-엔드로 최적화함
모델 속도를 높이는 표준 로컬 최적화 기법들은 보통 작업을 병렬화하거나 칩의 메모리 액세스를 줄임

<모델 속도를 높이는 표준 로컬 최적화 기법>
- 1. 벡터화(Vectorization)
    : 루프나 중첩 루프가 있는 경우 한 번에 한 항목씩 실행하는 대신 메모리에 인접한 여러 요소를 동시에 실행해 데이터 I/O로 인한 레이턴시 줄임
- 1. 병렬화(Parallelization)
    : 입력 배열(혹은 n차원 배열)이 주어지면 이를 독립적인 작업 청크로 나눠, 각 청크가 개별적으로 수행될 수 있도록 함
- 1. 루프 타일링(Loop tiling)
    : 루프에서 데이터 엑세스 순서를 변경해 하드웨어의 메모리 레이아웃과 캐시를 활용함. 이 방법은 하드웨어에 따라 다른데, CPU에서 좋은 액세스 패턴은 좋은 액세스 패턴이 아니기 때문임
- 1. 연산자 융합(Operator fusion)
    : 중복 메모리 액세스를 방지하기 위해 여러 연산자를 하나로 통합함
    한 배열에 두 작업을 수행하려면 해당 배열에 루프가 두 개 필요하지만, 융합된 경우에는 하나가 됨
속도를 훨씬 크게 향상하려면 계산 그래프의 상위 수준 구조를 활용해야 함

<머신러닝을 사용해 머신러닝 모델 최적화하기>
합성곱 신경망의 수직 및 수평 융합에서 보면 주어진 계산 그래프를 다양한 방법으로 실행할 수 있는데, 예를 들어 세 연산자 A,B,C,가 주어지면 A를 B와 융합하거나 B를 C와 융합하거나 A,B,C를 모두 융합할 수 있음
전통적으로 프레임워크 및 하드웨어 공급업체는 경험을 바탕으로 모델의 계싼 그래프를 가장 잘 실행하는 방법에 대한 휴리스틱을 생각해내는 최적화 엔지니어를 고용함
다만 수작업으로 만든 휴리스틱은 비최적(nonoptimal) 함. 엔지니어가 생각한 휴리스틱이 최선의 해결책이라는 보장이 없음. 또한 비적응(nonadaptive)적임. 신규 프레임 워크나 신규 하드웨어 아키텍처에서 프로세스를 반복하려면 공을 들여야 함
모델 최적화는 계산 그래프를 구성하는 연산자에 의존하는데, 합성공 신경망 최적화는 순환 신경망 최적화와 다르고 순환 신경망 최적화는 트랜스포머 최적화와 다름
좋은 휴리스틱을 생각해내기 어려우면, 가능한 모든 방법으로 계산 그래프를 실행해서 실행에 필요한 시간을 기록한 다음 가장 좋은 방법을 선택하는 것임. 그러나 가능한 경로 조합이 매우 많아 전체 경로를 탐색하기 어려움.
다행히 ML은 난해한 문제에 대한 솔루션을 잘 근사화하는데, ML로 검색 공간을 좁힘으로써 많은 경로를 탐색할 필요가 없고 경로가 얼마나 걸릴지 예측해 그래프 실행이 완료될 때까지 기다리면 됨
그래프에 대한 많은 가정을 해야 하기 때문에 계산 그래프를 통과하는 경로가 실행되는데 걸리는 시간을 추정하기는 어려워 그래프의 작은 부분에 대한 분석에 집중하는 편이 좋음
GPU에서 파이토치를 사용하면 torch.backends.cudnn.benchmark=True 로, cuDNN 자동 튜닝(autotune)이 활성화됨
cuDNN 자동 튜닝은 미리 결정된 옵션 집합을 검색해 합성곱 연산자를 실행한 다음 가장 빠른 방법을 선택함
cuDNN 자동 튜닝은 효율적이지만 합성곱 연산자에만 작동함
일반적인 솔루션은 오픈 소스 컴파일러 스택 TVM의 일부인 autoTVM임
autoTVM은 연산자뿐 아니라 부분 그래프와 함께 작동해 검색 공간이 훨씬 복잡함
autoTVM 의 작동 방식은
(1) 계산 그래프를 부분 그래프로 나눔
(2) 각 부분 그래프의 크기를 예측
(3) 각 부분 그래프에 대한 간읗나 최상의 경로를 탐색하는 시간 할당
(4) 각 부분 그래프를 함께 실행해 전체 그래프를 실행하는 가장 좋은 경로 연결

autoTVM은 각 경로를 실행하는 데 실제로 걸리는 시간을 측정하여, 향후 경로가 얼마나 걸릴지 예측하기 위해 비용 모델을 훈련하는데 그라운드 트루스를 제공함

이 접근법의 장점은 모델이 런타임 중 생성된 데이터로 훈련되므로 어떤 유혀애의 하드웨어 에서 실행되든 적응하지만, 비용 모델이 개선되기 시작하는데 시간이 많이 걸린다는 단점이 있음
ML 기반 컴파일러는 결과는 인상적이지만 속도가 느림. 가능한 경로를 모두 살펴보고 가장 최적화된 경로를 찾기 때문임. 모델이 복잡하면 더 오래 걸림
그러나 이 작업은 일회성이고, 최적화 검색 결과를 캐시에 기존 모델을 최적화하는 데 사용하거나 향후 추가 개선 시 시작점으로 사용할 수 있음
하드웨어 백엔드 하나에 모델을 한 번 최적화한 다음 하드웨어 유형이 동일한 여러 디바이스에서 사용함 이러한 최적화는 프로덕션 모델과 추론을 실행한 타깃 하드웨어가 있을 때 이상적

브라우저에서의 머신러닝

브라우저에서 실행함으로써 어떤 하드웨어 백엔드에서든 실행 가능한 코들르 생성할 수도 있음
모델을 브라우저에서 실행할 수 있따면 해당 브라우저를 지원하는 모든 기기에서 실행 가능함
브라우저에 대해서 자바스크립트를 떠올리는 사람이 많겠지만, 자바스크립트는 느리고 데이터 피처 추출과 같은 복잡한 로직에는 프로그래밍 언어로서의 기능이 제한적임
보다 유망한 접근으로 웹어세블리(WebAssembly,WASM) 이 있는데, 다양한 언어로 작성된 프로그램을 웹 브라우저 상에서 실행하도록 해주는 개방형 표준임
사이킬런, 파이토치 ,텐서플로 등 프레임워크에서 모델을 빌드하고 특정 하드웨어에서 실행되도록 컴파일 하는 대신 모델을 WASM으로 컴파일함. 그러면 자바스크립트와 함께 사용하는 실행 파일을 얻게됨

WASM은 성능이 뛰어나고 사용하기 쉽고 생태계가 가파르게 성장하고 있다. 그러나 브라우저에서 실행돼 속도가 느리다는 단점이 있음. 자바스크립트보다는 빠르지만 iOS 나 안드로이드 앱 호환 기기에서 네이티브 코드를 실행하는 것과 비교하면 여전히 느림

결론
ML 모델 배포는 ML 엔지니어링 난제임
온라인 예측과 배치 예측, 에지에서의 ML과 클라욷의 ML을 비교해 모델을 배포하는 방법에는 고유한 이슈가 있음
온라인 예측을 사용하면 모델이 사용자 선호도 변경에 더 잘 반응하지만 추론 레이턴시라는 문제가 있음.
배치 예측은 모델이 예측을 생성하는데 너무 오래 걸릴 때 해결책이 되지만 모델 유연성이 떨어짐
클라우드에서 추론을 수행하면 설정은 쉽지만 네트워크 레이턴시와 클라우드 비용이 커지면 실용서이 떨어짐
에지에서 추론을 수행하려면 충분한 연산 성능, 메모리 및 배터리를 갖춘 에지 디바이스필요함
이러한 문제는 ML 모델이 실행되는 하드웨어의 제한에서 비롯되기도 함
하드웨어가 강력해지고 ML에 최적화되면 ML 시스템은 온디바이스의 온라인 예측으로 전환될 것임

gunny

꿈꾸는 것도 개발처럼 깊게

이전 포스트

[ML] 머신러닝 시스템 설계 : 6장 모델 개발과 오프라인 평가

다음 포스트