EP 112. AI 반도체 안에서 일어나는 일들: KV Cache부터 Roofline까지

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

AI 반도체 안에서 일어나는 성능과 비용의 차이는 KV cache가 만드는 메모리 병목과 Roofline이 보여주는 연산·대역폭의 균형으로 설명할 수 있다.

📌 핵심 요점

1. LLM 추론은 긴 입력을 병렬 처리하는 prefill과 토큰을 하나씩 생성하는 decode로 나뉜다. Prefill은 가중치를 반복 활용해 compute-bound가 되기 쉽지만, decode는 데이터 재사용이 적어 memory-bound가 되기 쉽다.
2. Decode에서는 과거 문맥의 Key와 Value를 KV cache에 보존한다. 컨텍스트와 동시 사용자 수가 늘면 KV cache가 모델 가중치보다 커질 수 있으며, 메모리 용량·대역폭·비용을 동시에 압박한다.
3. Roofline은 하드웨어의 최대 연산 능력과 메모리 대역폭을 arithmetic intensity로 연결한다. Ridge point의 왼쪽에서는 메모리 공급 속도가, 오른쪽에서는 연산 능력이 성능 한계를 결정하므로 칩의 이론 연산량만으로 실제 추론 성능을 판단할 수 없다.
4. 추론 최적화는 batch 확대만의 문제가 아니다. GQA·MLA·KV 양자화·PagedAttention·prefix caching·chunked prefill·speculative decoding·PD disaggregation은 KV 저장과 이동, TTFT와 TBT, interactivity와 throughput 사이의 절충을 조정한다.
5. Agentic AI에서는 사람이 자리를 비운 동안에도 긴 prefix와 KV cache가 누적된다. 이에 따라 SRAM·HBM·DDR·SSD를 잇는 계층형 메모리, KV 축출·회수 스케줄링, GPU와 특화 칩을 결합한 이기종 추론 인프라가 중요해진다.

🧩 배경과 문제 정의

• AI 모델의 발전 속도와 추론 수요가 급증하면서 가치 창출의 중심이 데이터센터·반도체 같은 인프라와 최종 응용 서비스 양쪽으로 이동하고 있다.
• 전력과 GPU 공급은 수요를 따라가지 못하고, 높은 컴퓨팅 비용과 메모리 병목이 AI 서비스의 확장성과 수익성을 제한한다.
• LLM 추론 비용을 이해하려면 prefill·decode의 차이, Transformer의 연산 구조, 메모리 대역폭과 KV cache가 하드웨어 자원에 미치는 영향을 함께 살펴야 한다.

🕒 시간순 섹션별 상세정리

1. AI 가치가 인프라와 응용 계층으로 이동하는 구조

• 모델 기술이 빠르게 보편화되면서 실제 수익을 확보하는 지점은 데이터센터·반도체 같은 하부 인프라와 사용자 접점의 응용 서비스로 양분되고 있다. [00:30]
• 전력을 투입해 칩을 가동하고, 학습된 모델로 대규모 추론 서비스를 제공하는 과정이 AI 반도체 성능과 벤치마크를 이해하는 핵심 맥락이다. [00:48]

2. 영구적인 컴퓨팅 부족과 폭발적인 토큰 수요

• OpenAI가 말하는 ‘compute crunch’는 학습과 추론 모두에서 연산 자원이 구조적으로 부족하며, 앞으로도 완전히 해소되기 어려운 상태를 뜻한다. [02:51]
• Google Cloud의 월간 토큰 사용량은 12개월 동안 50배, 이후 두 달을 포함한 14개월 동안 100배로 증가해 추론 수요가 하드웨어 공급보다 빠르게 커졌다. [03:27]

3. 데이터센터 투자 확대와 전력 공급 병목

• 급증한 연산 수요를 감당하기 위해 전 세계에서 GW급 데이터센터 건설이 진행되고 있으며, 2030년까지 관련 투자 규모는 약 6조7천억 달러로 추산된다. [04:33]
• 한국에서도 2035년까지 18.4GW 규모의 데이터센터 프로젝트가 추진되지만, 전력 확보가 실제 건설 가능성을 좌우하는 핵심 제약이다. [04:49]

4. 매출 증가와 컴퓨팅 증가 사이의 격차

• Anthropic의 매출은 3년 연속 매년 10배씩 증가한 반면 프런티어 연구소의 연산 능력은 매년 약 3배 증가해, 매출과 컴퓨팅 사이에 연간 약 3.3배의 격차가 생긴다. [05:21]
• 추론 마진을 높여 격차를 메울 수 있지만 현재 추정 마진이 70~80%이고 현실적인 상한을 90%로 보면 추가 개선 여지는 크지 않다. [06:04]

5. GPU 배분 한계와 컴퓨팅 단가 상승

• 학습용 GPU를 추론 서비스로 옮기면 같은 연산 자원으로 매출을 늘릴 수 있지만, 현재 학습과 추론의 비중이 이미 약 5대5여서 이동 가능한 자원이 제한적이다. [06:35]
• 학습 비중을 더 낮추면 차세대 모델 개발 경쟁에서 밀릴 수 있으므로, 프런티어 연구소는 추론 매출을 위해 학습 투자를 크게 희생하기 어렵다. [06:47]

6. LPDDR 기반 추론 칩 Bertha의 비용 전략

• HyperAccel의 첫 데이터센터용 AI 반도체 Bertha는 고가의 HBM 대신 저전력 LPDDR을 사용해 전력 소비와 하드웨어 가격을 함께 낮추는 전략을 택했다. [07:20]
• HBM은 비싸고 공급도 제한적이지만 DDR은 상대적으로 저렴하고 확보하기 쉬워, 대규모 AI 추론 서비스의 총비용을 낮출 수 있다. [07:48]

7. 낮은 이론 대역폭을 높은 활용률로 보완하는 방식

• LPDDR 모듈을 4개씩 8개 그룹으로 연결해 메모리 채널 수를 늘리고, HBM 없이도 추론에 필요한 일정 수준의 대역폭을 확보한다. [09:12]
• Bertha의 이론 대역폭은 546GB/s로 H100의 약 3TB/s보다 크게 낮지만, 실제 성능은 이론 수치보다 워크로드가 대역폭을 얼마나 활용하는지에 좌우된다. [09:34]

8. 가격·메모리 용량으로 겨냥하는 추론 시장

• Bertha의 목표 가격은 약 5,000달러로 고가 GPU보다 저렴해, 최대 속도보다 서비스 단가가 중요한 추론 환경에서 비용 경쟁력을 가진다. [10:19]
• 칩당 192GB의 LPDDR을 탑재해 적은 수의 칩으로도 대형 모델을 올릴 수 있으며, 메모리 용량 부족 때문에 장비 수를 늘리는 부담을 줄인다. [10:30]

9. 독립형 LPU와 OpenAI Jalapeño의 유사한 구조

• LPU는 완전히 새로운 반도체 분류가 아니라 NPU 계열에 붙인 제품명이며, Bertha는 GPU PCIe 카드처럼 독립적으로 장착해 사용할 수 있다. [12:00]
• OpenAI의 자체 AI 반도체 Jalapeño는 NVIDIA Rubin 세대에 해당하는 HBM4를 채택해 최신 메모리 대역폭을 확보하려는 방향을 택했다. [12:31]

10. Prefill과 decode로 나뉘는 LLM 추론

• prompt의 여러 토큰을 한꺼번에 처리해 첫 출력 토큰을 만드는 과정이 prefill이며, 긴 입력을 병렬 연산할 수 있어 GPU의 계산 능력을 적극적으로 활용한다. [15:30]
• 첫 토큰 이후에는 직전 출력 토큰을 다시 입력해 다음 토큰을 하나씩 생성하며, 이 순차적 반복이 decode 단계의 속도와 사용자 체감 응답성을 좌우한다. [16:09]

11. Transformer의 핵심 블록과 매개변수 분포

• 각 Transformer 계층은 attention과 feed-forward network를 반복하고, 마지막 LM head가 계산 결과를 바탕으로 다음 토큰을 선택한다. [18:23]
• 일반적인 dense 모델에서는 전체 매개변수의 약 20%가 attention, 약 80%가 FFN에 있어 실제 저장 공간과 연산량은 FFN 쪽에 더 많이 집중된다. [18:43]

12. Batch·sequence·embedding으로 구성되는 데이터 차원

• Transformer 입력은 동시에 처리하는 요청 수인 batch, 요청별 token 수인 sequence length, 각 token을 표현하는 embedding dimension의 세 차원으로 구성된다. [19:27]
• Prefill은 여러 입력 토큰을 한꺼번에 처리하지만 다음 토큰 하나만 출력하고, decode는 batch를 제외하면 한 토큰을 입력해 한 토큰을 출력하는 구조를 반복한다. [20:11]

13. Self-attention과 FFN이 담당하는 서로 다른 연산

• Self-attention은 Query와 Key의 행렬곱 및 softmax 결과에 Value를 곱해 토큰 사이의 관계를 계산한다. [21:49]
• Multi-head attention은 QKV를 여러 head로 나눠 독립적으로 관계를 계산한 뒤, 결과를 이어 붙이고 다시 가중치를 곱쳐 하나의 출력으로 합친다. [22:18]

14. 전역 문맥을 다루는 attention의 일반성

• CNN의 depthwise convolution은 정해진 국소 영역과 채널 방향을 나눠 처리하지만, attention은 토큰 방향 연산과 embedding 차원 연산을 결합한다. [24:09]
• 마지막 토큰은 앞선 모든 토큰을 전역적으로 참조할 수 있어 제한된 3×3 영역만 보는 합성곱보다 넓은 문맥을 처리하며, 규모 확장에 유리한 일반적 구조를 만든다. [24:28]

15. 이전 문맥을 재사용하는 KV cache

• Decode에서 새 토큰의 Query·Key·Value를 만들 때 attention 계산에는 이전 모든 토큰의 Key와 Value가 필요하며, 이 값들이 과거 문맥을 담는다. [26:40]
• 이전 Key와 Value를 매 단계 다시 계산하는 대신 prompt 처리 시 메모리에 저장해 두면 연산량을 줄일 수 있고, 이 저장 영역이 KV cache다. [27:18]

16. 긴 context가 만드는 KV cache 메모리 병목

• KV cache 용량은 Key와 Value 두 종류, Transformer 계층 수, KV head 수, 각 값의 저장 정밀도를 곱해 계산하며 모든 계층의 문맥을 보존해야 한다. [28:20]
• Grouped-query attention은 여러 Query head가 하나의 Key·Value head를 공유해 multi-head attention보다 KV cache 크기와 메모리 접근량을 줄인다. [28:40]

17. KV 캐시 용량과 서비스 비용

• 컨텍스트가 길어지면 토큰마다 생성되는 Key·Value가 누적되며, 압축하지 않으면 KV 캐시가 모델 가중치보다 더 많은 메모리를 차지할 수 있다. [30:27]
• 평균 컨텍스트 128K, 배치 32로 Llama 3.1 405B를 서비스하려면 저장 용량 기준 H100 27장이 필요하고, 실제 구성은 8장 단위이므로 약 32장까지 늘어난다. [30:57]

18. 모델·정밀도·어텐션 구조를 통한 용량 절감

• 작은 모델은 가중치와 실행 메모리를 직접 줄이고, MXFP4·NVFP4 같은 4비트 형식은 기존 8비트보다 저장 공간과 전송량을 더 낮춘다. [32:12]
• GQA는 여러 query head가 하나의 KV를 공유하고, MLA는 모든 query가 압축된 latent KV를 사용해 메모리에 저장되는 데이터 자체를 줄인다. [32:43]

19. 제한된 메모리를 보완하는 KV 운영 방식

• Sliding window attention은 전체 과거 토큰 대신 주변 구간만 참조하며, 성능 저하를 줄이기 위해 전체 attention과 번갈아 쓰는 hybrid 구성이 흔하다. [33:08]
• Mooncake 계열 방식은 HBM에 담지 못한 KV를 CPU 메모리나 SSD로 옮겼다가 필요할 때 다시 불러와 제한된 GPU 메모리를 보완한다. [33:33]

20. 추론 전용 칩과 XPU의 두 가지 병목

• 기존 추론 전용 칩은 설계 당시 예상하지 못한 KV 처리 방식에 대응하지 못할 수 있고, 신제품은 다양한 KV 활용과 메모리 구조를 초기 설계부터 반영해야 한다. [34:37]
• CPU·GPU·NPU를 포괄하는 XPU의 성능은 메모리에서 데이터를 읽고 쓰는 속도와 실제 연산을 수행하는 속도 중 더 느린 쪽에서 제한된다. [35:01]

21. H100의 균형점과 ridge point

• H100은 BF16 기준 약 1PFLOP/s의 연산 능력과 초당 3.35TB의 메모리 대역폭을 가지므로, 연산 능력이 데이터 공급 능력보다 훨씬 크다. [36:24]
• 두 수치를 비교하면 데이터를 한 번 읽을 때 약 300번 연산하는 지점에서 compute와 memory의 처리 시간이 균형을 이루며, 이를 ridge point라 부른다. [36:49]

22. Arithmetic Intensity의 의미와 계산

• Arithmetic Intensity는 메모리에서 1바이트를 읽은 뒤 수행할 수 있는 연산 횟수이며, 같은 데이터를 많이 재사용할수록 값이 높아진다. [37:48]
• 4×4 행렬 연산에서 가중치 W11을 한 번 읽어 네 차례 곱셈에 재사용한다면 해당 데이터의 산술 강도는 네 번 수준이 된다. [38:33]

23. Prefill과 decode의 산술 강도 차이

• Transformer의 산술 강도는 batch와 sequence length의 곱에 좌우되며, 여러 사용자와 토큰이 같은 가중치를 공유할수록 데이터 재사용량이 커진다. [39:20]
• Prefill에서 배치 1로 100만 토큰을 처리하면 가중치 하나를 최대 100만 번 활용할 수 있지만, decode는 토큰을 하나씩 생성하므로 재사용 횟수가 1에 가까워진다. [39:47]

24. Roofline 모델의 구조

• Roofline analysis는 하드웨어의 최대 연산 능력과 메모리 대역폭을 한 그래프에 결합하며, ridge point는 특정 모델이 아니라 하드웨어 사양으로 결정된다. [40:59]
• 수평선은 반도체가 제공하는 최대 연산량을, 기울기 1의 사선은 메모리 대역폭에 따라 얻을 수 있는 성능 한계를 나타낸다. [41:29]

25. Roofline에서 본 prefill·decode와 배치

• Ridge point 오른쪽의 prefill은 높은 데이터 재사용 때문에 compute-bound이고, 왼쪽의 decode는 가중치를 읽고 한 번만 계산하는 구조 때문에 memory-bound다. [42:22]
• Decode는 하나의 입력 토큰으로 하나의 출력 토큰을 만드는 vector-matrix 연산이므로, 행렬끼리 곱하는 prefill보다 산술 강도를 높이기 어렵다. [42:56]

26. 어텐션의 고유 병목과 완화 방법

• 사용자의 query는 다른 사용자의 KV 캐시를 공유할 수 없으므로, 일반 가중치 연산과 달리 attention은 배치를 늘려도 산술 강도가 1에 머물 수 있다. [44:24]
• GQA·MQA·MLA는 여러 query가 하나의 KV 또는 압축된 KV를 공유하게 만들어, 공유하는 query 수만큼 attention의 산술 강도를 높인다. [45:25]

27. 하드웨어 성능을 끌어내는 추론 최적화

• Prefill은 많은 토큰이 같은 가중치를 반복 사용해 CUDA 코어를 활용하는 compute-bound 작업이고, decode는 토큰별 재사용이 어려워 memory-bound 작업이 된다. [47:01]
• HBM처럼 대역폭이 높은 메모리는 Roofline의 memory-bound 영역을 끌어올려, 산술 강도가 낮은 decode의 처리 성능을 개선한다. [47:40]

28. 양자화 대상과 KV 용량의 역전

• 어떤 데이터를 양자화해야 효과적인지는 가중치와 KV 중 어느 쪽이 더 많은 용량과 대역폭을 차지하는지에 따라 달라진다. [49:13]
• Llama 3.1 70B의 BF16 가중치는 약 141GB지만, 배치가 증가하면 KV가 더 빠르게 커져 가중치 용량을 넘어서는 데 필요한 토큰 수가 감소한다. [50:02]

29. Interactivity와 throughput의 충돌

• Interactivity는 사용자 한 명이 초당 받는 토큰 수이고, throughput은 모든 사용자의 생성 토큰을 합산해 GPU 수로 나눈 GPU당 초당 토큰 수다. [51:59]
• 여러 주문을 한꺼번에 처리하면 전체 생산량은 늘지만 먼저 주문한 고객의 대기 시간은 길어지듯, 배치 확대는 throughput을 높이는 대신 interactivity를 낮춘다. [52:34]

30. Pareto curve로 비교하는 추론 성능

• SemiAnalysis 벤치마크는 x축에 interactivity, y축에 throughput을 두고 병렬화 방식과 batch size가 다른 모든 구성을 개별 점으로 표시한다. [53:47]
• 우측 상단의 최적점만 연결한 Pareto curve 바깥으로는 나갈 수 없으며, 오른쪽은 소규모 배치와 빠른 사용자 응답, 왼쪽은 대규모 배치와 높은 서버 처리량에 해당한다. [54:26]

31. 하드웨어·소프트웨어 구성을 맞춘 비교

• 여러 GPU를 사용한 결과도 GPU 수로 나누어 정규화하므로, 서로 다른 규모의 시스템을 동일한 GPU당 throughput 좌표에서 비교할 수 있다. [56:06]
• 성능 곡선은 GPU 종류뿐 아니라 모델, vLLM·SGLang 같은 추론 소프트웨어, tensor·expert·pipeline·data parallel 구성에 따라 달라진다. [56:24]

32. 서비스 경제성과 벤치마크 정보의 가치

• 모델 서비스 운영자는 목표 interactivity를 만족하는 지점의 throughput으로 GPU 투자비와 매출을 계산하며, 선택한 하드웨어·소프트웨어 스택에 따라 흑자와 적자가 갈린다. [57:49]
• GPU 구매량·클라우드 구성·사용자 요금과 Pareto curve를 결합하면 frontier lab의 비용 구조와 수익성을 역산할 수 있고, Anthropic의 토큰 마진 70~80% 추정도 이 방식에 기반한다. [58:34]

33. 무작위 요청을 수용하는 iteration 단위 스케줄링

• vLLM과 SGLang은 도착 시점과 길이를 예측할 수 없는 요청을 처리하며, 모든 요청이 끝날 때까지 다음 작업을 막는 static batching의 유휴 슬롯을 줄인다. [1:01:01]
• Orca 계열의 iteration-level scheduling은 토큰을 하나 생성할 때마다 완료된 요청을 내보내고 대기 요청을 채워, prefill과 decode를 같은 배치 안에서 처리한다. [1:02:04]

34. Prefill과 decode를 함께 묶을 수 있는 연산 구조

• Prefill과 decode는 query·key·value 및 FFN 계산에서 같은 weight를 사용하고 attention 처리만 요청별로 달라, attention을 분리하면 나머지 연산을 함께 수행할 수 있다. [1:02:43]
• 짧은 대화와 수천 줄의 코드 입력이 동시에 유입되는 환경에서 빈 슬롯은 직접적인 비용 손실이며, 승객이 찰 때까지 버스를 채우는 문제와 같은 자원 amortization이 필요하다. [1:04:18]

35. PagedAttention의 동적 KV 메모리 할당

• 응답 길이를 사전에 알 수 없어 최대 출력 길이만큼 KV 메모리를 예약하면 짧은 요청이 끝난 뒤 대부분의 공간이 낭비된다. [1:05:15]
• PagedAttention은 KV를 고정 크기 page에 순차 저장하고 page가 찰 때만 새 physical block을 연결해, 실제 토큰 수만큼 메모리를 사용하면서 더 많은 사용자를 수용한다. [1:06:15]

36. 메모리 초과 예약의 위험과 인프라 소프트웨어의 가치

• 평균 사용량을 기준으로 더 많은 요청을 받으면 메모리 활용률은 높아지지만, 여러 사용자가 동시에 최대 길이를 출력할 경우 KV를 외부로 축출하고 다시 불러와야 한다. [1:07:29]
• vLLM·SGLang·Kubernetes를 포함한 orchestration 계층의 최적화 수준은 동일한 GPU에서도 사업 비용을 크게 바꾸며, PagedAttention은 주요 inference serving framework 전반으로 확산됐다. [1:08:27]

37. Prefix caching과 chunked prefill의 지연 제어

• Prefix caching은 여러 요청이 공유하는 KV를 미리 계산해 저장하고 재사용하지만, 8,192토큰과 같은 대형 prefill이 한 번에 들어오면 함께 처리되는 decode가 지연된다. [1:09:26]
• Chunked prefill은 긴 입력을 일정 크기로 나누고 decode, 기존 prefill 조각, 신규 prefill 순으로 슬롯을 배정해 TBT를 낮추는 대신 첫 토큰 시간은 일부 희생한다. [1:10:15]

38. 작은 draft model을 이용한 speculative decoding

• Decode는 토큰 사이의 의존성 때문에 여러 토큰을 독립적으로 생성하기 어렵지만, 원본 모델의 약 100분의 1 크기인 draft model은 후보 토큰 여러 개를 빠르게 순차 생성할 수 있다. [1:11:22]
• 대형 모델은 후보 토큰을 prefill처럼 병렬 검증하고 처음 틀린 지점까지만 채택한 뒤 다시 draft model을 실행해, 반복적인 단일 토큰 decode 횟수를 줄인다. [1:12:45]

39. 단일 모델 조기 종료와 병렬 draft 생성

• 100개 layer 전체를 통과하지 않아도 쉬운 토큰은 중간 layer에서 맞힐 수 있으므로, 중간 LM head가 빠르게 후보를 만들고 전체 모델이 검증하는 단일 모델 방식이 가능하다. [1:14:10]
• DSpark 계열은 diffusion transformer로 여러 후보 토큰을 한 번에 생성한 뒤 원본 모델에서 검증하며, decode 비용을 저렴한 draft 연산과 prefill 검증으로 전환한다. [1:15:20]

40. 전통적 시스템 최적화의 재사용과 검증량 조절

• PagedAttention과 speculative decoding은 CPU·운영체제에서 발전한 paging과 자원 스케줄링 원리를 LLM·GPU 환경으로 옮겨 compute-bound와 memory-bound 사이의 병목을 바꾼다. [1:16:43]
• 후보 뒤쪽으로 갈수록 오답 확률과 불필요한 검증 연산이 커지므로, 가용 compute가 부족할 때는 생성된 8개 중 6개만 검증하는 식으로 검증 길이를 동적으로 줄인다. [1:17:17]

41. 확률적 토큰 수용과 품질·처리량 절충

• 후보가 최고 확률 토큰과 정확히 같지 않아도 충분히 높은 확률을 가지면 정답으로 수용할 수 있어, 의미상 자연스러운 대안을 버리지 않고 검증 통과율을 높일 수 있다. [1:18:12]
• 사용자가 알아채기 어려운 범위에서 수용 임계값을 조절하면 품질을 소폭 양보하는 대신 단위 GPU와 전력당 생성 토큰 수를 늘릴 수 있다. [1:18:30]

42. Prefill-decode disaggregation의 필요성

• Prefill이 대량 유입되면 decode의 토큰 간 지연이 늘고 decode만 우선하면 TTFT가 악화되므로, 하나의 GPU pool에서 두 작업을 섞는 방식에는 SLO 충돌이 발생한다. [1:18:53]
• Prefill 전용 pool과 decode 전용 pool을 분리하는 PD disaggregation은 공정별 생산라인처럼 각 자원을 한 작업에 집중시키지만, 생성된 KV 전체를 pool 사이에서 전송해야 한다. [1:19:30]

43. Raw throughput보다 goodput을 높이는 분리 구조

• Disaggregation은 일정 규모와 빠른 네트워크가 없으면 KV 전송 비용을 상쇄하지 못하며, GPU의 총연산량이 같기 때문에 raw token throughput 자체가 자동으로 증가하지는 않는다. [1:20:17]
• Prefill과 decode의 GPU 비율을 workload에 맞추면 초당 최소 30토큰 같은 응답 조건을 충족하는 처리량인 goodput이 크게 증가한다. [1:21:13]

44. Disaggregation의 적용 조건과 인터커넥트 제약

• 긴 입력과 짧은 출력이 결합되고 SLO가 엄격하며 클러스터 규모가 클수록 prefill이 decode에 주는 간섭이 커져 분리 효과가 높다. [1:21:44]
• 소규모 환경에서는 chunked prefill이 더 효율적일 수 있고, NVLink보다 느린 인터페이스를 사용하는 AI 반도체는 KV 전송 병목 때문에 disaggregation 이점이 제한된다. [1:22:08]

45. 챗봇 추론에서 agent workload로의 전환

• Roofline 최적화와 interactivity·throughput 절충, KV 관리와 스케줄링 기술은 이미 production에 들어갔으며 칩 설계도 실제 serving 동작을 이해해야 한다. [1:22:41]
• Agentic AI는 LLM과 tool을 반복 호출하는 loop를 만들기 때문에 기존 챗봇·reasoning workload와 다른 실행 패턴을 가지며, session·request·step 단위의 분석이 필요하다. [1:23:30]

46. Agent 실행 단위와 반복 호출 규모

• Session은 agent 시작부터 종료까지, request는 사람의 prompt 이후 결과가 나올 때까지의 loop, step은 그 안에서 발생하는 개별 LLM 또는 tool 호출에 해당한다. [1:24:12]
• 평균 session은 62.6분 동안 약 9.2개 request를 포함하고 request마다 약 9개 step이 실행돼, session 하나가 대략 100회의 step으로 커진다. [1:24:58]

47. Heavy-tail workload와 KV Cache 축출 전략

• 한 번의 LLM 실행에서 기존 prefix가 11만 9천 토큰인 데 비해 신규 입력은 875토큰, 출력은 214토큰에 불과해 연산보다 누적 KV를 다시 읽는 비용이 지배적이다. [1:26:09]
• Session 시간의 약 92%는 사람의 판단과 복귀를 기다리는 구간이고 LLM과 tool 실행은 약 8%에 그치지만, request 사이 중앙값 25분 동안 중앙값 40GB의 KV를 HBM에 유지하면 메모리가 낭비된다. [1:27:22]

48. KV 캐시 재계산보다 계층형 저장과 재사용이 유리한 이유

• 클라우드 비용의 약 60%가 prefix를 다시 읽는 데 쓰일 수 있으며, KV 캐시를 삭제한 뒤 재계산하는 방식은 CPU DRAM이나 스토리지로 옮겼다가 불러오는 방식보다 시간과 비용 부담이 크다. [1:30:21]
• 멀리 떨어진 저장장치에서도 기존 KV 캐시를 읽어오는 편이 대부분 유리하고, 읽는 동안 다른 연산을 병행하면 데이터 이동 지연까지 가릴 수 있다. [1:30:43]

49. 컨텍스트 압축과 메모리 경제성

• 추론 작업은 계산보다 정보를 오래 기억하는 능력에 좌우되는 경우가 많아 메모리 수요가 장기간 증가하고, 최적화가 누적되면 Anthropic·OpenAI 같은 사업자의 추론 수익성도 개선될 가능성이 크다. [1:31:55]
• 컨텍스트를 압축하면 최종 압축 KV만 남기고 이전 캐시는 제거할 수 있지만, 압축 과정에서 정보가 손상되면 일부 내용을 다시 계산해야 한다. [1:32:30]

50. Roofline으로 본 NVIDIA와 Groq의 역할 분담

• 추론 시장에는 Groq·Cerebras·TPU와 각국의 자체 칩이 진입하고 있으며, NVIDIA GPU가 담당하던 작업의 일부를 특화 하드웨어가 대체할 가능성이 커졌다. [1:33:44]
• Groq LPU는 높은 메모리 대역폭 덕분에 산술 집약도가 낮은 영역에서 강하고, Vera Rubin 계열의 LPX는 prefill과 attention을 Rubin GPU에 남긴 채 FFN만 담당한다. [1:34:24]

51. MoE와 이기종 추론 파이프라인

• MoE는 요청 배치를 여러 expert로 나누므로 개별 expert의 배치 크기와 산술 집약도가 낮아지고, 이 특성이 Groq 같은 대역폭 중심 칩에 유리하게 작용한다. [1:36:19]
• FFN 분리는 GPU와 LPU 사이에 거대한 KV 캐시를 전달하지 않고 토큰만 주고받게 해 통신량을 줄이며, 특화 칩을 기존 추론 파이프라인에 삽입하기 쉽게 만든다. [1:36:36]

52. AI 반도체 설계 자동화의 가능성과 남은 장벽

• FPGA 실험에서 AI 기반 설계가 예상보다 좋은 결과를 냈고, 설계 결과가 정상 작동하는지 확인하는 검증 단계는 소프트웨어 중심이며 평가 지표도 존재해 자동화 가능성이 높다. [1:38:18]
• RTL·Verilog 작성은 하드웨어 제약을 이해해야 하고, 트랜지스터 수준의 레이아웃과 P&R까지 결합해야 실제 작동하는 반도체가 나오므로 전체 설계 자동화에는 시간이 더 필요하다. [1:39:20]

53. 범용 GPU에서 작업별 전용 하드웨어로

• 테이프아웃 비용이 큰 반도체 산업은 검증용 시뮬레이션 도구가 이미 잘 갖춰져 있어 AI 검증을 적용하기 좋은 환경이지만, 실제 하드웨어에서는 성능·비용·전력 사이의 trade-off를 풀어야 한다. [100:08] [1:40:22]
• 하나의 LLM 작업도 Groq·GPU·Cerebras 등으로 분할할 수 있어 특수 목적 칩을 더 빠르고 다양한 형태로 출시할 수 있으며, 단일 GPU가 모든 작업을 맡는 구조는 약화된다. [100:42] [1:40:48]

54. 추론 기술의 산업화와 학습 수요

• 불과 1년여 전에는 새 모델의 학습 방식과 추론 모델 자체가 중심이었지만, 이제는 수익성 있는 추론 클라우드를 어떻게 구축하고 운영할지가 핵심 사업 문제로 바뀌었다. [102:12] [1:41:18]
• Cursor와 OpenAI, NVIDIA와 OpenAI의 충돌처럼 경쟁이 격화되고 변화 주기도 월 단위로 빨라져 기술과 산업 구조를 지속적으로 따라가야 하는 부담이 커졌다. [102:52] [1:42:55]

🧾 결론

• AI 추론의 실질적 경쟁력은 최고 FLOPS보다 목표 응답 속도에서 달성하는 goodput과 GPU·전력당 토큰 생산량으로 평가해야 한다.
• KV cache는 단순한 구현 세부가 아니라 긴 컨텍스트, 동시 사용자 수, 메모리 구매량과 API 서비스 원가를 연결하는 핵심 자원이다.
• 범용 GPU가 모든 연산을 담당하기보다 prefill·attention·FFN·decode의 특성에 맞춰 GPU, LPU, NPU와 계층형 메모리를 조합하는 방향이 강화될 가능성이 크다.
• 소프트웨어 스케줄링과 메모리 운영은 같은 하드웨어에서도 수익성을 바꿀 수 있으므로 칩과 serving stack을 하나의 시스템으로 비교해야 한다.

📈 투자·시사 포인트

• 전력 연결, HBM 공급, 메모리 대역폭과 인터커넥트가 데이터센터 증설의 실제 속도를 제한하므로 GPU 출하량만으로 AI 인프라 공급을 판단하기 어렵다.
• 최고 성능보다 가격·전력·메모리 용량을 우선하는 추론 시장에서는 LPDDR 기반 칩과 대역폭 중심 특화 하드웨어가 별도 수요를 확보할 수 있다.
• vLLM·SGLang·PagedAttention 같은 serving 소프트웨어와 성능·경제성 벤치마크는 하드웨어 투자 효율을 좌우하는 인프라 계층으로 가치가 커질 수 있다.
• Agentic AI 확산은 연산량뿐 아니라 KV cache의 장기 보존과 이동 수요를 늘리므로 CPU DRAM, SSD, 고대역폭 플래시와 관련 스케줄링 기술의 중요성을 높인다.
• 하드웨어 비교에서는 최대 처리량보다 요구 interactivity를 만족하는 Pareto curve상의 throughput, 즉 실제 과금 가능한 goodput을 확인해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• Google Cloud 토큰 증가율, 2030년 데이터센터 투자액, 초대형 모델의 매개변수 규모와 Anthropic의 추론 마진은 공개 발언 또는 외부 추정에 의존하므로 산정 범위와 시점을 별도로 확인해야 한다.
• Bertha의 90% 이상 대역폭 활용률, 약 5,000달러의 목표 가격과 PoC 공급 계획은 목표 또는 bring-up 단계의 설명이며 실제 양산 수율·소프트웨어 호환성·서비스 성능으로 검증된 결과는 아니다.
• Roofline의 이론적 위치가 같더라도 모델 구조, 정밀도, context length, batch, 병렬화 방식과 vLLM·SGLang 설정에 따라 실제 Pareto curve는 달라질 수 있다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 운영하려는 모델별로 가중치 크기와 토큰당 KV cache를 계산하고, 예상 context length와 동시 사용자 수를 적용해 HBM·DRAM·스토리지 요구량을 산정한다.
• 목표 TTFT·TBT·interactivity를 먼저 정한 뒤 batch와 병렬화 구성을 바꾸며 GPU당 throughput과 goodput을 측정한다.
• 대상 하드웨어의 FLOPS와 메모리 대역폭으로 ridge point를 구하고 prefill·decode·attention·FFN을 Roofline 위에 배치해 병목을 구분한다.
• GQA·MLA·KV 양자화·PagedAttention·prefix caching·chunked prefill을 각각 적용해 메모리 절감량과 응답 지연 변화를 비교한다.

❓ 열린 질문

• Agentic AI의 긴 유휴 시간과 heavy-tail context를 고려할 때 KV cache를 HBM에 유지할지 외부 계층으로 축출할지를 결정하는 최적 정책은 무엇인가?
• 동일한 서비스 SLO에서 HBM 중심 GPU와 LPDDR·SRAM 중심 특화 칩의 토큰당 비용은 실제 production workload에서 얼마나 차이 나는가?
• Prefill·attention·FFN·decode를 서로 다른 칩에 분리할 때 연산 효율 증가가 데이터 이동과 운영 복잡성의 비용을 넘어서는 최소 규모는 어느 정도인가?