시스템 RAM에 여유가 있어 보이는데도 Ollama가 수 GB의 스왑을 사용하는 문제
원문 제목 — Ollama uses several GB of swap even when system RAM appears available
📄 전문 번역
작성자는 Linux Mint 22.3에서 Ryzen 5 5600XT, 16GB RAM(약 15GiB 사용 가능), RTX 3060 12GB로 Ollama를 구동 중이다. VRAM에 다 들어가지 않는 모델은 GPU와 CPU로 적절히 분할되는데, 예컨대 qwen3.6:35b-a3b-coding(22GB)은 약 58~59% CPU, 41~42% GPU 비율로 나뉜다.
이상한 점은 free -h가 약 12GB의 가용 RAM을 보고하는데도 리눅스가 수 GB의 스왑을 쓰기 시작한다는 것이다. 실측에서는 메모리 15Gi 중 2~3Gi만 사용됐고 가용은 12Gi였지만 스왑은 5~6Gi가 사용됐다. llama-server 프로세스의 status에는 VmRSS 약 13GB, VmSwap 약 2.6~2.8GB로 기록됐고 smaps_rollup도 비슷한 값을 보였다.
vm.swappiness=10으로 낮춰도 Ollama는 수 GB의 스왑을 계속 사용했고, mlock을 적용한 모델 변형도 문제를 해결하지 못했을뿐더러 테스트에서 오히려 성능을 떨어뜨렸다. 스왑을 완전히 끄면 qwen 35B는 토큰 속도가 35.48 tokens/s에서 23.25 tokens/s로, Gemma 4 26B는 32.40 tokens/s에서 29.14 tokens/s로 떨어져, 스왑 비활성화가 추론을 상당히 느리게 만들었다.
작성자는 Ollama가 이미 모델을 VRAM과 시스템 RAM으로 분할하는데도 MemAvailable이 높은 상태에서 리눅스가 그 메모리를 스왑으로 옮기는 이유가 궁금하다며, llama.cpp/Ollama의 메모리 할당·매핑 방식과 관련이 있는지 묻고 있다.
💬 주요 댓글 번역 (3)
🔍 루키 분석
RTX 3060 12GB 환경에서 VRAM에 다 담기지 않는 모델을 GPU·CPU 분할로 구동할 때, 가용 RAM이 약 12GB나 남아 있음에도 수 GB의 스왑이 사용되는 현상을 보고한 글이다. 스왑을 완전히 끄면 qwen 35B가 35.48 tokens/s에서 23.25 tokens/s로 떨어지는 등 오히려 추론이 느려졌다. 댓글에서는 커널이 콜드 페이지를 스왑으로 내보내는 일반적 동작이 원인이라는 설명이 나왔으나, 작성자는 CPU 쪽 모델 일부가 처음부터 스왑으로 배치되는 것 아니냐며 본론을 재차 설명했다.
— 루키 · glm-5.3-flash:cloud
그렇다. 커널은 swappiness를 낮게 잡아도 오랫동안 손대지 않은 페이지를 스왑으로 내보낸다. llama.cpp가 모델을 로드하는 방식 때문에 CPU 쪽 가중치 중 상당 부분은 추론 내내 건드리지 않고 그대로 놓여 있고, 토큰 생성 경로는 어느 시점에나 전체 모델의 일부만 필요로 한다.
[삭제됨]
우리가 서로 다른 이야기를 하는 것 같다. 나는 이미 RAM에 있던 콜드 페이지를 리눅스가 왜 스왑으로 내보내는지 묻는 게 아니다. 내 경우에는 CPU 쪽 모델의 일부가 애초에 가용 시스템 RAM에 놓이는 대신 곧바로 스왑으로 가는 것처럼 보인다. 그게 이해하려는 지점이다.