로컬 LLM, 리눅스가 이긴다는 말의 반증 — 실측 데이터가 말하는 진짜 승부처

요즘 "LLM은 리눅스가 빠르다"는 말이 거의 공통 상식처럼 돌아다닙니다. 같은 GPU에 같은 모델을 올리면 리눅스가 당연히 유리하다는 것이죠. 포럼마다 그렇고, 유튜브 제목도 그렇고요.

저는 그 말이 방향은 맞지만 배율은 과장되었다고 생각합니다. 실제로 공개된 Controlled benchmark들을 뒤져보면, OS 때문에 생기는 속도 차이는 대부분 1~3% 수준이고, 오히려 Windows가 이긴 사례가 실제로 존재합니다. 리눅스가 진짜 강하게 이기는 영역은 속도가 아니라 무엇을 할 수 있는가의 범위입니다.

그리고 이 주장을 검증하는 동안 제가 제 PC에서 직접 하나를 재봤는데, 그 결과가 흔한 서사 하나를 뒤집었습니다.

먼저 반례부터. Windows가 이긴Controlled 테스트

Code Craft Studio가 2026-09-17에 공개한 벤치마크가 이 논쟁의 중심에 있습니다. 핵심 결론은 이 한 줄입니다.

The gap runs two to three percentage, sometimes even under 1%. One controlled Ollama test found the opposite. Windows hit 137 tokens per second native. WSL2 hit 124.

같은 조건은 RTX 4080 + Llama 3.2 3B Q4_K_M + Ollama였습니다.

여기서 주목할 건 WSL2가 네이티브 Linux보다 오히려 Windows 네이티브가 더 빠르다는 점입니다. "리눅스 쓰면 빠르다"가 사실이라도, 그 이득의 대부분은 WSL2를 빼고 리눅스를 그대로 쓸 때 나오는 것이지, "리눅스 계열 OS를 쓴다"와는 다른 이야기입니다.

llama.cpp 공식 저장소의 성능 discussion #15013에서도 같은 결론이 나옵니다. RTX 3060 12GB 환경에서 WSL2(Ubuntu 24.04, CUDA 13.3) 기준 tg128(생성 속도)이 75.58 tok/s였고, 네이티브 3060 항목은 72.09 tok/s였습니다. WSL2가 오히려 근소하게 앞서고 있죠. 프롬프트 처리(pp512)는 2407.93 대 2407.67로 0.01% 차이 — 사실상 완전 동일합니다.

직접 그 게시자가 적은 해석을 빌리면, WSL2 패널티는 생성 토큰 기준 약 1.7%이고 프롬프트 처리 기준 무시 가능합니다.

그렇다면 언제 리눅스가 실제로 이기나

Controlled 테스트가 2~3% 수준이라는 건, 그 반대로 특정 조건에서는 15~25% 간격으로 벌어지는 경우가 있다는 뜻이기도 합니다. found된 케이스를 보면 패턴이 분명합니다.

Windows 드라이버가 이미 고도로 튜닝된 AMD 경로. Phoronix가 2025년에 Ryzen 9 9950X3D + Radeon RX 9700 XT 동일 머신에서 Windows 11과 Ubuntu 24.04를 비교했습니다. llama.cpp 양쪽 구동. 결과는 Linux의 Vulkan 드라이버가 Windows의 Vulkan 드라이버를 outright로 이겼습니다. 조건과 무관하게 리눅스가 앞선 유일한 케이스입니다.

그런데 여기에 중요한 반전이 있습니다. llama.cpp Vulkan discussion #10879의 스코어카드 데이터가 어디서 나왔는지 묻는 질문에, llama.cpp 기여자 netrunnereve가 이렇게 답했습니다.

Yeah the scorecard results are on Windows, those drivers are generally much more optimized than the Mesa ones.

AMD Vulkan 경로에서는 Windows의 기존 AMD 드라이버가 Mesa보다 성숙하다는 뜻입니다. 즉 AMD 유저에게 "리눅스가 AMD를 잘 지원한다"는 건 성립하지만, "리눅스가 AMD에서 더 빠르다"는 건 초기에는 성립하지 않았다는 겁니다. Phoronix가 이후 하드웨어 세대를 바꿔서 뒤집은 것이지, 소프트웨어 스택이 원래부터 우위에 있던 게 아닙니다.

대규모 모델에서 격차가 벌어진다. Lubuntu 26.04 대 Windows 11 비교(RTX 5080 16GB GDDR7 + i9-14900KF, llama.cpp b4280c, Vulkan 및 CUDA 12.4, Llama 3.1 70B Q4_K_M)에서는 간격이 분명해집니다.

3B에서 2%였던 격차가 70B에서 15~25%로 벌어졌고, 최저값 기준으로는 26% 차이입니다. 모델이 커질수록 OS 레이어의 오버헤드가 절대적으로 커진다는 뜻으로 읽는 게 맞습니다.

결국 정리하면 이렇습니다. 작은 모델(3B급)에서는 OS가 거의 무관하고, 큰 모델(70B급)에서 리눅스가 실제로 벌기 시작합니다. "리눅스로 이주하세요"를 조언할 수 있는 근거는 여기서 나옵니다.

제가 제 PC에서 직접 본 VRAM 수치

여기서 제가 직접 측정한 값 하나를 넣겠습니다. 예전 글들에서 흔히 나오는 "리눅스 데스크톱은 VRAM을 100MB 이하에서 쓴다"는 주장인데, 제 환경에서 이건 사실이 아니었습니다.

jw-ms7c94 — Ubuntu 25.10, KDE Plasma 6, Xorg, RTX 3070 8GB 상태에서 모델을 하나도 올리지 않고 측정한 값입니다.

$ nvidia-smi --query-gpu=memory.used,memory.total --format=csv
memory.used [MiB], memory.total [MiB]
1163 MiB, 8192 MiB

$ nvidia-smi --query-compute-apps=pid,used_memory --format=csv
(compute 프로세스 0개)

Idle 상태에서 1163 MiB, 전체의 14.2%입니다. compute 프로세스가 하나도 없는, 순수하게 Xorg와 KDE가 잡아먹는 양입니다.

이게 중요한 이유는 DWM 이야기와 직접 맞물리기 때문입니다. Windows의 DWM이 1~2GB를 잡는다는 널리 알려진 전제가 있죠. 제 Linux 데스크톱은 1.1GB를 잡습니다. Windows 데스크톱 대 Linux 데스크톱을 비교하면 격차가 대략 수백 MB 수준이지, 1GB대 폭발이 아닙니다. "리눅스면 2GB를 아낀다"는 식의마케팅 논술은 헤드리스 서버가 아닌 실제 데스크톱 환경에서는 과장이 맞습니다.

한 변 더 붙이자면, Benchmarkاهم 2026년 16GB 카드 테스트에서 관측한 Linux의 VRAM 우위는 동일 부하 대비 약 800MB였습니다. 제 측정치의 1.1GB와 같은 자릿수입니다.

헤드리스를 쓰든 데스크톱을 쓰든 Linux가 이긴다는 건 같은 논리이고, 그러니 처음부터 헤드리스 기준의 수치를 데스크톱으로 옮기는 오독도 꽤 흔합니다.

진짜 리눅스 승부처: 속도가 아니라 범위

여기까지가 속도 이야기였습니다. 그런데 속도 격차는 1~3%밖에 안 됩니다. 이걸 가지고 "하드웨어 업그레이드"를 권할 근거가 안 되는 이유죠. 리눅스로 옮겨야 하는 진짜 이유는 아예 못 하는 것들을 할 수 있게 돼서입니다.

첫째, vLLM은 Windows를 공식 지원하지 않습니다. vLLM 공식 AMD 설치 문서에는 Requirements가 이렇게 적혀 있습니다.

OS: Linux

그리고 fork 저장소의 설명이 더 정확합니다.

Upstream vLLM supports AMD ROCm, but its official GPU requirements list Linux and explicitly state that vLLM does not support Windows natively.

Windows용 ROCm fork들이 나오긴 했지만, 모두 "unvalidated" 상태를 명시하고 있습니다. 경량 서버를 넘어 동시 요청 처리가 목적인 API 서버를 만들려면 선택지가 Linux밖에 없다는 뜻입니다.

둘째, 앞선 vLLM ROCm 벤치마크의 격차는 OS 문제가 아니라 커널 문제입니다. 같은 ROCm 위에서도 attention backend에 따라 TPS가 2.7~4.4배 갈립니다. AMD 서버 하드웨어를 다루는 쪽이 이런 레이어까지 만져야 한다면, 처음부터 Windows를 떠날 이유가 충분합니다.

셋째, WSL2는 메모리를 못 돌려줍니다. WSL2 issue #4166(2019년 6월)은 13년 넘게 열린 상태입니다.

I have seen it grow until nearly 100% of my system memory is in use, and it will not release it until I shut down the WSL 2 VM.

.wslconfig로 제한을 걸어도 Vmmem이 이를 무시한다는 보고가 산재하고, Windows 빌드 19041 이상에서만 전역 설정이 먹힙니다. 게다가 Microsoft Q&A와 Docker 포럼 양쪽에서 같은 답이 반복됩니다: 설정 후 반드시 wsl --shutdown을 해야 한다. 로컬 LLM은 컨텍스트를 잡고 늘려가는 게 일상이라, 메모리 반환 실패가 성능 저하로 직결되는 도메인입니다.

AMD 유저라면 알아야 할 함정

여기에 실측 후 소유한 정보를 하나 넣겠습니다. Ollama는 GPU를 부팅 시점에만 한 번 탐색합니다. 드라이버를 쓰다가, BIOS를 건드리다가, Ollama를 업그레이드하면서 서비스가 실행 중이면, 탐지 결과는 갱신되지 않고 에러 없이 CPU로 떨어집니다.

ortamarco.me에 잘 정리된 사례가 있습니다. RX 7900 XTX에서 CPU 15.89 tok/s 대 GPU 132.48 tok/s, 벌점 8.3배. 로그에는 library=cpu만 찍히고 경고도 없습니다.

여기에 더 나쁜 변형이 있습니다. Ollama 업데이트는 ROCm 번들을 다시 깔아버립니다. 의도적으로 Vulkan으로 바꿔둔 경우에도 업데이트를 하면 조용히 ROCm으로 되돌아가며, 아무도 알려주지 않습니다. 몇 주간 쌓아온 측정값이 그냥 다른 숫자가 됩니다.

같은 MSDN 육각 하나에 Windows Vulkan 로더가 AMD GPU를 못 찾는 문제가 남아 있습니다 (Ollama issue #16677, RX 6650 XT). 번들 로더가 디바이스를 못 찾는다고 하자:

inference falls back to CPU

사용자에게는 아무 경고가 없습니다. 9.6 tok/s에서 52 tok/s로 복구되는 실측 수치까지 붙어 있습니다. Linux에서는 시스템 로더가 그 자리를 대신하니 이 문제는 발생하지 않습니다.

그래서 나온 실무 규칙은 이겁니다.

1. Ryzen 내장 GPU가 있다면 BIOS에서 비활성화. 비용은 0.2 GiB이고, 애매함 축 하나가 사라집니다.
2. 드라이버·BIOS·Ollama 버전에 손댈 때마다 Ollama를 재시작합니다. 선택 사항이 아닙니다. 한 번만 탐색하기 때문입니다.
3. 로그의 compute=가 아니라 library=를 확인합니다.
4. ollama ps가 100% GPU를 말하기 전까지는 어떤 측정도 신뢰하지 않습니다.
5. 컨텍스트 길이는 보낸 값이 아니라 /api/ps에서 읽은 실제값을 씁니다.
6. 메모리 판단은 ollama ps 컬럼이 아니라 시스템 VRAM을 봅니다.
7. WSL 안에서 굴리지 마세요. Windows의 Ollama를 localhost:11434로 가리키게 합니다.
8. 측정 전 Chrome, Spotify, Slack을 닫습니다. tok/s만큼은 조용해야 하고, 범위(reach)에는 훨씬 큽니다.

여기서 알 만한 일. 8번 항목과 앞서 llama.cpp discussion #15013의 측정 결과가 정확히 맞물립니다. 그 게시자는 평범한 데스크톱 상태에서 tg128이 67.27 tok/s였는데, 호스트 GPU 소비 프로세스를 모두 닫고 재측정하니 75.58 tok/s로 +12%, 분산은 약 15배로 조였습니다. 극적인 수치는 아니지만 노이즈 폭이 격차 폭보다 큽니다는 뜻입니다. 2% 차이는 측정 조건에 따라 그대로 사라집니다.

흔한 오해 두 가지

"llama.cpp 빌드 설정이 OS보다 중요합니다." 실제 Linux가 Windows를 19% 넘게 이긴 사례가 있습니다. ianlpaterson.com의 기록입니다. RTX 2060 SUPER가 52.8 tok/s를 나냈는데, 알고 보니 바이너리가 교체 전 Maxwell 카드를 위해 컴파일돼 있었습니다. 드라이버가 런타임에 PTX를 번역하고 있었습니다. 아키텍처 네이티브로 다시 빌드하니:

생성이 약 19%, 프롬프트 처리가 3배 넘게 뛴 겁니다. OS를 바꾸는 것보다 여기서 더 큰 값을 뽑을 수 있다는 뜻입니다.

"가장 빠른 서버는 뭐죠." Mozilla AI가 llama.cpp / llamafile / LM Studio / Ollama를 Mac Studio M4, Linux 서버 NVIDIA L40S, Steam Deck(Vulkan) 세 환경에서 비교했습니다. 프롬프트 처리는 네 서버가 전반적으로 근접했고, 생성 속도에서 갈립니다. llama.cpp와 llamafile이 0.8B와 9B에서 앞서고, Ollama가 27B에서 앞섰습니다. 27B는 스페큘레이티브 디코딩을 draft length 2로 켠 상태였습니다. 즉 서버 선택도 모델 크기에 따라 답이 바뀝니다. 무엇이 우월한지 미리 말할 수 없고, 모델 크기를 정한 다음에야 답이 나오는 구간입니다.

결론

"리눅스가 이긴다"의 정확한 형태는 이렇습니다.

속도만 놓고 보면, 작은 모델에서는 OS가 거의 무관하고(1~3%), 큰 모델에서 리눅스가 15~25% 벌어집니다. 마주 오는 역전이 가능한 정도라서 "리눅스로 이주"를 다그는 근거로 쓰기 어렵습니다.

하지만 리눅스로 옮길 이유는 여전히 충분합니다. vLLM을 쓸 수 있고, CUDA 밖의 경로(AMD Vulkan)가 성숙하며, WSL2의 메모리 반환 결함을 피할 수 있습니다. 이것은 속도 격차가 아니라 가능 여부의 차이입니다.

그리고 내 PC 실측은 이 논쟁에서 제일 널리 퍼진 신화 하나를 치했습니다. 리눅스 데스크톱의 idle VRAM은 100MB가 아니라 1163 MiB였습니다. 헤드리스 서버의 장점을 데스크톱 환경의 증거로 쓰는 오독입니다. VRAM으로 이득을 약속받으려면 헤드리스로 가는 별도의 결정을 해야 하고, 그건 또 다른 트레이드오프입니다.

앞으로 리눅스를 검토하신다면, OS를 바꾸는 것 전에 두 가지를 먼저 확인하십시오. 모델을 GPU에 온전히 올리는가(끝까지 100% GPU인가), 그리고 내 드라이버 스택이 그 카드를 제대로 지원하는가. 두 번째는 OS보다 훨씬 자주 문제의 진짜 원인이 됩니다.