이 문서는 2주차 part 1 - 모델 서빙 시스템 설계의 LLM 가공로직 자세히 보기를 분리한 글입니다. 요청이 워커에 도달하기까지의 경계와 큐는 request_id의 여정에서 다루고, 여기서는 워커 안에서 문자열이 실제 다음 토큰으로 바뀌는 과정에만 집중합니다.

SSE로 토큰의 문자열 조각을 리턴합니다

이 예제에서 SSE로 받는 token은 모델이 이미 선택해 생성한 다음 토큰의 문자열 조각입니다. 아직 생성되지 않은 초안이나 계산 중간값은 아닙니다. 다만 전체 답변은 계속 생성 중이므로, 클라이언트가 받은 것은 생성은 끝났지만 문장 전체로는 미완성인 조각입니다.

모델이 지금까지 확정한 토큰:  "The" + " quick" + " brown"
이번 forward가 새로 확정한 토큰: " fox"
클라이언트가 SSE로 받는 값:      {"token": " fox", ...}
전체 답변 상태:                  아직 미완성

보통의 자기회귀 생성에서는 이미 전송한 토큰을 뒤에서 고쳐 쓰지 않습니다. 새 토큰을 하나씩 뒤에 붙입니다. 클라이언트는 이 조각들을 도착 순서대로 이어 붙여 한 문장을 만듭니다.

다만 두 가지는 구분해야 합니다.

• 토큰 생성은 모델과 샘플링 로직이 합니다.
• 즉시 전달은 SSE가 합니다. SSE가 토큰을 만드는 것은 아닙니다.

또한 상용 API의 text_delta 한 건이 언제나 토큰 정확히 하나라는 보장은 없습니다. 서버가 여러 토큰을 한 문자열 조각으로 묶을 수도 있습니다. 지금 보는 예제는 토큰 하나를 디코딩한 뒤 이벤트 하나로 보내므로 둘이 거의 일치합니다.

전체 지도: 트랜스포머 안과 밖

먼저 각 도구와 코드가 어디에 있는지 한 장에 놓아봅시다.

flowchart LR
    Text["사람의 문자열"]
    TokE["Tokenizer.encode
문자열 → token IDs"]
    Emb["Token + Position
Embedding"]
    Blocks["Decoder Transformer Blocks
Causal Self-Attention + FFN"]
    Head["LM Head
hidden state → vocabulary logits"]
    Select["Sampling
temperature + softmax + multinomial"]
    TokD["Tokenizer.decode
token ID → 문자열 조각"]
    SSE["SSE
클라이언트에 즉시 전달"]

    Text --> TokE --> Emb --> Blocks --> Head --> Select --> TokD --> SSE

    subgraph Model["self.model(...) 내부"]
        Emb
        Blocks
        Head
    end

경계를 정확히 나누면 다음과 같습니다.

• 토크나이저는 트랜스포머 모델 밖에 있습니다. 문자열과 토큰 ID 사이를 변환합니다.
• 임베딩, 트랜스포머 블록, LM 헤드는 모델의 forward 안에 있습니다.
• softmax와 토큰 선택은 보통 생성 정책입니다. 모델이 점수인 logits를 내면 생성 코드가 하나를 고릅니다.
• model.generate()는 트랜스포머의 한 층이 아닙니다. forward, 토큰 선택, 입력 갱신, 종료 검사를 반복하는 상위 제어 루프입니다.
• SSE는 모델 밖의 전송 방식입니다.

이 구분만 잡아도 tokenizer(), model(), model.generate(), SSE를 한 덩어리로 생각하는 혼란이 대부분 사라집니다.

등장인물 셋: 토크나이저, PyTorch, 모델

세 이름이 각각 어느 층을 맡는지 먼저 겹쳐 놓고 보겠습니다.

토크나이저

토크나이저는 문자열과 모델 어휘 사전의 정수 ID를 양방향으로 변환합니다.

"The quick brown"
    ↓ encode
[2, 133, 2119, 6219]
    ↓ decode
"The quick brown"

토큰은 반드시 단어나 글자 하나와 일치하지 않습니다. 공백이 붙은 조각, 서브워드, 바이트 조각일 수 있습니다. 그래서 토큰 하나를 디코딩한 결과가 " fox", "ing", 문장부호 또는 빈 문자열처럼 보일 수 있습니다.

토크나이저가 돌려주는 핵심 값은 두 개입니다.

• input_ids: 각 토큰의 어휘 사전 번호
• attention_mask: 배치 길이를 맞추기 위해 넣은 패딩 위치를 구분하는 0과 1

토큰 ID가 곧 임베딩 벡터는 아닙니다. 모델 안의 임베딩 테이블이 ID를 행 번호로 사용해 벡터를 조회합니다.

PyTorch

PyTorch는 이 코드의 수치 계산 실행 환경입니다.

• 토큰 ID와 logits를 텐서로 표현합니다.
• CPU 또는 GPU에 텐서를 배치합니다.
• 모델의 행렬곱과 어텐션 연산을 실행합니다.
• softmax, multinomial 같은 샘플링용 연산을 제공합니다.
• 학습 때는 역전파용 계산 그래프를 기록하고, 추론 때는 torch.no_grad()로 기록을 끕니다.

PyTorch가 언어를 이해하거나 문장을 생성하는 것은 아닙니다. 학습된 모델이 정의한 계산을 텐서 연산으로 실행하는 엔진에 가깝습니다.

self.model(...)

self.model(...)은 모델의 forward 한 번입니다.

입력 시퀀스를 임베딩하고, 여러 트랜스포머 블록을 통과시키고, 각 위치의 hidden state를 LM 헤드로 보내 어휘 전체의 logits를 계산합니다. 출력 shape을 기호로 쓰면 다음과 같습니다.

input_ids:       [B, T]
outputs.logits:  [B, T, V]

B = batch size
T = 현재 입력 시퀀스 길이
V = vocabulary size

model()은 다음 토큰 하나를 직접 선택해주지 않습니다. 각 위치마다 어휘 V개에 대한 점수를 돌려줍니다.

self.model.generate(...)

model.generate()는 forward를 이용해 문장을 만드는 고수준 함수입니다. 내부적으로 대략 다음 일을 반복합니다.

while not finished:
    outputs = model(input_ids)
    next_token_logits = outputs.logits[:, -1, :]
    next_token = select(next_token_logits)
    input_ids = append(input_ids, next_token)

실제 generate()는 여기에 EOS 검사, 최대 길이, beam search나 sampling 설정, KV 캐시, 배치별 종료 처리 등을 더합니다.

ModelWorker.generate()를 한 줄씩 읽기

이 메서드는 여러 프롬프트를 하나의 배치로 토큰화한 뒤, model.generate()가 내부 생성 루프를 끝낼 때까지 기다리고 완성된 결과를 한 번에 돌려줍니다.

1. 배치에서 문자열과 식별자를 분리한다

prompt_texts = [prompt.prompt for prompt in prompts]
request_ids = [prompt.id for prompt in prompts]

• prompt_texts는 모델에 넣을 문자열 목록입니다.
• request_ids는 결과가 어느 요청의 것인지 다시 연결하기 위한 식별자입니다.
• 배치가 하나의 텐서로 합쳐져도 행의 순서는 유지되므로, 나중에 같은 인덱스로 결과를 다시 묶을 수 있습니다.

2. 문자열 배치를 직사각형 텐서로 만든다

inputs = self.tokenizer(
    prompt_texts,
    return_tensors="pt",
    padding=True,
    truncation=True,
    max_length=512,
).to(self.device)

프롬프트 길이는 서로 다르지만 GPU의 배치 연산은 직사각형 텐서를 원합니다. 가장 긴 프롬프트 길이에 맞춰 짧은 행을 패딩합니다.

원래 토큰 길이:  [5], [8], [3]
padding 이후:     [3, 8]
attention_mask:   실제 토큰 1, 패딩 0

return_tensors="pt"는 결과를 PyTorch 텐서로 만들고, .to(self.device)는 모델과 같은 CPU 또는 GPU로 옮깁니다.

3. generate()가 자기회귀 루프를 맡는다

with torch.no_grad():
    outputs = self.model.generate(
        inputs.input_ids,
        attention_mask=inputs.attention_mask,
        max_new_tokens=50,
        num_return_sequences=1,
        pad_token_id=self.tokenizer.eos_token_id,
    )

• torch.no_grad()는 학습용 역전파 기록을 만들지 않습니다.
• max_new_tokens=50은 입력 뒤에 최대 50토큰을 더 생성합니다.
• num_return_sequences=1은 프롬프트마다 후보 하나를 반환합니다.
• attention_mask는 패딩을 실제 문맥으로 취급하지 않도록 알려줍니다.

이름이 닮은 마스크가 하나 더 있어서 자주 섞입니다. 가리는 대상과 사는 곳이 다릅니다.

여기서 가장 중요한 교정은 이것입니다.

/generate가 model.generate()를 한 번 호출하는 것은 맞지만, 생성 루프가 한 번만 도는 것은 아닙니다. generate() 내부에서 forward와 다음 토큰 선택이 최대 50번 반복됩니다.

4. 토큰 ID 전체를 문자열로 되돌린다

generated_texts = self.tokenizer.batch_decode(
    outputs,
    skip_special_tokens=True,
)

outputs는 선택이 완료된 토큰 ID들의 행렬입니다. batch_decode()가 각 행을 문자열로 되돌립니다. 이 예제의 결과에는 생성된 부분뿐 아니라 입력 프롬프트도 포함됩니다.

5. 요청 ID와 결과를 다시 묶는다

results = []
for request_id, generated_text in zip(request_ids, generated_texts):
    results.append({
        "request_id": request_id,
        "generated_text": generated_text,
    })
return results

배치 안에서 한 번에 계산했지만 HTTP 요청이나 프롬프트의 소유자는 서로 다릅니다. request_id가 모델 계산 결과를 원래 요청으로 돌려주는 우편번호 역할을 합니다.

generate_forward_batch()를 한 줄씩 읽기

이 메서드는 generate() 내부의 반복 루프 중 한 바퀴만 바깥으로 꺼낸 코드입니다. 활성 프롬프트를 배치로 묶어 각 프롬프트의 다음 토큰 하나씩을 만든 뒤 즉시 반환합니다.

1. 토큰화와 forward

encoded = self.tokenizer(
    prompt_texts,
    return_tensors="pt",
    padding=True,
    truncation=True,
    max_length=512,
).to(self.device)

with torch.no_grad():
    outputs = self.model(
        input_ids=encoded.input_ids,
        attention_mask=encoded.attention_mask,
        use_cache=False,
    )

self.model(...)을 직접 불렀으므로 forward 한 번만 실행됩니다. 아직 어떤 토큰도 선택하지 않았습니다. outputs.logits에는 각 배치, 각 위치, 각 어휘 토큰의 점수가 들어 있습니다.

예를 들어 배치 4개, 현재 길이 7, 어휘 50,272개라면:

encoded.input_ids.shape = [4, 7]
outputs.logits.shape     = [4, 7, 50272]

2. 왜 마지막 위치의 logits만 쓰는가

next_token_logits = outputs.logits[:, -1, :]

인과적 언어 모델은 각 위치에서 그 위치까지의 prefix를 보고 다음 토큰을 예측하도록 학습됩니다.

입력: [The, quick, brown]

위치 0의 logits: "The" 다음은 무엇인가
위치 1의 logits: "The quick" 다음은 무엇인가
위치 2의 logits: "The quick brown" 다음은 무엇인가  ← 지금 필요한 것

학습 때는 모든 위치의 예측을 한꺼번에 사용해 손실을 계산합니다. 추론 때는 현재 문장 전체 다음에 올 토큰만 필요하므로 마지막 위치만 꺼냅니다.

슬라이싱 결과 shape은 다음처럼 줄어듭니다.

[B, T, V]
  ↓ [:, -1, :]
[B, V]

배치의 각 행마다 어휘 V개에 대한 다음 토큰 점수표 하나가 남습니다.

3. logits를 확률로 바꾸고 하나를 뽑는다

next_token = torch.multinomial(
    torch.softmax(next_token_logits / 0.7, dim=-1),
    num_samples=1,
).squeeze(-1)

안쪽부터 읽으면 됩니다.

next_token_logits / 0.7

logits는 확률이 아니라 정규화되지 않은 점수입니다. temperature가 0.7처럼 1보다 작으면 점수 차이가 확대되어 높은 후보에 더 집중합니다. 반대로 1보다 크면 분포가 평평해져 다양한 후보가 선택될 가능성이 커집니다.

facebook/opt-125m 에 "The quick brown" 을 넣고 실제로 재어 본 값입니다.

나눗셈이 순위를 바꾸지는 않습니다. 1등은 나눠도 1등입니다. 바뀌는 것은 1등과 나머지의 격차뿐이고, 그 격차가 곧 다른 후보가 뽑힐 여지입니다.

softmax(..., dim=-1)

각 행의 어휘 V개 점수를 합이 1인 확률 분포로 바꿉니다. dim=-1은 마지막 차원, 즉 어휘 차원을 뜻합니다.

logits:        [2.1, 1.4, -0.3, ...]
softmax 결과:  [0.58, 0.29, 0.04, ...]

torch.multinomial(..., num_samples=1)

확률 분포에서 행마다 후보 하나를 무작위 추출합니다. 가장 높은 확률을 무조건 고르는 argmax와 달리, 낮지만 0이 아닌 후보도 선택될 수 있습니다.

.squeeze(-1)

multinomial 결과 [B, 1]의 마지막 크기 1인 차원을 제거해 [B]로 만듭니다. 이제 배치의 각 프롬프트마다 다음 토큰 ID 하나가 있습니다.

4. 토큰 ID를 문자열 조각으로 바꾸고 요청별로 포장한다

results = []
for i, prompt_data in enumerate(prompts):
    token = self.tokenizer.decode(
        next_token[i].unsqueeze(0),
        skip_special_tokens=True,
    )
    results.append({
        "request_id": prompt_data["request_id"],
        "token": token,
        "is_finished": token == self.tokenizer.eos_token,
    })
return results

이 for 루프는 프롬프트마다 모델을 다시 실행하는 루프가 아닙니다. 무거운 모델 연산은 배치 전체에 대해 이미 한 번 끝났습니다. 여기서는 [B]에 담긴 토큰 ID를 하나씩 문자열로 바꾸고, 원래 request_id와 묶을 뿐입니다.

반환 dict는 SSE 규격이 아닙니다. 워커 프로세스와 스케줄러 사이에서 결과를 운반하기 위한 내부 메시지 계약입니다.

• request_id: 어느 활성 시퀀스의 결과인지 찾음
• token: 이번 바퀴에서 생성된 문자열 조각
• is_finished: 바깥 생성 루프가 이 시퀀스를 제거할지 판단

이후 스케줄러는 token을 현재 프롬프트 뒤에 붙이고, 끝나지 않았다면 다음 배치에 다시 태웁니다.

현재 prompt
  → forward
  → 다음 token 선택
  → token을 클라이언트에 SSE로 전달
  → prompt = prompt + token
  → 다음 forward

따라서 문장 생성 루프가 사라진 것이 아닙니다. model.generate() 안에 있던 루프를 서빙 코드의 requests_processing_loop()가 대신 돌리는 것입니다.

/generate와 /generate_stream을 다시 정확히 말하면

처음의 두 문장을 다음처럼 고치면 정확합니다.

즉 /generate_stream이 개별 HTTP 요청을 받도록 설계된 것과 모델이 그 요청 하나만 단독 계산한다는 것은 다른 이야기입니다. 사용자는 각자 연결 하나를 갖지만 GPU에서는 여러 사용자가 한 배치에 합승할 수 있습니다.

그리고 SSE를 택한 이유는 결과가 완료되자마자 한 번 반환하기 위해서가 아닙니다. 완료되기 전부터 생성된 조각을 계속 반환하기 위해서입니다.

왜 굳이 한 토큰씩 바깥에서 돌리는가

model.generate()로 완성본을 만든 다음 문자열을 잘라 보내면 겉보기 스트리밍은 만들 수 있습니다. 하지만 사용자는 모델 계산이 모두 끝날 때까지 첫 글자를 받지 못합니다.

반대로 한 토큰씩 제어권을 돌려받으면 서빙 계층이 토큰 사이마다 다음 일을 할 수 있습니다.

• 생성된 조각을 즉시 SSE로 전달
• 취소된 요청을 다음 배치에서 제외
• 새 요청을 빈 배치 슬롯에 합류
• 요청별 최대 토큰 수와 종료 상태 확인
• 백프레셔와 연결 종료 처리
• 토큰 사용량과 생성 지연 관측

즉 수동 한 토큰 생성은 모델 기능을 흉내 내기 위한 목적보다, 서빙 스케줄러가 생성 도중에 개입할 제어 지점을 얻기 위한 구조입니다.

이 코드는 prefill도 KV 캐시도 쓰지 않는다

지금까지 읽은 generate_forward_batch()는 실제 서빙 엔진이 쓰는 두 가지 최적화를 둘 다 빼고 있습니다. 무엇을 뺐는지, 그래서 얼마를 손해 보는지 직접 재 보겠습니다.

캐시를 끄는 두 줄

캐시가 없는 이유는 코드 두 곳에 나뉘어 있습니다. 하나는 워커에 있습니다.

outputs = self.model(
    input_ids=encoded.input_ids,
    attention_mask=encoded.attention_mask,
    use_cache=False,      # K/V를 만들고 나서 버린다
)

다른 하나는 스케줄러 쪽 WorkloadManager.update_sequence_output()에 있습니다.

sequence.output.append(token)
sequence.prompt += token      # 프롬프트 문자열 자체가 길어진다
sequence.token_count += 1

토큰 ID를 이어붙이는 것이 아니라 프롬프트 문자열에 생성된 조각을 그대로 덧붙입니다. 그리고 다음 바퀴에 requests_processing_loop()이 그 길어진 seq.prompt를 다시 워커로 보냅니다. 두 줄이 합쳐지면 매 바퀴 이렇게 됩니다.

1. 지금까지의 문자열 전체를 처음부터 다시 토큰화한다
2. 그 전체를 모델에 넣어 모든 위치의 K/V를 다시 계산한다
3. 마지막 위치의 logits만 쓰고 나머지는 버린다
4. K/V도 버린다

즉 이 코드에는 prefill과 decode의 구분 자체가 없습니다. 매 바퀴가 전부 prefill입니다.

얼마를 다시 계산하나

이 저장소가 쓰는 모델 그대로(facebook/opt-125m), 이 루프 모양 그대로 재 봤습니다. 프롬프트는 12토큰이고, LLMEngine의 self.max_tokens = 20이 기본값이라 20토큰까지 생성했습니다. 비교군은 같은 루프에 KV 캐시만 켠 것입니다.

캐시를 켜면 누적 입력이 31토큰입니다. 프롬프트 12토큰을 한 번 넣고, 그 뒤로는 19바퀴 동안 한 번에 한 토큰씩만 넣기 때문입니다. 캐시가 없으면 12, 13, 14로 계속 늘어나며 다시 들어가서 430토큰이 됩니다.

같은 측정을 100토큰까지 늘리면 격차가 훨씬 벌어집니다.

토큰 수는 54배, 어텐션 점수 칸은 71배 차이인데 시간은 2.9배밖에 차이가 안 납니다. opt-125m이 작은 모델이고 CPU에서 돌렸기 때문입니다. 파이썬 오버헤드와 커널 실행 비용이 상수처럼 깔려 있어서 연산량 차이가 그대로 시간 차이로 나타나지 않습니다. 모델이 커지고 컨텍스트가 길어질수록 이 상수가 묻히면서 시간 격차가 연산량 격차 쪽으로 붙습니다.

브라우저에서 보이는 증상: 뒤로 갈수록 느려진다

연산량보다 체감에 직접 닿는 지표는 토큰 사이 간격입니다. 100토큰을 생성하며 구간별 평균을 재면 이렇습니다.

캐시가 없으면 문장이 길어질수록 다음 토큰까지의 간격이 같이 벌어집니다. 69ms에서 109ms로 1.6배가 됐습니다. 캐시를 켜면 27ms에 고정됩니다. 입력이 언제나 한 토큰이라 매 스텝 하는 일의 양이 같기 때문입니다.

이 저장소를 띄우고 /generate_stream에 긴 답을 요구해 보면 눈으로 확인할 수 있습니다. 처음엔 토큰이 또박또박 나오다가 뒤로 갈수록 뜸해집니다. 1주차 part 3에서 "TPS가 낮으면 decode 병목"이라고 했던 증상이 바로 이 모양이고, 여기서는 원인이 캐시가 없다는 것 하나뿐입니다.

결과가 달라지지는 않는다

캐시가 정확도를 깎는 근사는 아닌지 확인해 볼 필요가 있습니다. 샘플링의 무작위성을 빼고 항상 가장 확률 높은 토큰을 고르게(greedy) 한 뒤 두 경로를 돌리면, 20토큰이 문자 단위까지 완전히 같습니다.

캐시 없음:  runs away.\nI'm not sure if you're being sarcastic or not, but the brown fox
캐시 사용:  runs away.\nI'm not sure if you're being sarcastic or not, but the brown fox

당연한 결과입니다. 인과 마스크 때문에 앞 위치의 K/V는 뒤에 무엇이 붙어도 바뀌지 않으니, 다시 계산하든 꺼내 쓰든 같은 값입니다. KV 캐시는 같은 답을 더 싸게 얻는 방법이지 다른 답을 얻는 방법이 아닙니다.

그런데 왜 이렇게 짜여 있나

캐시를 켜는 순간 스케줄러가 할 일이 늘어나기 때문입니다. past_key_values를 요청마다 따로 들고 있어야 하고, 요청이 배치에 새로 들어오거나 빠져나갈 때 그 캐시도 같이 붙였다 떼야 합니다. 요청마다 길이가 제각각이니 이 메모리는 크기가 계속 변합니다. 이것이 PagedAttention이 푸는 문제이고, 1주차 part 3에서 "가변 크기 메모리를 어떻게 할당하고 관리할 것인가가 별도의 엔지니어링 문제"라고 했던 대목입니다.

이 예제는 그 앞 단계에서 멈춰 있습니다. 캐시도 없고 스케줄링도 없는 대신, 자기회귀 루프가 서빙 코드에 그대로 드러나 있어서 한 바퀴가 무엇인지 눈으로 볼 수 있습니다. 최적화를 하나씩 얹으면서 무엇이 왜 필요해지는지 따라가기에는 이 상태가 출발점으로 낫습니다.

덧붙여, 이 루프가 다시 하는 일은 모델 계산만이 아닙니다. 매 바퀴 누적 문자열 전체를 토크나이저에 다시 넣습니다. 100토큰을 생성하는 동안 토큰화한 문자 수가 누적 23,209자였습니다. 모델 forward에 비하면 작은 비용이지만, 실제 서빙 엔진이 문자열이 아니라 토큰 ID 리스트를 시퀀스 상태로 들고 다니는 이유가 여기 있습니다.

멀티모달 운영에서는 어디까지 이어지는가

텍스트와 이미지·영상은 사용자에게는 하나의 대화지만, 생성 결과의 성격이 다릅니다.

두 경로를 한 채팅에 결합할 때 백엔드는 먼저 메시지와 미디어 placeholder의 순서를 확정하고, 각각의 상태를 비동기로 갱신할 수 있습니다. 텍스트는 성공했지만 이미지가 실패한 경우도 전체 요청 실패로 뭉개지 않고 partial 상태로 표현할 수 있어야 합니다.

여기서 토큰 생성 이해가 필요한 이유는 모델 연구 때문이 아닙니다. 텍스트가 왜 먼저 흐를 수 있는지, 왜 이미지와 같은 완료 계약으로 묶으면 사용자 경험이 나빠지는지, 비용과 타임아웃을 어디서 나눌지를 판단하기 위해서입니다.

마지막으로 머릿속에 남길 일곱 문장

1. 토크나이저는 문자열을 토큰 ID로 바꾸며 트랜스포머 밖에 있다.
2. 모델의 forward는 각 위치에 대해 어휘 전체의 logits를 만든다.
3. 현재 문장 다음 토큰에는 마지막 위치의 logits만 사용한다.
4. softmax와 sampling이 logits에서 다음 토큰 ID 하나를 고른다.
5. model.generate()는 이 forward와 선택을 내부에서 반복한다.
6. generate_forward_batch()는 한 바퀴만 실행하고 바깥 스케줄러가 반복한다.
7. SSE는 이미 생성된 조각을 미완성 문장 상태에서 즉시 전달하는 운반 수단이다.

• 이전 개념: 1주차 part 2 - 토큰, 임베딩, 트랜스포머
• 요청 경계 추적: 추적: request_id의 여정
• 일괄 경로 추적: 추적: generate의 대기 루프