8GB 안드로이드 태블릿에서 Ollama로 멀티 에이전트 파이프라인 구동한다
원문 제목 — Running a multi-agent pipeline on an 8 GB Android tablet with Ollama
📄 전문 번역
Termux와 Ollama를 사용해 안드로이드 태블릿에서 로컬 멀티 에이전트 파이프라인을 구축했다. 주요 병목은 8GB RAM이다. 3B 모델 하나가 약 2GB를 차지하기 때문에 여러 모델을 동시에 구동하면 시스템이 멈추고 안드로이드가 Termux를 강제 종료시킨다.
해결책은 순차 로딩이다. Director 스크립트가 모델 하나를 로드해 결과를 받은 뒤 ollama stop으로 언로드하고, 안드로이드가 RAM을 해제하도록 10초를 기다린 후 다음 모델을 로드한다. 이 방식으로 크래시 없이 6~7개 모델 체인을 구동할 수 있다.
아키텍처는 Coder, Analyst, Judge, Sandbox로 이루어진 파이프라인이다. 원래 코드를 검증하는 Critic 세 개를 두었지만 8GB RAM에서는 루프에 유지하기에 너무 무거웠다. 태블릿에서 파이프라인을 안정적으로 유지하기 위해 우선 제거했으며, RAM이 더 많은 PC에서는 다시 추가할 계획이다.
Snapdragon 870에서 Qwen2.5-Coder 3B는 초당 약 4~5토큰으로 구동되며 이 파이프라인에는 충분한 속도다. 가장 큰 문제는 Sandbox였다. 원래는 단순히 종료된 스크립트의 exit 명령을 기다렸기 때문에 정상 코드를 죽이고 오류로 표시했으며, 정상 종료를 성공으로 간주하도록 수정했다.
저사양 하드웨어에서 비슷한 순차 로딩이나 메모리 관리를 시도해 본 사람이 있는지, 어떤 방법이 효과가 있었는지 묻는다. P.S. 별다른 이유는 없지만 필자는 14살이다(사실 조금 더 어리다). /u/RoneDoneBone001이 제출한 글이다.
💬 주요 댓글 번역 (5)
🔍 루키 분석
8GB RAM 안드로이드 태블릿에서 Termux와 Ollama로 멀티 에이전트 파이프라인을 구동한 사례로, 모델을 하나씩 로드한 뒤 ollama stop과 10초 대기로 메모리를 비우는 순차 로딩으로 크래시 없이 6~7개 모델 체인을 구현했다. Snapdragon 870에서 Qwen2.5-Coder 3B가 초당 4~5토큰으로 동작하며, 무거운 Critic 세 개는 빼고 Coder, Analyst, Judge, Sandbox 구성으로 안정성을 유지했다. 댓글에서는 keep_alive: 0과 OLLAMA_MAX_LOADED_MODELS 환경 변수로 자동 언로드가 가능하다는 지적이 나왔지만, 작성자는 CLI 사용과 안드로이드의 실제 RAM 해제 시점 문제 때문에 스크립트 방식이 필요하다고 답했다.
— 루키 · glm-5.3-flash:cloud
글에서 언급한 순차 로딩 방식에 대해, Ollama는 이를 자동으로 처리할 수 있다. 모델을 메모리에 유지하거나 즉시 언로드하는 방법이 공식 FAQ에 안내되어 있다.
좋은 지적이며 완전히 맞다. API의 keep_alive: 0이 정확히 그 기능을 한다. 하지만 나는 HTTP API가 아닌 Termux에서 CLI(ollama run)를 사용하므로 즉시 언로드할 간단한 플래그가 없다. 그래서 스크립트에서 ollama stop을 사용한다. PC에서 API로 옮기면 keep_alive: 0으로 전환하고 sleep을 없앨 것이다.
이 경우 환경 변수를 사용할 수 있다. OLLAMA_KEEP_ALIVE는 모델이 메모리에 유지되는 시간(기본값 5m)이고 OLLAMA_MAX_LOADED_MODELS는 GPU당 로드 가능한 최대 모델 수다. OLLAMA_MAX_LOADED_MODELS=1로 설정하면 다른 모델을 사용하려 할 때 Ollama가 이전 모델을 메모리에서 내리도록 강제하며, OLLAMA_KEEP_ALIVE=0은 REST API의 keep_alive 옵션과 정확히 같은 방식으로 동작한다.
해당 환경 변수들을 알고 있다. 하지만 내 경우 8GB RAM 태블릿에서 Ollama를 구동하고 있어 다음 모델을 로드한 후가 아니라 로드하기 전에 모델을 언로드해야 한다. OLLAMA_MAX_LOADED_MODELS=1은 다음 모델이 요청될 때만 작동하므로 몇 초간 두 모델이 모두 메모리에 남을 수 있고 그것만으로도 Termux가 크래시된다. OLLAMA_KEEP_ALIVE=0도 동작하겠지만 다음 모델을 시작하기 전에 안드로이드가 실제로 RAM을 해제하기를 기다려야 한다. 그래서 스크립트에서 ollama stop과 짧은 sleep을 함께 사용하며, RAM이 더 많은 PC에서는 OLLAMA_MAX_LOADED_MODELS=1과 OLLAMA_KEEP_ALIVE=0을 사용할 것이다.
몇 초간 두 모델이 모두 메모리에 있을 수 있다는 점이 흥미롭다. 아는 한 다음 모델 로드를 시작하기 전에 현재 모델을 메모리에서 내리는 것이 맞다. 이 플래그를 제안한 이유는 다음 생성이 같은 모델을 사용할 수 있으므로 잠깐이라도 모델을 유지하는 편이 합리적일 수 있기 때문이다(일반론이며, 현재 오케스트레이터 구성에서는 해당하지 않는다는 점은 이해한다). OLLAMA_KEEP_ALIVE=0이 동작하더라도 안드로이드가 실제로 RAM을 해제하기를 기다려야 한다는 점도 지적했다.