본문으로 건너뛰기
페이지 목차
이 페이지에서 검색

로컬 LLM

이 페이지에 묻기

로컬 LLM · 현재 차시와 목차 본문에서만 찾아 답합니다. 답을 지어내지 않고 해당하는 대목을 그대로 보여 주며, 여기에 없으면 없다고 알려 드립니다.

생성형 AI가 아니라 이 페이지 본문을 찾아 그대로 보여 주는 방식입니다. 외부로 나가는 요청이 없습니다.

LOCAL · LLM

로컬 LLM

생성 수정

로컬 모델 실행과 GPU·메모리 이해부터 서빙·RAG·도구 호출·업무형 앱 구현까지 차례로 살펴봅니다.

42개 문서 · 3일차 · 25 / 42

24차시 · Ollama와 vLLM 비교

지도 위치 : 3일차 · 정산 — ③추론 엔진 층의 두 어댑터 비교 | 이전: 23차시 vLLM 서버 성능 최적화 | 다음: 25차시 로컬 LLM API 애플리케이션 키워드 : 동일 모델의 응답속도, 처리량, 메모리 비교 및 활용 목적 분석

이 차시를 다 읽으면

  1. "Ollama는 간편한 로컬 실행, vLLM은 고성능 서빙"이라는 흔한 요약( 같은 층, 다른 목적 )을 유와 종차, 그리고 축 으로 다시 쓸 수 있다.
  2. "동일 모델"을 비교한다면서 형식이 다른 모델을 비교하는 함정 을 알고, 조건을 맞출 수 있다.
  3. 응답 속도 · 처리량 · 메모리 · 품질을 재는 비교 실험 을 설계하고 결과표를 채울 수 있다.
  4. 예상되는 차이를 "경향" 으로 말하고, 결론은 측정으로 내릴 수 있다.
  5. 활용 목적 매트릭스 로 상황마다 엔진을 고를 수 있다.
  6. "개발은 Ollama, 운영은 vLLM"이 20차시의 포트 덕분에 가능하다는 것을 설명할 수 있다.

0. 이 차시의 판별 축

#축왼쪽 (0)오른쪽 (1)이 축으로 갈리는 것큰 축 (README 5장)
1몇 명이 쓰는가1인 · 개발 · 실험다수 사용자 서비스엔진 선택⭐ ⑤ 하나 ↔ 여럿
2무엇을 재는가한 건의 시간 (TTFT · TPS)전체 처리량"어느 쪽이 빠른가"의 답이 뒤집히는 지점한 건의 시간 ↔ 전체 처리량 (파생 축, 부모 ⑤)
3같은 것을 비교하는가이름이 같다 (qwen3:8b ↔ Qwen/Qwen3-8B)형식 · 조건까지 같다비교의 공정성⑧ 구문 ↔ 의미 (이름이 같다고 실체가 같지 않다)

두 엔진을 비교할 때 흔히 듣는 결론은 한 줄입니다. "처음에는 Ollama로 시작하고, 여러 사람이 동시에 쓰는 순간 vLLM을 검토 한다." 1.1의 표처럼 짧게 요약되곤 합니다. 3일차 앞의 일곱 차시(17~23)가 그 문장의 근거였고, 이 차시는 그것을 내 장비의 숫자 로 확인하고 정산합니다.


1. 흔한 요약을 다시 쓰기

1.1 흔히 쓰는 요약 표

OllamavLLM
목적간편한 로컬 실행고성능 서빙
사용 감각ollama run 한 줄서버 프로세스를 띄워 운영
강점설치 · 모델 다운로드가 명령 한 줄동시 요청 처리량이 크게 높음
어울리는 자리개발 · 실험 · 1인 사용사내 다수 사용자에게 실제 서비스

1.2 유와 종차로

Ollama — [로컬 LLM 실행 도구(엔진 + 모델 관리 + 서버)]인데, [ 설치 · 모델 받기 · 실행을 명령 한 줄로 묶고, GGUF 양자화 모델을 Mac · CPU · GPU 어디서든 가볍게 돌리는 데 맞춰져 있다 ]는 점에서 vLLM과 구별된다.

vLLM — 18차시 1.1대로 [LLM 추론 엔진 겸 서빙 프레임워크]인데, [ PagedAttention과 연속 배칭으로 동시 처리량을 높이는 데 특화 ]되었다는 점에서 Ollama와 구별된다.

"같은 층, 다른 목적"을 이 말로 바꿀 수 있습니다. 유(類)가 같고 (③추론 엔진 층, 20차시의 어댑터) 종차가 다르다. 유가 같아서 갈아끼울 수 있고, 종차가 달라서 자리가 다릅니다.

1.3 축으로 다시 쓴 표

축 · 항목OllamavLLM근거
⑤ 하나 ↔ 여럿1인 · 소수다수 동시21차시
① 메모리를 잡는 방식부를 때 잡고, 기본 5분 뒤 내려놓음기동 시 미리 확보 , 놓지 않음19차시 3절
주 모델 형식GGUF (주로 4~8bit k-quant)Hugging Face 형식 BF16 + AWQ · GPTQ · FP812, 23차시
하드웨어Mac · CPU · GPU, CPU · GPU 혼합Linux + NVIDIA GPU가 기본12, 18차시
컨텍스트 설정num_ctx — 요청마다 바꿀 수 있음--max-model-len — 기동 시 고정18차시 4.2
동시 처리OLLAMA_NUM_PARALLEL (모델당 동시 요청 수)연속 배칭 + PagedAttention21차시
인증없음 (0.0.0.0이면 그대로 노출)--api-key 하나19차시 5.2
관측ollama ps, 응답 끝의 통계 (나노초)/metrics (Prometheus 형식)7, 22차시
API고유 /api/* + OpenAI 호환 /v1OpenAI 호환 /v1⭐ 20차시

2. ⚠️ 공정한 비교의 함정 — "동일 모델"이 사실 다르다

2.1 함정 표

ollama pull qwen3:8b와 vllm serve Qwen/Qwen3-8B는 이름이 같아 보이지만, 그대로 비교하면 엔진이 아니라 모델 형식을 비교 하게 됩니다.

함정무슨 일이 생기나맞추는 법
모델 형식Ollama 기본 태그는 대개 4bit GGUF (ollama show로 확인), vLLM은 그대로 띄우면 BF16 . 가중치 크기가 몇 배 차이 → Decode 속도도 품질도 다름 (15차시)정밀도를 맞춘다. (a) 높은 정밀도끼리: Ollama의 fp16 · q8_0 계열 태그(모델 페이지에서 존재 확인) ↔ vLLM BF16. (b) 4bit끼리: Ollama Q4_K_M ↔ vLLM AWQ 4bit. 형식이 완전히 같을 수는 없으니 무엇과 무엇을 비교했는지 적는다
컨텍스트Ollama num_ctx 기본값이 작을 수 있음(13차시) — 긴 입력이 잘려 더 빨라 보임둘 다 같은 값 (예: 8192)
동시 처리 설정Ollama의 동시 요청 수 설정이 작으면 나머지는 대기설정값을 확인 · 기록. 늘리면 메모리도 늘어남
생각 모드Qwen3의 <think>가 한쪽만 켜지면 출력 길이가 크게 다름둘 다 끔 (방법은 엔진마다, 모델 카드 확인)
출력 길이 · 워밍업한쪽이 일찍 멈추거나 첫 로딩이 섞임max_tokens 고정, temperature 0, 워밍업 버림
클라이언트Ollama는 /api/chat, vLLM은 /v1 → 측정 코드가 다름둘 다 /v1, 같은 스크립트 (22차시 3.2). 20차시의 포트 덕분
GPU 공유둘을 동시에 띄우면 서로 메모리를 뺏음하나씩 (18차시 5.1)
메모리 숫자nvidia-smi에서 vLLM은 항상 90% 근처 (미리 확보)아래 2.2

⭐ 엔진을 비교하려면 엔진 말고는 전부 같아야 합니다. 22차시 2.1의 "한 번에 하나만 바꾼다"를 엔진에 적용한 것입니다.

2.2 메모리는 무엇을 비교하나

보면 안 되는 값비교할 값
vLLMnvidia-smi memory.used (미리 확보한 예산)기동 로그의 가중치 메모리 , 그리고 실제 동시성에서 /metrics의 KV 사용률 × 풀 크기
Ollama—ollama ps의 크기, 요청 중 nvidia-smi (가중치 + 그 num_ctx · 동시 수의 KV)

메모리 비교의 질문은 "누가 더 많이 잡나"가 아니라 "같은 동시성 · 같은 컨텍스트를 감당하는 데 얼마가 필요한가" 입니다.


3. 비교 실험 설계와 결과표

3.1 무엇을 재나

비교조건지표축
A. 응답 속도동시성 1TTFT p50 · TPS p50한 건
B. 처리량동시성 1 · 4 · 8 · 16출력 처리량, TTFT p95전체
C. 메모리같은 컨텍스트 · 동시성2.2의 비교할 값①
D. 품질형식이 다르면 필수평가셋 분류 정확도 · 추출 정확도문장 2
E. 운영 편의—설치부터 첫 응답까지 단계 수, 설정 방식—

3.2 결과표 양식 — 직접 채웁니다

측정 일시:          GPU:            입력: 실제 문의 세트(___건), max_tokens ___, temperature 0
Ollama: 버전 ___ / 태그 ___ / 양자화 ___ / num_ctx ___ / 동시 처리 설정 ___
vLLM:   버전 ___ / 모델 ___ / 형식 ___ / 기동 명령(원문) ___
클라이언트: 같은 /v1 스크립트 (22차시 3.2)     생각 모드: 둘 다 끔 (방법: ___)
항목OllamavLLM비고
A. 동시 1 — TTFT p50
A. 동시 1 — TPS p50
B. 동시 4 — 처리량 / TTFT p95
B. 동시 8 — 처리량 / TTFT p95
B. 동시 16 — 처리량 / TTFT p95
C. 가중치 메모리
D. 평가셋 분류 정확도
E. 설치 → 첫 응답 단계 수

4. 예상되는 경향 — "경향"으로만 말하기

아래는 가설 입니다. 결론은 3.2의 표로 냅니다.

상황예상되는 경향왜뒤집힐 수 있는 조건
단일 요청 (동시 1)비슷하거나 , Ollama(4bit)가 더 가볍고 빠를 수 있음4bit는 Decode 때 읽을 가중치가 적음(15차시). vLLM의 강점인 배칭이 쓰이지 않음vLLM도 4bit(AWQ)면 차이가 줄어듦
동시 요청 처리량vLLM이 우위 인 경향연속 배칭 · PagedAttention (21차시)동시성이 아주 낮을 때, Ollama 동시 처리 설정
동시 요청의 TTFT 꼬리vLLM이 덜 늘어나는 경향스텝마다 새 요청을 받아 넣음무릎점을 넘으면 둘 다 늘어남
nvidia-smi 메모리vLLM이 늘 더 많아 보임미리 확보 (19차시 3절)비교 자체가 무의미 (2.2)
운영 편의Ollama가 쉬움명령 한 줄, 모델 관리 내장—

⚠️ 0절 축 2를 섞으면 "Ollama가 더 빠르다"와 "vLLM이 더 빠르다"가 둘 다 참 일 수 있습니다. 앞 문장은 한 건의 시간 , 뒤 문장은 전체 처리량 의 이야기입니다. README 5.1에서 축 ⑥에 붙여 둔 경고, "비동기는 빠른 게 아니다. 처리량이 늘어나는 것이다" 와 같은 구조입니다(21차시 3.3). 비교 결과를 말할 때는 어느 축의 숫자인지 를 붙입니다.


5. 활용 목적 매트릭스

                    하드웨어 →   Mac · CPU · 작은 GPU          NVIDIA GPU 서버 (Linux)
  사용자 수 ↓                  ┌────────────────────────────┬────────────────────────────┐
  1인 · 소수 (개발 · 실험)      │  Ollama / llama.cpp         │  Ollama (편의) · vLLM 가능   │
                              ├────────────────────────────┼────────────────────────────┤
  다수 (사내 서비스)            │  하드웨어부터 다시 (16차시)   │  ⭐ vLLM                    │
                              └────────────────────────────┴────────────────────────────┘
상황고르는 것이유
개발 · 프롬프트 실험, 혼자Ollama모델 교체 · 설정이 쉬움
Mac (Apple Silicon)Ollama, llama.cppvLLM의 기본 대상이 아님
VRAM이 모자라 CPU · GPU 혼합Ollama, llama.cpp (12차시)GGUF 부분 오프로드
노트북 데모, 소수가 잠깐Ollama단순함이 이김
상담원 10명이 쓰는 문의봇vLLM동시 처리량, /metrics, API 키
밤새 문의 수천 건 일괄 요약vLLM LLM 클래스 (18차시 4.3)오프라인 배칭
GPU 여러 장에 큰 모델vLLM텐서 병렬 (23차시 1.2)

⚠️ 반례 — "vLLM이 더 고급이니 처음부터 vLLM." ❌ README 5.1의 경고, "어느 쪽도 발전된 형태가 아니다. 규모와 실패 비용이 답을 정한다" (17차시 3.2의 모놀리식 ↔ MSA에서 본 것)가 엔진 선택에도 그대로입니다.


6. 개발은 Ollama, 운영은 vLLM — 20차시의 포트 덕분에

환경LLM_BASE_URLLLM_MODEL누가 쓰나
개발 노트북 .envhttp://localhost:11434/v1qwen3:8b앱 개발자
운영 서버 .envhttp://127.0.0.1:8000/v1munuibot상담원 10명

앱 코드는 LLMPort 하나만 압니다(20차시 1.5). 안쪽(업무 로직)이 약속(포트)에만 의존하고, 엔진은 바깥에서 그 약속을 지키는 어댑터이기 때문입니다(20차시 1.1). 그래서 엔진이 바뀌어도 .env만 바뀝니다. README 7장 문장 3이 실제로 쓰이는 모습이고, 0절 아래의 한 줄 결론("Ollama로 시작하고 여러 사람이 쓰는 순간 vLLM")이 코드 재작성 없이 가능한 이유입니다.

⚠️ 단, 세 가지는 넘어갈 때 다시 확인합니다.

확인할 것왜
평가셋을 운영 엔진으로 다시 돌린다형식(4bit GGUF ↔ BF16 · AWQ)이 달라 답이 다를 수 있음. 20차시 4.2의 "치환이 깨지는 지점"
엔진별 기능 차이도구 호출 · 구조화 출력은 엔진 · 버전마다 설정이 다름 (29, 30차시)
컨텍스트 설정개발에서 num_ctx 기본값으로 잘리던 것이 운영에서는 에러로 바뀔 수 있음 (20차시 2.3)

7. 3일차 정리 → 4일차 예고

차시한 줄축
17서빙 = 여럿에게 계속. 모델은 앱 밖의 모델 서버로⑤
18vLLM은 전용 가상환경에. 오프라인 추론은 아직 서빙이 아님전역 ↔ 격리
19vllm serve, 기동 시 미리 확보, 로그 세 줄, 127.0.0.1 + 키①
20OpenAI 호환 API = 포트, 엔진 = 어댑터. base_url 하나로 전환⭐ ②
21PagedAttention · 연속 배칭 · 프리픽스 캐시 = 처리량을 위한 장치⑤ ⑦
22동시성별 측정, 무릎점, SLO 먼저한 건 ↔ 처리량
23손잡이 일곱 개, 하나씩 바꾸는 루프, 결정 기록트레이드오프
24같은 층, 다른 목적. 공정하게 비교하고 목적으로 고른다⑤

README 1.1 표의 3일차 산출물 "vLLM 서버, 성능 측정표, Ollama와 비교" 가 이것으로 갖춰졌습니다.

앞으로 다시 만납니다 — 4일차는 다섯 층의 맨 위 ⑤ 애플리케이션 층 입니다. 25차시는 20차시의 LLMPort 위에 문의봇 API를 세우고, 26차시는 stream: true(20차시 2.3)를, 27차시는 무상태 API 위의 대화 (21차시 4.2)를, 29 · 30차시는 엔진마다 지원이 갈리던 구조화 출력과 도구 호출(20차시 4.2)을 다룹니다.


8. 실습 — 맡기고 검수하기

지시

같은 GPU에서 Ollama와 vLLM을 공정하게 비교해줘.
맥락: ollama show 출력, Ollama 모델 페이지(태그 목록), Hugging Face 모델 카드, vLLM 문서를 근거로.
제약:
- 정밀도를 맞출 것: 먼저 ollama show qwen3:8b로 양자화를 확인하고, 비교 쌍을 두 개 제안해서 내 승인을 받을 것
  (예: Ollama 4bit ↔ vLLM AWQ 4bit / Ollama 고정밀 태그 ↔ vLLM BF16). 없는 태그·저장소 이름을 지어내지 마.
- 컨텍스트 8192, max_tokens 200, temperature 0, 생각 모드 끔(엔진별 방법을 문서에서 확인해 적을 것).
- 두 엔진을 동시에 띄우지 말 것. 전환 전후 nvidia-smi로 확인.
- 클라이언트는 22차시의 /v1 비동기 스크립트 하나로, base_url과 model만 바꿔서.
할 일: 24차시 3.2 결과표를 채우고, 평가셋(첨부 50건) 분류 정확도도 두 엔진으로.
보고 형식: 3.2의 조건 기록 + 결과표 + 각 칸의 출력 원문 위치.
"어느 쪽이 빠르다"는 결론은 쓰지 말고, 축(한 건 / 처리량)별로 숫자만 나란히 보여줘.
추측하지 말고 실행 출력 원문을 붙여.

받을 증거

  • ollama show 출력 원문 (양자화 확인), vLLM 기동 명령 · 로그 원문
  • 두 엔진의 측정 출력 원문, 평가셋 채점 결과
  • 전환 전후 nvidia-smi

내가 직접 볼 것

볼 것이걸로 아는 것 / 왜 내가 보는가
비교 쌍의 형식 · 비트 수 가 맞는가엔진 비교인지 모델 형식 비교인지 (2.1)
동시 1의 TTFT · TPS한 건 축의 결과 (4절 첫 줄)
동시 8 · 16의 처리량처리량 축의 결과. 두 축의 결론이 다를 수 있음
평가셋 정확도 차이속도 차이가 품질을 내주고 얻은 것인가
문의봇에 어느 엔진을, 왜5절 매트릭스 + 이 표로 내가 결정하고 23차시 결정 기록 양식으로 남김

부록 A. 스스로 확인하기

#질문답이 있는 곳
1Ollama와 vLLM은 유가 같은가, 종차가 같은가?1.2
2두 엔진을 축으로 가른 표에서 메모리를 잡는 방식은 어떻게 다른가?1.3
3qwen3:8b와 Qwen/Qwen3-8B를 그대로 비교하면 무엇을 비교하게 되는가?2.1
4메모리 비교에서 nvidia-smi를 그대로 쓰면 안 되는 이유는?2.2
5비교 실험의 다섯 항목은?3.1
6"Ollama가 더 빠르다"와 "vLLM이 더 빠르다"가 둘 다 참일 수 있는 이유는?4
7Mac에서 혼자 개발할 때와 상담원 10명 서비스에서 각각 무엇을 고르는가?5
8개발 Ollama → 운영 vLLM으로 넘어갈 때 다시 확인할 세 가지는?6
93일차 여덟 차시를 축 하나씩으로 요약하면?7

부록 B. 자주 하는 실수

실수바로잡기
ollama pull qwen3:8b ↔ vllm serve Qwen/Qwen3-8B 그대로 비교❌ 4bit GGUF ↔ BF16. 형식부터 맞춤
nvidia-smi로 "vLLM이 메모리를 더 먹는다"❌ 미리 확보한 예산. 비교할 값은 2.2
동시 1만 재고 "vLLM이 별로"❌ vLLM의 강점은 동시 요청 . 축을 붙여 말함
둘을 같은 GPU에 동시에 띄워 비교❌ 서로 메모리를 뺏음. 하나씩
"vLLM이 상위 호환이니 늘 vLLM"❌ Mac · CPU 혼합 · 1인 개발은 Ollama가 맞음
개발에서 통과했으니 운영 엔진에서도 같은 결과⚠️ 형식이 다르면 답이 다름. 평가셋 재확인

부록 C. NotebookLM 복습 프롬프트

이 24차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"동일 모델 비교의 함정", "nvidia-smi 메모리 비교가 무의미한 이유", "한 건의 시간과 처리량 축을 섞으면 생기는 모순", "개발은 Ollama 운영은 vLLM이 가능한 이유"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.