앞선 두 실습은 서버 한 대에서 프로세스를 직접 띄웠다. 이번에는 Kubernetes 위에 얹는다. KubeRay Operator가 Ray 클러스터를 관리하고, 그 위에서 Ray Serve LLM이 vLLM 엔진을 감싸 OpenAI 호환 엔드포인트를 노출하는 구조를 만든다.

최종 목표는 하나다. kubectl apply 한 번으로 LLM 서빙이 뜨고, 모델을 바꾸려면 매니페스트만 고치면 되는 상태다.

이 글의 모든 명령과 결과는 RTX 3050 6GB 한 장이 달린 리눅스 데스크톱에서 실제로 실행한 것이다. 6GB는 LLM 서빙에 넉넉한 크기가 아니라서, 모델과 설정을 어디까지 줄여야 하는지가 이 실습의 절반을 차지한다.

앞 글에서는 모델 하나를 어떻게 빠르게 굴릴지를 다뤘다. 배칭, 스트리밍, 프로세스 격리가 주제였다. 이번에는 질문이 바뀐다. 모델이 여러 개일 때 무엇을 메모리에 올려두고 어디로 보낼 것인가.

같은 저장소 orca3/llm-model-inference의 ch03/multi_model_serving을 쓴다. 모델 4개를 LRU 캐시로 관리하고, 그중 하나는 NVIDIA Triton 컨테이너에 위임하는 구조다.

이 글의 모든 로그와 명령 결과는 RTX 3050 6GB 리눅스 머신에서 실제로 실행한 것이다.

1. Part 1과 무엇이 다른가

두 랩은 완전히 독립적이다. 그리고 torch 버전이 충돌하므로 venv를 반드시 분리해야 한다.

LLM 서빙은 보통 vLLM이나 TGI 같은 프레임워크를 가져다 쓴다. 하지만 그 안에서 무슨 일이 벌어지는지는 직접 만들어봐야 감이 온다. 이번 실습은 배칭 · 스트리밍 · 프로세스 격리를 손으로 구현한 서버를 띄우고, 로그를 읽어 동작을 확인하는 과정이다.

대상 코드는 책 Hands-On LLM Serving and Optimization의 공식 저장소 orca3/llm-model-inference 중 ch03/single_model_llm_serving이다. 모델은 facebook/opt-125m을 쓴다. 작아서 6GB GPU에서도 충분히 돌아간다.

이 글의 모든 로그와 명령 결과는 RTX 3050 6GB 리눅스 머신에서 실제로 실행한 것이다.

이 글의 구성

1부. 임베딩과 위치 정보 (Token을 벡터로 바꾸기)

LLM은 글자를 직접 다루지 못한다. 오직 숫자(벡터) 만 계산할 수 있다. 그래서 첫 단계는 단어(정확히는 token)를 벡터로 바꾸는 것인데, 이를 embedding(임베딩) 이라 한다. 먼저 GPT-3를 예로 임베딩이 행렬 연산으로 어떻게 이뤄지는지 본다.