📚 오늘 배운 내용 (LLM 후반부 + 생성형 AI)
오늘은 크게 두 파트다.
- LLM 후반부 — 거대 모델을 내 손으로 파인튜닝하고, 메모리를 아껴가며 돌리는 기술 (PEFT / LoRA / QLoRA / 양자화 / BF16)
- 생성형 AI (Generative AI) — 텍스트를 넘어 이미지·비디오·음악·3D를 만드는 기술, 그리고 이 모델들을 실제로 배포·구동하는 방법 (GGUF / llama.cpp / 추론 엔진)
핵심 실습은 "범용 지시어 챗봇 → 법률 전문가 챗봇" 으로 진화시키는 파인튜닝, 그리고 Naruto 스타일 캐릭터 생성 LoRA
PART 1. LLM 후반부 — 파인튜닝과 경량화
1. 실습 개요 : 한국어 질의응답 챗봇 파인튜닝
KoAlpaca 데이터셋을 활용해 기초적인 한국어 지시 이행 능력(instruction following) 을 강화하는 실습. 전체 파이프라인은 4단계(Phase)로 구성된다.
| Phase | 단계 | 내용 |
|---|---|---|
| Phase 1 | 데이터 준비 | KoAlpaca 52k 데이터셋 (네이버 지식인 베스트 질문 기반) |
| Phase 2 | 모델 경량화 | 4-bit 양자화 (메모리 절약을 위한 필수 과정) |
| Phase 3 | 학습 진행 | SFTTrainer 지도 학습 (LoRA 기법으로 효율적인 미세조정) |
| Phase 4 | 성능 평가 | 추론 및 정량 평가 (실제 샘플로 성능 개선 확인) |
이 4단계 흐름 = 데이터 → 경량화 → 학습 → 평가 가 파인튜닝의 기본 골격이다.
2. Alpaca 데이터셋 구조
파인튜닝 데이터의 기본 단위는 세 가지 필드로 이루어진다.
- Instruction (명령어) : 모델이 수행해야 할 작업에 대한 명확한 설명
- 예) "다음 기사를 요약해 줘."
- Input (입력값) : 작업 수행을 위한 선택적 문맥이나 데이터
- 예) 기사 본문 내용 (전체의 약 40%에만 포함됨 — 없을 수도 있다)
- Output (출력값) :
text-davinci-003이 생성한 이상적이고 정확한 답변 (정답 라벨)
💡 Input은 항상 있는 게 아니라 전체 데이터의 약 40% 에만 존재한다는 점이 포인트.
3. KoAlpaca 데이터셋은 어떻게 만들어졌나
영어 Alpaca를 한국어로 바꾸는 파이프라인:
스탠포드 Alpaca 52K 데이터
│ DeepL API (번역)
▼
한국어 Instruction & Input 확보 (오류 데이터 필터링)
│ ChatGPT (gpt-3.5-turbo)
▼
새로운 한국어 Output 생성- Instruction / Input → DeepL API로 번역 + 오류 데이터 필터링
- Output → 번역이 아니라
gpt-3.5-turbo로 한국어 답변을 새로 생성
즉 질문은 번역하고, 답변은 새로 생성하는 방식.
4. PEFT (Parameter Efficient Fine Tuning)
"파라미터를 효율적으로 미세조정한다" 는 개념. 기존 방식(Full Fine-tuning)과 비교하면 차이가 명확하다.
| 구분 | 기존 방식의 문제점 | PEFT (파라미터 효율적 파인튜닝) |
|---|---|---|
| 자원 | 엄청난 컴퓨팅 자원 | 1% 미만의 파라미터만 학습 |
| 저장 | 막대한 저장 공간 | 비용 절감 및 접근성 향상 |
| 성능 | 치명적 망각(Catastrophic Forgetting) | 가볍고 빠른 공유 |
Catastrophic Forgetting(치명적 망각) : 전체를 다시 학습시키면 기존에 알던 지식을 잊어버리는 현상. PEFT는 원본을 건드리지 않아 이 문제에서 자유롭다.
5. Hugging Face 3대 라이브러리
파인튜닝은 아래 세 라이브러리가 한 팀으로 움직인다.
- Transformers : 베이스 LLM 모델과 텍스트 토크나이저 준비
- PEFT : 무거운 베이스 모델을 동결(Freeze) 하고 가벼운 LoRA 어댑터 장착 (VRAM 세이브)
- TRL (SFTTrainer) : 데이터를 예쁘게 포맷팅/패킹하고 최적의 학습 루프(Train Loop) 실행
6. VRAM 아껴쓰기 — 4-bit 양자화 & LoRA
메모리를 아끼는 두 축:
- 4-bit 양자화 (BitsAndBytes) : "무거운 책 1만 권을 압축팩에 넣기" → 메모리 최적화
- LoRA (r=8, alpha=16) : "모든 페이지를 외우는 대신, 핵심 요약본만 덧붙여 학습" → 파라미터 효율적 미세조정
핵심 비유 : "책 전체를 다시 쓰지 마세요. 요약 노트(LoRA)만 끼워 넣으세요!"
- LoRA (Low-Rank Adaptation) : 트랜스포머 아키텍처 내 특정 레이어(Adapter)만 추가하여 가볍게 학습하는 PEFT의 표준 기술
- QLoRA (Quantized LoRA) : 모델의 정밀도를 낮춰(양자화, Quantization) 메모리를 극단적으로 절약하는 방법. 단일 GPU 학습의 일등공신
- PEFT 확장 패밀리 :
DoRA,Adapter Layers,BitFit,IA3등 최신 기술들도 모두 '효율적 파인튜닝' 철학을 공유한다.
7. 4-bit 양자화가 "가능한" 이유
정밀도를 4-bit까지 깎아도 모델이 동작하는 3가지 근거:
- 가중치는 "정확한 값"보다 "방향성"이 중요
수천 개의 Weight가 합쳐져 만드는 거대한 흐름이 중요하다. 개별 Weight 하나의 미세한 오차는 전체 방향성에 거의 영향을 주지 않는다. - Attention은 "상대적 크기"가 핵심
"누가 제일 크냐?", "어디에 집중할 것이냐?"가 중요하지 절대값이 중요하지 않다. LLM의 Attention 메커니즘은 절대값의 미세한 손실에 비교적 둔감하다. - 애초에 노이즈에 강하게 태어난 구조
LLM 기본 아키텍처 자체가 이미 노이즈를 견디도록 설계됨 →Dropout,LayerNorm,Residual connection.
8. ⚠️ 양자화가 "독"이 되는 5가지 순간
반대로, 4-bit 양자화를 하면 안 되는 경우들.
1) 수치 정확도가 생명인 작업 (수학/코드 생성)
- FP16:
1.0000000001(정밀도 유지) vs 4-bit:1.0(깎여나간 미세 수치) - 말은 그럴듯하게 하지만 틀린 답을 뱉어낸다.
- 적용 불가 분야: 수학 증명, 계산기 역할, 긴 로직의 코드 생성, 과학 시뮬레이션
2) Embedding 공간의 붕괴
- FP16 공간의 규칙적 격자가 4-bit 압축 공간에서는 뭉개진다.
- 👉 임베딩 모델은 반드시 FP16 또는 INT8을 사용할 것.
3 & 4) 새로운 기초공사 & 눈덩이 오차
- Base Tuning : 완전히 새로운 언어나 수학/논리를 가르칠 때는 '페인트칠(LoRA+4bit)'이 아닌 '기초 공사(Full Fine-tuning)' 가 필요.
- Long-context : 32k, 64k 이상의 초장문 컨텍스트에서는 Attention 누적 오차가 발생.
5) 프로덕션 환경의 최종 상용 모델 배포
- 아주 중요한 서비스의 최종 서빙에는 FP16 / BF16이 훨씬 안전하다.
- 위험 요소: 디버깅의 어려움, 재현성 부족, 장기적 안정성 리스크
9. Floating Point (부동소수점) 기초
숫자를 컴퓨터가 저장하는 방식. 두 부분으로 나뉜다.
- 지수 (Exponent) : 소수점을 몇 칸 옮길까? → 숫자의 거대한 크기(범위) 를 결정 (예:
10³) - 가수 (Fraction) : 얼마나 촘촘하게 나눌까? → 숫자의 유효숫자(정밀도)를 결정 (예:
$1.2345)
💡 정규화(Normalization)의 비밀 : 소수점 앞을 무조건 '1'이 되도록 맞춰서 그 '1'은 아예 메모리에 저장하지 않는다. 덕분에 정밀도에 1칸을 더 쓸 수 있다.
10. 크기별 Floating 구조 (FP32 / FP16 / BF16)
| 포맷 | 부호 | 지수 | 가수 | 특징 |
|---|---|---|---|---|
| FP32 (Reference) | 1칸 | 8칸 | 23칸 | 표준 규격 (기준점) |
| FP16 (Precision Focus) | 1칸 | 5칸 | 10칸 | "좁은 범위라도 엄청 정밀하게" (지수부가 작아 범위가 좁음) |
| BF16 (Range Focus) | 1칸 | 8칸 | 7칸 | "정밀도는 양보해도 FP32처럼 큰 숫자까지 다 품어" |
BF16은 FP32에서 가수부 꼬리만 툭 잘라낸 형태라 변환 작업이 매우 빠르고 호환성이 뛰어나다.
11. 왜 LLM 학습에는 BF16이 표준이 되었을까?
- FP16의 한계 : 표현 가능한 최대 숫자가
65,504에 불과. 학습 중 수치가 갑자기 커지면(Exploding) 에러(NaN)가 발생해 학습이 망가진다. - BF16의 안정성 : 계산 결과가 태양계 거리만큼($10³⁸) 커져도 끄떡없다.
핵심 : AI는
1.234나1.235나 대충(1.2) 알아도 똑똑하다. 하지만 에러(NaN)가 나면 즉시 학습이 죽는다. → 그래서 정밀도(가수)보다 범위(지수)가 넓은 BF16이 유리.
언제 무엇을 써야 할까?
| BF16 선택 | FP16 선택 |
|---|---|
| 모델 학습(Training) 중일 때 | 이미 학습된 모델을 서비스(Inference) 할 때 |
| NVIDIA Ampere 아키텍처 (A100, RTX 30/40 시리즈 이상) 또는 Google TPU | V100, RTX 20 시리즈 등 구형 GPU 환경 |
| → 주저 없이 BF16 (최신 LLM 트렌드) | → FP16으로 가볍고 빠르게 (구형에서 BF16은 느릴 수 있음) |
12. TRL이 제공하는 기능 (강화학습 흐름)
SFTTrainer → Reward Modeling → PPO & DPO- SFTTrainer ("정해진 정답 외우기")
여러 짧은 문장을 하나로 묶어(Packing) GPU 연산 효율 극대화, 기초적인 방향을 잡는다. - Reward Modeling ("어떤 대답이 더 훌륭한지 채점하기")
인간이 선호하는 답변에 더 높은 점수를 주도록 '채점관 모델'을 학습시킨다. - PPO & DPO ("본격적인 강화학습")
채점관의 기준에 맞춰 본 모델을 최적화하여 판단력을 기른다.
13. 실습 2 : 법률 전문가 챗봇으로 진화하기 (도메인 특화)
한국 민사법 도메인 데이터(legal-qa-1k)를 주입하여 전문가 수준의 응답 + 법률 개체 추출 능력을 확보하는 실습.
- Base Model :
Llama 3.2(Bllossom/llama-3.2-Korean...) + AI Hub 민사법 데이터
평가 지표 3가지
- ROUGE Score : 텍스트가 정답과 얼마나 겹치는지 평가 (단어 및 문장 구조의 유사성)
- F1 Score : 정답 토큰 포함 여부와 불필요 토큰 생성의 조화평균
- 법률 용어 정밀도 (Legal Precision) : 법원명, 사건번호, 법령명 등 도메인 특화 핵심 정보가 정확히 일치하는지 타겟 평가
🎯 도메인 파인튜닝의 핵심은 단순한 말하기가 아닌, 전문 용어의 정확성(Precision)을 증명하는 것.
PART 2. 생성형 AI (Generative AI)
14. 실습 환경 세팅
파이썬 가상환경부터 이미지·비디오·음악·3D 객체 생성까지 한 번에 끝내는 실습 로드맵.
# 1. 패키지 설치 (가상환경 생성)
conda env create -f generative_ai.yaml -n generative_ai
# 2. 가상 환경 연동 (활성화 후 VSCode 커널 연결)
conda activate generative_ai15. Generative AI 실습 로드맵 (4대 도메인)
- 이미지 생성 (Image Generation) — T2I, I2I, Fine-Tuning
- 비디오 생성 (Video Generation) — Image-to-Video
- 음악 생성 (Music Generation) — Text-to-Music
- 3D 객체 생성 (3D Object Generation) — Text/Image-to-3D
16. Stable Diffusion 프로세스
이미지 생성의 4단계 흐름:
1. 입력(Input) → 마구잡이 노이즈 (대리석 블록)
2. 텍스트 임베딩(CLIP) → 텍스트를 AI의 언어로 변환
3. 노이즈 제거(U-Net) → 스케줄러를 통해 노이즈를 깎아내며 밑그림 정제
4. 픽셀 변환(VAE Decoder) → 잠재 공간의 밑그림을 고해상도 픽셀 이미지로 복원Stable Diffusion = 3개 모델의 팀플레이
Stable Diffusion은 단일 모델이 아니라 3개의 모델이 한 팀으로 움직인다.
| 모델 | 파라미터 | 역할 |
|---|---|---|
| CLIP Text Encoder | 123M | 텍스트 이해 (눈/귀) |
| UNet | 860M | 메인 두뇌 (이미지 생성) |
| VAE | 83M | 이미지 압축 및 복원기 |
이 모든 가중치(Weights)를 합치면 시작점부터 이미 2GB를 훌쩍 넘기며 VRAM의 절반을 차지한다.
17. Video Generation (Stable Video Diffusion)
정적 이미지에 시간을 더하다.
- 핵심 기술 : 3D U-Net
- 3D U-Net은 공간(이미지)뿐만 아니라 시간(프레임 간 일관성) 까지 동시에 예측하여 자연스러운 움직임을 만든다. (플립북에 시간 축 Temporal Axis를 더하는 개념)
18. Music Generation (MetaAI MusicGen)
텍스트가 멜로디가 되는 마법.
입력: "90s rock song"
→ T5 Encoder (텍스트 블록)
→ Transformer (오디오 토큰 예측)
→ EnCodec (음악 파형 변환)
→ 🎵오디오 파형을 직접 그리는 대신, 소리를 '단어'처럼 쪼개서(토큰화) 문장을 쓰듯 작곡한다.
MusicGen 모델별 사양
| 모델 명칭 | 파라미터 규모 | 권장 VRAM | 지원 기능 |
|---|---|---|---|
| musicgen-small | 300M | 8GB 이상 (실습 추천!) | 텍스트 기반 작곡 |
| musicgen-medium | 1.5B | 16GB 이상 | 텍스트 기반 작곡 |
| musicgen-melody | 1.5B | 16GB 이상 | 텍스트 + 멜로디 조건 |
| musicgen-large | 3.3B | 16GB 이상 (A100) | 텍스트 기반 작곡 |
예시 프롬프트: "ambient electronic music with a calm piano melody and soft synth pads" (잔잔한 피아노 선율과 부드러운 신스 패드가 깔린 앰비언트 음악)
19. 3D Object Generation (Point-E)
평면을 넘어 입체 공간으로.
3단계 파이프라인
- 텍스트 → 2D 이미지 생성 (GLIDE 모델)
- 이미지 → 3D 포인트 클라우드 (Diffusion 모델로 1,024개 초기 샘플 생성)
- 업샘플링 (해상도 향상, 4,096개 포인트로 디테일 시각화)
💡 텍스트를 직접 3D로 변환하는 대신, '이미지'를 중간 다리로 거쳐 더 빠르고 정확하게 3D 구조를 이해한다.
2D Pixel vs 3D Point Cloud
| 구분 | 2D Pixel | 3D Point Cloud |
|---|---|---|
| 데이터 구조 | 행렬 기반의 격자 (Grid) | XYZ 좌표 기반의 산점도 (Coordinates) |
| 표현 요소 | 면을 채우는 픽셀 (Pixel) | 공간을 정의하는 점 (Point) |
| 특징 | 연산이 빠르고 직관적 | 빈 공간을 효율적으로 표현 가능, AI 3D 생성의 뼈대 역할 |
Point-E의 2 Stage 구조
- Stage 1: Base Model (base40M) — 전체적인 윤곽과 형태를 빠르게 잡아냄
- Stage 2: Upsampler Model (upsample) — 기본 뼈대 위에 3,072개의 점을 추가하여 해상도와 디테일 극대화
num_points = [1024, 4096 - 1024]
20. 나만의 캐릭터 학습시키기 (LoRA 실습)
문제 상황: "기존 모델에 특정 애니메이션 스타일만 딱 추가하고 싶은데, 처음부터 다시 학습시키는 건 너무 무겁고 느리다..."
→ 정답은 파이프라인 최적화와 LoRA에 있다.
- 학습 데이터셋 :
lambdalabs/naruto-blip-captions(10장으로 축소 실습) - 거대한 모델(Stable Diffusion U-Net) 전체를 다시 공부하지 않고, 핵심 특징만 담은 '가벼운 커닝페이퍼(LoRA)' 의 파라미터만 업데이트 → 메모리와 시간을 압도적으로 절약.
LoRA 학습 파이프라인 (3 Stage)
- Stage 1 — Dataset Load : HuggingFace
Milabench/naruto-blip-captions로드 (총 1,221개 이미지) - Stage 2 — Preprocessing : 512x512 사이즈 Resize → RGB 변환 → 텐서 변환 및
[-1, 1]정규화(Normalize) - Stage 3 — Trigger Word Magic : 기존 캡션 맨 앞에 트리거 키워드
naruto character,를 강제 삽입- 원본:
a man with dark hair and brown eyes - 가공 후:
naruto character, a man with dark hair and brown eyes
- 원본:
이미지 생성 모델 평가 지표
| 지표 | 방향 | 의미 |
|---|---|---|
| FID Score | 낮을수록 좋음 ↓ | 원본 데이터 분포 vs 생성 이미지 분포 차이 측정 (얼마나 고품질이고 자연스러운가?) |
| CLIP Score | 높을수록 좋음 ↑ | 텍스트 프롬프트와 생성 이미지 간의 의미적 유사도 (프롬프트의 말귀를 얼마나 잘 알아들었는가?) |
결과: 단 1,221장의 데이터와 짧은 학습만으로 캐릭터 스타일을 완벽하게 이식했다.
(예: "naruto character, Bill Gates with a hoodie", "John Oliver with Naruto style", "Hello Kitty with Naruto style")
PART 3. 모델 배포 & 온디바이스 — 양자화와 GGUF 생태계
21. 과제 : 하드웨어의 한계 (RAM)
- 모델이 배포될 때의 기본 정밀도는 32-bit 또는 16-bit.
- 높은 정확도를 자랑하지만, 이를 저장하고 실행하려면 일반 노트북이 감당할 수 없는 엄청난 용량의 RAM이 필요하다.
- 👉 그래서 양자화(Quantization) 가 필요하다.
22. Post-Training Quantization (PTQ)
학습이 끝난 모델을 사후에 압축하는 방식.
Float16 (16-bit) 원석 → PTQ 가공 → Int4 (4-bit) 압축.
🔍 모델 이름 해독하기 : DeepSeek-Q4_K_M.gguf
| 토큰 | 의미 |
|---|---|
| Q (Quantized) | 양자화된 모델임을 의미 |
| 4 (4-bit) | 4비트 정밀도로 압축됨 (메모리 최적화) |
| K | Variant — 품질과 성능의 균형을 맞춘 특정 압축 알고리즘 (K-Quants) |
| M | Medium 사이즈 (S / M / L) |
| .gguf | 포맷 — Llama.cpp 전용 단일 패키지 파일 |
23. 양자화 알고리즘의 3세대 진화 (Evolution Timeline)
| 세대 | 이름 | 특징 |
|---|---|---|
| 1세대 | Legacy Quants | 기본 선형 양자화(Linear Quantization), Q4_0, Q4_1 등 숫자(0,1)로 끝나는 명칭 |
| 2세대 | K-Quants | 이중 양자화 및 메모리 접근 최적화, Q4_K 등 명칭에 'K' 포함 |
| 3세대 | I-Quants | 벡터 양자화(Vector Quantization), IQ4_NL, IQ3_S 등 명칭에 'IQ' 포함 |
Mixed Precision (혼합 정밀도)
같은 4-bit라도 어떤 레이어를 더 정밀하게 남기느냐에 따라 파일 크기가 달라진다.
| Variant | 구성 | 파일 크기 |
|---|---|---|
| Q4_S | Int4 위주 + 일부 Q5 | 가장 작음 |
| Q4_M | Int4 + Q6 혼합 | 중간 (균형) |
| Q4_L | Int4 + Q6 + Q8 혼합 | 가장 큼 (고품질) |
unsloth: 양자화 작업을 거친 모델을 (편하게) 제공하는 도구.
24. 해결책 : 궁극의 도시락, GGUF 포맷
모델 가중치(Weights) + 메타데이터(Metadata) = 단일 GGUF 파일양자화된 모델을 하나의 파일로 깔끔하게 패키징한 포맷.
양자화 포맷 3대장 비교
| 포맷 | 캐릭터 | 핵심 |
|---|---|---|
| GGUF | CPU 중심의 온디바이스 생존자 | 어디서든 돌아감 |
| GPTQ | GPU 가속을 위한 1세대 표준 | GPU 추론 최고 속도 |
| AWQ | 중요 가중치만 보호하는 차세대 최적화 | 중요 1% 보존 |
25. 세 포맷 상세
🚙 GGUF : 어디서든 돌아가는 하이브리드 오프로더
- C++ 기반의 CTransformers 패키지 사용 (구 GGML)
- 특징 : CPU를 주력으로 사용하며, 작은 GPU가 있다면 일부 레이어를 GPU로 넘기는 오프로딩(GPU Layers Offloading) 가능
- 조건 : GPU가 아예 없거나 초소형인 노트북 환경에 완벽
🏎️ GPTQ : GPU를 위한 스피드 레이서
- Post-training 양자화 방식 사용
- 특징 : 오직 GPU 추론(Inference) 성능에 집중하여 가장 빠른 속도
- 조건 : 모델을 담을 수 있는 최소한의 GPU VRAM이 필수
🥇 AWQ : 중요한 1%를 보호하는 VIP 전략
- 활성화(Activation) 과정에서 유독 중요한 역할을 하는 핵심 가중치(Salient Weights)를 찾아냄
- 99%는 양자화하여 가볍게 만들고, 성능에 치명적인 1%의 가중치는 건드리지 않고 원본을 유지
26. GGUF 생태계 : 쌓아 올려진 기술 스택
GGUF (파일 포맷)
│
Llama.cpp (추론 엔진)
│
GGML (기반 라이브러리)- GGUF (파일 포맷) : 양자화된 가중치와 모델 메타데이터를 모두 담은 범용 바이너리 파일 포맷 (Georgi Gerganov 개발)
- Llama.cpp (추론 엔진) : GGML 위에서 동작하며, 로컬 환경에서 LLM을 로드하고 실행하는 핵심 엔진. 양자화 도구 포함
- GGML (기반 라이브러리) : C/C++로 작성된 초경량 고성능 텐서 연산 라이브러리 (PyTorch의 가벼운 대안)
온디바이스 AI의 근본, llama.cpp
- 순수 C/C++ (Dependency-free) : 복잡한 파이썬 의존성 제로! 가벼운 실행 파일 하나로 LLM 즉시 구동
- 고성능 CPU 최적화 : 비싼 외장 GPU 없이 일반 RAM만으로 부드럽게. 특히 애플 실리콘(M1~M4)의 통합 메모리(Unified Memory) 아키텍처를 완벽 활용
- 압도적인 속도 : 7B, 13B 파라미터 모델도 초당 수십 토큰으로 쾌적 ("하지만 빨랐죠")
27. 추론 엔진 카테고리
| 용도 | 대표 엔진 | 특징 |
|---|---|---|
| 고성능 GPU 서버 (기업용) | vLLM, TensorRT-LLM | 동시 요청 시 GPU 효율과 처리량 극대화 |
| 파이썬 연구용 | ExLlamaV2, TGI | 허깅페이스 생태계와 완벽한 호환성, 빠른 테스트 |
| 일반/초보자용 GUI | Ollama, LM Studio | 코드 없이 클릭 한 번으로 로컬 구동 (llama.cpp 백엔드) |
28. VRAM이 부족하다고요? RAM을 빌려 쓰면 됩니다
- 일반적인 GPU 환경에서는 VRAM에 안 들어가면 LLM이 깨진다(❌).
- GGUF의 GPU Offloading : VRAM에 다 못 넣으면 나머지를 System RAM으로 넘겨서 처리.
- GGUF는 CPU 연산에 최적화되어 있어, 맥북(Apple Silicon)이나 일반 PC 환경에서도 모델을 영리하게 끌어와 끝까지 구동한다.
내 RAM으로 어느 정도 모델이 좋을까?
| RAM | 환경 | 추천 모델 |
|---|---|---|
| 8GB | 노트북/모바일 기본 | Phi-4-mini (3.8B), Gemma 3 (4B), Qwen 3 (4B), Llama 3.2 (3B) |
| 16GB ~ 32GB | 고급 랩탑/워크스테이션 | Qwen 3 (14B), Gemma 4 (26B MoE) |
| 64GB+ | 로컬 서버급 | Qwen2.5-Coder (32B), DeepSeek R1 distill (70B) |
✅ 오늘의 핵심 요약
- 파인튜닝 4단계 = 데이터 준비 → 경량화(4-bit) → 학습(LoRA/SFT) → 평가
- PEFT / LoRA / QLoRA : 전체 모델 대신 1% 미만의 파라미터(어댑터)만 학습해 VRAM·시간을 절약
- 4-bit 양자화는 "방향성·상대적 크기·노이즈 내성" 덕분에 가능하지만, 수학/코드/임베딩/장문/최종 배포에는 독이 될 수 있다
- BF16 : 정밀도(가수)를 조금 포기하고 범위(지수)를 넓혀 학습 중 NaN을 막는다 → LLM 학습 표준
- 생성형 AI : Stable Diffusion(CLIP+UNet+VAE), Video(3D U-Net), Music(MusicGen), 3D(Point-E)
- 배포/온디바이스 : 양자화(PTQ) → GGUF 포맷 → llama.cpp/GGML 생태계 → RAM 오프로딩으로 어디서든 구동
💬 오늘의 한 줄 : "거대 모델을 통째로 다시 쓰지 말고, 요약 노트(LoRA)만 끼워 넣고 압축팩(양자화)에 넣어 도시락(GGUF)으로 싸 들고 다니자."
뭘봐