보통 이 비교는 잘못 이루어지곤 합니다. 한쪽은 백만 토큰당 비용으로 인용되는 반면, 다른 한쪽은 구매 비용으로 인용되기 때문입니다. 구매 비용을 동일한 단위로 변환하면 논쟁은 스스로 해결되며, 결정적인 요소는 하드웨어가 아니라는 사실이 드러납니다.

양측을 동일한 단위로 통일하기

API 가격은 백만 토큰당 통화 단위입니다. 이를 비교하려면 본인의 장비도 동일한 방식으로 표현해야 합니다. 이를 위해서는 세 가지 수치가 필요합니다: 장비를 소유하고 운영하는 데 드는 시간당 비용, 장비가 시간당 생성할 수 있는 토큰 수, 그리고 실제로 토큰을 생성하고 있는 시간의 비율입니다.

세 번째 수치에서 거의 모든 공개된 비교가 오류를 범합니다. 유휴 상태(idle)인 GPU도 여전히 감가상각 비용이 발생하며, 한 명의 개발자를 위해 구매한 장비는 압도적으로 대부분의 시간을 유휴 상태로 보냅니다.

이 과정을 생략하면 전체 작업이 무의미해지므로 한 가지 전제 조건을 두겠습니다. 양측은 비교 가능한 성능(capability)을 제공해야 합니다. 본인의 하드웨어에서 실행되는 작은 오픈 모델(open model)을 프런티어 API(frontier API)와 비교하는 것은 서로 다른 두 가지 물건의 가격을 비교하는 것이며, 이는 항상 로컬 측에 유리하게 작용할 것입니다. 동일한 오픈 모델의 호스팅 가격과 비교하거나, 비용뿐만 아니라 품질 측면에서도 트레이드오프(trade-off)를 하고 있음을 인정하고 이를 명시적으로 밝혀야 합니다. 아래의 산술 계산은 이미 모델이 결정되었다고 가정합니다.

공식

hourly_cost = amortised_capital_per_hour
            + (power_kw * electricity_per_kwh)
            + operational_per_hour
...

모든 입력값은 알고 있거나 측정할 수 있는 값입니다. sustained_tokens_per_sec(지속 초당 토큰 수)는 발표된 수치가 아니라, 실제 모델을 실제 하드웨어에서 llama-bench나 서빙 벤치마크(serving benchmark)를 실행하여 얻은 값입니다. utilisation(이용률)은 실제 일주일 동안 장비가 생성할 수 있었던 토큰 수 대비 실제로 생성된 토큰의 비율로 계산됩니다. power_kw(전력 kW)는 부하 상태에서의 전력 소모량(wall draw)이며, 시스템의 나머지 부분을 포함하면 GPU 자체의 수치보다 유의미하게 높게 나타납니다.

공식에 포함되지 않은 점에 주목하십시오. 모델의 성능이 얼마나 좋은지에 대한 내용은 전혀 없습니다. 이 공식은 토큰의 가격을 계산하는 것이며, 작은 모델의 토큰은 큰 모델의 토큰만큼 품질이 좋지 않습니다. 동일한 조건끼리 비교해야 하며, 그렇지 않으면 이 연습은 단순한 장식에 불과합니다.

계산 과정 (Working it through)

하나의 중간 크기 오픈 모델 (open model)을 서비스하는 단일 GPU 박스를 가정해 봅시다. 측정 결과 단일 스트림 (single stream)에 대해 초당 30개의 토큰이 지속적으로 생성된다고 가정합니다. 계산된 모든 비용을 어떤 통화로 계산하든 시간당 총비용을 H라고 부릅시다.

개발자 1명, 스트림 1개, 8시간 근무 중 40% 사용
  가동률 (utilisation) = 0.40 * (8/24) = 0.133
  시간당 토큰 수 (tokens_per_hour) = 30 * 3600 * 0.133 = 14,400
...

하드웨어는 변하지 않았습니다. 백만 토큰당 비용은 94배 차이가 났습니다. 유사한 오픈 모델의 현재 백만 토큰당 가격을 찾아 이를 H로 나누면 임계값 (threshold)을 얻을 수 있습니다. 첫 번째 시나리오에서 그 몫이 69보다 크면 자체 호스팅 (self-hosting)이 더 저렴하며, 그보다 낮으면 그렇지 않습니다. 대부분의 단일 사용자 설정에서 그 몫은 69에 근접하지 않으며, 해당 기기는 비용 이외의 다른 이유로 정당화됩니다.

가동률 (Utilisation)이 핵심입니다

두 가지 구조적 사실이 해당 표를 결정하며, 이는 일반적인 직관을 뒤집기 때문에 명확하게 언급할 가치가 있습니다.

• API는 토큰에 대해서만 비용을 청구하지만, 박스(하드웨어)는 시간에 대해 비용을 청구합니다. 유휴 (Idle) API 용량은 비용이 들지 않습니다. 유휴 GPU는 전체 감가상각 (amortisation) 비용이 발생합니다. 자체 호스팅 경제학의 핵심은 카드를 계속 바쁘게 유지하기 위한 싸움입니다.
• 배칭 (Batching)은 거의 비용이 들지 않는 처리량 (throughput)입니다. 생성 (Generation)은 메모리 대역폭 제한 (memory-bandwidth bound)을 받으므로, 하나의 토큰을 위해 스트리밍되는 가중치 (weights)는 동시에 여러 시퀀스 (sequences)를 처리할 수 있습니다. 하나의 스트림에서 10개의 동시 스트림으로 전환하면 총 초당 토큰 수는 비용 증가분보다 훨씬 더 많이 증가합니다. 이것이 바로 단일 스트림 런타임 (runtime)이 아닌 배칭 서버를 사용하는 것이 두 번째 행과 첫 번째 행의 차이를 만드는 이유입니다.

실질적인 결과는 다음과 같습니다. 비용 문제로 인해 셀프 호스팅 (self-hosting)을 하는 경우, 첫 번째 엔지니어링 과제는 하드웨어를 선택하는 것이 아닙니다. 그것은 현재 보유한 하드웨어가 공유되고, 큐잉 (queuing)되며, 배칭 (batching)되도록 만드는 것입니다.

사람들이 생략하는 용어들

• 당신의 시간. 설정, 업그레이드, 드라이버 오류, 모델 업데이트, 그리고 새벽 2시에 시스템이 다운되었을 때의 온콜 (on-call) 대응 경로. 어떤 전문적인 시간당 임금을 적용하더라도 이는 모델에서 가장 큰 비중을 차지하는 경우가 많지만, 거의 포함되지 않습니다.
• 중복성 (Redundancy). 장비 한 대는 단일 장애점 (single point of failure)입니다. 프로덕션 서비스를 정직하게 비용 산정한다는 것은 두 대의 비용을 산정하거나, 폴백 (fallback) 경로의 비용을 산정하는 것을 의미합니다.
• 피크 (Peak) 대 평균 (average). 하드웨어는 피크 동시성 (peak concurrency)에 맞춰 크기를 정해야 하지만, 위의 비용 모델은 평균으로 나눕니다. 이 비율이 클수록 셀프 호스팅의 경제성은 악화됩니다.
• 잔존 가치 및 노후화 (obsolescence). 감가상각 기간은 해당 카드가 얼마나 오랫동안 적절한 성능을 유지할지에 대한 추측이며, 메모리 단위당 성능은 매우 빠르게 변화해 왔습니다.
• API 측면: 캐싱 (caching) 및 배치 티어 (batch tiers). 할인된 비동기 처리 (asynchronous processing)와 캐싱된 프롬프트 접두사 (cached prompt prefixes)는 조건에 부합하는 워크로드에 대해 100만 토큰당 비용을 상당히 낮출 수 있습니다. 실제로 지불하게 될 가격과 비교해 보십시오.

각 측면이 승리하는 경우

셀프 호스팅은 지속적인 높은 활용도 — 연속적인 배치 처리 (batch processing), 대규모 코퍼스 (corpus)에 대한 임베딩 파이프라인 (embedding pipeline), 핫 패스 (hot path) 내의 분류기 (classifier) — 및 데이터가 통제 범위를 벗어나면 안 되는 워크로드, 즉 비용 모델이 중요하지 않은 상황에서 승리합니다. 또한 하드웨어가 이미 존재하고 그 감가상각이 다른 용도로 이미 처리된 경우에도 유리합니다.

API는 급격히 변동하는 낮은 평균 트래픽, 프런티어 성능 (frontier capability)이 필요한 모든 작업, 그리고 아직 볼륨을 예측할 수 없는 모든 초기 단계 시스템 — 즉 거의 모든 시스템 — 에서 승리합니다.

비싼 실수를 피하는 순서는 호스팅 (Hosted) 서비스로 시작하여 트래픽을 계측 (Instrument)하고, 한 달간의 실제 토큰 수와 측정된 사용률 (Utilisation) 수치를 확보한 뒤에 이 계산을 다시 실행하는 것입니다. 그 시점이 되면 답은 논쟁이 아닌 산술 (Arithmetic)의 영역이 되며, 하드웨어를 구매해야 할 명분(만약 있다면)은 스프레드시트를 붙들고 싸울 필요가 없을 정도로 충분히 명확해질 것입니다. 먼저 구매하고 나중에 측정하는 방식은 이를 역전시키며, 이 경우 기계는 사후에 정당성을 확보하려는 경향이 있습니다.

만약 산술적 결과가 임계선 근처에 있다면, 무엇인가를 구매하기 전에 가격을 검토해 볼 만한 중간 옵션이 있습니다. 바로 다른 업체가 제공하는 동일한 오픈 웨이트 (Open weights) 모델을 사용하는 것입니다. 호스트마다 하나의 오픈 모델에 대한 100만 토큰당 가격이 눈에 띄게 다릅니다. 이 방식은 모델 선택권을 유지하면서 사용률 (Utilisation) 문제를 해결해 줍니다. 만약 자체 호스팅 (Self-hosting)을 하려는 이유가 데이터가 외부로 유출될 수 없기 때문이라면 이 옵션은 전혀 도움이 되지 않습니다. 이 경우 사용률 (Utilisation) 문제를 해결하는 것이 곧 본연의 업무가 됩니다.

관련 항목 (Related)

• 팀 전체에 오픈 모델 서빙하기 (Serving an Open Model to Your Whole Team)
• 하이브리드 아키텍처: 대부분은 로컬로, 어려운 요청은 API로 (Hybrid Architecture: Local for Most, API for Hard Requests)
• 로컬 모델의 진정한 명분으로서의 개인정보 보호 (Privacy as the Real Case for Local Models)