AI 서버 메모리 병목 지도: HBM의 역할과 XPU, HBF·​HBS, CXL까지

AI 서버에서 GPU와 HBM이 각각 어떤 역할을 하는지, 메모리 대역폭이 왜 병목이 되는지 설명하고, XPU의 메모리 조합, HBF·HBS, CXL까지 메모리 계층 경쟁을 하나의 지도로 정리합니다.

이 글은 AI 인프라와 반도체 구조를 처음 이해하려는 독자를 위한 QSike Tech Notes 기술 해설입니다.

생성형 AI를 이야기할 때 가장 자주 등장하는 단어는 GPU입니다. 많은 사람이 AI 서버의 성능을 “GPU를 얼마나 많이 확보했는가”로 이해합니다. 물론 GPU는 AI 연산의 핵심입니다. 하지만 GPU만으로는 AI 서버의 성능을 온전히 설명할 수 없습니다. GPU가 아무리 빠르게 계산할 수 있어도, 필요한 데이터를 제때 읽고 쓰지 못하면 성능은 쉽게 막힙니다.

이때 중요한 부품이 HBM입니다. HBM은 High Bandwidth Memory의 약자로, 말 그대로 대역폭이 높은 메모리입니다. 쉽게 말하면 GPU 옆에 붙어 있는 매우 넓은 데이터 통로입니다. 그리고 최근에는 그 통로 옆에 어떤 기술을 더 붙일지를 두고 HBF, HBS, CXL 같은 새 용어가 잇따라 등장하고 있습니다.

참고: 이 글은 2026년 6~7월에 각각 발행된 메모리 병목 관련 글 네 편(HBM 대역폭 병목, XPU와 메모리 월, HBM·HBF·HBS 구분, 메타 Vistara와 CXL)을 하나의 가이드로 재구성했습니다.

GPU는 계산하고, HBM은 데이터를 공급한다

AI 서버에서 GPU와 HBM의 역할은 다릅니다. GPU는 계산을 담당합니다. 수많은 행렬 연산을 동시에 처리하며 모델 학습과 추론을 수행합니다. 반면 HBM은 GPU가 계산할 데이터를 빠르게 공급합니다.

AI 모델은 거대한 파라미터와 중간 계산값을 계속 읽고 써야 합니다. 이 데이터 이동이 느리면 GPU는 계산할 준비가 되어 있어도 기다리는 시간이 생깁니다.

그래서 AI 서버의 병목은 단순히 “계산 능력 부족”만이 아닙니다. 실제로는 계산 장치, 메모리 대역폭, 서버 간 네트워크, 전력, 냉각이 함께 맞물립니다. 특히 거대 언어모델처럼 많은 데이터를 반복해서 처리하는 시스템에서는 메모리 대역폭이 성능을 제한하는 중요한 요인이 됩니다.

GPU가 엔진이라면 HBM은 엔진으로 연료와 데이터를 공급하는 고속 통로입니다. 엔진만 커지고 통로가 좁으면 전체 시스템은 빨라지지 않습니다.

왜 HBM은 GPU 가까이에 붙어 있을까

일반적인 서버 메모리는 CPU나 GPU와 일정한 거리를 두고 데이터를 주고받습니다. 이 방식은 범용 서버에서는 충분히 효율적일 수 있지만, AI 가속기처럼 막대한 데이터를 짧은 시간에 반복 처리해야 하는 환경에서는 병목이 커집니다.

HBM은 여러 메모리 층을 쌓아 올리고, GPU 가까이에 배치해 매우 넓은 데이터 통로를 제공합니다. D램 칩을 수직으로 쌓고 TSV 같은 수직 연결 기술로 통로를 넓히는 구조입니다. 핵심은 “저장 공간”만이 아닙니다. 얼마나 빨리, 얼마나 많이 데이터를 GPU에 공급할 수 있는지가 중요합니다.

이 차이는 고속도로 차선 수에 비유할 수 있습니다. 같은 거리를 이동하더라도 차선이 좁으면 차량이 밀립니다. HBM은 GPU가 계속 계산할 수 있도록 더 넓은 차선을 제공하는 구조에 가깝습니다.

메모리 월: 계산이 빨라도 데이터 이동이 막힌다

컴퓨팅에서는 오래전부터 메모리 월(Memory Wall)이라는 개념이 있었습니다. 연산 장치는 계속 빨라지는데, 메모리에서 데이터를 가져오는 속도는 그만큼 빨라지지 않아 전체 성능이 막히는 현상입니다.

AI 서버에서도 같은 문제가 반복됩니다. 대규모 언어 모델을 학습하거나 답변을 생성할 때는 막대한 모델 가중치와 KV 캐시를 연산기 가까이에서 계속 읽고 써야 합니다. GPU가 대규모 병렬 연산을 빠르게 처리할 수 있어도 데이터를 충분히 빠르게 읽어오지 못하면 기다리는 시간이 늘어나고, GPU 사용률은 떨어지며, 비싼 AI 서버의 효율도 낮아집니다.

메모리 월은 작업 단계마다 조금씩 다른 얼굴로 나타납니다.

• 학습: 가중치뿐 아니라 활성값, 그래디언트와 옵티마이저 상태를 여러 가속기 사이에서 이동합니다. HBM 용량·대역폭과 칩 간 연결이 함께 병목이 됩니다.
• 프리필 추론: 긴 입력을 한꺼번에 처리하므로 계산량과 메모리 접근량이 동시에 큽니다.
• 토큰 생성: 매 단계에서 가중치와 KV 캐시를 반복해 읽기 때문에 메모리 대역폭과 캐시 관리가 중요합니다.
• 대규모 동시 서비스: 사용자마다 KV 캐시가 늘어나므로 순수 연산 성능보다 메모리 수용량과 단편화가 처리량을 제한할 수 있습니다.

그래서 벤치마크의 최고 연산 성능만 비교하면 실제 서비스 병목을 놓칠 수 있습니다. 모델 크기, 입력 길이, 동시 사용자 수와 캐시 정책까지 같은 조건으로 맞춰야 가속기의 효율을 판단할 수 있습니다.

가속기의 종류가 늘어난다: XPU와 메모리 조합

AI 서비스가 늘면서 데이터센터의 질문도 바뀌고 있습니다. “가장 빠른 GPU를 얼마나 많이 확보할까”에서 “우리 서비스에 필요한 연산을 가장 낮은 비용과 전력으로 처리할 칩은 무엇일까”로 옮겨 가는 중입니다. 이 변화의 중심에 있는 표현이 XPU입니다.

XPU는 업계에서 엄밀하게 하나로 고정된 표준 제품명이 아닙니다. JEDEC이나 IEEE가 지정한 단일 칩 분류도 아닙니다. 기사에 따라 TPU, NPU, AI ASIC과 클라우드 사업자의 자체 가속기를 묶는 편의적 표현으로 쓰입니다. 이 글에서는 XPU를 특정 AI 학습·추론·추천·에이전트 작업에 맞춘 가속기를 넓게 부르는 우산 용어로 한정합니다.

GPU는 다양한 계산을 병렬로 처리할 수 있고 CUDA 같은 소프트웨어 생태계를 갖췄습니다. 새로운 모델을 학습시키거나 워크로드가 자주 바뀌는 환경에서 유리합니다. 반면 XPU는 자주 쓰는 연산 형식, 데이터 흐름, 정밀도, 메모리 구조를 목표 작업에 맞게 덜어내고 강화합니다. 같은 일을 반복해서 처리하는 대규모 AI 서비스라면 필요한 기능에 집중해 전력과 비용을 낮출 가능성이 생깁니다. XPU는 GPU를 없애는 칩이라기보다 역할을 나누는 칩입니다.

누가 XPU를 만드는지도 설계자와 제조사로 나눠 봐야 합니다. 구글은 TPU를 학습, 추론, 강화학습용 맞춤형 가속기로 운영하고, AWS는 학습용 Trainium과 추론용 Inferentia를 서버, 네트워크, Neuron 소프트웨어와 함께 설계한다고 설명합니다. 메타의 MTIA, 마이크로소프트의 Maia 같은 자체 가속기 사례도 있고, 설계·공급망에서는 브로드컴과 마벨, 제조에서는 TSMC 같은 파운드리, 메모리에서는 삼성전자·SK하이닉스·마이크론의 역할이 결합됩니다.

메모리 관점에서 흥미로운 점은 XPU가 모두 HBM만 쓰는 것이 아니라는 것입니다. AWS 공식 설명에 따르면 1세대 Inferentia는 칩당 8GB DDR4를 사용했고, Inferentia2는 칩당 32GB HBM으로 이동했습니다. 더 무거운 생성형 AI 추론을 목표로 하면서 메모리 용량과 대역폭 요구가 함께 커진 사례입니다. 학습용 Trainium 계열 역시 HBM과 온칩 SRAM을 함께 배치합니다.

결국 워크로드가 메모리 조합을 결정합니다.

당장 GPU가 사라질 가능성은 낮습니다. GPU는 다양한 모델과 프레임워크를 빠르게 올릴 수 있는 생태계와 범용성이 강합니다. 다만 클라우드 사업자처럼 AI 수요가 크고 반복적인 회사는 자체 XPU로 비용, 전력, 공급 안정성을 직접 관리하려 합니다. 메모리 반도체 관점에서 중요한 변화는 수요의 양보다 구조입니다. “HBM을 얼마나 많이 탑재하느냐”와 함께 “어떤 가속기가 어떤 메모리 계층과 패키징 구조를 요구하느냐”가 경쟁력이 됩니다.

HBM만으로는 부족해질 때: HBF와 HBS

HBM은 빠르지만 비싸고 만들기도 어렵습니다. AI 서버가 계속 늘면 HBM 수요는 커지지만, 모든 데이터를 HBM에 담는 방식은 비용과 공급 측면에서 부담이 큽니다. 그래서 “HBM 옆에 무엇을 더 붙일 것인가”가 다음 질문이 되고, 여기서 HBF와 HBS가 나옵니다.

세 용어는 모두 넓은 데이터 통로를 지향하지만, HBM은 고속 D램, HBF는 대용량 낸드 계층, HBS는 D램과 낸드를 한 패키지에 묶는 방향에 가깝다.

• HBM: 빠른 D램. 현재 AI 서버의 주력 메모리. HBM3E를 거쳐 2026년에는 HBM4 상용 출하와 HBM4E 샘플 경쟁이 진행되고 있습니다.
• HBF: 대용량 낸드. HBM 옆에서 더 많은 데이터를 가까이 두려는 기술로, 낸드플래시를 고대역폭 구조로 만듭니다. 샌디스크와 SK하이닉스가 표준화를 추진 중이며, 보도 기준 D램 대비 용량이 8~16배 클 수 있다고 설명됩니다. 다만 지연시간은 HBM보다 불리할 가능성이 큽니다.
• HBS: D램과 낸드를 한 패키지에 적층하는 고대역폭 스토리지 개념. 주로 모바일·온디바이스 AI 맥락에서 논의되며 아직 개발 초기 단계입니다.

HBS와 자주 함께 언급되는 장기 비전이 ‘메모리 타운’입니다. 김정호 KAIST 교수가 제안한 구상으로, S램·D램·낸드가 연산기 주변에 계층적으로 붙는 구조를 상상합니다. S램은 D램보다 훨씬 빠르지만 면적을 많이 차지해 대용량으로 만들기 어렵습니다. 이 구상은 2030년대 이후의 장기 과제로 보는 것이 자연스럽고, HBS 제품 정의와 같은 개념은 아닙니다. 다만 두 이야기 모두 “메모리 계층을 더 다층적으로 쌓겠다”는 같은 방향을 가리킵니다.

도입 흐름을 정리하면 2024~2026년은 HBM3E와 HBM4 중심의 경쟁 구간이고, 공급능력, 고객사 인증, 패키징 역량이 핵심 변수입니다. 2026~2028년은 HBF 샘플과 초기 검증이 중요한 시기로, AI 서버·AI PC·엣지 AI에서 어느 정도 채택될지가 관건입니다. HBS는 모바일·온디바이스 AI 쪽에서 시장 형성을 노리는 단계입니다.

CXL: HBM을 대체하지 않는 보완 계층

메모리 가격이 오르면서 “이렇게 비싸진 메모리를 계속 새로 사야만 할까”라는 질문도 나옵니다. 메타가 ISCA 2026에서 공개한 Vistara가 그 사례입니다. Vistara는 새로운 AI 가속기나 HBM 대체 기술이 아니라, 구형 서버에서 회수한 DDR4 메모리를 CXL 2.0 기반 Type 3 메모리 확장 ASIC로 새 서버에 다시 붙이는 기술에 가깝습니다.

Vistara는 새 고속 메모리를 만드는 기술이라기보다, 버려질 수 있는 DDR4를 CXL 계층으로 다시 붙이는 데이터센터 최적화에 가깝다.

구체적인 구성도 공개됐습니다. CPU에 직접 연결된 빠른 DDR5 768GB에 Vistara 카드 두 장을 통해 재활용 DDR4 256GB를 추가해 서버 한 대의 메모리를 총 1TB로 만드는 구조입니다. 로컬 DDR5의 피크 대역폭이 초당 약 614GB 수준일 때 CXL로 연결된 DDR4 쪽은 약 76GB 수준으로 제시됩니다. 피크 대역폭 기준 약 8배 차이고, PCIe 링크를 거치므로 지연시간도 더 깁니다.

그런데도 메타는 일부 머신러닝 추론 서버에서 필요한 서버 수를 최대 25% 줄였고, 분산 캐시 서비스에서 평균 처리 지연을 29% 낮췄다고 보고했습니다. 비교 대상이 DDR5가 아니라 플래시나 원격 저장장치였기 때문입니다. 메모리가 부족하면 데이터는 더 느린 계층으로 밀려나고 모델 파라미터도 더 많은 서버에 나눠 담아야 합니다. 느린 DDR4라도 DRAM 계층에 데이터를 붙잡아 둘 수 있다면 더 큰 손실을 피할 수 있습니다.

핵심은 HBM과 CXL이 같은 문제를 푸는 기술이 아니라는 점입니다. HBM은 모델 가중치, 활성값, KV 캐시처럼 반복 접근이 많고 지연에 민감한 데이터를 연산기 가까이 두는 기술입니다. CXL은 접근 빈도가 낮은 데이터, 대용량 캐시, 추천 시스템의 거대한 임베딩 테이블처럼 “용량이 먼저 부족해지는” 워크로드를 위한 바깥쪽 계층입니다. CXL이 DRAM 공급 자체를 늘려 주는 것도 아닙니다. 새 CXL 모듈 안에도 결국 DRAM이 들어가고, 카드·전력·냉각·관리 비용이 추가됩니다. 메타 논문 기준 서버당 CXL 확장부가 약 50W의 전력을 더 씁니다.

핵심은 HBM과 CXL 중 하나를 고르는 문제가 아니다. 데이터의 접근 빈도와 지연 민감도에 따라 어느 계층에 둘지 나누는 문제가 된다.

한국 기업이 이 생태계에서 맡을 역할도 넓어집니다. 삼성전자는 CMM-D(CXL Memory Module-DDR) 제품군과 CXL 3.1 기반 차세대 모듈을, SK하이닉스는 DDR5 기반 CXL 메모리와 CXL 3.2 모듈을 준비해 왔고, 국내 팹리스 파네시아(Panmnesia)는 CXL 컨트롤러와 패브릭 스위치 설계에 집중하고 있습니다. 메모리 컨트롤러, 스위치, 페이지 배치 소프트웨어, 펌웨어와 장애 관리까지 묶어 시스템으로 제공하는 능력이 중요해집니다.

HBM은 데이터센터 비용과도 연결된다

HBM은 데이터센터와 클라우드 비용에도 연결됩니다. HBM을 탑재한 AI 가속기는 고성능이지만 비싸고, 전력 소모와 냉각 요구도 큽니다. 클라우드 사업자는 이런 서버를 대량으로 구축하기 위해 GPU, HBM, 고속 네트워크, 전력 설비, 냉각 인프라를 함께 투자해야 합니다.

결국 사용자가 생성형 AI 서비스를 사용할 때 지불하는 API 비용이나 기업의 AI 도입 비용 뒤에는 이런 물리적 인프라 비용이 숨어 있습니다. AI 서비스는 화면 안에서 작동하는 소프트웨어처럼 보이지만, 실제로는 데이터센터 안의 반도체, 전력, 냉각, 네트워크가 함께 움직이는 시스템입니다.

추론 시대에는 왜 메모리 병목이 더 잘 보이나

HBM은 학습용 서버에서만 중요한 것이 아닙니다. 생성형 AI가 실제 서비스로 확산될수록 추론 단계에서도 메모리 병목은 더 자주 드러납니다. 사용자가 질문을 보내면 모델은 이미 학습된 파라미터를 읽고, 입력 문맥을 처리하고, 답변 토큰을 순서대로 생성합니다. 이 과정에서 모델 가중치와 중간 상태를 계속 가져와야 하므로 메모리 대역폭과 용량이 모두 중요해집니다.

특히 긴 문서를 넣거나, 여러 도구를 호출하거나, 대화 이력을 길게 유지하는 서비스에서는 메모리 부담이 커집니다. 문맥이 길어질수록 저장하고 다시 참조해야 할 정보가 늘어나기 때문입니다. GPU 계산 능력이 충분해도 메모리에서 데이터를 제때 가져오지 못하면 사용자는 답변 지연으로 느끼고, 운영자는 GPU 사용률 저하와 비용 상승으로 경험합니다.

이 때문에 AI 인프라 최적화는 HBM만 많이 붙이는 방향으로 끝나지 않습니다. 모델 압축, 캐시 최적화, KV cache 관리, 배치 처리, 작은 모델과 큰 모델의 역할 분리 같은 소프트웨어 설계가 함께 필요합니다. HBM은 병목을 줄여주는 핵심 부품이지만, 전체 시스템이 데이터를 어떻게 읽고 재사용하는지가 성능을 결정합니다.

HBM 뉴스를 볼 때 헷갈리기 쉬운 지점

HBM을 단순히 “비싼 메모리”로만 이해하면 중요한 차이를 놓칩니다. 일반 서버 메모리의 핵심 질문이 용량이라면, AI 가속기 옆의 HBM은 용량과 대역폭을 동시에 봐야 합니다. 큰 모델을 올릴 수 있는지, 그리고 그 모델을 충분히 빠르게 읽어올 수 있는지가 함께 중요합니다.

또 하나의 혼동은 HBM 공급과 AI 서버 공급을 같은 것으로 보는 것입니다. HBM 칩이 충분해도 GPU와 함께 패키징하고, 서버 보드에 얹고, 데이터센터에서 안정적으로 냉각할 수 있어야 실제 AI 서버가 됩니다. 반대로 GPU가 충분해도 인증된 HBM과 패키징 용량이 부족하면 출하 속도는 제한됩니다.

“HBM 다음은 CXL이다”, “HBF가 HBM을 대체한다” 같은 대체 서사도 조심해야 합니다. 앞에서 본 것처럼 각 기술은 다른 계층의 다른 문제를 풉니다. 메모리 경쟁은 누가 한 종류의 메모리로 이기느냐가 아니라, 어떤 데이터를 어느 계층에 두느냐의 조합 설계로 이동하고 있습니다.

따라서 HBM 관련 뉴스를 볼 때는 세 가지를 구분하는 편이 좋습니다. 첫째, 메모리 업체가 HBM 칩을 얼마나 만들 수 있는가. 둘째, 그 HBM이 특정 GPU나 가속기 고객의 인증을 통과했는가. 셋째, 완성된 패키지가 서버와 데이터센터 환경에서 안정적으로 운영되는가. 이 세 단계가 모두 맞아야 HBM은 실제 AI 인프라 성능으로 이어집니다.

기업이 메모리 뉴스를 읽을 때 볼 실무 신호

기업이나 기술 독자가 HBM 뉴스를 볼 때는 단순히 “새 세대가 나왔다”는 문장보다 실제 병목이 어디에서 풀리는지를 보는 편이 좋습니다. 대역폭이 늘어나는지, 용량이 늘어나는지, 전력 효율이 좋아지는지에 따라 의미가 다릅니다. 대역폭 증가는 GPU가 더 빠르게 데이터를 읽는 데 도움이 되고, 용량 증가는 더 큰 모델이나 더 긴 문맥을 다루는 데 유리합니다. 전력 효율은 데이터센터 운영비와 냉각 부담에 연결됩니다.

또한 HBM 세대 변화가 곧바로 서비스 가격 하락으로 이어지는 것은 아닙니다. 새 메모리는 초기에는 비싸고 공급도 제한적일 수 있습니다. 고객 인증, 패키징, 서버 설계, 클라우드 배포까지 시간이 걸립니다. 그래서 기술 발표와 실제 클라우드 인스턴스 가격 사이에는 시차가 생깁니다.

AI 서비스를 도입하는 기업은 이 시차를 이해해야 합니다. 지금 당장 필요한 업무는 현재 사용 가능한 인프라 기준으로 설계하고, 장기적으로는 HBM 세대 변화와 추론 최적화가 비용을 낮출 가능성을 함께 봐야 합니다. HBM은 미래 비용을 낮출 수 있는 기술이지만, 그 효과는 서버와 소프트웨어가 함께 최적화될 때 나타납니다.

정리: 병목은 하나가 아니라 계층으로 움직인다

AI 서버를 이해하려면 GPU만 보면 부족합니다. GPU는 계산을 담당하지만, HBM은 그 계산이 멈추지 않도록 데이터를 공급합니다. 학습과 추론, 토큰 생성과 동시 서비스에서 메모리 병목은 서로 다른 모습으로 나타나고, 워크로드마다 필요한 메모리 조합도 달라집니다.

그래서 앞으로의 메모리 경쟁은 “누가 HBM을 대체하느냐”가 아닙니다. 어떤 데이터는 HBM에 두고, 더 큰 데이터는 HBF 같은 대용량 계층에 두고, 용량이 부족한 서버는 CXL로 보완하고, 모바일 기기는 HBS로 공간을 아끼는 식으로 계층이 나뉩니다. 메모리 반도체는 단품 공급을 넘어 대역폭·전력·용량·첨단 패키징을 함께 맞추는 시스템 경쟁으로 들어가고 있습니다.

AI 인프라 경쟁은 이제 단순히 더 많은 메모리를 사는 단계에서, 여러 종류의 메모리를 어떻게 나눠 쓰느냐의 단계로 넘어가고 있습니다. 생성형 AI를 더 깊게 이해하려면 “어떤 모델이 더 똑똑한가”뿐 아니라, 그 모델을 움직이는 서버 안에서 데이터가 어떻게 흐르는지도 함께 봐야 합니다.

이 글은 AI 인프라와 반도체 기술 구조를 쉽게 이해하기 위해 작성된 기술 해설입니다. 특정 기업이나 제품의 성능을 보증하지 않으며, 기술 개념 학습 목적으로 읽어주시기 바랍니다.

다음에 읽을 글

메모리 병목이 계층으로 나뉜다는 점을 이해했다면, 다음에는 HBM이 GPU와 어떻게 하나의 패키지로 묶이는지 보면 좋습니다. AI 가속기의 다음 병목: HBM 스택과 첨단 패키징 이해하기는 HBM 스택 제작과 GPU-HBM 통합 패키징의 차이를 설명합니다.

체크포인트

• GPU 계산 성능과 HBM 대역폭을 따로 보지 않고 함께 보고 있는가
• 학습, 프리필, 토큰 생성, 동시 서비스에서 메모리 병목이 다르게 나타나는지 이해했는가
• XPU가 워크로드에 따라 메모리 조합을 다르게 설계한다는 점을 확인했는가
• HBM, HBF, HBS가 같은 역할이 아니라 계층과 용도가 다르다는 점을 구분했는가
• CXL이 DRAM 공급을 늘리는 기술이 아니라 활용률을 높이는 보완 계층이라는 점을 확인했는가
• 메모리 병목이 추론 지연과 클라우드 비용으로 이어지는 경로를 이해했는가

확인한 출처 / 근거

• NVIDIA H100 Tensor Core GPU — HBM 용량·대역폭이 가속기 핵심 사양이라는 제품 사례.
• AMD Instinct MI300X — 대규모 모델에서 HBM 용량과 대역폭의 역할.
• Samsung Semiconductor, HBM — HBM 적층 구조와 AI·HPC 적용 배경.
• Google Cloud TPU 공식 페이지 — AI 워크로드용 맞춤형 가속기.
• AWS Trainium 공식 페이지 — 대규모 AI 학습용 purpose-built 칩.
• AWS Inferentia 공식 페이지 — 딥러닝·생성형 AI 추론용 칩.
• 연합뉴스, 「[테크톡노트] AI칩 시장서 GPU 독주 흔들리나…XPU 확장 주목」 — XPU 확산과 GPU 시장 변화를 다룬 배경 보도.
• Semiconductor Engineering, “AI Inference Needs A Mix-And-Match Memory Strategy” — 추론 서비스에서 메모리 계층을 혼합해 설계해야 하는 배경.
• TrendForce, “Memory Wall Bottleneck: AI Compute Sparks Memory Supercycle” — AI 수요 증가와 메모리 대역폭 병목 개요.
• SK hynix, SK hynix and Sandisk begin global standardization of HBF — HBF 공동 표준화와 AI 추론용 대용량 메모리 방향을 설명한 공식 발표.
• Sandisk, Memory-Centric AI — HBF가 HBM을 보완하는 계층으로 제안된 배경을 설명한 회사 자료.
• Sandisk, HBF Fact Sheet — 구조·용량·대역폭 목표를 정리한 공식 자료(PDF).
• Semiconductor Engineering, Flash Getting Stacked: High-Bandwidth Version — NAND 적층과 넓은 인터페이스를 이용하는 HBF 구조를 다룬 기술 기사.
• EE Times, NAND Reimagined in High-Bandwidth Flash to Complement HBM — HBF와 HBM의 보완 관계를 다룬 기술 기사.
• Samsung Newsroom, Samsung ships industry-first commercial HBM4 — HBM4 상용 출하에 관한 공식 발표.
• Samsung Newsroom, Samsung begins shipment of HBM4E samples — HBM4E 샘플 출하에 관한 공식 발표.
• TrendForce, SK hynix reportedly explores High Bandwidth Storage stacking NAND and DRAM — HBS의 D램+낸드 적층 구상을 전하는 보도.
• Vistara 논문: “Vistara: Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment.” ISCA 2026 Industry Session, June 29, 2026. 논문 PDF — CXL 확장 구성과 배치 결과의 1차 출처.
• Panmnesia, “Panmnesia Presents Silicon-Proven CXL 3.2 Controller and Switch at ISCA 2026” — 논문과 실리콘 검증 결과에 관한 공식 기술 개요.
• The Register, “Zuck saves Meta bucks by reusing memory from old servers with a custom CXL ASIC” — Vistara의 실제 배치 맥락.
• Tom’s Hardware, “Meta fights soaring hardware costs by reusing old DDR4 server memory” — DDR4 재사용 구조의 교차 확인.
• Blocks & Files, “Panmnesia boosts CXL scale with fabric switching. Meta repurposes old DRAM with CXL” — 두 ISCA 발표의 비교 보도.
• ISCA 2026 발표 영상 — Vistara 발표 원문 영상.