다들 알고 계시겠지만, 얼마 전에 큰 일이 있었어요.지난 목요일(5/3)에 cdn.jsdelivr.net이 접속불능에 빠졌습니다.bootstrap, jquery 등등을 저희가 link tag로 편하게 이용하고자 할 때, 무심코 접속하게 되는 사이트입니다.제가 js, css 번들을 다운 받을 필요 없이, 단지 저 link tag를 html에 삽입하는 것만으로 위 라이브러리들을 사용할 수 있어서 편하게 사용들을 했었는데요.저거 넣어서 만들었던 서비스들이 여럿 깨져있어서, cdn.jsdelivr.net이 복구 될 때까지 매우 혼란스러운 하루를 보냈었습니다.대부분의 서비스는, js, css 번들 다운 받아 붙이는 걸로 금새 복구할 수 있었는데,fastapi에는 자동으로 swagger 문서를 생성해주는 매우 편리한 기능이 있는데요.이걸 사내 api 만들어서 공유할 때 engr들이 엄청 많이 쓰고 있었는데, (사실상 fastapi를 사용하는 이유의 8할...)문제는 fastapi에서 자동으로 만드는 swagger 문서가이 두 녀석으로부터 css, js를 받아온다는 것이었습니다.fastapi에서 자동으로 생성해주는 docs endpoint에 대한 configuration 때문에 고민을 좀 했었어요. 결론적으로는 이렇게 해결하시면 됩니다.일단 swagger-ui.css 하고 swagger-ui-bundle.js 를 구합니다.저는 그냥 브라우저로 저 url에 접속해서 구해둔 게 있어서 썼는데요. 구글 검색하시면 css, js 구하실 수 있으실 거예요.얼추 project가 이렇게 구성되어 있다고 치면,app.py를 이렇게 구성하시면 됩니다. 간단한 샘플 코드니 보면 바로 이해되실 거예요.기본적으로 fastapi의 /docs endpoint는fastapi.openapi.docs 에 있는 get_swagger_ui_html 을 실행해서 출력하도록 되어 있습니다.이 부분을 원하는 대로 커스터마이징해서 실행하도록 구성하면 설정을 바꿔줄 수 있어요.저 코드를 실행하고 docs 엔드포인트에 들어가보면저렇게 swagger 문서에서 cdn.jsdelivr.net과의 의존성이 없어진 것을 확인하실 수 있습니다.

안녕하세요. 카카오페이 데이터실 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