결론부터 말하자. 청구서가 오르는 것은 대부분 사용량이 늘어서가 아니다. 내가 했던 지능형 고객센터 프로젝트는 작년 상반기 월 청구서가 8000위안 안팎으로 안정적이었는데, 4분기에 23000위안으로 뛰었고 같은 기간 호출량은 40%만 늘었다. 늘어난 돈은 어디로 갔을까? 나는 세 달치 호출 로그를 꺼내 작업 유형, 입력 길이, 출력 길이, 재시도 횟수 네 가지 차원으로 집계했다. 문제는 명확했다. 네 가지 숨은 비용 블랙홀이 동시에 피를 흘리고 있었다.

먼저 정의를 내리자면, 뒤에서 헷갈리지 않기 위해서다. 대규모 모델 API의 비용 구조는 본질적으로 「입력 token + 출력 token + 실패 재시도로 발생한 무효 token」 세 부분의 합이며, 사용량 기반 과금은 단지 가격 책정 방식일 뿐, 비용 절감을 책임져 주지 않는다. 실제로 청구서를 결정하는 것은 모델 게이트웨이의 라우팅 전략과 컨텍스트 관리 전략이다.

블랙홀 1: 플래그십 모델로 거친 일 처리

이것이 가장 비싼 항목이다. 그 고객센터 시스템에는 티켓 분류, 감정 태깅, 의도 인식 세 가지 작업이 있었고, 하루 약 12만 건의 호출이 있었다. 당시 편하려고 전부 같은 플래그십 모델로 돌렸다. 그런데 이 세 가지 작업은 난이도가 어느 정도인가? 200자짜리 사용자 메시지를 주고 「물류 문의」인지 「판매 후 환불」인지 판단하는 일인데, 이런 일은 소형 모델이 대형 모델보다 오히려 안정적으로 해낸다. 레이블 공간이 그렇게 크지 않기 때문이다.

나는 작업별로 평가를 다시 돌렸다. 분류 작업을 중간 크기 모델로 바꾸자 정확도가 96.2%에서 95.7%로 떨어졌다. 0.5포인트 차이인데 단가는 한 자릿수 배 차이였다. 이 항목 하나만으로도 청구서의 40%를 줄일 수 있다.

블랙홀 2: 컨텍스트 이력 전체 재삽입

고객센터는 멀티턴 대화이고 평균 턴 수는 7.3턴이다. 개발팀은 간단하게 하려고 매 턴마다 전체 이력을 이어 붙였다. 첫 턴 입력은 800 token인데 일곱 번째 턴 입력은 4200 token이 되고, 매 턴마다 앞의 여섯 턴에 대해 반복해서 비용을 지불하고 있었다. 이 비용 곡선은 제곱급이라 사용량이 늘면 폭발한다.

더 골치 아픈 것은 이력 대부분이 현재 턴에는 전혀 가치가 없다는 점이다. 사용자가 세 번째 턴에서 「반품할 거예요」라고 말했고 일곱 번째 턴에서 「운송비는 누가 내나요」라고 물었는데, 앞의 인사말과 상품 설명은 전부 쓸모없는 token이다.

블랙홀 3: 실패 재시도 증폭

이것이 가장 은밀하다. 업스트림 속도 제한이나 타임아웃이 발생할 때 SDK는 기본적으로 세 번 재시도한다. 문제는 재시도 요청이 같은 긴 컨텍스트를 다시 완전히 보내는 경우가 많다는 것이다. 내가 집계해 보니 청구서의 약 11% token이 실패 재시도에서 나왔고, 이 부분 호출은 최종적으로 60%가 여전히 실패해서 순전히 헛불에 그쳤다. 재시도에 백오프와 멱등성 제어를 하지 않으면 한 번의 장애가 세 배의 무효 소비로 증폭될 수 있다.

블랙홀 4: 스트리밍 미절단 출력

출력 token은 보통 입력보다 비싸다. 당시 고객센터 응답에는 max_tokens를 설정하지 않아서 모델이 가끔 「과시」했다. 두 문장이면 끝낼 수 있는 환불 설명을 번호 붙은 절차 설명으로 길게 써 버렸다. 출력 길이 분포에서 P99는 P50의 여섯 배가 넘었다. 이렇게 늘어난 글자는 사용자가 전혀 보지 않는데 돈은 그대로 낸다.

다섯 가지 지혈 조치

첫째, 모델 등급별 라우팅. 나는 작업별로 세 등급을 만들었다. 단순 분류는 소형 모델, 표준 질의응답은 중간 등급, 복잡한 불만과 분쟁 조정만 플래그십 모델에 배치했다. 이 계층은 token8341 대규모 모델 API 통합 플랫폼에서 구성했는데, 작업 유형별로 태그를 붙여 자동 분기하므로 비즈니스 코드를 바꿀 필요 없이 게이트웨이 측에 규칙만 추가하면 된다. 전환한 첫 주에 분류 작업 부분 비용이 바로 한 등급 내려갔다.

둘째, 컨텍스트 슬라이딩 윈도우와 요약. 최근 세 턴의 원문은 유지하고 더 이전 대화는 100자 이내의 요약으로 압축했다. 실측 결과 평균 입력 길이가 3200 token에서 1400 token으로 줄었고 고객센터의 컨텍스트 연속성은 영향을 받지 않았다.

셋째, 멱등 재시도. 요청마다 고유 ID를 붙이고 게이트웨이 측에서 중복 요청을 식별해 결과를 그대로 재사용하며, 재시도 시 전체 컨텍스트가 아니라 실패한 조각만 다시 보낸다. 이 항목으로 재시도에서 발생하는 무효 token을 11%에서 3% 이내로 눌렀다.

넷째, 출력 길이 제약. 작업 유형별로 max_tokens 상한을 설정하고, 환불 설명 같은 고정 시나리오는 템플릿을 직접 주고 모델은 변수만 채우게 했다. 출력 token이 약 30% 줄었다.

다섯째, 습관이 아니라 작업에 따라 모델을 선택하라. 이 말은 헛소리처럼 들리지만 많은 팀이 게을러서 하나의 모델로 모든 것을 처리한다. 우리는 나중에 token8341 대규모 모델 API 통합 플랫폼에서 국산 모델과 해외 모델을 동일한 인터페이스에 올려 비교 테스트를 했는데, 같은 고객센터 말뭉치에서 DeepSeek와 Qwen은 중국어 업무 시나리오에서 충분히 쓸 만했고 가격은 대량 처리에 더 적합했다. 멀티 모델 통합 접속의 장점이 바로 여기에 있다. 모델을 바꿔도 SDK를 바꿀 필요 없이 base_url 한 줄만 바꾸면 된다.

사용량 기반 과금의 전제는 올바른 라우팅

「사용량 기반 과금, 더 나은 비용」이라는 말 자체는 틀리지 않았지만, 여기에는 전제가 있다. 바로 라우팅 전략이 올바라야 한다는 것이다. 사용량 기반 과금은 유휴 컴퓨팅에 비용을 내지 않도록 보장할 뿐, 잘못된 모델 선택에 비용을 내지 않도록 보장하지는 않는다. 청구서가 23000위안에서 9000위안대로 돌아왔고 사용량은 오히려 늘었는데, 이는 싼 플랫폼으로 바꿔서가 아니라 라우팅과 컨텍스트 이 두 가지를 제대로 했기 때문이다.

지금도 이해되지 않는 청구서를 들여다보고 있다면, 먼저 호출 로그를 작업 유형과 입력·출력 길이별로 나눠 살펴보길 권한다. 블랙홀은 보통 생각하는 곳에 있지 않다. token8341 대규모 모델 API 통합 플랫폼이 이런 비용 최적화 시나리오에서 도움이 될 수 있는 부분은 주로 모델 게이트웨이 계층으로, 등급별 라우팅, 속도 제한 폴백, 멀티 모델 통합 접속 같은 것이며 비즈니스 측에서는 거의 체감할 수 없다.

저자: 리윈룽

발행일: 2026년 10월 24일