로컬 LLM

지도 위치 : 2일차 · ③추론 엔진의 설정 손잡이 | 이전: 12차시 GGUF와 경량 LLM | 다음: 14차시 LLM 추론 성능 측정 키워드 : Context Length, Batch Size, KV Cache, Sampling Parameter, GPU Memory 설정

이 차시를 다 읽으면

1. 추론 파라미터를 품질 파라미터 ↔ 자원 파라미터 두 무리로 가를 수 있다.
2. 각 자원 파라미터가 9차시 VRAM 예산식의 어느 항 을 건드리는지 표로 말할 수 있다.
3. 같은 손잡이가 Ollama · llama.cpp · vLLM · OpenAI API에서 어떤 이름으로 불리는지 대응표에서 찾을 수 있다.
4. 문의봇의 업무별(분류 · 추출 · 요약 · 초안) 시작값 을 정하고, 그것이 "정답"이 아니라 "출발점"인 이유를 말할 수 있다.
5. 파라미터를 바꿀 때 한 번에 하나만 바꿔야 하는 이유를 말할 수 있다.

---

0. 이 차시의 판별 축

앞에서 이어집니다 — README 6장의 번역어 함정에서 "파라미터"는 세 가지였습니다. 이 차시는 그중 ② 추론 파라미터 만 다룹니다. 6차시에서 temperature · top_p를 품질의 눈 으로 만졌다면, 이번에는 같은 목록에 섞여 있던 자원 손잡이들을 분리 해 9차시 예산식에 연결합니다.

---

1. ⭐ 두 무리로 가르기

엔진 문서의 파라미터 목록은 한 줄로 쭉 나열되어 있어서 다 같은 종류처럼 보입니다. 0절 축 1로 가르면 이렇게 나뉩니다.

품질 파라미터 — [추론 파라미터]인데, [ 다음 토큰을 고르는 방식과 생성의 끝을 정해 출력 내용을 바꾼다 ]는 점에서 자원 파라미터와 구별된다.

자원 파라미터 — [추론 파라미터]인데, [ 메모리를 얼마나 잡고 몇 개를 함께 계산할지 정해 VRAM과 속도를 바꾼다 ]는 점에서 품질 파라미터와 구별된다.

⚠️ 경계에 걸친 것이 하나 있습니다. num_predict 는 품질(잘림)이지만, 길게 생성할수록 KV 캐시가 자라고 시간이 늘어나 자원에도 영향 을 줍니다. 그래서 "넉넉히 4096"이 아니라 업무에 맞게 짧게 잡습니다(4절).

1.1 품질 파라미터 — 6차시 회수

6차시에서 다룬 내용이라 한 줄씩만 정리합니다.

⚠️ 반례 — 품질 파라미터는 VRAM을 거의 바꾸지 않습니다. "temperature를 낮췄더니 메모리가 줄었다"는 일어나지 않습니다. 메모리 문제가 생기면 2절의 손잡이를 봅니다.

---

2. ⭐ 자원 파라미터 ↔ VRAM 예산식

9차시 3절의 예산식입니다.

필요한 VRAM ≈ 가중치  +  KV 캐시(토큰당 크기 × 컨텍스트 × 동시 요청)  +  나머지(활성값 · CUDA 컨텍스트 …)

⭐ 이 표 하나로 "메모리가 부족하다"는 증상을 어느 손잡이로 풀지 고를 수 있습니다. 9차시 3.1의 문의봇 계산(FP16, 8K, 약 5명)을 예로 들면 다음 조합이 가능합니다.

2.1 ⚠️ "배치"라는 단어의 두 뜻

README 6장의 번역어 함정입니다. 이 차시에서는 같은 단어가 두 가지로 쓰입니다.

vLLM의 --max-num-batched-tokens는 한 스텝에 처리할 토큰 총량 이라 두 뜻에 걸쳐 있습니다. 21차시 연속 배칭에서 정확히 봅니다.

---

3. 엔진별 이름 대응표

같은 손잡이가 엔진마다 다른 이름입니다. ⚠️ 이름과 기본값은 버전에 따라 바뀌니 공식 문서로 확인합니다.

3.1 품질 파라미터

3.2 자원 파라미터

앞으로 다시 만납니다 — vLLM 열은 19차시(서버 구축)에서 처음 켜고, 23차시(성능 최적화)에서 이 표의 손잡이를 하나씩 돌립니다.

3.3 Ollama 쪽에서 조심할 것

systemd — [리눅스의 서비스 관리자]인데, [ 프로그램을 백그라운드 서비스로 상시 실행하고, 꺼지면 다시 띄우고, 부팅 때 자동으로 켠다 ]는 점에서 사람이 터미널에서 직접 실행하는 방식과 구별된다. 리눅스에 Ollama를 설치하면 대개 ollama라는 systemd 서비스로 등록됩니다. 서비스는 사람이 연 터미널(셸)과 따로 돌기 때문에, 셸에서 정한 환경변수를 보지 못합니다.

# systemctl edit ollama 로 여는 파일
[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

🔍 읽는 포인트 : 세 줄 모두 서버 전체 에 걸리는 자원 파라미터입니다(0절 축 3). 품질 파라미터는 여기에 없습니다.

---

4. 업무별 시작값 — 문의봇

⚠️ 아래는 출발점 입니다. 정답이 아니라 "여기서 시작해 평가셋으로 조정할 값"입니다. 먼저 모델 카드의 권장 샘플링 값 을 확인하세요. Qwen3처럼 생각 모드 여부에 따라 권장값을 따로 적어 둔 모델도 있고, 생각 모드에서 온도 0(greedy)을 권하지 않는 경우도 있습니다(모델 카드 확인).

💡 컨텍스트 길이를 정하는 순서: ① 평가셋 메일의 토큰 수 분포를 잰다 → ② 상위 몇 %까지 받을지 정한다 → ③ 시스템 프롬프트 + 그 길이 + num_predict + 여유 → ④ 9차시 예산식에 넣어 동시 요청 수가 나오는지 본다. "넉넉히 32K"는 예산식을 무시한 선택 입니다.

---

5. ⭐ 한 번에 하나만 바꾸기

AI에게 맡길 때도 마찬가지입니다(README 9장). AI가 "최적화했습니다"라고 말해도, 판정은 측정 숫자와 평가셋 이 합니다. 한 번에 하나만 바꾸게 해야 그 숫자가 어느 손잡이의 효과인지 읽을 수 있습니다. 변경 기록은 14차시 측정표에 조건 한 줄 로 남깁니다.

5.1 비유 (기억 보조)

품질 파라미터는 요리사의 간 맞추기 , 자원 파라미터는 주방의 화구 수와 냉장고 크기 입니다. 간을 바꿔도 주방이 넓어지지 않고, 화구를 늘려도 음식 맛이 좋아지지 않습니다. 둘을 동시에 바꾸면 맛이 변한 이유를 모릅니다.

---

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

지시

목표: 문의봇용 Ollama 모델의 자원 파라미터를 하나씩 바꾸며 메모리 변화를 기록하고, 업무별 품질 파라미터 시작값을 Modelfile로 고정한다.
맥락: ollama.com의 Ollama 문서(Modelfile 파라미터, FAQ의 환경변수)와 Qwen3-8B 모델 카드의 권장 샘플링 값을 먼저 인용해.
      설치된 Ollama 버전과 기본 num_ctx 값을 확인해서 보고해.
작업:
 1. 기준: qwen3:8b, num_ctx 4096, 병렬 1, KV f16. 
 2. 한 번에 하나만 바꾸기: (a) num_ctx 8192 (b) num_ctx 16384 (c) OLLAMA_KV_CACHE_TYPE=q8_0 + FLASH_ATTENTION=1 (d) OLLAMA_NUM_PARALLEL=4
    환경변수는 systemctl edit ollama로 설정하고 재시작(실행 전 변경 내용을 나에게 보여줘).
 3. 각 단계에서 같은 프롬프트로 한 번 요청 후 ollama ps, nvidia-smi 기록.
 4. 분류용/초안용 Modelfile 두 개를 만들어 ollama create (temperature, num_predict, num_ctx 포함).
보고 형식:
| 단계 | 바꾼 것 하나 | ollama ps SIZE | PROCESSOR | nvidia-smi used | 9차시 계산과 비교 |
추측하지 말고 실행 명령과 출력 원문을 붙여.

받을 증거

• Ollama 버전, 기본 num_ctx 확인 출력
• 단계별 ollama ps, nvidia-smi 출력 원문
• systemctl edit 내용, 두 Modelfile 원문, ollama show --modelfile 출력

내가 직접 볼 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 13차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"품질 파라미터 vs 자원 파라미터", "각 자원 파라미터가 VRAM 예산식의 어느 항인가", "Ollama와 vLLM 이름 대응", "한 번에 하나만 바꾸기"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.