LLM 서빙 실습 가이드 — AWS GPU에서 끝까지 돌려보기
해당 포스팅은 현재 재직중인 회사에 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.
실습 저장소: llm-model-inference (검증 커밋
80dcd9f)참고: Hands-On LLM Serving and Optimization (O'Reilly 2026) Ch.3~4
검증 환경: AWS EC2
g5.xlarge/g5.2xlarge(NVIDIA A10G 24GB), us-east-1
이 글은 세 파트로 구성된다. Part 1에서는 Ch.3의 서빙 코드를 GPU 인스턴스에 올려서 단일 모델 서버의 4개 엔드포인트가 각각 어떤 경로로 동작하는지, 배치와 vLLM이 지연에 어떤 차이를 만드는지, 프로세스와 GPU 메모리가 실제로 어떻게 갈라지는지를 따라간다. Part 2에서는 Ch.4의 RAG 에이전트를 돌려 질문 하나에 LLM이 몇 번 호출되는지 계측하고, AWS 관리형 서빙 (Bedrock, JumpStart, DLC)을 차례로 다룬다. Part 3에서는 저장소가 들고 있는 테스트 32개를 전부 실행하고, 트러블슈팅과 리소스 정리로 마무리한다.
이 문서를 관통하는 하나의 질문은 이것이다 — 저장소를 그대로 클론해서 GPU에서 돌리면 어디까지 되는가. Ch.3의 서빙 코드는 두 줄만 고치면 전부 동작하고, 문서가 말한 배치 효과·프로세스 격리·LRU 축출이 실측으로 확인된다. Ch.4의 에이전트도 돌아간다. AWS 관리형 배포 중 JumpStart 경로는 이 계정·시점에서 완료하지 못했는데, 그 지점은 실행 로그에 남은 원인만 짧게 적고 대신 같은 모델을 EC2에 직접 올리는 경로로 마무리했다.
모든 수치·응답·오류 메시지는 실제 실행 로그에서 가져왔다. 추정한 값은 "추정"이라고 따로 적었다.