SK Hynix와 SanDisk가 HBF (High Bandwidth Flash) 명세 발표: GPU와 공동 패키징된 512 GiB 플래시 캐시로 AI 추론의 메모리 병목 해결, Google 및 Tenstorrent의 지지

제공해주신 텍스트는 이미 영어로 작성되어 있습니다(기계 번역으로 읽힐 수 있음). 모든 기술 용어, 숫자 및 조직 이름을 보존하면서 다듬고 전문적인 영어로 정제하겠습니다:

---

HBM은 GPU 옆에 저장 매체를 적층하고 함께 패키징함으로써 AI 연산에서의 데이터 이동 병목 현상을 완화할 수 있음을 입증했습니다.

이제 SK하이닉스와 샌디스크는 HBF를 통해 GPU를 비롯한 다양한 xPU 옆에 고용량 플래시 스토리지를 배치하여 AI 추론의 메모리 월 문제를 해결하기 위해 NAND에도 유사한 접근 방식을 공식적으로 적용했습니다.

최근 두 회사는 OCP를 통해 "High Bandwidth Flash (HBF) High-Level Base Die Specification, Version 0.7.0"을 발표했으며, Google과 Tenstorrent는 피드백과 권장 사항을 제공한 공로자로 명단에 올랐습니다.

HBM과 SSD 사이에 위치하는 HBF는 Base Die와 호스트 소프트웨어가 공동으로 관리하며 xPU 옆에 위치한 고용량 플래시 스토리지입니다.

적용 범위는 정적 모델 가중치부터 KV Cache, 다중 모델, mixture-of-experts, 에이전트 워크로드까지 확장됩니다.

NAND의 쓰기 작업, 내구성, 관리 측면에서의 물리적 제약은 여전히 존재합니다. 이러한 제약으로 인한 복잡성은 Base Die와 가속기의 소프트웨어 스택으로 이전됩니다.

메모리 월 문제는 CPU 시대에 이어 오늘날 데이터 중심 컴퓨팅 시스템에서도 지속되고 있습니다. GPU 성능 향상이 메모리 응답 시간을 지속적으로 상회함에 따라 데이터 이동이 점점 더 성능 병목 현상으로 작용하고 있습니다.

동시에 대규모 언어 모델의 규모와 컨텍스트 길이가 증가함에 따라 더 높은 메모리 대역폭과 상당히 증가된 메모리 용량에 대한 요구가 발생했습니다.

AI 처리에 관련된 데이터는 두 가지 범주로 나눌 수 있습니다. 하나는 연속적인 처리 레이어에서 생성되는 모델 입력 및 중간 결과물인 동적 데이터인 활성화(activations)이고, 다른 하나는 모델을 정의하는 가중치(파라미터)입니다.

추론 동안 모델 가중치는 일반적으로 변경되지 않습니다. 그러나 그 총량은 단일 처리 칩이나 로컬 캐시가 수용할 수 있는 양을 훨씬 초과할 수 있습니다.

충분히 큰 모델의 경우 일부 가중치는 랙 내 SSD나 프로세서에서 더 멀리 떨어진 네트워크 연결 스토리지에 저장될 수 있습니다.

이는 다단계 데이터 경로를 생성합니다. 비휘발성 스토리지는 장기 용량을 제공하고, 연산에 필요한 가중치는 DRAM(아마도 HBM)으로 이동한 후 프로세서 측 SRAM에 캐시됩니다.

가중치가 처음 액세스될 때 데이터는 여러 스토리지 레벨을 거쳐 프로세서에 도달해야 할 수 있습니다. 나중에 이 가중치가 캐시에서 제거되었다가 다시 액세스되면 동일한 경로를 한 번 더 통과해야 합니다.

HBF의 개념은 적층 및 함께 패키징을 통해 컴퓨이트 유닛에 저장 매체를 가까이 옮긴다는 사고방식에서 비롯되었습니다.

그러나 사용되는 매체와 그 역할은 다릅니다. HBM은 DRAM을 사용하여 저지연, 고읽기/쓰기 대역폭의 작업용 메모리를 제공하는 반면, HBF는 원래 SSD나 네트워크 스토리지에 저장된 모델 가중치와 같은 대규모 읽기 중심 데이터를 처리하면서도 높은 집합 읽기 대역폭을 유지하기 위해 더 높은 용량의 NAND를 활용합니다.

일부 시스템 설계에서는 HBF에 사전 로드된 모델 가중치가 전통적인 DRAM 중계 단계를 우회하여 프로세서 측 캐시로 직접 전송될 수 있습니다. 이러한 설계는 캐시 및 메모리 관리를 복잡하게 만들지만 외부 스토리지에서 DRAM으로의 전송 오버헤드를 절약합니다.

Expedera의 수석 과학자이자 공동 창립자인 Sharad Chole이 설명하듯, HBF는 "고속 대역폭 액세스와 높은 스토리지 용량" 사이의 격차를 해소하는 것을 목표로 합니다. 이는 HBF를 단순히 더 빠른 SSD나 플래시 기반 HBM으로 설명하는 것보다 더 정확한 표현입니다.

OCP 사양은 HBF를 GPU, TPU 또는 기타 xPU 옆에 위치하여 프로세서 근처에 테라바이트 규모의 추가 메모리 용량을 더해 HBM을 보완하도록 설계된 비공조(non-coherent), 메모리 중심 플래시 장치로 공식적으로 정의합니다.

HBF는 HBM을 직접 대체하거나 단순히 그 용량을 확장하지 않습니다. 대신 고성능 대역폭 메모리와 전통적 스토리지 사이에 또 다른 메모리 계층을 도입하여 모델 데이터의 더 큰 비율을 물리적으로 컴퓨이트 유닛에 가깝게 유지합니다.

Base Die는 단순한 수동 인터커넥트 레이어 이상입니다. Base Die는 호스트 xPU와의 통신을 유지하면서 UCIe 프로토콜을 관리하고 호스트 인터페이스와 NAND 다이 간의 데이터 이동을 제어합니다.

또한 호스트 및 NAND 명령, ECC 인코딩 및 디코딩, 오류 보고, 전송 스케줄링, 읽기/쓰기/소거 상태, NAND 초기화 및 TSV 중복성 매핑을 처리합니다.

이러한 업무 분담은 HBF를 "프로세서 옆에 플래시 다이를 단순히 배치하는 것"과 구별합니다. NAND 적층은 용량을 제공하고, Base Die는 스택이 렛 메모리 장치로서 기능하는 데 필요한 제어, 인터페이스 및 신뢰성 메커니즘을 제공합니다.

xPU는 패키지 내부 다이-투-다이 인터커넥트를 위한 표준인 UCIe 3.0을 통해 HBF에 연결됩니다. UCIe(Universal Chiplet Interconnect Express) 인터페이스 위에서는 AXI가 통신 프로토콜로 사용됩니다. UCIe는 물리 계층 및 링크 계층을 처리하는 반면, AXI는 호스트와 HBF 간 읽기/쓰기 작업을 운반합니다.

사양은 UCIe 프로토콜 계층, Flit 형식 및 AXI 채널에 대한 상세한 설명을 제공합니다. 그러나 HBF의 시스템 역할을 이해하는 핵심 포인트는 PCIe SSD가 특별한 수정 없이 기존 가속기에 연결될 수 있는 것과 달리, HBF가 xPU와 HBF 양쪽 모두에 해당하는 링크 계층 구현이 포함된 전용 렛 인터페이스를 필요로 한다는 점입니다.

단일 HBF 스택은 최대 16개의 호스트 채널을 지원합니다. 각 채널은 전용 UCIe 링크를 사용하며 자체 NAND 리소스에 대한 액세스를 제공합니다. 하나의 채널을 통해 발행된 요청은 다른 채널에 연결된 데이터에 액세스할 수 없습니다.

각 채널에는 자체적인 연속적인 로컬 주소 공간이 있습니다. Base Die는 이 로컬 주소 공간을 물리적 NAND 뱅크, 다이 및 블록에 매핑합니다. 시스템 수준에서 호스트 소프트웨어는 호스트의 전역 주소를 사용 가능한 HBF 채널의 로컬 주소 공간에 매핑합니다.

그 결과는 단일 자동 통합 플래시 풀이 아니라, 성능이 호스트가 여러 독립된 리소스 간에 데이터와 요청을 어떻게 분배하는지에 부분적으로 의존하는 채널화된 아키텍처입니다.

이 구분은 사양에서 동일 시스템 내에서 HBF와 HBM을 별도로 관리해야 한다고 요구하기 때문에 중요합니다. HBF는 자동으로 HBM의 공조 주소 공간의 일부가 되지 않습니다. 소프트웨어는 어떤 데이터가 어느 메모리 계층에 속하는지, 그리고 데이터가 어떻게 이동, 분할 및 액세스되어야 하는지 결정해야 합니다.

사양에서 제공하는 참조 구성은 16개의 NAND 다이, 채널당 16개의 뱅크, 4 KiB NAND 페이지를 사용하며 총 용량은 512 GiB(약 550 GB)이며, 더 높은 용량의 HBF 스택을 허용합니다.

약 3 TB/s의 최대 대역폭 목표는 개별 NAND가 HBM에 가까운 성능을 달성해서 나오는 것이 아니라, 16개의 호스트 채널과 여러 다이, 뱅크 및 어레이 간의 병렬성이 결합되어 발생합니다. 최대 구성에서 각 채널은 64비트 인터페이스를 사용하며 데이터 레인 속도는 최대 32 GT/s입니다.

이러한 병렬 리소스를 진정으로 활용하려면 데이터가 충분한 채널, 다이 및 뱅크에 분산되어야 하며, 호스트는 Base Die가 해당 스케줄링을 수행할 만큼 충분한 요청 동시성을 유지해야 합니다.

따라서 약 3 TB/s는 실제 칩이나 추론 워크로드에서 측정된 성능보다는 최대 구성에 대한 사양 목표로 더 정확하게 설명될 수 있습니다.

집합 읽기 대역폭이 HBM 클래스 수준에 도달하더라도 HBF는 HBM과 동등하지 않습니다. 이들은 지연 시간, 쓰기 능력, 액세스 세분성, 내구성 및 메모리 의미 체계에서 크게 다릅니다.

HBF의 핵심 장점은 모든 워크로드에서 DRAM 수준의 성능을 달성하는 것이 아니라, 고병렬 읽기와 결합된 고용량 NAND를 pairing하는 것입니다.

모델 가중치는 몇 GiB에서 수십 또는 수백 GiB에 이르기까지 하며, 토큰 생성 중에 가져와야 하고 일반적으로 추론 동안 변경되지 않습니다. 이는 지속적인 재쓰기가 발생하는 데이터에 비해 읽기 최적화된 고용량 NAND 계층에 더 적합합니다.

메모리 분석가 Jim Handy는 이렇게 요약합니다. "학습은 모델 가중치를 지속적으로 변경하는 반면, 추론은 일반적으로 이를 변경하지 않습니다."

그러나 OCP 사양은 HBF에 더 넓은 적용 범위를 할당합니다. 그 응용 분야에는 단일 LLM 서빙, 다중 LLM 저장 및 전환, mixture-of-experts 모델, 멀티모달 모델, 에이전트 워크로드, AI 파라미터 로드 및 KV Cache 읽기/쓰기가 포함됩니다.

단일 모델의 경우, 사양은 병렬 읽기를 위해 모델 파라미터를 모든 호스트 채널에 분배하는 방법을 설명합니다. 다중 모델의 경우 두 가지 가능한 레이아웃을 제공합니다.

여러 모델을 HBF에 유지하면 활성 모델이 전환될 때 전체 모델을 외부 SSD에서 다시 로드해야 하는 필요가 줄어듭니다. 이는 모델 전환 지연 시간을 완전히 제거하지는 않지만, 전통적 배포에서 별도의 SSD에서 가속기로 로드하는 단계를 제거합니다.

mixture-of-experts, 멀티모달 및 에이전트 워크로드의 경우, HBF의 데이터 배치는 최대 대역폭을 추구하여 모든 채널에 데이터를 산란시키거나, 용량 할당 및 워크로드 격리를 우선시하여 지정된 채널에 데이터를 배치하는 두 가지 전략 중 하나를 따를 수 있습니다.

prefill 단계 동안 모델 레이어는 KV Cache를 계산하고 씁니다. decode 단계에 진입한 후, attention 모듈은 이전에 생성된 KV Cache를 읽고 이후 토큰을 생성할 때 새 캐시 콘텐츠를 추가합니다.

추론 동안 거의 변경되지 않는 모델 가중치와는 달리, KV Cache는 지속적으로 성장하며 끊임없는 읽기/쓰기 작업을 겪습니다.

사양은 호스트가 LLM 및 AI 워크로드 구조를 이해하고 읽기/쓰기 성능을 최적화하기 위해 KV Cache 데이터를 배치하기를 기대합니다. 따라서 HBF는 파라미터 로드 장치뿐만 아니라 추론 런타임 동안 생성된 데이터의 가능한 저장 대상으로도 정의됩니다.

이는 특히 긴 컨텍스트와 에이전트 워크로드가 메모리 용량 요구사항을 증가시킬 때 HBF의 잠재적 가치를 확대합니다. 그러나 이는 또한 아키텍처를 NAND의 가장 약한 특성인 빈번한 쓰기에 직접 노출시킵니다.

NAND 플래시의 물리적 구조는 읽기/쓰기 액세스 패턴을 결정합니다. 플래시 칩은 내부적으로 블록으로 나뉘며, 각 블록은 다시 페이지로 세분화됩니다.

사양은 4 KiB 크기의 NAND 페이지를 사용하며 4 KiB 정렬 버스트 쓰기를 지원합니다. 4 KiB 미만의 쓰기 요청은 Base Die에 캐시되며, 실제 4 KiB 페이지가 축적될 때까지 NAND 코어 다이로의 실제 쓰기는 발생하지 않습니다.

NAND 블록 내에서 HBF는 순차적 쓰기를 요구하며 이미 프로그래밍된 페이지의 직접적인 무작위 덮어쓰기를 지원하지 않습니다. 블록 내의 임의 데이터를 다시 쓰기 위해서는 먼저 전체 블록을 소거한 다음 지정된 페이지 순서대로 처음부터 다시 써야 합니다.

이러한 규칙은 미리 결정된 대형 모델 가중치 레이아웃과 비교적 잘 부합합니다. 가중치는 순차적으로 완전한 페이지로 쓸 수 있는 쓰기 일회성, 읽기 다수(write-once, read-many) 데이터입니다.

그러나 동적으로 생성되는 데이터의 경우 이는 어려운데, 이는 그들의 크기, 수명 주기 및 업데이트 패턴이 추론 동안 변경될 수 있기 때문입니다.

빈번한 세분화된 쓰기가 필요한 KV Cache와 같은 데이터의 경우, 사양은 모든 KV Cache 워크로드가 HBF에서 잘 수행될 것이라고 보장하지 않습니다. 실제 성능은 호스트가 작은 쓰기를 어떻게 결합하고, KV Cache 페이지를 어떻게 레이아웃하며, 비효율적인 NAND 블록 활용으로 이어지는 패턴을 어떻게 피하는지에 달려 있습니다.

모델 가중치와 KV Cache는 서로 다른 읽기/쓰기 패턴을 가지므로, 사양은 동일한 영역에 혼합하면 내구성과 용량 활용도가 감소할 수 있다고 명시합니다. 따라서 채널 세분성에서 HBF를 분할할 것을 권장하며 두 가지 예시 전략을 제공합니다.

비균일 분할은 활성 모델 가중치를 저장하는 데 필요한 만큼의 채널만 할당하고 나머지 용량을 KV Cache에 할당합니다.

이는 HBF의 데이터 레이아웃이 하드웨어에 의해 완전히 자동화될 수 없음을 나타냅니다. 호스트는 워크로드 특성을 이해하고, 가중치와 KV Cache에 대한 용량 요구사항을 추정하며, 각각에 얼마나 많은 대역폭과 내구성 예산을 할당할지 결정해야 합니다.

각 HBF 채널이 독립적인 주소 공간을 가지므로, 호스트 소프트웨어는 전역 주소를 다른 채널에 매핑하고, 데이터가 어떻게 인터リーブ되는지 결정하며, HBF와 HBM을 별도로 관리해야 합니다.

NAND 매체의 유지 관리는 Base Die 내에 완전히 캡슐화되지 않습니다. 웨어 레벨링은 Base Die에 의해 수행되거나 호스트에 의해 영역 재매핑을 통해 제어될 수 있습니다.

호스트는 논리적 주소와 물리적 주소 간의 매핑을 조정하여 프로그래밍 및 소거 작업을 더 균등하게 분배할 수 있지만, 재매핑 명령은 기존 데이터를 자동으로 마이그레이션하지 않습니다. 호스트는 새 위치에 데이터를 다시 쓰기 전에 관련 액세스를 먼저 중지해야 합니다.

데이터 보존 및 읽기 방해(read disturb)도 정기적인 관리가 필요합니다. Base Die는 NAND 상태를 감지하고 보고하며, 호스트는 데이터를 새로 고치고, 읽기를 재시도하며, 실패한 용량을 격리하거나 장치 복구를 기다려야 할 수 있습니다.

그러나 HBF는 전통적인 SSD 컨트롤러가 처리하는 모든 기능을 호스트 소프트웨어로 이전하지 않습니다. Base Die는 NAND 명령, ECC, 요청 스케줄링 및 오류 감지를 담당하지만, 데이터 레이아웃, 부분적 웨어 관리 및 이상 복구에는 호스트의 참여가 필요합니다.

HBF의 책임 분할은 HBM과 전통적인 SSD 모두와 다릅니다. 전자(DRAM 기반)는 NAND의 관리 복잡성에 직면하지 않으며, 후자는 NAND를 사용하지만 일반적으로 SSD 컨트롤러에서 주소 변환, 가비지 컬렉션 및 웨어 관리를 처리하며 상위 소프트웨어는 이러한 프로세스를 거의 인지하지 못합니다.

HBF는 다른 위치에 있습니다. Base Die는 장치 측 제어 능력을 유지하지만 NAND 매체 관리를 완전히 캡슐화하지는 않습니다. 그 용량과 병렬 대역폭을 최대한 활용하려면 xPU 호스트와 그 소프트웨어가 여전히 채널, 데이터 레이아웃 및 부분적 매체 상태를 이해해야 합니다.

이것이 HBF의 근본적인 트레이드오프입니다. 이는 고용량 NAND를 컴퓨이트에 더 가깝게 이동시키면서 하드웨어, 펌웨어, 런타임 소프트웨어 및 워크로드 데이터 레이아웃 간의 tighter 조정을 요구합니다.