로컬 LLM

지도 위치 : 2일차 · ①하드웨어 × ③추론 엔진을 숫자로 읽기 | 이전: 13차시 LLM 추론 파라미터 최적화 | 다음: 15차시 모델별 최적화 비교 키워드 : Latency, TTFT, TPS, Throughput, GPU Utilization, VRAM 사용량

이 차시를 다 읽으면

1. Latency · TTFT · TPOT · TPS · Throughput을 유와 종차로 정의하고, 타임라인 그림 위에 짚을 수 있다.
2. TTFT와 TPS가 각각 Prefill과 Decode (2차시)에 대응한다는 것을 말할 수 있다.
3. 한 건의 시간 ↔ 전체 처리량 축으로 "빨라졌다"는 말이 어느 쪽 이야기인지 가를 수 있다.
4. Ollama 응답 통계(나노초)로 Prefill 속도와 생성 TPS를 계산 할 수 있다.
5. 측정 규칙 다섯 가지를 대고, AI의 보고에서 "추정"과 "측정"을 구분 할 수 있다.

---

0. 이 차시의 판별 축

앞에서 이어집니다 — README 5.1의 경고 하나가 이 차시의 축 1입니다. " ⑥ 비동기는 더 빠른 것이 아니다. 일 한 건 에 걸리는 시간은 같고, 기다리는 시간에 다른 일을 해서 같은 시간에 처리하는 양(전체 처리량) 이 늘어날 뿐이다." 가게로 치면, 손님 한 명의 음식이 나오는 시간은 그대로인데 한 시간에 받는 손님 수가 늘어나는 것입니다. LLM 서빙에서 "빨라졌다"는 말도 이처럼 두 가지 전혀 다른 뜻 이 될 수 있습니다. 2차시 4절의 Prefill · Decode를 이번에는 숫자로 잽니다.

---

1. 지표 — 타임라인 위에 놓기

1.1 한 요청의 타임라인 ⭐

요청 보냄                첫 토큰 도착                                       마지막 토큰 도착
   │                        │                                                   │
   ├─ (모델 로딩) ─┬─ Prefill ┤─ 토큰 ─ 토큰 ─ 토큰 ─ … ─ 토큰 ─ 토큰 ─ 토큰 ──────┤
   │  첫 요청만    │  입력 전체 │◄─TPOT─►                                          │
   │               │  한꺼번에  │        Decode: 한 토큰씩                         │
   │◄──── TTFT ────────────────►│                                                   │
   │◄─────────────────────────── Latency (E2E) ─────────────────────────────────────►│

1.2 정의

TPOT ≈ (E2E − TTFT) ÷ (출력 토큰 수 − 1)
TPS  ≈ 출력 토큰 수 ÷ 생성 시간

⭐ 2차시 4절의 표가 여기서 숫자를 얻습니다. "첫 응답이 늦다" = TTFT(Prefill) , "답이 느릿느릿 나온다" = TPS(Decode) . 손볼 곳이 다르다는 그 표입니다.

1.3 GPU 자원 지표

⚠️ 반례 — "GPU 사용률 100%니까 더 이상 빨라질 수 없다"는 틀린 추론입니다. 사용률은 바빴던 시간의 비율 이지 얼마나 효율적으로 바빴는가 가 아닙니다. 15차시에서 Decode가 메모리 병목이라는 것을 보면 이유가 분명해집니다.

---

2. ⭐ 한 건의 시간 ↔ 전체 처리량

2.1 두 질문은 다르다

2.2 둘은 서로 당긴다

동시 요청이 늘면 GPU는 여러 요청을 한꺼번에 계산해 처리량이 늘지만 , 각 요청 입장에서는 남과 나눠 쓰느라 한 건의 시간이 늘 수 있습니다.

동시 요청 1개:   한 건 빠름 · 처리량 낮음
동시 요청 10개:  한 건 조금 느려짐 · 처리량 크게 높음   ← 서빙 엔진(vLLM)이 노리는 자리
동시 요청 과다:  한 건 많이 느려짐 · 처리량도 더 안 늚 · 메모리 부족으로 대기·선점

(방향만 보여주는 그림입니다. 실제 모양은 22차시에서 측정합니다.)

⭐ 그래서 목표는 한 문장에 두 축을 같이 적습니다. 예: "동시 10명에서 TTFT p95 < 1초" (SLO, 22 · 39차시). "빠르게"만 쓰면 어느 축인지 모릅니다.

앞으로 다시 만납니다 — 이 차시는 요청 하나씩 재는 법입니다. 동시 요청을 걸어 처리량을 재는 것은 22차시(Serving 성능 측정)에서 비동기 클라이언트 로 합니다.

💡 왜 비동기 클라이언트인지 미리 짚어 둡니다. 일은 무엇을 기다리느냐에 따라 두 종류로 나뉩니다.

Python에서는 async def로 정의한 함수가 이 "기다리는 동안 다른 일을 하는" 방식으로 돕니다. 클라이언트의 일은 거의 전부 I/O-bound이므로, 비동기로 짜면 컴퓨터 한 대로 수십 개의 동시 요청을 걸어 서버의 처리량 을 잴 수 있습니다. 반대로 서버 쪽 생성 속도(TPS)는 비동기로 바뀌지 않습니다.

---

3. Ollama 응답 통계로 계산하기

3.1 통계 필드

7차시에서 본 대로 Ollama 응답의 마지막 줄("done": true)에 통계가 붙습니다. ⚠️ 단위는 나노초 (10⁻⁹초)입니다.

curl -s http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "prompt": "다음 고객 문의를 세 줄로 요약해: ...",
  "stream": false,
  "options": {"temperature": 0, "num_predict": 200, "seed": 42}
}' | jq '{load_duration, prompt_eval_count, prompt_eval_duration, eval_count, eval_duration, total_duration}'

🔍 읽는 포인트 : "stream": false(한 번에 받기), options의 세 값이 측정 조건 고정 (4절), jq는 통계 필드만 골라 보여주는 도구.

3.2 계산

Prefill 속도 (토큰/초) = prompt_eval_count ÷ prompt_eval_duration × 1e9
생성 TPS   (토큰/초) = eval_count ÷ eval_duration × 1e9
서버 기준 TTFT 어림   ≈ (load_duration + prompt_eval_duration) ÷ 1e9  초

예시(실측 아님): eval_count 200, eval_duration 4,000,000,000 → 200 ÷ 4e9 × 1e9 = 50 토큰/초.

⚠️ 주의 두 가지.

• 서버 기준 vs 사용자 기준 : 통계는 서버 안에서 잰 값입니다. 사용자가 느끼는 TTFT에는 네트워크 · 앱 처리 시간이 더해집니다. 사용자 기준은 스트리밍으로 받으며 클라이언트에서 첫 조각 도착 시각 을 잽니다(아래 코드).
• 같은 프롬프트를 반복하면 엔진이 앞부분 계산을 재사용해 prompt_eval_count가 작게 나올 수 있습니다. 매번 값을 확인하고, Prefill을 잴 때는 이 점을 기록합니다(21차시 프리픽스 캐싱과 같은 현상).

3.3 사용자 기준 TTFT 재기

import time, ollama

t0 = time.perf_counter()
ttft = None
for chunk in ollama.chat(model="qwen3:8b", messages=[{"role": "user", "content": PROMPT}],
                         stream=True, options={"temperature": 0, "num_predict": 200, "seed": 42}):
    if ttft is None and chunk["message"]["content"]:
        ttft = time.perf_counter() - t0          # 첫 조각 도착
    last = chunk
e2e = time.perf_counter() - t0                   # 마지막 조각 도착

🔍 읽는 포인트 : t0(보낸 시각) → ttft(첫 조각이 비어 있지 않을 때 ) → e2e(끝). stream=True여야 첫 조각을 잴 수 있습니다. ⚠️ Qwen3의 생각 모드가 켜져 있으면 첫 조각이 <think> 내용일 수 있으니, 생각 모드를 어떻게 설정했는지 도 측정 조건에 적습니다(버전 · 모델 카드 확인).

---

4. ⭐ 측정 규칙

p95 — [통계 지표]인데, [ 100번 중 95번은 이보다 빨랐다는 경계값 ]이라는 점에서 가운데 값인 중앙값과 구별된다. 사용자가 "가끔 너무 느리다"고 느끼는 것은 평균이 아니라 p95 쪽입니다.

4.1 GPU 숫자 함께 기록하기

# 1초마다 사용률 · 메모리를 CSV로
nvidia-smi --query-gpu=utilization.gpu,memory.used,memory.total --format=csv -l 1

측정을 돌리는 동안 다른 터미널에서 켜 두고, 결과를 측정표와 함께 저장합니다. 눈으로만 볼 때는 watch -n 1 nvidia-smi도 됩니다.

4.2 측정 결과표 양식

💡 숫자 칸은 직접 채웁니다. "VRAM (도구)" 칸에 어느 도구의 숫자인지(nvidia-smi / ollama ps)를 꼭 적습니다(9차시 4.2). 15차시 비교표가 이 양식을 그대로 씁니다.

---

5. AI의 "추정"과 "측정" 구분하기

README 9장의 위험 "추정을 측정처럼 말함"이 이 차시에서 가장 자주 일어납니다.

⭐ 코드를 맡길 때 AI의 "완료했습니다"라는 말 대신 실행해 본 결과(빌드 · 테스트 통과 여부) 로 판정하듯, 성능에서도 AI의 "빨라졌습니다" 대신 측정표가 판정 합니다. 판정은 AI 바깥의 숫자가 합니다.

💡 이론 상한(15차시)처럼 계산으로 나온 값 은 추정이 아니라 계산값 입니다. 다만 "실측은 이보다 낮다"는 표시를 붙여 측정값과 섞이지 않게 합니다.

---

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

지시

목표: 문의봇 모델(qwen3:8b)의 한 건 성능을 측정 규칙에 따라 잰다.
맥락: Ollama API 문서에서 응답 통계 필드(이름, 단위)를 먼저 인용해. 설치된 Ollama 버전, GPU 이름, 모델 태그와 양자화(ollama show)를 기록.
조건: 문의 예시 3개(짧은/중간/긴 메일, 내가 줌). temperature 0, seed 42, num_predict 200, num_ctx 8192, 생각 모드 설정 명시.
작업:
 1. 각 프롬프트마다 워밍업 1회 버리고 10회 반복.
 2. 서버 통계로 Prefill 속도, 생성 TPS 계산. 스트리밍으로 클라이언트 기준 TTFT, E2E 측정.
 3. 측정 중 nvidia-smi --query-gpu=utilization.gpu,memory.used --format=csv -l 1 을 따로 기록.
보고 형식: 노트 14차시 4.2 측정 결과표 양식 그대로. 중앙값과 p95를 함께.
추측하지 말고 실행 코드, 원본 측정 로그(10회 각각의 값), 계산 과정을 붙여.

받을 증거

• 버전 · GPU · 모델 정보 출력
• 10회 각각의 원본 값 (통계 JSON 또는 CSV), 워밍업 1회 값(버린 것도 별도로)
• 계산 과정, nvidia-smi 로그

내가 직접 볼 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 14차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"TTFT와 TPS가 Prefill·Decode 중 어디인가", "한 건의 시간 vs 전체 처리량", "Ollama 통계 나노초 계산", "측정 규칙"은 반드시 포함하고 계산 문제 1개를 넣어줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.