Astra가 엄청난 모델이라는 이야기는 많이 들었다.
하지만 실제로 그 변화가 여기까지 이어질 수 있을 것이라고는 생각하지 못했다.
돌이켜보면 나 역시 매일의 주가 흐름과 시장의 평가에 조금씩 영향을 받으면서, 예전처럼 기술 변화의 끝을 자유롭게 상상하기보다 당장의 현실적인 제약과 숫자 안에서만 생각하려 했던 것 같다.
그러다 Astra의 Long Context와 Agentic Workload가 실제로 Compute와 Memory 구조를 어떻게 바꿀지를 하나씩 따라가다 보니 생각보다 훨씬 큰 변화가 보이기 시작했다.
Astra가 바꾸는 것은 단순히 모델의 성능이나 Token 사용량만이 아니었다.
더 긴 Context, 더 많은 동시 Agent, 더 오래 유지되는 Memory는 결국 HBM의 Capacity와 Bandwidth를 더욱 중요한 병목으로 만들고, 이미 설치된 GPU의 유휴 FLOPS를 얼마나 실제 Token 생산으로 전환할 수 있는지가 AI Factory의 경제성을 결정하게 된다.
그렇게 생각을 이어가다 보니 HBM 역시 단순히 GPU에 붙는 고가의 Memory Component가 아니라, GPU와 전력에 투자한 막대한 자본의 생산성을 결정하는 핵심 설비에 더 가까워 보이기 시작했다.
이번 글은 Astra가 만들어낼 변화에서 출발해, 그 변화가 HBM의 수요와 기술적 중요성을 넘어 HBM 자체의 경제적 가치와 가격결정 구조를 어떻게 바꿀 수 있는지를 따라가 본 리서치 기록이다.
이번 글의 핵심문단은 아래와 같다.
Agentic AI가 확산될수록 더 긴 Context와 KV Cache를 유지해야 하고, 출력 단계에서는 이를 매 Token마다 반복적으로 읽어야 하기 때문에 Decode의 HBM Bandwidth 병목은 더욱 중요해진다.
결국 GPU의 연산성능이 아무리 높아져도 HBM이 데이터를 충분히 빠르게 공급하지 못하면 Tensor Core는 기다릴 수밖에 없다.
그래서 앞으로 HBM의 경제적 가치는 단순히 저장하는 Byte의 가치가 아니라, Memory Wall을 해소해 되살리는 GPU FLOPS와 추가 Token 생산량의 가치에 의해 결정될 가능성이 높다.
The Price of Idle FLOPS, Astra & HBM
Astra 이후, HBM의 가격은 무엇으로 결정될까
최근 OpenAI의 GPT-6 Astra와 NVIDIA의 Rubin, NVHBM 관련 자료들을 함께 정리하면서 HBM을 바라보는 기준을 조금 바꿔야겠다는 생각이 들었다.
그동안 HBM 수요를 전망할 때 가장 먼저 봤던 숫자는 GPU당 HBM 탑재용량이었다.
80GB에서 141GB, 192GB에서 288GB로 올라가는 식이다.
하지만 Astra와 같은 Agentic Model이 등장하고, Rubin처럼 GPU의 연산성능이 메모리 대역폭보다 훨씬 빠르게 증가하기 시작하면 앞으로 더 중요한 질문은 단순히 GPU 한 개에 HBM이 몇 GB 들어가는가가 아닐 수 있다.
오히려,
HBM이 없어서 얼마나 비싼 GPU의 연산기가 놀고 있는가.
그리고
추가적인 HBM Capacity와 Bandwidth가 그 유휴 FLOPS를 얼마나 다시 유료 Token으로 바꿀 수 있는가.
이 질문이 HBM의 경제적 가치를 설명하는 데 더 중요해질 수 있다.
앞서 생각정리 325 (* Memory Premium)에서 비슷한 문제를 한 번 다뤘다.
당시의 결론은 HBM의 적정가격을 DRAM 제조원가만으로 볼 것이 아니라, Memory가 회복시키는 GPU 가동시간과 추가 Token의 가치를 기준으로 역산해야 한다는 것이었다.
이번에는 Astra 이후의 Agentic AI와 Rubin·NVHBM까지 연결해서 이 생각을 조금 더 확장해본다.
1. Astra에서 중요한 것은 100만 Token이 아니다
GPT-6 Astra와 GPT-5.6 Sol의 최대 Context Window는 모두 105만 Token이다.
따라서 Astra가 Sol보다 더 많은 Memory를 필요로 한다면 단순히 Context Window가 늘었기 때문은 아니다.
중요한 것은 같은 100만 Token을 얼마나 실제 업무에 활용할 수 있느냐다.
OpenAI의 Long-context 평가에서 512K~1M Token 구간의 성능은
 |
| OpenAI |
Astra 96.3%
Sol 73.8%
였다. (OpenAI)
명목상 Context Window는 같지만 실제 활용 가능한 Working Context의 범위는 상당히 달라진 것이다.
Astra의 변화는 단순히 더 긴 글을 읽는 데 그치지 않는다.
Research, Coding, Computer Use와 같은 작업을 장시간 이어가면서 과거의 Tool Output과 상태를 계속 유지하고, 이를 다시 불러와 다음 행동에 활용한다.
이 변화의 배경은 앞서 생각정리 328 (* The agent Mutipler, Unhobbling, OOM)에서 정리했기 때문에 여기서는 반복하지 않는다.
이번 글에서 중요한 것은 그 다음이다.
Agent의 능력이 높아질수록 Memory가 필요한 이유가 Model Weight 하나에서 Agent의 Working State 전체로 확장된다.
Model Weight
KV Cache
Active Context
Multiple Agents
Tool History
Persistent Memory
결국 AI의 Memory 수요 단위가
GB per Model
에서
GB × Bandwidth × Concurrent Agents × Context Lifetime
으로 바뀌기 시작한다.
2. 효율이 좋아지는데 왜 HBM 수요는 늘어날까
Astra는 일부 업무에서 Sol보다 적은 Token과 짧은 시간으로 더 높은 성공률을 보인다.
따라서 한 업무만 떼어놓고 보면 Memory Traffic이 생각보다 크게 증가하지 않을 수도 있다.
문제는 가격과 성능이 개선될수록 사람이 AI에 맡기는 업무 자체가 늘어난다는 것이다.
이 내용 역시 생각정리 358 (* The Price of Compute)에서 이미 다뤘다.
Token당 가격이 내려가면 AI 사용량이 줄어드는 것이 아니라,
Hardware Efficiency ↑
→ Cost per Token ↓
→ Addressable Tasks ↑
→ Agent Calls ↑
→ Compute Consumption ↑
→ Cloud Utilization ↑
의 제번스 효과가 발생한다.
따라서 Astra 한 번의 호출이 Sol보다 몇 % 많은 HBM을 쓰는지를 계산하는 것만으로는 충분하지 않다.
실제로 중요한 것은
Memory per Agent × Agents per User × Agent Runtime
이다.
현재 Astra의 정확한 Parameter 수와 Serving Architecture는 공개되지 않았다.
그래서 직접적인 HBM 요구량은 어디까지나 추정해야 한다.
내가 현재 사용하는 중앙 가정은 대략 다음과 같다.
여기서 위 두 줄과 아래 두 줄은 의미가 완전히 다르다.
Astra라는 모델 자체가 HBM을 2배 쓰는 것이 아니다.
모델 자체의 HBM 증가폭은 대략 25~35% 정도일 수 있다.
그보다 훨씬 큰 변화는 Astra가 가능하게 만드는 Agent 사용량과 동시성의 증가에서 발생한다.
따라서 Memory 투자관점에서는 Direct Model Effect보다 Usage Elasticity가 더 중요하다.
3. 그리고 HBM의 핵심은 Capacity보다 Bandwidth로 이동한다
이전에는 GPU당 HBM 탑재용량 증가가 가장 눈에 잘 들어왔다.
H100은 80GB, H200은 141GB, Blackwell Ultra는 288GB까지 증가했다.
그런데 Blackwell Ultra에서 Rubin으로 넘어가면 조금 이상한 변화가 나타난다.
HBM 용량은 그대로인데 대역폭이 2.75배 증가한다. (NVIDIA Developer)
왜 NVIDIA는 HBM 용량을 두 배로 늘리지 않고 대역폭을 거의 세 배 가까이 높였을까.
NVIDIA도 Rubin Architecture를 설명하면서 Context가 길어지고 Interactive Inference가 증가할수록 실제 Memory Performance가 전체 시스템 효율을 지배하는 요소가 된다고 설명한다. (NVIDIA Developer)
결국 문제는 저장공간만이 아니다.
Model Weight와 KV Cache를 아무리 많이 HBM에 넣어놔도 이를 Tensor Core에 충분히 빠르게 공급하지 못하면 연산기는 기다려야 한다.
HBM Capacity = 창고의 크기
HBM Bandwidth = 창고와 공장 사이 컨베이어의 속도
라고 생각하면 이해하기 쉽다.
AI GPU의 생산라인은 엄청난 속도로 빨라졌는데, 원재료를 공급하는 컨베이어가 그 속도를 따라가지 못하고 있는 것이다.
4. GPU Utilization과 FLOPS Utilization은 다르다
여기서 GPU 가동률이라는 표현도 조금 주의해서 사용할 필요가 있다.
GPU Utilization이 90~100%라고 표시된다고 해서 Tensor Core가 이론적 최대 FLOPS의 90~100%를 유료연산으로 전환하고 있다는 의미는 아니다.
Decode에서는 GPU에 작업이 계속 배정돼 있더라도 HBM에서 Weight와 KV Cache가 도착하기를 기다리는 시간이 존재한다.
따라서 실제로 봐야 하는 것은
Useful Model FLOPS / Peak Hardware FLOPS
에 가까운 개념이다.
이를 단순하게 MFU라고 표현하면,
FLOPS Idle = 1 - MFU
가 된다.
중요한 것은 여기서 발생하는 Idle이 단순한 서버 유휴시간과 전혀 다르다는 점이다.
전원도 들어와 있다.
GPU도 비싸게 구매했다.
전력도 소비한다.
그런데 Memory, Network, Scheduling과 Software 병목으로 인해 이론적인 연산능력 중 일부가 실제 Token 생산으로 전환되지 못한다.
말 그대로 돈을 주고 산 FLOPS가 놀고 있는 것이다.
5. H100과 H200이 보여준 Memory의 가치
이 문제를 확인하기에 H100과 H200은 상당히 좋은 자연실험이다.
두 GPU는 같은 Hopper Architecture를 사용한다.
그러나 Memory가 크게 달라졌다.
NVIDIA의 MLPerf 결과에서 동일한 700W 조건의 H200은 Llama 2 70B 추론에서 H100보다 최대 28% 높은 성능을 기록했다. (NVIDIA Developer)
NVIDIA가 설명한 이유도 명확하다.
더 큰 HBM 덕분에 일부 Tensor/Pipeline Parallelism을 줄일 수 있었고, 더 높은 Memory Bandwidth가 Memory-bound 구간의 병목을 완화하면서 Tensor Core utilization이 개선됐다.
즉 Compute Architecture를 완전히 새로 바꾸지 않고도 Memory System을 개선하자 Token 생산량이 크게 증가했다.
이것이 HBM의 경제적 가치다.
HBM은 데이터를 보관하는 부품이 아니라 이미 구입한 GPU의 생산성을 높이는 설비다.
6. Astra에서는 FLOPS가 얼마나 놀게 될까
정확한 수치는 알 수 없다.
OpenAI는 Astra의 실제 Serving Architecture와 production fleet의 MFU를 공개하지 않았다.
따라서 여기부터는 투자모델을 위한 Scenario다.
Agentic Workload를 다음처럼 나눠볼 수 있다.
내가 현재 Base Case로 사용하는 값은 Useful FLOPS 약 **35%**다.
즉 Peak FLOPS의 약 **65%**가 매 순간 완전히 꺼져 있다는 뜻은 아니다.
Memory, Network, Sequential Decode, Expert Routing, Kernel Launch, Latency SLO 등 여러 병목 때문에 최대 연산능력이 Useful Token으로 전환되지 못하는 비중을 의미한다.
그리고 이 65%를 HBM 하나로 모두 회복할 수도 없다.
내가 현실적으로 HBM Capacity와 Bandwidth 개선에 귀속시키는 구간은 약 8~15%p다.
즉,
35% MFU
→ 43~50% MFU
정도로 올라가는 Scenario다.
별것 아닌 것처럼 보이지만 GPU 생산량으로 환산하면 상당히 크다.
43 / 35 - 1 = +23%
50 / 35 - 1 = +43%
즉 Memory System의 개선으로 GPU의 실질적인 생산량이 23~43% 증가할 수 있다.
바꿔 말하면 특정 워크로드에서는 GPU를 23~43% 더 구매하는 것과 비슷한 효과다.
7. HBM 1GB의 가치는 얼마일까
여기서부터 조금 재미있는 계산이 가능하다.
H100에서 H200으로 넘어가면서
Capacity +61GB
Bandwidth +1.45TB/s
가 동시에 증가했고, 동일 700W에서 최대 28%의 추론 성능 개선이 나타났다.
Capacity와 Bandwidth 효과를 정확하게 분리할 수는 없다.
다만 여러 세대의 변화와 Batch·KV Cache 구조를 함께 감안해 HBM Capacity가 실제 병목인 구간에서 추가 **1GB당 Goodput 약 +0.10~0.18%**를 하나의 경험적 민감도로 사용할 수 있다.
이는 공식적인 산업수치가 아니라 내가 사용하는 모델링 가정이다.
그렇다면 추가 100GB는 대략
+10~18% Goodput
의 잠재가치를 갖는다.
물론 실제 함수는 선형이 아니다.
추가 Memory가 필요 없는 Workload에서는 100GB를 더 달아도 가치가 거의 없다.
반대로 Model Weight나 KV Cache가 HBM에 간발의 차이로 들어가지 않아 GPU를 하나 더 사용해야 하는 경우에는 마지막 몇 GB가 GPU 전체 한 개를 절약할 수도 있다.
그래서 HBM Capacity의 경제적 가치는 선형보다 Threshold에 가깝다.
HBM Capacity ↑
→ Larger Batch
→ More Concurrent Agents
→ Less KV Offload
→ Less Tensor Parallelism
→ Higher GPU Goodput
이 구조다.
8. 실제 돈으로 바꾸면 숫자가 더 커진다
생각정리 325 (* Memory Premium)에서 사용했던 방식과 동일하게 계산해본다.
HBM이 만들어내는 경제적 가치를
GPU 시간당 가치
× 연간시간
× 유료가동률
× Goodput 개선
× Incremental Margin
× 사용기간 현재가치
로 생각할 수 있다.
GB300급 GPU-hour 경제가치를 약 $13, 유료가동률 70%, Incremental Margin 60%, 4년 현재가치 계수를 약 3.17로 놓으면,
GPU Goodput을 단 1% 높이는 경제적 가치는 대략 GPU당 $1,500 전후가 된다.
그렇다면 앞의 경험적 민감도인
+1GB HBM → +0.10~0.18% Goodput
을 적용할 경우,
HBM 1GB의 Marginal Economic Value는 대략
$150~270/GB
정도가 된다.
조금 넓게 잡으면 $100~300/GB 정도다.
다시 말하지만 이것은 HBM의 판매가격을 의미하지 않는다.
Cloud 사업자가 추가 HBM으로 GPU의 생산성을 높이면서 얻는 경제적 잉여의 현재가치다.
9. 그런데 Capacity보다 Bandwidth의 가치가 더 커질 수 있다
Rubin은 GPU당 22TB/s의 HBM4 Bandwidth를 제공한다.
여기서 1TB/s가 추가되면 Bandwidth가 약 4.5% 증가한다.
Memory-bound Workload에서 실제 Throughput의 Bandwidth Elasticity를 보수적으로 0.5~0.8만 적용하더라도,
추가 1TB/s
→ 약 +2.3~3.6% Goodput
정도의 가치가 생길 수 있다.
앞서 계산한 Goodput 1%당 약 $1,500을 적용하면,
HBM Bandwidth +1TB/s의 4년 경제적 가치
는 GPU당 약
$3.5K~5.5K
수준이 된다.
Astra 이후 HBM을 단순히 $/GB로 보면 안 되는 이유다.
앞으로 더 중요한 지표는
$/GB
보다
$/TB/s
일 수 있다.
10. 그래서 Rubin의 22TB/s가 중요하다
Blackwell Ultra에서 Rubin으로 넘어가면서 HBM Capacity는 288GB로 동일하지만 Bandwidth는
8TB/s
→ 22TB/s
로 2.75배 증가한다.
그런데 Compute도 동시에 크게 증가한다.
Blackwell Ultra의 Dense NVFP4 Compute가 약 15PFLOPS, Rubin의 NVFP4 inference 성능은 최대 50PFLOPS다. (NVIDIA Developer)
즉 Compute 증가속도가 Memory Bandwidth 증가속도보다 느리지 않다.
HBM Bandwidth를 거의 세 배 늘렸는데도 Tensor Core를 완전히 먹여 살리기 위해 필요한 Memory Throughput 부담은 여전히 크다.
이것이 중요하다.
HBM의 기술개선이 GPU의 연산성능을 앞서가는 것이 아니라, 급증하는 Compute를 따라가기 위해 거의 전력질주하고 있는 상황에 가깝기 때문이다.
Compute ↑↑
→ Weight/KV Traffic ↑↑
→ HBM Bandwidth ↑↑
→ 그러나 Compute/Bandwidth Ratio는 여전히 높음
→ Memory Wall 지속
따라서 GPU FLOPS가 증가하면 HBM의 중요성이 떨어지는 것이 아니다.
오히려 반대다.
비싸진 FLOPS를 놀리지 않기 위해 Memory 한 단위의 가치가 더 높아진다.
11. NVHBM을 다시 보면 의미가 달라진다
NVHBM의 기술적 구조는 이미 생각정리 355 (* HBM hegemony, NVHBM)에서 정리했으므로 반복하지 않는다.
핵심 숫자만 가져오면 NVIDIA가 표준 HBM4E 대비 제시하는 최대 효과는
Memory Bandwidth +30%
HBM Power -15%
XPU Compute Die Area +25%
다. (NVIDIA Blog)
이 수치들은 NVIDIA가 제시한 up to 기준이므로 실제 고객별 성능은 달라질 수 있다.
그럼에도 앞선 경제적 가치 계산에 넣어보면 꽤 흥미롭다.
22TB/s의 30%라면 추가 Bandwidth는 최대
6.6TB/s
다.
앞서 1TB/s의 경제적 가치를 $3.5K~5.5K/GPU로 계산했으므로 단순한 Bandwidth 효과만으로도
약 $23K~36K/GPU
의 경제적 가치가 설명된다.
여기에는 HBM Power 15% 절감이나 XPU Die 면적 확보효과는 포함하지 않았다.
결국 NVIDIA가 Memory Controller까지 HBM Base Die로 가져가려는 이유도 명확해진다.
NVHBM은 단순히 더 비싼 HBM을 만드는 기술이 아니다.
GPU와 HBM 사이에서 사라지는 FLOPS를 줄이는 기술이다.
12. HBM4 전체의 경제적 가치를 다시 계산해보면
앞선 Memory Premium에서는 Rubin Memory System의 경제적 가치를 대략 $100K~140K/GPU로 추정했다.
이번에는 조금 더 보수적으로 수정하고 싶다.
Rubin HBM4의 Capacity와 Bandwidth가 Agentic Inference의 전체 Goodput을 Blackwell Ultra 대비 약 50~70% 개선하는 데 기여한다고 가정하면,
현재 GPU-hour 경제가치를 기준으로 HBM에 귀속되는 4년 영업이익 현재가치는 대략
$80K~110K/GPU
정도가 Base Case로 적절해 보인다.
Memory-heavy Astra Workload가 예상보다 빠르게 확대될 경우
$120K~150K+
도 가능하다.
즉 기존 추정치를 폐기하는 것이 아니라
기존 $100K~140K
→ Base $80K~110K
→ Astra Bull $120K~150K+
정도로 Scenario를 조금 더 구분하는 편이 합리적이다.
13. 그러면 HBM 가격은 어디까지 올라갈 수 있을까
이전 생각정리 325 (* Memory Premium)에서 Rubin GPU당 HBM4 비용을 약 $8K~12K로 가정했다.
이를 이번에 추정한 HBM의 경제적 가치와 비교하면,
Economic Value / HBM Cost
= 대략 7~14배
가 된다.
물론 이 경제적 잉여를 Memory 업체가 전부 가져갈 수는 없다.
NVIDIA가 가져갈 몫이 있고,
TSMC와 Advanced Packaging 업체가 가져갈 몫이 있고,
Cloud가 가져갈 몫이 있고,
낮아지는 Token 가격을 통해 최종고객에게 돌아갈 몫도 있다.
그러나 Memory 업체가 전체 경제적 잉여의 일부만 가격으로 가져가더라도 현재 HBM 가격보다 훨씬 높은 가격을 시스템이 감당할 여지는 존재한다.
그래서 생각정리 325 (* Memory Premium)에서 추정했던
현실적인 HBM 가격 상단 3~5배
라는 가정을 현재도 유지한다.
이 3~5배는 Cloud가 이론적으로 감당할 수 있는 최대가격이 아니다.
실제 산업 Value Chain에서 Memory 업체가 어느 정도의 경제적 잉여를 협상력을 통해 가져갈 수 있을지에 대한 현실적인 범위에 가깝다.
14. 1GW로 확대하면 더 쉽게 보인다
AI Factory의 경제성은 이미 생각정리 358 (* The Price of Compute)에서 정리했다.
당시 고가동률의 최신 AI Cloud를 가정한 장기 정상화 매출을 약 $17B/GW/년이라는 기준으로 놓았다.
이 숫자를 다시 활용해보자.
새로운 데이터센터나 GPU를 추가하지 않고 HBM이 기존 GPU Goodput만 개선한다고 가정한다.
1GW AI Factory에서 Memory System이 Goodput을 단 10% 높이는 것만으로 약 $3B 이상의 경제적 가치가 발생할 수 있다.
20%면 $6B를 넘어간다.
1GW AI Factory의 건설비 자체를 대략 $40~60B로 봤던 것과 비교해도 무시하기 어려운 금액이다.
Cloud 사업자 입장에서는 HBM 가격이 30%, 50% 올라가는 것이 가장 큰 문제가 아니다.
더 큰 문제는
수백억 달러를 들여 설치한 GPU·Network·Power가 HBM 부족 때문에 10~20% 덜 생산적인 상태로 남는 것
이다.
15. 결국 HBM의 가격결정 방식이 달라진다
과거 DRAM의 가격은 대체로 다음과 같이 생각했다.
Cost
→ Supply/Demand
→ ASP
HBM도 Memory Commodity Cycle의 영향을 받기 때문에 이 논리가 사라지는 것은 아니다.
하지만 AI 시스템 안에서는 새로운 가격기준이 하나 추가된다.
GPU CAPEX
→ Idle FLOPS
→ Additional HBM
→ Recovered Goodput
→ Additional Tokens
→ Additional Revenue
→ Willingness to Pay
따라서 HBM의 Shadow Price는
**Avoided GPU CAPEX
Additional Token Revenue
Lower Power
Lower Network/Sharding Cost**
의 합으로 볼 수 있다.
HBM DRAM Die의 제조원가는 이 가치 가운데 일부일 뿐이다.
이 관점이 중요한 이유는 HBM의 ASP가 과거 일반 DRAM보다 훨씬 오랫동안 높은 수준을 유지할 수 있는 논리적 근거가 되기 때문이다.
16. 같은 288GB라도 가격이 달라질 수 있다
HBM4 이후에는 같은 용량의 HBM이라도 경제적 가치가 달라질 가능성이 높다.
예를 들어 둘 다 288GB라고 하더라도
Bandwidth
Pin Speed
Power
Logic Base Die
Memory Controller
PHY
Packaging
GPU/XPU와의 최적화
실제 Achieved Bandwidth
가 다르면 GPU가 생산할 수 있는 Token도 달라진다.
그래서 앞으로 HBM은 단순히
GB × $/GB
로 가격이 결정되는 제품에서
Capacity × Bandwidth × Customization × System Qualification
으로 가격이 결정되는 제품에 가까워질 수 있다.
NVHBM이 중요한 이유도 여기에 있다.
앞으로 NVIDIA GPU용 HBM, Google TPU용 HBM, AWS Trainium용 HBM, Microsoft Maia용 HBM의 가격이 동일할 이유가 점점 줄어든다.
HBM은 Commodity DRAM에서 Semi-custom System Component 쪽으로 이동할 가능성이 높다.
17. SOCAMM과 NAND가 증가해도 HBM이 대체되는 것은 아니다
Astra 이후 Persistent Context가 늘어나면 모든 정보를 비싼 HBM에 저장할 수는 없다.
그래서 Memory Hierarchy가 확장된다.
Hot Memory — HBM4
Model Weight, Active KV Cache, Decode와 Prefill
Warm Memory — SOCAMM·Server DRAM
Agent State, Context Buffer, CPU-side processing
Context Memory — CMX·eSSD
Inactive KV Cache, Shared Context, Persistent Memory
Cold Storage — NAND
Long-term Data와 Archived State
이를 HBM 대체로 이해하면 안 된다.
오히려 아래 Memory Tier가 충분히 커지면 비싼 HBM은 가장 가치 있는 Hot Working Set에 집중할 수 있다.
그 결과 HBM utilization과 GPU utilization 모두 높아진다.
즉 DRAM·NAND의 확대와 HBM 확대는 서로 경쟁하는 관계라기보다 AI Memory Hierarchy 전체가 커지는 과정에 가깝다.
18. 가장 강한 반대논리
물론 이 Thesis가 틀릴 수도 있다.
다음 기술들이 예상보다 빠르게 발전한다면 HBM의 Marginal Value는 떨어질 수 있다.
KV Cache Compression
PagedAttention
MLA·GQA
Sparse Attention
Quantization
Prefill·Decode Disaggregation
CXL Memory
Context Tiering
Memory-aware Scheduling
더 중요한 것은 Astra의 성능개선이 Model Size 확대보다 Algorithm, Harness와 Test-time Compute 개선에서 대부분 발생했을 가능성이다.
이 경우 Astra 자체의 HBM Capacity 증가폭은 예상보다 훨씬 작을 수 있다.
하지만 여기서도 한 가지를 구분해야 한다.
Memory per Task 감소
와
Total Memory Demand 감소
는 같은 이야기가 아니다.
Memory Efficiency ↑
→ Cost per Task ↓
→ Addressable Tasks ↑
→ Agent Usage ↑
→ Concurrent Workloads ↑
가 더 빠르게 나타난다면 전체 Memory 수요는 계속 증가할 수 있다.
결국 이 Thesis를 정말 훼손하는 것은 Memory Efficiency 개선 그 자체가 아니다.
앞으로 확인해야 하는 것은 세 가지다.
첫째, Astra 이후 실제 평균 Context가 늘어나는가.
둘째, 사용자당 Concurrent Agent 수가 증가하는가.
셋째, Memory Traffic의 효율화보다 Agent 업무량 증가속도가 더 빠른가.
이 세 가지를 계속 확인하면 될 것 같다.
19. HBM은 GPU의 Yield Enhancer가 된다
이전까지 HBM을 바라보는 가장 직관적인 방법은 GPU 한 개에 몇 GB가 들어가는지를 계산하는 것이었다.
앞으로는 그것만으로 부족할 가능성이 높다.
내가 현재 중요하게 보는 지표는 다음과 같다.
특히 앞으로는 HBM TB/s/GPU와 Useful FLOPS/Peak FLOPS를 같이 봐야 할 것 같다.
결국 HBM이 하는 일은 단순하다.
놀고 있는 GPU FLOPS를 다시 생산라인으로 돌려놓는다.
글을 마치며,
Astra를 보면서 처음에는 이 모델이 Sol보다 HBM을 얼마나 더 많이 사용할지가 궁금했다.
조금 더 들여다보니 그 질문 자체가 너무 좁았던 것 같다.
Astra 자체가 Sol보다 HBM을 2배 사용하는지가 중요한 것이 아니다.
Astra가 더 긴 Context를 실제 업무에 사용하고, 인간이 더 많은 업무를 Agent에게 위임하고, 여러 Agent가 동시에 수시간씩 움직이기 시작하면 AI Factory 전체의 Memory Traffic이 얼마나 증가하는지가 더 중요하다.
그리고 Compute가 증가할수록 HBM의 가치도 달라진다.
GPU FLOPS ↑
→ Memory가 공급해야 할 Data ↑
→ Memory Wall ↑
→ Idle FLOPS의 절대가치 ↑
→ HBM의 Shadow Price ↑
결국 HBM의 경제적 가치는 저장되는 Byte 자체의 가치가 아니다.
그 Byte가 되살리는 GPU FLOPS의 가치다.
이 관점에서 보면 B300에서 Rubin으로 넘어가면서 HBM Capacity가 288GB로 그대로인데 Bandwidth가 8TB/s에서 22TB/s로 2.75배 증가하는 이유도 이해된다.
NVIDIA가 NVHBM을 통해 Memory Controller를 Base Die까지 내려보내고 표준 HBM4E보다 최대 30% 높은 Bandwidth를 얻으려는 이유도 같은 맥락이다.
AI 산업에서는 Compute가 점점 비싸지는 것이 아니라 생산 가능한 Compute가 점점 귀해지고 있다.
GPU 한 개가 가진 Peak FLOPS보다 중요한 것은 실제로 몇 %의 FLOPS를 유료 Token으로 전환할 수 있느냐다.
그래서 앞으로 HBM을 단순한 Memory BOM으로 보는 것은 적절하지 않을 수도 있다.
HBM은 GPU의 Yield Enhancer에 가깝다.
더 많은 GPU를 설치하지 않고도 이미 구매한 GPU, 이미 확보한 전력, 이미 지은 데이터센터에서 더 많은 Intelligence를 생산하게 해준다.
이 구조가 맞다면 HBM의 가격 상단 역시 과거 Commodity DRAM의 원가나 역사적 Premium만으로 설명하기 어렵다.
내 현재 Base Case에서는 Rubin HBM4가 GPU당 만들어내는 경제적 가치를 약 $80K~110K, Astra와 같은 Memory-heavy Agent workload가 빠르게 확산되는 경우 $120K~150K 이상까지 열어두고 있다.
반면 현재 가정하는 HBM4의 실제 비용은 그보다 훨씬 낮다.
결국 앞으로 중요한 질문은
“HBM 가격이 얼마나 더 오를 수 있는가”
보다,
“HBM이 만들어내는 System Surplus 가운데 Memory 업체가 얼마만큼을 가격으로 가져갈 수 있는가”
에 가까울 것 같다.
생각정리 324 (* Token Empire)에서 처음 정리했던 AI Cloud의 생산성은 결국
Chip × Memory × Network × Power × Software × Utilization
의 곱으로 결정된다.
Astra 이후에는 이 식에서 Memory와 Utilization 사이의 관계가 이전보다 훨씬 중요해질 가능성이 높아 보인다.
Compute가 더 빨라질수록 Memory의 중요성이 낮아지는 것이 아니라, 그 비싼 Compute를 굶기지 않기 위해 Memory의 경제적 가치가 더 높아진다.(하루만 더 참을껄 젠~~~장~~~~~~..)
=끝
