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

같은 저장소 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 리눅스 머신에서 실제로 실행한 것이다.