안녕하세요. 카카오페이 데이터실 Jenson, Todd입니다.카카오페이에서는 얼굴을 탐지하고 검증하는 기술을 활용해 고객 편의성과 안정성을 제공하고 있습니다. 저희는 얼굴 탐지 및 검증 기술을 서비스에 제공하는 프로젝트에서 서버를 개발하고 있습니다. (카카오페이 개발자센터에서 얼굴 인식 API를 제공하고 있으니 사용해보세요. ?)저희 서버는 현재 kotlin + spring boot 를 사용하고 있습니다. 하지만 이미지 처리 코드 포팅 및 결과값 정합성 등의 이유로 Python 기반의 서버 프레임워크를 사용하는 것으로 결정하였고, 어떤 프레임워크를 사용할지에 대한 고민과 결정을 공유드리고자 합니다.아래의 고민을 하고 있는 분들에게 많은 도움이 될 것 같습니다. ?이미지 처리를 담당하는 서버를 구축해야 하는데, 언어/프레임워크 선정부터 고민이야.java(kotlin)+spring boot를 사용하고 있는데, 개발 생산성이 부족한 것 같아. 다른 프레임워크 맛이나 볼까?왜 저희가 Python 기반의 서버 프레임워크를 사용하게 되었는지 말씀드리겠습니다.현재 저희 개발 Flow 입니다.모델 학습 및 검증 (By data scientist) 이미지 처리 로직 Python 으로 작성 (By data scientist) Python 으로 작성된 코드 kotlin 으로 포팅 (By ML engineer) 결과 정합성 검증 (By data scientist & ML engineer) 서버 개발 (By ML engineer) 실제 서비스 적용kotlin + spring boot 로 이미지 처리 서버를 개발하기 때문에 3, 4번과 같이 포팅, 정합성 검증하는 flow가 반드시 필요합니다. kotlin 에서의 이미지 처리는 OpenCV를 자바에서 사용하기 쉽게 래핑한 JavaCV를 사용했고, 행렬 처리는 native code로 작성했습니다. 아무래도 kotlin 에서는 이미지 처리 작업이 main job이 아니기 때문에 정보도 적고, 지원하지 않는 기능인 경우 native code로 작성하는 경우가 발생했습니다. 간단하게 예를 들어보면, 행렬의 축을 바꾸는 전치 코드를 Python 에서 kotlin 으로 포팅하여 비교해보겠습니다.Python 코드import numpy as np np. transpose (array)kotlin 코드fun Array. transpose (): Array < IntArray > { val cols = this .first().size return this .fold( List (cols) { IntArray ( 0 ) }) { list, arr -> list.zip(arr.toList()) { a, b -> a + b } }.toTypedArray() }위와 같이 Python numpy에서 제공하는 행렬 연산들을 kotlin으로 포팅하기 위하여 native code를 작성하거나 JavaCV의 연산을 사용하게 됩니다. 포팅이 끝나면 이어서 결과값 검증을 진행합니다. 검증이 한번에 잘 끝나면 좋겠지만, 다르게 나오는 경우에는 과장을

AWS Inferentia를 이용한 모델 서빙 비용 최적화: 모델 서버 비용 2배 줄이기 2탄우당탕탕 Inferentia 배포하기지난 글에서는 AWS Inferentia 소개와 사용법, GPU와의 성능 비교 등을 설명해 드렸어요! 이번 글에서는 Inferentia를 실제 서비스에 도입하기 위해 핑퐁팀에서 어떤 과정들을 거쳤는지 소개해드릴게요.?정합성 검증AWS Inferentia는 모델의 정확도는 유지하면서 모델 추론 속도를 빠르게 하도록 BF16을 이용한 mixed precision을 지원하고 있어요. BF16은 부호 비트 1개, 지수 비트 8개, 가수 비트 7개로 구성된 16비트 부동 소수점 형식을 의미해요. 16 bits로 이루어져 있어 FP32에서 필요한 메모리의 절반만 필요하지만, 표현할 수 있는 범위는 FP32와 같아요. Overflow, Underflow, NaN 등을 맞추기 위해 loss scaling이 필요한 FP16과는 달리, 아무런 변경 없이 BF16을 이용해 FP32를 대체할 수 있어요. 하지만, 가수부가 더 적은 비트로 표현되기 때문에 정확도는 살짝 떨어질 수 있게 돼요. BF16에 대해 더 궁금하신 분들은 해당 논문을 참고해주세요.기본적으로 Neuron Hardware에서는 BF16 또는 FP16 값에 대해 행렬 곱셈 연산 후 FP32로 누적합니다. Compile 시에는 기본으로 FP32로 학습된 모델을 BF16으로 자동 캐스팅해서 FP16의 속도로 추론할 수 있게 해줘요. 그렇다면 자연스럽게 추론 속도와 모델 정확도 사이의 trade-off가 발생하게 되겠죠? 저희는 간단한 정합성 검증을 통해 GPU 위에서 FP32 포맷으로 모델을 추론했을 때와 Inferentia 위에서 추론했을 때의 모델의 정확성을 비교해보았어요.실험 세팅두 문장이 얼마나 유사한지를 측정하는 KLUE STS 태스크를 통해 정합성 검증을 진행했어요. KLUE STS는 두 문장을 주면 문장 사이의 의미적 유사성을 0에서 5 사이의 실숫값으로 예측하고, threshold인 3을 넘으면 유사하다, 넘지 않으면 유사하지 않다고 이진화해서 F1 Score를 계산해요. 저희는 간단하게 정합성을 테스트하기 위해 1) 0~5 사이의 모델 추론 값 비교, 2) 추론 값을 0, 1로 이진화했을 때 값이 달라지는 지를 확인했어요.KLUE 측에서 제공한 학습 데이터셋을 이용하여 사전 학습된 klue/roberta-base 모델을 Fine-Tuning 했어요. 학습이 완료된 모델을 GPU에서 추론하기 위해 SavedModel 형식으로 저장하고, Inferentia 위에서 추론하기 위해 Neuron Compile 후 SavedModel 형식으로 한 번 더 저장해주었습니다. Neuron Compile하는 법은 이전 포스트인 AWS Inferentia를 이용한 모델 서빙 비용 최적화: 모델 서버 비용 2배 줄이기 1탄에서 소개하고 있으니 참고해주세요.GPU 인스턴스로는 g5.xlarge를 사용하였고, Inferentia 인스턴스로는 inf1.xlarge를 사용했어요. 실

안녕하세요, 카카오페이 머신러닝 엔지니어 카일입니다.카카오페이 데이터 프로덕트 팀에서는 얼굴 인식, OCR(Optical Character Recognition) 등의 기술을 활용하여 여러 서비스를 실시간으로 제공하고 있습니다. 서비스 목적에 따라 다양해지는 모델과 높아지는 서비스 요구사항(낮은 지연시간과 높은 처리량)을 반영하기 위해 효율적인 모델 서빙 프레임워크의 도입을 고민했습니다.본 포스팅에서는 카카오페이 상황에 맞는 최적의 모델 서빙 프레임워크 선정을 위하여 프레임워크들을 비교하고, 선정된 프레임워크의 서빙 성능 최적화를 위해 다양한 기능을 테스트한 결과를 공유해 드리려고 합니다. 테스트 결과는 모델 서빙 프레임워크를 도입하고자 하는 분들에게 좋은 벤치마킹 데이터가 되리라 생각합니다. ?카카오페이에서 제공하는 여러 딥러닝 모델 중 얼굴 인식에 활용하는 모델을 예시로 설명을 드리려 합니다.기존에는 각 개발 영역에서의 생산성을 위해 모델 개발을 하는 머신러닝 리서처는 파이썬 을 이용했고, 모델을 서빙하는 백엔드 개발자는 코틀린+스프링부트 로 직접 서버를 개발했습니다. 이는 각 엔지니어들의 개발 생산성은 높였지만 아래와 같은 어려운 점들이 있었습니다.파이썬 기반의 모델 전/후처리 코드를 코틀린으로 변환하는 과정에서 추가적인 개발이 필요했고, 종종 변환 과정에서 결과의 정합성 이슈가 발생했습니다. 다양한 딥러닝 프레임워크(Tensorflow, PyTorch 등)로 개발된 모델은 정합성의 차이가 허용 가능한 선에서 인퍼런스 최적화를 위해 모델이 변환(ONNX, TensorRT 등) 될 수 있고, 최종적으로 모델별 최종 서빙 포맷이 다를 수 있었습니다. 하지만 다양한 포맷의 모델을 서빙하는 것은 개발 생산성, 운영 안정성 측면에서 문제가 있어, 최선의 선택은 아니지만 하나의 포맷으로 통일해서 서빙을 수행해야 했습니다. 직접 모델 서빙 서버를 개발할 경우, 서비스 요구사항을 만족시키기 위한 성능 개선과 튜닝 작업에 많은 시간과 비용이 소요되었습니다.개발 언어 간 변환 과정에서 발생하는 문제점을 해소하기 위해 모델 학습, 개발 및 서빙을 위한 언어를 파이썬 으로 통일하기로 결정했습니다. 그리고 모델 서빙 프레임워크를 도입함으로써 나머지 문제점을 해소하고자 했습니다.카카오페이 내 모델은 대부분 Tensorflow 기반으로 학습되었고 모델 서빙에 활용되었습니다. 하지만, Tensorflow 모델만으로는 원하는 수준만큼의 인퍼런스 속도가 나오지 않는 경우도 존재했습니다. 이를 개선하기 위해 모델 인퍼런스 최적화 및 가속화 엔진을 활용하여 최적화된 모델들을 확보했습니다. 대표적으로 알려져 있는 ONNX(Open Neural Network Exchange)와 TensorRT를 활용했습니다.ONNX는 각기 다른 딥러닝 프레임워크로 학습된 모델을 서로 호환할 수 있도록 해주는 표준 역할을 합니다. Tensorflow, PyTorch 등으로 학습된 모델은 대부분 문제없이 ONNX로 변환할 수 있으며, 변환하는 과정에서 모델의 그래프가 최적화됩니다. ONNX

원티드 서버개발자 QnA 1편 ‘원티드 서버 FastAPI 도입 장점과 단점’안녕하세요, 원티드 DevRel 매니저 장명희입니다:)원티드의 메인 서버 개발 언어가 Python이라는 사실, 게다가 Flask나 Django도 아닌 FastAPI를 사용한다는 사실 알고 계셨나요?약 두 달 전, 베일에 싸여있던 원티드 서버개발 직무를 파헤치기 위해 질문을 수집했습니다.그 결과 무려 440분께서 670개의 질문을 보내주셨는데요, 공통으로 많이 궁금해하셨던 질문들을 모아서 원티드의 서버 개발자분들이 직접 답변해주는 시간을 가져보았습니다.서버개발자들이 직접 말하는 원티드 서버개발 이야기, 지금부터 들어볼까요??원티드 서버개발 미리 엿보기 * Python2.x 버전에서 Python3로 전환* Flask에서 FastAPI로 이전하며, FastAPI를 활발하게 사용 중* 각 사업별로 구성된 스쿼드라는 목적조직으로 나눠져 개발 중* 상황에 맞게 다양한 DB를 사용하며 기술선택에 있어서 유연한 편* 주요 기술 스펙 : Python, FastAPI, Flask, AWSDevRel 매니저와 Python 서버 개발자분들Q. 원티드 서버개발자가 사용하는 기술 스택을 소개해주세요!(상민) 원티드의 서버는 파이썬(Python)을 메인으로 사용하고 있습니다. 일부 프로젝트에서는 장고(Django)나 노드(Node.js), 자바(JAVA), 그리고 루비(Ruby)같이 다양한 언어도 활용하고 있어요. 자바로 전환할 계획에 대해서 질문 주신 분도 계셨는데, 지금까지는 파이썬을 사용한다고 해서 발생하는 문제나 어려움은 없었다고 판단했기 때문에 언어 자체의 문제만으로는 자바로 전환할 계획은 없습니다!Q. 웹 프레임워크 FastAPI를 사용한다고 하셨는데, 간단히 설명해주세요!(상민) 네, 저희가 사용하는 웹 프레임워크는 ‘FastAPI’라는 프레임워크고요. 이름에 Fast가 들어가있는 것처럼, 성능에 장점을 갖고 있는 웹 프레임워크에요. 비교적 신생 오픈소스 프로젝트임에도 불구하고 플라스크를 대체할 수 있는 모던 웹프레임워크라는 장점으로 빠르게 성장하고 있습니다.Q. FastAPI는 비교적 최근에 개발된 프레임워크인데요, 원티드는 어떻게 FastAPI를 도입을 결정하게 되었나요?(영식) 제가 처음 입사했을 때 원티드는 Python2와 플라스크(Flask)를 사용하고 있었고, Python3로 옮겨가려고 마이그레이션을 계획하고 있었을 때였어요.제가 개인 프로젝트로 운동 기록하는 애플리케이션을 만들어서 지금까지 계속 운영하고 있는데, 백엔드 서버를 FastAPI를 도입해서 사용해보고 있었거든요. 이런 프레임워크 같은 것들이 새롭게 나오면 대부분 굉장히 좋다고 말씀하시지만, 프로덕션 레벨에 적용하는 것은 많은 고민이 필요한 사항들이 많잖아요. 그래서 일단 간단하게나마 제 개인 프로젝트를 통해 실제 프로덕트에 도입을 해봤기 때문에 제안드릴 수 있었던 것 같아요. 타이밍도 운 좋게 맞물렸던 거죠. “FastAPI를 한번 사용해보면 어떻겠냐”라고 제안을 드릴 때 보일러플레이트같은 걸 만들어서