Are LLM Performance Benchmarks Reliable? — Ashok Chandrasekar & Jason Kramberger, Google

한 줄 핵심

LLM 성능 벤치마크는 단순히 숫자를 재는 도구가 아니라, 클라이언트 동작·메트릭 정확도·워크로드 재현성을 함께 검증해야만 생산 환경에서 믿을 수 있다.

시간별 요약

0:00
다른 사람의 수치를 재현하지 못한 두 Google 엔지니어 LLM 성능 평가와 최적화를 다루는 두 발표자가 inference perf와 LLMD benchmarking의 배경을 소개하고, 기존 벤치마크 생태계가 모델 서버용, 경쟁 분석용, 웹 부하용으로 나뉘어 있음을 정리한다. 이 영상의 초점은 production scale inference serving stack을 정확하게 측정하는 벤치마크 문제다.
2:47
프로덕션 규모 벤치마크가 해야 할 일 production scale 벤치마크는 단순한 synthetic 부하가 아니라 실제 온라인 서빙과 batch workload를 반영해야 하며, 높은 부하를 걸 수 있어야 한다. 또한 정확한 메트릭, 포화 지점을 찾는 능력, SLO 준수 여부까지 확인할 수 있어야 비용과 성능을 함께 최적화할 수 있다.
4:34
메트릭, 관측성, 재현성, 데이터의 네 가지 함정 벤치마크 결과가 다른 사람의 수치와 잘 맞지 않는 이유로 정확한 메트릭, 도구 자체의 관측성, 재현성, 데이터셋 품질이 핵심 문제로 제시된다. 벤치마크 하네스가 실제로 부하를 유지하고 있는지, 데이터가 일관되게 생성되는지, 입력 데이터의 품질이 충분한지 확인해야 한다.
5:29
200 QPS를 요청했는데 38 QPS가 나온다 Python의 GIL 때문에 단일 프로세스 벤치마크 하네스는 CPU가 충분해도 처리량이 쉽게 제한되며, 요청한 QPS를 실제로 달성하지 못하는 경우가 생긴다. 사용자는 200 QPS를 보냈다고 믿지만 실제로는 38 QPS만 나가는 식으로, 하네스의 한계가 결과를 왜곡한다.
6:35
클라이언트가 지연시간을 58초나 부풀린다 벤치마크 클라이언트가 스트리밍 토큰 요청을 처리하느라 자체적으로 병목이 생기면 서버 지연시간이 크게 부풀려질 수 있으며, 실제로 최대 58초까지 왜곡된 사례가 있었다. 이 경우 서버가 느린 것이 아니라 측정 도구가 지연을 만들어내는 것이므로, 클라이언트와 서버를 분리해 관찰해야 한다.
7:16
temperature 0과 20% 착시 temperature를 0으로 두면 출력이 더 결정적이어서 실제 워크로드보다 throughput이 높게 나올 수 있고, 20% 개선처럼 보이는 결과가 착시일 수 있다. 같은 데이터셋도 하네스마다 샘플링과 truncation 방식이 달라 입력 토큰 수가 달라지므로, 실제 사용 환경과 맞는 설정이 중요하다.
8:39
멀티프로세스 로드 제너레이터인 Inference Perf Inference Perf는 재현 가능한 선언적 설정을 제공하고, Python의 GIL 문제를 피하는 멀티프로세스 로드 제너레이터를 통해 실제 부하와 클라이언트 상태를 함께 관측한다. 또한 5,000 QPS 수준에서도 부하를 유지하며, 대화 replay 같은 세부 설정을 통해 워크로드를 정밀하게 표현할 수 있다.
11:51
공유 가능한 워크로드 카탈로그 표준화된 workload catalog를 통해 multi-turn 생성, tree of thought, agentic generation, batch summarization 같은 대표 워크로드를 자연어 설명과 세부 설정으로 공유할 수 있다. 이를 Prism 같은 UI와 연결해 벤치마크 결과를 시각화하고, production scale에서의 최적화 효과를 비교 가능하게 만든다.
14:02
벤치마크 타당성을 위한 원칙 검증 가능한 벤치마크를 위해서는 클라이언트 동시성, 클라이언트 행동에 대한 관측성, 메트릭 정확도, 현실적인 비결정성 설정, 그리고 실제 목적에 가까운 데이터셋이 모두 필요하다. 워크로드 카탈로그와 도구를 표준화하면 결과를 더 쉽게 공유하고 재현할 수 있다.

실무 인사이트

벤치마크 결과를 볼 때는 서버 수치보다 먼저 하네스가 요청한 부하를 실제로 보냈는지와 클라이언트 병목이 없었는지를 확인해야 한다.
temperature, 샘플링, truncation, 종료 조건 같은 워크로드 설정을 고정하지 않으면 성능 차이처럼 보이는 현상이 측정 편차일 수 있다.
팀 내부 기준을 만들 때는 QPS 하나가 아니라 입력/출력 길이 분포, 동시성, SLO, 관측성까지 포함한 표준 워크로드 정의가 필요하다.