22. Benchmarking AI 단계별 학습 문서

원문 경로: /Users/keumky/Documents/New project 3/sources/mlsysbook/22-benchmarking/source.md

짧은 소개

이 장은 AI 시스템을 어떻게 공정하고 믿을 만하게 측정할 수 있는지 설명해요.

AI에서는 “정확도가 높다”는 말만으로는 충분하지 않아요. 모델이 빠른지, 전기를 얼마나 쓰는지, 실제 서비스에서도 같은 성능이 나오는지, 여러 번 실행해도 결과가 안정적인지, 데이터가 공정하고 대표적인지도 함께 봐야 해요.

그래서 이 장은 벤치마킹을 단순한 점수표가 아니라 AI 시스템을 과학적으로 비교하기 위한 실험 설계로 다뤄요.

읽는 방법

처음부터 모든 세부 수치와 표준 이름을 외우려고 하면 어렵습니다. 이 장은 아래처럼 세 번에 나누어 읽으면 좋아요.

1단계: 벤치마크를 "공정한 시험"으로 이해해요.
2단계: 어떤 순서로 시험을 설계하고 측정하는지 봐요.
3단계: 원문 절 흐름을 따라 실제 ML 시스템에서 왜 복잡해지는지 파고들어요.

읽을 때는 특히 세 가지 질문을 계속 붙잡으면 됩니다.

이 장의 한 줄 요약

AI 벤치마킹은 한 줄 순위를 매기는 일이 아니라, 모델·시스템·데이터를 같은 조건에서 반복 측정하고, 그 결과가 실제 운영 환경에서도 의미 있는지 판단하는 방법입니다.

1단계: 중학교 수준

1. 벤치마크는 공정한 시험이에요

학교에서 학생들의 실력을 비교하려면 같은 시험지, 같은 시간, 같은 채점 기준이 필요해요. 어떤 학생은 쉬운 문제를 풀고, 다른 학생은 어려운 문제를 풀었다면 점수를 비교할 수 없겠죠.

AI 시스템도 마찬가지예요. 어떤 모델이 더 좋은지, 어떤 컴퓨터가 더 빠른지, 어떤 방법이 전기를 덜 쓰는지 비교하려면 모두가 같은 조건에서 시험을 봐야 해요. 이 공정한 시험이 바로 벤치마크예요.

2. AI는 “정답을 잘 맞히는지”만 보면 안 돼요

AI 모델이 시험 문제를 잘 맞히더라도 실제로는 문제가 생길 수 있어요.

예를 들어 길 안내 앱이 길은 정확히 찾지만 답을 10초 뒤에 준다면 운전 중에는 쓸모가 적어요. 스마트폰 사진 앱이 멋진 보정을 해주지만 배터리를 너무 빨리 닳게 한다면 사용자는 불편해요.

그래서 AI 벤치마크는 여러 점수를 함께 봐요.

3. 벤치마크는 저울이 아니라 건강검진에 가까워요

저울은 몸무게 하나만 알려줘요. 하지만 건강검진은 키, 혈압, 피검사, 시력, 생활 습관을 함께 봐요.

AI 벤치마크도 건강검진처럼 여러 항목을 함께 봐야 해요. “정확도 1등”인 모델이 항상 좋은 모델은 아니에요. 너무 느리거나, 너무 비싸거나, 특정 사람들에게만 잘 맞거나, 실제 서비스 데이터에서 갑자기 성능이 떨어질 수 있기 때문이에요.

4. 작은 부품 시험과 전체 서비스 시험은 달라요

자전거를 생각해 볼게요.

브레이크만 따로 시험할 수도 있고, 바퀴만 따로 시험할 수도 있어요. 이것은 작은 부품 시험이에요. 하지만 실제로 중요한 것은 사람이 자전거를 타고 길에서 안전하게 달릴 수 있는지예요. 이것은 전체 시험이에요.

AI에서도 작은 계산 하나를 따로 재는 시험, 모델 하나를 재는 시험, 데이터 준비부터 최종 결과까지 전체 흐름을 재는 시험이 모두 필요해요.

5. 학습 시험과 추론 시험은 목적이 달라요

AI가 공부하는 시간을 재는 시험이 있고, 공부가 끝난 AI가 실제 질문에 답하는 시간을 재는 시험이 있어요.

학습 벤치마크는 “얼마나 빨리 제대로 배웠나요?”를 봐요. 추론 벤치마크는 “사용자가 물었을 때 얼마나 빠르고 안정적으로 답하나요?”를 봐요.

6. 실제 경기장과 연습장은 달라요

연습장에서 잘하는 선수가 실제 경기에서도 항상 잘하는 것은 아니에요. 관중, 날씨, 상대 선수, 긴장감이 달라지기 때문이에요.

AI도 실험실 벤치마크에서는 잘 나왔지만 실제 서비스에서는 다를 수 있어요. 실제 서비스에는 갑자기 몰리는 요청, 이상한 입력, 네트워크 문제, 서버 장애, 시간이 지나며 바뀌는 데이터가 있어요.

그래서 이 장의 가장 큰 메시지는 이거예요.

벤치마크 점수는 중요한 출발점이지만, 실제 운영에서 다시 확인해야 해요.

2단계: 고등학교 수준

1. 벤치마크는 실험 설계예요

벤치마크는 “한번 돌려보고 빠르네”라고 말하는 일이 아니에요. 제대로 된 실험처럼 다음 순서를 가져야 해요.

문제 정의
  ↓
데이터 선택
  ↓
모델 선택
  ↓
측정 지표 선택
  ↓
실행 도구와 규칙 설정
  ↓
하드웨어/소프트웨어 조건 기록
  ↓
여러 번 실행하고 결과 해석

이 흐름이 없으면 두 시스템을 비교해도 공정한 비교인지 알 수 없어요.

2. AI 벤치마크가 어려운 이유

일반적인 컴퓨터 프로그램은 같은 입력을 넣으면 거의 같은 결과가 나와요. 하지만 AI는 학습 데이터의 순서, 초기값, 하드웨어 상태, 배치 크기, 실행 환경에 따라 결과가 조금씩 달라질 수 있어요.

그래서 한 번만 실행해서 “이 시스템이 더 좋다”고 말하면 위험해요. 원문은 여러 번 실행하고 평균뿐 아니라 표준편차나 신뢰구간처럼 결과의 흔들림을 함께 보고해야 한다고 설명해요.

간단히 말하면 이렇게 볼 수 있어요.

측정값 = 실제 성능 + 실행할 때 생기는 흔들림

우리가 알고 싶은 것은 실제 성능이에요. 그래서 흔들림을 줄이거나, 적어도 흔들림의 크기를 함께 보고해야 해요.

3. 세 가지 축: 알고리즘, 시스템, 데이터

이 장은 ML 벤치마크를 세 축으로 나누어 설명해요.

좋은 AI 시스템은 이 셋이 함께 맞아야 해요. 모델이 좋아도 데이터가 편향되어 있으면 위험하고, 데이터가 좋아도 시스템이 너무 느리면 서비스에 쓰기 어려워요.

4. 작은 측정과 큰 측정의 차이

벤치마크의 크기를 고르면 어떤 정보를 얻을 수 있는지도 달라져요.

고등학교 수준에서 핵심은 “작게 볼수록 원인 분석이 쉽고, 크게 볼수록 실제 상황에 가까워진다”는 점이에요.

5. 학습 성능의 기본 관계

학습 벤치마크에서는 단순히 초당 샘플을 많이 처리한다고 좋은 것이 아니에요. 목표 정확도까지 도달해야 해요.

원문은 학습 시간을 다음 생각으로 설명해요.

$$ T_{\text{train}} = \text{목표 정확도에 처음 도달한 시간} $$

그리고 처리량은 다음처럼 볼 수 있어요.

$$ \text{Throughput} = \frac{\text{처리한 샘플 수}}{\text{걸린 시간}} $$

하지만 처리량만 높고 목표 정확도에 도달하지 못하면 좋은 결과가 아니에요. 그래서 학습 벤치마크에서는 time-to-accuracy, 즉 목표 정확도까지 걸린 시간이 중요해요.

6. 추론 성능의 기본 관계

추론에서는 사용자가 기다리는 시간이 중요해요.

평균 지연시간만 보면 위험해요. 대부분은 빠르지만 100번 중 1번이 매우 느리면 실제 사용자에게는 큰 문제가 될 수 있어요. 그래서 p95, p99 같은 꼬리 지연시간을 봐요.

p95 latency: 요청 100개 중 95개는 이 시간 안에 끝나요.
p99 latency: 요청 100개 중 99개는 이 시간 안에 끝나요.

7. 배치 크기는 처리량과 지연시간을 흔들어요

한 번에 여러 요청을 묶어서 처리하면 GPU 같은 장비를 더 잘 쓸 수 있어요. 그래서 처리량은 좋아질 수 있어요.

하지만 묶음이 찰 때까지 기다려야 하므로 요청 하나의 지연시간은 늘어날 수 있어요.

배치 크기 증가
  → 장비 활용률 증가
  → 처리량 증가 가능
  → 개별 요청 대기시간 증가 가능

그래서 실시간 서비스는 무조건 큰 배치를 쓰면 안 되고, 추천 시스템처럼 대량 요청을 처리하는 서비스는 큰 배치가 유리할 수 있어요.

8. 에너지는 별도의 점수가 아니라 모든 선택에 얽힌 조건이에요

전력 측정은 “칩 하나가 몇 와트를 쓰나요?”만 묻지 않아요. 메모리 이동, 냉각, 저장장치, 네트워크, 배치 크기, 온도, 대기 상태까지 영향을 줘요.

모바일 기기에서는 배터리가 중요하고, 데이터센터에서는 전기요금과 냉각 비용이 중요해요. 그래서 같은 모델이라도 어디에 배포하느냐에 따라 좋은 선택이 달라져요.

9. 중간 정리

2단계까지 오면 벤치마크를 이렇게 이해할 수 있어요.

벤치마크는 모델·데이터·시스템을 정해진 조건에서 반복 측정하고, 정확도·속도·처리량·에너지·비용·재현성 사이의 균형을 해석하는 절차예요.

3단계: 대학교 수준

1. Purpose: 왜 벤치마킹이 ML 시스템 공학의 기초인가요?

원문은 벤치마킹을 ML 시스템의 공학적 발전을 가능하게 하는 측정 discipline으로 소개해요. 어떤 최적화가 정말 좋아졌는지, 어떤 하드웨어 투자가 타당한지, 어떤 성능 주장이 재현 가능한지 확인하려면 객관적인 측정 기준이 필요해요.

ML 시스템에서는 알고리즘, 하드웨어, 데이터가 복잡하게 얽혀 있어요. 그래서 직관만으로 성능을 예측하기 어렵습니다. 벤치마크는 이 복잡한 상호작용을 정해진 절차로 측정해서, 주관적인 인상을 비교 가능한 데이터로 바꿔요.

이 장의 학습 목표는 다음과 같이 정리할 수 있어요.

2. Machine Learning Benchmarking Framework

ML 벤치마킹은 전통적인 컴퓨터 성능 측정보다 어렵습니다. 일반 프로그램은 같은 입력에 대해 같은 동작을 기대할 수 있지만, ML은 확률적 요소가 많아요. 초기 가중치, 데이터 셔플링, 난수 seed, 배치 순서, 하드웨어 상태가 결과에 영향을 줄 수 있어요.

또한 ML 시스템은 한 가지 목표만 최적화하지 않아요.

원문은 이 복잡성을 다루기 위해 알고리즘, 시스템, 데이터라는 세 차원의 평가 틀을 세워요. 이후 모든 절은 이 세 차원을 바탕으로 구체적인 벤치마크 설계와 해석 방법을 설명합니다.

3. Historical Context

3.1 Performance Benchmarks

초기 컴퓨팅 벤치마크는 Whetstone, LINPACK처럼 특정 연산을 중심으로 성능을 측정했어요. 하지만 이런 좁은 시험은 vendor가 benchmark에 맞춰 최적화하기 쉬웠고, 실제 사용 성능을 잘 설명하지 못하는 문제가 있었어요.

SPEC CPU는 실제 애플리케이션 workload를 사용하면서 대표성의 중요성을 보여줬어요. 이 교훈은 MLPerf에도 이어져요. MLPerf가 ResNet-50, BERT 같은 실제 모델을 포함하는 이유는 이상적인 toy 연산이 아니라 실제 배포와 비슷한 복잡성을 측정하기 위해서예요.

또한 성능 평가는 단일 지표에서 다중 지표로 이동했어요. 그래픽 벤치마크는 속도와 품질을 함께 봤고, 모바일 벤치마크는 성능과 배터리를 함께 봤어요. ML에서도 정확도, 지연시간, 처리량, 에너지, 비용을 함께 봐야 합니다.

마지막으로 component 단위 평가에서 integrated system 평가로 이동했어요. 분산 학습에서는 GPU만 빠르다고 전체 학습이 빠른 것이 아니에요. 데이터 파이프라인, 저장장치, 네트워크, gradient synchronization이 함께 영향을 줘요.

3.2 Energy Benchmarks

컴퓨팅이 모바일, 슈퍼컴퓨터, 데이터센터로 확장되면서 에너지는 1급 지표가 되었어요. 원문은 SPEC Power, Green500, ENERGY STAR를 예로 들어 성능당 전력이라는 관점이 자리 잡았다고 설명해요.

AI에서는 하드웨어 전력만 보는 것으로 부족해요. 알고리즘 자체가 계산량을 줄이면 큰 에너지 절감이 가능하기 때문이에요.

따라서 energy-aware benchmarking은 하드웨어 소비전력, FLOP 감소, 메모리 접근 감소, 정밀도 감소 효과를 함께 측정해야 해요.

3.3 Domain-Specific Benchmarks

일반 벤치마크 하나로 모든 환경을 평가하기 어렵기 때문에 domain-specific benchmark가 필요해요. 데이터센터는 처리량과 비용이 중요하고, 모바일은 수 와트 안에서의 열과 배터리가 중요하며, IoT는 밀리와트 수준의 작동이 중요해요.

또한 애플리케이션 요구사항도 달라요. 의료 AI는 해석 가능성과 안정성이 중요하고, 금융 시스템은 매우 낮은 지연시간과 감사 가능성이 중요하며, 자율주행은 safety-critical reliability가 중요해요.

MLPerf Training, MLPerf Inference, MLPerf Tiny처럼 deployment context별 benchmark가 나뉘는 이유가 여기에 있어요.

4. Machine Learning Benchmarks

ML benchmark는 전통 benchmark보다 더 복잡해요. ML 모델은 확률적이고, 데이터에 따라 성능이 달라지며, 정확도와 계산 효율이 동시에 중요해요.

4.1 ML Measurement Challenges

원문은 ML 측정의 핵심 어려움을 variability라고 설명해요.

그래서 benchmark는 여러 random seed로 5-10회 실행하고, 평균뿐 아니라 표준편차나 95% 신뢰구간을 보고해야 해요. 작은 성능 차이가 통계적으로는 유의해도 실제 운영에서는 의미가 없을 수 있으므로, statistical significance와 practical significance를 구분해야 해요.

또한 대표 workload가 중요해요. synthetic microbenchmark는 실제 ML workload의 데이터 이동, 메모리 할당, dynamic batching, preprocessing overhead를 놓칠 수 있어요. 따라서 실제 배포 패턴에 가까운 데이터 분포, 배치 크기, sequence length, data loading을 반영해야 합니다.

4.2 Algorithmic Benchmarks

Algorithmic benchmark는 모델의 정확도, 손실, 일반화 능력, 계산 복잡도 사이의 관계를 봐요. ImageNet은 대표적인 예입니다. ImageNet은 AlexNet 이후 컴퓨터 비전 모델의 발전을 측정하고 촉진한 benchmark였어요.

원문은 ImageNet error rate 감소를 예로 들며, benchmark가 단지 현재 상태를 측정하는 데 그치지 않고 연구 방향을 이끈다고 설명해요. 다만 알고리즘 benchmark는 모델 능력을 중심으로 보기 때문에 실제 시스템 병목이나 데이터 품질 문제를 모두 설명하지는 못해요.

4.3 System Benchmarks

System benchmark는 CPU, GPU, TPU, ASIC 같은 하드웨어와 프레임워크, 메모리, interconnect가 ML workload를 얼마나 잘 실행하는지 평가해요. 측정 지표에는 계산 처리량, 메모리 대역폭, 전력 효율, 확장성이 포함됩니다.

여기서 중요한 개념은 compute-bound와 memory-bound예요.

$$ \text{Arithmetic intensity} = \frac{\text{FLOPs}}{\text{data movement in bytes}} $$

이 값이 높으면 계산 장치가 바빠지는 compute-bound에 가까워지고, 낮으면 메모리에서 데이터를 가져오는 속도가 병목인 memory-bound에 가까워져요.

예를 들어 원문은 NVIDIA A100을 기준으로 312 TFLOPS tensor 성능과 1.6 TB/s 메모리 대역폭을 들며, 약 195 FLOPS/byte를 임계값처럼 설명해요. ResNet-50의 큰 batch forward pass는 arithmetic intensity가 높아 GPU peak에 가까워질 수 있지만, batch size 1의 BERT inference는 낮은 intensity 때문에 peak 계산 성능의 작은 일부만 활용할 수 있어요.

이 관계를 시각화하는 것이 roofline model이에요. roofline은 workload가 메모리 대역폭에 막히는지, 계산 성능에 막히는지 보여줘요.

분산 시스템에서는 추가 문제가 생겨요.

따라서 system benchmark는 peak FLOPS만 보는 것이 아니라 실제 workload에서의 utilization, memory bandwidth, communication, thermal behavior, fault tolerance를 함께 봐야 해요.

4.4 Data Benchmarks

Data benchmark는 데이터 품질, 대표성, 편향, coverage를 평가해요. 원문은 데이터 품질이 알고리즘이나 하드웨어만큼 실제 배포 성공을 좌우한다고 강조해요.

데이터 benchmark는 다음 질문에 답해야 해요.

4.5 Community-Driven Standardization

벤치마크가 널리 쓰이려면 기술적으로 좋기만 해서는 부족해요. 연구 커뮤니티, 산업계, domain expert가 함께 만들고 받아들여야 해요.

원문은 ImageNet의 성공을 community challenge와 workshop의 지속적 운영에서 찾고, IEEE나 ISO 같은 표준화 조직이 community method를 formal standard로 바꾸는 역할을 설명해요.

성공적인 benchmark에는 governance가 필요해요. version control, 변경 이력, reference implementation, validation suite, containerized environment가 있어야 하고, academic rigor와 industry practicality 사이의 균형도 맞춰야 해요.

5. Benchmarking Granularity

벤치마크는 평가 범위를 어디까지 잡느냐에 따라 micro, macro, end-to-end로 나뉘어요.

5.1 Micro Benchmarks

Micro-benchmark는 tensor operation, convolution, matrix multiplication, activation function, LSTM cell, Transformer block처럼 작은 구성요소를 격리해서 측정해요.

예를 들어 cuDNN이나 DeepBench는 convolution과 matrix multiplication 같은 핵심 연산을 여러 하드웨어에서 측정해요. 이 방식은 어떤 kernel이 병목인지, 어떤 하드웨어가 특정 연산에 강한지 파악하는 데 좋아요.

하지만 micro-benchmark가 좋은 결과를 보여도 전체 모델이나 서비스가 빠르다는 뜻은 아니에요. 작은 부품이 빠른 것과 전체 시스템이 빠른 것은 다릅니다.

5.2 Macro Benchmarks

Macro-benchmark는 완성된 모델 단위로 평가해요. 모델 정확도, 메모리 사용, batch size별 처리량, latency, hardware configuration별 성능을 함께 볼 수 있어요.

ImageNet에서 vision model을 평가하거나 번역 task에서 NLP 모델을 평가하는 것이 여기에 가까워요. MLPerf Inference, MLPerf Mobile, MLPerf Tiny, MLMark, AI-Benchmark 같은 benchmark suite가 이 범주에 들어갑니다.

5.3 End-to-End Benchmarks

End-to-end benchmark는 데이터 추출, 변환, 로딩, 전처리, 모델 실행, 후처리, 저장장치, 네트워크까지 전체 pipeline을 평가해요.

이 수준은 실제 운영과 가장 가깝지만 표준화가 매우 어려워요. 회사마다 데이터, 네트워크, storage, traffic pattern이 다르기 때문이에요. 그래서 원문은 완전히 공개된 end-to-end benchmark가 아직 제한적이며, 많은 조직이 production instrumentation을 통해 내부적으로 수행한다고 설명해요.

5.4 Granularity Trade-offs

핵심 trade-off는 다음과 같아요.

실무에서는 하나만 고르지 않고 조합해야 해요. micro로 병목을 찾고, macro로 모델 수준의 균형을 보고, end-to-end로 실제 운영 성능을 확인하는 식입니다.

6. Benchmark Components

6.1 전체 구성요소

원문은 벤치마크 구현의 공통 요소를 다음처럼 설명해요.

6.2 Problem Definition

문제 정의는 입력, 출력, 성능 요구사항을 명확히 하는 단계예요. 원문은 audio anomaly detection을 예로 들어, 입력은 audio waveform, 출력은 정상/이상 분류, 성능 기준은 정확도·속도·자원 사용이라고 설명해요.

문제 정의가 흐리면 이후 데이터 선택, 모델 선택, metric 선택이 모두 흔들려요. 따라서 benchmark는 가장 먼저 “이 시스템이 무엇을 해야 하는가?”를 형식적으로 정해야 해요.

6.3 Standardized Datasets

표준 데이터셋은 모든 모델을 같은 조건에서 평가하게 해줘요. Vision에서는 ImageNet, COCO, CIFAR-10이, NLP에서는 SQuAD, GLUE, WikiText가 예로 나와요.

데이터셋은 두 가지 조건을 동시에 만족해야 해요.

Audio anomaly detection에서는 정상 소리와 다양한 이상 소리가 모두 있어야 하고, 실제 noise pattern도 포함되어야 해요. 연구용으로 통제된 데이터는 방법 개발에는 좋지만 실제 배포 복잡성을 충분히 담지 못할 수 있어요.

6.4 Model Selection

모델 선택은 baseline을 세우는 작업이에요. 간단한 linear regression이나 logistic regression이 baseline이 될 수도 있고, NLP에서는 BERT 같은 표준 모델이 baseline이 될 수 있어요.

중요한 점은 framework 차이도 성능에 영향을 준다는 거예요. 같은 모델이라도 PyTorch와 TensorFlow에서 operator implementation이나 optimization이 달라 성능 특성이 달라질 수 있어요.

모델은 training과 inference 두 경로에서 모두 고려해야 해요. 학습에서는 목표 정확도에 안정적으로 도달해야 하고, 추론에서는 quantization 같은 최적화 후에도 정확도가 유지되어야 해요.

6.5 Evaluation Metrics

Metric은 task-specific metric과 implementation metric으로 나눌 수 있어요.

원문의 anomaly detection 예시는 model size 270K parameters, 10.4 ms/inference, 0.86 AUC, 516 microjoules/inference를 함께 봐요. 하나의 점수만으로는 충분하지 않기 때문이에요.

6.6 Benchmark Harness

Harness는 benchmark를 실제로 실행하고 측정하는 장치예요. 입력을 어떤 패턴으로 보낼지, 동시에 몇 개 요청을 만들지, warm-up을 어떻게 할지, metric을 어떻게 수집할지 관리해요.

Server deployment에서는 Poisson distribution 같은 방식으로 request arrival을 모델링할 수 있어요. Mobile이나 embedded deployment에서는 sequential image input, multi-sensor stream처럼 실제 사용 패턴을 반영해야 해요.

Harness는 background process, thermal state, power state 같은 환경 요인을 통제하거나 기록해야 하고, metric 수집 자체가 system under test를 과하게 방해하지 않도록 설계되어야 해요.

6.7 System Specifications

재현 가능한 benchmark를 위해서는 시스템 사양을 자세히 기록해야 해요.

이 정보가 없으면 “누가 더 빠른가”보다 “어떤 환경에서 그 결과가 나왔는가”를 알 수 없어요.

6.8 Run Rules

Run rule은 benchmark를 실행하는 절차 규칙이에요. random seed, weight initialization, data shuffling, learning rate, batch size, hyperparameter, dataset preprocessing, code provenance, logging, checkpoint를 명확히 해야 해요.

ML은 stochastic process가 많기 때문에 run rule이 없으면 결과를 비교하기 어렵습니다. 특히 hyperparameter의 작은 차이가 성능을 크게 바꿀 수 있으므로, 제출 결과에는 훈련과 평가에 사용한 모든 설정이 기록되어야 해요.

6.9 Result Interpretation

결과 해석에서는 두 가지를 구분해야 해요.

예를 들어 의료 진단에서는 정확도 1% 향상이 매우 중요할 수 있지만, 어떤 추천 시스템에서는 latency와 cost가 더 중요할 수 있어요. 또한 benchmark overfitting을 피하려면 비슷하지만 다른 task나 실제 배포 환경에서도 성능을 확인해야 해요.

6.10 Compression Benchmarks

Compression benchmark는 pruning, quantization, knowledge distillation, architecture optimization이 모델 크기·정확도·속도·에너지에 미치는 영향을 평가해요.

원문은 다음 차이를 강조해요.

현재 benchmark suite는 dense unoptimized model에 치우친 경우가 있어서, production에서 흔히 쓰는 optimized model을 더 잘 반영해야 한다고 원문은 지적해요.

6.11 Mobile and Edge Benchmarks

Mobile SoC는 CPU, GPU, DSP, NPU가 함께 있는 heterogeneous system이에요. benchmark는 어떤 processor가 어떤 workload를 맡는지, 열 제한과 배터리 제한 속에서 sustained performance가 어떻게 변하는지 측정해야 해요.

원문은 Snapdragon 8 Gen 3의 peak TOPS와 sustained TOPS 차이, computational photography와 background AI의 전력 차이를 예로 들어, peak 성능만으로 모바일 AI를 평가하면 안 된다고 설명해요.

또한 5G/WiFi edge-cloud coordination, URLLC의 1ms 미만 latency 요구, automotive 환경의 ASIL validation과 -40도에서 85도까지의 환경 테스트처럼 domain-specific 조건도 고려해야 해요.

7. Training vs. Inference Evaluation

Training과 inference는 neural network를 사용한다는 점은 같지만 목적과 자원 사용이 완전히 달라요.

원문은 ResNet-50 training이 inference보다 훨씬 많은 GPU 메모리를 요구하고, GPT-3 training처럼 거대한 학습은 오랜 기간 많은 accelerator를 쓰지만, inference는 수많은 사용자 요청에 millisecond 단위로 응답해야 한다고 설명해요.

8. Training Benchmarks

8.1 Training Benchmark Motivation

Training benchmark는 모델 architecture, data loader, hardware configuration, distributed training strategy가 학습 효율에 미치는 영향을 평가해요.

대형 모델은 수십억 또는 수천억 parameter, terabyte 단위 데이터, 분산 computing을 요구할 수 있어요. 따라서 단일 GPU가 빠른지보다 전체 training workflow가 목표 정확도에 얼마나 효율적으로 도달하는지가 중요해요.

또한 data pipeline도 benchmark 대상이에요. 이미지나 텍스트 데이터를 제때 불러오지 못하면 accelerator가 놀게 되고, 이 경우 아무리 좋은 GPU를 써도 throughput이 낮아져요.

8.2 Training Metrics

Training benchmark의 핵심은 speed가 아니라 speed to valid accuracy예요.

$$ T_{\text{train}} = \arg\min_t {\text{accuracy}(t) \geq \text{target accuracy}} $$

이 식은 “정확도가 목표치 이상이 되는 가장 이른 시간”을 의미해요.

처리량은 다음처럼 계산할 수 있어요.

$$ \text{Throughput} = \frac{N_{\text{samples}}}{T_{\text{train}}} $$

하지만 throughput이 높아도 target accuracy에 도달하지 못하면 유효한 benchmark 결과가 아니에요. MLPerf Training처럼 정확도 기준을 명시하는 이유가 여기에 있어요.

Training에서 중요한 지표는 다음과 같아요.

8.3 Scalability and Parallelism

대형 모델 학습에서는 data parallelism, model parallelism, pipeline parallelism이 사용돼요.

이론적으로 GPU를 두 배로 늘리면 시간이 절반이 되어야 하지만, 실제로는 communication overhead, memory bandwidth, synchronization 때문에 완벽한 선형 scaling은 어렵습니다.

8.4 Resource Utilization

Training benchmark는 GPU utilization만 보는 것이 아니라, 왜 utilization이 낮은지도 찾아야 해요. BERT를 TPU cluster에서 학습할 때 input pipeline이 느리면 TPU가 고성능이어도 놀게 됩니다.

따라서 data prefetching, caching, sharding, storage throughput, preprocessing speed가 모두 benchmark 대상이 됩니다.

8.5 Energy, Cost, Fault Tolerance, Reproducibility

대형 학습은 전기와 비용이 큽니다. 원문은 GPT-3 training의 에너지 사용량을 예로 들며, 정확도에 더 적은 iteration으로 도달하면 에너지와 비용을 직접 줄일 수 있다고 설명해요.

또한 training job은 며칠 또는 몇 주 동안 실행될 수 있어서 장애 대응이 중요해요. checkpointing은 장애 복구에 필요하지만 checkpoint를 너무 자주 쓰면 throughput이 떨어질 수 있어요. 따라서 checkpoint overhead와 recovery success rate도 benchmark에 들어가야 해요.

재현성은 seed, framework, compiler, floating-point behavior, library version에 의해 흔들릴 수 있어요. 제대로 된 benchmark는 여러 실행과 환경에서 결과가 안정적인지 확인해야 합니다.

8.6 Training Benchmark Pitfalls

원문이 지적하는 training benchmark 함정은 다음과 같아요.

9. Inference Benchmarks

9.1 Inference Benchmark Motivation

Inference benchmark는 학습이 끝난 모델을 실제로 배포해 예측할 때의 효율, 지연시간, 자원 요구량을 평가해요.

추론은 cloud datacenter, mobile device, IoT, embedded processor, tinyML까지 매우 다양한 환경에서 실행돼요. 그래서 GPU나 TPU뿐 아니라 NPU, FPGA, Edge TPU 같은 추론용 hardware도 benchmark 대상이 됩니다.

추론의 핵심 질문은 다음과 같아요.

9.2 Inference Metrics

Latency는 요청 하나가 들어와 결과가 나올 때까지의 시간이에요. 평균 latency도 유용하지만 production에서는 p95, p99 같은 tail latency가 매우 중요해요.

예를 들어 평균은 50ms인데 p99가 500ms라면, 많은 사용자는 빠르게 느끼지만 일부 사용자는 매우 느린 경험을 하게 돼요. 대규모 서비스에서는 1%의 느린 요청도 수천, 수만 명에게 영향을 줄 수 있어요.

Throughput은 초당 처리하는 요청 수예요. QPS나 FPS로 표현할 수 있어요. Batch inference는 throughput을 높일 수 있지만, 실시간 시스템에서는 latency를 악화시킬 수 있어요.

정밀도와 정확도 trade-off도 중요해요.

Memory footprint와 model size는 특히 edge와 mobile에서 중요해요. 모델이 정확해도 RAM이나 storage 한계를 넘으면 배포할 수 없어요.

Cold-start와 model load time은 serverless AI나 on-demand inference에서 중요해요. 모델을 매번 새로 로드해야 하면 첫 요청이 매우 느릴 수 있어요.

Dynamic workload scaling은 수요가 급증하거나 여러 모델이 동시에 실행될 때 latency와 throughput을 유지할 수 있는지를 봐요.

Energy efficiency는 joules/inference 또는 QPS/W처럼 측정돼요. inference는 계속 실행되므로 작은 비효율도 누적 비용이 큽니다.

9.3 Inference Performance Evaluation

원문은 inference 평가가 context-dependent라고 강조해요.

같은 latency도 환경에 따라 중요도가 달라져요. 실시간 시스템에서는 p95 latency가 핵심이지만, cloud batch service에서는 aggregate throughput이 더 중요할 수 있어요.

9.4 Inference Benchmark Pitfalls

Inference benchmark의 흔한 함정은 다음과 같아요.

9.5 MLPerf Inference Benchmarks

MLPerf Inference는 MLCommons가 만든 표준 추론 benchmark예요. 처음에는 하나의 benchmark였지만, 배포 환경이 다양해지면서 여러 계열로 나뉘었어요.

원문은 MLPerf 결과가 실제 hardware procurement에도 영향을 준다고 설명해요. 특히 recommendation system에서 DLRM workload 같은 결과는 accelerator 선택에 직접 쓰일 수 있어요.

다만 MLPerf 제출은 비용이 큽니다. 최적화, tuning, validation, hardware/cloud 비용이 커서 대기업과 hardware vendor가 주로 제출하고, 작은 조직은 공개 결과를 참고하거나 더 가벼운 내부 benchmark를 운영해야 할 수 있어요.

10. Power Measurement Techniques

10.1 왜 전력 측정이 어려운가요?

ML 배포 환경은 microwatt 수준 TinyML부터 kilowatt 수준 data center rack까지 넓게 퍼져 있어요. 그래서 하나의 전력 측정 방식으로 모든 환경을 공정하게 재기 어렵습니다.

전력 측정은 반드시 boundary를 정해야 해요.

측정 경계가 다르면 같은 시스템도 전력 효율이 다르게 보일 수 있어요.

10.2 System-level Power Measurement

Component 하나만 측정하면 전체 에너지를 놓칠 수 있어요. 원문은 mobile TensorFlow workload에서 data movement가 inference energy의 큰 비중을 차지할 수 있다고 설명해요. 즉 계산 자체보다 메모리에서 데이터를 옮기는 일이 더 많은 전기를 쓸 수 있어요.

Data center에서는 cooling과 power delivery도 중요해요. 냉각은 전체 facility power의 큰 부분을 차지할 수 있고, PUE는 data center 전력 효율을 나타내는 지표예요.

10.3 Computational Efficiency vs. Power Consumption

성능을 높이면 전력이 항상 비례해서 좋아지는 것은 아니에요. clock frequency를 올리면 성능은 조금 오르지만 전력은 훨씬 크게 늘 수 있어요. 원문은 frequency 20% 증가가 성능은 약간만 높이고 전력은 크게 늘릴 수 있다고 설명해요.

따라서 최적점은 환경에 따라 달라요.

Quantization이나 compression은 정확도를 1-2% 정도만 잃으면서 속도와 에너지 효율을 크게 개선할 수 있지만, 모든 task에서 자동으로 안전한 것은 아니므로 benchmark로 확인해야 해요.

10.4 Standardized Power Measurement

ML workload는 power profile이 일정하지 않아요. 어떤 모델은 짧고 강한 power spike를 만들고, 어떤 CNN inference는 비교적 일정한 전력 패턴을 보일 수 있어요.

따라서 전력 benchmark는 다음을 고려해야 해요.

10.5 MLPerf Power Case Study

MLPerf Power는 datacenter, edge, tiny inference 등 다양한 ML 배포 환경의 에너지 효율을 표준 방식으로 측정하려는 framework예요.

원문은 MLPerf Power가 여러 hardware architecture에서 비교 가능성을 유지하면서 전력 측정의 integrity를 확보하려 한다고 설명해요. 또한 MLPerf 버전이 누적되며 전통 ML workload에서는 에너지 효율 개선이 plateau에 가까워지는 반면, generative AI 영역에서는 급격한 효율 개선이 나타나는 경향을 언급해요.

이것은 두 가지 과제를 보여줘요. 기존 workload에서는 효율 한계를 돌파할 새 접근이 필요하고, generative AI에서는 빠른 확장을 지속 가능하게 만들 측정과 최적화가 필요해요.

11. Benchmarking Limitations and Best Practices

11.1 Statistical and Methodological Issues

벤치마크에는 한계가 있어요. 원문은 먼저 통계적·방법론적 문제를 지적해요.

11.2 Laboratory-to-Deployment Performance Gaps

실험실 benchmark는 controlled condition에서 실행돼요. 하지만 배포 환경은 noisy하고 dynamic해요.

Benchmark가 accuracy와 throughput을 높게 보여도, 실제 서비스에서는 power, cost, robustness, tail latency, 유지보수 복잡성, business requirement가 더 중요할 수 있어요.

따라서 표준 benchmark 결과는 시작점이지 최종 결론이 아니에요.

11.3 Environmental Conditions

온도, 습도, 고도, 공기 흐름, 전원 안정성, background process, network condition은 benchmark 결과에 영향을 줄 수 있어요.

예를 들어 높은 온도는 thermal throttling을 일으켜 성능을 낮출 수 있고, cloud 환경에서는 같은 instance type이라도 주변 workload와 전원 관리 상태에 따라 결과가 달라질 수 있어요.

따라서 환경 조건을 통제하거나 최소한 자세히 기록해야 해요.

11.4 Hardware Lottery

Hardware lottery는 어떤 알고리즘이 “본질적으로 더 좋아서” 성공한 것이 아니라, 현재 널리 쓰이는 하드웨어에 잘 맞아서 성공할 수 있다는 현상을 말해요.

Transformer가 GPU의 matrix multiplication에 잘 맞는 것처럼, 특정 architecture는 기존 hardware에서 매우 효율적일 수 있어요. 반대로 좋은 아이디어라도 현재 hardware에 잘 매핑되지 않으면 benchmark에서 낮게 평가될 수 있어요.

그래서 benchmark는 다양한 hardware configuration에서 모델을 평가해야 해요. 하나의 GPU에서 좋은 결과가 CPU, DSP, EdgeTPU, NPU에서도 좋은 것은 아닙니다.

11.5 Benchmark Engineering, Bias, Over-Optimization

Benchmark engineering은 실제 성능 향상보다 benchmark 점수를 높이기 위해 hyperparameter, preprocessing, model architecture를 조정하는 행위예요.

여기에는 Goodhart’s Law가 적용돼요.

어떤 측정값이 목표가 되면, 그 측정값은 좋은 측정값으로서의 힘을 잃기 시작해요.

이를 줄이려면 다음 전략이 필요해요.

11.6 Benchmark Evolution

벤치마크는 안정성과 적응성 사이에서 균형을 잡아야 해요. 너무 자주 바뀌면 과거 결과와 비교하기 어렵고, 너무 오래 고정되면 낡은 문제에만 최적화하게 돼요.

Image classification 중심 benchmark에서 NLP, recommendation, generative AI, edge AI, scientific AI benchmark로 확장된 흐름은 AI application이 다양해졌기 때문이에요.

앞으로 benchmark는 accuracy와 throughput뿐 아니라 fairness, robustness, scalability, energy efficiency, safety 같은 차원도 함께 반영해야 해요.

11.7 MLPerf as Industry Standard

MLPerf는 reference implementation, 명확한 rule, 재현 가능한 환경을 제공해 benchmark variability를 줄이려는 industry standard예요.

또한 MLPerf Inference, Mobile, Client, Tiny처럼 deployment constraint별 benchmark를 제공하고, generative AI나 energy-efficient computing처럼 새 과제를 반영하며 계속 진화해요.

원문은 MLPerf의 핵심 가치를 fairness, transparency, adaptability로 정리할 수 있게 설명해요.

12. Model and Data Benchmarking

12.1 Model Benchmarking

Model benchmark는 알고리즘이 특정 task를 얼마나 잘 수행하는지 봐요. 초기에는 accuracy가 중심이었지만, 이제는 fairness, robustness, efficiency, generalizability도 중요해졌어요.

원문은 MNIST, ImageNet, COCO, GPT-3 training corpus 같은 dataset이 모델 발전을 이끈 사례를 언급해요.

하지만 LLM 시대에는 새로운 문제가 생겨요. benchmark dataset이 web corpus에 섞여 모델 pre-training에 들어가면, 모델이 문제를 이해해서 잘 푸는 것이 아니라 이미 본 문제를 기억해서 높은 점수를 받을 수 있어요. 이것은 전통 시스템 benchmark engineering과 다르게, 코드 최적화가 아니라 데이터 노출을 통해 발생할 수 있는 benchmark adaptation이에요.

또한 Gender Shades 사례처럼 aggregate accuracy만 보면 특정 집단에서 성능이 낮은 문제를 놓칠 수 있어요. 따라서 model benchmark는 fairness와 subgroup performance를 포함해야 해요.

12.2 Data Benchmarking

Data benchmarking은 모델 구조보다 데이터 품질이 성능 한계를 좌우할 수 있다는 data-centric AI 관점에서 중요해요.

원문은 DataPerf와 DataComp를 언급하며, carefully curated subset이 전체 데이터보다 더 나은 성능을 낼 수 있다는 점을 설명해요. 즉 데이터가 많다고 항상 좋은 것은 아니에요.

또한 dataset saturation 문제가 있어요. ImageNet이나 MNIST에서 모델이 매우 높은 점수를 받으면, 그것이 진짜 능력 향상인지 test set artifact에 맞춘 결과인지 구분하기 어려워져요.

이에 대한 대응으로 Dynabench처럼 모델 성능에 따라 test data를 계속 발전시키는 dynamic benchmark가 등장해요. WILDS, RxRx 같은 benchmark는 out-of-distribution generalization을 평가하고, MSWC 같은 speech dataset은 bias와 representation 문제를 다룹니다.

12.3 Holistic System-Model-Data Evaluation

실제 AI 성능은 system, model, data의 상호작용에서 나와요. 빠른 시스템도 나쁜 모델을 보완할 수 없고, 강력한 모델도 편향된 데이터 위에서는 신뢰하기 어려워요.

따라서 앞으로의 benchmark는 세 차원을 함께 봐야 해요.

System efficiency
        +
Model performance
        +
Data quality
        ↓
실제 배포 가능한 AI 성능

이 통합 관점은 정확도뿐 아니라 효율, 공정성, 견고성, 윤리적 배포까지 함께 평가하게 해요.

13. Production Environment Evaluation

지금까지의 benchmark는 주로 controlled condition을 다뤘어요. 하지만 production ML system은 동적 workload, 변하는 데이터 품질, infrastructure failure, concurrent user demand를 처리해야 해요.

원문은 production benchmark가 단일 성능 측정을 넘어 시간에 따른 행동, stress 상황, failure 상황까지 평가해야 한다고 설명해요.

13.1 Silent Failure Detection

ML 모델은 오류 메시지 없이 성능이 나빠질 수 있어요. 그럴듯하지만 틀린 답을 내면 일반 monitoring만으로는 발견하기 어렵습니다.

그래서 production benchmark는 baseline performance distribution을 만들고, subtle accuracy degradation을 statistical process control로 감지해야 해요. A/B testing은 새 모델과 기존 모델을 같은 traffic 조건에서 비교하는 방법이에요.

13.2 Continuous Data Quality Monitoring

Production data stream은 시간이 지나며 변할 수 있어요. distribution shift, adversarial examples, corrupted input, missing features, out-of-range values가 들어올 수 있어요.

Monitoring system은 training data와 production data의 feature distribution 차이를 추적하고, retraining이 필요한 시점을 판단해야 해요. Data validation pipeline은 preprocessing이 이상 입력을 조용히 망가뜨리지 않는지도 benchmark해야 합니다.

13.3 Load Testing and Capacity Planning

실제 서비스는 시간대별 traffic, 갑작스러운 요청 폭증, 장기적 성장 패턴을 가질 수 있어요. Load testing은 이런 요청 패턴에서 latency requirement를 유지하는지 확인해요.

Capacity planning benchmark는 system utilization이 한계에 가까워질 때 성능이 어떻게 나빠지는지 측정해서 proactive scaling 결정을 돕습니다.

13.4 Operational Resilience Benchmarking

Production system은 inference server가 죽거나, network latency가 늘거나, compute resource가 줄어드는 상황에서도 완전히 무너지지 않아야 해요.

Chaos engineering은 이런 failure를 의도적으로 주입해 degradation pattern과 recovery behavior를 측정해요. 단, 실제 사용자 영향과 실험 위험을 조절해야 하므로 신중한 설계가 필요해요.

13.5 Continuous Model Validation

Shadow deployment는 새 모델을 실제 traffic 옆에서 실행하되 사용자에게 영향을 주지 않고 결과를 비교하는 방법이에요. Champion-challenger framework는 현재 production model과 새 후보 모델을 통제된 rollout으로 비교해요.

Production benchmark는 accuracy만이 아니라 reliability, operational efficiency, user experience, cost까지 포함해야 합니다.

14. Fallacies and Pitfalls

원문 마지막 부분은 benchmark를 해석할 때 흔히 빠지는 오류를 정리해요.

14.1 Benchmark 점수가 실제 성능으로 바로 이어진다는 착각

Benchmark는 curated dataset, standardized protocol, optimal configuration에서 실행돼요. Production에는 data quality issue, distribution shift, latency constraint, resource limitation이 있어요.

따라서 benchmark ranking만 보고 시스템을 고르면 실제 서비스에서 실패할 수 있어요.

14.2 Benchmark metric만 최적화하는 함정

특정 benchmark 점수만 올리면 robustness, calibration, fairness, energy efficiency가 나빠질 수 있어요. 이것은 benchmark overfitting의 형태예요.

14.3 단일 metric이면 충분하다는 착각

현대 AI 시스템은 accuracy, latency, throughput, energy, fairness, robustness를 모두 봐야 해요. 어떤 metric이 가장 중요한지는 stakeholder와 deployment context에 따라 달라요.

14.4 낡은 benchmark를 계속 쓰는 함정

모델이 발전하면 benchmark가 saturated될 수 있어요. 더 이상 모델 차이를 잘 구분하지 못하거나, 현재 문제를 반영하지 못할 수 있어요.

14.5 연구 benchmark를 production 평가에 그대로 쓰는 함정

Research benchmark는 비교를 위해 이상적인 조건을 가정하는 경우가 많아요. Production은 concurrent load, network latency, memory limit, failure, cost, availability, user experience가 중요해요.

따라서 production에서는 benchmark 결과에 operational metric을 더해야 해요.

15. Summary

이 장의 결론은 명확해요. 벤치마킹은 AI 시스템에서 성능 주장과 최적화 전략을 검증하는 측정 기반이에요.

원문은 세 차원의 통합 평가를 다시 강조해요.

또한 미래의 benchmark는 안전성, 공정성, 환경 영향까지 포함해야 해요. AI가 중요한 사회적 의사결정에 쓰일수록, 우리가 무엇을 측정하느냐가 무엇을 최적화하느냐를 결정하기 때문이에요.

마지막으로 이 장의 전체 흐름을 한 번 더 압축하면 다음과 같아요.

역사적 교훈
  → 대표 workload, 다중 지표, 통합 시스템 평가
ML 특수성
  → 확률성, 데이터 의존성, 정확도-효율 trade-off
구체적 설계
  → 문제, 데이터, 모델, metric, harness, run rule
학습/추론 구분
  → time-to-accuracy vs latency/tail latency
전력 측정
  → 경계, sampling, memory, cooling, thermal effect
한계와 운영
  → 재현성, hardware lottery, benchmark overfitting, production monitoring

복습 질문

1. AI 벤치마킹에서 정확도 하나만으로 시스템을 평가하면 왜 위험한가요?
2. 알고리즘 벤치마크, 시스템 벤치마크, 데이터 벤치마크는 각각 무엇을 측정하나요?
3. Micro, macro, end-to-end benchmark는 어떤 trade-off를 가지나요?
4. Training benchmark에서 throughput보다 time-to-accuracy가 중요한 이유는 무엇인가요?
5. Inference benchmark에서 평균 latency보다 p95, p99 tail latency가 중요한 상황은 언제인가요?
6. Roofline model은 compute-bound와 memory-bound를 구분하는 데 어떤 도움을 주나요?
7. Quantization이나 pruning을 benchmark할 때 accuracy와 speedup을 함께 봐야 하는 이유는 무엇인가요?
8. 전력 측정에서 measurement boundary를 명확히 해야 하는 이유는 무엇인가요?
9. Hardware lottery와 benchmark engineering은 각각 benchmark 해석을 어떻게 왜곡할 수 있나요?
10. Production environment evaluation이 실험실 benchmark와 달리 반드시 포함해야 하는 요소는 무엇인가요?