GLM API는 "월 정액으로 마음껏 쓰는" 상품이 아니라 실제 사용량에 따라 과금되는 서비스입니다. 많은 팀이 첫 청구서를 보고 의아해합니다. 요청 수는 많지 않은데 왜 예상보다 비용이 높을까요? 원인은 대개 단가가 아니라 입력이 너무 길거나, 출력이 통제되지 않았거나, 캐시가 적중하지 않았거나, 실패한 요청을 재시도하면서 같은 내용을 다시 생성했기 때문입니다.

이 글에서는 구체적인 단가를 나열하지 않습니다. 가격은 모델, 컨텍스트 구간, 프로모션에 따라 달라지기 때문입니다. 대신 과금 구조와 비용이 발생하는 지점, 산정과 절감 방법을 설명하고 마지막에 실행 가능한 통제 목록을 제시합니다. 현재 가격은 사이트의 모델 가격과 즈푸(Zhipu) 공식 가격 페이지를 기준으로 확인하세요.

안내: 즈푸(Zhipu), GLM, BigModel은 해당 권리자의 상표입니다. 이 글은 기술 설명 목적으로만 작성되었으며 즈푸와 제휴 또는 대리 관계가 없습니다. 과금 규칙과 가격은 변경될 수 있으므로 주문 전에 공식 문서와 청구서 페이지를 확인하세요.

1. 과금의 기본 단위

텍스트 모델은 토큰을 기본 단위로 사용합니다. 즈푸 공식 문서가 제시하는 경험적 환산은 대략 토큰 1개가 한자 1.6자에 해당한다는 것이지만, 실제 수량은 토크나이저와 텍스트 내용에 따라 달라지며 최종적으로는 API가 반환하는 usage 값을 기준으로 합니다. 즉, 추정은 예산 수립에만 쓸 수 있고 청구서를 대신할 수는 없습니다.

모든 모델이 토큰으로 과금되는 것은 아닙니다. 이미지 생성, 영상 생성, 음성 합성, 음성 복제, 실시간 오디오·비디오, 지식베이스 파싱 등은 호출 횟수, 분, 문자 수 또는 페이지 단위로 과금될 수 있습니다. 멀티모달 제품을 만들 때는 단가를 논하기 전에 과금 단위부터 확인해야 합니다.

2. 입력과 출력을 따로 계산하는 이유

하나의 요청에는 보통 입력 토큰과 출력 토큰이 포함되며, 두 가지는 별도로 가격이 매겨집니다. 일반적으로 출력이 더 비쌉니다. 장문 컨텍스트 모델은 입력 길이에 따라 구간이 나뉠 수 있습니다. 예를 들어 32K를 경계로 그 이상은 더 높은 구간에 들어가며, 일부 모델은 출력 길이로도 구간을 나눕니다. 따라서 "같은 모델"이라도 사용 방식에 따라 단위 비용이 달라질 수 있습니다.

비용에 영향을 주는 것은 요청 수보다 요청마다 함께 보내는 컨텍스트입니다. 지식베이스 전체, 모든 대화 이력, 수십 개의 도구 정의를 프롬프트에 넣으면 입력이 빠르게 불어납니다. 더 흔한 낭비는 출력입니다. 최대 출력 길이를 설정하지 않으면 모델이 끝없이 답변을 이어 가고 비용도 자연스럽게 올라갑니다.

비용 항목 과금 기준 흔한 발생 상황 통제 방법
입력 토큰 캐시에 적중하지 않은 입력 기준 긴 프롬프트, 다중 턴 이력, 도구 정의 컨텍스트 축소, 요약
출력 토큰 생성된 내용 기준 장문 작성, 코드 생성 최대 출력 길이 설정
캐시 적중 적중 부분은 할인 가격 고정 시스템 프롬프트, 지식베이스 접두사 접두사 안정적으로 유지
장문 컨텍스트 구간 임계값 초과 시 단가 변경 장문 문서, 코드베이스 분석 분할, 요약, 필요 시 로딩
재시도와 실패 이미 생성된 부분이 과금될 수 있음 타임아웃, 스트리밍 중단, 중복 제출 멱등성, 백오프, 중복 제거
멀티모달과 도구 호출 횟수, 분, 페이지 등 기준 이미지 생성, 음성, 검색, 파싱 별도 산정, 호출 제한

3. 캐시 적중: 반복되는 접두사를 절약하는 방법

즈푸는 컨텍스트 캐시 기능을 제공하며, 공식 문서에서 주로 설명하는 것은 암시적 캐시입니다. 시스템이 반복되는 내용을 자동으로 인식하므로 사용자가 캐시 지점을 직접 표시할 필요가 없습니다. "고정 시스템 프롬프트 + 고정 지식베이스 + 변화하는 질문" 같은 상황에 적합합니다.

적중률을 높이려면 최소 세 가지 조건을 충족해야 합니다. 반복되는 접두사가 충분히 길어야 하며 공식 권장 기준은 500토큰 이상입니다. 접두사 내용이 완전히 같아야 하며, 공백 하나만 달라도 적중하지 않을 수 있습니다. 캐시는 비동기로 생성되므로 첫 요청 후 잠시 기다렸다가 후속 요청을 보내는 편이 효과적입니다. 적중 여부는 usage.prompt_tokens_details.cached_tokens에서 확인할 수 있습니다.

캐시가 만능은 아닙니다. 짧은 프롬프트, 매번 달라지는 내용, 자주 수정되는 지식베이스는 적중시키기 어렵습니다. 캐시 저장이 별도로 과금되는지, 할인 폭이 얼마인지는 공식 가격 페이지를 기준으로 합니다. 캐시는 비용 모델의 기본 전제가 아니라 최적화 항목으로 다루는 것이 안전합니다.

4. 장문 컨텍스트, 배치, 멀티모달

장문 컨텍스트는 실용적이지만 예산을 가장 쉽게 초과하는 지점이기도 합니다. 계약서, 논문, 코드베이스를 처리할 때는 먼저 세 가지를 물어야 합니다. 정말로 전체 내용을 한 번에 넣어야 하는가? 먼저 검색한 뒤 이어 붙일 수 있는가? 구간별로 처리한 뒤 합칠 수 있는가? 많은 작업은 "검색 + 요약"만으로 완료할 수 있으며, 전체를 그대로 밀어 넣는 것보다 비용이 훨씬 낮습니다.

배치 작업은 Batch 인터페이스를 고려할 수 있습니다. 공식 문서에 따르면 지원 모델을 Batch 인터페이스로 호출하면 대체로 할인이 적용됩니다. 오프라인 라벨링, 대량 요약, 데이터 정제처럼 실시간 응답이 필요 없는 상황에 적합합니다. 대신 지연이 길어지고 작업 오케스트레이션이 복잡해지므로, 큐와 결과 검증 체계를 갖춘 팀에 알맞습니다.

멀티모달 기능은 별도로 산정해야 합니다. 이미지 생성은 장당, 이미지 이해는 보통 토큰 기준으로 과금됩니다. 음성 합성은 문자 수나 분, 지식베이스 파싱은 페이지 기준입니다. 이런 비용을 텍스트 예산에 섞으면 월말에 반드시 장부가 맞지 않습니다.

5. 재시도, 스트리밍 중단, 숨은 비용

실패한 요청이 항상 무료인 것은 아닙니다. 서버가 일부 내용을 생성한 뒤 타임아웃되면 그 사용량은 여전히 과금될 수 있습니다. 스트리밍 연결이 끊겼을 때도 이미 생성된 부분이 청구서에 포함될 수 있습니다. 따라서 재시도 전략은 절제되어야 합니다. 속도 제한, 5xx, 네트워크 타임아웃에만 재시도하고, 지수 백오프를 사용하며, 최대 횟수를 정해야 합니다.

또 다른 숨은 비용은 중복 제출입니다. 사용자가 버튼을 연속으로 누르거나, 프런트엔드가 타임아웃 후 자동으로 다시 보내거나, 큐가 같은 메시지를 중복 소비하면 추가 요청이 생깁니다. 요청 ID로 멱등성을 확보하거나 게이트웨이 계층에서 중복을 제거하는 편이 사후 정산보다 훨씬 효과적입니다.

엔지니어링 비용도 계산에 넣어야 합니다. 로그, 모니터링, 평가, 사람의 검수 모두 비용입니다. 모델 호출료는 전체 비용의 일부일 뿐이므로, 호출료를 조금 아끼려고 몇 배의 인력을 수작업 보정에 투입해서는 안 됩니다.

6. 월 예산을 산정하는 방법

산정은 네 단계로 나뉩니다. 월 호출량을 집계하고, 평균 입력과 출력을 추정하고, 캐시 적중률을 가정한 뒤, 현재 단가를 적용합니다. 여러 모델의 잔액과 사용량을 한곳에서 관리하고 싶다면 ZSQH AI Gateway에 등록한 뒤 통합해서 확인할 수 있습니다. 구체적인 가격은 여전히 모델 가격 페이지를 기준으로 합니다. 아래 코드는 계산 틀일 뿐이며, 단가는 공식 가격 페이지에서 읽어 채워 넣어야 합니다.

# 예산 모델: 모든 단가는 자리표시자이므로 현재 공식 가격으로 교체하세요.
monthly_calls = 300_000
avg_input_tokens = 1_200
avg_output_tokens = 300
cache_hit_rate = 0.35
input_rate = 0.0       # 입력 단가, 공식 가격 페이지 확인
output_rate = 0.0      # 출력 단가
cache_rate = 0.0       # 캐시 적중 단가

uncached_input = avg_input_tokens * (1 - cache_hit_rate)
cached_input = avg_input_tokens * cache_hit_rate
per_call = (
    uncached_input * input_rate
    + cached_input * cache_rate
    + avg_output_tokens * output_rate
)
print(f"예상 월 비용: {monthly_calls * per_call:.2f} 위안")

산정할 때는 여유를 두세요. 신규 업무의 실제 입력은 설계 당시보다 긴 경우가 많고, 재시도와 실패도 사용량을 늘립니다. 먼저 소규모 트래픽으로 2주간 운영한 뒤 실제 usage 데이터로 가정값을 교체하고 예산을 확정하는 것이 좋습니다.

7. 예산 통제 체크리스트

  1. 환경별, 서비스별로 독립된 한도 상한을 설정합니다.
  2. 모든 요청에 최대 출력 길이와 타임아웃을 설정합니다.
  3. 시스템 프롬프트 순서를 고정해 캐시 적중률을 높입니다.
  4. 장문 문서는 먼저 검색과 요약을 거친 뒤 장문 컨텍스트 투입 여부를 결정합니다.
  5. 재시도 가능한 오류에만 재시도하고, 백오프와 횟수 상한을 둡니다.
  6. 매일 사용량을, 매주 청구서를 확인하고 이상 증가는 즉시 추적합니다.
  7. 오프라인 작업은 Batch를 우선하고, 실시간 작업만 온라인 인터페이스를 사용합니다.

8. 자주 묻는 질문(FAQ)

1. GLM API는 구체적으로 얼마인가요?

가격은 모델, 컨텍스트 구간, 프로모션에 따라 달라지므로 이 글에서는 고정 숫자를 제시하지 않습니다. 사이트의 모델 가격 또는 즈푸 공식 가격 페이지를 확인하고, 최종적으로는 콘솔 청구서를 기준으로 하세요.

2. 캐시 적중은 어떻게 과금되나요?

캐시에 적중한 부분은 할인 가격으로, 적중하지 않은 입력은 표준 입력 가격으로 과금됩니다. 구체적인 할인율과 저장 비용은 공식 가격 페이지를 기준으로 하며, 적중량은 usage 필드에서 확인할 수 있습니다.

3. 요청이 실패해도 요금이 부과되나요?

실패 단계에 따라 다릅니다. 이미 일부 내용이 생성되었다면 실제 사용량 기준으로 과금될 수 있습니다. 반면 파라미터 오류나 자격 증명 오류는 보통 생성 비용을 발생시키지 않습니다. 청구서 상세를 기준으로 판단하세요.

4. 장문 컨텍스트는 항상 더 비싼가요?

대체로 더 비쌉니다. 많은 모델이 입력 길이로 구간을 나누며, 임계값을 넘으면 단가가 올라갑니다. 분할이나 검색으로 해결할 수 있는 작업이라면 굳이 장문 컨텍스트를 사용할 필요가 없습니다.

5. 기존 비용을 빠르게 줄이려면 어떻게 해야 하나요?

먼저 세 가지를 하세요. 최대 출력 길이를 제한하고, 시스템 프롬프트를 압축하고, 캐시 적중률을 높이는 것입니다. 이 세 가지가 보통 모델을 교체하는 것보다 빠르게 효과를 내고 통제도 쉽습니다.

관련 글