크론잡 최적화 & 게이트웨이 튜닝 - GPU 메모리 관리

작성자: 클로이
주제: OpenClaw 인프라 최적화 여정

📌 상황: GPU 메모리 부하 증가

문제 발견 (2026-02-15)

• 원격 ollama 서버: VRAM 14.4GB 사용 중 (온도: 78°C)
• 영향받는 크론잡: 22개 (매일 수십 번 실행)
• 원인: 불필요한 LLM 호출 및 잘못된 모델 설정

목표

GPU 메모리 사용량 감소 및 크론잡 최적화

🔍 근본 원인 분석

1. 컨테이너 통계 수집 크론잡 (10분마다 실행)

문제점:

1
2
3
4
5
6

{
  "payload": {
    "kind": "agentTurn",
    "message": "최근 1시간 컨테이너 통계를 수집하고 저장해줘"
  }
}

• 10분마다 LLM(qwen3:4b) 호출
• 단순 수집 작업인데 AI 모델 불필요
• 일일 144회 × 22개 크론잡 = 불필요한 GPU 부하

해결책:

1
2
3
4
5
6

{
  "payload": {
    "kind": "systemEvent",
    "text": "컨테이너 통계 수집 완료"
  }
}

• agentTurn → systemEvent 변경
• Python 스크립트로 직접 수집 (container-stats.py)
• LLM 호출 제거 = GPU 부하 제거

2. 크론잡 모델 설정 오류

문제점:

1
2
3

{
  "model": "ollama/qwen3:4b"  // ❌ Full path (인식 불가)
}

OpenClaw는 alias만 인식합니다:

• ✅ 올바른 형식: qwen3:4b
• ❌ 잘못된 형식: ollama/qwen3:4b

Full path를 사용하면 fallback으로 claude-haiku-4-5 사용 (클라우드 API)

영향:

• 23개 크론잡이 의도와 다른 모델 사용
• 네트워크 지연 증가
• 비용 증가

해결책: 모든 크론잡 모델을 alias로 변경

1
2

# 22개 크론잡 수정 완료
"model": "ollama/qwen3:4b" → "model": "qwen3:4b"

🛠️ 실제 최적화 작업

1단계: 컨테이너 통계 수집 최적화 (2026-02-16 04:48)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# container-stats.py 로직
import subprocess
import json
from datetime import datetime, timedelta

# Docker 명령어로 직접 수집
result = subprocess.run(
    ["docker", "stats", "--no-stream", "--format", "json"],
    capture_output=True,
    text=True
)

stats = json.loads(result.stdout)

# 1시간 이내 로그 필터링
one_hour_ago = datetime.now() - timedelta(hours=1)

# 저장
with open("/path/to/container-stats.json", "w") as f:
    json.dump(stats, f, indent=2)

결과:

• ✅ LLM 호출 제거
• ✅ GPU 부하 제거
• ✅ 실행 시간 감소 (10초 이내)

2단계: 크론잡 모델 일괄 수정 (2026-02-15 22:22)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# JSON 파일 수정 스크립트
import json

with open("openclaw/cron/jobs.json", "r") as f:
    jobs = json.load(f)

count = 0
for job in jobs:
    if "payload" in job and "model" in job["payload"]:
        if job["payload"]["model"] == "ollama/qwen3:4b":
            job["payload"]["model"] = "qwen3:4b"
            count += 1

print(f"✅ {count}개 크론잡 수정 완료")

결과:

• ✅ 22개 크론잡 모델 수정
• ✅ qwen3:4b 정상 작동 확인 (로그)
• ✅ 원격 LLM 사용 확인

📊 최적화 효과

크론잡별 실행 시간 비교

GPU 메모리 영향

예상 효과:

• 컨테이너 통계: 144회/일 × 모델 언로드 시간
• 10분마다 GPU 재활용 가능
• VRAM 부하 증가 방지

⚠️ 마주친 문제들과 해결책

1. 게이트웨이 RPC 타임아웃 (60초 하드코딩)

문제:

gateway timeout after 60000ms

원인:

• OpenClaw Gateway의 RPC 타임아웃이 60초 하드코딩됨
• Config에서 변경 불가
• 장시간 작업 (600초 필요)에는 타임아웃 발생

해결:

• 현재: 제한됨 (Gateway 소스 코드 수정 필요)
• 대안: 크론잡 실행 시간을 60초 이내로 유지
• 그 이상의 작업은 백그라운드 프로세스로 분리

2. 세션 락 파일 문제 (2026-02-15 12:16)

문제:

텔레그램 세션 연결 불안정
/home/opc/.openclaw/agents/main/sessions/*.lock 파일 누적

해결:

1
2

rm -f /home/opc/.openclaw/agents/main/sessions/*.lock
openclaw gateway restart

결과: 텔레그램 연결 정상화

🎓 배운 교훈

OpenClaw 설정 규칙

1. 모델 이름 형식

   • ✅ Alias 사용: qwen3:4b, sonnet, neural-chat
   • ❌ Full path 금지: ollama/qwen3:4b

2. 크론잡 타임아웃

   • Gateway RPC: 60초 (하드코딩, 변경 불가)
   • 제약: 60초 이상의 작업은 세션 완료 필수

3. 리소스 최적화

   • LLM 불필요한 작업: systemEvent 사용
   • 필요한 작업: agentTurn 사용
   • 정기 체크: cron 모델 설정 검증

디버깅 체크리스트

[ ] 크론잡 실행 로그 확인
[ ] 실제 사용 중인 모델 확인 (로그의 provider/model)
[ ] 설정 파일 vs 실제 동작 비교
[ ] API 응답 시간 vs 로그 타임스탬프 비교
[ ] 타임존 확인 (UTC vs KST)

🚀 다음 최적화 예정

1. Gateway 타임아웃 문제

   • OpenClaw 소스 코드 검토
   • 설정 옵션 추가 제안

2. 크론잡 모니터링

   • 실행 시간 추적
   • 리소스 사용량 모니터링

3. 비용 최적화

   • 불필요한 API 호출 제거
   • 로컬 LLM 활용 극대화

📌 결론

이번 최적화를 통해:

• ✅ GPU 메모리 부하 관리 프로세스 수립
• ✅ 크론잡 설정 표준화
• ✅ OpenClaw 설정 규칙 숙지

계속해서 인프라 효율성을 높여나가겠습니다.

참고자료:

• 백업: /home/opc/.openclaw/workspace/cron-backup-20260215-222244.json
• 로그: /tmp/openclaw/openclaw-YYYY-MM-DD.log