100만 토큰이 양쪽에서 각각 얼마인지.

요약

이 둘을 비교하는 글은 거의 모두 숫자 하나로 결론을 냅니다 — “자체 호스팅이 10배 싸다”, “규모가 아주 커지기 전까지는 API가 싸다” — 그리고 둘 다 같은 실수를 합니다. 토큰 단위로 과금하지 않는 머신에 토큰당 비용을 매기는 실수입니다. 임대한 GPU는 가격이 정확히 하나이고 움직이지 않습니다: 이번 달에 10억 토큰을 생성하든 하나도 생성하지 않든 청구서는 같습니다. 그러므로 정직한 질문은 “여기서 토큰 하나가 얼마인가”가 아니라 “고정 가격이 계량기를 이기려면 토큰을 몇 개나 생성해야 하는가”입니다.

그 수치는 나눗셈이며, 아래에서 당사의 가격과 당사의 처리량 모델로 직접 계산합니다 — 구성 도구가 쓰는 것과 같은 모델입니다. 이후의 내용은 그 물량에 도달할 수 있는지를 가르는 2가지를 다룹니다: 배칭, 그리고 머신을 유휴 상태로 두는 시간입니다.

계산

4줄입니다. 세 번째 줄은 화이트보드에 적어 둘 만하고, 네 번째 줄은 사람들이 건너뛰는 줄입니다. 그 줄을 건너뛰면 멀쩡한 추정이 틀린 추정이 됩니다.

# 1. What the API charges. Linear in what you use, zero when you stop.
api_cost_per_month = output_tokens_per_month / 1e6 × api_price_per_million

# 2. What the machine charges. A constant. Tokens are free once you own the hours.
machine_cost_per_month = monthly_price

# 3. Set them equal. This is the break-even VOLUME, in output tokens per month.
break_even_tokens = monthly_price / api_price_per_million × 1e6

# 4. And the only question that matters: can the machine produce that many?
#    730 hours is the month we bill, so 2,628,000 seconds of it.
sustained_tokens_per_second = break_even_tokens / 2,628,000

4번 줄은 최대치가 아니라 지속 속도입니다. 하루 1시간만 초당 600토큰을 내고 나머지 23시간은 유휴 상태인 머신의 지속 속도는 25이며, 청구서는 둘 중 무엇을 말하는지 신경 쓰지 않습니다.

단일 스트림의 비용

가정 없이 제시할 수 있는 유일한 수치이므로 최악의 경우부터 시작합니다: 한 번에 요청 1건, 배칭 없음, 그 외 시간에는 머신 유휴. 아래의 모든 노드는 Llama 3.3 70B 모델을 4-bit (AWQ, GPTQ) 정밀도로 구동하며, 처리량은 당사가 보수적으로 잡은 추정치입니다 — 운 좋은 날에 측정한 값이 아니라 메모리 대역폭으로 상한을 둔 값입니다.

이 값은 견적이 아니라 상한선으로 읽으십시오. 머신에 한 번에 질문 하나씩만 답하게 하고 그 달의 나머지 기간에는 놀려 둘 때 토큰 하나에 드는 비용입니다 — 현존하는 가장 비효율적인 GPU 보유 방식입니다. 실제 서빙 스택은 모두 이보다 낫고, 이어지는 절 2개가 얼마나 나은지를 다룹니다.

등급별 손익분기점

위 표에서 가장 싼 행을 보십시오 — 2 × NVIDIA RTX 5090 노드, 월 $692 — 그리고 이 행이 API 시장의 각 등급을 이기려면 얼마나 많은 작업이 필요한지 따져 보십시오.

마지막 열이 이 글의 전부입니다. “이미 더 저렴”이라고 적힌 곳에서는 $692 머신의 배칭 없는 스트림 하나가 API를 이기므로 더 고민할 것이 없습니다. 배수가 표시된 곳에서도 머신이 이길 수 있습니다 — 다만 실제로 일감을 채워 넣을 때만 그렇고, 그것이 다음 절의 내용입니다.

관건은 배칭

토큰 1개를 생성하려면 활성 가중치를 메모리에서 한 번 읽어야 합니다. 서로 다른 요청 100건에 대해 토큰 100개를 생성할 때도 읽기는 한 번이면 됩니다 — 배치 안의 모든 요청이 같은 가중치를 쓰기 때문입니다. 연속 배칭을 갖춘 서빙 스택이 같은 하드웨어에서 단일 스트림의 몇 배에 달하는 초당 토큰을 내는 이유가 여기에 있고, 그 표의 마지막 열에 있는 배수가 애초에 도달 가능한 이유도 마찬가지입니다.

실무적 결론: 손익분기점 표의 배수를 사용자 수가 아니라 처리량 목표로 보십시오. 단일 스트림의 10배라는 목표는 “사용자 10명”을 뜻하지 않습니다. 서버가 배칭 없는 속도의 평균 10배를 내야 한다는 뜻이며, 여기에는 보통 동시 요청 10건보다 많고 100건보다 적은 수가 필요합니다. 숫자를 확정하기 전에 머신에서 직접 측정하십시오 — 벤치마크 한 번이면 논쟁이 끝납니다.

그래도 요금을 내야 하는 유휴 시간

위 내용은 부하가 한 달에 걸쳐 고르게 퍼진다고 가정했습니다. 실제로는 결코 그렇지 않습니다. 월 단위로 임대한 머신은 일요일 04:00에도 요금이 나가고, 그때 생성하지 않은 토큰은 이월되지 않습니다. 실제로 서빙하는 시간을 실제로 결제하는 시간으로 나누어 보십시오:

사내 도구는 대부분 세 번째 행에 해당하며, 이 행은 손익분기점을 조용히 4배 넘게 키웁니다. 자체 호스팅 추정이 어긋나는 가장 흔한 원인이 바로 이것입니다 — 토큰 가격도, 하드웨어도 아니고, 근무 주간을 한 주 전체로 가정한 탓입니다.

프롬프트가 사실상 공짜인 이유

머신을 직접 보유하는 쪽에 크게 유리한 비대칭이 하나 있는데, 토큰 단가 비교로는 드러나지 않습니다. API는 입력 토큰에도 과금합니다 — 토큰당 보통 출력 가격의 4분의 1에서 3분의 1입니다. 직접 보유한 GPU에서는 입력 토큰을 프리필 단계에서 처리하며, 이 단계는 프롬프트 전체를 병렬로 처리하고 메모리 대역폭이 아니라 계산량의 제약을 받습니다. 프리필의 초당 토큰 수는 생성보다 한 자릿수 더 큽니다.

계산이 빠뜨리는 것

토큰당 비용 표에는 결코 나오지 않지만, 숫자만큼이나 자주 결론을 좌우하는 4가지입니다.

어느 쪽에 해당하는가

순서대로 읽고, 해당되는 첫 항목에서 멈추십시오.

1. 최상위 비공개 모델 수준의 품질이 필요한 경우. 이 글은 해당하지 않습니다: 그 가중치를 임대해 주는 곳은 없습니다. API를 쓰시고, 공개 모델이 해당 작업에서 격차를 좁히면 다시 검토하십시오.
2. 물량이 적거나 아직 얼마인지 모르는 경우. API를 쓰십시오. 트래픽이 실제로 어떤 모습인지 알아내는 가장 저렴한 방법이며, 계량기는 훌륭한 측정 도구입니다.
3. 트래픽이 들쭉날쭉하고 대기열을 감내할 수 있는 경우. API를 쓰시거나, 나누십시오: 꾸준한 기본 부하는 직접 운영하는 머신에, 최대 부하는 호스팅 엔드포인트에 맡기는 방식입니다. 한쪽으로만 결정해야 할 이유는 없습니다.
4. 공개 가중치 모델로 실제 배치 물량을 꾸준히 처리하는 경우. 하드웨어가 이기는 경우이며, 그것도 큰 차이로 이깁니다 — 고정 가격은 더 움직이지 않는 반면 계량기는 계속 돌아갑니다. 믿기 전에 위 표에서 직접 수치를 확인하십시오.
5. 프롬프트가 민감하거나, 모델이 바뀌면 안 되거나, 청구 금액을 미리 알 수 있어야 하는 경우. 이때 계산은 형식적인 절차일 뿐입니다. 모델이 들어가는 머신을 임대하시고, 누구에게도 신원을 밝히지 않고 결제하십시오.

어느 줄에서 멈추셨든, 확인할 수치는 고객의 모델과 고객의 물량에 해당하는 손익분기점 표의 값입니다. 구성 도구는 당사가 임대하는 모든 노드에 대해 모델이 카드 1장에 들어가는지, 분할이 필요한지, 처리량 추정치가 얼마인지 알려 줍니다 — 이 계산에 필요한 입력이 모두 여기에 있습니다. 월 단위 임대와 시간당 과금 사이에서 아직 정하지 못하셨다면, 그것은 다른 손익분기점이며 그 계산도 따로 정리해 두었습니다.