내가 계속 마주쳤던 문제

나는 멀티 에이전트 (multi-agent) LLM 시스템을 운영하는 팀들과 함께 일합니다. 일반적인 패턴은 다음과 같습니다: 오케스트레이터 (orchestrator) 에이전트가 작업을 분해하고, 서브 에이전트 (sub-agents)들에게 할당하며, 이 서브 에이전트들이 때때로 다른 에이전트들을 호출합니다. 그리고 작업이 완료될 때쯤이면, 3번의 LLM 호출을 예상했으나 실제로는 10~20번의 호출이 발생해 있는 상황을 맞닥뜨리게 됩니다.

비용만이 문제가 아닙니다. 예측 불가능성이 문제입니다. 월요일에 0.30달러가 들었던 작업이 화요일에는 4달러가 들 수도 있습니다. 한 에이전트가 재시도 루프 (retry loop)에 빠졌거나 더 긴 추론 체인 (chain of reasoning)을 생성했기 때문입니다. 이는 대시보드를 확인했을 때나 알 수 있는 사실입니다.

모니터링 도구들 (Langfuse, Helicone, Datadog LLM Observability)은 "알아내는" 부분에는 능숙합니다. 무엇이 일어났는지 보여줍니다. 하지만 그때는 이미 돈이 다 써버린 후입니다.

나는 LLM 호출이 끝난 후가 아니라, 각 호출이 이루어지기 전에 결정을 내릴 수 있는 무언가를 원했습니다.

내가 만든 것

Token Budget Orchestrator는 기존의 LLM 클라이언트를 감싸는 (wrap) Python 및 Node SDK입니다. 각 호출 전에 다음을 수행합니다:

1. 호출에 사용할 토큰 (token) 수를 추정합니다.
2. 에이전트/사용자/프로젝트에 남은 예산이 있는지 확인합니다.
3. 라우팅 정책 (routing policies)을 평가합니다 (이 호출을 더 저렴한 모델로 보내야 할까요?).
4. 호출을 허용하거나, 차단하거나, 또는 경로를 재설정 (reroute)합니다.

호출이 끝난 후에는 실제 사용량을 기록하고 추정치를 조정 (reconcile)합니다.

pip install token-budget-orchestrator

from tbo import TBOClient, BudgetConfig

client = TBOClient(
...

요약 에이전트 (summarizer agent)가 일일 할당량인 100K 토큰을 다 써버리면, 실패하는 대신 Haiku 모델로 경로를 변경합니다. 호출하는 코드 측에서는 이런 일이 일어났는지 알 필요가 없습니다.

모든 것을 결정지은 설계 결정

나는 이것을 게이트웨이 (gateway)로 만들 수도 있었습니다 (LiteLLM이나 Bifrost가 하는 방식처럼). 모든 트래픽을 프록시 (proxy)를 통해 라우팅하고, 그곳에서 예산을 강제하는 방식입니다. 그 접근 방식은 이미 검증되었고 잘 작동합니다.

나는 다른 길을 선택했습니다: SDK가 당신의 프로세스 내에서 실행됩니다. 프롬프트 (prompts)는 결코 당신의 인프라를 벗어나지 않습니다. 당신과 LLM 제공업체 사이에 프록시가 위치하지 않습니다.

왜일까요? 제가 협업하는 팀들은 민감한 데이터 (sensitive data)를 다루기 때문입니다. 그들은 해당 서비스가 셀프 호스팅 (self-hosted) 방식이라 할지라도, 또 다른 서비스가 자신들의 프롬프트 (prompts)를 보는 것을 원치 않습니다. 신뢰 경계 (trust boundary)가 중요하기 때문입니다.

트레이드오프 (tradeoff): 코드를 직접 제어할 수 있다면 SDK를 우회할 수 있습니다. 이것은 협력적 시스템 (cooperative systems)을 위한 거버넌스 (governance) 도구이지, 적대적 코드 (adversarial code)에 대항하는 보안 경계 (security boundary)가 아닙니다.

정책 라우팅 (Policy routing)

예산 집행 (Budget enforcement)도 유용하지만, 제가 실제로 가장 많이 사용하는 기능은 정책 기반 모델 라우팅 (policy-based model routing)입니다:

from tbo import PolicyConfig, RoutingRule

policy = PolicyConfig(rules=[
...

에이전트 (agent) 코드는 자신이 무엇을 하고 있는지에 대한 메타데이터 (metadata)를 포함하여 client.chat(...)을 호출하기만 하면 됩니다. 그러면 SDK가 모델을 선택합니다. 이는 에이전트 코드를 수정하지 않고도 모델 할당 전략 (model allocation strategy)을 변경할 수 있음을 의미합니다.

동시성 문제 (The concurrency problem)

제가 파악하는 데 가장 오래 걸렸던 버그가 여기 있습니다.

5개의 에이전트가 동시에 예산을 확인한다고 가정해 봅시다. 각 에이전트는 "80K 토큰 사용됨, 100K 제한, 20K 남음"을 확인합니다. 각 에이전트는 작업을 진행합니다. 그들은 모두 10K 토큰을 사용합니다. 결과적으로 130K를 사용하게 되어 예산을 30% 초과하게 됩니다.

해결책은 예약 패턴 (reservation pattern)입니다. 에이전트가 예산을 확인할 때, SDK는 예상 토큰을 원자적 (atomically)으로 예약합니다. 호출 시 예상보다 적게 사용하면 차액이 해제됩니다. 더 많이 사용하면 초과분이 기록됩니다.

에이전트가 예산 확인 -> 10K 예약 -> LLM 호출 수행 -> 실제 사용량: 7K -> 3K 해제

단일 프로세스 (single-process) 설정의 경우, 이는 스레드 안전 (thread-safe) 딕셔너리 (dict)를 사용합니다. 멀티 프로세스 (multi-process, 하나의 예산을 공유하는 여러 서비스)의 경우, 원자성 (atomicity)을 위해 Lua 스크립트를 사용하는 선택적인 Redis 기반 엔진이 있습니다.

제가 다르게 했을 점

만약 처음부터 다시 시작한다면, Python SDK가 실제 운영 환경 (production)에서 사용되기 전까지는 Node SDK를 건너뛰었을 것입니다. 두 가지 언어를 지원하는 것은 유지보수 범위를 두 배로 늘리며, Node SDK는 본질적으로 아직 아무도 운영 환경에서 테스트하지 않은 포트 (port) 버전이기 때문입니다.

또한, 직접 구축하는 대신 첫날부터 LiteLLM의 프로바이더 추상화 (provider abstraction)를 통합했을 것입니다. 그들의 모델 카탈로그 (model catalog)와 재시도 로직 (retry logic)은 제가 가진 것보다 더 훌륭합니다.

대안들 (Alternatives)

현황에 대해 솔직하게 말씀드리자면 다음과 같습니다:

• LiteLLM은 게이트웨이 (gateway) 수준에서 예산 집행 (budget enforcement) 기능을 제공합니다. 이미 해당 프록시 (proxy)를 사용 중이라면 별도의 SDK가 필요하지 않을 수도 있습니다.
• TokenBudget (PyPI)은 데코레이터 (decorators)를 사용하여 코드 수준에서 예산 집행을 수행합니다. TBO보다 가볍지만 정책 라우팅 (policy routing) 기능은 없습니다.
• Bifrost (Maxim AI)는 계층적 예산 (hierarchical budgets) 기능을 갖춘 완전한 게이트웨이 (gateway)입니다.

TBO의 적합한 용도: 예산 집행과 모델 라우팅 (model routing)이 모두 필요하면서, 경로 상에 프록시 (proxy)를 두고 싶지 않고, 배포해야 하는 인프라 (infrastructure)가 아닌 임포트 (import)하여 사용할 수 있는 라이브러리 (library) 형태를 원하는 경우입니다.

Links

• GitHub: github.com/ricmmartins/tokenbudgetorchestrator
• PyPI: pip install token-budget-orchestrator
• npm: npm install token-budget-orchestrator

MIT 라이선스입니다. 이슈 (Issues) 및 피드백을 환영합니다.