멀티 에이전트 앱에는 저렴한 모델뿐만 아니라 토큰 예산이 필요합니다

팀이 AI 에이전트(AI agents)를 사용하기 시작할 때, 첫 번째 비용 제어 본능은 대개 단순합니다. 더 많은 트래픽을 저렴한 모델로 옮기는 것입니다.

그것이 도움이 되기는 하지만, 실제 운영상의 문제를 해결하지는 못합니다.

장시간 실행되는 워크플로(workflow)가 재정적으로 실패하는 이유는 특정 모델이 비싸기 때문이 아닙니다. 실행이 끝난 후 지출 체인을 아무도 설명할 수 없기 때문에 실패하는 것입니다.

어떤 API 키가 작업을 시작했는가? 어떤 프로젝트가 소유했는가? 각 단계에서 어떤 모델 경로(model route)를 사용했는가? 요청이 다른 경로로 폴백(fallback)되었는가? 세 번 재시도(retry)했는가? 최종 청구 비용은 어떤 잔액 버킷(balance bucket)에서 지불되었는가?

만약 이러한 질문에 답할 수 없다면, 저렴한 모델을 사용하는 것은 동일한 문제를 지연시킬 뿐입니다.

제어의 단위는 작업(task)이어야 합니다

대부분의 대시보드는 모델별, 일별 또는 제공업체(provider)별 지출을 보여줍니다. 이는 회계에는 유용하지만, 에이전트 작업에는 너무 거칠게(coarse) 분류되어 있습니다.

에이전트는 깔끔한 일일 행 단위로 돈을 쓰지 않습니다. 이들은 다음과 같은 작업 체인(task chains)을 통해 돈을 사용합니다:

연구 작업(research task)이 컨텍스트(context)를 확장함
코딩 작업(coding task)이 여러 모델을 호출함
재시도 루프(retry loop)가 실패한 단계를 조용히 반복함
폴백 경로(fallback route)가 사용된 모델을 변경함
보고서 생성 작업(report generation task)이 30~45분 동안 실행됨

운영자에게 필요한 것은 단순히 월간 한도(monthly cap)만이 아닙니다. 운영자에게는 작업당 예산 범위(per-task budget envelope)가 필요합니다.

작업 수준의 예산은 다음과 같이 말합니다: 이 워크플로는 이러한 경로 유형(route types)에 대해, 이러한 폴백 규칙(fallback rules)을 사용하여 최대 이 금액까지 지출할 수 있습니다. 경계를 넘어서면 워크플로를 중단하거나 새로운 결정을 요구하십시오.

이것은 제공업체 과금(provider billing)과는 다른 기본 단위(primitive)입니다.

경로 원장(Route ledgers)은 경로 선택만큼 중요합니다

라우팅(Routing)은 보통 비용을 낮추는 방법으로 제시됩니다. 더 쉬운 작업은 저렴한 모델로 보내고, 어려운 작업에는 프리미엄 경로를 예약하며, 백업을 준비해 두는 방식입니다.

그것은 제품의 절반에 불과합니다.

나머지 절반은 원장(ledger)입니다.

모든 모델 요청에 대해, 시스템은 나중에 비용을 설명할 수 있을 만큼 충분한 컨텍스트를 저장해야 합니다:

API 키 및 프로젝트 소유자 (API key and project owner)
요청된 모델 및 결정된 경로 (requested model and resolved route)
실제로 호출된 업스트림 모델 (upstream model actually called)
프리미엄/직접(premium/direct) 또는 저비용 풀(lower-cost pool)과 같은 경로 유형 (route type)
폴백 체인 (fallback chain)
재시도 횟수 (retry count)
입력 및 출력 토큰 사용량 (input and output token usage)
정산 버킷 또는 잔액 버킷 (settlement bucket or balance bucket)
지연 시간 및 에러 상태 (latency and error state)

그러한 원장(ledger)이 없다면, 라우팅 계층(routing layer)은 블랙박스(black box)가 될 수 있습니다. 대부분의 경우 비용을 절감할 수는 있겠지만, 사용자가 왜 특정 작업에 그렇게 많은 잔액이 소모되었는지 물었을 때 유용한 답변을 내놓을 수 없게 됩니다.

별도의 잔액 관리는 제품을 더 명확하게 만듭니다

Tokens Forge를 구축하며 배운 한 가지는 잔액의 의미론(semantics)이 중요하다는 점입니다.

프리미엄/직접 모델 액세스(Premium/direct model access)와 저비용 라우팅 액세스(lower-cost routed access)는 숨겨진 환율이 적용되는 동일한 지갑처럼 느껴져서는 안 됩니다. 이들은 서로 다른 기대치를 가지고 있습니다.

공식 모델 크레딧을 구매하는 사용자는 예측 가능한 프리미엄 액세스를 원합니다. 반면 저비용 경로를 사용하는 사용자는 할인된 처리량(throughput)을 원하며, 라우팅에 풀(pools), 백업(backups) 및 다양한 업스트림 동작이 포함될 수 있음을 이해합니다.

이러한 요소들을 명확한 버킷(buckets)으로 나누면 UI를 설명하기 쉬워지고 원장(ledger)을 감사(audit)하기에도 용이해집니다.

이는 연구 워크플로우(research workflows)에서 특히 중요합니다

Tokens Forge에는 AI Researcher 워크플로우도 포함되어 있습니다. 이로 인해 예산 문제가 더욱 명확해졌습니다.

짧은 채팅 요청은 이해하기 쉽습니다. 하지만 연구 실행(research run)은 다릅니다. 데이터를 수집하고, 분석을 생성하며, 빠르고 깊이 있는 모델들을 호출하고, 긴 보고서를 작성할 수 있습니다. 깊이에 따라 15분, 30분, 또는 45분 동안 실행될 수도 있습니다.

이러한 종류의 워크플로우에서는 실행 전후에 토큰 사용량이 반드시 가시화되어야 합니다. 사용자는 시작 전에 충분한 잔액을 보유해야 하며, 운영자는 실행 비용이 예상보다 많이 들 경우를 대비해 원장(ledger)을 갖추고 있어야 합니다.

이것이 우리가 AI Researcher를 단순한 별개의 눈속임(gimmick)이 아니라, 게이트웨이(gateway) 위에 구축된 워크플로우로 취급하는 이유입니다. 이는 회계 계층(accounting layer)이 충분히 훌륭한지를 판단하는 실질적인 테스트입니다.

요점 (The takeaway)

더 저렴한 모델은 유용합니다. 폴백 라우팅(Fallback routing)도 유용합니다. 통합 API(Unified APIs) 역시 유용합니다.

하지만 실제 제품을 위해서는 게이트웨이(gateway)에 예산 경계(budget boundaries)와 경로 수준의 증거(route-level evidence)도 필요합니다.

비용 제어 문제는 단지 다음과 같아서는 안 됩니다:

어떤 모델이 가장 저렴한가?

다음과 같아야 합니다:

어떤 작업(task)이 이 비용을 사용했는가, 어떤 경로(route)가 이 비용을 사용했는가, 그리고 그 지출이 허용된 것이었는가?

그것이 바로 우리가 Tokens Forge를 통해 구축하고 있는 방향입니다: 저비용 멀티 모델 API 액세스, 가시적인 경로 원장(route ledgers), 분리된 잔액 의미론(separate balance semantics), 그리고 토큰 사용을 명시적으로 만드는 AI 연구자(AI Researcher) 워크플로입니다.

https://tokens-forge.com/