해당 포스팅은 현재 재직중인 회사에 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.

원본 학습 자료: O'Reilly Hands-On LLM Serving and Optimization (Chi Wang, Peiheng Hu) 7-8장

측정 환경: AWS EC2 g6.xlarge (NVIDIA L4 24GB, compute capability 8.9) · g5.12xlarge (A10G 24GB x4, NVLink 없음) · g6.12xlarge (L4 24GB x4, NVLink 없음, 5절 재현) · Qwen2.5-7B-Instruct 타깃 + Qwen2.5-0.5B-Instruct 드래프트

양자화까지 적용하고 나면 단일 GPU에서 짜낼 수 있는 것은 대체로 다 짜낸 상태가 된다. 그다음에 남는 선택지가 이 글에서 다루는 네 가지다. 작은 모델로 토큰을 미리 찍어보는 추측 디코딩, 모델을 여러 GPU에 쪼개는 병렬화, 입력 처리와 출력 생성을 물리적으로 분리하는 PD 분리, 그리고 KV 캐시를 GPU 밖까지 계층으로 관리하는 방법이다. 마지막으로 이 기법들을 실제로 구현해 주는 서빙 프레임워크를 비교한다.

네 기법의 성격이 꽤 다르다. 추측 디코딩과 KV 캐싱은 GPU 한 장에서도 효과를 볼 수 있고 병렬화와 PD 분리는 애초에 GPU가 여러 장 있어야 성립한다. 측정한 것과 개념 정리에서 멈춘 것을 절마다 표시해 두었다.

한 가지만 미리 적어둔다. 추측 디코딩은 흔히 "지연을 2~3배 줄인다"고 소개되는데 이 숫자에는 동시성이 낮을 때라는 조건이 빠져 있다. GPU가 한가할 때 남는 연산으로 미리 토큰을 찍어보는 기법이라서 GPU가 이미 배치로 꽉 차 있으면 이득이 사라지고 오히려 손해가 될 수 있다.

해당 포스팅은 현재 재직중인 회사에 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.

원본 실습: O'Reilly Hands-On LLM Serving and Optimization (Chi Wang, Peiheng Hu) ch06/quantization_3way_300.ipynb

검증 환경: AWS EC2 g6e.xlarge (NVIDIA L40S 48GB, compute capability 8.9) · vLLM 0.8.5.post1 · transformers 4.51.3 · CUDA 12.4 · Qwen2.5-7B-Instruct

양자화 설명은 보통 "가중치 정밀도를 낮추면 메모리가 줄고 속도가 빨라진다"에서 멈춘다. 틀린 말은 아닌데, 막상 서비스에 넣을지 결정하려고 하면 이 문장만으로는 아무것도 고를 수 없다. 얼마나 빨라지는지, 어떤 상황에서 빨라지는지, 그 대가로 무엇을 내주는지까지 알아야 판단이 선다.

그래서 Qwen2.5-7B 한 모델을 세 가지 정밀도로 준비해 같은 GPU에 번갈아 올리고, 동시성을 1에서 300까지 올려가며 직접 재봤다. 비교 대상은 BF16 원본, FP8-dynamic(W8A8), GPTQ-Int4(W4A16) 세 가지다.

결론부터 적으면, 모든 지표를 다 가져가는 변형은 없었다. 처리량은 GPTQ-Int4가 전 구간에서 1위였지만, 동시성이 높을 때의 지연과 원본 대비 출력 충실도는 둘 다 FP8이 가장 좋았다. 함정도 하나 있는데, 인스턴스 타입을 잘못 고르면 FP8이 에러 하나 없이 W8A16으로 격하돼서 비교 자체가 무의미해진다.

해당 포스팅은 현재 재직중인 회사에 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.

실습 저장소: 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에 직접 올리는 경로로 마무리했다.

모든 수치·응답·오류 메시지는 실제 실행 로그에서 가져왔다. 추정한 값은 "추정"이라고 따로 적었다.

해당 포스팅은 현재 재직중인 회사에 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.

인터랙티브 실습: Transformer Explainer (Georgia Tech)

참고: Hands-On LLM Serving and Optimization (O'Reilly 2026)

GPT-2 (small, 124M params) 기준

이 글은 두 파트로 구성된다. Part 1에서는 GPT-2를 기준으로 Transformer의 동작 원리를 하나의 예시 문장("The cat sat on the")이 입력부터 다음 단어 예측까지 거치는 전체 경로를 따라가며 설명한다. Embedding, Self-Attention, MLP, Output 각 단계에서 데이터가 어떤 형태로 변환되는지를 코드와 함께 추적한다. Part 2에서는 학습된 모델을 실제로 서빙할 때의 문제 — Auto-Regressive 생성의 비효율, KV Cache 메모리 관리, Prefill/Decode 병목 — 를 다루고, Continuous Batching, PagedAttention, Quantization, Speculative Decoding 등 주요 최적화 기법과 vLLM/TensorRT-LLM 같은 서빙 프레임워크를 정리한다.

해당 포스팅은 현재 재직중인 회사에 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.

시리즈의 마지막 편이다. 지금까지 분산 학습의 내용들을 정리해봤다.

• 1편·2편: 네트워크(EFA)로 노드 간 통신을 빠르게
• 3편: 스토리지(FSx/EFS/S3)로 데이터·체크포인트 공급
• 4편: 관측으로 병목 찾기

그런데 마지막 질문이 남는다.

"이 많은 노드를 어떻게 하나의 학습 잡으로 묶어서 돌리지?"

노드 수십 대에 일일이 SSH로 들어가 EFA를 켜고 FSx를 마운트하고 mpirun을 칠 수는 없다. 프로비저닝·스케줄링·장애 복구를 대신 해주는 오케스트레이션 계층이 필요하다. 이 글에서는 AWS의 세 가지 방식을 비교한다.