서론

도쿄과학대학 박사 과정의 후지이입니다. 본 기사에서는 LLM Inference (LLM 추론)의 속도 등을 Benchmarking (벤치마킹)할 때 이해해 두어야 할 기초적인 지식에 대해 해설합니다. 많은 논문, Technical Blog (기술 블로그) 등에서 제안 기법을 통해 어떻게 LLM Inference를 고속화/최적화할 수 있었는지 올바르게 이해하기 위해서는 기초적인 지식을 갖추고 있는 것이 중요합니다. 물론 개요를 "어렴풋이" 이해하는 것도 가능하지만, 시간을 조금 내어 기초부터 되짚어 보는 것도 좋지 않을까요?

LLM Inference 의 동작

이하에서는 AutoRegressive Decoder Only Transformer (Llama 시리즈나 Qwen 시리즈 등 유명한 LLM은 모두 이것입니다)를 전제로 이야기를 진행합니다. Mamba 아키텍처나 Discrete Masked Diffusion LM 등에 대해서는 이야기가 복잡해지므로 다루지 않습니다.

LLM Inference는 다음과 같은 단계로 구성됩니다.

Prompt (프롬프트): 사용자(Users)가 LLM에 프롬프트를 주는 단계입니다 -
Queuing (큐잉): 사용자로부터 주어진 프롬프트를 포함한 쿼리(query)가 처리 큐(queue for processing)에 추가됩니다 -
Prefill (프리필): LLM이 큐잉된 Query에서 프롬프트를 꺼내어 prompt를 처리합니다 (후술하듯이 많은 경우 Compute Bound Operation (연산 집약적 작업)입니다) -
Generation (생성) (decoding): LLM이 프롬프트를 처리한 결과에 기반하여 이어지는 문장(tokens)을 생성합니다. 이때 AR (Auto Regressive) 모델인 LLM에서는 한 번에 1개씩 토큰을 생성해 나갑니다 (one token at a time).

LLM Inference metrics

본 기사에서는 "token", "sequence length (시퀀스 길이)", "context length (컨텍스트 길이)" 등의 용어를 이해하고 있다고 가정하고 해설을 진행합니다. LLM 전반에 관계된 용어에 대해서는 별도의 기사 등을 참조해 주세요.

LLM Inference benchmarking 특유의, 또는 중요한 용어에 대해서는 이하에서 해설합니다.

용어 해설

ISL

**Input Sequence Length (ISL, 입력 시퀀스 길이)**란, LLM이 얼마나 많은 tokens 수를 받아들이는지를 가리키는 용어입니다. 구체적으로는 사용자의 쿼리(user query), 시스템 프롬프트(system prompt) (모델 제공 사업자 등이 모델에 설정해 둔 프롬프트), 이전 채팅이 존재하는 경우 채팅 이력(previous chat history), CoT (Chain of Thought) 이력, RAG (Retrieval-Augmented Generation)를 이용하고 있는 경우 RAG가 가져온 문서가 ISL (Input Sequence Length)에 포함됩니다.

OSL

**Output Sequence Length (OSL, 출력 시퀀스 길이)**는 LLM이 얼마나 많은 수의 token을 생성하는지를 나타냅니다. 일반적으로 Context Length (컨텍스트 길이)는 어떤 generation step (생성 단계)에서 모델이 참조하는 토큰 열의 길이를 가리킵니다. Decoder-only Transformer에서는 생성이 진행됨에 따라 참조하는 시퀀스 길이는

Streaming

Streaming (스트리밍)이란, LLM의 출력 결과를 토큰의 어느 정도 덩어리(chunks of tokens) 단위로 사용자에게 전송하는 옵션 기능입니다. LLM의 생성이 모두 완료된 후 사용자에게 출력 결과를 돌려주어도 되지만, 모든 생성이 완료되려면 어느 정도 시간이 소요됩니다. 그래서 어느 정도 생성이 되면 그 부분을 사용자에게 전송하고 화면에 표시함으로써, 사용자가 출력이 진행 중인 것을 확인하는 동안 나머지 토큰 생성을 수행하는 것이 가능해집니다.

전체상

이하에서는 아래 그림과 같이 User (사용자)와 Inference Service (추론 서비스) 사이에서 발생하는 각종 계산을 예로 들어, Inference Benchmarking에서 이용되는 metrics (지표)에 대해 해설합니다.

Time to first token

**Time To First Token (TTFT)**는 아래 그림에서 보여주는 것처럼 프롬프트를 처리(tokenize + prefill)하여 첫 번째 토큰 1개를 생성할 때까지 소요되는 시간을 나타냅니다. 사용자 관점에서 보면, Inference Service와의 통신 등을 무시했을 때, 프롬프트를 작성하여 Chat Bot에 전송한 후 생성 결과가 단 한 글자라도 생성될 때까지 얼마나 기다려야 하는지를 나타내는 지표입니다.

위 그림에서는 생략하였으나, 일반적으로 Request Queuing Time(사용자의 Request를 대기열(Queue)에 넣은 후 실제로 처리가 시작될 때까지의 시간)도 TTFT에 포함됩니다. 또한, 사용자와 Inference Service 사이는 많은 경우(Local LLM 등을 제외하고) 네트워크를 경유하여 통신하므로 Network Latency도 TTFT에 영향을 미칩니다.

또한, 입력하는 프롬프트 길이가 길 경우 TTFT는 증가합니다. 이는 위 그림 중 "Initial Prompt Processing (Prefill)" 부분이 나타내는 것처럼, Input Sequence 전체를 처리하여 KV cache를 계산해야 하기 때문입니다. Input Sequence Length (ISL)가 길수록 LLM이 계산해야 하는 KV cache 크기는 증가합니다. 많은 경우 Prefill Phase는 Compute Bound이므로, 계산해야 할 대상이 증가하면 소요되는 시간도 증가하게 됩니다.

End-to-end request latency

**End-to-end Request Latency (E2E Latency)**는 Query를 전송한 후, LLM이 모든 응답을 반환할 때까지의 시간을 나타냅니다. (아래 그림) 따라서 Queuing, Batching, Network Latency 등도 E2E Latency에 포함됩니다. Streaming mode의 경우, De-Tokenization은 한 번에 일괄적으로 이루어지는 것이 아니라 여러 번에 나누어 수행됩니다.

Intertoken latency

**InterToken Latency (ITL)**는 sequence 내에서 연속되는 token 간에 생성에 소요되는 시간의 평균값을 취한 것입니다. 아래 그림에서 Decoding(녹색) 부분을 확대한 것을 보면, itl-1, itl-2, ...와 같이 첫 번째 token의 생성이 완료된 후 두 번째 token의 생성이 완료될 때까지의 시간을 itl-1, 두 번째 token 생성 종료부터 세 번째 token 생성 완료까지를 itl-2와 같이 하여, 이들의 평균을 낸 것이 ITL이 됩니다.

이 정의는 매우 단순 명쾌하여 Inference Benchmarking Tool 간에 차이가 없을 것처럼 보이지만, 실제로는 그렇지 않습니다. 예를 들어 GenAI-Perf (현재의 AI Perf)에서는 TTFT(Total Time for First Token)를 ITL의 평균값 산출에 포함하지 않지만, LLMPerf에서는 포함합니다. 동일한 도구로 측정할 때는 문제가 없으나, 논문 수치와 비교할 때 어떤 도구를 사용하고 있는지 의식하지 않고 비교하게 되면 ITL 값의 비교 가능성이 상실됩니다. arXiv에 게시된 논문 중에는 이 부분을 의식하지 않은 것도 있으므로 주의가 필요합니다.

그렇기 때문에 개인적으로는 사용 도구 등에 대해 상세히 보고하는 것을 어설픈 신규성(Novelty)보다 중요하게 생각합니다. 신규성을 주장하는 실험 결과가 애초에 여러 도구로 측정한 결과를 섞어 놓았다면 말이 되지 않기 때문입니다...

Tokens per second

**Tokens Per Second (TPS)**는 일반적으로 system 전체에서 1초당 생성할 수 있는 output token 수를 나타내는 throughput metric입니다. NVIDIA의 정의에 따르면, TPS per system은 동시에 발생하고 있는 모든 request를 고려한 total output token throughput입니다. Concurrency나 request rate를 높이면 system TPS는 어느 포화점까지는 증가하지만, GPU compute, memory bandwidth, KV cache capacity 등의 제약에 도달하면 정체되며, 조건에 따라서는 저하되기도 합니다.

References

おわりに

본 기사에서는 LLM Inference Benchmarking의 기초 지식에 대해 해설하였습니다. 본 기사에서는 LLM Inference에 대해 다루었으나, 저의 다른 기사들에서는 LLM 구축 지견, LLM Training Library에 대하여 학습 가속화 방법 등 다양한 관련 토픽에 대해 해설하고 있습니다.

또한, LLM Inference와 관련된 토픽으로는 다음과 같은 기사도 집필하였습니다.

아울러, 모델 아키텍처 (Model Architecture) 측면에서 LLM Inference에 대해 생각하는 것도 매우 중요합니다. 그 내용에 대해서도 향후 기사를 집필해 나갈 예정입니다.

Discussion