MLPerf 벤치마크, 우리 AI 연구에 NVIDIA GPU를 어떻게 매핑할까요?

MLPerf 실측 수치를 우리 연구 시간·사용자 수로 환산해 봤어요

엑스디노드 기술팀

읽는 시간 약

약 12분

새 GPU 서버를 검토할 때 처음 마주치는 건 거대한 사양표예요. H100 SXM5, 80GB HBM3, 3.35TB/s 메모리 대역폭, 989 TFLOPS(FP16), 1,979 TFLOPS(FP8), TDP 700W. 숫자가 클수록 좋다는 건 알겠는데, 정작 우리가 만들려는 모델·서비스에 이게 어떤 의미인지는 와닿지 않습니다.

사양표는 GPU 제조사가 이상적인 조건에서 측정한 이론적 최대치예요. 실제 AI 연구에서 우리가 알고 싶은 건 "Llama 2 70B를 파인튜닝하면 얼마나 걸리는가", "챗봇 서비스를 운영하면 사용자 몇 명을 받을 수 있는가" 같은 구체적인 질문이죠. 이 두 세계 사이의 다리를 놓는 것이 바로 MLPerf 벤치마크예요.

이 글에서는 MLPerf가 어떤 기준으로 GPU를 측정하는지, 그리고 그 실제 수치를 우리 연구·서비스 시나리오에 대입했을 때 어느 정도의 학습 시간과 토큰 처리량이 나오는지 차근차근 풀어보겠습니다.



GPU 살 때 마주치는 숫자들, 우리 AI 연구에는 어떤 걸 봐야 할까요?

GPU 데이터시트는 보통 이런 식으로 시작합니다. "FP8 Tensor Core 성능 1,979 TFLOPS, 메모리 대역폭 3.35 TB/s, NVLink 900 GB/s." 처음 보면 압도되는 숫자죠. 그런데 막상 GPU를 들여놓고 우리 모델을 돌려보면 이런 의문이 생깁니다.

"분명히 카탈로그엔 1,979 TFLOPS라고 적혀 있는데, 우리 Llama 70B 파인튜닝은 왜 이렇게 오래 걸리지?" 사양표 숫자는 이상적인 행렬 곱셈 한 가지 동작의 최대 처리량이고, 실제 AI 워크로드는 그 행렬 곱셈을 한참 동안 반복하는 와중에 메모리에서 가중치를 읽어오고, 여러 GPU 사이에 데이터를 주고받고, 옵티마이저 상태를 업데이트하면서 진행돼요. 그 사이에 수십 가지 병목이 끼어들죠.

그래서 사양표는 "우리 GPU가 이론적으로 이만큼 빨라요"라는 제조사 주장이지, 당신이 만드는 모델이 이만큼 빨리 돌아가요라는 약속은 아니에요. 우리가 정작 알고 싶은 건 후자죠. 사전학습은 며칠이 걸리는지, 파인튜닝은 몇 시간이면 끝나는지, 추론 서비스에서 사용자 1,000명을 받으려면 GPU 몇 장이 필요한지.

이런 질문에 답하려면 "이미 학습된 모델을, 실제 데이터셋으로, 정해진 정확도까지 학습·추론하는 데 시간이 얼마나 걸리는가"를 측정한 데이터가 필요해요. 사양표 옆에 그런 데이터를 같이 봐야 비로소 우리 연구에 맞는 GPU를 고를 수 있습니다.

NVIDIA RTX PRO 6000 Blackwell 워크스테이션 에디션 사양표 (출처: NVIDIA)



GPU 사양표는 널리 알려져 있지만, 우리 연구에 맞는 벤치마크는 찾기 어려워요

제조사가 만든 사양표와 실제 AI 연구 환경 사이의 거리를 표로 정리해 보면, 같은 GPU라도 어디서 어떻게 측정하느냐에 따라 완전히 다른 숫자가 나온다는 게 분명해집니다.

사양표가 말하는 것

우리 연구가 알고 싶은 것

FP16/FP8 이론 최대 TFLOPS

Llama 70B 사전학습이 며칠 걸리는지

메모리 용량과 대역폭(GB/s)

우리 배치 크기·시퀀스 길이에서 OOM 없이 학습되는지

INT8 TOPS (이론값)

실제 챗봇 서비스에서 초당 몇 토큰을 만드는지

TDP 최대 전력

우리 워크로드에서 전기료가 얼마나 나오는지

예를 들어 NVIDIA H100은 사양표상 직전 세대 A100 대비 FP8에서 약 6배 빠르다고 적혀 있어요. 그런데 실제 MLPerf 학습 벤치마크에서 비교해 보면 워크로드에 따라 1.2배에서 3배 사이의 차이로 나뉩니다. 사양표만 보면 6배인데, 우리 모델에서는 2배 차이일 수도 있는 거죠. 단순 사양표로는 이 격차를 예측할 수 없어요.

문제는 사양표는 사방에 흔하지만, 실제 AI 워크로드 기준의 벤치마크는 한 곳에 모여 있지 않다는 점이에요. 회사마다 자기 GPU가 좋다고 발표하는 자료가 산재해 있고, 측정 조건도 제각각이라 비교가 어렵습니다. 그래서 업계는 "AI 워크로드를 동일한 조건에서 측정하는 표준"의 필요성을 오래전부터 이야기해 왔어요. 그 답이 MLPerf예요.



MLPerf는 MLCommons라는 비영리 컨소시엄이 운영하는 벤치마크예요

MLPerfMLCommons라는 비영리 오픈 컨소시엄이 운영하는 AI 성능 표준 벤치마크예요. 2018년 Baidu, Google, 하버드·스탠퍼드·UC 버클리 엔지니어들이 AI 벤치마크 표준화의 필요성을 논의하면서 시작됐고, 2020년 캘리포니아 등록 비영리 법인으로 정식 출범했어요.

회원사를 보면 MLPerf가 왜 업계 표준이 됐는지 알 수 있어요. NVIDIA, AMD, Intel, Google, Meta, Microsoft, Dell, HPE, Lenovo, Oracle, Cisco, Supermicro 등 AI·HPC 생태계의 거의 모든 주요 기업이 130여 개 이상 회원으로 참여합니다. 한쪽 편을 들 수 없는 구조라 결과가 공정하게 나올 수밖에 없어요.

MLPerf가 다른 벤치마크와 결정적으로 다른 점은 세 가지예요. 첫째, 모든 측정 규칙이 GitHub에 공개돼 누구나 검증할 수 있어요. 둘째, Closed Division에서는 모든 참가자가 동일한 모델·데이터셋·정확도 목표를 사용해야 합니다. 셋째, 매 라운드마다 무작위로 최대 두 개의 제출이 감사 대상이 돼 결과 신뢰성을 검증해요. 감사 실패 시 결과가 무효 처리됩니다.

이런 엄격함 덕분에 NVIDIA·AMD·Dell·HPE·Supermicro 같은 회사들도 신제품 출시 시 MLPerf 결과를 공식 마케팅 자료로 활용합니다. AI 인프라 구매 의사결정의 가장 표준화된 참조점이 바로 MLPerf예요.

MLCommons 회사 로고



MLPerf는 어떤 기준으로 GPU 성능을 측정할까요?

MLPerf는 크게 두 갈래로 나뉩니다. Training(학습)은 "정해진 정확도까지 학습을 마치는 데 시간이 얼마나 걸리는가"를 잰다면, Inference(추론)는 "이미 학습된 모델로 요청을 처리할 때 얼마나 빠른가"를 잽니다. 두 측정 방식은 결이 다르기 때문에, 우리 연구가 학습 중심인지 추론 중심인지에 따라 봐야 할 숫자가 달라져요.

학습 벤치마크 — 정해진 정확도까지의 실제 경과 시간

MLPerf Training은 모델을 초기화 상태에서 시작해 사전에 정해진 품질 목표(예: 정확도 75.9%, Log Perplexity 3.3)에 도달할 때까지의 실제 경과 시간(wall clock time, 분)을 잽니다. 시간이 짧을수록 GPU 성능이 좋은 거예요.

중요한 점은 정확도 목표를 채우지 못하면 결과가 무효 처리된다는 거예요. 정확도를 희생해서 속도를 부풀릴 수 없는 구조죠. 같은 모델을 최소 3회에서 10회까지 반복 실행한 뒤 최고·최저 결과를 제외하고 평균을 최종 점수로 씁니다.

2025년 11월 발표된 MLPerf Training v5.1 현행 벤치마크는 다음과 같아요.

분야

모델

품질 목표

대형 LLM 사전학습

Llama 3.1 405B

Log Perplexity ≤ 5.6

소형 LLM 사전학습

Llama 3.1 8B

Log Perplexity ≤ 3.3

LLM 파인튜닝 (LoRA)

Llama 2 70B LoRA

Cross-Entropy Loss ≤ 0.925

이미지 생성

FLUX.1

Validation Loss ≤ 0.586

추천 시스템

DLRMv2 (DCNv2)

AUC ≥ 0.80275

추론 벤치마크 — 4가지 사용 시나리오로 분리해 측정

추론은 학습과 달리 사용 패턴이 다양해요. 챗봇처럼 실시간으로 요청이 들어오는지, 야간 배치처럼 한꺼번에 처리하는지, 자율주행 카메라처럼 한 건씩 들어오는지에 따라 좋은 GPU가 다릅니다. 그래서 MLPerf Inference는 시나리오를 네 가지로 나눠 측정해요.

시나리오

측정 방식

대표 활용

Offline

전체 요청을 한꺼번에 보내고 총 처리량 측정

야간 배치, 데이터 파이프라인

Server

포아송 분포로 무작위 시점에 요청 도착

실서비스 API, 챗봇 서버

Single Stream

한 번에 하나씩 순차 요청

자율주행 카메라, 엣지 디바이스

Interactive

Server보다 엄격한 TTFT·TPOT 제약

실시간 챗봇, 코딩 어시스턴트

2026년 4월 발표된 MLPerf Inference v6.0에는 DeepSeek-R1, Llama 3.1 405B, Llama 2 70B Interactive, GPT-OSS 120B, 그리고 텍스트→비디오 생성 모델 Wan 2.2까지 포함돼 있어요. 챗봇부터 추론 모델, 생성형 비디오까지 거의 모든 응용 워크로드가 표준 벤치마크에 들어와 있다는 뜻이에요.



이제 이 기준을 우리 연구에 도입해 보겠습니다

MLPerf 벤치마크는 종류가 많지만, 우리가 모든 벤치마크를 다 볼 필요는 없어요. 우리 팀이 어떤 작업을 하느냐에 따라 결정적으로 봐야 할 벤치마크가 달라지거든요. 크게 학습·파인튜닝 중심팀과 추론 서비스 중심팀으로 나누어 정리해 봤어요.

학습·파인튜닝이 목적이라면 — MLPerf Training

사내 R&D 팀이 자체 모델을 만들거나, 오픈소스 모델을 우리 데이터셋으로 파인튜닝하는 경우라면 MLPerf Training의 "분(minutes)" 지표가 핵심이에요. 시간이 짧을수록 한 번 실험을 끝내고 다음 가설을 검증하는 사이클이 빨라지죠.

우리 팀이 하는 일

참고할 MLPerf Training 벤치마크

오픈소스 모델을 우리 데이터로 파인튜닝

Llama 2 70B LoRA Fine-tuning ← 가장 현실적

중형 모델 자체 사전학습

Llama 3.1 8B Pretraining

대형 모델 자체 사전학습

Llama 3.1 405B Pretraining

이미지 생성 모델 학습

FLUX.1 Text-to-Image

추천 시스템 학습

DLRMv2

기업 AI 연구의 90% 이상은 사전학습이 아니라 파인튜닝이에요. 즉 대부분의 회사에서는 Llama 2 70B LoRA 벤치마크 결과가 가장 현실적인 참고점입니다. 우리 회사가 H100 8장 서버를 도입할 예정이라면 이 벤치마크에서 8장 H100이 몇 분에 학습을 마치는지 보면, 우리 환경에서도 비슷한 시간이 나올 거라는 합리적 기대를 할 수 있어요.

추론 서비스가 목적이라면 — MLPerf Inference

반대로 이미 학습된 모델을 가져와 사내 챗봇·API 서비스로 운영하는 팀이라면 MLPerf Inference의 시나리오별 처리량을 봐야 해요. 어떤 시나리오 수치를 볼지는 우리 서비스 패턴에 달려 있어요.

우리 서비스 형태

참고할 MLPerf Inference 시나리오

실시간 챗봇·코딩 어시스턴트

Llama 2 70B Interactive (TTFT 450ms·TPOT 40ms)

일반 챗봇 API 서버

Llama 2 70B Server

야간 배치·임베딩 생성

Llama 2 70B Offline (총 처리량 tokens/sec)

추론 모델(Reasoning) 서비스

DeepSeek-R1 Server / Offline

이미지 생성 서비스

SDXL Server / Offline (20초 제약)

실시간 챗봇이라면 TTFT(Time to First Token)TPOT(Time Per Output Token) 두 지표를 같이 봐야 해요. TTFT는 사용자가 질문을 보낸 뒤 첫 글자가 나오기까지 기다리는 시간, TPOT는 그다음 한 글자씩 이어지는 속도예요. 챗봇 사용자가 자연스럽게 느끼는 한국어 출력 속도는 대략 1초에 12~15자, 즉 25~30 tokens/sec 수준이에요.



이 벤치마크를 NVIDIA GPU에 대입해 보면 어떤 수치가 나올까요?

자, 이제 본격적으로 우리 연구·서비스 시나리오에 MLPerf 실측 수치를 대입해 보겠습니다. 학습 한 가지, 추론 두 가지(일반 LLM, 추론 모델) 시나리오를 차례로 살펴볼게요.

학습 시나리오 — Llama 2 70B를 우리 데이터로 파인튜닝하면 몇 분 걸리나요?

사내 고객 응대 챗봇을 만들기 위해 Llama 2 70B 모델을 우리 콜센터 대화 데이터로 LoRA 파인튜닝한다고 가정해 봅시다. MLPerf Training v5.0/v5.1 Closed Division에서 같은 작업을 측정한 8장 단일 노드 기준 결과는 다음과 같아요.

GPU 8장 노드 1대

Llama 2 70B LoRA 파인튜닝 시간

H100 대비

HGX H100 8GPU

약 29분

기준 (1x)

HGX H200 8GPU

약 23분

약 1.16배

DGX B200 8GPU

약 14분

약 2배

GB200 NVL72 (8GPU 부분)

약 11~12분

약 2.5배

실제 의미로 풀어보면, H100 8장 서버에서 약 30분 걸리던 LoRA 한 라운드가 B200 같은 8장 서버에서는 약 14분에 끝납니다. 하루 8시간 R&D 시간 안에 H100으로는 16회 실험을 돌릴 수 있다면, B200으로는 같은 시간에 약 34회 실험이 가능한 셈이에요. 가설 검증 사이클 자체가 두 배로 빨라진다는 의미입니다.

스케일을 늘리면 어떻게 될까요? Oracle OCI가 MLPerf Training v4.1에 제출한 결과를 보면, H100 64장(8노드) 클러스터로 같은 LoRA 작업이 4.75분에 끝나고, 128장(16노드)으로는 3.07분까지 줄어듭니다. NVIDIA가 v5.1에 제출한 최대 스케일 결과는 Blackwell Ultra GPU 512장으로 24초예요. 같은 LoRA 작업이지만 인프라 규모에 따라 30분에서 24초까지 펼쳐지는 셈이에요.

즉 우리 회사가 "주 1회 모델 갱신"이라는 운영 리듬을 정했다면 8장 H100 한 노드로도 충분하지만, "매일 5회 새 데이터로 재학습"을 원한다면 H200·B200 노드 한 대를 도입하는 편이 운영 효율이 훨씬 좋아지는 거죠.

추론 시나리오 — 사내 챗봇으로 동시 사용자 몇 명을 받을 수 있나요?

학습이 끝났다면 이제 운영입니다. 사내 직원 챗봇에 Llama 2 70B 모델을 올렸을 때 동시 사용자 처리량을 MLPerf Inference Server 시나리오 실측 수치로 환산해 봅시다.

2025년 4월 발표된 MLPerf Inference v5.0에서 CoreWeave가 제출한 NVIDIA H200 8장 노드 한 대는 Llama 2 70B Server 시나리오에서 약 33,000 tokens/sec를 기록했어요. H100 8장 노드는 동일 시나리오에서 약 23,700 tokens/sec로 H200 대비 약 40% 낮은 수치입니다. 2025년 9월 v5.1에서 Nebius가 제출한 B200 8장은 같은 워크로드에서 약 101,611 tokens/sec까지 뛰어올랐어요.

이 처리량을 우리 챗봇 사용자 수로 환산해 볼게요. 사용자 한 명에게 한국어로 자연스러운 챗봇 속도(1초에 약 25 토큰)를 보장한다고 가정하면 GPU 8장 노드 한 대로 받을 수 있는 동시 사용자 수가 나옵니다.

GPU 8장 노드 1대

Llama 2 70B 처리량

동시 사용자 (25 t/s/user 보장)

H100 8GPU

약 23,700 tokens/sec

약 950명

H200 8GPU

약 33,000 tokens/sec

약 1,320명

B200 8GPU

약 101,611 tokens/sec

약 4,060명

사내 직원 1,000명을 위한 챗봇이라면 H100 8장 노드 한 대로도 운영이 가능하다는 말이에요. 직원 4,000명 규모라면 H100 4노드 vs B200 1노드라는 선택지가 보이고, 이때부터는 전력 소비와 데이터센터 공간까지 함께 따져 결정하게 됩니다. 풀랙 단위 GB200 NVL72(72장 통합 시스템)는 비공식 측정에서 Llama 2 70B 약 90만 tokens/sec까지 나오는데, 같은 가정으로 환산하면 한 랙으로 동시 사용자 약 36,000명까지 커버하는 셈이에요.

추론 모델 시나리오 — DeepSeek-R1 같은 추론 모델을 운영하면 어떻게 되나요?

2025~2026년 들어 가장 화제가 된 모델 카테고리는 추론 모델(reasoning model)이에요. DeepSeek-R1, OpenAI o3, GPT-OSS-120B 같은 모델인데, 답하기 전에 길게 "생각"하는 과정을 거치기 때문에 일반 LLM보다 출력 토큰이 5~10배 많아요. 자연스럽게 GPU 처리량 요구도 그만큼 커집니다.

MLPerf Inference v6.0에서 NVIDIA가 제출한 GB300 NVL72의 DeepSeek-R1 Offline 처리량은 GPU 1장당 약 8,064~9,821 tokens/sec예요. 직전 세대 GB200 NVL72(GPU 1장당 약 5,842 tokens/sec) 대비 같은 하드웨어 폼팩터에서 2.7배 향상된 수치인데, 이는 소프트웨어(TensorRT-LLM) 업데이트만으로 따라온 격차예요. 즉 GPU를 새로 사지 않아도 시간이 지나면 같은 GPU에서 추가 성능이 나온다는 의미예요.

고객 시나리오로 환산해 보면, 사내 R&D 팀에 DeepSeek-R1급 추론 모델 기반 코딩 어시스턴트를 제공한다고 했을 때 한 명이 한 번 질문하면 평균 2,000 토큰 정도의 추론 과정을 거친 답이 나옵니다(일반 챗봇 응답의 약 4배). GB300 NVL72 한 랙 72장이면 초당 약 58만 토큰을 만드니까, 사용자당 50 tokens/sec를 보장한다고 가정하면 동시에 약 11,600명의 사내 코딩 작업을 받을 수 있어요. 추론 모델은 응답 시간이 일반 LLM보다 훨씬 긴 만큼, 같은 사용자 수를 받으려면 GPU 처리량을 훨씬 크게 잡아야 한다는 사실을 같이 기억해 두면 좋아요.



MLPerf 기준 NVIDIA GPU 성능, 한눈에 정리해 봤어요

지금까지 다룬 학습·추론 시나리오의 핵심 수치를 한 표로 정리했어요. 우리 팀의 작업이 학습 위주인지 추론 위주인지에 따라 봐야 할 컬럼이 다르니, 우리 운영 패턴에 맞춰 참고하시면 됩니다.

GPU (8장 노드 1대)

Llama 2 70B LoRA 파인튜닝

Llama 2 70B 챗봇 처리량

대응 가능 동시 사용자

H100 SXM 8GPU

약 29분

약 23,700 tokens/sec

약 950명

H200 SXM 8GPU

약 23분

약 33,000 tokens/sec

약 1,320명

B200 SXM 8GPU

약 14분

약 101,611 tokens/sec

약 4,060명

GB200 NVL72 (전체 72GPU)

512장 클러스터에서 24초 (Blackwell Ultra)

약 900,000 tokens/sec (비공식)

약 36,000명 (1개 랙)

기준 출처는 모두 MLPerf 공식 결과예요. 학습 시간은 NVIDIA의 MLPerf Training v4.1·v5.0 Closed Division 제출 결과를 기반으로 했고, 추론 처리량은 CoreWeave(v5.0 H200) 및 Nebius(v5.1 B200) 제출치를 사용했어요. 동시 사용자 수는 사용자 한 명에게 한국어로 자연스러운 25 tokens/sec를 보장한다는 가정 아래 환산했습니다.

위 표 수치는 모두 Closed Division 결과예요. MLPerf 결과를 볼 때는 반드시 Closed인지 확인해야 해요. Open Division은 모델 구조까지 자유롭게 바꿀 수 있어 소프트웨어 최적화 자랑이 섞여 들어가기 때문에, 하드웨어 자체를 공정하게 비교하는 데는 Closed Division만 봐야 합니다.



정리하자면

GPU 사양표의 TFLOPS와 메모리 대역폭 숫자는 제조사가 약속한 이론적 최대치예요. 우리 연구·서비스에서 실제로 나오는 결과는 그 숫자가 아니라 실제 AI 워크로드 기준 벤치마크가 알려줍니다. 그 표준이 MLPerf예요.

우리 팀이 학습·파인튜닝 중심이라면 MLPerf Training의 Llama 2 70B LoRA 같은 분(分) 지표를, 추론 서비스 중심이라면 MLPerf Inference의 Server·Interactive 시나리오 tokens/sec를 보면 됩니다. 그 숫자를 GPU 사양표 옆에 같이 놓고 보면, "H100 8장 서버 한 대로 직원 950명 챗봇이 가능하다"거나 "B200 8장이면 30분 걸리던 LoRA가 14분에 끝난다" 같은 구체적인 운영 감각이 잡혀요.

다음 글에서는 LLM 추론·파인튜닝·RAG·사전학습 네 가지 워크로드를 하나씩 펼치면서, 각 워크로드에 어떤 NVIDIA GPU가 가장 잘 들어맞는지 구체적인 매핑을 정리해 보겠습니다.

Newsletter

AI 인프라 인사이트, 메일로 받아보세요

GPU 시세 동향, 신제품 출시, 인프라 구축 기술 가이드를 월 2회 정리해 보내드립니다.

XDNODE를 통해 한정된 예산을
얼마나 잘 활용할 수 있을지 확인해 보세요.

XDNODE를 통해 한정된 예산을
얼마나 잘 활용할 수 있을지 확인해 보세요.

XDNODE를 통해 한정된 예산을
얼마나 잘 활용할 수 있을지 확인해 보세요.