로컬 LLM

지도 위치 : 2일차 · ②모델 파일 층 × ③추론 엔진(Transformers) | 이전: 10차시 LLM 양자화 원리 | 다음: 12차시 GGUF와 경량 LLM 키워드 : BitsAndBytes, 8bit · 4bit 모델 로딩, GPU 메모리 사용량 비교

이 차시를 다 읽으면

1. BitsAndBytesConfig 코드에서 8bit인지 4bit인지, 계산은 어떤 정밀도로 하는지 를 알아볼 수 있다.
2. GPU 메모리를 재는 세 가지 도구 가 왜 서로 다른 숫자를 내는지 말할 수 있다.
3. FP16 · 8bit · 4bit 비교표를 같은 조건 에서 채우도록 AI에게 맡기고, 결과를 검수할 수 있다.
4. bitsandbytes 8bit가 메모리는 줄었는데 더 느릴 수 있는 이유를 말할 수 있다.
5. 메모리 숫자만으로 결정하지 않고 평가셋 결과 칸 까지 채워야 하는 이유를 말할 수 있다.

---

0. 이 차시의 판별 축

앞에서 이어집니다 — 10차시 4절 지도에서 bitsandbytes는 "로딩할 때 즉석으로" 칸에 있었습니다. 원본 FP16 파일 하나만 있으면 설정 한 줄로 8bit · 4bit를 바꿔 가며 올릴 수 있어서 비교 실험에 가장 편한 도구 입니다. 10차시 1.2의 QLoRA도 이 라이브러리로 원래 가중치를 4비트(NF4)로 줄여 올려 둡니다.

---

1. bitsandbytes — 무엇이고 어디에 쓰는가

bitsandbytes — [양자화 라이브러리]인데, [ 원본 가중치 파일을 읽어 GPU에 올리는 순간 8bit · 4bit로 바꾼다 ]는 점에서 미리 양자화된 파일을 배포하는 GPTQ · AWQ · GGUF와 구별된다.

⚠️ 반례 — bitsandbytes는 서빙 성능용 도구가 아닙니다. 이 차시의 목적은 "같은 모델을 정밀도만 바꿔 보면 메모리 · 속도 · 품질이 어떻게 변하는가"를 눈으로 확인하는 것 이고, 운영 설정은 12차시(GGUF)와 3일차(vLLM)에서 고릅니다.

---

2. 코드 — 세 가지 로딩

AI가 짜 줄 코드는 대략 이런 모양입니다. 다 읽을 필요 없습니다. 🔍 표시만 봅니다.

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig

MODEL = "Qwen/Qwen3-8B"
tok = AutoTokenizer.from_pretrained(MODEL)

# (A) FP16/BF16 — 기준선
model = AutoModelForCausalLM.from_pretrained(
    MODEL, torch_dtype=torch.bfloat16, device_map="auto")

# (B) 8bit
cfg8 = BitsAndBytesConfig(load_in_8bit=True)
model = AutoModelForCausalLM.from_pretrained(
    MODEL, quantization_config=cfg8, device_map="auto")

# (C) 4bit
cfg4 = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True)
model = AutoModelForCausalLM.from_pretrained(
    MODEL, quantization_config=cfg4, device_map="auto")

🔍 읽는 포인트

⚠️ device_map="auto"는 편하지만, FP16이 VRAM에 안 들어갈 때 에러 없이 CPU로 일부를 넘겨 비교를 망칩니다. 결과를 받을 때 model.hf_device_map에 cpu나 disk가 있는지 확인하게 하세요.

💡 옵션 이름은 transformers와 bitsandbytes 버전에 따라 바뀔 수 있습니다. 설치된 버전과 공식 문서(Transformers의 bitsandbytes 양자화 페이지)를 맥락으로 주세요.

---

3. ⭐ 메모리를 재는 세 가지 도구

3.1 도구별로 무엇을 재는가

nvidia-smi memory.used  ─────────────────────────────────────────────── (가장 큼)
 ├─ CUDA 컨텍스트 (라이브러리 적재분)              ← 프로그램 안에서는 안 보임
 └─ PyTorch가 확보한 메모리 (reserved)
     └─ 실제로 텐서에 쓰인 최대치 max_memory_allocated
         ├─ 가중치 ≈ get_memory_footprint()          (가장 작음)
         └─ KV 캐시 · 활성값 (생성 중에만)

⭐ 셋은 다른 질문에 대한 답 이라 숫자가 달라야 정상입니다. 같은 도구, 같은 시점끼리만 비교합니다. 9차시 4.2의 원칙 그대로입니다.

3.2 측정 절차 (AI에게 넘길 규칙)

---

4. 비교표 — 직접 채울 표

⚠️ 아래 표의 숫자 칸은 비워 둡니다. 실측값은 여러분 환경에서 채웁니다. 오른쪽 "예상 방향"은 원리(9 · 10차시)에서 나온 방향 일 뿐 측정값이 아닙니다.

4.1 ⚠️ 8bit가 FP16보다 느릴 수 있다

⭐ 그래서 이 표의 결론은 대개 이렇게 씁니다. "bitsandbytes는 이 GPU에 원래 안 들어가는 모델을 올리거나, QLoRA로 학습할 때 쓴다. 속도가 목적이면 12차시(GGUF) · 3일차(vLLM + AWQ/FP8) 의 사전 양자화 방식을 잰다." 15차시에서 이 비교를 GGUF까지 넓힙니다.

4.2 문의봇에 대입하기

24GB GPU에서 Qwen3-8B는 FP16으로도 들어갑니다(9차시 3.1). 그러면 이 실습의 질문은 "들어가느냐"가 아니라 이것입니다.

---

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

지시

목표: Qwen/Qwen3-8B를 Transformers + bitsandbytes로 BF16, 8bit, 4bit(NF4) 세 가지로 로딩해 비교한다.
맥락: 설치된 transformers, bitsandbytes, torch 버전을 먼저 출력하고, Transformers 공식 문서의
      bitsandbytes 페이지 기준으로 코드를 작성해. 3일차 vLLM과 섞이지 않게 이 실습 전용 가상환경을 써.
제약:
 - 정밀도마다 별도 프로세스로 실행. 생성 전 reset_peak_memory_stats() 호출.
 - 프롬프트 3개(내가 준 문의 예시), max_new_tokens=200, do_sample=False 고정. 워밍업 1회 후 3회 반복.
 - 로딩 후 model.hf_device_map을 출력하고, cpu나 disk가 있으면 그 결과는 무효로 표시.
 - 6차시 평가셋(문의 N건)으로 분류값과 주문번호 추출 결과를 정밀도별로 저장(채점은 내가 함).
보고 형식:
| 정밀도 | footprint(GB) | max_allocated(GB) | nvidia-smi used(GB) | 로딩(초) | 토큰/초(중앙값) | device_map 이상 |
그리고 평가셋 결과 파일 경로.
추측하지 말고 실행한 코드와 출력 원문을 붙여.

💡 가상환경 — [Python 실행 환경]인데, [ 프로젝트마다 설치한 패키지 묶음을 따로 둔다 ]는 점에서 컴퓨터 전체가 하나의 패키지 묶음을 같이 쓰는 기본 환경과 구별된다. bitsandbytes 실습용 transformers 버전과 3일차 vLLM이 요구하는 버전이 서로 부딪히지 않게 하려고 나눕니다.

받을 증거

• 버전 출력, 실행한 코드 파일, 정밀도별 출력 원문
• hf_device_map 출력
• 평가셋 결과 파일 (정밀도별로 분리된 것)

내가 직접 볼 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 11차시 노트만 근거로 5문제를 내줘. 비전공자 기준으로.
"bnb_4bit_compute_dtype의 의미", "메모리 측정 도구 세 가지의 차이", "8bit가 느릴 수 있는 이유"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.