# \#aiperf **URL:** https://discuss.pytorch.kr/tag/aiperf/9172.md [최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md) --- ## [AIPerf: 서버 성능 측정 시, 부하 생성기가 병목이 되지 않도록 NVIDIA가 개발 및 공개한 LLM 추론 벤치마크 도구](https://discuss.pytorch.kr/t/aiperf-nvidia-llm/11975)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [9월 22, 2026, 9:00오전 UTC](https://discuss.pytorch.kr/t/aiperf-nvidia-llm/11975 "2026-09-22T09:00:46Z")
AIPerf 소개: 측정 도구가 측정 대상을 가려 버리는 문제 모델을 서버에 올리고 프롬프트를 던지면 응답이 돌아옵니다. 그다음에 반드시 나오는 질문은 "이거 빠른 건가요?" 입니다. 이 질문에 답하려고 개발자들이 가장 먼저 하는 일은 대개 curl을 몇 번 날려 보거나, asyncio 기반의 짧은 부하 스크립트를 직접 짜거나, 일회용 부하 생성기를 하나 더 만드는 것입니다. NVIDIA 기술 블로그가 지적하는 문제는 이 세 갈래가 결국 같은 곳에서 무너진다는 점입니다. 단일 프로세스의 성능 한계에 걸리거나, 파이썬의 전역 인터프리터 잠금(Global Interpreter Lock, GIL) 이 동시성을 제한하거나, 애초에 자기가 만든 기준선에 대고 측정한 숫자가 나옵니다. 어느 쪽이든 완전히 신뢰하기 어려운 결과가, 요구사항이 바뀌는 순간 다시 짜야 하는 도구에 묶인 채로 남습니다. 이 문제가 LLM 서빙에서 유독 고약한 이유가 있습니다. 부하 생성기가 병목이 되면 측정값은 서버의 성능이 아니라 클라이언트의 성능을 반영하게 되는데, 겉으로는 구분이 되지 않습니다. 서버가 낼 수 있는 토큰 속도보다 클라이언트가 파싱할 수 있는 속도가 낮으면 리포트에는 낮은 쪽 숫자가 찍히고, 그 숫자를 근거로 GPU를 더 사는 결정이 내려집니다. 게다가 LLM 추론은 요청 하나가 수 초 동안 스트리밍되면서 수십에서 수백 개의 청크를 보내기 때문에, 부하 생성기가 처리해야 하는 이벤트 수가 일반적인 HTTP 벤치마크와 자릿수가 다릅니다. AIPerf는 이 지점을 겨냥해 NVIDIA가 바닥부터 다시 만든 생성형 AI 추론(inference) 벤치마크 도구입니다. NVIDIA는 AIPerf를 Triton Inference Server의 perf\_analyzer 안에 있던 GenAI-Perf의 지정된 후속 도구(designated successor) 로 규정하고, GenAI-Perf가 얹혀 있던 Perf Analyzer 위에서 돌아가는 구조 자체를 끊어 냈습니다. 저장소는 a…