
들어가며
LLM을 로컬에서 돌려본 사람이라면 한 번쯤은 이런 문구를 만나신적이 있으실겁니다.
“CUDA out of memory”
딥러닝 실험의 상징(?) 같은 문장이죠.
저 또한 RTX 3060 Ti (8GB VRAM)으로 LLM을 실행하려다가 수없이 맞닥드렸던 문구입니다.
물론 LLM을 양자화(Quantization)하면 필요한 VRAM을 줄일 수는 있습니다. 하지만 그 대가로 정확도와 추론 품질의 저하를 감수할수 밖에 없는게 현실입니다.
클라우든 인스턴스를 써서 테스트 해볼 수 있지만 비용이 만만치 않기 때문에 그 것또한 부담이었습니다.
이런 상황에서 oLLM이라는 흥미로운 라이브러리(프로젝트)를 발견했습니다.
oLLM은 모델을 양자화하지 않고도 8GB GPU에서 Qwen3-Next-80B 모델을 실행할 수 있게 해줍니다.
핵심 비결은 양자화가 아니라 오프로딩(Offloading)입니다. 즉, GPU 메모리에 모든 가중치를 올리지 않고, 필요한 순간에만 SSD에서 불러오는 방식입니다. SSD를 일종의 확장 메모리처럼 활용하는 셈입니다.
이러한 방법이 가능 한 이유 중 하나가 MoE 아키텍쳐 덕분이라는 생각이드는데, MoE에 대해서는 다음에 따로 정리를 하도록하고
이번 글에서는 oLLM에 대해 알아보도록 하겠습니다.
oLLM
공식 REPO : https://github.com/Mega4alik/ollm
GitHub - Mega4alik/ollm
Contribute to Mega4alik/ollm development by creating an account on GitHub.
github.com
oLLM의 o가 정확히 어떤것인지에 대해서는 알아내지 못했지만 아무래도 oLLM의 핵심 기법인 offloading이 아닌가 추측됩니다.
oLLM의 세 가지 핵심 기술
1.SSD에서의 지연 로딩(Lazy Loading)
일반적인 LLM은 전체 가중치를 VRAM에 한 번에 적재합니다.
반면, oLLM은 지연 로딩(lazy loading) 방식을 적용하여, 연산이 필요한 시점에 해당 레이어의 가중치만 SSD에서 불러옵니다.
이 덕분에 80B 모델도 약 5.4GB 수준의 VRAM으로 실행할 수 있습니다.
2. DiskCache를 통한 KV 캐시 오프로딩
긴 컨텍스트를 처리할 때 가장 많은 VRAM을 차지하는 요소는 KV 캐시입니다. oLLM은 이를 DiskCache로 SSD에 저장함으로써 VRAM 사용량을 획기적으로 절감합니다.
이 방식으로 10만 토큰 이상의 컨텍스트를 단 5GB VRAM만으로 처리할 수 있습니다.
3. 청크 기반 MLP 및 FlashAttention-2
연산 과정에서도 메모리 초과가 발생하지 않도록 oLLM은 두 가지 추가 전략을 사용합니다.
- 청크 기반 MLP: 대규모 행렬 연산을 더 작은 청크 단위로 분할하여 VRAM 폭증을 방지합니다.
- FlashAttention-2: 중간 연산값을 저장하지 않고 즉시 처리함으로써, 속도와 메모리 효율을 동시에 확보합니다.
결과적으로 oLLM은 “VRAM 대신 SSD를 활용하는 새로운 추론 패러다임”을 보여줍니다.
그들의 철학은 명확합니다.
“슈퍼컴퓨터는 필요 없습니다. 충분히 빠른 SSD면 됩니다.”
실제 수치로 본 oLLM의 효율성
oLLM의 공식 GitHub repo에서 다양한 모델에 대한 구체적인 메모리 사용량을 비교한 결과를 확인 할 수 있습니다.
이 자료는 oLLM이 실제로 얼마나 효율적으로 VRAM을 절약하는지를 잘 나타냅니다.
| Model | Weights | Context length | KV cache | Baseline VRAM | oLLM GPU VRAM | oLLM Disk (SSD) |
|---|---|---|---|---|---|---|
| qwen3-next-80B | 160 GB | 50k | 20 GB | ~190 GB | ~7.5 GB | 180 GB |
| gpt-oss-20B | 13 GB | 10k | 1.4 GB | ~40 GB | ~7.3 GB | 15 GB |
| gemma3-12B | 25 GB | 50k | 18.5 GB | ~45 GB | ~6.7 GB | 43 GB |
| llama3-1B-chat | 2 GB | 100k | 12.6 GB | ~16 GB | ~5 GB | 15 GB |
| llama3-3B-chat | 7 GB | 100k | 34.1 GB | ~42 GB | ~5.3 GB | 42 GB |
| llama3-8B-chat | 16 GB | 100k | 52.4 GB | ~71 GB | ~6.6 GB | 69 GB |
※ “Baseline”은 오프로딩 없이 일반적인 추론 환경에서의 GPU VRAM 사용량을 의미합니다.
표에서 확인할 수 있듯이, 예를 들어 Qwen3-Next-80B 모델은 기존 방식이라면 약 190GB의 VRAM이 필요하지만, oLLM을 이용하면 GPU는 약 7.5GB, SSD는 180GB만 사용하여 동일한 모델을 실행할 수 있습니다.
oLLM의 의의와 한계
oLLM의 등장은 “대규모 언어 모델의 로컬 활용”이라는 가능성을 현실화한 중요한 전환점입니다.
이제 고가의 A100이나 H100 GPU 없이도, 개인용 PC에서 LLM을 통해 데이터를 분석하거나 실험할 수 있게 되었습니다.
다만 한계도 분명합니다.
SSD 기반 오프로딩은 VRAM 대비 속도가 느리므로, 실시간 대화형 애플리케이션에는 적합하지 않습니다.
실제 테스트결과 gtx 3060 12GB 환경에서 gpt-oss-20B 모델로 512 토큰을 생성하는 데 약 4시간이 소요되었습니다.
SSD의 성능에 따라 차이가 있긴 하지만, 전반적으로 속도가 지나치게 느려 아직까지 실용적인 수준의 응답성을 확보하기는 어렵습니다.
그 때문인지 공식 문서에서도 다음과 같은 작업에 적합하다고 언급하고 있습니다.
- 대규모 계약서, 규제 문서, 컴플라이언스 보고서 분석
- 의료 데이터나 환자 이력 기록 요약 및 인사이트 추출
- 대용량 로그 파일 또는 보안 위협 리포트의 로컬 분석
- 고객 상담 기록(챗 로그)을 기반으로 빈출 질문이나 문제 유형 도출
마무리하며
oLLM은 VRAM의 한계를 ‘양자화’가 아닌 ‘오프로딩’이라는 접근으로 해결했습니다.
지금까지 LLM 활용의 장벽은 “좋은 GPU”였습니다. oLLM은 이 벽을 “더 똑똑한 자원 활용”으로 허물었습니다.
양자화가 아닌 오프로딩, 비용이 아닌 설계방식의 차이.
이 기술 덕분에 개인 개발자도 이제 거대한 모델을 직접 다뤄볼 수 있는 시대가 열리고 있습니다.
앞으로는 “얼마나 좋은 GPU를 가졌는가”보다, “그 GPU를 얼마나 효율적으로 쓰는가” 가 더 중요한 질문이 될 것 같습니다.
Reference
'AI > LLM' 카테고리의 다른 글
| LLM은 진짜 100K 토큰을 전부 다 볼까? (0) | 2026.01.04 |
|---|---|
| GPT-OSS (0) | 2025.11.23 |
| Context Engineering (0) | 2025.09.11 |
| Testing 18 RAG Techniques to Find the Best (1) | 2025.05.27 |
| LLM을 서빙하는 프레임워크, vLLM 사용법 (0) | 2025.05.06 |