TB급 랙 메모리의 의미

랙 한 칸에 GPU 메모리 20.7TB, CPU 메모리 54TB가 들어가는 순간, “모델이 커서 못 올린다”는 말은 단순한 용량 문제가 아니라 아키텍처 선택의 문제가 된다. NVIDIA가 공개한 Vera Rubin NVL72는 랙 단위로 HBM4 20.7TB와 GPU 메모리 대역폭 1,580TB/s를 제시한다. NVIDIA 공식 GB300 NVL72 페이지의 사양 표 기준으로는 GPU 메모리 20TB, CPU 메모리 17TB LPDDR5X, GPU 메모리 대역폭 최대 576TB/s로 제시된다. 따라서 21TB GPU 메모리와 18TB CPU 메모리라는 수치는 공식 페이지와 일치하지 않는다. 핵심은 숫자 자체보다, 이 수치가 학습·추론·서빙의 병목 위치를 바꾼다는 점이다.

세 줄 요약

TB급 랙 메모리의 핵심 이슈는 더 큰 모델을 “올릴 수 있느냐”보다, 분산 병렬화·KV 캐시·체크포인팅·데이터 이동을 얼마나 줄일 수 있느냐에 있다.
이 변화가 중요한 이유는 메모리 용량과 대역폭이 늘수록 추론 배치, 긴 컨텍스트 처리, 학습 중 활성값 저장 방식의 비용 구조가 달라지고, 그에 따라 시스템 비용 구조와 장애 지점도 달라지기 때문이다.
독자는 지금 바로 모델 가중치, KV 캐시, 활성값, 옵티마이저 상태를 따로 계측하고, “메모리 부족” 문제를 분산 구조로 풀지 단일 도메인 확장으로 풀지 판단 기준을 다시 정리해야 한다.

현황

공식 문서 기준으로 확인되는 사실부터 분리해서 보자. NVIDIA Vera Rubin NVL72는 랙 구성 기준 GPU 메모리 20.7TB HBM4, CPU 메모리 54TB LPDDR5X, GPU 메모리 대역폭 1,580TB/s를 제시한다. 다만 이 수치에는 해당 페이지에 예비 정보이며 변경될 수 있다는 단서가 붙어 있다. GB300 NVL72는 NVIDIA 공식 페이지 기준으로 GPU 메모리 20TB, CPU 메모리 17TB LPDDR5X, GPU 메모리 대역폭 최대 576TB/s로 제시된다.

여기서 첫 번째 오해를 걷어내야 한다. 이번 조사 결과로 확인된 것은 “단일 GPU가 TB급 HBM을 갖는다”는 사실이 아니라, 랙급 구성에서 총 GPU 메모리가 TB 단위를 넘는다는 점이다. 커뮤니티에서 거론되는 차세대 단일 패키지의 TB급 HBM 수치, 특히 Rubin Ultra 1TB HBM4e 같은 표현은 이번 기준에서 NVIDIA 공식 원문으로 확인되지 않았다. 공식 자료에서 확인되는 방향은 HBM 확대, CPU·GPU 메모리 결합, 그리고 플랫폼·랙 단위 메모리 확장이다.

과거 세대 사례를 기준점으로 놓으면 차이가 더 또렷해진다. NVIDIA H200의 공식 수치는 GPU 메모리 141GB, 메모리 대역폭 4.8TB/s다. 이 수치를 현재 랙급 수치와 나란히 두면, 논의 단위가 “가속기 한 장”에서 “메모리 풀을 가진 랙”으로 옮겨가고 있음을 확인할 수 있다. AMD 쪽 공식 로드맵에서는 MI325X와 MI350이 최대 288GB HBM3E까지, MI400은 2026년 예정 수준까지 확인된다.

분석

이 변화가 실제 운영에 미치는 영향은 추론에서 먼저 드러난다. Hugging Face 문서에 따르면 KV 캐시는 [batch_size, num_heads, seq_len, head_dim] 형태다. 즉 KV 캐시 메모리는 배치 크기와 컨텍스트 길이에 선형으로 늘어난다. 메모리가 커지면 더 큰 배치와 더 긴 컨텍스트를 같은 메모리 도메인 안에 둘 수 있다. 그만큼 잦은 오프로딩이나 과도한 캐시 축소 정책을 덜 써도 된다. 다만 슬라이딩 윈도우 어텐션이나 청크드 어텐션을 쓰는 모델은 캐시가 최대 창 크기에서 성장을 멈춘다. 그래서 메모리 증설 효과는 모델 구조에 따라 달라진다.

학습에서는 “큰 메모리 = 무조건 빠름”으로 끝나지 않는다. Megatron Bridge 기준으로 모델 상태 메모리는 분산 옵티마이저를 끄면 파라미터당 18 bytes, 켜면 6 + 12 / shard_size bytes로 계산한다. 이는 메모리가 커질수록 샤딩을 덜 하고 단순한 구성을 택할 여지가 생긴다는 뜻이다. 동시에 분산 옵티마이저가 주던 메모리 절감 이점을 일부 포기할 수 있다는 뜻이기도 하다. 활성값 재계산도 같은 맥락이다. NeMo 문서에 따르면 Transformer layer recomputation은 메모리를 줄이는 대신 레이어당 연산 비용이 약 30% 늘어난다. 메모리가 넉넉해지면 이 비용을 줄일 수 있다. 반대로 메모리만 믿고 체크포인팅을 모두 줄이면, 랙 장애 시 복구 시간과 자원 낭비가 다른 방식으로 커질 수 있다.

핵심 트레이드오프는 비교적 분명하다. 메모리 증설 덕분에 모델, KV 캐시, 마이크로배치를 더 적은 노드에 모을 수 있다면 통신 오버헤드와 운영 복잡도를 줄일 수 있다. 반면 워크로드가 이미 슬라이딩 윈도우 캐시, 강한 양자화, 공격적인 샤딩으로 최적화돼 있다면 추가 메모리의 체감 이익은 예상보다 작을 수 있다. 특히 랙 총용량 수치를 단일 GPU 체감 용량으로 오해하면 설계 판단이 틀어질 수 있다.

실전 적용

개발자와 인프라 팀이 지금 해야 할 일은 “더 큰 메모리면 더 큰 모델”이라는 단순한 도식을 버리는 일이다. 먼저 현재 시스템에서 무엇이 실제로 메모리를 쓰는지 분해해야 한다. 추론은 가중치와 KV 캐시를 나눠 보고, 학습은 파라미터·그래디언트·옵티마이저 상태·활성값을 따로 재야 한다. 이 분해가 끝나야 TB급 랙 메모리를 병렬화 축소에 쓸지, 더 긴 컨텍스트에 쓸지, 아니면 배치 확대에 쓸지 판단할 수 있다.

예: 긴 대화 세션이 많은 서비스라면 KV 캐시가 먼저 병목이 될 가능성이 크다. 반대로 학습 파이프라인이라면 활성값 재계산을 줄여 연산 손실을 줄이는 편이 더 나을 수 있다. 같은 “메모리 증설”이어도 서빙과 학습의 최적 해법은 다르다.

오늘 바로 할 일 체크리스트 3개:

현재 워크로드에서 가중치, KV 캐시, 활성값, 옵티마이저 상태가 차지하는 메모리를 항목별로 계측하라.
슬라이딩 윈도우 어텐션이나 청크드 어텐션을 쓰는지 확인하고, 캐시가 실제로 계속 커지는 모델인지 먼저 검증하라.
분산 옵티마이저, 활성값 재계산, 오프로딩을 하나씩 끄고 켜며 메모리 절감과 성능 손실의 교환비를 표로 정리하라.

FAQ

Q. TB급 GPU 메모리 시대가 곧 단일 GPU에서 TB급 HBM을 쓴다는 뜻인가?

그렇지는 않습니다. 이번 조사 결과에서 공식 문서로 확인된 것은 Vera Rubin NVL72와 GB300 NVL72 같은 랙 구성의 총 GPU 메모리 수치입니다. 단일 GPU 또는 단일 가속기 기준 TB급 HBM 용량은 이번 기준에서 공식 확인되지 않았습니다.

Q. 메모리가 커지면 긴 컨텍스트 문제가 거의 해결되나?

부분적으로만 그렇습니다. KV 캐시는 배치 크기와 시퀀스 길이에 따라 선형으로 커지므로 메모리 증설은 직접적인 도움이 됩니다. 다만 슬라이딩 윈도우 어텐션이나 청크드 어텐션을 쓰는 모델은 캐시가 최대 창 크기에서 성장을 멈추기 때문에, 메모리 증가 효과가 모든 모델에서 같은 방식으로 나타나지는 않습니다.

Q. 학습에서는 메모리가 커지면 어떤 최적화를 줄일 수 있나?

활성값 재계산이나 과도한 샤딩 의존도를 줄일 여지가 생깁니다. 예를 들어 NeMo 문서 기준으로 Transformer layer recomputation은 메모리를 아끼는 대신 연산 비용을 약 30% 늘립니다. 메모리 여유가 생기면 이런 비용을 덜 치를 수 있습니다. 다만 분산 옵티마이저를 줄이는 결정은 통신, 장애 복구, 자원 활용까지 함께 봐야 합니다.

결론

TB급 메모리의 본질은 “더 큰 숫자”가 아니다. 병렬화, 캐시, 재계산, 오프로딩 사이의 균형점을 다시 쓰게 만든다는 데 있다. 다음으로 볼 포인트도 분명하다. 공식 문서에서 확인되는 랙 총메모리와, 아직 확인되지 않은 단일 가속기 용량 관련 이야기는 끝까지 분리해서 봐야 한다.

Aionda

TB급 랙 메모리의 의미

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기