juyeon22 님의 블로그

Hands-On LLM Serving and Optimization Study: Speculative Decoding, 병렬화, PD 분리 정리Hands-On LLM Serving and Optimization 스터디 정리입니다. 책 7장 Advanced LLM Optimization Techniques를 따라 그 위에 얹는 고급 최적화 세 가지를 다룹니다. Speculative Decoding, 멀티 GPU/멀티 노드 병렬화(TP, PP, EP, DP), 그리고 Prefill-Decode 분리입니다.이 글의 목표는 세 기법이 각각 어떤 병목을 겨냥하는지, 무엇을 내주고 무엇을 얻는지 이해하고, 그래서 내 워크로드와 하드웨어에서 무엇을 켜고 무엇을 켜지 말아야 할지 스스로 판단할 수 있게 되는 것입니다...

Hands-On LLM Serving and Optimization Study 3주차 Challenges When Serving LLMsHands-On LLM Serving and Optimization 스터디 4주차 정리입니다. 지난 주차까지가 서빙 시스템을 "어떻게 구성하는가"의 이야기였다면, 이번 주는 그 시스템이 "왜, 어디서 느려지는가"의 이야기입니다. 책 5장(Challenges When Serving LLMs)을 따라가며 최적화가 왜 사업의 문제인지, GPU 스펙을 어떻게 읽어야 하는지, 그리고 모델 로딩과 실행 각각에서 병목이 어디에 생기는지를 정리했습니다.결론을 미리 말하면 이렇습니다. LLM 서빙 최적화는 "무조건 더 빠르게"가 아니라 지연 시간, 처리량, 모델 품질(크기) 사이의 트레..

Hands-On LLM Serving and Optimization Study 2주차 Model Serving System DesignHands-On LLM Serving and Optimization 스터디 2주차 정리입니다. 이번 주는 AI 모델을 실제 서비스로 만드는 이야기입니다. 책 3장(Model Serving System Design: A Deep Dive)의 설계를 따라가며, 서빙 시스템을 구성하는 원리를 중심으로 정리했습니다.1. 배경: 프레임워크를 고르기 전에 알아야 하는 것이런 상황을 가정해 봅시다. 사내에 LLM 기반 기능을 올리기로 했고, 서빙 프레임워크를 골라야 합니다. vLLM, Triton, TGI — 선택지는 많고 각자 내세우는 벤치마크 수치도 제각각입니다. 어느 것을 골라야..

Hands-On LLM Serving and Optimization Study 스터디 1주차 — GPT-2(small)로 뜯어보는 Transformer 내부 구조개요이 게시물은 가시다님의 Hands-On LLM Serving and Optimization Study 1주차 추가내용으로, GPT-2(small) 모델이 텍스트를 입력받아 다음 단어를 예측하기까지의 전체 과정을 단계별로 정리한 게시글입니다. Transformer Explainer는 GPT-2(small) 모델이 브라우저 안에서 실제로 실행되는 인터랙티브 시각화 도구이기 때문에, 글을 읽으면서 사이트를 함께 열어 두고 각 단계를 직접 눌러보는 것을 권장합니다.행렬 곱셈이 무엇인지 정도만 알고 있으면 따라올 수 있도록 수식보다는 "각 단계가 왜 ..

Nokia SR Linux 텔레메트리 랩(srl-telemetry-lab) Deep Dive — SNMP 폴링 vs gNMI 스트리밍 감지 지연 실측개요이 게시물은 Nokia SR Linux 기반의 srl-telemetry-lab을 WSL2 환경에서 배포하고, SNMP 폴링과 gNMI 스트리밍 텔레메트리의 감지 지연 차이를 실측한 내용을 정리한 게시글입니다.쿠버네티스 클러스터는 node_exporter를 15초마다 스크레이프하면서, 그 클러스터가 올라가 있는 네트워크 스위치는 여전히 5분 주기 SNMP로 모니터링하는 환경이 많습니다. 이 글에서는 그 간극이 실제로 무엇을 놓치는지 컨테이너 랩에서 직접 측정합니다. Windows PC의 WSL2만으로 Nokia SR Linux 5대짜리 Clos 패브릭과 g..

AI Datacenter Network Study 3주차 — RDMA Write Deep Dive + Congestion Control(ECN·PFC·DCQCN), Load Balancing, AI Fabric TopologyAI Datacenter Network 스터디 3주차 정리입니다. 2주차가 "무손실 이더넷을 PFC·ECN·DCQCN으로 만든다"는 개념과 ROD·RUD 토폴로지에서 끝났다면, 이번 주는 그 아래로 내려갑니다. RDMA Write 한 번이 성립하기까지의 실제 절차, 임계값 네 개의 순서가 fabric의 성패를 가르는 이유, elephant flow를 나누는 세 가지 방법, 그리고 rail을 물리 스위치에 담는 방식까지 다룹니다.1. 개요이 글은 AI Datacenter Network..

AI Datacenter Network Study 2주차 IB, RoCEv2 + GPU Cluster Network Design, ROD/RUDAI Datacenter Network 스터디 2주차 정리입니다. 1주차가 GPU 간 통신을 RDMA와 InfiniBand·RoCEv2로 처리한다는 데서 끝났다면, 이번에는 그 두 전송 기술을 한 겹 더 파고들고, 수천 장의 GPU를 실제로 어떻게 배선하는지까지 내려가 봅니다.1. 개요이 글은 AI Datacenter Network 스터디 2주차 발표 내용을 바탕으로, GPU 클러스터의 전송 기술과 네트워크 설계를 정리한 기록입니다.1주차의 흐름을 짧게 되짚어 보겠습니다. "GPU가 빠른데 왜 AI는 느리고 비싼가"라는 질문에서 출발해, 병목이 연산이 아니라 메모..

AI Datacenter Network 스터디 1주차AI Datacenter Network 스터디 1주차 정리입니다. GPU가 빠른데도 왜 AI는 느리고 비싼가라는 질문(메모리 병목)에서 출발하여, 수천 장의 GPU를 묶는 전송 기술(RDMA·InfiniBand·RoCEv2)까지 다룹니다.1. 개요이 글은 AI Datacenter Network 스터디 1주차 의 강의 내용을 바탕으로, GPU와 AI 인프라의 병목, 그리고 그 병목을 해소하는 네트워크 전송 기술까지 정리한 기록입니다.필자는 DevOps 엔지니어입니다. Linux, 네트워크, 쿠버네티스, 클라우드 업무를 거쳐 MLOps를 맡게 되었으나, 필자는 GPU도 딥러닝도 익숙하지 않은 영역이었습니다. 그래서 접근 방식을 바꾸었습니다. AI를 처음부터..

AWS EKS Study(AEWS) 4기 9주차 Amazon EKS AutoMode와 GPU/AI 워크로드1. 개요이 게시물은 9주차 정용준님이 진행하신 Amazon EKS AutoMode와 GPU/AI 워크로드의 내용과 GKE Autopilot의 비교를 기록한 게시글입니다.2. 두 서비스가 등장한 배경과 Managed K8s 진화 흐름Managed Kubernetes의 진화는 Data Plane을 얼마나 추상화할 것인가의 문제였습니다. 초기 EKS와 GKE는 Control Plane만 관리했고, Cluster Autoscaler 시대를 거쳐 Karpenter가 인스턴스 다양성과 동적 프로비저닝의 표준이 되었습니다. 다음 단계는 Data Plane 전체를 사용자 시야에서 지우는 것이었는데, 두 회사가 ..

AWS EKS Study(AEWS) 4기 7주차 Amazon EKS Upgrade개요이 게시물은 7주차 김성한님이 진행하시는 Amazon EKS Upgrade WorkShop의 내용을 기록한 게시글입니다.1. 실습 전 짚어둘 EKS 업그레이드 포인트EKS 업그레이드의 전반적인 배경(공동 책임 모델, 26개월 지원 정책, 버전 스큐 정책 등)은 AWS 공식 모범 사례 가이드에 자세히 정리되어 있습니다. 이 글에서는 그 내용을 반복하기보다, 실습/실무에서 의사결정에 직접 영향을 주는 포인트 위주로 정리해보려 합니다.1.1 공동 책임 모델 — "AWS가 관리한다 ≠ AWS가 알아서 한다"EKS의 공동 책임 모델은 다이어그램으로 자주 나오는데, 업그레이드 관점에서 실제로 헷갈리는 지점은 다음 한 줄입니다.이 ..