Supermicro의 JumpStart 프로그램은 하드웨어 평가에 있어 완전히 새로운 접근 방식을 제시합니다. 공유 연구실 환경에서 정해진 스크립트에 따라 짧게 시연하는 대신, JumpStart는 자격을 갖춘 고객에게 실제 운영 서버 카탈로그에 대한 무료 시간 제한 액세스 권한을 제공합니다. Intel Xeon 6 프로세서가 탑재된 새로운 X14 플랫폼부터 5세대 AMD EPYC 및 대형 HGX GPU 구성이 적용된 H14 시스템에 이르기까지, 고객은 시스템을 예약하고 원격으로 로그인하여 마치 실제 장비가 자신의 랙에 있는 것처럼 워크로드를 실행할 수 있습니다.
신속하고 정보에 기반한 플랫폼 결정을 내릴 때 비즈니스 가치가 명확해집니다. AI 또는 고성능 컴퓨팅에 대한 현실적인 개념 증명을 구축하려면 일반적으로 평가 하드웨어를 기다리고, 여러 공급업체와 협력하고, 테스트 구성이 배포 계획에 충분히 근접하기를 바라야 합니다. JumpStart는 이러한 어려움을 해소합니다. 팀은 내부 랩 사이클을 소모하거나 전국에 서버를 대량으로 배송하지 않고도 성능을 검증하고, 소프트웨어 호환성을 확인하고, 전력 및 열 동작을 분석하고, 아키텍처를 비교할 수 있습니다. 대부분의 조직은 적절한 구성에 집중하는 일주일이면 플랫폼이 요구 사항에 맞는지 확인하거나, 실제로 사용하기 전에 배제하기에 충분합니다.
Supermicro JumpStart 출시 페이지
JumpStart를 특히 매력적으로 만드는 것은 온라인 시스템 수뿐만 아니라 Supermicro가 공개하려는 기술의 깊이입니다. 인기 있는 선택지로는 Intel Xeon 6 및 NVIDIA 가속기를 탑재한 X14 GPU 서버, 5세대 AMD EPYC를 탑재하여 고밀도 CPU 컴퓨팅에 최적화된 H14 플랫폼, 그리고 최신 CPU와 모든 NVMe 백엔드를 결합한 스토리지 중심 시스템 등이 있습니다. 하이엔드 시스템에서 Supermicro는 이미 AI 학습 및 추론을 위한 HGX B200 및 B300급 시스템에 대한 액세스를 제공하고 있으며, JumpStart를 사용하여 아직 광범위하게 출시되지 않은 차세대 플랫폼에 대한 NDA 기반 초기 정보를 제공합니다. 정식 출시 이전 인프라를 체계적이고 반복 가능한 원격 랩 환경으로 전환하는 데 이처럼 적극적인 OEM은 본 적이 없습니다.
대부분의 공급업체 데모 환경은 가이드 솔루션 랩이나 소규모 제품 샌드박스에 그칩니다. 이러한 환경은 관리 도구와 오케스트레이션 워크플로우를 익히는 데 유용하지만, 최상위 서버에 대한 루트 액세스나 자체 스택을 설치하고 실행할 수 있는 자유를 제공하는 경우는 드뭅니다. JumpStart는 원격 데이터 센터의 대여 랙과 매우 유사하게 작동합니다. 특정 시스템을 예약하면 예약 기간 동안 SSH, VNC, IPMI를 통해 완전한 제어권을 얻게 되며, Supermicro는 다음 고객이 사용하기 전에 환경을 삭제하고 재구축합니다. 실제로 이는 마케팅 데모라기보다는 잘 운영되는 원격 랩에서 짧고 집중적인 참여를 통해 진행되는 것과 같습니다.
Supermicro JumpStart X14 B200 시스템
이번 분석을 위해 Supermicro는 StorageReview에 고객이 실제로 경험하게 될 JumpStart 환경을 그대로 제공했습니다. 저희는 NVIDIA HGX B200 8-GPU 베이스보드와 듀얼 6세대 Intel Xeon Platinum 6960P 프로세서가 탑재된 X14 10U GPU 시스템을 사용 일정 을 예약했습니다. 서버는 3TB의 DDR5-6400 ECC 메모리, 로컬 스토리지용 M.2 및 U.2 NVMe SSD, 그리고 각각 180GB의 HBM3e를 장착한 8개의 B200 GPU로 구성되었습니다. 일주일 동안 이 플랫폼을 사용하여 AI 워크로드와 시스템 동작을 무작위로 점검하고, 차세대 인프라 도입을 고려하는 실제 구매자들이 궁금해하는 질문들에 집중했습니다.
Supermicro JumpStart 프로그램의 주간 일정
예약 창이 열리자 JumpStart 포털이 테스트의 중심 허브가 되었습니다. 아래에 표시된 초기 대시보드는 예약 일정을 설명하고 원격 Ubuntu 환경에 대한 SSH 자격 증명과 전체 IPMI 액세스를 포함하여 시작하는 데 필요한 모든 것을 제공했습니다. 두 인터페이스를 즉시 사용할 수 있게 되면서 프로비저닝이나 지원팀의 개입을 기다리지 않고도 몇 분 안에 시스템 검증을 시작할 수 있었습니다.
워크플로의 첫 번째 단계는 하드웨어가 준비되었는지 확인하는 것이었습니다. 포털의 시스템 개요 페이지(아래 스크린샷 참조)를 사용하여 섀시 전원이 켜져 있는지, 두 CPU가 모두 감지되었는지, 메모리가 완전히 채워졌는지, 그리고 BMC가 시스템 상태를 '녹색'으로 보고하는지 확인했습니다. 이러한 빠른 확인은 랩 평가에서 표준 관행이 되었으며, 포털을 통한 원격 가시성 덕분에 이 프로세스가 간소화되었습니다.
시스템 검증이 완료된 후, 실무 작업으로 전환했습니다. 테스트 자산의 파일 업로드는 JumpStart 인터페이스를 통해 직접 처리되었으며, 덕분에 원격 플랫폼에서 데이터 세트를 스테이징하는 데 따르는 일반적인 번거로움이 사라졌습니다. 이후 워크로드 배포를 위해 SSH를 통해 연결했고, 저수준 접근이나 부팅 동작 관찰이 필요할 때는 IPMI를 통해 원격 콘솔을 사용했습니다.
일주일 내내 진행된 워크플로는 저희 연구실의 장비 운영과 매우 유사했습니다. 워크로드를 빠르게 시작, 중지, 반복하고, 필요 시 플랫폼을 재부팅하고, Supermicro의 지원 없이도 하드웨어 동작을 모니터링할 수 있었습니다. OS 수준 접근과 완벽한 대역 외 제어 기능 덕분에 짧은 테스트 주기 동안 예측 가능하고 효율적인 환경을 구축할 수 있었습니다.
예약이 종료되면 시스템이 자동으로 복구 및 재설정되어 계약이 깔끔하게 종료되었습니다. 이러한 예측 가능한 구조 덕분에 물류 작업보다는 테스트에 집중할 수 있었고, 제한된 접근 시간을 최대한 활용할 수 있었습니다.
GPUDirect 스토리지 성능
Supermicro X14 플랫폼에서 수행한 테스트 중 하나는 Magnum IO GPUDirect Storage(GDS) 테스트였습니다. GDS는 NVIDIA에서 개발한 기능으로, GPU가 NVMe 드라이브 또는 기타 고속 저장 장치에 저장된 데이터에 액세스할 때 CPU를 우회할 수 있도록 합니다. GDS는 CPU와 시스템 메모리를 통해 데이터를 라우팅하는 대신, GPU와 저장 장치 간의 직접 통신을 지원하여 지연 시간을 크게 줄이고 데이터 처리량을 향상시킵니다.
GPUDirect 스토리지 작동 방식
전통적으로 GPU가 NVMe 드라이브에 저장된 데이터를 처리할 때, 데이터는 GPU에 도달하기 전에 먼저 CPU와 시스템 메모리를 거쳐야 합니다. 이 과정에서 CPU가 중개 역할을 하게 되어 병목 현상이 발생하고, 지연 시간이 늘어나고 귀중한 시스템 리소스가 소모됩니다. GPUDirect Storage는 GPU가 PCIe 버스를 통해 저장 장치의 데이터에 직접 액세스할 수 있도록 하여 이러한 비효율성을 제거합니다. 이러한 직접 경로는 데이터 이동 오버헤드를 줄여 더 빠르고 효율적인 데이터 전송을 가능하게 합니다.
AI 워크로드, 특히 딥러닝 관련 워크로드는 매우 데이터 집약적입니다. 대규모 신경망을 학습하려면 테라바이트급의 데이터를 처리해야 하며, 데이터 전송 지연은 GPU 활용도 저하 및 학습 시간 증가로 이어질 수 있습니다. GPUDirect Storage는 데이터가 GPU에 최대한 빠르게 전달되도록 보장하여 유휴 시간을 최소화하고 연산 효율성을 극대화함으로써 이러한 문제를 해결합니다.
또한 GDS는 비디오 처리, 자연어 처리 또는 실시간 추론과 같이 대용량 데이터 세트를 스트리밍하는 작업 부하에 특히 유용합니다. GDS는 CPU에 대한 의존도를 줄임으로써 데이터 이동을 가속화하고 다른 작업을 위한 CPU 리소스를 확보하여 전반적인 시스템 성능을 더욱 향상시킵니다.
GPUDirect는 원시 대역폭 외에도 NVMe-oF(TCP/RDMA)를 지원하여 초저지연 I/O를 제공합니다. 이를 통해 GPU가 데이터 부족 현상을 겪지 않도록 보장하여 실시간 AI 추론, 분석 파이프라인, 비디오 재생에 이상적인 시스템입니다.
GDSIO 읽기 순차 처리량
B200 플랫폼에서 GDSIO 순차 읽기 테스트를 진행했을 때, 단일 스레드가 블록 크기에 따라 약 14~15GiB/s의 처리량을 기록하며 워크로드가 완만하게 시작되었습니다. 스레드 수와 블록 크기를 모두 늘리자마자 성능이 빠르게 향상되었습니다. 스레드 수를 2~4개로 늘리자 처리량이 20~36GiB/s 범위로 증가하여 병렬 처리 도입 후 시스템 확장성이 얼마나 뛰어난지 보여주었습니다.
실제 가속은 스레드가 8개 이상에 도달했을 때 발생했는데, 이때 대부분의 워크로드는 30GiB/s 후반대에 안착했습니다. 블록 크기가 클수록 성능이 가장 크게 향상되었으며, 5M과 10M 블록 크기가 모든 스레드 수에서 꾸준히 높은 성능을 보였습니다.
처리량은 256개 스레드에서 10M 블록 크기로 최대 약 43GiB/s에 도달했으며, 이는 이 테스트에서 관찰된 가장 높은 지속적인 순차적 읽기 속도였습니다.
GDSIO 읽기 순차 지연 시간
지연 시간 측면에서, 워크로드는 매우 빠르게 반응하기 시작했으며, 작은 블록의 경우 단일 스레드 읽기 속도가 0.06~0.1ms 범위에 머물렀습니다. 스레드 수가 증가함에 따라 지연 시간은 점진적으로 증가하여 대부분의 워크로드에서 8스레드 지점까지 1ms 미만을 유지했습니다.
스레드 수가 16개를 넘어서자, 스토리지 경로가 포화 상태가 되면서 더 큰 블록 크기가 수 밀리초(ms)에 달하는 수준으로 증가하기 시작했습니다. 테스트 마지막 부분에서 가장 높은 지연 시간이 발생했는데, 256개의 스레드를 가진 10M 블록 크기에서 최대 1.2초(약 1200ms)가 발생했는데, 이는 시스템에 과부하가 걸리도록 설계된 최악의 부하를 반영합니다.
GDSIO 쓰기 순차 처리량
순차 쓰기의 경우, 읽기에 비해 성능이 훨씬 낮았습니다. 작업 부하가 빠르게 안정되어 대부분의 스레드 및 블록 크기 조합이 약 6.3~6.5GiB/s에 도달했습니다. 이는 쓰기 경로가 초기에 일정한 한계에 도달했음을 나타내며, 이는 GPU 또는 PCIe 제한보다는 저장 매체 및 버퍼링과 관련이 있을 가능성이 높습니다.
스레드 수를 확장해도 처리량은 2개에서 128개 스레드로 거의 변동이 없었기 때문에 큰 영향을 미치지 않았습니다. 유일하게 눈에 띄는 결과는 마지막에 나타났는데, 256개 스레드에서 10M 블록 크기가 18.2GiB/s로 급증했습니다. 이는 시스템이 딥 큐와 쓰기 집계를 최대한 활용할 수 있을 때 잠깐이나마 이점을 보여주었습니다.
GDSIO 쓰기 순차 지연 시간
쓰기 지연 시간은 비교적 낮게 시작했는데, 단일 스레드 워크로드는 작은 블록 크기에서 약 0.15~0.5ms였습니다. 스레드가 증가함에 따라 지연 시간은 읽기보다 훨씬 더 빠르게 증가하여, 4개 스레드에서는 1~4ms, 8개 스레드에서는 4~9ms 범위로 증가했습니다.
더 큰 블록 크기를 가진 32개 스레드에 도달하자 지연 시간이 급격히 증가하여 5M과 10M 블록은 170~350ms 범위로 뛰어올랐습니다. 가장 극단적인 경우는 256개 스레드에서 10M 블록 크기가 발생했을 때로, 최대 3초 미만(약 2900ms)으로 나타났습니다. 이는 높은 병렬 부하에서 쓰기 경로가 얼마나 빨리 포화되는지를 명확하게 보여줍니다.
GDSIO 임의 읽기 처리량
무작위 읽기의 경우 작업 부하가 빠르게 증가했습니다. 단일 스레드 성능은 블록 크기에 따라 약 11~31GiB/s였으며, 블록 크기가 클수록 더 높은 대역폭의 이점을 즉시 얻었습니다. 스레드를 2개와 4개로 변경하자 처리량이 20~36GiB/s 범위로 증가하여 초반에 강력한 확장성을 보였습니다.
스레드 8개 이상부터 시스템은 순차 읽기 테스트에서 확인한 결과와 매우 유사한 30GiB/s 후반대에서 안정적인 안정세를 보였습니다. 블록 크기가 10M이고 스레드가 256개일 때 가장 높은 결과를 얻었으며, 최대 약 42.7GiB/s에 도달했습니다.
GDSIO 임의 읽기 지연 시간
무작위 읽기 지연 시간은 매우 낮게 시작되었으며, 단일 스레드 워크로드는 작은 블록 크기에서 약 0.15~0.4ms였습니다. 스레드가 증가함에 따라 지연 시간은 점차 증가하여 4개 스레드까지는 1ms 미만을 유지했고, 8개 스레드에서는 약 1~3ms에 도달했습니다.
스레드 수를 32개로 늘리고 블록 크기를 늘리자 지연 시간이 더 급격히 증가하여 5M과 10M 전송 시 30~55ms 범위에 도달했습니다. 가장 극단적인 경우는 10M 블록 크기를 가진 256개 스레드에서 나타났는데, 최대 지연 시간은 1.1초(약 1180ms)를 약간 넘는 수준이었습니다.
GDSIO 임의 쓰기 처리량
임의 쓰기 성능은 전반적으로 매우 일관적이었으며, 대부분의 블록 크기와 스레드 수는 약 5.8~6.1GiB/s 수준이었습니다. 작업 부하가 거의 즉시 이 수준에 도달했고, 추가 스레드가 도입됨에 따라 최소한의 확장만 보였는데, 이는 쓰기 경로가 조기에 한계에 도달했음을 나타냅니다.
유일하게 주목할 만한 이상치는 테스트가 끝날 때 나타났는데, 256개 스레드에서 10M 블록 크기가 잠시 12.5GiB/s로 급증했는데, 이는 무거운 병렬 부하에서 심층 큐잉과 쓰기 집계의 이점을 얻은 것으로 보입니다.
GDSIO 임의 쓰기 대기 시간
무작위 쓰기 지연 시간은 비교적 낮게 시작했는데, 단일 스레드 성능은 작은 블록 크기의 경우 약 0.6~1.2ms, 가장 큰 전송의 경우 5~12ms였습니다. 동시성이 증가함에 따라 지연 시간은 빠르게 증가하여 8개 스레드에서는 4~9ms, 32개 스레드에서는 18~38ms에 도달했습니다.
그 지점을 넘어서면 쓰기 경로가 포화 상태가 됩니다. 더 큰 블록 크기는 64개 스레드에서 150~380ms 범위로 급증했고, 지속적인 확장으로 인해 지연 시간이 급격히 증가했습니다. 최악의 경우는 256개 스레드에서 10M 블록 크기로 약 4.4초에 달했습니다.
vLLM 온라인 제공 – LLM 추론 성능
vLLM은 LLM을 위한 가장 널리 사용되는 고처리량 추론 및 서빙 엔진입니다. vLLM 온라인 서빙 벤치마크는 동시 요청 환경에서 이 추론 엔진의 실제 서빙 성능을 측정하는 성능 평가 도구입니다. 요청 속도, 입출력 길이, 동시 클라이언트 수 등 구성 가능한 매개변수를 사용하여 실행 중인 vLLM 서버에 요청을 전송하여 프로덕션 워크로드를 시뮬레이션합니다. 이 벤치마크는 처리량(초당 토큰), 첫 번째 토큰까지의 시간(Time to First To To), 출력 토큰당 시간(TPOT) 등의 주요 지표를 측정하여 사용자가 다양한 부하 조건에서 vLLM의 성능을 이해하는 데 도움을 줍니다.
우리는 다양한 아키텍처, 매개변수 스케일, 양자화 전략에 걸친 포괄적인 모델 제품군에서 추론 성능을 테스트하여 다양한 동시성 프로필에서 처리량을 평가했습니다.
밀집 모델 성능
밀집 모델은 추론 과정에서 모든 매개변수와 활성화가 사용되는 기존 LLM 아키텍처를 따르므로, 희소 모델보다 더 많은 계산량이 필요합니다. 모델 규모와 양자화 전략에 따른 성능 특성을 종합적으로 평가하기 위해 Llama 3.1 8B 제품군의 여러 밀집 모델 구성을 벤치마킹했습니다.
테스트 세트에는 기본 구성, NVIDIA의 NVFP4 형식을 활용한 FP8 및 FP4 양자화 버전 등 세 가지 정밀도 형식에 대한 Meta Llama 3.1 8B 평가가 포함되었습니다. vLLM은 현재 NVFP4 양자화 모델에 Marlin 커널을 사용하고 있으며, 이 양자화 형식의 완전한 성능 이점은 아직 이 벤치마크에서 실현되지 않았다는 점에 유의해야 합니다. 향후 네이티브 NVFP4 텐서 코어 연산을 타겟으로 하는 vLLM 최적화를 통해 추가적인 성능 향상을 기대할 수 있습니다. 이러한 모델 선택 전략을 통해 점진적 양자화가 추론 처리량에 미치는 영향을 분리하면서 직접적인 성능 비교가 가능합니다.
라마 3.1 8B 성능
표준 정밀도에서 Llama 3.1 8B는 동시성 수준에서 다음과 같은 확장 특성을 보입니다. 단일 사용자 동시성(BS=1)에서 이 모델은 사용자당 279.27 tok/s를 제공하며, 총 처리량은 1,727.62 tok/s, TPOT는 3.37ms입니다. 배치 크기가 증가함에 따라 사용자당 처리량은 감소하는 반면 총 처리량은 증가합니다. BS=8에서 이 모델은 사용자당 82.85 tok/s를 제공하며, 총 처리량은 3,386.48 tok/s, TPOT는 3.28ms입니다. 성능은 BS=32(사용자당 56.46 tok/s, 총 8,274.66 tok/s) 및 BS=64(사용자당 52.70 tok/s, 총 13,707.66 tok/s)까지 지속적으로 확장됩니다.
이 모델은 BS=256에서 최대 총 처리량에 도달하여 32,797.67 tok/s를 전달하며, 사용자당 30.64 tok/s, TPOT는 16.13ms입니다. 이는 단일 사용자 성능 대비 총 처리량이 19배 증가함을 나타냅니다. TPOT 값은 BS=64까지 3~4ms 범위를 유지하다가 BS=256에서는 16.13ms로 증가합니다.
라마 3.1 8B FP8 성능
FP8 양자화 변형은 다른 특성을 보입니다. BS=1에서 사용자당 149.46 tok/s의 처리량을 달성하여 총 처리량은 9,565.20 tok/s, TPOT는 3.44ms입니다. 파레토 프런티어 분석 결과 세 개의 최적 지점(BS=1, BS=128, BS=256)이 도출되었습니다.
BS=128에서 모델은 사용자당 44.12 tok/s를 제공하며 총 19,198.40 tok/s, 11.04ms입니다.
TPOT. 최대 총 처리량은 BS=256에서 발생하며, 총 29,219.67 tok/s, 사용자당 30.13 tok/s, TPOT는 13.26ms입니다. FP8 변형은 표준 정밀도(29.2K 대 32.8K tok/s)에 비해 더 낮은 최대 총 처리량을 달성합니다.
라마 3.1 8B FP4 성능
FP4 양자화 구성은 다음과 같은 결과를 보여줍니다. 단일 사용자 동시성(BS=1)에서 사용자당 279.73 tok/s, 총 처리량 830.46 tok/s, 그리고 3.43ms의 TPOT를 달성합니다.
FP4 모델은 7개의 파레토 프런티어 지점을 보여줍니다. BS=2에서는 사용자당 159.95 tok/s, 총 928.60 tok/s, 그리고 3.43ms의 TPOT를 제공합니다. BS=4(사용자당 76.36 tok/s, 총 1,631.69 tok/s)와 BS=32(사용자당 76.09 tok/s, 총 9,014.29 tok/s)까지 성능이 지속적으로 향상됩니다. BS=256에서는 총 29,340.89 tok/s, 사용자당 30.13 tok/s, 그리고 16.18ms의 TPOT로 최대 처리량에 도달합니다.
희소 모델 성능
희소 모델, 특히 전문가 혼합(MoE) 아키텍처는 언어 모델을 효율적으로 확장하는 새로운 접근 방식입니다. 이러한 아키텍처는 토큰당 매개변수의 하위 집합만 활성화하면서 높은 총 매개변수 수를 유지하여, 활성 매개변수당 향상된 성능을 제공할 수 있습니다.
두 가지 MoE 아키텍처, 즉 추론 중심 모델인 DeepSeek-R1과 코드 생성에 특화된 희소 아키텍처인 Qwen3 Coder 30B-A3B를 평가했습니다. DeepSeek-R1은 가장 널리 사용되는 추론 중심 모델로, 기존 언어 모델과 비교하여 뚜렷한 성능 특성을 보여줍니다. Qwen3 Coder 모델은 생성된 토큰당 3B 매개변수만 활성화하면서 전체 30B 매개변수 크기를 유지합니다. 양자화 전략에 따른 성능 특성을 파악하기 위해 기본 및 FP8 양자화 변형 모두에서 Qwen3 Coder를 벤치마킹했습니다.
DeepSeek-R1 성능
DeepSeek-R1 모델은 배치 크기에 따라 흥미로운 확장 특성을 보입니다. 단일 사용자 동시성(BS=1)에서 이 모델은 사용자당 30.24 tok/s, 총 처리량 88.13 tok/s, 그리고 29.85ms의 TPOT를 달성합니다. BS=4로 확장하면 사용자당 29.77 tok/s의 성능을 달성하고, 총 처리량 266.40 tok/s와 32.04ms의 TPOT를 제공하여 모든 구성에서 달성된 최대 총 처리량을 나타냅니다.
DeepSeek-R1 성능은 BS=4를 넘어서면 정체됩니다. BS=8에서는 사용자당 처리량이 14.98 tok/s로 급격히 감소하고, 배치 크기가 커질수록 감소폭이 커져 BS=256에서는 사용자당 0.46 tok/s에 불과합니다. BS=4부터 BS=256까지 총 처리량은 200~260 tok/s 사이에서 비교적 안정적으로 유지되는데, 이는 단일 노드에서 동시 요청이 증가하면 모델이 확장할 수 없기 때문입니다. 따라서 유의미한 처리량 향상 없이 지연 시간이 증가합니다. 여기서 중요한 점은 B200 DGX가 이 대규모 모델을 실행할 수 있는 유일한 단일 서버 솔루션 중 하나라는 것입니다.
Qwen3 Coder 30B-A3B 성능
표준 정밀도 Qwen3 Coder는 동시성 수준에 따라 다음과 같은 확장성을 보입니다. 단일 사용자 동시성(BS=1)에서 이 모델은 사용자당 178.30 tok/s, 총 처리량 527.25 tok/s, TPOT 5.46ms를 달성합니다. BS=2에서는 사용자당 174.56 tok/s, 총 처리량 718.70 tok/s, TPOT 5.60ms를 달성합니다. 배치 크기가 증가함에 따라 사용자당 처리량은 감소하지만 총 처리량은 계속 확장됩니다. BS=16에서는 사용자당 127.76 tok/s, 총 처리량 4,204.40 tok/s, TPOT 6.93ms를 달성합니다.
이 모델은 BS=256에서 최대 총 처리량에 도달하여 총 22,305.88 tok/s, 사용자당 46.16 tok/s, TPOT 17.64ms를 달성합니다. 파레토 프런티어는 8개의 개별 지점으로 구성되며, BS=32에 중복 항목이 있습니다(사용자당 72.97 tok/s와 93.50 tok/s, 서로 다른 구성을 나타낼 가능성이 높음). TPOT 값은 BS=64까지 5~9ms 범위를 유지합니다.
Qwen3 Coder 30B-A3B FP8 성능
FP8 양자화 변형은 다음과 같은 성능 특성을 보입니다. 단일 사용자 동시성(BS=1)에서 사용자당 107.46 tok/s, 총 처리량 317.75 tok/s, 그리고 9.16ms의 TPOT를 제공합니다. BS=2에서 이 모델은 사용자당 99.55 tok/s, 총 처리량 409.87 tok/s, 그리고 9.86ms의 TPOT를 달성합니다.
더 큰 배치 크기로 확장: BS=8은 사용자당 54.60 tok/s, 총 1,383.13 tok/s, TPOT 10.24ms를 제공하는 반면, BS=32는 사용자당 48.78 tok/s, 총 3,874.21 tok/s, TPOT 10.67ms를 제공합니다. 최대 총 처리량은 BS=256에서 총 19,114.86 tok/s, 사용자당 36.38 tok/s, TPOT 20.00ms로 발생합니다. 이는 표준 정밀도 최대 처리량의 약 86%에 해당합니다.
마이크로스케일링 데이터 유형 성능
마이크로스케일링은 대규모 매개변수 그룹에 걸쳐 균일한 양자화를 적용하는 대신, 작은 가중치 블록에 세밀한 스케일링 계수를 적용하는 고급 양자화 방식을 나타냅니다. NVIDIA의 NVFP4 포맷은 8~32개 값으로 구성된 각 마이크로스케일 블록이 공통 지수를 스케일링 계수로 공유하는 블록형 부동 소수점 표현을 통해 이 기술을 구현합니다. 이러한 세밀한 접근 방식은 수치적 정밀도를 유지하면서도 4비트 표현을 구현하여 변압기 아키텍처에 필수적인 동적 범위를 유지합니다. 이 포맷은 NVIDIA의 텐서 코어 아키텍처와 통합되어 행렬 연산 중 즉각적인 압축 해제를 통해 효율적인 혼합 정밀도 계산을 가능하게 합니다.
OpenAI의 GPT OSS 모델을 NVFP4 양자화를 사용하여 두 가지 매개변수 스케일(20B 변형과 더 큰 120B 변형)에서 평가했습니다. 이 벤치마크는 마이크로스케일링 양자화가 다양한 모델 크기에 걸쳐 어떻게 작동하는지 보여줍니다.
GPT-OSS-20B 성능
20B 매개변수 모델은 배치 크기에 따라 다음과 같은 성능을 달성합니다. 단일 사용자 동시성(BS=1)에서 사용자당 299.28 tok/s, 총 처리량 943.43 tok/s, 그리고 3.23ms의 TPOT를 제공합니다. BS=2에서 모델은 사용자당 299.19 tok/s, 총 처리량 1,356.87 tok/s, 그리고 3.19ms의 TPOT를 유지합니다.
더 큰 배치 크기로 확장: BS=8은 사용자당 259.02 tok/s, 총 5,149.59 tok/s, 3.42ms의 TPOT를 달성하는 반면, BS=16은 사용자당 200.69 tok/s, 총 7,765.73 tok/s, 3.77ms의 TPOT를 제공합니다. 이 모델은 BS=32(사용자당 168.34 tok/s, 총 12,411.72 tok/s)와 BS=64(사용자당 123.96 tok/s, 총 16,931.47 tok/s)까지 확장됩니다.
총 처리량은 BS=256에서 발생하여 사용자당 65.08 tok/s, 9.39ms의 TPOT로 총 38,258.50 tok/s를 달성합니다. 이는 단일 사용자 성능에 비해 총 처리량이 40.5배 증가함을 의미합니다. TPOT 값은 BS=32까지 3~5ms 범위를 유지합니다. 파레토 프런티어는 8개의 개별 지점으로 구성됩니다.
GPT-OSS-120B 성능
더 큰 120B 매개변수 모델은 매개변수 수가 증가했음에도 불구하고 다음과 같은 성능을 유지합니다. 단일 사용자 동시성(BS=1)에서 사용자당 248.62 tok/s, 총 처리량 783.73 tok/s, 그리고 3.89ms의 TPOT를 달성합니다. BS=2에서 이 모델은 사용자당 240.99 tok/s, 총 처리량 1,092.91 tok/s, 그리고 3.99ms의 TPOT를 제공합니다.
배치 크기가 커질수록 성능은 지속적으로 향상됩니다. BS=4는 사용자당 190.63 tok/s, 총 2,096.73 tok/s, TPOT 4.22ms를 달성하는 반면, BS=8은 사용자당 172.66 tok/s, 총 3,692.10 tok/s, TPOT 4.54ms를 달성합니다. BS=16(사용자당 138.28 tok/s, 총 5,751.41 tok/s), BS=32(사용자당 111.63 tok/s, 총 8,646.05 tok/s), BS=64(사용자당 88.64 tok/s, 총 13,027.97 tok/s)로 확장하면 일관된 처리량 확장을 보여줍니다.
이 모델은 BS=256에서 최대 총 처리량에 도달하여 29,976.99 tok/s를 전달하고, 사용자당 48.64 tok/s, TPOT는 12.53ms입니다. 이는 단일 사용자 성능 대비 총 처리량이 38.2배 증가했음을 나타냅니다. 최대 총 처리량은 20B 모델 최고치의 약 78%입니다. 파레토 프런티어는 9개의 개별 지점으로 구성되어 있으며, 이는 테스트된 모델 중 가장 많은 수치입니다.
예상치 못한 양자화 모델 성능
양자화된 모델 결과는 예상치 못한 것이었으며, 추가 조사가 필요합니다. 여러 사례에서 NVFP4 및 FP8 양자화된 모델은 네이티브 정밀도 모델에 비해 예상했던 성능 향상을 달성하지 못했습니다. 예를 들어, Llama 3.1 8B FP4 모델은 BS=1에서 830.46 tok/s의 총 처리량을 달성한 반면, 표준 정밀도 모델은 유사한 사용자당 처리량에도 불구하고 1,727.62 tok/s를 달성했습니다. 더 높은 배치 크기에서는 양자화된 모델이 표준 정밀도 처리량(BS=256에서 29.2K-29.3K tok/s vs 32.8K tok/s)에 근접했지만, 전반적인 결과는 vLLM의 현재 구현이 Blackwell에 완전히 최적화되지 않았을 수 있음을 시사합니다.
우리는 vLLM에 대한 추가 테스트를 수행하고 TensorRT-LLM과 비교하여 최종 사용자가 오늘날 어떤 성능을 기대할 수 있는지 알아볼 계획입니다.
Supermicro JumpStart, AI PoC 게임의 판도를 바꾸다
Supermicro의 JumpStart 프로그램은 약속한 바를 실현합니다. 기존 PoC(개념 증명)에서 발생하는 물류, 배송 지연 또는 실험실 간접비 없이 프로덕션급 하드웨어에 대한 실제적이고 무제한적인 액세스를 제공합니다. X14 HGX B200 플랫폼에서의 JumpStart 주간은 빠르게 시작되어 순조롭게 진행되었으며, 자체 랙에 있는 장비와 동일한 방식으로 성능을 평가할 수 있었습니다.
신속한 AI 인프라 결정을 내리는 조직의 경우, 이러한 플랫폼 접근 방식을 통해 몇 주 걸리는 계획을 며칠 만에 완료할 수 있습니다. GPU 처리량, 스토리지 동작, 모델 성능을 검증하거나 단순히 스택 호환성을 확인하는 것이 목표라면 JumpStart를 통해 최소한의 마찰로 답을 찾을 수 있습니다. JumpStart는 하드웨어 평가에 대한 신뢰성 있는 접근 방식이며, 더 많은 공급업체가 이를 채택하기를 바랍니다.
아마존