LLM 추론은 어떻게 작동하는가

텍스트는 먼저 토큰화되고, 대부분의 LLM은 **Byte Pair Encoding(BPE)**으로 문장을 약 5만 개의 토큰 조각으로 쪼갠다. 이어 각 토큰은 임베딩 테이블에서 4,096차원 벡터로 바뀌고, RoPE 같은 위치 정보가 더해져 순서가 반영된다.

그다음 transformer layer들이 연쇄적으로 작동한다. 각 층은 self-attention으로 토큰 간 정보를 섞고, feed-forward network으로 표현을 가공한 뒤 마지막 위치의 벡터를 어휘 크기로 투영해 다음 토큰 확률을 만든다.

추론은 실제로 prefill과 decode 두 단계로 나뉜다. 프롬프트 전체를 한 번에 처리하는 prefill은 모든 토큰의 Q/K/V를 병렬 계산하는 compute-bound 구간이며, 첫 토큰이 나온 뒤의 decode는 새 토큰 하나씩만 계산하는 memory-bound 구간이다. 전자는 TTFT(Time to First Token), 후자는 **ITL(Inter-Token Latency)**을 좌우한다.

핵심 최적화는 KV 캐시다. 이전 토큰의 K/V를 저장해 재계산을 피하면 긴 응답에서 속도를 5배 이상 높일 수 있지만, 캐시는 GPU 메모리를 빠르게 소모한다. 기사 기준으로 13B 모델은 토큰당 대략 1MB, 4K 토큰 컨텍스트는 캐시만으로 약 4GB VRAM을 사용한다.

완화책도 다양하다.

• INT8/INT4 양자화로 가중치 메모리를 줄이고, FP16/BF16 대비 처리량을 끌어올린다.
• GPTQ와 AWQ는 채널별 스케일링으로 품질 손실을 줄인다.
• Grouped-query attention과 PagedAttention은 K/V 메모리 부담을 줄이거나 페이지처럼 관리한다.

가중치 크기만 봐도 차이가 분명하다. 7B 파라미터 모델은 FP32 28GB, FP16 14GB, INT8 7GB, INT4 3.5GB 수준으로 내려가며, 훈련과 달리 추론은 이런 저정밀화에 훨씬 관대하다. 그래서 작은 GPU나 노트북급 환경에서도 실행 가능해진다.

DeepSeek V4 계열은 캐시 자체를 줄이는 방향도 보여준다. 100만 토큰 컨텍스트에서 캐시 크기를 약 10%, 토큰당 계산량을 27% 수준으로 낮췄다고 소개되며, vLLM, TensorRT-LLM, Text Generation Inference는 continuous batching과 speculative decoding으로 여러 사용자를 같은 GPU에서 묶어 처리한다. 생성된 토큰은 다시 문자로 바뀌어 스트리밍된다.

실무 함의는 분명하다.

• 긴 프롬프트는 TTFT를, 긴 출력은 ITL을 악화시킨다.
• 컨텍스트를 늘리면 캐시가 커지고 배치 효율이 떨어진다.
• 양자화는 가장 큰 레버리지이며, GPU utilization만 보고 속도를 판단하면 안 된다.

결국 체감 속도는 연산량보다 메모리 대역폭과 캐시 설계에 더 크게 좌우된다. 모델이 느릴 때 먼저 물어야 할 질문은 더 강한 GPU가 아니라, 시작이 느린지 스트리밍이 느린지다.