AI 반도체 안에서 일어나는 일들: KV 캐시부터 Roofline까지

URL: https://www.youtube.com/watch?v=9Qf_QLt7IWY 날짜: 2026-09-01 채널: Chester Roh / AI Frontier Korea (노정석) 출연: Chester Roh, Jinwon Lee(HyperAccel CTO), Seungjoon Choi, Jonghyun Park 원문 제목: EP 112. What Happens Inside an AI Chip: From KV Cache to Roofline

---

메타데이터

• 콘텐츠 유형: YouTube 심층 다이제스트
• 자막: YouTube 자동 생성 영어 자막(en-US)을 기반으로 한국어로 정리
• 녹화일: 2026-08-30
• 발행일(drop_date): 2026-09-01
• 재생 시간: 1시간 44분 10초
• 핵심 주제: LLM inference, prefill, decode, KV cache, arithmetic intensity, Roofline analysis, inference serving, agentic AI, heterogeneous computing
• 관련 조직·제품: HyperAccel Bertha, OpenAI Jalapeño, NVIDIA H100·Vera Rubin·LPX, Groq LPU, vLLM, SGLang, PagedAttention, Splitwise, SemiAnalysis InferenceX
• 분류: ai-llm

---

📌 핵심 질문 / 이 콘텐츠가 다루는 핵심 논점

==LLM inference의 병목은 하나로 고정되지 않으며, prefill·decode·agentic workload의 특성에 맞춰 연산량, 메모리 대역폭, KV cache, 전력, 네트워크를 함께 설계해야 한다.==

• Prefill은 많은 입력 토큰을 한꺼번에 처리하므로 산술 집약도(arithmetic intensity)가 높고 대체로 compute-bound가 된다.
• Decode는 토큰 하나를 순차적으로 생성하며 매번 큰 가중치와 KV cache를 읽으므로 arithmetic intensity가 낮고 memory-bound가 된다.
• Batching, PagedAttention, chunked prefill, speculative decoding, prefill-decode disaggregation은 서로 다른 병목을 옮기거나 완화하는 실제 production 기법이다.
• Agentic AI에서는 사람의 대기 시간이 길어져 KV cache를 비싼 HBM에 붙잡아 두는 일이 새로운 핵심 비용 문제가 된다.
• GPU 하나가 모든 일을 담당하는 homogeneous computing에서 벗어나, GPU·LPU·외부 메모리처럼 각자 잘하는 일을 맡기는 heterogeneous computing으로 이동한다.

LLM 서비스를 평가할 때 단일 “초당 토큰 수”만 비교하면 안 된다. 사용자 한 명이 체감하는 interactivity와 서버가 GPU 한 장당 만들어내는 throughput 사이에는 trade-off가 있으며, 실제 서비스의 SLO와 비용 구조를 함께 놓고 SemiAnalysis InferenceX 같은 Pareto curve를 읽어야 한다. 결국 좋은 AI 반도체는 compute 성능만 큰 칩이 아니라, 모델 구조와 서빙 소프트웨어가 만드는 메모리·대역폭·전력·네트워크 병목까지 포함해 전체 파이프라인의 goodput을 높이는 칩이다.

---

1. AI 가치 포착이 인프라로 내려오는 배경

AI 사용량과 모델 규모가 함께 폭증하면서 모델 자체보다 이를 돌리는 데이터센터, 메모리, 전력, 칩의 경제성이 점점 중요해진다.

1.1. 모델·토큰·데이터센터 수요의 동시 팽창

1. 가치 포착의 이동

   1. 데이터센터를 바닥에 두고 칩과 모델, 애플리케이션을 위에 쌓는 AI 스택에서 모델 발전은 매우 빠르게 진행된다.
   2. 모델 계층의 차별화가 빠르게 평준화되면서 실제 돈이 만들어지는 가치 포착(value capture)은 아래쪽 인프라와 위쪽 애플리케이션으로 동시에 이동하고 있다.
   3. Chester Roh는 이전에 Seungjoon과 inference를 다루고 Dwarkesh의 Roofline analysis를 함께 살펴봤지만, 불과 3개월이 AI 업계에서는 3년처럼 느껴질 만큼 상황이 빠르게 변했다고 짚었다.

2. 영원한 compute crunch

   1. Sam Altman은 2026년 4월 OpenAI Forum에서 학습과 inference 모두에 사용할 compute가 심각하게 부족한 “compute crunch”를 언급했다.
   2. compute 부족은 일시적인 공급 문제를 넘어 앞으로도 계속될 수 있다. AI를 사용하는 사람이 늘고 모델이 커질수록 계산 자원은 다시 부족해진다.
   3. Google은 GCP의 토큰 사용량이 12개월 동안 50배 증가했다고 Google I/O에서 발표했고, 이후 14개월 기준으로 100배가 되었다고 설명했다.
   4. 그 뒤 사용량은 다시 증가해 2024년 수준의 약 330배에 이르렀으며, 토큰 수요는 폭발적으로 커지고 있다.

3. 모델과 데이터센터의 규모 경쟁

   1. 비공식 추정치로 Fable 5는 약 8T 파라미터, Mythos는 약 10T 파라미터라는 이야기가 나오며, 한동안 멈춘 듯했던 모델 규모가 다시 커지고 있다.
   2. 이를 받치기 위해 세계 곳곳에서 GW급 데이터센터가 건설되고 있으며, 2030년까지 데이터센터에 약 6.7조 달러, 한화로 거의 1경 원이 투입될 것으로 제시됐다.
   3. 한국에서도 2035년까지 국내에 18.4GW 규모의 데이터센터를 건설하려는 네 개의 메가 프로젝트가 추진되고 있다.
   4. 미국에서는 데이터센터 건설 후 전력망을 실제로 연결하기까지 평균 약 5년이 걸린다. 서울 수도권의 데이터센터 전력 신청은 절반 이상이 심사에서 탈락한다는 보도도 이어지고 있다.

1.2. 매출과 compute의 격차가 inference 가격을 밀어 올리는 구조

1. Anthropic의 매출·compute 불일치

   1. Anthropic은 3년 연속 매출을 매년 10배씩 키우는 반면, frontier lab들의 compute 용량은 매년 약 3배씩 증가하는 것으로 소개됐다.
   2. 매출 증가 속도가 compute 증가 속도보다 3.3배 빠르므로, 두 수치 사이의 격차를 설명할 경제적 메커니즘이 필요하다.

2. 매출을 늘릴 수 있는 세 가지 경로

   1. Inference 마진을 높이는 방법이 있지만, Anthropic의 inference 마진은 이미 70~80%로 추정된다. 상한을 90%로 보더라도 추가로 끌어올릴 공간은 크지 않다.
   2. 전체 GPU가 100장이고 기존에 학습 70장·서비스 30장으로 썼다면 서비스 비중을 50장까지 늘릴 수 있다. 그러나 현재 frontier lab의 학습·서비스 배분은 이미 대략 50 대 50으로 알려져 있다.
   3. 학습 비중을 더 낮추면 모델 개발이 느려진다. 생존 경쟁 중인 frontier lab이 학습을 포기하기는 어렵기 때문에 서비스에 배정할 GPU를 크게 늘리기도 힘들다.
   4. 남는 길은 compute 한 단위의 가격을 올리는 것이다. Neocloud와 비슷한 기업이 높은 수익을 내고 있으며, 단기 GPU 임대 가격은 장기 임대보다 두 배 이상 비싸다.

3. Inference 인프라의 경제적 의미

   1. 토큰 수요와 전력·GPU 부족이 겹치면 같은 compute를 더 비싸게 판매할 수밖에 없다.
   2. 따라서 inference를 더 싸고 전력 효율적으로 처리하는 칩은 단순한 대체 하드웨어가 아니라 서비스 원가와 이익률을 바꾸는 사업 인프라가 된다.

---

2. HyperAccel Bertha와 저비용·저전력 AI 칩

HyperAccel의 Bertha는 HBM 중심의 기존 AI 칩과 다른 메모리·가격·전력 설계로 느린 속도를 감수할 수 있는 대규모 inference 수요를 겨냥한다.

2.1. LPDDR을 사용하는 Bertha의 설계 선택

1. HBM 대신 LPDDR을 택한 이유

   1. Bertha는 삼성 4nm 공정으로 제조된 HyperAccel의 첫 데이터센터급 AI 칩이며, 2026년 3월 말 칩이 나온 뒤 bring-up을 진행 중이다.
   2. Bring-up은 칩 위에 소프트웨어를 올리고 실제 서비스가 가능한 수준까지 끌어올리는 단계다. 2026년 8월 Hot Chips에서 시연했으며, 추가 정제 후 한두 달 안에 PoC용으로 시장에 널리 공개할 계획이다.
   3. HBM은 대역폭이 높지만 매우 비싸고 확보하기 어렵다. Bertha는 저전력 DDR인 LPDDR을 사용해 전력과 메모리 비용을 낮춘다.
   4. 애플리케이션마다 속도 요구가 다르다. 조금 느려도 되는 서비스라면 낮은 원가가 더 중요하므로 Bertha가 적합할 수 있다.

2. LPDDR 대역폭을 확보한 방식

   1. PCIe 카드 양면에 LPDDR 메모리 4개씩, 총 8개를 배치해 DDR의 양을 크게 늘렸다. 이런 방식의 칩은 NVIDIA 제품이나 과거 Meta 제품처럼 세계적으로도 많지 않다.
   2. Bertha의 이론상 대역폭은 546GB/s다. H100의 약 3TB/s와 비교하면 대략 6분의 1이다.
   3. H100은 실제 AI workload에서 최적화 전 메모리 대역폭 활용률이 약 50%, 많은 최적화 후에도 약 70% 수준으로 제시됐다.
   4. Bertha의 내부 아키텍처는 메모리 대역폭의 90% 이상을 활용하도록 설계돼 이론상 대역폭 차이를 실제 성능에서 일부 상쇄한다.

3. 가격과 용량

   1. Bertha의 목표 가격은 약 5,000달러, 한화 1,000만 원 미만이다.
   2. 칩 한 장에 192GB 메모리를 탑재하므로 적은 수의 칩으로도 큰 모델을 서비스할 수 있다.
   3. HBM의 최고 대역폭이 필요한 모든 workload가 아니라, 높은 용량과 낮은 원가가 중요한 workload를 겨냥한다.

2.2. LPU 명칭, Jalapeño, Hot Chips

1. LPU는 새로운 계열명이라기보다 제품명이다

   1. Groq가 NVIDIA에 인수되기 전 사용하던 LPU라는 이름과 HyperAccel의 LPU 명칭은 우연히 같지만, HyperAccel이 더 일찍 사용했다고 소개됐다.
   2. Groq는 처음에 Tensor Streaming Processor(TSP)라는 이름을 썼다가 LPU로 바꿨다. LPU가 새로운 NPU 종류라는 뜻은 아니며, 넓게 보면 모두 NPU의 한 유형이다.
   3. HyperAccel LPU는 독립적으로 동작하는 PCIe 카드 제품이다. 별도 큰 칩의 부품으로만 쓰이는 것이 아니라 GPU 카드처럼 단독으로 구성할 수 있다.

2. OpenAI Jalapeño와 Bertha의 아키텍처 유사성

   1. OpenAI는 Hot Chips에서 자체 AI 반도체 Jalapeño를 공개했다. Jalapeño는 HBM4를 사용하며, NVIDIA 제품 중에서는 Rubin부터 HBM4가 사용되고 현재 Blackwell은 HBM3E를 사용한다.
   2. Jalapeño와 Bertha는 HBM 또는 DDR에서 들어오는 데이터를 인접한 코어가 직접 받아 계산하고, 코어 사이에서 계산 결과를 공유하는 구조가 매우 비슷하다.
   3. 서로 다른 장소와 시기에 별도로 개발했는데도 아키텍처가 비슷해진 점은, 대역폭과 코어 배치라는 물리적 제약이 유사한 해법을 유도한다는 의미다.

3. Hot Chips와 확인되지 않은 소문

   1. Hot Chips는 Stanford University의 한 건물 안, 별도 트랙 없는 하나의 강당 공간에서 이틀 동안 열리는 오래된 학회다.
   2. NVIDIA, AMD, Intel 같은 주요 AI 반도체 기업이 참석했고 OpenAI도 이번에 참여했다. HyperAccel에서는 bring-up 일정 때문에 CTO 대신 CEO와 엔지니어들이 참석했다.
   3. 현장에서 gpt-oss 2T 파라미터 모델이 유출됐다는 이야기가 X에서 돌았지만, Jinwon Lee가 직접 확인한 사실은 아니므로 소문으로만 남겨야 한다.

---

3. LLM inference의 두 단계와 Transformer 내부

Inference는 입력을 한꺼번에 처리하는 prefill과 다음 토큰을 순차 생성하는 decode로 나뉘며, 두 단계의 계산 특성이 근본적으로 다르다.

3.1. Prefill과 decode, TTFT와 TBT

1. Prefill의 일괄 계산

   1. “Is tomato a fruit?” 같은 prompt가 들어오면 네 개 토큰을 한꺼번에 계산해 첫 번째 출력 토큰 “Yes”를 만든다.
   2. 입력이 1,000~2,000토큰일 수도 있고 책 한 권 전체일 수도 있지만, GPU는 이 입력 토큰들을 행렬 연산으로 병렬 처리해 첫 토큰까지 진행한다.
   3. 입력이 들어온 시점부터 첫 토큰이 나올 때까지가 time to first token(TTFT)다.

2. Decode의 순차 계산

   1. “Yes”를 다시 입력으로 넣어 “it”을 만들고, “it”에서 “is”, “is”에서 문장 종료를 나타내는 end-of-sentence(EOS) 토큰을 만드는 식으로 반복한다.
   2. 앞 토큰이 나와야 다음 토큰을 계산할 수 있으므로 한 번에 한 토큰씩 생성된다.
   3. 토큰 하나가 나온 뒤 다음 토큰이 나올 때까지의 시간이 time between tokens(TBT) 또는 time per output token(TPOT)이다.
   4. TTFT는 prefill과 decode 경계까지의 체감 대기 시간이고, TBT·TPOT는 답변이 이어지는 동안의 체감 속도다.

3. 서빙 최적화의 출발점

   1. Prefill은 입력 토큰을 병렬로 처리하고 decode는 고도로 순차적이므로, 같은 GPU에서도 두 workload를 같은 방식으로 최적화할 수 없다.
   2. 서비스 품질은 첫 토큰을 빨리 보여주는 것과 이후 토큰을 끊기지 않고 빠르게 보내는 것을 모두 요구하므로 두 지표를 따로 관리해야 한다.

3.2. Transformer의 연산 흐름과 텐서 차원

1. Transformer 블록의 큰 흐름

   1. 토큰이 들어오면 위치 정보는 요즘 모델에서 내부적으로 처리되며, 대표적으로 Rotary Position Embedding(RoPE)이 쓰인다.
   2. 핵심 블록은 attention과 feed-forward network(FFN)이며, 두 블록을 여러 층 반복한 뒤 LM head가 다음 토큰을 선택한다.
   3. 100B dense 모델의 파라미터를 대략 나누면 attention이 약 20%, FFN이 약 80%다. MoE에서는 FFN 쪽 비중이 더 커진다.
   4. Attention이 Transformer의 상징처럼 보이지만, 실제 중요한 계산 축은 토큰 간 관계를 다루는 attention과 토큰 벡터 내부 차원을 다루는 FFN이다.

2. 입력·출력의 세 차원

   1. 입력은 batch(B), 토큰 수 또는 sequence length(S), 토큰을 표현하는 embedding dimension(D)의 세 차원으로 구성된다.
   2. Batch는 여러 요청을 동시에 처리하는 묶음이며, sequence length는 prompt의 토큰 수이고, D는 한 토큰이 벡터로 표현되는 차원이다.
   3. Prefill은 S가 최대 100만 토큰까지 커질 수 있지만 출력은 다음 토큰 하나이므로, 실질적으로 B×S와 D의 2차원 행렬 연산으로 볼 수 있다.
   4. Decode는 입력 토큰 하나와 출력 토큰 하나를 사용하므로 S가 항상 1에 가깝다.

3. 토큰 ID가 벡터가 되는 과정

   1. 처음 토큰은 정수 ID라는 스칼라지만, embedding을 거치면 D개의 숫자로 된 벡터가 된다.
   2. 예를 들어 B=5, S=2, D=10이면 앞의 두 차원 B×S를 평탄화해 10×10 형태로 만들고 행렬 연산을 수행할 수 있다.

4. QKV와 self-attention

   1. 토큰 embedding 벡터에 모델 가중치를 곱해 Query, Key, Value를 만든다.
   2. Query와 Key의 내적을 행렬 곱으로 계산하고 softmax를 적용한 뒤 Value를 다시 곱하면 self-attention 결과가 나온다.
   3. Multi-head attention에서는 생성된 QKV를 여러 head로 나눈다. 16개 head라면 16개 조각마다 attention을 수행한 뒤 concatenate로 다시 합친다.
   4. 합쳐진 결과에 또 다른 가중치를 곱하고 residual connection 등을 거쳐 FFN으로 보낸다.

5. FFN과 CNN의 비유

   1. FFN은 대략 두 개의 linear layer를 연속으로 적용하는 신경망이며, 최근에는 gate가 추가되어 더 복잡해졌지만 핵심은 두 번의 가중치 곱이다.
   2. Attention은 모든 토큰 사이의 관계를 학습한다. FFN은 한 토큰을 구성하는 벡터 차원 사이에서 계산한다.
   3. 이 구조는 CNN의 depthwise convolution과 닮았다. CNN은 공간 방향과 channel 방향 계산을 분리하고, Transformer는 토큰 방향 attention과 벡터 차원 FFN을 분리한다.
   4. CNN의 3×3 convolution이 고정된 지역만 보는 반면, causal attention의 마지막 토큰은 첫 토큰까지 전체 과거를 볼 수 있어 전역적이다. 이런 일반성이 scale을 키울수록 성능이 좋아지는 Transformer의 중요한 특성이다.
   5. 행렬 차원이 직관적으로 어렵다면 3Blue1Brown의 3차원 행렬 시각화 영상이 도움이 된다. 모든 gate나 내부 연산을 당장 외울 필요는 없지만, attention·FFN이 어디에서 많은 계산을 소비하는지는 알아야 이후 논리를 따라갈 수 있다.

---

4. KV cache가 만드는 메모리 문제

Decode는 앞선 토큰의 Key와 Value를 반복해서 필요로 하므로 이를 저장하는 KV cache가 생기며, 긴 문맥과 큰 모델에서는 KV cache가 모델 가중치보다 커질 수 있다.

4.1. Decode에서 Key와 Value를 재사용하는 이유

1. QKV의 재사용 패턴

   1. Prefill 때 각 토큰의 Query·Key·Value를 계산해 둔다.
   2. Decode에서 새 토큰이 들어오면 새 Query·Key·Value를 만들지만, 이전 토큰의 Query는 다시 필요하지 않다.
   3. 새 Query가 과거 모든 토큰의 Key와 상호작용하고, 결과가 과거 Value를 참조해야 하므로 이전 Key와 Value는 매 decode 단계마다 필요하다.

2. KV cache의 의미

   1. 이전 대화나 prompt의 문맥 정보가 Key와 Value에 저장된다고 생각할 수 있다.
   2. 과거 K·V를 매번 재계산할 수도 있지만, 대부분 한 번 계산한 값을 메모리에 저장했다가 읽어오는 편이 훨씬 유리하다.
   3. 새로 생성된 “Yes”의 K·V도 다음 단계에 사용해야 하므로 decode가 진행될 때마다 cache가 한 토큰씩 늘어난다.

3. 사용자 경험과 가격 정책

   1. 2,000토큰 뉴스 기사를 prompt로 넣었다면 그 2,000토큰 전체의 KV를 이후 단계에서 읽어야 한다.
   2. API 서비스는 일정 시간 KV를 보관하고 cache hit가 나면 prompt 처리 비용을 크게 할인할 수 있다. 캐시가 맞으면 가격이 약 10분의 1까지 내려가는 정책도 이런 저장 비용을 바탕으로 한다.
   3. 일반 사용자는 cache의 소멸을 직접 관리할 필요가 없지만, inference engineering에서는 언제 보관하고 언제 버릴지가 비용과 지연 시간을 결정한다.

4.2. Llama 3.1 70B의 KV cache 용량 계산

1. 토큰당 용량

   1. KV 용량은 Key와 Value 두 종류이므로 2를 곱하고, attention layer 수, KV head 수, head dimension, 저장 정밀도에 따라 계산한다.
   2. Llama 3.1 70B는 일반적인 multi-head attention이 아니라 grouped-query attention(GQA)을 사용한다.
   3. GQA에서는 예를 들어 8개의 Query head가 하나의 Key·Value head를 공유한다. Query는 8개지만 K와 V는 하나만 저장하므로 multi-head attention보다 cache가 줄어든다.
   4. BF16 또는 FP16은 요소당 2바이트다. 이 조건에서 Llama 3.1 70B의 KV cache는 토큰당 약 320KB다.

2. 긴 문맥에서의 폭증

   1. 128K 토큰 문맥을 저장하면 320KB×128,000으로 약 40GB가 필요하다.
   2. H100 한 장의 80GB 메모리 절반이 사용자 한 명의 128K 문맥 KV cache로 소모될 수 있다.
   3. 1T 모델로 커지면 layer·head·차원 증가에 따라 KV 용량이 더욱 커진다.
   4. 최근 공개 모델을 비교하면 중국계 오픈소스 모델 중에는 attention 구조를 달리해 토큰당 KV 용량을 더 작게 만든 사례가 있다. KV가 줄지 않으면 모델 가중치 저장 용량보다 KV 저장 용량이 커질 수 있다.

3. 여러 사용자와 GPU 수

   1. Batch 32, 평균 context 128K로 32명을 동시에 서비스한다고 가정하면 각 사용자의 KV가 누적되어 필요한 용량이 커진다.
   2. H100으로 Llama 3.1 405B를 서비스할 때 storage capacity만 단순 계산해도 약 27장이 필요하다.
   3. 실제 GPU 구성은 8장의 배수로 맞춰야 하는 경우가 많으므로 약 32장으로 봐야 한다. 이는 계산 성능 여유를 반영한 수치가 아니라 메모리 capacity만 나눈 값이다.

4.3. KV cache를 줄이고 계층화하는 방법

1. 모델·정밀도·attention 구조를 줄이는 방법

   1. 더 작은 모델을 사용하면 가중치와 KV의 총량을 함께 줄일 수 있다.
   2. 8비트 또는 4비트 양자화를 적용할 수 있다. 최근에는 기존 표준에 원래 등록되지 않았던 4-bit 부동소수점 형식 MXFP4와 NVFP4도 정의되고 사용되기 시작했다.
   3. GQA는 여러 Query가 하나의 K·V를 공유한다. DeepSeek가 사용한 Multi-head Latent Attention(MLA)은 하나의 latent vector로 K·V를 더 압축해 저장한다.
   4. Sliding window attention은 모든 과거 토큰 대신 정해진 창 주변만 보며, CNN의 지역 연산과 비슷하다. 성능 저하를 막기 위해 전체 attention과 sliding window를 번갈아 쓰는 hybrid가 일반적이다.

2. 외부 메모리로 내보내는 방법

   1. Mooncake 같은 시스템은 KV를 CPU 메모리로 옮기거나 SSD에 offload했다가 필요할 때 다시 읽는다.
   2. Agentic AI에서는 reasoning 모델보다도 훨씬 많은 KV가 생성되고, 에이전트가 수분에서 수십 분 동안 작업하므로 모든 KV를 고가 HBM에 계속 둘 수 없다.
   3. 오래 걸리는 작업을 실행해 두고 사람이 다른 일을 하다 돌아오는 서비스에서는 KV를 값싼 계층으로 이동하는 정책이 필수가 된다.

3. 새 칩이 감당할 수 있는 범위

   1. 기존에 제작된 inference 칩이 모든 새 KV 처리 방식을 지원하는지는 설계 당시 무엇을 예상했는지에 따라 다르다.
   2. 과거에는 KV가 이렇게 커질 것을 충분히 고려하지 않았을 수 있지만, 새로 설계되는 칩은 KV offload와 다양한 메모리 계층을 훨씬 더 의식한다.

---

5. Arithmetic Intensity와 Roofline analysis

AI 칩 성능은 계산 유닛 수 하나로 정해지지 않는다. 메모리에서 데이터를 읽는 속도와 읽은 데이터를 재사용해 수행하는 연산량의 비율이 compute-bound와 memory-bound를 가른다.

5.1. Arithmetic Intensity의 정의와 에너지 의미

1. 계산과 메모리의 겹침

   1. A와 B를 메모리에서 읽고 더해 C를 만든 뒤 다시 저장하는 단순한 연산을 생각할 수 있다.
   2. 실제 하드웨어는 A+B를 계산하는 동안 다음 C+D를 미리 읽어 연산 파이프라인을 계속 채운다. AI 연산은 같은 작업을 대량 병렬로 반복하므로 이 겹침이 기본이다.
   3. 초당 몇 번 계산할 수 있는지와 메모리에서 초당 얼마만큼의 데이터를 공급할 수 있는지가 병목의 위치를 정한다.

2. H100으로 보는 ridge point

   1. H100은 BF16 기준 약 1PFLOP/s, 즉 1,000TFLOP/s를 계산할 수 있고 메모리 대역폭은 약 3.35TB/s로 제시됐다.
   2. BF16 요소가 2바이트이므로 단순 비율을 계산하면 계산 성능과 메모리 공급이 균형을 이루는 지점이 대략 300이다.
   3. 이 균형점을 ridge point라고 한다. Hardware가 정해지면 모델과 무관하게 그 하드웨어의 compute·memory 조합에서 하나의 ridge point가 생긴다.

3. Arithmetic Intensity의 의미

   1. 여기서 AI는 Artificial Intelligence가 아니라 Arithmetic Intensity다.
   2. 메모리에서 데이터 1바이트를 읽은 뒤 몇 번의 연산을 수행할 수 있는지를 뜻한다. 같은 데이터를 많이 재사용할수록 arithmetic intensity가 높다.
   3. 4×4 가중치 행렬에서 W11 하나를 메모리에서 읽고 네 개 입력과 곱하면 W11을 네 번 재사용할 수 있다. 이 단순한 예에서 W11의 arithmetic intensity는 4로 생각할 수 있다.
   4. 실제 dot product에서는 곱셈과 덧셈이 항상 쌍으로 일어나므로 multiply-add를 2개 연산으로 세기도 하지만, 여기서는 상대적 순서와 재사용량이 핵심이다.

4. 전력과 메모리 읽기의 비용

   1. 칩 내부 SRAM, HBM, DDR에서 데이터를 읽는 에너지는 곱셈·덧셈 자체의 에너지보다 크게 높다.
   2. 위치와 구현에 따라 다르지만 메모리 계층 사이의 비용 차이는 네댓 자릿수까지 벌어질 수 있다.
   3. 저전력 칩의 핵심은 계산 유닛을 무조건 늘리는 것이 아니라 메모리에서 읽고 쓰는 데이터량을 줄이는 것이다. Arithmetic intensity는 성능뿐 아니라 전력 효율을 좌우한다.

5.2. Roofline graph에서 병목 읽기

1. 그래프의 구성

   1. Roofline analysis는 David Patterson을 포함한 연구자들이 2009년에 발표한 논문으로 널리 알려졌다.
   2. 가로축은 arithmetic intensity, 세로축은 하드웨어가 낼 수 있는 성능이다.
   3. 수평선은 compute의 최대치다. H100이라면 약 1,000TFLOP/s가 수평선의 높이를 정한다.
   4. 왼쪽 아래에서 올라가는 선은 memory bandwidth가 정한다. log-log 그래프에서 기울기 1이며, bandwidth가 높아지면 선 전체가 위로 올라간다.

2. Ridge point 이동

   1. 대역폭이 높아지면 같은 계산 성능에 도달하기 위해 필요한 arithmetic intensity가 낮아지므로 ridge point가 왼쪽으로 이동한다.
   2. 계산 유닛을 늘리면 수평선이 위로 올라가고 ridge point가 오른쪽으로 이동한다.
   3. Ridge point의 왼쪽은 memory-bound, 오른쪽은 compute-bound 영역이다.

3. Prefill과 decode의 위치

   1. Prefill은 한 번 읽은 가중치로 매우 많은 입력 토큰을 계산한다. Batch 1에 100만 토큰을 넣는다면 arithmetic intensity가 대략 100만에 이르러 ridge point 300보다 훨씬 오른쪽, 즉 compute-bound가 된다.
   2. Decode는 토큰 하나를 넣고 하나를 내보내므로 가중치를 한 번 읽고 사실상 한 번의 토큰 계산을 수행한다. Arithmetic intensity가 1에 가깝고 memory-bound가 된다.
   3. Decode의 낮은 intensity는 단순히 compute 유닛을 더 추가해서 해결할 수 없다. 데이터가 도착하는 속도보다 계산 유닛이 놀게 되는 구조가 근본적으로 다르기 때문이다.

4. Batching으로 decode를 오른쪽으로 이동

   1. 여러 사용자의 다음 토큰을 모아 같은 가중치 행렬에 동시에 곱하면 batch가 커지고 arithmetic intensity가 높아진다.
   2. Training에서 batch는 여러 문장을 뜻하지만, inference에서 sequence length가 사용자마다 크게 달라지는 batch는 사실상 동시에 서비스하는 사용자 수로 이해해야 한다.
   3. 따라서 decode 서빙은 가능한 한 많은 사용자 토큰을 묶어 GPU 계산 유닛을 채우려 한다.

5. Attention이 만드는 한계

   1. 서로 다른 사용자의 KV cache는 서로 공유할 수 없다. 한 사용자의 Query는 자기 문맥의 Key·Value를 읽어야 하므로 사용자 간 attention 행렬을 합칠 수 없다.
   2. QKV 생성과 FFN은 모든 batch가 같은 가중치를 사용하므로 함께 계산할 수 있지만, attention은 각 요청의 KV가 달라 arithmetic intensity가 1에 머무르기 쉽다.
   3. GQA는 8개의 Query가 하나의 K·V를 공유해 attention intensity를 1에서 8로 올린다. MQA에서는 16개의 Query가 하나의 K·V를 공유하므로 더 높아진다.
   4. MLA는 K·V 자체를 압축하며, prefix caching은 모든 요청에 공통인 system prompt·도구 설명·안전 지침의 KV를 미리 계산해 재사용한다.
   5. K·V를 8비트 또는 4비트로 양자화하면 같은 bandwidth로 더 많은 K·V를 읽을 수 있어 attention 병목을 완화한다.

6. 하드웨어와 모델을 맞추는 관점

   1. Roofline curve는 Transformer가 아니라 하드웨어의 compute와 memory 사양만으로 먼저 정해진다.
   2. 그 위에 prefill·decode라는 서로 다른 Transformer workload를 얹고, 각각을 가능한 한 오른쪽과 높은 위치로 옮기는 것이 inference optimization의 목표다.
   3. 이 프레임워크는 모든 세부 수식을 외우기보다, 어떤 workload가 계산을 기다리는지 메모리를 기다리는지 판단하는 사고방식으로 쓰면 된다.

---

6. Interactivity·throughput과 InferenceX

AI 반도체 벤치마크는 단일 숫자로 끝나지 않는다. 한 명의 응답 속도와 서버 전체 처리량은 반대 방향으로 움직일 수 있다.

6.1. 두 가지 성능 지표와 McMorning 비유

1. Interactivity

   1. 한 사용자가 초당 몇 토큰을 받는지를 tokens per second per user로 측정한다.
   2. 같은 모델이라도 batch를 작게 잡아 한 사용자에게 자원을 많이 주면 interactivity가 올라가고 답변이 빠르게 이어진다.
   3. Anthropic의 fast mode처럼 일반 모드보다 약 2.5배 빠른 서비스를 제공하면서 6배 요금을 받는 가격 정책은 이 자원 배분에서 나온다.

2. Throughput

   1. 서버가 여러 사용자의 토큰을 합쳐 처리한 총 토큰 수를 GPU 수로 나눈 값이 GPU당 throughput이다.
   2. 한 명에게 가는지 100명에게 나뉘는지와 관계없이 서버가 일정 시간 동안 만들어낸 토큰을 합산한다.
   3. Batch를 크게 만들면 throughput은 증가하지만 각 사용자의 대기와 응답 속도는 떨어질 수 있다.

3. McMorning 비유

   1. McDonald’s에서 먼저 주문한 사람이 음식이 나올 때까지 기다리는 동안 직원이 여러 주문의 빵을 한 번에 굽고 포장하면 전체 처리량은 높아진다.
   2. 먼저 주문한 한 사람의 interactivity는 나빠진다. 여러 명의 주문을 가득 채운 버스, KTX 좌석을 꽉 채우는 문제도 동일한 최적화다.
   3. 결국 inference 서빙은 빈 버스를 줄이고 승객을 가득 태워 보내는 일이며, throughput과 interactivity 사이의 선택이다.

6.2. SemiAnalysis InferenceX Pareto curve 읽기

1. 그래프를 만드는 변수

   1. InferenceX는 x축에 interactivity, y축에 throughput을 놓는다. 오른쪽일수록 사용자 토큰 속도가 빠르고, 위쪽일수록 GPU당 서버 처리량이 높다.
   2. Tensor parallelism, expert parallelism, pipeline parallelism, data parallelism 같은 병렬화 설정과 batch size를 바꾸며 많은 실험점을 만든다.
   3. 각 실험점 중 우측 상단의 지배적인 점을 연결하면 Pareto curve가 된다. 곡선 위쪽으로는 같은 조건에서 올라갈 수 없다.

2. 오른쪽과 왼쪽의 trade-off

   1. 오른쪽으로 이동하면 batch size와 동시 사용자 수가 줄어 한 사용자에게 더 많은 자원을 주므로 interactivity가 좋아진다.
   2. 왼쪽으로 이동하면 동시 사용자를 많이 처리해 GPU당 throughput은 높아지지만, 각 사용자는 KV cache를 더 많이 읽게 되어 느려진다.
   3. 사용자가 1명이면 그 사용자의 KV만 읽지만 10명이면 10명의 KV를 읽고 attention을 수행해야 한다. 100개 layer라면 이 일이 100번 반복된다.

3. 비교 방법과 사업적 사용

   1. 여러 GPU를 써도 총 throughput을 GPU 수로 나누므로 서로 다른 규모의 구성을 같은 축에서 비교할 수 있다.
   2. 실제 그래프는 hardware, model, vLLM·SGLang 같은 orchestration software, parallelism 설정을 모두 반영한다.
   3. 서비스가 사용자에게 최소 100 tokens/s를 보장해야 한다면 x축 100에 수직선을 긋고 그 지점의 throughput을 비교한다.
   4. 곡선은 서로 교차할 수 있다. 큰 batch 구간에서 좋은 하드웨어가 작은 batch 구간에서도 항상 좋은 것은 아니며, 하드웨어와 소프트웨어 특성에 따라 우열이 바뀐다.
   5. 기업은 모델과 서비스 요구사항을 이 그래프에 대입해 필요한 GPU 수, 사용자에게 청구할 가격, 투자 회수 기간, 이익 여부를 추정할 수 있다.
   6. SemiAnalysis는 이런 대규모 측정 데이터로 frontier lab의 매출과 token margin을 역산하며, 투자 없이도 기업과 칩 회사에 보고서를 판매해 높은 수익을 내고 있다.

4. LPU가 유리한 구간

   1. Jensen Huang이 GTC에서 보여준 LPU 비교 그래프는 낮은 batch, 높은 interactivity 구간에서 LPU curve가 크게 떨어지지 않고 유지되는 모습을 강조한다.
   2. LPU가 높은 bandwidth를 제공하면 한 사용자 또는 소수 사용자에게 KV를 읽어주는 구간에서 좋은 성능을 낼 수 있다.
   3. 그래프의 모양을 이해하면 NVIDIA, AMD, LPU 기업이 발표하는 benchmark의 숫자와 조건을 함께 해석할 수 있다.

---

7. Inference serving 소프트웨어의 핵심 최적화

실제 요청은 한꺼번에 정렬되어 오지 않는다. 요청 도착 시점과 응답 길이가 제각각이므로 vLLM·SGLang 같은 orchestration software가 하드웨어 이용률과 수익성을 크게 좌우한다.

7.1. Static batching에서 continuous batching으로

1. Static batching의 낭비

   1. 네 요청이 동시에 들어오면 전통적인 static batching은 네 요청을 한 batch로 묶고, 네 요청 모두가 끝날 때까지 다음 요청을 받지 않는다.
   2. 짧은 요청이 먼저 끝나도 가장 긴 요청이 끝날 때까지 빈 슬롯으로 남는다. 빈 슬롯은 ChatGPT 관점에서 수익을 만들지 못하는 GPU 비용이다.

2. Iteration-level scheduling

   1. 서울대학교 Byung-Gon Chun 교수 연구실이 제안한 Orca 논문은 요청 단위가 아니라 iteration 단위로 스케줄링한다. Byung-Gon Chun은 FriendliAI도 창업했다.
   2. 토큰 하나가 생성될 때마다 스케줄러가 다시 확인한다. R2가 먼저 끝나면 다음 iteration에서 대기열의 R6을 받아 prefill을 시작한다.
   3. Prefill과 decode가 한 시점에 섞여 있어도 QKV 생성과 FFN은 동일한 가중치를 사용하므로 함께 실행할 수 있다.
   4. 유일하게 별도 처리가 필요한 부분은 요청마다 다른 KV를 읽는 attention이다. 이 부분을 분리하면 prefill과 decode를 한 batch 안에 섞어도 된다.
   5. Prefill이 1,000토큰이면 query가 1,000개이고 decode는 query 하나지만, 동일 가중치를 재사용한다는 점에서는 함께 처리할 수 있다.

3. Continuous batching의 본질

   1. 사용자는 짧은 “Hi”를 보낼 수도 있고 Claude Code에서 수천 줄의 코드를 보낼 수도 있어 서비스 제공자는 도착할 workload를 미리 알 수 없다.
   2. Continuous batching은 빈 슬롯이 생길 때마다 새로운 요청을 넣어 GPU를 계속 채운다.
   3. McDonald’s 햄버거, 고속버스, KTX 승객을 가득 채우는 비유는 모두 amortization과 utilization을 높이는 같은 문제다.

7.2. PagedAttention과 메모리 가상화

1. 최대 길이 사전 할당의 문제

   1. 사용자가 몇 토큰을 출력할지 미리 알 수 없으므로 최악의 최대 출력 길이를 기준으로 KV 메모리를 예약하면 짧은 대화의 빈 공간이 낭비된다.
   2. “Hello” 몇 토큰으로 끝나는 요청도 최대 길이 공간을 붙잡게 되므로 동시에 받을 수 있는 사용자가 줄어든다.

2. Page table 기반 동적 할당

   1. PagedAttention은 KV cache를 page 단위로 쪼개 필요한 만큼만 물리 메모리에 할당한다.
   2. 첫 단어가 Alan이면 가상 block 0을 물리 block 7에 연결하고, 같은 page에 Turing과 computer를 이어 저장한다.
   3. 한 page가 네 단어를 담는다면 가득 찬 뒤 새 page를 할당한다. 가상 block 1을 물리 block 1에, 가상 block 2를 물리 block 3에 연결하는 식으로 물리적으로 흩어진 메모리를 table이 관리한다.
   4. page 안에 한 슬롯만 사용됐다면 세 슬롯이 남았다는 정보도 관리한다. 필요한 만큼만 동적으로 할당하므로 더 많은 사용자를 서비스할 수 있다.

3. 최악의 경우와 eviction

   1. 은행이 모든 고객이 예금을 한꺼번에 찾지 않는다고 보고 준비금을 낮게 두는 것처럼, 실제 시스템도 모든 요청이 최대 길이까지 가지 않는다고 보고 추가 사용자를 받는다.
   2. 우연히 모든 사용자가 최대 길이의 답변을 생성하면 메모리가 부족해진다. 이때 일부 KV를 내보냈다가 나중에 다시 읽어야 한다.
   3. 따라서 PagedAttention은 평균 상황에서 매우 효율적이지만, 최악의 tail workload까지 처리하는 소프트웨어 설계가 필요하다.

4. Orchestration software의 산업적 가치

   1. 같은 NVIDIA GPU와 오픈소스 모델을 쓰더라도 vLLM, SGLang, Kubernetes 등의 orchestration layer를 얼마나 잘 최적화하는지에 따라 성능과 비용이 몇 자릿수까지 달라질 수 있다.
   2. PagedAttention은 논문으로 발표된 뒤 오픈소스에 흡수되어 vLLM이 되었고, 현재는 거의 모든 inference serving framework가 유사한 기능을 사용한다.
   3. 하드웨어뿐 아니라 이 소프트웨어 계층도 실제 AI 인프라의 핵심 산업이다.

7.3. Chunked prefill

1. 긴 prefill이 decode를 멈추게 하는 문제

   1. 8,192토큰 prompt가 한꺼번에 들어오면 ridge point가 약 300인 하드웨어에서 많은 iteration을 차지한다.
   2. 이 긴 prefill이 bus를 점유하면 이미 진행 중인 decode가 늦어져, 답변이 잘 나오다가 갑자기 중간에 멈추는 것처럼 보일 수 있다.

2. Prefill을 잘라 넣는 정책

   1. Prefill을 일정한 크기의 chunk로 잘라 decode와 번갈아 태운다.
   2. 우선순위는 보통 decode가 가장 높다. 이미 진행 중인 decode를 먼저 태우고, 이전에 시작했지만 버스에 못 탄 prefill, 새로 도착한 prefill 순으로 공간을 채운다.
   3. Decode의 TBT를 낮추는 대신 prefill의 TTFT를 조금 희생해 응답이 일정하게 이어지도록 한다.
   4. 작은 규모에서는 PD disaggregation보다 chunked prefill이 더 유리할 수 있다.

7.4. Speculative decoding

1. 여러 토큰을 한 번에 만들려는 이유

   1. Autoregressive decode는 토큰 하나씩 생성하므로 arithmetic intensity가 낮다.
   2. Decode batch를 늘리면 KV도 함께 늘어나 attention이 좋아지지 않는 문제가 있다. 따라서 KV를 늘리지 않고 여러 토큰을 동시에 제안하는 방법이 speculative decoding이다.

2. Draft model과 target model

   1. 원래 모델의 약 100분의 1 크기인 작은 draft model이 빠르게 8개 토큰을 순차 생성한다.
   2. 큰 target model은 이 8개 토큰을 prompt prefill처럼 한꺼번에 넣어 검증한다.
   3. target model은 “the” 다음에 “cat”, “sat”, “on”이 맞는지 각 prefix 길이별 다음 토큰을 병렬로 계산한다.
   4. 중간 토큰이 틀리면 맞았던 지점까지만 채택하고 draft model로 돌아가 그 지점부터 다시 8개를 만든다.

3. 변형과 비용

   1. 두 모델을 계속 오가야 하므로 작은 모델과 큰 모델을 모두 실행하는 비용이 있다.
   2. 같은 모델을 일부 층만 실행하는 방법도 있다. 100-layer 모델을 50층에서 잘라 LM head를 붙이고 예측 통계를 내면, 50층만으로도 약 70%를 맞히고 70층쯤이면 거의 대부분을 맞힐 수 있다.
   3. DSpark는 diffusion transformer처럼 여러 토큰을 한꺼번에 생성하는 방식을 draft model로 사용하고, 원래 모델이 검증하는 접근으로 소개됐다.
   4. EAGLE-3도 speculative decoding 계열 방법이다.
   5. Prefill은 decode보다 싸므로 작은 모델의 빠른 제안을 큰 모델의 저렴한 prefill 검증으로 바꾸는 것이 핵심 경제성이다.

4. 적응형 검증

   1. DeepSeek의 DSpark는 제안된 토큰 8개를 항상 모두 검증하지 않는다. 뒤쪽으로 갈수록 틀릴 확률이 커지고, compute가 이미 부족한데 틀릴 가능성이 높은 토큰까지 계산하면 낭비다.
   2. 현재 compute 자원을 보고 마지막 두 개를 빼고 여섯 개만 검증하는 식으로 검증 길이를 조절한다.
   3. 토큰은 확률적으로 생성되므로 최고 확률 토큰만 정답으로 인정할 필요는 없다. “Hello”와 “Greetings”처럼 의미상 모두 자연스러운 후보를 허용하는 threshold를 조정해 품질과 속도를 교환할 수 있다.
   4. Ridge point가 더 높아져도 이 구조의 원리는 유지된다. Decode의 순차성을 prefill의 병렬 검증으로 바꾸는 방식은 하드웨어 수치와 무관하게 계속 쓰인다.

---

8. Prefill-decode disaggregation과 goodput

Prefill과 decode가 서로 다른 Roofline 위치에 있으므로, 큰 서비스는 두 작업을 서로 다른 pool로 분리해 SLO를 맞추려 한다.

8.1. PD disaggregation의 구조

1. 두 pool로 나누는 이유

   1. Prefill은 sequence length×batch size에 따라 arithmetic intensity가 크게 올라가고 decode는 attention을 제외하면 batch size의 영향을 주로 받는다.
   2. 긴 prefill이 decode에 섞이면 decode TBT가 나빠지고, decode만 우선하면 prefill TTFT가 길어진다.
   3. Prefill pool은 prefill만, decode pool은 decode만 처리해 두 workload를 각각의 최적 조건에서 실행한다.

2. Token Factory 비유

   1. Jensen Huang이 말하는 Token Factory는 토큰을 많이 만든다는 뜻뿐 아니라 자동차 조립 라인처럼 공정을 분리한다는 의미를 포함한다.
   2. 한 작업자가 바퀴를 조립하고 다른 작업자가 문을 다는 것처럼, prefill 전담 pool과 decode 전담 pool이 이어진다.
   3. Prefill에서 만들어진 모든 KV를 decode pool로 보내야 하므로 두 pool 사이 네트워크 대역폭이 중요하다.

3. Throughput과 goodput의 차이

   1. 같은 GPU 100장을 모두 100% 사용한다면 raw throughput, 즉 만들어지는 총 토큰 수 자체는 분리 전후로 크게 늘지 않는다.
   2. PD disaggregation이 높이는 것은 정해진 SLO를 만족하는 goodput이다. 예를 들어 최소 30 tokens/s를 받아야 하는 사용자 수를 더 많이 만족하게 된다.
   3. Microsoft Splitwise 논문은 같은 H100으로 prefill instance 수를 달리해 pool 비율을 조절하는 방식을 논의했다.

8.2. 언제 효과가 커지는가

1. 효과가 큰 조건

   1. 입력이 길고 출력이 짧으면 prefill이 차지하는 비중이 커 decode를 방해하므로 PD disaggregation의 효과가 크다.
   2. 사용자에게 “반드시 이 SLO를 지켜야 한다”처럼 엄격한 지연 시간 조건이 있을수록 goodput 개선 가치가 커진다.
   3. 충분히 큰 규모에서 pool을 나누고 네트워크 비용을 상쇄할 수 있어야 한다.

2. 효과가 작은 조건

   1. 작은 규모에서는 pool 간 KV 전송과 관리 비용 때문에 단순한 chunked prefill이 더 유리할 수 있다.
   2. NVIDIA GPU는 NVLink 같은 고속 interconnect가 있어 PD disaggregation이 잘 작동한다.
   3. 인터페이스가 느린 AI 반도체에서는 KV 전송 지연이 커져 기대한 만큼 이득을 얻기 어렵다.

---

9. Agentic AI가 만드는 새로운 inference workload

Agentic AI에서는 AI가 사람보다 훨씬 많이 LLM을 호출하고, 사람은 긴 시간 돌아오지 않는다. 병목은 계산량이 아니라 KV를 얼마나 오래, 어디에 보관할지로 이동한다.

9.1. Session·request·step 구조

1. 세 단계의 정의

   1. Session은 에이전트가 시작해 모든 작업을 끝낼 때까지의 전체 기간이다.
   2. Request는 사람이 prompt를 주고 에이전트가 LLM과 tool을 반복 호출해 하나의 결과를 낼 때까지다. 사람이 결과를 확인한 뒤 새 작업을 주면 또 다른 request가 된다.
   3. Step은 request 안에서 LLM이나 tool이 한 번 호출되는 단위다.

2. 관찰된 규모

   1. Copilot의 2026년 6월 전체 trace를 분석한 2026년 8월 논문과 TraceLab 같은 연구가 agent workload를 분석하기 시작했다.
   2. 평균 session은 62.6분이고 session당 request는 약 9.2개다.
   3. Request 하나당 약 9 step이므로 session 하나에 대략 100 step이 있다.
   4. 실제 LLM call의 약 90%는 사람이 아니라 AI가 시작한다. 사람이 prompt를 넣을 때는 한 번 호출하지만, agent loop 안에서는 AI가 계속 다음 LLM을 호출한다.

3. Reasoning과 KV 폭증

   1. Chatbot에서 reasoning model로 넘어오며 thinking token이 크게 늘었고, 이제 각 agent step 안에 긴 reasoning LLM call이 반복된다.
   2. 한 사례에서는 이전 prefix를 읽는 토큰이 119,000개, 새로 추가된 토큰이 875개, 출력 토큰이 214개였다.
   3. 새 출력을 계산하는 양보다 이미 쌓인 prefix와 KV를 다시 읽는 양이 압도적으로 많아졌다. Rereading이 inference 비용의 핵심이 된다.

9.2. Heavy tail과 사람의 대기 시간

1. Long-tail 분포

   1. Agent workload는 평균적인 한 사례만 보면 안 된다. tail이 전체 시스템을 좌우하는 heavy-tailed 분포다.
   2. median과 average가 최대 15배까지 벌어질 수 있으며, 최악의 경우를 무시하면 agent 서비스가 실패한다.
   3. 평일에는 session 수가 많고 주말에는 session 수가 적지만 session당 iteration이 많다. 주말에 복잡한 작업을 걸어 두고 떠나는 패턴이 반영된다.

2. 사람이 만든 대기

   1. 한 request가 끝난 뒤 다음 request를 주려면 사람이 결과를 읽고 판단해야 하므로 시간이 생긴다.
   2. 전체 session 시간 중 사람의 시간이 약 92%, tool call이 4.8%, LLM이 3.3%다. 기계가 실제 작업하는 시간은 약 8%이고 사람이 92%를 차지한다.
   3. Session 내부 request 사이의 사람 대기 시간 median은 25분이다. 사용자는 agent를 계속 바라보지 않고 다른 agent를 쓰거나 다른 일을 하다가 돌아온다.

3. KV cache의 골든타임

   1. Request 사이 median 25분 동안 median 약 40GB의 KV를 고가 HBM에 붙잡아 두는 것은 매우 비효율적이다.
   2. 분석상 사람이 5~10분 안에 돌아올 가능성이 높은 구간이 KV cache의 golden time이다.
   3. 가벼운 machine learning 모델로 10분 안에 돌아올지 여부를 예측할 수 있다. 정확히 몇 분 뒤에 돌아올지 맞히기는 어렵지만 곧 돌아올 사람과 오래 돌아오지 않을 사람은 예상보다 잘 구분된다.
   4. 예측에는 사용자별 기록이나 prompt 내용, 작업 유형, 실행 시각 같은 특징을 사용할 수 있다. 취침 전에 긴 작업을 걸어 둔 경우처럼 시간대와 과제 유형이 복귀 확률에 영향을 준다.

9.3. 재계산보다 재읽기, 계층형 메모리

1. Eviction 이후의 선택

   1. Cloud 서비스 원가를 분해하면 prefix를 읽는 비용이 약 60%가 될 수 있다.
   2. HBM에서 KV를 쫓아낸 뒤 사용자가 돌아오면 KV를 완전히 삭제하고 다시 계산하거나, CPU DRAM·SSD·외부 메모리에 저장했다가 읽어올 수 있다.
   3. 대부분의 경우 재계산은 오래 걸리고 비싸며, 외부 계층에서 다시 읽는 것은 조금 느려도 재계산보다 훨씬 짧다. 따라서 KV를 멀리 보내고 필요할 때 읽는 방향이 유리하다.
   4. 읽어오는 동안 다른 계산을 수행해 latency를 숨길 수 있다면 재읽기 비용을 더 줄일 수 있다.

2. 메모리 계층의 역할 분담

   1. SRAM, HBM, DDR, SSD, high-bandwidth flash를 계층으로 두고 KV 중간 결과를 언제 어느 계층으로 보낼지 스케줄링해야 한다.
   2. KV 압축을 하면 최종 compressed KV만 남길 수 있지만 압축 과정에서 정보가 사라져 사용자가 돌아왔을 때 일부 계산을 다시 해야 할 수 있다.
   3. 모델마다 최대 context length도 다르다. 어떤 서비스는 Opus 1M, 즉 100만 토큰을 제공하고 다른 서비스는 27만 토큰만 제공하므로 필요한 메모리 farm과 가격 구조가 완전히 달라진다.

3. 병목의 이동

   1. 초기에는 compute가 병목이었다가 memory, power, network로 병목이 이동하고 다시 돌아온다.
   2. Agentic AI에서는 “계산을 얼마나 빨리 하느냐”보다 “필요한 것을 어디에 보관하고 얼마나 빨리 되읽느냐”가 서비스 원가를 좌우한다.
   3. 이 문제를 잘 해결하는 vLLM·SGLang 같은 오픈소스 도구와 메모리 관리 소프트웨어가 새롭게 중요한 인프라가 된다.

---

10. Heterogeneous computing과 AI 반도체의 미래

Inference pipeline을 세분화할수록 GPU·LPU·메모리·네트워크가 각각 잘하는 일을 맡는 heterogeneous computing이 자연스러워진다.

10.1. Vera Rubin과 Groq LPU의 결합 논리

1. Roofline으로 본 특성

   1. Vera Rubin과 Groq를 하드웨어 Roofline graph에 놓으면 Groq 쪽이 더 높은 bandwidth 영역에 위치하고, arithmetic intensity ridge point가 한 자릿수인 구간에서 강점이 있다.
   2. NVIDIA의 Vera Rubin family는 PD disaggregation 계열을 LPX라고 부른다.
   3. LPX 구성에서는 prefill과 decode의 attention을 Rubin GPU가 담당하고, FFN을 Groq의 LPX가 담당하는 식으로 작업을 나눈다.

2. Groq가 FFN에 맞는 이유

   1. Groq는 약 500MB의 SRAM만 사용한다. 이 용량에는 앞에서 계산한 대규모 KV cache가 들어갈 수 없으므로 KV를 계속 들고 있어야 하는 attention에는 맞지 않는다.
   2. FFN은 KV가 필요하지 않으며, MoE에서는 batch가 expert별로 나뉜다. 전체 batch가 커도 한 expert가 보는 batch는 상대적으로 작아 arithmetic intensity가 여전히 낮게 남을 수 있다.
   3. 따라서 Groq는 KV를 서로 전달하지 않고 토큰만 GPU와 주고받으며 FFN을 빠르게 처리하는 역할에 적합하다.

3. 다음 단계의 파이프라인

   1. Agentic AI가 external memory를 빠르게 읽거나 칩 가까이에 큰 메모리를 붙이는 특성을 요구하면, KV를 외부 계층에 저장한 채 일부 계산을 병렬 수행할 수 있다.
   2. 이런 특성이 pipeline과 맞으면 한 회사의 한 종류 칩이 모든 작업을 하지 않고 각 칩의 장점을 조합하는 구조가 된다.
   3. Homogeneous computing은 거의 끝나가고, 어떤 작업을 어느 하드웨어에 꽂아야 가장 좋은지 찾는 시대가 온다.

10.2. HyperAccel의 다음 제품과 산업 전망

1. Bertha 이후의 방향

   1. Bertha는 가격과 전력을 주요 병목으로 보고 저비용·저전력에 집중했다.
   2. 다음 제품은 Agentic AI의 긴 idle time, 거대한 KV, 계층형 메모리 요구에 맞는 특성을 고려해 준비 중이다.
   3. Compute·memory·power 세 축을 모두 해결하는 플랫폼 경쟁이 inference hardware 시장의 중심이 된다.

2. AI 인프라의 산업화

   1. GPU만 쓰던 시기에는 새 모델의 학습 방식과 파라미터가 주된 대화였지만, 이제는 수익성 있는 cloud를 어떻게 만들지와 token economics를 어떻게 설계할지가 핵심이 됐다.
   2. Cursor·OpenAI, NVIDIA·OpenAI 사이의 경쟁처럼 모델 기업·클라우드·칩 기업의 이해관계가 강하게 충돌한다.
   3. Inference는 연구 주제가 아니라 메모리, 전력, 소프트웨어, 네트워크를 모두 포함한 산업 운영 문제가 됐다.

---

11. AI가 바꾸는 반도체 설계와 전문 칩의 춘추전국시대

AI가 칩 설계·검증을 자동화하고 workload를 세분화하면 특수 목적 하드웨어가 빠르게 늘어난다.

11.1. Verifiable한 설계·검증 업무

1. AI가 먼저 잘할 수 있는 영역

   1. FPGA 기반 연구와 논문 결과를 보면 설계·검증의 일부는 예상보다 잘 자동화되고 있다.
   2. 특히 설계한 회로가 의도대로 작동하는지 확인하는 verification은 software domain에 가까워 검증 가능한 metric을 만들기 쉽다.
   3. OpenAI는 CUDA 관련 작업을 Codex로 빠르게 만들었다고 소개했다. DeepSeek를 돌릴 MLA kernel이 없었지만 Codex로 신속하게 구현했다는 사례도 제시됐다.

2. 완전 자동화가 어려운 영역

   1. RTL과 Verilog로 회로를 작성하는 design은 하드웨어를 의식해 코딩해야 하므로 단순한 소프트웨어 생성보다 제약이 많다.
   2. 좋은 결과인지 판단하는 기준이 workload와 목적에 따라 달라진다. 단순히 기능이 맞는지만으로는 충분하지 않고 area, power, timing, throughput을 함께 봐야 한다.
   3. Transistor 수준의 물리 설계, layout, place and route(P&R)까지 합쳐야 실제 작동하는 반도체가 된다.
   4. 설계와 verification, 물리 구현이 한꺼번에 연결되는 데는 시간이 걸리지만, 각 단계의 자동화는 이미 진행 중이며 전체 자동화도 오래 남지 않았을 가능성이 크다.

11.2. 전문 하드웨어의 분화

1. 작업별 trade-off에 따른 분업

   1. Groq, GPU, Cerebras, TPU, 중국계 칩 등은 서로 다른 compute·memory·power trade-off를 갖는다.
   2. LLM 하나 안에서도 prefill, decode, attention, FFN, MoE, KV storage를 각각 다른 하드웨어에 배치할 수 있다.
   3. 이 분업은 한 GPU가 모든 일을 맡는 구조보다 각 workload의 Roofline 위치에 맞춘 효율을 낼 수 있다.

2. 반도체의 춘추전국시대

   1. 생산 이후 수정 비용이 매우 큰 하드웨어는 tape-out 전에 simulation과 verification으로 위험을 줄여야 한다.
   2. AI가 검증 도구와 설계 코드를 잘 다루고, workload가 세분화되면 특수 목적 칩이 연이어 등장할 수 있다.
   3. CPU만 있던 시대에 게임용 GPU가 분화된 것처럼, LLM inference에서도 특정 작업에 최적화된 여러 칩이 공존하는 춘추전국시대가 열린다.

---

주요 발언 모음

“AI의 세계에서는 3개월이 3년처럼 느껴진다.”

“앞으로도 우리는 항상 compute가 부족한 세계에서 살 가능성이 크다.”

“Prefill은 여러 토큰을 한꺼번에 넣고, decode는 한 토큰씩 순차적으로 내보낸다.”

“KV cache는 이전 대화의 기억이며, decode에서는 그 기억을 계속 읽어야 한다.”

“Ridge point의 왼쪽은 memory-bound이고, 오른쪽은 compute-bound다.”

“InferenceX의 그래프는 어떤 하드웨어와 소프트웨어 조합이 실제 서비스에서 돈을 벌게 하는지 보여준다.”

“Agentic AI에서 사람은 92%의 시간을 차지하고, LLM과 tool은 약 8%만 사용한다.”

“Homogeneous computing은 거의 끝나가고, 각자가 잘하는 일을 찾아 연결하는 시대가 온다.”

---

핵심 데이터 & 수치

• 2026-09-01: 영상 발행일. 2026-08-30 녹화.
• 1시간 44분 10초: 전체 재생 시간.
• 50배 → 100배 → 330배: Google GCP 토큰 사용량의 12개월·14개월·2024년 대비 증가 수준.
• 약 8T·10T 파라미터: Fable 5와 Mythos에 관한 비공식·추정 규모.
• 6.7조 달러: 2030년까지 예상되는 전 세계 데이터센터 투자액.
• 18.4GW: 한국에서 2035년까지 추진되는 네 개 데이터센터 메가 프로젝트 규모.
• 약 5년: 미국 데이터센터의 전력 연결까지 걸리는 평균 기간.
• 70~80%: Anthropic inference 마진 추정치.
• 3배 대 10배: frontier lab의 연간 compute 증가와 Anthropic 연간 매출 증가 속도.
• 546GB/s: HyperAccel Bertha의 이론상 LPDDR 대역폭.
• 약 3TB/s: H100의 메모리 대역폭.
• 90% 이상: Bertha 내부 아키텍처가 목표로 하는 대역폭 활용률.
• 약 5,000달러·192GB: Bertha 목표 가격과 칩당 메모리 용량.
• 약 320KB/토큰: Llama 3.1 70B, GQA, BF16 기준 KV cache 용량.
• 약 40GB: 128K context에서 한 사용자의 KV cache 용량.
• 27장 → 실제 약 32장: Llama 3.1 405B를 batch 32·128K context로 H100에 올릴 때 capacity만으로 계산한 GPU 수와 8장 단위 구성 고려치.
• 약 300: H100 BF16 기준 Roofline ridge point 추정치.
• 약 100분의 1: speculative decoding의 draft model이 target model보다 작을 수 있는 규모.
• 62.6분·9.2개·약 9개: agent session 평균 시간, session당 request 수, request당 step 수.
• 약 100개: agent session 하나에 포함되는 대략적인 step 수.
• 90%: 사람이 아니라 AI가 시작하는 실제 LLM call 비율.
• 119,000·875·214토큰: 한 agent LLM call에서 읽은 prefix, 새로 추가된 토큰, 출력 토큰.
• 최대 15배: heavy-tail workload에서 median과 average의 차이.
• 92%·4.8%·3.3%: session 시간 중 사람·tool·LLM의 비중.
• 25분·약 40GB: request 사이 사람 대기 시간 median과 유지되는 KV cache median 용량.
• 5~10분: KV cache를 HBM에 유지할 가치가 높은 golden time.
• 약 500MB: Groq LPU의 SRAM 용량.

---

결론 및 시사점

1. LLM inference는 prefill과 decode를 분리해 봐야 하며, prefill은 compute-bound, decode는 memory-bound라는 차이가 모든 최적화의 출발점이다.
2. KV cache는 긴 문맥과 reasoning·agent loop가 확산될수록 모델 가중치보다 커질 수 있으므로, attention 구조·양자화·페이지 할당·외부 메모리 정책이 칩 성능만큼 중요하다.
3. Roofline의 ridge point는 모델이 아니라 하드웨어가 정하는 기준선이며, workload를 그 기준선의 유리한 쪽으로 옮기는 것이 batching·GQA·MLA·prefix caching의 공통 원리다.
4. Interactivity와 throughput은 동시에 최대화하기 어렵다. 실제 구매와 서비스 설계에서는 사용자의 최소 tokens/s, GPU당 throughput, SLO, 가격, 투자 회수 기간을 InferenceX Pareto curve에 함께 대입해야 한다.
5. Continuous batching, PagedAttention, chunked prefill, speculative decoding은 논문 속 아이디어가 아니라 현재 production serving stack의 핵심 구성요소다.
6. PD disaggregation은 총 토큰 생산량보다 SLO를 만족하는 goodput을 높이는 기술이며, 긴 입력·짧은 출력·엄격한 SLO·고속 interconnect가 있을 때 효과가 크다.
7. Agentic AI의 주요 비용은 LLM이 실제로 계산하는 시간이 아니라 사람이 돌아올 때까지 KV를 보관하고 다시 읽는 시간에서 발생한다. HBM·DDR·SSD를 계층적으로 사용해야 한다.
8. Bertha처럼 낮은 가격·전력·높은 용량을 택한 칩과 Groq처럼 높은 bandwidth·SRAM으로 특정 FFN 구간을 노리는 칩은 서로 다른 병목을 공략한다.
9. GPU, LPU, TPU, Cerebras, 외부 메모리, orchestration software가 하나의 inference pipeline에서 역할을 나눌수록 homogeneous computing의 비중은 줄어든다.
10. AI가 RTL·verification·kernel 개발을 자동화하면서 특수 목적 칩의 설계 속도가 빨라지고, AI 반도체 시장은 단일 GPU 중심에서 다양한 전문 하드웨어가 공존하는 춘추전국시대로 향한다.

---

핵심 요약 (20줄)

AI 인프라의 가치 포착은 빠르게 모델에서 데이터센터·메모리·칩과 애플리케이션 쪽으로 이동하고 있다. Google의 토큰 사용량은 1년 만에 50배, 14개월 만에 100배, 2024년 대비 약 330배로 늘었다. 모델이 수조 파라미터로 커지고 데이터센터·전력 투자가 폭증하면서 compute crunch는 구조적 문제가 됐다. HyperAccel Bertha는 HBM 대신 LPDDR을 사용해 낮은 가격과 전력, 192GB 용량을 겨냥한다. Prefill은 많은 prompt 토큰을 병렬 처리하고 decode는 앞 토큰에 의존해 한 토큰씩 순차 생성한다. TTFT는 첫 토큰까지의 시간이고 TBT·TPOT는 이후 토큰 사이의 시간을 뜻한다. Transformer의 핵심 계산은 토큰 간 관계를 다루는 attention과 토큰 벡터 내부를 처리하는 FFN이다. Decode는 이전 토큰의 Key와 Value를 반복해서 읽기 때문에 KV cache라는 큰 메모리 부담을 만든다. Llama 3.1 70B는 GQA와 BF16 기준 토큰당 약 320KB, 128K 문맥당 약 40GB의 KV가 필요하다. KV 문제는 작은 모델, 양자화, GQA·MLA, sliding window, CPU·SSD offload로 완화할 수 있다. Arithmetic intensity는 메모리에서 읽은 데이터를 재사용해 수행하는 연산량이며 전력과 성능을 함께 좌우한다. H100의 Roofline ridge point는 약 300으로, prefill은 compute-bound이고 decode는 memory-bound가 된다. Batching은 decode arithmetic intensity를 높이지만 서로 다른 사용자의 KV를 공유할 수 없어 attention에는 한계가 있다. Interactivity는 사용자별 토큰 속도이고 throughput은 GPU당 총 토큰 처리량이어서 서로 trade-off 관계다. SemiAnalysis InferenceX는 하드웨어·모델·소프트웨어·병렬화 조합의 Pareto curve로 이 trade-off를 보여준다. Continuous batching과 PagedAttention은 빈 GPU 슬롯과 미리 할당된 KV 메모리를 줄여 더 많은 사용자를 받게 한다. Chunked prefill은 긴 입력이 decode를 막는 현상을 줄이고 speculative decoding은 작은 모델의 제안을 큰 모델이 병렬 검증하게 한다. PD disaggregation은 prefill pool과 decode pool을 나누어 raw throughput보다 SLO를 만족하는 goodput을 높인다. Agentic AI에서는 사람이 평균 25분 뒤 돌아오며 약 40GB KV를 붙잡아 두므로 계층형 메모리와 재읽기가 핵심이 된다. 미래의 AI 팩토리는 GPU·LPU·외부 메모리·소프트웨어가 각자 잘하는 일을 맡는 heterogeneous computing으로 향한다.