오늘날 머신러닝(machine learning, ML) 모델 개발은 대부분 NVIDIA의 데이터센터 GPU(예: A100)나 워크스테이션 GPU(예: RTX4090)가 장착된 고성능 서버 환경에서 이루어집니다. 우아한형제들 로보틱스LAB에서도, 실외 배달 로봇의 자율주행에 사용할 ML 모델을 개발할 때 이러한 고성능 서버들을 사용합니다. 덕분에 매우 큰 데이터셋들과 다양한 고성능 ML 모델들을 손쉽게 다루고 있죠. 그러나 여기엔 한 가지 문제점이 있는데, 바로 고성능 서버 환경에서 개발된 ML 모델은 곧바로 로봇에 배포할 수 없다는 점입니다. 이 글에서는 고성능 서버 환경과 실외 자율주행 로봇 환경의 차이점을 살펴보고, 그로부터 ML 모델 경량화의 필요성을 이해한 후, ML 모델 경량화 방법 중 하나인 양자화의 원리와 적용 방법을 알아보겠습니다. 양자화의 원리와 적용 방법에 대해서는 NVIDIA의 공식 문서를 참고하였으며, 이러한 기술들은 로봇을 포함한 다양한 NVIDIA 하드웨어 기반 컴퓨터에 응용할 수 있습니다.로봇이 실외에서 자율주행을 하려면?그림 1. 우아한형제들 로보틱스LAB의 실외 자율주행 배달로봇 ‘딜리’• 충격, 진동, 온도, 습도, 물, 먼지 등을 견디는 내구성• 긴 배터리 수명과 낮은 발열을 위한 전성비• 좁은 로봇 내부 공간에 맞는 작은 크기의 부품들• 다양한 센서를 연결하기 위한 많은 포트 및 높은 호환성이러한 조건을 무시하고 고성능 서버 환경의 GPU를 로봇에 그대로 사용하면, 조금의 충격에도 쉽게 망가지고 배터리도 금방 방전되는 로봇이 될 것입니다. 따라서 실외 환경에서 사용할 로봇에는 이러한 요구 사항들을 충족하는 엣지 디바이스(edge device)를 사용해야 합니다. 일반적으로 ML 목적의 엣지 디바이스에는 행렬 연산에 최적화된 처리 장치를 사용합니다. 그러한 처리 장치로 GPU를 사용할 수도 있고, GPU 대신 포괄적 개념의 ML 모델 처리 장치인 신경망 처리 장치(neural processing unit, NPU), Google의 텐서 처리 장치(tensor processing unit, TPU), Intel의 비전 처리 장치(vision processing unit, VPU), NVIDIA의 딥러닝 가속기(deep learning accelerator, DLA) 등을 사용하기도 합니다. 이러한 처리 장치들은 엣지 디바이스에서 GPU의 역할을 대체합니다. 그렇다면 수많은 ML 목적의 엣지 디바이스 중에서 어떤 제품을 선택해야 할까요? 우아한형제들 로보틱스LAB에서는 NVIDIA의 Jetson 플랫폼을 사용하고 있습니다. 다음 챕터에서는 NVIDIA GPU와 Jetson 플랫폼의 특징을 살펴보고, 그로부터 Jetson 플랫폼의 장점을 알아보겠습니다.NVIDIA GPU는 ML 모델을 처리하는 장치로 많이 쓰입니다. 어떤 ML 처리 장치를 사용하든, 그것으로 ML 모델을 구동시키려면 딥러닝 프레임워크(PyTorch 등)의 포맷으로 되어 있는 ML 모델을 그 처리 장치의 특성에 맞게 최적화된 포맷으로 변환하는

안녕하세요. 왓챠 ML팀에서 머신러닝 엔지니어로 일하고 있는 찰스입니다.이전 글에서는 기존 왓챠 ML 파이프라인 및 실험 환경이 가진 문제점에 대해서 살펴보고, 문제를 해결하기 위해 컨테이너 환경의 도입, On-premise GPU 서버와 클라우드 서비스와의 연동, ML 파이프라인과 실험 환경을 제공하기 위해 여러 서비스를 활용한 사례에 대해 살펴보았습니다.이렇게 여러 해결책을 점진적으로 도입한 후 왓챠 ML 파이프라인 및 실험 환경은 기존에 비해 사용성과 안정성에서 많은 개선을 이루었습니다. 다만, 학습된 모델을 서빙하고 모니터링하는 과정은 여전히 개선해야 할 영역으로 남아있었습니다.이 글에서는 왓챠 추천 시스템에서 학습된 추천 모델을 서비스에 반영하기 위해 독립적인 추론 서버가 왜 필요했고 어떻게 개발했는지, 그리고 추론 서버와 추천 모델의 성능을 모니터링하기 위해 어떠한 노력을 기울였는지에 대해서 알아보도록 하겠습니다.기존 왓챠 추천 시스템의 문제점기존 왓챠 추천 시스템은 추천 모델을 학습하고 추천에 필요한 여러 데이터를 정제하는 워커(Worker)와 워커에서 생성한 모델과 정제된 데이터를 이용하여 API 형태로 추천 결과를 제공하는 서비스(Service)로 이루어져 있었습니다.기존 왓챠 추천 시스템이 중 워커는 이전 글에서 설명 드린대로 On-premise GPU 클러스터 내 Argo workflow를 기반으로 작성된 ML 파이프라인으로 이전되었고, ML 파이프라인에서 생성된 여러 모델 및 정제 데이터는 AWS S3와 Redis Pubsub을 통해 서비스로 동기화되어 실시간 반영되고 있었습니다.서비스에서는 업데이트된 학습 모델과 정제 데이터를 활용하되, 하나의 애플리케이션에서 추천 후보 필터링, 전처리, 모델 추론, 후보정과 같은 과정을 거쳐 API 형태로 제공되었으며, 왓챠/왓챠피디아 내 추천 및 랭킹을 필요로 하는 클라이언트로부터 전달받은 여러 요청을 처리하고 있었습니다.이러한 구조의 추천 서비스는 추천 모델과 추천에 필요한 데이터를 애플리케이션 내 메모리에 올려두어 사용하기 때문에 처리 속도가 매우 빠르다는 장점을 가지고 있었지만, Monolithic 서비스 특성상 특정 로직의 수정만으로도 서비스 전체에 배포되어야 하고, 모델의 문제가 추천 서비스 전체 장애로 퍼질 수 있다는 문제점을 가지고 있었습니다.그리고 서비스는 동시성(Concurrency)과 비동기(Asynchronous)를 최대한으로 활용하기에 적합한 Scala로 구현되어 있어 PyTorch로 학습된 추천 모델을 추론하기 위해서는 PyTorch JNI와 같은 Java library가 필요했습니다. 아쉽게도 Pytorch JNI는 Pytorch에서 직접 관리하지 않아 버전 업데이트가 느렸으며 학습과 추론에 효율적인 기능이 PyTorch에 업그레이드되어도 JNI 버전이 업데이트되지 않아 실 서비스에서 빠르게 적용하기가 어려웠습니다. 또한, JNI를 이용하여 모델을 추론했을 때 기본적인 Forward 이외에 지원되는 기능이 제한되어 있어 추론에 필요한 여러 정보를 별도의

MNIST 데이터셋을 이용한 Multi-Layer Perceptron (MLP) 예제를, MLX 를 이용해 구현해보도록 하겠습니다.Torch 로 구현하는 것과 어떤 차이를 보이는지 비교해볼 예정입니다.MLP class 를 하나 만들어줍니다. 잘 보면 torch.nn 을 사용할 때와 거의 유사함을 확인할 수 있습니다.라이브러리를 만들면서 이런 점들을 고려하지 않았을까 싶네요.코드들을 건드리지 않고 import 하는 부분만 에서 등으로 바꾸기만 해도 코드가 돌아갈 수 있는 것을 의도하지 않았을까요 (뇌피셜)Loss function 과 evaluation function 도 만들어주겠습니다.이 또한 torch 와 거의 유사하게 구현되었습니다.Hyperparam 들을 설정하고, MNIST 데이터셋을 다운받아 전처리 해주도록 하겠습니다.MLP 를 사용하기 때문에 ( 28 X 28 ) 의 이미지를 768 dimensions 으로 flatten 해줍니다.Batch iterator 를 구현해주겠습니다. torch 는 dataloader 가 구현되어 있죠.아직 MLX 는 따로 구현되어 있는 것은 찾지 못했습니다. (2023/12/17 기준)그럼 만들어진 MLP 를 학습시켜 보겠습니다.PyTorch 와 다른 부분은 update 부분이 되겠습니다.PyTorch 같은 경우 loss function 만 정의한 뒤 , , 를 통해 업데이트를 하죠.MLX 는 를 통해 loss와 gradient를 구해주고, 를 통해 model 을 업데이트합니다.일단 제일 Learning scheduleer 같은 걸 쓰지 않고 SGD 로 간단하게 학습해보겠습니다.Parameter initialize 도 랜덤이므로 가끔 학습이 안될때도 있으니 주의!!보면 1 epoch 당 0.2 초 정도 걸리는 것을 확인할 수 있습니다.여러번 돌려보니 Accuracy 는 0.2 일때도 있고 0.9까지 오를 때도 있네요.잘 학습될 때를 노려 test set 평가를 해보겠습니다.이제 동일한 코드를 Torch 로 구현해보도록 하겠습니다.PyTorch 도 device="mps" 를 사용하면 GPU 를 사용할수는 있습니다.그렇다면 MLX 의 장점은 무엇인가 하면 CPU와 GPU 의 unified memory 라는 점입니다.즉 메모리를 공유하니까 GPU 로 메모리를 이동시키는 시간이 줄어들겠죠.사실 MLP 의 경우 CNN 같은 구조보다 GPU 활용도는 떨어집니다. GPU 를 이용한 시간 단축 효과를 크게 보기 어렵다는 것이죠.실제로 PyTorch 로 구현한 코드의 결과를 보면 CPU 를 활용한 학습의 경우 1 epoch 당 0.39 초가 걸렸지만, GPU 를 활용한 학습의 경우 1 epoch 당 0.53 초가 걸렸습니다.Unified Memory 가 아니기 때문에 메모리를 device 로 옮기는데서 시간 손해를 보기도 하고, 최적화도 덜 되어 있고 판단할 수 있겠습니다.아주 간단한 MLP 를 MLX 를 통해 구현해보았습니다.이전의 Linear regression 보다 모델의 크기가 더욱 커진 상태에서 MLX 를

새로운 루다를 지탱하는 모델 서빙 아키텍처 — 3편: 안정적인 LLM 서비스를 위한 서빙 최적화 기법LLM 서빙을 위한 다양한 최적화 기법과 그 효과를 검증하기 위한 부하 테스트 방법론많은 기업들이 생성AI 시장에 뛰어들기 위해서 각자의 LLM 을 만들기 위해 온 열정을 쏟아붓고 있습니다. 특히 ChatGPT 출시 이후 다양한 종류와 크기의 LLM 들이 만들어 지고 있는데요. 하지만 모든 모델들이 공통적으로 서빙쪽에서 문제를 겪고 있습니다. LLM 을 학습하는 비용 보다, LLM 을 지속적으로 서빙하기 위해서 더 많은 돈(GPU 서버 비용)이 필요로 하기 때문입니다. 역사상 가장 빠르게 성장한 서비스인 ChatGPT 는 하루에 약 $700,000(한화 10억) 이상을 서버 비용으로 사용한다는 예측도 나와있어 얼마나 많은 비용이 필요로 한지 체감할 수 있습니다.스캐터랩도 더 놀라운 대화형 AI 를 만들기 위해서 저희만의 LLM 을 만들어 오고 있는데요. 저희 역시 더 좋은 성능의 모델을 사용하기 위해 모델크기를 점점 키우면서 LLM 서빙에 필요로 하는 GPU 비용이 기하급수적으로 증가하고 있는 상황이었습니다. 앞으로 모델 크기가 더 커질 일만 남은 상황에서 적정한 가격으로 모델을 서비스하기 위해서는 LLM 비용 최적화가 필수적이라고 판단하였고, 스캐터랩 ML Engineering 팀은 ChatGPT 가 출시되기 이전인 22년 상반기 부터 LLM 서빙 최적화를 연구해 왔습니다. 이번 블로그에서는 LLM 최적화에 대한 배경지식들을 간략하게 소개해 드리고, 저희가 지금까지 진행한 LLM 서빙 최적화 실험 결과들을 공유해 드리려고 합니다.우선 LLM 서빙을 최적화 할 수 있는 대표적인 최적화 기법들에 대해서 알아보도록 하겠습니다. 참고로 이번 블로그에서는 모델의 성능을 동일하게 유지하면서 적용할 수 있는 서빙 최적화 방법에 대해서만 다룹니다. 따라서 Low Precision Quantization(INT8, INT4, FP8) 이나 Distillation 에 대해서는 다루지 않습니다.GPU는 Kernel 단위로 연산이 이루어 지게 됩니다. 예를 들어 우리가 두개의 텐서를 서로 MatMul 후에 Add 하는 연산을 수행할 때, Matmul Kernel, Add Kernel 이렇게 두개의 커널을 실행하게 됩니다. 이때 두개의 커널을 실행하는 대신 두개의 커널을 MatmulAdd 라는 하나의 커널로 합쳐 실행하는 것을 Kernel Fusion 이라고 합니다. Matmul Kernel 의 결과를 메모리에 저장하고 Add Kernel 이 다시 메모리에 저장된 결과를 불러와 연산에 사용해야 하는 overhead 가 발생하는데, kernel 내에서 sharedmemory 나 register 를 공유해 이러한 overhead 를 제거할 수 있습니다. Kernel Fusion 은 주어진 연산 그래프가 있을 때 잘 알려진 패턴이 보이면 이를 Fused 된 Kernel 로 교체하여 성능 최적화를 만들어냅니다. 이 기법은 학습/평가시에 모두 적용할 수 있음으로 딥러닝