"ML 기초 학습 (9/9) — PyTorch vs TensorFlow, 그리고 로컬 LLM"

마지막 편이다. 지금까지 모델 자체를 다뤘다면, 이번엔 그 모델을 실제로 돌리는 도구를 본다. PyTorch와 TensorFlow의 설계 철학 차이가 무엇인지, 그리고 Hugging Face transformers·llama.cpp·MLX·Ollama가 어떻게 로컬에서 LLM을 돌리는 다리를 만들었는지 정리한다. 시리즈를 마치면 "사전 학습 모델 하나를 자기 기기에서 띄워 보는" 전체 흐름이 손에 잡힌다.


0. 학습 목표

  • PyTorch와 TensorFlow의 eager vs graph 차이를 설명한다.
  • autograd가 어떻게 backward pass를 자동화하는지 그래프 관점에서 설명한다.
  • Hugging Face transformersAutoModel / AutoTokenizer / pipeline 추상화를 안다.
  • llama.cpp의 GGUF 양자화·INT4·CPU 추론 흐름을 안다.
  • Apple MLX의 unified memory 활용과 PyTorch와의 차이를 안다.
  • Ollama로 로컬에서 LLM을 띄워 OpenAI 호환 API로 호출할 수 있다.

1. 핵심 요약

  • PyTorch: 기본이 eager. 매 줄이 즉시 실행되고 autograd가 동적 그래프를 만든다. 연구·NLP·LLM 학계 표준.
  • TensorFlow 2: tf.function으로 자동 graph 컴파일. 프로덕션·모바일·임베디드 강점.
  • Hugging Face transformers: 사전 학습 모델을 한 줄로 로드하고 추론한다. 사실상 모든 오픈 LLM의 진입점.
  • llama.cpp: C++로 작성된 LLM 추론 엔진. GGUF 양자화로 INT4 같은 저비트 추론. Mac·Windows·Linux에서 CPU/GPU 모두.
  • MLX (Apple): Mac unified memory를 살린 ML 프레임워크. Apple Silicon에서 빠르고 메모리 효율적.
  • Ollama: llama.cpp 기반의 데스크탑 도구. ollama run llama3로 모델 다운로드·실행·OpenAI 호환 API 노출.

2. 직관 — eager와 graph는 무엇이 다른가

2.1 두 가지 실행 모델

x = torch.tensor([1.0, 2.0])
y = x * 2
print(y)                 # 즉시 [2.0, 4.0]

@tf.function
def f(x):
    return x * 2
y = f(tf.constant([1.0, 2.0]))  # 첫 호출 시 트레이싱 후 컴파일된 그래프

eager는 각 줄이 즉시 실행된다. 디버깅이 자연스럽다. 단점은 컴파일러가 전체 그래프를 못 봐 최적화 폭이 좁다.

graph는 한 번 계산 그래프를 빌드한 뒤 컴파일러 (XLA 등) 가 통째로 최적화한다. 빠르지만 디버깅이 어렵고 동적 분기에 약하다.

요즘은 두 진영 모두 eager로 작성하고 부분적으로 graph 컴파일하는 방식으로 수렴 중이다. PyTorch의 torch.compile, TensorFlow의 @tf.function.

2.2 왜 학계가 PyTorch로 갔는가

2018~2020 무렵 학계가 TensorFlow에서 PyTorch로 대거 이동했다. 이유는 단순했다.

  • 디버깅이 파이썬 그대로 통한다 (pdb, print).
  • 동적 그래프가 NLP·RL·트랜스포머 같은 가변 입력에 자연스럽다.
  • API가 numpy에 가까워 학습 곡선이 낮다.
  • 사전 학습 모델 생태계 (Hugging Face) 가 PyTorch 기반으로 자라났다.

2.3 왜 산업·모바일에 TensorFlow가 남았는가

  • TensorFlow Serving·TFLite·TensorFlow.js로 배포 파이프라인이 잘 정비.
  • 모바일 (iOS Core ML / Android TFLite) 추론 도구.
  • TPU 우선 지원 (구글 인프라).
  • 다만 LLM 시대에 들어와 PyTorch가 산업 쪽도 빠르게 잠식 중.

3. 정의와 표기 — autograd

3.1 동적 계산 그래프

PyTorch는 forward를 실행하면서 연산 노드 그래프를 동시에 기록한다.

x = torch.tensor([1.0, 2.0], requires_grad=True)
y = x * 2
z = y.sum()
z.backward()
print(x.grad)            # tensor([2., 2.])

z.backward()가 그래프를 거꾸로 따라가며 6편의 \(\delta\) 전파를 자동 수행한다.

3.2 그래프 객체 들여다보기

z.grad_fn                            # <SumBackward0>
z.grad_fn.next_functions             # ((<MulBackward0>, 0),)
z.grad_fn.next_functions[0][0].next_functions  # ((<AccumulateGrad>, 0),)

각 노드가 backward 함수를 들고 있고, next_functions가 다음 노드 (입력 텐서) 를 가리킨다.

3.3 그래디언트 비활성화

with torch.no_grad():
    y = model(x)           # 그래프 기록 안 함, 메모리·속도 절약

x.detach()                 # 텐서를 그래프에서 떼어 냄

추론 또는 평가 코드에서 필수.

3.4 torch.compile (PyTorch 2.0+)

model = torch.compile(model)         # TorchDynamo + Inductor로 graph 컴파일

eager로 작성한 코드를 동적으로 트레이싱해 graph로 컴파일. 일반적으로 1.3~2배 속도 향상.


4. 정의와 표기 — Hugging Face transformers

4.1 AutoModel + AutoTokenizer

from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

model_id = "meta-llama/Llama-3.1-8B-Instruct"
tok = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id, torch_dtype=torch.bfloat16, device_map="auto"
)

prompt = "Explain backpropagation in one sentence."
inputs = tok(prompt, return_tensors="pt").to(model.device)
out = model.generate(**inputs, max_new_tokens=128, do_sample=True, temperature=0.7)
print(tok.decode(out[0], skip_special_tokens=True))

세 줄로 8B 파라미터 LLM의 가중치를 받고, 토큰화하고, 생성한다.

4.2 추상화 계층

계층 역할
AutoTokenizer 텍스트 ↔ 토큰 ID 변환
AutoModel 모델 가중치 로드 + forward
AutoModelFor{Task} 분류·생성·QA 등 작업별 헤드
pipeline() 토큰화·forward·디코딩을 한 줄로
Trainer 학습 루프 (PyTorch + DeepSpeed 등)

4.3 PEFT (LoRA)

from peft import LoraConfig, get_peft_model

lora_cfg = LoraConfig(
    r=16, lora_alpha=32, target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05, bias="none", task_type="CAUSAL_LM",
)
model = get_peft_model(model, lora_cfg)
model.print_trainable_parameters()

LLM 핵심 학습 2편의 LoRA가 그대로 한 줄로 적용된다.


5. 정의와 표기 — llama.cpp / MLX / Ollama

5.1 llama.cpp

C++로 작성된 LLM 추론 엔진. 주요 특징:

  • GGUF 포맷: 모델 가중치 + 메타데이터를 한 파일에. 양자화 정보 포함.
  • 저비트 양자화: Q4_K_M, Q5_K_M, Q8_0 등. 70B 모델을 INT4로 40GB → 20GB 메모리에.
  • 백엔드: CPU (AVX2/AVX-512), CUDA, Metal (Apple), Vulkan.
  • CLI/서버 양쪽 제공: ./llama-cli, ./llama-server (OpenAI 호환 API).
./build/bin/llama-cli -m models/llama-3.1-8b-instruct.Q4_K_M.gguf \
                      -p "Explain backprop in one sentence." \
                      -n 128 -t 8 -ngl 99

5.2 GGUF 양자화

양자화 비트 8B 모델 크기 품질 손실
F16 16 16 GB 기준
Q8_0 8 8 GB 거의 없음
Q5_K_M 5 5.5 GB 미미
Q4_K_M 4 4.6 GB 작음
Q3_K_M 3 3.5 GB 보임

LLM 핵심 학습 2편의 QLoRA가 학습 시 4-bit이라면, GGUF는 추론 시 저비트.

5.3 MLX (Apple)

Apple Silicon Mac 전용 ML 프레임워크. PyTorch와 가장 다른 점은 unified memory 활용이다. CPU와 GPU가 메모리를 공유하므로 host↔device 복사가 없다.

import mlx.core as mx
import mlx.nn as nn

class MLP(nn.Module):
    def __init__(self, dim):
        super().__init__()
        self.fc = nn.Linear(dim, dim)
    def __call__(self, x):
        return mx.maximum(self.fc(x), 0)

model = MLP(64)
x = mx.random.normal(shape=(2, 64))
print(model(x).shape)

API는 PyTorch와 유사하지만 lazy evaluation을 기본으로 한다. Apple Silicon에서 메모리 효율과 속도 모두 강점.

5.4 Ollama

llama.cpp를 데스크탑 사용 경험으로 감싼 도구.

ollama pull llama3.1:8b
ollama run llama3.1:8b "Explain backprop in one sentence."

서버 모드도 자동:

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama3.1:8b", "messages": [{"role":"user","content":"hi"}]}'

OpenAI Python SDK로 그대로 접속:

from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
resp = client.chat.completions.create(
    model="llama3.1:8b",
    messages=[{"role": "user", "content": "Explain backprop in one sentence."}],
)
print(resp.choices[0].message.content)

기존 OpenAI 코드의 base_url만 바꾸면 로컬 모델 호출. 이 호환성이 로컬 LLM 채택의 핵심 가속기다.


6. 다이어그램 — 학습부터 로컬 추론까지

diagram-1

7. 원리 워크스루 — 학습부터 로컬 추론까지의 전환점

로컬 LLM 워크플로는 사실 5단계로 압축된다: 사전 학습된 모델 → 양자화 → 추론 엔진 → API 호환 인터페이스. 각 전환점이 왜 등장했는지 가 본 글의 학습 가치다.

7.1 transformers — 사전 학습 모델의 공통 표준

from transformers import AutoTokenizer, AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-7B-Instruct", torch_dtype=torch.bfloat16, device_map="auto")

왜 transformers가 표준이 되었나 Hugging Face 2018 huggingface/pytorch-pretrained-BERT 이후 Auto 클래스가 등장 — AutoModelForCausalLM이 모델별 클래스를 자동 선택. 사전 학습 모델을 한 줄로 가져오는 표준 API. 이게 LLM 생태계 폭발의 인프라적 토대.

한계 파이썬 + PyTorch 의존. 연구·실험에는 최적이지만 추론 속도가 평범. 프로덕션 추론에는 vLLM·TGI·llama.cpp 같은 전용 엔진이 필요.

7.2 양자화 — 왜 GGUF 포맷이 필수가 되었나

관찰되는 패턴 - Qwen2.5-7B fp16: 14GB 메모리 (소비자 GPU 한계) - Q4_K_M (4-bit quantization): 4.4GB (Mac mini 32GB로도 충분) - 양자화 품질 손실: Q5+ 에서는 거의 무시 가능, Q3은 코드·수학 작업에서 체감 저하

왜 등장했나 LLaMA 1 (2023) 공개 직후 일주일 만에 llama.cpp와 GGUF 포맷이 등장. 7B 모델을 라즈베리 파이에서 돌리는 일이 가능해진 것이 LLM 민주화의 결정적 순간. Dettmers 2022 LLM.int8(), AWQ (Lin 2023), GPTQ (Frantar 2022) 가 양자화 알고리즘의 표준.

다음 단계로의 연결 양자화는 추론 메모리 만 줄임. 학습 시에는 QLoRA (Dettmers 2023) 같은 기법이 4-bit weights 위에서 LoRA를 학습.

7.3 추론 엔진 — 왜 여러 가지가 공존하나

같은 모델에 다른 엔진을 쓰는 이유는 환경별 최적화가 다르기 때문:

엔진 어디서 빠른가
transformers 연구·실험 (CUDA, MPS) 유연성
vLLM 서버 GPU 다중 사용자 PagedAttention (KV cache 페이지화)
TGI (HF) 프로덕션 서버 멀티 워커
llama.cpp CPU·Mac·Raspberry Pi GGUF + SIMD 최적화
MLX Apple Silicon unified memory, ANE
Ollama 데스크탑 UX llama.cpp wrapper + 모델 라이브러리

핵심 시각: "어떤 모델"보다 "어떤 환경에서 어떤 엔진" 이 더 결정적. 같은 7B 모델이 vLLM에서는 1000 tok/s, llama.cpp CPU에서는 5 tok/s.

7.4 OpenAI 호환 API — 동일 코드, 다른 백엔드

from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
resp = client.chat.completions.create(model="qwen2.5:7b", messages=[...])

왜 이게 게임을 바꿨나 OpenAI API가 사실상 LLM의 공통 인터페이스가 됨. Ollama·vLLM·TGI 모두 OpenAI 호환 엔드포인트 제공 → 같은 클라이언트 코드로 로컬·클라우드 양쪽 사용 가능.

핵심 시각: 인터페이스 표준화 = 공급자 종속 (vendor lock-in) 회피. 모델을 바꾸려면 base_url만 바꾸면 됨.

7.5 LoRA — 왜 풀 파인튜닝이 사라졌나

from peft import LoraConfig, get_peft_model
config = LoraConfig(r=16, lora_alpha=32, target_modules=["q_proj", "v_proj"])
model = get_peft_model(base_model, config)

무엇을 보는가 7B 모델 풀 파인튜닝 = 14GB × 4 (Adam 상태) = 56GB 메모리. 소비자급 불가능. LoRA: 가중치 행렬 \(W\) 대신 저랭크 보정 \(W + BA\)만 학습 (rank 16). 학습 파라미터 = 전체의 0.1% 미만.

왜 등장했나 Hu et al. 2022 LoRA: Low-Rank Adaptation of Large Language Models. 사전 학습 모델의 작은 변화만 학습하면 충분하다는 통찰. QLoRA (Dettmers 2023)는 base 모델을 4-bit으로 함께 두어 메모리를 또 한 번 줄임.

핵심 시각: 풀 파인튜닝은 사라지고 LoRA + QLoRA + 데이터 큐레이션이 표준. 효율적 적응 이 표준 패러다임.


8. 변형과 사례

8.1 추론 엔진 비교

엔진 강점 약점
transformers Python·연구·실험에 최적 추론 속도 평범
vLLM KV cache 페이지화로 매우 빠름 서버급 GPU 필요
TGI (HF) 프로덕션 추론 서버 설정 복잡
llama.cpp CPU/Mac에서 빠름 Python 통합 별도
MLX Apple Silicon 전용 최고 효율 macOS만
Ollama 데스크탑 UX 최고 고급 옵션 제한
LM Studio GUI, 사용자 친화 사이드카 의존

8.2 파이프라인: 학습 vs 추론

단계 도구
데이터 전처리 datasets, pandas, polars
학습 (full) PyTorch + DeepSpeed/FSDP
학습 (LoRA) PEFT, mlx-lm
평가 lm-evaluation-harness, OpenAI evals
양자화 bitsandbytes, AWQ, GPTQ, GGUF
배포 vLLM / TGI / Ollama / llama.cpp
클라이언트 OpenAI SDK 호환

8.3 사례

  • 개인 비서: Ollama + 작은 모델 + 로컬 임베딩으로 오프라인 RAG.
  • 코드 어시스턴트: Continue.dev + Ollama, GitHub Copilot 대안.
  • 데스크탑 챗봇: LM Studio, Jan, Msty.
  • 온디바이스 검색: 임베딩 모델 + ChromaDB.
  • 연구 실험: Hugging Face Hub 모델 + transformers + Weights & Biases.

9. 한계와 실패 양상

9.1 GPU·메모리 한계

왜 본질적 한계인가 70B 모델 fp16 = 140GB. 양자화해도 Q4_K_M에서 약 40GB. 소비자급 GPU·Mac에서 모델 크기 자체가 천장.

어떻게 진단하는가 OOM 즉시 발생. 또는 swap에 의한 극단적 속도 저하.

다음 단계 - 4~13B 모델부터 시작. - 13B 이상은 Apple Silicon unified memory (64GB+) 또는 GPU 클러스터. - MoE 모델 (Mixtral 8x7B) 은 추론 시 일부만 활성화 — 메모리 절감.

9.2 양자화 품질 손실

왜 본질적 한계인가 Q4 이하에서는 코드·수학 같은 정밀 작업에서 체감 저하. 모델이 "거의 맞는데" 결정적 부분에서 틀린다.

어떻게 진단하는가 같은 모델의 fp16과 Q4 출력을 같은 프롬프트로 비교. 일반 대화는 차이 적지만 코드는 잡음 증가.

다음 단계 - 일반 대화: Q4_K_M 충분. - 코드·수학: Q5_K_M 이상. - 추론 (reasoning) 모델: Q6 또는 fp16 권장.

9.3 컨텍스트 길이

왜 본질적 한계인가 KV cache가 컨텍스트 길이에 비례해 메모리 사용. 32k 컨텍스트면 KV cache가 모델 크기 수준으로 큼.

어떻게 진단하는가 긴 입력에서 OOM, 또는 응답 시간 급증.

다음 단계 - Sliding Window Attention (Mistral) — 일정 길이 윈도우만 보존. - Flash Attention 2 — 메모리 효율 추론. - Mamba/RWKV — \(O(L)\) 메모리.

9.4 추론 속도

왜 본질적 한계인가 CPU 추론은 메모리 대역폭에 묶임. 7B 모델 기준 CPU 5~20 tok/s, Apple Silicon 30~50 tok/s, RTX 4090 100+ tok/s.

어떻게 진단하는가 실시간 채팅 사용 가능 여부 측정.

다음 단계 - 작은 모델 (3B 이하) — 더 빠른 응답. - Speculative decoding — 작은 모델로 초안 + 큰 모델로 검증. - vLLM 같은 효율 엔진 + 양자화.

9.5 버전·포맷 호환

왜 본질적 한계인가 GGUF 포맷이 자주 진화 (V1, V2, V3). llama.cpp / Ollama 업데이트와 모델 파일 호환성 깨질 수 있음.

어떻게 진단하는가 모델 로드 시 에러 메시지에 quantization format 관련 언급.

다음 단계 - 정기 업데이트 + 사용 중인 모델 버전 기록. - 가능하면 최신 GGUF 로 재변환.

9.6 보안·프라이버시

왜 본질적 한계인가 모델이 학습 데이터의 암묵적 편향을 출력할 수 있음. 의료·법률 같은 민감 도메인은 반드시 평가 필요.

어떻게 진단하는가 도메인별 평가 세트로 출력 품질·편향 측정.

다음 단계 - 도메인 데이터로 추가 파인튜닝 (LoRA) — 7.5와 같은 패턴. - Guardrails (NeMo Guardrails, LangChain) 로 출력 필터링. - 민감 데이터는 로컬 LLM이 프라이버시 이점 — 클라우드로 데이터가 나가지 않음.


10. 정리된 결론 — 보지 않고 답해 보라

이 글이 답한 핵심 질문 5개. 먼저 답을 가린 채로 한 줄로 답해 본 뒤 정답과 비교.

Q1. transformers 라이브러리가 LLM 생태계의 표준이 된 결정적 이유는?

정답 AutoModelForCausalLM.from_pretrained(...) — 한 줄로 어떤 사전 학습 모델이든 가져오는 공통 API. 모델별 클래스를 수동으로 알 필요 없이 Auto 클래스가 자동 선택. 이게 사전 학습 모델 공유의 인프라적 토대. (본문 7.1)

Q2. 양자화의 4-bit (Q4_K_M)가 인기 있는 이유는? 한계는?

정답 7B 모델을 14GB → 4.4GB로 줄여 소비자 하드웨어에서 가능. 한계: 코드·수학 같은 정밀 작업에서 체감 저하 → Q5+ 권장. llama.cpp + GGUF (2023) 이 LLM 민주화의 결정적 순간. 모델 크기추론 가능성 을 결정했던 것을 양자화가 풀어 줌. (본문 7.2, 9.2)

Q3. 같은 모델인데 vLLM vs llama.cpp가 같은 작업에서 다른 속도를 보이는 이유는?

정답 환경별 최적화가 다름. vLLM은 서버 GPU 다중 사용자에 최적 (PagedAttention), llama.cpp은 CPU·Mac에 최적 (SIMD). "어떤 모델"보다 "어떤 환경에서 어떤 엔진"이 더 결정적. 7B 모델 기준 vLLM 1000 tok/s, llama.cpp CPU 5 tok/s. (본문 7.3)

Q4. OpenAI 호환 API가 로컬 LLM 도구들의 표준이 된 이유는?

정답 OpenAI API가 사실상 공통 인터페이스. 같은 클라이언트 코드로 로컬 (Ollama)·클라우드 (OpenAI) 양쪽 사용 가능, base_url만 변경. 인터페이스 표준화 = 공급자 종속 회피. 모델 교체 비용이 거의 0. (본문 7.4)

Q5. 풀 파인튜닝 대신 LoRA가 표준이 된 이유는?

정답 학습 파라미터를 전체의 0.1% 미만 으로 줄여 소비자급 메모리에서 가능. 사전 학습 모델의 "작은 변화"만 학습하면 충분. Hu et al. 2022 LoRA. QLoRA (Dettmers 2023)는 base 모델을 4-bit으로 함께 두어 메모리를 또 한 번 줄임. 풀 파인튜닝 56GB → QLoRA 6GB. (본문 7.5)


5개를 한 줄로 답할 수 있었다면 로컬 LLM 워크플로의 5단계 전환점이 자리잡은 것이다.


11. 시리즈를 마치며 — 어디로 가는가

지금까지 9편을 통해:

  • 1편 sklearn: ML의 공통 문법
  • 2편 k-NN: 가장 단순한 모델로 차원·거리·바이어스를 본다
  • 3편 선형 회귀: 손실·최적화의 출발점
  • 4편 로지스틱 회귀: 확률·cross-entropy·MLE
  • 5편 정규화: 과적합 다루기
  • 6편 신경망 기초: backprop과 보편 근사
  • 7편 학습 기법: Adam·BatchNorm·초기화·스케줄
  • 8편 아키텍처: CNN·RNN·Transformer
  • 9편 (이번 편): 프레임워크·로컬 LLM

이제 어디로 가는가? 자연스러운 다음 단계는 LLM 핵심 학습 시리즈 (6편)이다.

  1. 트랜스포머 한 블록 내부: 토큰화·임베딩·어텐션·위치 인코딩
  2. 파인튜닝: LoRA·QLoRA·Distillation
  3. 디코딩: Greedy·Beam·Top-p·Speculative
  4. 고급: RAG·CoT·MoE·In-Context Learning
  5. 수학 직관: Softmax·CE·KL·LayerNorm
  6. 학습 로드맵

머신러닝 기초가 손에 들어왔으니, 다음 시리즈에서는 LLM이라는 특정 아키텍처가 왜 이렇게 생겼는가를 같은 깊이로 따라간다.


12. 추가 학습

1차 자료

  • Paszke, A. et al. PyTorch: An Imperative Style, High-Performance Deep Learning Library. NeurIPS 2019. arXiv:1912.01703.
  • Abadi, M. et al. TensorFlow: A system for large-scale machine learning. OSDI 2016. arXiv:1605.08695.
  • Wolf, T. et al. Transformers: State-of-the-Art Natural Language Processing. EMNLP 2020 Demo. arXiv:1910.03771 — Hugging Face transformers.
  • Hu, E. J. et al. LoRA: Low-Rank Adaptation of Large Language Models. ICLR 2022. arXiv:2106.09685.
  • Dettmers, T. et al. QLoRA: Efficient Finetuning of Quantized LLMs. NeurIPS 2023. arXiv:2305.14314.

공식 docs·저장소

  • PyTorch: https://pytorch.org/docs/stable/
  • TensorFlow: https://www.tensorflow.org/api_docs/
  • Hugging Face transformers: https://huggingface.co/docs/transformers/
  • PEFT: https://huggingface.co/docs/peft/
  • llama.cpp: https://github.com/ggml-org/llama.cpp
  • MLX: https://ml-explore.github.io/mlx/
  • Ollama: https://ollama.com/
  • vLLM: https://docs.vllm.ai/

보조 자료

  • d2l.ai (Dive into Deep Learning): 무료 교과서.
  • Karpathy, A. Neural Networks: Zero to Hero (YouTube). backprop·트랜스포머를 처음부터.
  • Chip Huyen. Designing Machine Learning Systems. O'Reilly 2022. 배포·운영 측면.

이 시리즈가 머신러닝의 큰 그림을 손에 잡히게 해 주었길 바란다. 다음 시리즈에서 LLM의 내부를 같은 깊이로 만나자.

시리즈 전체 안내: 시리즈 목차

댓글

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"