Attention, Please!!!

대규모 언어 모델이 다양한 분야에서 활용되면서, 학습된 모델을 실제 서비스에서 효율적으로 운영할 수 있는 추론하는 방법이 그 어느 때보다 중요해지고 있다. 무지막지한 성능의 LLM을 개발하는 것만큼이나, 이를 빠르고 비용적인 측면에서 효율적으로 사용하는 것이 어찌보면 핵심적이다. 이러한 LLM 추론 환경의 중심에는 vLLM과 Ollama라는 두 개의 강력한 오픈소스가 존재한다. 하지만, 둘 간의 지향하는 목표가 근본적으로 다르다. vLLM은 서버 환경에서 다수의 요청을 동시에 처리하며 처리량을 극대화하는 데 최적화 되어 있는 반면, Ollama는 개발자 개인의 컴퓨터에서 모델을 쉽고 간편하게 실행하는 데 중점을 둔다. 이처럼 사용하는 목적이 굉장히 다르기 때문에, 적절한 상황에 맞춰 사용하는 것이 중요하..

LLM에서 임베딩은 텍스트의 의미를 수치적으로 얼마나 잘 표현하는지에 따라 모델의 언어 이해 및 생성 능력을 결정짓는 핵심적인 요소이다. Next Token Prediction 기반의 Causal Masking 기법을 사용하는 모델이든, 문장 전체를 한 번에 보고 특정 단어의 의미를 그 단어의 앞과 뒤에 있는 모든 단어를 동시에 참고하는 Masked Language Model이 있다. 전반적으로 LLM 시장을 아우르는 두 개의 모델은 단어나 문맥의 미묘한 차이를 정확히 포착하는 고품질 임베딩 모델이 필수적이다. 하지만 "How Contextual are Contextualized Word Representations?" 논문에 따르면, 모델이 상위 계층을 거치면 거칠수록 문맥 특정성이 높아진다고 지적한다..

Retrieval-Augmented Generation (RAG)는 대규모 언어 모델이 가진 환각 (Hallucination) 현상을 완화하고, 최신 정보나 특정 도메인의 지식을 기반으로 정확하고 신뢰성 높은 답변을 생성할 수 있게 돕는 강력한 프레임워크이다. 이러한 RAG의 성능을 좌우하는 가장 중요한 구성 요소 중 하나가 바로 임베딩 모델이라고 해도 무방하다. 임베딩 모델은 RAG 프레임워크에서 심장과 비슷한 역할을 수행하며, 전체 시스템의 효율성과 정확성에 결정적인 영향을 미치게 된다. 하지만, 일반적인 목적으로 학습된 임베딩 모델은 특정 전문 분야의 용어나 미묘한 문맥 차이를 제대로 파악하지 못하는 경우가 대부분이며, 이를 해결하고자 임베딩 모델을 찾거나 scratch 부터 학습 시키는 것은 굉장..

Padding Token은 입력 시퀸스의 길이를 맞추기 위해 추가되는 특수 토큰이다. 트랜스포머 모델은 병렬적으로 모든 토큰을 처리하기 때문에, 입력 시퀸스의 길이가 동일해야한다. 이에 가장 많이 사용되지만, 메모리와 계산량 측면에서 상당한 낭비를 초래한다. 이에 최근에는 Packing으로 시퀸스의 활용도를 극대화하고, 계산 비용을 최소화할 수 있는 Packing이 제안되였다. 하지만, 종종 Packing을 기반으로 파인튜닝하는 게시물 혹은 영상물을 여럿 찾아볼 수 있지만, 이에 대한 성능의 효율성을 보여주는 것이 대부분이다. 구체적으로 패킹이 파인튜닝하는 과정에서 내부적으로 어떻게 작동하는지에 대해서는 설명하지 않는다. 따라서, 본 게시물에서는 Padding과 Packing를 SFT 기반으로 파인튜닝..

대형 언어 모델(LLM)을 처음부터 구축하거나 혹은 복잡한 딥러닝 모델을 다룰 때, 필연적으로 GPU를 활용하는 경우가 대부분이다. 이에 따라 Pytorch에서는 .to(device) 라는 간편한 메서드를 통해 모델의 파라미터를 원하는 장치(CPU 혹은 GPU)로 손쉽게 옮길 수 있는 기능을 제공한다. 하지만 모델을 GPU로 옮겼다고 생각했는데, 막상 실행 했을 때 " Expected all tensors to be on the same device, but found at least two devices, cuda:0 and cpu!" 와 같은 RuntimeError를 마주하게 된다. 이러한 문제는 모델의 파라미터(nn.Parameter)외에, 학습되지는 않지만 모델의 동작에 필수적인 텐서가 GPU로 ..

대규모 언어 모델(LLM)의 Self-Attention 메커니즘은 모델의 성능을 좌우하는 가장 핵심적인 요소로, 문맥을 전역적으로 이해하고 복잡한 언어의 패턴을 학습하는 데 필수적이다. 그러나, Multi-Head Attention(이하 MHA)은 높은 계산 비용과 메모리 사용량으로 인해 대규모 모델의 효율적인 학습과 추론에 제약적이다. 이를 해결하기 위해 제안된 Grouped-Query Attention(이하 GQA)가 제안되었으며, 이는 쿼리 헤드를 적은 수의 키-값(KV)헤드로 그룹화하여 메모리 사용량을 줄이고 추론 속도와 효율성을 높였다. 하지만, GQA의 방식은 모델에 따라 품질 저하가 발생하는 단점이 있다. 이러한 한계를 극복하기 위해 DeepSeek에서 제안하였던 Multi-Head Lat..

초기 대형 언어 모델들은 대체적으로 float32 데이터 유형을 통해 훈련하고 배포된다. 하지만 float32는 각 파라미터가 32비트 (즉, 4바이트)를 차지하기 때문에, LLaMA 3와 같은 700 억 개 파라미터를 가진 모델의 경우 필요한 메모리의 소비량이 대략 280GB에 달한다. 이 엄청난 메모리 사용량은 대규모 모델의 배포와 운영적인 측면에서 어려움을 겪고 있다. 이에 이러한 문제를 해결하기 위해 LLM 개발자들은 메모리 소비를 절반으로 줄일 수 있는 float16를 사용하고 있는 추세이다. 하지만 float16으로 전환하는 것은 다양한 문제점을 동반한다. float16은 표현 가능한 숫자의 범위와 정밀도가 float32에 비해 훨씬 적기 때문에, 모델 훈련 중에 오버플로우(숫자가 커져 버리는..

요즘 여러 모델들을 다뤄보고 LLM 관련 논문을 읽어보면서, 문득 이런 생각이 들었다. "과연, Perplexity를 기반으로 LLM을 평가하는 것이 합리적일까?" 물론 Perplexity는 언어 모델들의 주요 평가 지표 중 하나로 가장 많이 사용되고 있다. 이를 통해 모델이 주어진 토큰 시퀀스를 얼마나 잘 예측하는지를 측정하게 되며, 학습 중에 모델의 목표는 이 값을 최소화하는 것이다. 따라서 Perplexity가 낮을수록 모델이 더 좋은 성능을 발휘한다고 일반적으로 이야기할 수 있게 된다. 하지만 이 지표만으로 모든 것을 판단하는 것이 정말 타당할까라는 의문이 든다. 이에 본 게시물에서는 "만약 동일 데이터 셋을 기반으로 학습된 모델 A의 perplexity가 2.5이고, 모델 B의 perplexit..

Gemma 3 모델을 완전하게 파인튜닝하려면 80GB VRAM을 지원하는 고성능 GPU가 필요하다. 그러나 LoRA를 기반으로 파인튜닝할 경우, 1B 및 4B 모델은 24GB VRAM이 요구되며, 27B 모델은 54GB VRAM이 필요하다. 다만, 27B 모델을 4비트로 양자화하면 24GB VRAM에서도 파인튜닝이 가능하지만, 시퀀스 길이가 제한되며 임베딩을 재학습할 수 없다는 단점이 있다. 이로 인해 chat template 사용 시 문제가 발생할 수 있다. Chat template은 대화형 AI 모델이 채팅 환경에서 효과적으로 작동하도록 설계된 특정 구조를 의미하며, 일반적으로 또는 같은 특별 토큰을 포함한다. 하지만 이러한 토큰이 학습되지 않으면 모델이 대화 흐름을 제대로 이해하지 못해 부정확하..

2025년 3월 중 구글은 Gemma 모델 시리즈의 업데이트 버전인 Gemma 3를 발표하였다. 이 모델은 비슷한 파라미터를 가진 다른 오픈 소스 모델들에 비해 강력한 성능을 보여주며, 100B 파라미터 미만의 오픈 LLM 중 가장 뛰어난 능력을 갖춘 Gemma 3의 27B 모델이 있다. 이를 달성하기 위해 구글은 정확도와 효율성을 모두 개선할 수 있는 새로운 아키텍처를 개발하였으며, Gemma 3는 기본적으로 멀티모달 기능을 지원하여 텍스트와 이미지 입력을 모두 처리할 수 있다는 아주 강력한 장점이 있는 모델이다.   더 나아가 Gemma 3 모델은 "single-accelerator model"을 기반으로 설계 되었으며, LMAreana 리더보드에서 Chatbot Arena Elo Score 평가에서..