모델을 실행할 때, 단 1분 만에 활성화되고 인스턴스를 선택할 필요가 없다는 이유로 Serverless를 선택합니다. 하지만 한 달이 지나 제품이 응답 시간(Response Time)에 의존하기 시작하면, 시작의 간편함 때문에 선택했던 모드가 부하 상황에서의 지연 시간(Latency)에 대해 아무것도 보장하지 않았다는 사실을 깨닫게 됩니다. 이것은 버그가 아닙니다. 해당 모드가 문서에 기술된 방식 그대로 작동하는 것입니다.

반론의 여지가 없도록 좁게 정의하자면, 지연 시간과 부하의 예측 가능성이 계산에 포함되지 않는다면 Serverless와 Dedicated 사이의 선택은 불완전합니다. "Serverless가 나쁘다"거나 "모두에게 Dedicated가 필요하다"는 뜻이 아닙니다. 단지 낮은 진입 장벽이 적절한 운영 모드와 동일한 것은 아니라는 의미입니다. Hugging Face의 모드들을 문서에 따라 분석하고, 이를 부하, 오류, 그리고 총 소유 비용(TCO)과 비교해 본 뒤, 마지막으로 Dedicated Inference를 고려해야 하는 경계선을 제시하겠습니다.

먼저 범위를 명확히 하겠습니다. 이것은 Hugging Face의 두 모드를 서로 비교하는 것이지, 자체 하드웨어에 모델을 로컬 호스팅하는 것과 비교하는 것이 아닙니다. 또한 특정 인프라에 대한 계산도 아닙니다. 저는 귀하의 제품에 대한 실제 지연 시간, 실제 부하, 최종 비용을 알지 못하며 알 수도 없습니다. 여기에 있는 모든 내용은 각 모드의 문서화된 조건과 이를 해석하는 시나리오 기반의 방식일 뿐입니다.

Hugging Face의 Serverless는 대체 어떻게 변했나

기존의 기사들을 무색하게 만드는 첫 번째 사실은, "Inference API (Serverless)\

따라서 만약 당신이 "hugging face inference api"를 구글링하다가 "시간당 수백 개의 요청"이라고 적힌 2024년 블로그 글을 발견한다면, 그 수치들은 현재 공식 문서에는 더 이상 존재하지 않는 모델을 설명하고 있는 것입니다. 이제는 크레딧 (credits)을 확인해야 합니다. 가격 문서에 따르면: 무료 계정은 매월 $0.10의 크레딧을 받고, PRO는 매월 $2.00, Team/Enterprise 조직은 사용자당 매월 $2.00를 받습니다. 크레딧을 다 쓰면, 요청을 계속 보내기 위해서는 종량제 (pay-as-you-go) 방식으로 추가 구매를 해야 합니다. HF의 제공 가격은 자체 마진 없이 그대로 전달됩니다.

두 번째 뉘앙스는 Serverless가 HF의 인프라 위에서 거대한 LLM을 "돌리고" 있다고 생각하는 사람들에게 더 중요합니다. 2025년 7월 문서의 자체 메모에 따르면, hf-inference 제공자 (바로 그 레거시 (legacy) Serverless 백엔드)는 "주로 CPU 추론 (CPU-inference)"에 집중하고 있습니다: 임베딩 (embeddings), 텍스트 랭킹 (ranking), 분류 (classification), 그리고 BERT나 GPT-2와 같은 소규모 및 레거시 모델들이 이에 해당합니다. 즉, Serverless를 통한 최신 대규모 LLM 서비스는 사실상 Hugging Face 자체의 Serverless 컴퓨팅에서 계산되는 것이 아니라, 외부 GPU 제공 파트너사로 넘어가 있습니다. 당신은 프록시 (proxy)를 통해 타사의 컴퓨팅 파워에 비용을 지불하는 것이며, 지연 시간 (latency) 프로필은 HF가 아닌 파트너사가 결정하게 됩니다.

Hugging Face 스스로도 그 목적을 명확하게 규정하고 있습니다. 문서에서 Serverless는 "공용 리소스 (shared resources)"에서 작동하는 "모델 연구 및 평가를 위한 솔루션"입니다. 이는 지연 시간이 보장되는 프로덕션 (production) 계층이 아니며, HF 또한 이를 그렇게 포지셔닝하지 않습니다. 이 점을 명심하세요: 논점은 누가 더 빠른가가 아니라, 해당 모드가 어떤 운영상의 약속을 제공하느냐에 있습니다.

따라서 어떤 선택을 하기 전에 수행할 수 있는 간단한 작업 단계가 있습니다. 예상되는 월간 요청량을 파악하고, 제공업체의 요율에 따른 호출당 평균 비용을 추산한 다음, 이를 계정의 월간 크레딧 한도와 비교해 보십시오. 만약 크레딧이 며칠 만에 소진된다면, 당신은 이미 "조사 및 평가 (research and evaluation)" 모드에 있는 것이 아닙니다. 당신은 serverless 크레딧이 설계 의도대로 감당할 수 없는 프로덕션 워크플로우 (production workflow)에 진입한 것입니다.

Dedicated 비용 산정 방식과 결정론적 비용인 이유

전용 모드인 Inference Endpoints는 구조가 다르며, 이것이 가장 큰 특징입니다. Hugging Face (HF) 문서에 따르면, 사용자는 AWS, Azure 또는 GCP에서 CPU 또는 GPU와 같은 인스턴스 유형을 직접 선택합니다. 가격은 시간당으로 표시되지만 분 단위로 차감되며, 엔드포인트가 "초기화 (initialized)"되거나 "작동 (running)" 중인 동안에만 비용이 발생합니다. 일시 중지(paused)된 엔드포인트는 컴퓨팅 비용이 발생하지 않습니다.

문서에 명시된 요율 범위는 AWS intel-spr x1 CPU 기준 시간당 $0.033부터 GCP nvidia-h100 GPU 기준 시간당 $10.00까지 매우 넓습니다 (실제 가격 페이지의 스냅샷이며, 문서 확인 시점의 값으로 버전 없이 변경될 수 있음). 최종 비용은 다음과 같은 공식으로 계산됩니다: 인스턴스 시간당 요율 × (기본 replica-시간 + 오토스케일링 (auto-scaled)된 replica-시간). 이것이 serverless와의 핵심적인 차이점입니다. 트래픽의 형태를 알 수 있다면, 월간 총 소유 비용 (TCO)은 완전히 결정론적 (deterministic)이 됩니다. 크레딧이 차감된 후에야 알게 되는 것이 아니라, 미리 계산할 수 있습니다.

오토스케일링 (Auto-scaling)은 CPU/GPU의 평균 사용률이 80%에 도달하면 레플리카 (replica)를 추가합니다 (GPU의 경우 1분간의 평균값 기준). 요청 수에 따른 베타 모드도 있습니다. 이는 레플리카당 20초 동안 1.5개 이상의 대기 요청이 발생할 때 작동합니다. 확장(scale-up) 체크는 1분마다 수행되고, 축소(scale-down) 체크는 2분마다 수행되며, 300초의 안정화 지연 시간 (stabilization delay)이 적용됩니다. 이러한 임계값 (thresholds)은 추상적인 개념이 아닙니다. 바로 이 값들이 시스템이 당신의 트래픽 급증에 맞춰 전력을 배치할 수 있을지, 아니면 요청이 점유된 레플리카에 막혀버릴지를 결정합니다.

502 및 503 오류가 시작을 문제로 만드는 지점

이제 계산할 때 가장 자주 누락되는 부분인 오류 처리 (Error Handling)에 대해 이야기해 보겠습니다. Dedicated 방식은 요청이 없는 15분 후에 0으로 스케일링 (Scale-to-zero)할 수 있어 유휴 시간 비용을 절감할 수 있습니다. 하지만 이러한 동작에는 대가가 따릅니다. 0으로 축소된 엔드포인트 (Endpoint)는 콜드 스타트 (Cold Start)가 진행되는 동안 새로운 요청에 대해 HTTP 502 코드로 응답합니다. 그리고 HF의 문서에는 내장된 요청 큐 (Request Queue)가 없으므로, 클라이언트 코드에서 반드시 재시도 (Retry)와 큐를 직접 구현해야 한다고 명시되어 있습니다.

HF는 콜드 스타트의 지속 시간을 공개된 수치 없이 "모델 크기에 따라 달라지는" 가변적인 것으로 정의합니다. 소스에 명시되어 있지 않으므로 초 단위인지 분 단위인지 임의로 추측하지는 않겠습니다. 하지만 동작 방식은 명확합니다. 유휴 상태 이후의 첫 번째 요청은 502 오류를 받을 수 있으며, 클라이언트가 재시도할 준비가 되어 있지 않다면 사용자는 오류를 보게 됩니다.

부하가 걸리면 503 오류가 추가됩니다. Hugging Face의 자체 FAQ에서는 프로덕션 환경을 위해 503 오류 횟수를 줄이기 위해 최소 2개의 레플리카 (Replica)를 유지하고, 헬스 체크 (Health-check) 라우트(준비되었을 때 HTTP 200 반환)를 생성하며, 스케일링 이벤트 동안 요청이 거부되지 않고 유지될 수 있도록 X-Scale-Up-Timeout 헤더를 보낼 것을 권장합니다. 주의할 점은, 최소 2개의 레플리카를 유지한다는 것은 더 이상 "기본적으로 serverless보다 저렴한" 상태가 아니라는 것입니다. 이는 시작 단계에서 오류가 발생하지 않도록 하기 위해 의도적으로 지불하는 비용입니다.

콜드 스타트 및 스케일링 시 502/503 오류를 방지하기 위한 최소한의 클라이언트 구성은 다음과 같습니다:

import time, httpx

def call_endpoint(client, url, payload, retries=5):
...

이것은 단순히 "보기 좋은 래퍼 (Wrapper)"가 아니라, scale-to-zero가 유휴 비용 절감을 사용자 측의 서비스 실패로 바꾸지 않기 위해 반드시 필요한 요소입니다. 프로젝트에 재시도 (Retry), 큐 (Queue), 헬스 체크 (Health-check)가 없다면, 그것이 serverless이든 dedicated이든 상관없이 모드 선택은 불완전하게 이루어진 것입니다.

결정 테이블: 조건 및 리스크에 따른 serverless vs dedicated 비교

각 모드의 조건들을 하나의 결정 테이블로 정리합니다. 수치와 문구는 HF(Hugging Face) 문서(2026년 7월 18일 기준)를 바탕으로 하였으며, 선택의 경계선으로서의 해석은 저의 개인적인 견해입니다. 이는 방법론일 뿐 HF의 공식적인 사실이 아닙니다.

SLA(Service Level Agreement)에 대해서는 별도로 다루겠습니다. 이 부분에서 실수하기 쉽기 때문입니다. 전용 인프라에서의 24시간 SLA 및 업타임(Uptime) 보장은 형식적으로 Inference Endpoints Enterprise 계층에서만 제공됩니다. 이는 표준적인 종량제(pay-as-you-go) 요율이 아니라, 연간 계약과 사용량 약정이 포함된 커스텀 가격 모델입니다. 즉, 일반적인 dedicated 엔드포인트에서는 업타임 보장이 자동으로 제공되지 않습니다. 또한 HF는 "99.9%"와 같은 구체적인 수치를 공개적으로 게시하지 않습니다. 이는 제가 임의로 만들어낸 것이 아닙니다.

여기서 두 가지 경로를 구분해야 합니다. 그렇지 않으면 비교할 수 없는 것들을 비교하게 됩니다. 위에서 언급한 모든 내용은 본인 소유의 모델을 호스팅하는 것에 관한 것입니다. 만약 본인만의 모델이 필요하지 않고, 단순히 러시아에서 완성된 LLM(Large Language Model)을 호출하는 것이 목적이라면 경로는 달라집니다: provod.ai — OpenRouter의 러시아판 대안. 플랫폼에서 사용 가능한 모델들에 대해 하나의 API와 웹 인터페이스를 제공합니다. 호환성은 프로토콜 수준에서 이루어집니다. OpenAI 호환 API를 사용할 수 있는 클라이언트, 에이전트 또는 IDE는 코드를 다시 작성할 필요 없이 base_url과 키를 교체하는 것만으로 연결할 수 있습니다.

from openai import OpenAI

client = OpenAI(
...

이 글의 주제와 관련하여 이러한 경로에서는 두 가지 속성이 중요합니다. 첫째, 안정적인 멀티채널 라우팅(multichannel routing)입니다. 하나의 상위 채널이 일시적으로 사용할 수 없을 때도 요청이 계속 전달됩니다. 이는 단일 채널에 대한 의존도를 낮춰주지만, 재시도(retry)나 업타임(uptime) 보장을 없애주는 것은 아닙니다. 일반적인 HF dedicated 환경과 마찬가지로 여기에서도 그 무엇도 보장되지 않습니다. 둘째, provod.ai의 추가 비용 없이 제공업체의 공식 가격으로 모델에 접근할 수 있으며, 루블화로 결제됩니다. 이는 HF에 자체 모델을 호스팅하는 과제를 해결해 주지는 않습니다. 그것은 다른 질문에 대한 답이며, 기본 설정이 아닌 자신의 시나리오에 따라 비교해야 합니다.

그렇다면 serverless가 dedicated보다 유리하지 않은 시점은 언제인가

선택지를 세 가지 행동 양식으로 요약하겠습니다: 기본값으로 serverless를 사용하기, 부하 계산 없이 즉시 dedicated로 전환하기, 또는 예측 가능한 시나리오에 따라 모드를 대조하기입니다. 앞의 두 가지는 동일한 이유로 제외합니다. 즉, 시나리오가 정의되지 않았기 때문입니다. 부하에 대한 설명, 지연 시간(latency) 요구사항, 오류 처리 계획 없이 내리는 선택은 모드 선택이 아니라 도박입니다.

세 번째 경로의 대가는 미리 부하와 요구사항을 정의해야 한다는 것입니다. 하지만 그 대신 결정이 검증 가능해집니다. 경계선은 다음과 같습니다. 작업이 모델을 탐색하거나, 임베딩(embeddings), 분류(classification) 또는 트래픽이 드물고 예측 불가능한 가벼운 레거시 LLM(legacy-LLM)을 구동하는 단계라면, serverless 크레딧과 공유 리소스가 합리적인 기본값입니다. 하지만 응답 시간이 제품에 대한 약속이 되고, 트래픽이 지속적으로 크레딧 한도를 초과하며, 트래픽 급증 시에도 사용자 측의 장애 없이 견뎌야 한다면, dedicated는 평가의 대상이 됩니다. 즉, 공식에 따른 결정론적 TCO(총 소유 비용), 분 단위 결제, 최소 2개의 복제본(replicas), 그리고 엔지니어링 계획의 일부로서의 클라이언트 재시도(retry)를 고려해야 합니다.

여기서 무엇이 확정되었고 무엇이 확정되지 않았는지 살펴보겠습니다. 확정된 사항: 모드 조건, 오류 코드 및 요금 체계는 문서와 대조하여 확인할 수 있습니다. 아마도(Probable): 귀하의 워크로드(workload) 프로필이 Dedicated 인프라가 필요한지 여부를 결정할 것이며, 이는 트래픽의 형태에 따라 달라집니다. 불확실한 사항(Unknown): 실제 지연 시간(latency), 실제 부하(load), 그리고 귀하의 제품에 대한 구체적인 최종 비용입니다. 귀하의 트래픽이 정확히 어떻게 작동할지에 대한 그 어떤 주장도 가설일 뿐입니다. 왜냐하면 문서는 메커니즘을 설명하는 것이지, 검증되지 않은 임의의 부하에 대한 보증을 제공하는 것이 아니기 때문입니다. 제가 옹호하는 입장은 간단합니다. 모드는 초기 편의성이 아니라, 요구되는 운영 수준의 약속(operational promise)에 따라 선택해야 한다는 것입니다.