김신건의 로그 - 위키 / ml

분산 학습

koa (김신건) — Sat, 18 Jul 2026 00:00:00 GMT

정의

분산 학습 (Distributed Training) 은 한 [[GPU]] 또는 [[TPU]] 에 들어가지 않는 큰 모델을 여러 가속기에 나눠서 학습시키는 기법.

현대 LLM (Llama 405B, GPT-4, Gemini Ultra 등) 은 수천 ~ 수만 개의 GPU 로 동시에 학습된다. 한 GPU 가 메모리, 컴퓨트, 통신 등 어느 한 자원이 부족할 때 다양한 방식으로 분할한다.

{}

문제 상황과 동기

단일 GPU 학습의 한계:

제약	설명
VRAM 한계	A100 80GB 기준, Llama 70B float16 = 140GB. 한 GPU 불가.
컴퓨트 한계	1조 token 학습에 A100 1대로 수십 년.
통신 병목	대규모 batch 는 gradient 크기가 너무 커서 동기화 자체가 부담.

이를 해결하기 위해 데이터, 레이어, 텐서, 시퀀스 차원을 각각 나눠 수천 개 GPU 를 동시에 활용한다.

핵심 4가지 병렬화 전략

대규모 모델 학습은 보통 4가지 (이상의) parallelism 을 조합해서 사용한다.

flowchart TD
    All["분산 학습 전략"]
    All --> DP["Data Parallelism (DP)"]
    All --> TP["Tensor Parallelism (TP)"]
    All --> PP["Pipeline Parallelism (PP)"]
    All --> ZeRO["ZeRO / FSDP"]
    All --> CP["Context Parallelism (CP)"]
    All --> EP["Expert Parallelism (EP)"]
    DP --> DPnote["전체 모델 복제, 데이터만 분할"]
    TP --> TPnote["레이어 내 행렬 분할"]
    PP --> PPnote["레이어 단위 분할"]
    ZeRO --> ZeROnote["Optimizer/Grad/Param sharding"]

1. Data Parallelism (DP), 가장 단순

GPU 0: 전체 모델 + 데이터 batch 의 1/N
GPU 1: 전체 모델 + 데이터 batch 의 1/N
...
GPU N: 전체 모델 + 데이터 batch 의 1/N

→ 각자 forward + backward
→ all-reduce 로 gradient 동기화
→ 같은 step 후 모델이 동일해짐

장점: 구현 가장 단순 (PyTorch DDP 한 줄)
단점: 각 GPU 에 전체 모델이 들어가야 함 (메모리 부족 시 사용 불가)
통신: 매 step backward 후 all-reduce (전체 모델 gradient 동기화)

2. Tensor Parallelism (TP), 한 layer 를 쪼개기

큰 행렬 곱셈을 가로/세로로 분할.

Original: Y = X @ W  (W: [hidden, ff] = [4096, 16384])

Tensor Parallel (4-way):
  GPU 0: W_0 = W[:, 0:4096]
  GPU 1: W_1 = W[:, 4096:8192]
  GPU 2: W_2 = W[:, 8192:12288]
  GPU 3: W_3 = W[:, 12288:16384]

  각 GPU: Y_i = X @ W_i
  결합: Y = concat([Y_0, Y_1, Y_2, Y_3])  # all-gather

장점: 큰 layer 도 분할 가능
단점: forward 마다 통신 (all-reduce/all-gather) 필요, 노드 내 NVLink 같은 빠른 연결 필수
대표: Megatron-LM 의 TP 구현

3. Pipeline Parallelism (PP), layer 를 분할

모델의 layer 를 GPU 들에 수직 분배.

GPU 0: Layer 1-10
GPU 1: Layer 11-20
GPU 2: Layer 21-30
GPU 3: Layer 31-40

→ 입력 → GPU 0 → GPU 1 → GPU 2 → GPU 3 → 출력

순차적이라 idle 시간 발생. micro-batching 으로 pipeline 채움 (GPipe, PipeDream).

시간 →
GPU 0: [B1] [B2] [B3] [B4] [bw4][bw3][bw2][bw1]
GPU 1:      [B1] [B2] [B3] [B4] [bw4][bw3][bw2][bw1]
GPU 2:           [B1] [B2] [B3] [B4] [bw4][bw3][bw2][bw1]
GPU 3:                [B1] [B2] [B3] [B4] [bw4][bw3][bw2][bw1]

장점: 통신 비용 작음 (인접 GPU 만), 매우 깊은 모델에 효과적
단점: bubble (idle 시간) 발생, 정확한 schedule 필요

4. ZeRO / FSDP, 메모리 sharding

Microsoft DeepSpeed 의 ZeRO (arXiv:1910.02054), PyTorch FSDP 가 대표.

데이터 병렬의 메모리 비효율을 해결. 각 GPU 가 모델 일부만 저장.

Stage	shard 대상	메모리 절약
ZeRO-1	Optimizer state	4x
ZeRO-2	+ Gradient	8x
ZeRO-3 (FSDP)	+ Parameter	N x (GPU 수에 비례)

ZeRO-3 / FSDP 동작:

평소: parameter 도 shard 되어 있음
forward 시: 필요한 layer 의 parameter 를 all-gather 로 모음
backward 시: gradient 계산 후 reduce-scatter 로 다시 분산
장점: Data Parallelism + 메모리 효율
단점: gather/scatter 통신 비용 추가

5. Context Parallelism (CP), 시퀀스 차원 분할

긴 컨텍스트 (32K, 100K+ token) 학습 시 시퀀스 자체를 GPU 에 분할.

GPU 0: token 0~8K
GPU 1: token 8K~16K
GPU 2: token 16K~24K
GPU 3: token 24K~32K

→ attention 시 ring exchange 로 통신

Google Gemini 1.5 Pro (1M context), Llama 3 (128K context) 학습에 사용.

6. Expert Parallelism (EP), MoE 모델

Mixture of Experts (MoE) 모델에서 각 expert 를 다른 GPU 에 배치. 라우팅으로 활성 expert 만 통신.

Mixtral 8x7B
DeepSeek V3 (671B parameter, 활성 37B)

조합: 3D / 4D / 5D Parallelism

대규모 학습은 보통 여러 차원을 조합:

Total GPUs = TP × PP × DP × CP × EP

예: Llama 3.1 405B 학습 (16,000 H100):
  TP: 8 (노드 내, NVLink)
  PP: 16 (노드 간, InfiniBand)
  DP: 125 (전체 batch 분산)
  Total: 8 × 16 × 125 = 16,000

각 차원의 통신 패턴:

TP: forward 마다 all-reduce/all-gather → 고대역폭 필수 (NVLink)
PP: layer 경계에서 1회 → 저대역폭 OK (InfiniBand)
DP: backward 후 all-reduce → 중간 대역폭
CP: ring exchange → 노드 내 추천
EP: 라우팅 통신 → all-to-all

동기화 패턴 (Collective Communication)

분산 학습의 핵심은 collective operation 들.

all-reduce:  [a,b,c,d] → 각 노드에 sum=a+b+c+d
all-gather:  [a,b,c,d] → 각 노드에 [a,b,c,d]
reduce-scatter: [a,b,c,d] → 각 노드에 일부 sum
broadcast:   [a,...,...,...] → [a,a,a,a]
all-to-all:  matrix transpose 같은 전체 재분배

이 연산들이 분산 학습의 통신 비용. 효율적인 구현이 NVIDIA NCCL, AMD RCCL, Google CC 라이브러리.

프레임워크

프레임워크	주력	비고
PyTorch DDP	DP	가장 단순, 한 줄로 사용
PyTorch FSDP	DP + ZeRO-3	메모리 효율 DP
Megatron-LM (NVIDIA)	TP + PP + CP + DP + EP	LLM 학습 표준
DeepSpeed (Microsoft)	ZeRO 1/2/3 + PP	MoE 지원
Colossal-AI	모든 전략 통합	학습 + 추론 통합
JAX/Flax + pmap/pjit	SPMD 스타일 분할	Google TPU 표준

어디서 사용?

모델	학습에 쓴 전략
Llama 2/3 (70B+)	DP + TP + PP + FSDP
Mixtral 8x7B (MoE)	DP + EP + TP
GPT-4 (추정)	DP + TP + PP + EP
Gemini 1.5 Pro (1M context)	DP + TP + CP
DeepSeek V3 (671B MoE)	DP + EP + TP

함정

1. TP degree 와 NVLink

Tensor Parallelism 은 forward 마다 통신이 발생해 노드 내 NVLink 가 없으면 성능이 급락한다. TP degree 는 노드 내 GPU 수 (보통 8) 를 초과하지 않는 것이 원칙.

2. Pipeline bubble

PP 에서 micro-batch 수가 적으면 GPU idle 시간(bubble) 이 커진다. bubble fraction = (PP-1) / (PP-1+microbatches). microbatches 를 늘리거나 interleaved schedule 적용 필요.

3. ZeRO-3 와 메모리 재집합 비용

ZeRO-3 는 parameter 를 분산하므로 각 forward 단계에서 all-gather 가 필요. 작은 batch size 에서 통신이 오히려 bottleneck 이 될 수 있다.

4. 체크포인트 복잡도

TP+PP+DP 조합에서 체크포인트는 각 rank 마다 다른 파일이 생긴다. 학습 재개 시 정확히 같은 parallelism 설정이 필요하거나 변환 스크립트 필요.

CS 에 미친 영향

분산 학습은 단순한 엔지니어링 기법을 넘어 ML 연구 전체를 바꿨다.

모델 크기 폭증: 1B → 7B → 70B → 405B → 1T (3년에 1000배)
데이터센터 설계 변화: NVLink, InfiniBand, 광 통신이 핵심 인프라
새로운 연구 분야: scaling law, parallelism 자동 탐색 (Alpa, GSPMD)
분산 시스템 지식 필수: ML 엔지니어가 통신, 동기화, 장애 복구를 알아야

HBM

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

HBM (High Bandwidth Memory)는 DRAM die 를 수직으로 적층해 매우 높은 대역폭을 제공하는 메모리 패키지. AI 시대 GPU/TPU 의 메모리 병목 해결을 담당한다.

기존 GDDR 메모리가 PCB 위에서 칩 옆에 배치되는 것과 달리, HBM 은 GPU/TPU die 와 같은 interposer 위에 수 mm 거리에 배치되어 수천 개의 병렬 채널로 연결된다.

{}

GDDR 대비 차이

flowchart LR
    subgraph GDDR["GDDR (기존 방식)"]
        G_GPU["GPU die"] <-->|"PCB 배선\n(32-bit x N 채널)"| G_MEM["GDDR6X\n(칩 측면 배치)"]
    end
    subgraph HBM_PKG["HBM (2.5D 패키징)"]
        H_GPU["GPU die"] <-->|"Silicon Interposer\n(1024-bit 병렬)"| H_MEM["HBM Stack\n(GPU 위/옆 mm 단위)"]
    end

항목	GDDR6X	HBM3e
버스 폭	32-bit per chip	1024-bit per stack
대역폭 (단일)	~56 GB/s	~1,218 GB/s
레이턴시	~낮음	~비슷
전력 효율	낮음	높음 (TSV 짧음)
비용	저렴	비쌈 (~20배)
용량	높음	제한적 (die 수)
사용처	게임 GPU	AI GPU/TPU

구조

                     [HBM Stack]
        +-------------------------+
        |     DRAM Die (layer 12) |  ← HBM3e 까지 12 단
        +-------------------------+
        |     DRAM Die (layer 11) |
        +-------------------------+
        |          ...            |
        +-------------------------+
        |     DRAM Die (layer 1)  |
        +-------------------------+
        |     Base Die (Logic)    |  ← I/O + Refresh + ECC
        +-----+-------+-----+-----+
              |       |     |
              ↓       ↓     ↓  (TSV: 수천 개의 실리콘 관통 전극)
        +-----+-------+-----+-----+
        |    Silicon Interposer   |  ← 마이크론 단위 배선
        +-----+-------+-----+-----+
              |       |     |
        +-----+-------+-----+-----+
        |       GPU / TPU         |
        +-------------------------+

Base Die (Logic Die)

스택의 가장 아래. DRAM die 가 아니라 로직 회로 만 들어있다.

I/O 컨트롤러
ECC (Error Correcting Code) 회로
Refresh 로직 (DRAM 셀이 주기적 갱신 필요)
Channel 관리

Through-Silicon Via (TSV)

핵심 기술. die 를 수직으로 관통하는 전극.

HBM3 기준 한 스택에 약 1,024 개 TSV
직경 수 마이크로미터
모든 die 를 통과해야 하므로 정렬 정밀도가 핵심

Silicon Interposer

GPU/TPU die 와 HBM stack 을 연결하는 작은 PCB 같은 실리콘 기판. 일반 PCB 보다 훨씬 미세한 배선 (마이크론 단위).

HBM 의 비용 큰 이유 중 하나가 interposer + 패키징 (2.5D 패키징, 또는 CoWoS).

Channel 과 Bank 구조

HBM 한 스택은 내부적으로 여러 channel 로 나뉜다.

1 HBM3 stack
  ├── 8 channels (병렬 접근 가능)
  │   ├── 16 banks 각각
  │   └── 각 bank: row + column address
  └── 1024-bit wide interface

Channel: 독립적으로 read/write 가능. 8 channel = 8 개 메모리 컨트롤러가 동시 동작
Bank: 한 channel 안에서 여러 행이 동시 활성화. bank parallelism 으로 throughput 증가
Wide interface: 한 cycle 에 1024 bit (128 bytes) 동시 전송

GPU 메모리 컨트롤러는 이 8 channels × 16 banks 를 잘 활용해야 최대 대역폭을 낸다. 그래서 GPU 의 메모리 접근 패턴 (coalesced access) 이 중요.

동작 원리

DRAM 의 기본 동작은 같다.

1. ACTIVATE: row 를 row buffer 로 가져오기 (RAS, ~15ns)
2. READ/WRITE: row buffer 의 column 선택 (CAS, ~15ns)
3. PRECHARGE: 다음 access 를 위해 row 닫기

HBM 의 트릭:
- 8 channel × 16 bank = 128개 작업을 동시 진행
- TSV 가 짧아 latency 가 일반 DDR 과 비슷 (~80ns) 이지만
- 동시 처리량은 ~20배 (1.2 TB/s vs 50 GB/s)

즉 HBM 은 latency 가 아니라 throughput 으로 이긴다. 한 access 의 응답 시간은 비슷하지만 동시 처리 가능 수가 압도적.

세대별 대역폭

세대	출시	스택당 대역폭	비고
HBM1	2015	128 GB/s	AMD Fiji
HBM2	2016	256 GB/s	NVIDIA V100
HBM2e	2019	460 GB/s	NVIDIA A100
HBM3	2022	819 GB/s	NVIDIA H100, TPU v5p
HBM3e	2024	1,218 GB/s	NVIDIA H200, B200 (12-stack)
HBM4	2026 예정	~2,048 GB/s	NVIDIA Rubin, AMD MI400

비교용으로, DDR5 한 채널은 약 51 GB/s. HBM3e 한 스택이 DDR5 의 24배 대역폭.

왜 AI 에 필수인가

Roofline Model: 산술 강도

AI 워크로드를 분류하는 핵심 개념.

산술 강도 = FLOPs / 메모리 바이트 전송량

메모리 바운드: 산술 강도 낮음. GPU 연산 유닛이 놀고 메모리 기다림. HBM 이 직접 영향.
컴퓨트 바운드: 산술 강도 높음. 메모리보다 연산이 병목. Tensor Core 가 영향.

LLM 추론 예:

단계	산술 강도	병목
Prefill (긴 입력 처리)	높음	컴퓨트 바운드
Decode (토큰 생성)	낮음	메모리 바운드 (HBM 직결)
Attention (긴 컨텍스트)	낮음	메모리 바운드

LLM 서빙 속도는 대부분 HBM 대역폭이 결정한다.

실제 수치

GPT-3 175B 모델은 FP16 으로 350 GB
매 토큰 생성마다 모델 가중치를 전부 메모리에서 가져와야 함
1초에 100 토큰 생성하려면 35 TB/s 대역폭 필요

이 수치는 HBM 8 스택 (8 × 1.2 TB/s = 9.6 TB/s) 으로도 부족하다. 그래서:

모델 분할 (multi-GPU)
양자화 (FP16 → INT8 → INT4)
KV cache 최적화 (Flash Attention)
HBM4, HBM5 로의 지속 진화

Flash Attention 과 HBM

Flash Attention (Dao et al., 2022) 은 HBM I/O 를 최소화하는 어텐션 구현.

기존 Attention:
  Q, K, V 행렬 HBM → SRAM 이동 (대용량)
  S = QK^T 계산
  S HBM 에 저장
  P = softmax(S) 계산
  P HBM 에 저장
  O = PV 계산 → HBM

Flash Attention:
  Q, K, V 타일(tile)만 SRAM 에 로드
  타일 단위 내에서 softmax + 곱 완결
  HBM write 획기적 감소 (2-4배 속도 향상)

HBM 대역폭을 아끼는 알고리즘 설계가 성능의 핵심.

비용 구조

HBM 은 비싸다.

일반 DDR5 16GB: ~$50
HBM3e 16GB: ~$1,000 (20배)

이유:

TSV 공정 복잡 (수율 낮음)
수직 적층 패키징 비용
SK Hynix 사실상 독점 (HBM3e 의 75%+ 점유)

NVIDIA H100 의 HBM 비용이 전체 칩 가격 (~$30,000) 의 약 1/3 을 차지한다.

CPU vs GPU 메모리 격차

프로세서	메모리 종류	대역폭
Intel Core i9 (DDR5)	DDR5-5600	~89 GB/s
Apple M4 Max (LPDDR5X)	unified	~546 GB/s
AMD Threadripper (DDR5)	DDR5-5200	~166 GB/s
NVIDIA H100 (HBM3)	HBM3 5 stack	~3,350 GB/s
NVIDIA B200 (HBM3e)	HBM3e 8 stack	~8,000 GB/s

GPU/TPU 가 AI 워크로드를 압도하는 핵심 이유 = HBM 의 대역폭.

용량 vs 대역폭 trade-off

HBM 은 대역폭은 압도적이지만 용량 한계가 있다.

시스템	HBM 용량	GDDR/DDR 최대
NVIDIA H100 (80GB)	80 GB	(DDR5 호스트 2TB)
NVIDIA H200	141 GB	(DDR5 호스트 2TB)
Google TPU v5p pod	스택 수에 비례	(TPU HBM only)

GPU 가속기에서 모델이 HBM 용량을 초과하면 두 가지 선택:

Multi-GPU 샤딩: tensor/pipeline parallelism 으로 분산
Offloading: CPU RAM 으로 overflow (대역폭 급감)

HBM 용량은 AI 모델 크기의 자연적 상한선이다.

함정

[!WARNING] 대역폭이 높아도 접근 패턴이 비효율이면 낭비: GPU 는 coalesced memory access (연속된 주소) 일 때 최대 대역폭을 낸다. 랜덤 접근이면 대역폭의 일부만 활용.

[!CAUTION] 용량 한계: HBM3e 최대 약 96 GB (H200). 모델이 이를 초과하면 multi-GPU 분산이 불가피. HBM 용량은 GDDR 대비 여전히 제한적.

SIMT

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

SIMT (Single Instruction, Multiple Threads) 는 NVIDIA 가 정립한 GPU 의 실행 모델이다. 한 명령(instruction) 을 한 그룹의 thread(warp) 가 동시에 실행하되, 각 thread 는 자기 레지스터와 데이터를 갖는다.

{}

언제 쓰이나

GPU 프로그래밍 (CUDA, ROCm, OpenCL) 의 실행 원리 이해
커널 최적화: warp divergence, memory coalescing, occupancy
ML 모델 추론/학습 시 GPU 활용률 분석
[[TPU|TPU]] 의 Systolic Array 와 비교 시 기준점

SIMD 와의 차이

SIMD (Single Instruction Multiple Data) 와 헷갈리기 쉽다.

	SIMD	SIMT
데이터 그룹	벡터 레지스터 (예: AVX-512 = 16 floats)	thread (수 십개)
분기 처리	어렵음 (masked operation)	자동 (warp divergence)
프로그래밍 모델	명시적 SIMD intrinsic	평범한 thread 코드
레지스터	공유 벡터 레지스터	각 thread 독립 레지스터
대표 사례	CPU AVX, ARM NEON	NVIDIA CUDA, AMD ROCm

CUDA 코드는 마치 각 thread 가 독립적으로 도는 것처럼 작성하지만, 하드웨어는 32 thread (= 1 warp)를 lockstep 으로 함께 실행한다.

__global__ void add(float* a, float* b, float* c, int n) {
  int i = blockIdx.x * blockDim.x + threadIdx.x;
  if (i < n) c[i] = a[i] + b[i];
}
// 각 thread 가 c[i] = a[i] + b[i] 를 자기 i 로 수행
// 한 warp 의 32 thread 가 동시에 ADD 명령 실행

Thread 계층: Thread / Block / Grid

CUDA 커널은 3단계 계층으로 thread 를 구성한다.

flowchart TB
    Grid["Grid\n(전체 커널)"] --> B0["Block 0"]
    Grid --> B1["Block 1"]
    Grid --> BN["Block N"]
    B0 --> W0["Warp 0\n(32 threads)"]
    B0 --> W1["Warp 1\n(32 threads)"]
    B0 --> WK["Warp K\n(32 threads)"]
    W0 --> T["Thread 0 ~ 31\n(각자 레지스터 + 데이터)"]

Thread: 독립적 레지스터 + 스택. 고유 threadIdx.
Block: 공유 메모리(SRAM)를 공유하는 thread 그룹. 한 SM 에 할당.
Grid: 전체 커널 실행 범위. 여러 SM 에 분산.

// 예: 1M 원소 덧셈
// Grid = 1000 blocks, Block = 1024 threads
add<<<1000, 1024>>>(a, b, c, N);
// threadIdx.x: 0~1023 (블록 내)
// blockIdx.x : 0~999  (그리드 내)
// globalIdx   = blockIdx.x * 1024 + threadIdx.x

SM (Streaming Multiprocessor) 아키텍처

flowchart TB
    subgraph "SM (Streaming Multiprocessor)"
        WS["Warp Scheduler\n(64 warp 관리)"]
        RF["Register File\n(65536 x 32-bit)"]
        SMEM["Shared Memory / L1\n(228KB, H100)"]
        CC["CUDA Cores\n(128개 FP32)"]
        TC["Tensor Cores\n(4개 BF16/FP8)"]
    end
    SMEM <--> CC
    SMEM <--> TC
    WS --> CC
    WS --> TC
    SMEM --> L2["L2 Cache"]
    L2 --> HBM["HBM"]

H100 SM 기준:

128 CUDA Cores (FP32)
4 Tensor Cores (BF16/FP8 matmul)
최대 64 warp 동시 보유, 한 cycle 에 4 warp 디스패치
Shared Memory: 228 KB / SM (L1 와 공유)
Register File: 65536 x 32-bit

NVIDIA H100 = 132 SM × 64 warp × 32 thread = 약 27만 thread 동시 처리 가능.

Warp

Warp 크기: NVIDIA = 32 threads, AMD wavefront = 32 또는 64
1 warp 의 모든 thread 는 같은 PC (program counter) 를 공유 → 같은 명령 동시 수행
각 thread 는 고유한 thread index + 자기 레지스터 보유

SM (Streaming Multiprocessor) 한 개:
  - 64 개의 warp 동시 보유 가능
  - 한 cycle 에 1~4 개의 warp 명령 디스패치
  - 같은 SM 의 warp 들은 공유 메모리(SRAM) 접근 가능

Occupancy

Occupancy = SM 에 실제 할당된 warp 수 / SM 최대 warp 수.

높은 occupancy 는 메모리 레이턴시를 숨기는 데 중요하다. 한 warp 가 메모리 대기 중일 때 다른 warp 를 실행해 파이프라인을 채운다.

Occupancy 저하 요인	영향
레지스터 과다 사용	1 SM 의 Register File 총량 초과 시 block 수 감소
공유 메모리 과사용	1 SM 의 SRAM 을 여러 block 이 나눠 씀
Block 크기가 warp 배수 아님	마지막 warp 에 idle thread 발생
큰 Block	한 SM 에 몇 개 block 만 들어감

// Occupancy 계산 보조 API
int numBlocks;
cudaOccupancyMaxActiveBlocksPerMultiprocessor(
    &numBlocks,
    myKernel,
    blockSize,
    sharedMemBytes
);

Warp Divergence

SIMT 의 가장 큰 함정.

if (x > 0) {
  result = compute_A();
} else {
  result = compute_B();
}

같은 warp 의 일부 thread 만 if 경로를 타고 나머지가 else 를 타면, GPU 는 두 경로를 직렬로 실행한다.

Cycle 1: warp 의 (x>0) thread 만 활성, compute_A 실행
         (x<=0) thread 는 idle
Cycle 2: warp 의 (x<=0) thread 만 활성, compute_B 실행
         (x>0) thread 는 idle

결과적으로 같은 warp 안에서 분기가 갈리면 활용률이 절반으로 떨어진다.

Divergence 최소화 패턴

데이터 정렬: 비슷한 분기 결과를 가진 thread 를 같은 warp 로 모음
분기 단순화: triangle ops, masked select 등으로 변환
branch-free 알고리즘 선호: min(a, b) 대신 조건 없는 수식

메모리 접근 패턴

SIMT 의 또 다른 성능 결정 요인은 coalesced memory access.

한 warp 의 32 thread 가 연속된 메모리 주소를 접근 → 1번의 메모리 트랜잭션으로 처리 (좋음)
흩어진 주소를 접근 → 32번의 트랜잭션 (나쁨, 32x 메모리 대역폭 소모)

배열 인덱스를 thread ID 로 만드는 게 정석.

// Good: thread 0 → a[0], thread 1 → a[1], ... → coalesced
data[threadIdx.x]

// Bad: thread 0 → a[0], thread 1 → a[32], ... → scattered
data[threadIdx.x * 32]

Shared Memory (SRAM) 활용

같은 block 의 thread 들이 공유하는 빠른 SRAM 을 활용하면 전역 메모리 접근을 줄일 수 있다.

__global__ void matrix_mul_shared(float* A, float* B, float* C, int N) {
    __shared__ float tileA[32][32];
    __shared__ float tileB[32][32];

    int row = blockIdx.y * 32 + threadIdx.y;
    int col = blockIdx.x * 32 + threadIdx.x;
    float sum = 0.0f;

    for (int t = 0; t < N / 32; t++) {
        // 전역 메모리 → 공유 메모리 (coalesced 로드)
        tileA[threadIdx.y][threadIdx.x] = A[row * N + t * 32 + threadIdx.x];
        tileB[threadIdx.y][threadIdx.x] = B[(t * 32 + threadIdx.y) * N + col];
        __syncthreads();  // 모든 thread 로드 완료 대기

        for (int k = 0; k < 32; k++)
            sum += tileA[threadIdx.y][k] * tileB[k][threadIdx.x];

        __syncthreads();
    }
    C[row * N + col] = sum;
}

Shared Memory 에 tile 을 올린 뒤 반복 참조 → 전역 메모리 접근 횟수 크게 감소.

NVIDIA vs AMD

항목	NVIDIA (CUDA)	AMD (ROCm/HIP)
Warp 단위	32 threads (warp)	32 또는 64 threads (wavefront)
코어 명칭	CUDA Core	Stream Processor
SM 명칭	SM (Streaming Multiprocessor)	CU (Compute Unit)
행렬 가속	Tensor Core	Matrix Core
언어	CUDA C++	HIP (CUDA 유사), OpenCL
이식성	낮음 (NVIDIA only)	HIP 은 CUDA 코드 자동 변환 가능

AMD wavefront 크기가 64 인 경우, branch divergence 의 비용이 NVIDIA 대비 2배가 될 수 있다.

흔한 함정

[!WARNING]

Warp divergence 무시 = 분기 많은 커널에서 활용률 50% 이하로 급락. 데이터 정렬 또는 branch-free 패턴으로 최소화.

Uncoalesced memory access = 흩어진 주소 접근은 대역폭 낭비. thread ID 를 연속 인덱스로 매핑.

Block 크기가 32 배수 아님 = 마지막 warp 에 idle thread. block 크기는 항상 32 배수로.

Shared memory bank conflict = 같은 bank 에 여러 thread 가 동시 접근 시 직렬화. padding 으로 해결.

Occupancy 무조건 최대화 = 레지스터/SRAM 을 너무 아끼면 오히려 스루풋 감소. profiler 로 최적점 탐색.

SPMD

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

SPMD (Single Program, Multiple Data)는 병렬 컴퓨팅의 대표 모델 중 하나. 모든 프로세스(또는 thread)가 같은 프로그램을 실행하되, 각자 다른 데이터를 처리한다.

Frederica Darema 가 1980년대 후반 IBM 에서 정의한 개념. MPI, CUDA, OpenMP 등 거의 모든 병렬 컴퓨팅 프레임워크의 기본 추상화.

동작 방식

flowchart TD
    P["같은 프로그램 코드"]
    P --> R0["Rank 0\n데이터 슬라이스 0"]
    P --> R1["Rank 1\n데이터 슬라이스 1"]
    P --> R2["Rank 2\n데이터 슬라이스 2"]
    P --> RN["Rank N-1\n데이터 슬라이스 N-1"]
    R0 & R1 & R2 & RN --> SYNC["집합 통신\n(All-Reduce / All-Gather / Barrier)"]
    SYNC --> OUT["집계된 결과"]

# SPMD 의사 코드 (모든 노드가 같은 코드 실행)
my_rank = get_rank()           # 0, 1, 2, ..., N-1
my_data = load_data(my_rank)   # 노드마다 다른 데이터 슬라이스
result = process(my_data)      # 같은 처리 로직
all_results = collective_op(result)  # 통신 (all-reduce 등)

각 노드/프로세스는:

rank (또는 id) 로 자기를 식별
자기 데이터 슬라이스만 처리
동기화 지점 에서 통신 (barrier, all-reduce, broadcast 등)

다른 병렬 모델과의 차이

모델	프로그램	데이터	동기화	대표 사례
SIMD	1	여러 vector	매 사이클	CPU AVX, SSE
[[SIMT]]	1	thread 마다	warp 단위	GPU CUDA
SPMD	1 (인스턴스 N개)	노드 마다	명시적	MPI, 분산 학습
MIMD	여러	여러	명시적	일반 멀티스레드

[[SIMT]] 는 SPMD 의 GPU 하드웨어 구현 정도로 볼 수 있다. CUDA 코드를 작성할 때 각 thread 가 자기 threadIdx.x 로 자기 데이터를 처리하는 패턴이 정확히 SPMD.

SPMD 의 매력

1. 프로그래밍 단순함

여러 다른 프로그램을 짜는 게 아니라 하나만 짜면 됨. rank 로 분기.

if my_rank == 0:
    coordinator_logic()
else:
    worker_logic()

2. 확장 용이

같은 코드를 100 노드든 10,000 노드든 실행 가능. 노드 수만 바꾸면 끝.

3. 동기화가 명시적

모든 노드가 같은 코드를 실행하므로 collective_op 같은 동기화 지점이 자연스럽게 일치.

실제 예시

MPI (Message Passing Interface)

전통적인 HPC 의 SPMD 표준.

MPI_Init(&argc, &argv);
int rank, size;
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
MPI_Comm_size(MPI_COMM_WORLD, &size);

// 각 rank 가 자기 데이터 슬라이스 처리
double local_sum = compute_local_sum(rank);

// 모든 노드의 합 = global_sum 으로 집계
double global_sum;
MPI_Reduce(&local_sum, &global_sum, 1, MPI_DOUBLE, MPI_SUM, 0, MPI_COMM_WORLD);

MPI_Finalize();

CUDA (GPU)

GPU 의 SPMD 구현. 각 thread 가 자기 인덱스로 작업.

__global__ void add_vectors(float* a, float* b, float* c, int n) {
  int i = blockIdx.x * blockDim.x + threadIdx.x;
  if (i < n) c[i] = a[i] + b[i];
}

PyTorch DDP / FSDP

[[분산 학습]] 의 SPMD 패턴. 모든 GPU 가 같은 모델 코드를 실행, 각자 다른 배치 처리, all_reduce 로 gradient 동기화.

# 모든 rank 가 실행 (DDP)
dist.init_process_group()
model = DDP(model)
for batch in dataloader:  # rank 마다 다른 배치
    loss = model(batch)
    loss.backward()
    # DDP 가 자동으로 all-reduce
    optimizer.step()

DDP 와 FSDP 의 차이:

항목	DDP	FSDP
모델 복제	각 GPU 에 전체 복사	파라미터 샤딩
메모리	GPU 수만큼 중복	효율적
대상	모델이 단일 GPU 에 맞을 때	초대형 모델

JAX `pmap`

함수형 SPMD. XLA 컴파일러가 device 배치를 자동 최적화.

import jax
import jax.numpy as jnp

@jax.pmap
def step(params, batch):
    loss, grads = jax.value_and_grad(compute_loss)(params, batch)
    # pmap 이 자동으로 all-reduce
    grads = jax.lax.pmean(grads, axis_name="batch")
    new_params = params - learning_rate * grads
    return new_params, loss

# pmap 은 모든 device 에 같은 함수를 자동 분배
new_params, losses = step(replicated_params, sharded_batch)

JAX `shard_map` / `jit` + sharding (최신)

JAX 의 최신 권장 패턴. pmap 보다 더 유연한 샤딩 명세.

from jax.sharding import Mesh, PartitionSpec as P
from jax.experimental import mesh_utils

# 8 GPU 를 (data, model) 2D 메시로
devices = mesh_utils.create_device_mesh((2, 4))
mesh = Mesh(devices, ("data", "model"))

# 텐서 샤딩 명세
data_sharding = jax.sharding.NamedSharding(mesh, P("data", None))
model_sharding = jax.sharding.NamedSharding(mesh, P(None, "model"))

@functools.partial(jax.jit, in_shardings=(model_sharding, data_sharding))
def train_step(params, batch):
    ...

Collective 통신 종류

SPMD 프로그램의 동기화 지점.

flowchart LR
    subgraph AR["All-Reduce"]
        AR0["R0: 3"] & AR1["R1: 5"] & AR2["R2: 2"] --> SUM["합: 10"]
        SUM --> AR0R["R0: 10"] & AR1R["R1: 10"] & AR2R["R2: 10"]
    end

연산	설명	사용처
All-Reduce	모든 노드 값 집계 후 전체 배포	gradient 합산
Broadcast	한 노드에서 전체로 배포	파라미터 초기 동기화
Scatter	한 노드에서 각 노드로 분배	배치 분할
Gather	각 노드에서 한 노드로 집결	결과 모으기
All-Gather	Scatter 의 역: 분산 배열 전체 복원	FSDP 파라미터 복원
Reduce-Scatter	Reduce + 결과를 노드별로 샤딩	FSDP gradient 집계
Barrier	모든 노드 도착 대기	단순 동기화

SPMD 의 한계

1. Heterogeneous 워크로드 어려움

모든 노드가 같은 일을 한다는 가정. 일부 노드만 다른 작업이 필요한 경우 ([[분산 학습#pipeline-parallelism|Pipeline Parallelism]] 등) MIMD 스타일로 전환 필요.

2. Load imbalance

각 노드의 작업량이 다르면 빠른 노드가 느린 노드를 기다림. 균형 분할이 중요.

Rank 0: 배치 크기 1024 (처리 완료: t=1.0s)
Rank 1: 배치 크기 1024 (처리 완료: t=1.0s)
Rank 2: 배치 크기 1024 (처리 완료: t=1.0s)
Rank 3: 배치 크기 1024 이지만 긴 시퀀스 (처리 완료: t=2.5s)
          ↑ 모든 rank 가 rank 3 을 기다림 (bubble)

3. 통신 비용

all_reduce, all_gather 같은 collective 가 노드 수에 따라 비용 급증. 100 노드 → 10,000 노드 확장 시 통신 패턴 재설계 필요.

Ring-AllReduce 같은 최적화된 통신 토폴로지가 실제로는 O(N) 이 아닌 O(1) 에 가까운 성능을 낸다.

SPMD 와 Data Parallelism 관계

Data Parallelism (데이터 병렬) 은 SPMD 의 가장 흔한 구현 패턴이다.

Data Parallelism 구조:
  전체 배치 N
  ├── GPU 0: 배치 0 ~ N/k (같은 모델, 다른 배치)
  ├── GPU 1: 배치 N/k ~ 2N/k
  └── GPU k-1: ...
  → backward: gradient all-reduce
  → optimizer: 동기화된 weight update

SPMD 관점에서 각 GPU 는 완전히 동일한 코드를 실행하되 rank 로 배치 슬라이스를 식별한다. DDP 와 FSDP 모두 이 패턴.

반면 Tensor Parallelism 은 같은 배치를 여러 GPU 에 나눠 처리. 같은 코드이지만 데이터 대신 연산(행렬 곱) 를 분할 → 이것도 SPMD 이지만 데이터 분할 축이 다르다.

함정

[!WARNING] XLA/JAX 에서 동적 shape 주의: pmap 내부 shape 이 rank 마다 달라지면 XLA 재컴파일 트리거. 배치 크기를 rank 수의 배수로 패딩해 shape 고정.

[!CAUTION] MPI 프로세스 중 하나만 죽어도 전체 중단: SPMD 는 모든 rank 가 같은 코드를 실행하므로 장애 허용이 어렵다. Checkpoint + restart 전략 필수.

GPU: 그래픽/ML 병렬 프로세서

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

GPU (Graphics Processing Unit) 는 원래 3D 그래픽 렌더링을 위해 설계됐지만, massively parallel 아키텍처가 딥러닝의 행렬 연산과 완벽히 맞아 현재 AI 컴퓨팅의 표준 하드웨어가 됐다. NVIDIA, AMD, Intel 이 3대 제조사.

언제 쓰이나

딥러닝 모델 학습 / 추론
LLM inference serving (vLLM, TGI 등)
3D 그래픽 렌더링, 영상 처리
과학 시뮬레이션 (HPC), 암호화폐 채굴
CUDA 에코시스템이 필요한 모든 병렬 워크로드

아키텍처 개요

전체 계층 구조

flowchart TB
    GPU["GPU 칩"] --> GPC["GPC\n(Graphics Processing Cluster)"]
    GPC --> SM["SM (Streaming Multiprocessor)\n× 132개 (H100)"]
    SM --> CUDA["CUDA Core × 128\n(FP32 ALU)"]
    SM --> TC["Tensor Core × 4\n(행렬곱 전용)"]
    SM --> Shared["Shared Memory\n+ L1 Cache (256KB)"]
    SM --> Reg["Register File\n(65536 × 32bit)"]
    GPU --> L2["L2 Cache (50MB)"]
    GPU --> HBM["HBM3 (80GB, 3.35 TB/s)"]

SM (Streaming Multiprocessor)

NVIDIA GPU 의 핵심 실행 단위. 각 SM 은 독립적인 연산 블록.

H100 (Hopper 아키텍처) SM 구성:

128개 FP32 CUDA 코어 (일반 연산)
4개 Tensor Core (3세대 Hopper TC: FP8/FP16/BF16/FP32 지원)
256KB L1 cache + Shared Memory (프로그래머 제어 가능)
Register file 65,536 × 32bit (스레드 간 공유 없음)
Warp Scheduler 4개 (32스레드 warp 관리)

H100 SXM5: 132 SM × (128 FP32 + 4 Tensor Core) = 16,896 CUDA cores

SIMT: GPU 실행 모델

[[simt|SIMT (Single Instruction Multiple Thread)]] 는 GPU 의 병렬 실행 모델.

Warp 실행

Warp = 32개 스레드의 묶음 (하드웨어 실행 단위)
 ┌──────────────────────────────────┐
 │ Thread 0  Thread 1  ... Thread 31│   ← 동일 명령 동시 실행
 └──────────────────────────────────┘
           Warp 0 (32T)

SM 은 최대 64 warp (2048 스레드) 를 동시에 관리
활성 warp 중 하나가 메모리 대기 → 즉시 다른 warp 전환 (zero-cost context switch)

Branch Divergence (분기 발산)

// SIMT 의 함정: if-else 분기
if (threadIdx.x % 2 == 0) {
    do_A();  // 짝수 스레드만
} else {
    do_B();  // 홀수 스레드만
}
// Warp 내 분기 → 두 경로 순차 실행 (SIMD 효율 50% 낙하)

Warp 내 스레드가 다른 분기를 탈 경우, 두 경로를 순차적으로 실행하고 비활성 스레드는 마스킹. 성능 반감.

메모리 계층

flowchart TB
    subgraph "빠름 (작음)"
        Reg["Register\n(스레드 전용, ~1 cycle)"]
        Shared["Shared Memory\n(SM 내 공유, ~1 cycle, 128-256KB)"]
        L1["L1 Cache\n(SM 내, ~10 cycle, Shared 와 공유)"]
    end
    subgraph "느림 (큼)"
        L2["L2 Cache\n(전체 GPU 공유, ~200 cycle, 50MB)"]
        HBM["HBM (Global Memory)\n(~500 cycle, 80GB, 3.35 TB/s H100)"]
    end
    Reg --> Shared --> L1 --> L2 --> HBM

계층	크기	지연	대역폭	접근
Register	스레드별 64KB	~1 cycle	최고	스레드 전용
Shared Memory	SM당 최대 228KB	~1 cycle	매우 높음	SM 내 블록 공유
L1 Cache	SM당 128KB	~28 cycle	높음	자동
L2 Cache	50MB (H100)	~200 cycle	중간	자동
HBM (Global)	80GB (H100)	~500 cycle	3.35 TB/s	전체 커널

[!IMPORTANT] 메모리 대역폭이 병목인 커널(bandwidth-bound)을 컴퓨트 집약 커널(compute-bound)로 바꾸는 것이 GPU 최적화의 핵심. Shared Memory 활용과 메모리 coalescing 이 주요 기법.

Tensor Core: 딥러닝 특화 유닛

CUDA 코어가 scalar(단일 FP32) 연산을 하는 반면, Tensor Core 는 4×4 행렬 연산을 1 클럭에 처리.

Tensor Core (Hopper, 3세대):
  D = A × B + C
  A: [16×16], B: [16×8], C/D: [16×8]
  지원 형식: FP8, FP16, BF16, FP32, INT8, INT4

CUDA Core (FP32):
  d = a * b + c   (scalar)
  1개 연산/clock

Tensor Core 성능 (H100 SXM5)

정밀도	피크 TFLOPS
FP64	66.9
FP32 (CUDA Core)	133.8
TF32 (Tensor Core)	989
FP16/BF16 (Tensor Core)	1,979
FP8 (Tensor Core)	3,958
INT8 (Tensor Core)	3,958

세대 비교

flowchart LR
    V100["V100 (Volta 2017)\nTensor Core 1세대\n125 TFLOPS FP16\n16-32GB HBM2"] --> A100["A100 (Ampere 2020)\nTensor Core 3세대\nSparse 지원\n312 TFLOPS FP16\n40-80GB HBM2e"]
    A100 --> H100["H100 (Hopper 2022)\nTensor Core 4세대\nFP8 지원\n1,979 TFLOPS BF16\n80GB HBM3"]
    H100 --> B200["B200 (Blackwell 2024)\nFP4 지원\n9 PFLOPS FP8\n192GB HBM3e"]

GPU	아키텍처	BF16 TFLOPS	HBM	NVLink
V100	Volta (2017)	125	32GB	NVLink 2
A100	Ampere (2020)	312	80GB	NVLink 3
H100	Hopper (2022)	1,979	80GB	NVLink 4
H200	Hopper (2024)	1,979	141GB HBM3e	NVLink 4
B200	Blackwell (2024)	4,500	192GB	NVLink 5

소프트웨어 스택

flowchart TB
    App["PyTorch / TensorFlow / JAX"] --> Lib["cuDNN / cuBLAS / NCCL"]
    Lib --> CUDA["CUDA Runtime / Driver"]
    CUDA --> HW["NVIDIA GPU HW"]
    App2["OpenCL / ROCm (AMD)"] --> HW2["AMD GPU"]
    Triton["OpenAI Triton\n(Python CUDA 커널)"] --> CUDA

라이브러리	역할
CUDA	NVIDIA 독점 GPU 프로그래밍 API
cuDNN	CNN, Transformer 최적화 커널
cuBLAS	GEMM 최적화
NCCL	멀티 GPU 통신 (all-reduce 등)
Triton	Python 에서 CUDA 커널 작성 (OpenAI)
ROCm	AMD GPU 대응 오픈소스 스택

실전: CUDA / PyTorch 최적화

기본 행렬곱 (CUDA)

// naive: global memory 직접 접근 (느림)
__global__ void matmul_naive(float *A, float *B, float *C, int N) {
    int row = blockIdx.y * blockDim.y + threadIdx.y;
    int col = blockIdx.x * blockDim.x + threadIdx.x;
    float sum = 0.0f;
    for (int k = 0; k < N; k++) {
        sum += A[row * N + k] * B[k * N + col];
    }
    C[row * N + col] = sum;
}

// shared memory tiling: L1 활용 (빠름)
__global__ void matmul_tiled(float *A, float *B, float *C, int N) {
    __shared__ float As[TILE][TILE];
    __shared__ float Bs[TILE][TILE];
    // ... tiling 로직
}

PyTorch 에서 Tensor Core 활용

import torch

# Tensor Core 활성화: AMP (Automatic Mixed Precision)
from torch.cuda.amp import autocast, GradScaler

scaler = GradScaler()

with autocast(dtype=torch.bfloat16):  # BF16 → Tensor Core 자동 사용
    output = model(input)
    loss = criterion(output, target)

scaler.scale(loss).backward()
scaler.step(optimizer)
scaler.update()

Flash Attention: 메모리 효율 Attention

# standard: O(seq^2) HBM 접근
# flash attention: HBM 접근 최소화, Shared Memory 활용
import torch.nn.functional as F

# PyTorch 2.0+ 기본 내장 (SDPA)
with torch.backends.cuda.sdp_kernel(
    enable_flash=True,
    enable_math=False,
    enable_mem_efficient=True
):
    output = F.scaled_dot_product_attention(q, k, v)

CPU 와 비교

flowchart LR
    subgraph "CPU (Intel Xeon)"
        c_core["8-64 코어\n복잡한 ALU\n분기 예측, OoO 실행"]
        c_mem["DDR5 ~200 GB/s"]
        c_core --> c_mem
    end
    subgraph "GPU (H100)"
        g_sm["132 SM\n16,896 CUDA Core\n528 Tensor Core"]
        g_hbm["HBM3 3.35 TB/s"]
        g_sm --> g_hbm
    end

항목	CPU (Xeon)	GPU (H100)
코어 수	8-64	16,896 CUDA
클럭	3-5 GHz	~1.98 GHz
메모리 BW	~200 GB/s	3.35 TB/s
분기 처리	최적화 (예측)	비효율 (warp divergence)
단일 스레드 성능	높음	낮음
병렬 스루풋	낮음	극도로 높음
딥러닝 행렬곱	낮음 (~2 TFLOPS)	1,979 TFLOPS (BF16)

다중 GPU 연결

flowchart TB
    subgraph "단일 서버 (DGX H100)"
        GPU0 <-->|"NVLink 4\n900 GB/s"| GPU1
        GPU1 <-->|"NVLink 4"| GPU2
        GPU2 <-->|"NVLink 4"| GPU3
        GPU0 <-->|"NVLink 4"| GPU3
    end
    subgraph "서버 간"
        Server1 <-->|"InfiniBand NDR\n400 Gb/s"| Server2
        Server2 <-->|"InfiniBand"| Server3
    end

NVLink: 노드 내 GPU 간 고속 상호연결 (단방향 900 GB/s, H100)
NVSwitch: NVLink 스위치 패브릭, 8-16 GPU 완전 연결
InfiniBand: 노드 간 연결, NCCL all-reduce 에 활용

흔한 함정

[!WARNING]

메모리 coalescing 무시 = warp 32 스레드가 연속 주소 접근 안 하면 실효 BW 1/32. 메모리 레이아웃 설계 중요.

작은 커널 남발 = 커널 launch overhead 누적. 여러 op 을 하나로 fusion (torch.compile / Triton).

CPU-GPU 동기화 남발 = .item(), print(tensor) 호출 시 CPU 동기화 발생. 학습 루프에서 최소화.

Host-Device 전송 병목 = CPU 에서 GPU 로 데이터 복사(PCIe 16-64 GB/s)가 병목. DataLoader 의 pin_memory=True, num_workers 활용.

AMP 미사용 = FP32 로 학습 시 Tensor Core 를 사용하지 못함. torch.autocast('cuda') 로 BF16/FP16 전환.

NPU (Neural Processing Unit): 엣지 AI 칩

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

NPU (Neural Processing Unit) 는 모바일/엣지 디바이스용 저전력 AI 가속기. 스마트폰, 노트북, IoT 에 내장되어 온디바이스 AI 추론을 담당한다.

[[gpu|GPU]] 는 범용 병렬 연산을, [[tpu|TPU]] 는 데이터센터 규모 학습을 처리하는 데 비해, NPU 는 배터리 구동 장치에서 수 와트 이하로 신경망 추론을 실행하는 데 특화된다.

언제 쓰이나

스마트폰 실시간 기능: 얼굴 인식 (Face ID), 사진 처리 (Portrait mode, Deep Fusion)
온디바이스 음성 인식: Siri, Google Assistant 오프라인 모드
온디바이스 LLM: Apple Intelligence (iOS 18+), Copilot+ (Windows 11)
실시간 번역: 오프라인 번역 앱
헬스케어 센싱: 심박, 혈중 산소 모니터링
자율주행 엣지 유닛: 산업용 IoT, 로봇

컴퓨트 계층 구조

flowchart TB
    subgraph "클라우드 / 데이터센터"
        GPU["GPU (H100, A100)\n학습 + 대규모 추론\n300-700W"]
        TPU2["TPU v4/v5\n대규모 Transformer 학습\n170-250W"]
    end
    subgraph "엣지 서버"
        JET["NVIDIA Jetson\n엣지 서버급 추론\n10-40W"]
    end
    subgraph "모바일 / 온디바이스"
        ANE["Apple ANE\niPhone, Mac 내장\n1-5W"]
        HEX["Qualcomm Hexagon\nSnapdragon 내장\n1-5W"]
        ETpu["Google Edge TPU\nCoral USB / M.2\n2W"]
        INPU["Intel NPU\nMeteor Lake+\n5-15W"]
    end
    GPU --> JET
    JET --> ANE
    JET --> HEX
    JET --> INPU

NPU 아키텍처 특성

NPU 는 [[gpu|GPU]] 와 같은 범용 병렬 프로세서가 아닌, 신경망 연산 (행렬 곱, 컨볼루션, 활성화 함수) 에 최적화된 고정 파이프라인 을 가진다.

핵심 특성

저전력: 배터리 구동 (수 W ~ 수십 W)
정수 연산 위주: INT8, INT4 로 추론 최적화 (학습은 FP32/BF16)
온디바이스 추론: 개인정보 보호, 지연시간 낮음, 인터넷 불필요
고정 연산 그래프: GPU/CPU 처럼 임의 커널을 실행하는 게 아니라, 컴파일된 모델 그래프를 실행

INT8 추론

[[quantization|Quantization]] 을 통해 FP32(32비트) 모델 가중치를 INT8(8비트) 로 변환. 메모리 4배 절약, 연산 4-8배 빠름, 정확도 손실은 일반적으로 1% 이내.

FP32 가중치: [-0.234, 0.891, -1.23, ...]
                    ↓ Post-Training Quantization
INT8 가중치:  [-30,   114,  -157, ...]  + scale factor

NPU 는 INT8 행렬 곱 유닛을 하드웨어에 내장해 FP32 대비 에너지 효율이 10배 이상.

GPU / CPU / NPU 비교

항목	CPU	GPU	NPU
설계 목적	범용 순차 연산	범용 병렬 연산	신경망 추론 특화
코어 수	8-128	수천~수만	수십~수백 (행렬 유닛)
정밀도	FP32/INT	FP16/FP32	INT4/INT8
전력 소모	15-350W	100-700W	1-20W
지연시간	낮음 (단일)	배치 지향	즉각 처리
유연성	최고	높음	낮음 (고정 연산)
프로그래밍	직접	CUDA / OpenCL	Core ML / ONNX

대표 NPU

Apple Neural Engine (ANE)

flowchart LR
    CPU["CPU\n(성능 코어)"] --> Dispatch["OS 디스패처\n(Core ML)"]
    GPU2["GPU\n(Metal)"] --> Dispatch
    ANE["Apple ANE"] --> Dispatch
    Dispatch --> App["앱 추론 요청"]

Core ML 프레임워크가 모델의 각 연산 레이어를 CPU / GPU / ANE 중 최적 유닛에 자동 분배한다.

칩	출시	TOPS	주요 기능
A11 Bionic	2017	0.6	최초 ANE, Face ID
A14 Bionic	2020	11	5nm, Neural Engine 16코어
A16 Bionic	2022	15.8	iPhone 14 Pro
A17 Pro	2023	35	3nm, iPhone 15 Pro
M2	2022	15.8	Mac, iPad Pro
M4	2024	38	Apple Intelligence 온디바이스 LLM

TOPS (Tera Operations Per Second): 초당 1조 연산. NPU 성능 측정 단위.

ANE 는 Core ML 프레임워크를 통해서만 접근 가능하다 (직접 프로그래밍 불가). Apple Intelligence 의 온디바이스 LLM 추론은 ANE + CPU + GPU 를 동시에 활용한다.

Qualcomm Hexagon DSP/NPU

Snapdragon 8 Gen 시리즈에 내장. Hexagon DSP 위에 HTP (Hexagon Tensor Processor) 가 추가된 구조.

Android 기기 대부분의 NPU 역할
Qualcomm AI Engine API, ONNX Runtime (QNN 백엔드) 로 접근
Snapdragon 8 Gen 3: 98 TOPS

Google Edge TPU (Coral)

[[tpu|TPU]] 아키텍처를 엣지용으로 축소한 제품. USB Accelerator (2W) 와 M.2 모듈 형태.

TensorFlow Lite 모델만 지원
단 8MB 온칩 SRAM 으로 모델이 작아야 함 (MobileNet 급)
라즈베리파이에 USB 로 연결해 추론 보조

Intel NPU (Meteor Lake+)

2024년 출시된 Intel Core Ultra 칩에 내장. 저전력 AI 워크로드를 CPU, GPU 가 아닌 NPU 에 오프로드.

OpenVINO, ONNX Runtime (OpenVINO 백엔드) 지원
Microsoft Copilot+ PC 의 요건 (40 TOPS 이상)

실전: Core ML 로 ANE 활용 (iOS/Swift)

import CoreML
import Vision

// 1. 모델 로드 (ANE 자동 활용)
let config = MLModelConfiguration()
config.computeUnits = .cpuAndNeuralEngine  // ANE 우선, 폴백은 CPU

guard let model = try? MyVisionModel(configuration: config) else { return }

// 2. 이미지 분류 요청
let request = VNCoreMLRequest(model: VNCoreMLModel(for: model.model)!) { request, _ in
    guard let results = request.results as? [VNClassificationObservation] else { return }
    let top = results.first!
    print("\(top.identifier): \(top.confidence)")
}

let handler = VNImageRequestHandler(ciImage: ciImage)
try? handler.perform([request])

computeUnits = .cpuAndNeuralEngine 로 ANE 를 명시하면 Core ML 이 지원되는 레이어를 ANE 로 보낸다. .all 은 GPU 도 포함.

실전: ONNX Runtime 으로 NPU 활용 (Python)

import onnxruntime as ort
import numpy as np

# Qualcomm NPU (QNN) 또는 Intel NPU (OpenVINO) 백엔드
providers = [
    ("QNNExecutionProvider", {"backend_type": "htp"}),  # Qualcomm Hexagon
    "CPUExecutionProvider",  # 폴백
]

session = ort.InferenceSession("model_int8.onnx", providers=providers)

input_name = session.get_inputs()[0].name
result = session.run(
    None,
    {input_name: np.random.randn(1, 3, 224, 224).astype(np.float32)}
)
print(result[0].argmax())

INT8 ONNX 모델을 생성하려면 먼저 [[quantization|Post-Training Quantization]] 으로 변환해야 한다:

from onnxruntime.quantization import quantize_dynamic, QuantType

quantize_dynamic(
    model_input="model_fp32.onnx",
    model_output="model_int8.onnx",
    weight_type=QuantType.QInt8,
)

TOPS 비교 (2024-2025 대표 기기)

기기	NPU	TOPS	출시
iPhone 15 Pro	A17 Pro ANE	35	2023
iPhone 16 Pro	A18 Pro ANE	38	2024
MacBook Pro M4	M4 ANE	38	2024
Galaxy S24 Ultra	Snapdragon 8 Gen 3 Hexagon	98	2024
Microsoft Surface Pro 11	Snapdragon X Elite XDNA	45	2024
Lenovo ThinkPad X1 Carbon Gen 13	Intel Core Ultra 7 NPU	47	2025

[!IMPORTANT] TOPS 수치는 INT8 기준이 일반적이나, 벤더마다 INT4/INT8/FP16 기준이 달라 단순 비교는 어렵다. 실제 추론 속도는 지원하는 op 범위와 모델 구조에 따라 크게 달라진다.

모바일 추론 파이프라인

flowchart LR
    M["학습된 모델\n(FP32)"] --> Q["Quantization\n(INT8/INT4)"]
    Q --> C["플랫폼 컴파일\n(Core ML / TFLite / ONNX)"]
    C --> NPU2["NPU 실행\n(온디바이스)"]
    NPU2 --> R["추론 결과\n(저지연, 오프라인)"]
    style NPU2 fill:#e8f5e9,stroke:#388e3c

함정

[!WARNING] NPU 는 모든 연산을 가속하지 않는다. 지원하지 않는 연산자 (op) 가 있으면 자동으로 CPU 로 폴백된다. 폴백이 많으면 NPU 와 CPU 간 데이터 복사 오버헤드가 오히려 성능을 떨어뜨린다. 반드시 프로파일러로 op 지원 여부를 확인해야 한다.

[!CAUTION] INT8 Quantization 은 calibration 없이 하면 정확도가 급락한다. Weight 만 양자화하는 dynamic quantization 과 달리, static quantization 은 대표 데이터셋으로 activation 분포를 측정하는 calibration 이 필수다.

[!IMPORTANT] NPU API 는 플랫폼 종속이 심하다. ANE 는 Core ML 만, Hexagon 은 QNN/ONNX, Edge TPU 는 TFLite 만 지원한다. ONNX 를 중간 포맷으로 쓰면 플랫폼 간 이식이 쉬워진다.

Systolic Array

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

Systolic Array 는 격자 형태로 배치된 다수의 Processing Element (PE) 가, 입력 데이터가 박동(systolic)처럼 격자를 가로질러 흐르는 동안 각 PE 가 곱셈+누적(MAC) 을 수행하는 하드웨어 구조다.

H.T. Kung 이 1978년 제안한 개념이며, [[TPU]] 의 핵심 컴퓨팅 단위로 부활했다. TPU 에서는 MXU (Matrix Multiply Unit) 으로 불린다.

{}

이름의 유래는 심장 박동(systole): 데이터가 규칙적으로 PE 사이를 리드미컬하게 펌핑하며 이동하는 모습에서 온다.

언제 쓰이나

대규모 행렬곱(GEMM) 이 반복적으로 필요한 딥러닝 학습/추론
전통적인 범용 프로세서(CPU/GPU)로는 메모리 대역폭 병목이 발생하는 상황
Google TPU, 일부 Edge AI 칩(Google Edge TPU, 삼성 Exynos NPU), FPGA 구현 등

Systolic Pumping: 핵심 동작 원리

행렬 곱셈 C = A × B 의 기본 연산:

C[i][j] += A[i][k] * B[k][j]   (k = 0 ~ K-1)

Systolic Array 에서는 이 연산을 PE 격자가 담당한다:

flowchart LR
    subgraph "A 행렬 (좌에서 우로 이동)"
        a0["a[0][k]"]
        a1["a[1][k]"]
    end
    subgraph "B 행렬 (위에서 아래로 이동)"
        b0["b[k][0]"]
        b1["b[k][1]"]
    end
    a0 --> PE00["PE(0,0)\nMAC"]
    a0 --> PE01["PE(0,1)\nMAC"]
    a1 --> PE10["PE(1,0)\nMAC"]
    a1 --> PE11["PE(1,1)\nMAC"]
    b0 --> PE00
    b0 --> PE10
    b1 --> PE01
    b1 --> PE11
    PE00 --> out00["C[0][0]"]
    PE01 --> out01["C[0][1]"]
    PE10 --> out10["C[1][0]"]
    PE11 --> out11["C[1][1]"]

각 클럭 사이클마다:

A 행렬 원소가 왼쪽에서 오른쪽으로 이동
B 행렬 원소가 위에서 아래로 이동
각 PE 가 수신한 두 값을 곱해 누적

Weight Stationary vs Output Stationary

[[TPU]] 는 Weight Stationary 방식을 채택한다.

방식	정주(고정) 데이터	흐름 데이터	적합한 상황
Weight Stationary	가중치 (B)	활성화 (A)	추론, 가중치 재사용
Output Stationary	부분합 출력 (C)	가중치 + 활성화	작은 필터 합성곱
Input Stationary	활성화 입력 (A)	가중치	모바일 NPU

추론 시 가중치는 고정, 입력(활성화)만 바뀌므로 Weight Stationary 가 이상적.

3가지 우아함

1. 메모리 접근 최소화

각 가중치(weight)는 PE 에 한 번 적재 후 수많은 활성화 벡터와의 곱셈에 재사용된다. DRAM/HBM 접근 횟수가 극적으로 줄어든다.

전통 방식: C[i][j] 계산 시마다 A[i][k], B[k][j] 메모리 로드 → K 번 * M*N 회 = K*M*N 접근
Systolic:  B 행렬 한 번 적재 → A 원소마다 재사용 → M*N + K*M 회 접근

2. 완벽한 데이터 재사용

한 활성화 값이 PE 배열을 가로질러 이동하면서 N 개의 PE 와 연산. 단 1번 메모리에서 읽어 N 번 사용.

3. 단순한 제어 회로

모든 PE 가 동일한 동작(MAC: Multiply-Accumulate) 반복 실행. CPU 의 분기 예측, OoO 실행 등 복잡한 제어 회로가 불필요 → 동일 면적에 훨씬 많은 연산 유닛 배치 가능.

Google TPU MXU 실제 구현

TPU 내부 아키텍처

flowchart TB
    HBM["HBM (고대역폭 메모리)"] --> UB["Unified Buffer (on-chip SRAM)"]
    UB --> WF["Weight FIFO"]
    WF --> MXU["MXU (Systolic Array)"]
    MXU --> ACC["Accumulators (결과 임시 저장)"]
    ACC --> VU["Vector Unit (softmax, norm, pool 등)"]
    VU --> UB
    VU --> HBM

세대	MXU 크기	피크 성능	메모리
TPU v1	256×256	92 TOPS (INT8)	8 GB LPDDR
TPU v2	128×128 × 2	45 TFLOPS (BF16)	16 GB HBM
TPU v3	128×128 × 2	123 TFLOPS (BF16)	32 GB HBM
TPU v4	128×128 × 4	275 TFLOPS (BF16)	32 GB HBM
TPU v5e (Trillium)	-	~394 TFLOPS (BF16)	16 GB HBM

[!IMPORTANT] TPU MXU 는 BF16 (bfloat16) 형식을 사용한다. BF16 은 FP32 와 같은 exponent(8bit) 범위를 유지하면서 mantissa 를 줄여(7bit), 학습 안정성을 보존하면서 메모리 대역폭을 절반으로 줄인다.

Unified Buffer 역할

MXU 가 쉬지 않고 연산하려면 데이터 공급이 끊기지 않아야 한다. Unified Buffer (on-chip SRAM, 16-128MB) 가 HBM 과 MXU 사이 버퍼 역할을 맡는다.

재사용 계수(reuse factor) = 행렬 차원 N
행렬 N=1024 이면: 각 가중치 원소 1024 번 재사용
→ 효과적인 메모리 대역폭 = HBM 실제 BW × 1024

GEMM 과 딥러닝 연산 맵핑

딥러닝의 주요 연산은 대부분 GEMM 으로 표현된다:

딥러닝 연산	GEMM 형태	비고
`nn.Linear(in, out)`	`[B, in] × [in, out]`	가장 기본
Attention `Q @ K.T`	`[BH, seq, d] × [BH, d, seq]`	배치 GEMM
Conv2d (im2col)	`[BOHOW, ICKHKW] × [ICKHKW, OC]`	변환 필요
LayerNorm, Softmax	GEMM 아님	Vector Unit 에서 처리

Tiling 전략

MXU 가 128×128 이고 행렬이 1024×1024 라면 타일링:

A[1024×1024] = 8×8 타일 (각 128×128)
B[1024×1024] = 8×8 타일

C[i][j] = sum over k { A_tile[i][k] × B_tile[k][j] }

XLA 컴파일러가 타일링 크기를 자동 결정하므로 수동 지정 불필요.

CPU / GPU 와 비교

flowchart LR
    subgraph "CPU (범용)"
        c1["DRAM"] --> c2["L3/L2/L1 Cache"] --> c3["복잡 ALU\n분기, OoO 실행"]
    end
    subgraph "GPU (SIMT)"
        g1["HBM"] --> g2["L2/L1 Cache"] --> g3["CUDA 코어 / Tensor Core\n(Warp 32 스레드)"]
    end
    subgraph "TPU (Systolic)"
        t1["HBM"] --> t2["Unified Buffer\n(on-chip SRAM)"] --> t3["MXU (PE 격자)\n단순 MAC 반복"]
    end

항목	CPU	GPU (H100)	TPU v4
피크 컴퓨트 (BF16)	~2 TFLOPS	1,979 TFLOPS	275 TFLOPS
메모리 대역폭	~100 GB/s	3.35 TB/s	1.2 TB/s
제어 회로 비중	매우 높음	중간	낮음
범용성	최고	높음	ML 특화
실제 MFU	~5%	30-50%	60-70%

MFU (Model FLOP Utilization): 이론 피크 대비 실제 활용률. TPU MFU 가 GPU 보다 높다.

실전: XLA + JAX 로 MXU 최대 활용

import jax
import jax.numpy as jnp
from functools import partial

# XLA jit 컴파일: TPU에서 MXU 타일링 자동 최적화
@partial(jax.jit, backend='tpu')
def matmul(a: jnp.ndarray, b: jnp.ndarray) -> jnp.ndarray:
    return jnp.dot(a, b)

# 배치 행렬곱 (vmap으로 자동 벡터화)
@jax.jit
def batched_matmul(a, b):
    return jax.vmap(jnp.dot)(a, b)

# Transformer 셀프 어텐션 (MXU 에 최적화된 einsum)
def scaled_dot_product_attention(q, k, v, scale):
    # q, k, v: [batch, heads, seq, dim]
    scores = jnp.einsum('bhid,bhjd->bhij', q, k) * scale
    weights = jax.nn.softmax(scores, axis=-1)
    return jnp.einsum('bhij,bhjd->bhid', weights, v)

XLA 가 jnp.dot, jnp.einsum 을 HLO (High-Level Optimizer IR) 로 낮추고, MXU 크기에 맞는 타일을 생성한다.

배치 크기 권장

MXU 효율 극대화: seq_len, hidden_dim 등이 128(또는 256) 배수여야 함
예: hidden_dim=512(ok), 500(비효율), 768(ok)
    batch_size: 8, 16, 32 등 2의 거듭제곱 권장

한계

MXU 크기 미스매치 (Underutilization)

MXU 128×128 에 64×64 행렬을 넣으면:

실제 연산: 64 × 64 = 4,096 MAC
MXU 최대: 128 × 128 = 16,384 MAC
활용률: 25%

회피 전략: 배치 크기 늘리기, 행렬 패딩, 모델 차원을 128(또는 256) 배수로 설계.

비행렬 연산 병목

Softmax, LayerNorm, ReLU 등은 Vector Unit 에서 처리. MXU 와 VU 가 번갈아 작동하면 파이프라인 낭비. Fused kernel (XLA 가 자동) 으로 경감.

희소 행렬 비효율

대부분 원소가 0인 sparse matrix 에서도 모든 PE 가 쓸모없는 곱셈을 실행. TPU v4+ 에서 SparseCore 별도 추가로 일부 해소.

흔한 함정

[!WARNING]

행렬 차원이 MXU 크기 배수 아님 = 자동 패딩 낭비, 활용률 급락. 모델 설계 시 128/256 배수 권장.

작은 배치 크기 = MXU 활용률 급락. 추론 시 배치 큐잉(dynamic batching)으로 보정.

jit 없이 실행 = 각 연산이 개별 커널 실행, XLA 최적화 불가. 반드시 @jax.jit 적용.

element-wise 연산 남발 = Vector Unit 병목으로 MXU idle. XLA 의 op-fusion 에 맡기고 개별 kernel 실행 최소화.

TPU v1 사용 시 INT8 고정 = 추론 전용, 학습 불가. v2+ 에서 BF16 학습 가능.

TPU (Tensor Processing Unit): Google 의 ML ASIC

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

TPU (Tensor Processing Unit) 는 Google 이 딥러닝 워크로드 전용으로 설계한 ASIC (Application-Specific Integrated Circuit). 2015년 내부 투입, 2017년 ISCA 발표. GPU 처럼 범용 병렬 프로세서가 아닌 행렬 곱셈 특화 가속기.

핵심 컴퓨팅 단위는 [[systolic-array|Systolic Array]] 기반 MXU (Matrix Multiply Unit).

언제 쓰이나

대규모 Transformer (LLM, Vision Transformer) 학습/추론
Google Gemini, PaLM, BERT 등 Google 모델 대부분 TPU 에서 학습
JAX/XLA 스택으로 분산 학습을 구현할 때
GPU 에 비해 비용 효율($/TFLOPS) 이 중요한 장기 학습

핵심 아키텍처

MXU (Matrix Multiply Unit)

[[systolic-array|Systolic Array]] 를 이용한 대규모 병렬 행렬곱. 가중치(weight)가 PE 격자에 정주(stationary)하고 활성화(activation)가 격자를 통과하며 MAC 수행.

flowchart TB
    HBM["HBM (고대역폭 메모리)"] --> UB["Unified Buffer\n(on-chip SRAM 32-128MB)"]
    UB --> WF["Weight FIFO"]
    WF --> MXU["MXU (Systolic Array)\nBF16 행렬곱"]
    MXU --> ACC["Accumulators\n(FP32 누적)"]
    ACC --> VU["Vector Unit\n(softmax, norm, ReLU 등)"]
    VU --> UB
    UB --> HBM

bfloat16

FP32 exponent(8bit) + 축소된 mantissa(7bit). GPU 의 FP16(5+10) 과 달리 FP32 와 exponent 범위 동일 → 오버플로/언더플로 없이 학습 안정성 유지.

형식	exponent	mantissa	동적 범위
FP32	8bit	23bit	FP32
FP16	5bit	10bit	좁음 (오버플로 위험)
BF16	8bit	7bit	FP32 와 동일
FP8 E4M3	4bit	3bit	매우 좁음 (추론용)

세대별 발전

flowchart LR
    V1["TPU v1\n2015\n추론 전용\nINT8"] --> V2["TPU v2\n2017\n학습 지원\nBF16 + HBM"]
    V2 --> V3["TPU v3\n2018\n액체 냉각\n2x v2"]
    V3 --> V4["TPU v4\n2021\n4096 칩 pod\nOCS 상호연결"]
    V4 --> V5["TPU v5e/p\n2023\n비용/성능 두 트랙"]
    V5 --> V6["Trillium v6\n2024\n5x vs v5e"]

세대별 상세

세대	출시	MXU 크기	피크 TFLOPS (BF16)	HBM	특징
v1	2015	256×256	92 TOPS (INT8)	없음	추론 전용, AlphaGo 사용
v2	2017	128×128 × 2	45 TFLOPS	16 GB	최초 BF16 학습, HBM 도입
v3	2018	128×128 × 2	123 TFLOPS	32 GB	액체 냉각, v2 2배
v4	2021	128×128 × 4	275 TFLOPS	32 GB	OCS 광 상호연결, PaLM 학습
v5e	2023	-	~197 TFLOPS	16 GB	비용 효율 트랙
v5p	2023	-	~459 TFLOPS	95 GB	성능 트랙
Trillium (v6)	2024	-	~918 TFLOPS	32 GB	v5e 대비 4.7x 컴퓨트

TPU Pod: 수천 칩 연결

개별 TPU 칩을 고속 인터커넥트로 묶은 단위. Pod 안에서 칩들이 dedicated ICI (Inter-Chip Interconnect) 로 연결.

flowchart TB
    subgraph "TPU v4 Pod (최대 4096 칩)"
        subgraph "Cube 0"
            T00["TPU 0"] <-->|"ICI"| T01["TPU 1"]
            T01 <-->|"ICI"| T02["TPU 2"]
            T02 <-->|"ICI"| T03["TPU 3"]
        end
        subgraph "Cube 1"
            T10["TPU 4"] <-->|"ICI"| T11["TPU 5"]
            T11 <-->|"ICI"| T12["TPU 6"]
        end
        Cube0["Cube 0"] <-->|"OCS (광 스위치)"| Cube1["Cube 1"]
    end

TPU v4 Pod 의 혁신: OCS (Optical Circuit Switch) 로 수백~수천 칩을 유연하게 연결. 임의의 topology 구성 가능.

Pod 크기	칩 수	피크 성능
TPU v4 슬라이스	8~512	수십 petaFLOPS
TPU v4 Pod	4096	~1 exaFLOPS

XLA: 컴파일러가 MXU 를 최대한 활용

TPU 는 XLA (Accelerated Linear Algebra) 컴파일러 없이는 제 성능이 나오지 않는다.

flowchart LR
    JAX["JAX / TF / PyTorch/XLA\n(Python 코드)"] --> HLO["HLO\n(High-Level Optimizer IR)"]
    HLO --> OPT["최적화 패스\n(fusion, tiling, layout)"]
    OPT --> LLO["LLO\n(Low-Level Optimizer)"]
    LLO --> TPU["TPU HW 커널\n(MXU + VU 명령)"]

XLA 가 자동으로 수행하는 최적화:

최적화	효과
Op fusion	softmax = exp + sum + div → 단일 커널
Tiling	행렬을 MXU 크기에 맞게 분할
Layout optimization	메모리 레이아웃을 MXU 친화적으로 전환
Rematerialization	activation checkpoint (메모리/컴퓨트 트레이드오프)
SPMD partitioning	분산 학습 자동 샤딩

실전: JAX 로 TPU 활용

기본 설정

import jax
import jax.numpy as jnp

# 사용 가능한 TPU 장치 확인
devices = jax.devices('tpu')
print(f"TPU 장치 수: {len(devices)}")

# jit 컴파일: XLA 가 MXU 최적화 적용
@jax.jit
def linear(weights, x):
    return jnp.dot(x, weights)

# BF16 명시 사용
x = jnp.ones((1024, 512), dtype=jnp.bfloat16)
W = jnp.ones((512, 256), dtype=jnp.bfloat16)
y = linear(W, x)  # [1024, 256] BF16

분산 학습 (pmap / pjit)

from jax.experimental import mesh_utils
from jax.sharding import Mesh, PartitionSpec, NamedSharding

# TPU Pod: 64 칩을 8x8 mesh 로 배치
devices = mesh_utils.create_device_mesh((8, 8))
mesh = Mesh(devices, axis_names=('data', 'model'))

# 가중치 모델 병렬, 배치 데이터 병렬 샤딩
weight_sharding = NamedSharding(mesh, PartitionSpec('model', None))
data_sharding   = NamedSharding(mesh, PartitionSpec('data', None))

@jax.jit
def train_step(state, batch):
    # pjit 내부에서 자동 collective (all-reduce, all-gather)
    loss, grads = jax.value_and_grad(loss_fn)(state.params, batch)
    return state.apply_gradients(grads=grads), loss

Flax 모델 정의

from flax import linen as nn

class TransformerBlock(nn.Module):
    hidden: int
    heads: int

    @nn.compact
    def __call__(self, x):
        # 모든 dot/matmul 이 XLA 에 의해 MXU 최적화됨
        attn_out = nn.MultiHeadDotProductAttention(
            num_heads=self.heads
        )(x, x)
        x = nn.LayerNorm()(x + attn_out)
        mlp_out = nn.Dense(self.hidden * 4)(x)
        mlp_out = nn.gelu(mlp_out)
        mlp_out = nn.Dense(self.hidden)(mlp_out)
        return nn.LayerNorm()(x + mlp_out)

GPU 와 비교

flowchart LR
    subgraph "GPU (H100)"
        g1["HBM 80GB\n3.35 TB/s"] --> g2["L2 Cache 50MB"]
        g2 --> g3["132 SM\n각 128 CUDA + 4 Tensor Core"]
        g3 --> g4["CUDA / cuDNN\n광범위한 생태계"]
    end
    subgraph "TPU (v4)"
        t1["HBM 32GB\n1.2 TB/s"] --> t2["Unified Buffer 32MB"]
        t2 --> t3["MXU 4개\n(Systolic Array)"]
        t3 --> t4["XLA 컴파일\nJAX / TF / PyTorch/XLA"]
    end

항목	GPU (H100)	TPU v4
피크 TFLOPS (BF16)	1,979	275 (칩당)
MFU (실제 활용률)	30-50%	60-70%
메모리 대역폭	3.35 TB/s	1.2 TB/s
소프트웨어	CUDA (광범위)	XLA 중심
병렬 실행 모델	SIMT (warp 32T)	Systolic Array
지연시간	낮음 (스트리밍)	배치 지향
접근성	AWS, Azure, GCP, on-prem	GCP TPU 만
유연성	높음 (그래픽, HPC 포함)	ML 특화

[!IMPORTANT] H100 의 피크 TFLOPS 가 훨씬 높지만, MFU 를 감안하면 실효 성능 차는 크게 줄어든다. TPU 는 행렬 연산에서 효율이 매우 높고, Pod 로 묶으면 H100 클러스터보다 통신 대역폭이 유리하다.

한계

한계	상세
GCP 한정	AWS, Azure, on-prem 불가. 벤더 종속
CUDA 생태계 없음	PyTorch CUDA 확장 직접 사용 불가. XLA 기반 재작성 필요
동적 shape 비효율	XLA 는 shape 별 재컴파일. 가변 길이 시퀀스 처리 까다로움
디버깅 어려움	JIT 컴파일 후 실행 → 스택 트레이스 추적 복잡
소형 모델	작은 모델/배치에서는 GPU 가 오히려 빠름

흔한 함정

[!WARNING]

jax.jit 없이 실행 = Python 레벨 eager 실행, MXU 최적화 전혀 없음. 항상 @jax.jit 필수.

행렬 차원이 128 배수 아님 = MXU padding 낭비. hidden_dim, intermediate 크기를 128 배수로.

동적 shape 남발 = 매번 재컴파일 발생. 고정 shape 또는 jax.vmap + padding.

HBM 부족 무시 = TPU v4 HBM 32GB. 큰 모델은 분산 샤딩 (tensor/pipeline parallelism) 필수.

PyTorch 습관 그대로 = TPU 에서 .cuda() 대신 jax.device_put(x, devices[0]) 사용.

[FL] FedAvg (Federated Averaging)

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

FedAvg (Federated Averaging) 는 McMahan et al. (2017) 이 제안한 연합 학습의 기본 알고리즘 입니다. 원본 데이터를 중앙 서버로 보내지 않고 각 클라이언트가 로컬 데이터로 모델을 학습한 뒤 weight 을 가중 평균 하여 글로벌 모델을 갱신합니다.

“local 여러 step, 서버 평균 한 번” 이라는 단순 구조로 FedSGD 대비 통신 라운드 수를 10-100 배 줄여, 실용적 연합 학습의 문을 열었습니다.

FedSGD 와의 차이

FedSGD (naive baseline)

각 라운드에서 클라이언트가 1 step gradient 만 계산해 서버로 전송
서버가 gradient 를 평균해 global weight 갱신
각 SGD step 마다 통신 -> 매우 비효율

FedAvg (핵심 개선)

각 클라이언트가 로컬에서 여러 epoch 을 돌리고
최종 weight 를 서버에 전송
서버는 weight 을 가중 평균
한 라운드에 로컬 여러 step 이 들어가므로 통신 횟수 대폭 감소

핵심 통찰: 데이터가 IID 에 가깝다면 로컬 여러 step 이 낭비가 아니라 이득 (서버 라운드 = 통신 = 병목이므로).

알고리즘

Server:

Initialize w_0
For each round t = 0, 1, 2, ...:
    S_t = random subset of K clients (fraction C of N clients)
    For each client k in S_t (in parallel):
        w_k^{t+1} = ClientUpdate(k, w_t)
    w_{t+1} = sum over k in S_t of (n_k / n) * w_k^{t+1}

Client (ClientUpdate(k, w)):

Split D_k into batches of size B
For each local epoch e = 1..E:
    For each batch b:
        w <- w - eta * grad_l(w; b)
Return w

하이퍼파라미터

기호	의미	관용 값
$N$	전체 클라이언트 수	100 ~ 10^6+ (cross-device)
$C$	라운드당 참여 fraction	0.001 ~ 0.1 (cross-device), 1.0 (cross-silo)
$K$	라운드당 실제 참여 클라이언트 수	$C \cdot N$
$E$	로컬 epoch 수	1 ~ 20
$B$	로컬 minibatch 크기	10 ~ 200
$\eta$	로컬 learning rate	0.001 ~ 0.1
$T$	총 라운드 수	수백 ~ 수만

서버 집계 공식

가중 평균 (weighted average):

$$ w_{t+1} = \sum_{k \in S_t} \frac{n_k}{n} \cdot w_k^{t+1} $$

$n_k$: 클라이언트 $k$ 의 데이터 개수
$n = \sum_{k \in S_t} n_k$: 이번 라운드 참여 클라이언트 총 데이터 개수

왜 개수 비율로 가중: 데이터가 많은 클라이언트의 로컬 optimum 이 실제 loss 표면에 대해 더 많은 정보를 담고 있다고 가정 (empirical risk minimization 관점의 자연스러운 가중).

주의: 이 가중은 개수 편향 을 유발할 수 있습니다. 대형 클라이언트가 지배적이면 소수 클라이언트의 분포가 무시됩니다. 문제가 있으면 uniform 또는 클래스 균형 가중으로 대체.

왜 로컬 여러 epoch 이 통하는가

IID 데이터 (모든 클라이언트가 같은 분포에서 샘플링) 라면 각 클라이언트의 로컬 optimum 이 글로벌 optimum 과 근접합니다. 여러 step 이 낭비가 아니라 서버 라운드 사이의 진전.

Non-IID 라면 각 클라이언트가 자기 로컬 optimum 으로 수렴하려 하고, 서로 다른 방향으로 이동합니다 (client drift). 평균이 잘못된 방향으로 이동해 수렴 속도 저하 또는 성능 하락. 이 문제는 [[fl-non-iid|FL Non-IID]] 위키에서 상세 다룹니다.

Convergence 이론

Li et al. (2019) “On the Convergence of FedAvg on Non-IID Data” 는 convex loss 가정 하에 다음을 보였습니다.

IID + full participation: FedSGD 와 유사한 rate 로 수렴
Non-IID + partial participation: decay learning rate 가 필요, 아니면 수렴하지 않을 수 있음
통신 라운드 $T$ 관점에서 $O(1/T)$ (strongly convex), $O(1/\sqrt{T})$ (convex)

Non-convex (딥러닝) 는 정확한 이론이 없고 empirical validation 에 의존합니다.

FedSGD 로부터의 도출

E = 1, B = 무한 (전체 배치) 이면 FedAvg = FedSGD. 즉 FedSGD 는 FedAvg 의 특수 케이스.

E 를 늘리면:

통신 감소 (좋음)
Client drift 증가 (나쁨, non-IID 에서)
Batch normalization 통계 로컬 편향 심화

Sweet spot: E = 1-5, B = 클라이언트 데이터의 1/10 정도.

통신 비용 분석

한 라운드 통신량:

$$ \text{총 통신량} = 2 \cdot K \cdot |w| $$

서버 -> 클라이언트: global weight 다운로드
클라이언트 -> 서버: 로컬 학습 후 weight 업로드

$|w|$ 는 모델 파라미터 총 크기 (float32 기준 4 bytes/param).

최적화 방법:

Model compression: quantization (8-bit, 4-bit), sparsification (top-k)
Structured updates: low-rank, random mask
FetchSGD: Count sketch 로 gradient 압축
Federated Dropout: 부분 모델만 학습/전송

배치 정규화의 함정

Batch Normalization 은 배치 통계에 의존합니다. 로컬 데이터가 non-IID 이면 로컬 BN 통계가 글로벌 분포를 대표하지 않아 성능 저하.

해결:

GroupNorm: 배치 무관 (BN 대체 자주 사용)
LayerNorm
FedBN: BN 파라미터는 로컬 유지, 다른 파라미터만 aggregate

실전 구현 (Flower)

import flwr as fl
import torch
from torch.utils.data import DataLoader

class Client(fl.client.NumPyClient):
    def __init__(self, model, train_ds, val_ds):
        self.model = model
        self.train_dl = DataLoader(train_ds, batch_size=32, shuffle=True)
        self.val_dl = DataLoader(val_ds, batch_size=64)

    def get_parameters(self, config):
        return [p.detach().cpu().numpy() for p in self.model.parameters()]

    def set_parameters(self, parameters):
        for p, new in zip(self.model.parameters(), parameters):
            p.data = torch.tensor(new)

    def fit(self, parameters, config):
        self.set_parameters(parameters)
        # 로컬 E epoch 학습
        opt = torch.optim.SGD(self.model.parameters(), lr=config["lr"])
        for epoch in range(config["local_epochs"]):
            for x, y in self.train_dl:
                opt.zero_grad()
                loss = self.model.loss(x, y)
                loss.backward()
                opt.step()
        return (
            self.get_parameters({}),
            len(self.train_dl.dataset),  # n_k, 서버가 가중 평균에 사용
            {}
        )

    def evaluate(self, parameters, config):
        self.set_parameters(parameters)
        loss, acc = self.eval()
        return float(loss), len(self.val_dl.dataset), {"acc": acc}

# 서버
strategy = fl.server.strategy.FedAvg(
    fraction_fit=0.1,           # C = 0.1
    min_fit_clients=10,
    min_available_clients=100,
    on_fit_config_fn=lambda rnd: {"lr": 0.01, "local_epochs": 1},
)

fl.server.start_server(
    server_address="0.0.0.0:8080",
    config=fl.server.ServerConfig(num_rounds=200),
    strategy=strategy,
)

FedAvg 의 개선/변형

변형	개선점
FedProx	Non-IID client drift 완화 (proximal term)
SCAFFOLD	Control variate 로 drift correction
FedYogi / FedAdam	서버측 adaptive optimizer
FedNova	Local step 수 불균형 정규화
FedBN	Batch Norm 통계 로컬 유지
Personalized FedAvg	클라이언트별 로컬 fine-tuning

각 변형은 특정 조건 (non-IID 극심, system heterogeneity 등) 에 특화. 자세한 알고리즘 유도는 원 논문 참조.

함정

[!WARNING] Non-IID 극심 하면 FedAvg 자체가 수렴하지 않을 수 있습니다. Learning rate decay + [[fl-non-iid|FedProx/SCAFFOLD]] 등 변형 사용 고려.

[!CAUTION] 가중 평균의 편향. 대형 클라이언트 데이터가 노이즈/편향이면 글로벌 모델이 그 편향을 흡수. Robust aggregation (median, trimmed mean) 을 검토.

[!WARNING] Client dropout. 라운드 중 클라이언트가 이탈하면 그 클라이언트의 weight 만 누락 -> 편향. Secure Aggregation 은 dropout 을 threshold secret sharing 으로 처리.

[!IMPORTANT] BN 통계 문제. 딥러닝 모델에 BN 이 있으면 성능 저하 위험. GroupNorm 대체 또는 FedBN 사용.

[FL] Frameworks (Flower, TFF, NVFlare, FATE, PySyft)

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

연합 학습 프레임워크 는 서버-클라이언트 통신, 집계 알고리즘, 프라이버시 도구, 시뮬레이션 환경, 실 배포 인프라를 제공하는 라이브러리/플랫폼입니다. 알고리즘을 직접 구현하지 않고 자기 모델 학습 로직만 작성 하면 프레임워크가 나머지를 담당합니다.

주요 프레임워크 5개 (Flower, TFF, NVFlare, FATE, PySyft) 와 신진 (FedML, OpenFL) 을 비교합니다.

프레임워크 요약 비교

프레임워크	개발/유지	언어	프레임워크 애그노스틱	실 배포	시뮬레이션	프라이버시 도구
Flower	Adap (스타트업) + 커뮤니티	Python	✓ (PyTorch/TF/JAX/HF)	강함	✓	SecAgg, DP 통합
TFF	Google	Python	X (TF 위주)	시뮬레이션 위주	매우 강함	강함 (Google TFF Analytics)
NVFlare	NVIDIA	Python	✓	강함 (Clara)	✓	HE, DP, PSI
FATE	WeBank	Python + Scala	부분	매우 강함 (프로덕션)	✓	HE, MPC 강함
PySyft	OpenMined	Python	✓ (PyTorch/TF)	중간	✓	HE, MPC, DP 통합
FedML	FedML Inc.	Python	✓	강함	강함	통합

Flower (권장 진입점)

특징

가벼운 API, “가장 사용하기 쉬운 FL 프레임워크” 평판
완전 프레임워크 애그노스틱: PyTorch, TensorFlow, JAX, scikit-learn, HuggingFace 다 붙음
시뮬레이션과 실 배포가 같은 코드
200+ 학술 논문에 채택, 산업 사례 증가

코드 뼈대

Client:

import flwr as fl

class MyClient(fl.client.NumPyClient):
    def get_parameters(self, config):
        return [p.detach().cpu().numpy() for p in model.parameters()]

    def set_parameters(self, parameters):
        for p, new in zip(model.parameters(), parameters):
            p.data = torch.tensor(new)

    def fit(self, parameters, config):
        self.set_parameters(parameters)
        train(model, train_loader, epochs=config["local_epochs"])
        return self.get_parameters({}), len(train_dataset), {}

    def evaluate(self, parameters, config):
        self.set_parameters(parameters)
        loss, acc = evaluate(model, val_loader)
        return float(loss), len(val_dataset), {"accuracy": acc}

fl.client.start_numpy_client(server_address="server:8080", client=MyClient())

Server:

strategy = fl.server.strategy.FedAvg(
    fraction_fit=0.1,
    min_fit_clients=10,
    min_available_clients=100,
    on_fit_config_fn=lambda rnd: {"local_epochs": 1},
)

fl.server.start_server(
    server_address="0.0.0.0:8080",
    config=fl.server.ServerConfig(num_rounds=200),
    strategy=strategy,
)

지원 전략

FedAvg, FedProx, FedYogi, FedAdam, FedAdagrad, SCAFFOLD, FedMedian, Krum, FaultTolerantFedAvg, custom strategy 상속.

시뮬레이션

flwr.simulation.start_simulation 으로 단일 프로세스에서 수백 클라이언트 병렬 시뮬레이션 (Ray backend). 대규모 시뮬레이션에도 강함.

강점

진입 장벽 낮음
프로덕션 배포 (mobile SDK, edge) 사례 다수
활발한 커뮤니티, 문서 우수

약점

HE / MPC 는 자체 제공 X, 다른 라이브러리 (CrypTen, TenSEAL) 와 통합 필요
시각화/모니터링 UI 는 별도 (외부 tool 필요)

TensorFlow Federated (TFF)

특징

Google 개발, 학술 연구 및 시뮬레이션의 사실상 표준
두 계층 API: Federated Core (저수준) + Federated Learning API (고수준)
TF eager mode + XLA 컴파일, 매우 빠른 시뮬레이션
Federated Analytics (평균, 히스토그램 등 통계 연산도 연합) 강력

코드 예시

import tensorflow_federated as tff

def create_model():
    return tf.keras.Sequential([
        tf.keras.layers.Dense(128, activation="relu"),
        tf.keras.layers.Dense(10),
    ])

def model_fn():
    return tff.learning.models.from_keras_model(
        create_model(),
        input_spec=input_spec,
        loss=tf.keras.losses.SparseCategoricalCrossentropy(from_logits=True),
        metrics=[tf.keras.metrics.SparseCategoricalAccuracy()],
    )

trainer = tff.learning.algorithms.build_weighted_fed_avg(
    model_fn,
    client_optimizer_fn=lambda: tf.keras.optimizers.SGD(learning_rate=0.02),
    server_optimizer_fn=lambda: tf.keras.optimizers.SGD(learning_rate=1.0),
)

state = trainer.initialize()
for round_num in range(NUM_ROUNDS):
    result = trainer.next(state, sampled_client_data)
    state = result.state
    print(f"Round {round_num}: {result.metrics}")

강점

시뮬레이션 성능 최상급
Google Analytics DP 도구 성숙
TFF Analytics 는 다른 프레임워크에 없는 강점

약점

실 배포 지원 약함. 시뮬레이션 편중.
TF-heavy: PyTorch 사용자에겐 접근성 낮음
API 학습 곡선 있음 (federated computation, TFF type system)

결론: Google 스타일 연구용. 배포는 다른 프레임워크 병행.

NVIDIA FLARE (NVFlare)

특징

Cross-silo 프로덕션 지향. NVIDIA Clara (의료) 에서 검증
워크플로 지향: SAG (Scatter and Gather), CyclicController 등 orchestration
강한 프라이버시 툴: HE (TenSEAL), DP, PSI (Private Set Intersection)
모니터링 (TensorBoard, MLflow) 통합
Multi-org deployment (여러 회사가 협력)

강점

의료/금융 실 배포 사례 (병원간, 은행간)
프라이버시 도구 통합 최상급
Job / workflow 관리 성숙

약점

Cross-device (수백만 모바일) 시나리오는 아님
진입 장벽 (연구자에게는 복잡)

대표 사용처: 다기관 의료 학습, 금융 컨소시엄.

FATE (Federated AI Technology Enabler)

특징

WeBank (중국) 주도, cross-silo 산업 배포에서 압도적
Multi-Party Computation (MPC), Homomorphic Encryption 이 first-class
FederatedML: FL 알고리즘 대규모 라이브러리
FATEFlow: workflow, FATEBoard: 시각화, FATE-Serving: 배포
스칼라 + 파이썬 + Spark 백엔드로 대규모 데이터에 강함

강점

MPC/HE 통합이 가장 완성도 높음
대규모 데이터 (수백 GB+) 처리
배포 도구 (dashboard, monitoring) 완비

약점

학습 곡선 가파름
문서 대부분 중국어 (영어 자료 상대적으로 부족)
스타트업 규모에는 무거움

대표 사용처: 금융 컨소시엄, 대형 헬스케어.

PySyft (OpenMined)

특징

오픈소스 커뮤니티 (OpenMined) 주도
프라이버시 우선: HE, MPC, DP 통합
PySyft + PyGrid 구조: SDK + 서버
PyTorch, TensorFlow 지원

강점

프라이버시 도구 종합
활발한 오픈소스 커뮤니티
교육 리소스 풍부 (강좌, 튜토리얼)

약점

아키텍처 변경이 잦아 프로덕션 사용에는 신중 필요
성능 최적화가 후순위 (연구/교육 편중)

대표 사용처: 프라이버시 연구, 교육.

FedML

특징

FedML Inc. 학술 + 산업 겸용
FedML-Nexus AI: 학술 실험 + 산업 배포 통합 플랫폼
다양한 topology (star, ring, hierarchical) 지원
Cross-silo + cross-device + IoT 모두

강점

다양한 시나리오 커버
LLM/멀티모달 FL 초기 지원

약점

상대적으로 신생 (2021~), 성숙도 아직

프레임워크 선택 가이드

상황	권장
학습/연구, 빠른 프로토타입	Flower or TFF
PyTorch 워크로드, 실 배포 계획	Flower
Google 스타일 연구, 시뮬레이션 극대화	TFF
다기관 의료/금융, 프라이버시 필수	NVFlare or FATE
프라이버시 도구 강력	PySyft or FATE
모바일 SDK, edge	Flower
대규모 산업 배포 (수 GB+ 데이터)	FATE

Aggregation 알고리즘 지원 (공통)

대부분 프레임워크가 FedAvg, FedProx, FedYogi/Adam, SCAFFOLD, robust aggregation (Median, Trimmed Mean, Krum) 은 built-in. Personalized FL (pFedMe, Ditto) 은 프레임워크별 지원 편차. Custom strategy 상속으로 대체 가능.

함정

[!WARNING] 시뮬레이션과 실 배포는 다릅니다. 시뮬레이션에서 좋은 알고리즘이 실 환경 (네트워크 불안정, 클라이언트 dropout) 에서는 실패할 수 있음. 반드시 실 배포 시나리오 테스트.

[!CAUTION] 프라이버시 툴은 사용법을 잘못 쓰면 프라이버시가 없습니다. DP epsilon, HE parameter 를 이해하지 않고 default 만 쓰면 정량 보장 없음.

[!WARNING] 성능 튜닝. 프레임워크마다 통신 프로토콜, 직렬화, 배치 처리가 다름. 실 부하 벤치마크 필수.

[!IMPORTANT] 버전 호환성. Flower 는 stable API 이지만 TFF/PySyft 는 breaking change 잦음. 프로덕션은 pin 필수.

[FL] Non-IID Data & Client Drift

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

Non-IID data 는 연합 학습에서 각 클라이언트의 데이터가 서로 다른 분포에서 추출되는 상황을 말합니다. FedAvg 를 비롯한 대부분 FL 알고리즘의 최대 난관이며, client drift (각 클라이언트가 자기 로컬 optimum 으로 이탈해 평균이 잘못된 방향으로 이동) 를 유발합니다.

Non-IID 의 유형

Kairouz et al. (2021) 서베이 분류:

1. Feature distribution skew (covariate shift)

$P_k(x) \ne P_{k’}(x)$, but $P_k(y|x)$ 는 동일.

예: 여러 병원의 X-ray 데이터. 라벨 (질병) 규칙은 같지만 촬영 장비/환자군이 달라 이미지 통계가 다름.

2. Label distribution skew (prior probability shift)

$P_k(y) \ne P_{k’}(y)$, but $P_k(x|y)$ 는 동일.

예: MNIST 를 100명에게 나눠주되 각자는 특정 숫자 3-4개만 받음. 클래스 사전 분포가 극단적으로 다름.
실전에서 흔한 유형. 사용자별 관심사 편중.

3. Same label, different features (concept shift)

$P_k(x|y) \ne P_{k’}(x|y)$.

예: 여러 나라의 “긴급 상황” 라벨 데이터. 라벨은 같지만 특성 분포가 다름.

4. Same features, different label (concept drift)

$P_k(y|x) \ne P_{k’}(y|x)$.

예: 다국어 감정 분석. 같은 단어가 나라마다 다른 감정.

5. Quantity skew (unbalancedness)

$|D_k|$ 가 클라이언트별로 크게 다름. 대형 클라이언트 몇 개가 지배.

실무에서는 이 유형들이 혼합 되어 나타납니다.

Non-IID 상황 시각화

flowchart TB
    subgraph IID["IID (이상적 분포)"]
        C1["클라이언트 A\n클래스 0~9 균등"]
        C2["클라이언트 B\n클래스 0~9 균등"]
        C3["클라이언트 C\n클래스 0~9 균등"]
    end
    subgraph NonIID["Non-IID (Label Skew)"]
        D1["클라이언트 A\n클래스 0,1,2 만"]
        D2["클라이언트 B\n클래스 5,6,7 만"]
        D3["클라이언트 C\n클래스 8,9 만"]
    end
    IID -->|"FedAvg 잘 수렴"| GoodGlobal["좋은 글로벌 모델"]
    NonIID -->|"client drift 발생"| BadGlobal["편향된 글로벌 모델"]

Client Drift 의 수학적 원인

로컬 objective $F_k(w)$ 는 클라이언트 $k$ 의 로컬 데이터에 대한 손실. 글로벌 objective 는:

$$ F(w) = \sum_k \frac{n_k}{n} F_k(w) $$

로컬 SGD 를 $E$ epoch 돌리면 클라이언트 $k$ 는 $F_k$ 의 로컬 minimum $w_k^*$ 에 접근합니다.

$$ w_k^{t+1} \approx w_k^* = \arg\min_w F_k(w) $$

Non-IID 상황에서 ${w_k^}$ 들은 서로 멀리 흩어져 있고, 그들의 평균은 글로벌 minimum $w^ = \arg\min_w F(w)$ 와 무관 할 수 있습니다.

$$ \sum_k \frac{n_k}{n} w_k^* \not\approx w^* $$

이것이 client drift. E 가 클수록 더 심해집니다.

완화 전략

A. Reduce local computation

E 축소 (극단적으로는 E=1, 즉 FedSGD): drift 감소, 대신 통신 폭증
B 확대: 배치를 크게 (분산 감소, 하지만 GPU 메모리 요구 증가)

Trade-off: 통신 vs drift.

B. Proximal Regularization (FedProx)

Li et al. (2020) 의 FedProx 는 로컬 objective 에 proximal term 을 추가:

$$ \min_w F_k(w) + \frac{\mu}{2} | w - w_t |^2 $$

$\mu$: 하이퍼파라미터 (0.001 ~ 1)
로컬 update 가 글로벌 모델에서 멀리 벗어나지 못하도록 제약
Straggler (느린 클라이언트) 가 partial work 만 해도 안전

Pros: 구현 간단 (loss 에 term 하나 추가), FedAvg 대비 안정성 향상. Cons: $\mu$ 튜닝 필요, drift 를 완전히 없애진 못함.

C. Control Variate (SCAFFOLD)

Karimireddy et al. (2020) 의 SCAFFOLD 는 각 클라이언트의 drift 방향을 control variate $c_k$ 로 추적하고 로컬 gradient 에서 빼줍니다.

로컬 SGD update:

$$ w \leftarrow w - \eta \left( \nabla F_k(w) - c_k + c \right) $$

$c_k$: 클라이언트 $k$ 의 로컬 correction (drift 방향)
$c$: 서버 correction (모든 클라이언트 평균)
$c_k - c$: “이 클라이언트가 평균보다 얼마나 편향된가”

라운드 종료 시 $c_k$ 를 업데이트하고 서버가 $c$ 를 재집계.

Pros: 이론적으로 IID 급 수렴 rate 회복. Cons: 통신량 2배 (weight + control variate 모두 전송), 메모리 2배.

D. Objective Consistency (FedNova)

Wang et al. (2020) 의 FedNova 는 각 클라이언트의 로컬 step 수 $\tau_k$ 가 다를 때 정규화. FedAvg 는 클라이언트별로 step 수가 달라도 그냥 평균하지만, 이는 objective inconsistency 를 야기.

FedNova 는 normalized gradient 를 집계:

$$ w_{t+1} = w_t - \tau_{\text{eff}} \cdot \sum_k \frac{n_k}{n} \cdot \frac{d_k}{\tau_k} $$

$d_k = w_t - w_k^{t+1}$: 클라이언트 $k$ 의 delta
$\tau_k$: 클라이언트 $k$ 의 로컬 step 수
$\tau_{\text{eff}}$: 유효 step 수 (스케일 조정)

특히 system heterogeneity (느린/빠른 클라이언트 혼재) 상황에 강함.

E. Server-side adaptive optimizer

Reddi et al. (2020) 의 FedAdam, FedYogi, FedAdagrad. 서버에서 pseudo-gradient $\Delta_t = w_t - w_{t+1}^{\text{avg}}$ 를 Adam/Yogi/Adagrad 로 적용.

$$ w_{t+1} = w_t - \eta \cdot \text{AdamUpdate}(\Delta_t) $$

Non-IID 하에서 학습 안정성 향상.

F. Data augmentation / Mixup

클라이언트가 로컬에서 data augmentation 을 강하게 하면 로컬 분포가 완화되어 drift 감소. Mixup, CutMix, RandAugment 등이 흔히 결합.

G. Personalization (개인화)

Non-IID 를 없애려 하지 말고 각 클라이언트가 자기 분포에 맞게 개인화 모델을 갖도록 함. 자세한 것은 [[personalized-fl|Personalized FL]] 참조.

벤치마크 데이터셋

Non-IID FL 연구에 자주 쓰이는:

Federated MNIST / FEMNIST: 필기 데이터를 작가별로 자연 분할
Federated CIFAR-10 (Dirichlet split): Dirichlet 파라미터 $\alpha$ 로 non-IID 정도 조절
Shakespeare: 극중 인물별 대사, 언어 모델링
StackOverflow: 사용자별 질문/답변
iNaturalist: 지역별 야생동물 이미지
Reddit: user별 댓글

Dirichlet split: 라벨 $y$ 의 클라이언트 분포를 $\text{Dir}(\alpha)$ 로 샘플. $\alpha$ 가 작을수록 극단적 non-IID.

BatchNorm 특별 주의 (FedBN)

Non-IID 에서 Batch Normalization 은 특히 취약합니다. 각 클라이언트의 배치 통계 (mean, variance) 가 달라서 글로벌 집계 후 BN 레이어가 “틀린 통계” 로 추론합니다.

해결책:

FedBN (Li et al., 2021): BN 레이어는 집계하지 않고 각 클라이언트에서 로컬 통계를 유지
GroupNorm / LayerNorm 대체: 배치 통계에 의존하지 않아 Non-IID 에 강함
InstanceNorm: 각 샘플마다 정규화, 배치 크기에 무관

모델 설계 단계에서 FL 을 고려하면 처음부터 GroupNorm 을 쓰는 것이 좋습니다.

알고리즘 선택 가이드

flowchart TD
    Start["Non-IID 문제 진단"]
    Start --> Q1{"극심한 label skew?"}
    Q1 -->|"Yes"| Q2{"통신량 허용 2배?"}
    Q1 -->|"No"| Q3{"system heterogeneity?"}
    Q2 -->|"Yes"| SCAFFOLD["SCAFFOLD"]
    Q2 -->|"No"| FedProx["FedProx (mu=0.01~0.1)"]
    Q3 -->|"Yes"| FedNova["FedNova"]
    Q3 -->|"No"| Q4{"서버 optimizer 도입?"}
    Q4 -->|"Yes"| FedAdam["FedAdam / FedYogi"]
    Q4 -->|"No"| FedAvg["FedAvg (E 줄이기)"]
    FedProx --> Eval{"클라이언트별 accuracy 편차?"}
    FedAvg --> Eval
    Eval -->|"크다"| Personalized["Personalized FL 검토"]
    Eval -->|"OK"| Done["배포"]

상황	권장
Mild non-IID + IID 근접	FedAvg (그대로)
표준 non-IID (label skew)	FedProx ($\mu$ = 0.01)
극심한 drift, 클라이언트 다수	SCAFFOLD
System heterogeneity (다양한 로컬 step)	FedNova
서버 최적화 여지	FedAdam / FedYogi
BatchNorm 통계 문제	FedBN or GroupNorm 대체
개인화가 목적	Personalized FL

실험 체크리스트

Non-IID FL 논문/프로젝트에서 반드시 보고해야 하는 항목:

Non-IID 정도 정량화: Dirichlet $\alpha$, 클라이언트당 클래스 수, Earth Mover’s Distance 등
클라이언트 참여율: 라운드당 샘플링 비율 (full participation vs partial participation)
로컬 epoch E: drift 의 직접 파라미터
글로벌 accuracy 뿐 아니라 per-client accuracy 분포: worst-10% 클라이언트 성능 필수
통신 라운드 수 vs 성능: 총 통신량 비교 (알고리즘마다 라운드당 비용 다름)
SCAFFOLD 는 통신 2배 반영: 단순 accuracy 비교는 불공평

함정

[!WARNING] Non-IID 를 IID 처럼 다루면 수렴 실패. 처음부터 데이터 분포를 EDA 로 파악.

[!CAUTION] BN 은 non-IID 에서 특히 취약. 로컬 통계가 글로벌 분포를 대표하지 않아 성능 저하. GroupNorm 또는 FedBN 을 첫 손에 검토.

[!WARNING] 극심한 non-IID + partial participation 은 이론적 수렴 보장이 약함. 실전에서 learning rate decay + warm-up 이 필수.

[!IMPORTANT] 개인화 지표를 평가. 글로벌 모델의 accuracy 뿐 아니라 클라이언트별 accuracy 분포도 함께 리포트. 평균은 좋지만 최악의 클라이언트가 안 되면 UX 실패.

[!CAUTION] Fairness 함정. Non-IID FL 은 소수 그룹 (소량 데이터 클라이언트) 이 대형 클라이언트에 종속될 수 있음. 가중 평균 외에도 min-max fairness (q-FFL 등) 검토.

[FL] Personalized Federated Learning

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

Personalized FL 은 모든 클라이언트가 동일한 글로벌 모델을 쓰지 않고, 각 클라이언트가 자신의 데이터 분포에 맞춰 조정된 모델 을 학습하는 연합 학습 계열입니다. Non-IID 극심한 환경에서 글로벌 모델을 억지로 수렴시키는 대신, 자연스러운 이질성을 받아들이고 개인화 성능 을 최적화합니다.

McMahan et al. 의 FedAvg 는 단일 글로벌 모델이 목표였지만, 실전에서 키보드 (다국어), 추천, 헬스 등 사용자별 특성이 강한 도메인에서는 개인화가 필수임을 깨닫게 되었습니다.

왜 필요한가

Non-IID 의 근본 딜레마

극심한 non-IID 에서 FedAvg 는 두 가지 문제:

글로벌 모델 수렴 실패: [[fl-non-iid|Client drift]] 로 정확도 저하
클라이언트별 fit 부족: 수렴해도 각 클라이언트 로컬 분포에는 잘 안 맞음

Personalized FL 은 문제 2 를 정면 공략. 글로벌 모델을 완전히 포기하지 않고, 각 클라이언트가 그 위에 로컬 조정을 얹습니다.

실전 사례

Gboard: 사용자별 이모지 추천, 단어 예측
Siri / Google Assistant: 음성 명령 개인화
Netflix / Amazon 추천: 사용자별 성향
의료 wearable: 개인별 정상 baseline
헬스케어 fedeated: 환자군 특성 반영

주요 접근법

1. Local Fine-tuning (가장 단순)

Global model 학습 후 클라이언트가 로컬 데이터로 몇 step fine-tune.

w_local = w_global.copy()
for step in range(local_steps):
    x, y = local_batch()
    w_local = w_local - eta * grad(loss(w_local, x, y))

Trade-off:

간단, 파라미터 추가 없음
하지만 언제 stop 할지 (overfit vs underfit) 결정 어려움
각 클라이언트가 개별 모델 저장 필요

2. Personalization Layers (FedPer, LG-FedAvg)

공유 부분 (representation extractor) + 개인 부분 (classifier head) 로 분리:

서버가 학습하는 부분: representation (conv/transformer body)
클라이언트가 로컬에 유지: personalization head (fully connected + softmax)

Global: [Body: shared conv/transformer]  → aggregated
Local:  [Head: personal FC + softmax]    → kept per client

FedPer (Arivazhagan et al., 2019): head 만 로컬. LG-FedAvg: 반대로 body 로컬 + head 공유.

Trade-off:

명확한 구조 분리, 통신량 감소 (head 안 전송)
어느 layer 를 로컬로 할지 도메인 지식 필요
Head 규모가 크면 로컬 학습 데이터 부족 문제

3. Meta-Learning (Per-FedAvg)

Fallah et al. (2020) 은 MAML (Model-Agnostic Meta-Learning) 스타일로 접근. 글로벌 모델이 “한 step 만 로컬 SGD 를 돌리면 잘 맞도록” 학습.

$$ \min_w F(w) = \sum_k F_k(w - \alpha \nabla F_k(w)) $$

$w$: meta-parameter (글로벌)
$w - \alpha \nabla F_k(w)$: 클라이언트 $k$ 가 한 step 학습 후의 로컬 파라미터
이 로컬 파라미터가 잘 맞도록 $w$ 를 최적화

배포 시: 각 클라이언트가 $w$ 를 받아 자기 데이터로 한 step 파인튜닝하면 즉시 개인화.

Trade-off:

이론적으로 매우 우아
Second-order gradient (Hessian) 필요 -> 계산 비용
FOMAML (first-order approximation) 로 완화 가능

4. Regularized Local Model (pFedMe, Ditto)

pFedMe (T. Dinh et al., 2020): 각 클라이언트가 로컬 모델 $\theta_k$ 를 유지하되 글로벌 $w$ 근처에 있도록 정규화.

$$ \min_{\theta_k} F_k(\theta_k) + \frac{\lambda}{2} | \theta_k - w |^2 $$

$w$ 는 서버에서 aggregated 로컬 모델들. $\lambda$ 큰 -> 글로벌에 가까움 (드리프트 방지). $\lambda$ 작은 -> 개인화 자유.

Ditto (Li et al., 2021): 유사하지만 강건성 + 공정성 초점. Global + local 이중 objective:

$$ \text{Global: } \min_w \sum_k F_k(w) \quad \text{Local: } \min_{\theta_k} F_k(\theta_k) + \frac{\lambda}{2} | \theta_k - w^* |^2 $$

Byzantine 공격에도 robust. Fair FL 계열의 대표.

5. Multi-Task Learning (MTL)

각 클라이언트 = 하나의 task. 클라이언트 간 관계 (task graph) 를 학습하며 관련 task 간 정보 공유.

MOCHA (Smith et al., 2017): dual formulation, 관계 행렬 학습
FedMTL: 최근 확장

6. Clustered FL

극심한 non-IID 에서는 하나의 글로벌 대신 여러 클러스터 별 모델. 유사 클라이언트끼리 같은 클러스터에 배정.

IFCA (Ghosh et al., 2020): Iterative Federated Clustering
HypCluster: Hypothesis-based 그룹핑

Trade-off: 클러스터 수 하이퍼파라미터, 클라이언트가 어느 클러스터 소속인지 privacy 함의.

7. Mixture of Experts / Adapter

Adapter layer 를 로컬로 유지 (LoRA 스타일). 글로벌은 base + shared params. 대형 모델 시대에 자연스러운 확장.

알고리즘 비교

방법	로컬 저장	통신	이론	대표 논문
Local Fine-tune	로컬 모델	표준 FedAvg	약함	(Baseline)
FedPer	Head	Body 만	중간	Arivazhagan 2019
Per-FedAvg (MAML)	없음 (배포 시 1-step)	표준 FedAvg	강함 (meta)	Fallah 2020
pFedMe	로컬 모델	표준	강함 (Moreau)	T. Dinh 2020
Ditto	로컬 모델	표준 + robust	강함 (fair/robust)	Li 2021
Clustered	클러스터 모델	클러스터별	중간	Ghosh 2020

시각화: 개인화 접근법 구조

flowchart LR
    G["글로벌 서버"] --> FA["FedAvg<br/>단일 글로벌"]
    G --> FP["FedPer<br/>레이어 분리"]
    G --> PF["Per-FedAvg<br/>메타 초기화"]
    G --> PM["pFedMe<br/>Moreau 정규화"]
    G --> DT["Ditto<br/>공정성 강조"]
    FA --> CA["클라이언트: 동일 모델"]
    FP --> CB["클라이언트: Head 개인화"]
    PF --> CC["클라이언트: 1-step 적응"]
    PM --> CD["클라이언트: 로컬 모델 유지"]
    DT --> CD

접근법 선택 기준

데이터, 인프라, 목표에 따라 적합한 방법이 달라진다:

조건	권장 방법	이유
신규 프로젝트, 빠른 실험	Local Fine-tune	설정 최소, 기준점 수립
모바일 배포, 통신 절약	FedPer	Head 만 로컬, Body 공유
즉시 개인화, MAML 경험 있음	Per-FedAvg	배포 후 1-step 으로 즉시 맞춤
Non-IID 심하고 수렴이 목적	pFedMe	λ 로 글로벌/개인화 균형 조절
공정성, 악의적 클라이언트 우려	Ditto	Robust + Fair FL
클러스터 구조 의심	Clustered FL	분포 유사 그룹끼리 집계
대형 모델 기반	LoRA / Adapter	파라미터 효율 개인화

λ 하이퍼파라미터 선택 (pFedMe, Ditto)

λ 는 글로벌 모델에 얼마나 당겨올지를 결정한다:

λ → ∞: 로컬 모델이 글로벌 모델로 수렴. FedAvg 와 동일 효과.
λ → 0: 완전 로컬 학습. 과적합 위험.
실전 탐색 범위: λ ∈ {0.001, 0.01, 0.1, 1, 10} 에서 cross-validation.

# pFedMe 로컬 학습 (단순화)
def local_train(w_global, local_data, lam, lr, steps):
    theta = w_global.clone()
    for _ in range(steps):
        x, y = sample(local_data)
        grad = compute_grad(theta, x, y)
        reg = lam * (theta - w_global)  # Moreau 정규화 항
        theta = theta - lr * (grad + reg)
    return theta

Fine-tune step 수 선택 (Per-FedAvg)

배포 시 몇 step 을 돌릴지 결정 기준:

1 step: 논문 기본값. 계산 빠름. 데이터 적은 클라이언트에 안정적.
5~10 step: 데이터 충분한 클라이언트는 더 많이 적응 가능.
조기 종료: validation loss 모니터링으로 over-adaptation 방지.
실전: 클라이언트별 데이터 크기에 비례한 step 수 적용.

평가 프로토콜 표준화

같은 방법도 평가 방식에 따라 숫자가 크게 달라진다. 논문 비교 시 주의:

방법	평가 시점	평가 데이터
FedAvg	글로벌 모델로	IID test set
FedPer	개인화 Head 적용 후	로컬 test set
Per-FedAvg	1-step fine-tune 후	로컬 test set
pFedMe / Ditto	로컬 모델로	로컬 test set

비교할 때 항상 동일 프로토콜 을 사용해야 한다. 평균 accuracy 만 보면 개인화 이득을 놓친다. per-client 분포 (min, max, std) 도 함께 보고해야 한다.

평가 지표

중요: Personalized FL 은 글로벌 accuracy 만 보면 오독합니다. 반드시:

Per-client accuracy 분포: 평균 + std + 최악 (min)
Fairness metric: q-FFL, EFL 등
Personalization gain: 로컬 fine-tune 후 vs 전
Communication cost: 개인화 부분 저장/전송 비용

실전 팁

단순부터 시작: FedAvg + Local fine-tune 부터. Meta / pFedMe 는 튜닝 부담 큼.
개인화 부분 크기 신중히: Head 만인지 여러 layer 인지가 성능/저장 크게 좌우.
cold-start client: 새 클라이언트는 데이터가 없어 개인화 어려움. Global 만으로 시작 후 시간 지나 개인화.
개인화 모델 크기: 모바일 배포는 로컬 모델 저장 공간 제약. Adapter/LoRA 가 유리.
평가 데이터 도 non-IID 하게: 학습과 동일 분포의 로컬 val set 사용.

함정

[!WARNING] 개인화가 항상 이득은 아닙니다. Non-IID 가 mild 하면 FedAvg 만으로도 충분. 개인화가 오히려 overfitting 유발 가능.

[!CAUTION] 개인화 모델의 privacy 함의. 개인 모델을 로컬에 저장하면 device 손실 시 개인 정보 유출 위험. 모델 자체가 학습 데이터의 정보를 포함.

[!WARNING] Cold client. 데이터가 매우 적은 신규 클라이언트는 개인화가 오히려 성능 저하. Threshold 를 두고 데이터 축적 후 개인화 전환.

[!IMPORTANT] 평가 프로토콜 명확히. Meta-learning 계열은 “1-step 후” 평가하고, pFedMe 는 “로컬 학습 완료 후” 평가. 논문 비교 시 프로토콜 통일 필수.

[!CAUTION] 서버 저장 필요: FedPer 등은 서버가 global body 만 저장, but pFedMe 는 사실상 클라이언트 개별 상태 관리. Cross-device 대규모에서는 클라이언트 side 상태 관리가 부담.

[FL] Secure Aggregation

koa (김신건) — Tue, 07 Jul 2026 00:00:00 GMT

정의

Secure Aggregation 은 연합 학습 서버가 개별 클라이언트 업데이트 를 보지 못하고 오직 합 (또는 평균) 만 볼 수 있도록 보장하는 암호학 프로토콜입니다. 서버가 honest-but-curious 라도 (프로토콜은 따르지만 학습 데이터를 캐내려 함) 개별 gradient 를 복원할 수 없습니다.

Bonawitz et al. (2017) 의 논문 “Practical Secure Aggregation” 이 사실상 표준이며, Google 이 실제 Gboard 학습에 배포하면서 실용성이 입증되었습니다.

왜 필요한가

Raw 데이터 미공개 만으로는 부족합니다. gradient 자체에서 원본이 복원될 수 있습니다 (gradient inversion attack).
Differential Privacy 만으로는 개별 값에 노이즈를 크게 넣어야 하고 유용성이 크게 손상됩니다.
서버가 실제 관측하는 것을 집계 값 으로만 제한하면, 개별 편향 없이 학습 가능.

위협 모델

Honest-but-curious server: 프로토콜은 따르지만 로그를 뒤져 개별 값 복원 시도
Malicious 최대 $t$ 클라이언트: 담합 (collusion) 가능. 프로토콜은 이 $t$ 이하 담합 아래 안전
Client dropout: 프로토콜 실행 중 이탈 (배터리, 네트워크). 필수 대응
Network eavesdropper: 전송 도청. TLS 로 방어 가정

Non-goals (Secure Aggregation 이 해결하지 않는 것):

집계 결과 자체의 프라이버시: 이는 [[differential-privacy|DP]] 로 별도 처리
Byzantine robustness (악성 값 주입): 이는 robust aggregation 으로 별도

기본 아이디어

각 클라이언트 $i$ 의 업데이트 $x_i$ 를 서로 다른 랜덤 마스크 $m_{ij}$ 로 감춥니다. 마스크는 쌍 (i, j) 에 대해 상쇄 되도록 설계:

$$ y_i = x_i + \sum_{j > i} m_{ij} - \sum_{j < i} m_{ji} \pmod{R} $$

여기서 $m_{ij} = -m_{ji}$ (반대 부호로 상쇄되는 쌍별 마스크).

서버가 모든 $y_i$ 를 더하면:

$$ \sum_i y_i = \sum_i x_i + \underbrace{\sum_i \sum_{j > i} m_{ij} - \sum_i \sum_{j < i} m_{ji}}_{= 0} = \sum_i x_i $$

마스크가 서로 상쇄되어 합만 남습니다. 개별 $x_i$ 는 마스크로 감춰져 있어 서버가 볼 수 없습니다.

프로토콜 단계

Bonawitz et al. 의 실제 프로토콜은 4 라운드 구성:

Round 0: Advertise Keys

각 클라이언트가 Diffie-Hellman public key 두 쌍을 생성해 서버에 전송.

$c_i^{PK}, c_i^{SK}$: 마스크용 shared secret 유도 키
$s_i^{PK}, s_i^{SK}$: 자기 secret 백업 키

각 클라이언트가 자기 secret key 를 Shamir’s Secret Sharing 으로 $n$ 조각으로 나눠 다른 $n-1$ 클라이언트에게 분배. 임계값 $t$ 이하 담합으로는 복원 불가.

Round 2: Masked Input Collection

각 클라이언트 $i$:

다른 클라이언트 $j$ 와의 shared secret $s_{ij} = KDF(c_i^{SK} \cdot c_j^{PK})$ 로 pairwise mask $m_{ij}$ 유도 (PRG)
자기 개인 mask $b_i$ 생성 (자기 secret 로부터)
마스크된 업데이트 전송: $$y_i = x_i + \sum_{j > i} m_{ij} - \sum_{j < i} m_{ji} + b_i \pmod{R}$$

$b_i$ 는 자기 자신만 아는 additional mask, dropout 대응용.

Round 3: Unmasking

서버는 살아남은 클라이언트 집합 $U$ 를 확정. 살아남은 클라이언트는:

$j \in U$ 라면: $b_j$ 를 자기 secret 로 복원 후 서버에 전송
$j \notin U$ (dropout) 라면: $j$ 의 secret share 를 다른 클라이언트들이 서버에 전송해 $s_j$ 복원, 이로부터 ${m_{ij}}$ 재생성

서버가 살아남은 클라이언트의 $b_j$ 합 을 계산해 빼고, dropout 클라이언트의 pairwise mask 합 도 계산해 빼면:

$$ \sum_{i \in U} y_i - \sum_{i \in U} b_i - \sum_{\text{dropped}} \text{recovered masks} = \sum_{i \in U} x_i $$

깨끗한 합이 도출됩니다.

왜 두 개의 마스크가 필요한가

Pairwise mask ($m_{ij}$): 모든 클라이언트가 살아있다면 상쇄, 서버가 개별 값 못 봄
Self mask ($b_i$): dropout 이 발생해도 $x_i$ 노출 방지

만약 self mask 없이 pairwise 만 있다면, dropout 클라이언트의 pairwise 를 복원할 때 살아있는 클라이언트의 $x_i$ 가 잠깐 노출 될 수 있습니다. Self mask 로 이 constraint 를 해소.

통신 복잡도

Bonawitz 원 프로토콜:

클라이언트당 $O(n)$ 통신 (모든 다른 클라이언트와 key exchange)
$n$ = 1000 정도면 감내 가능하지만 $n = 10^6$ 은 불가능

SecAgg+ (Bell et al., 2022): 통신을 $O(\log n)$ 으로 줄임. 각 클라이언트는 로그 스케일의 이웃과만 통신. 대규모 cross-device FL 에서 실용화.

대안 접근

1. Homomorphic Encryption (HE)

각 클라이언트가 업데이트를 HE 로 암호화 하여 서버에 전송. 서버는 암호화된 상태로 덧셈 수행, 결과만 신뢰된 aggregator 가 복호화.

Pros: 담합 우려 없음, 단순한 데이터 흐름
Cons: 연산 비용이 매우 큼 (수십~수백 배), gradient 크기 큰 딥러닝에 부담
대표 스킴: BFV, CKKS (approximate arithmetic)

2. Trusted Execution Environment (TEE)

서버측 SGX/TDX enclave 에서 raw 업데이트를 받아 집계. Enclave 코드가 서명되어 외부에서 검증 가능.

Pros: 성능 오버헤드 작음
Cons: 하드웨어 신뢰 필요, side-channel 공격 사례 존재

3. Multi-Party Computation (MPC)

여러 non-colluding 서버가 집계 계산을 분산 수행. 어느 한 서버도 완전한 정보를 갖지 않음.

Pros: 강한 이론 보장
Cons: 여러 서버 인프라 필요, 통신 라운드 증가

Differential Privacy 와의 결합

Secure Aggregation 은 집계의 은닉 을 보장하지만, 집계 결과 자체 에는 정보가 남습니다. 서버가 집계된 gradient 를 여러 라운드 관찰하면 개별 정보를 추정할 수 있음.

해결: 각 클라이언트가 자기 gradient 에 [[differential-privacy|DP noise]] 를 추가하고 그 결과를 Secure Aggregation.

$$ \tilde{x}_i = x_i + \mathcal{N}(0, \sigma^2 I) $$

또는 central DP: 신뢰된 aggregator 가 집계 후에 노이즈 추가. 필요 노이즈 양이 client-level DP 대비 작음.

실전 프레임워크 지원

TensorFlow Federated: tff.aggregators.secure_aggregation
Flower: FedAvg 에 secure aggregation strategy plugin
NVFlare: SAG (Scatter and Gather) 워크플로에 통합
CrypTen (Meta): PyTorch 기반 MPC
PySyft (OpenMined): HE + MPC 통합

함정

[!WARNING] DP 없는 Secure Aggregation 은 완전한 프라이버시가 아닙니다. 집계된 gradient 로부터도 정보가 새므로, DP 와 반드시 결합.

[!CAUTION] Dropout 관리가 까다롭습니다. 임계값 $t$ 를 잘못 잡으면 프로토콜이 실패하거나 (너무 많이 dropout) 프라이버시가 훼손 (담합 임계값 낮음).

[!WARNING] Byzantine 클라이언트가 임의의 큰 값을 넣으면 결과가 오염 됩니다. Secure Aggregation 은 담합/도청은 방어하지만 값 검증은 안 함. Robust aggregation (Krum, Median) 이 별도 필요.

[!IMPORTANT] 모듈러 산술 (mod R) 오버플로 관리. 실수를 정수로 quantize 하고 R 을 충분히 크게 잡아야 합계가 wrap-around 안 함.

[!CAUTION] 암호학적 primitive 를 직접 구현하지 마세요. 검증된 라이브러리 (TFF, Flower, OpenMined) 를 사용. Side-channel 공격은 다이렉트 구현에서 흔한 위험.

프로토콜 흐름 시각화

flowchart TD
    R0["Round 0: 키 광고<br/>각 클라이언트, DH 공개키 서버 전송"]
    R1["Round 1: 키 분배<br/>Shamir Secret Sharing, 임계값 t"]
    R2["Round 2: 마스크된 업데이트<br/>pairwise mask + self mask 적용"]
    R3["Round 3: 마스크 제거<br/>살아남은 클라이언트 b_j 공개, dropout 복원"]
    Done["집계 완료: gradient 합만 노출"]
    R0 --> R1 --> R2 --> R3 --> Done

Dropout 처리 흐름

flowchart LR
    Alive["살아남은 클라이언트 U"] -->|"b_j 제출"| Server[서버]
    Dropped["Dropout 클라이언트"] -->|"Shamir 복원"| MaskRec["mask 재생성"]
    MaskRec --> Server
    Server --> Sum["sum(x_i for i in U)"]

SecAgg+ 통신 복잡도

프로토콜	클라이언트당 통신	n=10^6 적합
Bonawitz SecAgg	O(n)	불가
SecAgg+ (Bell 2022)	O(log n)	가능
TEE 방식	O(1)	가능 (하드웨어 신뢰 필요)

SecAgg+ 는 각 클라이언트를 $k$-정규 그래프 이웃과만 연결. 이웃 수 $k = O(\log n)$ 로 전체 통신량이 대폭 감소.

공격 방어 매핑

공격 유형	Secure Aggregation 대응	추가 방어 필요
Gradient inversion	개별 gradient 미노출	DP noise 병행 권장
Honest-but-curious server	집계 값만 노출	-
Collusion (t 이하)	Shamir threshold 로 차단	-
Byzantine (값 오염)	미대응	Robust aggregation (Krum, Median)
Model poisoning	미대응	이상값 탐지
Dropout 공격	t 이하 dropout 허용	임계값 조정

Secure Aggregation 은 누가 무엇을 보는가 를 제어. 무엇을 넣는가 는 별도 방어 레이어가 필요.

실전 구현 고려사항

# TensorFlow Federated
import tensorflow_federated as tff

secure_sum = tff.aggregators.SecureModularSumFactory(
    modulus=2**20,   # R: wrap-around 방지. gradient 합이 R 을 넘지 않도록 설정
)

# Flower: strategy 플러그인 방식으로 SecAgg 적용
# from flwr.server.strategy import FedAvg + SecureAggregation adapter

클라이언트 수 $n$, 임계값 $t$, gradient 차원 $d$ 에 따라 통신 오버헤드 추정:

$$ \text{총 통신량} \approx n \cdot k \cdot d \cdot \text{element_size} $$

대규모 배포 전 $d \times n$ 통신량 계산 필수. 7B 모델 ($d \approx 10^7$) 에서 클라이언트당 수백 MB 발생.

[AWS SageMaker] Model Monitor: 모델 및 데이터 드리프트 감지

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

[!WARNING] AWS 공식 발표 (2026): 2026-07-30 부터 SageMaker Model Monitor 는 신규 고객 사용이 중단됩니다. 기존 사용 고객은 계속 이용 가능하며 보안/가용성 개선은 유지되지만, 신규 기능 추가는 없습니다. 대안으로 Amazon SageMaker AI 통합 모니터링, 또는 서드파티 (EvidentlyAI, WhyLabs, Arize, Fiddler 등) 를 고려하세요.

정의

Amazon SageMaker Model Monitor 는 SageMaker AI 로 프로덕션 배포된 ML 모델의 데이터 및 모델 품질을 지속 모니터링 하고, 드리프트가 발생하면 알림을 보내는 관리형 서비스입니다. 실시간 endpoint 와 배치 transform 작업 양쪽 모두를 지원합니다.

핵심 아이디어: 학습 데이터로 baseline 통계 를 만들어 두고, 프로덕션 요청/응답을 캡처하여 주기적으로 baseline 과 비교, 위반 (violation) 을 감지합니다.

4 가지 모니터 타입

Model Monitor 가 제공하는 네 가지 감시 유형입니다.

1. Data Quality Monitor

입력 데이터 통계 변화 감지
학습 데이터의 통계 (feature 별 평균, 분산, 결측 비율, distinct 개수, 데이터 타입 등) 를 baseline 으로 삼음
프로덕션 입력이 이 통계에서 크게 벗어나면 위반
Data drift 라고도 부름

2. Model Quality Monitor

예측 성능 지표 자체를 모니터링
Accuracy, F1, precision, recall, MSE, MAE 등 (참고: [[classification-metrics|분류 모델 지표]])
정답 라벨 (ground truth) 이 나중에 제공되어야 하므로, 프로덕션 예측과 라벨을 매칭하는 파이프라인이 필요
Concept drift 감지 목적

3. Bias Drift Monitor

인구통계 집단 간 예측 편향 변화
SageMaker Clarify 와 통합
지표: DPPL (Difference in Positive Proportions in Predicted Labels), DI (Disparate Impact) 등
학습 시점 대비 특정 집단에 대한 편향이 커졌는지 감시

4. Feature Attribution Drift Monitor

feature importance 분포 변화
SHAP 값 기반, 각 feature 가 예측에 기여하는 정도가 학습 시점과 달라졌는지
입력 통계는 안 변했는데 feature 의 역할이 바뀐 미묘한 shift 를 잡음

아키텍처

┌──────────────┐    inference    ┌───────────────────┐
│   Client     │ ─────────────>  │  SageMaker        │
└──────────────┘   request +     │  Endpoint         │
       ▲          response       │  (with            │
       │                         │   DataCapture)    │
       │                         └────────┬──────────┘
       │                                  │ capture
       │                                  ▼
       │                          ┌────────────────┐
       │                          │   S3 bucket    │  ◀── training data baseline
       │                          │   captured/    │      (statistics.json,
       │                          └────────┬───────┘       constraints.json)
       │                                   │
       │                                   ▼
       │                          ┌────────────────┐
       │                          │  Monitoring    │
       │                          │  Schedule      │  (hourly / daily)
       │                          │  (Processing   │
       │                          │   Job)         │
       │                          └────────┬───────┘
       │                                   │
       │                                   ▼
       │                          ┌────────────────┐
       │  alert  ┌────────────┐   │  CloudWatch    │
       └────────┤ SNS/Lambda  ├───┤  Metrics +     │
                └────────────┘    │  Alarms        │
                                  └────────────────┘

단계별 컴포넌트

Data Capture: 엔드포인트에 DataCaptureConfig 활성화, 입력/출력을 S3 에 저장
Baseline: 학습 데이터에서 suggest_baseline() 실행 → statistics.json + constraints.json 생성
Monitoring Schedule: cron 또는 hourly 로 Processing Job 자동 실행
Processing Job: 컨테이너에서 캡처 데이터 vs baseline 비교, 위반 리포트 생성
CloudWatch: 위반 개수, 지표를 CloudWatch 메트릭으로 발행. 알람 → SNS → Lambda / Slack / PagerDuty

Python SDK 클래스

sagemaker Python SDK 의 각 모니터 클래스:

클래스	모니터 타입
`sagemaker.model_monitor.DefaultModelMonitor`	Data Quality
`sagemaker.model_monitor.ModelQualityMonitor`	Model Quality
`sagemaker.model_monitor.ModelBiasMonitor`	Bias Drift
`sagemaker.model_monitor.ModelExplainabilityMonitor`	Feature Attribution Drift

공통 인터페이스:

suggest_baseline(...): baseline 통계 생성
create_monitoring_schedule(...): 스케줄 등록
describe_schedule(), list_executions(), stop_monitoring_schedule(), delete_monitoring_schedule()

실전 코드 (Data Quality)

1. Endpoint 에 Data Capture 활성화

from sagemaker.model_monitor import DataCaptureConfig

data_capture_config = DataCaptureConfig(
    enable_capture=True,
    sampling_percentage=100,
    destination_s3_uri=f"s3://{bucket}/captured/",
    capture_options=["REQUEST", "RESPONSE"],
    csv_content_types=["text/csv"],
    json_content_types=["application/json"],
)

predictor = model.deploy(
    initial_instance_count=1,
    instance_type="ml.m5.xlarge",
    data_capture_config=data_capture_config,
)

2. Baseline 생성

from sagemaker.model_monitor import DefaultModelMonitor
from sagemaker.model_monitor.dataset_format import DatasetFormat

monitor = DefaultModelMonitor(
    role=role,
    instance_count=1,
    instance_type="ml.m5.xlarge",
    volume_size_in_gb=20,
    max_runtime_in_seconds=3600,
)

monitor.suggest_baseline(
    baseline_dataset=f"s3://{bucket}/training-data.csv",
    dataset_format=DatasetFormat.csv(header=True),
    output_s3_uri=f"s3://{bucket}/baselines/",
    wait=True,
)

결과로 statistics.json (feature 별 mean, std, min, max, distinct_count 등) 과 constraints.json (허용 범위) 이 생깁니다.

3. Monitoring Schedule 등록

from sagemaker.model_monitor import CronExpressionGenerator

monitor.create_monitoring_schedule(
    monitor_schedule_name="my-daily-monitor",
    endpoint_input=predictor.endpoint_name,
    output_s3_uri=f"s3://{bucket}/monitor-reports/",
    statistics=monitor.baseline_statistics(),
    constraints=monitor.suggested_constraints(),
    schedule_cron_expression=CronExpressionGenerator.hourly(),
    enable_cloudwatch_metrics=True,
)

4. CloudWatch 알람 연결

import boto3

cw = boto3.client("cloudwatch")

cw.put_metric_alarm(
    AlarmName="ModelMonitor-FeatureBaselineDrift",
    MetricName="feature_baseline_drift_check_violations",
    Namespace="aws/sagemaker/Endpoints/data-metrics",
    Statistic="Sum",
    Period=3600,
    EvaluationPeriods=1,
    Threshold=1,
    ComparisonOperator="GreaterThanOrEqualToThreshold",
    AlarmActions=["arn:aws:sns:us-east-1:123:model-alerts"],
    Dimensions=[
        {"Name": "Endpoint", "Value": predictor.endpoint_name},
        {"Name": "MonitoringSchedule", "Value": "my-daily-monitor"},
    ],
)

Model Quality 의 ground truth 연결

Model Quality Monitor 는 예측 결과와 실제 정답을 매칭 해야 하는 게 특별합니다.

예측 시 각 요청에 inference_id 부여 (헤더 또는 payload 필드)
나중에 정답 라벨이 확정되면 s3://.../ground_truth/YYYY/MM/DD/HH/data.json 에 저장
Model Quality Monitor 가 이 두 소스를 조인해서 accuracy/F1 등 계산

라벨 지연이 큰 서비스 (예: 이탈 예측은 30 일 후 결과 확인) 에는 스케줄을 그에 맞게 설정합니다.

Baseline 파일 형식

statistics.json (예)

{
  "version": 0.0,
  "dataset": { "item_count": 10000 },
  "features": [
    {
      "name": "age",
      "inferred_type": "Fractional",
      "numerical_statistics": {
        "common": { "num_present": 9980, "num_missing": 20 },
        "mean": 34.5, "sum": 344310, "std_dev": 12.3,
        "min": 18, "max": 88,
        "distribution": { "kll": { ... } }
      }
    }
  ]
}

constraints.json (예)

{
  "version": 0.0,
  "features": [
    {
      "name": "age",
      "inferred_type": "Fractional",
      "completeness": 0.998,
      "num_constraints": { "is_non_negative": true }
    }
  ],
  "monitoring_config": {
    "evaluate_constraints": "Enabled",
    "datatype_check_threshold": 1.0,
    "domain_content_threshold": 1.0,
    "distribution_constraints": {
      "perform_comparison": "Enabled",
      "comparison_threshold": 0.1,
      "comparison_method": "Robust"
    }
  }
}

comparison_method 는 Simple / Robust / LInfty 등이 있으며, 통계 비교 방식을 정의합니다.

지원 데이터 타입 제한

tabular 입력만 자동 통계 지원. 이미지 분류 모델의 이미지 입력은 통계 계산 불가, 하지만 출력 라벨은 모니터링 가능
Multi-model endpoint 미지원
Data Capture 저장소 disk 사용률 75% 이상이면 캡처 중단 → 정기 정리 필요

다른 도구와 비교

도구	관리 방식	강점	약점
SageMaker Model Monitor	AWS 관리형	SageMaker 통합 편함	2026-07-30 신규 종료, 커스터마이징 제한
EvidentlyAI	오픈소스 + 클라우드	시각화 강함, 프레임워크 애그노스틱	셀프 호스팅 부담
WhyLabs	SaaS	whylogs 프로파일링 라이브러리 좋음	유료
Arize AI	SaaS	LLM 모니터링 강점 (Phoenix)	유료
Fiddler	SaaS	대기업 규제 산업 대응	무거움
Prometheus + Grafana + 자체 스크립트	셀프	완전 제어	초기 구현 부담

비용

Model Monitor 는 처리 작업 (Processing Job) 실행 비용 을 청구합니다:

인스턴스 타입 (ml.m5.xlarge 등) × 실행 시간
하루 24 회 (매 시간) × 30 분씩 실행이면 대략 12 시간분 비용
S3 저장 (capture, baseline, report), CloudWatch 메트릭 별도

프로덕션에서는 하루 1~2 회 스케줄로 충분한 경우가 많습니다.

Best Practice

Baseline 은 학습 데이터가 아니라 최근 검증 데이터 로 만들면 편차가 작습니다
Alert threshold 를 여러 심각도로 (warning: violations>=1, critical: violations>=5)
CloudWatch 대신 EventBridge → Lambda → 슬랙 을 자주 사용
비용 통제: 트래픽 크면 sampling_percentage=10 정도로 낮춰서 캡처
Model Quality 는 라벨 지연을 감안 하여 스케줄 늦춤
위반이 나면 자동 재학습 트리거 하는 파이프라인 (SageMaker Pipelines + Step Functions)
드리프트가 아니라 데이터 파이프라인 문제일 가능성 을 먼저 검토 (매핑 코드 변경, 스키마 변경 등)

Model Drift 개념 정리

Model Monitor 가 감지하려는 것들:

Data Drift (Covariate Shift): 입력 $P(X)$ 분포 변화. 데이터 자체가 달라진 경우
Concept Drift: 입력-출력 관계 $P(Y|X)$ 변화. 예측 대상 자체의 성질 변화 (예: 사기 패턴이 진화)
Label Drift: $P(Y)$ 변화. 실제 정답 분포가 달라진 경우
Prediction Drift: 모델 예측 $P(\hat{Y})$ 변화. 위 셋 중 하나 이상의 결과

각각 다른 시그널이며, 4 가지 모니터가 이 시그널들을 부분적으로 커버합니다.

대안 (2026 신규 종료 이후)

신규 프로젝트라면 다음을 고려:

Evidently + SageMaker Pipelines: 오픈소스, SageMaker 안에서 처리 작업으로 실행
whylogs + WhyLabs: 데이터 프로파일링 라이브러리, WhyLabs SaaS
자체 구축: Great Expectations 로 데이터 품질, MLflow 로 모델 성능 트래킹
AWS 대체: 앞으로 나올 SageMaker AI 의 통합 모니터링 (공지 참고)

참고

관련 [[classification-metrics|분류 모델 지표]] 는 Model Quality Monitor 의 근간
관련 [[transfer-learning|Transfer Learning]] fine-tuned 모델도 동일하게 모니터링 대상
AWS 공식: Model Monitor, Availability change
참고 아티클: Model drift 관련 개념

Differential Privacy: (ε, δ) 로 정량화하는 프라이버시 보장

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

Differential Privacy (DP, 차분 프라이버시) 는 데이터셋에 대한 질의 (query) 결과에 calibrated noise 를 추가함으로써, 한 개인의 데이터가 포함되었는지 여부 를 결과만 보고서는 알 수 없게 만드는 수학적 프라이버시 프레임워크입니다. Cynthia Dwork 등이 2006 년에 정의했습니다.

핵심 아이디어: “당신이 데이터셋에 있든 없든, 통계 결과는 거의 같게 보이도록 만든다.”

왜 등장했는가

전통적 익명화 (identifier 제거, k-anonymity, l-diversity 등) 는 linkage attack 에 취약합니다.

Netflix Prize (2007): 익명화된 시청 기록이 IMDb 공개 리뷰와 결합되어 사용자 재식별
AOL 검색 로그 (2006): 사용자 ID 만 익명화했지만 검색 쿼리 자체가 지문 역할
Massachusetts governor 재식별 (Sweeney, 1997): ZIP + 생년월일 + 성별 3 축만으로 87% 재식별 가능

문제의 본질: 관측 가능한 결과가 특정 개인의 데이터에 크게 의존 하면, 아무리 이름을 지워도 그 개인이 데이터에 있었다는 사실 자체가 새어 나갑니다. DP 는 이 의존성을 정량적 상한 으로 제어합니다.

형식 정의

인접 데이터셋 (Adjacent Datasets)

두 데이터셋 $D$ 와 $D’$ 이 정확히 한 레코드만 다를 때 인접 (adjacent) 이라고 합니다.

Add/Remove 인접: $D’ = D \cup {x}$ 또는 $D’ = D \setminus {x}$
Replace 인접: $D’$ 이 $D$ 의 한 레코드를 다른 값으로 바꾼 결과

정의에 따라 프라이버시 보장 강도가 조금씩 달라지지만, 실용적으로는 큰 차이 없습니다.

ε-Differential Privacy (pure DP)

무작위 알고리즘 $\mathcal{M}$ 이 $\epsilon$-DP 를 만족한다는 것은, 임의의 인접 데이터셋 $D, D’$ 과 임의의 출력 집합 $S$ 에 대해:

$$ \Pr[\mathcal{M}(D) \in S] \leq e^{\epsilon} \cdot \Pr[\mathcal{M}(D’) \in S] $$

$\epsilon$ (epsilon): 프라이버시 손실의 상한. 작을수록 강력한 보장.
$e^\epsilon \approx 1 + \epsilon$ (작은 $\epsilon$ 일 때), 즉 두 확률 분포가 매우 유사.

(ε, δ)-Differential Privacy (approximate DP)

$$ \Pr[\mathcal{M}(D) \in S] \leq e^{\epsilon} \cdot \Pr[\mathcal{M}(D’) \in S] + \delta $$

$\delta$: 위 부등식이 실패할 확률의 상한. 보통 $\delta \ll 1/n$ (데이터 크기의 역수보다 작게)
Gaussian mechanism 등은 pure DP 를 만족할 수 없어 approximate DP 를 씀

Rule of thumb:

$\epsilon \leq 1$: 강한 보장
$1 < \epsilon \leq 3$: 중간
$\epsilon > 10$: 실질적 보장 미미 (경고 신호)
$\delta < 1/n^2$ 정도 권장 (Dwork 의 조언)

왜 이 정의인가

DP 의 강력한 점:

개인 데이터의 존재/부재를 감출 수 있음: 공격자가 사전에 알고 있는 정보가 아무리 많아도 (어떤 auxiliary data 를 가지고 있어도) 새 정보를 얻기 어려움
Composition 가능: 여러 DP 쿼리를 합쳐도 여전히 DP 성질 유지 (예산 합산)
Post-processing immunity: DP 결과에 어떤 계산을 추가로 해도 여전히 DP 유지
미래 공격에 대비: 특정 공격을 상정하지 않고 최악 케이스를 다룸

핵심 개념: Sensitivity

함수 $f: \text{Data} \to \mathbb{R}^d$ 의 global sensitivity 는 인접 데이터셋에 대한 함수 값 변화의 상한:

$$ \Delta f = \max_{D, D’ \text{ adjacent}} | f(D) - f(D’) |_1 $$

개수 세기 (count): $\Delta f = 1$ (한 명 추가/제거하면 결과 1 변함)
평균 (mean) with bounded values in $[0, M]$: $\Delta f = M/n$
합 (sum) with bounded values in $[0, M]$: $\Delta f = M$

Sensitivity 가 클수록 더 많은 노이즈가 필요합니다. 값을 미리 clip 해서 sensitivity 를 제어 하는 게 실전에서 매우 흔한 패턴입니다.

핵심 메커니즘

Laplace Mechanism

$\epsilon$-DP 를 만족하는 가장 단순한 방법. Laplace 분포에서 노이즈 샘플:

$$ \mathcal{M}(D) = f(D) + \text{Lap}\left( \frac{\Delta f}{\epsilon} \right) $$

Laplace 분포는 라플라스 확률 밀도 $\text{Lap}(b): p(x) = \frac{1}{2b} e^{-|x|/b}$.

import numpy as np

def laplace_mechanism(true_value, sensitivity, epsilon):
    noise = np.random.laplace(loc=0, scale=sensitivity/epsilon)
    return true_value + noise

# 예: 데이터셋에서 특정 조건 만족하는 사용자 수 세기
true_count = 4321
noisy_count = laplace_mechanism(true_count, sensitivity=1, epsilon=0.5)

Gaussian Mechanism

$(\epsilon, \delta)$-DP 를 만족. L2 sensitivity 사용:

$$ \mathcal{M}(D) = f(D) + \mathcal{N}\left(0, \left(\frac{\Delta_2 f \cdot \sqrt{2 \ln(1.25/\delta)}}{\epsilon}\right)^2 \right) $$

Gaussian 은 여러 차원의 합성에서 유리하며, DP-SGD 등에서 표준입니다.

Exponential Mechanism

범주형/불연속 출력 에 사용. Utility 함수 $u(D, r)$ 을 정의하고:

$$ \Pr[\mathcal{M}(D) = r] \propto \exp\left( \frac{\epsilon \cdot u(D, r)}{2 \Delta u} \right) $$

Utility 가 높은 후보를 확률적으로 우선 선택합니다. 경매, 후보 선택 문제에 씀.

Composition

여러 DP 쿼리를 순차적으로 하면 프라이버시가 누적됩니다.

Basic Composition

$k$ 개의 $(\epsilon_i, \delta_i)$-DP 메커니즘의 순차 합성은:

$$ \left(\sum \epsilon_i, \sum \delta_i\right)\text{-DP} $$

간단하지만 상당히 loose 합니다.

Advanced Composition (Dwork et al., 2010)

$k$ 개의 $(\epsilon, \delta)$-DP 메커니즘의 합성은 다음과 같이 tighter:

$$ \left(\epsilon’ = \epsilon \sqrt{2k \ln(1/\delta’)} + k \epsilon (e^\epsilon - 1), ; k\delta + \delta’\right)\text{-DP} $$

Basic 대비 $\sqrt{k}$ 배 정도로 개선됩니다.

Rényi DP 를 통한 tighter composition

Mironov (2017) 의 Rényi DP 는 Rényi divergence 로 프라이버시를 정의합니다. 합성이 매우 tight 하며 최종적으로 $(\epsilon, \delta)$-DP 로 변환합니다. DP-SGD 의 privacy accounting 은 사실상 Rényi DP + Moments Accountant 방식입니다.

Privacy Budget

한 데이터셋에 대해 여러 분석을 하고 싶다면, 각 분석마다 $\epsilon_i$ 를 배분해야 합니다.

$$ \sum_i \epsilon_i \leq \epsilon_{\text{total}} $$

총 예산 소진 후에는 더 이상 어떤 쿼리도 하면 안 됨
프로덕션에서는 accountant 로 남은 예산을 실시간 추적
예산이 부족하면: 데이터셋 refresh, 사용자 그룹 세분화, 더 세밀한 clipping 으로 sensitivity 감소

Central DP vs Local DP

Central DP (Trusted Curator)

신뢰할 수 있는 데이터 큐레이터 존재
큐레이터가 원본 데이터를 보고 노이즈 추가 후 결과 공개
Utility 높음, 프라이버시 보장은 큐레이터를 신뢰한다는 전제
예: 미국 인구조사국, 대부분의 학술 통계

Local DP (LDP)

신뢰할 수 있는 큐레이터가 없음
각 개인이 자기 데이터에 노이즈를 추가하고 서버에 전송
서버는 노이즈가 낀 데이터만 받으므로 원본을 알 수 없음
Utility 매우 낮음 (같은 $\epsilon$ 이면 노이즈가 훨씬 커야 함)
Apple, Google 이 자주 배포

RAPPOR (Google, 2014)

LDP 의 대표 배포. Chrome 사용자의 홈페이지 URL 통계를 수집할 때 각 사용자가 자기 URL 을 Bloom filter 로 인코딩한 뒤 각 비트를 randomized response 로 뒤집어 전송. 서버는 통계만 복원 가능, 개인 URL 은 알 수 없음.

비교

구분	Central DP	Local DP
신뢰 모델	큐레이터 신뢰 필요	Trustless
노이즈 위치	서버 (집계 후)	클라이언트 (개별 데이터)
같은 ε 에서 utility	높음	낮음
배포 사례	미국 인구조사, 학술	Apple 이모지, Google RAPPOR

DP-SGD, 딥러닝 학습의 DP

Abadi et al. (2016) 이 제안한 DP-SGD (Differentially Private SGD) 는 딥러닝 학습에 DP 를 적용하는 표준 방법입니다.

알고리즘:

Sample: 각 step 에서 mini-batch 를 Poisson sampling (각 샘플이 확률 $q = B/N$ 로 포함)
Compute per-sample gradients: 각 샘플에 대한 gradient 를 개별 계산
Clip: 각 gradient 를 L2 norm 상한 $C$ 로 클립 $$ \bar{g}_i = g_i / \max\left(1, \frac{|g_i|_2}{C}\right) $$
Aggregate + noise: 클립된 gradient 를 합산하고 Gaussian noise 추가 $$ \tilde{g} = \frac{1}{B}\left( \sum_i \bar{g}_i + \mathcal{N}(0, \sigma^2 C^2 I) \right) $$
Update: $\theta \leftarrow \theta - \eta \tilde{g}$

노이즈 배율 $\sigma$ 와 sampling 확률 $q$, 총 step 수 $T$ 로부터 최종 $(\epsilon, \delta)$ 를 계산합니다 (Moments Accountant 또는 Rényi DP accountant).

Opacus (PyTorch)

Facebook Research 의 PyTorch DP 라이브러리:

from opacus import PrivacyEngine

model = MyModel()
optimizer = torch.optim.SGD(model.parameters(), lr=0.05)
data_loader = torch.utils.data.DataLoader(dataset, batch_size=256)

privacy_engine = PrivacyEngine()

model, optimizer, data_loader = privacy_engine.make_private(
    module=model,
    optimizer=optimizer,
    data_loader=data_loader,
    noise_multiplier=1.1,       # σ
    max_grad_norm=1.0,          # C
)

for epoch in range(N):
    for batch, labels in data_loader:
        optimizer.zero_grad()
        loss = criterion(model(batch), labels)
        loss.backward()
        optimizer.step()

    epsilon = privacy_engine.get_epsilon(delta=1e-5)
    print(f"epoch {epoch}: (ε={epsilon:.2f}, δ=1e-5)")

DP-SGD 의 utility 손실

이미지 분류에서 clean 대비 5~15%p accuracy 손실이 흔함
LLM 파인튜닝에서는 더 심각할 수 있음
완화: PEFT 와 결합 (파라미터 수가 적으면 노이즈 영향 감소), 사전 학습 모델 재사용, 더 큰 batch

실배포 사례

Apple (2016~)

iOS 10 부터 emoji 추천, QuickType 같은 기능에 LDP. Randomized response 계열, ε 는 일당 수 단위. WWDC 2016 발표.

Google

RAPPOR (Chrome, 2014)
Federated Learning + DP (Gboard 다음 단어 예측)
Google Health 데이터 집계

US Census (2020)

2020 년 미국 인구조사가 DP 를 공식 채택. 발표된 통계에 Gaussian noise 를 추가한 것이 정치적 논란도 있었지만 역사적 이정표입니다. Epsilon 은 여러 통계별로 배분 (총 예산 약 $\epsilon = 19.6$).

Microsoft

Windows telemetry 에 LDP 적용
SmartNoise 오픈소스 릴리스

학술 데이터셋

OpenDP 프로젝트 (Harvard) 가 공공 데이터셋 릴리스에 DP 도구 제공

프레임워크

도구	특징
Opacus	PyTorch, DP-SGD, Facebook
TensorFlow Privacy	TF, DP-SGD, Google
OpenDP	Harvard, rigorous verification, Rust core + Python binding
Diffprivlib	IBM, sklearn-호환 인터페이스
SmartNoise	Microsoft + OpenDP, 통계 쿼리 지향
PyDP	OpenMined, Google DP C++ 라이브러리 wrapper

한계와 유의점

Utility-Privacy Trade-off

강력한 프라이버시 ($\epsilon$ 작게) 는 노이즈 증가 → 정확도 하락. “공짜 프라이버시” 는 없습니다.

ε 해석의 어려움

실무자에게 ε=1 이 “얼마나 안전한지” 직관 어려움
$e^\epsilon$ 배 정도의 확률 차이라고 설명해도 감이 안 오는 경우 많음
최근에는 Bayesian re-interpretation 이나 membership inference attack 성공률로 환산해 설명하려는 시도

데이터 카탈로그 문제

DP 는 각 쿼리 에 대해 보장하는 것이지, 데이터셋 자체를 “완전히 익명” 만드는 것이 아닙니다. 여러 릴리스가 쌓이면 예산이 소진됩니다.

결측치와 outlier

극단값이 sensitivity 를 크게 만들어 노이즈가 급증합니다. Clipping 을 잘 설계해야 함.

Group Privacy 는 다름

DP 는 “한 개인” 을 보호합니다. 가족처럼 상관관계 있는 그룹은 별도 분석 필요.

정확한 구현이 어려움

Floating-point 구현이 이론과 미묘하게 어긋나 실제로 DP 를 위반하는 사례 보고 (Mironov, 2012)
Random number generator 품질 중요
이 때문에 검증된 라이브러리 (Opacus, OpenDP) 사용 강력 권장

방법	보장 강도	특징
Identifier 제거	매우 약함	Netflix, AOL 사건으로 실패 증명
k-anonymity	약함	Quasi-identifier 지정 필요, 조합 attack 취약
l-diversity, t-closeness	약함~중간	k-anonymity 개선판, 실전 여전히 어려움
Differential Privacy	강함, 정량	Composition 성질, 미래 공격에 대비
Secure Multi-Party Computation (MPC)	강함	계산 자체는 정확, 프로토콜 비용 큼
Homomorphic Encryption (HE)	강함	암호화 상태 계산, 매우 느림
Federated Learning	자체 보장 없음	Gradient inversion 취약, DP 와 결합 필요

참고

관련 [[federated-learning|Federated Learning]] 에 DP 를 결합한 학습
관련 [[transfer-learning|Transfer Learning]] 파인튜닝 시 DP-SGD 로 개인정보 보호
관련 [[classification-metrics|분류 모델 지표]] DP 학습 모델도 동일 지표로 평가
정본 교과서: Dwork & Roth 2014, The Algorithmic Foundations of Differential Privacy
Wikipedia: Differential privacy
강의 자료: Boston University CS 591, Harvard OpenDP

Federated Learning: 분산 학습 without central data

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

Federated Learning (FL) 은 데이터를 중앙에 모으지 않고 각 클라이언트 (edge device, 병원, 은행 등) 가 로컬 데이터로 모델을 학습한 뒤 모델 파라미터의 업데이트 (gradient 또는 weight) 만 서버에 전송하여 집계하는 분산 학습 패러다임입니다. 서버는 원본 데이터를 절대 보지 않습니다.

Google 이 2016~2017년경 Gboard (Android 키보드) 의 다음 단어 예측 학습을 위해 이 패러다임을 대중화했습니다.

왜 필요한가

개인정보 보호 규정: GDPR (EU), HIPAA (US 의료), 국내 개인정보보호법 등이 원시 데이터의 외부 반출을 제한합니다.
데이터 주권: 병원 / 금융사 등 규제 산업의 데이터는 기관 내부에 머물러야 하는 경우가 많습니다.
엣지 컴퓨팅: 모바일/IoT 에서 데이터를 서버로 계속 전송하기엔 대역폭이 부담입니다.
콜드 데이터: 사용자 로컬에만 존재하는 데이터 (키보드 입력, 사진) 는 애초에 서버로 가지 않습니다.

FedAvg, 기본 알고리즘

McMahan et al. (2017) 의 FedAvg (Federated Averaging) 는 FL 의 원형입니다.

서버 라운드 $t$:

서버는 현재 글로벌 모델 $w_t$ 를 가지고 있습니다.
서버가 $K$ 개 클라이언트를 샘플링 (전체 $N$ 개 중 일부만) 하고 $w_t$ 를 전송합니다.
각 클라이언트 $k$ 는 로컬 데이터 $D_k$ 에서 $E$ epoch 만큼 SGD 를 돌려 $w_k^{t+1}$ 을 얻습니다.
클라이언트가 $w_k^{t+1}$ 을 서버에 전송합니다.
서버가 가중 평균: $$ w_{t+1} = \sum_{k=1}^{K} \frac{n_k}{n} \cdot w_k^{t+1} $$ 여기서 $n_k$ 는 클라이언트 $k$ 의 데이터 개수, $n = \sum n_k$ 입니다.

수백 라운드를 반복하며 글로벌 모델이 수렴합니다.

왜 그냥 gradient 를 보내지 않는가

FedSGD (1 step gradient 만 보내는 방식) 도 가능하지만 통신량이 많아집니다. FedAvg 는 로컬에서 여러 epoch 을 돌리고 나서 weight 을 보내므로 통신 횟수를 크게 줄입니다 (핵심 통찰).

배포 유형

Cross-device FL

수백만 ~ 수억 대의 모바일/IoT 기기
각 기기의 데이터는 소량 (수~수백 샘플)
기기의 가용성은 불안정 (배터리, 네트워크)
실제 예: Google Gboard, Apple Siri, Meta Ranking
Sampling 이 필수 (한 라운드에 전체 클라이언트 대상 불가능)

Cross-silo FL

소수 (2~100 개) 의 신뢰할 수 있는 기관 (병원, 은행)
각 사일로의 데이터는 대량
통신 인프라 안정적
실제 예: NVIDIA Clara (병원간 의료 영상), WeBank FATE (금융 컨소시엄)
모든 사일로가 매 라운드 참여 가능

주요 도전 과제

1. Non-IID 데이터 (Statistical Heterogeneity)

클라이언트마다 데이터 분포가 다릅니다. 예: 어떤 사용자는 영어로만, 어떤 사용자는 한국어로만 타이핑. 이 경우:

각 클라이언트의 local update 가 서로 다른 방향을 가리킴 (client drift)
단순 평균이 잘못된 방향으로 이동
수렴 속도 저하, 최종 성능 하락

2. System Heterogeneity

클라이언트마다 컴퓨팅 성능 다름 (고사양 폰 vs 저사양 폰)
Straggler: 느린 클라이언트 때문에 라운드가 지연됨
배터리, 네트워크 상태로 라운드 중 이탈 (client dropout)

3. Communication Cost

대형 모델 (수 GB) 을 매 라운드 수백만 클라이언트가 다운로드/업로드
Model compression, quantization, sparsification 으로 완화
FetchSGD, top-K sparsification 등 통신 최적화 알고리즘

4. Privacy 공격

Raw 데이터를 보내지 않아도 gradient 자체에서 정보가 새어 나올 수 있습니다.

Gradient inversion: gradient 로부터 원본 이미지 복원 (Zhu et al., 2019 “Deep Leakage from Gradients”)
Membership inference: 특정 샘플이 학습에 쓰였는지 추론

FL 만으로는 프라이버시가 보장되지 않으며, DP 나 Secure Aggregation 을 함께 써야 합니다.

주요 변형

FedProx (Li et al., 2020)

Non-IID 대응. 로컬 objective 에 proximal term 추가:

$$ \min_{w} F_k(w) + \frac{\mu}{2} | w - w_t |^2 $$

$\mu$ 는 하이퍼파라미터. 로컬 업데이트가 글로벌 모델에서 너무 멀리 벗어나지 못하도록 제약. Client drift 완화.

FedYogi / FedAdam (Reddi et al., 2020)

서버에서 adaptive optimizer 사용. FedAvg 는 서버측에서 단순 평균이지만, FedYogi 는 Yogi (Adam 변형) 를 서버에 적용해 수렴을 안정화합니다.

SCAFFOLD (Karimireddy et al., 2020)

Control variate 를 도입하여 client drift 를 correction. 클라이언트가 로컬 gradient 방향을 조정하는 벡터 $c_k$ 를 관리:

$$ w_k \leftarrow w_k - \eta (g_k - c_k + c) $$

Non-IID 에서 FedAvg 보다 훨씬 빨리 수렴.

개인화 FL (Personalized FL)

모든 클라이언트가 같은 글로벌 모델을 쓰는 대신, 글로벌 모델 + 로컬 튜닝 형태:

Per-FedAvg: MAML 계열, 글로벌 모델을 각 클라이언트가 한 step 파인튜닝
pFedMe: 클라이언트가 자기 모델 + 정규화 (글로벌 근처)
Ditto: 글로벌 + 개인 모델 병존, 두 목적을 함께 최적화

Privacy-Enhancing Techniques

Differential Privacy (DP)

Gradient/weight 에 calibrated noise 를 추가하여, 특정 개인의 데이터가 있었는지 확률적으로 알 수 없게 만듭니다.

DP-SGD (Abadi et al., 2016):

Gradient 를 클립 (norm 상한 $C$)
Gaussian noise $\mathcal{N}(0, \sigma^2 C^2)$ 추가
Privacy budget $(\epsilon, \delta)$ 로 정량 관리

FL 에서는 client-level DP (한 클라이언트 전체가 있었는지 감추기) 와 sample-level DP (한 샘플이 있었는지 감추기) 두 가지 granularity 가 있습니다.

Secure Aggregation

Bonawitz et al. (2017) 의 프로토콜. 클라이언트들이 자기 업데이트를 cryptographic masking 으로 감춰서 서버가 볼 때는 합만 보이고 개별 값은 못 봅니다.

핵심 아이디어: 클라이언트 쌍 사이에 secret share 를 교환하여 서로의 mask 가 합쳐지면 상쇄되도록 설계. Dropout 이 발생해도 threshold secret sharing 으로 복구 가능합니다.

Homomorphic Encryption (HE)

암호화된 상태로 덧셈/곱셈 연산 가능. Gradient 를 암호화한 채로 서버가 집계, 클라이언트만 복호화. 계산 비용이 매우 크지만 강력한 프라이버시 보장.

프레임워크

프레임워크	개발/유지	특징
Flower	오픈소스 (Adap)	프레임워크 애그노스틱 (PyTorch, TF, JAX), 실전 배포 지향
TensorFlow Federated (TFF)	Google	시뮬레이션 중심, Federated Analytics 강점
PySyft	OpenMined	프라이버시 도구 통합 (HE, MPC, DP)
FATE	WeBank	Cross-silo 산업용, Chinese fintech 배포 사례 다수
NVFlare	NVIDIA	Clara/의료 도메인, 프로덕션 지향
FedML	FedML Inc.	학술 + 산업 겸용 플랫폼

실전 코드 (Flower 예시)

import flwr as fl
import torch

# 클라이언트 정의
class MyClient(fl.client.NumPyClient):
    def get_parameters(self, config):
        return [p.detach().cpu().numpy() for p in model.parameters()]

    def set_parameters(self, parameters):
        for p, new in zip(model.parameters(), parameters):
            p.data = torch.tensor(new)

    def fit(self, parameters, config):
        self.set_parameters(parameters)
        train(model, local_dataloader, epochs=config["local_epochs"])
        return self.get_parameters({}), len(local_dataset), {}

    def evaluate(self, parameters, config):
        self.set_parameters(parameters)
        loss, acc = test(model, val_dataloader)
        return float(loss), len(val_dataset), {"accuracy": acc}

fl.client.start_numpy_client(server_address="server:8080", client=MyClient())

# 서버 정의
strategy = fl.server.strategy.FedAvg(
    fraction_fit=0.1,          # 매 라운드 10% 샘플링
    min_fit_clients=10,
    min_available_clients=100,
    on_fit_config_fn=lambda rnd: {"local_epochs": 1},
)

fl.server.start_server(
    server_address="0.0.0.0:8080",
    config=fl.server.ServerConfig(num_rounds=100),
    strategy=strategy,
)

실전 배포 사례

Google Gboard: 다음 단어 예측, 이모지 추천 모두 FL 로 학습 (2017~)
Apple: Differential Privacy 기반 Emoji 추천, Siri 개선
NVIDIA Clara: COVID-19 흉부 CT 진단 모델을 30 개 병원 협업 학습 (2020)
WeBank FATE: 은행간 신용평가 모델
Meta: 광고 랭킹 모델의 프라이버시 강화 학습

한계와 유의점

극심한 non-IID 에서는 개인화 FL 을 쓰거나 centralized 로 회귀하는 것이 낫습니다.
모델 성능 은 대개 centralized 대비 몇% 낮습니다. 프라이버시 규제 만족이 목적일 때 받아들일 만한 트레이드오프입니다.
디버깅이 어렵습니다. 클라이언트 데이터를 볼 수 없으므로 로컬 이슈 진단이 힘듭니다.
공격 모델을 명시 해야 합니다. Honest-but-curious 서버 vs malicious 서버, 개별 클라이언트 vs 담합 공격 등.

참고

관련 [[differential-privacy|Differential Privacy]] 를 결합하면 client-level / sample-level 프라이버시가 정량 보장됩니다
관련 [[transfer-learning|Transfer Learning]] 을 클라이언트별 개인화에 결합하기도 합니다
관련 [[classification-metrics|분류 모델 지표]] 로 각 라운드 성능 평가
Google AI Blog: Federated Learning: Collaborative Machine Learning without Centralized Training Data
Kairouz et al. 2021, Advances and Open Problems in Federated Learning

Transfer Learning: pre-training, fine-tuning, domain adaptation

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

Transfer Learning 은 source task/domain 에서 학습한 지식을 target task/domain 에 재사용 하여 학습 효율을 높이는 패러다임입니다. 대규모 데이터로 사전 학습한 모델을 소량의 태스크 특화 데이터로 미세 조정하는 것이 대표적입니다.

핵심 가정: 저수준 특징 (edge, syllable, phoneme) 은 대체로 도메인/태스크에 관계없이 유용하다. 이 가정이 성립할 때 처음부터 학습하는 것보다 훨씬 적은 데이터와 시간으로 좋은 성능을 얻을 수 있습니다.

왜 필요한가

데이터 부족: target task 데이터가 수천 개인데 처음부터 CNN/Transformer 를 학습하면 과적합 심함
계산 비용: LLM 을 처음부터 학습하는 것은 조 단위 예산이 필요, 사전 학습 모델 재사용이 현실적
범용 표현 학습: ImageNet 이나 대규모 웹 코퍼스로 학습한 표현은 이후 대부분의 downstream 태스크에 유용

고전 분류 (Pan & Yang, 2010)

Source 와 target 의 도메인 (input 분포) 과 태스크 (output/label) 차이 여부에 따라:

유형	Source 도메인	Source 태스크	Target 도메인	Target 태스크	예
Inductive Transfer	같음/유사	다름	같음	다름 (라벨 있음)	ImageNet 분류 → 의료 영상 분류
Transductive Transfer (Domain Adaptation)	다름	같음	다름	같음	서구인 얼굴 인식 → 아시아인 얼굴 인식
Unsupervised Transfer	다름	다름	다름	다름 (라벨 없음)	클러스터링 지식 전이

딥러닝 시대에는 이 구분이 흐려지고 있으며, 실질적으로는 “대규모 사전 학습 + downstream 파인튜닝” 이라는 한 가지 패러다임이 지배적입니다.

딥러닝 관점: 레이어별 전이 가능성

Yosinski et al. (2014) 는 AlexNet 의 각 레이어를 하나씩 얼려 (freeze) target 태스크에 옮기는 실험으로 다음을 밝혔습니다.

저수준 레이어 (conv1, conv2): 에지, 색깔 필터. 일반적 이라 대부분의 태스크에 잘 전이됩니다.
중간 레이어: 조각, 형태. 부분적 으로 전이됩니다.
고수준 레이어 (fc7, fc8): 클래스 특화. 원본 태스크에 강하게 특화되어 있어 잘 전이되지 않습니다.

이 통찰이 오늘날 대부분의 fine-tuning 전략의 근거입니다.

Fine-tuning 전략

1. Feature Extractor

사전 학습 모델 전체를 freeze, 마지막에 새 head (선형 분류기) 만 학습합니다.

import torch
from torchvision.models import resnet50

model = resnet50(weights='IMAGENET1K_V2')
for p in model.parameters():
    p.requires_grad = False

# 새 head
model.fc = torch.nn.Linear(2048, num_target_classes)
# model.fc.parameters() 만 학습

데이터가 극히 적을 때 유리
학습 빠르고 안정적이지만 성능 상한이 낮음

2. Full Fine-tuning

모든 파라미터를 학습, 다만 작은 learning rate (예: 1e-5) 사용.

for p in model.parameters():
    p.requires_grad = True

optimizer = torch.optim.AdamW(model.parameters(), lr=1e-5)

데이터가 충분할 때 최고 성능
대신 catastrophic forgetting 위험 있음

3. Discriminative Fine-tuning (ULMFiT)

레이어별로 다른 learning rate. 낮은 레이어는 작은 LR, 높은 레이어는 큰 LR.

$$ \eta^{(l-1)} = \eta^{(l)} / 2.6 $$

Howard & Ruder (2018) 이 ULMFiT 에서 제안했고, NLP 파인튜닝의 기준이 되었습니다.

4. Gradual Unfreezing

먼저 head 만 학습 (다른 레이어 freeze), 그 다음 마지막 레이어를 unfreeze, 그 다음 그 아래 레이어를 unfreeze 하는 식으로 레이어별로 서서히 녹입니다. Catastrophic forgetting 완화에 효과적입니다.

Foundation Models

Bommasani et al. (2021) 는 다음 조건을 만족하는 모델을 Foundation Model 로 명명했습니다.

대규모 self-supervised pre-training
광범위한 downstream 태스크에 적응 가능

대표: BERT, GPT, T5, CLIP, ViT, DINO, SAM, LLaMA. Transfer learning 이 이제 특별한 기법이 아니라 AI 시스템 구축의 기본 방식 이 되었다는 관점 전환입니다.

PEFT (Parameter-Efficient Fine-Tuning)

Foundation model 이 수십억 파라미터 규모가 되면서 full fine-tuning 은 GPU 메모리도, 저장 공간도 감당하기 어려워졌습니다. 일부 파라미터만 학습 하는 기법들이 나왔습니다.

Adapter (Houlsby et al., 2019)

Transformer 블록 안에 작은 병목 레이어 를 삽입, 원본 파라미터는 freeze, adapter 만 학습:

x → [Layer Norm] → [Attention] → [Add] → [Adapter (down → nonlinear → up)] → [FFN] → [Add] → [Adapter] → out

전체의 3~5% 정도만 학습해도 full fine-tuning 에 근접한 성능.

LoRA (Hu et al., 2021)

가중치 업데이트 $\Delta W$ 를 low-rank 분해 로 근사:

$$ W’ = W + \Delta W = W + BA, \quad A \in \mathbb{R}^{r \times k}, B \in \mathbb{R}^{d \times r} $$

$r \ll \min(d, k)$ 이면 $BA$ 가 $\Delta W$ 를 근사합니다. 학습 파라미터는 $r(d+k)$ 개로 크게 줄어들고, inference 때는 $W + BA$ 를 병합하면 추가 지연이 없습니다. 오늘날 LLM 파인튜닝의 사실상 표준입니다.

# peft 라이브러리 예
from peft import LoraConfig, get_peft_model

config = LoraConfig(
    r=8,                          # rank
    lora_alpha=32,                # scaling factor
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
)
model = get_peft_model(base_model, config)

QLoRA (Dettmers et al., 2023) 는 4-bit 양자화 + LoRA 로 GPU 메모리를 더 줄였습니다.

Prompt Tuning / Prefix Tuning

모델은 완전 freeze, 입력에 학습 가능한 soft token 벡터 만 추가:

Prompt Tuning (Lester et al., 2021): 입력 앞에 학습 가능한 임베딩 몇 개 추가
Prefix Tuning (Li & Liang, 2021): 각 Transformer 레이어의 key/value 앞에 접두 벡터 삽입

파라미터 수가 극히 작지만 (< 0.1%) 매우 큰 모델에서만 효과적입니다.

BitFit (Ben-Zaken et al., 2021)

bias 파라미터만 학습. 극단적으로 적은 파라미터로도 특정 태스크에서 경쟁력 있음.

Domain Adaptation

Source 와 target 의 입력 분포가 다를 때 사용됩니다.

Feature Alignment

두 도메인의 feature 분포를 정렬:

MMD (Maximum Mean Discrepancy): RKHS 에서 두 분포의 평균 벡터 거리 최소화
CORAL (Correlation Alignment): 공분산 매트릭스 정렬

Adversarial Domain Adaptation (DANN)

Ganin et al. (2015) 의 DANN 은 두 도메인의 feature 를 discriminator 가 구분 못하게 학습시킵니다.

feature extractor → classifier (label 예측, 정상 gradient)
                 → domain discriminator (source vs target, gradient reversal)

Gradient Reversal Layer (GRL) 로 discriminator loss 의 gradient 를 뒤집어 feature 를 domain-invariant 하게 만듭니다.

Self-training / Pseudo-labeling

Target 데이터의 라벨을 모델 예측으로 채우고 (confidence 높은 것만), 다시 학습. 반복.

Catastrophic Forgetting

Fine-tuning 시 사전 학습에서 얻은 일반 지식이 소실 되는 현상. 특히 target 데이터가 적을 때 심각합니다.

완화 기법:

작은 learning rate + 짧은 학습
Elastic Weight Consolidation (EWC) (Kirkpatrick et al., 2017): 원본 파라미터 근처에 머무르도록 L2-regularization, Fisher Information 으로 중요도 가중
Rehearsal: 원본 태스크 샘플을 fine-tuning 중에도 계속 노출
PEFT (adapter, LoRA): 원본 파라미터는 그대로 두므로 자연스럽게 forgetting 방지

Negative Transfer

source 와 target 이 관련 없으면 오히려 성능 하락. 예: 자연 이미지 사전 학습 → 위성 이미지 태스크 는 도움이 되지만, 자연 이미지 사전 학습 → 의료 X-ray 태스크는 부정적 전이 사례가 알려져 있습니다.

방지책:

Source 선택 시 domain similarity 검토 (feature 통계, MMD 로 측정)
모델 여러 개 후보 중 target 검증으로 선택
애매하면 사전 학습 도메인이 넓은 foundation model 사용 (CLIP, DINOv2 등)

실전 예시

NLP: BERT fine-tuning

from transformers import BertForSequenceClassification, Trainer, TrainingArguments

model = BertForSequenceClassification.from_pretrained("bert-base-uncased", num_labels=2)

training_args = TrainingArguments(
    output_dir="./results",
    num_train_epochs=3,
    per_device_train_batch_size=16,
    learning_rate=2e-5,           # BERT paper 권장
    warmup_steps=500,
    weight_decay=0.01,
)

trainer = Trainer(model=model, args=training_args, train_dataset=ds, ...)
trainer.train()

Vision: ViT fine-tuning

from transformers import ViTForImageClassification

model = ViTForImageClassification.from_pretrained(
    "google/vit-base-patch16-224",
    num_labels=num_classes,
    ignore_mismatched_sizes=True,  # 새 head 필요
)

LLM: LoRA fine-tuning

from peft import LoraConfig, get_peft_model, TaskType

config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=16,
    lora_alpha=32,
    lora_dropout=0.1,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
)

model = get_peft_model(base_llm, config)
model.print_trainable_parameters()
# trainable: ~4M / total: ~7B (0.06%)

참고

관련 지표: [[classification-metrics|분류 모델 지표]]
관련 시스템: [[federated-learning|Federated Learning]] 에서도 pretrained model 을 초기점으로 씁니다
관련 평가: [[helm-llm-benchmark|HELM]] 은 여러 downstream 태스크에서 foundation model 을 평가합니다
HuggingFace: PEFT library
Paper: Bommasani et al. 2021, Foundation Models
Survey: A Comprehensive Survey on Transfer Learning (Zhuang et al., 2020)

분류 모델 지표: Confusion Matrix, Precision, Recall, F1

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

분류 (classification) 모델의 성능을 정량화하는 지표들입니다. 이진 분류를 기준으로 하며, multi-class 로 확장하는 방법도 함께 다룹니다. 핵심 출발점은 Confusion Matrix 이고, 여기서 accuracy, precision, recall, F1, ROC/PR 등 모든 지표가 유도됩니다.

Confusion Matrix

이진 분류의 예측 결과를 2x2 표로 정리한 것입니다. 스팸 필터를 예로 들면:

	예측: Positive (스팸)	예측: Negative (정상)
실제: Positive (스팸)	TP (True Positive)	FN (False Negative)
실제: Negative (정상)	FP (False Positive)	TN (True Negative)

TP (True Positive): 스팸을 스팸이라고 맞춘 경우
TN (True Negative): 정상을 정상이라고 맞춘 경우
FP (False Positive): 정상을 스팸이라고 잘못 예측 (Type I error)
FN (False Negative): 스팸을 정상이라고 놓친 경우 (Type II error)

[!TIP] First letter (T/F) 은 예측이 맞았는가 (True/False), second letter (P/N) 은 모델이 무엇으로 예측했는가 (Positive/Negative) 입니다. “FP = 모델은 Positive 라고 예측, 실제는 반대라 False” 로 읽으면 헷갈리지 않습니다.

기본 지표

Accuracy

$$ \text{Accuracy} = \frac{TP + TN}{TP + TN + FP + FN} $$

전체 예측 중 맞은 비율. 직관적이지만 class imbalance 에 취약합니다. 99% 정상 메일 데이터에서 “모두 정상” 이라고 예측해도 accuracy 99% 가 나옵니다.

Precision (정밀도)

$$ \text{Precision} = \frac{TP}{TP + FP} $$

모델이 Positive 라고 예측한 것 중 실제로 Positive 인 비율. “모델이 Positive 라고 외칠 때 얼마나 믿을 만한가?”

스팸 필터: precision 낮으면 정상 메일이 스팸함으로 감 → 사용자 불만
추천 시스템: precision 낮으면 관심 없는 상품 추천 → 이탈

Recall (재현율, Sensitivity, TPR)

$$ \text{Recall} = \frac{TP}{TP + FN} $$

실제 Positive 중 모델이 맞춘 비율. “진짜 Positive 를 얼마나 놓치지 않고 잡았는가?”

암 진단: recall 낮으면 환자를 놓침 → 치명적
이상 거래 탐지: recall 낮으면 사기를 놓침 → 손실

Specificity (TNR)

$$ \text{Specificity} = \frac{TN}{TN + FP} $$

실제 Negative 중 Negative 로 맞춘 비율. 의료 통계에서 자주 쓰이며 ROC 곡선의 x 축을 구성합니다.

Precision vs Recall 트레이드오프

두 지표는 대체로 상충됩니다. 이유는 대부분의 확률 모델이 임계값 (threshold) 에 따라 결정을 내리기 때문입니다. Threshold 를 낮추면 (더 많이 Positive 로 예측):

Recall ↑ (놓치는 것 감소)
Precision ↓ (틀린 Positive 증가)

반대로 threshold 를 높이면:

Precision ↑ (확신 있을 때만 Positive)
Recall ↓ (놓치는 것 증가)

어느 쪽을 우선할지는 도메인 비용 함수 에 따라 다릅니다.

상황	우선 지표	이유
스팸 필터	Precision	정상 메일 놓치는 비용 큼
추천 시스템	Precision	관심 없는 추천은 사용자 피로
암 진단 스크리닝	Recall	놓치는 비용 (사망) 극심
사기 탐지	Recall	놓친 사기의 손실 큼
검색 랭킹	Precision@K	상위 K 개만 노출됨

F1 Score

Precision 과 Recall 의 조화 평균 (harmonic mean):

$$ F_1 = 2 \cdot \frac{\text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}} $$

산술 평균 대신 조화 평균을 쓰는 이유는 한쪽이 극단적으로 낮을 때 벌점을 주기 위함 입니다. Precision=1.0, Recall=0.01 이면 산술 평균은 0.505 지만 F1 은 0.0198 로 곤두박질칩니다.

F-beta

Precision 과 Recall 을 다른 비중으로 가중:

$$ F_\beta = (1 + \beta^2) \cdot \frac{P \cdot R}{\beta^2 \cdot P + R} $$

$\beta = 1$ → F1 (동일 가중)
$\beta = 2$ → F2 (recall 을 2 배 중시)
$\beta = 0.5$ → F0.5 (precision 을 2 배 중시)

$\beta$ 는 “recall 을 precision 대비 몇 배로 중요하게 보는가” 의 계수입니다.

ROC 곡선과 AUC

ROC (Receiver Operating Characteristic) 곡선: 다양한 threshold 에서 (FPR, TPR) 을 그린 곡선.

x축: FPR (False Positive Rate) = FP / (FP + TN) = 1 - Specificity
y축: TPR (True Positive Rate) = Recall

AUC-ROC 는 이 곡선 아래 면적입니다. 0.5 는 random, 1.0 은 완벽. 직관적 해석: 랜덤한 positive 샘플과 negative 샘플을 뽑았을 때, positive 샘플의 점수가 더 높을 확률.

ROC 의 한계, 극심한 imbalance

Negative 가 압도적으로 많을 때 (예: 사기 거래 1% vs 정상 99%), FPR 이 0.01 만 되어도 절대 개수로는 엄청난 오탐입니다. 그러나 ROC 곡선은 FPR 을 %로 표현하므로 오탐의 심각성이 시각적으로 감춰집니다.

PR 곡선과 AUC-PR

Precision-Recall 곡선: threshold 별 (Recall, Precision) 을 그린 곡선.

AUC-PR 은 그 아래 면적이며, imbalanced dataset 에서 ROC 보다 정보량이 많습니다 (Saito & Rehmsmeier, 2015).

경험칙:

양쪽 클래스가 비슷하게 있음 → ROC/AUC 로 충분
Positive 가 희소함 (예: <10%) → PR 곡선 / AUC-PR 을 우선

Multi-class 확장

이진의 precision/recall/F1 을 여러 클래스로 확장할 때 세 가지 평균 방식이 있습니다.

Macro-average

각 클래스별 지표를 구한 뒤 단순 평균:

$$ \text{Macro-F1} = \frac{1}{K} \sum_{k=1}^{K} F_1^{(k)} $$

각 클래스를 동등하게 취급
소수 클래스도 존중 하고 싶을 때 적합

Micro-average

모든 클래스의 TP/FP/FN 을 먼저 합산하고 지표 계산:

$$ \text{Micro-F1} = 2 \cdot \frac{\sum TP}{\sum TP + \sum FP + \sum FN} $$

전체 샘플을 동등하게 취급 (샘플 많은 클래스가 지배)
Micro-F1 은 multi-class accuracy 와 같아집니다

Weighted-average

각 클래스의 support (샘플 수) 로 가중 평균:

$$ \text{Weighted-F1} = \sum_{k=1}^{K} \frac{n_k}{n} F_1^{(k)} $$

실제 분포를 반영
다수 클래스가 편중된 경우 macro 대신 자주 쓰임

기타 지표

Cohen’s Kappa

우연히 맞을 확률을 보정한 accuracy:

$$ \kappa = \frac{p_o - p_e}{1 - p_e} $$

$p_o$ 는 실제 관측 accuracy, $p_e$ 는 우연히 일치할 기대 확률. 클래스가 매우 불균형할 때 raw accuracy 보다 신뢰할 만합니다.

Matthews Correlation Coefficient (MCC)

$$ \text{MCC} = \frac{TP \cdot TN - FP \cdot FN}{\sqrt{(TP+FP)(TP+FN)(TN+FP)(TN+FN)}} $$

-1 (완전 반대) ~ 0 (random) ~ 1 (완벽). Confusion Matrix 네 셀 모두를 반영하며, Chicco & Jurman 2020 은 이진 분류에서 F1/accuracy 보다 MCC 를 권장합니다.

Log Loss / Cross-Entropy

확률 출력에 대한 지표:

$$ \text{LogLoss} = -\frac{1}{N} \sum_{i=1}^{N} \left[ y_i \log \hat{p}_i + (1-y_i) \log (1-\hat{p}_i) \right] $$

예측 확률이 실제 클래스에서 얼마나 벗어났는지 측정
Calibration (예측 확률이 실제 빈도와 일치하는가) 를 평가할 때 함께 사용

scikit-learn 실전 코드

from sklearn.metrics import (
    confusion_matrix,
    classification_report,
    roc_auc_score,
    precision_recall_curve,
    matthews_corrcoef,
)

# Confusion matrix
cm = confusion_matrix(y_true, y_pred)

# 종합 리포트 (precision, recall, F1, support 를 각 클래스별로)
print(classification_report(y_true, y_pred, digits=4))

# 확률 기반 지표 (y_proba 는 positive class 확률)
auc_roc = roc_auc_score(y_true, y_proba)
precision, recall, thresholds = precision_recall_curve(y_true, y_proba)

# MCC
mcc = matthews_corrcoef(y_true, y_pred)

threshold 튜닝

기본 threshold 0.5 를 그대로 쓰면 안 됩니다. 도메인 비용에 맞춰 조정:

from sklearn.metrics import f1_score
import numpy as np

thresholds = np.linspace(0, 1, 101)
f1s = [f1_score(y_true, y_proba > t) for t in thresholds]
best_t = thresholds[np.argmax(f1s)]

또는 precision 을 최소 몇% 이상 유지하는 조건 아래에서 recall 을 최대화하는 식으로 제약 최적화합니다.

참고

[[federated-learning|Federated Learning]] 에서도 동일 지표를 클라이언트별로 계산합니다.
[[transfer-learning|Transfer Learning]] downstream 평가에 대부분 이 지표들을 씁니다.
[[sagemaker-model-monitor|SageMaker Model Monitor]] 의 Model Quality Monitor 가 이 지표들을 모니터링합니다.
[[helm-llm-benchmark|HELM]] 의 accuracy 축은 여기서 확장된 형태입니다.
Wikipedia: Precision and recall, Receiver operating characteristic

모델 양자화

koa (김신건) — Sun, 14 Jun 2026 00:00:00 GMT

정의

양자화 (Quantization) 는 신경망 모델의 가중치/활성화를 높은 정밀도 (FP32, FP16) 에서 낮은 정밀도 (INT8, INT4 등) 로 변환하여 메모리와 연산량을 줄이는 기법.

{}

원래 신호 처리 용어. 연속적인 신호 (continuous signal) 를 이산적인 (discrete) 양자 (quantum) 레벨로 변환한다는 뜻에서 “양자(量子)화”라 부른다. 실수 값을 정수 격자에 맞춰 떨어뜨리는 과정.

FP32 가중치: 0.327891, -1.42876, 0.00123, ...
                ↓ 양자화 (4-bit, 16 levels)
INT4 가중치: 3, -6, 0, ...  (scale 곱해서 복원)

왜 “양자” 인가

물리학의 양자(quantum) 개념에서 유래. 연속체를 이산적인 단위로 쪼개는 것.

FP32: 약 2^32 가지 값 표현 가능 (사실상 연속)
INT8: 256 가지 값만 (이산)
INT4: 16 가지 값만 (매우 이산)

비유: 아날로그 회전 다이얼 vs 디지털 16 단계 클릭. 16 단계로 “양자화” 된다.

왜 필요한가

LLM (Large Language Model) 은 메모리와 메모리 대역폭이 가장 큰 병목.

모델	FP16	INT8	INT4
Llama 2 7B	13 GB	7 GB	4 GB
Llama 2 70B	140 GB	70 GB	40 GB
GPT-3 175B	350 GB	175 GB	90 GB

INT4 로 양자화하면:

메모리 4~8 배 절약
메모리 대역폭 4~8 배 절약 (가장 중요, 추론 속도 결정)
연산 2~4 배 빠름 (INT 연산이 FP 보다 회로가 작음)

24 GB RTX 4090 한 장에 70B 모델 INT4 로 돌릴 수 있게 됨.

양자화의 수학

스칼라 양자화의 기본 공식:

quantize(x) = round(x / scale) + zero_point
dequantize(q) = (q - zero_point) * scale

여기서
  scale = (x_max - x_min) / (q_max - q_min)
  zero_point = q_min - round(x_min / scale)

예) FP32 가중치 범위 [-2.5, 3.0] 을 INT8 ([-128, 127]) 로:

scale = 5.5 / 255 ≈ 0.0216
zero_point = -128 - round(-2.5 / 0.0216) ≈ -12
0.327 → round(0.327/0.0216) + (-12) = 15 - 12 = 3
복원: 3 * 0.0216 - (-12 * 0.0216) ≈ 0.324 (오차 0.003)

이 오차가 누적되면 모델 품질이 떨어진다. 어떻게 오차를 최소화할지가 양자화 기법의 핵심 차이.

양자화 방법론

1. Post-Training Quantization (PTQ)

이미 학습된 모델을 그대로 양자화. 재학습 필요 없음.

# PyTorch 의사 코드
model_fp32 = load_model()
calibration_data = small_dataset_sample()
model_int8 = quantize_ptq(model_fp32, calibration_data)

장점: 빠름 (수십 분), 학습 데이터 불필요
단점: 정확도 손실 가능

가장 실용적, 가장 널리 사용.

2. Quantization-Aware Training (QAT)

학습 중에 양자화 효과를 시뮬레이션. 모델이 양자화 오차에 적응.

# fake quantize 삽입
y = forward_pass(x)
y_quantized = fake_quantize(y)  # 양자화 + 즉시 역양자화
# backward 에서는 Straight-Through Estimator (STE) 로 gradient 통과

장점: 가장 정확도 좋음
단점: 재학습 비용 (full training 의 5~30%)

극한 압축 (4-bit 미만) 시 필수.

3. GPTQ (Generative Pre-trained Transformer Quantization)

2022년 발표 (arXiv:2210.17323). LLM 특화 PTQ.

동기

기본적인 RTN (Round-To-Nearest) 양자화는 단순하지만 오차가 크다. 한 가중치를 양자화하면 발생한 오차가 이후 출력에 그대로 전파됨. GPTQ 는 이미 양자화한 가중치의 오차를, 아직 양자화 안 한 가중치들로 보정한다.

핵심 알고리즘 (OBQ 기반)

OBQ (Optimal Brain Quantization) 의 LLM-scale 확장. 가중치 행렬 W 한 행씩 처리:

1. 입력 데이터로 Hessian 행렬 H = 2·X·X^T 계산
2. 각 column (가중치) 을 순서대로 양자화:
   a. quant(w_j) 로 양자화
   b. 양자화 오차 e_j = (w_j - quant(w_j)) / [H^-1]_jj
   c. 아직 양자화 안 한 가중치들을 e_j · H^-1_j,k 만큼 조정 (오차 보정)
3. 모든 column 끝나면 다음 행으로

핵심 통찰: Hessian 의 역행렬 정보 (H^-1) 가 각 가중치를 얼마나 흔들어야 출력 오차가 최소화되는지 알려준다.

Cholesky 분해 최적화

원래 OBQ 는 매 column 마다 Hessian 역행렬 갱신이 필요해 매우 느렸다 (175B 모델에 수개월). GPTQ 는 Cholesky 분해로 미리 H^-1 의 윗삼각 형태를 한 번에 계산하고, blockwise update 로 메모리/시간 최적화. 175B 모델을 4시간 으로 단축.

옵션: act-order

활성화 크기가 큰 column 순으로 양자화하면 7B 모델에서 PPL 7.15 → 6.09 로 개선. 큰 활성화 → 작은 오차 우선 보정 → 후속 column 영향 최소화.

장점: INT4 에서도 정확도 손실 매우 작음
단점: 처리 시간 (1~4시간), 보정용 데이터 128+ 샘플 필요
품질: LLaMA-7B 기준 FP16 PPL 5.68 vs GPTQ-INT4 6.09 (0.4 차이)

4. AWQ (Activation-aware Weight Quantization)

2023년 발표 (arXiv:2306.00978). GPTQ 와 같은 목표지만 완전히 다른 접근.

동기

GPTQ 의 Hessian 기반 보정은 수학적으로 우아하지만 비싸다. AWQ 의 관찰: 출력 오차의 대부분은 “outlier channels” 가 만든다. 일부 채널의 활성화 크기가 매우 크고, 이 채널의 가중치 양자화 오차가 출력 전체를 망친다.

핵심 아이디어, Activation-aware Scaling

수학적 항등식 활용:

Y = (W · diag(s)^-1) · (diag(s) · X)
  = W_scaled · X_scaled

여기서 s = per-channel scaling factor

W_scaled 에서 salient channels 의 가중치는 s^-1 배 작아짐 → INT4 격자에서 더 정밀하게 표현
X_scaled 에서 같은 채널의 활성화는 s 배 커짐 → 출력 동일

알고리즘

1. 캘리브레이션 데이터로 각 채널의 평균 활성화 크기 |X|_c 계산
2. s_c = |X|_c^α 형태로 parametrize (α 는 grid search 변수)
3. α 를 20개 정도 grid 에서 탐색:
   for α in [0, 0.05, 0.1, ..., 1.0]:
     계산 layer 출력 오차
4. 가장 작은 오차의 α 채택, W_scaled 를 단순 INT4 RTN 으로 양자화

비교

	GPTQ	AWQ
접근	Hessian-weighted 가중치 보정	Pre-quantization 채널 스케일링
계산	Cholesky 분해 + sequential update	Grid search (20 forward pass/layer)
시간	1~4 시간	10분~~30분 (5~~10배 빠름)
품질	LLaMA-7B INT4: PPL 6.09	LLaMA-7B INT4: PPL 6.08 (거의 동일)

GPTQ vs AWQ: GPTQ 는 “weight 별로 더 열심히 보정”, AWQ 는 “문제를 회전시켜서 weight 별 보정이 쉬워지게”. 실용적으로는 AWQ 가 더 인기.

5. GGUF / GGML (llama.cpp)

CPU + Apple Silicon 친화 양자화 포맷. 여러 비트수 동시 지원.

포맷	bit	7B 메모리	품질
Q2_K	2.6	2.8 GB	극한 압축 (품질 손실 큼)
Q4_K_M	4.1	4.1 GB	권장, FP16 대비 96~98%
Q5_K_M	5.1	4.8 GB	고품질
Q8_0	8.0	7.2 GB	FP16 거의 무손실

K_M = Mixed precision (중요 레이어는 더 높은 비트). 로컬 LLM 실행의 사실상 표준.

6. QLoRA (NF4)

2023년 5월 발표 (arXiv:2305.14314). Tim Dettmers 외. 24 GB GPU 1대로 65B 모델 fine-tuning 을 가능하게 만든 기법. 단순한 양자화를 넘어 3가지 혁신을 조합.

1. NF4 (4-bit NormalFloat)

가장 중요한 혁신. 신경망 가중치는 보통 정규분포 N(0, σ²) 를 따른다 는 관찰에서 시작.

기존 INT4 / FP4 는 균등 간격으로 16개 값을 잡지만, 정규분포 데이터에서는 0 근처에 값이 몰려 있다. 균등 간격은 비효율.

NF4 는 각 양자화 구간이 표준정규분포 N(0, 1) 아래 같은 면적 을 가지도록 16개 값을 설계.

표준정규분포 N(0, 1) 를 16등분 (각 구간 확률 1/16):
  q_i = quantile((i + 0.5) / 16)  for i = 0..15

결과 NF4 값들 (대략):
  -1.0,  -0.69, -0.52, -0.40, -0.30, -0.21, -0.13, -0.06,
   0.06,  0.16,  0.25,  0.34,  0.44,  0.56,  0.72,  1.0

0 근처에 값이 빽빽하고 양 끝에 듬성. 정규분포 데이터에 최적.

정보이론 관점: NF4 는 “정규분포 데이터를 4-bit 로 표현하는 information-theoretically optimal” 양자화. 균등 INT4 대비 같은 비트로 더 적은 정보 손실.

2. Double Quantization

블록 양자화 (blocksize 64) 에서는 각 블록마다 scale (FP32, 4 bytes) 이 필요. 큰 모델에선 이 scale 자체가 메모리를 차지.

65B 모델, blocksize 64:
  parameter 수: 65 × 10^9
  block 수: ~10^9
  block 당 FP32 scale: 4 bytes
  scale 총량: 4 GB (! 가중치 압축한 의미가 무색)

Double Quantization: scale 자체를 다시 양자화.

원본:     W (FP16) → blockwise quant → W_NF4 + c_1 (FP32 per 64 weights)
Double:   W (FP16) → quant 1 → W_NF4 + c_1_quantized + c_2 (FP32 per 256 c_1)

c_1 은 8-bit 로 양자화 (c_2 가 c_1 의 scale)

평균 0.37 bits/parameter 절약 (65B 모델에서 ~3 GB).

3. Paged Optimizer

QLoRA 의 또 다른 혁신. LoRA adapter 의 optimizer state (Adam 의 momentum + variance, FP32) 가 메모리 spike 의 원인.

긴 시퀀스 처리 중 일시적으로 메모리가 부족해지면 OOM. Paged Optimizer 는 NVIDIA Unified Memory 를 활용해 optimizer state 를 자동으로 GPU ↔ CPU RAM 사이에 페이지 단위로 교환. OS 의 가상 메모리 paging 과 동일 개념.

전체 QLoRA 수식

Y_BF16 = X_BF16 · doubleDequant(c_1, c_2, W_NF4) + X_BF16 · L_1 · L_2

  W_NF4: 4-bit 양자화된 frozen base model 가중치
  c_1, c_2: double quantized scales
  L_1, L_2: LoRA adapters (low-rank decomposition, trainable, BF16)

doubleDequant 가 NF4 → BF16 복원, 그 후 일반 LoRA forward.

결과

LLaMA 65B 를 단일 48 GB A6000 1장으로 fine-tuning
Guanaco 모델 (QLoRA 로 fine-tuned LLaMA 65B) 가 ChatGPT-3.5 와 비교 가능한 품질 달성
HuggingFace bitsandbytes 라이브러리로 한 줄 적용 가능

bitsandbytes 사용 예

from transformers import AutoModelForCausalLM, BitsAndBytesConfig
import torch

quant_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type='nf4',          # NF4 사용
    bnb_4bit_use_double_quant=True,     # Double Quantization
    bnb_4bit_compute_dtype=torch.bfloat16,
)

model = AutoModelForCausalLM.from_pretrained(
    'meta-llama/Llama-2-70b-hf',
    quantization_config=quant_config,
)
# 이제 LoRA 추가 후 학습

7. FP8, FP4 (Hardware native)

NVIDIA H100 부터 FP8 (e4m3, e5m2) 하드웨어 지원. B200 부터 FP4 추가.

FP8: 학습 + 추론. INT8 대비 동적 범위 넓음
FP4: 4-bit 부동소수, INT4 대비 정확도 우위

INT4 같은 정수 양자화는 별도 calibration 이 필요하지만, FP8/FP4 는 하드웨어가 직접 처리.

정확도 vs 압축 트레이드오프

포맷	압축률	품질 (FP16 대비)
FP16 / bf16	1x	기준
FP8 (H100)	2x	~99.7%
INT8	4x	~99%
FP4 (B200)	4x	~99.0%
AWQ 4-bit	4x	9899%
GPTQ 4-bit	4x	9799%
Q4_K_M GGUF	4x	9698%
NF4 (QLoRA)	4x	9597%
단순 INT4	4x	8593%
INT2	16x	큰 손실

시나리오별 권장

환경	권장
NVIDIA H100/H200/B200	FP8 (vLLM, TensorRT-LLM)
NVIDIA B100/B200 frontier	FP4
NVIDIA A100/4090	AWQ 4-bit
Apple Silicon (Mac)	MLX 4-bit 또는 GGUF Q4_K_M
CPU 전용	GGUF Q4_K_M (llama.cpp)
Fine-tuning, 메모리 제약	QLoRA NF4

CS 에 미친 영향

양자화는 단순한 최적화 기법을 넘어 모델 배포의 전체 패러다임을 바꿨다.

로컬 LLM: ChatGPT 급 모델을 노트북에서 실행 (llama.cpp + GGUF Q4)
edge AI: 스마트폰 [[NPU]] 가 INT4 회로로 LLM 추론
GPU 비용: 같은 모델을 1/4 메모리로 → 클라우드 비용 4 배 절감
연구 방향: “더 큰 모델” 만큼 “더 효율적인 양자화” 가 활발한 연구 분야

김신건의 로그 - 위키 / ml

분산 학습

정의

문제 상황과 동기

핵심 4가지 병렬화 전략

1. Data Parallelism (DP), 가장 단순

2. Tensor Parallelism (TP), 한 layer 를 쪼개기

3. Pipeline Parallelism (PP), layer 를 분할

4. ZeRO / FSDP, 메모리 sharding

5. Context Parallelism (CP), 시퀀스 차원 분할

6. Expert Parallelism (EP), MoE 모델

조합: 3D / 4D / 5D Parallelism

동기화 패턴 (Collective Communication)

프레임워크

어디서 사용?

함정

1. TP degree 와 NVLink

2. Pipeline bubble

3. ZeRO-3 와 메모리 재집합 비용

4. 체크포인트 복잡도

CS 에 미친 영향

관련 위키

HBM

정의

GDDR 대비 차이

구조

Base Die (Logic Die)

Through-Silicon Via (TSV)

Silicon Interposer

Channel 과 Bank 구조

동작 원리

세대별 대역폭

왜 AI 에 필수인가

Roofline Model: 산술 강도

실제 수치

Flash Attention 과 HBM

비용 구조

CPU vs GPU 메모리 격차

용량 vs 대역폭 trade-off

함정

관련 위키

SIMT

정의

언제 쓰이나

SIMD 와의 차이

Thread 계층: Thread / Block / Grid

SM (Streaming Multiprocessor) 아키텍처

Warp

Occupancy

Warp Divergence

Divergence 최소화 패턴

메모리 접근 패턴

Shared Memory (SRAM) 활용

NVIDIA vs AMD

관련 모델: SPMD

흔한 함정

관련 위키

SPMD

정의

동작 방식

다른 병렬 모델과의 차이

SPMD 의 매력

1. 프로그래밍 단순함

2. 확장 용이

3. 동기화가 명시적

실제 예시

MPI (Message Passing Interface)

CUDA (GPU)

PyTorch DDP / FSDP

JAX pmap

JAX shard_map / jit + sharding (최신)

Collective 통신 종류

SPMD 의 한계

1. Heterogeneous 워크로드 어려움

2. Load imbalance

3. 통신 비용

SPMD 와 Data Parallelism 관계

함정

관련 위키

GPU: 그래픽/ML 병렬 프로세서

JAX `pmap`

JAX `shard_map` / `jit` + sharding (최신)