‹ Back to Blog

Blog

다수의 구세대 GPU 노드에서의 Long-Context Prefill 최적화

December 26, 2025

Authors: Jiyoung Park, Seungman Han, Jangwoong Kim, Jungwook Kim, and Kyungrok Kim

이 문서는 AI를 통해 자동 번역되었습니다. 어색하거나 부정확한 내용이 있을 수 있으니, 필요한 경우 영어 원문을 참고해 주세요. 영어 원문 보기

개요

AI 애플리케이션에서 에이전틱 워크플로우가 점점 더 보편화됨에 따라, 모델은 급격히 늘어난 컨텍스트 길이를 처리해야 합니다. 이러한 변화는 시스템 활용도를 극대화하면서 서비스 수준 목표(SLO)를 유지해야 한다는 중대한 과제를 제시합니다. 특히, 긴 컨텍스트 요청에 대한 Time-To-First-Token(TTFT)을 줄이기 위해 prefill 성능을 최적화하는 것이 매우 중요합니다. 이를 해결하기 위해 저희는 SLO-Driven Prefill Engine(SLOPE)을 개발했습니다.

SLOPE는 멀티 노드 GPU 클러스터에서 context parallelism 기법(Ulysses + Ring Attention)을 적용하여 긴 컨텍스트 입력에 대한 SLO 기반 최적화를 수행하는 전용 prefill 엔진입니다. 기존 LLM 엔진은 prefill 연산이 단일 노드에 한정되어 있어, 긴 입력 프롬프트를 처리할 때 TTFT를 일정 임계값 이하로 줄이는 데 근본적인 한계가 있습니다. SLOPE는 prefill 연산을 여러 노드에 걸쳐 병렬화함으로써 이러한 한계를 극복하고, 동시 사용자 요청 수를 극대화하면서도 TTFT를 목표 SLO 임계값 이하로 크게 낮춥니다.

SLOPE는 기존 LLM 엔진과 prefill/decode 분리 모드로 통합할 수 있으며, 이 경우 전용 prefill 워커로 동작합니다.

Context Parallelism 소개

Tensor parallelism(TP)은 LLM 추론에서 가장 널리 사용되는 병렬화 기법입니다. TP는 linear layer의 파라미터를 디바이스들에 분산하여 attention head를 디바이스별로 나누고, AllReduce 통신을 필요로 합니다. 그러나 TTFT를 줄이기 위해 단순히 TP 크기를 늘리는 것에는 한계가 있습니다:

  • 비효율적인 GEMM 연산: 과도한 파라미터 분할은 비효율적인 GEMM 연산을 초래합니다.
  • 중복 연산: attention head 수가 TP 크기보다 작을 경우 중복 연산이 발생합니다.
  • 통신 오버헤드: TP 크기가 증가하면 노드 간 AllReduce가 필요해져 통신 오버헤드가 크게 증가합니다.

Context parallelism은 입력 프롬프트를 시퀀스 차원을 따라 분할합니다. 특히 긴 컨텍스트 시나리오에서는, 시퀀스 차원에서 활용 가능한 대규모 병렬성 덕분에 context parallelism이 tensor parallelism보다 더 효율적입니다. attention layer를 제외한 대부분의 연산은 토큰 간 의존성이 없어 완전히 독립적으로 처리할 수 있습니다. attention layer의 토큰 간 의존성은 두 가지 접근법으로 해결할 수 있습니다:

  • Ulysses: attention 연산 전에 query, key, value에 대해 all-to-all 통신을 수행하고, head 차원으로 분할하여 독립적인 연산을 가능하게 합니다.
  • Ring Attention: 각 디바이스에서 부분적인 query, key, value로 attention 연산을 수행하면서, 동시에 인접 디바이스와 key 및 value를 송수신합니다.

이 두 접근법은 상호 보완적인 트레이드오프를 가집니다. Grouped Query Attention(GQA)이나 Multi-Head Latent Attention(MLA)을 사용할 경우 key와 value head 수가 줄어들기 때문에 Ulysses 적용에 제약이 있습니다. 반면 Ring Attention은 Ulysses보다 통신량이 많습니다. 그러나 시퀀스 길이가 길어질수록 attention 연산이 비례적으로 더 지배적이 되어, 통신을 attention 연산으로 은닉할 수 있습니다. 따라서 컨텍스트 길이와 SLO 요구사항에 따라 적절히 조합하여 사용해야 합니다.

Context parallelism을 적용하면 모든 디바이스가 모델 파라미터를 중복으로 보유하게 되므로, TP에 비해 메모리 사용량이 증가합니다. 이 문제는 context parallelism과 함께 pipeline parallelism을 적용하여 해결합니다.

평가

저희는 4노드 AMD MI250 클러스터(노드당 8 디바이스)에서 Ulysses, Ring Attention, Pipeline Parallel을 다양하게 조합한 병렬화 구성에 대해 SLOPE의 prefill 성능을 평가하고, TP=8을 적용한 SGLang과 비교했습니다. 모든 실험에서 openai/gpt-oss-120b 모델을 사용하여 prefill 성능을 평가했으며, 32K, 64K, 100K의 세 가지 컨텍스트 길이로 테스트했습니다.

아래 표에서 볼 수 있듯이, SLOPE는 모든 컨텍스트 길이에서 매우 낮은 TTFT SLO를 충족하는 반면, SGLang의 충족 여부는 경우에 따라 다릅니다.

Table 1. Whether different TTFT constraints (1s, 2s, and 3s) are satisfied.
Table 1. Whether different TTFT constraints (1s, 2s, and 3s) are satisfied.

Figure 1은 다양한 병렬화 구성과 동시 요청 수에 따른 TTFT 및 처리량 측정 결과를 보여줍니다. 결과를 통해 SLOPE가 32K와 64K 컨텍스트 모두에서 TTFT 1초 미만의 매우 낮은 지연 시간 SLO를 달성함을 확인할 수 있습니다. TP=8을 적용한 SGLang과 비교했을 때, SLOPE는 동일한 TTFT에서 더 높은 처리량을 달성합니다. 이는 SLO 요구사항을 충족하면서 더 많은 동시 사용자 요청을 처리할 수 있음을 의미합니다. 100K 컨텍스트 길이에서도 SLOPE는 TTFT 2초 미만을 달성하는 반면, TP=8을 적용한 SGLang은 약 9초에 머뭅니다. 이는 SLOPE가 긴 컨텍스트 LLM 추론을 위한 실용적인 솔루션을 제공함을 보여줍니다.

Figure 1. TTFT and throughput across various parallelization configuration and concurrency combinations.
Figure 1. TTFT and throughput across various parallelization configuration and concurrency combinations.

이기종 클러스터에서의 SLOPE 엔진

SLOPE 엔진의 활용은 단순히 긴 컨텍스트 추론의 응답 지연 시간을 줄이고 토큰 처리량을 높이는 것에 그치지 않습니다. 데이터 센터에 이미 존재하는 레거시 GPU 서버를 효율적으로 활용하는 방법도 제공합니다.

일반적으로 LLM 추론은 여러 노드에 걸쳐 병렬화하기 어려우며, 이것이 대규모 LLM을 처리하기 위해 점점 더 빠르고, 더 큰 용량을 가지며, 더 비싼 GPU가 계속 도입되는 이유 중 하나입니다. 그러나 SLOPE 엔진을 사용하면, 적어도 prefill 단계에서는 여러 대의 구형 GPU 서버를 결합하여 충분히 낮은 지연 시간과 높은 처리량을 달성할 수 있습니다.

이러한 활용이 실현 가능함을 보여주기 위해, 저희는 AMD MI250 GPU 클러스터에서 SLOPE를 평가했습니다. AMD MI250 GPU(NVIDIA A100에 상당)와 최신 MI300 시리즈 GPU가 공존하는 시스템에서, MI250 GPU를 SLOPE에 할당하고 MI300 시리즈 GPU는 기존 추론 엔진을 사용하여 디코딩을 수행함으로써, 전체 시스템의 효율성을 높일 수 있습니다. 이러한 기능은 2026년 1분기부터 MoAI Inference Framework를 통해 지원될 예정입니다.