HBF를 두고 가장 먼저 생기는 질문은 “낸드로 HBM을 대체할 수 있나”입니다.
현재 공개된 연구 두 편을 같이 보면 답은 대체보다 역할 분담에 가깝습니다. HBM은 지연에 민감한 데이터를 맡고, HBF는 모델 가중치를 많이 담는 용량 계층을 맡는 구조입니다.
확인된 연구 결과
Oxford 연구진이 IEEE Computer Architecture Letters에 발표한 논문은 HBF를 HBM보다 스택당 16배 큰 용량을 제공할 수 있는 대안으로 모델링했습니다.
하지만 HBM을 HBF로 단순 교체하자 낸드의 긴 꼬리 지연이 GPU 스케줄러를 굶겼습니다. 용량은 늘었지만 성능이 따라오지 않았습니다.
연구진은 자주 쓰는 데이터를 HBM에 남기고 HBF의 데이터를 예측해 옮기는 이종 메모리 구조를 제안했습니다. 시뮬레이션 결과는 다음과 같습니다.
| 비교 | 연구 결과 | 근거 수준 |
|---|---|---|
| HBM+HBF 이종 구조 vs HBF-only | 기하평균 2.79배 성능 | peer-reviewed modeling |
| 단일 edge GPU에서 실행 가능한 모델 크기 | 9.2배 확대 | peer-reviewed modeling |
| HBF 스택 용량 vs HBM | 16배 | 연구의 설계 가정 |
숫자가 말하는 핵심은 HBF 자체가 빠르다는 것이 아닙니다. 느린 HBF를 GPU의 critical path에서 얼마나 잘 치우느냐가 성능을 결정했습니다.
FLINT가 추가한 세 가지 조건
8월 25일 공개된 FLINT preprint는 HBF를 HBM 옆의 memory-capacity tier로 정의합니다. HBF를 SSD처럼 다루지 않고, LLM 가중치의 읽기 패턴에 맞춘 세 가지 장치를 제안했습니다.
첫째, burst-buffer controller입니다. GPU가 보내는 작은 cache-line 읽기를 모아 낸드 plane을 병렬로 읽는 큰 burst로 바꿉니다. 별도 대형 SRAM staging buffer 없이 HBF 내부의 page buffer와 cache buffer를 활용합니다.
둘째, phantom-plane refresh입니다. 낸드는 반복 읽기로 read disturb가 쌓여 refresh가 필요합니다. FLINT는 refresh 작업을 foreground 읽기 경로 밖으로 옮겨 추론이 멈추지 않게 합니다.
셋째, read-only FTL입니다. LLM 가중치는 배포 뒤 대부분 읽기 전용입니다. 그래서 garbage collection과 임의 쓰기처럼 SSD에 필요한 관리 기능을 덜고, logical burst를 physical HBF 위치로 옮기는 작은 변환표에 집중합니다.
정적 prefetch는 왜 실패했나
FLINT 연구에서 기존 정적 prefetch 구조는 MoE 모델의 HBF 트래픽 중 86~96%를 낭비했습니다. 다음 layer에 필요할 것이라고 미리 가져온 가중치가 실제로 쓰이지 않거나, buffer에서 밀려난 뒤 다시 읽혔기 때문입니다.
FLINT는 여섯 모델의 MoE 구간에서 기존 HBF 구조보다 GPU당 decode 처리량을 4.0~14.3배 높였다고 보고했습니다. refresh를 켠 경우와 끈 경우의 처리량도 같았습니다.
다만 이 결과를 HBF가 HBM보다 낫다로 읽으면 안 됩니다. 비교 대상은 HBM-only 전체가 아니라 정적 prefetch 기반의 기존 HBF 구조입니다.
HBF가 불리한 경우도 확인됐다
FLINT는 다섯 MoE 모델에서 토큰당 에너지가 HBM-only의 0.72~0.90배였습니다. 여러 GPU가 barrier에서 기다리는 시간을 줄였기 때문입니다.
그러나 dense Llama에서는 토큰당 에너지가 HBM-only의 1.64배로 올라갔습니다. 매 토큰마다 많은 가중치를 HBF에서 다시 읽으면 낸드의 높은 bit당 읽기 에너지가 그대로 드러납니다.
이 수치가 중요한 이유는 HBF의 반증 조건을 보여 주기 때문입니다.
- MoE처럼 필요한 expert만 선택해 읽는 모델은 HBF 용량 계층의 이점이 큽니다.
- dense 모델처럼 가중치를 넓게 반복해서 읽으면 HBF의 지연과 에너지 비용이 커질 수 있습니다.
- 따라서 모델 크기만으로 HBF 적합성을 판단할 수 없고, 가중치 재사용·batch size·context length·읽기 선택성을 함께 봐야 합니다.
정보 사이에서 나온 인사이트
OCP에는 실제로 High Bandwidth Flash Workstream이 존재하고, SK하이닉스·샌디스크가 공개한 첫 규격은 최대 512GB와 0.4~3.0TB/s 등급을 제시합니다. 산업은 용량과 인터페이스를 먼저 표준화하고 있습니다.
학계는 그 다음 질문을 다룹니다. 그 큰 용량을 GPU가 기다리지 않게 쓰려면 무엇이 필요한가입니다.
두 연구가 서로 다른 방법으로 같은 결론에 도달했습니다.
HBF의 경쟁 상대는 HBM이 아니라, HBM만으로 모델을 담기 위해 추가해야 하는 GPU와 SSD까지 내려갔을 때 생기는 지연입니다.
따라서 HBF가 커질수록 HBM 수요가 사라진다고 바로 연결할 수 없습니다. 오히려 HBM은 hot data와 KV cache를 맡는 critical-path tier로 남고, HBF는 cold·read-mostly weight tier를 맡을 가능성이 큽니다. HBM의 역할이 전체 모델 저장소에서 지연에 민감한 작업 집합으로 바뀌는 것입니다.
반증 조건과 다음 확인 숫자
이 해석을 낮춰야 하는 조건은 명확합니다.
- 실제 HBF silicon의 p99 읽기 지연이 길어 GPU stall을 숨기지 못할 때
- 지속 읽기 대역폭이 발표된 0.4~3.0TB/s 등급에 미달할 때
- read-disturb refresh와 ECC가 연구보다 큰 foreground 비용을 만들 때
- dense 모델 비중이 높아 HBF의 토큰당 에너지가 HBM-only보다 계속 높을 때
- 고객이 HBF 대신 CXL 메모리·eSSD·추가 GPU를 선택할 때
다음에 확인할 숫자는 실제 스택 용량, 지속 읽기 대역폭, p99 latency, refresh overhead, read endurance, 고객 sample·양산 시점입니다. 이 값이 나오기 전까지 연구의 배수는 제품 성능으로 승격하지 않습니다.
규격과 회사별 진행 상태는 보강한 HBF 위키, 메모리 계층 전체는 계층형 메모리, HBM의 역할은 HBM에서 이어서 볼 수 있습니다.
원문과 검증 정보
- Oxford ORA — Hardware-managed heterogeneous high-bandwidth memory and flash in LLM inference systems — 출판일 2026-08-12, acceptance 2026-08-04, IEEE Computer Architecture Letters, DOI 10.1109/LCA.2026.3723326, peer reviewed, 마지막 검증일 2026-09-01, 다음 검증일 상용 실측 공개 시, 근거 수준
peer-reviewed modeling - arXiv — FLINT — 제출일 2026-08-25 18:58:14 UTC, 대상 6개 LLM·128K context simulation, 마지막 검증일 2026-09-01, 다음 검증일 peer review·후속 silicon 검증 시, 근거 수준
preprint simulation - Open Compute Project Community — HBF Workstream 공개 목록, 마지막 검증일 2026-09-01, 다음 검증일 규격 문서 공개 시, 근거 수준
confirmed official organization - SK하이닉스 HBF 발표 — 발표일 2026-08-04, 대상 첫 규격의 용량·대역폭·UCIe, 마지막 검증일 2026-09-01, 다음 검증일 sample·양산 발표 시, 근거 수준
confirmed company disclosure
이 글은 연구 결과와 공식 규격을 구분해 연결한 기술 분석이며 특정 종목의 매수·매도를 권하지 않습니다.
밑줄 친 말은 용어 위키로 이어집니다.