GPU가 없는 노트북에서 180B 모델을 실행하는 방법: 4비트 GGUF가 전체 정확도를 유지하는 원리

과거에는 최첨단(frontier-class) 모델이란 데이터센터 GPU 여러 대를 의미했습니다. 이 게시물은 그 가정을 깨뜨립니다.

POCKET-Darwin-180B-GGUF는 1,800억 개의 매개변수를 가진 Darwin-180B-RSI의 4비트 빌드 버전으로, GPU 없이도 실행되도록 패키징되었습니다. 이 모델은 Hugging Face와 ModelScope에서 GGUF 형태로 배포됩니다. 2026년 10월 기준으로 측정된 주요 수치들은 다음과 같습니다:

• 크기: 111 GB (4비트 GGUF, 4개 파일)로, 360 GB (BF16, 131개 파일)에서 감소했습니다.
• CPU 전용: 단일 서버 CPU(16 스레드)를 사용하여 초당 18.4~21.0 토큰을 생성하며, 최대 메모리는 78.8 GB입니다.
• 노트북: RTX 5060 Laptop (8 GB VRAM)과 32 GB RAM으로 초당 4.17 토큰으로 실행됩니다.
• 미니 PC: 128 GB RAM의 미니 PC는 전체 모델을 메모리에 올려놓고 GPU 없이 작동합니다.
• 정확도: MMLU-Pro, 2,000개 질문, 쌍 비교 테스트에서 **원본 대비 87.65% vs 양자화 버전 87.65%**를 기록했습니다.

요약 (TL;DR)

1,800억 개의 매개변수를 가진 Mixture-of-Experts(MoE) 모델은 토큰당 약 3B개의 매개변수만 활성화합니다. 이러한 희소성(sparsity)에 4비트 양자화(quantization)를 결합하여 학습 과정에서 실제로 변경된 가중치 중 작은 분율을 높은 정밀도로 유지하면, 노트북급 메모리에 들어오면서도 전체 모델처럼 답변하는 모델을 얻을 수 있습니다. 이 모델은 llama.cpp로 단 하나의 명령어로 실행할 수 있습니다. 본 게시물에서는 이것이 작동하는 원리와 재현 방법을 설명합니다.

180B 모델이 노트북에 들어가는 방법은 무엇인가요?

이것을 가능하게 하는 것은 두 가지이며, 둘 다 마법이 아닙니다.

첫째, 아키텍처가 희소(sparse)합니다. Darwin-180B는 Mixture-of-Experts (MoE) 모델입니다. 512개의 전문가 서브 네트워크 중 토큰당 단 10개만 선택됩니다. 총 1,800억 개의 매개변수 중 주어진 토큰에 대해 활성화되는 것은 대략 3B입니다. 밀집된 부분(attention, routing, embeddings)은 매 단계마다 실행되며, 전문가 가중치는 필요할 때 읽어옵니다. llama.cpp는 파일을 메모리 맵핑(memory-map)하여 운영체제가 전문가 텐서(expert tensors)를 필요한 시점에 불러오고 내보낼 수 있게 하므로, 한 번에 111 GB 전체가 상주할 필요가 없습니다. 128 GB 미니 PC에서는 모든 것이 RAM에 존재하며, 32 GB 노트북의 경우 운영체제가 디스크의 GGUF 파일과 교환(page)하면서 작동하기 때문에 속도는 느리지만 여전히 실행이 가능합니다.

두 번째로, 양자화는 선택적입니다. 이 빌드는 커뮤니티가 검증한 베이스 가중치(base weights)의 4비트 양자화에서 시작합니다. 그 위에, 자가 개선 학습(self-improvement training)이 실제로 수정한 부분(전체 용량의 약 3%)만 더 높은 정밀도로 유지됩니다. 신호가 있는 곳에 비트 예산을 사용하며, 균일하게 사용하지 않습니다. 이것이 '4비트 및 손실성(lossy)'과 '벤치마크에서의 4비트 및 무손실성(lossless)'의 차이입니다.

4비트 양자화가 여기서 정확도를 떨어뜨릴까요?

측정된 벤치마크에서는 그렇지 않습니다. 양자화 손상도를 확인하는 정직한 방법은 **쌍 비교(paired comparison)**입니다. 동일한 질문, 동일한 디코딩 방식을 사용하며, 원본 모델과 양자화된 모델을 항목별로 비교합니다. MMLU-Pro(2,000개 질문)에서 원본 모델과 4비트 빌드 모두 **87.65%**를 기록했습니다. 동일합니다.

이 결과는 구체적이며 주의 깊게 읽을 가치가 있습니다. 이것이 4비트가 일반적으로 무료라는 의미는 아닙니다. 이것은 이 모델의 경우, 이 벤치마크에서, 학습된 변화량(trained delta)을 보호하는 선택적 방식을 사용했을 때, 손실 폭이 측정 해상도 이하라는 의미입니다. 양자화 오류는 가장 많은 작업 관련 신호를 담고 있는 가중치에 집중되므로, 그 3%를 보호하는 것이 점수를 유지시키는 핵심입니다.

두 번째로 더 미묘한 결과가 있습니다. SuperGPQA(1,000개 대학원 수준 과학 질문으로, 학습에 사용된 적 없음)에서 양자화된 POCKET 빌드를 베이스 모델의 동일한 4비트 양자화와 비교했습니다. POCKET은 **61.55% 대 59.10%**를 기록하며 2.45점 향상을 보였고, 이는 통계적으로 유의미하게 유지되었으며, 질문당 약 13% 적은 토큰을 사용했습니다. 자가 개선 학습은 모델이 답변을 재도출하는 대신 확신하여 답하도록 가르쳤고, 양자화는 그 행동을 보존했습니다. 제3자 개발자가 공개 스레드에서 파일 수준으로 이를 재현했습니다.

POCKET-Darwin-180B-GGUF를 실행하려면 어떻게 해야 하나요?

최신 llama.cpp 빌드(b11048 이상), 네 개의 GGUF 파일(총 111 GB), 그리고 모델을 메모리에 로드하거나 페이지할 수 있는 충분한 메모리가 필요합니다. CPU 경로의 경우 클라우드 계정이나 GPU 드라이버 스택이 필요하지 않습니다.

1. llama.cpp 빌드하기 (b11048 이상)

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
...

측정 결과에서 얻은 몇 가지 실질적인 참고 사항:

• 스레드가 중요합니다. 서버 CPU 결과는 16개의 스레드를 사용했습니다. -t 옵션을 물리적 코어 수와 일치시키세요. 코어 수를 초과하여 스레드를 과도하게 할당하는 것은 일반적으로 생성 속도를 높이기보다 늦춥니다.
• 메모리가 경로를 결정합니다. RAM이 128 GB인 경우 모델이 메모리에 상주하며 최고 수준의 성능을 얻을 수 있습니다. 32 GB인 경우 OS가 전문가(expert) 텐서를 디스크에서 페이징하므로 처리량(throughput)이 초당 몇 개의 토큰으로 떨어집니다. 빠른 NVMe SSD는 이 페이징 경로에 눈에 띄게 도움을 줍니다.
• 컨텍스트 길이도 메모리를 소모합니다. 78.8 GB라는 수치는 작업 컨텍스트가 최대일 때의 피크 값입니다. -c를 높이면 가중치(weights) 외에 KV-캐시(KV-cache)의 크기가 증가합니다.
• GPU 오프로드는 선택 사항입니다. 8 GB 노트북 GPU의 경우, 레이어 중 일부만 VRAM에 들어갈 수 있으므로 대부분의 작업은 여전히 CPU와 RAM에서 처리됩니다. 4.17 tok/s라는 수치는 이러한 혼합된 경로를 반영합니다.

CPU 전용 180B 모델이 실제로 적절한 경우?

처리량(Throughput) 자체가 정직한 트레이드오프입니다. 서버 CPU에서 21 tok/s는 배치 작업, 초안 작성, 추출, 그리고 지연 시간(latency)을 허용하는 에이전트 단계에는 충분합니다. 노트북에서 4 tok/s는 채팅 제품이라기보다는 개발자의 편의성입니다. 대규모로 상호작용적인 속도가 필요하다면 GPU가 여전히 우세합니다.

CPU 경로가 강점을 가지는 곳은 데이터가 건물 외부로 나갈 수 없는 경우입니다. 연결이 차단된(air-gapped) 서버, 공장 바닥의 미니 PC, 아웃바운드 연결이 없는 국방, 금융 또는 공공 부문 장비: 이곳에서는 로컬 CPU와 RAM에서 완전히 실행되며, 한 번 다운로드한 가중치를 사용하는 모델은 타협이 아닙니다. 그것은 정책을 통과시키는 유일한 방법입니다. 엣지 AI(Edge AI)는 종종 밀리초 단위의 속도보다는 바이트가 어디에 머무를 수 있는지가 더 중요합니다.

FAQ

LM Studio나 Ollama에서 실행할 수 있나요?
본 게시물은 GGUF가 목표로 하는 엔진인 llama.cpp 경로(b11048 이상)만을 검증합니다. 다른 구동기(runner)들은 이 특정 빌드를 로드하는지 확인하기 전까지는 테스트되지 않은 것으로 간주하십시오.

RAM에 전체 111 GB가 필요한가요?
아닙니다. 128 GB를 사용하면 최고의 속도를 위해 모델을 메모리에 유지할 수 있습니다. 32 GB의 경우, OS가 GGUF 파일을 메모리 매핑(memory-maps)하고 전문가 텐서(expert tensors)를 필요에 따라 페이징(pages on demand)하여 작은 메모리 공간을 확보하는 대신 처리량(throughput)을 희생합니다. 다만, 디스크에는 전체 111 GB가 필요합니다.

노트북이 서버 CPU보다 훨씬 느린 이유는 무엇인가요?
메모리 때문입니다. 32 GB 노트북은 모델 전체를 담을 수 없기 때문에 디스크에서 페이징하며, 8 GB GPU에는 몇 개의 레이어만 적재됩니다. 충분한 RAM을 가진 16 스레드 서버 CPU는 작업 집합(working set)의 훨씬 더 많은 부분을 '핫'(hot)하게 유지합니다.

4비트가 항상 이렇게 손실이 없는 건가요?
아닙니다. 그리고 일반화하지 마십시오. 87.65% 일치율은 이 모델과 벤치마크에 대해 측정된 쌍별(paired) 결과이며, 학습된 델타(trained delta)(가중치의 약 3%)를 더 높은 정밀도로 유지했기 때문에 가능했습니다. 항상 가정만 하기보다는 쌍별 비교를 통해 직접 양자화(quantization)를 검증하십시오.

활성 파라미터 개수가 왜 그렇게 적은가요?
MoE 라우터는 토큰당 512개의 전문가 중 10개를 선택하므로, 단일 토큰에 대해 약 3B의 파라미터만 작동합니다. 이러한 희소성(sparsity)이 CPU 추론 및 필요에 따른 전문가 로딩을 실용적으로 만듭니다.

어디서 얻을 수 있나요?
huggingface.co/FINAL-Bench/POCKET-Darwin-180B-GGUF와 modelscope.cn/models/FINAL-Bench/POCKET-Darwin-180B-GGUF입니다. 원본은 huggingface.co/FINAL-Bench/Darwin-180B-RSI입니다.

추가 자료 (Further reading)

• 이 시리즈의 이전 글: Offline AI on a Phone: Thread Pinning, Lazy Loading, and a Safety Gate That Knows When to Stay Quiet (휴대폰에서의 오프라인 AI: 스레드 고정(Thread Pinning), 지연 로딩(Lazy Loading), 그리고 조용히 있을 때를 아는 안전 게이트)

본 게시물의 측정값은 2026년 10월 장치 테스트에서 나온 것입니다. 양자화 일치율은 쌍별, 동일 질문 비교로 확인되었으므로, 양자화를 모델별(model-specific)로 취급하고 직접 검증하시기 바랍니다.