콘텐츠로 이동

하드웨어

개요

이 문서는 Rebel100™에 Coding Assistant를 배포하는 데 필요한 하드웨어와 각 요구 사항의 근거를 설명합니다.

이 페이지의 상태 배지는 레퍼런스 디자인 › 상태 배지를 따릅니다. 배지가 없는 설명은 Validated 상태가 아닙니다.

구분 구성 상태
대상 RebelRack™(서버 4대와 스위치, 부대 장비), 총 32개 NPU, 4P4D(노드마다 prefill 인스턴스 1개와 decode 인스턴스 1개) Validated

RebelRack™이 제품 도입 단위이므로 Target Configuration은 4개 노드를 기준으로 설명하고 검증했습니다.

요구 사항 요약

다음 요구 사항은 서버 모델과 관계없이 충족되어야 합니다. 각 요구 사항의 근거는 다음 절과 Kubernetes 배포에서 설명합니다.

요구 사항 값 상세 설명
인스턴스당 NPU prefill과 decode 모두 RBLN-CR13 카드 4개 인스턴스당 카드 4개를 사용하는 이유
인스턴스당 RoCE NIC 인스턴스의 NPU 4개와 같은 NUMA 노드에 있는 RoCE NIC 2개. 전송에는 하나를 사용하며 나머지는 NIC 장애 후 사용할 예비 NIC입니다. 네트워크, NIC 장애 시 동작, 디바이스 할당
P/D 연결 모든 prefill 인스턴스에서 모든 decode 인스턴스로 노드 내부 및 노드 간 RDMA 연결 가능 네트워크
Rebellions Direct Storage(RDS)용 로컬 NVMe RDS를 사용하는 Pod가 실행되는 노드의 파일시스템이 없는 raw NVMe. P/D에서는 prefill Pod가, AGG에서는 decode Pod가 RDS를 사용합니다. 파일시스템과 RDS는 한 디스크를 공유할 수 없습니다. 스토리지, 노드 준비 › RDS 설정
공유 스토리지 Pod가 여러 노드에 걸쳐 실행될 때 모델 가중치(250 GB 이상)와 컴파일 캐시(P/D role별 200Gi)용 ReadWriteMany StorageClass 스토리지, 볼륨
노드 메모리와 CPU modelserver Pod당 메모리 630Gi와 CPU 코어 40개입니다. 각 노드에는 라우팅 사이드카, EPP, 게이트웨이를 포함해 배치한 Pod의 합계와 여유 용량이 필요합니다. 리소스 및 노드 예산

서버

각 노드는 RBLN-CR13 NPU 카드 8개를 탑재한 5U 섀시의 RebelServer™입니다.

항목 값
폼 팩터 5U
NPU 카드 노드당 8개
CPU 2 x AMD EPYC 9355(32C/64T, 3.55 GHz, 280 W)
DRAM 1.5 TB(24 x 64 GB DDR5)
로컬 스토리지 OS 1.92 TB NVMe x 2, 데이터(KV 캐시) 1.92 TB NVMe x 2
네트워크 4 x 400G QSFP112-DD 1-port, 1 x 100G QSFP56 2-port, 1 x 10G/25G SFP28 2-port(OCP 3.0)
PCIe 세대 Gen5(카드당 2 x PCIe Gen5 x16)
전원 공급 장치 6 x 2,700 W
소비 전력 일반 4 kW, 최대 7 kW
작동 온도 10 °C~35 °C

랙 구성

Target Configuration은 이 서버 4대를 탑재한 42U 공랭식 랙 1개로, RebelRack™ NPU 랙에 해당합니다.

항목 값
서버 4 x RebelServer™(5U)
NPU 카드 32개
CPU 8 x AMD EPYC 9355(256C/512T)
시스템 메모리 6 TB DDR5
NPU 메모리 총 4.61 TB, HBM 대역폭 합계 153.6 TB/s
연산 성능 64 PFLOPS(FP8), 32 PFLOPS(FP16)
백엔드 패브릭 400G QSFP112-DD
냉각 공랭식, 최대 105,094 BTU/hour
소비 전력 최대 28 kW
크기 42U, 1,991 mm(H) x 600 mm(W) x 1,200 mm(D)

NPU 랙과 함께 제공되는 관리 랙은 별도 장치이며 이 문서의 서빙 용량에 포함되지 않습니다.

NPU 카드

RBLN-CR13에는 Rebel100™ 칩 1개가 탑재됩니다.

항목 값
아키텍처 UCIe-Advanced 기반의 동종 칩렛 4개로 구성된 SoC
연산 성능(dense) 1,024 TFLOPS(FP16), 2,048 TFLOPS(FP8)
HBM 용량 144 GB(HBM3E)
HBM 대역폭 4.8 TB/s
칩렛 인터페이스(UCIe-A) 16 Gbps, 채널당 1 TB/s
호스트 연결 2 x PCIe Gen5 x16(64 GB/s + 64 GB/s)
소비 전력 최대 600 W

칩렛 4개는 칩 전체를 연결하는 단일 메시로 구성됩니다. 채널당 양방향 대역폭은 1 TB/s, 지연 시간은 11 ns이며 하나의 가상 다이처럼 동작합니다. 소프트웨어가 제어하는 예측 DMA 엔진은 이 메시를 통해 KV 데이터를 미리 로드하며 유효 대역폭은 약 2.7 TB/s입니다.

인스턴스당 카드 4개를 사용하는 이유

필요한 디바이스 수는 모델에 따라 결정됩니다. MiniMax-M2.7의 FP8 체크포인트는 약 234 GB이고 카드당 HBM은 144 GB이므로 카드 1개에 로드할 수 없습니다. 카드 2개면 가중치를 저장할 수 있지만 KV 캐시, 활성값, 컴파일 런타임도 같은 HBM을 사용하므로 인스턴스 단위를 카드 4개로 정했습니다. 카드 4개를 사용하면 카드당 가중치가 약 59 GB로 줄어 나머지 용량을 KV 캐시에 할당할 수 있습니다.

카드 4개에 가중치를 분산하는 방식은 prefill과 decode가 다릅니다. prefill은 PP4로 레이어를 4부분으로 나누고 decode는 expert parallel을 적용한 DP4로 expert를 분산합니다. 자세한 내용은 서빙 설정에서 확인할 수 있습니다.

네트워크

항목 값 상태
NIC 노드당 400 Gbps NIC 4개(NUMA 노드당 2개)
전송 방식 RoCE v2
NIC 선택 nixl-rbln이 NUMA-local NIC 1개를 선택 Validated
P/D 연결 서로 다른 subnet의 NIC을 포함해 모든 P/D 쌍 연결 가능 Validated

KV 전송은 노드 내부와 노드 간에 모두 발생하므로 라우터가 자유롭게 쌍을 구성하려면 모든 P/D 쌍이 서로 연결될 수 있어야 합니다.

노드당 NIC이 4개 있더라도 단일 프로세스는 NUMA-local NIC 1개를 사용합니다. 따라서 KV 전송 대역폭의 상한은 노드 전체의 1.6 Tbps가 아니라 인스턴스당 400 Gbps로 계산해야 합니다. 서비스 구동 시 각 인스턴스는 NUMA-local NIC 2개를 요청합니다. 두 번째 NIC은 정상 운영 중에는 트래픽이 흐르지 않는 예비 디바이스입니다. NIC 장애가 발생하면 엔진이 재시작 없이 정상 NIC으로 전송을 전환할 수 있도록 확보합니다(NIC 장애 시 동작 참고).

항목 값
ISL 50K 요청의 KV 전송량 약 6 GB
400 Gbps일 때 이론적 최소 시간 약 130 ms

이론적 최소 시간은 앞의 두 값과 Rebel100™ 기반 Coding Assistant › KV 캐시 크기의 토큰당 크기를 기준으로 계산합니다(50,000 토큰 × 124 KiB = 5.9 GiB; 5.9 GiB × 8 bit / 400 Gbps ≈ 127 ms). 프로토콜 오버헤드나 전송 시작 지연은 포함하지 않습니다.

NIC 장애 시 동작

NIC 장애가 발생하면 엔진은 재시작하지 않고 인스턴스가 요청한 두 번째 NUMA-local NIC으로 전송을 전환합니다. 전환 중 요청이 어떻게 처리되는지, 장애별 측정 결과, link_down_exit_s 옵션은 장애 대응 › RoCE NIC 장애에 설명합니다.

스토리지

용도 요구 사항 비고
모델 가중치 약 234 GB, 250 GB 이상 권장 공유 볼륨에 미리 로드하는 것을 권장
컴파일 캐시 P/D role별 200Gi ReadWriteMany PVC prefill과 decode에 각각 필요
RDS(KV 오프로딩) RDS를 사용하는 Pod(P/D에서는 prefill, AGG에서는 decode)가 실행되는 노드의 raw NVMe. 캐시 용량은 청크 수로 제한됨(rds_max_chunks x LMCACHE_CHUNK_SIZE; 기본값에서 rank당 4,096,000 토큰). 서빙 설정 참고 Default configuration

가중치는 공유 볼륨에 미리 로드하는 것을 권장합니다. 모델 볼륨이 비어 있으면 시작 시 다운로드를 시도합니다. Secret 및 모델 저장소를 참고하세요.

RDS가 없는 Pod도 알림 없이 Ready 상태가 됩니다. 확인 방법은 서빙 설정 › LMCache와 RDS를 참고하세요.

컴파일 캐시는 최초 컴파일의 결과를 저장합니다. 측정 시간과 캐시 재사용 조건은 컴파일 캐시에 설명되어 있습니다.

용량 산정 지침

배포 용량은 카드 수보다 인스턴스 수를 기준으로 산정하세요. prefill 또는 decode 인스턴스마다 NPU 4개와 NIC 2개(활성 1개, 장애 전환용 예비 1개)가 필요하므로 하나의 RebelServer™에는 인스턴스 2개, 하나의 RebelRack™에는 인스턴스 8개를 배치할 수 있습니다.

P:D 비율을 변경하기 전에 성능을 먼저 측정하세요. TTFT, prefill과 decode 각각의 대기 요청 수, 모니터링의 prefix 캐시 hit 메트릭을 관찰하고 병목이 되는 P/D role의 용량을 늘리세요.

P:D 비율

구성 상태
4P4D Validated. 기본값
5P3D, 3P5D Validated

비율은 워크로드의 ISL/OSL 비율과 prefix hit 비율에 따라 결정합니다. 이 워크로드는 ISL 50K / OSL 1K로 prefill 비중이 크지만 Automatic Prefix Caching에서 hit이 발생하면 prefill 부하가 크게 줄어들므로 단순한 토큰 비율만으로 결정할 수 없습니다.

프롬프트의 80%가 캐시된 prefix인 검증 워크로드에서는 4P4D가 균형 잡힌 배치입니다. 그 양옆의 두 배치는 동시성이 높아질 때 각각 다른 리소스가 먼저 한계에 도달합니다.

  • 5P3D는 decode 용량이 부족해집니다. decode 인스턴스가 거의 가득 찬 상태를 유지하며 prefill에 여유가 있어도 요청은 decode 슬롯이 비기를 기다립니다.
  • 3P5D는 prefill 용량이 부족해집니다. decode 슬롯 일부가 비어 있는 동안 요청은 prefill 큐에서 기다립니다.
  • 4P4D는 동시성 64까지 두 한계에 도달하지 않습니다. 동시성 128에서는 prefill 인스턴스도 포화됩니다. 인스턴스 8개를 어떻게 나누어도 이 부하를 처리할 수 없으며 인스턴스를 추가하면 도움이 되지만 비율을 변경해도 도움이 되지 않습니다.

prefix caching을 사용하지 않으면 prefill이 프롬프트 전체를 계산하므로 요청당 작업이 약 3배 늘어납니다. 이때는 prefill이 부족한 리소스가 되므로 5P3D처럼 prefill 인스턴스가 더 많은 배치가 같은 워크로드를 4P4D보다 잘 처리합니다.

prefill과 decode 중 어느 쪽이 배포 용량을 제한하는지 확인하려면 prefill 인스턴스와 decode 인스턴스의 큐 대기 시간(vllm:request_queue_time_seconds)을 비교하면 됩니다. prefill이 포화되어도 요청당 prefill 계산 시간은 늘어나지 않습니다. 포화는 큐 대기 시간으로만 드러납니다.