로컬 AI 긴 작업이 30분 만에 죽을 때, 절전과 이어 하기

한눈에 보기

겪은 일: 올라마로 돌리던 긴 배치 작업이 자리를 비운 뒤 약 30분 만에 죽었습니다. 올라마는 살아 있고 파이썬 프로세스만 없었습니다.

원인: PC가 절전(슬립)에 들어갔습니다. 프로그램 안에서 절전을 막는 호출로도 못 막은 사례가 두 번 있었습니다.

이렇게 풀었다: powercfg로 절전 시간을 0으로 바꾸고, 작업은 이어 하기가 되는 독립 러너로 띄웁니다.

30분쯤 지나면 조용히 멈춰 있었다

로컬 모델로 시간이 오래 걸리는 분류 작업을 백그라운드로 걸어 두고 자리를 비웠습니다. 돌아와 보니 작업이 멈춰 있었고, 오류 메시지도 없었습니다. 같은 일이 6월 14일과 6월 26일 두 번, 모두 약 30분 지점에서 일어났습니다.

멈춘 자리의 모습은 늘 같았습니다. 올라마 서비스는 살아 있었고, 모델은 램에서 내려가 있었고, 작업을 돌리던 파이썬 프로세스만 사라져 있었습니다.

작업 스케줄러로 돌린 다른 분류 작업은 모양이 조금 달랐습니다. 3시간에 죽고, 다음 날 다시 시작하면 앞부분만 반복했습니다. 이것은 절전과 다른 원인이 겹친 경우라 아래 표에서 따로 나눴습니다.

절전, 그리고 처음부터 다시 하는 구조

모양 원인
약 30분에 파이썬만 사라짐 PC 절전(슬립)
3시간에 죽고 다음 날 앞부분만 반복 작업 스케줄러 기본 실행 제한 3시간 + 매번 처음부터 시작하는 구조

처음에는 프로그램 안에서 절전을 막으려고 SetThreadExecutionState(ES_CONTINUOUS|ES_SYSTEM_REQUIRED)를 불렀습니다. 그런데도 두 번 다 막지 못했습니다. 왜 이 호출이 안 먹혔는지는 여기까지 확인하지 못했습니다.

3시간 문제는 작업 스케줄러의 실행 시간 제한 때문입니다. 결과 코드로 가리는 법은 작업 스케줄러 결과 코드 읽는 법에 따로 적었습니다. 여기서 중요한 것은, 어느 쪽이든 작업이 처음부터 다시 시작하는 구조라면 영원히 끝나지 않는다는 점입니다.

진단: 세 가지가 함께 보이면 절전이다

Get-Process python
ollama ps
(Get-Item .\결과.jsonl).LastWriteTime

파이썬 프로세스가 없고, ollama ps가 빈 목록이고, 결과 파일의 마지막 수정 시각이 30분쯤에서 멈춰 있으면 절전으로 죽은 것입니다. 결과 파일 이름은 각자 작업에 맞게 바꿉니다. 올라마가 살아 있으니 모델이나 엔진 문제로 보기 쉬운데, 엔진을 다시 깔기 전에 이 세 가지부터 확인하는 편이 시간을 아낍니다.

절전 끄기와 이어 하기 러너

전원이 연결됐을 때와 배터리일 때의 절전 시간을 모두 0(안 함)으로 바꿉니다. 이렇게 바꾼 6월 26일 뒤로는 끊기지 않았습니다.

powercfg /change standby-timeout-ac 0
powercfg /change standby-timeout-dc 0

절전을 끄는 것만으로는 부족합니다. 다른 이유로 멈췄을 때 하던 자리부터 잇게 작업 자체를 고칩니다. 이미 처리한 것은 건너뛰고, 결과는 200개마다 중간 저장합니다.

더 긴 일은 대화창이나 터미널에 묶지 않는 독립 러너로 띄웁니다. 창을 닫아도 계속 돕니다.

Start-Process -FilePath "<파이썬 경로>" -ArgumentList "scripts\runner.py" `
  -WorkingDirectory "<작업 폴더>" -WindowStyle Hidden
러너에 둘 것 왜
진행 파일 창 없이도 상태를 보려고. 단계마다 시각과 함께 적는다
이어 하기 멈춰도 하던 자리에서 잇는다
잠금 파일 두 번 돌면 같은 파일을 서로 덮어쓴다(실제로 당했다)
결과 파일 끝난 뒤 사람이 읽을 보고서

PC를 같이 쓰는 동안에도 돌린다면 우선순위를 낮춥니다. 사람이 안 쓸 때는 CPU를 다 쓰고, 쓰기 시작하면 바로 물러납니다.

subprocess.Popen(cmd, creationflags=subprocess.BELOW_NORMAL_PRIORITY_CLASS)

고쳐졌는지 확인하는 법

절전을 끈 뒤 같은 작업을 걸고 30분 넘게 자리를 비웁니다. 돌아와서 위 진단 세 가지를 다시 보고, 결과 파일 수정 시각이 계속 움직이면 된 것입니다. 일부러 러너를 한 번 끄고 다시 띄워, 처음이 아니라 멈춘 자리부터 이어지는지도 봅니다.

속도를 올리려고 동시 작업을 늘리기 전에는 CPU 사용률부터 잽니다. 음성 받아쓰기 작업에서 하나가 27%만 쓰고 있어 셋으로 나누니 71%가 되고 3시간이 1시간으로 줄었습니다. 이미 CPU를 꽉 쓰고 있다면 나눠도 빨라지지 않습니다. 로컬 모델이 램을 얼마나 차지하는지는 GTX 1660에서 35B 모델 돌리기를 참고하세요.

확인한 환경

항목 값
운영체제 윈도우
엔진 올라마
확인한 날짜 2026년 6월 14일, 6월 26일

이 글의 내용은 2026년 10월 5일에 마지막으로 확인했습니다. 틀린 곳을 발견하시면 연락처로 알려 주세요.