사고 과정이 끝난 후 응답하지 않는 문제
원문 제목 — Not replying after the thinking process is over
📄 전문 번역
여러분 안녕하세요. EndeavourOS(arch linux)에서 qwen 3.5 9b 모델로 ollama를 구동하고 있다. 시스템 사양은 다음과 같다. 그래픽 카드는 AMD 6700 XT 12GB(ollama가 인식했으며 ROCm 지원 모델이라고 표시), CPU는 i5-13600K, RAM은 32GB 6400MT/s다.
12GB 카드에 9b 모델을 사용하고 있다. 지금까지는 실제 답변을 만들어 내지 않는 경우가 대부분이다. 몇 번은 답변했지만, 대체로 긴 사고 과정만 화면에 출력한다. 사고 과정 자체는 보통 그리 오래 걸리지 않는다. 몇 차례 시간을 재 보니 질문에 따라 사고를 마치고 그것을 화면에 출력하기까지 15초에서 30초 정도 걸린다. 그런 다음에는 다시 깜빡이는 커서만 남아 다음 질문을 할 준비가 된 상태가 된다.
다른 분들도 이 문제를 겪은 적이 있는가? 있다면 어떻게 해결했는지 알려주기 바란다. 감사한다. 이 게시물은 /u/mastershake2013가 제출했다.
💬 주요 댓글 번역 (5)
🔍 루키 분석
EndeavourOS에서 Ollama로 Qwen 3.5 9B를 구동하는 사용자가 AMD 6700 XT 12GB 환경에서 사고 과정 출력 뒤 최종 답변이 생성되지 않는 문제를 보고했다. 댓글에서는 사고 과정이 기본 컨텍스트 창을 채워 답변 공간을 남기지 못하는 것이 주요 원인으로 지목되었으며, num_ctx나 OLLAMA_CONTEXT_LENGTH로 컨텍스트를 늘리는 방법이 제시되었다. 또한 Ollama와 ROCm 빌드를 최신으로 유지하고, /set nothink으로 사고를 끈 상태에서 테스트해 원인을 가려보라는 조언도 있었다.
— 루키 · glm-5.3-flash:cloud
ollama 로그를 확인하라. num_ctx를 설정해야 할 수도 있고, 추론 수준을 설정하고, 로드 시 GPU VRAM 사용량을 확인하라. 또한 KV 캐시 양자화를 설정할 수 있고, 헤드리스 환경이라면 GPU 오버헤드 수준을 낮출 수도 있다. 호출에 붙은 다른 도구가 KV 캐시를 차지하고 있을 수 있으니 그것도 확인하라.
num_ctx 문제는 작은 카드에서 나도 예전에 당한 적이 있다. 이런 추론 모델들은 사고 과정 전체를 메모리에 쏟아 넣기 때문에 기본 컨텍스트가 빠르게 불어난다. '사고' 중에 VRAM을 지켜보면 사용량이 치솟았다가 실제 생성이 막히는 모습을 볼 수 있을 것이다. num_ctx를 8192 같은 적당한 값으로 설정해 놓고 일관되게 답변하는지 확인해 볼 수 있다. ROCm 빌드가 충분히 최신인지 확인할 가치도 있다. 6700 XT는 커널 버전에 따라 까다로울 수 있다.
흔한 원인은 두 가지다. 모델보다 오래된 Ollama 버전이 모델의 사고 출력을 제대로 파싱하지 못하는 경우와, 답변이 시작되기 전에 사고 과정이 컨텍스트 창을 채워 버리는 경우다. 먼저 Ollama를 업데이트하고(Arch에서는 ROCm 빌드도 최신인지 확인하라), 그다음 컨텍스트를 늘려라. 예를 들어 ollama run 안에서 /set parameter num_ctx 16384를 쓰거나 서버에서는 OLLAMA_CONTEXT_LENGTH를 설정하면 되는데, 12GB에서 9B 모델에 맞는 크기다. 원인을 좁히려면 사고를 끈 상태(/set nothink)로 같은 질문을 실행해 보라. 그때 정상적인 답변이 나오면 문제는 사고 단계에 있다는 뜻이다.
Qwen 3.5 9B가 추론 내용은 출력하지만 최종 답변이 없으니, 먼저 같은 짧은 프롬프트를 다른 소형 모델로 테스트해 보겠다. ollama ps가 Qwen이 GPU에 로드됐는지를 보여주는가? Ollama 서버 로그에 생성이 멈출 때 오류가 표시되는가? 이 두 가지 확인은 모델 출력 문제와 메모리나 ROCm 문제를 구별하는 데 도움이 된다.
사고 후에 깜빡이는 커서는 보통 컨텍스트 창이 가득 찼다는 뜻이다. ollama는 많은 설정에서 꽤 작은 컨텍스트를 기본값으로 사용하며(작은 카드에서는 4k), qwen의 사고 과정이 실제 답변에 공간이 생기기 전에 그 대부분을 잡아먹을 수 있다. 서비스 환경 변수에 OLLAMA_CONTEXT_LENGTH=16384를 설정해 보라. 12GB에서 q4 양자화 9b 모델은 여전히 충분히 들어갈 것이다. 단순히 과도한 사고를 멈추게 하고 싶다면 대화형 세션에서 /set nothink 또는 --think=false도 작동한다.