# inference

LLM이 text를 생성하는 방식과 생성 전략
LLM의 inference 과정을 설명 허깅페이스 모델의 generate 함수를 직접 구현하여 구체적 설명 생성 전략의 간략한 소개 Transformer 모델은 주로 Encoder와 Decoder 두 계열로 구분됩니다. Encoder 계열 모델, 예를 들어 BERT 같은 모델의 추론 과정은 직관적이고 이해하기 쉽습니다. 주어진 입력 시퀀스는 여러 레이어들을 거치며, 각 토큰 간의 Attention 연산이 수행됩니다. 이 과정을 마치면 마지막 레이어의 형태에 맞는 출력이 도출됩니다. 반면, 생성형 LLM인 Decoder 계열의 생성 과정은 처음 접할 때 직관적으로 이해하기가 어렵습니다. 대다수의 사용자들이 Hugging Face의 Transformers 라이브러리에서 제공하는 model.generate() 메서드를 이용해 추론하는데, 이 메서드 내부에서 정확히 어떠한 과정으로 텍스트가 생성되는지에 대한 깊은 이해 없이 사용하는 경우가 많습니다. 저 역시 처음에는 LLM 모
타입스크립트 정리2: annotation, 함수
Type annotation 타입 애너테이션으로 타입을 선언해줄 수 있다 어떤 함수는 숫자만 반환해야 한다던가 어떤 객체는 color라는 프로퍼티를 갖고 그것은 문자열의 배열이어야 한다 이렇게 정해놓을때 변수 이름 뒤에 콜론 : 을 적고 타입을 적어주면 된다 콜론 뒤에 string이 타입스크립트에게 이 변수가 문자열이라는 걸 알려주고 ‘So Awesome!’ 과 같다고 말해주는 것이다. 사용하는 법 구문에서 등호 왼쪽에 타입을 써준다 (소문자로 써야한다) 이렇게 지정해 놓으면 이 변수에 다른 타입을 배정하려고 하면 오류 표시가 뜬다 또한 해당 타입에는 쓸수 없는 메서드를 쓰려고 하면 오류가 뜬다. 숫자와 불리언 숫자는 number 불리언은 boolean 타입스크립트 컴파일링 타입스크립트로 작성하고 자바스크립트로 컴파일할때는 터미널에서 파일 위치 디렉터리만 지정하면된다 터미널에서 다음과 같이 쓴다 이렇게 하면 b
[MLOps] Triton Inference Server 구축기 2 - model repository 만들기
이전 글에서 triton inference server를 docker로 띄우는데 성공하였다면, 이제 serving 하고자 하는 모델을 triton에 올릴 차례이다. triton은 모델 저장소(model-repository)에서 각각의 모델과 메타 데이터(버전 등)을 읽어와 서버로 띄운다. model-repository는 로컬 혹은 remote cloud인 AWS S3, Azure Blob Storage, Google Cloud Storage가 될 수도 있다. 여기서는 로컬 환경에서의 repository 구성을 하려 한다. Model Repository의 구조 우선 serving 할 모델들이 위치할 폴더를 하나 생성한다. 그 다음 생성한 폴더 아래에 아래와 같은 layout으로 model, config 파일 등을 넣어둔다. [Model-repository 구성 예시] Model-repository는 총 세가지 구성 요소로 되어 있는데, 1.
[MLOps] Triton Inference Server 구축기 1 - 설치
공식 문서에서 추천하는 triton build 및 deployment 방법은 docker 이미지를 통한 빌드이기 때문에 추천하는 방식으로 블로그를 쓰려고 한다. 1. Docker, NVIDIA Container Toolkit 설치하기 Triton inference server 설치 전 아직 docker와 NVIDIA Contianer Toolkit이 설치되어 있지 않다면 설치해주자. Docker 다운로드 : https://github.com/NVIDIA/nvidia-docker NVIDIA Contianer Toolkit 다운로드 : https://github.com/NVIDIA/nvidia-docker 만약, DGX 유저라면 아래 링크를 따라 셋팅하면 된다. https://docs.nvidia.com/deeplearning/frameworks/preparing-containers/index.html 2. NVIDIA driver 버전 확인하기 NVIDIA
[MLOps] Triton Inference Server 구축기 0 - 공식 문서 모음
[Update] 28 Feb - 7번 Tutorial repo 추가 Triton으로 inference server를 구축하는 과정에서 정보가 많이 없어 고생을 많이 하고 있다. 예시도 많이 없을 뿐더러, Nvidia에서 나온 공식 문서도 이곳 저곳 흩어져 있어서 이곳에 정리해보려 한다. 삽질하는 시간을 줄이는 방법은, 공식 문서를 보는 것이기 때문에..! Triton Inference Server Offical Docs 1. Triton Inference Server Release Notes -> Link Triton의 이전 버전부터 최신 버전까지의 release note를 확인할 수 있다. 또한, 가장 중요한 driver requirements(CUDA, CuDNN, NVIDIA

[MLOps] Inference Model Format
딥러닝 모델을 학습하고 나면.. PyTorch와 같은 딥러닝 프레임워크를 통해 학습한 모델을 실제 product에서 활용하려면 아래와 같이 모델의 변환이 필요하다. Eager Mode prototyping, training, experimenting에 적합함 Script Mode production deployment가 가능하도록 최적화 된 모델 모델 서빙 형식 Production 용(?) 모델 포멧은 아래와 같이 여러가지가 있는데, 파일의 확장자라고 생각하면 쉽다. 1. TensorRT (model.plan) NVIDIA에서 만듦. 학습된 Deep Learning 모델을 최적화하여 NVIDIA GPU 상에서의 Inference 속도를 수배~수십배 까지 향상 가능 다만,

M1 Part12 - '아직은 잘 모르겠는' BetterTransformer on M1
INTRO 2022년 11월 22일쯤에 우연히 BetterTransformer, Out of the Box Performance for Hugging Face Transformers이 포스트를 발견하였다. 들뜬 마음에, 링크부터 저장하였다. 원래는 무언가 실험을 하고 싶었으나, '토치의 호흡' 강의하드캐리하느라 시간이 없어서 다소곳하게 SLACK 한 구석에다가 링크만 저장해두었다가, 이제서야 보면서 실험을 해보았다. 그런데... 문제는 BetterTransformer을 목적을 아직 잘 모르겠다는 것이다. (아마 필자의 내공이 아직 부족해서 그럴 것이다.) 이유는 이제부터 차차 말해보겠다. 실습은 필자의 경우, M1에서 진행하였고, Pytorch 2.0

yolo v7 export.py 분석하기
어제 torch.jit.script 활용하여 pt 파일을 생성해보려 했지만, 제대로 되지 않았다. 따라서, yolo v7의 소스코드에 있는 export.py 를 분석하여, 어떤 방식으로 pyTorch 모델을 architecture와 parameter가 담긴 pt파일이 생성된다. 어떤 방식으로 이루어지는지 알아보도록 하겠다. 위의 명령어를 활용하여 export 시킨다. weights : 가중치 파일 release 폴더에서 download 받아와서 사용한다. pt 파일이며, 단순히 torch.save를 했을 때, 갖는 파일과 동일하다 node 정보는 존재하나, models/common의 class단위로 node 정보를 표시해놨다.

Inference - 3
해당 시리즈는 LG에서 지원하는 LG Aimers의 교육 내용을 정리한 것으로, 모든 출처는 https://www.lgaimers.ai/ 입니다. 위의 3 도시는 서로 다른 데이터를 만들어낸다. LA는 Z1에 대한 실험을, 뉴욕은 간단한 관찰을, 서울은 Z2에 대한 실험을 진행했다. LA의 데이터셋은 데이터를 샘플링하는데 있어, 인구 모집단에 대해 무작위 샘플링을 한 것이 아니라, 특정한 변수인 나이에 대해 샘플링을 진행했다. 뉴욕의 경우, Socioeconomic Status, SES라고 하는 사회 경제적인 사람들의 상태에 따라서 데이터가 수집될 수 있는 특징을 이용했다. 이런 식으로 데이터는 다양한 특성을 가지고, 인과 추론을 하는 데 있어 이러한 특성들을 고려하지 않고, 인

Inference - 2
해당 시리즈는 LG에서 지원하는 LG Aimers의 교육 내용을 정리한 것으로, 모든 출처는 https://www.lgaimers.ai/ 입니다. Casual Effect Identifiability 이번 장에서는 인과효과를 계산하는 방법에 대해 알아본다. 위의 3가지를 이용하여 인과추론 알고리즘을 통해 계산을 진행한다. 계산이라고 말은 했지만, 특정할 수 있는지를 물어보는 것이고, 실제로 가능하다면 인과효과를 계산할 수 있을 것이고, 특정할 수 없다면 계산할 수 없다는 것이 아니라, 주어진 그래프와 데이터가 있을

Inference - 1
해당 시리즈는 LG에서 지원하는 LG Aimers의 교육 내용을 정리한 것으로, 모든 출처는 https://www.lgaimers.ai/ 입니다. casual inference은 인과성에 대한 소개와 인과적 추론을 하기 위한 기본 개념이다. Casuality casuality는 하나의 어떤 무언가가 다른 무엇을 생성함에 있어 영향을 미치는 부분적인 관계를 말한다. 이는 즉, 원인과 결과 사이의 관계는 필요조건이나 충분조건일 필요가 없다는 말이다. 예를 들어 '버스를 놓쳐서 지각을 했다' 라는 문장이 있으면, 이는 인과적 관계를 보인다. Science는 일반적 사실이나 법칙을 포함하는 지식체계로 정의하며, 여기서 법칙은 현상의 본질적인 구조를 명확하게 한 것을 의미한다. 과학에서 물리나 화학과 같은 자연과학과 함께 심리학, 경제학과 같이 실험하기 어려운 사람, 사람 집단의 행동에 대한 연구하는 것들은 단순히 상관관계를 찾는 것이 아니라,

[MLOps] Multi-Model 서빙을 위한 RedisAI Cluster 구축하기 1편 - What is RedisAI ?
최근 팀에서 자체 NLU 모델을 개발하며 안정적인 Multi-model Serving에 요구가 생겼습니다. 그 동안 NLU 엔진은 DialogFlow, Watson, Lex 등의 서비스에 비용을 지불하며 SDK로 연동해왔으나, 추론 성능, 모델 관리, 비용 등에 제약이 많았습니다. 따라서 좀 더 유연한 모델 생성 및 관리, 지속적인 학습, 빠른 추론 성능을 위한 NLU 파이프라인을 구축해나가기 시작했고 그 중 가장 고민을 많이 한 부분은 모델 서빙 파트였습니다. 현재 운영중인 서비스의 NLU 모델은 각 유저(에이전트)마다의 학습모델이 존재합니다. 즉, 10명의 고객이 있다면 10개의 모델이 존재하는 것이죠. 고객이 늘어날수록 관리해야하는 모델도 선형적으로 증가하게 됩니다. 추론 서버

Model Train Job API 개발 - Kubernetes 환경
_ 1. 배경_ 쿠버네티스가 컨테이너 오케스트레이션 도구로 각광을 받은 이유 중 AI 환경에서의 편의성이 높은 점도 있다고 생각합니다. ML Pipeline 환경을 쿠버네티스에서 운영했을 때 학습,관리,배포를 모두 운영 할 수 있습니다. 이러한 각각의 오픈소스(Notebooks, Katilb 등)를 조합해 플랫폼화 한것이 Kubeflow 입니다. 하지만 Kubeflow는 아직 많은 사례가 없고 사용이 어렵다는 단점이 있습니다(일반적인 AI 엔지니어 입장에서). 또한 Job을 관리하는 기능이 없기 때문에 이번에 Kubernetes를 통해 Job을 생성하는 API를 만드는 작업을 진행하였습니다. 현재 글에서 작성하는 Job은 AI pipeline에서 Model Training 부분에 속합니다.

Model Inference with ONNX
현재 Pytorch는 Tensorflow를 뛰어넘어 가장 많이 사용되는 Deeplearning 프레임워크이다. pytorch가 연구/개발하기에는 여러모로 편리하지만 실제 realtime 서비스에 사용하기엔 추론성능이 좋지 않아 연구는 pytorch 서비스는 tensorflow로 한다는 말이 있을 정도다. 이 포스팅은 개발한 pytorch 모델을 바로 서빙에 사용할 수 있도록 Pytorch로 개발한 모델(using transformers)을 onnx포멧으로 변환하고 모델최적화, 그리고 onnxruntime으로 서빙하는 과정을 소개한다. ONNX (Open Neural Network eXchange) AI 서비스은 위해 모델을 개발, 학습하고 추론서비스를 배포하는 과정으로 나뉠 수 있는데 개발자에 따라 선호하는 프레임워크와 추론서비스가 배포되는 하드웨어가 다양해 최적화하는 과정이 복잡하다. 자연어처리분야 AI개발자인 나는 Pytorch로 모델 개

[TS] (2) 기초 : 타입 선언과 타입 추론
타입 선언과 타입 추론(inference) 1) 타입 추론 없이 타입 선언하기 : 얼마나 코드가 길어질지... a) 변수에 타입 선언 : '변수명: 타입'(타입 추론은 적용하지 않았습니다) 변수 선언만 할 때도 미리 변수에 들어갈 타입을 선언할 수 있다. 객체: 아래처럼 세미콜론으로 프로퍼티를 나눠 선언한다. b) 함수에 타입 선언(타입 추론은 적용하지 않았습니다) 매개변수의 타입 선언 : 변수에서와 동일. ( 중요 ) return 값의 타입 선언(다양함) : 괄호("()") 옆 타입 작성 2) 타입 추론(Type Inference)을 활용하여 타입 선언하기 >타입 추론이란? : 타입을 선언하지 않더라도, 코드 문맥상 추론 가능한 가장 흔한 타입(best common type)으로 선언되는 것. [Documentation - Type Inference - TypeScript](https://www.typesc

TIL 49 | Type Inference
Type Inference(타입 추론) Inference TS에서 변수 명에 특정 값을 할당할 때, 타입을 따로 명시하지 않았을 경우 알아서 타입이 자동으로 결정되는 것을 말한다. > 위처럼 text 변수 명에 hello를 할당하였더니 변수 타입이 string으로 추론되어 자동으로 결정되었다. 이후 타입이 number값인 1을 재할당하니 에러가 발생한다. (기존의 text 타입이 string으로 결정되었기 때문이다.) Intersection in default > 특정 함수의 인자의 타입값을 따로 지정하지 않고, default 값에 따라 타입이 추론되어 지정될 수 있다. add 함수의 경우, 인자들이 숫자값이므로 number로 타입이 추론되어 결정되었다. 또한 result값도 add의 return값이 number 타입을 갖고 있으므로 위같은 결과를 확인할 수 있었다. -