종량 과금
텍스트 모델에서 가장 일반적인 과금 방식으로, 일반적으로 입력 및 출력 Token 사용량을 기준으로 과금됩니다
종량 과금은 텍스트 모델에서 가장 일반적인 과금 방식입니다.
간단히 말하면:
- 사용자가 모델에 입력한 내용은 일정량의 Token을 소모합니다
- 모델이 반환한 내용도 일정량의 Token을 소모합니다
- 시스템은 이러한 실제 사용량을 기준으로 비용을 정산합니다
왜 대부분의 텍스트 모델은 종량 과금을 사용할까요
텍스트 요청의 길이 차이가 매우 크기 때문입니다.
예를 들어:
- "안녕하세요" 한 문장을 보내면 소모량이 매우 적습니다
- 긴 컨텍스트, 긴 프롬프트, 긴 문서를 보내고 모델이 긴 답변을 출력하도록 하면 소모량이 더 커집니다
따라서 종량 과금이 더 공정하고, 더 세밀한 방식이라고 할 수 있습니다.
종량 과금에서 가장 중요하게 봐야 할 것은 무엇인가요
초보자에게 정말 중요한 것은 과금 공식을 외우는 것이 아니라, 아래 내용을 이해하는 것입니다:
입력이 길수록, 컨텍스트가 많을수록, 출력이 길수록 일반적으로 비용이 더 높아집니다.
이 때문에 많은 사용자가 처음에는 "분명 질문은 하나만 했는데 왜 비용이 낮지 않지?"라고 느끼게 됩니다. 모델이 실제로 보는 내용이 마지막 한 문장만이 아닐 수 있기 때문입니다. 다음이 함께 포함될 수 있습니다:
- 대화 기록
- 시스템 프롬프트
- 추가 컨텍스트
- 도구 호출 관련 내용
비용에 영향을 주는 일반적인 요소
1. 입력 길이
프롬프트가 길고 첨부 자료가 많을수록 입력 Token이 증가합니다.
2. 출력 길이
모델의 답변이 길수록 출력 Token이 증가합니다.
3. 대화 히스토리 컨텍스트
멀티턴 대화 시나리오에서는 클라이언트가 이전 대화 기록을 함께 전송할 수 있습니다.
4. 모델 자체
모델마다 단가가 다르므로, Token 수가 비슷하더라도 비용은 달라질 수 있습니다.
5. Group 전략
같은 모델이라도 서로 다른 Group에서는 가격 정책이 달라질 수 있습니다.
종량 과금 비용은 어떻게 최적화하나요
비용을 절감하고 싶다면, 가장 효과적인 방법은 보통 "모델 사용을 줄이는 것"이 아니라 "불필요한 소모를 줄이는 것"입니다.
권장 방법
- 프롬프트를 간결하게 작성하고, 중복되는 배경 설명을 피합니다
- 히스토리 메시지 길이를 제어합니다
- 의미 없이 모델이 지나치게 긴 답변을 출력하게 하지 않습니다
- 서로 다른 업무에 서로 다른 가격대의 모델을 매칭합니다
- 서로 다른 Key와 Group으로 테스트 트래픽과 운영 트래픽을 분리합니다
흔한 오해
- 마지막 질문 한 문장만 계산된다고 오해함
- 클라이언트가 많은 히스토리 컨텍스트를 몰래 함께 전송하고 있다는 점을 모름
- 고가 모델이 테스트 용도로 반복 호출됨
한 문장으로 이해하기
종량 과금의 핵심은 "요청 1회에 얼마인가"가 아니라, "이번 요청에서 입력과 출력이 총 얼마나 소모되었는가"입니다.
그러면 언제 건별 과금을 봐야 하나요?
주로 이미지, 비디오 또는 고정 동작형 인터페이스를 사용한다면, 다음 문서를 함께 확인해 보세요:
이 문서가 도움이 되었나요?
마지막 업데이트