대규모 LLM 추론 심층 분석: 메모리·지연시간·서빙 최적화

URL: https://www.youtube.com/watch?v=y2W4FNAuPEA
날짜: 2026-09-09
채널: aiDotEngineer
발표: Harshul Jain(Audible 시니어 소프트웨어 엔지니어), Tanmay Sah(시니어 퀀트 모델러·AI 연구자)

📌 핵심 질문 / 이 워크숍이 다루는 핵심 논점

==대규모 LLM 추론의 비용과 지연시간은 모델 자체와 서빙 시스템을 함께 최적화하고, 품질·지연시간·처리량 사이의 명시적인 트레이드오프를 설계할 때 낮출 수 있다.==

• 추론은 모델 학습처럼 한 번 지불하는 비용이 아니라 사용자·토큰·세션마다 반복되는 운영비다.
• 컨텍스트가 길어질수록 KV cache가 커지고, prefill은 TTFT(Time to First Token)를 늘리며, decode는 메모리 대역폭에 묶인다.
• 양자화(quantization), attention 구조 변경, KV cache 최적화, continuous batching, 적합한 serving engine을 조합해야 한다.

LLM 추론의 병목은 하나가 아니다. 고정된 GPU 메모리 안에 모델 가중치와 KV cache를 함께 배치해야 하고, 긴 입력의 첫 토큰을 빨리 내보내면서도 생성 토큰 사이의 지연시간을 낮춰야 하며, 여러 사용자를 동시에 처리해야 한다. premium chat은 품질과 지연시간을, 비동기 agent workload는 품질과 처리량을 우선하므로 동일한 모델과 GPU에도 서로 다른 최적점이 생긴다.

1. 워크숍의 범위와 추론 비용의 문제

1.1. 대상과 진행 순서

1. 입문자와 중급자를 위한 첫 원리 접근

   1. LLM 추론을 처음 접한 사람부터 모델을 운영 환경에 배포하고 튜닝해 본 사람까지를 대상으로 한다.
   2. 워크숍 자료와 실습은 저장소의 workshop 폴더와 README에 제공하며, 슬라이드·PPTX·벤치마크 리포트·Jupyter notebook 링크를 함께 제공한다.
   3. Audible에서 약 5년간 ML/AI 데이터 플랫폼을 만든 Harshul Jain은 LLM inference 오픈소스 핸드북을 작성하고 있다.
   4. Tanmay Sah는 양적 모델러이자 AI 연구자로서 agent verifier와 world model을 연구하며, 복잡한 문제를 단계적으로 쪼개 설명하는 역할을 맡는다.

2. 학습 순서

   1. 먼저 추론의 문제 상황과 메모리·TTFT·처리량 병목을 확인한다.
   2. 이어 병목이 생기는 원인을 inference pipeline과 GPU 메모리 구조에서부터 파악한다.
   3. 모델 최적화와 serving 최적화를 분리해 살펴본다.
   4. vLLM, SGLang, TensorRT-LLM 등 serving engine을 비교하고, 사용 사례별 선택 기준과 벤치마크를 적용한다.

1.2. 추론이 반복 운영비가 되는 이유

1. LLM 추론의 적용 범위

   1. 영상·오디오 생성, 텍스트 분석, 의료 보고서 분석, 세금 고지서 분석 등 AI에게 요청하는 모든 생성·분석 작업이 LLM inference에 해당한다.
   2. 추론 시장 규모는 약 230억 달러다.

2. 검색 서비스가 마주하는 비용 압력

   1. SemiAnalysis의 사례에 따르면 Google 검색 질의를 LLM으로 모델링하려면 약 360억 달러 규모의 손익 부담이 발생할 수 있다.
   2. 검색 사업의 수익성을 유지하려면 질의당 비용을 0.5센트보다 낮춰야 한다.
   3. Business Insider가 말한 “AI를 다이어트시켜야 한다”는 표현은 토큰 사용량을 감사하고 예산화해야 한다는 뜻이다.

3. 학습 비용과 추론 비용의 차이

   1. GPT-3 학습비로 언급된 약 460만 달러는 한 번 지불하는 비용이다.
   2. 추론비는 사용자가 늘고, 입력 토큰과 출력 토큰이 늘고, 세션이 새로 열릴 때마다 반복되는 운영비다.
   3. 대응 방법은 토큰 사용량을 줄이거나, inference service provider로서 모델·GPU·서빙 경로를 최적화하는 두 방향이다.
   4. 새로운 최적화 기법과 엔진이 계속 등장하므로 제품 이름을 외우기보다 병목의 원인과 기본 계산을 이해해야 다음 기술을 평가할 수 있다.

2. 기본 실험에서 드러나는 세 가지 병목

2.1. 실습 환경과 모델 메모리

1. 재현 가능한 실험 환경

   1. 실습 저장소는 Google Colab의 대안인 Moab과 협력해 무료 RTX 6000 GPU를 제공하는 notebook을 준비했다.
   2. 실습 GPU는 약 102GB VRAM으로 표시되며, 네트워크가 불안정한 행사장에서는 실행 대신 미리 확보한 결과를 사용했다.
   3. 예제로 약 15GB인 Mistral 7B 모델을 GPU에 로드하고, 모델을 올린 뒤 남은 메모리와 요청을 추가할 때의 변화를 관찰한다.

2. 컨텍스트가 늘 때의 메모리 문제

   1. 입력을 더 많이 전달할수록 메모리 사용량이 천천히 계속 증가한다.
   2. 컨텍스트 길이가 4K, 16K, 32K 토큰으로 늘어나면 KV cache가 큰 폭으로 커져 out-of-memory가 발생할 수 있다.
   3. 첫 번째 병목은 “토큰 또는 컨텍스트 길이가 늘수록 메모리가 증가한다”는 사실이다.

2.2. TTFT와 처리량

1. TTFT(Time to First Token)

   1. 입력 컨텍스트가 길어질수록 첫 토큰이 나올 때까지 걸리는 시간이 늘어난다.
   2. 긴 입력을 처리하는 비용은 TTFT에 직접 반영되므로, 긴 문서를 다루는 서비스는 모델 크기뿐 아니라 입력 길이도 latency SLO에 넣어야 한다.

2. 처리량(throughput)

   1. 처리량은 초당 생성 가능한 토큰 수와 초당 처리 가능한 사용자 수를 모두 포함한다.
   2. 순수한 vanilla 구현은 요청을 순차 처리하므로 다섯 요청을 보내면 다섯 요청이 차례로 끝난다.
   3. 여러 사용자가 동시에 들어오면 각 요청 완료 시간이 길어지고 GPU 활용률도 떨어진다.

3. 네 번째 지연시간 지표

   1. prefill이 끝나 첫 토큰을 내보내기까지의 시간이 TTFT다.
   2. 이후 토큰 하나를 생성하는 데 걸리는 시간이 inter-token latency(ITL)이며, 매 토큰 사이의 체감 응답성을 결정한다.
   3. 따라서 추론에서 기억해야 할 핵심 지표는 메모리, TTFT, 처리량, ITL이다.

3. Inference pipeline과 KV cache의 수학

3.1. 토큰에서 Transformer까지

1. 순차 생성 과정

   1. 텍스트 입력을 토큰으로 바꾸며, 직관을 위해 단어 하나를 토큰 하나로 가정할 수 있다.
   2. 토큰을 embedding으로 변환한 뒤 Transformer layer를 통과시킨다.
   3. Mistral 7B 예시는 32개의 Transformer layer를 사용하지만 모델마다 layer 수는 다르다.
   4. 새 토큰 하나를 생성하면 그 토큰이 다음 입력에 다시 들어가고, 다음 토큰을 생성하는 과정이 반복된다.

2. 연산이 몰리는 곳

   1. 전체 추론 연산의 약 95%가 Transformer layer에서 일어난다.
   2. 각 Transformer layer에는 normalization, attention, feed-forward 등의 하위 layer가 있다.
   3. Attention is All You Need로 유명해진 attention은 특히 계산량이 큰 부분이므로 메모리와 연산 구조를 이해해야 한다.

3.2. Attention과 KV cache의 크기

1. Query·Key·Value 투영

   1. Attention은 각 토큰이 이전 토큰들과 얼마나 관련 있는지 attention score를 계산한다.
   2. 이를 위해 각 토큰을 query, key, value 공간으로 투영한다.
   3. 토큰이 10개면 10개의 query·key·value 벡터가, 100개면 100개의 벡터가 필요하므로 입력 길이에 따라 K와 V의 개수가 증가한다.

2. Mistral 7B의 토큰당 KV 크기

   1. Mistral 7B의 KV cache 계산값은 토큰당 약 131KB다.
   2. 한 벡터의 차원 128, 32개 Transformer layer, 일반적인 32개가 아닌 GQA 계열 KV head 수, K와 V 두 벡터를 반영한 값이다.
   3. 4K 컨텍스트에서는 토큰당 크기를 누적해 약 0.5GB가 되고, 16K 컨텍스트에서는 약 2.1GB가 된다.
   4. 4K 컨텍스트 사용자 80명을 동시에 수용하면 KV cache만 약 42GB가 될 수 있어 24GB GPU에서는 모델 가중치를 제외하고도 메모리가 부족하다.

3. GPU 메모리의 구성

   1. 고정에 가까운 모델 가중치가 먼저 GPU 메모리를 차지한다.
   2. 실행 오버헤드도 필요하며, 크기가 크게 변하지 않는 비용으로 볼 수 있다.
   3. 두 부분을 제외한 잔여 공간에 사용자별 KV cache가 쌓인다.
   4. GPU가 고정되고 모델과 토큰당 KV 크기도 고정되면 컨텍스트 길이와 동시 사용자 수가 서로 메모리를 나눠 갖는다.

3.3. 컨텍스트·동시 사용자·품질의 교환

1. 용량 방정식의 직관

   1. 동시 사용자 수는 KV에 남은 GPU 메모리를 사용자 한 명의 KV 크기로 나눈 값에 가깝다.
   2. 동시 사용자를 늘리려면 컨텍스트 길이를 줄여야 하고, 컨텍스트를 늘리려면 수용 가능한 사용자 수가 줄어든다.
   3. 컨텍스트를 줄이면 장기 문맥을 잃어 품질이 떨어질 수 있다.

2. SLO가 만드는 세 번째 축

   1. 이론상 GPU 메모리가 허용하는 최대 동시 사용자 수를 그대로 운영할 수는 없다.
   2. batch size와 입력 길이가 늘면 decode 시간도 늘어나고, TTFT와 ITL 모두 악화된다.
   3. 실제 설계의 세 축은 품질(quality), 지연시간(latency), 처리량(throughput)이다.

3. 서비스별 우선순위

   1. premium chat은 높은 품질과 짧은 latency를 우선하므로 GPU당 사용자 수나 비용 효율을 일부 희생할 수 있다.
   2. 비동기 agent workload는 오래 실행되는 작업이므로 품질과 처리량을 우선하고, 가능한 많은 작업을 동시에 처리하는 편이 낫다.
   3. 시간당 가격이 높은 GPU가 항상 비싼 선택은 아니다. 충분한 처리량을 내면 토큰 100만 개당 비용이 더 낮을 수 있다.

3.4. GPU를 고르는 capacity calculator

1. 입력해야 할 변수

   1. 모델 크기 7B, 정밀도 FP16 등 모델 조건을 고정한다.
   2. GPU별 VRAM, 메모리 대역폭, FLOPS, 시간당 가격을 비교한다.
   3. premium chat은 latency 목표를 먼저 고정하고, 비동기 작업은 GPU당 최소 batch size를 먼저 고정한다.

2. 계산 방식

   1. 예시에서는 premium chat에 10ms latency 목표, 최소 batch size 2, 높은 컨텍스트 품질을 우선하는 조건을 넣었다.
   2. 시간당 약 8~10달러인 GPU라도 수용 가능한 동시 사용자와 토큰 처리량을 계산하면 더 낮은 cost per million tokens가 나올 수 있다.
   3. GPU 선택은 시간당 가격만 보는 것이 아니라 latency·batch·컨텍스트·토큰당 비용을 함께 계산하는 것이 첫 번째 추론 최적화다.

4. Prefill·Decode와 GPU Roofline

4.1. Prefill은 compute-bound다

1. 입력 전체를 한 번에 처리하는 단계

   1. Prefill은 입력 토큰 전체에 대한 K와 V를 만들고, 각 토큰의 attention score를 이전 토큰들과 계산한다.
   2. 많은 matrix multiplication과 attention 연산이 한꺼번에 수행되므로 GPU가 잘하는 고밀도 계산에 해당한다.
   3. Prefill이 완료되는 시간이 TTFT가 된다.

2. 컨텍스트 길이와 TTFT

   1. 입력 토큰이 늘어나면 만들어야 할 KV 벡터가 늘어난다.
   2. attention 계산량도 증가하므로 입력 컨텍스트가 길수록 TTFT가 선형 이상으로 악화되는 구간을 관찰할 수 있다.

4.2. Decode는 memory-bound다

1. 한 토큰씩 생성하는 단계

   1. Decode는 한 토큰을 만든 뒤 다음 토큰을 순차적으로 생성한다.
   2. 새 토큰의 attention을 계산할 때 이전 토큰들의 K와 V를 참조하며, 한 번에 새 토큰 하나에 대한 계산만 수행한다.
   3. 계산량은 prefill보다 적지만 각 단계마다 모델 가중치와 이전 KV를 메모리에서 반복적으로 읽는다.

2. HBM과 shared memory

   1. GPU의 HBM(High Bandwidth Memory)은 크지만 shared memory보다 대역폭이 낮다.
   2. shared memory는 작지만 매우 빠르며, 계산할 데이터를 HBM에서 가져와 연산한 뒤 결과를 HBM에 다시 쓴다.
   3. Prefill은 무거운 matrix math를 한 번 수행하므로 arithmetic intensity가 높다.
   4. Decode는 이전 토큰의 KV와 모델 가중치를 많이 전송하면서 새 토큰 하나만 계산하므로 arithmetic intensity가 낮고 HBM 대역폭에 제한된다.

3. Roofline 관점

   1. Arithmetic intensity는 전송된 데이터 바이트당 수행하는 부동소수점 연산 수다.
   2. Roofline plot의 왼쪽 memory-bound 영역에서는 연산 유닛의 속도보다 데이터를 메모리에서 가져오는 속도가 상한이 된다.
   3. Decode 토큰 생성률은 shared memory의 계산 속도보다 HBM에서 데이터를 옮기는 속도에 의해 제한된다.

4.3. 실험으로 확인한 지연시간 패턴

1. Prefill 측정

   1. 입력 토큰 수를 늘리면 prefill 시간이 꾸준히 증가하고, 그 결과 TTFT가 증가한다.
   2. Cold start를 제외하면 decode 시간은 대체로 평균선 주변에 머무른다.

2. Decode의 작은 증가

   1. Decode가 완전히 일정한 시간은 아니다.
   2. 입력이 길어질수록 이전 토큰 전체의 K와 V를 메모리에서 가져와야 하므로 ITL도 조금씩 증가한다.
   3. Prefill은 컨텍스트에 민감하게 증가하고, decode는 메모리 전송량 때문에 완만하게 증가한다는 차이가 핵심이다.

5. 모델 최적화: 메모리와 attention을 줄이는 방법

5.1. 문제를 쪼개는 두 가지 가상 알고리즘

1. Ostrich algorithm

   1. 타조가 문제를 만나면 머리를 모래에 묻는다는 비유처럼 문제를 무시하는 가상 알고리즘이다.
   2. “압축해도 품질 손실이 없다고 가정한다”처럼 먼저 낙관적인 가정을 세워 빠르게 설계 공간을 좁히는 용도로 사용한다.
   3. 실제 운영에서는 외부 benchmark로 품질 손실을 검증해야 하므로 이 가정을 그대로 믿으면 안 된다.

2. World Cup algorithm

   1. 48개 팀을 12개 조로 나누고, 32강·16강·8강·4강·결승으로 유효한 결과를 계속 통과시키는 월드컵 구조를 비유로 사용한다.
   2. 큰 문제를 작은 문제로 분해하고, 각 단계에서 쓸모 있는 결과만 다음 단계로 넘기는 방식이다.
   3. 모델 최적화도 압축·행렬 분할·attention 선택·품질 검증을 작은 단계로 나눠 진행한다.

5.2. 양자화로 모델 가중치 줄이기

1. GPT-OSS 120B 예시

   1. GPT-OSS 120B를 BF16으로 저장하면 가중치가 약 240GB다.
   2. 80GB H100 한 장에 올려야 한다면 원래 정밀도로는 적재할 수 없다.
   3. BF16을 FP8로 낮추면 약 120GB로 줄지만 여전히 80GB보다 크다.
   4. MXFP4까지 압축하면 약 65GB가 되어 단일 H100에 적재할 수 있다.

2. 정밀도와 품질 검증

   1. Mistral 7B를 FP16으로 저장하면 약 14~14.6GB로 H100이나 A40에 쉽게 들어간다.
   2. FP16 대신 INT8, INT4, NF4를 적용하면 모델 가중치가 줄고 KV cache에 쓸 잔여 메모리가 늘어난다.
   3. Post-training quantization은 학습이 끝난 모델을 양자화하는 방식이다.
   4. Quantization-aware training은 fine-tuning 과정에서 양자화 효과를 반영하는 방식이다.
   5. 압축 과정에서 품질 손실이 없다고 가정하는 것은 출발점일 뿐이며, 외부 benchmark로 정확도와 생성 품질을 검증해야 한다.

3. 실험 결과

   1. Mistral 7B의 FP16 메모리 사용량은 약 15GB로 측정됐다.
   2. INT8 2배 압축은 사용량을 약 7.5GB로 낮춰 KV cache와 동시 사용자에 쓸 공간을 늘렸다.
   3. INT4 수준의 4배 압축은 이론상 약 3~4.5GB까지 낮출 수 있다.
   4. 메모리 여유가 늘면 컨텍스트 상한이나 동시 사용자 수를 올릴 수 있다.
   5. 일부 benchmark에서는 INT8 압축의 처리량이 낮아지는 경우도 관찰됐으므로, 메모리 절감이 곧 처리량 증가를 보장하지는 않는다.

5.3. Attention 구조를 줄이는 스펙트럼

1. Multi-Head Attention(MHA)

   1. 4096×4096 같은 큰 행렬의 열을 128개씩 나누면 32개 블록이 된다.
   2. 여러 GPU에서 블록을 병렬 처리할 수 있어 계산 속도를 높일 수 있지만, KV를 그대로 유지하므로 압축 효과는 없다.
   3. 품질은 좋고 병렬화에 유리하지만 KV 메모리 비용은 크다.

2. Multi-Query Attention(MQA)

   1. 32개 블록 중 하나만 남기고 모든 query가 같은 K와 V 블록을 참조한다고 가정한다.
   2. KV 저장량은 크게 줄지만, 서로 다른 query가 지나치게 적은 K/V에 의존하므로 품질 손실이 커질 수 있다.
   3. MQA는 MHA와 GQA 사이 스펙트럼의 한쪽 극단이다.

3. Grouped-Query Attention(GQA)

   1. 모든 KV head를 버리는 대신 비슷한 query가 비슷한 블록을 공유하도록 여러 KV head를 그룹화한다.
   2. MHA의 품질을 상당 부분 유지하면서 KV cache를 줄여 현재 많은 모델이 사용하는 절충안이 됐다.
   3. Mistral을 포함한 여러 모델에서 GQA가 사용되며, 실제 품질과 처리량은 모델과 사용 사례에 따라 확인해야 한다.

4. Multi-Head Latent Attention(MLA)

   1. K와 V 행렬을 latent vector로 압축하고 필요할 때 원래 표현을 복원한다.
   2. RoPE(Rotary Position Embedding)는 위치 의존적이지만 latent vector가 위치 독립적일 수 있어, key를 매핑하기 위한 별도 위치 index가 필요하다.
   3. DeepSeek 계열 논의에서는 latent 차원과 RoPE index 차원을 별도로 두며, 초기 계산은 압축률을 50~56배로 표시했다.
   4. 전날 밤 benchmark에서 layer 수를 계산에 포함하지 않은 오류가 발견되어, 실제 비교 절감량은 MHA 대비 약 14배로 정정됐다.
   5. MLA는 큰 KV 공간을 줄이는 데 매우 강력하지만, 모델 구조·위치 인코딩·복원 계산을 함께 설계해야 한다.

5. Sparse·Linear Attention과 Mamba

   1. Sparse attention은 모든 이전 토큰이 아니라 중요한 토큰만 선택해 attention하는 방향이며 DeepSeek Sparse Attention 같은 연구가 여기에 해당한다.
   2. Linear attention은 모든 행렬 곱을 그대로 수행하는 대신 정보를 먼저 요약한 뒤 조회해 계산량을 낮추려 한다.
   3. Mamba는 attention이 아닌 state space model 계열로, 상태를 유지하며 순차 정보를 처리한다.
   4. 확산 모델처럼 토큰을 순차적으로 하나씩 만들지 않고 동시에 생성하는 구조가 주류가 되면 현재 attention 최적화의 선택지도 달라질 수 있다.

6. FlashAttention

   1. 일반적인 attention은 Q와 K 행렬을 HBM에서 tensor core로 가져와 계산한 뒤 다시 HBM에 기록하는 이동을 여러 번 반복한다.
   2. FlashAttention은 큰 행렬을 작은 tile로 나누고 tile만 빠른 shared memory에 올려 HBM 왕복을 줄인다.
   3. 온라인 softmax 계산에 필요한 몇 가지 통계 변수를 유지해 전체 attention 결과를 재구성한다.
   4. 32개 KV head를 8개로 줄이면 GQA에서 4배 KV 압축을 얻는 식으로 계산할 수 있다.

5.4. 모델 최적화의 판단 기준

1. 품질이 유지되는 병렬화와 압축을 구분한다

   1. MHA는 주로 병렬화하므로 품질 손실이 없지만 KV 메모리 절감은 작다.
   2. GQA는 품질이 MHA에 가깝고 KV 비용을 줄이는 현실적인 균형점이다.
   3. MQA는 메모리 절감이 크지만 품질이 상대적으로 낮을 수 있다.
   4. MLA는 압축률이 크지만 위치 정보와 복원 구조를 고려해야 한다.

2. 성능 수치를 검증한다

   1. 데모나 슬라이드의 계산 결과가 모델 layer 수를 빠뜨렸는지 확인해야 한다.
   2. 이론적인 메모리 절감, 실제 throughput, TTFT, ITL, 품질 benchmark는 서로 다른 측정값이므로 별도로 확인한다.
   3. Attention demo는 행사 환경에서 GPU를 탐지하지 못했지만, 구조별로 MHA→GQA→MLA로 이동할수록 KV 계산과 저장을 줄인다는 원리는 유지된다.

6. Serving 최적화: KV cache를 활용하는 시스템 설계

6.1. KV cache가 반복 계산을 없애는 이유

1. 순수 decode의 낭비

   1. KV cache가 없으면 매 decode 단계마다 이전 모든 토큰의 K와 V를 다시 계산한다.
   2. 순차 생성에서 같은 계산이 반복되어 시간 복잡도가 O(N²)로 커진다.

2. 메모리를 지불하고 계산을 저장한다

   1. 이미 만든 토큰별 K와 V를 GPU 메모리에 저장하고 다음 단계에서 참조하면 반복 계산을 피할 수 있다.
   2. 이 저장 공간이 KV cache이며, 메모리 사용량을 늘리는 대신 latency와 처리량을 개선하는 전형적인 trade-off다.

6.2. PagedAttention

1. 연속 메모리 할당의 낭비

   1. 여러 요청을 batch로 넣을 때 각 요청에 2KB의 연속된 공간을 미리 할당한다고 가정한다.
   2. 실제 요청이 1KB만 사용하면 50%가 빈 공간으로 남는다.
   3. 빈 공간이 있어도 연속된 큰 블록이 없으면 새 요청을 넣을 수 없어 메모리 fragmentation이 생긴다.

2. 운영체제식 가상 메모리

   1. PagedAttention은 운영체제의 논리 메모리와 물리 메모리 분리에서 영감을 얻었다.
   2. 논리적으로는 토큰별 KV가 연속된 것처럼 보이지만, 물리적으로는 서로 다른 블록 주소에 매핑한다.
   3. KV를 블록 단위로 보고 요청이 새 토큰을 생성할 때 필요한 블록만 동적으로 할당한다.
   4. 이 방식은 단편화와 예약 낭비를 낮춰 같은 GPU에서 더 많은 요청을 수용하게 한다.

6.3. Continuous Batching

1. 정적 batch의 유휴 시간

   1. 전통적인 batch는 batch 안의 모든 요청이 끝나야 다음 batch를 받는다.
   2. 길이가 짧은 요청이 먼저 끝나도 긴 요청을 기다리는 동안 GPU가 일부 유휴 상태가 된다.

2. 요청 단위로 계속 채우기

   1. Continuous batching은 완료된 요청 자리에 새 요청을 계속 넣는다.
   2. GPU가 가능한 한 항상 작업을 수행하게 하므로 유휴 시간이 줄고 처리량이 증가한다.
   3. 다양한 길이의 요청이 섞인 실제 서비스에서 특히 중요한 serving 최적화다.

6.4. Prefix caching과 Radix tree

1. 반복되는 입력 prefix 재사용

   1. 한 요청 내부에서 KV cache가 토큰 재계산을 막는다면, prefix caching은 서로 다른 요청에 공통으로 나타나는 토큰의 prefill 결과를 재사용한다.
   2. 시스템 프롬프트나 agent의 반복 지시문처럼 동일한 prefix가 많을수록 효과가 커진다.
   3. vLLM에는 이 기능이 존재하며 바로 사용할 수 있다.

2. 정적 hash의 한계

   1. 일반적인 static prefix caching은 prompt를 hash해 다음 요청의 hash와 완전히 일치할 때 cache를 재사용한다.
   2. 사용자가 단어 하나나 글자 하나만 고쳐도 hash가 달라져 cache miss가 된다.

3. Radix tree의 장점

   1. Radix tree는 공통 prefix를 트리 노드로 공유해 완전히 동일하지 않은 요청도 공통 구간을 재사용한다.
   2. 가지가 하나뿐인 노드를 합쳐 반복되는 prompt 구조를 압축한다.
   3. agent가 “당신은 200배 뛰어난 소프트웨어 엔지니어다” 같은 지시문과 중간 결과를 반복해 test-time inference를 수행하는 경우 공통 부분이 많아진다.
   4. 이런 agentic workload에서 Radix tree 기반 prefix caching이 정적 hash보다 유리하며 SGLang이 이 계열 알고리즘을 사용한다.

6.5. KV cache 양자화

1. 가중치 외의 양자화 대상

   1. 모델 가중치만 줄이는 것이 아니라 K와 V 벡터 자체를 낮은 정밀도로 저장할 수 있다.
   2. KV 하나에 필요한 공간이 줄어들면 같은 GPU에 더 많은 토큰과 더 긴 컨텍스트를 저장할 수 있다.
   3. 컨텍스트 상한과 동시 사용자 수가 늘어날 수 있지만 품질 영향은 benchmark로 확인해야 한다.

2. 실제 적용

   1. vLLM에는 KV quantization을 포함한 여러 최적화가 이미 구현되어 있다.
   2. 직접 새 시스템을 재발명하기 전에 기존 엔진의 옵션과 측정 방법을 확인하는 것이 빠른 출발점이다.

7. Serving engine 벤치마크와 선택

7.1. 비교 조건

1. 동일 모델과 GPU

   1. 기본 비교 모델은 Mistral 7B로 고정했다.
   2. H100에서 SharedGPT 데이터셋의 질문을 넣고, 서버 기동 여부·vLLM 메트릭·KV 사용량을 측정하는 helper function을 사용했다.
   3. 서버를 바꿀 때마다 중지·재시작하고 모델을 다시 로드해야 하므로 전체 benchmark에 약 한 시간이 걸렸다.

2. 기준선

   1. Hugging Face의 단순 호출은 초당 약 51 tokens의 처리량을 보였다.
   2. TTFT는 약 54, ITL은 약 19로 기록됐다. 해당 latency 측정값은 밀리초 단위로 이해할 수 있다.
   3. 이는 cache·batching·page 관리가 없는 raw baseline이다.

7.2. vLLM의 기본 최적화

1. 기본 제공 기능

   1. vLLM은 기본 설정에서 PagedAttention, Continuous Batching, KV caching을 제공한다.
   2. 별도의 최적화 코드를 작성하지 않아도 raw Hugging Face 호출보다 훨씬 효율적인 생산 경로를 얻는다.

2. 측정 결과의 방향

   1. 기본 vLLM의 처리량은 baseline보다 거의 15배 높았다.
   2. TTFT, ITL, 사용자 수 대비 KV 사용량, 컨텍스트 대비 KV 사용량도 각각 달라지므로 처리량 하나만 보고 판단하면 안 된다.
   3. prefix caching을 켜면 처리량이 더 증가하고 TTFT가 줄었으며, ITL은 대략 비슷하게 유지됐다.
   4. prefix caching은 사용자 수 대비 KV 사용량도 낮추는 경향을 보였지만, 컨텍스트 대비 사용량 변화는 크지 않았다.

3. KV 양자화와 speculative decoding

   1. KV quantization을 추가하면 throughput·TTFT·ITL은 대체로 비슷하게 유지되면서 KV 사용량이 내려갔다.
   2. speculative decoding을 추가한 결과도 일부 KV 사용량 감소가 보였지만 전체 지표는 대체로 비슷했다.
   3. 실험 결과는 모델·프롬프트·GPU·동시성 설정에 따라 달라지므로 환경별 재측정이 필요하다.

7.3. Speculative decoding과 변형

1. 기본 원리

   1. Transformer의 본 생성은 토큰을 한 개씩 순차적으로 만든다.
   2. 작은 draft model이 네다섯 개 토큰을 먼저 제안하고, 큰 teacher model이자 referee가 제안 토큰 중 몇 개를 승인한다.
   3. 승인된 토큰을 한 번에 반영해 큰 모델의 비싼 순차 decode 횟수를 줄이는 방식이다.

2. 잘 맞는 사용 사례와 한계

   1. 코드처럼 문법과 패턴이 반복되고 창의성이 낮은 영역에서는 draft model과 큰 모델의 출력이 잘 맞을 가능성이 있다.
   2. 창의적 텍스트처럼 두 모델의 분포가 어긋나는 영역에서는 alignment가 병목이 된다.
   3. 개인적인 테스트에서는 기본 speculative decoding의 효과가 충분하지 않았다는 평가가 나왔다.

3. 다른 변형

   1. Self-speculative decoding은 큰 모델에 auxiliary head를 붙여 작은 모델 역할을 내부에서 수행한다.
   2. EAGLE 계열은 토큰을 직접 생성하는 대신 주 모델의 특정 layer feature를 이용해 다음 후보를 예측한다.
   3. Medusa는 여러 토큰을 병렬적으로 제안하려는 접근이다.
   4. 어느 변형도 모든 도메인에서 자동으로 이득을 주지 않으므로 acceptance rate와 실제 ITL을 확인해야 한다.

7.4. vLLM과 SGLang 비교

1. 표준 API workload

   1. SharedGPT 질문을 단일 요청 형태로 처리한 첫 실험에서는 vLLM과 SGLang 사이에 통계적으로 유의한 차이가 없었다.
   2. requests per second, TTFT, latency가 거의 비슷하게 나왔다.
   3. 일반적인 API workload의 생산 기본값은 기능과 생태계가 안정적인 vLLM이다.

2. Agentic branching workload

   1. “세계 최고의 소프트웨어 엔지니어가 되어 도시의 교통 혼잡을 해결하라”는 첫 요청으로 제안서를 만들게 했다.
   2. 다음 라운드에서 같은 모델에게 제안서를 검토하고 1~10점으로 평가하도록 하며, 이 대화 loop를 반복했다.
   3. 프롬프트와 컨텍스트가 계속 이어지고 분기되는 agentic workflow에서는 SGLang이 vLLM보다 약 3~4배 나은 결과를 보였다.
   4. 이 수치는 특정 H100 설정과 실험 구성에 따른 결과이며, 다른 모델·분기 수·프롬프트에서는 달라질 수 있다.

3. 실무 선택

   1. 일반 API라면 vLLM을 기본값으로 두고, PagedAttention·Continuous Batching·KV caching을 바로 활용한다.
   2. agent가 반복적인 prefix와 여러 branch를 생성하며 vLLM 성능에 만족하지 못한다면 SGLang을 검증한다.
   3. SGLang의 이점은 agentic branching과 prefix 공유에서 나오므로, 단순 단일 질의 benchmark만으로 선택하지 말아야 한다.

7.5. TensorRT-LLM과 다른 엔진

1. TensorRT와 TensorRT-LLM의 구분

   1. TensorRT는 NVIDIA의 최적화 SDK이고, TensorRT-LLM은 vLLM·SGLang과 같은 LLM inference engine이다.
   2. TensorRT-LLM은 NVIDIA GPU에 맞춰 각 layer와 연산을 하드웨어 수준에서 쪼개고 최적화한다.
   3. NVIDIA 하드웨어의 peak performance가 중요하면 TensorRT-LLM benchmark를 확인해야 한다.

2. 추가로 살펴볼 엔진

   1. NVIDIA Dynamo는 agentic session routing을 겨냥한 새 엔진으로 언급됐다.
   2. Hugging Face 직접 호출은 간단한 no-server 기준선으로 활용할 수 있다.
   3. Stanford가 제안한 멀티모달 inference engine도 소개됐으며, 슬라이드의 명칭과 최신 구현은 별도 확인이 필요하다.
   4. 120B급 GPT-OSS 비교에서는 Clarifai가 vLLM·SGLang·TensorRT-LLM benchmark를 준비했으므로, 큰 모델을 선택할 때도 공개 benchmark와 자신의 workload를 함께 비교해야 한다.

8. 운영 설계 절차와 다음 학습 주제

8.1. 모델에서 엔진까지의 선택 순서

1. 기준선부터 측정한다

   1. 사용 사례에 맞는 모델을 먼저 고르고, Mistral 7B처럼 작고 편한 모델을 무조건 선택하지 않는다.
   2. 품질·컨텍스트·출력 길이·동시성·latency SLO를 정한 뒤 raw baseline을 측정한다.

2. GPU 메모리에 맞춰 모델을 배치한다

   1. 더 큰 모델의 품질이 필요하면 FP8·INT8·INT4·NF4·MXFP4 같은 양자화로 가중치를 줄인다.
   2. 가중치를 줄여 남은 메모리를 KV cache, 컨텍스트, 동시 사용자에 배분한다.
   3. 시간당 GPU 가격이 아니라 목표 throughput을 달성했을 때의 cost per million tokens를 비교한다.

3. 서빙 최적화를 적용한다

   1. KV cache로 토큰 재계산을 없앤다.
   2. PagedAttention으로 메모리 단편화를 낮추고, Continuous Batching으로 GPU 유휴 시간을 줄인다.
   3. 반복 prefix가 많으면 prefix caching과 Radix tree를 적용한다.
   4. KV quantization과 speculative decoding은 품질·acceptance rate·실제 latency를 측정하며 단계적으로 추가한다.

4. 워크로드에 맞는 engine을 선택한다

   1. 일반 API는 vLLM을 기준선으로 삼는다.
   2. 반복·분기하는 agentic workflow는 SGLang을 비교한다.
   3. NVIDIA 하드웨어의 최고 성능이 중요한 경우 TensorRT-LLM을 benchmark한다.
   4. 멀티모달, session routing, 분산 환경처럼 요구사항이 달라지면 관련 엔진을 별도 검증한다.

8.2. 추론 엔지니어링의 다음 영역

1. KV cache가 독립적인 엔지니어링 분야가 된다

   1. 앞으로는 KV cache eviction strategy, KV compression, hybrid memory가 중요한 연구·운영 영역이 된다.
   2. 어떤 KV를 버리고 어떤 KV를 보존할지, GPU 밖 메모리와 GPU 메모리를 어떻게 조합할지 결정해야 한다.
   3. 제품에 실제로 긴 컨텍스트와 높은 동시성이 필요한지 먼저 확인한 뒤 해당 최적화를 선택해야 한다.

2. 분산 LLM inference

   1. 여러 GPU와 노드에 모델을 배치하는 distributed inference는 메모리·통신·스케줄링이 추가되는 별도 문제다.
   2. 이번 입문·중급 워크숍의 범위를 넘어서는 주제이며, 내부 동작과 hands-on을 다루려면 별도의 긴 세션이 필요하다.
   3. AI Engineer New York에서 advanced LLM inference를 다루는 후속 세션이 제안됐다.

3. 첫 원리로 신기술을 평가한다

   1. 새 attention이나 serving engine이 등장할 때 “어떤 병목을 해결하는가”를 먼저 묻는다.
   2. 메모리 절감이 필요한지, TTFT가 문제인지, ITL이 문제인지, GPU 활용률과 batch가 문제인지 구분한다.
   3. 공개 benchmark를 읽되 모델·GPU·입력 길이·동시성·agent branch가 자신의 환경과 같은지 확인한다.

주요 발언 모음

“추론 비용은 사용자, 토큰, 세션이 늘어날 때마다 반복되는 운영비다.”

“GPU가 비싸 보이더라도 처리량을 계산하면 토큰 100만 개당 비용은 더 낮을 수 있다.”

“Prefill은 compute-bound이고, decode는 메모리 대역폭에 묶이는 memory-bound 작업이다.”

“모델·GPU·사용 사례를 고정하지 않으면 어떤 최적화가 좋은지 말할 수 없다.”

“일반 API workload는 vLLM을 기본값으로 두고, agentic workload는 SGLang을 비교할 만하다.”

“새 솔루션이 어떤 문제를 해결하는지, 그 문제가 자신의 사용 사례에 실제로 존재하는지부터 확인해야 한다.”

핵심 데이터 & 수치

• 추론 시장: 약 230억 달러.
• 검색 모델링 사례: 약 360억 달러의 손익 부담과 질의당 0.5센트 미만 비용 요구.
• GPT-3 학습비: 약 460만 달러의 일회성 비용으로 언급됨.
• Transformer 연산 비중: 전체 추론 계산의 약 95%.
• Mistral 7B KV: 토큰당 약 131KB, 4K 컨텍스트 약 0.5GB, 16K 컨텍스트 약 2.1GB.
• 동시 사용자 예시: 4K 컨텍스트 사용자 80명에서 KV만 약 42GB.
• GPT-OSS 120B: BF16 약 240GB, FP8 약 120GB, MXFP4 약 65GB.
• 양자화 실험: Mistral 7B FP16 약 15GB, INT8 약 7.5GB, INT4 이론값 약 3~4.5GB.
• 기준선 benchmark: H100에서 Hugging Face 약 51 tokens/s, TTFT 약 54, ITL 약 19.
• vLLM benchmark: 기본 최적화 적용 후 기준선 대비 처리량이 거의 15배.
• MLA 정정값: 초기 50~56배 표기에서 계산 오류를 수정해 MHA 대비 약 14배 절감.
• SGLang agent benchmark: 특정 H100·반복 평가 loop에서 vLLM 대비 약 3~4배 우수.

결론 및 시사점

1. 메모리부터 계산한다: 모델 가중치와 KV cache가 차지하는 공간을 분리해 계산하고, 컨텍스트와 동시 사용자 사이의 교환을 수치화한다.
2. prefill과 decode를 분리한다: 긴 입력의 TTFT는 compute-bound prefill, 출력 속도의 상한은 memory-bound decode에서 비롯되므로 같은 최적화로 해결되지 않는다.
3. 모델 최적화와 serving 최적화를 함께 쓴다: 양자화·GQA·MLA·FlashAttention은 모델 측면, PagedAttention·continuous batching·prefix caching·KV quantization은 시스템 측면의 도구다.
4. 품질·지연시간·처리량 중 우선순위를 고정한다: premium chat과 비동기 agent는 서로 다른 최적 GPU와 엔진을 요구한다.
5. 기준선과 실제 workload로 검증한다: vLLM은 일반 API의 실용적인 기본값이고, SGLang은 반복·분기하는 agentic workload에서 강점을 보이며, TensorRT-LLM은 NVIDIA 하드웨어의 최대 성능을 겨냥한다.
6. 새 기술은 문제-해결 대응으로 읽는다: KV eviction, compression, hybrid memory, distributed inference 중 실제 병목을 해결하는 것만 선택해야 한다.

핵심 요약 (20줄)

1. LLM 추론은 학습과 달리 사용자·토큰·세션마다 반복되는 운영비이므로 비용 최적화가 제품 수익성에 직접 연결된다.
2. 추론 시장은 약 230억 달러로 언급됐고 검색 질의를 LLM으로 대체하면 질의당 0.5센트 미만 비용이 요구될 수 있다.
3. GPT-3 학습비 약 460만 달러는 일회성이지만 추론비는 사용량에 따라 계속 증가하는 운영비다.
4. 기본 추론의 핵심 병목은 GPU 메모리 증가, 긴 입력의 TTFT, 낮은 동시 처리량, 토큰 사이 지연시간이다.
5. 텍스트는 토큰과 embedding을 거쳐 여러 Transformer layer를 통과하고 생성 토큰은 다음 입력으로 다시 들어간다.
6. 전체 추론 계산의 약 95%가 Transformer layer에 집중되며 attention이 특히 계산량과 메모리 사용량을 키운다.
7. Mistral 7B의 KV cache는 토큰당 약 131KB여서 4K와 16K 컨텍스트에서 각각 약 0.5GB와 2.1GB가 된다.
8. 컨텍스트와 동시 사용자 수가 함께 늘면 KV cache가 GPU 잔여 메모리를 소진해 품질과 비용의 교환이 발생한다.
9. Prefill은 입력 전체의 attention을 계산하는 compute-bound 단계이고 완료 시간이 TTFT가 된다.
10. Decode는 한 토큰씩 생성하며 이전 KV와 모델 가중치를 반복적으로 읽어 HBM 대역폭에 묶이는 memory-bound 단계다.
11. GPU 선택은 시간당 가격보다 품질·latency·batch·동시 사용자·토큰당 비용을 함께 계산해야 정확해진다.
12. GPT-OSS 120B는 BF16 약 240GB지만 MXFP4 압축 후 약 65GB가 되어 80GB H100에 들어갈 수 있다.
13. FP16 Mistral 7B를 INT8로 줄이면 모델 메모리가 약 15GB에서 7.5GB로 감소해 KV cache 공간이 늘어난다.
14. MHA·MQA·GQA·MLA는 품질과 KV 메모리 사이에서 서로 다른 지점을 선택하는 attention 구조다.
15. MLA 절감량은 계산 오류를 바로잡아 초기 50~56배에서 MHA 대비 약 14배로 정정됐다.
16. KV cache는 이전 토큰의 K와 V를 재사용해 반복 계산을 줄이며 PagedAttention은 메모리 단편화를 낮춘다.
17. Continuous batching은 완료된 요청 자리에 새 요청을 넣어 GPU 유휴 시간을 줄이고 처리량을 높인다.
18. Prefix caching과 Radix tree는 반복되는 시스템 프롬프트와 agent 문맥을 재사용해 prefill 비용을 절감한다.
19. H100 benchmark에서 vLLM은 raw Hugging Face 기준선보다 처리량이 거의 15배 높았고 기본 생산 선택으로 제시됐다.
20. 일반 API는 vLLM, 반복 분기하는 agentic workload는 SGLang, NVIDIA 최고 성능은 TensorRT-LLM을 검증하는 순서가 합리적이다.