Parallelization Strategies for Dense LLM Deployment: Navigating Through Application-Specific Tradeoffs and Bottlenecks

이 논문은 Llama-3.1-70B 와 405B 와 같은 밀집형 LLM 의 배포 시 텐서 병렬화 (TP) 가 지연 시간 최적화에, 파이프라인 병렬화 (PP) 가 처리량 최적화에 유리하며, 두 기법을 혼합하여 지연 시간과 처리량 간의 트레이드오프를 조절할 수 있음을 실증적으로 분석합니다.

핵심

🏭 거대한 AI 공장: "로보트"와 "작업대"

우리가 사용하는 AI(예: Llama 3.1) 는 수천억 개의 파라미터라는 거대한 지식 덩어리를 가지고 있습니다. 이 지식은 마치 거대한 도서관에 꽂혀 있는 수백만 권의 책과 같습니다.

하지만 이 도서관을 한 명의 사서 (GPU) 가 혼자서 관리하기엔 너무 큽니다. 책이 너무 많아서 책장 하나에 다 들어가지도 않고, 한 번에 모든 책을 찾아서 정리하는 데는 시간이 너무 오래 걸립니다.

그래서 연구자들은 이 도서관을 여러 명의 사서 (여러 개의 GPU) 가 나누어 맡게 하는 두 가지 전략을 제안했습니다.

1. 전략 A: "책장을 쪼개기" (텐서 병렬화, Tensor Parallelism - TP)

• 비유: 한 권의 거대한 책을 여러 사서가 페이지 단위로 나누어 동시에 읽는 방식입니다.
  • 예를 들어, 100 페이지짜리 책을 4 명의 사서가 맡으면, 1 번 사서는 125 페이지, 2 번 사서는 2650 페이지를 동시에 읽습니다.
  • 장점: 한 번에 책을 읽는 속도가 매우 빨라집니다. (지연 시간, Latency 감소)
  • 단점: 사서들이 서로 "내 페이지 읽었어?", "다음 페이지로 넘어가자"라고 수시로 대화해야 합니다. 이 대화 (통신) 시간이 길어지면 속도가 느려질 수 있습니다.
• 누가 좋아할까? "나는 지금 바로 답을 원해!"라고 급하게 물어보는 사용자에게 좋습니다. (예: 채팅, 실시간 번역)

2. 전략 B: "작업대를 나누기" (파이프라인 병렬화, Pipeline Parallelism - PP)

• 비유: 도서관을 여러 개의 **작업 구역 (스테이션)**으로 나누는 방식입니다.
  • 1 번 사서는 책의 앞부분만 읽고, 2 번 사서는 그 다음 부분을 읽고, 3 번 사서는 마지막 부분을 읽습니다. 마치 조립 라인처럼요.
  • 장점: 한 번에 한 권의 책만 처리하는 게 아니라, 1 번 사서가 2 번 책을 읽는 동안 2 번 사서는 1 번 책의 다음 부분을 읽을 수 있습니다. 즉, 여러 주문을 동시에 처리할 수 있어 전체 생산량 (처리량, Throughput) 이 늘어납니다.
  • 단점: 한 번에 한 권의 책을 끝내는 데 걸리는 시간은 변하지 않습니다. (지연 시간 감소 효과는 적음)
• 누가 좋아할까? "나는 한 번에 수백 개의 문서를 요약해 줘."라고 대량으로 요청하는 기업이나 서버에 좋습니다.

---

⚖️ 연구 결과가 말해주는 것: "속도 vs 양"

이 논문은 이 두 가지 전략을 섞어서 쓸 때 어떤 일이 일어나는지 실험으로 증명했습니다.

1. 속도가 중요할 때 (TP):

   • 만약 당신이 "지금 당장 답이 필요해!"라고 한다면, TP(책장을 쪼개기) 전략이 가장 좋습니다.
   • 하지만 너무 많은 사서 (GPU) 를 모으면 서로 대화하는 시간이 길어져서 오히려 느려질 수도 있습니다. 적정선을 찾아야 합니다.

2. 양이 중요할 때 (PP):

   • 만약 당신이 "한 번에 1,000 명에게 답을 줘야 해!"라고 한다면, PP(작업대 나누기) 전략이 훨씬 효율적입니다.
   • PP 는 메모리 (책장 공간) 를 아껴주어 더 많은 주문을 동시에 받을 수 있게 해줍니다.

3. 최고의 조합 (하이브리드):

   • 연구자들은 TP 와 PP 를 섞어서 쓰는 것이 가장 현명하다고 말합니다.
   • 마치 공장에서 "한 번에 처리하는 속도를 높이기 위해 책을 쪼개고 (TP), 동시에 여러 주문을 받기 위해 작업대를 늘리는 (PP)" 방식입니다.
   • TP 의 정도를 조절하면 '속도'를 조절할 수 있고, PP 의 깊이를 조절하면 '처리량'을 조절할 수 있습니다.

---

💡 핵심 요약 (한 줄로 정리)

"거대한 AI 를 돌릴 때는, '빠른 답변'이 필요하면 책을 여러 사람이 나누어 읽고 (TP), '많은 주문'을 처리해야 하면 작업대를 여러 개 만들어 동시에 돌리는 (PP) 것이 정답입니다. 상황에 따라 이 두 가지를 적절히 섞으면 최고의 효율을 얻을 수 있습니다."

이 연구는 AI 서비스 제공자들이 고객의 요구 (빠른 응답 vs 대량 처리) 에 맞춰 가장 적합한 하드웨어 설정을 할 수 있도록 돕는 매뉴얼과 같은 역할을 합니다.

기술 요약

1. 문제 정의 (Problem Statement)

• 자원 제약: Llama 3.1-405B 와 같은 초대규모 밀집형 LLM 은 단일 GPU 의 메모리 용량을 초과합니다. 예를 들어, FP8 양자화 기준 모델 가중치만 약 405GB 가 필요하며, KV 캐시 (Key-Value Cache) 까지 고려하면 단일 GPU 에서는 실행이 불가능합니다.
• 지연 시간 vs 처리량의 상충 관계: LLM 추론 시스템에서 지연 시간 (지연성) 과 처리량 (처리 속도) 은 본질적으로 상충됩니다. 한쪽을 최적화하면 다른 쪽이 희생되는 경우가 많습니다.
• 병렬화 전략의 복잡성: 텐서 병렬화 (TP) 와 파이프라인 병렬화 (PP) 는 메모리 제약을 해결하는 핵심 기술이지만, 입력 특성, 배치 크기 (Batch Size), 모델 크기 등에 따라 지연 시간과 처리량에 미치는 영향이 다릅니다. 기존 연구들은 이러한 다양한 조건 하에서의 전략별 성능 한계와 병목 현상을 체계적으로 분석하지 못했습니다.

2. 방법론 (Methodology)

• 시뮬레이터 개발 및 검증: 연구진은 자체 개발한 시뮬레이터를 사용하여 다양한 병렬화 구성, 배치 전략, 입력 특성에 따른 추론 성능을 분석했습니다.
  • 모델: Llama 3.1-70B 와 405B (FP8 및 4-bit 양자화).
  • 하드웨어: AMD MI325x 및 MI355x GPU(각각 256GB/288GB HBM) 가 탑재된 8 개 GPU 노드 환경.
  • 데이터셋: 짧은 문맥 (BBH, GSM8K, HumanEval) 과 긴 문맥 (LongAlpaca, MLPerf) 을 모두 포함하는 다양한 데이터셋 사용.
• 검증: 시뮬레이션 결과는 실제 하드웨어 (Silicon) 실행 결과와 비교하여 검증되었습니다.
  • Llama 3.1-70B: 프리필 (Prefill) 및 디코드 (Decode) 단계에서 90% 이상 및 86% 이상의 정확도.
  • Llama 3.1-405B (TP8): 평균 오차 17.25% 수준으로 추세를 정확히 포착.
• 평가 지표:
  • 지연 시간: 첫 번째 토큰 도착 시간 (TTFT), 출력 토큰당 소요 시간 (TPOT).
  • 처리량: 초당 생성된 토큰 수 (TPS, Tokens Per Second).

3. 주요 기여 (Key Contributions)

1. 커널 수준의 작업 부하 분석: 다양한 병렬화 전략 (TP, PP, 하이브리드) 하에서 Transformer 레이어가 GPU 에 어떻게 매핑되는지 커널 수준에서 상세히 분석했습니다.
2. 지연 시간 - 처리량 트레이드오프 정량화: 배치 크기, 입력/모델 특성, 병렬화 깊이를 변화시키며 지연 시간 유연성 (Latency Flexibility) 과 처리량 간의 상관관계를 정량적으로 규명했습니다.
3. 병목 현상 식별: TP 의 경우 'All-Reduce' 통신 오버헤드가, PP 의 경우 파이프라인 간 통신 및 메모리 제약이 주요 병목임을 확인하고, 이를 해결하기 위한 설계 가이드라인을 제시했습니다.

4. 주요 결과 (Key Results)

A. 텐서 병렬화 (Tensor Parallelism, TP)

• 지연 시간 최적화: TP 는 Transformer 레이어 내부 (GEMM, Attention) 를 분할하여 여러 GPU 에서 병렬로 계산하므로, 지연 시간 (TTFT 및 TPOT) 을 크게 단축시킵니다.
• TP 깊이 증가 효과: TP 깊이 (예: TP4 → TP8) 를 높일수록 지연 시간이 선형적으로 감소하지만, All-Reduce 통신 오버헤드가 증가하여 일정 수준 이상에서는 효율이 떨어집니다.
• 적합한 시나리오: 낮은 지연 시간이 요구되는 실시간 대화형 애플리케이션에 적합합니다.

B. 파이프라인 병렬화 (Pipeline Parallelism, PP)

• 처리량 최적화: PP 는 Transformer 블록을 GPU 간에 분할하므로, 단일 GPU 의 메모리 부담을 줄여 **더 큰 KV 캐시와 더 큰 배치 크기 (Nano-batch)**를 허용합니다.
• 지연 시간 영향: PP 는 단일 배치의 처리 속도를 높이지 못하므로 지연 시간 감소에는 효과가 없으며, 오히려 파이프라인 간 통신으로 인해 지연 시간이 약간 증가할 수 있습니다.
• 처리량 향상: 더 큰 배치 크기를 통해 시스템 전체의 처리량 (TPS) 을 극대화합니다. 특히 디코드 단계가 메모리 병목 (Memory-bound) 에서 계산 병목 (Compute-bound) 으로 전환될 때 효과가 큽니다.
• 적합한 시나리오: 높은 처리량이 요구되는 오프라인 배치 처리나 대량 요청 처리에 적합합니다.

C. 하이브리드 전략 (Hybrid TP & PP)

• 균형 잡기: TP 와 PP 를 결합하면 TP 의 깊이로 지연 시간을 제어하고, PP 의 깊이로 처리량을 확장할 수 있는 **조정 가능한 균형 (Tunable Balance)**을 이룰 수 있습니다.
• 결과: TP 는 지연 시간 민감도, PP 는 처리량 민감도를 담당하도록 구성하여 서비스 수준 협약 (SLA) 을 만족시키는 최적의 설정을 찾을 수 있습니다.

D. 통신 오버헤드 분석

• TP: All-Reduce 연산이 지연 시간의 주요 병목이며, 링크 대역폭이 증가해도 All-Reduce 비율은 일정하게 유지되어 통신 오버헤드가 불가피함.
• PP: 파이프라인 간 통신 (P2P) 오버헤드는 All-Reduce 에 비해 훨씬 작아 지연 시간에는 미미한 영향을 미침.

5. 의의 및 결론 (Significance & Conclusion)

이 논문은 밀집형 LLM 배포 시 병렬화 전략 선택이 단순한 메모리 분할 문제를 넘어, 애플리케이션의 목표 (지연 시간 vs 처리량) 에 따라 결정되어야 함을 실증적으로 증명했습니다.

• 실무적 시사점:
  • 지연 시간 민감형 서비스 (예: 챗봇): 높은 TP 깊이 (예: TP8) 를 사용하여 지연 시간을 최소화해야 합니다.
  • 처리량 민감형 서비스 (예: 대량 문서 요약): PP 를 활용하여 배치 크기를 극대화하고 처리량을 높여야 합니다.
  • 하이브리드 접근: 시스템 요구사항에 따라 TP 와 PP 의 비율을 동적으로 조정하는 것이 가장 효율적인 전략입니다.
• 미래 전망: 본 연구의 인사이트는 다중 노드 시스템, 희소 모델 (MoE), 그리고 차세대 하드웨어 아키텍처에 대한 병렬화 전략 수립의 기초가 될 것입니다.

요약하자면, 이 연구는 **"TP 는 지연 시간을, PP 는 처리량을 최적화한다"**는 명확한 결론을 내리며, 이를 기반으로 한 하이브리드 병렬화 전략이 LLM 추론 시스템 설계의 핵심임을 강조합니다.