OpenClaw LLM 콜드 모델 로딩 타임아웃 수정

문제: 차가운 모델이 60초에 타임아웃
사용자들은 OpenClaw에서 차갑게 로드된 로컬 모델이 일반 에이전트 타임아웃이 훨씬 더 높게 설정되어 있음에도 불구하고 약 60초 후에 지속적으로 실패한다고 보고했습니다. 이 문제는 Ollama를 통한 클라우드 모델과 때로는 OpenAI Codex에서도 발생했습니다.
일반적인 실패 패턴:
- 이미 예열된 모델은 작동함
- 차가운 모델은 약 60초 후에 중단됨
- 로그에 타임아웃 / embedded 장애 조치 / 상태: 408이 언급됨
- 대체 모델이 인수함
오해의 소지가 있는 구성
출처는 몇 가지 명백한 구성 옵션이 실제 해결책이 아니며 개발자를 잘못된 길로 이끌 수 있다고 경고합니다:
agents.defaults.timeoutSeconds.zshrc내보내기LLM_REQUEST_TIMEOUT- 즉시 LM Studio / Ollama 탓하기
근본 원인
이 문제는 OpenClaw가 모델이 첫 번째 스트리밍 토큰을 내보내기 전 기간에 대한 별도의 embedded-runner LLM 유휴 타임아웃을 가지고 있기 때문에 발생합니다.
소스 추적 위치:
src/agents/pi-embedded-runner/run/llm-idle-timeout.ts
기본값:
DEFAULT_LLM_IDLE_TIMEOUT_MS = 60_000
구성 경로는 다음에서 확인됩니다:
cfg?.agents?.defaults?.llm?.idleTimeoutSeconds
따라서 실제 구성 매개변수는 다음과 같습니다:
agents.defaults.llm.idleTimeoutSeconds
해결 방법
테스트 후, 작동하는 구성은 다음과 같습니다:
{
"agents": {
"defaults": {
"llm": {
"idleTimeoutSeconds": 180
}
}
}
}
테스트 결과, 이전에 약 60초에 실패했던 차가운 Gemma 호출이 해당 임계값을 넘어서 생존했으며 결국 즉각적인 장애 조치 없이 성공적으로 응답했습니다.
권장 영구 구성
{
"agents": {
"defaults": {
"timeoutSeconds": 300,
"llm": {
"idleTimeoutSeconds": 300
}
}
}
}
300초 권장 사항은 로컬 모델이 예측 불가능한 경우를 고려한 것으로, 잘못된 장애 조치가 진정으로 차가운 모델을 더 오래 기다리는 것보다 더 문제가 됩니다.
📖 전체 소스 읽기: r/openclaw
👀 See Also

VSCode/Cursor 통합 터미널에서 Claude Code 실행하여 워크플로우 개선하기
VSCode나 Cursor의 통합 터미널에서 Claude Code를 외부 터미널 대신 실행하면 창을 전환할 필요 없이 git diff 패널과 디버거에 즉시 접근할 수 있으며, 추가 설정이 필요하지 않습니다.
![[업데이트] 보안성이 뛰어나고 '항상 켜진' 상태로 OpenClaw를 VPS 번거로움 없이 실행할 방법을 요청하셨습니다. 저희가 만들었습니다. 대기자 명단이 열렸습니다.](/covers/article-139.jpg?v=3)
[업데이트] 보안성이 뛰어나고 '항상 켜진' 상태로 OpenClaw를 VPS 번거로움 없이 실행할 방법을 요청하셨습니다. 저희가 만들었습니다. 대기자 명단이 열렸습니다.
OpenClaw가 VPS의 복잡성 없이 플랫폼을 안전하고 지속적으로 실행할 수 있는 새로운 기능을 발표했습니다. 조기 접속을 위한 대기자 명단이 오픈되었습니다.

클로드 한도에 도달하는 것을 막는 방법: 각 세션을 토큰 예산처럼 다루기
사용자가 세션을 범위 지정하고 오래된 컨텍스트를 제거하여 일일 Claude 한도를 고정한 방법을 공유합니다. 실제 워크플로우와 r/ClaudeAI의 인포그래픽 포함.

완벽한 프롬프트 작성보다 AI 대화 구성하기
한 개발자가 r/ClaudeAI에서 완벽한 프롬프트 문장에 집착하는 대신 Claude AI와의 대화를 상황으로 구성하는 방법으로 전환하여 훨씬 더 나은 결과물을 얻었다고 설명합니다.