디코드 (Decode)

디코드(Decode)는 언어 모델이 프리필 뒤에 다음 토큰을 하나 고르고, 그 토큰을 문맥에 더한 뒤 다시 다음 토큰을 고르는 생성 구간입니다. 여기서 디코드는 암호문을 평문으로 바꾸는 일반적인 복호화 뜻이 아니라, 자기회귀 언어 모델의 출력 생성 단계를 가리킵니다. 일반적인 자기회귀 생성에서는 첫 토큰 뒤의 모든 답을 한꺼번에 확정하지 않고, 이미 나온 토큰을 포함한 문맥을 바탕으로 순서대로 이어 갑니다.

한 토큰씩 이어지는 생성

“서울의 봄 날씨는”이라는 입력 뒤에 답을 만든다고 생각해 보겠습니다. 프리필이 입력을 처리해 다음 후보 분포를 만들면, 서비스는 설정에 따라 한 토큰을 선택합니다. 선택된 토큰은 화면에 스트리밍될 수 있고, 동시에 다음 계산의 입력 문맥이 됩니다. 다음 토큰은 방금 선택된 토큰까지 포함한 문맥에서 나옵니다. Hugging Face의 KV 캐시 설명은 이처럼 이전 토큰의 키와 값을 저장해 같은 계산을 반복하지 않도록 한다고 설명합니다.

스트리밍 화면에서 문장이 조금씩 길어지는 모습은 모델이 문단 전체를 이미 완성해 두고 글자를 나누어 보내는 모습과 다를 수 있습니다. 보통은 선택한 토큰이 다음 토큰의 조건이 됩니다. 설정한 최대 출력 길이에 도달하거나 종료를 뜻하는 토큰을 고르면 이 순서가 멈춥니다. 같은 입력이라도 샘플링 설정이 다르면 선택 경로와 답이 달라질 수 있습니다.

그래도 디코드가 과거를 전부 잊고 한 칸만 계산한다는 뜻은 아닙니다. 새 토큰은 앞선 문맥을 참고해야 하므로 캐시에 쌓인 값을 읽습니다. 생성이 길어질수록 캐시도 커질 수 있고, 이 읽기와 모델 가중치 접근이 병목이 되는 조건도 있습니다. vLLM의 청크 프리필 문서는 디코드가 보통 메모리 대역폭에 제약을 받는다고 설명하지만, 이는 모델, 하드웨어, 배치, 문맥 길이에 따라 달라지는 일반적 경향입니다. KV 캐시는 재계산을 줄여 주지만 출력 토큰을 무한히 병렬 생성하게 해 주지는 않습니다.

첫 토큰과 측정

첫 응답 토큰은 프리필과 디코드 사이에서 특히 헷갈리기 쉽습니다. 입력 마지막 위치의 로짓, 곧 다음 토큰 후보의 점수로 첫 토큰을 고르는 과정은 프리필 결과에 바로 이어집니다. 어떤 구현이나 지표는 이를 프리필 완료로 묶고, 다른 구현은 디코드의 첫 단계로 셉니다. 사용자 관점의 TTFT는 이 경계 하나만 재는 시간이 아닙니다. 대기열, 입력 토큰화, 프리필, 첫 토큰 선택과 전송이 더해질 수 있으므로, “프리필이 줄면 TTFT가 같은 만큼 줄어든다”라고 단정할 수 없습니다.

출력 길이는 디코드 성능을 읽는 핵심 조건입니다. 짧은 답변은 첫 토큰이 빨리 보이는 경험이 더 중요할 수 있지만, 긴 답변은 토큰 사이 지연과 초당 생성 토큰 수가 전체 완료 시간에 더 크게 작용합니다. 여러 요청을 한 배치로 디코드하면 GPU 자원을 더 채울 여지가 생기지만, 요청 수와 길이가 늘면 각 요청의 토큰 간 지연이 달라질 수 있습니다. vLLM은 청크 프리필에서 디코드 요청을 먼저 스케줄해 이 지연을 줄이려 하며, 배치 토큰 한도를 작게 두면 토큰 사이 지연에, 크게 두면 첫 토큰 시간에 유리할 수 있다고 안내합니다.

다른 뜻과 구별하기

생성 시스템에서 decode라는 말은 보통 이 순차 생성 단계를 뜻합니다. 토크나이저의 decode처럼 토큰 ID를 읽을 수 있는 문자열로 바꾸는 절차와도 구별해야 합니다. 토크나이저의 디코드는 이미 정해진 ID를 텍스트로 복원하고, 모델의 디코드 구간은 다음에 생성할 ID를 계산하고 선택합니다. 또 speculative decoding은 보통 디코드 자체의 다른 이름이 아닙니다. 초안 모델이나 다른 제안 방식이 여러 후보 토큰을 먼저 제시하고, 대상 모델이 이를 확인해 지연을 줄이려는 별도 최적화입니다. vLLM의 speculative decoding 문서도 초안 모델, n-gram, 다중 토큰 예측 같은 방법과 후보 토큰을 검증하는 절차를 별도 기능으로 다룹니다.

일반적인 자기회귀 디코드는 선택한 한 토큰을 문맥에 붙이며 다음 단계로 갑니다. speculative decoding을 켜더라도 최종 출력이 문맥에 반영되는 생성 순서와 캐시의 역할이 사라지는 것은 아닙니다. 입력이 길면 프리필 부담이, 출력이 길면 디코드 반복 부담이 커질 수 있습니다. 운영자는 두 길이를 함께 보고 TTFT와 토큰 사이 지연, 전체 완료 시간, 처리량을 나누어 측정해야 합니다. 디코드는 답변이 실제로 늘어나는 구간이므로, 이 구분을 알면 긴 프롬프트와 긴 답변이 서로 다른 지연을 만드는 이유를 읽을 수 있습니다.