GPU 없이 180B 모델 구동하기: llama.cpp와 POCKET-Darwin-180B (GGUF)
요약
GPU 없이도 180B 규모의 대형 언어 모델(LLM)을 구동하는 방법을 소개합니다. POCKET-Darwin-180B-GGUF는 MoE 구조와 4비트 양자화 기술을 활용하여, 전체 파라미터 크기 대비 실제 계산에 필요한 메모리 부하를 크게 줄였습니다. llama.cpp 프레임워크를 사용하면 고사양 GPU 없이도 CPU만으로 높은 성능의 추론이 가능합니다.
핵심 포인트
- MoE 구조 덕분에 180B 모델을 효율적으로 구동할 수 있습니다.
- 4비트 양자화와 GGUF 형식을 통해 메모리 요구량을 대폭 줄였습니다.
- llama.cpp를 사용하면 고성능 GPU 없이도 CPU만으로 LLM 추론이 가능합니다.
- 필요한 전문가(experts)만 필요시 SSD에서 매핑하여 로드하는 방식으로 작동합니다.
요약
POCKET-Darwin-180B-GGUF는 GPU 없이 실행하도록 설계된 오픈 소스 모델 Darwin-180B-RSI의 양자화(quantized) 버전입니다. 배포할 사람들을 위한 핵심 사항은 다음과 같습니다:
- GGUF 형식으로 111 GB 크기이며 (원래 BF16 버전은 360 GB), llama.cpp를 사용하여 실행됩니다.
- CPU만 사용해도 초당 최대 21 토큰까지 가능합니다 (소켓 1개, 스레드 16개, RAM 사용량 78.8 GB). RTX 5060 8GB와 32GB RAM을 가진 노트북의 경우: 4.17 tok/s.
- 원래 모델과 동일한 정확도: MMLU-Pro (2,000 질문)에서 둘 다 87.65%를 기록하며, 모델이 4비트임에도 불구하고 그렇습니다.
- 아키텍처는 **MoE(Mixture of Experts)**입니다: 총 파라미터는 180B이지만, 토큰당 활성화되는 것은 약 3B에 불과합니다 (512개 전문가 중 10개 사용).
- 총 4개의 파일을 다운로드하고 단 하나의 커맨드 라인으로 실행할 수 있습니다.
본 기사에서는 이것이 어떻게 작동하는지, 그리고 어떻게 구동하는지를 설명합니다.
왜 180B 모델이 노트북에 들어갈 수 있나요?
간단히 말해: 모델의 대부분은 매 단계마다 사용되지 않기 때문입니다.
Darwin-180B-RSI는 전문가 혼합(Mixture of Experts, MoE) 모델입니다. 512개의 '전문가' 네트워크를 가지고 있지만, 토큰을 생성할 때 라우터(router)는 단지 10개만 선택합니다. 1800억 개의 파라미터 중 실제로 각 토큰 계산에 관여하는 것은 겨우 30억 개 정도입니다.
이는 배포 계산을 완전히 바꿉니다. 180B의 밀집(dense) 모델이라면 매 토큰마다 180B의 파라미터를 메모리로 이동해야 합니다. 하지만 MoE를 사용하면, 토큰당 산술 작업량은 마치 3B 모델과 비슷하지만, 전체 용량 자체는 여전히 거대한 모델의 수준을 유지합니다. 병목 현상은 계산(compute)이 아니라 가중치를 어디에 저장하고 얼마나 빠르게 읽어올 수 있는지로 바뀝니다.
여기서 양자화(quantization)가 등장합니다. 원래 BF16 버전은 360 GB를 차지합니다. POCKET 버전은 커뮤니티에서 검증된 4비트 양자화를 기반으로 구축되었으며, 오직 VIDRAFT의 자기 지도 학습(self-supervision training)이 실제로 수정한 부분(전체 용량의 약 3%)만 높은 정밀도로 유지됩니다. 그 결과: 디스크에 111 GB가 4개의 GGUF 파일로 분산되어 저장됩니다.
111 GB를 가지고 두 가지 방법이 있습니다:
- RAM 128 GB의 Mini PC: 전체 모델을 메모리에 올려 GPU 없이 실행합니다.
- RAM 32 GB의 노트북: 전체가 들어가지 않으므로, llama.cpp는 필요한 전문가(experts)를 필요할 때마다 메모리 매핑(mmap)을 통해 SSD에서 읽어옵니다. 속도는 느리지만 작동은 합니다.
llama.cpp로 어떻게 실행하나요? (단계별)
GGUF는 오픈 소스 추론 엔진인 llama.cpp가 사용하는 형식입니다. 클라우드 계정이나 GPU 서버가 필요하지 않습니다. 최신 버전의 llama.cpp 빌드(b11048 이상)와 111 GB의 디스크 공간만 있으면 됩니다.
먼저, Hugging Face에서 저장소 파일을 다운로드합니다:
# Hugging Face 클라이언트 설치
pip install -U "huggingface_hub[cli]"
...
다음으로 llama.cpp를 컴파일하고 추론을 실행합니다:
# llama.cpp 컴파일 (b11048 또는 그 이상 빌드)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp && cmake -B build && cmake --build build --config Release
...
엔지니어링 실용 팁:
--threads: CPU의 물리적 스레드 수에 맞게 조정합니다. 테스트 서버(16 스레드)에서는 18.4에서 21.0 tok/s를 얻었습니다.- mmap: llama.cpp는 기본적으로 파일을 매핑하며, 따라서 RAM이 적은 기기에서는 가중치(weights)가 필요할 때마다 SSD에서 읽어옵니다. 빠른 NVMe SSD가 여기서 큰 도움이 됩니다.
- HTTP 서버: 채팅 API와 호환되는 엔드포인트를 노출하려면
llama-cli대신llama-server를 사용하세요.
중요한 참고 사항: 이 모델은 llama.cpp용 GGUF 형식으로 배포됩니다. 다른 데스크톱 도구에 통합하기 전에 엔진 버전을 확인하여 호환성을 검증하십시오.
4비트로 압축하면 정밀도가 떨어지나요?
이것은 양자화된(quantized) 버전에 의존하기 전에 모든 엔지니어가 던지는 질문입니다. 측정된 답변은 다음과 같습니다: 아니요, 적어도 주요 테스트 벤치마크에서는 그렇지 않습니다.
MMLU-Pro는 2,000개의 질문으로 구성된 일반 지식 시험이며, 질문별로 비교했을 때:
| 버전 | MMLU-Pro |
|---|---|
| Original (BF16) | 87.65% |
| POCKET (4 bits) | 87.65% |
동일합니다. 공격적인 양자화(quantization)가 해당 세트의 정확도에 저하를 주지 않았습니다.
게다가, 자가 초월(RSI: Recursive Self-Improvement) 효과에 대한 흥미로운 신호가 있습니다. 대학원 수준 과학 1,000개 질문으로 구성된 SuperGPQA에서는 RSI로 수정된 부분만 기본 모델의 동일한 4비트 버전과 비교했습니다:
- 기본 모델 (4 bits): 59.10%
- POCKET (4 bits): 61.55%
2.45 포인트 향상으로, 통계적으로 유의미합니다. 그리고 이는 질문당 약 13% 적은 토큰을 사용하면서 달성되었습니다: 더 간결하게 추론하고 이미 알고 있는 답변에 대해 재검증하는 것을 멈춥니다. 외부 개발자가 공개 논의에서 이 결과를 파일별로 검증했습니다.
오프라인 고성능 모델은 어떤 경우에 유용한가?
앞서 언급된 모든 내용을 종합했을 때 사용 사례는 명확합니다: 데이터가 클라우드로 나갈 수 없는 환경입니다. 국방, 금융 및 공공 부문은 데이터를 외부 서버로 전송하는 것을 금지하는 규정을 가지고 있습니다. POCKET-Darwin-180B는 로컬 서버나 미니 PC 내에서 인터넷 연결 없이 실행되며, 어떠한 데이터도 조직의 경계를 넘지 않습니다.
비용 비교 또한 중요합니다. H100 GPU 8개로 구성된 서버는 수십만 달러에 달하는 금액대입니다. 그래픽 메모리 8GB와 RAM 32GB를 갖춘 중급 게이밍 노트북은 그보다 훨씬 적은 비용이 듭니다. 속도는 같지 않지만, 배치 작업(batch job)이나 로컬 추론(local inference)의 경우 방정식 자체가 완전히 달라집니다.
자주 묻는 질문 (FAQ)
최소 사양 하드웨어는 무엇인가요?
모델 전체를 메모리에 올리려면 GPU가 없는 128GB RAM을 갖춘 미니 PC가 필요합니다. RAM 32GB로는 SSD에서 mmap 방식으로 작동하며, 속도는 더 느립니다(8GB RTX 5060 노트북에서 측정 시 4.17 tok/s). 빠른 NVMe SSD를 사용하는 것이 매우 권장됩니다.
디스크 공간은 얼마나 차지하나요?
총 111 GB에 달하는 4개의 GGUF 파일로 구성되어 있습니다. 운영체제 캐시를 위해 추가 여유 공간을 확보해 두는 것이 좋습니다.
왜 180B의 파라미터가 CPU에서 이렇게 빠르게 실행되나요?
MoE(Mixture of Experts) 아키텍처 덕분입니다. 토큰당 512개 전문가 중 단 10개만 활성화되어 약 3B의 활성 파라미터와 동일한 효과를 냅니다. 따라서 토큰당 계산량은 낮지만, 실제 난관은 디스크나 RAM에서 가중치(weights)를 읽어오는 속도입니다.
Ollama나 LM Studio에서도 사용할 수 있나요?
이 모델은 llama.cpp(빌드 b11048 이상)용으로 공개 및 테스트되었습니다. 다른 도구와 사용하기 전에, 해당 엔진 버전이 이 아키텍처와 양자화(quantization)를 지원하는지 확인해야 합니다.
4비트 양자화가 신뢰도를 떨어뜨리나요?
MMLU-Pro에서 정확도는 원본과 동일합니다(둘 다 87.65%). 자가 개선 학습(self-supervision training)으로 수정된 부분은 높은 정밀도로 유지되어 품질 보존에 도움이 됩니다.
어디서 다운로드하나요?
Hugging Face(huggingface.co/FINAL-Bench/POCKET-Darwin-180B-GGUF)와 ModelScope(modelscope.cn/models/FINAL-Bench/POCKET-Darwin-180B-GGUF)에서 다운로드할 수 있습니다. 원본 모델은 huggingface.co/FINAL-Bench/Darwin-180B-RSI에 있습니다.
마무리
POCKET-Darwin-180B의 흥미로운 점은 단순히 180B 모델이 GPU 없이 구동된다는 사실을 넘어, 이를 가능하게 만든 일련의 엔지니어링 결정들입니다. 즉, 토큰당 계산량을 줄이는 MoE, 정밀도를 유지하는 4비트 양자화, 그리고 단일 명령줄로 배포할 수 있게 해주는 GGUF와 llama.cpp의 결합입니다. 이 조합은 최고 수준의 모델을 현재 사용 가능한 하드웨어에 가까이 끌어내립니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기