로컬 AI 성능은 운영체제가 좌우한다 — 윈도우·WSL·리눅스 로컬 LLM 벤치마크와 메모리 병목

핵심 메시지

• 같은 하드웨어(AMD 라이젠 AI 9 HX 470 미니 PC)에서 윈도우·WSL·바탕(bare metal) 리눅스로 동일 모델·프롬프트를 돌려 로컬 LLM 성능을 비교했다.
• 윈도우에서 Ollama는 기본적으로 AMD GPU를 놓치고 CPU만 쓴다. llama.cpp에 Vulkan을 직접 붙여야 GPU가 제대로 동작한다.
• 긴 프롬프트를 미리 읽는 프리필(prefill) 단계에서는 리눅스의 오픈소스 radv 드라이버가 윈도우보다 약 3배 빨랐다.
• 토큰을 생성하는 디코드 단계는 어떤 OS·백엔드를 써도 거의 같았다. 이 구간의 병목은 연산이 아니라 메모리 대역폭이었다.
• 메모리를 1개(싱글 채널)에서 2개(듀얼 채널)로 바꾸자 모든 OS에서 디코드 속도가 약 2배로 뛰었다.

쉽게 이해하기

발표자는 AMD 라이젠 AI 9 HX 470(Strix Point APU, 12코어·Radeon 890M 내장 GPU·50 TOPS NPU)을 얹은 GEEKOM A9 Max 미니 PC 한 대에 윈도우, WSL(윈도우 속 리눅스), 바탕 리눅스를 각각 설치했다. 그리고 같은 모델과 같은 프롬프트로 로컬 LLM을 돌려 어떤 운영체제가 유리한지 측정했다.

윈도우에서 가장 흔히 쓰는 Ollama는 기본 설정에서 AMD 내장 GPU를 무시하고 CPU만 100%로 쓴다. GPU를 직접 다루는 API인 Vulkan을 llama.cpp에 붙이자 비로소 GPU가 돌았지만, 성능 향상은 Ollama의 CPU 대비 약 10%에 그쳐 기대보다 낮았다. AMD의 Lemonade 서버는 프리필에 NPU, 디코드에 GPU를 나눠 쓰는 하이브리드 방식으로 디코드 성능이 llama.cpp Vulkan과 비슷하게 나왔다.

WSL에서는 기본 우분투 패키지에 내장 GPU를 인식시키는 Mesa 드라이버(dznICD.json)가 빠져 있어 처음엔 GPU가 보이지 않았다. 별도 저장소에서 Vulkan 드라이버를 설치하자 내장 GPU가 잡혔고, 다만 윈도우 네이티브 대비 처리량의 6분의 1가량을 손해 봤다. 리눅스 도구 체인을 윈도우 안에서 그대로 쓰는 편의의 대가인 셈이다.

바탕 리눅스에서는 Ollama, llama.cpp Vulkan(radv), llama.cpp ROCm 세 백엔드의 디코드 성능이 서로 몇 퍼센트 안에서 붙었다. 그러나 긴 프롬프트를 처리하는 프리필에서는 리눅스 radv가 윈도우보다 약 3배 빨랐다. 코드 저장소 전체를 붙여넣고 답을 얻는 것처럼 RAG·에이전트·코딩 보조에서 중요한 작업이 바로 이 프리필이다.

가장 큰 발견은 디코드 속도가 어느 OS에서도 똑같이 낮았던 이유였다. 발표자가 기기를 열어 보니 메모리 슬롯 2개 중 1개만 꽂혀 있어 싱글 채널로 동작하고 있었다. 칩이 기대하는 대역폭의 절반만 쓰고 있던 것이다. 메모리를 한 짝 더 꽂아 듀얼 채널로 만들자 모든 OS의 디코드 속도가 약 2배로 올랐다. 연산이 아니라 메모리 대역폭이 진짜 벽이었다는 교과서적 사례다.

주요 인사이트

• 윈도우에서 로컬 LLM을 쓸 때 Ollama를 그대로 쓰면 GPU를 못 살릴 수 있으니 llama.cpp에 Vulkan을 직접 붙이는 편이 낫다.
• 운영체제 선택은 특히 긴 프롬프트 프리필에서 크게 갈린다. 코드베이스·문서를 통째로 넣는 작업이 잦다면 리눅스가 유리하다.
• 토큰 생성(디코드) 속도가 안 나오면 GPU가 아니라 메모리 구성을 먼저 의심해야 한다. 대역폭은 연산으로 우회할 수 없다.
• AMD 계열 미니 PC를 살 때 '싱글 채널' 또는 메모리 1개 표기가 있으면 반드시 같은 규격 메모리를 한 짝 더 맞춰 듀얼 채널로 구성하라.

자주 묻는 질문

관련 AI 소식