Source-linked AI summary

DynamoLLM: Designing LLM Inference Clusters for Performance and Energy Efficiency

Jovan Stojkovic, Chaojie Zhang, Íñigo Goiri, Josep Torrellas, Esha Choukse

arXiv:2408.00741v1cs.AIcs.ARcs.DC

TL;DR

LLM inference cluster는 엄격한 성능 SLO를 충족하는 과정에서 상당한 에너지를 소비하지만, energy management는 충분히 연구되지 않았다. DynamoLLM은 energy-efficient configuration을 동적으로 선택해 latency SLO를 충족하면서 에너지를 53%, operational carbon emissions를 38%, customer cost를 61% 줄인다.

  • 문제

    전력 소모가 큰 GPU를 사용하고 carbon emissions를 줄이면서 높은 성능을 유지해야 함에도, LLM inference cluster의 energy consumption은 여전히 충분히 연구되지 않았다.

  • 방법

    DynamoLLM은 performance SLO 하에서 instance 수, model parallelism, GPU frequency를 조정해 configuration을 동적으로 선택하도록 energy-performance profile을 사용한다.

  • 결과

    latency SLO를 충족하면서 에너지는 53% 감소했고, operational carbon emissions는 38% 감소했으며, customer cost는 61% 감소했다.

  • 시사점 및 한계

    DynamoLLM은 LLM inference cluster를 동적으로 구성하면 performance guarantee를 유지하면서 에너지, carbon emissions, customer cost를 줄일 수 있음을 보인다.

Abstract

from arXiv · show

The rapid evolution and widespread adoption of generative large language models (LLMs) have made them a pivotal workload in various applications. Today, LLM inference clusters receive a large number of queries with strict Service Level Objectives (SLOs). To achieve the desired performance, these models execute on power-hungry GPUs causing the inference clusters to consume large amount of energy and, consequently, result in excessive carbon emissions. Fortunately, we find that there is a great opportunity to exploit the heterogeneity in inference compute properties and fluctuations in inference workloads, to significantly improve energy-efficiency. However, such a diverse and dynamic environment creates a large search-space where different system configurations (e.g., number of instances, model parallelism, and GPU frequency) translate into different energy-performance trade-offs. To address these challenges, we propose DynamoLLM, the first energy-management framework for LLM inference environments. DynamoLLM automatically and dynamically reconfigures the inference cluster to optimize for energy and cost of LLM serving under the service's performance SLOs. We show that at a service-level, DynamoLLM conserves 53% energy and 38% operational carbon emissions, and reduces 61% cost to the customer, while meeting the latency SLOs.

I. 서론

DynamoLLM은 workload의 이질성과 변동을 활용해 성능 SLO를 충족하면서 효율적인 LLM inference 구성을 동적으로 선택하는 energy-management framework다. Production-level trace에서 energy, operational carbon emissions, customer cost를 줄인다.

  • I. 서론: 요청 길이, model compute properties, service SLO가 이질적이고 변동하는 workload를 만들어 LLM inference energy management가 어렵다.이러한 변동은 기존 datacenter energy-management 환경과 다른 동적 환경을 만든다.
  • I. 서론: DynamoLLM은 성능 SLO를 충족하면서 energy-performance profile에서 energy-efficient 구성을 자동으로 동적으로 선택한다.이 framework는 workload properties와 여러 configuration knob를 활용해 inference energy consumption을 줄인다.
  • I. 서론: DynamoLLM은 요청 유형별로 다르게 구성된 instance pool을 유지하고 request distribution이 변하면 이를 동적으로 확장하거나 축소한다.입력 및 출력 token 수가 적은 요청은 더 낮은 frequency에서 더 적은 GPU를 사용할 수 있지만, input-heavy 요청은 frequency에 더 민감하다.
  • I. 서론: Hierarchical controller structure는 더 낮은 복잡도와 더 적은 centralized bottleneck으로 configuration knob를 관리하며, transition technique은 reconfiguration overhead를 줄이거나 숨긴다.Controller는 upper-level constraint 아래에서 동작하고 추가 constraint를 하위로 전달해 resource management를 조정한다.
  • I. 서론: Latency SLO를 충족하면서 53% energy, 38% operational carbon emissions, 61% customer cost reduction을 달성했다.평가는 주요 cloud provider의 production-level trace를 실행하는 대규모 GPU cluster에서 수행했다.

II. 배경 · III. 에너지 효율 향상의 기회 · A. 이질적인 에너지-성능 프로파일

LLM inference는 서로 구별되는 prefill 및 decode 단계로 구성되며, 요청 길이, 부하, 모델, 서비스 SLO에 따라 이질적인 에너지-성능 프로파일을 만든다. DynamoLLM은 이러한 이질성을 활용해 요청별·워크로드 적응형 configuration을 선택하고, 알려지지 않은 output length를 예측한다.

  • II. 배경: Prefill은 input token을 병렬로 처리하는 반면, decode는 output token을 순차적으로 생성하므로 inference 성능과 에너지에 영향을 미치는 서로 다른 compute 동작이 나타난다.Prefill은 input-token 수에 따라 확장되는 반면, decode는 output token을 순차적으로 생성한다. Tensor parallelism은 GPU 간 communication을 집계하며, 2, 4, 8 GPUs에 대해 고려된다.
  • A. 이질적인 에너지-성능 프로파일: 짧은·중간·긴 input/output length를 포괄하는 요청 유형은 서로 다른 TTFT/TBT 요구사항과 에너지-성능 특성을 보인다.이러한 이질성을 포착하기 위해 요청을 SS, MM, LL을 포함한 9개의 input/output-length bucket으로 분류한다.
  • A. 이질적인 에너지-성능 프로파일: 에너지가 가장 적게 드는 configuration은 SS 요청에서 1.2 GHz의 TP2인 반면, LL 요청은 TP8을 필요로 하며 1.6 GHz에서 에너지를 최소화한다.가장 낮은 전력의 feasible configuration이 항상 에너지 최적은 아니다. 실행 시간이 길어지면 총 에너지가 증가할 수 있기 때문이다. 모든 요청을 결합하면 가장 제약이 큰 SLO를 따르게 된다.
  • A. 이질적인 에너지-성능 프로파일: 에너지 효율적인 요청 라우팅을 위해서는 input/output length별로 요청을 분리하고 서로 다른 server configuration을 할당해야 하지만, output length는 도착 시점에 알려지지 않으므로 예측해야 한다.DynamoLLM은 기존 output-length prediction 방법,, 에 의존하며, 간헐적인 misprediction을 완화하는 메커니즘을 포함한다.
  • A. 이질적인 에너지-성능 프로파일: 650 TPS의 낮은 부하에서는 1.2 GHz의 TP4가 에너지가 가장 적게 드는 configuration인 반면, 4K TPS의 높은 부하에서는 2 GHz의 TP4 또는 TP8이 필요하다.낮은 부하는 저주파 동작을 위한 SLO 여유를 제공하는 반면, 높은 부하는 여유를 줄이고 더 높은 주파수의 configuration을 요구한다.
  • A. 이질적인 에너지-성능 프로파일: Compute-bound 대형 모델은 frequency와 parallelism에 더 민감해 높은 에너지 모드를 요구하는 경우가 많은 반면, sparse 소형 모델은 성능이 낮은 configuration을 허용한다.따라서 요청된 모델은 해당 모델의 에너지 프로파일과 feasible operating point에 직접 영향을 미친다.

B. 동적 LLM 추론 워크로드

LLM 추론 워크로드는 요청 구성과 시간에 따른 부하가 크게 달라 정적인 에너지 최적 구성도 빠르게 비최적 상태가 된다. 따라서 효과적인 에너지 관리를 위해서는 tuning 정밀도와 fragmentation 사이의 균형을 유지하면서 요청 유형별 resource pool을 동적으로 조정해야 한다.

  • 변화하는 요청 길이 분포: Coding과 Conversation은 요청 길이 분포가 다르며, Conversation은 일반적으로 Coding보다 출력이 더 길고 입력이 더 짧다.두 서비스 모두 각 요청 유형을 상당한 비율로 포함하며, 요청 유형별 인기도 시간에 따라 변한다.
  • 구성의 시사점: 요청 유형마다 에너지 최적 구성이 다르므로, 현재 요청 분포에 맞춰 조정되는 개별 configured pool로 resource를 나눠야 한다.요청을 너무 적은 수의 class로 분류하면 에너지 fine-tuning이 제한되고, class가 너무 많으면 fragmentation이 발생해 효율이 저하될 수 있다.
  • 워크로드 부하 변동: Conversation은 평균 부하의 1.7×, valley 부하의 3.3×까지 증가하는 반면, Coding은 각각 2.8×와 34.6×까지 증가해 에너지 절약 운용을 위한 여유를 만든다.서버는 부하가 낮은 동안에는 성능이 낮더라도 에너지에 최적화된 구성을 사용하고, SLO를 유지하면서 부하가 증가하면 더 높은 성능 모드로 전환할 수 있다.
  • 핵심 통찰: 고도로 동적인 워크로드에서는 에너지 최적 구성이 빠르게 비최적 구성이 될 수 있으므로, 자동으로 사용자에게 드러나지 않게 구성을 선택해야 한다.구성 search space가 넓어 수동 또는 정적 선택은 실용적이지 않다.

C. 재구성 오버헤드

LLM workload가 변하면 DynamoLLM은 구성 간을 신속하게 전환해야 하지만, instance 수, model parallelism, GPU frequency를 재구성하는 데 오버헤드가 발생한다. GPU-frequency 조정만으로도 inference-step latency가 크게 증가할 수 있다.

  • C. 재구성 오버헤드: Workload adaptation에는 inference server instance 수, model parallelism, GPU frequency의 재구성이 필요하다.이 framework는 빠르게 변하는 LLM inference workload를 포착하기 위해 구성 간을 신속하게 전환해야 한다.
  • C. 재구성 오버헤드: GPU-frequency 조정에는 약 50–80 ms가 걸리는 반면, LLM decode iteration 하나에는 20–30 ms가 걸린다.따라서 조정 오버헤드는 inference performance에 상당한 영향을 줄 수 있다.
  • C. 재구성 오버헤드: 각 inference iteration마다 GPU frequency를 reset하면 개별 inference step의 latency가 잠재적으로 double될 수 있다.Figure 3은 일정한 1980 MHz frequency와 background에서 1980 MHz로 frequency를 reset하는 경우의 throughput을 비교한다.

IV. DYNAMOLLM: LLM 추론 클러스터를 위한 에너지 관리 프레임워크

DynamoLLM은 성능 SLO를 충족하면서 기존 추론 플랫폼과 통합되는 LLM 추론 환경용 에너지 관리 프레임워크다. 에너지 소비를 줄이기 위해 pool, model instance, parallelization, request scheduling, GPU frequency를 동적으로 관리한다.

  • DynamoLLM은 LLM 추론 환경을 위한 최초의 에너지 관리 프레임워크로, 성능 SLO를 충족하면서 기존 추론 플랫폼과 통합되어 workload를 에너지 효율적이고 비용 효율적으로 운영한다.
  • DynamoLLM은 cluster resource를 request type별 pool로 나누고 controller hierarchy를 사용한다.
  • Pool Manager는 pool 수와 model instance 수를 동적으로 조정하고, pool별 에너지 소비를 낮추도록 request를 scheduling하며, instance를 더 에너지 효율적인 parallelization으로 re-sharding한다.
  • Instance Manager는 inference engine으로 request를 scheduling하고 필요할 때 각 instance의 GPU frequency를 조정한다.

A. 에너지 효율을 위한 인스턴스 구성

DynamoLLM은 요청 길이, model parallelism, GPU frequency에 따라 배포된 각 model의 profile을 생성한 뒤, resource·load·performance 제약을 만족하면서 energy를 최소화하는 configuration을 선택한다. exact solver는 optimality를 보장하지만 약 100s of milliseconds의 overhead가 발생하므로, 세밀한 의사결정을 위해 hierarchical approximation이 필요하다.

  • LLM profile 생성: 시스템은 다양한 요청 길이, tensor parallelism TP2, TP4, and TP8, 그리고 200MHz 간격의 800–1980MHz GPU frequency를 사용해 model의 profile을 생성한다.최대 throughput까지 여러 load level을 profiling하고, 그 결과로 얻은 energy-performance profile을 extrapolate한다.
  • LLM profile 생성: Profile은 여러 service에서 reused across services할 수 있고 local에 cache할 수 있어, 여러 service가 하나의 model을 공유할 때 반복적인 profiling overhead를 줄인다.DynamoLLM은 profile을 global repository에 저장하고, service deployment 시 cluster-local storage에 cache한다.
  • 에너지 최적화 configuration 선택: DynamoLLM은 GPU-budget, load-assignment, performance-SLO 제약을 만족하면서 total energy를 최소화해 energy-optimal configuration을 선택한다.Solver는 total GPU 수를 N으로 제한하고, expected load L을 여러 instance에 분배하며, aggregate expected performance가 SLO를 충족하도록 요구한다.
  • 에너지 최적화 configuration 선택: Exact optimization은 energy optimality를 보장하지만 약 100s of milliseconds의 solver overhead가 발생해, 몇 초마다 configuration을 결정하는 것이 불가능하다.따라서 DynamoLLM은 computation complexity를 낮추기 위해 hierarchical subtask와 approximation heuristic을 도입한다.

B. 동적 부하를 위한 계층적 제어 · C. 원활한 재구성을 위한 오버헤드 감소

DynamoLLM은 서로 다른 시간척도에서 동작하는 계층적 로컬 최적화 controller를 사용해 재구성 비용과 downtime을 고려하면서 cluster resource를 조정한다. cached model weights, 효율적인 re-sharding, 전환 중 지속적인 service, 더 빠른 GPU-frequency 변경을 통해 reconfiguration overhead를 줄인다.

  • B. 동적 부하를 위한 계층적 제어: DynamoLLM은 계층적 controller에 걸쳐 최적화를 분해하고, 서로 다른 시간척도에서 동작하면서 상위 수준 제약하에 각 knob에 locally optimal value를 할당한다.이를 통해 configuration space를 전역적으로 탐색하는 것을 피하며, 하위 controller가 highest-performance configuration을 사용한다고 가정한다.
  • B. 동적 부하를 위한 계층적 제어: 각 epoch마다 cluster manager는 각 request type의 load를 예측하고 peak를 지원하는 데 필요한 highest-performance instance의 minimal number를 선택한다.작업을 더 적은 node에 통합하면 lightly loaded GPU에서 user cost와 idle energy가 감소한다.
  • B. 동적 부하를 위한 계층적 제어: DynamoLLM은 한 pool에 instance를 하나 적게 할당하고 남은 load를 다음으로 큰 request-type pool로 전달해 fragmentation을 완화한다.이를 통해 pool 전반에 누적된 overprovisioning이 energy efficiency를 낮추는 것을 방지한다.
  • B. 동적 부하를 위한 계층적 제어: controller는 scale, sharding 또는 frequency를 변경하기 전에 Overhead Table을 사용해 energy savings와 reconfiguration costs 및 downtime을 비교한다.reconfiguration은 instance에 걸쳐 단계적으로 수행되며, 다른 instance가 workload를 계속 처리하는 동안 potential energy savings가 더 큰 instance를 우선한다.
  • C. 원활한 재구성을 위한 오버헤드 감소: DynamoLLM은 cluster 내부에 model weights를 locally caching하고 추가적인 instance-creation strategy를 적용해 server scale-in/out overhead를 줄인다.제공된 passage는 이러한 strategy를 소개하지만 전체 목록은 제시하지 않는다.
  • C. 원활한 재구성을 위한 오버헤드 감소: Re-sharding parallelism은 target layout에 필요한 weights만 전송한다. TP4→TP2는 parallel transfer가 model weights의 1/4을 이동하므로 around 100ms가 걸린다.transfer overhead는 model의 1/8을 이동하는 데 걸리는 시간을 T로 정의하며, 명시된 setup에서 T = 50ms이다.
  • C. 원활한 재구성을 위한 오버헤드 감소: TP4→TP8 전환 중에는 old instance가 weights를 전송하는 동안 throughput을 preserve할 수 있지만, TP8→TP4 전환에는 lower throughput으로 동작해야 한다.DynamoLLM은 new instance가 synchronize하는 동안에도 old instance가 request를 처리하도록 해 synchronization 중 downtime을 방지한다.
  • C. 원활한 재구성을 위한 오버헤드 감소: GPU-frequency 변경은 nvidia-smi를 memory에 loaded 상태로 유지하고 controller를 privileged mode에서 실행해 OS-user interaction overhead를 피함으로써 가속된다.이러한 기법은 rapid frequency adjustment를 지원한다.

D. 요청 이질성을 고려한 예측적 스케줄링

DynamoLLM은 각 요청의 출력 길이를 예측해 이질적인 instance pool 간에 요청을 라우팅하며, 긴급 처리는 deadline을 고려한 queue 재정렬에서 GPU 주파수 증가, 요청 재조정, 기한 초과 요청 제거로 단계적으로 강화된다.

  • 요청 이질성 매핑: 출력 길이 예측은 요청을 short, medium, long으로 분류하고, 예측된 출력 길이와 알려진 입력 길이를 사용해 해당 instance pool로 라우팅한다.예측기는 proxy model로 작동하며, cluster manager는 각 요청 유형을 담당하는 pool manager로 요청을 전달한다.
  • 긴급 처리: 도착량이 처리량을 초과해 queue가 늘어나면, instance manager는 더 강한 긴급 조치를 적용하기 전에 deadline이 임박한 요청을 우선 처리한다.이 단계적 강화는 queue에 있는 요청을 재정렬하는 것에서 시작하고, deadline이 여전히 위험하면 GPU 주파수를 높인다.
  • 긴급 처리: backlog가 지속되면 시스템은 시작되지 않은 요청을 pool 내 다른 instance로 재조정하고, 결국 threshold를 초과해 대기 중인 요청을 제거해 사용자에게 재시도를 요청한다.이러한 조치는 queue 재정렬과 최대 GPU 주파수 증가만으로는 충분하지 않은 경우에만 단계적으로 적용된다.

E. DynamoLLM 구현 · V. 평가 · A. 평가 설정

DynamoLLM은 LLM inference platform에 통합되는 modular lightweight control system으로 구현되며, 여러 baseline과 configuration에 걸친 production-level workload에서 평가된다.

  • E. DynamoLLM 구현: DynamoLLM은 vLLM 을 기반으로 구축되지만 수정 없이 TensorRT-LLM 과 통합할 수 있다.이는 구현의 platform-level modularity를 보여준다.
  • E. DynamoLLM 구현: Lightweight gRPC controller가 memory와 compute requirement를 낮게 유지하면서 management를 조정한다.Cluster manager와 pool manager는 전용 VM에서 실행되며, instance manager는 communication overhead를 줄이기 위해 inference engine과 co-locate된다.
  • A. 평가 설정: 실험에는 8 H100 GPUs 가 장착된 server를 사용하고 Llama2-70B [67] 결과를 보고하며, Mixtral, Falcon, BLOOM [59]에서도 동일한 trend가 나타난다.따라서 보고된 평가는 Llama2-70B를 중심으로 하되 추가 model family도 정성적으로 다룬다.
  • A. 평가 설정: Workload는 1-hour open-source trace 와 fleet에서 수집한 1-day 및 1-week Coding 및 Conversation trace로 구성된 production-level trace를 사용한다.이 trace는 평가를 위해 open-source와 fleet-derived workload duration을 모두 제공한다.
  • A. 평가 설정: DynamoLLM은 다섯 개 system과 비교되며, 여기에는 request를 공통 TP8 instance pool로 라우팅하는 state-of-practice baseline인 SinglePool이 포함된다.제시된 설정에서 SinglePool은 8개 GPU에 tensor parallelism을 사용하는 baseline으로 설명된다.
  • A. 평가 설정: 평가는 1-hour open-source production trace [50]에서 Llama2-70B [67]를 실행하는 system의 latency와 power를 요약한다.Figure 7은 latency summary를, Figure 8은 동일한 workload와 model의 power summary를 보고한다.
  • A. 평가 설정: 현재 workload demand에 configuration을 맞추기 위해 instance count, model parallelism, GPU frequency를 변경한다.이 control은 각각 pool instance scaling, parallelism 조정, GPU frequency 변경에 해당한다.

B. 클러스터 수준 실험 · C. 민감도 연구

클러스터 수준 실험은 production trace에서 고정 자원 baseline과 비교해 DynamoLLM을 평가하며, 부하에 맞춰 자원을 조정하면서 전력 소비를 줄임을 보인다. 민감도 연구는 중간 정도의 예측 오류가 발생해도 DynamoLLM이 오예측을 감지하고 제어를 재구성하므로 에너지와 성능에 미치는 영향이 제한적임을 확인한다.

  • B. 클러스터 수준 실험: DynamoLLM은 현재 부하에 따라 GPU 서버 수를 조정하는 반면, baseline은 1시간 동안의 Conversation-service production trace에서 peak demand에 대비해 H100 서버 12대를 provision한다.
  • B. 클러스터 수준 실험: MultiPool은 SinglePool보다 에너지 소비가 20% 증가한다. 항상 더 많은 자원을 할당해 가동하기 때문이다.
  • B. 클러스터 수준 실험: DynamoLLM은 production trace에서 Llama2-70B를 serving하는 동안 TP2, TP4, TP8 sharding configuration 전반에 걸쳐 시간에 따라 GPU frequency와 GPU 수를 변화시킨다.
  • B. 클러스터 수준 실험: DynamoLLM은 energy-efficient operating mode를 통해 baseline 대비 P50 전력 소비를 43%, P99 전력 소비를 9% 낮춘다.
  • B. 클러스터 수준 실험: MultiPool은 SinglePool 대비 P99 TTFT와 TBT latency를 각각 5.3%와 11.1% 낮추지만, P50 TTFT와 TBT latency는 각각 11.4%와 7.6% 높인다.
  • C. 민감도 연구: Sensitivity analysis는 medium load에서 bounded output-length misclassification error를 도입해 prediction-model accuracy가 system efficiency에 미치는 영향을 평가한다.
  • C. 민감도 연구: Llama2-70B model에 대해 서로 다른 load level에서도 에너지를 평가한다.
  • C. 민감도 연구: 오류가 없는 경우와 비교하면 prediction error가 40%일 때 에너지 소비가 13% 높아지고 TTFT가 7.3% 높아진다. 이는 에너지와 성능에 미치는 영향이 크지 않음을 나타낸다.DynamoLLM은 오예측을 신속하게 감지하고 control knob를 재구성하므로 강건성을 보인다.

D. 장기 클러스터 수준 실험 · E. 대규모 시뮬레이션 · F. 비용 및 탄소 배출

장기 실험과 대규모 시뮬레이션에서 DynamoLLM은 피크 및 저이용률 조건과 Conversation 및 Coding 서비스 모두에서 에너지 소비를 줄인다. 이러한 에너지 절감은 GPU 비용, 에너지 비용, 운영 탄소 비용도 낮춘다.

  • D. 장기 클러스터 수준 실험: 장기 클러스터 실험은 일반적인 근무일 동안 일부 서비스 인스턴스의 모든 호출을 포함하는 하루치 Conversation trace를 사용한다.실험은 11대의 H100 서버에서 24시간 동안 실행된다.
  • D. 장기 클러스터 수준 실험: 11대의 H100 서버에서 24시간 동안 수행한 Conversation 서비스 실험에서 DynamoLLM은 피크 시간대와 저이용률 기간에 SinglePool 대비 에너지를 줄인다.실험에서는 부하에 따라 인스턴스 수를 조정하는 반면, SinglePool은 고정된 pool configuration을 사용한다.
  • E. 대규모 시뮬레이션: DynamoLLM은 일주일간의 production trace를 사용한 시뮬레이션에서 Conversation 및 Coding 서비스 모두의 정규화 에너지 소비를 크게 줄인다.시뮬레이터는 일주일치 trace로 5개 시스템을 평가하며, 입력이 일반적으로 더 짧기 때문에 DynamoLLM은 Conversation에서 더 에너지 효율적인 모드로 동작한다.
  • E. 대규모 시뮬레이션: 대규모 연구는 production trace에서 서로 다른 시스템의 에너지 소비를 모델링하기 위해 discrete-time simulator를 사용한다.Figure 14는 일주일간의 Conversation 및 Coding trace에 대한 정규화 에너지 소비를 보고한다.
  • F. 비용 및 탄소 배출: 38.5% 비용 절감: DynamoLLM은 일주일간의 실험에서 평균 GPU 서버 수를 40대에서 24.6대로 줄여, 현재 GPU VM 가격 기준으로 시간당 $1362.7를 절감한다.DynamoLLM은 에너지 효율을 최적화하면서 GPU 수를 최소화한다.
  • F. 비용 및 탄소 배출: 56%: DynamoLLM은 에너지 비용을 최대 이만큼 줄이며, 에너지 비용이 GPU 비용보다 상당히 낮기 때문에 시간당 $4.4의 절감으로 이어진다.
  • F. 비용 및 탄소 배출: DynamoLLM은 여러 grid의 일주일간 carbon-intensity trace를 시간에 따른 에너지 소비량에 매핑하여 SinglePool과 운영 배출량을 비교한다.비교에는 Conversation trace와 CAISO grid가 포함된다.

VI. 관련 연구 · VII. 결론

기존 연구는 sharing, allocation, hardware reconfiguration, power management, 효율적인 LLM-serving 기법을 통해 SLO 제약 자원 효율을 개선한다. DynamoLLM은 성능 보장하에 에너지 최적 LLM inference-cluster 구성을 대상으로 하며, 에너지, 탄소 배출량, 고객 비용을 줄인다.

  • VI. 관련 연구: 기존 연구는 resource sharing,,, dynamic allocation, hardware reconfiguration 을 통해 latency-sensitive workload의 SLO 제약 효율을 개선한다.
  • VI. 관련 연구: 다른 연구들은 workload characteristics, 를 활용해 안전한 power management와 oversubscription,, 을 가능하게 한다.
  • VI. 관련 연구: 최근 LLM-serving work는 heterogeneous resources, platforms, memory와 key-value caches,, node- 또는 cluster-level scheduling,,,,,, 을 다룬다.
  • VI. 관련 연구: throughput 또는 latency에 초점을 둔 연구들과 달리, DynamoLLM은 LLM-inference energy optimization에 distinct한 performance, energy-consumption, overhead trade-offs가 있음을 보인다.
  • VII. 결론: DynamoLLM은 performance guarantees하에서 동작하면서 energy를 53%, carbon emissions를 38%, customer cost를 61% 줄인다.DynamoLLM은 instance count, model parallelism, GPU frequency를 포함한 cluster organization을 자동으로 동적으로 구성한다.
  • VII. 결론: DynamoLLM은 inference compute properties의 heterogeneity와 inference workloads의 fluctuations를 활용해 energy를 절감한다.
  • VII. 결론: 이 framework는 instance count, model parallelism, GPU frequency를 사용해 energy-optimal cluster organization을 자동으로 선택한다.
Loading 2408.00741v1…