본문으로 건너뛰기

원리 기반 LLM 추론 성능 모델링

배치·컨텍스트·KV 구조가 LLM 추론의 병목을 결정하며 메모리와 계산 경계에서 최적화 전략이 달라진다

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

이 글은 LLM 추론 성능을 연산 집약도(Arithmetic Intensity), 처리량, 레이턴시 관점에서 1차원 물리량과 모델·워크로드 변수로부터 수식화한 후 실무적 시사점을 도출한 글이다. 입력으로 모델 파라미터 P, 레이어·헤드·헤드 차원과 배치 B, 시퀀스 길이 S, 디코드 파라미터 λ·α를 넣으면 FLOPs와 메모리 바이트를 계산해 연산 집약도를 얻고, Roofline 관점에서 메모리 바운드와 컴퓨트 바운드를 구분할 수 있다. 그 결과 짧은 컨텍스트에서는 배치·추측 디코딩으로 이득을 보고 긴 컨텍스트에서는 KV 캐시가 지배하므로 GQA/MQA나 λ·α 조정 같은 접근이 효과적이며 과도한 배칭은 단일 세션 레이턴시를 크게 악화시킨다.

섹션별 상세

LLM 추론 성능은 연산 집약도(Arithmetic Intensity), 처리량(Throughput), 레이턴시(Latency) 세 축으로 요약되며 이들 각각은 하드웨어의 peak FLOP/s와 메모리 대역폭이라는 물리적 자원으로부터 수학적으로 유도된다. 입력으로 모델 파라미터 수 P, 레이어 L, 헤드·차원 등 모델 구조와 배치 B, 시퀀스 길이 S, 디코드 시 λ 같은 워크로드 변수를 넣으면 분자에 해당하는 FLOPs와 분모에 해당하는 메모리 바이트를 계산해 연산 집약도를 산출한다. 이 관계를 Roofline 식 Performance = min(π, β * Arithmetic Intensity)로 표현하면 메모리 바운드 구간과 컴퓨트 바운드 구간이 어떻게 나뉘는지, 그리고 어디를 목표로 최적화해야 비용 효율이 나오는지가 명확해진다.
근거
  • H100 SXM의 peak BF16 tensor core throughput은 π=989 TFLOP/s이고 HBM3 대역폭은 β=3.35 TB/s이다. 변수 글로서리에서 π와 β 값이 명시된 항목(하드웨어 파라미터)
  • 해당 플랫폼의 ridge point는 약 590 FLOPs/byte로, 이 값 근처로 연산 집약도를 끌어올리는 것이 compute 유휴를 줄이는 목표가 된다. 루프라인 모델 및 ridge point 논의 부분(Arithmetic Intensity와 Roofline Model 설명)
H100 SXM 플랫폼 특성(peak BF16 tensor core throughput π=989 TFLOP/s, HBM3 대역폭 β=3.35 TB/s)을 예로 들면 연산 성능이 메모리 대역폭에 비해 매우 크므로 ridge point가 약 590 FLOPs/byte로 계산되어 이 값을 목표로 연산 집약도를 끌어올려야 compute가 idle되지 않는다. 계산은 모델 당 파라미터 바이트(예: BF16이면 2P)와 KV 캐시·활성화(activations) 바이트를 합한 분모와, 매 포워드의 행렬곱과 어텐션에서 발생하는 FLOPs를 합한 분자를 사용해 이루어진다. 여기서 데이터 타입을 바꾸면 분모가 곧바로 변해 연산 집약도와 비용 효율에 큰 영향을 주며, 저정밀도(예: int8, nvfp4)는 메모리 트래픽을 줄여 같은 하드웨어에서 더 높은 효율을 얻는 근거가 된다.
어텐션에서 발생하는 FLOPs와 KV 캐시 바이트는 시퀀스 길이 S에 선형적으로 의존하므로 짧은 컨텍스트(short-context)와 긴 컨텍스트(long-context)에서는 병목이 완전히 달라진다. 수식 한계로 보면 S→0일 때 분모에 파라미터 P가 지배적이라 batch(B)와 λ를 키우면 연산 집약도가 올라가는 반면 S→∞일 때는 KV 로드가 지배하여 연산 집약도의 극한값이 λ * H / H_kv로 수렴한다. 이로 인해 짧은 문맥에서는 배치로 효율을 개선하는 것이 유효하지만 긴 문맥에서는 배치가 더는 연산 집약도를 끌어올리지 못하고 대신 KV 희소화(GQA/MQA)나 λ 기반의 추측 디코딩이 효과적이라는 결론이 나온다.
근거
  • S→∞인 긴 컨텍스트 극한에서 연산 집약도는 λ * H / H_kv로 수렴하므로 GQA/MQA처럼 KV 헤드 수를 줄이면 긴 문맥에서 연산 집약도가 개선된다. 연산 집약도 한계식 유도 및 GQA/MQA 효과에 대한 언급
KV 캐시의 크기는 레이어 수 L, 배치 B, 시퀀스 길이 S, KV 헤드 수 H_kv, 헤드 차원 d_h에 선형 비례하므로 구체적으로 KV 바이트 = 4 * B * S * L * H_kv * d_h (BF16 기준)로 계산된다. 예시로 LLama3-8B(32 레이어, H_kv=8, d_h=128, 가중치 약 16GiB)를 넣으면 토큰 하나당 KV 바이트는 약 131,072바이트가 되어 가중치 전체(16·10^9 바이트)를 KV 바이트로 나누면 약 122,070 토큰이 나온다. 이 값보다 더 많은 토큰을 배치 내에서 처리하면 파라미터 로드보다 KV 로드가 메모리 트래픽을 지배해 long-context 행동으로 전환되므로 배치 크기와 시퀀스 길이의 조합이 성능 정책을 결정한다.
근거
  • LLama3-8B 예시에서 KV 캐시가 토큰 하나당 약 131,072바이트를 차지하며, 가중치 약 16GB를 KV 바이트로 나누면 약 122,070 토큰이 되어 그 이상이면 KV 로드가 지배적이다. KV 바이트 산출 예시와 파라미터 대비 토큰 수 계산 섹션
긴 컨텍스트 상황에서는 메모리 대역폭이 지배하므로 포워드 패스 시간 T_fwd를 바이트 수 / β로 근사할 수 있고, 이를 통해 처리량과 레이턴시의 닫힌형식을 얻을 수 있다. 구체적으로 Throughput = B * λ * α / T_fwd = B λ α β / (2P + 4 B S L H_kv d_h)이고 Latency = T_fwd / (α λ) = (2P + 4 B S L H_kv d_h) / (α λ)이다. 이 수식에서 B→∞로 보냈을 때 Throughput은 λ α β / (4 S L H_kv d_h)로 포화되지만 Latency는 발산하여 무한대로 치솟기 때문에 긴 컨텍스트에서 과도한 배칭은 처리량을 더 늘리지 못하는 동시에 단일 세션 레이턴시를 심각하게 악화시킨다.
근거
  • 긴 컨텍스트 장에서는 Throughput이 배치 B를 무한대로 늘려도 포화되고 Latency는 무한대로 증가하므로 과도한 배칭은 단일 세션 응답성을 악화시킨다. Throughput과 Latency 유도 및 B→∞ 한계값(Throughput 한계와 Latency 발산) 관련 수식
실무적 힌트로는 짧은 컨텍스트에서는 배치(B) 증대와 추측 디코딩(λ)으로 연산 집약도를 높여 비용 효율을 얻을 수 있고, 긴 컨텍스트에서는 GQA/MQA 같은 KV 희소화와 추측 디코딩을 통해 KV 바이트를 줄이거나 λ와 α의 균형을 맞추는 것이 더 유의미하다. 또한 데이터 타입을 BF16에서 더 저정밀도로 바꾸면 분모가 줄어드는 직접적 효과가 있어 동일 하드웨어에서 비용을 절감할 수 있다. 이 식들과 한계값들은 어디에서 메모리 바운드가 시작되는지, 배치·시퀀스·λ 설계가 시스템 비용과 응답성에 어떤 영향을 주는지 결정을 명확하게 해준다.

용어 해설

루프라인 모델(Roofline model)
연산 집약도와 메모리 대역폭의 관계를 성능 곡선으로 그려 병목을 가르는 분석 도구이다. 입력으로는 peak FLOP/s와 메모리 대역폭, 그리고 연산당 바이트 접근량이 필요하며 x축이 연산 집약도일 때 선형 상승과 평탄화되는 지점(ridge point)을 통해 메모리 바운드·컴퓨트 바운드를 구분한다. LLM 추론에서 어떤 최적화가 유의미한지 판단하는 지표로 사용된다.
연산 집약도(Arithmetic Intensity)
FLOPs 대비 메모리에서 로드한 바이트 수의 비율로 정의되는 지표이다. 단위가 FLOPs/byte이므로 메모리 대역폭(바이트/sec)과 곱하면 실제 달성 FLOP/s를 얻을 수 있고, H100 SXM 같은 플랫폼에서는 ridge point(~590 FLOPs/byte)가 효율 목표가 된다. LLM 추론에서 파라미터 로드·KV 캐시 크기·배치·λ값 변화가 이 값에 직접 영향을 준다.
KV 캐시(KV Cache)
디코드 시 이전 토큰들의 Key와 Value 투영을 저장한 메모리 구조로, 각 타임스텝의 Attention 계산에서 재생성 대신 로드해 사용한다. 크기는 레이어 수, 배치, 시퀀스 길이, KV 헤드 수와 헤드 차원에 선형 비례하며 BF16이면 요소당 2바이트가 소모된다. 긴 문맥에서는 이 KV 캐시 로드가 메모리 트래픽을 지배해 성능 병목을 만든다.
추측 디코딩(Speculative decoding)
한 번의 포워드 패스로 여러 쿼리 위치(λ)를 생성하고 그 중 수용(alpha)된 토큰만 커밋하는 기법으로, 동일 시간에 수행하는 연산량을 늘려 연산 집약도를 개선할 수 있다. 입력으로 큰 λ를 주면 분자와 분모 둘 다 영향을 받아 처리량과 레이턴시에 상반된 효과를 낼 수 있으며 잘 설계하면 긴 컨텍스트와 짧은 컨텍스트 양쪽에서 이득을 얻는다. 수용률(alpha)과 λ의 곱이 실제 커밋된 토큰 수가 되어 지연·비용 효과를 결정한다.
GQA·MQA(GQA / MQA)
KV 헤드 수를 줄여 Key/Value 투영을 희소화하는 설계로, GQA는 쿼리 헤드 수 대비 적은 KV 헤드를 쓰고 MQA는 하나의 KV 헤드만 쓰는 방식이다. 수렴하면 긴 문맥의 KV 바이트를 줄여 연산 집약도를 높이며 long-context에서 메모리 바운드를 완화할 수 있다. 본문에서는 LLama3-8B가 GQA를 사용해 H_kv=8로 동작한다고 명시되어 있다.

기술

  • H100 SXM
  • BF16
  • LLama3-8B
  • GQA
  • MQA
  • KV Cache

활용 사례

  • 긴 시스템 프롬프트를 가진 에이전트형 워크로드에서의 디코드 성능 최적화
  • 대규모 배치 처리(throughput-중심) 파이프라인 설계
  • 실시간 대화형 챗봇에서 단일 세션 레이턴시 관리
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 08. 07.수집 2026. 08. 07.출처 타입 RSS

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.