모듈 1에서 하드웨어 이야기를 했다면, 이번에는 그 위에서 LLM이 실제로 어떻게 동작하는지를 살펴봅니다. 이 원리를 알면 "왜 이럴 때 느려지는지"를 남에게 설명할 수 있게 됩니다.
모델은 우리가 보는 것처럼 한 글자, 한 글자를 읽지 않습니다. 대신 토큰(token)이라는 글자 조각 단위로 읽고 씁니다. 예를 들어 "안녕하세요"라는 짧은 인사말도 모델에 따라 2~4개 정도의 토큰으로 쪼개집니다.
여기서 한 가지 알아두면 좋은 사실이 있습니다. 한국어는 영어보다 같은 내용을 표현하는 데 토큰이 더 많이 드는 경향이 있습니다. 그래서 분량이 비슷해 보여도 한국어 문서가 모델 입장에서는 더 "길게" 느껴집니다. 요금(API로 쓸 경우), 처리 속도, 그리고 앞으로 나올 컨텍스트 한도까지, 전부 이 토큰 단위로 계산됩니다.
LLM이 실제로 하는 일은 딱 하나입니다. 지금까지 나온 글 다음에 올 토큰 하나를 확률로 예측하는 것입니다. 이 단순한 동작을 수백에서 수천 번 반복하면, 그 결과물이 우리 눈에는 자연스러운 문장으로 보입니다. 그래서 사실이 아닌 내용을 그럴듯하게 지어내는 '환각'도 생깁니다.
그런데 토큰 하나를 만들 때마다 모델 전체를 한 번씩 통과해야 합니다. 모듈 1에서 이야기한 대역폭(bandwidth, GPU가 1초에 메모리에서 읽어올 수 있는 데이터의 양) 이야기와 바로 연결되는 지점입니다. 답변이 길어진다는 것은 이 과정을 그만큼 여러 번 반복한다는 뜻이고, 당연히 시간도 그만큼 늘어납니다.
모델이 한 번에 기억하면서 참고할 수 있는 토큰 수에는 상한이 있습니다. 이를 컨텍스트 윈도우라고 부르며, 모델에 따라 8천 토큰짜리도 있고 3만 2천, 13만 토큰까지 되는 것도 있습니다. 감을 잡자면 A4 1장이 대략 500~700토큰이니, 8천 토큰은 A4 12장 안팎입니다. 이 한도를 넘기면 오류가 나거나, 혹은 앞부분의 내용을 조용히 잘라내고 잊어버립니다.
실무에서는 이런 질문으로 이어집니다. "이 규정집 전체를 넣고 질문할 수 있을까?" 답은 규정집을 토큰으로 환산한 분량이 그 모델의 컨텍스트 윈도우 안에 들어가는지에 달려 있습니다. 다만 컨텍스트를 넉넉하게 잡을수록 뒤에 나올 메모리(KV 캐시)도 그만큼 많이 먹는다는 점을 함께 기억해야 합니다.
모델이 답을 만드는 과정은 사실 두 단계로 나뉩니다. 첫 번째는 Prefill로, 입력된 내용 전체를 한꺼번에 읽어들이는 단계입니다. 이 단계는 병렬로 처리되어 상대적으로 빠르지만, 입력이 길어질수록 그만큼 오래 걸립니다. 긴 문서를 넣고 나서 첫 글자가 나오기까지 한참 조용한 그 시간이 바로 이 prefill입니다.
두 번째는 Decode로, 토큰을 한 개씩 순서대로 만들어내는 단계입니다. 여기가 바로 메모리 대역폭이 병목이 되는 지점입니다. 모듈 1의 공식(속도 상한 ≈ 대역폭 ÷ 모델 크기)이 바로 이 decode 단계에 적용됩니다.
이미 읽은 토큰들의 계산 결과를 GPU 메모리(VRAM, 그래픽카드 안의 전용 메모리)에 저장해 두는 장치를 KV 캐시라고 부릅니다. 만약 이 캐시가 없다면, 토큰을 하나 만들 때마다 그동안의 대화 전체를 처음부터 다시 계산해야 합니다. 그러니 KV 캐시는 속도를 지키기 위한 필수 장치입니다.
다만 공짜는 아닙니다. 컨텍스트가 길어질수록, 그리고 동시에 사용하는 사람이 많아질수록 이 KV 캐시가 VRAM을 그만큼 차지합니다. "여러 명이 같이 쓰면 왜 느려지는가"의 답이 여기 있습니다. 첫째, KV 캐시끼리 자리를 다투면서 한 사람이 쓸 수 있는 컨텍스트가 줄어듭니다. 둘째, GPU는 결국 여러 요청을 번갈아 처리해야 합니다.
최근 나오는 모델 중에는 답을 내놓기 전에 속으로 긴 '생각'을 거치는 것들이 있습니다. 이를 흔히 thinking 모드라고 부릅니다. 눈에 보이지 않는 추론 토큰을 먼저 잔뜩 생성한 뒤에야 최종 답을 내놓는 방식인데, 어려운 문제일수록 품질이 눈에 띄게 좋아집니다. 다만 그 대가로 생성해야 하는 토큰 수가 수십 배로 늘어나고, 그만큼 느려지고 메모리도 더 씁니다.