Video: HBM4 추가로 더 탑재, 엔비디아 Rubin CPX 부활설 |삼성 HBM4 13Gbps가 의미 있었던 이유 | 168GB HBM4의 정체
Channel: 안될공학 - IT 테크 신기술
Duration: 12m 6s
Source: subtitle (auto, ko)
Transcript:
네, 여러분 안녕하세요. 패치입니다. 삼성전자가 올해 HBM4를 양산을 하면서 굉장히 강하게 내세운 숫자가 있습니다. 11.7G 7GBS 그리고 최대 13GBS HBM 4 표준 속도인 8GBS를 훨씬 넘겨 가지고 처음부터 꽤 공격적인 속도를 잡았는데요. 삼성은 아예 개발 초기부터 제 기준보다 높은 성능을 목표를 했고요. 고객이 더 높은 성능을 요구를 할 때 대응할 수 있도록 여유를 확보했다고 설명을 했습니다. 당시에는 삼성전자가 HBN 경쟁에서 뒤쳐졌다는 평가를 뒤집기 위해서 최고 속도에 상당히 집착한 것처럼 보이기도 했습니다. 그런데 최근 엔비디아에서 나온 이야기를 좀 같이 봐 보면이 높은 속도가 생각보다 훨씬 실용적인 곳에 쓰일 수가 있을 것 같아요. 지난 GTC 타이에서 에러 님이 M비DI GPU 설계 담당 디렉터를 직접 인터뷰하신 적이 있었죠. 그때에 인터뷰를 하면서 CPX에 대해서도 물어봤는데요. 당시 답변은 현재 CPX를 제품으로 가져가는 방향은 고려하고 있지 않다라는 그런 취지였습니다. 실제로 지난 3월 GTC에서도 엔비디아의 이한 버그은 루빈 CPX를 당장 진행하지 않고 그록의 LPU를 이용한 디코드 쪽에 집중을 한다고 밝혔는데요.

근데 그러면서도 CPX라는 아이디어 자체는 여전히 좋고 이후 세대에서 다시 생각해 볼 수 있다는 그런 여지를 남겼었죠. 그런데 불과 몇 달 뒤인 지난 8월 30일 밍거가 공급망 조사 결과를 하나 내놨습니다. 루빈 CPX가 다시 살아났다는 건데요. 원래 128GB GDDR7이었던 메모리는 168GB HBM 4로 바뀌고요. 연산 성능도 일반 루빈에 가까워지면서 최대 전력 역시도 루빈이랑 같은 2,300W 생산은 2027년 1분기를 목표로 한다는 내용입니다. 이게 뭐 아직 엔비디아가 공식적으로 확인한 내용은 아닌데요. 그런데 168GB를 실제 HBM4 구성으로 맞춰 보면이 사양이 생각보다 꽤 구체적이에요. 자, 삼성의 HBM4는 디램 다이 하나가 3GB죠. 8단으로 쌓으면 24GB, 12단이면 36GB가 되는데요. 삼성도 24GB 8단, 36GB 12단 구성을 공식적으로 공개를 했습니다. 24GB짜리 HBM 4곱개를 사용을 하면 정확히 168GB죠. 엔비디아가 실제로 일곱 개를 사용한다는 자료는 아직 없는데요.

음. 그러니까 지금부터의 계산은 168GB라는 용량에서 거꾸로 역사해 본 하나의 가능한 구성입니다. 일반 루빈 GPU는 HBM 4 288GB의 최대 메모리 대역 폭이 22바/세컨드거든요. 반면에 삼성 HBM4를 11.7GBS로 7GBS로 동작을 시키면 스택 하나가 거의 3TB/s 그러니까 일곱 개면 약 21TB/세가 나옵니다. 그러니까 루비는 288GB에 22바/s CPX는이 가정에서 168GB의 약 21바/s예요. 용량은 42%를 줄였는데 대역폭이 거의 안 줄어드는 거죠. HBM4개만 가지고서 루비의 22바/세컨드를 정확히 맞추려면은 핀 하나당 필요한 속도가 약 11.3GBs거든요. 삼성이 공개한 최대 성능 범위는 13GBS니까이 속도를 엔비디아가 실제 제품에서 안정적으로 사용을 할 수 있다는 전제에서는 168GB로도 이론상 23TB/세가 넘습니다. 일반 루빈보다 메모리은 훨씬 적은데 대역폭을 루빈급으로 맞출 수가 있는 거죠. 삼성의 13GBS가 CPX를 견냥해서 만들어졌다는 그런 이야기는 아니고요.

CPX에 삼성 HBM4가 들어간다는 근거도 현재는 없어요. 하지만 삼성이 확보를 했다고 말하는 그 높은 속도의 가치가 단순히 그냥 HBM 하나를 더 빠르게 만들었다. 이거에서 끝나지 않는다는 거를 보여 주는 겁니다. 핀 속도가 충분히 올라가면 필요한 대역폭을 유지를 하면서 HBM 용량을 낮출 수 있죠. 이거를 HBM 안에 들어가는 디램 다이 숫자로 보면 차이가 훨씬 더 크게 보이는데요. 일반 루빈이 36GB짜리 12단 HBM 4를 여덟 개 사용을 한다고 단순히 계산을 해 보면 DM 다이가 총 96GB가 필요하죠. CPX를 24GB짜리 8단 HBM 4개로 구성을 한다면 56개예요. 디램 다이는 40%가 넘게 줄어드는데 앞에서 계산한 메모리 대역폭은 21TB/세대 22TB/세 별 차이가 안 나는 수준인 거죠. 2027년에는 HBM 공급 자체가 빠듯할 가능성이 높기 때문에이 차이가 실제 추화량으로 이어질 수도 있습니다. 트렌드 포스는 HBM 비트 공급이 내년에 50%에서 60%가 늘어나더라도 수요 증가를 따라가기 어려울 것으로 보고 있는데요.

엔비디아 역시도 루빈 울트라에서 원래 12단 HBM뿐만이 아니라 8단 HBM 4랑 8단 HBM 42처럼 용량을 낮춘 구성까지 검토하고 있다고 하는데요. 그 이유 중에 하나가 제한된 디램 웨이퍼로 더 많은 GPU를 생산을 하기 위해서입니다. 그러니까 삼성 같은 메모리 업체가 핀 속도를 많이 올려 놓으면 엔비디아 입장에서는 반드시 12단 HBM을 최대 용량으로 달지 않아도 되겠죠. 8단으로 적량을 줄이고 부족해진 용량 대신에 속도로 필요한 대역폭을 맞추는 그런 방법이 생기는 거예요. 삼성이 HBN4에서 11.7GBS를 7GBS를 넘어 가지고 13GBS까지 계속 강조해 왔던 거를 이런 관점에서도 볼 수 있다는 말입니다. GTC 타이페이에서 젠슨 황이 베라 루빈을 설명을 할 때 GPU 하나만 이야기하지 않았죠. 루빈 GPU랑 베라 CPU, MB링크, 네트워크, HPM4 그리고 전력이랑 냉각을 묶은 멀티렉 시스템 전체를 하나의 컴퓨터처럼 설명을 했습니다. 특히 에이젠틱 AI에서는 에이전트가 거대한 컨텍스트를 들고 여러 단계를 반복을 하기 때문에 루빈 자체를 처음부터 그런 형태의 시스템으로 설계를 했다고 강조를 했어요.

그래서 어느 한 부품의 조건이 바뀌면 전체 시스템 안에서 다른 구성을 다시 계산을 해 볼 수가 있습니다. 더 빠른 HBM이 안정적으로 나오면 적층수를 낮출 수도 있고요. 프리필이 예상보다 훨씬 큰 작업으로 성장을 하면 별도의 CPX를 다시 붙이는 선택도 가능하겠죠. 실제로 CPX가 처음 공개됐을 때랑 지금 와서 AI를 쓰는 형태도 꽤 달라졌으니까요. 기존 채포에서는 사용자가 질문을 주면 입력을 한번 읽고 답변을 만들면 됐는데 지금 코딩 에이전트는 코드 저장소를 읽고 검색하고 툴 호출하고 로그를 다시 읽고 또 코드 수정한 다음에 테스트하고 필요하면 서브 에이전트까지 다시 띄우게 되죠. 엔비디아도 GTC 타이에서 에이젠틱 AI가 거대한 컨텍스트를 관리를 하고 여러 에이전트를 동원하는 그런 작업이라고 설명을 했어요. AI가 처음 들어온 긴 컨텍스트를 한꺼번에 처리하는 과정이 프리필이죠. 이때 이후 답변 생성에 계속 사용할 KB 캐시도 같이 만들어지는데요. 프리필은 원래 대규모 행렬 계산이 많아 가지고 연산 상능에 영향을 크게 받잖아요.

그래서 최초의 CPX는 30페타플럽면 연상기를 넣으면서도 비싼 HBM 대신에 128GB GDDR7으로 비용을 줄이는 방향이었습니다. 그런데 CPX 연산 성능을 일반 루빈 가까이에 올려 버리면 GDDR7 쪽도 그대로 둘 수 있을지가 좀 문제가 되는데요. 수십만에서 수백만 토큰을 한 번에 처리하면서 어텐션 계산을 돌리고 그다음에 KB캐시까지 만들어야 되는데 이게 연상기만 크게 키우고 메모리 공급 속도가 따로오지 못하면 비싼 연산기가 데이터를 기다리는 시간이 늘어나겠죠. 그러면 CPX는 처음 공개했던 그 저비용 프리필 GPU보다 거대한 컨텍스트를 최대한 빨리 처리하는 그런 전용 GPU에 가까워져 버립니다. 역할이 이렇게 갈리면 루빈이랑 CPX의 HBM 구성도 같을 필요가 없어요. 디코드를 계속 수행하는 루빈은 모델 가중치랑 여러 사용자의 KB캐시를 오래 들고 있어야 되니까 288GB라는 큰 용량이랑 22T바세컨드 대역폭이 둘 다 필요하겠죠. 근데 CPX는 긴 입력을 빠르게 처리해 가지고 KB를 만든 다음에 그 결과를 루빈으로 그냥 넘겨 주는 역할이라면 288GB바까지 들고 있을 필요는 줄어들게 될 거예요.

대신에 프리필 연상기가 기다리지 않도록 대역폭은 높아야 되겠죠. 루비는 모델이랑 KB를 오래 들고 있어야 되니까 용량까지 커야 되고 CPX는 용량을 좀 포기하더라도 프리피를 밀어붙일 그런 대요폭을 확보하는 그런 식인 겁니다. 밍치거가 전환 구조에서도 CPX가 프리필이랑 KB캐시 생성을 막고 루빈이 디코드를 수행을 하고 둘 사이에서 KB를 이단의 RDMA로 넘긴다고 합니다. 엔비디아가 루빈이랑 CPX를 1대 1 정도로 구성을 하는 그런 방안을 권장한다는 내용까지 포함이 되어 있어요. 기존에 루빈 한 개가 긴 프리필이랑 디코드를 계속 같이 수행을 하면 누군가가 엄청나게 긴 코드나 문서를 넣었을 때 큰 프리필 연산이랑 이미 진행 중인 디코드가 같은 GPU 자원을 공유를 하게 되겠죠. 근데 프리필을 CPX로 빼내면 CPX가 긴 입력을 처리를 하고 KB를 만들어서 넘기는 동안에 루비는 그냥 답을 생성하는 작업에 더 집중을 할 수 있는 거죠. HB 공급량까지 계산을 하면 결과도 꽤 다른데요. 프리필이랑 디코드에 일반 루빈을 각각 하나씩 사용을 한다고 그냥 아주 단순하게 가정을 하면 필요한 HBM은 288GB + 288GB 그러니까 총 576GB예요.

하나를 168GB CPX로 바꿔 버리면 168GB에다가 288GB니까 총 456GB가 되겠죠? 약 21%가 적어지는 거예요. 디램 다이 숫자도 루빈 두 개라면은 192개인데 루빈 하나랑 우리가 가정한 그 CPX 하나면 152개가 되는 거고요. 그러니까 같은 HBM 생산량으로 구성할 수 있는 시스템 숫자를 늘릴 여지가 생기게 되는 겁니다. 반대로 원래 루빈 한 개만 사용하던 시스템 옆에 CPX가 그냥 추가되는 형태라면 계산은 좀 달라질 것 같은데요. 168GB가 추가되니까 HBM 사용량은 58%가 증가를 하고요. 그래서 CPX의 HBM 4 채택을 곧바로 그냥 HBM 수요 58% 증가 이렇게 말하기는 좀 어렵습니다. 실제로는 CPX가 루빈을 대신을 하는 비율이랑 기존 루빈 옆에 새로 붙는 비율 그리고 프리필 비용이 낮아지면서 전체 AI 서버 설치량이 얼마나 늘어나는지가 같이 결정을 하게 되겠죠. 지난해까지만 해도 엔비디아는 프리필 GPU에서 HBM 비용을 피하려고 했거든요. 그 영역에 HBM4가 들어온다면 HBM이 필요한 출론 영역 자체가 넓어지는 셈이에요.

현재 삼성전자가 CPX용 HBM을 공급한다는 정보는 없습니다. SK 하이닉스도 역시 11.7GBS의 HBM 4를 공개를 했고요. 루빈 공급망에서 강한 위치를 가지고 있죠. 엔비디아도 루빈용 HBM4 공급사로 삼성전자랑 SK 하이닉스 마이크론을 모두 언급을 했고요. 그래서 우리가 삼성 HBM4의 13GBS를 볼 때도 최고 속도 숫자만 볼 필요는 없어요. 엔비디아처럼 GPU랑 HBM을 포함한 시스템 전체를 동시에 설계하는 회사에서는 더 빠른 HBM 덕분에 적층수를 낮추고도 목표 대역표를 맞출 수 있는 그런 여유가 생기는 거죠. CPX 168GB 루머가 정확하고 이게 실제로 8단 HBM4를 활용을 하는 구조라면은 그 효과를 아주 보기 좋게 보여주는 그런 제품이 될 수 있을 것 같습니다. 삼성전자가 HBM4에서 그렇게 속도에 집착을 했던 거를 그냥 뭐 이번에는 성능으로 하이닉스를 좀 따라잡겠다 이런 정도로만 볼 필요가 없는게 속도를 충분히 확보하면 더 적은 메모리로도 시스템이 원하는 대역폭을 만들 수 있고 HBM이 부족해질수록 그런 설계 여유는 돈이랑 출화량으로 바로 연결이 될 수 있으니까 그랬겠죠.이 이 공급망 정보가 진짜 맞는지를 볼 수 있는 가장 가까운 대형 행사가 10월에 있는 GTC 베를린입니다.

엔비디아는 10월 20일부터 22일까지 베를린에서 GTC를 열고 젠슨 황이 21일 직접 키노트를 하는데요. 공식 행사 소개에도 새로운 발표가 있을 거를 명시를 하고 있어요. 현재 행사 프로그램에 루빈 CPX라든가 168GB HBM4가 적혀 있는 건 아닌데요. 그래도 베를린에서 CPX가 나온다면 저는 HBM4 채택 여부보다는 사양 전체를 같이 한번 봐 볼 것 같습니다. 예를 들면 30페타플롭스랑 128GB GDDR7이 그대로인지 아니면 루빈급 연산 성능이랑 168GB HBM4로 바뀌었는지 에러 님이 예전에 GTC 타이에서 직접 물어봤을 때만 해도 현재는 CPX를 고려하지 않는다고 했던 엔비디아가 정말 몇 달 만에 그 설계를 다시 꺼냈는지도 진짜 확인을 할 수 있겠죠. 그리고 그 168GB가 적은 용량의 고속 HBM으로 루빈급 대역폭을 만드는 구성인지까지 확인이 되면 이번 공급망 정보의 기술적인 그림도 상당 부분 맞춰질 것 같습니다. 그때 우리는 삼성의 13GBS라는 숫자도 다시 한번 볼 필요가 있을 것 같아요.

더 많은 HBM을 갖다 붙이는 것만이 성능을 높이는 방법은 아니니까요. 그럼 오늘은 여기까지 패치였습니다.