다중 파일 에이전트 파이프라인에서 비용 관리 어떻게 하시나요?

실패한 단계에서 발생하는 낭비는 보통 라우팅 문제가 아니라 검증 문제입니다. 저희가 구축한 다단계 파이프라인에서는 LLM 호출 앞에 결정론적 필터를 배치해서, 대부분의 분류 작업은 모델을 거치지 않게 하고 모호한 경우에만 비싼 모델 단계를 호출하도록 했습니다.

LiteLLM은 공급자 전환 부분을 잘 처리해주고, 폴백 체인을 통해 여러 모델에서 작동합니다. 직접 호스팅하기 싫다면 OpenRouter도 괜찮고요. 하지만 낭비되는 단계는 오케스트레이션의 문제이니 Hatchet이나 Tempo 같은 도구를 살펴보는 걸 추천합니다.

OpenRouter랑 비슷한 routescope.ai도 찾아봤는데, 이거 꽤 괜찮더라.

모델 라우팅, 폴백, 단계별 토큰 추적을 수행하는 게이트웨이가 이 문제에 적합한 계층입니다. 낭비는 보통 기본 가격보다는 실패한 단계가 계속 재시도되면서 발생하거든요. 저희는 단계별 지출을 추적하고 공급자 간에 폴백이 되도록 직접 구축했는데, 실제로 손실을 막아주는 핵심은 단계별 출력을 점수화해서 실패한 단계가 무작정 수십 번 재시도되지 않게 차단하는 것입니다.

u/Future_AGI가 말한 내용에 동의하려고 들어왔음. 진짜 지갑 털어가는 주범은 기본 모델 토큰 가격이 아니라 걷잡을 수 없이 돌아가는 재시도 루프임.

이번 주에 TypeScript 워크스페이스에서 Cline을 엄청 굴려봤는데(1,000줄이 넘는 파일을 계속 주고받으면서), 조용하고 빠르게 반복되는 레이트 리밋 루프에 계속 걸리더라. 유료 계정에서 명시적인 제한 없이 돌리면 에이전트가 문법 오류나 컴파일 오류를 스스로 고치려다 꼬였을 때 시간당 수천 번의 요청을 날리는 건 일도 아님...

맥락을 좀 더 추가하자면, 에이전트가 사소한 TypeScript 오류를 스스로 수정하려고 할 때 몇 초 만에 똑같은 호출을 5번씩 날리는 걸 보고 이 문제를 알게 됐음. 스크립트 구조에 대해 궁금한 거 있으면 언제든 물어보셈!