제14장 — 토큰 경제학과 API 가격

LLM Primer VI: AI 시스템 확장하기를 챕터별로 걷는 워크스루의 열네 번째 글입니다. 제1장의 물리를 청구서의 라인 아이템에 연결하고, 첫 달의 청구서가 왜 팀이 모델링한 것과 닮지 않는 경우가 많은지 설명하는 장입니다.

이 장이 존재하는 이유

앞선 장들은 추론 비용을 물리적 사실 — HBM에 옮겨진 바이트, 행렬곱에 쓴 FLOPs, 요청이 소비한 GPU 초 — 로 다뤘습니다. 실리콘을 소유한 팀에게는 그 프레이밍이 맞습니다. 훨씬 더 많은, API에서 추론을 사 오는 팀에게는 비용 표면이 공급자가 청구하는 단위 — 토큰 — 에 의해 다시 그려집니다. 제14장은 왜 토큰이 그렇게 가격이 매겨지는지, 같은 호출의 입력과 출력 쪽이 왜 그렇게 다른 가격을 갖는지, 그리고 챗봇의 대화 이력과 추론 모델의 보이지 않는 생각이 얼마나 조용히 청구서에 오르는지에 대한 것입니다.

14.1 디코딩이 대역폭에 묶인 국면이라 출력은 입력보다 4~8배 비싸다

입력 토큰은 프리필 경로를 탑니다 — 조밀하고, 연산에 묶여 있으며, 프롬프트의 모든 위치에 대해 병렬이고, 정확히 GPU가 설계된 워크로드를 탑니다. 70B 모델에서 H100은 초당 수만 개의 입력 토큰을 처리합니다. 조작이 산술 강도가 높은 넓은 행렬곱이기 때문입니다. 출력 토큰은 디코드 경로를 탑니다 — 순차적이고, 메모리 대역폭에 묶여 있으며, 포워드 패스당 토큰 하나, 각 스텝은 HBM에서 KV 캐시 전체를 읽습니다. 같은 H100은 요청당 초당 50~100개의 출력 토큰을 만듭니다. 두 처리량 사이의 비율은 가격표가 반영하는 비율입니다. 2025년의 프런티어 모델은 백만 입력 토큰당 2~5달러, 백만 출력당 10~30달러를 청구합니다 — 4:1에서 8:1의 비대칭은 마진 선택이 아니라 저변 연산 비대칭의 직접 통과입니다. 캐시된 입력은 더 쌉니다. 공급자가 이전 요청에서 프리필 비용을 이미 지불했기 때문입니다. 배치 API는 반값입니다. 공급자가 유휴 용량 창에 작업을 스케줄할 수 있기 때문입니다. 추론 토큰은 출력 토큰입니다. 엔진 안에서 그것이 그것이기 때문입니다.

14.2 최적화 레버는 입력/출력 모양에 달려 있다

실수는 「토큰은 X 값이다」라는 하나의 마음속 숫자로 비용을 모델링하고 입력과 출력을 따로 분해하지 않는 것입니다. 8,500 입력 토큰을 보내고 600 토큰 응답을 받는 검색 중심의 고객 서비스 트리아지는 프런티어 가격에서 입력 비용에 지배됩니다(하루 10,000 요청 기준 대략 입력 $255 대 출력 $90). 같은 볼륨의 장문 초안 작성 시스템 — 2,200 입력 토큰 들어가고 3,000 출력 토큰 나옴 — 은 출력에 지배됩니다($66 입력 대 $450 출력). 두 경우 최적화 조언은 반대입니다 — 첫째는 프롬프트를 줄이고, 둘째는 응답을 줄이고, 지배 축에 유리한 가격 프로파일을 가진 모델로 라우팅합니다. 돌려 볼 만한 두 번째 분해는 테넌트나 워크로드별입니다. 멀티 테넌트 시스템은 거의 항상 상위 10퍼센트 테넌트가 지출의 절반 이상을 차지하는 파워로 편향을 보이며, 그 테넌트를 겨냥한 비용 최적화 작업은 롱테일에 걸쳐 균일하게 퍼진 작업보다 몇 배 더 회수됩니다.

14.3 컨텍스트 누적과 보이지 않는 추론 토큰이 청구서를 복리로 부풀린다

가장 비싼 토큰은 팀이 보내고 있는 줄 잊은 토큰입니다. API는 무상태입니다 — 모든 요청은 매 호출마다 전체 대화 이력을 입력으로 보냅니다. N턴 대화에 걸친 누적 입력 비용은 N에 대해 이차적으로 자라고, 프리픽스 캐시 크레딧을 뺍니다. 단일 턴 기준선으로 시스템 가격을 매겼던 팀은 여섯 달 뒤 평균 대화가 이제 여덟 턴이고 대화당 입력 비용이 대략 제곱만큼 곱해졌음을 발견합니다. 두 번째 조용한 곱셈 인자는 추론 토큰입니다. o1/o3, Anthropic의 확장 사고, DeepSeek R1, Google의 추론 변형 같은 모델은 눈에 보이는 답 앞에 큰 양의 내부 사고 — 종종 500 토큰 응답 뒤에 4,000~8,000 토큰 — 를 만듭니다. 그 토큰은 같은 출력 디코드 루프를 타고 출력으로 청구됩니다. 코드가 그것을 요청하지 않는 한 호출자에게 돌아오지 않습니다. 완화책은 API 응답의 usage 객체를 올바르게 계측하는 것 — prompt_tokens, cached_prompt_tokens, completion_tokens, reasoning_tokens, 그리고 공급자 특화 범주들 — 이고, 알 수 없는 범주는 조용히 버리지 않고 표시하는 것입니다. 공급자가 추가하는 모든 새 청구 차원은 팀의 사용 스키마에 나타나야 합니다. 그렇지 않으면 다음 청구서가 놀라움입니다.

제14장이 준비하는 것

팀이 자기 청구서를 입력 대 출력, 테넌트별, 범주별 분해로 읽을 수 있게 되면, 다음 질문 — 재무가 물을 질문 — 은 팀이 애초에 토큰당 값을 치러야 하는가입니다. 제15장은 대안을 걷습니다 — 추론을 내부로 가져오고, GPU를 임대하거나 사고, 대신 GPU 시간당 값을 치릅니다. 손익분기 산수는 깔끔합니다. 덜 깔끔하고, 대부분의 팀이 과소평가하는 것은 GPU 청구서에 없는 전용 쪽 원장의 모든 것입니다 — 플랫폼 엔지니어링, 보안 패치, 모델 업그레이드 안무, 노드가 함대에서 떨어질 때 답하는 온콜 순환.

다음 → 제15장: 서버리스 API 대 전용 인프라. 손익분기 공식, 숨은 라인 아이템, 그리고 둘 다가 답인 하이브리드 자세.