개요
Inference는 학습이 끝난 모델에 새로운 입력을 주고 예측이나 생성 결과를 계산하는 단계다. 학습이 모델의 파라미터를 바꾸는 과정이라면, 추론에서는 보통 고정된 파라미터를 사용해 실제 요청을 처리한다.
서비스 환경
실제 서비스에서는 한 번의 추론만 빠르게 실행하는 것뿐 아니라 여러 사용자의 요청을 묶고, 메모리를 관리하고, 지연시간과 처리량을 함께 최적화해야 한다. MLPerf Inference는 다양한 배포 시나리오에서 학습된 모델을 얼마나 빠르게 실행하는지 비교하기 위한 표준화된 벤치마크를 제공한다.[1]
LLM 추론
LLM 서비스에서는 생성 과정에서 KV Cache가 큰 메모리를 차지할 수 있다. vLLM 연구는 이 캐시를 효율적으로 관리하는 PagedAttention을 제안해 같은 지연시간 수준에서 더 높은 처리량을 목표로 했다.[2] 실제 성능은 GPU, 배치 크기, 입력·출력 길이와 시스템 구현에 따라 달라진다.
Prefill과 생성 단계
자동회귀 LLM 추론은 긴 입력을 한꺼번에 처리하는 단계와, 이후 토큰을 하나씩 생성하는 단계를 구분해 생각할 수 있다. 입력 길이가 길면 초기 처리 비용이 커지고, 출력 토큰이 길어지면 반복 생성 단계가 길어진다. 그래서 같은 모델이라도 입력 길이와 출력 길이에 따라 사용자가 체감하는 지연 특성이 달라진다.
배치와 동시 요청
여러 요청을 함께 처리하면 처리량을 높일 수 있지만 개별 요청의 대기시간과 메모리 사용량이 늘 수 있다. vLLM의 PagedAttention 연구는 동적으로 변하는 KV Cache를 효율적으로 관리해 더 많은 요청을 동시에 처리하는 문제를 다룬다.[2] 서비스 운영에서는 최대 처리량만이 아니라 목표 지연시간과 동시 사용자 수를 함께 정해야 한다.
비용을 볼 때
추론 비용은 모델 크기 하나로 결정되지 않는다. 입력 문맥과 생성 길이, 사용 정밀도, 배치 전략, 하드웨어 메모리와 대역폭, 캐시 재사용 여부가 함께 영향을 준다. 따라서 벤치마크 숫자를 실제 서비스 비용으로 옮길 때는 측정 조건이 같은지 확인해야 한다.
사례: 첫 답변은 느리고 이후 글자는 빠른 경우
다음은 ORBiS Tree가 만든 가상 관찰 사례다. 짧은 질문에는 곧바로 답하던 서비스가 긴 문서를 붙이자 첫 글자를 보여 주는 데 오래 걸리고, 이후에는 글자가 빠르게 이어진다고 하자. 입력을 먼저 처리하는 단계와 출력 토큰을 계속 생성하는 단계의 부담이 다를 수 있다. 다만 실제 원인은 대기열, 네트워크, 검색, 모델 처리 중 어디에 있는지 측정해야 알 수 있다.
응답 속도를 나눠 기록하기
- 첫 토큰까지의 시간: 사용자가 요청한 뒤 첫 출력이 보이기까지 걸리는 시간이다. 입력 처리와 대기 등이 함께 영향을 준다.
- 토큰 생성 속도: 첫 출력 이후 생성이 얼마나 빠르게 이어지는지다.
- 전체 완료 시간: 필요한 출력이 모두 전달될 때까지의 시간이다.
- 요청 성공률: 속도와 함께 실패·중단된 요청도 기록해야 사용자 경험을 판단할 수 있다.
동시에 사용하면 달라지는 것
한 명의 요청이 빠르게 끝나는 조건과 여러 요청이 몰렸을 때의 처리량은 다른 문제다. 배치 처리와 KV Cache의 메모리 관리는 동시 요청을 처리하는 데 중요하다. PagedAttention 연구는 KV 캐시의 낭비와 공유를 개선하는 서빙 설계를 다뤘다.[2] 논문에서 얻은 성능 수치를 다른 모델과 하드웨어의 서비스에 그대로 적용해서는 안 된다.
하드웨어 선택의 기준
GPU나 TPU를 선택할 때는 모델이 사용하는 연산, 메모리 요구량, 소프트웨어 지원과 배치 조건을 확인해야 한다. Cloud TPU 공식 문서도 행렬 연산에 적합한 작업과 그렇지 않은 작업을 구분한다.[3] 장치의 이름이나 최대 연산량만으로 실제 요청 지연과 비용을 계산하기 어렵다.
느려졌을 때의 점검 순서
- 검색·파일 처리·모델 호출·전송 시간을 나누어 어느 구간이 길어졌는지 확인한다.
- 같은 모델에서 입력 길이와 출력 길이를 바꿔 비교한다.
- 동시 요청 수를 바꾸며 대기시간과 메모리 부족을 확인한다.
- 캐시·배치·출력 길이 제한을 적용한 뒤 정확도와 성공률이 유지되는지 확인한다.
- 최종적으로 '완료된 작업 하나의 비용'을 비교한다. 재시도와 사람의 확인 시간이 빠져 있으면 실제 비용을 과소평가할 수 있다.
AI inference cost efficiency를 읽는 기준
AI inference cost efficiency는 같은 품질과 작업량에서 추론에 드는 전체 비용을 줄이는 관점이다. 모델 호출 요금, 장치 사용 시간, 자료 검색·도구 실행, 재시도와 사람의 검토 비용은 서로 다른 항목이다. 빠른 첫 응답과 많은 동시 요청 처리도 다르므로 Latency and Throughput의 조건을 함께 기록한다.
계산 예: 성공한 작업당 비용
다음은 실제 요금이 아닌 가상 계산이다. 방식 A는 요청 100건에 100 비용 단위가 들고 80건을 기준에 맞게 처리했다면 성공 작업당 비용은 100÷80=1.25다. 방식 B는 120 단위가 들고 100건을 처리했다면 1.2다. 요청당 비용만 보면 A가 싸지만 같은 완료 기준의 성공 작업당 비용은 B가 작다. 이 계산에는 재시도와 검토 비용을 어디까지 포함했는지도 표시해야 한다.
캐시가 줄이는 것과 남기는 것
OpenAI의 prompt caching 안내는 반복되는 동일 입력 접두부의 계산 상태를 재사용하는 구성을 설명한다.[4] 지원 조건과 실제 캐시 적중 여부를 확인해야 하며, 비용 절감률을 모든 요청에 고정해 적용해서는 안 된다. 캐시는 잘못된 자료를 고치거나 생성 답변의 정답을 보장하지 않는다. KV Cache의 메모리·재사용 배경과 AI Memory의 사용자 상태 저장을 구분해서 읽는다.
예제: 첫 토큰과 전체 시간을 직접 계산
다음은 실제 서비스 측정이 아닌 가상 기록이다. 요청은 0.2초 대기했고 입력 처리부터 첫 토큰까지 0.8초가 걸렸다. 첫 토큰 시간은 요청 시작으로부터 1.0초다. 이후 99개 토큰이 초당 50개로 전달되면 1.98초가 더 걸려 총 100개 토큰의 완료 시간은 2.98초다. 전체 시간으로 나눈 평균은 약 33.6토큰/초이며, 첫 토큰 이후의 50토큰/초와 다른 값이다.
이렇게 기준점을 명시해야 '빠르다'는 숫자를 비교할 수 있다. 검색·전송 시간이 별도로 있다면 사용자 관점의 시간선에 포함한다. 지연과 처리량에는 요청별 시간과 동시에 끝낸 작업 수를, 입력 조건에는 토큰 수와 자료 구성을 남긴다.
예제: KV 캐시 메모리의 단순 추산
가상의 모델에서 32개 층, 층마다 KV 헤드 8개, 헤드 차원 128, 캐시 길이 4,096토큰, 값당 2바이트라고 하자. K와 V를 함께 저장하는 단순 식은 2×32×8×128×4,096×2=536,870,912바이트, 즉 요청당 512MiB다. 같은 길이의 요청 8개는 단순 합계 4GiB가 된다. 이는 특정 모델 사양이 아니며 가중치·활성값·메타데이터·메모리 정렬·다른 실행 비용은 포함하지 않는다.
실제 캐시의 표현·공유·할당 방식은 엔진마다 다르다. PagedAttention 원논문 ↗은 동적으로 변하는 KV 캐시의 낭비와 공유를 다룬다.[2] 이 계산에서 KV 헤드 수를 전체 쿼리 헤드 수와 자동으로 같다고 두지 않는다. 캐시 구조와 저장 정밀도를 확인한 뒤 실제 엔진의 측정값과 비교한다.
병목별로 바꿀 항목을 정하기
- 대기 시간이 늘면 도착량·동시 실행 수·배치 대기 조건을 본다.
- 긴 입력에서만 첫 토큰이 느리면 자료 선택과 입력 처리 비용을 본다.
- 생성이 길수록 지연되면 필요한 출력 길이와 토큰 생성 단계를 본다.
- 메모리 부족이 반복되면 가중치·KV 캐시·동시 요청의 점유를 나눠 본다.
- 도구가 느리면 모델 최적화 전후에 도구 구간이 실제로 변했는지 확인한다.
장치 사용률 하나로 원인을 단정하지 않고 같은 요청 조건에서 한 항목씩 비교한다. 장치를 바꾸는 비교에는 엔진·정밀도·소프트웨어 버전도 남긴다. 속도 개선 이후 답의 누락과 실패율이 커졌다면 품질 조건을 다시 확인한다.
캐시 적중은 완료된 작업과 다르다
Prompt caching 안내 ↗는 동일한 입력 접두부의 계산 재사용을 설명한다.[4] 달라진 문서 버전·도구 정의·입력 순서 등 실제 요청 차이를 확인하고 적중 여부를 기록한다. 캐시가 있다고 사용자 선호가 영구 저장되거나 최신 자료가 자동으로 반영되는 것은 아니다. 사용자 상태와 계산 캐시의 수명·목적을 구분한다.
도구 실행이 포함된 작업의 비용은 모델·검색·재시도·검토를 합친 뒤 같은 완료 기준으로 나눈다. 호출 가격이나 캐시 적중률만으로 성공한 전체 작업의 비용을 대신하지 않는다.