페이지 목차
이 페이지에서 검색
로컬 LLM
이 페이지에 묻기
로컬 LLM · 현재 차시와 목차 본문에서만 찾아 답합니다. 답을 지어내지 않고 해당하는 대목을 그대로 보여 주며, 여기에 없으면 없다고 알려 드립니다.
생성형 AI가 아니라 이 페이지 본문을 찾아 그대로 보여 주는 방식입니다. 외부로 나가는 요청이 없습니다.
LOCAL · LLM
로컬 LLM
생성 수정
로컬 모델 실행과 GPU·메모리 이해부터 서빙·RAG·도구 호출·업무형 앱 구현까지 차례로 살펴봅니다.
42개 문서 · 3일차 · 25 / 42
24차시 · Ollama와 vLLM 비교
지도 위치 : 3일차 · 정산 — ③추론 엔진 층의 두 어댑터 비교 | 이전: 23차시 vLLM 서버 성능 최적화 | 다음: 25차시 로컬 LLM API 애플리케이션 키워드 : 동일 모델의 응답속도, 처리량, 메모리 비교 및 활용 목적 분석
이 차시를 다 읽으면
- "Ollama는 간편한 로컬 실행, vLLM은 고성능 서빙"이라는 흔한 요약( 같은 층, 다른 목적 )을 유와 종차, 그리고 축 으로 다시 쓸 수 있다.
- "동일 모델"을 비교한다면서 형식이 다른 모델을 비교하는 함정 을 알고, 조건을 맞출 수 있다.
- 응답 속도 · 처리량 · 메모리 · 품질을 재는 비교 실험 을 설계하고 결과표를 채울 수 있다.
- 예상되는 차이를 "경향" 으로 말하고, 결론은 측정으로 내릴 수 있다.
- 활용 목적 매트릭스 로 상황마다 엔진을 고를 수 있다.
- "개발은 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 흔히 쓰는 요약 표
| Ollama | vLLM | |
|---|---|---|
| 목적 | 간편한 로컬 실행 | 고성능 서빙 |
| 사용 감각 | ollama run 한 줄 | 서버 프로세스를 띄워 운영 |
| 강점 | 설치 · 모델 다운로드가 명령 한 줄 | 동시 요청 처리량이 크게 높음 |
| 어울리는 자리 | 개발 · 실험 · 1인 사용 | 사내 다수 사용자에게 실제 서비스 |
1.2 유와 종차로
Ollama — [로컬 LLM 실행 도구(엔진 + 모델 관리 + 서버)]인데, [ 설치 · 모델 받기 · 실행을 명령 한 줄로 묶고, GGUF 양자화 모델을 Mac · CPU · GPU 어디서든 가볍게 돌리는 데 맞춰져 있다 ]는 점에서 vLLM과 구별된다.
vLLM — 18차시 1.1대로 [LLM 추론 엔진 겸 서빙 프레임워크]인데, [ PagedAttention과 연속 배칭으로 동시 처리량을 높이는 데 특화 ]되었다는 점에서 Ollama와 구별된다.
"같은 층, 다른 목적"을 이 말로 바꿀 수 있습니다. 유(類)가 같고 (③추론 엔진 층, 20차시의 어댑터) 종차가 다르다. 유가 같아서 갈아끼울 수 있고, 종차가 달라서 자리가 다릅니다.
1.3 축으로 다시 쓴 표
| 축 · 항목 | Ollama | vLLM | 근거 |
|---|---|---|---|
| ⑤ 하나 ↔ 여럿 | 1인 · 소수 | 다수 동시 | 21차시 |
| ① 메모리를 잡는 방식 | 부를 때 잡고, 기본 5분 뒤 내려놓음 | 기동 시 미리 확보 , 놓지 않음 | 19차시 3절 |
| 주 모델 형식 | GGUF (주로 4~8bit k-quant) | Hugging Face 형식 BF16 + AWQ · GPTQ · FP8 | 12, 23차시 |
| 하드웨어 | Mac · CPU · GPU, CPU · GPU 혼합 | Linux + NVIDIA GPU가 기본 | 12, 18차시 |
| 컨텍스트 설정 | num_ctx — 요청마다 바꿀 수 있음 | --max-model-len — 기동 시 고정 | 18차시 4.2 |
| 동시 처리 | OLLAMA_NUM_PARALLEL (모델당 동시 요청 수) | 연속 배칭 + PagedAttention | 21차시 |
| 인증 | 없음 (0.0.0.0이면 그대로 노출) | --api-key 하나 | 19차시 5.2 |
| 관측 | ollama ps, 응답 끝의 통계 (나노초) | /metrics (Prometheus 형식) | 7, 22차시 |
| API | 고유 /api/* + OpenAI 호환 /v1 | OpenAI 호환 /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 메모리는 무엇을 비교하나
| 보면 안 되는 값 | 비교할 값 | |
|---|---|---|
| vLLM | nvidia-smi memory.used (미리 확보한 예산) | 기동 로그의 가중치 메모리 , 그리고 실제 동시성에서 /metrics의 KV 사용률 × 풀 크기 |
| Ollama | — | ollama ps의 크기, 요청 중 nvidia-smi (가중치 + 그 num_ctx · 동시 수의 KV) |
메모리 비교의 질문은 "누가 더 많이 잡나"가 아니라 "같은 동시성 · 같은 컨텍스트를 감당하는 데 얼마가 필요한가" 입니다.
3. 비교 실험 설계와 결과표
3.1 무엇을 재나
| 비교 | 조건 | 지표 | 축 |
|---|---|---|---|
| A. 응답 속도 | 동시성 1 | TTFT 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) 생각 모드: 둘 다 끔 (방법: ___)
| 항목 | Ollama | vLLM | 비고 |
|---|---|---|---|
| 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.cpp | vLLM의 기본 대상이 아님 |
| 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_URL | LLM_MODEL | 누가 쓰나 |
|---|---|---|---|
개발 노트북 .env | http://localhost:11434/v1 | qwen3:8b | 앱 개발자 |
운영 서버 .env | http://127.0.0.1:8000/v1 | munuibot | 상담원 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 | 서빙 = 여럿에게 계속. 모델은 앱 밖의 모델 서버로 | ⑤ |
| 18 | vLLM은 전용 가상환경에. 오프라인 추론은 아직 서빙이 아님 | 전역 ↔ 격리 |
| 19 | vllm serve, 기동 시 미리 확보, 로그 세 줄, 127.0.0.1 + 키 | ① |
| 20 | OpenAI 호환 API = 포트, 엔진 = 어댑터. base_url 하나로 전환 | ⭐ ② |
| 21 | PagedAttention · 연속 배칭 · 프리픽스 캐시 = 처리량을 위한 장치 | ⑤ ⑦ |
| 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. 스스로 확인하기
| # | 질문 | 답이 있는 곳 |
|---|---|---|
| 1 | Ollama와 vLLM은 유가 같은가, 종차가 같은가? | 1.2 |
| 2 | 두 엔진을 축으로 가른 표에서 메모리를 잡는 방식은 어떻게 다른가? | 1.3 |
| 3 | qwen3:8b와 Qwen/Qwen3-8B를 그대로 비교하면 무엇을 비교하게 되는가? | 2.1 |
| 4 | 메모리 비교에서 nvidia-smi를 그대로 쓰면 안 되는 이유는? | 2.2 |
| 5 | 비교 실험의 다섯 항목은? | 3.1 |
| 6 | "Ollama가 더 빠르다"와 "vLLM이 더 빠르다"가 둘 다 참일 수 있는 이유는? | 4 |
| 7 | Mac에서 혼자 개발할 때와 상담원 10명 서비스에서 각각 무엇을 고르는가? | 5 |
| 8 | 개발 Ollama → 운영 vLLM으로 넘어갈 때 다시 확인할 세 가지는? | 6 |
| 9 | 3일차 여덟 차시를 축 하나씩으로 요약하면? | 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이 가능한 이유"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.
LangTailor