LLM 서빙과 추론 최적화
1.LLM 서빙을 위한 GPU 이해하기 (스펙 읽기부터 병목 분석까지)
한 줄 요약TFLOPS 높은 GPU = 좋은 LLM GPU는 틀렸다.LLM 서빙 성능은 연산(Compute) · 메모리(용량/대역폭) · 인터커넥트의 균형으로 결정되고,실제로 대부분의 구간은 연산이 아니라 메모리 대역폭에 막힌다.TTFT와 응답 지연이 커질수록 만족도가
2.CH3. Model Serving System — 정리
Hands-On LLM Serving and Optimization 3장 학습 정리세 줄 요약1\. 위쪽 4개(API server, LLM engine, Workload manager, Model executor)는 CPU 일만 한다.2\. 아래 2개(Model wor
3.CH4. 프로덕션 LLM 서빙 - 정리
세 줄 요약1\. 2~3장은 "모델을 어떻게 실행하는가"였고, 4장은 "실제 서비스를 어떻게 운영하는가"다.2\. 결정적 전환점은 모델이 요청당 한 번이 아니라 제어 루프 안에서 반복 호출된다는 것.3\. 그 순간 서빙은 추론 문제가 아니라 시스템 아키텍처 문제가 된다
4.LLM 서빙 최적화 (배칭, 어텐션 커널, 모델 압축)
5장이 "GPU를 어떻게 읽을 것인가"였다면, 6장은 "그래서 뭘 해야 하는가"다.모든 기법의 출발점은 5장의 결론 하나로 수렴한다 Prefill은 compute-bound, Decode는 항상 memory bandwidth-bound.이 장의 거의 모든 최적화는 "d
5.LLM 추론 배칭 전략 정리 (Static, Dynamic, Continuous Batching)
LLM 서빙 엔진을 고르거나 파라미터를 조정할 때 가장 먼저 마주치는 개념이 배칭이다. vLLM은 continuous batching, Triton은 dynamic batching이라는 식으로 언급되지만 두 용어는 같은 층위에서 대립하는 개념이 아니다.이 글은 세 가지
6.LLM 서빙에서 KV 캐시는 어떻게 관리되는가 PagedAttention
앞 글에서 continuous batching을 정리하면서, 매 스텝 시퀀스가 교체되려면 KV 캐시를 자유롭게 할당·해제할 수 있어야 한다는 조건을 언급했다. 그 조건을 만족시키는 것이 PagedAttention이다.이 글은 KV 캐시가 왜 병목이 되는지, 기존 방식이
7.GPU 메모리와 커널로 보는 추론 최적화 다섯 가지
앞선 글에서 continuous batching과 PagedAttention을 정리하며 decode 단계가 memory-bound라는 이야기를 반복했다. 이 글은 그 진단에서 출발해, 실제로 손댈 수 있는 지점이 어디인지를 정리한다.결론부터 말하면 방법은 다섯 가지뿐이
8.Speculative Decoding 벤치마크
vLLM 0.28.0에서 speculative decoding 4개 구성을 비교 측정한 결과.eagle3를 쓰세요. concurrency 1에서 2.11배, 16에서 1.83배.n-gram은 주어진 설정(6 / 4–6)으로는 concurrency 16에서 오히려 0.9
9.LLM 서빙의 KV 캐시 메모리 관리 — PagedAttention에서 llm-d까지 (2026년 9월 기준)
LLM 추론은 이미 계산한 key/value 텐서를 다시 계산하지 않기 위해 KV 캐시에 쌓아둡니다. 이 캐시는시퀀스 길이에 비례해 계속 커지고,요청이 언제 끝날지 미리 알 수 없고,GPU HBM이라는 가장 비싼 자원을 점유합니다.논문 시점의 서빙 시스템(Orca, F