LangTailor페이지 목차
이 페이지에서 검색
로컬 LLM
이 페이지에 묻기
로컬 LLM · 현재 차시와 목차 본문에서만 찾아 답합니다. 답을 지어내지 않고 해당하는 대목을 그대로 보여 주며, 여기에 없으면 없다고 알려 드립니다.
생성형 AI가 아니라 이 페이지 본문을 찾아 그대로 보여 주는 방식입니다. 외부로 나가는 요청이 없습니다.
LOCAL · LLM
로컬 LLM
생성 수정
로컬 모델 실행과 GPU·메모리 이해부터 서빙·RAG·도구 호출·업무형 앱 구현까지 차례로 살펴봅니다.
42개 문서 · 2일차 · 16 / 42
15차시 · 모델별 최적화 비교
지도 위치 : 2일차 · ①②③을 한 실험으로 묶기 | 이전: 14차시 LLM 추론 성능 측정 | 다음: 16차시 하드웨어별 최적 모델 선정 키워드 : FP16 · 8bit · 4bit 모델의 메모리 · 속도 · 출력 품질 비교
이 차시를 다 읽으면
- 정밀도 비교 실험을 같은 모델 · 같은 엔진 · 같은 프롬프트셋 · 같은 측정 규칙 으로 설계할 수 있다.
- 계산 병목 ↔ 메모리 병목 축으로 "왜 가중치가 가벼우면 Decode가 빨라지는가"를 설명할 수 있다.
- 메모리 대역폭과 가중치 크기로 Decode 속도의 이론 상한 을 계산하고, 실측과 비교할 수 있다.
- bitsandbytes 8bit처럼 이 설명이 맞지 않는 예외 를 말할 수 있다.
- 품질을 블라인드 비교 로 채점하고, 결과를 해석 문장 으로 쓸 수 있다.
0. 이 차시의 판별 축
| # | 축 | 왼쪽 (0) | 오른쪽 (1) | 이 축으로 갈리는 것 | 큰 축 (README 5장) |
|---|---|---|---|---|---|
| 1 | ⭐ 무엇이 속도를 막는가 | 계산 병목 (Prefill) | 메모리 병목 (Decode) | 양자화가 TTFT보다 TPS에 더 듣는 이유 | 계산 병목 ↔ 메모리 병목 (파생 축, 부모 ①) |
| 2 | 정밀도 | FP16 | Q8 · Q4 | 세 축(메모리 · 속도 · 품질)의 값 | 정밀도 (파생 축, 부모 ①) |
| 3 | 채점자가 답을 아는가 | 앎 (모델명 보고 채점) | 모름 (블라인드) | 믿을 수 있는 품질 숫자 | — (이 차시에서 세우는 축, 4절) |
앞에서 이어집니다 — 2차시 4절에서 "Decode의 병목은 메모리 읽기 (토큰 하나마다 가중치 전체를 읽음)"라고 적고 "15차시에서 이 표로 설명한다"고 예고했습니다. 그 회수입니다. 그리고 10차시 5.2에서 "양자화가 확실히 주는 것은 메모리뿐, 속도는 측정으로만"이라고 했습니다. 이번에 그 측정을 합니다.
1. 비교 실험 설계
1.1 무엇을 고정하고 무엇을 바꾸나
14차시 측정 규칙 4번 "한 번에 변수 하나"를 실험 전체로 키운 것입니다. 바꾸는 것은 정밀도 하나뿐 입니다.
| 고정 | 값 (문의봇 예) | 고정하지 않으면 |
|---|---|---|
| 기반 모델 | Qwen3-8B | 크기 · 구조 차이가 섞임 (16차시에서 따로) |
| 엔진 | 한 엔진 안에서 (예: Ollama 또는 llama.cpp의 GGUF F16 · Q8_0 · Q4_K_M) | ⚠️ 엔진 차이가 정밀도 차이로 보임 |
| 프롬프트셋 | 6차시 평가셋 전체 + 측정용 고정 프롬프트 3개 | 우연히 쉬운 문의만 비교 |
| 생성 설정 | temperature 0, seed 고정, 출력 길이 고정, 같은 num_ctx | 14차시 4절 |
| 측정 규칙 | 워밍업 · N회 반복 · 중앙값/p95 | 14차시 4절 |
| 하드웨어 | 같은 GPU, 다른 프로세스 없음, 오프로드 없음 | 12차시 4.2 — CPU 분할이 섞이면 무효 |
⚠️ 가장 흔한 설계 오류는 "FP16은 Transformers로, 4bit는 Ollama로" 재는 것입니다. 그러면 정밀도 차이와 엔진 차이가 섞여 무엇을 비교했는지 모릅니다. 11차시(bitsandbytes) 결과는 별도 열 로 두고 섞지 않습니다.
💡 Ollama에서 같은 모델의 정밀도별 태그(예: -fp16, -q8_0, -q4_K_M 꼴)는 모델 페이지의 태그 목록에서 실제 이름을 확인 합니다. 또는 12차시 5.1처럼 GGUF 파일을 받아 ollama create로 등록합니다.
1.2 결과표 양식 — 세 축
숫자 칸은 직접 채웁니다. "이론 상한" 열만 2절의 계산값 입니다.
| 축 | 항목 | F16 | Q8_0 | Q4_K_M | (참고) bnb 8bit · 4bit — 11차시 |
|---|---|---|---|---|---|
| 메모리 | 파일 크기 (GB) | — | |||
| VRAM (도구: ________) | |||||
| 같은 GPU에서 8K 동시 요청 가능 수 (9차시 예산식) | |||||
| 속도 | TTFT 중앙값 / p95 (긴 메일) | ||||
| 생성 TPS 중앙값 | |||||
| 이론 상한 TPS (2.2절, 계산값) | ≈ 60 | ≈ 115 | ≈ 200 | — | |
| 실측 ÷ 이론 상한 (%) | |||||
| 품질 | 분류 정확도 (%) | ||||
| 주문번호 · 연락처 추출 정답 (건/전체) | |||||
| 요약 · 초안 블라인드 점수 (4절) |
2. ⭐ 계산 병목 ↔ 메모리 병목
2.1 정의
계산 병목 (Compute-bound) — [성능 제약 상태]인데, [ 연산 장치가 계산하느라 바빠서 속도가 막힌다 ]는 점에서 메모리 병목과 구별된다.
메모리 병목 (Memory-bound) — [성능 제약 상태]인데, [ 계산할 숫자를 메모리에서 읽어 오느라 연산 장치가 기다려서 속도가 막힌다 ]는 점에서 계산 병목과 구별된다.
-bound라는 이름짓기는 앞에서 배운 CPU-bound ↔ I/O-bound (14차시 2.2)와 같습니다. "무엇이 속도를 묶어 두는가." ⚠️ 하지만 메모리 병목은 네트워크 응답을 기다리는 I/O 대기가 아니라 GPU 칩 안에서 일어나는 기다림이라 async로 풀리지 않습니다. 비동기는 프로그램이 바깥(네트워크 · 디스크)을 기다리는 시간을 다른 일에 쓰는 기술이지, 계산 장치의 메모리 읽기를 빠르게 하지 않습니다(README 5.3, 2차시 4절).
| Prefill | Decode (요청 하나) | |
|---|---|---|
| 한 번 가중치를 읽어서 | 입력 토큰 수백~수천 개 를 한꺼번에 계산 | 토큰 1개 만 계산 |
| 읽기 대비 계산량 | 많음 | 적음 |
| 병목 | 계산 | 메모리 읽기 |
| 양자화(가중치가 가벼워짐)의 효과 | 작음. 역양자화 비용으로 오히려 느려질 수도 | ⭐ 큼 . 읽을 바이트가 줄어든 만큼 빨라짐 |
2.2 이론 상한 계산 — 계산값
Decode에서 토큰 하나를 만들 때마다 가중치를 대략 한 번 다 읽는다면, 1초에 만들 수 있는 토큰 수의 상한 은 이렇습니다.
Decode 속도 상한 (토큰/초) ≈ 메모리 대역폭 (GB/s) ÷ 토큰당 읽는 바이트 (≈ 가중치 크기, GB)
RTX 4090(메모리 대역폭 ≈ 1,000GB/s), Qwen3-8B 기준 계산값 입니다. 실측이 아닙니다.
| 정밀도 | 가중치 크기 (어림) | 이론 상한 | FP16 대비 |
|---|---|---|---|
| F16 | ≈ 16.4GB | 1,000 ÷ 16.4 ≈ 60 토큰/초 | 1배 |
| Q8_0 | ≈ 8.7GB | 1,000 ÷ 8.7 ≈ 115 토큰/초 | ≈ 1.9배 |
| Q4_K_M | ≈ 5GB | 1,000 ÷ 5 ≈ 200 토큰/초 | ≈ 3.3배 |
⚠️ 실측은 항상 이보다 낮습니다. KV 캐시도 읽어야 하고(컨텍스트가 길수록 더), 계산 커널이 대역폭을 100% 쓰지 못하고, 역양자화 계산도 있습니다. 이 표의 쓸모는 두 가지입니다.
- 방향과 비율 예측 — "Q4가 F16보다 대략 몇 배까지 빨라질 수 있나"
- 실측 검수 — 실측이 상한을 넘으면 측정이 틀렸습니다(출력 길이 · 단위 · 캐시 확인). 상한의 매우 작은 비율 이면 오프로드나 설정 문제를 의심합니다.
💡 같은 공식으로 GPU를 비교할 수도 있습니다. RTX 3090(≈ 936GB/s)은 4090과 대역폭이 비슷해서 Decode 상한도 비슷 합니다. 계산 성능 차이는 Prefill(TTFT) 쪽에서 더 드러납니다. 16차시 GPU 선정에서 "VRAM 용량"과 함께 "대역폭"을 보는 이유입니다.
2.3 예외 — 이 설명이 맞지 않는 경우
| 예외 | 왜 |
|---|---|
| ⚠️ bitsandbytes 8bit | 바이트는 줄었지만 튀는 값을 FP16으로 분리 계산하는 추가 계산 이 커서, 메모리 병목이 아니라 그 처리가 속도를 정함 → FP16보다 느릴 수 있음 (11차시 4.1) |
| 저비트 전용 계산 경로가 없는 엔진 · GPU 조합 | 가중치를 매번 펼치는 비용이 이득을 지움 |
| 동시 요청이 많을 때 | 한 번 읽은 가중치로 여러 요청의 토큰을 함께 계산 → 읽기 대비 계산량이 늘어 계산 병목 쪽으로 이동 → 양자화의 속도 이득이 줄어드는 경향 |
| 일부가 RAM에 있을 때 | RAM 대역폭이 상한을 정함 (12차시 4.2) |
⭐ 셋째 줄이 3일차의 열쇠입니다. 배치는 가중치 읽기 한 번을 여러 요청이 나눠 쓰게 하는 기술 이라서, 한 건의 속도가 아니라 처리량 을 늘립니다(14차시 2절).
앞으로 다시 만납니다 — 21차시 연속 배칭, 23차시 vLLM 최적화에서 "동시 요청이 많을 때 어떤 양자화가 이득인가"를 다시 봅니다.
3. 메모리 축 읽기
메모리는 비교적 예측대로 나옵니다. 이 축에서 볼 것은 줄어든 가중치가 어디로 가는가 입니다.
| 정밀도 | 가중치 | 24GB에서 KV 캐시에 쓸 수 있는 몫 (계산값) | 8K 요청 동시 (144KB/토큰 기준) |
|---|---|---|---|
| F16 | ≈ 16.4GB | ≈ 6GB | 약 5 |
| Q8_0 | ≈ 8.7GB | ≈ 14GB | 약 12 |
| Q4_K_M | ≈ 5GB | ≈ 17GB | 약 15 |
| (나머지 1.5GB 가정. 9차시 3.1과 같은 방식의 계산값) |
⭐ 문의봇처럼 동시 사용자가 있는 서비스 에서는 양자화의 진짜 이득이 "한 건이 빨라짐"보다 "같은 GPU에 더 많은 동시 요청이 들어감" 인 경우가 많습니다. 결과표의 메모리 칸 셋째 줄이 그것입니다.
4. 품질 — 블라인드 비교
4.1 왜 블라인드인가
채점자가 답안의 주인을 알면 채점이 흔들립니다. 자기가 쓴 답안을 자기가 채점하면 관대해지듯(README 9장 "품질 자가 채점"), 사람도 누구의 답안인지 알면 기대가 점수에 섞입니다. "이건 4bit니까 좀 떨어지겠지"를 알고 읽으면 실제보다 엄하게 , "FP16이니까"를 알면 관대하게 채점합니다.
| 출력 종류 | 채점 방법 | 블라인드가 필요한가 |
|---|---|---|
| 분류 | 정답 라벨과 자동 비교 | 자동이라 불필요 |
| 정보 추출 (주문번호 · 연락처) | 정답과 필드별 자동 비교 | 불필요. 단, 틀린 건은 사람이 원인 확인 |
| 요약 · 답변 초안 | 사람이 루브릭으로 | ⭐ 필요 |
4.2 절차 (AI에게 맡길 부분과 내가 할 부분)
| 단계 | 누가 | 내용 |
|---|---|---|
| 1 | AI | 정밀도별 출력을 모아 문의마다 순서를 섞고 A · B · C로 이름만 붙임 |
| 2 | AI | 정답 키(A=Q4 등)는 별도 파일 에 저장, 채점 시트에는 넣지 않음 |
| 3 | 나 | 루브릭(예: 핵심 누락 없음 / 사실 오류 없음 / 존댓말 · 맞춤법 / 길이 규칙)으로 채점 |
| 4 | AI | 채점 후 키를 합쳐 정밀도별 점수 집계 |
⚠️ AI(같은 모델이든 다른 모델이든)에게 채점까지 맡기면 README 9장의 "품질 자가 채점" 위험입니다. 보조 채점으로 쓰더라도 사람 채점과 어긋나는 건 을 직접 봅니다.
5. 결과 해석 — 문장 틀
숫자표만으로는 결정이 되지 않습니다. 16차시로 넘길 수 있게 문장으로 씁니다.
[정밀도]는 [기준 정밀도] 대비
- 메모리: 가중치 ___GB(−__%), 같은 GPU에서 8K 동시 요청 ___개 → ___개
- 속도: 생성 TPS ___배 (이론 상한 비율 ___배 중 ___% 실현), TTFT ___ (변화 거의 없음/증가)
- 품질: 분류 정확도 ___%p, 추출 오류 ___건 증가(유형: ________), 블라인드 점수 ___
따라서 [업무: 분류·추출 / 요약 / 초안]에는 [채택 / 조건부 채택 / 보류].
조건: ________ (예: 추출 결과는 형식 검증 후 사용, 29차시)
측정 조건: 조건 ID ___ (14차시 4.2 양식)
| ❌ 해석 | ⭕ 해석 |
|---|---|
| "Q4가 제일 좋네요" | "Q4는 TPS 약 ○배, 동시 수 ○배, 추출 오류 ○건 증가 → 분류에는 채택, 추출은 검증 조건부" |
| "품질 차이 없음" | "분류 정확도 차이 ○%p(평가셋 ○건 기준), 블라인드 점수 차이 ○ — 이 평가셋 범위에서 차이 작음" |
| "4bit는 3배 빠릅니다" | "이론 상한 비율 3.3배, 실측 ○배" |
6. 실습 — 맡기고 검수하기
지시
목표: Qwen3-8B의 F16, Q8_0, Q4_K_M을 같은 엔진(Ollama)에서 메모리·속도·품질 세 축으로 비교한다.
맥락: ollama.com의 qwen3 태그 목록에서 세 정밀도의 정확한 태그 이름을 먼저 확인해 인용해. 없으면 Hugging Face GGUF로 ollama create.
조건: 노트 15차시 1.1 고정 조건 표 그대로. 측정은 14차시 4절 규칙(워밍업 1회, 10회 반복, 중앙값/p95).
작업:
1. 각 정밀도마다 ollama ps의 PROCESSOR가 100% GPU인지 먼저 확인(아니면 중단하고 보고).
2. 측정용 프롬프트 3개로 TTFT, 생성 TPS 측정. nvidia-smi 기록.
3. 6차시 평가셋 전체 실행. 분류·추출은 정답과 자동 비교. 요약·초안은 순서를 섞어 A/B/C로 익명화한 채점 시트(csv)와 별도의 정답 키 파일을 만들어줘. 채점은 내가 함.
4. 이론 상한 = 1000 ÷ (모델 파일 GB)로 계산해 실측과 비율 표시.
보고 형식: 노트 15차시 1.2 결과표 양식. 품질 블라인드 칸은 비워 둠.
추측하지 말고 실행 명령, 원본 측정 로그, 자동 채점 결과 파일 경로를 붙여.
받을 증거
- 세 태그 이름과 출처, 정밀도별
ollama ps출력 (100% GPU 확인) - 원본 측정 로그,
nvidia-smi기록 - 자동 채점 결과 파일, 익명화된 채점 시트 와 분리된 정답 키 파일
내가 직접 볼 것
| 볼 것 | 이걸로 아는 것 |
|---|---|
| 세 정밀도 모두 100% GPU 인가 | 하나라도 분할이면 속도 비교 무효 (특히 F16에서 num_ctx가 클 때) |
| TPS 비율이 이론 상한 비율과 같은 방향 인가 | 메모리 병목 설명이 이 환경에서 맞는가. 상한을 넘는 값이 있으면 측정 오류 |
| TTFT 차이가 TPS 차이보다 작은가 | Prefill은 계산 병목 → 양자화 효과가 작음 |
| 추출에서 틀린 건의 유형 (숫자 한 자리, 하이픈 누락 등) | 10차시 5.3 "숫자 민감" — 정밀도 탓인지 프롬프트 탓인지 |
| 채점 시트에 모델 이름 단서가 없는가 | 블라인드가 실제로 지켜졌는가 |
부록 A. 스스로 확인하기
| # | 질문 | 답이 있는 곳 |
|---|---|---|
| 1 | 정밀도 비교에서 고정해야 할 것 여섯 가지는? 가장 흔한 설계 오류는? | 1.1 |
| 2 | 계산 병목과 메모리 병목을 유와 종차로 정의하면? | 2.1 |
| 3 | Prefill과 Decode는 각각 어느 병목이고, 양자화는 어느 쪽에 더 듣는가? | 2.1 |
| 4 | Decode 속도 이론 상한 공식은? 4090에서 F16 · Q4의 상한은? | 2.2 |
| 5 | 이론 상한을 실측 검수에 어떻게 쓰는가? | 2.2 |
| 6 | bitsandbytes 8bit가 이 설명의 예외인 이유는? | 2.3 |
| 7 | 동시 요청이 많아지면 양자화의 속도 이득이 왜 줄어드는 경향이 있나? | 2.3 |
| 8 | 동시 사용자가 있는 서비스에서 양자화의 진짜 이득은? | 3 |
| 9 | 어떤 출력에 블라인드 채점이 필요한가? 절차는? | 4 |
부록 B. 자주 하는 실수
| 실수 | 바로잡기 |
|---|---|
| FP16과 4bit를 다른 엔진 으로 재서 비교 | ❌ 엔진 차이가 섞임. 한 엔진 안에서 |
| 실측 TPS가 이론 상한보다 높게 나왔는데 그대로 보고 | ❌ 측정 오류 신호. 출력 길이 · 단위 · 캐시 확인 |
| "양자화하면 TTFT도 같이 줄어든다" | ⚠️ Prefill은 계산 병목. 효과가 작거나 없을 수 있음 |
메모리 병목이니 async로 해결 | ❌ GPU 칩 안의 기다림. 다른 축 |
| 모델 이름을 보고 요약 품질 채점 | ❌ 블라인드 |
| "빠르고 가벼우니 Q4 채택" (품질 칸 비어 있음) | ❌ 품질 축 없이 결정 불가 → 16차시 절차 |
부록 C. NotebookLM 복습 프롬프트
이 15차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"계산 병목 vs 메모리 병목", "Decode 이론 상한 계산", "bitsandbytes 8bit 예외", "블라인드 채점"은 반드시 포함하고 계산 문제 1개를 넣어줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.