에이전트 한 단계에 12만 토큰: 사용처와 해결 방법
자율 에이전트는 에이전트 루프의 각 단계에서 전체 컨텍스트를 반복적으로 보내기 때문에 예상보다 훨씬 많은 토큰을 소비할 수 있습니다. 이 글은 Uma Computer가 실제 원인이 대화 기록이 아니라 시스템 지시문, 도구 스키마, 메모리의 반복적인 오버헤드임을 발견하고, 주문형 도구로 볼륨 이동, 명시적 잘림 마커가 있는 문자 예산 전환, 투명한 속도 기대치 제시라는 세 가지 최적화를 소개합니다.
Uma Computer의 개발자들은 웹 검색, 미디어 생성, 비디오 클리핑과 같은 작업을 수행하는 자율 에이전트인 Uma Computer에서 한 사용자 요청이 예상 비용의 3분의 1이 아닌 38크레딧을 소비한 이유를 조사했습니다. 청구 내역을 확인한 결과, 프롬프트 토큰은 119,208개였지만 완성 토큰은 1,018개에 불과했습니다. 즉, 모델은 주로 쓰기보다는 읽기를 수행한 것입니다. 처음에는 긴 대화 기록이 원인일 것이라고 추정했지만, 실제 문제가 있는 대화는 총 530자에 불과한 두 개의 메시지만으로 구성되어 있었습니다. 측정 결과, 각 단계의 컨텍스트는 13,900토큰이었고, 9단계를 거치면서 총 약 120,000토큰에 달했습니다. 즉, 에이전트 루프의 단계 수만큼 오버헤드가 곱해진 것입니다. 또한 제공업체는 max_tokens를 높게 설정하여 최악의 경우 비용을 예약하기 때문에, 잔액이 충분함에도 HTTP 402 오류가 발생했습니다. 해결책으로는 사전 로드된 컨텍스트를 온디맨드 도구로 이동하고, 우선순위와 명시적 잘림 표시가 있는 문자 예산을 사용하며, 속도 기대치를 투명하게 공개하는 것이 포함되었습니다. 이 기사는 컨텍스트를 모델로부터 조용히 숨겨서는 안 되며, 최적화는 구체적인 사례를 통해 검증해야 한다고 강조합니다. 거의 기록이 중요하지 않은 사례에 대해 최적화할 뻔했기 때문입니다.
출처: Habr — хаб ML —
원문
