AI 추론은 왜 메모리에 막히나, 속도와 처리량을 헷갈리면 생기는 일

LLM 추론은 모델 가중치와 요청별 KV 캐시를 메모리에 유지하고 토큰을 생성할 때 이를 반복해 이용하므로, 조건에 따라 연산 성능보다 메모리 용량과 대역폭이 먼저 제약이 된다. 이때 지연시간은 한 요청이 얼마나 빨리 반응하고 끝나는지를, 처리량은 시스템 전체가 일정 시간에 얼마나 많은 요청이나 토큰을 처리하는지를 나타낸다. 동시 요청을 늘려 전체 처리량을 높여도 개별 사용자의 대기시간은 길어질 수 있다.

따라서 실시간 챗봇은 첫 토큰 시간과 토큰 간 지연시간을 우선하고, 배치 요약은 전체 완료량과 비용을 먼저 봐야 한다. 다중 사용자 API에서는 최대 TPS가 아니라 허용 가능한 지연시간 안에서 유지되는 처리량이 핵심이다. 속도와 처리량을 같은 의미로 읽으면 사용자에게 느린 구성을 빠른 시스템으로 잘못 평가할 수 있다.

학습용 사양표만으로 추론 성능을 판단할 수 없는 이유

학습과 추론은 같은 가속기를 사용할 수 있지만 자원 사용 방식이 다르다. 학습은 계획된 기간에 큰 데이터 묶음을 반복 처리하므로 전체 처리량과 연산 장치 활용률이 중요하다. 개별 작업의 즉각적인 응답보다 모델이 목표 수준에 도달하기까지 걸리는 시간이 우선되는 경우가 많다.

AWS의 학습·추론 비교 는 학습을 대체로 예측 가능하고 연산 중심이며 처리량 지향적인 작업으로, 추론을 변동성이 크고 메모리 중심이며 지연시간에 민감한 작업으로 구분한다. 추론에서는 모델 크기뿐 아니라 요청별 상태가 메모리를 차지하며, 실시간 트래픽과 여러 동시 세션도 처리해야 한다.

그러므로 학습에서 높은 연산 성능을 낸 구성이 추론에서도 가장 빠르거나 경제적이라고 단정할 수 없다. 모델과 요청 상태가 가속기 메모리에 들어가는지, 목표 동시성에서 응답시간을 지키는지, 트래픽 급증에 대응하고도 유휴 비용을 억제할 수 있는지를 별도로 따져야 한다.

첫 토큰 시간과 종단 지연시간은 다른 속도다

첫 토큰 시간(TTFT)은 요청을 보낸 뒤 첫 출력 토큰을 받기까지의 시간이다. 일반적으로 요청 대기, 입력 프롬프트를 처리하는 프리필, 네트워크 지연이 반영되므로 사용자가 서비스의 즉각성을 느끼는 지표가 된다.

종단 지연시간은 요청 전송부터 마지막 토큰 수신까지 걸린 전체 시간이다. 첫 토큰이 빨라도 이후 토큰 사이의 간격이 길거나 출력이 길면 완료는 늦어진다. 반대로 짧은 답변은 TTFT가 같더라도 전체 응답을 더 빨리 끝낼 수 있다.

NVIDIA의 LLM 지표 정의 는 TTFT, 종단 지연시간, 토큰 간 지연시간, 시스템 전체 TPS와 사용자별 TPS를 구분한다. 이 문서에 따르면 동시 요청이 늘 때 시스템 TPS는 자원이 포화될 때까지 증가할 수 있지만, 지연시간이 커지면서 사용자별 TPS는 낮아질 수 있다. 벤치마크에서 ‘초당 토큰 수’가 시스템 전체 값인지 단일 사용자 값인지 확인해야 하는 이유다.

메모리 용량과 대역폭이 각각 병목을 만든다

추론 서버는 모델 가중치를 가속기 메모리에 올리고, 각 요청의 이전 토큰에서 계산한 정보를 KV 캐시로 보존한다. 문맥이 길어지거나 동시 요청이 늘면 요청별 캐시가 더 많은 공간을 차지한다. 메모리 용량은 모델과 KV 캐시를 한 장치 또는 구성에 수용할 수 있는지를 결정한다.

입력 프롬프트를 처리하는 프리필 단계는 여러 토큰을 병렬로 계산할 여지가 크다. 반면 디코딩은 직전 결과를 바탕으로 다음 토큰을 순차 생성한다. 토큰 생성 단계마다 필요한 가중치와 상태를 충분히 빠르게 공급하지 못하면 연산 장치에 여유가 있어도 기다리는 시간이 생기므로, 이 구간에서는 메모리 대역폭이 체감 생성 속도를 제한할 수 있다.

용량이 충분하다는 사실만으로 목표 속도와 동시 사용자 수가 보장되지는 않는다. 양자화는 가중치의 공간과 이동할 데이터 양을 줄일 수 있지만 정밀도, 모델 품질, 추론 엔진과 지원 연산도 함께 달라질 수 있다. 양자화 전후 결과는 같은 모델과 품질 기준, 같은 실행 조건에서 비교해야 한다.

챗봇·배치·다중 사용자 서비스는 우선 지표가 다르다

실시간 챗봇에서는 사용자가 답변의 시작을 기다리므로 TTFT가 우선이다. 첫 토큰 이후에는 토큰 간 지연시간이 읽기 흐름을 좌우하고, 답변 완료 후 다음 업무로 넘어가는 서비스라면 종단 지연시간도 중요하다. 평균만으로 일부 사용자의 긴 대기가 가려지지 않도록 P95나 P99 같은 꼬리 지연시간도 함께 보는 편이 적절하다.

야간 문서 요약이나 대량 분류에서는 개별 작업의 첫 반응보다 전체 묶음의 완료 시간이 중요하다. 시스템 전체 TPS 또는 RPS, 가속기 한 대당 처리량, 총 실행시간과 작업당 비용이 주요 지표가 된다. 입력과 출력 길이가 다른 결과를 단순 비교하면 더 긴 문서를 처리한 시스템을 부당하게 느린 것으로 판단할 수 있다.

다중 사용자 API는 응답성과 전체 용량을 함께 관리해야 한다. 동시성을 높이면 유휴 자원을 활용해 처리량을 늘릴 수 있지만, 포화점에 가까워지면 큐 대기가 늘어 TTFT와 꼬리 지연시간이 악화된다. 운영상 의미 있는 값은 최고 처리량 자체가 아니라 서비스의 지연시간 목표를 지키며 수용할 수 있는 최대 동시 요청 수다.

• 실시간 대화: TTFT, 토큰 간 지연시간, 종단 및 꼬리 지연시간
• 배치 요약·분류: 시스템 전체 TPS 또는 RPS, 총 완료시간, 작업당 비용
• 다중 사용자 API: 지연시간 목표를 충족하는 최대 동시성과 그 지점의 처리량

‘몇 배 빠르다’보다 먼저 맞춰야 할 조건

추론 결과는 입력 길이, 출력 길이와 동시성에 크게 좌우된다. 긴 입력은 프리필 작업과 메모리 요구량을 늘리고, 긴 출력은 순차적인 디코딩 시간을 늘린다. 같은 모델과 장비라도 짧은 고정 프롬프트를 쓴 단일 요청 테스트와 실제 대화 분포를 반영한 부하 테스트는 서로 다른 질문에 답한다.

Databricks의 엔드포인트 벤치마킹 지침 은 실시간 작업에서는 짧은 대기가 중요하지만 오프라인 작업에서는 중요도가 낮다고 설명한다. 또한 동시 요청이 증가하면 처리량과 지연시간이 함께 오를 수 있고, 처리량이 포화된 뒤에도 큐 대기로 지연시간은 계속 늘어날 수 있다고 제시한다. 최고 TPS 하나보다 동시성별 지연시간과 처리량을 함께 봐야 하는 근거다.

서로 다른 발표의 배수 수치를 비교하려면 최소한 다음 조건이 공개되고 서로 맞아야 한다. 조건이 빠지면 개선된 대상이 사용자 경험인지, 서버 전체 용량인지, 비용인지 구분하기 어렵다.

• 모델 버전, 정밀도 또는 양자화 방식과 품질 기준
• 입력·출력 토큰 길이와 실제 데이터 분포
• 배치 크기, 요청 도착 방식과 동시 사용자 수
• TTFT와 종단 지연시간에 큐·네트워크 시간이 포함됐는지 여부
• 처리량이 사용자별 TPS, 시스템 전체 TPS 또는 RPS 중 무엇인지
• 평균과 P95·P99 지연시간, 오류·타임아웃 요청의 처리 방식
• 가속기 수와 메모리 용량, 병렬화 구성, 추론 엔진 버전

유효한 처리량은 지연시간 한도 안에서 정해진다

인프라를 비교할 때는 서비스가 허용할 TTFT, 토큰 간 지연시간과 종단 지연시간을 먼저 정해야 한다. 그다음 실제에 가까운 입력·출력 길이 분포로 동시성을 높이며, 지연시간 한도를 넘기 직전의 처리량과 메모리 사용량을 확인한다. 이 값이 해당 구성에서 서비스가 실제로 이용할 수 있는 용량에 가깝다.

목표에 미치지 못한다면 더 높은 연산 성능만 찾기 전에 병목을 구분해야 한다. 모델과 KV 캐시가 메모리 용량을 압박한다면 양자화, 캐시 관리, 요청 길이 제한이나 더 큰 메모리 구성을 검토할 수 있다. 큐 대기가 주원인이라면 복제본 증설, 요청 라우팅과 동시성 제한이 더 직접적인 대응이 될 수 있다.

결국 빠른 추론 서비스는 가장 높은 TPS를 기록한 시스템이 아니라 필요한 응답성을 유지하면서 예상 트래픽을 감당하는 시스템이다. 지연시간은 한 요청의 경험을, 처리량은 전체 설비의 능력을 설명한다. 두 지표를 같은 부하와 메모리 조건에서 함께 읽어야 학습용 사양표가 아닌 실제 서비스에 맞는 구성을 고를 수 있다.