Provider 청구서는 단 하나의 질문에만 잘 답합니다. 즉, 계정이 얼마를 지출했는지입니다. 하지만 팀이 실제로 던지는 거의 모든 다른 질문에는 답하지 못합니다. 어떤 기능이 이 지출을 발생시켰는가? 어느 팀의 실험이 화요일 사용량을 두 배로 늘렸는가? 여섯 번 실패할 때마다 재시도하는 통합에 속한 키는 무엇인가? 청구서는 총액만 알고 있습니다. 그 이야기는 모릅니다.
요청별 비용 귀속(Per-request cost attribution)은 사건이 발생하는 순간 그 이야기를 기록하는 관행입니다. nRouter의 LLM 비용 최적화 프레임워크에 문서화된 바와 같이, 모든 요청은 모델, 입력 및 출력 토큰, 비용, 지연 시간(latency), 재시도 횟수(retry count), 그리고 제공업체 결과(provider outcome)를 기록하며 — 이를 생성한 팀, 키, 프로젝트에 귀속합니다.
각 필드가 존재하는 이유는 실제 비용 검토가 그것을 요구하기 때문입니다:
- Model— 티어 결정(어떤 작업이 프리미엄 모델을 얻는지)은 오직 작업 유형별 실제 모델 사용량과 비교하여 검토될 수 있기 때문입니다. -
- Input/output tokens— 컨텍스트 성장 및 장황한 출력은 별개의 문제이며 별도의 해결책이 필요합니다. 총합계는 어느 쪽 문제를 가지고 있는지 숨깁니다. -
- Latency— 지연 시간(latency) 없이 비용을 검토하는 것은 사용자가 기다리는 시간을 통해 비용으로 지불하게 만드는 절감액을 초래하기 때문입니다. -
- Retries— 실패로 인한 낭비는 성공만을 기록하는 장부에서는 보이지 않습니다. 다섯 번째 시도에서 성공한 요청은 다섯 번의 시도를 비용으로 발생시킵니다. -
- Provider outcome— 폴백(fallback) 활동 역시 자체적인 비용 서명(cost signature)을 가지고 있기 때문입니다. -
- Team, key, project— 귀속되지 않은 지출은 주인이 없으며, 소유되지 않은 지출은 결코 최적화되지 않기 때문입니다.
대시보드에만 존재하는 기록들은 사고가 발생했을 때 검토됩니다. 비용 내보내기(Spend exports) — 이 프레임워크는 CSV 내보내기를 문서화합니다 — 는 비용 검토를 일상적인 활동으로 만듭니다. 기간의 기록을 가져와 팀 및 모델별로 그룹화하고, 품질 결과 옆에서 비용을 읽어낼 수 있게 합니다. 낭비를 가장 빨리 찾아내는 팀들은 최고의 대시보드를 가진 팀들이 아니라, 그들의 데이터가 도구 외부로 나가는 팀들입니다.
이 프레임워크는 비용 통제를 예방(prevent), 라우팅(route), 귀속(attribute) 순서로 처리하며, 이 순서는 의존성 체인입니다. 예방(캐싱, 사전 할당 예산 등)과 라우팅(가장 저렴한 적합 모델 선택)이 결정을 내리고, 귀속은 그 결정들이 맞았는지 알아내는 방법입니다. 영수증 없이는 모든 비용 검토는 전설에 불과합니다. 하지만 영수증이 있다면 이는 산술 계산이 됩니다.
공개: 저는 nRouter 팀에서 근무하고 있습니다. 설명된 기능들은 링크된 페이지에 문서화되어 있습니다.
