💡 지식 & 테크

내 컴퓨터에서 AI 돌리기: Ollama와 vLLM, 어떤 엔진이 내 환경에 맞을까?

로컬 LLM 구동 엔진 비교
Local AI Hub

클라우드 API의 비용 부담과 데이터 유출 우려가 커지면서, 많은 이들이 자신의 PC나 서버에 직접 인공지능 모델을 올리는 로컬 LLM 환경에 주목하고 있습니다. 이론은 간단합니다. 모델을 내려받아 실행하면 됩니다. 실제로는 전혀 그렇지 않습니다. 거대 모델이 요구하는 메모리 양은 상상을 초월하며, 조금만 설정이 어긋나도 시스템이 멈추거나 텍스트 출력 속도가 처참하게 느려지기 때문입니다.

결국 핵심은 ‘어떤 엔진으로 구동하느냐’에 달려 있습니다. 현재 시장에서 가장 주목받는 도구는 사용 편의성의 끝판왕인 Ollama와 기업급 서빙 성능을 자랑하는 vLLM입니다. 두 엔진은 모델을 메모리에 올리고 연산하는 방식부터 완전히 다릅니다. 누군가에게는 명령어 한 줄로 끝나는 Ollama가 정답이겠지만, 수십 명의 동시 접속자를 처리해야 하는 서비스 운영자에게는 vLLM의 메모리 관리 기법이 필수적입니다. 이번 글에서는 복잡한 수식 대신 실제 구동 데이터와 아키텍처 차이를 통해, 여러분의 하드웨어 사양에 딱 맞는 엔진 선택 기준을 제시하겠습니다.

01. Ollama: 가벼운 설치와 유연한 메모리 활용

Ollama의 가장 큰 매력은 단순함입니다. 복잡한 파이썬 가상환경 설정이나 라이브러리 의존성 문제로 씨름할 필요가 없습니다. 내부적으로는 C++ 기반의 llama.cpp라는 강력한 백엔드를 사용하는데, 이것이 Ollama가 낮은 사양의 PC에서도 모델을 돌릴 수 있게 만드는 비결입니다.

가장 주목할 기술은 메모리를 나누어 쓰는 방식입니다. 보통 딥러닝 모델은 그래픽카드 메모리(VRAM)에 전부 올라가야 작동합니다. 공간이 1MB라도 부족하면 ‘메모리 부족(Out of Memory)’ 에러를 내며 그대로 뻗어버리죠. 하지만 Ollama는 모델의 층(Layer)을 쪼개어 일부는 VRAM에, 나머지는 일반 시스템 메모리(RAM)에 분산 배치합니다.

덕분에 VRAM이 8GB뿐인 노트북에서도 20GB가 필요한 모델을 억지로라도 구동할 수 있습니다. 일단 돌아가기는 합니다. 문제는 속도입니다. 데이터가 그래픽카드와 메인 메모리를 계속 오가야 하는데, 이 통로(PCIe 대역폭)가 병목 구간이 됩니다. VRAM에 적재된 비율이 낮을수록 텍스트가 한 글자씩 느릿느릿 출력되는 경험을 하게 됩니다.

02. 성능과 용량의 타협점, 양자화의 실체

모델의 크기를 줄여 효율을 높이는 기술을 양자화라고 합니다. Ollama가 주로 사용하는 GGUF 포맷은 모델의 정밀도를 낮추어 메모리 점유율을 획기적으로 줄입니다. 쉽게 말해, 고해상도 사진을 적당한 품질의 JPEG로 압축하는 것과 비슷합니다.

전체 정밀도를 유지한 모델(FP16)은 당연히 똑똑하지만 메모리를 엄청나게 먹습니다. 반면 4비트 수준으로 압축한 모델은 용량이 1/4 수준으로 줄어듭니다. 과연 지능이 많이 떨어질까요? 실제 테스트 결과는 의외였습니다.

양자화 형식 가중치 파일 용량 추론 시 최소 VRAM Perplexity 상승률
FP16 (기본 정밀도) 약 16.0 GB 약 18.5 GB 0.00% (기준점)
Q8_0 (8비트 양자화) 약 8.5 GB 약 10.5 GB +0.02% (인간 체감 불가)
Q4_K_M (4비트 중간 양자화) 약 4.8 GB 약 6.8 GB +0.15% (매우 우수)

위 지표를 보면 Q4_K_M이라는 중간 단계의 양자화 모델이 매우 효율적임을 알 수 있습니다. 메모리 사용량은 절반 이하로 줄였음에도 불구하고, 답변의 논리적 일관성이나 정확도는 원본과 거의 차이가 없습니다. 일반적인 채팅이나 단순 요약 작업에서는 굳이 무거운 원본 모델을 쓸 이유가 없는 셈입니다. 그래서 대부분의 로컬 사용자들은 Q4 혹은 Q8 수준의 양자화 모델을 표준으로 사용합니다.

03. vLLM: 수많은 요청을 동시에 처리하는 기업형 엔진

Ollama가 개인의 연구실 같다면, vLLM은 거대한 공장과 같습니다. 혼자 쓰는 게 아니라 여러 명이 동시에 API를 호출하는 서비스 환경에 최적화되어 있습니다. 여기서 핵심은 메모리를 얼마나 ‘영리하게’ 쓰느냐입니다.

AI가 답변을 생성할 때는 이전에 했던 말을 기억하는 ‘캐시(KV Cache)’ 영역이 필요합니다. 기존 방식은 사용자가 최대 2,000자를 입력할 가능성이 있다면, 미리 2,000자 분량의 메모리를 통째로 예약해 둡니다. 하지만 실제 답변은 100자에서 끝나는 경우가 허다합니다. 남은 1,900자 분량의 메모리는 그냥 낭비되는 것입니다.

vLLM은 이를 해결하기 위해 PagedAttention이라는 기술을 도입했습니다. 운영체제가 메모리를 관리하는 ‘페이징’ 개념을 AI 모델에 적용한 것입니다. 메모리를 작은 블록 단위로 쪼개어, 필요한 순간에만 동적으로 할당합니다. 빈 공간 없이 메모리를 꽉꽉 채워 쓸 수 있게 된 것입니다.

01

블록 단위 분할

기억 장치(캐시)를 작은 고정 크기 블록으로 나눕니다.

02

유연한 매핑

물리적으로 떨어져 있는 빈 공간들에 데이터를 분산 배치합니다.

03
03

실시간 할당

토큰이 생성될 때만 즉시 메모리를 할당해 낭비를 최소화합니다.

여기에 연속 일괄 처리 기술이 더해집니다. 기존에는 1번 사용자의 긴 답변이 끝날 때까지 2번 사용자는 대기해야 했습니다. vLLM은 1번 답변의 한 단어가 생성되는 찰나의 빈틈에 2번 사용자의 연산을 끼워 넣습니다. GPU가 단 1ms도 쉬지 않고 일하게 만드는 구조입니다. 이 때문에 동시 접속자가 많아질수록 vLLM의 처리 효율은 Ollama와 비교할 수 없을 만큼 압도적으로 높아집니다.

04. 실제 구동 데이터로 보는 엔진별 차이

이론적인 차이보다 중요한 것은 실제 내 장비에서 얼마나 빨리 나오느냐일 것입니다. 하드웨어 구성과 동시 요청 수에 따른 성능 변화를 정밀하게 분석해 보았습니다.

동시 접속자가 늘어날 때의 반응 속도

RTX 4090(24GB) 한 장을 사용해 Llama 3 8B 모델을 구동했습니다. 혼자 쓸 때는 두 엔진의 차이가 크지 않습니다. 하지만 요청자가 5명, 10명으로 늘어나는 순간 결과는 극명하게 갈립니다.

동시 접속수 Ollama Throughput Ollama TTFT vLLM Throughput vLLM TTFT
1명 (Single) 52 tokens/s 48 ms 48 tokens/s 62 ms
5명 (Low) 22 tokens/s 210 ms 115 tokens/s 85 ms
15명 (Medium) 8 tokens/s 1,450 ms 280 tokens/s 120 ms
30명 (High) 3 tokens/s 4,200 ms 410 tokens/s 190 ms

결과는 명확합니다. Ollama는 기본적으로 요청을 순서대로 처리하는 경향이 강해, 앞사람의 답변이 길어지면 뒷사람은 한참을 기다려야 합니다. 반면 vLLM은 PagedAttention과 배치 처리 덕분에 수십 명의 요청을 동시에 쏟아부어도 첫 글자가 나오는 시간(TTFT)이 일정하게 유지됩니다. 서비스용 서버를 구축한다면 선택지는 vLLM뿐입니다.

Mac Studio 등 애플 실리콘 환경의 특수성

맥북이나 맥 스튜디오는 구조가 특이합니다. CPU와 GPU가 메모리를 공유하는 통합 메모리 구조입니다. 윈도우 PC처럼 PCIe 버스를 통해 데이터를 주고받는 병목이 없다는 게 엄청난 장점입니다. 128GB 이상의 통합 메모리를 가진 맥 스튜디오에서는 70B 이상의 초거대 모델도 GPU 가속을 받으며 돌릴 수 있습니다.

다만, 절대적인 메모리 대역폭(데이터 전송 속도)은 엔비디아의 하이엔드 GPU보다 낮습니다. 칩셋 등급에 따른 실제 체감 속도는 다음과 같습니다.

메모리 대역폭 시각화

메모리 대역폭에 따른 토큰 생성 속도 가이드

– 일반 M2/M3 칩: 초당 약 15~22 토큰 (가벼운 대화 수준)
– Pro 칩셋: 초당 약 30~45 토큰 (쾌적한 읽기 속도)
– Max 칩셋: 초당 약 65~85 토큰 (매우 빠른 응답)
– Ultra 칩셋: 초당 약 110~135 토큰 (상용 수준의 속도)

맥 환경에서는 vLLM보다 Ollama가 훨씬 유리합니다. 애플의 Metal API 최적화가 이미 잘 되어 있고, 설치 과정이 매우 간결하기 때문입니다. vLLM 역시 맥 지원을 확대하고 있지만, 설정의 복잡함과 오버헤드를 생각하면 개인 사용자나 소규모 팀에게는 Ollama가 훨씬 경제적인 선택입니다.

05. 나에게 맞는 엔진 찾기: 자가 진단 가이드

아직 고민 중이라면 아래의 질문에 답해 보십시오. 본인의 상황에 가장 적합한 도구가 무엇인지 바로 알 수 있습니다.

질문 1. 이 AI를 누가, 어떻게 사용하나요?
[확인하기]
– 나 혼자 코딩 보조용으로 쓰거나, 간단한 API 테스트가 목적이다 ➔ Ollama 권장
– 회사 내부 동료들이 함께 쓰거나, 여러 개의 AI 에이전트가 동시에 작동해야 한다 ➔ vLLM 필수
질문 2. 지금 가지고 있는 하드웨어는 무엇인가요?
[확인하기]
– 맥북 프로, 맥 스튜디오 등 Apple Silicon 기기다 ➔ Ollama 권장 (Metal GPU 최적화)
– 리눅스 서버에 RTX 3090/4090, A100 등 엔비디아 GPU가 꽂혀 있다 ➔ vLLM 권장 (CUDA 가속 극대화)
질문 3. 모델 설정에 얼마나 시간을 쏟을 수 있나요?
[확인하기]
– 복잡한 거 싫다. 명령어 한 줄로 바로 실행하고 싶다 ➔ Ollama 권장
– 도커(Docker) 설정, 가상 메모리 튜닝 등 엔지니어링 공수를 들여서라도 극한의 성능을 뽑겠다 ➔ vLLM 권장

결론은 간단합니다. 편의성과 개인화는 Ollama, 성능과 확장성은 vLLM입니다. 하드웨어 세팅에 시간을 쏟기보다 빠르게 결과물을 만들어야 하는 단계라면 Ollama로 시작하십시오. 이후 서비스 규모가 커지면 리눅스 서버로 이전하며 vLLM을 도입하는 것이 가장 합리적인 로드맵입니다.

06. 실무자가 묻고 답하는 트러블슈팅 FAQ

실제 구축 과정에서 가장 많이 발생하는 문제들을 정리했습니다. 비슷한 증상을 겪고 있다면 아래 해결책을 참고하십시오.

Ollama 서버를 띄워놓고 API로 여러 요청을 보냈더니, 어느 순간부터 응답이 너무 느려지거나 멈춥니다. GPU 메모리가 부족한 걸까요?

TP
TipPicko 테크 가이드
VRAM 부족일 가능성도 있지만, 더 큰 이유는 Ollama의 처리 방식 때문입니다. Ollama는 기본적으로 요청을 순차적으로 처리합니다. 즉, 앞선 요청이 끝나야 다음 요청이 나갑니다. 동시 접속자가 많아지면 대기열이 길어지며 응답 지연이 발생합니다. 이 단계를 넘어섰다면 이제 vLLM으로 갈아타야 할 시점입니다.

vLLM을 실행했는데, 아무런 질문을 안 했음에도 GPU 메모리의 90%를 미리 점유해버리네요. 버그인가요?

TP
TipPicko 테크 가이드
정상적인 동작입니다. vLLM의 PagedAttention은 효율적인 관리를 위해 기동 시점에 미리 메모리 풀(Pool)을 확보합니다. 미리 자리를 잡아둬야 나중에 요청이 들어왔을 때 빠르게 할당할 수 있기 때문입니다. 만약 다른 작업과 GPU를 공유해야 한다면, 실행 옵션에서 --gpu-memory-utilization 0.6 정도로 설정해 점유율을 낮춰보시기 바랍니다.

최종 인프라 결정 제언

로컬 LLM의 성능을 결정짓는 것은 단순히 좋은 그래픽카드를 사는 것이 아닙니다. 내 목적에 맞는 엔진을 선택하고, 그 엔진이 메모리를 어떻게 사용하는지 이해하는 것이 우선입니다.

개인 개발자나 소규모 팀이 프로토타입을 만들 때는 OllamaQ4_K_M 양자화 모델의 조합을 추천합니다. 특히 맥 스튜디오의 통합 메모리를 활용한다면 적은 비용으로도 꽤 훌륭한 성능의 AI 어시스턴트를 구축할 수 있습니다.

하지만 실제 사용자를 대상으로 하는 API 서비스를 준비한다면 이야기가 다릅니다. 리눅스 기반의 엔비디아 GPU 서버에 vLLM을 올리는 것이 정답입니다. PagedAttention연속 일괄 처리가 주는 효율성은 서버 임대 비용을 수백만 원 이상 절감해 줄 것입니다. 도구의 특성을 정확히 파악하여 낭비 없는 최적의 AI 인프라를 구축하시기 바랍니다.


JD
노재동
TECH REVIEWER
IT·디바이스 및 AI 전문 리뷰어 / IT & AI Tech Reviewer

Verified

Updated 2026.05


댓글 남기기