70B 자체 서빙은 버스를 대절하는 것이다 - 좌석을 25% 이상 채워야 택시보다 싸다

“우리도 모델을 직접 돌리면 API보다 싸지 않을까.” 이 질문에 답하려면 월 토큰 수를 세는 것으로는 부족하다. 세어야 하는 것은 좌석을 몇 % 채우는지다.

이 글의 결론을 그 언어로 먼저 말하면 이렇다.

• 버스 대절료를 택시 요금으로 나눈 교차점은 월 56억 과금 토큰이다. 그런데 이 숫자는 워크로드가 무엇이든 똑같이 나와서 판단 기준으로 쓸 수 없다
• 대화형 워크로드에서 버스가 이기려면 좌석의 25.5%를 채워야 한다. 긴 문서를 다루면 47.0%로 올라간다
• 여기에 현실적인 지연 목표와 예비 버스를 얹으면 필요 좌석률이 100%를 넘는다. 그러면 승객을 아무리 늘려도, 버스를 몇 대 더 대절해도 택시보다 싸지지 않는다

아래는 그 계산이다. 전제와 출처를 모두 공개하니 자기 숫자를 넣어 다시 계산하면 된다.

전제 세 개

항목	값	출처 (2026-08-23 조회)
택시 요금 — Together AI, Llama 3.3 70B	입력·출력 각 $1.04 / 1M 토큰	공식 요금 페이지
버스 대절료 — Lambda, H100 SXM	$3.99 / GPU·시간	공식 요금 페이지
버스 좌석 수 — Llama 3.3 70B FP8 처리량	4,181.06 출력 토큰/초	TensorRT-LLM 성능 문서

GPU 단가 $3.99는 공개된 범위 $3.99~4.29의 하단이고 세금은 별도다. 상단을 쓰면 아래 모든 값이 7.5% 비싸진다. 교차점은 56.0억에서 60.2억으로, 필요 좌석률은 25.5%에서 27.4%로 올라간다. 이 글의 숫자는 자체 서빙에 유리한 쪽으로 잡은 것이다.

처리량 수치는 조건이 붙어야 의미가 있다. 위 값은 H100 SXM 80GB 2장, 텐서 병렬 2, FP8 양자화, 입력 1,000 토큰 / 출력 1,000 토큰 조건이다. 이 조건이 빠진 추론 속도 수치는 비교에 쓸 수 없다. 같은 기준으로 이 글의 출처도 하나가 비어 있다 — 원문에 배치 크기가 명시되어 있지 않다.

버스는 이 벤치마크와 동일하게 H100 SXM 2장, 한 달은 730시간으로 둔다.

시간당 = 2 × $3.99          = $7.98
월     = $7.98 × 730시간    = $5,825.40   <- 대절료

교차점은 월 56억이고, 그 숫자는 쓸모가 없다

대절료를 택시 요금으로 나누면 두 선이 만나는 지점이 나온다.

교차점 = 대절료 ÷ 택시 요금
       = $5,825.40 ÷ ($1.04 / 1M)
       = 56.0억 과금 토큰 / 월

이 식에 처리량이 들어오지 않는다는 점을 눈여겨봐야 한다. 버스에 좌석이 40개든 4개든 교차점은 56.0억이다. 그래서 “우리는 월 몇 토큰 쓰니까 자체 서빙이 유리하다”는 형태의 판단은 성립하지 않는다.

56.0억을 24시간 균등하게 흘리면 초당 2,131 과금 토큰이다. 입출력이 1:1인 워크로드라면 출력 1,066 토큰/초에 해당한다. 이것이 첫 번째 기준선이다.

좌석을 몇 % 채워야 하나

처리량이 결정하는 것은 교차점이 아니라 버스에 좌석이 몇 개 있는가, 즉 용량이다. 용량이 정해지면 그 좌석을 몇 % 채워야 택시비를 넘기지 않는지가 나온다. 그것이 필요 좌석률, 원래 용어로는 필요 가동률이다.

입력 / 출력 토큰	출력 처리량 (토큰/초)	월 용량 (과금 토큰)	필요 좌석률	포화 시 절감 배수
2,048 / 128	723.40	323.2억	17.3%	5.77배
5,000 / 500	865.55	250.2억	22.4%	4.47배
1,000 / 1,000	4,181.06	219.8억	25.5%	3.92배
128 / 2,048	5,892.94	164.5억	34.0%	2.94배
2,048 / 2,048	2,785.53	146.4억	38.3%	2.61배
20,000 / 2,000	411.85	119.1억	47.0%	2.13배

마지막 열은 상금이다. 좌석을 꽉 채웠을 때 택시 대비 몇 배 싼가이고, 1 ÷ 필요 좌석률이다. 필요 좌석률이 100%를 넘으면 이 값이 1배 아래로 내려가 버스가 더 비싸진다.

순서가 뒤집히는 것도 눈여겨볼 만하다. 처리량 순으로 보면 2,048/128이 가장 느린 편인데 필요 좌석률로 보면 가장 유리하다. 짧은 답을 뽑는 RAG 워크로드는 문서를 읽는 단계가 지배해 초당 출력 토큰은 적지만, 그 읽은 문서가 전부 과금되기 때문이다.

4,181 토큰/초는 텅 빈 도로에서 잰 값이다

TensorRT-LLM 문서는 이 수치를 만든 벤치마크를 스스로 이렇게 설명한다. 모든 요청을 연달아 큐에 넣는 오프라인 최대 처리량 시나리오.

대화형 서비스는 첫 토큰 지연과 토큰 간 지연 목표를 지켜야 한다. 그 제약을 걸면 동시 처리 요청 수를 줄여야 하고 실효 처리량은 상한보다 낮아진다. 얼마나 낮아지는지는 지연 목표와 트래픽 패턴에 달려 있어 신뢰할 만한 1차 출처를 찾지 못했다.

배수를 단정할 수 없으니 감도 분석을 한다. 가장 불리한 20,000/2,000 워크로드에서 실효 처리량이 상한의 몇 %인지에 따라 필요 좌석률이 이렇게 움직인다.

긴 컨텍스트만의 문제가 아니다. 가장 유리한 조건인 대화형(1,000/1,000)에 같은 감도를 적용하면 이렇게 된다.

1,000/1,000 조건	월 용량	필요 좌석률
실효 처리량 100%	219.8억	25.5%
실효 처리량 50%	109.9억	51.0%
실효 처리량 100% + 예비 버스 1대	219.8억	51.0%
실효 처리량 25%	54.9억	102.0%
실효 처리량 50% + 예비 버스 1대	109.9억	102.0%

대화형에서도 실효 처리량이 상한의 4분의 1이면 역전이 불가능하다. 예비 버스까지 넣으면 절반만 떨어져도 같은 결과다. 이 글이 확보한 데이터로 말할 수 있는 가장 강한 결론은 긴 컨텍스트에 관한 것이 아니라 이것이다 — 지연 목표를 현실적으로 잡고 이중화를 넣으면 2×H100 구성은 워크로드 종류와 무관하게 서버리스 API를 이기기 어렵다.

버스를 더 대절하면 해결될 것 같지만 그렇지 않다.

버스 수 (GPU)	월 대절료	월 용량	필요 좌석률
2	$5,825	29.8억	188.2%
4	$11,651	59.5억	188.2%
8	$23,302	119.1억	188.2%

좌석과 대절료가 함께 비례해 늘어나므로 필요 좌석률은 변하지 않는다. 필요 좌석률은 규모에 불변이고, 따라서 물량으로 푸는 문제가 아니다. 승객의 성격을 바꾸거나, 버스를 바꾸거나, 택시를 타는 것 중에서 골라야 한다.

이 표는 텐서 병렬 2 구성을 복제로 늘린다고 가정한다. 즉 4 GPU는 2 GPU 노드 두 벌이다. 그래야 용량이 GPU 수에 정확히 비례한다. 텐서 병렬 자체를 4나 8로 넓히면 통신 오버헤드로 용량 증가가 비례에 못 미치고, 그러면 필요 좌석률은 188.2%보다 더 높아진다. 확보한 데이터가 텐서 병렬 2뿐이라 이 가정을 썼고, 가정이 낙관적인 쪽이므로 결론 방향은 그대로다.

좌석률에는 두 가지가 있고, 둘은 곱해진다

지금까지 쓴 좌석률은 시간 기준이 아니다. 2장의 GPU 최대 처리량 대비 실제 처리량이다. 이것을 구분하지 않으면 판단이 어긋난다.

• 시간 가동률 — 버스가 운행하는 시간의 비율. 오토스케일로 낮출 수 있다
• 포화도 — 운행 중에 좌석이 얼마나 찼는지. 요청이 드문드문 오면 버스가 굴러도 좌석은 20~30%만 찬다

사내 도구를 예로 곱해 보자. 업무시간에만 쓰이므로 하루 8~10시간 트래픽이고, 시간 가동률을 잘 잡아도 40%가 상한이다. 요청이 드문드문 들어오면 포화도는 25% 부근이다. 실효 좌석률 10%다. 필요치 25.5%의 39% 수준이고, 사내 도구 규모에서는 자체 서빙이 손익분기에 닿지 못한다.

두 비율은 이 글의 예시 값이지 실측이 아니므로 자기 트래픽 곡선으로 다시 곱해야 한다. 다만 두 값을 곱해야 한다는 것 자체가 요점이다. 시간 가동률만 보고 판단하면 실제보다 두세 배 낙관하게 된다.

오토스케일로 시간 가동률을 올리면 되지 않는가. 이 반론이 걸리는 곳은 모델 로딩 시간이다. 70B FP8 웨이트는 약 70GB다. 로컬 NVMe에서 3 GB/s로 읽어도 23초, 오브젝트 스토리지에서 1 GB/s로 당기면 70초가 걸린다. 여기에 엔진 로딩과 워밍업이 붙는다. 초 단위로 오는 트래픽 급증을 분 단위로 뜨는 인스턴스가 따라갈 수 없다.

따라서 실무에서는 최소 인스턴스를 항상 켜 둔다. 그 최소 인스턴스가 곧 대절료이고, 오토스케일은 대절료를 없애는 것이 아니라 그 위의 초과분만 줄인다. 이 로딩 시간은 웨이트 크기와 대역폭 가정으로 계산한 추정이며 실측값이 아니다.

운전기사 비용이 지배한다

GPU 비용은 자체 서빙 비용의 일부다. 버스에는 운전기사가 필요하다. 배포와 모니터링, 장애 대응, 모델·프레임워크 버전 업그레이드, 양자화 재검증, 용량 계획을 계속해야 한다.

월 운영 인건비	교차점	최저 시점 필요 처리량	필요 좌석률 (1:1 워크로드)
$0	56.0억	2,131 토큰/초	25.5%
$2,000	75.2억	2,863 토큰/초	34.2%
$4,000	94.5억	3,595 토큰/초	43.0%
$8,000	132.9억	5,058 토큰/초	60.5%

교차점 = ($5,825.40 + E) ÷ 택시 요금

$E는 출처가 없는 가정이다. 조직마다 다르니 자기 숫자를 넣어야 한다. 여기서 볼 것은 절대값이 아니라 기울기다. GPU 비용 $5,825.40의 70%에 해당하는 운영 인건비를 얹으면 필요 물량이 1.7배가 된다. 자체 서빙의 손익분기를 지배하는 것은 GPU 시간이 아니라 사람이다.

이것이 자체 서빙 검토에서 가장 흔하게 빠지는 항목이다. 버스 견적은 조달팀이 뽑아 오지만 그 버스를 몰 사람의 시간은 아무 견적서에도 나오지 않는다.

실제로는 정기 승객만 버스에 태운다

지금까지의 계산은 버스 100% 대 택시 100%의 이항 선택이었다. 실무에서 고르는 구성은 그 중간이다.

자체 서빙 부분을 야간 최저 트래픽에 맞춰 크기를 잡으면 그 GPU는 사실상 포화 상태로 돌고 초과분은 API가 받는다. 좌석률 문제가 구조적으로 사라진다.

예비 버스도 필요 없어진다. 대기 노드는 대절료를 두 배로 만들면서 좌석은 한 자리도 늘리지 않으므로 필요 좌석률이 두 배가 된다. 대화형이라면 25.5%에서 51.0%로 뛴다. 위의 모든 계산은 단일 노드 기준이어서 그 부담이 아직 들어 있지 않다. 고객 대면 서비스라면 어딘가에서 그 두 배를 물어야 하는데, 하이브리드는 자체 서빙 노드가 죽었을 때 API로 넘기므로 애초에 두 벌을 두지 않는다.

그러면 판단 기준이 총 물량에서 최저 시점 처리량으로 바뀐다. 야간 최저점에도 초당 2,131 과금 토큰이 흐르고 있으면 그 부분을 자체 서빙으로 내리는 것이 이득이고, 그 크기는 용량표의 절감 배수만큼이다. 대화형이면 그 슬라이스에서 3.92배 싸진다. 총 물량이 아무리 커도 최저점이 그 아래면 이득이 없고, 총 물량이 크지 않아도 최저점이 그 위면 이득이 있다.

단 2,131은 운영 인건비를 0으로 둔 값이다. 인건비 $4,000을 넣으면 기준선이 초당 3,595 과금 토큰으로 69% 올라간다. 실무 기준선은 인건비를 넣은 쪽이다.

회사 두 곳으로 계산해 보면

두 예시가 보여주는 것은 같다. 총 물량은 1차 관문일 뿐이고, 통과한 뒤에 봐야 하는 것은 최저 시점 처리량과 필요 좌석률이다.

계산에 넣지 않은 것들

빠진 항목	자체 서빙에
1~3년 약정·예약 할인 (온디맨드만 계산)	유리
프리픽스 캐싱	방향 불명
배치 처리 가능한 오프라인 작업	방향 불명
야간·주말 유휴 시간	불리
모델 로딩 지연으로 오토스케일 대응 불가	불리
예비 버스 (하이브리드가 아니면 최소 2 노드)	불리
GPU 조달 리드타임과 재고 리스크	불리
모델 교체 시 재검증 비용	불리
API 전용 엔드포인트·볼륨 계약 단가	불리
API 배치 처리 할인	불리
API 제공자의 지속적 단가 인하	불리

약정 할인은 대절료를 낮추므로 교차점을 그만큼 내린다. 할인율 d를 넣으면 교차점 = $5,825.40 × (1 - d) ÷ 택시 요금이다. 20% 할인이면 44.8억(필요 좌석률 20.4%), 40% 할인이면 33.6억(15.3%)이 된다. 할인율은 제공자와 기간마다 달라 이 글에서는 값을 쓰지 않는다.

단 약정은 좌석률이 확실할 때만 이득이다. 물량이 불확실한 단계에서 약정을 걸면 좌석률 리스크를 그대로 떠안는다.

캐시 적중이 높거나 배치로 묶을 수 있으면 자체 서빙의 실효 처리량이 오른다. 그런데 API 제공자들도 캐시 히트와 배치 요청에 할인 단가를 적용하므로 API 비용도 같이 내려간다. 어느 쪽이 더 내려가는지는 제공자의 할인 단가를 확인해야 정해지고, 그 값을 이 글에서는 확보하지 못했다.

그리고 이 글의 가장 큰 비교 한계를 밝혀야 한다. API 값으로 쓴 $1.04는 서버리스 정가다. 월 56억 토큰 규모에서 정가를 그대로 내는 조직은 없다. 전용 엔드포인트, 볼륨 계약, 배치 처리 할인이 모두 API 쪽 실단가를 낮춘다. 그 단가를 확보하지 못해 이 글은 정가로 계산했고, 따라서 자체 서빙에 유리한 방향으로 기울어진 계산이다. GPU 약정 할인만 파라미터로 모델링하고 API 쪽 할인은 빼는 것은 비대칭이므로, 이 항목이 다음 편의 최우선 취재 대상이다.

하이퍼스케일러에서 버스를 대절하면

인스턴스	GPU	GPU 메모리	시간당
AWS g6e.12xlarge (서울, 온디맨드)	L40S ×4	192 GB	$12.90
Lambda H100 SXM ×2	H100 ×2	160 GB	$7.98

AWS 가격은 3차 집계 사이트(Vantage, 2026-08-23 조회)에서 얻었다. AWS 공식 요금 페이지가 인스턴스별 표를 JavaScript로 렌더링해 자동 조회가 되지 않았다. 인스턴스 사양만 AWS 문서로 확인했다.

GPU 메모리는 192 GB 대 160 GB로 20% 차이인데 시간당 가격은 1.6배다. 메모리 1GB·시간당으로 정규화하면 1.35배다. 다만 L40S와 H100은 다른 하드웨어다.

같은 조건의 L40S 처리량 수치를 확보하지 못했기 때문에 AWS 기준 필요 좌석률은 계산하지 않는다. 좌석 수를 모르면 필요 좌석률을 낼 수 없고, 시간당 단가만 비교하는 것은 이 글의 모델에서 의미가 없다.

방향만 말할 수 있다. 대절료가 높으면 교차점과 필요 좌석률이 함께 오른다. 이미 하이퍼스케일러 온디맨드에서 돌아가고 있고 그 계약을 벗어날 수 없다면 자체 서빙 조건은 위 계산보다 불리해진다.

그래서 어떻게 판단하는가

API 청구서를 열어 월 과금 토큰을 확인하는 것으로 시작한다. 이 글이 물량 기준을 쓸모없다고 해놓고 물량으로 시작하는 이유가 있다.

야간 최저점에 초당 2,131 과금 토큰이 흐르려면 그 속도가 한 달간 유지될 때 총 56억이 된다. 즉 총 물량 56억은 완벽하게 평탄한 트래픽에서의 최소치이고, 실제 트래픽에는 편차가 있으니 총 물량은 그보다 훨씬 커야 한다. 총 물량은 통과 못 하면 볼 것도 없는 1차 스크린이고, 통과한 뒤에 최저 시점 처리량과 필요 좌석률을 본다. 그 순서다.

월 10억 과금 토큰 미만. 비용을 근거로 한 자체 서빙 검토를 종결한다. 교차점의 18% 수준이고 하이브리드로도 최저 시점 처리량이 기준선에 한참 못 미친다. 예시 A가 이 구간이다.

이 구간의 정당한 이유는 데이터 주권, 규제, 지연 시간, 모델 커스터마이징이다. 그렇다면 비용 논리로 포장하지 말고 그 이유로 결정하라. 그쪽이 검토도 빠르고 나중에 뒤집히지 않는다.

월 10억~50억. 아직 API가 싸다. 성장률을 보는 구간이고 지금 할 일은 전환이 아니라 계측이다.

월 50억 이상. 계산할 가치가 있다. 단 자기 숫자로 해야 하고 필요한 값은 네 개다.

• 요청별 입력·출력 토큰 길이 분포 (히스토그램)
• 지연 목표 아래에서 실측한 실효 처리량
• 시간대별 트래픽 곡선, 특히 야간 최저점의 초당 과금 토큰
• 투입 가능한 운영 인력의 실제 비용

앞의 세 개가 없으면 견적은 숫자놀음이다. 그리고 넣는 순서가 정해져 있다. 분포로 좌석 수를 구하고, 좌석 수로 필요 좌석률을 구하고, 필요 좌석률이 100%를 넘지 않는지 먼저 확인한다. 넘으면 물량 논의는 의미가 없다.

소형 모델은 이야기가 다르다. 8B급은 GPU 한 장에 올라가고 처리량이 훨씬 높아 좌석 수가 많아지고 필요 좌석률이 크게 내려간다. 이 글의 숫자를 그대로 적용할 수 없다. 다만 구조는 같다. 대절료 대 좌석 수이고, 필요 좌석률이 100%를 넘는지 먼저 본다.