저희가 가장 자주 받는 질문 중 하나는 Cerebras의 웨이퍼 규모 칩(wafer-scale chips)에 대규모 모델을 어떻게 배포하느냐입니다. 단일 Cerebras WSE-3T 웨이퍼는 44 GB의 온칩 메모리(on-chip memory)를 가지고 있지만, 조 단위 매개변수(trillion-parameter) 프론티어 모델은 가중치(weights)만 해도 테라바이트(terabytes)가 필요합니다.
본 게시물에서는 대규모 프론티어 모델을 여러 WSE-3T 웨이퍼에 분할하여, 수조 매개변수 규모의 모델을 초당 1000~2000 토큰 이상으로 구동하는 방법을 설명하겠습니다.
예시로 약 3조 개의 매개변수를 가진 오픈 소스 모델 Kimi K3를 사용합니다.
이 글을 끝까지 읽으면 다음 내용을 이해하게 될 것입니다:
- 전체 모델을 온칩 메모리에 어떻게 적재하는지
- 모델을 여러 칩에 어떻게 매핑하는지
- 높은 수의 동시 요청(concurrent requests)을 어떻게 처리하는지
Kimi K3를 이용한 분석
Kimi K3는 69개의 선형 어텐션 레이어(linear-attention layers)와 24개의 밀집 레이어(dense layers)를 가진 3조 매개변수 규모의 오픈 소스 모델입니다.
이 모델은 Terminal-Bench 2.1에서 88.3%라는 인상적인 점수를 기록했으며 (GPT-5.6 Sol의 88.8% 대비), BrowseComp에서는 91.2%를 달성했습니다 (GPT-5.6 Sol의 90.4% 대비). 이러한 결과는 일부 벤치마크에서 선도적인 독점 모델(proprietary models)을 능가하는 프론티어 수준의 코딩 및 에이전트적 역량(agentic capabilities)을 입증합니다. Kimi K3에 대한 더 자세한 내용은 여기를 참조하십시오.
이 예시를 위해 저희는 다음 가정을 사용했습니다:
-
평균 요청 크기 256k
-
4비트 가중치 양자화(weight quantization) (Hugging Face 구현과 유사)
-
8비트 KV 캐시(KV cache)
-
밀집 레이어(Dense layers)는 각 밀집(전체 어텐션, full-attention) 레이어가 모든 활성 요청의 모든 토큰에 대한 키와 값(keys and values)을 저장하기 때문에 KV 캐시를 위해 추가 공간이 필요합니다. 따라서 우리는 웨이퍼당 하나의 밀집 레이어를 배치하고 나머지 SRAM은 해당 레이어의 KV 캐시에 남겨둡니다.
-
선형 어텐션 레이어(Linear-attention layers)는 KV 캐시를 위해 추가 공간을 요구하지 않습니다. 이 레이어는 모든 토큰에 대한 키와 값을 저장하는 대신, 컨텍스트 길이에 관계없이 요청당 작고 고정된 크기의 상태만 유지합니다. 이는 웨이퍼당 두 개의 선형 레이어를 배치할 수 있는 공간을 남깁니다(2 × 16 GB = 32 GB).
따라서 Kimi K3의 69개 선형 레이어와 24개 밀집 레이어를 사용하면 다음과 같습니다:
이를 통해 총 웨이퍼 수는 35 + 24 = 59개의 웨이퍼가 됩니다.
#3: 웨이퍼 연결하기 (Connecting the wafers together)
Cerebras는 모델을 파이프라인(pipeline) 방식으로 실행합니다. Cerebras 컴파일러가 웨이퍼 영역 전반에 걸쳐 모델 레이어를 매핑한 후, 런타임(runtime)은 토큰이 웨이퍼 간에 흐르는 경로를 매핑합니다. 초고속 지연 시간(ultrafast latency)을 위해 활성화 값(activations)만 웨이퍼 간에 전달되면 되며, 이는 Ethernet을 통한 RDMA 방식으로 수행할 수 있습니다. 이는 홉당 약 2 마이크로초입니다.
각 Cerebras 웨이퍼가 44GB의 온칩 SRAM(on-chip SRAM)을 가지고 있고 각 레이어가 단지 16GB에 불과하기 때문에, 일반적으로 모델 전체 레이어를 칩에 직접 적재할 수 있다는 점을 강조하는 것이 중요합니다.
이는 대부분의 경우 모델 가중치(model weights)가 이동할 필요가 없고, 레이어를 웨이퍼 전반에 걸쳐 분할할 필요가 없다는 것을 의미합니다. 오직 활성화 값만 한 웨이퍼에서 다음 웨이퍼로 교차됩니다.
#4: 요청 1건 처리 방식 (How we serve 1 request)
이제 웨이퍼들이 연결되고 모델이 배치되었으므로, 각 웨이퍼를 조립 라인의 한 단계로 생각할 수 있습니다: 각 단계의 모델 가중치는 제자리에 머무르고, 요청의 중간 결과물(intermediate results)이 레이어 단계를 거쳐 이동합니다.
예를 들어, 웨이퍼 1은 모델 레이어 12를 실행하고 활성화 값을 웨이퍼 2로 보냅니다. 웨이퍼 2는 레이어 34를 실행하고 그 결과를 웨이퍼 3으로 전달하며, 마지막 웨이퍼가 다음 토큰을 생성할 때까지 이 과정이 반복됩니다.
#5: 다수의 요청 처리 방식 (How we serve many requests)
이것은 흔한 오해를 불러일으킵니다. 토큰이 순서대로 각 웨이퍼를 통과해야 한다면, 각 웨이퍼는 차례를 기다리며 유휴 상태에 있지 않을까요? 사실상 시스템은 배치 크기(batch size)가 1로 작동하지 않을까요?
아닙니다! 만약 우리가 한 번에 하나의 요청만 파이프라인으로 보내고 다음 요청을 시작하기 전에 그것이 완료되기를 기다린다면, 이는 파이프라인의 비효율적인 사용이 될 것입니다. 대신, 우리는 전체 파이프라인을 다양한 요청들로 가득 채웁니다. 모델이 이미 파이프라인 단계(pipeline stages)로 분할되어 있기 때문에, 각 단계는 동시에 서로 다른 요청을 처리할 수 있습니다.
단계 3이 요청 A의 토큰을 처리하는 동안, 단계 2는 요청 B의 토큰을 처리하고, 단계 1은 요청 C의 토큰을 처리합니다. 저희 예시에서 각 단계는 레이어(layer)입니다. 실제 생산 환경에서는 Cerebras가 훨씬 더 세분화된 단계와 훨씬 더 많은 단계를 사용합니다.
각 단계는 또한 단일 요청 대신 작은 그룹의 요청인 **마이크로 배치(micro-batch)**를 처리할 수도 있습니다. 따라서 비행 중인 요청(requests in flight)의 수는 대략 단계 수 곱하기 마이크로 배치 크기가 됩니다.
이러한 트레이드오프(tradeoff)를 이해하려면, 더 작은 마이크로 배치는 각 요청을 더욱 빠르게 만들고, 더 큰 마이크로 배치는 전체 처리량(total throughput)을 증가시킵니다.
#6: 얼마나 많은 요청을 처리할 수 있나요?
많이
온칩 메모리(on-chip memory)에 할당된 KV 캐시(KV cache) 용량이 동시 요청의 최대 개수를 결정합니다. 비행 중인 모든 요청은 각 밀집 레이어 웨이퍼(dense-layer wafer)에서 자체 KV 캐시를 필요로 하므로, 온칩 메모리 크기가 동시 요청의 상한선을 설정합니다. 위에서 설명했듯이, 우리는 밀집 레이어에 대한 KV 캐시 요구 사항만 계산하면 됩니다.
이미 하나의 밀집 레이어를 가지고 있는 44 GB 웨이퍼의 경우, 다음 공식을 사용하여 KV 캐시를 위한 남은 공간을 계산할 수 있습니다:
총 웨이퍼 저장 용량 - 단일 밀집 레이어 크기. 이 경우:
동시 요청 개수 계산하기
특정 모델 매핑에 대해 지원되는 동시 요청 수를 찾으려면, 먼저 256k 요청 하나가 얼마나 많은 캐시를 차지하는지 계산해야 합니다:
이 구성을 통해 지원할 수 있는 총 동시 요청 수를 계산하기 위해, 우리는 다음과 같이 나눕니다:
총 동시 요청 수는 특정 시점에 파이프라인을 통과하는 동시 요청의 수를 나타냅니다. GPU 배치와 달리, 이러한 요청들은 서로 완료되기를 기다리지 않고 파이프라인을 지속적으로 스트리밍합니다.
물론, 동시성(concurrency)이나 배치 크기(batch size)만으로는 추론 시스템이 얼마나 효율적으로 작동하는지 정확히 알려주지 않습니다. 추론 시스템의 처리량(throughput)을 평가할 때, 가장 의미 있는 지표는 동일한 출력 생성 속도에서 측정된 단위 전력당 총 토큰 처리량(예: 메가와트당 초당 토큰 수)입니다.
3조 개 매개변수를 넘어 확장하는 방법
동일한 접근 방식은 더 큰 모델에도 확장됩니다: 가중치(weights)와 요청 상태(request state)에 필요한 메모리를 계산하고, 모델을 웨이퍼(wafers) 전반에 분산시킨 다음, 이를 파이프라인으로 연결합니다. 추가되는 각 웨이퍼는 컴퓨팅 능력과 온칩 메모리(on-chip memory)를 제공하여, 단일 칩의 용량을 초과하는 모델도 수용할 수 있게 합니다.
저희와 함께 학습해 주셔서 감사합니다! Cerebras에 모델을 배포하거나 당사의 추론 클라우드(inference cloud)로 구축하는 데 관심이 있으신가요?
디자인: Halley Chang. 검토 및 피드백에 감사드립니다: Atharva Talpade, Zhenwei Gao, Angela Yeung, Jessica Liu, Joyce Er, Emma Call, 그리고 Rohan Gupta.