유휴 Inference GPU Pool을 이용한 GPU Job 스케줄링

목차

• LLM 서비스에서 일반적인 오토스케일링이 잘 안 맞는 이유
• 유휴 inference GPU pool을 어떻게 발견하고 정의했는가
• GPU 작업 파이프라인은 어떤 구조로 설계했는가
• 운영 결과가 말해주는 것
• 실무에서 가져갈 수 있는 핵심 포인트
• 자주 묻는 질문

참고 링크: LG AI Research 원문

LLM 서비스에서 일반적인 오토스케일링이 잘 안 맞는 이유

GPU가 부족하다고 하면 흔히 “더 많이 사면 되지 않나?”라고 생각하기 쉽습니다. 그런데 실제 운영 현장에서는 그렇게 간단하지 않습니다. 특히 LLM 서비스는 요청 하나하나의 무게가 다르고, 입력 토큰 수나 생성 길이, 모델 구조에 따라 GPU 소비량이 크게 달라집니다. 같은 트래픽처럼 보여도 내부 자원 사용량은 전혀 같지 않은 경우가 많습니다.

그래서 CPU 사용률이나 메모리 사용률만 보고 오토스케일링을 걸면 자주 어긋납니다. GPU utilization이 순간적으로 치솟아도 그게 곧 전체 부하를 뜻하지는 않고, 메모리 역시 모델 로딩 시점에 이미 크게 차 있기 때문에 트래픽 변화가 선명하게 드러나지 않습니다. LLM 서비스에서는 “겉으로 보이는 지표”와 “실제 부하”가 어긋나기 쉽습니다.

이 사례가 흥미로운 이유는 바로 그 지점에 있습니다. 단순한 리소스 기준이 아니라, vLLM이 제공하는 내부 메트릭처럼 LLM 특성을 더 잘 반영하는 지표를 스케일링 기준으로 삼았다는 점입니다. 실시간 처리량과 큐 상태를 함께 보면서, 서비스가 실제로 얼마나 바쁜지 더 정확하게 읽어낸 것입니다.

유휴 inference GPU pool을 어떻게 발견하고 정의했는가

이 글의 출발점은 아주 현실적입니다. 서비스 트래픽이 많은 시간대에는 GPU를 넉넉히 확보해야 하고, 반대로 밤처럼 한산한 시간대에는 확보된 GPU 일부가 사실상 놀게 됩니다. 서비스 안정성을 위해 남겨 둔 여유분이지만, 장시간 비어 있는 상태라면 활용 관점에서는 아쉬움이 남습니다.

사례에서는 주간과 야간의 차이를 시계열로 확인한 뒤, 야간 비혼잡 시간대에 남는 GPU를 연구·실험 작업에 돌리는 구조를 만들었습니다. 여기서 중요한 점은 “서비스를 방해하지 않는 선”을 절대 넘지 않는 것입니다. 남는 자원을 쓰되, 서비스 트래픽이 올라오면 언제든 회수될 수 있어야 합니다.

예를 들어 한 레플리카가 GPU 4장을 쓰는 환경이라면, 하루 기준으로 상당 수의 GPU가 약 12시간가량 유휴 상태가 될 수 있습니다. 이런 유휴 시간을 그냥 흘려보내지 않고, 연구용 잡이나 실험 파이프라인으로 전환하는 것이 이 프로젝트의 핵심 아이디어입니다.

GPU 작업 파이프라인은 어떤 구조로 설계했는가

유휴 GPU를 잘 쓰려면 단순히 “빈 슬롯에 작업을 넣는 것”만으로는 부족합니다. 실행 방식이 다양한 연구 작업을 수용할 수 있어야 하고, 같은 작업을 반복 실행할 때도 결과를 추적할 수 있어야 합니다. 그래서 이 사례는 범용성, 확장성, 재현성을 동시에 만족하는 파이프라인을 지향했습니다.

• 모든 작업을 Docker 이미지 단위로 정의해 실행 환경의 차이를 줄였습니다.
• 작업은 스텝 단위로 나뉘어 순차 실행이나 병렬 실행이 가능하도록 구성했습니다.
• 데이터 경로, 모델 경로, 하이퍼파라미터, GPU 수량은 외부 입력으로 주입했습니다.
• 실행 결과는 Cloud storage에 남겨 상태를 분리하고, 파이프라인은 stateless하게 유지했습니다.

이 구조의 장점은 분명합니다. 새로운 모델이나 실험 방식이 들어와도 파이프라인 자체를 크게 바꾸지 않아도 됩니다. 필요한 것은 실행 가능한 이미지와 입력값뿐입니다. 덕분에 연구자는 실험에 집중할 수 있고, 인프라 팀은 자원 회수와 안전성을 더 쉽게 제어할 수 있습니다.

무엇보다 인상적인 부분은 Best-effort 방식입니다. 서비스 트래픽이 다시 올라오면 실행 중인 작업이 중단될 수 있다는 전제를 분명히 두고, 그 대신 놀고 있던 GPU를 최대한 활용하는 것입니다. 완벽한 보장보다 현실적인 효율을 택한 설계라고 볼 수 있습니다.

운영 결과가 말해주는 것

이런 구조가 실제로 의미가 있었는지는 결국 숫자가 말해줍니다. 사례에서는 3개월 동안 총 85개의 작업이 실행되었고, 모델 학습, 성능 평가, 데이터 생성 등 다양한 유형의 작업이 포함되었습니다. 누적 GPU 사용량은 95,000 GPU hours에 달했습니다.

또한 시간이 지날수록 활용량이 늘어났다는 점도 중요합니다. 초기에는 소규모로 시작했지만, 내부 확산과 안정화가 진행되면서 사용량이 빠르게 증가했습니다. 한 달 기준으로는 70% 가까운 증가세가 관측되었고, 이를 다시 GPU 장수 기준으로 환산하면 추가 장비를 새로 들인 것과 비슷한 효과를 냈다고 볼 수 있습니다.

비용 관점의 효과도 큽니다. 동일한 연산량을 퍼블릭 클라우드 장기 약정 비용 기준으로 비교했을 때, 한 달 단위로도 수천만 원 규모의 절감 효과가 계산되었고, 3개월 누적 기준으로는 훨씬 더 큰 가치가 만들어졌습니다. 결국 이 사례는 “빈 GPU를 어떻게 채울 것인가”가 단순한 최적화 문제가 아니라, 인프라 전략 자체가 될 수 있음을 보여줍니다.

실무에서 가져갈 수 있는 핵심 포인트

이 사례를 다른 조직에 그대로 복사할 수는 없지만, 배울 수 있는 원칙은 분명합니다.

• LLM 서비스는 일반적인 리소스 지표만으로 판단하면 놓치는 부분이 많습니다.
• 유휴 자원은 “남는 자원”이 아니라 “정책적으로 회수 가능한 자원”으로 봐야 합니다.
• 작업 파이프라인은 범용성보다 먼저 안전성과 추적 가능성을 갖춰야 합니다.
• Best-effort 설계는 불완전해 보여도, 실제 운영에서는 매우 강력한 선택이 될 수 있습니다.

한마디로 정리하면, 이 글은 GPU를 더 확보하는 이야기가 아니라 GPU를 더 똑똑하게 쓰는 이야기입니다. 인프라의 빈 시간을 기술적으로 회수할 수 있다면, 같은 자산으로도 훨씬 더 많은 일을 할 수 있습니다.

자주 묻는 질문

Q. 왜 LLM 서비스에서는 CPU나 메모리 기준 오토스케일링이 잘 맞지 않나요?

A. 요청마다 연산량이 크게 다르고, GPU 사용 패턴도 짧은 순간에 급변하기 때문입니다. 겉으로 보이는 수치만으로는 실제 부하를 정확히 읽기 어렵습니다.

Q. 유휴 inference GPU pool은 어떤 작업에 잘 맞나요?

A. 학습, 평가, 데이터 생성, 실험 반복 실행처럼 시간이 유동적이거나 중단 가능성을 어느 정도 감수할 수 있는 작업에 잘 맞습니다.

Q. 작업이 중간에 끊기면 데이터는 어떻게 되나요?

A. 이 사례처럼 Cloud storage 기반으로 결과를 관리하면, 스텝 단위의 상태를 분리할 수 있어 재시도와 추적이 훨씬 쉬워집니다.

Q. 이런 방식은 모든 AI 서비스에 적용할 수 있나요?

A. 아닙니다. 서비스 안정성과 회수 가능성을 전제로 설계할 수 있는 환경에서 특히 효과적입니다. 먼저 트래픽 패턴과 자원 여유를 정확히 측정하는 것이 중요합니다.

이 글이 마음에 드세요?

RSS 피드를 구독하세요!