LLM Goodput이 높아도 충분한 용량일까? SLO 충족률로 가려보기
LLM의 Goodput이 높아져도 서비스 용량이 충분하다고 단정할 수는 없습니다. 목표를 지킨 요청이 초당 몇 개였는지와, 전체 시도 중 몇 %가 목표를 지켰는지는 다른 질문입니다. 용량 후보를 고를 때는 요청별 조건을 동시에 통과했는지, 오류까지 포함한 충족률이 목표 이상인지를 함께 확인해야 합니다.
먼저 확인할 것은 “좋은 요청”의 분모입니다. 완료된 응답만 보고 있다면 실패·타임아웃을 포함한 전체 시도로 다시 나눠보세요. 그다음 통과율을 지킨 후보끼리 처리량을 비교하는 것이 안전한 순서입니다.
기준일: 2026년 10월 23일 KST. 공식 문서와 논문을 읽고 구성한 분석이며, 아래 요청 수·지연 기준·도식은 모두 가상입니다. Windows의 Node.js 24.14.1로 산술과 조건 판정만 실행했습니다. 실제 LLM·GPU·AIPerf 벤치마크나 유료 API는 실행하지 않았습니다.
- 요청별 허용 기준과 SLO — 한 요청의 합격선과 서비스가 지킬 목표.
- Goodput과 충족률 — 초당 합격 요청 수와 전체 시도 중 합격 비율.
- 같은 60초의 두 후보 — 처리량이 더 높은 쪽이 목표에는 탈락하는 예.
- 공동 통과와 실패 분모 — 두 조건을 따로 보거나 오류를 빼면 생기는 착시.
- 부하별 용량 판단 — 한 번의 결과를 최대 용량으로 부르지 않는 방법.
1. 요청의 합격선과 서비스 목표는 다릅니다
요청별 허용 기준은 한 요청을 통과로 셀 조건입니다. 이 글에서는 “오류 없이 완료하고, TTFT 1초 이하이며, 요청별 평균 TPOT 80ms 이하”를 예로 들겠습니다. TTFT는 첫 내용 토큰까지의 기다림, TPOT는 첫 토큰 이후 출력 토큰당 평균 시간입니다. 둘 중 하나만 지켜서는 통과가 아닙니다.
SLO(Service Level Objective)는 서비스가 지키려는 목표입니다. 예를 들어 “정한 관측 구간의 전체 시도 중 위 조건을 모두 만족한 비율이 95% 이상”으로 정할 수 있습니다. 앞의 1초·80ms는 요청의 합격선이고, 95%는 집계 결과를 판단할 목표 비율입니다. 모두 설명을 위해 선택한 값이지 업계 공통 권장값은 아닙니다.
Google SRE의 SLO 설명은 좋은 사건 수를 전체 사건 수로 나누는 지표와 목표를 구분합니다. 무엇을 좋은 사건으로 셀지, 관측 지점과 기간은 무엇인지가 먼저 정해져야 숫자가 의사결정에 쓰입니다.
기본 용어가 낯설다면 기존 한국어 가이드 LLM 추론 성능 지표 이해하기를 먼저 보세요. 이번 글은 용어 사전을 반복하기보다 이미 계산한 숫자로 용량 후보를 걸러내는 과정에 집중합니다.
2. Goodput 하나만으로는 목표 달성을 알 수 없습니다
Goodput(유효 처리율)을 여기서는 정한 요청별 조건을 모두 만족한 요청의 초당 처리율로 사용합니다. 단위는 req/s입니다. SLO 충족률은 같은 통과 요청 수를 전체 시도 수로 나눈 비율이며 단위는 %입니다.
Goodput = 통과 요청 수 ÷ 관측 시간(초)
충족률 = 통과 요청 수 ÷ 전체 시도 수 × 100
이 글의 통과 요청은 오류 없이 완료하고 TTFT·평균 TPOT 조건을 모두 만족한 요청입니다. 모든 요청의 판정이 끝난 가상 집합을 사용합니다. 관측 경계에 남은 요청을 임의로 삭제하지 않습니다.
NVIDIA AIPerf의 Goodput 문서도 처리율과 목표 충족 비율을 구분합니다. Goodput은 조건을 지킨 요청이 초당 얼마나 나왔는지를 보여주지만, “전체의 95%가 조건을 지켰는가”에는 별도의 비율이 필요합니다.
주의할 점도 있습니다. 여기서 “좋다”는 뜻은 설정한 지연·완료 조건을 지켰다는 것입니다. 답변의 사실성·유용성·안전성까지 검증했다는 뜻은 아닙니다.
3. 가상 비교: Goodput은 늘었지만 목표에는 탈락합니다
각각 60초로 끝나는 가상 관측 A·B를 비교해보겠습니다. 모든 시도는 그 구간 안에 성공·오류·타임아웃 중 하나로 판정이 끝났다고 가정합니다. 성공 완료한 요청은 모두 200개 출력 토큰을 냈고, 요청별 합격선과 목표 비율은 같습니다. 실제 도착 시각이나 장기 정상 상태를 측정한 결과가 아닙니다.
| 항목 | A | B |
|---|---|---|
| 전체 시도 | 100건 | 200건 |
| 성공 완료 | 98건 | 190건 |
| 오류 등 | 2건 | 10건 |
| 조건 통과 | 96건 | 140건 |
| 출력 처리량* | 326.67 token/s | 633.33 token/s |
| 유효 처리율 | 1.60 req/s | 2.33 req/s |
| 충족률 | 96% | 70% |
| 95% 목표 | 통과 | 미달 |
*이 예제의 출력 처리량은 성공 완료한 요청의 출력 토큰 합 ÷ 60초입니다. 오류 요청의 부분 출력은 제외했습니다. 실제 도구와 비교할 때는 토큰 집계 범위·워밍업·시간 경계를 맞춰야 합니다. 소수는 둘째 자리까지 반올림했습니다.
A · 96 / 100건 = 96%Goodput 1.60 req/s
설정한 95% 목표를 통과합니다.
B · 140 / 200건 = 70%Goodput 2.33 req/s
처리율은 높지만 95% 목표에는 미달합니다.
B는 토큰 처리량과 Goodput 모두 더 높습니다. 그런데 이 예제의 서비스 목표를 만족하는 후보는 A뿐입니다. “Goodput이 늘었다”와 “현재 부하를 목표 품질로 감당했다”는 같은 결론이 아닙니다.
반대로 A를 서비스의 최대 용량이라고 부를 수도 없습니다. 두 가상 집합만 비교했을 뿐, 그 사이 부하나 다른 구성에서 어디까지 목표를 지키는지 탐색하지 않았기 때문입니다.
4. 두 가지 착시: 조건을 따로 세거나, 실패를 분모에서 빼기
공동 통과는 같은 요청이 필요한 조건을 모두 지킨 상태입니다. 예를 들어 100건 중 5건은 TTFT만 늦고, 다른 5건은 TPOT만 느리며, 나머지 90건은 모두 통과했다고 가정해보세요. TTFT 통과율과 TPOT 통과율은 각각 95%지만, 두 조건을 동시에 지킨 비율은 90%입니다.
각 지표의 요약 수치가 합격처럼 보인다고, 같은 요청들이 함께 합격했다고 결론 내리지 마세요. 요청별 식별자를 기준으로 성공 여부와 두 지연 조건을 묶어 판정해야 합니다. 이 예시는 집합을 직접 센 산술이며 두 지표가 독립이라는 통계 가정은 쓰지 않았습니다.
분모에서 사라진 실패도 확인해야 합니다. 1,000번 시도해 200건만 성공했고 그 200건이 모두 빠른 경우, 성공 응답만 나누면 100%처럼 보입니다. 하지만 전체 시도 중 통과 비율은 20%입니다.
AIPerf 문서는 good_request_fraction의 분모에 정상 요청과 오류 요청을 함께 넣는 이유를 설명합니다. 이 글 역시 같은 취지로 오류·타임아웃을 전체 시도에 포함합니다. 다만 재시도·취소·수신되지 않은 요청을 어떻게 식별하는지는 실제 관측 지점과 운영 정책에 맞춰 별도로 정해야 합니다.
TTFT를 재기 전에 실패한 요청에는 유효한 TTFT 값이 없을 수 있습니다. 그런 요청을 지연 백분위 계산에서 다루는 방식과, 목표 충족률의 분모에 남겨두는 판단은 서로 다른 문제입니다.
5. 용량은 “목표를 지키는 부하”로 비교합니다
목표를 지키는 용량은 지정한 작업·구성·지연 목표 아래에서 감당할 수 있는 부하입니다. OSDI 2024 DistServe 연구는 TTFT와 TPOT 제약을 지키면서 처리할 수 있는 최대 요청률을 중요하게 봅니다. 논문의 특정 조건에서 얻은 수치를 지금의 모든 모델이나 GPU에 그대로 적용할 수는 없습니다.
실제 비교에서는 다음 순서를 권합니다. 아래는 이번 글에서 실행한 벤치마크가 아니라, 측정을 설계할 때 확인할 항목입니다.
- 같은 작업을 고릅니다. 모델·토크나이저·입출력 길이 분포·정밀도·캐시 상태·엔진 버전과 하드웨어 범위를 기록합니다.
- 부하를 한 단계씩 바꿉니다. 동시 요청 수와 요청 도착률을 구분하고 대기열·실패·타임아웃도 남깁니다. NVIDIA의 부하 설정 설명처럼 클라이언트 동시성과 엔진 배치 크기는 같지 않을 수 있습니다.
- 통과 후보를 먼저 가릅니다. 요청별 공동 조건, 전체 시도의 충족률, 오류율과 관측 기간을 함께 봅니다. 목표 미달을 높은 처리량으로 상쇄했다고 보지 않습니다.
- 그다음 비용과 변동을 비교합니다. 같은 목표를 지킨 후보 사이에서 지연 분포·자원·비용을 비교하고, 반복 측정과 여유 폭을 확인합니다. 짧은 표본의 통과가 운영 기간 전체의 보장은 아닙니다.
메모리 용량과 대역폭, 요청 배분, 네트워크도 결과에 영향을 줄 수 있습니다. 그러나 Goodput 하나로 어느 부품이 원인인지 역산할 수는 없습니다. 병목 진단에는 별도의 자원·실행 경로 관측이 필요합니다.
6. AI 데이터센터를 볼 때도 총량과 유효 용량을 나눠 봅니다
필자의 해석: 설치한 GPU 수나 총 토큰 수는 서비스가 목표를 지키면서 제공한 처리 능력과 다릅니다. 같은 설비에서도 작업 특성과 목표에 따라 사용할 수 있는 여유가 달라질 수 있으므로, 기술 효율을 기업 실적에 연결하기 전에 어떤 부하를 어떤 조건으로 처리했는지부터 확인하는 편이 낫습니다.
그렇다고 이 글의 가상 수치로 데이터센터 증설 필요량이나 메모리 매출을 계산할 수는 없습니다. 투자 논의와의 경계는 기존 한국어 분석 AI 인프라 투자 회의론을 계약·매출·추론 수요로 나눠 보는 글에서 이어 읽을 수 있습니다. 이 글은 기술·산업을 이해하기 위한 정보이며 매수·매도 추천이 아닙니다.
요약 · 다음에 확인할 숫자
| 질문 | 확인할 항목 |
|---|---|
| 목표를 지킨 요청이 초당 몇 개인가? | 같은 시간 경계의 Goodput |
| 전체 시도 중 몇 %가 함께 합격했나? | 오류를 포함한 공동 충족률 |
| 더 큰 부하도 감당할 수 있나? | 부하별 반복 측정과 목표 통과 여부 |
| 어떤 부품이 병목인가? | 별도의 시스템·커널 관측 |
먼저 목표를 통과한 후보를 고르고, 그 안에서 처리량과 비용을 비교하세요. Goodput의 req/s, 충족률의 %, 그리고 목표를 지키는 최대 요청률을 같은 숫자로 읽지 않는 것이 이번 글의 핵심입니다.
Appendix · 계산 범위와 공식 출처
총 16개의 산술·조건 검증을 Node.js 24.14.1·Windows에서 실행했습니다. 가상 A·B 집계, 공동 통과 90%, 오류 포함 20%, 목표 판정과 반올림을 확인했습니다. AIPerf·vLLM·GPU·실제 LLM 서버는 설치하거나 실행하지 않았으며 다른 OS를 시험했다고 주장하지 않습니다.
도구 문서에서 Goodput이라는 이름을 보더라도 단위·분모·시간 구간·통과 조건을 먼저 읽어야 합니다. 여기서는 60초 안에 모든 요청의 판정이 끝난 집합을 사용했지만, 운영 로그는 구간 밖까지 이어질 수 있습니다. 워밍업·미완료 요청·재시도를 임의로 없애면 같은 비교가 되지 않습니다.
- NVIDIA AIPerf — Benchmark Goodput: Goodput과 충족률·오류 분모. 확인 화면의 버전은 v0.13.0입니다.
- USENIX OSDI 2024 — DistServe: 지연 제약을 지키는 요청률의 연구 맥락.
- Google SRE Workbook — Implementing SLOs: 좋은 사건/전체 사건 지표와 서비스 목표.
- NVIDIA NIM Benchmarking — Parameters and Best Practices: 부하·동시성·배치 비교 조건. 확인 화면의 버전은 2.0.0입니다.
공식 자료 확인일: 2026-10-23 KST. 문장·가상 계산·도식은 독립 제작했습니다. 공식 자료의 그림·코드·벤치마크 결과를 복제하지 않았습니다.
댓글
댓글 쓰기
안녕하세요 :)