같은 모델, 다른 워크로드: 추론과 학습

모델이 어떤 계산을 하는지, GPU가 그 계산을 어떻게 실행하는지 알았다면 이제 어떤 입력이 주어지고, 그 계산을 어떤 순서로 반복하는지 살펴볼 차례입니다. 같은 Transformer를 사용하더라도, 준비된 데이터로 학습하는 작업과 언제 들어올지 모르는 사용자 요청에 답하는 작업은 실행을 구성하는 조건이 다릅니다.

이러한 작업을 설명할 때는 모델의 이름과 크기뿐 아니라 입력, 수행할 계산, 유지할 상태, 반복 방식과 목표를 함께 보아야 합니다. 이들을 묶어 워크로드(workload)라고 부르겠습니다.

이번 글에서는 입력을 미리 준비할 수 있는지가 실행 계획에 어떤 차이를 만드는지 먼저 살펴봅니다. 이어서 추론이 토큰을 생성하는 과정과 학습이 가중치를 갱신하는 과정을 비교하고, 각 과정이 유지할 상태를 알아보겠습니다. 마지막으로 새 요청을 받아 응답을 마칠 때까지 추론 엔진이 맡는 일을 연결하겠습니다. 비교의 기준은 준비된 토큰열로 다음 토큰을 학습하는 과정과, 가중치를 고정한 모델로 사용자의 요청에 따라 문장을 생성하는 추론입니다.

학습 데이터와 추론 요청

워크로드를 구성할 때 먼저 달라지는 것은 처리할 입력을 언제 알 수 있느냐입니다. 학습 데이터가 준비되어 있다면 각 실행에 넣을 입력과 정답을 데이터에서 가져올 수 있습니다. 어떤 데이터를 함께 묶을지, 어떤 순서로 처리할지도 미리 계획할 수 있습니다. 모델이 앞선 답변을 생성해야 다음 학습 입력을 알 수 있는 것은 아닙니다.

사용자 요청을 실시간으로 받는 온라인 추론에서는 앞으로 어떤 내용과 길이의 요청이 언제 들어올지 미리 알 수 없습니다. 요청이 도착하면 그 입력은 알 수 있지만, 이미 진행 중인 요청 사이에 새 요청이 계속 들어옵니다. 실제로 몇 토큰을 생성하고 끝날지도 요청 시작 시점에는 확정되지 않을 수 있습니다.

예를 들어 요청 A에 답하는 동안 긴 문서를 요약하는 B가 들어오고, 이어 짧은 질문 C가 도착할 수 있습니다. 엔진은 이미 실행 중인 작업과 새 요청을 함께 보며, 무엇을 먼저 처리하고 얼마나 많은 요청을 동시에 실행할지 계속 결정해야 합니다. 준비된 데이터를 처리하는 계획에서, 실행 중 달라지는 요청 상황에 대응하는 계획으로 바뀌는 것이 온라인 추론 워크로드의 중요한 차이입니다.

추론에서도 요약할 문서 목록처럼 입력을 미리 모아 처리할 수 있습니다. 이러한 오프라인 추론에서는 도착할 입력을 알고 있지만, 답변을 생성하는 계산과 가중치를 갱신하는 학습의 계산은 여전히 다릅니다. 여기서는 온라인 추론의 요청 관리를 중심에 두고, 학습은 준비된 데이터를 사용하는 경우를 비교합니다.

살펴볼 요소	추론: 온라인 생성	학습: 준비된 데이터
입력 준비	요청이 도착해야 내용을 알 수 있고 이후 요청은 미정	각 실행의 입력과 정답을 데이터에서 준비
입력	프롬프트와 지금까지 선택한 출력	정답이 포함된 알려진 토큰열
계산	Forward와 다음 토큰 선택	Forward, 손실, 역전파, 가중치 갱신
반복	선택한 토큰으로 생성을 이어감	다음 데이터 배치로 학습을 이어감
주요 상태	요청별 토큰 이력과 재사용할 KV	역전파에 필요한 활성값, 기울기, 옵티마이저 상태
실행 목표	응답 시간과 처리량·비용	학습 품질을 확보하며 주어진 자원으로 진척

모델은 주어진 텐서의 계산을 정의하고, 엔진은 필요한 입력과 상태를 준비해 그 계산을 반복합니다. 학습 엔진의 상세한 설계는 이후 학습 과정에서 다룹니다.

토큰 생성과 가중치 갱신

세 토큰 p0 p1 p2를 입력해 문장을 이어 쓴다고 해보겠습니다. LM Head는 각 입력 위치의 표현에서 다음 토큰을 선택할 점수인 logits를 계산합니다. 생성에서는 마지막 위치 p2의 logits로 새 토큰 x0를 선택합니다. 생성을 계속한다면 x0가 다음 실행의 입력이 되고, 그 결과로 x1을 선택합니다.

이처럼 생성에서는 앞서 선택한 출력이 다음 실행의 입력이 됩니다. x0를 선택하기 전에는 이를 입력으로 하는 계산을 진행할 수 없습니다. 여러 요청을 함께 실행하더라도 한 요청 안의 생성 단계들이 순서대로 이어지는 이유입니다. 앞 절에서 본 새 요청의 도착 시점과 별개로, 한 요청의 답변도 생성하면서 정해집니다.

학습 데이터에 p0 p1 p2 p3가 이미 있다면, 입력 p0 p1 p2에 대응하는 다음 토큰 정답은 p1 p2 p3입니다. 세 위치의 예측을 함께 계산하고, 각 위치에서 정답 토큰에 얼마나 높은 확률을 주었는지 평가할 수 있습니다. 모델이 앞 위치에서 어떤 토큰을 골랐는지 기다릴 필요 없이 데이터에서 다음 입력과 정답을 가져옵니다. 다음 토큰을 학습하는 과정

여러 위치를 함께 계산해도 미래를 보는 것은 아닙니다. Causal mask 때문에 p0 위치는 p1이나 p2의 정보를 attention으로 가져오지 못합니다. 정답 p1은 p0 위치의 예측을 평가하는 데 쓰이고, p1 위치에서는 그 위치까지의 문맥으로 다음 토큰 p2를 예측합니다. 알려진 토큰열을 입력으로 사용한다는 사실과, 각 위치가 참조할 수 있는 문맥의 범위는 구별해야 합니다.

학습에서는 이렇게 예측이 정답에 얼마나 맞는지 손실(loss)로 계산합니다. 토큰 하나를 골라 정답과 같은지 확인하는 데 그치지 않고, 정답 토큰에 부여한 확률을 평가합니다. 역전파(backward)는 손실에서 가중치에 대한 기울기를 구하고, 옵티마이저(optimizer)는 이 기울기로 가중치를 갱신합니다. 다음 학습 배치에서는 갱신한 가중치를 사용합니다. 손실 계산과 가중치 갱신

추론에서는 가중치를 유지한 채 모델의 순방향 계산(forward)과 토큰 선택을 반복합니다. 그림에서 추론의 반복은 다음 입력으로 이어지고, 학습의 갱신은 모델 가중치로 이어집니다.

학습과 추론의 상태 관리

모델 계산이 끝난 뒤에도 다음 작업을 위해 보관할 정보가 있습니다. 실행 목적에 따라 이러한 상태(state)가 달라지고, GPU 메모리를 사용하는 구성도 달라집니다. 학습과 추론 모두 모델 가중치를 메모리에 두지만, 가중치 외에 유지할 값은 서로 다릅니다.

학습에서는 역전파에 사용할 forward 중간값인 활성값(activation)을 보관합니다. 가중치의 기울기인 그레디언트(gradient), 가중치 갱신에 쓰는 누적 통계 등의 옵티마이저 상태도 필요합니다. 이 값들이 가중치와 함께 GPU 메모리의 주요 구성 요소가 됩니다. 활성값 일부를 필요할 때 다시 계산하거나 상태를 다른 메모리에 두는 등, 정확히 무엇을 얼마나 저장하는지는 학습 방식과 옵티마이저에 따라 달라집니다.

추론에서는 역전파와 가중치 갱신을 하지 않으므로 그레디언트와 옵티마이저 상태가 필요하지 않습니다. 대신 생성 중인 요청의 KV 캐시가 GPU 메모리를 차지합니다. KV 캐시는 다음 토큰 생성에 재사용할 과거 토큰의 Key와 Value를 저장한 것입니다. 여기서는 생성이 이어지는 동안 보관할 값이라는 점만 짚고, 무엇을 저장하고 어떻게 재사용하는지는 다음 글에서 살펴보겠습니다.

그림은 주요 구성 요소를 비교한 것으로, 칸 크기가 실제 메모리 사용 비율을 뜻하지는 않습니다. 추론에서도 현재 계산을 위한 중간값과 작업 공간은 필요합니다. 학습의 활성값은 역전파를 위해 남겨 두고, KV 캐시는 이후 생성을 위해 남겨 둔다는 저장 목적의 차이에 주목하면 됩니다.

같은 모델의 가중치를 공유해도, 동시에 처리하는 요청이 많아지거나 각 요청이 보관할 문맥이 길어지면 KV 캐시에 필요한 공간은 커집니다. KV 캐시가 항상 가중치보다 큰 것은 아니지만, 요청에 따라 늘어나는 중요한 메모리 사용처입니다. 따라서 모델 가중치가 GPU에 들어간다는 사실만으로 얼마나 많은 요청을 함께 처리할 수 있는지 결정할 수는 없습니다.

엔진은 이러한 계산 상태와 함께 요청의 입력, 선택한 출력 토큰, 진행 위치와 종료 조건도 관리합니다. 요청 A와 B는 동일한 모델 가중치를 사용하면서 각자의 진행 상황을 따로 유지할 수 있습니다. 이후 배치와 스케줄링에서 이 구분이 중요해집니다.

추론 엔진의 요청 처리

사용자가 입력한 문장은 곧바로 GPU의 행렬 곱이 되지 않습니다. 텍스트를 토큰으로 바꾸고, 요청의 생성 조건을 정리하고, 실행할 기회를 기다려야 합니다. 실행 뒤에는 결과를 요청별로 되돌리고, 출력을 전달하며, 끝난 요청의 자원을 정리해야 합니다. 추론 엔진은 이 과정들을 모델 실행과 연결합니다. 실제 시스템은 입력 처리·엔진·모델 실행을 여러 구성 요소로 나눌 수 있습니다. vLLM의 구조 설명

새 요청은 입력 준비 후 대기 큐에 들어갑니다. 엔진은 진행 중인 요청과 새 요청 중 이번 실행에 포함할 작업을 선택합니다. 여러 요청의 작업을 묶어 실행하는 단위를 배치(batch)라고 하고, 실행 대상을 고르는 일을 스케줄링(scheduling)이라고 합니다.

선택할 때는 이번 실행에서 처리할 토큰 수와 KV 저장 공간을 함께 고려합니다. 계산을 많이 넣으면 한 단계가 길어지고, 저장 공간이 없으면 계산 결과를 유지할 수 없습니다. 선택과 자원 확보가 서로 맞춰지는 과정입니다.

모델을 실행하면 새로 계산한 KV와 선택한 출력 토큰을 요청 상태에 반영합니다. 출력을 사용자에게 전달하고, 아직 끝나지 않은 요청은 다음 단계의 선택 대상으로 돌아갑니다. 완료되거나 취소된 요청은 더 이상 필요하지 않은 자원을 반환합니다. 출력 전달과 다음 계산이 겹칠 수도 있으므로 그림은 특정 엔진의 함수 호출 순서를 그대로 나타낸 것은 아닙니다.

여기서 진행 중인 모든 요청이 매번 같은 배치에 들어가는 것은 아닙니다. 이번 단계에 처리할 토큰 수를 제한하느라 일부 요청이 쉬더라도 그 요청의 KV는 남겨둘 수 있습니다. KV 공간이 부족한 경우에는 새 요청의 진입을 늦추거나, 진행 중인 요청을 중단하고 실제 KV 공간을 회수하는 선택이 필요할 수 있습니다. 배치에서 빼는 동작과 저장 공간을 반환하는 동작은 별개입니다. 이러한 중단·회수·재개는 뒤에서 자세히 살펴보며, 여기서는 모델 실행 단계 사이의 요청 관리라는 점만 기억하면 됩니다.

응답 시간과 처리량

요청 A는 짧은 답변을 원하고, B는 긴 문서를 작성하며, 두 요청이 진행되는 동안 C가 도착한다고 해보겠습니다. 엔진은 A가 먼저 끝난 자리를 어떻게 사용할지, B가 문맥을 얼마나 더 저장할지, C를 언제 시작할지 판단해야 합니다. 실제 출력 길이는 종료할 때까지 확정되지 않을 수 있어, 처음 한 번의 결정으로 모든 실행을 정하기 어렵습니다.

목표도 하나가 아닙니다. 대화 서비스에서는 첫 응답이 빨리 나오는지와, 이후 응답이 얼마나 꾸준히 이어지는지가 모두 중요합니다. 반면 많은 문서를 미리 처리하는 작업에서는 전체 작업량을 일정 시간과 비용 안에 끝내는 것이 더 중요할 수 있습니다. 함께 실행할 요청을 늘려 서버의 처리량이 좋아져도 각 사용자의 대기 시간이 같은 비율로 줄어드는 것은 아닙니다. 응답 시간 제약과 처리량을 함께 보는 이유입니다.

학습에서도 학습 품질을 유지하면서 같은 자원으로 얼마나 진척하는지가 중요합니다. 다만 이를 ‘학습은 언제나 계산 병목, 추론은 언제나 메모리 병목’으로 단순화하지는 않겠습니다. 생성 안에서도 입력 문맥을 처리하는 때와 새 토큰을 하나씩 이어가는 때의 계산 형태가 다르기 때문입니다. 이 차이는 이후 Prefill과 Decode를 다루면서 살펴보겠습니다.

SFT도 통상 post-training에 포함되지만, 우리의 시리즈에서는 교육 순서에 따라 Pretraining·SFT를 학습 단계에서, RL 기반 post-training을 그다음에 다룹니다. RL 기반 과정에서는 생성한 결과를 학습에 사용하는 등 두 실행이 연결됩니다.

추론 엔진의 요청 처리 흐름을 살펴보았으니, 다음에는 한 요청이 토큰을 생성하는 과정을 자세히 보겠습니다. 다음 글에서는 다음 토큰을 계산할 때 무엇을 새로 계산하고, 어떤 과거 계산을 재사용하는지 따라가겠습니다.