누군가 LLM (Large Language Model) 비용을 어떻게 줄일 수 있는지 물을 때마다, 첫 번째 질문은 항상 "어떤 모델이 가장 저렴한가요?"입니다.

그것은 잘못된 질문입니다. 저는 이를 제대로 확인하기 위해 비용 시뮬레이터 (cost simulator)를 구축했습니다. 제가 모델링한 모든 시나리오에서, 가장 저렴한 모델은 거의 항상 동일한 아주 작은 모델이었습니다. GPT-5.4 nano는 기본적으로 거의 매번 순수 가격 면에서 승리합니다. 만약 그것이 전부라면, 모델 선택은 사소한 문제가 될 것이고 아무도 비용에 대해 생각하지 않을 것입니다.

흥미로운 점은 어떤 모델이 가장 저렴한가가 아닙니다. 돈이 실제로 어디로 흘러가는가 하는 점이며, 이는 모델의 이름이 아니라 사용 형태 (shape of your usage)에 의해 결정됩니다.

당신이 추측하는 숫자가 비용을 결정합니다

고객 지원 시나리오를 예로 들어보겠습니다. 다른 모든 조건은 동일하게 두고, 단 하나의 입력값만 변경하겠습니다: 평균 출력 길이 (average output length).

응답당 출력 토큰 (output tokens)이 350개일 때, nano는 월 약 $63가 소요되며, 비용은 입력과 출력이 거의 균형을 이룹니다.

출력을 1,400개로 늘리면—응답이 조금 더 장황해질 경우 발생하는 수준입니다—동일한 시나리오에서 비용은 월 $159로 급증합니다. 이제 출력 비용이 전체 청구액의 70%를 차지합니다.

슬라이더 하나가 바뀐 것입니다. 대부분의 사람들이 대수롭지 않게 넘기는 숫자("몇 백 토큰 정도겠지?")가 비용을 세 배로 늘렸고, 비용을 유발하는 핵심 요인을 완전히 바꾸어 놓았습니다. 그리고 출력은 비싼 토큰입니다. 대부분의 현재 모델에서 출력 가격은 입력 가격의 약 6배로 책정되어 있습니다. 출력 길이를 낮게 추측하는 것은 견적을 낼 때 저지를 수 있는 가장 비싼 실수입니다.

동일한 "가장 저렴한 모델", 다른 동인

이제 에이전트 (agent) 시나리오를 살펴보면, 입력 1,200, 출력 900, 일일 요청 1,500건입니다. nano 모델은 월 약 $111가 소요되며, 출력 비용은 그 중 약 52%를 차지합니다.

여기서 일어난 일을 주목하십시오: 가장 저렴한 모델은 변하지 않았습니다. 여전히 nano입니다. 하지만 동인 (driver)이 바뀌었습니다. 긴 답변을 지원하는 (Support) 시나리오는 출력 (output) 중심이었습니다. 반면, 더 많은 입력과 적당한 출력을 사용하는 에이전트 (agent) 시나리오는 입력과 출력의 균형에 더 가깝게 위치하며, 재시도 (retries)와 사용되지 않은 컨텍스트 (unused context)가 실제 비용 항목으로 나타나기 시작합니다.

이것이 핵심입니다. "Support"와 "agent"는 고유한 비용 프로필을 가지고 있지 않습니다. 여러분이 투입하는 토큰 형태 (token shape)가 비용을 결정합니다. 서로 다른 출력 가정을 가지고 동일한 에이전트 시나리오를 실행하는 두 사람은 무엇을 최적화해야 하는지에 대해 서로 다른 답을 얻게 됩니다.

보이지 않는 것이 비용을 발생시킵니다

동일한 에이전트 시나리오에서 더 비싼 모델 (Gemini 1.5 Flash)을 사용할 때, 아무도 예산에 편성하지 않는 두 가지 비용이 두드러졌습니다:

• 12%의 비율로 발생하는 재시도 (Retries): 월 약 $54
• 지불하고 있지만 사용하지 않는 컨텍스트 (Context): 월 약 $62

낭비되는 컨텍스트가 재시도 비용보다 더 컸습니다. 두 항목 모두 "토큰 수 × 가격"을 대략적으로 훑어볼 때는 나타나지 않습니다. 하지만 두 항목 모두 매달 조용히 실제 돈을 소모합니다.

모델 선택은 고정된 레버입니다. 형태가 판돈을 결정합니다.

가장 놀라웠던 부분은 이것입니다. 두 시나리오 모두에서, 제가 시도한 모든 출력 설정에 걸쳐 저렴한 모델과 고품질 모델 사이의 격차는 약 7배로 유지되었습니다. nano 대 Flash의 경우, Support 시나리오에서 약 7.3배, Agent 시나리오에서 약 7.3배였습니다.

따라서 모델을 교체하는 것은 한 번 당길 수 있는 알려진 약 7배의 고정된 승수 (multiplier), 즉 고정된 레버입니다. 하지만 여러분의 토큰 형태 (token shape)는 여러분이 곱하게 될 청구서의 절대적인 크기를 결정합니다. 모델에 대한 질문이 흥미로워지기도 전에 토큰 형태를 올바르게 설정하는 것이 중요합니다.

대부분의 사람들이 사용하는 순서는 거꾸로 되어 있습니다. 그들은 모델을 먼저 선택한 다음, 청구서를 보고 놀랍니다. 청구서는 그들이 전혀 검토하지 않았던 형태 (shape)에 의해 이미 결정되어 있었던 것입니다.

여러분만의 형태를 실행하십시오

제 수치를 그대로 믿으라는 것이 아닙니다. 그것은 저의 가정 (assumptions)이며, 핵심은 바로 이 가정들이 이 문제의 본질이라는 점입니다. 유용한 방법은 여러분만의 형태 (shape)를 실행해 보는 것입니다. 즉, 실제 출력 길이 (output length), 재시도율 (retry rate), 컨텍스트 사용량 (context usage)을 실행하여 어떤 요인 (driver)이 실제로 비용을 발생시키고 있는지 확인하는 것입니다. 제가 만든 도구는 시나리오별로 각 요인을 식별하고, 각각에 대한 달러 단위의 예상 비용을 표시해 줍니다.

그것이 바로 이 도구입니다: modelindex.io. 시나리오를 선택하고, 토큰을 설정하여, 돈이 어디로 흘러가는지 확인하십시오.

이 도구가 찾아낸 요인들이 여러분이 실제 운영 (production) 청구서에서 보는 것과 일치하는지 진심으로 알고 싶습니다. 그 부분이 제가 일반화하기에 가장 확신이 없는 부분이며, 제가 틀렸다는 말을 가장 듣고 싶은 부분이기도 합니다.