반복 프로세스의 또 다른 부분인 모델 배포를 알아본다. 배포는 일반적으로 ‘모델을 실행하고 액세스 가능하게 함’을 의미하는 포괄적인 용어이다.

프로덕션의 스펙트럼은 다양하다. 어떤 경우에는 멋진 플롯을 작성하는 일을 의미하고, 또 어떤 경우에는 하루 수백만 명 사용자를 위해 모델을 계속 가동하는 것을 의미한다.

첫 번째 경우 개발 환경과 프로덕션 환경이 유사하지만, 두 번째 경우 그렇지 않고 이 장의 내용이 도움이 될 것이다.

“어려운 부분을 모두 무시하면 배포가 쉽다.” 하지만 사용자 수백만 명이 모델을 밀리초 단위 레이턴시와 99% 가동 시간으로 사용하도록 하고, 문제 발생 시 적절한 사람에게 즉시 알리도록 인프라를 설정하고, 잘못된 부분을 파악하고 문제를 수정하기 위해 업데이트를 원활하게 배포하는 것은 어렵다.

ML 모델 배포와 관련이 있든 없든, 모델이 사용되는 방식을 이해함으로써 모델의 제약 조건을 이해하고 목적에 맞게 조정하는 데 도움이 된다.

첫 번째 절에서는 ML 배포에 대한 몇 가지 통념을 짚어본다.

모델이 예측을 생성하고 사용자에게 제공하는 주요 방법인 온라인 예측과 배치 예측을 알아본다.

예측 생성을 위한 계산이 수행되는 곳, 즉 디바이스(에지라고도 함) 상 모델 배포와 클라우드상 모델 배포를 알아본다.

7.1 머신러닝 배포에 대한 통념

모델 배포 경험이 없는 사람들은 프로세스를 두려워하거나, 반대로 소요되는 시간과 노력을 과소평가한다.

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

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

위 이미지는 넷플릭스에서 ML을 활용하는 여러 작업을 보여준다.

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

시간에 따라 소프트웨어 프로그램이 아무런 변화가 없어 보임에도 성능이 저하되는 현산을 소프트웨어 부패 또는 비트 부패라고 한다.

게다가 ML 시스템은 프로덕션에서 모델이 접하는 데이터 분포가 훈련된 데이터 분포와 다를 때 데이터 분포 시프트 문제를 겪는다.

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

모델 성능은 시간에 따라 저하되므로 최대한 빨리 업데이트해야 한다.

웨이보는 일부 ML 모델을 10분마다 업데이트한다.

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

‘스케일’이 의미하는 바는 애플리케이션마다 다르지만, 예로는 초당 수백 개의 쿼리를 처리하거나 한 달에 수백만 명의 사용자를 처리하는 시스템이 있다.

ML 관련 직업을 구하고 있다면 직원 100명 이상인 회사에서 일할 가능성이 높으며 ML 애플리케이션을 확장할 수 있어야 한다.

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

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

온라인 예측은 예측에 대한 요청이 도착하는 즉시 예측이 생성되고 반환되는 경우이다. 온 디멘드 예측, 동기 예측이라고도 한다. (구글 번역에 영어 문장을 입력하는 즉시 프랑스어 번역문이 돌아온다.)

배치 예측은 예측이 주기적으로 혹은 트리거될 때마다 생성되는 경우이다. 비동기 예측이라고도 한다. (넷플릭스는 네 시간마다 모든 사용자에 대한 영화 추천을 생성하며 사용자가 넷플릭스에 로그인할 때 사전 계산된 추천을 가져와서 표시해준다.)

배치 예측에서는 배치 피처만 사용하며 온라인 예측에서는 배치 피처와 스트리밍 피처를 모두 사용할 수 있다. 음식 배달 플랫폼 도어대시에서 사용자의 주문에 대한 배송 시간을 추정하는데는 다음과 같은 피처가 필요하다.

• 배치 피처: 과거 이 음식점의 평균 음식 준비 시간
• 스트리밍 피처: 지난 10분 동안 해당 건 외에 들어온 주문 건수, 가용한 배달 인력 명수

온라인 예측이 배치 예측보다 비용과 성능 면에서 비효율적으로 생각하는 경우가 많다. 하지만 3.6절 ‘배치 처리 vs. 스트림 처리’에서 논의했듯이 이것이 반드시 맞지는 않다.

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

온라인 예측은 모델이 예측을 생성하는 데 너무 오래 걸릴 수 있다는 문제가 있다.

배치 예측은 예측이 미리 계산되므로 모델이 예측을 생성하는 데 얼마나 오래 걸릴지 걱정할 필요가 없다. 예측을 많이 생성하되 결과가 즉시 필요하지 않을 때 유용하다. 하지만 모델이 사용자의 선호도 변화에 덜 민감하다는 점과 예측을 생성할 요청을 미리 알아야 한다는 점이 문제다.

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

더 맞춤화되고 강력한 하드웨어가 등장하고 기술이 발전함에 따라 더 빠르고 저렴한 온라인 예측이 가능해지면서 온라인 예측이 기본이 됐다.

최근 몇 년 간 기업들은 배치 예측에서 온라인 예측으로 전환하기 위해 상당한 투자를 했다. 온라인 예측의 레이턴시 난제를 극복하려면 두 가지 구성 요소가 필요하다.

• (거의) 실시간 파이프라인. 수신 데이터로 작업하고, 필요에 따라 스트리밍 피처를 추출하고, 모델에 입력하고, 거의 실시간으로 예측을 반환한다. 실시간 전송과 스트림 계산 엔진이 있는 스트리밍 파이프라인이 도움이 된다.
• 최종 사용자가 만족할 만한 속도로 예측을 생성하는 모델. 대부분의 소비자 앱에서 밀리초 수준을 의미한다.

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

기업들은 ML을 시작할 때 기존 배치 시스템을 활용해 예측을 수행했다. 이러한 기업에서 온라인 예측에 스트리밍 기능을 사용하려면 별도의 스트리밍 파이프라인을 구축해야 한다.

스트림 처리와 배치 처리를 통합하기 위한 인프라 구축은 최근 ML 커뮤니티에서 인기 있는 주제가 됐다. 아파치 플링크 같은 스트림 프로세서로 배치 처리 및 스트림 처리 파이프라인을 통합하기 위해 주요 인프라를 정비하기도 하고, 피처 스토어를 사용해 훈련에 사용되는 배치 피처와 예측에 사용되는 스트리밍 피처 간의 일관성을 보장한다.

7.3 모델 압축

ML 모델의 빠른 추론을 위한 기술들을 살펴본다.

추론 레이턴시를 줄이기 위한 세 가지 주요 접근 방식은 다음과 같다.

추론을 더 빠르게 하거나, 모델을 더 작게 만들거나, 배포된 하드웨어가 더 빠르게 실행되도록 하는 것

추론 최적화는 7.4.1절에서 다루고, 하드웨어 백엔드 환경은 7.4절에서 논의한다.

이 장에서는 모델 압축을 알아본다.

7.3.1 저차원 인수분해(low-rank factorization)

고차원 텐서를 저차원 텐서로 대체하는 것이다. 한 가지 유형은 소형 합성곱 필터이다.

특정 모델 유형에만 적용되는 경향이 있고, 모델을 설계하는 데 많은 아키텍처 지식이 필요해 아직 널리 적용되지 않는다.

7.3.2 지식 증류(knowledge distillation)

작은 모델(학생)이 더 큰 모델이나 모델의 앙상블(교사)를 모방하도록 훈련하는 방법이다.

장점은 네트워크 간 아키텍처가 달라도 적용할 수 있다는 점이다. 교사 모델을 트랜스포머로 두고 학생 모델로 랜덤 포레스트 모델을 훈련할 수 있다.

단점은 교사 네트워크의 가용성에 크게 의존한다는 점이다. 사용 가능한 교사 모델이 없을 땐 교사 네트워크를 훈련하기 위해 자원이 많이 쓰인다.

7.3.3 가지치기(pruning)

신경망 맥락에서 가지치기에는 두 가지 의미가 있다. 먼저, 신경망 전체 노드를 제거함으로써 아키텍처를 변경하고 매개변수를 줄임을 의미한다. 보다 일반적으로는 예측에 가장 덜 유용한 매개변수를 찾아 0으로 설정함을 의미한다. 신경망이 더 희소해지며 밀집 구조에 비해 모델 아키텍처를 저장하기 위해 필요한 저장 공간을 아낄 수 있다.

7.3.4 양자화(quantization)

매개변수를 나타내는 데 더 적은 비트를 사용함으로써 모델 크기를 줄인다. 단정밀도 부동 소수점(FP32)로 모델 파라미터를 저장하는 것을 반정밀도 부동 소수점(FP16)으로 저장하면 메모리 공간을 절반으로 줄일 수 있다.

모델을 정수로만 구성하기도 한다. 각 정수를 나타내는 데는 8비트만 사용한다. 이 방법을 ‘고정 소수점(fixed point)’이라고도 한다.

양자화는 메모리 풋프린트를 줄일 뿐 아니라 계산 속도도 향상한다.

단점은 숫자를 나타내는 비트 수를 줄이면 나타낼 수 있는 값의 범위 또한 줄어들어 발생하는 오차가 성능을 크게 변화시킬 수 있다는 점이다.

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

클라우드에서 계산을 수행함은 클라우드(퍼블릭이든 프라이빗이든)에서 많은 계산이 수행됨을 의미한다.

에지에서 계산을 수행함은 소비자 디바이스(에지 디비이스)에서 많은 계산이 수행됨을 의미한다.

가장 쉬운 배포 방법은 AWS나 GCP 같은 관리형 클라우드 서비스로 모델을 패키징하고 배포하는 것이다. 다만 비용이 비싸다는 단점이 있다.

계산을 에지에서 수행하면 클라우드 컴퓨팅이 덜 필요하고 비용을 절감할 수 있다. 클라우드 컴퓨팅이 불가능한 곳에서 애플리케이션을 실행할 수도 있고 네트워크 레이턴시에 대한 우려도 줄일 수 있다. 민감한 사용자 데이터를 처리할 때도 매력적이다. 하지만 에지 디바이스가 계산을 처리할 수 있을 만큼 강력해야 하고, ML 모델을 메모리에 적재하기에 충분한 메모리가 있어야 한다.

ML 모델을 실행할 하드웨어는 종류가 매우 많다. 이어지는 절에서 모델을 특정 하드웨어 백엔드에서 실행하기 위해 컴파일하고 최적화하는 방법을 알아본다.

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

특정 프레임워크, 예컨대 텐서플로나 파이토치로 빌드한 모델이 하드웨어 백엔드에서 실행되려면 하드웨어 공급업체에서 해당 프레임워크를 지원해야 한다.

하드웨어 백엔드에서 프레임워크에 대한 지원을 제공하는 것은 엔지니어링 노력이 많이 들기에 시간이 걸린다. 이러한 어려움 때문에 프레임워크 개발자는 소수의 서버급 하드웨어 지원에만 집중하는 경향이 있고, 하드웨어 공급업체는 일부 프레임워크에만 자체 커널 라이브러리를 제공하는 경향이 있다.

그렇다면 모든 신규 하드웨어 백엔드를 위한 새로운 컴파일러와 라이브러리를 직접 개발하는 대신 프레임워크와 플랫폼을 연결할 중개자를 만들면 어떨까? 프래임워크 개발자는 모든 하드웨어 유형을 지원할 필요 없이 프레임워크 코드를 이 중개자로 변환하기만 하면 된다. 그리고 하드웨어 공급업체는 여러 프레임워크가 아니라 중개자 하나만 지원하면 된다.

이러한 중개자를 IR(Intermediate Representation)이라고 한다. IR은 컴파일러 작동 방식의 핵심에 있다. 모델의 원래 코드에서 컴파일러는 하드웨어 백엔드에 네이티브 코드를 생성하기 전에 일련의 고수준 및 저수준 IR을 생성한다.

이 프로세스는 고수준의 프레임워크 코드를 저수준의 하드웨어 네이티브 코드로 ‘낮춘다’는 의미로 로어링(lowering)이라고도 한다.

모델 최적화

ML 모델을 최적화하는 방법은 로컬과 전역으로 두 가지이다. 로컬 최적화는 모델의 연산자 또는 연산자 집합을 최적화하며 전역 최적화는 전체 계산 그래프를 엔드-투-엔드로 최적화한다.

모델 속도를 높이는 표준 로컬 최적화 기법들은 보통 작업을 병렬화하거나 칩의 메모리 액세스를 줄인다. 일반적인 기법 네 가지는 다음과 같다.

• 벡터화(Vectorization)
• 병렬화(Parallelization)
• 루프 타일링(Loop tiling)
• 연산자 융합(Operator fusion)

속도를 훨씬 크게 향상하려면 계산 그래프의 상위 수준 구조를 활용해야 한다.

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

주어진 계산 그래프를 다양한 방법으로 실행할 수 있다. 예를 들어, 세 연산자 A, B, C가 주어지면 A를 B와 융합하거나, B를 C와 융합하거나, A, B, C를 모두 융합할 수 있다.

전통적으로 프레임워크 및 하드웨어 공급업체에서는 경험을 바탕으로 모델의 계산 그래프를 가장 잘 실행하는 방법에 대한 휴리스틱을 생각해내는 최적화 엔지니어를 고용한다. 하지만 수작업으로 만든 휴리스틱에는 몇 가지 단점이 있다. 비최적이라는 점과 비적응적이라는 점이다.

가능한 모든 방법으로 계산 그래프를 실행해보고 실행에 필요한 시간을 기록한 다음 가장 좋은 방법을 선택하는 것은 휴리스틱의 대안이 된다. 다만 가능한 경로 조합이 너무 많으므로 전체 경로를 탐색하기에는 무리가 있는데, 다행히도 ML은 이런 문제에 대한 솔루션을 잘 근사한다.

GPU에서 파이토치를 사용한다면 torch.backends.cudnn.benchmark = True를 본 적이 있을 것이다. 이를 True로 설정하면 cuDNN 자동 튜닝이 활성화된다. cuDNN 자동 튜닝은 미리 결정된 옵션 집합을 검색해 합성곱 연산자를 실행한 다음 가장 빠른 방법을 선택한다. 효율적이긴 하지만 합성곱 연산자에만 작동한다.

그보다 훨씬 일반적인 솔루션은 오픈 소스 컴파일러 스택 TVM의 일부인 autoTVM이다. autoTVM의 작동 방식을 간단히 요약하면 다음과 같다.

1. 계산 그래프를 부분 그래프로 나눈다.
2. 각 부분 그래프의 크기를 예측한다.
3. 각 부분 그래프에 대해 가능한 최상의 경로를 검색하는 시간을 할당한다.
4. 각 부분 그래프를 함께 실행해 전체 그래프를 실행하는 가장 좋은 경로를 연결한다.

autoTVM은 각 경로를 실행하는 데 실제로 걸리는 시간을 측정한다. 이는 향후 경로가 얼마나 걸릴지 예측하기 위해 비용 모델을 훈련하는 데 그라운드 트루스를 제공한다. 이 접근법의 장점은 모델이 런타임 중 생성된 데이터로 훈련되므로 어떤 유형의 하드웨어에서 실행되든 적응한다는 점이다.

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

모델을 브라우저에서 실행할 수 있다면 해당 브라우저를 지원하는 모든 기기에서 실행 가능하다.

좋은 접근 방식으로 웹어셈블리(WASM)가 있다. WASM은 다양한 언어로 작성된 프로그램을 웹 브라우저상에서 실행하도록 해주는 개방형 표준이다. 사이킷런, 파이토치, 텐서플로 등 프레임워크에서 모델을 빌드하고 특정 하드웨어에서 실행되도록 컴파일하는 대신 모델을 WASM으로 컴파일한다. 그러면 자바스크립트와 함께 사용하는 실행 파일을 얻게 된다.

자바스크립트보다는 훨씬 빠르지만 속도가 느리다는 단점이 있다.

7.5 정리

온라인 예측과 배치 예측, 에지에서의 ML과 클라우드에서의 ML을 비교해 모델을 배포하는 다양한 방법을 알아보았다.

각 방법에는 고유한 이슈가 있으나, 하드웨어가 더 강력해지고 ML에 최적화됨에 따라 ML 시스템은 온디비이스의 온라인 예측으로 전환될 것이다.

모델 배포 후에도 중요한 프로세스가 많이 남아있음을 확인하였다.