Novita가 최근 LLM 가격 정책을 업데이트했습니다. 플랫폼을 통해 프로덕션 추론(inference)을 실행하는 팀이라면, 이 문장을 접하는 즉시 현재 지출 내역을 점검해야 합니다. API 요율 변경은 결코 편리한 시점에 찾아오지 않으며, 여러 모델 티어에 걸쳐 적용될 경우 월간 비용(monthly burn)에 미치는 영향은 예상보다 훨씬 클 수 있습니다.
추론 가격 책정에 주목해야 하는 이유
대부분의 현대적인 AI 애플리케이션은 자체 관리형 GPU 클러스터 기반으로 구축되지 않습니다. 개발자들이 Novita와 같은 추론 제공업체로 요청을 라우팅하는 이유는, 그렇지 않을 경우 하드웨어를 확보하고, vLLM 또는 TGI 배포를 관리하며, 트래픽 급증 시 콜드 스타트(cold start) 문제를 처리해야 하기 때문입니다. 이러한 편의성은 가치가 있지만, 그만큼 비용이 발생합니다. 생성되는 모든 토큰은 사용자 세션, 백그라운드 작업 및 내부 도구 전반에 걸쳐 누적되어 청구 금액에 합산됩니다.
제공업체가 가격을 조정하면 그 영향은 전체 스택으로 파급됩니다. 하루에 만 건의 고객 대화를 처리하는 챗봇은 일주일에 4,000만 개의 입력 토큰과 1,200만 개의 출력 토큰을 소비할 수 있습니다. 100만 토큰당 요율이 단 몇 달러만 변해도 월간 차액은 금세 상당한 금액이 됩니다. 자본이 부족한(bootstrapped) 제품이나 마진이 적은 팀의 경우, 이러한 차이가 수익성을 완전히 갉아먹을 수 있습니다. 브라우저 확장 프로그램으로 실행되는 코딩 어시스턴트, 밤새 작동하는 배치 요약 파이프라인, 또는 페이지를 로드할 때마다 모델에 쿼리를 보내는 내부 조회 도구 모두 동일한 취약점을 안고 있습니다. 이들의 단위 경제성(unit economics)은 다음 토큰의 정확한 가격에 달려 있기 때문입니다.
Novita에서 변경된 사항
Novita는 카탈로그 내의 서로 다른 모델에 영향을 미치는 새로운 비용 체계를 도입했습니다. 회사는 일괄적으로 동일한 비율의 인상이나 인하를 적용하지 않았습니다. 대신 모델별로 조정 사항이 다르므로, 귀하가 정확히 어떤 엔드포인트를 사용하느냐에 따라 청구 금액이 달라질 것입니다.
애플리케이션의 모든 트래픽을 단일 대규모 언어 모델(LLM)로 라우팅한다면 계산은 간단합니다. 이전 요율과 새 요율을 비교하여 손실 또는 절감액을 예측하면 됩니다. 하지만 대부분의 프로덕션 설정은 훨씬 복잡합니다. 팀들은 종종 간단한 쿼리는 가벼운 모델로 보내고, 복잡한 추론 작업에는 고성능 모델을 예약하는 라우팅 로직을 유지합니다. 다른 팀들은 지연 시간(latency)과 품질을 비교하기 위해 여러 모델에 대해 A/B 테스트를 수행하기도 합니다. 이러한 시나리오에서는 단 한두 개의 모델에서 발생하는 가격 변동만으로도 전체 비용 구조가 왜곡될 수 있습니다.
구체적인 토큰당 및 요청당 수치는 Narevbot이 Dev.to에 게시한 상세 분석 내용을 통해 확인할 수 있습니다. 정확한 요율표는 여기에서 검토할 수 있습니다: https://dev.to/narevbot/changes-to-llm-pricing-novita-3plc
기억에 의존하거나 문서 어딘가에 묻혀 있는 오래된 스크린샷을 믿지 마십시오. 다음 분기 계획을 세우기 전에 해당 소스에서 직접 최신 수치를 확인하십시오.
노출 위험을 점검하는 방법
가정이 아닌 데이터로 시작하십시오. Novita 대시보드에 로그인하여 지난 2~3개월간의 사용 내역을 내보내기 하십시오. 해당 데이터를 모델별, 작업 유형별로 세분화하십시오. 어떤 엔드포인트가 예산의 대부분을 소비하고 있는지, 어떤 엔드포인트가 요청당 가장 많은 토큰을 생성하는지 파악해야 합니다.
다음과 같은 패턴을 확인하십시오:
- 집중 위험(Concentration risk). 지출의 70%가 하나의 모델에 집중되어 있고 그 모델의 가격이 인상되었다면, 즉각적인 조치가 필요합니다. 지출이 8개의 모델에 분산되어 있고 그중 3개의 가격이 변동되었다면 계산은 더 오래 걸리겠지만, 여전히 위험 요소는 실재합니다.
- 토큰 팽창(Token bloat). 프롬프트에 불필요한 컨텍스트가 과도하게 포함되어 있는지 확인하십시오. 긴 시스템 프롬프트, 반복적인 퓨샷(few-shot) 예시, 장황한 XML 형식은 모두 입력 비용을 부풀립니다. 가격 업데이트는 불필요한 부분을 쳐내기에 가장 좋은 명분입니다.
- 출력 비효율성(Output inefficiency). 애플리케이션이 긴 답변을 요청하지만 실제로는 처음 몇 문장만 사용한다면, 버려지는 토큰에 대해서도 비용을 지불하고 있는 셈입니다.
max_token제한과 중단 시퀀스(stop sequences)를 조정하십시오. - 유휴 백그라운드 작업(Idle background jobs). 보고서를 생성하거나 문서를 임베딩하는 예약 작업이 필요 이상으로 자주 실행되고 있을 수 있습니다. cron 스케줄과 배치 크기를 확인하십시오.