로컬 LLM

지도 위치 : 5일차 · 프로젝트 7단계 · ①~⑤ 다섯 층 전체를 숫자로 | 이전: 38차시 Function Calling 및 서비스 통합 | 다음: 40차시 프로젝트 발표 및 평가 키워드 : 응답속도, TPS, Throughput, GPU 메모리 측정 및 최적화

이 차시를 다 읽으면

1. 33차시의 성능 목표(SLO)를 시나리오 · 동시성 단계 · 지표 로 이루어진 측정 계획으로 바꿀 수 있다.
2. 동시성 단계별 부하 테스트 표를 채우고, SLO가 깨지는 지점을 찾을 수 있다.
3. 느릴 때 Prefill인가 Decode인가 → KV 캐시 부족인가 → 앱 서버인가 의 순서로 병목을 판정할 수 있다.
4. 최적화를 한 번에 하나씩 적용하고 before/after 표로 판정할 수 있다.
5. 최적화 후 평가셋을 다시 돌려 품질 회귀를 확인해야 하는 변경을 고를 수 있다.
6. 숫자마다 측정 조건 을 함께 기록할 수 있다.

---

0. 이 차시의 판별 축

앞에서 이어집니다 — 14차시 (측정 규칙: 워밍업, 고정 출력 길이, 중앙값 · p95, 변수 하나), 22차시 (동시 요청 부하 측정), 23차시 (vLLM 최적화 옵션)를 프로젝트 하나에 적용합니다. 다른 점은 통과선이 있다 는 것입니다. 3일차에는 "몇이 나왔다"로 끝났지만, 39차시는 33차시 NFR-01 — "동시 10명 TTFT p95 < 1초" — 을 넘었는가 못 넘었는가 를 판정합니다.

---

1. 측정 계획 — SLO를 시험으로 바꾸기

1.1 지표 회수 (14 · 22차시)

1.2 시나리오 — 부하의 모양

문의봇의 요청은 모양이 다릅니다. 한 가지 프롬프트로만 재면 실제와 다릅니다.

💡 입력은 33차시 평가셋의 실제 메일(가명) 에서 뽑습니다. 짧은 "안녕하세요" 프롬프트로 잰 숫자는 문의봇의 숫자가 아닙니다.

1.3 측정 조건 기록

[측정 ID] P-003
[날짜] 2026-12-06 15:20
[장비] RTX 4090 24GB / 드라이버 ___ / CUDA ___
[엔진] vLLM ___ (vllm --version 출력)
[모델 · 양자화] DR-001의 값
[기동 옵션] (35차시 명령 전체를 그대로 붙임)
[프롬프트 버전] triage.v2, reply.v1
[시나리오] S1:S2:S3 = 5:4:1, 입력 토큰 중앙값 ___ / 최대 ___
[생성 설정] temperature 0, max_tokens S1=300 S2=500
[동시성 · 요청 수] 10 동시, 200 요청, 워밍업 10 요청 제외
[측정 구간] vLLM 직접 / 앱 경유
[도구 · 명령] (실행한 명령 원문)

⚠️ 조건이 없는 숫자는 비교할 수 없습니다. "빨라졌습니다"만으로는 아무 정보도 되지 않습니다. 무엇이, 어떤 조건에서, 얼마에서 얼마로 바뀌었는지가 함께 있어야 숫자가 됩니다. "어떤 조건에서"가 바로 이 기록입니다. 40차시 발표에서 숫자를 말할 때 이 블록이 함께 갑니다.

---

2. 동시성 단계별 부하 테스트

2.1 왜 단계별인가

동시 10명만 재면 "통과/실패"만 압니다. 1 → 2 → 5 → 10 → 15 → 20으로 올리면 어디서 깨지는지 , 즉 여유가 얼마인지 압니다. 상담원이 12명으로 늘면 괜찮은가? 그 답이 15 · 20 줄에 있습니다.

2.2 ⭐ 부하 테스트 표 — 직접 채우는 표

시나리오 혼합(1.2절)으로, 측정 구간은 vLLM 직접 과 앱 경유 두 벌을 채웁니다.

2.3 표를 읽는 법

⭐ 첫 줄이 이 차시의 핵심입니다. 앞에서 배운 "비동기는 빠른 게 아니다. 한 건의 시간은 같고 처리량이 늘어난다"(README 5.1 축 ⑥) 와 같은 구조입니다. vLLM의 연속 배칭도 한 건을 빠르게 하는 기술이 아니라 처리량을 늘리는 기술 입니다(21 · 22차시, README 5.3 "한 건의 시간 ↔ 전체 처리량").

2.4 무엇으로 재나

⚠️ nvidia-smi의 memory.used로 KV 캐시가 꽉 찼는지 알 수 없습니다. vLLM은 기동 때 이미 확보해 두었기 때문입니다. KV가 얼마나 차 있는지는 /metrics 에서 봅니다.

---

3. ⭐ 병목 판정 순서

SLO를 못 넘었을 때 "모델이 느리다"고 결론 내리면 대개 틀립니다. 요청 한 건은 브라우저 → 앱 서버 → 모델 서버 → (도구) → 다시 앱 서버를 지나므로, 구간마다 시간을 따로 찍어야 어디서 느린지 압니다. 전체 시간 하나만 보면 범인을 모델로 몰기 쉽습니다. 아래 순서로 좁힙니다.

3.1 세 질문

3.2 판정별 손볼 곳

💡 앱 서버가 병목이면 모델 쪽을 손대지 않습니다. 대가가 "거의 없음"인 칸부터 고칩니다. 36차시 4.3절의 "원인이 지시 · 설정 쪽에 있으면 모델 교체는 답이 아니다"의 성능판입니다.

⚠️ Decode의 이론 상한은 34차시 4.2에서 계산했습니다(대역폭 ÷ 가중치 크기). 동시성 1에서 잰 TPS가 이 상한을 넘으면 측정이 잘못된 것이고, 상한에 크게 못 미치면 엔진 설정을 의심합니다(개발용 Ollama로 쟀다면 ollama ps의 CPU/GPU 분할부터, 12차시).

---

4. 최적화 — before / after

4.1 규칙

4.2 before / after 표 — 직접 채우는 표

4.3 ⚠️ 품질 회귀 확인 — 평가셋을 다시 돌려야 하는 변경

⭐ README 7장 문장 2 — "품질 · 속도 · 메모리는 셋 다 가질 수 없다. 측정해서 고른다." — 를 실제로 하는 자리가 이 표입니다. TTFT가 30% 줄었는데 주문번호 정확도가 하한(95%) 아래로 떨어졌다면, 그 최적화는 채택하지 않습니다. 34차시의 순서(품질 하한이 먼저)가 최적화에서도 그대로입니다.

💡 회귀(Regression) — 예전에 잘 되던 것이 새 변경 때문에 다시 망가지는 현상 — 가 LLM 서비스에서는 "설정 하나 바꿨더니 분류 정확도가 떨어졌다" 로 나타납니다. 사람은 안 건드린 곳을 다시 시험하지 않으니, 프롬프트 · 설정이 바뀔 때마다 평가셋 실행이 자동으로 돌게 하는 것이 다음 단계입니다. 코드가 바뀔 때마다 자동으로 시험을 돌리는 이런 장치를 CI (지속적 통합)라고 부릅니다(40차시 개선사항).

---

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

지시

문의봇의 성능 테스트와 최적화를 해줘.

목표: 1.2절 시나리오 혼합으로 동시성 1/2/5/10/15/20 부하 테스트를 vLLM 직접과 앱 경유 두 구간에서 실행하고,
     33차시 SLO(동시 10명 TTFT p95 < 1초, 오류 0건) 통과 여부를 판정해.
     실패하면 3.1절 순서(TTFT/TPOT → KV·대기열 → 앱 구간)로 병목을 판정하고, 4.2절 변경을 하나씩 적용해.
맥락: 35차시 vLLM 서비스(기동 옵션 첨부), 37·38차시 앱 서버. 입력은 eval_v1.jsonl의 메일에서 뽑아.
     vLLM 벤치마크 도구는 설치된 버전의 문서 기준으로.
제약:
- 워밍업 요청은 버리고, temperature 0, max_tokens 고정. 1.3절 측정 조건 블록을 측정마다 남겨.
- 한 번에 옵션 하나만 바꿔. 서비스 재시작이 필요하면 바꿀 옵션을 먼저 보여줘.
- kv-cache-dtype, 양자화, 프롬프트, max-model-len을 바꾸면 반드시 평가셋을 다시 돌려 품질 칸을 채워.
- 성능이 올라도 품질 하한(분류 90%, 주문번호 95%, 지어낸 값 0건)을 깨면 '미채택'으로 표시해.
- 추측하지 말고 실행 명령, 벤치마크 출력 원문, /metrics 발췌를 붙여.
보고 형식:
1) 2.2절 부하 테스트 표 (직접 / 앱 경유 두 벌)
2) 병목 판정: [질문 | 본 지표 | 값 | 판정]
3) 4.2절 before/after 표 + 각 행의 측정 ID

받을 증거

• 측정마다 측정 조건 블록 (1.3절)과 실행 명령 · 출력 원문
• /metrics 발췌 (대기 요청 수 · KV 사용률 · 선점), nvidia-smi 로그
• before/after 각 행의 평가셋 실행 결과

내가 직접 볼 것

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

• 측정 계획 (시나리오 S1~S4, 혼합 비율, 입력 출처)
• 측정 조건 블록 (측정 ID별)
• 부하 테스트 표 (동시성 6단계 × 직접 / 앱 경유)
• SLO 판정 (NFR-01 통과 / 미달, 깨지는 동시성)
• 병목 판정표 (3.1절 세 질문)
• before/after 표 (한 행 한 변경, 품질 칸 포함)
• 갱신된 기동 명령 · DR-001 (채택한 변경 반영)

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 39차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"한 건의 시간과 전체 처리량", "병목 판정의 세 질문", "품질 회귀 확인이 필요한 변경", "측정 조건 기록"은 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.