TECH 으로 돌아가기
TECH HACKER NEWS 8분 읽기 30 READS

웨이퍼 59장으로 3조 파라미터 모델을 돌리는 법: 체레브라스의 파이프라인 전략

웨이퍼 59장으로 3조 파라미터 모델을 돌리는 법: 체레브라스의 파이프라인 전략
SOURCE IMAGE · HACKER NEWS

대형 언어모델을 실제 서비스로 띄워본 엔지니어라면 가장 먼저 부딪히는 벽이 메모리다. 모델 파라미터가 조 단위로 늘어나면 가중치만으로도 테라바이트급 저장 공간이 필요한데, 칩 한 장에 올릴 수 있는 메모리는 그 발끝에도 미치지 못한다. 체레브라스(Cerebras)는 자사 블로그에서 이 질문, 즉 '웨이퍼 한 장에 44GB뿐인 온칩 메모리로 어떻게 조 단위 모델을 돌리느냐'에 대한 답을 공개했다. 핵심은 하나의 거대한 칩에 모델을 욱여넣는 것이 아니라, 여러 장의 WSE-3T 웨이퍼에 모델을 쪼개어 '조립 라인'처럼 연결하는 방식이다.

설명을 위해 체레브라스가 든 예시는 오픈소스 모델 Kimi K3다. 약 3조(3T) 파라미터 규모로, 69개의 선형 어텐션(linear-attention) 레이어와 24개의 밀집(dense) 레이어로 구성된다. 체레브라스가 제시한 벤치마크에 따르면 이 모델은 Terminal-Bench 2.1에서 88.3%(GPT-5.6 Sol은 88.8%), BrowseComp에서 91.2%(GPT-5.6 Sol은 90.4%)를 기록했다. 코딩과 에이전트 작업에서 일부 상용 모델에 필적하거나 앞서는 수준이라는 것이 회사 측 주장이다. 중요한 것은 이 글이 모델 성능 자랑이 아니라, 이런 규모의 모델을 하드웨어에 어떻게 물리적으로 배치하는지를 설명하는 데 있다는 점이다.

레이어 단위로 쪼개 웨이퍼에 올린다

계산의 출발점은 레이어 하나의 크기다. 3조 파라미터를 4비트 정밀도로 저장하면 전체 가중치 용량이 나오고, 이를 93개 레이어로 나누면 레이어당 약 16GB가 된다. 웨이퍼 한 장의 온칩 메모리가 44GB이므로, 레이어 하나(16GB)는 웨이퍼에 통째로 올라간다. 바로 이 지점이 체레브라스가 강조하는 구조적 이점이다. 레이어를 여러 칩에 다시 쪼갤 필요 없이 하나의 웨이퍼 위에 온전히 올릴 수 있어, 가중치는 자리에서 움직이지 않는다. 레이어 유형에 따라 웨이퍼당 수용량이 달라지는데, 선형 레이어 69개는 35장, 밀집 레이어 24개는 24장에 배치되어 총 59장의 웨이퍼가 필요하다는 계산이 나온다.

웨이퍼들이 연결되면 각 웨이퍼는 조립 라인의 한 공정이 된다. 1번 웨이퍼가 모델의 앞쪽 레이어를 처리한 뒤 그 결과값(activation)을 2번 웨이퍼로 넘기고, 2번은 다음 레이어를 처리해 3번으로 넘기는 식으로 마지막 웨이퍼가 다음 토큰을 만들어낸다. 이때 웨이퍼 사이를 오가는 것은 무거운 가중치가 아니라 가벼운 활성값뿐이며, 전송은 이더넷 기반 RDMA로 이뤄진다. 체레브라스는 이 홉(hop) 하나당 지연이 약 2마이크로초 수준이라고 밝혔다. 가중치가 메모리와 연산 유닛 사이를 끊임없이 왕복하는 기존 GPU 방식과 달리, 가중치를 제자리에 고정한다는 것이 이 설계의 근본 차이다.

'배치 사이즈 1' 오해를 푸는 열쇠, 파이프라인

여기서 실무자들이 흔히 품는 의문이 있다. 토큰이 웨이퍼를 순서대로 통과해야 한다면, 각 웨이퍼는 자기 차례를 기다리며 놀고 있는 것 아닌가. 그렇다면 사실상 배치 사이즈 1로 돌아가는 비효율적인 시스템 아닌가. 체레브라스의 답은 '아니다'이다. 요청 하나를 끝까지 흘려보낸 뒤 다음 요청을 시작하는 것이 아니라, 파이프라인 전체를 서로 다른 요청으로 가득 채우기 때문이다. 3번 공정이 요청 A를 처리하는 동안 2번 공정은 요청 B를, 1번 공정은 요청 C를 동시에 처리한다. 각 공정은 요청 하나가 아니라 소규모 묶음인 마이크로배치를 처리할 수도 있어, 동시에 처리되는 요청 수는 대략 '공정 수 × 마이크로배치 크기'가 된다. 마이크로배치를 작게 하면 개별 요청이 더 빨라지고, 크게 하면 전체 처리량이 올라가는 트레이드오프가 존재한다.

동시 요청 수의 상한을 결정하는 것은 KV 캐시다. 모든 진행 중 요청은 밀집 레이어 웨이퍼마다 자기 몫의 KV 캐시를 가져야 하므로, 남는 온칩 메모리의 크기가 동시 처리 가능한 요청 수의 천장을 정한다. 밀집 레이어 한 개를 올린 44GB 웨이퍼에서 레이어가 차지하고 남은 공간이 KV 캐시로 쓰이고, 256k 길이 요청 하나가 차지하는 캐시 용량으로 그 공간을 나누면 해당 구성이 지원하는 동시 요청 수가 산출된다. GPU 배치와 달리 이 요청들은 서로가 끝나기를 기다리지 않고 파이프라인을 따라 끊임없이 흘러간다는 점이 특징이다. 체레브라스는 실제 운영 환경에서는 예시보다 훨씬 잘게 나뉜 더 많은 공정을 사용한다고 덧붙였다.

실무자가 눈여겨볼 지점과 한계

이 글이 던지는 실무적 메시지 중 하나는 성능 평가 지표에 관한 것이다. 체레브라스는 동시성(concurrency)이나 배치 크기만으로는 추론 시스템의 효율을 제대로 가늠할 수 없다고 지적한다. 같은 토큰 생성 속도 조건에서 측정한 '전력당 토큰 처리량', 예컨대 메가와트당 초당 토큰 수가 더 의미 있는 지표라는 것이다. 초당 1,000~2,000개 이상의 토큰이라는 숫자도 결국 이 전력 효율 맥락에서 읽어야 한다. 조 단위 모델의 운영 비용이 사실상 전력과 데이터센터 공간으로 수렴하는 현실을 고려하면, 벤치마크 점수보다 전력당 처리량을 비교 기준으로 삼으라는 조언은 설비를 설계하는 쪽에서 새겨둘 만하다.

다만 이 설명을 그대로 일반화하기 전에 짚어둘 한계가 있다. 블로그가 공개한 것은 어디까지나 체레브라스가 자사 장점을 가장 잘 드러내는 방식으로 재구성한 모델 배치 시나리오이며, 레이어당 16GB나 웨이퍼 59장 같은 수치도 특정 정밀도와 특정 모델 구조를 전제로 한 계산이다. 모델의 레이어 구성이나 양자화 방식이 달라지면 필요한 웨이퍼 수와 동시성은 크게 변한다. 또한 59장의 웨이퍼를 조달하고 운영하는 총비용, 웨이퍼 간 홉이 길어질수록 누적되는 지연, 장애 발생 시의 복원력 같은 실제 운영 변수는 이 글에서 다루지 않았다. 그럼에도 '가중치는 고정하고 활성값만 흘려보낸다'는 웨이퍼 스케일 접근의 논리 자체는, 메모리 대역폭에 발목 잡힌 추론 인프라를 고민하는 이들에게 참고할 만한 대안적 사고의 틀을 제공한다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://www.cerebras.ai/blog/how-we-deploy-trillion-paramete...
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...