简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

OpenClaw 비용 절감 가이드: 매월 2만 원을 절감한 비결을 밝혀드립니다!

이 글을 읽으려면 16 분

그것이 이전 내용을 반복해서 읽지 않도록해주세요

원문 제목: 내 OpenClaw 세션은 하루에 21.5백만 토큰을 소모했지만 (그리고 실제로 이를 해결한 방법)
원문 작성자: MOSHIII
번역: Peggy, BlockBeats

에디터 주: 현재 Agent 애플리케이션이 신속하게 보급되는 가운데 많은 팀이 보이지 않는 현상을 발견했습니다: 시스템이 정상 작동하지만 토큰 비용이 자동으로 계속 상승합니다. 본문은 실제 OpenClaw 작업 부하를 분해하여 발견한 바에 따르면, 비용 폭발의 주요 원인은 종종 사용자 입력이나 모델 출력이 아닌 무시된 캐시된 접두사 재생(cached prefix replay)에서 옵니다. 모델이 각 호출에서 방대한 역사적 컨텍스트를 반복적으로 읽어들여 대량의 토큰을 소비하게 됩니다.

이 기사는 구체적인 세션 데이터를 통해 도구 출력, 브라우저 스냅샷, JSON 로그 등 대형 중간 생성물이 어떻게 역사적 컨텍스트에 지속적으로 기록되고 에이전트 루프에서 반복적으로 읽히는지를 보여줍니다.

이 사례를 통해 작가는 명확한 최적화 방안을 제시했습니다: 컨텍스트 구조 설계부터 도구 출력 관리 및 압축 메커니즘 구성까지. 에이전트 시스템을 구축 중인 개발자들에게 이 기술적 해부 기록은 물론 비용 절약 전략서로도 중요한 자료입니다.

아래는 원문입니다:

나는 한 번의 실제 OpenClaw 작업 부하를 분석했고, 많은 Agent 사용자가 익히 알아볼만한 패턴을 발견했습니다:

토큰 사용량이 매우 "활발"해 보입니다

응답도 정상적으로 보입니다

하지만 토큰 소비가 갑자기 폭발적으로 증가했습니다

아래는이 분석의 구조 분해, 근본적인 이유 및 실질적인 수정 경로입니다.

요약

가장 큰 비용 주도 요인은 사용자 메시지 길이가 너무 길다는 것이 아니라 대량의 캐시된 접두사가 반복적으로 재생되었기 때문입니다.

세션 데이터로 보면:

총 토큰: 21,543,714

캐시 읽기: 17,105,970 (79.40%)

입력: 4,345,264 (20.17%)

출력: 92,480 (0.43%)

다시 말해, 대부분의 호출 비용은 실제로는 새로운 사용자 의도를 처리하는 데가 아니라 거대한 기존 컨텍스트를 반복적으로 읽는 데 발생합니다.

“잠깐, 왜 이런 일이 벌어졌을까?” 순간

원래 높은 토큰 사용량이 매우 긴 사용자 프롬프트, 대량의 출력 생성 또는 비용이 많이 드는 도구 호출에서 비롯된 줄 알았습니다.

하지만 실제로 주도되는 패턴은 다음과 같습니다:

입력: 수백에서 수천 개의 토큰

캐시 읽기: 각 호출마다 17 만에서 18 만 개의 토큰

즉, 모델은 매 라운드마다 동일한 거대한 고정 프리픽스를 반복해서 읽습니다.

데이터 범위

저는 두 가지 데이터 수준을 분석했습니다:

1. 런타임 로그 (runtime logs)
2. 세션 기록 (session transcripts)

설명이 필요한 점은 다음과 같습니다:

런타임 로그는 주로 행동 신호 (재부팅, 오류, 구성 문제 등)를 관찰하는 데 사용됩니다.

정확한 토큰 통계는 세션 JSONL의 사용량 필드에서 가져옵니다.

사용된 스크립트:

scripts/session_token_breakdown.py

scripts/session_duplicate_waste_analysis.py

생성된 분석 파일:

tmp/session_token_stats_v2.txt

tmp/session_token_stats_v2.json

tmp/session_duplicate_waste.txt

tmp/session_duplicate_waste.json

tmp/session_duplicate_waste.png

토큰이 실제로 소비되는 곳은 어디에 있나요?

1) 세션 집중

하나의 세션이 다른 것보다 훨씬 많이 소비됩니다:

570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 토큰

그런 다음 급격한 감소가 있습니다:

ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038

ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649,584

2) 행동 집중

토큰은 주로 다음에서 나옵니다:

toolUse: 16,372,294

stop: 5,171,420

문제는 주로 도구 호출 체인 루프에 있으며 일반 채팅이 아닙니다.

3) 시간 집중

토큰 피크는 무작위가 아니라 특정 몇 시간에 집중되어 있습니다:

2026-03-08 16:00: 4,105,105

2026-03-08 09:00: 4,036,070

2026-03-08 07:00: 2,793,648

거대한 캐시 접두사 안에는 무엇이 정확히 포함되어 있나요?

대화 내용이 아니라 주로 대형 중간 생성물이 포함되어 있습니다:

거대한 toolResult 데이터 블록

매우 긴 추론/사고 추적

대형 JSON 스냅샷

파일 목록

브라우저 크롤링 데이터

하위 에이전트의 대화 기록

최대 세션에서 문자 양은 대략 다음과 같습니다:

toolResult:text: 366,469 문자

assistant:thinking: 331,494 문자

assistant:toolCall: 53,039 문자

이러한 내용이 한 번 히스토리 콘텍스트에 보존되면, 이후 각 호출에서 cache 접두사를 통해 다시 읽을 수 있습니다.

구체적인 예시(세션 파일로부터)

대량의 컨텍스트 블록이 다음 위치에서 반복적으로 나왔습니다:

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70

대형 게이트웨이 JSON 로그(약 3.7 만 문자)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134

브라우저 스냅샷 + 보안 래핑(약 2.9 만 문자)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219

대형 파일 목록 출력(약 4.1 만 문자)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311

session/status 상태 스냅샷 + 대형 프롬프트 구조(약 3 만 문자)

「반복 내용 낭비」 vs 「캐시 재생 부담」

내가 내부 단일 호출에서 반복되는 콘텐츠 비율도 측정했습니다:

반복 비율 약: 1.72%

실제로는 존재하지만 주요 문제는 아닙니다.

진짜 문제는: cache 접두어의 절대 양이 너무 많다는 것입니다

구조는: 거대한 히스토리컨텍스트, 각 라운드 호출 재로드, 위에는 적은 양의 새 입력만 쌓입니다

따라서 최적화의 중점은 중복이 아니라 상황 구조 설계에 있습니다.

왜 에이전트 루프가 특히 이 문제에 노출되기 쉬울까요?

세 가지 메커니즘이 상호 작용합니다:

1. 많은 도구 출력이 기록된 상황에 쓰여집니다.

2. 도구 루프는 대량의 짧은 간격 호출을 생성합니다.

3. 접두사 변화가 매우 작음 → 캐시가 매번 다시 읽힙니다.

만약 컨텍스트 압축이 안정적으로 트리거되지 않는다면, 문제는 신속하게 확대됩니다.

가장 중요한 수정 전략(영향으로 정렬)

P0—거대한 도구 출력을 장기적 컨텍스트에 넣지 마세요

대규모 도구 출력에 대해:

· 개요 유지 + 참조 경로 / ID

· 원본 payload를 파일 아티팩트로 작성

· 채팅 기록에 완전한 내용을 저장하지 마세요

이러한 유형을 우선적으로 제한하세요:

· 대규모 JSON

· 긴 디렉터리 목록

· 브라우저 전체 스냅샷

· 하위 에이전트 완전 대본

P1—압축 메커니즘이 실제로 작동하는지 확인하세요

이 데이터에서 구성 호환성 문제가 반복적으로 발생했습니다: 압축 키가 잘못되었습니다

이로 인해 최적화 메커니즘이 조용히 비활성화됩니다.

올바른 절차: 버전 호환 구성만 사용

그런 다음 확인하세요:

openclaw doctor --fix

및 시작 로그를 확인하여 압축이 수락되었는지 확인하세요.

P1—추론 텍스트 지속성 감소

반복적으로 재생되는 긴 추론 텍스트를 피하세요

프로덕션 환경에서: 완전한 추론 대신 간단한 개요를 유지하세요

P2—개선된 프롬프트 캐싱 디자인

목표는 cacheRead를 최대화하는 것이 아닙니다. 목표는, 콤팩트하고 안정적이며 가치 있는 접두어를 사용하여 캐시를 활용하는 것입니다.

제안:

· 안정적인 규칙을 시스템 프롬프트에 넣으세요

· 불안정한 데이터를 안정적인 접두어에 넣지 마세요

· 매 라운드마다 과도한 디버그 데이터를 주입하는 것을 피하세요

급속 손실 방지 계획 (내일 처리해야 할 경우)

1. cacheRead 비율이 가장 높은 세션 식별
2. runaway 세션에 대해 /compact 실행
3. 툴 출력에 Truncate + Artifact 추가
4. 수정 후 매번 토큰 통계 다시 실행

주요 KPI 네 가지 추적:

cacheRead / totalTokens

toolUse 평균 총/call

>=100k 토큰 호출수

최대 세션 비율

성공 신호

최적화가 작동하면 다음을 볼 수 있어야 합니다:

100k+ 토큰 호출이 현저히 감소합니다

cacheRead 비율이 감소합니다

toolUse 호출 가중치가 감소합니다

단일 세션의 우세함이 감소합니다

이러한 지표에 변화가 없으면, 여전히 컨텍스트 전략이 너무 넓다는 것을 의미합니다.

재현 실험 명령어

python3 scripts/session_token_breakdown.py 'sessions' \
--include-deleted \
--top 20 \
--outlier-threshold 120000 \
--json-out tmp/session_token_stats_v2.json \
> tmp/session_token_stats_v2.txt

python3 scripts/session_duplicate_waste_analysis.py 'sessions' \
--include-deleted \
--top 20 \
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt