HBM이 AI 성능을 결정한다? GPU 병목을 읽는 Roofline

메모리 부족과 느린 메모리는 다른 문제다

AI 서버를 고를 때 GPU의 연산 성능과 HBM 용량을 나란히 보는 일이 많다. 두 수치가 크면 도움이 될 수 있지만, 무엇이 부족한지에 따라 효과가 달라진다. 모델과 실행 상태가 들어가지 않아 작업을 시작하지 못하는 상황과, 실행은 되지만 연산기가 데이터를 기다리는 상황은 구분해야 한다.

가중치·KV 캐시·작업 공간의 합이 사용 가능한 메모리를 넘으면 모델 분할, 정밀도 조정, 배치 축소 등을 검토한다. 반면 용량이 충분한데도 데이터를 반복해서 읽는 시간이 길다면 메모리 이동량과 대역폭을 보게 된다. 용량 계산은 추론 메모리와 KV 캐시 해설에서 다뤘다. 여기서는 실행 중 데이터가 얼마나 움직이는가로 질문을 바꾼다.

구분	묻는 질문	먼저 확인할 정보
용량	필요한 상태를 모두 담을 수 있나?	가중치·캐시·작업 공간·예약 메모리
대역폭	단위 시간에 필요한 데이터를 옮길 수 있나?	실제 메모리 전송량과 지속 대역폭
지연	개별 작업의 응답을 얼마나 기다리나?	커널 실행·의존성·동기화·통신 시간
연산 성능	데이터를 받은 뒤 계산할 여력이 있나?	연산 종류·정밀도·실제 연산기 이용률

같은 GPU에서도 요청 길이와 배치가 달라지면 지배적인 제약이 바뀐다. 따라서 “이 모델은 메모리 병목”이라는 표현에는 어느 실행 단계와 조건을 말하는지 붙여야 한다.

HBM 사양을 읽을 때 용량과 대역폭을 분리한다

예를 들어 NVIDIA H200 제품 문서는 141GB HBM3e와 4.8TB/s 메모리 대역폭을 명시한다. 141GB는 저장할 수 있는 양에 관한 사양이고, 4.8TB/s는 메모리 인터페이스의 전송 능력에 관한 사양이다. 이 숫자만으로 특정 모델의 초당 토큰 수나 동시 사용자 수를 계산할 수는 없다.

모델 실행 시간에는 메모리 외에 연산·통신·스케줄링이 관여한다. 또한 실제 접근 패턴이 사양상 대역폭을 충분히 활용하지 못할 수 있다. 큰 연속 전송과 작은 비연속 전송, 충분한 병렬 요청과 연쇄 의존성이 큰 요청은 같은 결과를 내지 않는다.

큰 용량은 모델을 더 적은 장치에 배치할 가능성도 열어 준다. 장치 수가 줄면 일부 통신이 줄 수 있지만, 동시에 전체 연산 자원과 총 메모리 대역폭도 달라진다. “더 큰 메모리 한 장이면 여러 장보다 언제나 빠르다”는 결론은 이 두 변화를 빠뜨린다.

Roofline은 연산과 데이터 이동의 상한을 함께 본다

NVIDIA의 GPU 성능 배경 문서와 NERSC의 Roofline 안내는 연산량과 데이터 이동량의 관계로 병목을 해석한다. 핵심 변수인 연산 집약도(arithmetic intensity)는 다음처럼 정의한다.

I = 수행한 부동소수점 연산 수 / 메모리에서 이동한 바이트 수

단순 Roofline 상한 = min(P, B × I)
P: 해당 연산·정밀도의 피크 연산 성능 (FLOP/s)
B: 선택한 메모리 계층의 대역폭 (byte/s)
I: 그 계층의 이동량을 기준으로 한 연산 집약도 (FLOP/byte)

한 바이트를 가져와 여러 번 계산에 재사용하면 I가 높아진다. 반대로 데이터를 많이 읽고 간단히 한 번 계산한다면 I가 낮다. 여기서 어느 메모리 계층을 기준으로 삼았는지가 중요하다. HBM과 칩 내부 캐시의 이동량을 섞어 계산하면 하나의 Roofline으로 해석할 수 없다.

두 상한이 만나는 지점은 I = P/B다. 그보다 왼쪽에서는 대역폭을 늘리는 일이 유리할 가능성이 있고, 오른쪽에서는 연산 성능을 높여야 상한이 올라간다. 이는 이상적인 한계다. 실제 성능은 그 아래에 있으며 낮은 병렬성이나 실행 지연 때문에 두 상한 모두에 못 미칠 수 있다.

가상 GPU로 계산하면 업그레이드의 조건이 드러난다

피크 연산 성능 200TFLOP/s, 메모리 대역폭 2TB/s인 가상의 장치를 생각해 보자. 이 글의 예시는 소수 단위 TB와 TF를 사용한다. 실제 GPU 벤치마크나 H200의 성능 추정이 아니다. I가 10FLOP/byte이면 대역폭 상한은 2 × 10 = 20TFLOP/s이고, 연산 피크 200보다 낮다.

I (FLOP/byte)	기준: 200TFLOP/s·2TB/s	대역폭만 4TB/s	연산만 400TFLOP/s
1	2	4	2
10	20	40	20
100	200	200	200
200	200	200	400

표의 결과 단위는 모두 TFLOP/s이며 상한 계산값이다. 기준 장치의 전환점은 100FLOP/byte다. I=10에서 연산 피크만 두 배로 높여도 메모리에서 데이터가 오는 속도는 같으므로 상한은 20에 머문다. I=200에서는 대역폭을 두 배로 높여도 연산 피크 200이 상한을 막는다.

계산 입력·결과 JSON에서 동일한 수식을 확인할 수 있다. 실제 장치를 비교할 때에는 같은 정밀도와 같은 연산 종류의 P를 써야 한다. 한 장치의 저정밀 희소 연산 피크를 다른 장치의 일반 연산 피크와 비교하면 이 계산의 전제가 달라진다.

배치는 연산 집약도를 바꾸지만 공짜가 아니다

여러 입력을 묶어 처리하면 같은 가중치를 더 많은 입력에 재사용할 수 있다. 이것이 작은 작업을 모아 큰 행렬 연산으로 바꾸는 효과와 결합하면 연산기를 더 잘 활용할 수 있다. 다만 모든 연산의 이동량이 같은 비율로 줄어드는 것은 아니다.

언어 모델의 디코딩에서는 각 요청의 KV 캐시도 고려해야 한다. 배치를 늘리면 가중치 재사용에는 유리할 수 있지만 동시 요청의 캐시와 작업 공간이 증가한다. 문맥이 길어질 때의 캐시 읽기 비용도 함께 변한다. 메모리에 들어가는 최대 배치를 그대로 최적 배치로 정하기 어려운 이유다.

서비스에는 대기 시간이라는 또 다른 제약이 있다. 배치를 채우려고 요청을 기다리면 전체 처리량은 좋아져도 첫 응답이 늦어질 수 있다. 사용자별 출력 길이가 달라지는 동적 배치에서는 스케줄러 동작도 영향을 준다. 비교의 기준은 단순 최대 tokens/s보다 목표 응답 지연을 만족하는 처리량이어야 한다.

프리필과 디코딩을 하나의 평균 이용률로 묶는 것도 문제다. 긴 입력을 처리하는 단계와 토큰을 순차적으로 내보내는 단계는 연산 모양과 재사용 조건이 다르다. 두 단계의 시간과 메모리 사용을 따로 보면 같은 최적화가 어디에 효과를 냈는지 판단하기 쉽다.

FlashAttention의 요점은 더 큰 메모리를 사는 것이 아니다

FlashAttention 논문은 어텐션을 계산하는 과정에서 HBM과 더 작은 온칩 메모리 사이의 읽기·쓰기를 줄이도록 계산 순서를 설계한다. 큰 중간 결과를 계속 외부 메모리에 저장하고 다시 읽는 대신, 나눠 계산하고 재사용하는 방식이다.

이 사례는 Roofline을 하드웨어 구매 도구로만 보면 놓치는 지점을 보여 준다. 대역폭 B를 높이는 대신, 같은 문제를 풀 때 메모리를 오가는 바이트 수를 줄여 유효한 연산 집약도 I를 바꿀 수 있다. 알고리즘의 계산 순서와 커널 구현이 사양표 못지않게 중요한 이유다.

그렇다고 모든 병목이 사라지는 것은 아니다. 이 방법을 “어텐션의 모든 계산량이 선형이 된다”는 뜻으로 읽어서는 안 된다. 지원하는 자료형·모양·하드웨어와 실제 런타임의 커널 선택을 확인해야 한다. 논문의 실험 수치를 다른 모델과 장치에 그대로 대입하는 것도 별도의 검증이 필요하다.

장비를 바꾸기 전에 남길 측정 기록

성능 문제를 재현하려면 모델 이름만 기록해서는 부족하다. 정밀도, 입력·출력 길이 분포, 배치 또는 동시성, 장치 수, 런타임 버전, 적용 커널, 워밍업 조건을 함께 고정해야 한다. 다음은 비교 실험을 설계할 때 사용할 기록 틀이다. 이 글에서 해당 실험을 실행한 것은 아니다.

관측	의심할 수 있는 문제	다음 비교
메모리 할당 실패·캐시 축출	용량 또는 관리 방식	배치·문맥·정밀도별 점유량
메모리 이동이 실행 시간 지배	낮은 재사용 또는 큰 이동량	배치·커널별 전송량과 지속 대역폭
작은 커널 사이 빈 시간이 큼	실행·동기화·병렬성 부족	커널 융합·그래프 실행 전후
여러 장에서 확장 효과가 작음	통신 또는 작업 분할	장치 수별 통신 시간과 연산 시간
처리량 증가와 꼬리 지연 악화가 동반	대기열·배치 정책	같은 지연 목표에서의 처리량

관측과 원인은 일대일로 대응하지 않는다. 예를 들어 GPU 이용률이 낮다는 요약 지표 하나만으로 메모리 병목을 확정할 수 없다. 타임라인과 커널 단위 지표를 함께 보고, 한 번에 한 조건을 바꿔 가설을 좁혀야 한다.

HBM의 가치를 판단하는 질문도 이렇게 바뀐다. “몇 GB인가” 다음에는 “어느 데이터를 얼마나 자주 옮기는가”, 그다음에는 “그 이동을 줄일 수 있는가”를 묻는다. 이 순서라면 용량 증설, 대역폭 개선, 커널 최적화, 서비스 스케줄링 중 어디에 비용을 써야 할지 근거를 세울 수 있다.