로컬 LLM

지도 위치 : 5일차 · 프로젝트 2단계 · ①하드웨어 + ②모델 파일 층 | 이전: 33차시 프로젝트 요구사항 분석 | 다음: 35차시 LLM Serving 구축 키워드 : 모델 비교, GPU 자원 분석, 양자화 방식 선정 및 적용

이 차시를 다 읽으면

1. 2일차(9~16차시)에서 배운 것을 프로젝트 절차 여섯 단계 로 다시 꿸 수 있다.
2. 33차시 요구사항(동시 사용자 · 문의 길이)에서 VRAM 예산표 를 계산할 수 있다.
3. 후보 모델 2~3개 × 양자화 2개의 비교 매트릭스 를 설계하고, 품질 하한부터 거르는 순서를 지킬 수 있다.
4. 운영할 서빙 엔진에 맞는 양자화 형식 을 고를 수 있다(vLLM이면 AWQ · GPTQ · FP8, Ollama면 GGUF).
5. 선정 결과를 결정 기록 (맥락 · 결정 · 검토한 대안 · 결과)으로 남길 수 있다.

---

0. 이 차시의 판별 축

앞에서 이어집니다 — 2일차는 두 문장에서 출발했습니다. "숫자를 외우지 말고 계산식 을 외우세요"(9차시, README 7장 문장 1), 그리고 "양자화는 메모리 · 속도를 얻고 품질을 조금 내주는 거래 다"(10차시). 2일차는 그 두 문장을 계산과 측정 으로 펼쳤고, README 7장의 문장 2 — "먼저 내 업무에 충분한 품질을 평가셋으로 정하고, 나머지를 최적화한다" — 로 닫았습니다. 34차시는 그 문장을 내 프로젝트에 한 번 실행 하는 시간입니다.

---

1. 2일차를 프로젝트 절차로 회수하기

1.1 여섯 단계 ⭐

⚠️ ④와 ⑤의 순서가 이 차시의 핵심입니다. 빠르고 가벼운 모델이 분류를 틀리면, 그 속도는 틀린 답을 빨리 내는 속도 입니다.

1.2 왜 34차시가 35차시보다 먼저인가

35차시의 vllm serve 명령에 들어갈 옵션 — 모델 이름, --max-model-len, --quantization, --kv-cache-dtype — 은 전부 34차시의 결정에서 나옵니다. 35차시에서 옵션마다 "왜 이 값인가?"를 물으면, 답은 이 차시의 예산표와 결정 기록에 있어야 합니다.

---

2. GPU 자원 분석 — VRAM 예산표

2.1 식 — README 7장 문장 1

필요한 VRAM ≈ 모델 가중치 + KV 캐시(요청당 토큰 수 × 동시 요청 수) + 오버헤드(1~2GB 이상)

앞에서 배운 9차시의 식입니다. 33차시 요구사항에서 두 숫자 를 가져옵니다.

2.2 KV 캐시 — 토큰 하나에 얼마인가

KV 캐시 / 토큰 = 2(K, V) × 층 수 × KV 헤드 수 × 헤드 차원 × 바이트
Qwen3-8B, FP16: 2 × 36 × 8 × 128 × 2 = 147,456 B ≈ 144KB / 토큰

🔍 읽는 포인트 : 층 수 · KV 헤드 수 · 헤드 차원은 모델의 config.json에서 num_hidden_layers, num_key_value_heads, head_dim을 찾아 직접 확인 합니다(9차시). 위 값은 Qwen3-8B 기준이고, 다른 후보는 다시 계산합니다.

2.3 ⭐ 예산표 — 문의봇, RTX 4090 24GB

요청당 토큰을 4K(평소 최대) 와 8K(긴 메일) 두 경우로 잡아 봅니다. 아래는 전부 계산값(이론) 입니다.

⚠️ 4bit 가중치의 "+ α" — 8B × 0.5바이트 = 4GB는 이론값입니다. 실제 양자화 파일은 일부 층(임베딩 등)을 양자화하지 않는 경우가 많아 더 큽니다. 파일 크기를 직접 확인하세요.

⚠️ vLLM의 --gpu-memory-utilization 0.9 는 24GB의 90%(≈ 21.6GB)만 씁니다(19차시). 그래서 A안은 "경계"가 아니라 사실상 부족 입니다.

💡 이 표를 읽는 법은 하나입니다. 예산이 모자라면 어느 칸을 줄일지 고르는 것 입니다.

앞으로 다시 만납니다 — vLLM은 KV 캐시를 PagedAttention으로 필요한 만큼만 나눠 씁니다(21차시). 그래서 예산이 빠듯하면 기동이 실패하기보다 기동 로그의 "Maximum concurrency" 숫자가 줄어드는 형태로 드러납니다. 35차시에서 그 숫자를 이 예산표와 대조합니다.

---

3. 모델 비교 — 후보 × 양자화 매트릭스

3.1 후보 고르기

⚠️ 앞에서 배운 대로(1차시 실습) AI가 추천하는 모델 이름은 Hugging Face에서 실제로 있는지 열어 봅니다. 라이선스는 기술 판단이 아니라 사업 판단입니다.

💡 B를 넣는 이유: 2일차에서 본 경향 — 큰 모델의 4bit가 작은 모델의 FP16보다 나은 경우가 많다 — 을 내 평가셋으로 확인 하기 위해서입니다. "경우가 많다"는 "내 업무에서도 그렇다"가 아닙니다.

3.2 ⭐ 품질 하한 — 문턱부터

품질 하한 (Quality Floor) — [선정 기준]인데, [ 넘지 못하면 다른 장점이 아무리 커도 탈락시키는 문턱 ]이라는 점에서 높을수록 좋은 순위 기준(속도 · 메모리)과 구별된다.

33차시 요구사항표에서 가져옵니다.

⚠️ 앞에서 배운 대로 한국어 · 숫자(주문번호) · 형식 준수 는 양자화에 더 민감할 수 있습니다. 그리고 4bit 미만(Q3 · Q2)은 품질이 급격히 떨어집니다 (10 · 12차시). 그래서 하한을 분류 정확도 한 줄로만 잡지 말고 주문번호 줄을 꼭 넣습니다.

3.3 비교 매트릭스 — 직접 채우는 표

이론값 칸만 채워 두었습니다. 나머지는 실측으로 채웁니다.

채우는 규칙 (14차시 측정 규칙 그대로)

---

4. 양자화 방식 선정 — 운영 엔진에 맞는 형식

4.1 엔진이 형식을 고른다

4.2 반례 — 이렇게 고르면 안 됩니다

⭐ 0절 축 3을 다시 봅니다. Decode는 토큰마다 가중치 전체를 메모리에서 읽으므로(2 · 15차시), 가중치가 가벼워지면 이론상 상한이 올라갑니다. RTX 4090(≈ 1TB/s)에서 16GB 모델은 이론 상한 약 60 tok/s, 5GB 모델은 약 200 tok/s입니다. 실제는 이보다 낮습니다. 이 이론값은 "얼마나 빨라질 수 있는가"의 천장일 뿐, 측정을 대신하지 않습니다.

---

5. 결정 기록 — 고른 이유를 남기기

5.1 정의

결정 기록 (Decision Record) — [프로젝트 문서]인데, [ 결정 그 자체보다 그때의 맥락과 버린 대안을 남긴다 ]는 점에서 결과값만 적힌 설정 파일과 구별된다.

설정 파일에는 --quantization awq만 남습니다. 3주 뒤에 누가 "왜 FP16이 아니냐"고 물으면, 설정 파일은 답하지 못합니다. 40차시 발표에서 받을 질문도 "무엇을 썼나"보다 "왜 그것을 골랐고, 무엇을 버렸나" 입니다. 그 답이 이 기록에 있습니다.

형식은 앞에서 배운 결정 기록(16차시 4절) 의 네 칸 그대로입니다. 맥락 (그때의 조건 · 제약), 결정 (무엇을 골랐나), 검토한 대안 (무엇을 왜 버렸나), 결과 (얻은 것과 치른 대가). 여기에 이 차시는 "다시 볼 조건" 한 칸을 더합니다.

5.2 양식

# DR-001 문의봇 모델 · 양자화 선정
- 날짜 / 작성자:
- 관련 요구사항: FR-01, FR-02, NFR-01

## 맥락
RTX 4090 24GB 1대. 상담원 10명 동시, 요청당 최대 4K 토큰(평가셋 최장 메일 기준 ___ 토큰).
예산표(2.3절)상 FP16은 KV 캐시 여유가 없음.

## 결정
모델: ______   양자화: ______   엔진: vLLM   max-model-len: ______

## 검토한 대안
| 대안 | 탈락 이유 (숫자로) |
| A · FP16 | 예산 초과 (계산 ___GB > 21.6GB) |
| B · 4bit | 분류 정확도 ___% (하한 90% 미달) 또는 TPS ___ |

## 결과 (얻은 것 / 치른 대가)
얻은 것: 동시 10명 KV 여유, 평가셋 ___%
치른 대가: FP16 대비 분류 정확도 ___%p 차이

## 다시 볼 조건
평가셋이 바뀌면 / GPU가 바뀌면 / 39차시 부하 테스트에서 NFR-01 미달이면

🔍 읽는 포인트 : 검토한 대안의 탈락 이유가 숫자 여야 합니다. "품질이 아쉬워서"는 기록이 아니라 인상입니다. 다시 볼 조건은 이 결정이 언제 무효가 되는지 를 미리 적어 두는 칸입니다.

💡 이 파일을 저장소에 두면, 다음에 AI에게 35차시 작업을 맡길 때 맥락으로 그대로 줄 수 있습니다. AI에게 일을 맡길 때는 필요한 배경 정보를 골라 함께 넣어 주는 것 이 결과의 질을 정합니다. 그 배경을 대화창에 매번 다시 쓰지 않고 파일로 남겨 두는 것 이 이 결정 기록의 또 하나의 쓰임입니다.

---

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

지시

33차시 평가셋(eval_v1.jsonl)으로 모델 후보 비교 매트릭스를 채워줘.

목표: 아래 후보 × 양자화 조합마다 [품질 하한 통과 여부 → 통과한 것만 성능] 순서로 측정.
맥락: RTX 4090 24GB, 운영 엔진 vLLM. 후보 저장소 주소와 모델 카드는 아래에 붙임.
     (각 후보의 config.json 값으로 KV 캐시/토큰도 계산해줘)
제약:
- 모든 조합을 같은 엔진, 같은 프롬프트 파일, temperature 0, max_tokens 고정으로.
- 품질 하한(분류 정확도 90%, 주문번호 정확도 95%, 지어낸 주문번호 0건, 스키마 통과 100%)에서
  탈락한 조합은 성능 측정을 하지 말고 '탈락'이라고만 써.
- 성능은 워밍업 1회 버리고 5회 반복, 중앙값.
- 모델 다운로드나 드라이버 변경이 필요하면 실행 전에 나에게 먼저 물어봐.
- 추측하지 말고 실행 명령과 출력 원문을 붙여.
보고 형식:
[후보·양자화 | 가중치 파일 크기 | VRAM(nvidia-smi) | 분류 정확도 | 주문번호 정확도 | 지어낸 값 | 스키마 통과 | 하한 통과 | TTFT 중앙값 | TPS 중앙값] 표
+ 탈락 조합별로 틀린 평가셋 id 목록.

받을 증거

• 조합별 실행 명령 + 출력 원문 (평가 스크립트의 요약 줄, nvidia-smi 출력)
• 틀린 평가셋 id 목록 (점수만이 아니라 무엇을 틀렸는지)
• 후보별 config.json 값과 KV 캐시/토큰 계산

내가 직접 볼 것

산출물 체크리스트 (34차시)

• VRAM 예산표 (내 요청당 토큰 · 동시 수로 계산, 이론값 표시)
• 후보 2~3개 목록 (Hugging Face 주소 · 라이선스 확인)
• 비교 매트릭스 (하한 통과 여부 먼저, 통과한 행만 성능)
• 운영 엔진과 양자화 형식의 짝 (4.1절)
• 결정 기록 DR-001 (탈락 이유가 숫자로)
• 35차시에 넘길 값: 모델 저장소 이름, 양자화, max-model-len, KV 캐시 dtype

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 34차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"VRAM 예산표 계산", "품질 하한을 먼저 보는 이유", "엔진에 맞는 양자화 형식", "결정 기록의 네 칸"은 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.