추론 (Inference)

추론(Inference)은 학습을 마친 모델이 새 입력을 받아 예측이나 결과를 만드는 실행 과정입니다. 사진에서 물체를 분류하고, 문장을 번역하고, 사기 거래일 가능성을 점수로 매기고, 대화형 모델이 다음 토큰을 생성하는 일은 모두 추론에 들어갑니다. Hugging Face의 추론 안내도 이를 훈련된 모델로 새 데이터의 예측을 만드는 과정으로 정의합니다. 모델의 가중치를 데이터로 조정하는 학습과 달리, 보통의 추론 요청은 이미 정해진 가중치를 사용해 전달받은 입력을 처리합니다.

범위

언어 모델 이야기에서 추론을 답변 생성과 같은 말로 좁혀 부르기 쉽습니다. 생성은 추론의 한 종류입니다. 분류 모델이 이메일을 스팸과 일반 메일로 나누거나, 추천 모델이 후보 상품의 점수를 계산해 순서를 정하는 것도 추론입니다. 반대로 학습은 오차를 바탕으로 가중치를 바꾸는 과정입니다. 추론 중에 사용자의 대화가 길어져도 그 대화 내용이 곧바로 모델 전체의 지식이나 가중치에 새로 새겨지는 것은 아닙니다.

추론과 추리(reasoning)도 범위가 다릅니다. 여기서 추리는 어려운 문제에서 추가 토큰을 생성하거나, 여러 후보를 비교하거나, 도구 호출 결과를 다시 검토하는 문제 해결 전략을 가리킬 수 있습니다. 그런 전략을 쓰는 모델도 입력에서 출력을 만드는 동안에는 추론을 수행합니다. 그러나 일반적인 이미지 분류나 짧은 다음 토큰 예측이 긴 문제 풀이를 포함해야 하는 것은 아닙니다. 두 용어를 섞으면 필요한 응답 품질, 지연 시간, 계산량을 잘못 예상할 수 있습니다.

생성 흐름

생성형 언어 모델은 프롬프트를 토큰으로 바꾼 뒤, 다음 토큰의 확률을 계산하고 하나를 선택합니다. 선택한 토큰은 다음 계산의 문맥에 더해지므로 답변은 보통 한 토큰씩 이어집니다. 처음에 긴 프롬프트 전체를 읽는 구간을 프리필(prefill), 그 뒤 출력 토큰을 하나씩 만드는 구간을 디코드(decode)라고 부릅니다. NVIDIA는 프리필이 입력 길이에 따라 계산량이 커지는 성격이고, 디코드는 동시 시퀀스와 KV 캐시 사용량의 영향을 크게 받는 성격이라고 설명합니다. NVIDIA Dynamo 문서를 보면 두 구간을 같은 작업량으로 보면 안 되는 이유를 확인할 수 있습니다.

독자가 체감하는 속도도 한 숫자로 끝나지 않습니다. 첫 토큰이 도착하기까지의 시간은 TTFT(Time to First Token), 이후 토큰이 도착하는 사이의 시간은 ITL(Inter-Token Latency)로 따로 볼 수 있습니다. 토큰은 글자와 일대일로 대응하지 않으므로 화면에 보이는 글자 수와 구별해 측정합니다. 짧은 질문은 대기열과 프리필 시간이 더 크게 보일 수 있고, 긴 답변은 디코드 속도가 더 오래 누적됩니다. 서버는 여러 요청을 배치로 묶어 GPU를 더 바쁘게 만들 수 있습니다. 다만 배치를 크게 잡을수록 개별 요청이 기다리는 시간, 각 요청의 입력·출력 길이, 남은 메모리가 함께 달라지므로 처리량이 높아졌다는 사실만으로 모든 사용자의 응답 시간이 짧아졌다고 말할 수 없습니다.

운영 판단

추론을 최적화할 때는 먼저 무엇을 개선하려는지 정해야 합니다. 실시간 상담처럼 첫 응답이 중요하면 TTFT와 대기열을 봅니다. 긴 보고서를 생성하는 작업이라면 토큰 간 지연과 총 완료 시간을 함께 봅니다. 밤새 많은 문서를 분류하는 배치 작업은 이런 기준보다 전체 처리량과 실패율이 더 중요할 수 있습니다. 같은 모델이라도 입력 길이, 출력 길이, 동시 요청 수, 하드웨어, 배치 정책에 따라 결과가 달라지는 이유입니다.

예를 들어 10쪽짜리 정책 문서를 매 질문 앞에 붙이는 챗봇은 매 요청에서 프리필 부담이 커질 수 있습니다. 시스템 프롬프트와 공통 문서를 안정된 앞부분에 두면, 지원하는 서버에서는 해당 접두사의 계산 결과를 재사용할 여지가 생깁니다. 반면 매번 달라지는 사용자 정보가 앞에 오거나 요청이 서로 다른 서버로 흩어지면 같은 효과를 기대하기 어렵습니다. 이때 확인할 대상은 모델 이름 하나가 아니라 프롬프트 구조, 캐시 정책, 요청 분포, 실제 TTFT와 완료 시간입니다.

추론은 학습이 끝난 뒤의 실행이라는 뜻에서 넓게 쓰고, 생성·reasoning·배치·캐싱은 그 실행 안의 방식과 조건으로 나누어 보는 편이 안전합니다. 이 구분이 있어야 모델을 다시 학습할 문제인지, 프롬프트를 줄일 문제인지, 서버의 배치와 메모리를 조정할 문제인지 차례로 판단할 수 있습니다.