OpenCode에서 Ollama qwen3.5:4b가 플랜 작성 중 갑자기 멈춘 이유
원문 제목 — opencode ollama/qwen3.5:4b just stoppend while making a plan - why
📄 전문 번역
노트북에서 OpenCode를 Ollama와 함께 실행해 봤는데 다소 실망스러웠다. 기대치가 너무 높았던 것일까 궁금하다. GPU는 NVIDIA GTX 1650 Ti Mobile(4GB VRAM), CPU는 Intel i7-10750H(6코어/12스레드), RAM은 32GB다. 추론은 Ollama로 진행했으며 현재 qwen3.5:4b를 사용 중이고 컨텍스트 윈도우는 16k 토큰으로 설정했다.
OpenCode를 플랜 모드로 실행해 1,444행짜리 CSV를 분석하고 beancount(회계) 거래 초안 작성 계획을 세우도록 맡겼다. 모델은 약 32분 동안 파일 경로와 잘린 파일 출력 문제로 헤매다가 반복적인 추론 루프에 빠져 계획을 내지 못한 채 멈춰 섰다. 총 61k 입력 토큰과 12k 출력 토큰이 소요됐다.
하드웨어가 제한적이라는 건 알지만 작은 모델이라도 이 작업을 해낼 수 있으리라 기대했고, 실제로 32분이 걸린 것처럼 오래 걸리더라도 완료되리라 생각했다. 왜 멈춘 것일까? 내 하드웨어와 qwen3.5:4b에는 이 작업이 너무 어려운 걸까? 이 사양에서 로컬 모델을 의미 있게 구동할 방법에 대한 추천이 있을까? 궁극적으로는 데이터 프라이버시 때문에 OpenAI나 Anthropic 대신 일부 작업을 로컬 모델에 맡기고 싶다.
💬 주요 댓글 번역 (5)
🔍 루키 분석
16k 토큰 컨텍스트 윈도우의 qwen3.5:4b 모델이 61k 입력 토큰이 필요한 작업을 처리하다 추론 루프에 빠져 중단된 사례다. 댓글들은 토큰 양이 4B 모델의 처리 능력을 초과한 것이 원인이라고 진단하며, CSV를 청크로 나누거나 스크립트로 전처리해 컨텍스트 사용량을 줄이는 방법을 제안한다. 작성자는 데이터 프라이버시를 이유로 OpenAI와 Anthropic 대신 로컬 모델로 작업을 위임하려는 목적을 밝혔다.
— 루키 · glm-5.3-flash:cloud
16k 컨텍스트 윈도우의 4B 모델이 61k 토큰을 처리하려는 건 피자 한 판을 열쇠구멍으로 밀어 넣는 격이다. 중간에 작업 메모리가 바닥나면서 스스로 루프를 돌기 시작한 것이다. 하드웨어는 더 작은 작업에는 충분하지만 그 토큰 수는 4b 모델이 일관성 있게 추적하기에는 한참 넘어선다. 글 끝에 도달할 즈음 첫 문장을 기억하라고 금붕어에게 부탁하는 것과 마찬가지다. CSV를 200행 정도의 청크로 나눠 하나씩 입력하거나, 더 작은 컨텍스트로 VRAM에 넣을 수 있다면 qwen2.5-coder 7b 같은 모델을 살펴봐라.
4b급 모델로는 언제나 고전할 수밖에 없겠지만, 모델이 작을수록 프롬프트와 시스템 프롬프트에서 더 명시적이고 장황하게 지시해야 한다는 걸 경험으로 알게 됐다. 번거롭지만 실제로 시행착오가 필요하다. 디버그 출력을 보지 않은 상태에서의 추측이지만, 루프에 빠졌다가 결국 가드가 아마 올바르게 해당 동작을 감지해 중단시킨 것 같다. 어떤 도구를 사용하고 사용하지 말아야 하는지, 어떤 디렉터리와 파일을 사용해야 하는지 프롬프트에서 매우 명시적으로 지시해봐라.
정보 감사하다. 큰 도움이 된다. 프롬프트는 요약하면 파일을 읽고 자산 로트 이동을 분석해 최종 로트 기록을 생성하라는 것이었다. 하네스로 Claude Code도 시도했지만 역시 안 됐다.
4B 모델이 1,444행을 직접 읽게 하지 마라. 대신 CSV 열을 beancount 항목에 매핑하는 짧은 스크립트를 작성하게 한 뒤, 스크립트가 분류하지 못한 payee만 한 번에 수십 개씩 입력해서 16k 컨텍스트가 절대 가득 차지 않게 해라.
OpenCode 자체 문제일 수도 있다. 다른 도구에서 동일한 작업을 시도해봐라.