제15장 — 서버리스 API 대 전용 인프라

LLM Primer VI: AI 시스템 확장하기를 챕터별로 걷는 워크스루의 열다섯 번째 글입니다. 손익분기 산수를 테이블에 올리고, 대부분의 팀에게 답을 뒤집는 플랫폼 엔지니어링 라인 아이템에 이름을 붙이는 장입니다.

이 장이 존재하는 이유

제14장은 팀에게 API 청구서가 무엇으로 이루어졌는지에 대한 깔끔한 그림과, 그것이 더 쌀 수 있을 것이라는 조용한 의심을 남겼습니다. 자연스러운 다음 질문은 팀이 애초에 토큰당 값을 치러야 하는가입니다. 대안은 추론을 내부로 가져와, 앞선 장들이 서술한 스택 위에 오픈 웨이트 모델을 돌리고, 대신 GPU 시간당 값을 치르는 것입니다. 절충에는 깔끔한 손익분기점이 있습니다. 덜 깔끔하고, 대부분의 팀이 과소평가하는 것은 GPU 청구서에 없는 전용 쪽 원장의 모든 것 — 플랫폼 엔지니어링, 보안 패치, 모델 업그레이드 안무, 노드가 함대에서 떨어질 때의 새벽 3시 호출 — 입니다. 제15장은 두 쪽을 진지하게 다루고, 언제 자체 호스팅이 답인지를 유도합니다.

15.1 손익분기 공식은 깔끔하고, 대체로는 미끼다

GPU는 시간당 처리량 × 활용률 × 3,600 출력 토큰을 만듭니다. 백만 토큰당 비용은 (gpu_시간당 / 시간당 토큰) × 1,000,000입니다. 손익분기는 그 숫자가 API의 백만당 가격과 같아지는 지점입니다. $3/시간의 H100에서 FP8로 도는 70B 모델이 활용률 60퍼센트에서 초당 800 토큰 총합으로 돌면 백만 출력 토큰당 대략 $1이 나옵니다. 프런티어 API는 $15을 청구합니다. 겉보기 절감은 14배 — 재무가 사랑하고 두 번째, 더 큰 라인 아이템을 놓친 자체 호스팅 논거입니다. 손익분기는 또한 활용률에 의존합니다 — 활용률 20~30퍼센트 아래에서는 자체 호스팅 백만당 비용이 API 요율을 넘어서고 GPU는 대체하려던 대안보다 비싸집니다. 활용률은 또한 트래픽 모양, 오토스케일링 품질, 그리고 팀이 같은 함대에 둘 이상의 워크로드를 담을 수 있는지의 함수입니다.

15.2 플랫폼 엔지니어링이 거래를 결정하는 라인 아이템이다

GPU 청구서는 더 작은 반쪽입니다. 더 큰 반쪽은 함대를 돌리는 팀입니다 — 엔진, 드라이버, 오케스트레이션, 오토스케일링, 관측 가능성, 보안. API 팀은 이 비용을 토큰당 가격을 통해 암묵적으로 지불하고, 자체 호스팅 팀은 인력으로 지불합니다. 유용한 어림잡기 — 하나의 서빙 GPU 함대(한두 모델 변형, 오토스케일링, 관측 가능성, 온콜, 분기별 업그레이드)는 대략 한 명의 정규직 플랫폼 엔지니어에 SRE 일부를 요구합니다. 더 다양한 함대 — 여러 엔진, 여러 모델, 멀티 테넌트 스케줄링 — 는 두세 명에서 넷을 요구합니다. 엔지니어당 완전 부담 $300k 기준으로 연간 플랫폼 청구서는 $300k~$1.2M입니다. 자체 호스팅이 회수되는 월간 트래픽 손익분기는 월 2억에서 10억 출력 토큰 사이 어딘가입니다. 그 아래에서는 엔지니어링 오버헤드가 토큰 절감을 초과하고 팀은 API에 남아야 합니다. 그 위에서는 절감이 지배합니다. 플랫폼 엔지니어링은 또한 부드러운 곡선이 아니라 계단 함수로 옵니다 — 첫 채용이 함대를 올리고, 두 번째는 첫 번째가 주말 온콜을 감당하지 못해서 오고, 세 번째는 함대가 멀티 리전으로 커질 때 옵니다.

15.3 현실적 자세는 하이브리드, 그리고 라우터가 하중 지지 부품

프로덕션에 들어간 지 1년 이상 지난 팀에게 가장 깔끔한 결정 — 전부 API나 전부 전용 — 은 좀처럼 옳지 않습니다. 정상 상태의 예측 가능한 워크로드(야간 배치, 예약 리포트, 분류 큐)는 계획된 전용 용량에 잘 담깁니다. 폭발적 워크로드(바이럴 스파이크, 티켓 홍수, 신규 코호트 출시)는 API의 탄력성을 필요로 합니다. 엄격한 지연 워크로드(대화형 완성, 음성)는 코로케이션된 전용 배포로부터 이득을 봅니다. 지연 없는 워크로드(야간 보강, 재인덱싱)는 반값 배치 API로부터 이득을 봅니다. 하이브리드를 지지하는 아키텍처는 애플리케이션 경계의 라우터로, 각 요청을 지연 예산, 복잡도, 현재 백엔드 활용률로 분류하고 SLA를 만족하는 가장 싼 백엔드로 디스패치합니다. 다듬어진 라우터는 API 내 모델 라우팅도 합니다(단순 쿼리에는 값싼 모델, 복잡한 것에는 프런티어, 필요한 것에는 추론 층). 두 번째 이차적 이득은 선택권입니다 — 워크로드는 애플리케이션 코드가 아니라 라우터 정책을 바꿈으로써 경계를 넘어 이동할 수 있습니다. 그리고 전용 경우는 종종 두 번째 워크로드 — 그렇지 않으면 API로 갔을 워크로드 — 가 이미 값을 치른 GPU에 편승할 때에만 회수됩니다. 하나의 워크로드로 전용을 평가하는 팀은 대개 옮기지 않고, 워크로드 포트폴리오로 생각하는 팀은 옮기고 아낍니다.

제15장이 준비하는 것

제15장은 에이전트가 도입한 「API 호출」이나 「모델 서빙」 어디에도 맞지 않는 워크로드 부류에 이름을 붙였습니다 — LLM이 생성한 코드의 실행 환경. 이것은 격리와 패키지 유연성이 필요한 에이전트에 따라 서버리스 함수, 마이크로 VM(Firecracker, gVisor), 또는 WASM 샌드박스에 삽니다. 제16장은 자세 선의 어느 쪽에서도 적용 가능한 비용 절감 수의 카탈로그로 이 권을 닫습니다 — 지능형 모델 라우팅, 애플리케이션 수준 컨텍스트 압축, 배치 API, 시맨틱 캐시 — 지난달 청구서의 3분의 1이나 절반으로 복리로 쌓이는 수들입니다.

다음 → 제16장: 프로덕션의 비용 절감 전략. 지난달의 청구서를 다음 달의 절감으로 바꾸는 복리 수들.