SUN: Shared Use of Next-token Prediction for Efficient Multi-LLM Disaggregated Serving

이 논문은 여러 LLM 을 위한 분산 서비스에서 모델 간 디코딩 실행을 공유하여 GPU 활용도를 극대화하고 처리량을 2 배까지 향상시키는 'SUN'이라는 새로운 접근법을 제안합니다.

핵심

🍕 비유: "피자 가게의 비효율적인 주방"

지금까지의 AI 서비스 방식은 다음과 같았습니다.

1. 기존 방식 (문제점): "각자 전용 주방"

• 상황: 피자 가게에 '피자 전문', '파스타 전문', '초밥 전문' 세 개의 주방이 있다고 상상해 보세요.
• 문제:
  • 피자 주문이 몰릴 때: 피자 주방은 바글바글하지만, 초밥 주방은 손님이 없어 요리사들이 멍하니 서 있습니다. (GPU 자원 낭비)
  • 초밥 주문이 몰릴 때: 반대로 초밥 주방은 붐비는데 피자 주방은 비어 있습니다.
  • 결과: 가게 전체의 효율이 떨어지고, 손님이 기다리는 시간 (지연 시간) 이 길어집니다. 특히 주문을 받아 재료를 다듬는 과정 (Prefill) 과 완성된 요리를 접시에 담는 과정 (Decode) 을 같은 주방에서 하면 서로 방해가 되어 더 느려집니다.

2. SUN 의 해결책: "공유 주방과 전문 요리사"
SUN 은 이 문제를 해결하기 위해 두 가지 혁신적인 아이디어를 제시합니다.

🧩 아이디어 1: "요리 과정 분리 & 공유" (Decomposition & Sharing)

• 분리: 요리를 두 단계로 나눕니다.
  1. 재료 준비 (Prefill): 주문 내용을 보고 어떤 재료가 필요한지 파악하는 단계. (계산이 많음)
  2. 접시 담기 (Decode): 재료를 받아서 실제로 요리를 완성하고 접시에 담는 단계. (메모리 사용이 많음)
• 공유:
  • 재료 준비 (Prefill): 각 메뉴 (피자, 파스타, 초밥) 에 맞춰 전문 요리사가 따로 있습니다. (각 모델에 맞는 미세 조정)
  • 접시 담기 (Decode): 이 단계는 모든 메뉴가 똑같은 방식으로 이루어집니다. 그래서 **한 명의 '마스터 셰프' (공유된 디코더)**가 모든 메뉴의 완성 작업을 담당하게 합니다.
• 효과: 주문이 어느 메뉴에 몰리든 상관없이, '마스터 셰프'들이 모두 함께 일하므로 주방이 비는 일이 사라집니다.

🚀 아이디어 2: "마스터 셰프의 훈련법" (Prefill-only Tuning)

• 질문: "다른 메뉴의 재료를 받아서 마스터 셰프가 잘 요리할 수 있을까요?"
• 해결: SUN 은 마스터 셰프 (공유된 모델) 는 절대 건드리지 않고 (Frozen) 그대로 둡니다. 대신, 각 메뉴의 **재료 준비 담당자 (Prefill 모듈)**만 특별히 훈련시킵니다.
• 비유: "마스터 셰프는 원래대로 두되, 재료 준비 담당자들이 '이 셰프가 좋아하는 방식으로 재료를 다듬어 달라'는 신호를 보내도록 훈련시킵니다."
• 결과: 마스터 셰프는 어떤 메뉴의 재료가 들어와도 완벽하게 요리할 수 있게 되며, 정확도도 떨어지지 않습니다.

⚡ 아이디어 3: "QSUN (양자화 버전)" - "더 빠른 마스터 셰프"

• 아이디어: 마스터 셰프의 두뇌 (모델) 를 조금 더 가볍게 만들어서 속도를 높입니다. (정밀도는 살짝 떨어질 수 있음)
• 해결: 마스터 셰프를 가볍게 만든 후, 재료 준비 담당자만 다시 훈련시켜서 가벼운 셰프도 완벽하게 요리할 수 있게 맞춥니다.
• 효과: 요리 속도가 45% 빨라지지만, 맛 (정확도) 은 거의 그대로 유지됩니다.

---

🌟 SUN 이 가져오는 변화 (핵심 요약)

1. 비용 절감 (TCO 감소):

   • 예전에는 메뉴별로 전용 주방 (GPU) 을 다 갖춰야 했지만, 이제는 공유 주방을 쓰면 필요한 주방 수가 절반 이상 줄어듭니다.
   • 비유: 4 개의 주방을 2 개만 써도 같은 양의 피자를 더 빠르게 만들어냅니다.

2. 부하 균형 (Skewed Workloads 해결):

   • 어떤 메뉴가 갑자기 대박이 나도, 다른 메뉴의 주방이 비어있지 않고 모두 힘을 합쳐 처리합니다.
   • 비유: 피자가 대박이 나도 초밥 주방이 비어있지 않고, 피자를 만드는 데 도움을 줍니다.

3. 속도 향상:

   • GPU 당 처리량이 최대 2 배까지 늘어납니다.
   • 사용자에게는 "답이 나오는 속도"가 거의 그대로 유지되면서, 서버 비용은 확 줄어듭니다.

💡 결론

이 논문은 **"여러 개의 AI 모델을 따로따로 돌리는 비효율적인 방식"**을 버리고, **"공통된 부분을 공유하고 필요한 부분만 맞춤화하는 방식"**으로 바꾸어, 더 저렴하고 더 빠른 AI 서비스를 가능하게 합니다.

마치 공유 오피스처럼, 각 팀 (모델) 은 자신만의 책상 (Prefill) 을 쓰지만, 회의실 (Decode) 은 모두 공유해서 비는 공간 없이 효율적으로 운영하는 것과 같습니다.

기술 요약

1. 문제 정의 (Problem Statement)

최근 대규모 언어 모델 (LLM) 은 범용 챗봇을 넘어 다양한 도메인별 전문 모델이나 다중 에이전트 워크플로우에서 동시에 서비스되는 경우가 많아졌습니다. 그러나 이러한 다중 LLM 서빙 (Multi-LLM Serving) 환경에서는 다음과 같은 비효율성이 발생합니다.

• 모델 간 고립 (Inter-model Isolation): 기존 분해형 (Disaggregated) 아키텍처는 Prefill(입력 처리) 과 Decode(토큰 생성) 단계를 분리하여 내부 간섭을 해결하지만, 각 모델마다 별도의 Decode 워커 (GPU) 를 할당합니다.
• 리소스 낭비: 실제 트래픽은 특정 인기 모델에 치우치는 (Skewed workload) 경향이 강합니다. 이로 인해 인기 모델은 큐가 길어지는 반면, 인기가 낮은 모델에 할당된 GPU 는 메모리 바운드 (Memory-bound) 인 Decode 단계 특성상 심각한 유휴 상태 (Underutilization) 에 빠집니다.
• 교차 모델 배치 불가능: 각 모델이 고유한 파라미터를 가지기 때문에, 서로 다른 모델의 Decode 요청을 하나의 배치로 합쳐서 처리할 수 없어 GPU 활용도가 낮아집니다.

2. 제안 방법론 (Methodology: SUN)

저자들은 SUN (Shared Use of Next-token Prediction) 을 제안하여 모델 간 고립을 해결하고 Decode 리소스를 공유하는 새로운 방식을 도입했습니다.

핵심 아이디어: Prefill-Only Tuning 및 Frozen Decode 공유

• 모델 분해: Decoder-only Transformer 를 Prefill 모듈 (프롬프트 처리 및 KV Cache 생성) 과 Decode 모듈 (토큰 생성) 로 개념적으로 분해합니다.
• 파라미터 전략:
  • Prefill 모듈: 각 태스크 (수학, 코딩, 도구 호출 등) 에 맞춰 미세 조정 (Fine-tuning) 합니다.
  • Decode 모듈: 모든 태스크에서 동결 (Frozen) 시켜 단일 공유 모듈로 사용합니다.
• KV Cache 호환성 확보: 단순히 공유된 디코더를 사용하면 정확도가 급격히 떨어집니다 (Train-Inference Mismatch). 이를 해결하기 위해 SUN 은 Prefill-Only Tuning을 수행합니다. 공유된 디코더가 이해할 수 있도록 각 태스크별 Prefill 모듈이 생성하는 KV Cache 가 디코더와 호환되도록 학습시킵니다.
• 모델 무관 라우팅 (Model-agnostic Routing):
  • Prefill: 요청은 태스크별 전용 Prefill 워커로 라우팅됩니다.
  • Decode: 생성된 토큰 요청은 모델 식별자와 무관하게 공유된 Decode 워커 풀 (Pool) 로 라우팅되어 부하를 분산합니다. 이를 통해 서로 다른 모델의 요청도 하나의 배치로 처리 가능합니다.

QSUN (Quantized SUN): 양자화 최적화

• Decode 단계는 메모리 바운드이므로 양자화 (Quantization) 의 효과가 큽니다. SUN 의 공유 Decode 모듈에 Weight-only Quantization (4-bit) 을 적용합니다.
• 양자화로 인한 정확도 저하를 막기 위해, Prefill 모듈만 재조정 (Re-tuning) 하여 양자화된 디코더와 호환되는 KV Cache 를 생성하도록 학습시킵니다.

3. 주요 기여 (Key Contributions)

1. 강건한 교차 모델 Decode 공유: SUN 은 태스크별 Prefill 모듈만 미세 조정하고 공유된 Frozen Decode 모듈을 사용하여, 다양한 모델과 태스크에서 풀 파인튜닝 (Full Fine-tuning) 과 comparable 한 정확도를 유지하면서 단일 디코더를 공유합니다.
2. 높은 활용도를 위한 모델 무관 라우팅: 공유 워커 간 부하 균형을 통해 Decode GPU 수를 50% 줄이면서도 시스템 처리량 (Throughput) 을 유지하고, 편향된 트래픽 (Skewed workload) 하에서도 지연 시간 오버헤드를 최소화합니다.
3. 정확도 보존 양자화 디코딩 (QSUN): 공유 Decode 모듈에 양자화를 적용하고 Prefill 만 재조정하여, 4-bit 디코딩의 효율성 (속도 향상) 을 유지하면서도 SUN 의 정확도 수준을 회복합니다.

4. 실험 결과 (Experimental Results)

NAVER Cloud 의 vLLM 기반 분해형 환경 (DGX A100 8 GPU) 에서 LLaMA3.1-8B 및 Qwen3 시리즈를 대상으로 실험했습니다.

• 정확도 (Accuracy): SUN 은 수학 (GSM8K), 코딩 (HumanEval), 도구 호출 (BFCL) 등 다양한 벤치마크에서 풀 파인튜닝 모델과 거의 동일한 정확도를 달성했습니다. (예: LLaMA3.1-8B 기준 GSM8K 70.6% vs Full-FT 71.3%)
• 시스템 성능 (Throughput & Latency):
  • GPU 효율성: 기존 분해형 방식 대비 GPU 당 처리량 (Throughput per GPU) 이 최대 2.0 배 향상되었습니다.
  • 리소스 절감: 동일한 처리량을 유지하면서 Decode GPU 수를 줄일 수 있어 총 소유 비용 (TCO) 을 절감합니다.
  • 지연 시간: 출력 토큰당 소요 시간 (TPOT) 은 기존 대비 5% 이내로 유지되거나 개선되었습니다.
• 편향된 트래픽 (Skewed Workload) 대응: 트래픽 편향 (Zipf 분포) 이 심한 환경에서도 SUN 은 모델별 격리 방식보다 훨씬 안정적인 처리량과 상호작용성 (Interactivity) 을 유지했습니다.
• QSUN 성능:
  • 속도 향상: SUN 대비 TPOT 가 45% 단축되어 속도가 크게 개선되었습니다.
  • 정확도 회복: 양자화로 인한 정확도 하락을 Prefill 재조정으로 거의 완전히 회복하여, 16-bit 풀 정밀도 SUN 과 유사한 성능을 내면서도 4-bit 디코딩의 이점을 취했습니다.
  • TTFT 개선: Prefill 단계를 고정 정밀도로 유지하여 AWQ(전체 양자화) 대비 첫 토큰 도달 시간 (TTFT) 이 17% 더 빠릅니다.

5. 의의 및 결론 (Significance)

이 논문은 다중 LLM 서빙 환경에서 발생하는 모델 간 리소스 고립 문제를 해결하는 획기적인 접근법을 제시합니다.

• 경제적 효율성: 고가의 HBM 이 장착된 GPU 를 메모리 바운드인 Decode 단계에서 효율적으로 공유함으로써, 서비스 비용을 크게 절감할 수 있습니다.
• 확장성: 수백 개의 전문 모델을 동시에 서비스해야 하는 에이전트 기반 AI 시대에, 리소스 분할의 한계를 극복하고 유연한 스케일링을 가능하게 합니다.
• 실용성: SUN 과 QSUN 은 기존 LLM 서빙 프레임워크 (vLLM 등) 와 호환되며, 양자화 기술을 통해 저비용 고효율의 배포를 실현할 수 있는 구체적인 솔루션을 제공합니다.

결론적으로 SUN 은 정확도를 희생하지 않으면서 다중 모델 환경의 GPU 활용도를 극대화하고, 양자화를 통해 지연 시간을 획기적으로 줄인 차세대 LLM 서빙 아키텍처의 표준이 될 수 있는 기술입니다.