오래 일하는 AI는 HBM 의존과 HBM 절약을 함께 키웁니다

Astra 같은 장기 업무 모델의 발전은 HBM의 경제적 중요성을 높이는 방향입니다. 다만 그 힘은 최전선 모델의 학습과, 큰 모델이 빠르게 답을 생성하는 구간에 집중됩니다. 장기 업무의 모든 기억과 모든 추론에 HBM이 대체 불가능해진다는 주장은 성립하지 않습니다.

더 많은 일을 맡는 AI에는 큰 모델, 긴 문맥, 여러 실행 경로와 검증이 필요할 수 있습니다. 동시에 서비스 제공자는 자주 쓰지 않는 상태를 비싼 메모리 밖으로 옮기고, 특정 계산을 SRAM 기반 장치에 배분하며, 모델과 캐시를 압축할 이유가 커집니다. HBM을 더 필요로 하는 힘과 HBM을 아끼는 기술의 가치가 함께 커지는 구조입니다.

이 판단은 2026년 9월 6일까지 확인한 공식 발표와 공개 연구에 근거합니다. Astra의 실제 모델 크기, 내부 구조, 학습 장비 구성, 요청당 HBM 사용량은 검토한 공개 자료로 확인하지 못했습니다. 아래 내용은 Astra의 비공개 설계도를 추정한 것이 아니라, 장기 업무 모델이 요구하는 계산을 공개된 구현과 대조한 산업 분석입니다. 종목별 거래 판단은 다루지 않습니다.

‘더 많이 팔린다’와 ‘다른 것으로 못 바꾼다’는 다른 주장입니다

HBM은 여러 DRAM 칩을 쌓고 연산 장치 가까이에 연결해, 큰 용량과 넓은 데이터 통로를 함께 제공하는 메모리입니다. 여기서 대역폭은 초당 옮길 수 있는 데이터의 양이고, 지연시간은 요청한 데이터가 도착하기까지 걸리는 시간입니다. 대역폭이 높다는 이유만으로 모든 접근의 지연시간이 가장 짧은 것은 아닙니다. 칩 내부의 SRAM, 일반 시스템 DRAM, 저장장치는 서로 다른 비용과 성능 조합을 가집니다. [3][4][19]

HBM의 ‘대체불가능성’을 검증할 때는 동일한 모델 품질, 응답시간, 동시 사용자 수, 전력과 총비용에서 바꾸기 어려운가를 물어야 합니다. 아주 많은 칩과 전력을 쓰면 구현할 수 있는 것과, 고객이 받아들일 비용으로 구현할 수 있는 것은 다릅니다.

서로 혼동하기 쉬운 주장도 분리해야 합니다. AI가 처리하는 전체 업무가 늘어나는 것, 한 업무가 사용하는 HBM이 늘어나는 것, 전체 AI 메모리 중 HBM의 비중이 높아지는 것, HBM 공급자의 이익이 늘어나는 것은 각각 다른 경로로 결정됩니다. 전체 기억에서 HBM의 비중이 내려가면서도 HBM 사용량은 늘 수 있고, 사용량이 늘어도 공급 증설과 가격 경쟁으로 이익은 기대에 못 미칠 수 있습니다.

따라서 가장 강하게 지지할 수 있는 가설은 ‘모든 메모리가 HBM으로 수렴한다’가 아닙니다. 큰 작업 집합을 높은 대역폭으로 반복해서 읽고 쓰는 구간에서 HBM의 가치가 유지되고, 그 구간의 경제적 규모가 커질 가능성이 높다는 것입니다. 얼마나 커지는지는 효율 개선과 실제 업무 수요를 함께 봐야 합니다.

장기 업무는 하나의 연속된 GPU 계산이 아닙니다

보고서를 만들고 프로그램을 수정하는 에이전트는 입력을 읽고, 다음 행동을 생성하고, 외부 도구의 결과를 기다리고, 결과를 검증합니다. 이 과정에서 모델의 계산, 프로그램 실행, 파일 저장과 대기가 번갈아 나타납니다. NVIDIA가 공개한 Vera Rubin 구성도 GPU뿐 아니라 CPU 실행 환경, SRAM 기반 추론 장치, 문맥 저장장치를 따로 둡니다. [7]

한 시간 동안 실행된 에이전트가 한 시간 내내 전용 GPU와 HBM을 점유해야 하는 것은 아닙니다. 검색 결과나 코드 테스트를 기다리는 동안 다른 요청에 계산 자원을 배분할 수 있습니다. 상태를 외부로 옮겼다가 복원하는 데 드는 시간이 허용되는지가 관건입니다.

반대로 화면에 보이는 답변이 짧다고 계산과 메모리 사용량도 작다고 판단할 수 없습니다. 내부 추론, 도구 입력, 검색 문서, 후보 경로와 결과 검사까지 포함해야 합니다. OpenAI는 Astra의 도구 사용 외부 추론에 감시를 적용하며 상당한 계산 비용이 발생한다고 밝혔지만, 그중 HBM 비용의 비중은 공개하지 않았습니다. [2]

업무 구간	주로 다루는 데이터	HBM 의존에 대한 판단
사전학습·지도학습의 가중치 갱신	가중치, 기울기, 최적화 상태, 중간 계산값	큰 용량과 데이터 이동이 중요합니다. 다만 계산량이나 장비 간 통신이 먼저 병목일 수 있습니다.
강화학습의 실행 경로 생성	모델 가중치, 각 실행의 추론 캐시	긴 출력과 여러 동시 실행은 추론형 메모리 부담을 키울 수 있습니다.
강화학습의 가중치 갱신	실행 기록과 보상, 학습용 상태	학습용 HBM의 중요성이 유지됩니다. 경로 전체를 항상 HBM에 보관하는 것은 아닙니다.
입력 읽기, 프리필	새 입력과 기존 문맥	입력을 병렬 처리하므로 연산 처리량이 중요할 수 있습니다.
다음 토큰 생성, 디코드	활성 가중치와 문맥 캐시	작은 배치와 긴 문맥에서는 메모리 대역폭·용량·응답시간의 제약이 강해집니다.
도구 실행·승인 대기	프로그램 상태, 재개용 정보	CPU·시스템 메모리·저장장치로 처리할 여지가 큽니다.
완료 기록·장기 기억	원문, 결과물, 승인·변경 이력	영속 저장의 문제입니다. 추론 캐시와 같은 것으로 취급하면 안 됩니다.

표는 공개된 학습·추론 구조를 바탕으로 한 일반화이며, 개별 모델의 병목을 측정한 결과는 아닙니다. [3][5][6][7][8]

강화학습은 ‘학습 중에 추론을 많이 하는’ 수요를 만듭니다

장기 업무 능력을 강화학습으로 높이려면 모델이 여러 행동을 해 보고, 결과를 평가받고, 그 경험을 가중치 갱신에 반영해야 합니다. 실행 경로를 만드는 단계는 추론에 가깝고, 정책을 갱신하는 단계는 학습에 가깝습니다. Google의 Ironwood 설명도 이 두 종류의 작업을 구분합니다. [11]

이 차이는 HBM에 중요합니다. 학습을 모두 거대한 행렬곱으로만 보면 연산 성능을 중심으로 생각하기 쉽습니다. 그러나 긴 행동 경로를 반복해서 생성하는 비중이 커지면, 다음 토큰을 순서대로 만들고 많은 문맥 상태를 유지하는 작업의 비중도 커집니다. 추론 단계의 메모리 효율이 실제 서비스 원가뿐 아니라 학습 경험을 생산하는 원가에도 영향을 미칩니다.

2026년 7월 공개된 WAR 연구는 연구진이 다룬 동기식 에이전트 강화학습에서 긴 실행 경로 생성이 주요 병목이 됨을 보고합니다. 수만 토큰에 이르는 경로에서는 디코딩 자체와 작업 배분을 함께 최적화해야 한다는 문제의식입니다. 이것을 Astra의 실제 강화학습 원가 구성비로 옮겨 적을 수는 없지만, ‘장기 업무 학습이 추론 인프라 수요를 만든다’는 경로를 뒷받침합니다. [6]

동시에 긴 경로가 곧 메모리 사용량의 무제한 증가를 뜻하지는 않습니다. 학습 상태를 여러 장비에 나누는 ZeRO 같은 방법은 중복 저장을 줄입니다. 중간 계산값을 일부 다시 계산하거나 외부 메모리로 옮기는 방법도 용량과 계산·통신 사이의 교환입니다. 덜 저장한 대신 더 계산하거나 더 옮겨야 할 수 있습니다. [5][15]

또한 수시간의 브라우저 조작을 하나의 계산 그래프로 연결해 끝까지 역전파한다고 가정해서는 안 됩니다. 실행 기록을 생성·저장·채점하고 학습 배치로 사용하는 과정은 구분됩니다. 모든 실행 단계의 중간 계산값이 작업 종료 때까지 HBM에 남아야 한다는 설명은 일반적인 에이전트 강화학습의 필수 조건이 아닙니다. [6][11]

여기서 학습 규모를 제한하는 자원이 CPU 실행 환경, 테스트 시간, 보상 검증기나 장비 간 통신이면 HBM을 추가해도 유효한 경험의 생산 속도는 거의 늘지 않을 수 있습니다. 필요한 것은 명목 장비 수보다 단위 시간·비용당 새롭고 정확하게 채점된 경험의 양입니다. 이는 공개 구조로부터 도출한 운영상의 판단입니다.

빠른 순차 실행과 많은 동시 실행은 다른 방식으로 메모리를 압박합니다

언어모델이 출력을 생성할 때는 가중치를 읽고, 이전 문맥에 대한 중간 상태인 KV 캐시를 사용합니다. KV 캐시는 이전 토큰의 정보를 매번 처음부터 계산하지 않기 위해 보관하는 값입니다. 원문 파일이나 에이전트가 작성한 장기 메모와는 다릅니다. [3]

적은 수의 요청을 빠르게 처리할 때는 읽어 온 가중치를 여러 요청에 나눠 쓰기 어렵습니다. 여러 요청을 묶는 배치를 키우면 가중치 읽기 비용을 분담할 수 있지만, 요청별 KV 캐시가 늘고 사용자가 기다리는 시간도 고려해야 합니다. 긴 문맥의 주의집중 계산은 캐시에서 읽을 데이터 자체가 커집니다. 따라서 ‘배치를 키우면 메모리 병목이 사라진다’고 말할 수 없습니다. [3][4]

장기 업무에는 앞 단계가 끝나야 다음 단계를 시작할 수 있는 의존 관계가 많습니다. 독립적인 자료 조사 일부는 병렬화할 수 있어도, 확인한 사실을 바탕으로 수정하고 테스트하는 모든 단계를 동시에 실행할 수는 없습니다. 이 경우 빠른 토큰 생성의 가치는 단순한 대화의 쾌적함을 넘어 전체 완료시간에 누적됩니다. 다만 그 속도를 만드는 수단은 HBM만이 아니며, 뒤에서 다룰 SRAM 기반 추론도 포함됩니다.

여러 에이전트를 병렬로 돌릴 때는 공통 모델 가중치를 공유할 수 있지만 각자 다른 이력의 캐시는 별도로 필요할 수 있습니다. 동일한 앞부분은 공유할 여지가 있고, 경로가 갈라진 뒤의 상태는 증가합니다. PagedAttention은 이러한 캐시의 공간 낭비와 중복을 줄이는 대표적인 공개 접근입니다. 에이전트 수에 모델 전체 메모리를 그대로 곱하는 계산도, 모든 캐시가 공유된다는 계산도 틀릴 수 있습니다. [14]

긴 문맥의 용량은 모델 구조에 따라 크게 달라집니다

다음은 Astra 측정치가 아닌 가정 계산입니다. 모든 층이 전체 문맥을 사용하는 주의집중 구조이고, 층 수 80개, KV 헤드 8개, 헤드 차원 128, 캐시 값당 2바이트라고 둡니다. 그룹형 주의집중을 쓰는 대형 모델의 구조를 설명하기 위한 예시입니다. [4]

토큰당 KV 캐시
= K와 V 2개 × 80층 × 8개 헤드 × 128차원 × 2바이트
= 327,680바이트 = 320KiB

131,072토큰의 문맥 1개
= 327,680 × 131,072바이트
= 42,949,672,960바이트 = 40GiB

서로 다른 문맥 32개를 동시에 유지
= 40GiB × 32 = 1,280GiB = 1.25TiB

이 계산은 모델 가중치, 작업 공간, 할당 여유와 복제 비용을 제외합니다. 또한 131,072토큰은 정확히 128×1,024토큰이며, 128,000토큰과 다릅니다. GiB와 TiB는 각각 2의 30승·40승 바이트입니다. 예시 결과는 반올림하지 않은 정확한 값입니다.

캐시를 값당 1바이트로 저장하면 원시 데이터 용량은 이론적으로 절반이 됩니다. 그러나 실제 절감률에는 보조 정보와 구현이 영향을 주며, 장기 업무 정확도가 유지되는지도 검증해야 합니다. KV 헤드를 줄이거나, 잠재 표현으로 압축하거나, 일부 층을 다른 구조로 바꾸면 위 산식 자체가 달라집니다. 긴 문맥 길이만 보고 HBM 수요를 계산하면 모델 구조와 캐시 정책을 놓칩니다. [16][17]

HBM의 강점은 최고 속도 하나가 아니라 용량·대역폭의 조합입니다

큰 모델을 담을 용량이 부족하면 여러 장치에 나눠야 하고, 나눈 만큼 통신과 배분 문제가 생깁니다. 반대로 용량이 충분해도 데이터를 연산기에 공급하는 속도가 느리면 계산 장치가 기다립니다. HBM은 큰 작업 집합에 높은 대역폭을 제공하는 유력한 균형점입니다. [3][19]

용량이 싼 시스템 DRAM을 더 설치해도 연산 장치까지 연결하는 통로가 좁으면 HBM의 대역폭을 대신하지 못합니다. 반대로 SRAM으로 빠른 접근을 확보해도 큰 모델을 담는 데 필요한 칩과 통신의 비용을 해결해야 합니다. HBM은 이러한 양쪽 제약 사이에 있습니다. 연산 장치와 가까운 짧고 넓은 연결은 데이터 이동의 전력 부담을 낮추는 설계이기도 합니다. 다만 메모리의 에너지 효율과 서버 전체 전력 효율은 같은 지표가 아닙니다. [3][22]

이 균형은 맞춤형 AI 반도체로 옮겨 가도 사라지지 않습니다. Google은 Ironwood에 칩당 192GiB HBM3E와 7.4TB/s 대역폭을 명시했습니다. AWS는 2025년 12월 Trainium3 발표에서 칩당 144GB HBM3e와 4.9TB/s를 공개했습니다. 표기 단위는 각 회사의 표기를 유지했습니다. GPU가 자체 설계 반도체로 대체되는 것과 HBM이 대체되는 것은 다른 사건입니다. [11][12]

그러나 더 높은 대역폭이 곧 더 많은 메모리 비트를 뜻하지는 않습니다. Micron의 HBM4 제품 설명은 36GB 용량을 유지하면서 입출력 폭과 전송 속도를 높인 사례를 제공합니다. 2,048개의 입출력 통로와 스택당 2.8TB/s를 넘는 대역폭을 명시합니다. 대역폭과 용량이 같은 비율로 성장하지 않을 수 있다는 직접적인 예입니다. 제품 수치는 회사 발표 기준입니다. [19]

그 결과 HBM 산업의 성장에는 장착 용량 증가뿐 아니라 세대 전환, 인터페이스, 적층과 패키징의 난도가 관여합니다. 어느 항목이 더 비싸지고 공급자가 그 가치를 얼마나 가져가는지는 별도 문제입니다. 더 정교한 메모리가 필요하다는 기술적 설명만으로 공급자의 장기 수익성을 확정할 수 없습니다.

SRAM은 이미 ‘짧은 문맥만 가능한 대안’으로 보기 어렵습니다

HBM의 독점 가설에 대한 중요한 반례는 NVIDIA 자신의 추론 구조에서 나옵니다. 2026년 8월 24일 공개한 Groq 3 LPX 설명에는 입력 처리는 Rubin에서 하고, 이후 디코딩은 LPX가 맡는 구성과, 주의집중 계산과 전방향 신경망 계산을 두 장치에 나누는 구성이 함께 등장합니다. LPX를 작은 보조 모델로 사용해 초안을 만들고 Rubin의 큰 모델로 검증하는 구성도 있습니다. [9]

첫 번째 구성에서는 한 차례의 요청에서 입력 처리를 마친 캐시를 넘긴 뒤 LPX가 디코딩을 수행합니다. 따라서 ‘SRAM은 신경망 일부만 도울 뿐, 긴 문맥의 토큰 생성에는 언제나 HBM이 필요하다’는 주장은 너무 강합니다. 다만 입력 처리에 HBM 기반 Rubin이 들어간다면 전체 서비스가 HBM 없이 동작한다는 뜻도 아닙니다. [9]

NVIDIA는 같은 글에서 Gemma 4 31B, 10만 토큰 입력 문맥의 설정에서 Artificial Analysis가 측정한 출력 속도를 소개합니다. 이 결과는 긴 문맥에서도 SRAM 중심 디코딩이 가능한 사례이지만, Astra와 같은 품질·모델 크기·도구 사용 능력을 같은 비용으로 제공한다는 증거는 아닙니다. 공개된 특정 모델의 결과와 범용 최전선 서비스의 경제성을 구별해야 합니다. [9]

LPX 제품 설명에는 LPU당 SRAM 500MB, 랙당 LPU 256개와 SRAM 128GB가 명시돼 있습니다. 같은 랙에 DDR5 메모리 12TB도 명시돼 있으므로, SRAM 중심이라는 말을 모든 데이터를 SRAM에만 보관한다는 뜻으로 읽으면 안 됩니다. 어떤 데이터를 어디에 두는지, 필요한 칩 수와 랙 간 통신, 전력과 전체 설치 비용을 확인해야 합니다. HBM 한 칩과 SRAM 랙 전체의 대역폭 숫자만 비교하는 것도 부적절합니다. [10]

HBM에 대한 올바른 반론은 ‘SRAM이 있으니 HBM은 필요 없다’가 아닙니다. 일부 저지연 추론은 SRAM 중심 설계가 가져갈 수 있고, 따라서 HBM이 모든 디코딩을 독점한다는 가정은 버려야 한다는 것입니다. 반대로 더 큰 모델의 학습과 저장 용량, 다른 서비스 조건에서는 HBM의 경제성이 남을 수 있습니다. 어느 쪽이 이기는지는 작업과 시스템 단위의 검증 대상입니다.

쉬는 에이전트의 기억을 밖으로 옮기면 HBM을 더 생산적으로 쓸 수 있습니다

NVIDIA의 CMX 문맥 저장 구조는 GPU의 HBM, 시스템 메모리, 로컬 저장장치와 별도의 플래시 기반 계층을 구분합니다. 지금 계산에 필요한 캐시는 가까이에 두고, 재사용할 캐시는 외부에 보관했다가 미리 가져오는 방식입니다. HBM을 모든 세션의 대기실로 쓰는 대신, 실제 계산 중인 요청에 배분하려는 접근입니다. [8]

이 구조는 플래시가 HBM과 똑같은 속도로 모든 토큰의 주의집중 연산을 처리한다는 뜻이 아닙니다. 자주 재사용할 데이터를 예측해 가져오거나 재개 전에 복원해야 합니다. 캐시를 찾지 못했을 때 다시 계산하는 비용, 동시에 많은 세션이 깨어날 때의 전송 지연, 다른 사용자 데이터가 섞이지 않는지도 중요합니다.

CXL도 구분해서 봐야 합니다. CXL은 HBM과 같은 메모리 셀의 종류가 아니라 메모리 접근과 공유를 위한 연결 기술입니다. Beluga 연구는 CXL 스위치를 통해 GPU와 CPU가 큰 메모리 풀에 접근하고 KV 캐시를 관리하는 구조를 제시했습니다. 연구에서 비교한 대상은 특정 RDMA 기반 구성이지 모든 HBM 기반 추론을 대체하는 조건은 아닙니다. [13]

여기서 도출되는 판단은 HBM 밖의 메모리가 성장할수록 HBM의 필요성이 사라진다기보다, 같은 HBM으로 더 많은 활성 작업을 처리할 수 있다는 것입니다. 그러나 같은 업무량에서 필요한 HBM을 실제로 줄이는 효과도 있으므로 이를 무조건 보완재라고만 부르는 것도 부정확합니다. 업무량이 고정돼 있는지, 절감한 비용으로 서비스가 확대되는지에 따라 총수요가 달라집니다.

GDDR과 HBF는 같은 방식의 대안이 아닙니다

HBM 없이 AI 계산을 하는 GPU도 존재합니다. NVIDIA RTX PRO 6000 Blackwell Server Edition은 96GB GDDR7을 명시합니다. 이것만으로 Astra급 서비스를 같은 조건에서 대체할 수 있다는 뜻은 아니지만, 작은 모델과 다른 응답시간 조건까지 전부 HBM 시장으로 계산해서는 안 된다는 근거입니다. [18]

고대역폭 플래시인 HBF는 또 다른 방향입니다. Sandisk와 SK hynix는 2026년 8월 3일 첫 HBF 기술 규격을 공개했다고 발표했고, HBM과의 공존을 명시했습니다. 규격 발표는 의미 있는 진전이지만, 모든 추론 작업에서 실제 양산 경제성이 입증됐다는 뜻은 아닙니다. [20]

플래시 기반 대안을 평가할 때는 읽기 위주로 유지되는 모델 가중치와, 세션마다 늘고 재사용되는 추론 상태를 나눠야 합니다. 쓰기 빈도, 접근 단위, 지연시간과 내구성 요구가 다르기 때문입니다. 특히 높은 순차 읽기 대역폭만 보고 작은 단위의 반복 접근과 쓰기까지 같은 성능일 것이라 가정하면 안 됩니다. 필요한 검증 항목이지 특정 제품의 실패를 예단하는 주장은 아닙니다.

대안	줄일 수 있는 HBM 사용	별도로 확인할 조건
SRAM 중심 추론	특정 모델의 디코딩 또는 일부 계산	전체 작업 집합, 칩·랙 수, 통신, 전력, 동일 품질의 비용
GDDR 기반 가속기	HBM이 과한 모델·서비스의 배치	요구 대역폭과 지연시간을 실제로 충족하는지
시스템 DRAM·CXL 풀	대기·공유 캐시와 일부 외부 상태	복원 시간, 연결 병목, 캐시가 없는 요청의 지연
SSD·문맥 저장 계층	사용하지 않는 캐시의 장기 점유	미리 가져오기 적중률, 재계산 비용, 장애 복구
HBF	읽기 중심의 큰 데이터 배치 후보	규격과 제품 단계, 읽기·쓰기 특성, 시스템 비용
캐시 압축·모델 구조 변경	토큰당 저장량과 데이터 이동량	업무 정확도, 재학습 필요성, 실제 메모리 절감률

이 표는 현재의 가능 영역을 구분한 것이며 모든 대안의 상용 성숙도나 대체 범위가 같다는 의미는 아닙니다. [9][13][16][17][18][20]

모델 구조가 바뀌면 토큰당 HBM 부담도 바뀝니다

캐시의 빈 공간과 중복을 줄이는 것, 숫자의 정밀도를 낮추는 것, 문맥을 요약해 버리는 것, 신경망 구조 자체를 바꾸는 것은 서로 다른 선택입니다. 메모리를 절약한다는 이유로 모두 같은 최적화라고 묶으면 정확도 위험을 놓칩니다.

PagedAttention 같은 관리 기법은 캐시 배치의 낭비를 줄입니다. 동일한 모델·입력·위치 조건에서 같은 앞부분을 재사용하는 것은 계산의 반복을 줄일 수 있습니다. 반면 양자화, 토큰 제거와 문맥 요약은 수치나 정보를 바꾸므로 장기 업무의 결과가 달라질 수 있습니다. 회사 이름 하나나 예외 조항 하나를 잃은 뒤 수십 단계가 진행되면 마지막 답안만 보아서는 오류의 원인을 찾기 어렵습니다. [14]

모델 구조에서 캐시를 줄이는 접근도 이미 공개돼 있습니다. DeepSeek-V3의 잠재 주의집중 구조는 KV 표현을 압축합니다. Kimi Linear는 선형 구조와 주의집중을 결합하며, 해당 보고서의 설정에서 KV 캐시를 최대 75% 줄였다고 주장합니다. 이는 각 구조와 비교 조건에 속하는 결과이지, Astra의 캐시도 같은 비율로 줄일 수 있다는 증거는 아닙니다. [16][17]

전문가 혼합 구조도 단순하게 보면 안 됩니다. DeepSeek-V3는 전체 매개변수 6,710억 개 중 토큰당 370억 개를 활성화한다고 설명합니다. 매번 계산하는 부분이 적어도 전체 가중치의 저장·배치 문제는 남습니다. 다만 모든 전문가를 언제나 같은 가속기의 HBM에 보관해야 하는 것도 아닙니다. 일부를 외부에 두면 적재 지연과 적중률, 장치 사이의 통신이 새 제약이 됩니다. [16]

효율 개선이 HBM 수요를 줄이는 방향이라는 점은 인정해야 합니다. ‘절약하면 반드시 더 많이 쓰게 된다’는 반론도 자동으로 성립하지 않습니다. 비용 하락 뒤 새로운 업무의 채택이 얼마나 늘어나는지 관측해야 합니다. 더 나은 모델이 재시도와 불필요한 추론을 줄여 같은 업무를 더 적은 자원으로 끝내는 경우도 포함해야 합니다.

실제로 OpenAI의 Astra 발표에는 OSWorld 2.0 지연시간 모의실험에서 성능을 높이면서 완료시간을 줄였다는 결과가 있습니다. 이 회사 보고가 HBM 절감을 직접 증명하지는 않지만, 장기 업무 능력 향상을 ‘같은 일을 더 오래 생각한다’와 동일시해서는 안 된다는 반례는 됩니다. [1]

HBM 수요는 토큰 수보다 활성 상태와 시간으로 연결해야 합니다

운영 측정에 유용한 출발점은 다음과 같습니다. 이는 시장 규모 예측식이 아니라 시스템 비교를 위한 제안입니다.

업무 완료 한 건당 HBM 점유량·시간
= 측정 기간 전체 HBM 할당 용량의 시간 적분
  ÷ 품질·권한 기준을 통과한 완료 건수

단위 예: GiB·초 / 검증된 완료 1건

여기에는 실패한 시도와 재시도의 점유도 포함해야 합니다. 공통 가중치를 여러 요청이 쓰면 요청 수만큼 중복 계산하지 않고 서비스 전체에서 한 번 집계합니다. 캐시만 줄여 놓고 전체 모델의 상주 비용을 제외하면 경제성이 과장됩니다.

이 지표로도 설치해야 할 HBM 용량이 바로 계산되지는 않습니다. 가장 바쁜 시점의 동시성, 장애에 대비한 여유와 가동률이 필요합니다. 또한 같은 용량·시간을 쓰더라도 데이터를 훨씬 자주 읽는 모델은 더 높은 대역폭이 필요할 수 있습니다. 용량 점유, 메모리 전송량, 완료시간을 함께 측정해야 합니다.

단순한 가정으로 완료 업무가 10배로 늘고 한 건당 HBM 점유량·시간이 기존의 40%로 줄면, 전체 점유량·시간은 10 × 0.4 = 4배가 됩니다. 이것이 ‘전체 기억에서 HBM의 비중은 낮아지지만 HBM 수요는 늘어나는’ 상황입니다. 다만 설치 비트 수, 출하량이나 공급자의 매출이 반드시 4배라는 뜻은 아닙니다. 대역폭 향상과 가동률, 가격을 따로 계산해야 합니다.

서비스 구성이 바뀌는 방향에 따라 판단도 달라집니다.

앞으로 확대되는 업무	HBM에 유리한 요인	수요 증가를 낮추는 요인
최전선 모델의 학습·강화학습	큰 학습 상태, 많은 실행 경로, 빠른 반복 필요	경험 생성·채점 병목, 학습·서빙 효율 개선
빠른 응답이 필요한 복잡한 에이전트	큰 활성 상태, 긴 문맥, 순차 실행 지연의 누적	SRAM 디코딩, 혼합 배치, 캐시 압축
오래 대기하는 비동기 사무 업무	재개 시 계산 수요, 동시 사용자 증가	대기 상태 외부 저장, 배치 처리, 낮은 GPU 점유율
좁은 업무의 소형·증류 모델	사용자 수 증가에 따른 총계산 확대	GDDR·SRAM 등 비HBM 구성의 경제성

각 행의 순효과는 아직 숫자로 확정할 수 없습니다. 특히 Astra의 채택량과 실제 자원 사용을 공개 자료만으로 연결한 수요 추정치는 이 분석에 포함하지 않았습니다.

VC의 기회는 HBM의 독점보다 병목을 줄이는 위치에 있습니다

HBM 관련 제조·패키징 기업에는 대역폭과 적층 난도 상승이 기회가 될 수 있습니다. 실제 경쟁력은 고객 인증, 수율, 열 관리, 테스트 시간과 생산 확장 능력으로 확인해야 합니다. Micron의 2026년 3월 발표는 36GB 12단 HBM4의 양산과 48GB 16단 제품의 샘플 단계를 구분합니다. 서로 다른 개발 단계를 모두 확정된 매출로 취급하면 안 됩니다. [21]

추론 반도체와 컴파일러 기업은 특정 작업에서 필요한 전체 비용을 줄이는지가 중요합니다. SRAM의 최고 대역폭이나 작은 모델의 최고 출력 속도만으로는 충분하지 않습니다. 고객이 쓰는 모델 크기, 긴 문맥, 실제 동시성에서 전체 시스템 비용을 줄이는지 확인해야 합니다. 새 모델 구조에 맞추는 시간과 소프트웨어 유지 비용도 제품 경쟁력의 일부입니다.

메모리 관리 소프트웨어에는 활성 캐시 배치, 공유, 압축과 복원이라는 수요가 있습니다. 그러나 NVIDIA가 문맥 저장과 작업 배분을 직접 제품화하고 있으므로, 범용 기능 하나가 곧 독립적인 회사의 방어력이라고 보기는 어렵습니다. 여러 공급자의 장비를 묶는 능력, 고객의 실제 요청 패턴, 보안·장애 복구와 지속적인 원가 절감이 남는지 봐야 합니다. [7][8]

강화학습 인프라에서는 GPU 사용량을 늘리는 제품보다 유효한 경험을 더 빨리 만드는 제품이 더 중요할 수도 있습니다. 실행 환경 재현, 느린 테스트 제거, 정확한 자동 채점과 실패 복구가 병목이면 메모리만 늘려서는 해결되지 않습니다. 이런 기업을 HBM의 경쟁자라고 부르기보다 전체 학습 시스템에서 어느 비용과 지연을 줄이는지 평가하는 편이 정확합니다.

실사에서 요구할 비교표는 다음처럼 구성하는 것이 타당합니다. 이는 개별 기업에 대한 결론이 아닌 검증 기준입니다.

확인할 항목	충분하지 않은 지표	필요한 비교
업무 품질	짧은 답안 점수, 평균 정확도	새로운 장기 과제의 완료율, 복구, 권한 준수
응답과 재개	평균 토큰 생성 속도	첫 응답·토큰 간 지연, 느린 1% 요청, 캐시 없는 재개
자원 효율	피크 대역폭, 캐시 한 종류의 절감률	전체 HBM 용량·시간, 전송량, 연산·환경 대기 비중
총비용	칩 1개의 가격, 토큰 단가	칩·서버·네트워크·전력·운영을 포함한 완료당 비용
확장성	한 모델·한 사용자 시연	다중 사용자, 여러 모델, 긴 문맥과 동시 복원
지속 가능성	기능 목록, 규격 발표	고객 배포, 재계약, 새 모델 지원, 플랫폼 기본 기능과의 차이

HBM 공급자의 가격·수익성 판단에는 이 표만으로 부족합니다. 실제 주문, 고객 인증, 생산능력, 수율, 계약과 경쟁사 공급까지 별도로 확인해야 합니다. 장기 업무 AI의 성장이라는 설명은 그 조사를 대신하지 못합니다.

강화되는 것은 조건부 필수성이지 영구적인 독점이 아닙니다

현재 공개 근거에서 HBM에 가장 우호적인 해석은 최전선 학습, 강화학습의 대규모 실행 생성, 큰 모델의 높은 처리량과 빠른 응답에서 용량·대역폭을 함께 제공하는 역할이 중요해진다는 것입니다. 이 영역에서는 저렴한 대체 메모리가 있다는 이유만으로 쉽게 바꾸기 어렵습니다.

반면 모든 토큰 생성에 HBM이 필수라는 주장은 SRAM 중심 디코딩 사례와 맞지 않습니다. 장기 세션의 모든 상태를 HBM에 남겨야 한다는 주장도 문맥 저장과 CXL 메모리 풀의 발전을 설명하지 못합니다. AI의 총기억량, HBM 사용량과 HBM 공급자의 이익을 하나의 숫자로 연결하는 계산은 피해야 합니다.

이 판단을 낮춰야 하는 조건도 명확합니다. 비HBM 구성이 같은 최전선 모델 품질, 긴 문맥, 응답시간과 동시성에서 더 낮은 전체 비용을 반복적으로 보여주거나, 업무 증가보다 완료당 HBM 부담이 더 빠르게 줄어들면 HBM의 강한 수요 가설을 수정해야 합니다. 반대로 이런 대안이 작은 모델과 제한된 설정에 머물고 활성 작업 규모가 계속 커지면 HBM의 경제적 필수성은 더 강해집니다.

자본을 배분할 때는 ‘HBM을 대체하는가’라는 이분법보다, 같은 품질의 업무를 끝내는 데 어떤 데이터 이동과 어떤 자원 점유를 얼마나 줄였는지를 확인해야 합니다. HBM의 중요성이 높아지는 시장에서도 HBM을 절약하는 기업은 좋은 사업을 만들 수 있습니다.

---

출처와 검증 범위

공개 자료 확인 기준일은 2026년 9월 6일입니다. 회사 성능 수치는 해당 회사가 공개한 조건의 결과로 다뤘으며, 별도의 하드웨어 재현 실험은 수행하지 않았습니다. 논문, 규격 발표, 제품 사양과 양산 발표를 구분했습니다. 아래의 공개 자료만 사용했고 비공개 투자·고객 자료는 사용하지 않았습니다.

1. OpenAI, GPT-6 Astra 공식 발표, 2026년 9월 3일. 학습 설명과 전문 업무 성능, OSWorld 지연시간 모의실험.

2. OpenAI, Safety overview: GPT-6 Astra, 2026년 9월 3일. 도구 사용 추론의 감시와 추가 계산 비용.

3. How to Scale Your Model, All About Inference. 모델 가중치·KV 캐시, 입력 처리와 출력 생성, 배치의 비용 구조.

4. How to Scale Your Model, Applied Inference. 대형 모델의 구조와 KV 산식. 본문의 40GiB 사례는 명시한 2바이트 가정으로 직접 계산했습니다.

5. How to Scale Your Model, All About Training. 학습용 상태, 중간 계산값과 병렬화.

6. Xu 외, WAR: Workload-Aware Rollouts for Synchronous Agentic Reinforcement Learning, 2026년 7월 19일 최초 제출. 긴 실행 경로 생성의 병목.

7. NVIDIA, Vera Rubin Pod: Seven Chips, Five Rack-Scale Systems, One AI Supercomputer, 2026년 3월 16일. GPU·CPU·SRAM·문맥 저장 계층의 결합.

8. NVIDIA, BlueField-4-Powered Inference Context Memory Storage Platform. HBM·시스템 메모리·플래시의 역할과 캐시 이동.

9. NVIDIA, How Groq 3 LPX Unlocks Ultrafast Interactivity at Long Context, 2026년 8월 24일. 입력·출력 분리, 주의집중·신경망 분리, 초안 생성 구성과 Gemma 4 31B 사례.

10. NVIDIA, Groq 3 LPX 제품 설명, 2026년 9월 6일 확인. LPU와 랙의 SRAM 용량.

11. Google Cloud, From Silicon to Softmax: Inside the Ironwood AI Stack, 2025년 11월 6일. HBM 사양과 강화학습 작업 구분.

12. AWS, Amazon EC2 Trn3 UltraServers, 2025년 12월 2일. Trainium3 HBM 사양과 서비스 출시.

13. Yang 외, Beluga: A CXL-Based Memory Architecture for Scalable and Efficient LLM KVCache Management, 2025년 11월 25일 최초 제출, 27일 개정. CXL 공유 메모리와 캐시 관리, SIGMOD 2026 채택 표기.

14. Kwon 외, Efficient Memory Management for Large Language Model Serving with PagedAttention, 2023년 9월. 캐시 공간 낭비와 중복 감소.

15. Rajbhandari 외, ZeRO: Memory Optimizations Toward Training Trillion Parameter Models, 2019년 10월. 학습 상태의 분할과 중복 저장 감소.

16. DeepSeek, DeepSeek-V3 Technical Report, 2024년 12월. 전문가 혼합, 활성 매개변수와 잠재 주의집중 구조의 공개 사례. 2026년의 최신 모델이라는 뜻은 아닙니다.

17. Kimi, Kimi Linear: An Expressive, Efficient Attention Architecture, 2025년 10월. 혼합형 구조와 보고서 조건에서의 KV 캐시 감소.

18. NVIDIA, RTX PRO 6000 Blackwell Server Edition, 2026년 9월 6일 확인. GDDR7 기반 가속기의 공개 사례.

19. Micron, HBM4 제품 설명, 2026년 9월 6일 확인. 36GB 용량, 인터페이스와 대역폭.

20. Sandisk·SK hynix, HBF 세계 표준화 진전 발표, 2026년 8월 3일. 첫 기술 규격과 HBM 공존 방향.

21. Micron, HBM4 양산 발표, 2026년 3월 16일. 36GB 12단 양산과 48GB 16단 샘플의 구분.

22. Micron, High-bandwidth memory, 2026년 9월 6일 확인. 넓은 인터페이스, 가까운 패키징과 데이터 전송 에너지에 대한 제품 설명.

관련 글: GPT Astra의 장기 업무 역량, 추격 장벽은 모델 밖에도 있습니다.