GPU 관리: 유휴 GPU가 새로운 지상 항공기인 이유

항공 산업은 이 점을 힘든 경험을 통해 배웠습니다. 업계 역사 대부분 동안, 어떤 항공사가 생존할지 예측하는 가장 좋은 수치는 비행기가 하루 중 얼마나 많은 시간을 지상에 보내는지였습니다.

그 이유는 구조적입니다. 항공기의 비용은 달력 시간(calendar hour) 단위로 발생합니다: 자금 조달, 감가상각, 선체 보험, 예정된 유지보수, 승무원 계약 등. 반면 수익은 비행 시간(flight hour) 단위로만 발생합니다. 지상에 보내는 매시간은 그 방정식의 산출 측면을 줄이는 반면, 비용 측면은 이전과 똑같이 계속 실행됩니다. 또한 활용률(Utilization)은 항공사가 하는 거의 모든 것의 하류에 위치합니다. 주기장 관리(Turnaround discipline), 네트워크 설계, 유지보수 계획, 승무원 로스터링, 예비 부품 가용성 등 모든 것이 결국 그 하나의 수치에 반영되는데, 이는 근본적인 운영상의 문제가 비행기를 지상에 머물게 하기 때문입니다.

더 큰 규모의 기단을 보유하는 것도 여전히 도움이 됩니다. 더 많은 항공기는 더 많은 가용 용량을 의미하기 때문입니다. 하지만 비슷한 규모의 기단과 유사한 노선을 운항하는 두 항공사는 매우 다른 경제성을 갖게 될 수 있으며, 이 격차 대부분은 기단 크기보다는 하나의 측정치에 기인합니다.

엔터프라이즈 AI 역시 다른 종류의 하드웨어에서 동일한 구조에 직면하고 있습니다. GPU는 사용 여부와 관계없이 금융 비용, 감가상각비, 전력 및 냉각 비용을 통해 달력 시간 단위로 비용이 발생합니다. 그 출력은 오직 컴퓨팅 시간(compute hour)으로만 발생합니다. 더 많은 GPU를 확보하는 것은 항공사에 더 큰 기단을 갖는 것과 비슷한 방식으로 도움이 됩니다. 즉, 실제 용량(real capacity)이라는 진정한 우위를 제공하지만, 여전히 누가 이길지 결정하는 실제 결과에 대한 보장은 없습니다. 유사한 GPU 예산을 가진 두 회사는 어느 한쪽이 얼마나 많은 하드웨어를 소유했는지보다는, 주어진 순간에 그 하드웨어의 얼마나 많은 부분이 유용하게 사용되고 있는지에 따라 점차 벌어지고 있습니다. 이러한 비율은 항공사의 가동률(utilization rate)과 같으며, 기업이 내리는 거의 모든 다른 인프라 결정의 다운스트림에 위치합니다. 지능(Intelligence)이 업계를 여기까지 이끌었습니다. 이제 다음 실제 제약 조건이 형성되는 곳은 바로 '활용도(Utilization)'입니다.

AI가 확장되면서 희소성(scarcity)은 사라지지 않았습니다. 단지 사슬의 더 높은 단계로 이동하여, 완전히 다른 자원에 자리 잡았습니다.

엔터프라이즈 AI의 첫 번째 물결은 모델 품질에서 승패가 갈렸습니다. 더 많은 컴퓨팅으로 훈련된 더 큰 모델들이 더 까다로운 벤치마크를 통해 평가받았고: 파라미터 수와 리더보드 순위가 대화를 지배했으며, 이 경쟁을 통해 실제 엔터프라이즈 워크로드를 실행하기에 충분히 좋은 모델들이 탄생했습니다. 하지만 그 역량은 의존성(dependency)과 함께 옵니다. 프로덕션 AI는 특수화된 하드웨어에서 실행되며, 오늘날 그 하드웨어는 거의 전적으로 GPU입니다.

GPU는 고가이며 공급이 제한적이고 수요는 가용량을 훨씬 초과하여, 시장의 최고 수준에서도 마찬가지입니다. 2020년 Microsoft는 OpenAI를 위해 전용 슈퍼컴퓨터를 구축했는데, 당시 세계 5대 시스템 중 하나로 보고된 10,000개 이상의 GPU와 285,000개의 CPU 코어로 구성되어 GPT-3를 학습시키는 데 사용되었습니다. 당시에는 거의 상상할 수 없는 수준의 하드웨어 집중도를 보여주었으며, 컴퓨팅 자원이 접근 가능한 사람에게는 해결된 문제처럼 보이게 만들 정도였습니다. 6년이 지난 지금, 그 숫자는 천장이기보다는 시작점에 가깝습니다. 2026년까지도 지구상의 가장 자본력이 좋은 연구소들은 컴퓨팅 자원 접근성을 확정된 제약 조건이 아닌 살아있는 전략적 제약 조건으로 취급하고 있습니다. Anthropic만 해도 Amazon, Google, Microsoft, AMD라는 네 개의 별도 하드웨어 플랫폼에 걸쳐 수 기가와트(multi-gigawatt) 규모의 동시 약정을 진행했으며, Meta 역시 이에 필적하는 자체적인 다중 기가와트 규모의 계약을 체결했습니다. 한 번에 네 개 벤더에 걸쳐 약정 규모를 분산시키는 것이 바로 구매자가 사실상 무한한 자본을 가지고 있음에도 불구하고 어떤 단일 출처에서도 충분히 얻지 못할 때의 컴퓨팅 부족 현상을 보여줍니다.

6년 간격으로 발생한 이 두 사건 모두 연구소가 경쟁력을 유지하기 위해 필요했던 최전선을 표시했습니다. 그 사이에 바뀐 것은 AI가 더 능력이 생겼기 때문이라기보다는, 능력 자체가 더 이상 결속적인 제약 조건이 아니게 되었기 때문입니다.

이러한 패턴은 연구소 이후의 영역에서도 다른 형태로 나타납니다. API를 통해 이러한 모델을 사용하는 기업들은 하드웨어 문제보다는 가격 책정 문제를 더 많이 겪습니다. 비용은 사용 토큰에 비례하여 증가하며, 이 단 하나의 사실만으로 개념 증명(PoC)의 경제성과 실제 생산 환경의 경제성을 거의 완전히 분리시킵니다. 한 달에 몇천 건의 요청을 처리하는 PoC는 저렴해 보입니다. 하지만 동일한 워크로드를 생산 규모로 확장하면 결코 끝나지 않는 비용 라인으로 변할 수 있습니다. 우위를 점하고 있는 대안은 간단합니다. 기업들이 자체 GPU를 확보하여 모델을 로컬에서 실행함으로써, 가변적이고 선형적으로 증가하는 비용을 고정된 자본 지출로 교환하는 것입니다.

dharma_fig1_cost_curve (1)

API 비용은 사용량에 따라 상승하지만, 소유 인프라는 거의 고정 상태를 유지합니다. 손익분기점을 넘어서면 이 트레이드가 역전됩니다.

이러한 변화는 GPU를 단순한 품목(line item)이 아니라 인프라로 만듭니다. 성장에 맞춰 크기가 결정되고, 수요 피크에 맞춰 크기가 결정되며, 따라서 특정 주간이 실제로 필요로 하는 양보다 더 크게 크기가 결정됩니다. 이는 구매가 문제를 해결하지 못하고 새로운 문제를 열어젖힌다는 것을 의미합니다. 클러스터가 가동되는 날, 질문은 우리가 가속기를 확보할 수 있는가에서 우리를 바쁘게 유지할 수 있는가로 바뀌고, 오직 전자에만 조달팀이 배정되어 있었습니다. 하드웨어에 서명하는 것은 마감일과 소유자가 있는 부분입니다. 그것을 공중에 띄워 유지하는 것이 그 거래를 체결할 가치가 있었는지 조용히 결정하는 부분입니다.

이러한 계약들은 효율성이 아닌 용량(capacity) 약정을 설명합니다. 이 용량이 얼마나 잘 사용되는지는 별개의 질문이며, 다른 사람들에게 속해 있고, 훨씬 덜 엄격하게 측정되며, 해결되기까지는 상당히 먼 문제입니다.

바쁜 GPU로 가득 찬 클러스터도 잠재력의 대부분을 낭비할 수 있으며, 그 이유는 거의 항상 같습니다. GPU는 밤낮없이 지속적으로 작동하지만, 이들에 대한 수요는 그렇지 않습니다. 인프라는 트레이닝(training) 실행, 배치 작업(batch jobs), 실시간 트래픽이 한꺼번에 몰리는 피크 시점에 맞춰 크기가 결정되어야 하므로, 그 피크 외의 시간에는 의미 있는 상당량의 용량이 할당되고 사용되지 않은 채 남아 있게 됩니다. 모든 GPU가 모든 종류의 작업을 동등하게 흡수할 수 있다면, 더 나은 예측만으로도 이 문제가 해결될 수 있습니다. 하지만 그렇게 할 수 있는 곳은 드물고, 이것이 문제의 더 어려운 부분입니다.

불일치는 한 단계 더 깊은 곳에서 시작됩니다.

엔터프라이즈 AI의 1세대에서는 GPU의 역할이 주로 단일했습니다. 즉, 추론(inference)을 실행하는 것이었습니다. 오늘날 같은 하드웨어는 트레이닝, 파인튜닝(fine-tuning), 양자화(quantization), 실시간 추론, 배치 추론, 임베딩 생성, 모델 평가 등 다양한 작업을 지원하며, 종종 동일한 조직의, 때로는 동일한 모델에 대한, 동일한 클러스터에서 수행됩니다. 이러한 각 워크로드(workloads)는 하드웨어로부터 서로 다른 것을 요구하며, 그 차이는 깊습니다. 실시간 추론은 거의 모든 것보다 낮은 지연 시간(low latency)을 필요로 하는데, 느린 응답은 실패한 것으로 간주되기 때문입니다. 배치 작업은 처리량(throughput)에 신경 쓰고 지연 시간을 허용하며, 때로는 몇 시간 동안 그러합니다. 트레이닝은 GPU를 몇 시간 또는 며칠 단위로 지속적으로 점유할 수 있습니다. 양자화는 많은 용량을 필요로 하지만 짧은 시간만 필요합니다. 이 중 하나에 맞춰 조정된 스케줄러(scheduler)는 나머지 세 가지를 거의 기본적으로 잘못 할당하게 됩니다. 실패가 항상 활용률 대시보드(utilization dashboard)에 나타나는 것도 아닙니다. 클러스터는 높은 평균 점유율을 보고할 수 있지만, 여러 대기 중인 작업들은 완전히 다른 무언가를 실행하느라 바쁜 GPU 자원을 기다리고 있을 수 있습니다.

정확한 워크로드 혼합 비율은 조직마다 다릅니다. 하지만 문제의 형태는 그렇지 않습니다. 여기서 항공기 비유가 한계에 부딪히는데, 이 한계 자체가 비교를 단순히 정당화하는 것 이상의 무언가를 가르쳐 줍니다. 유휴 상태인 항공기는 보통 보유한 모든 노선 중 어느 곳으로든 재배치될 수 있습니다. 시카고에 있는 737은 다allas 대신 denver로 이동해도 큰 페널티가 없습니다. 반면, 유휴 GPU는 자신이 실제로 지원할 수 있는 메모리, 지연 시간(latency), 지속 시간 프로파일을 가진 워크로드만을 흡수할 수 있습니다. 이 차이점 때문에 오케스트레이션(orchestration)은 함대 스케줄링(fleet scheduling)보다 더 어렵습니다. 그래서 질문의 초점이 GPU가 점유되어 있는지 여부에서, 어떤 워크로드를 어느 GPU에, 언제, 어떤 우선순위로 실행해야 하는지로 바뀝니다. GPU 랙을 추가로 구매하는 것은 용량과 비용을 늘릴 뿐이며, 불일치(mismatch)를 해결해 주지는 못합니다. 그리고 이 새로운 용량 역시 이미 설치된 용량만큼이나 잘못된 형태와 시점에 놓여 있을 수 있습니다.

GPU 투자수익률(ROI)을 극대화하는 것은 일회성 프로비저닝 결정만으로는 충분하지 않습니다. 이는 구매 시점뿐 아니라 매시간 지속적으로 인프라 자체를 능동적으로 관리할 것을 요구합니다. 이에 대한 대응으로 등장하고 있는 것이 바로 GPU 관리(GPU Management)라는 명확한 분야입니다. 이는 워크로드, 모델, 하드웨어 사이에 위치하는 오케스트레이션 계층입니다. 이 계층의 임무는 어떤 워크로드를 언제, 어떻게, 그리고 클러스터 내 어느 특정 GPU에서 실행할지 지속적으로 결정하는 것입니다. 이 모든 개념은 생소한 것이 아닙니다. 이는 좋은 운영팀(operations team)이 본능적으로 이미 하고 있는 일에 가깝지만, 단지 공식화되어 누군가 문제를 알아차릴 때까지 기다리는 대신 지속적으로 작동한다는 차이가 있을 뿐입니다.

dharma_fig2_gpu_orchestration_v2_radial

지능은 모델 경계에서 멈추지 않습니다. 이 오케스트레이션 계층은 모델 자체에는 가시성이 없는 실시간 할당 결정을 내리고 있습니다.

지능은 거의 전적으로 모델 내에 존재했습니다. 더 크고, 더 잘 훈련되었으며, 더 능력이 있었고, 그것이 대부분의 핵심이었습니다. 이제 지능은 인프라에도 존재해야 합니다. 즉, 여러 경쟁 워크로드 중 어떤 것이 방금 해제된 GPU를 언제, 그리고 다른 모든 대기열에 있는 것들과 비교하여 어느 정도 우선순위로 가져갈지 결정하는 계층(layer)에 존재하는 것입니다. GPU를 바쁘게 유지하는 것은 더 이상 목표가 아닙니다. 왜냐하면 낮은 우선순위의 작업을 실행함으로써 쉽게 '바쁜 상태'를 위장할 수 있기 때문입니다. 각 설치된 GPU에서 발생하는 수익을 극대화하는 것이 실제 목표가 되며, 이는 이전의 프로비저닝(provisioning) 문제보다 훨씬 더 지속적인 문제가 됩니다.

잘 된 프로비저닝이 이 문제를 완전히 없애지는 못하지만 그 형태를 바꿀 뿐입니다. 프로비저닝 결정은 구매 시점에 한 번 내려집니다. 반면 할당(allocation) 결정은 끊임없이 이루어집니다. 작업이 완료될 때마다, 새로운 요청이 도착할 때마다, 고객 서비스와 내부 훈련 실행 간의 우선순위가 바뀔 때마다 말입니다. 이러한 빈도가 이 결정이 개인이 사례별로 처리하던 것에서 자동으로 실행되어야 하는 것으로 이동했음을 설명해 줍니다. 어느 엔지니어도 새벽 세 시에 대시보드를 보며 완료된 훈련 실행이 GPU를 대기열의 배치 작업에 넘겨줘야 할지, 아니면 들어오는 고객 트래픽 급증을 위해 붙잡아 두어야 할지 결정하지 않습니다. 다른 무언가가 이 결정을 지속적으로 내리고, 아무도 확인할 필요가 없을 만큼 충분히 정확하게 수행해야 합니다.

이 분야는 아직 새롭기 때문에 도구와 관행(conventions)이 형성되는 중이며, 성숙한 GPU 관리(GPU Management) 방식이 어떤 모습인지에 대한 단일한 플레이북은 아직 등장하지 않았습니다. 다만 한 가지 확실해진 것은 제약 조건이 어디로 이동했는지입니다.

특화(Specialization)와 오케스트레이션(orchestration)은 동일한 문제의 서로 다른 절반을 해결합니다.

특화된(specialized), 더 작은 모델들은 특정 작업을 수행할 때, 동일한 작업을 위해 거대한 범용 모델이 필요로 하는 자원 비용의 일부만을 사용하면서도 해당 작업에 필요한 품질을 포기하지 않을 수 있습니다. 이는 활용률(utilization)에 직접적인 영향을 미칩니다. 한때 단일하고 큰 모델 하나를 요구하여 클러스터 용량의 상당 부분을 전체 작업 시간 동안 점유해야 했던 워크로드들이, 대신 더 작고 작업별 특화된 모델 위에서 실행될 수 있으며, 이 경우 차지하는 공간(footprint)도 그 일부에 불과합니다. 이전에 완전히 사용되던 용량이 갑자기 비게 됩니다.

특화가 얼마나 많은 용량을 확보해 주는지 여부는 워크로드와 모델마다 다르지만, 이렇게 확보된 용량은 어딘가로 가야 하거나 그렇지 않으면 그냥 남아있게 됩니다. 작은 특화 모델이 GPU 투자수익률(ROI)로 전환되려면, 누군가가 이 공간을 비움으로써 무엇이 다음으로 일어날지 적극적으로 결정하고, 다른 워크로드, 다른 모델, 또는 뒤에 대기하는 다른 큐에 재할당해야 합니다. 관리되지 않은 채 남겨진 용량은 승리(win)라기보다는 또 다른 종류의 유휴 상태가 됩니다. 이는 명백히 사용되지 않는 GPU와는 다른 방식으로 눈에 보이지 않지만, 생산성은 더 이상 아닙니다.

dharma_fig3_specialization_matrix

오케스트레이션(orchestration) 없는 특화는 아무도 회수하지 못하는 용량을 남깁니다. 특화가 없는 오케스트레이션은 회수할 가치가 적은 용량을 갖게 합니다. 어느 한쪽 레버만으로는 전체 작업을 수행할 수 없습니다.