로컬과 클라우드 LLM 추론을 언제 결합해야 할까요?

하이브리드가 순수 로컬 또는 순수 클라우드보다 나은 경우

결정적인 요인은 요청당 단순 비용이 아니라 수요의 변동성입니다. 트래픽이 일정하다면 — 매일 요청 수가 거의 같고 모델 크기도 거의 같다면 — 그 안정적인 부하에 맞춰 더 저렴한 단일 환경을 선택하고 거기서 멈추십시오. 하이브리드 구성은 수요가 실제로 크게 변동하여 피크에 맞춰 로컬을 구축하면 대부분의 시간 동안 유휴 상태가 되는 경우에만 이익이 됩니다.

두 번째 요인은 로컬 하드웨어가 처리할 수 있는 것보다 큰 모델이 가끔 필요한 경우입니다. 워크로드의 95%가 로컬 하드웨어에서 무리 없이 처리되지만 매주 소수의 요청만 훨씬 큰 모델을 필요로 한다면, 그 드문 경우를 감당할 만큼 충분한 로컬 하드웨어를 구입하는 것은 대체로 낭비입니다 — 해당 요청만 임대한 클라우드 GPU로 라우팅하는 것이 전체적으로 더 저렴합니다.

데이터 보관 위치 요구 사항도 비용과는 반대 방향으로 하이브리드를 정당화할 수 있습니다. 민감한 정보는 엄격히 로컬에 유지하고, 민감하지 않고 시간에 덜 민감한 워크로드만 클라우드로 라우팅하는 방식입니다. 이 경우 분할을 결정하는 것은 하드웨어 한계가 아니라 정책입니다.

라우팅 로직을 설계하는 방법

세 가지 라우팅 패턴이 실제 대부분의 구성을 다루며, 대략 복잡도가 증가하는 순서입니다.

• ▸**요청 크기 기반 라우팅:** 가장 단순한 패턴입니다. 들어오는 각 요청 — 필요한 모델 크기, 컨텍스트 길이, 또는 명시적 우선순위 플래그 — 를 확인하여 고정된 임계값을 초과하는 것은 클라우드로, 나머지는 로컬 하드웨어로 보냅니다. 이해하고 디버깅하기 쉽지만, 로컬 시스템이 현재 얼마나 바쁜지에는 적응하지 못합니다.
• ▸**큐 깊이 기반 확장:** 로컬 큐가 설정한 임계값을 초과해 쌓였을 때만 요청을 클라우드로 보냅니다. 요청마다 고정된 규칙을 따르는 대신 실제 부하에 적응하지만, 큐 상태를 추적하고 라우팅 결정을 내리기 위해 모니터링과 조금 더 많은 애플리케이션 로직이 필요합니다.
• ▸**로컬 우선, 클라우드 폴백:** 모든 요청을 먼저 로컬에서 시도하고, 타임아웃이나 명시적인 로컬 실패(예: 큰 요청에서의 메모리 부족)가 발생할 때만 클라우드로 폴백합니다. 기존의 순수 로컬 구성 위에 구현하기 쉽지만, 결국 폴백되는 요청은 먼저 로컬 시도의 실패를 기다려야 하므로 지연 시간이 추가됩니다.
• ▸세 가지 패턴 모두에서, 애플리케이션과 두 추론 백엔드 사이의 API 호환 계층이 라우팅 결정을 애플리케이션의 나머지 부분에는 보이지 않게 유지합니다 — 애플리케이션 코드는 단일 엔드포인트만 호출하고, 그 뒤에서 라우팅 로직이 실제로 어느 백엔드가 요청을 처리할지 결정합니다.
• ▸이 결정의 비용 측면 — 클라우드 GPU가 시간당 실제로 얼마나 드는지, 그리고 로컬 하드웨어의 상각 비용과 어떻게 비교되는지 — 에 대해서는 위의 임계값 결정에 활용할 수 있는 공급자별 구체적인 수치를 담은 클라우드 GPU 시간당 비용과 RunPod 대 Vast.ai 가격 비교를 참고하십시오.