LLama 3.1 기반의 온프레미스 LLM 서버 구축 (feat. Ollama, Open WebUI)
LLama 3.1 버전이 7월 25일 릴리스되었다.
이전 버전, 다른 모델들과 어떻게 다른지 확인해보고자 로컬 환경에서 LLama 3.1 모델을 받아 간단하게 LLM 서버를 구축해보고 사용해보도록 한다.
Ollama
LLM을 로컬 환경에서 구동할 수 있게하는 프레임워크, Ollama를 통해 모델을 가져와 개인화된 LLM 서버를 배포하고 관리할 수 있다.
LLama 이외에도 Mistral, Gemma 등 여러 오픈소스 LLM도 지원한다. 지원하는 모든 모델 라이브러리는 아래에서 확인할 수 있다.
library
Get up and running with large language models.
ollama.com
또한 GPU Acceleration, GPU와의 연동을 지원해 더욱 빠른 응답을 생성할 수 있다.
Ollama 설치
Ollama는 현재 MacOS, Linux, Windows(프리뷰)를 모두 지원한다. 이번 실습에서는 WSL2 환경에 Ollama를 설치해보도록 한다.
참고로, 이번 실습의 환경은 아래와 같다. GPU를 사용할 것임으로 GPU Driver와 CUDA를 미리 설치하도록 한다.
Host OS : Windows 10
OS : Ubuntu 22.04 (WSL2)
CPU : i5-12600K
MEM : 32GB
GPU : RTX 3080 12GB
Nvidia-Driver : 537.42
CUDA : 12.2
Linux 환경에서는 아래와 같은 Script로 바로 설치할 수 있다.
curl -fsSL https://ollama.com/install.sh | sh
설치 과정은 자동으로 순조롭게 진행된다. 연결된 GPU를 탐지해내며, API 서버도 로컬로 오픈되는 것을 볼 수 있다.
Ollama의 설치가 완료되면, 이어서 사용할 model을 로컬로 다운받아야한다. 가장 작은 버전인 8b를 사용하기로 한다.
(각 model의 파라미터 수 별로 model의 용량이 달라진다.)
ollama run llama3.1
model을 다운받는데에 약 7분 가량 걸리며, 다운받고나면 바로 CLI 상으로 model과 대화할 수 있는 환경이 구성된다.
명령을 CLI로 입력하고, markdown 방식의 응답을 받을 수 있다.
이렇게 정말 간단하게 llama3.1을 CLI상으로나마 이용할 수 있다. 다음으로는 ChatGPT와 유사한 간단한 웹 UI를 바탕으로 llama3.1을 이용해보도록 한다.
Open WebUI
로컬 LLM 서버 API에 쉽게 접근할 수 있는 웹 기반 인터페이스로, Ollama UI를 전신으로 갖는 프로젝트이다.
간단한 설치, 오픈소스 LLM들과의 통합, PWA, 마크다운/LaTeX 지원 등과 같은 다양한 Key feature를 갖는다.
Open WebUI는 npm, pip로의 설치 뿐만 아니라 Docker기반 설치도 지원한다.
앞서 설치한 Ollama와 연동을 위한 WebUI Docker 컨테이너를 구동한다. (컨테이너 구동 방식을 권장)
장착된 GPU를 사용할 것이므로, 아래 커맨드에 사용된 컨테이너 이미지를 사용한다 (tagged with `:cuda`)
docker run -d -p 3000:8080 --gpus all \
--add-host=host.docker.internal:host-gateway \
-v open-webui:/app/backend/data --name open-webui \
--restart always ghcr.io/open-webui/open-webui:cuda
컨테이너 구동 후, 로그인 페이지를 확인하면 성공적으로 설치됨을 알 수 있다.
여기서 사용하는 계정은 외부와 연동되는 것이 아닌 WebUI를 구동한 서버에 저장되는 형식이다.
최초로 생성되는 계정은 Admin 권한을 갖는다.
이러한 Web Auth가 필요하지 않는 경우, 구동 시 WEBUI_AUTH를 false로 지정한다.
(한번 Auth를 켜두면 user가 남아있는 이상 끌 수 없다고 한다.)
채팅 페이지는 기존 ChatGPT와 거의 동일한 UI를 가진 페이지를 만나볼 수 있다.
여러 채팅의 목록을 좌측 사이드바에서 확인할 수 있고, 채팅박스와 메시지를 확인할 수 있는 공간도 chatGPT와 동일한 것을 알 수 있다.
상단의 '모델 선택'에서 앞서 다운받은 모델들 중 하나를 선택할 수 있다.
모델 선택 후 질문 시, 해당 모델이 올라간 Ollama의 API에 질의해 응답을 받아와 WebUI로써 출력해주는 것을 볼 수 있다.
기존 chatGPT 웹 UI와는 달리, 해당 response의 token과 duration time과 같은 정보들을 확인할 수 있다.
답변 비교
번외로 Ollama를 통해 구축한 LLama 3.1 서버를 GPU를 사용한 응답과 GPU를 사용하지 않은 응답(CPU-Only)을 비교해보았다.
모두 동일한 질문을 주었고, response의 생성 정보 수치들을 대상으로 비교를 진행했다.
먼저, GPU를 사용해 response를 생성한 결과이다.
### USER
kubernetes의 auto scaling 용도로 사용되는 KEDA에 대해 설명해주세요. KEDA의 ScaledObject와 TriggerAuthentication의 개념도 예시 manifest파일을 통해 설명해주세요.
### ASSISTANT
Kubernetes Autoscaling(KA)과 다르게, Kubernetes Event-Driven Autoscaling(KEDA)은 event-driven autoscaling를 지원합니다. 즉, 이벤트의 발생에 따라 auto scaling이 가능하다는 뜻입니다.
### KEDA 개념
*Keda*는 event-driven autoscaling을 지원하는 오픈소스 프로젝트로, event source에서 발생한 이벤트에 기반하여 container pool size를 스케일링할 수 있습니다. event source로는 Azure Queue, Event Hub, Kafka, RabbitMQ, Cron Job과 같은 다양한 원천이 가능합니다.
### Keda ScaledObject
KEDA의 core concept은 `ScaledObject`입니다. 이 개념은 event-driven autoscaling을 지원하기 위해 정의하는 resource로, scale target resource가 container pool size를 스케일링하도록 명령합니다. 예시 manifest 파일은 다음과 같습니다.
```yml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: my-scaling-object
spec:
scaleTargetRef:
apiVersion: v1
kind: Deployment
name: my-deployment
minReplicas: 0
maxReplicas: 10
```
위 예시 manifest 파일은 `ScaledObject`를 정의합니다. 이 object는 이름이 "my-scaling-object"인 deployment resource에 대한 스케일링을 명령합니다.
### Keda TriggerAuthentication
event source에서 발생한 이벤트가 keda 스케일러에 전달되기 위해서는 authentication process가 필요합니다. `TriggerAuthentication`은 event source의 credentials를 keda 스케일러에 전달하는 object입니다. 예시 manifest 파일은 다음과 같습니다.
```yml
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
name: my-trigger-authentication
spec:
secretName: my-secret-name
```
위 예시 manifest 파일은 `TriggerAuthentication`을 정의합니다. 이 object는 이름이 "my-trigger-authentication"이고, `secretName` field에 이름이 "my-secret-name"인 secret resource를 참조합니다.
### 결론
Keda는 event-driven autoscaling을 지원하는 오픈소스 프로젝트로, event source에서 발생한 이벤트에 기반하여 container pool size를 스케일링할 수 있습니다. KEDA의 ScaledObject와 TriggerAuthentication 개념은 manifest 파일을 통해 정의되어 이벤트 소스에서 발생한 이벤트가 스케일러에 전달될 수 있도록 합니다.
response의 내용은 prompt로 준대로 KEDA의 개념정의와 ScaledObject, TriggerAuthentication의 개념들을 manifest파일을 예시로 들어 설명을 해준 것을 볼 수 있다. 더불어 prompt에 물어보지 않은 ScalingRule에 대한 내용도 포함이 되어있는것을 볼 수 있다.
다음은 CPU-Only(steamdj/llama3.1-cpu-only)를 통해 response를 생성한 결과이다.
### USER
kubernetes의 auto scaling 용도로 사용되는 KEDA에 대해 설명해주세요. KEDA의 ScaledObject와 TriggerAuthentication의 개념도 예시 manifest파일을 통해 설명해주세요.
### ASSISTANT
**Kubernetes Autoscaling with KEDA**
KEDA (Kubernetes Event-Driven Autoscaling)는 Kubernetes의 Auto Scaling 기능을 확장하는 오픈 소스 플랫폼입니다. KEDA를 사용하면 이벤트 기반 autoscaling, 인메모리 데이터 및 로그 수집, 그리고 다른 리소스의 자동 조정을 수행할 수 있습니다.
**ScaledObject**
KEDA에서 ScaleObject는 리소스가 scale-in/scale-out에 대하여 관리하는 개체입니다. 예시 Manifest 파일은 다음과 같습니다:
```yml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: myscaledobject
spec:
scaleTargetRef:
apiVersion: v1
kind: Deployment
name: mydeployment
pollingInterval: 10
```
이 예시는 ScaleObject가 `mydeployment`라는 이름의 디플로이먼트를 scale-in/scale-out에 대하여 관리한다는 것을 나타냅니다.
**TriggerAuthentication**
KEDA에서 TriggerAuthentication은 ScaleObject가 특정한 트리거를 생성하기 전에 인증을 처리하는 개체입니다. 예시 Manifest 파일은 다음과 같습니다:
```yml
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
name: mytriggerauth
spec:
type: APIKey
apikey:
name: myapikey
```
이 예시는 ScaleObject가 트리거를 생성하기 전에 `myapikey`라는 이름의 API 키 인증을 처리한다는 것을 나타냅니다.
**KEDA의 주요 기능**
- **Event-driven Autoscaling**: KEDA는 특정한 이벤트에 따라 scale-in/scale-out을 수행합니다.
- **In-Memory Data & Logs Collection**: KEDA는 데이터 및 로그를 인메모리에서 수집하고 저장할 수 있습니다.
- **Other Resource Auto-scaling**: KEDA는 다른 리소스의 자동 조정을 지원합니다.
**KEDA의 장점**
- **Flexibility**: KEDA는 다양한 트리거와 ScaleObject에 대하여 확장성이 뛰어납니다.
- **Scalability**: KEDA는 큰 규모의 애플리케이션과 시스템에 적합합니다.
- **Ease of Use**: KEDA를 사용하는 것은 비교적 쉽고 간단합니다.
**KEDA의 한계**
- **Complexity**: KEDA를 사용할 때는 복잡한 설정과 트러블슈팅이 발생할 수 있습니다.
- **Resource Intensive**: KEDA는 시스템 자원에 대한 부담을 증가시킬 수 있습니다.
GPU를 사용한 response의 내용을 비교해보면, 일단 prompt가 동일하기에 그렇게 큰 내용차이는 존재하지 않았다. 아무래도 prompt를 너무 대략적으로만 주었던 것이 전반적으로 답변의 질이 낮아지는데에 기여하지 않았나 싶다.
내용도 내용이거니와 확실한 속도의 차이를 볼 수 있었다. GPU 버전은 CPU 버전에 비해 대략 10배 이상 빠른 response 속도를 보여주었다.
이래서 생성형 AI 파트에 GPU가 그렇게 강조가 되는 이유를 다시 한 번 알게되었다.