로컬 LLM

지도 위치 : 2일차 · 마무리 — ①②를 묶어 결정하기 | 이전: 15차시 모델별 최적화 비교 | 다음: 17차시 LLM Serving 아키텍처 키워드 : GPU VRAM별 모델 선정, 품질 · 속도 · 메모리 Trade-off 분석

이 차시를 다 읽으면

1. VRAM 8 · 12 · 16 · 24 · 48GB 이상에서 출발점이 될 모델 크기 · 정밀도 를 계산 근거와 함께 말할 수 있다.
2. "큰 모델 저비트 vs 작은 모델 고비트"의 경향과 그 한계 를 말할 수 있다.
3. 모델 선정을 다섯 단계 결정 절차 로 진행하고, 그 순서가 왜 품질부터인지 설명할 수 있다.
4. 결정을 결정 기록(맥락 · 결정 · 검토한 대안 · 결과) 형식으로 남길 수 있다.
5. 2일차 전체를 VRAM 예산식 한 줄과 트레이드오프 삼각형 으로 정리할 수 있다.

---

0. 이 차시의 판별 축

앞에서 이어집니다 — 9~15차시에서 도구를 다 모았습니다. VRAM 예산식(9차시), 양자화의 비트별 크기(10 · 12차시), 자원 손잡이(13차시), 측정 규칙(14차시), 정밀도 비교표(15차시). 이번 차시가 답하는 질문은 "그래서 우리 GPU에는 어떤 모델을 어떤 형식으로 올리는가?" 입니다. "8GB면 몇 B" 같은 숫자를 외워 두는 대신, 그 표를 계산으로 직접 만들고, 측정으로 확정하고, 기록으로 남기는 법 을 봅니다.

---

1. VRAM 등급별 출발점

1.1 계산 근거

표의 모든 칸은 9차시 예산식 하나로 나옵니다.

필요한 VRAM ≈ 가중치(파라미터 × 바이트) + KV 캐시(토큰당 크기 × 컨텍스트 × 동시 요청) + 나머지(약 1~2GB)

가중치 어림: F16 ≈ 파라미터 × 2 / Q8 ≈ × 1.06 / Q4_K_M ≈ × 0.6   (단위 GB, 파라미터는 B 단위)

⚠️ Q8 · Q4의 배수는 그룹 scale 등을 포함한 어림 입니다(10차시 2.2). KV 캐시 토큰당 크기는 모델마다 다르니 config.json으로 계산합니다(9차시 2.2). 아래 표는 8B급에서 약 144KB/토큰(Qwen3-8B, F16 KV)을 가정합니다.

1.2 ⭐ 등급별 출발점 표

이 표는 후보를 좁히는 출발점 입니다. 확정이 아닙니다. 결정은 3절 절차의 측정으로 합니다.

💡 VRAM 다음으로 볼 것은 메모리 대역폭 입니다(15차시 2.2). 같은 VRAM이라도 대역폭이 작은 GPU는 Decode 상한이 낮습니다. 노트북 GPU · 보급형 GPU를 비교할 때 사양표의 대역폭(GB/s) 칸을 함께 봅니다.

---

2. 큰 모델 저비트 vs 작은 모델 고비트

2.1 경향

같은 VRAM 예산 안에서 두 갈래가 생깁니다.

⭐ 둘째 줄이 15차시의 수확입니다. 속도 상한은 "몇 B인가"가 아니라 "몇 GB를 읽는가" 가 정합니다. 그래서 같은 바이트라면 크기 선택은 주로 품질 ↔ 동시 수(KV 캐시) 의 거래가 됩니다.

2.2 반례 — 경향이 뒤집히는 경우

---

3. ⭐ 결정 절차 — 품질부터

README 7장 문장 2: "먼저 내 업무에 충분한 품질 을 평가셋으로 정하고, 나머지를 최적화합니다." 그 순서를 단계로 씁니다.

① 품질 하한 정하기 ─→ ② 지연·동시성 요구 정하기 ─→ ③ 후보 고르기 ─→ ④ 측정 ─→ ⑤ 결정·기록
   (평가셋, 6차시)       (SLO, 14차시)                 (1절 표+예산식)   (14·15차시)   (4절)
        ▲                                                                   │
        └──────────── 하한을 넘는 후보가 없으면: 하한·요구·하드웨어 중 무엇을 바꿀지 사람이 결정 ─┘

⚠️ 순서를 거꾸로 하면(“가장 빠른 것부터 고르고 품질 확인”) 빠르지만 쓸 수 없는 모델 에 시간을 씁니다. ①이 비어 있으면 ④의 숫자를 어떤 기준으로 읽을지 정할 수 없습니다.

💡 ①②의 숫자는 사람이 정하는 값 입니다(0절 축 1). AI에게 "적당한 기준을 정해줘"라고 맡기면 업무의 위험(주문번호 한 자리 오류의 비용)을 모르는 값이 나옵니다.

---

4. 결정 기록 — 맥락 · 결정 · 검토한 대안 · 결과

결정 기록 (ADR, Architecture Decision Record) — [개발 문서]인데, [ 결정 하나를 고른 이유와 버린 대안까지 짧게 남긴다 ]는 점에서 "지금 무엇이 어떻게 되어 있는가"만 적는 설명서 · 설정 파일과 구별된다. 소프트웨어 개발에서 되돌리기 비싼 선택(어떤 데이터베이스 · 구조 · 엔진을 쓸지)을 남길 때 쓰는 형식이고, 결정마다 번호를 붙여 한 건씩 쌓습니다.

모델 선정도 나중에 "왜 이걸 골랐지?"를 물을 결정 이므로 이 네 칸으로 남깁니다.

4.1 트레이드오프 삼각형

              품질
             /    \
            /  ●   \        ● = 이번 결정이 앉은 자리
       속도 ──────── 메모리

트레이드오프는 "하나를 얻으면 하나를 잃는 관계"입니다(README 7장 문장 2). 10차시 5.1에서 본 양자화가 대표적입니다 — 메모리를 얻고 정밀도를 잃는 거래입니다. 결정 기록의 "결과" 칸에는 무엇을 잃었는지 를 반드시 적습니다.

4.2 문의봇 결정 예시

⚠️ 아래 숫자는 모두 예시(실측 아님) 입니다. 형식과 근거의 서술 방식만 참고하세요.

# 결정 기록 0003: 문의봇 1차 모델을 Qwen3-8B Q8_0으로 한다

## 맥락
- 하드웨어: RTX 4090 24GB 1장. 개인정보 때문에 로컬 필수(1차시).
- 요구: 상담원 10명 동시, 긴 메일 8K 토큰, TTFT p95 2초 이내(예시 SLO).
- 품질 하한: 분류 90%, 주문번호 추출 오류 0건(형식 검증 후), 초안 루브릭 3/5(예시).

## 결정
- Qwen3-8B Q8_0, num_ctx 8192, KV 캐시 f16, temperature: 분류·추출 0 / 초안 0.6.

## 검토한 대안
- 8B F16: 품질 최고였으나 8K 동시 약 5개로 10명 요구를 못 채움(9차시 계산 + 측정 조건 A-3).
- 8B Q4_K_M: 동시 수 여유 최대, TPS 최고. 단 평가셋에서 주문번호 추출 오류 2건(예시) → 하한 미달.
- 14B Q4_K_M: 초안 블라인드 점수 가장 높음(예시). KV 캐시가 커서 8K 동시 수 부족 → 3일차 vLLM에서 재검토.

## 결과
- 얻은 것: 하한 충족, 8K 동시 약 12개(계산값) 여유.
- 잃은 것: F16 대비 초안 점수 소폭 하락(예시), Q4 대비 속도.
- 다시 볼 조건: vLLM 전환 시(19~23차시) 14B AWQ/FP8 재측정. 평가셋이 바뀌면 재평가.
- 측정 조건 ID: A-1 ~ A-6 (14차시 4.2 양식).

🔍 읽는 포인트 : 각 근거 옆에 어느 차시의 계산인지, 어느 측정 조건 ID인지 가 붙어 있습니다. "느낌상 Q8이 무난해서"가 없습니다. 가장 쓸모 있는 칸은 "검토한 대안" 입니다. 3일차에 vLLM으로 바꾸거나 새 모델이 나왔을 때, 처음부터 다시 조사하지 않고 탈락 이유가 아직 유효한지 만 확인하면 되기 때문입니다.

💡 README 7장 문장 3 — 앱이 OpenAI 호환 API라는 약속 만 알고 그 뒤의 엔진 · 모델을 모르면(12차시 3.1, 20차시), 모델은 갈아 끼울 수 있습니다. 그러면 이 결정은 되돌릴 수 있는 결정 이 됩니다. 그래서 "다시 볼 조건"을 적어 두는 것입니다.

---

5. 2일차 정리 → 3일차 예고

5.1 2일차를 한 장으로

5.2 아직 답하지 않은 질문

2일차는 거의 전부 요청 하나 를 기준으로 쟀습니다. 문의봇의 결정 기록에도 "3일차 vLLM에서 재검토"가 남았습니다.

앞으로 다시 만납니다 — 17차시부터 축 ⑤ 하나 ↔ 여럿 으로 넘어갑니다. 상담원 10명이 동시에 요청하면 KV 캐시를 어떻게 나눠 쓰는가(21차시 PagedAttention), 한 건의 시간을 조금 내주고 처리량을 얼마나 얻는가(22차시), 그리고 9차시 3.1에서 손으로 계산한 "동시에 약 5개"를 vLLM이 기동 로그에서 어떻게 보여주는가(19차시).

---

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

지시

목표: 우리 GPU에서 문의봇 모델 후보 3개를 고르고, 결정 기록 초안을 만든다.
맥락: 노트 16차시 1절 표와 9차시 예산식. 후보 모델의 config.json 원문(층 수, KV 헤드, head_dim)과
      Ollama 태그 또는 GGUF 파일 크기를 직접 확인해 인용해. 기억으로 쓰지 마.
입력(내가 줌): GPU 이름과 VRAM, 품질 하한, 동시 사용자 수, 최대 컨텍스트, SLO.
작업:
 1. 후보 3개 각각: 가중치 크기(파일 크기 기준) + 토큰당 KV 캐시 + 나머지 1.5GB로 예산식 계산, 최대 컨텍스트 기준 동시 요청 수 계산.
 2. Decode 이론 상한 = GPU 메모리 대역폭(공식 사양 출처 인용) ÷ 가중치 GB.
 3. 15차시 측정 결과(조건 ID)가 있으면 붙이고, 없으면 "측정 필요"로 표시.
 4. 16차시 4.2 형식으로 결정 기록 초안. "결정" 칸은 비워 둬(내가 씀). "검토한 대안"에 세 후보 모두.
보고 형식:
| 후보 | 가중치 GB(출처) | KV/토큰 | 동시 요청 수(계산) | 이론 상한 TPS(계산) | 품질 하한 충족(측정/미측정) |
계산값과 측정값을 구분해서 표시하고, 추측하지 말고 출처 링크와 계산 과정을 붙여.

받을 증거

• 후보별 config.json 원문 일부, 파일 크기 출처, GPU 대역폭 사양 출처
• 계산 과정 (한 줄씩)
• 결정 기록 초안 (결정 칸 비어 있음)

내가 직접 볼 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 16차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"VRAM 등급표의 계산 근거", "큰 모델 저비트 vs 작은 모델 고비트", "결정 절차가 품질부터인 이유", "결정 기록의 네 칸"은 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.