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

읽은 자료: Machine Learning Platform Engineering(Manning, 2026) 3장 실습 환경: Rancher Desktop의 k3s(v1.36.2+k3s1, arm64), Docker 29.5.3, Helm v4. 모든 명령과 출력은 2026년 10월 25일 로컬에서 직접 확인했다.

지난 글에서 1~2장을 읽으며 "모델보다 비즈니스 문제가 먼저"이고, 머신러닝의 가치는 폐쇄 루프 안에서 나온다는 개념 뼈대를 정리했다. 3장은 그 이론을 실제로 돌릴 수 있는 토대로 옮긴다. 저자들의 표현대로, 여기서 다루는 Docker·쿠버네티스·CI/CD·모니터링은 머신러닝 전용 기술이 아니라 대규모로 신뢰할 수 있는 머신러닝 시스템을 떠받치는 인프라다.

이 글은 책의 흐름을 따라 하나의 데모 앱을 Docker 이미지로 만들고, 쿠버네티스에 올리고, Helm으로 패키징하고, Argo CD로 GitOps 배포하고, Prometheus·Grafana로 관측하는 과정을 직접 실행한 기록이다. 앱은 요청 수를 세어 /metrics로 노출하는 작은 Go HTTP 서버로, 모니터링 단계에서 이 커스텀 지표가 Prometheus까지 흘러가는 걸 눈으로 확인하려고 골랐다.

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

읽은 자료: Machine Learning Platform Engineering(Manning, 2026) 1~2장

머신러닝 프로젝트에서 모델을 고르는 일은 생각보다 늦게 찾아온다. 책의 1장에서 던지는 첫 질문은 "어떤 모델을 쓸까"가 아니라 "이 문제를 머신러닝으로 풀어야 하는가"이고, 2장은 배포가 끝이 아니라 시작이라고 말한다. 모델은 완성품이 아니라 목적을 위한 수단이며, 그 목적은 한 번의 배포로 달성되지 않는다. 저자들은 "첫 배포가 끝이었던 머신러닝 프로젝트를 본 적이 없다"고 말한다.

1~2장에서는 도구를 거의 사용하지 않는다. 대신 뒤 장들에서 반복될 사고의 기준을 세운다. 문제를 어떻게 정의하는가, 머신러닝 작업을 왜 하나의 루프로 보아야 하는가, 모델과 코드와 데이터의 리니지(lineage, 계보)를 왜 분리해 추적하는가, MLOps는 DevOps와 어디서 갈라지는가, 그리고 조직의 성숙도를 무엇으로 재는가. 그 다섯 가지 축을 따라 정리했다.

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

측정 환경: AWS EC2 g6.12xlarge (NVIDIA L4 24GB × 4, NVLink 없음) · K3s v1.36.4 · vLLM 0.11.0 · Qwen3-0.6B-FP8 × 2 (각 GPU 1장) · vllm-router 0.1.15 · Envoy Gateway v1.9.1 · Agent Router (Envoy AI Gateway) v1.1.0 · GAIE v1.0.1

vLLM 앞에 둘 수 있는 세 구현체를 검토했다. 대상은 vLLM 앞단에 두는 별도 패키지 vllm-router, Envoy 기반 Agent Router(구 Envoy AI Gateway), llm-d였다. 다만 세 구현체를 모두 성능 측정에 넣지는 못했다. Agent Router는 Envoy Gateway와 InferencePool의 호환성 문제로 라우팅 성능을 측정하지 못했고, llm-d는 standalone Envoy 경로에 GAIE EPP를 연결해 approximate 프리픽스 라우팅만 측정했다. 설치와 연동 과정은 8절에 따로 기록했다.

성능 측정에는 K8s Service 대조군을 포함해 다음 다섯 구성을 사용했다.

경로	구성	파드 선택 방식
K8s Service	kube-proxy	연결 단위 분배
vllm-router	round_robin	두 파드에 번갈아 분배
vllm-router	cache_aware 기본 설정	라우터가 추적한 프리픽스 기준
vllm-router	cache_aware + 균형 임계값 4096/100	프리픽스 우선 선택이 부하 균형 판단에 덮이지 않도록 임계값 조정
llm-d standalone Envoy 경로 + GAIE EPP	prefix-cache-scorer	EPP가 추정한 프리픽스 캐시 점수 기준

다섯 구성을 같은 GPU와 모델에 올리고 동일한 부하를 걸었다. 처리량 자체보다 "게이트웨이가 달라지면 어떤 차이를 보이는가"를 확인하려는 시험이었다. 그러나 다섯 구성의 처리량과 지연은 사실상 같았다. 이에 워크로드가 도달할 수 있는 상한을 별도로 측정한 뒤 실제 구성과의 차이를 계산했다.

이 워크로드에서 게이트웨이 계층이 활용할 수 있었던 성능 차이는 캐시 히트율 34.7포인트, 처리량 13.6%, p99 TTFT 56%였다. 성능을 측정한 다섯 구성은 이 차이를 실제 성능으로 바꾸지 못했다.

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

로컬 PC에서 테스트한 내용은 gasida 님이 작성하신 설치 가이드를 참고했습니다.

비교 기준: 로컬 PC(RTX 4070 Ti SUPER, GeForce) 환경의 같은 절차

측정 환경: AWS EC2 g6.2xlarge (NVIDIA L4 24GB, compute capability 8.9) · 순정 Ubuntu 24.04.4 LTS AMI · NVIDIA Driver 595.84 / CUDA 13.2 · Container Toolkit 1.20.0 · K3s v1.36.4 · device-plugin v0.20.0 · DCGM Exporter 4.6.0 · NFD 0.18.3 · HAMi v2.10.0 · vLLM 0.28.0

GPU가 꽂힌 물리 PC에 Ubuntu를 깔고 드라이버부터 쿠버네티스 GPU 분할까지 올리는 방법을 바탕으로 AWS EC2에서 그대로 진행해 보고 로컬 PC 환경과 어떤 부분에 차이가 있는지 비교하고 기록했다.

Deep Learning AMI를 쓰지 않았다. 앞선 실습들은 드라이버가 미리 깔린 DL용 AMI를 썼는데 이번에는 드라이버 설치 과정 자체가 주요 내용이다. DKMS 빌드, .ko.zst 모듈, /dev/nvidia* 장치 노드가 어떻게 생기는지 보려면 순정 이미지에서 시작해야 한다. 그래서 Canonical 순정 Ubuntu 24.04 AMI로 진행했다.

결론부터 말하자면 계획한 항목이 Utilyze 하나만 빼고 전부 통과했고 로컬 PC와 갈린 지점이 몇 가지 확인되었다. kubeadm과 GPU Operator를 전제로 한 후반부(HAMi, DRA)는 K3s에서 수동 스택으로 돌리려면 손을 봐야 했고, 그 과정에서 나온 것들을 정리했다.

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

원본 학습 자료: O'Reilly Hands-On LLM Serving and Optimization (Chi Wang, Peiheng Hu) 9장 · 실습 코드 orca3/llm-model-inference/ch09

측정 환경: AWS EC2 g6e.2xlarge (NVIDIA L40S 46GB, compute capability 8.9) · g6.12xlarge (L4 24GB x4, NVLink 없음, 도전과제) · vLLM 0.28.0 · Qwen3-14B / Qwen3-14B-AWQ

8장까지는 기법을 하나씩 떼어 봤다. 이 장은 그것들을 한 모델에 순서대로 얹어 보는 자리다. 목표는 단일 인스턴스의 토큰 처리량을 최대로 끌어올리는 것이고 순서는 하드웨어 확인 → 트래픽 설계 → 지표 정의 → 기준선 측정 → 양자화 → 추가 튜닝이다.

측정하면서 자료와 어긋난 지점이 두 곳 나왔다. 양자화는 자료가 예상한 것보다 ITL을 훨씬 크게 개선했고 반대로 자료가 권한 fine-tuned 설정은 성능을 떨어뜨렸다. 두 지점의 원인은 같았다.

마지막에 자료가 인용만 하고 직접 재지 않은 질문 하나를 따로 측정했다. GPU 두 장이 있을 때 TP로 쪼개는 것과 독립 인스턴스 두 대로 나누는 것 중 무엇이 나은가.