[책스터디] 8. sLLM 서빙하기

📍 성능을 떨어뜨리지 않으며 모델을 효율적으로 추론하는 방식

1. 배치 전략 
- 연속배치 

2. 어텐션 연산 효율화 : 플래시어텐션, 페이지어텐션
- 플래시어텐션 : GPU 메모리에 데이터를 읽고쓰는 작업(IO)을 줄여 어텐션 연산의 메모리 사용량을 줄이고 속도를 높임 

3. 추론 전략 : 커널퓨전, 추측인코딩 

 

 

 

 

1.   효율적인 배치전략 

---

 

❏  딥러닝 모델에서 입력 데이터를 추론할 때, 가능한 한 번에 많은 데이터를 받아 처리량을 높이는 것이 GPU를 효율적으로 활용하는 방법 → BUT 언어모델은 한 번에 하나씩의 토큰을 생성하므로 배치 전략에서 고려할 사항이 많음

 

 

1.1   일반배치

 

❍  일반배치(정적배치)

 ↪︎  입력 데이터를 배치처리할 때 한 번에 N개의 입력을 받아 모두 추론이 끝날 때까지 기다리는 방식

 

 

↪︎  가령 배치크기가 4인 위의 경우에서, 세번째 입력처럼 생성이 일찍 종료되는 문장이 있는 경우, 다른 데이터의 추론이 끝날 때까지 대기해야 하며, 먼저 종료되는 문장들이 발생하는 경우 결과적으로 배치 크기가 작아지는 형태가 되어 (e.g. 처음에는 4개 문장에 대해 추론을 수행했으나, 먼저 종료되는 문장들 때문에 마지막에는 1개 문장에 대해서만 추론을 수행하게됨) GPU를 비효율적으로 사용하게 된다. 

 

 

1.2   동적배치

 

❍  동적배치

 ↪︎  비슷한 시간대에 들어오는 요청을 하나의 배치로 묶어 배치 크기를 키우는 전략 

 

 

↪︎  No Dynamic : 요청이 들어올 때마다 추론을 수행해, 지연시간은 짧을 수 있겠으나 GPU를 효율적으로 사용하지는 못함

↪︎  Dynamic : 온라인 서빙에서 배치크기를 키워 처리량을 높일 수 있다. 그러나 생성하는 토큰길이 차이로 인해 처리하는 배치크기가 점차 줄어 GPU를 비효율적으로 사용하게 되는 문제는 여전히 남아있다. 

 

 

1.3  연속배치

 

❍  연속배치

 ↪︎  하나의 토큰 생성이 끝날 대마다 생성이 종료된 문장은 제거하고 새로운 문장을 추가하는 방식 

 

 

 ↪︎  생성이 종료된 첫번째, 세번째, 네번째 문장에서 바로 다음에 다섯번째, 여섯번째, 일곱번째 (S5,S6,S7) 문장을 추가한 것을 확인할 수 있다. 이러면 대기시간이 길어지는 문제 + GPU비효율사용 문제를 해결할 수 있다. 

 ↪︎  새로운 데이터를 배치에 추가할 때, 사전연산과 디코딩 처리 방식이 달라서, 처리중인 문장과 대기중인 문장 비율을 보고 특정 조건을 달성했을 때 추가하는 방식을 사용하기도 한다 (waiting_served_ratio) 

 

 

 

 

 

2.   효율적인 트랜스포머 연산

---

 

2.1   플래시어텐션

 

❍  셀프어텐션

 ↪︎  트랜스포머 연산은 쿼리와 키 벡터를 곱하는 과정에서 많은 메모리를 사용 

 

Attention부터 Dropout까지 행렬 크기가, 쿼리Q/키K/값V/출력O행렬에 비해 훨씬 큼

 

 

 ↪︎   Pytorch의 연산 시간을 각 단계마다 계산해보면, 많은 연산량이 필요한 Matrix 곱셈 연산에 드는 시간보다, 이후에 Mask, Softmax, Dropout 처리시간이 더 많이 소요되는데, 이는 어텐션행렬을 뒷단계에서 계속 물고 있으며 발생하는 GPU에서 메모리를 읽고 쓰는 데 오랜 시간이 걸리기 때문이다. 

 

GPU의 구조

 

 ↪︎  GPU의 구조 

       -  SRAM : 메모리 크기가 작지만, 데이터를 빠르게 이동시킬 수 있음 

       -  HBM(고대역폭메모리) : 메모리 크기는 크지만 데이터 이동속도가 느림 

       -  어텐션 행렬은 크기가 크므로 메모리 크기가 큰 HBM에서 이루어짐 (따라서 연산 시간은 오래 걸림)

 

 

 

❍  플래시어텐션

 ↪︎  트랜스포머가 더 긴 시퀀스를 처리하도록 만들기 위해 개발됨, Train 과정에서 필요한 메모리를 시퀀스 길이에 비례하도록 개선 (원래 트랜스포머 아키텍처에서는 Train에는 길이의 제곱에 비례하고 Inference에서는 길이에 비례함)

 

 

 ↪︎  플래시어텐션에서는 HBM에서 큰 어텐션 행렬을 쓰고 읽으며 걸리는 연산을 줄이기 위해 "블록" 단위로 어텐션 연산을 수행하고 전체 어텐션 행렬을 쓰거나 읽지 않는 방식으로 어텐션 연산의 속도를 높임 

 ↪︎  또한 작은 블록 단위로 연산을 수행하므로 SRAM에 올려 더 빠르게 연산을 수행한다. 

 ↪︎  다만, NxN크기의 행렬이 아니라 Nxd의 행렬을 저장하며 어텐션 연산을 진행하는데 때문에 역전파 계산 과정에서는 NxN 행렬 값이 필요해, 역전파 과정에서 다시 순전파를 계산하는 방식으로 해결한다. 

 

 

❍  플래시어텐션2

 ↪︎  속도를 한단계 더 높인 버전 : 행렬 곱셈이 아닌 연산을 줄이기, 시퀀스 길이 방향의 병렬화를 추가 

 

 

 

2.2   상대적위치인코딩

 

❍  절대적위치인코딩

 ↪︎  셀프어텐션 연산에서는 입력 토큰의 위치에 관계없이 모두 동등하게 처리하기 때문에, 위치정보를 별도로 추가해야 했다. 최초의 트랜스포머 아키텍처에서는 토큰의 위치에 따라 사인과 코사인 수식으로 정해진 값을 더해줬다. 

 ↪︎  그러나 이러한 방식은 학습 데이터보다 더 긴 입력이 들어오면 언어모델의 생성 품질이 빠르게 떨어진다는 한계 존재 

 

 

❍  상대적위치인코딩

 ↪︎  토큰의 상대적인 위치 정보를 추가하는 방식, 학습 데이터보다 더 긴 입력이 들어왔을 때의 성능 저하 문제를 해결

 

 ↪︎  1) RoPE : 각 토큰 임베딩을 토큰 위치에 따라 회전하는 방식으로, 토큰 사이의 위치정보가 두 임베딩 사이의 각도를 통해 모델에 반영된다.  

 

 

 

 ↪︎  2) ALiBi : 쿼리와 키 벡터를 곱한 어텐션 행렬에 오른쪽에서 왼쪽으로 갈수록 작은 값을 더하는 방식으로, 현재 쿼리 위치를 의미하는 0을 기준으로 앞쪽에 있을수록 더 작은 값을 더해 상대적 위치를 반영 

 

 

 ↪︎  RoPE는 회전하는 처리가 추가되어, ALiBi보다 학습 및 추론 속도가 느리다. 상대적위치인코딩 방식은 절대적위치인코딩 방식보다, 더 긴 입력 데이터에 대해 성능을 거의 유지한다. 

 

 

 

 

3.   효율적인 추론전략 

---

 

3.1   커널퓨전

 

❍  커널퓨전

 ↪︎  GPU에서 반복적으로 수행하는 연산을 하나로 묶어 더 효율적으로 처리하는 방식 

 ↪︎  GPU에서 연산은 '커널' 단위로 이루어지게 되는데, 연산을 수행하기 전후로 오버헤드(e.g. HBM에서 데이터를 읽어오거나 결과를 쓰는 작업 등)가 발생한다. 커널이 여러개가 수행되면 앞뒤로 오버헤드가 그만큼 발생해서 수행 시간이 길어지는데, 따라서 반복적으로 수행되는 연산에 대해서는 연산을 하나로 묶어 오버헤드를 줄이는 커널퓨전 방식이 등장했다. 

 

 

 

 

3.2   페이지어텐션

 

❍  KV캐시연산

 ↪︎ [복습] KV캐시 : 어텐션 연산 과정에서 키와 값 벡터를 중복해 계산하므로, 이 두 벡터 결과를 저장했다가 불러오는 방식 

 

 

 ↪︎  캐시연산은 중복 연산을 줄여서 전체적인 연산 시간을 줄이는데는 도움이 되지만, 많은 GPU메모리를 사용한다. 가령 위에서 노란색영역이 요청A라고 할 때, KV캐시는 몇 개의 토큰을 생성할지 알지 못하기 때문에 <resv>처럼 최대 생성 토큰 수 (2048개) 만큼 미리 메모리를 예약해둔다. 그러나 이미 생성할 토큰 + 앞으로 생성할 토큰을 제외한 2038개의 메모리는 결국 사용되지 않고 자리만 차지하는 비효율이 발생하게 된다. 

 ↪︎  즉, 연속적인 물리 메모리를 사용하기 위해 미리 메모리를 준비하는 데에서 메모리 낭비가 발생하는 것이다. 

 

 

 

❍  페이지어텐션

 ↪︎ 메모리를 효율적으로 관리하기 위해 '가상메모리' 같은 개념이 개발되었는데, 이는 프로그램이 실제 물리적 메모리 주소를 통해 메모리에 접근하지 않고, 운영체제가 관리하는 논리적 메모리 주소를 사용하는 방식이다. 

 

 ↪︎  페이지어텐션에서는 가상메모리 개념을 빌려와, 논리적메모리와 물리적메모리를 연결하는 블록테이블을 관리해, 물리적으로 연속된 메모리를 사용하지 않으면서도 논리적메모리에서는 서로 연속적으로 동작하도록 만드는 방식을 사용한다. 

 

한 번에 큰 메모리를 예약하지 않고 블록크기만큼의 메모리를 물리적으로 배정이 가능

 

 

 

 

3.3  추측인코딩

 

❍  추측인코딩

 ↪︎  쉬운 단어는 더 작고 효율적인 모델이 예측하고, 어려운 단어는 더 크고 성능이 좋은 모델이 예측하도록 하는 방식 

 

 

 ↪︎  어떤 단어가 예측하기 쉽고 어떤 단어가 예측하기 어려울지는 어떻게 판단하는가 ➱ 드래프트모델과 타깃모델이라는 2개의 모델을 활용해 추론을 수행 

 ↪︎  작은 Draft model이 K개의 토큰을 빠르게 먼저 생성하면, Target model이, Draft model이 생성한 토큰이 Target model이 추론했다면 생성했을 결과와 동일한지 계산해, 동일하다면 승인 아니면 거절하는 방식을 활용한다. 

 ↪︎  추측인코딩은 원본모델에 비해 훨씬 작은 드래프트 모델의 추가만으로 원본 모델의 성능을 그대로 유지하며, 속도를 2배이상 높일 수 있다는 점 때문에 다양한 서빙 프레임워크에서 채택함 

 

 

 

4.   LLM의 Inference

---

 

 

❍  vLLM 

 ↪︎  LLM을 빠르고 효율적으로 서빙하기 위한 라이브러리로 허깅페이스 유명 모델을 중심으로 지원 

 

❍  오프라인서빙

 ↪︎  대용량의 입력 데이터에 대해 추론을 수행하여 충분히 큰 배치크기를 활용할 수 있는 추론

import torch
from vllm import LLM, SamplingParams

model_id = "shangrilar/yi-ko-6b-text2sql"
llm = LLM(model=model_id, dtype=torch.float16, max_model_len=1024)

 

 

❍  온라인서빙 

 ↪︎  사용자의 요청에 따라 모델을 추론하는 방식

# 온라인 서빙을 위한 vLLM API 서버 실행

!python -m vllm.entrypoints.openai.api_server \
--model shangrilar/yi-ko-6b-text2sql --host 127.0.0.1 --port 8888 --max-model-len 1024



# OpenAI 클라이언트를 사용한 API 요청
from openai import OpenAI

openai_api_key = "EMPTY" # 로컬에서 실행 중인 vLLM 서버에 요청을 보내기 때문에 EMPTY
openai_api_base = "http://localhost:8888/v1"
client = OpenAI(
    api_key=openai_api_key,
    base_url=openai_api_base,
)
completion = client.completions.create(model="shangrilar/yi-ko-6b-text2sql",
                                 prompt=dataset.loc[0, 'prompt'], max_tokens=128)
print("생성 결과:", completion.choices[0].text)