김신건의 로그 - 위키 / ml

[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

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

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

정의

GPU (Graphics Processing Unit) 는 원래 그래픽 렌더링용이었지만, massively parallel 아키텍처가 딥러닝과 HPC 에도 이상적. NVIDIA, AMD, Intel 이 3 대 제조사.

아키텍처 개요

Streaming Multiprocessor (SM)

NVIDIA GPU 의 병렬 유닛. 각 SM 은 수십~수백 개 CUDA 코어 + 공유 메모리 + register file.

H100 (Hopper): 132 개 SM × 128 FP32 코어 = 16896 CUDA cores.

SIMT (Single Instruction Multiple Thread)

Warp (32 스레드) 단위로 같은 명령 실행. Warp 내부는 SIMD 유사, warp 간은 독립.

메모리 계층

층	크기	지연	대역폭
Register	스레드별	~1 cycle	최고
Shared memory	SM 당 ~100KB	~1 cycle	매우 높음
L1 cache	SM 당	~10 cycles	높음
L2 cache	GPU 전체	~200 cycles	중간
Global memory (HBM)	40-80 GB	~500 cycles	~3 TB/s (H100)

딥러닝 특화

Tensor Core

행렬곱 전용 유닛. FP16/BF16/FP8 지원. Ampere+ 는 sparse tensor 지원.

정밀도

FP32 → FP16/BF16 → FP8 → INT8/INT4. 낮은 정밀도 = 큰 처리량 + 낮은 메모리. 혼합 정밀도 학습 (mixed precision) 이 표준.

세대

년도	NVIDIA	AMD
2020	A100 (Ampere)	MI100
2022	H100 (Hopper)	MI250
2024	B200 (Blackwell)	MI300X

소프트웨어 스택

CUDA: NVIDIA 독점 API
PyTorch, TensorFlow, JAX: CUDA/ROCm/XLA 기반
Triton (OpenAI): Python 에서 CUDA 커널 작성
cuDNN, cuBLAS: NVIDIA 최적화 라이브러리
ROCm: AMD 대응 스택

참고

[[tpu|TPU]]
[[npu|NPU]]
[[hbm|HBM]]
[[simt|SIMT]]

NPU (Neural Processing Unit): 엣지 AI 칩

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

정의

NPU (Neural Processing Unit) 는 모바일/엣지 디바이스용 저전력 AI 가속기. 스마트폰, 노트북, IoT 에 내장.

특징

저전력: 배터리 구동 (수 W ~ 수십 W)
정수 연산 위주: INT8, INT4 로 추론 최적화
온디바이스 추론: 개인정보 보호, 지연시간 낮음

대표 NPU

스마트폰

Apple Neural Engine (ANE): A11 (2017) 부터, M-series 도 내장. 15.8 TOPS (A16).
Qualcomm Hexagon: Snapdragon 내장
Google Tensor: Pixel 시리즈, TPU 아키텍처 계승

PC

Intel NPU (Meteor Lake+, 2024): 저전력 AI 워크로드 처리
AMD XDNA: Ryzen AI 라인
Apple Silicon: M-series 내장 ANE

자율주행 / 로봇

NVIDIA Jetson: 엣지 서버급
Google Coral (Edge TPU): USB / M.2 형태

GPU 와의 차이

항목	GPU	NPU
유연성	학습 + 추론	추론 위주
정밀도	FP16/32 학습	INT4/8 추론
전력	100-700W	1-20W
지연시간	배치 대기	즉각 처리

사용

얼굴 인식 (Face ID)
사진 처리 (Portrait mode, Deep Fusion)
음성 인식 (Siri, Google Assistant 온디바이스)
실시간 번역
LLM 온디바이스 (Apple Intelligence, Copilot+)

참고

[[tpu|TPU]]
[[gpu|GPU]]
[[quantization|Quantization]]
[[federated-learning|Federated Learning]]

TPU (Tensor Processing Unit): Google 의 ML ASIC

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

정의

TPU (Tensor Processing Unit) 는 Google 이 딥러닝 워크로드용으로 만든 ASIC (application-specific IC). 2015 년 v1 (추론용), 2017 년 v2 (학습 지원) 발표.

핵심 아키텍처

Systolic Array

[[systolic-array|Systolic Array]] 를 이용한 대규모 병렬 행렬곱. TPU v4 는 128×128 행렬곱 유닛.

데이터가 배열을 통과하며 곱셈-누산
캐시/DRAM 접근 최소화 → 에너지 효율 극대화

bfloat16

FP32 exponent + FP16 mantissa. 학습 안정성 유지하며 대역폭 절반.

세대

세대	년도	특징
v1	2015	추론 전용, INT8
v2	2017	학습 지원, HBM
v3	2018	액체 냉각
v4	2021	4096 chip pod, OCS 상호연결
v5e / v5p	2023	비용/성능 두 트랙
Trillium (v6)	2024	5x 컴퓨트 vs v5e

TPU Pod

여러 TPU 를 고속 인터커넥트로 묶은 단위. v4 는 최대 4096 칩 pod, exaflops 급 컴퓨트.

사용

Google Cloud TPU: gcloud compute tpus
JAX + XLA: 표준 스택
TensorFlow / PyTorch/XLA: 지원

GPU 와 비교

항목	GPU	TPU
유연성	높음 (그래픽, HPC, ML)	ML 특화
소프트웨어	CUDA 광범위	XLA 중심
병렬 방식	SIMT	Systolic array
지연시간	낮음	배치 대기
접근성	광범위 (AWS, on-prem)	GCP 만

참고

[[gpu|GPU]]
[[npu|NPU]]
[[systolic-array|Systolic Array]]
[[distributed-training|Distributed Training]]

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

SPMD

koa (김신건) — Sun, 14 Jun 2026 00:00:00 GMT

정의

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

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

동작 방식

# 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 가 실행
dist.init_process_group()
model = DDP(model)
for batch in dataloader:  # rank 마다 다른 배치
    loss = model(batch)
    loss.backward()
    # DDP 가 자동으로 all-reduce
    optimizer.step()

JAX `pmap`

함수형 SPMD.

@jax.pmap
def step(params, batch):
    return params - learning_rate * grad(loss)(params, batch)

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

SPMD 의 한계

1. Heterogeneous 워크로드 어려움

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

2. Load imbalance

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

3. 통신 비용

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

모델 양자화

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 배 절감
연구 방향: “더 큰 모델” 만큼 “더 효율적인 양자화” 가 활발한 연구 분야

분산 학습

koa (김신건) — Sun, 14 Jun 2026 00:00:00 GMT

정의

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

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

{}

핵심 4가지 병렬화 전략

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

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

CS 에 미친 영향

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

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

HBM

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

정의

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

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

{}

구조

                     [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 에 필수인가

LLM 추론을 예로 들면:

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 최적화
HBM4, HBM5 로의 지속 진화

비용 구조

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 의 대역폭.

SIMT

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

정의

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

{}

SIMD 와의 차이

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

	SIMD	SIMT
데이터 그룹	벡터 레지스터 (예: AVX-512 = 16 floats)	thread (수 십개)
분기 처리	어렵음 (masked operation)	자동 (warp divergence)
프로그래밍 모델	명시적 SIMD intrinsic	평범한 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 명령 실행

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) 접근 가능

NVIDIA H100 = 132 SM × 64 warp × 32 thread = 약 27만 thread 동시 처리 가능 (실제 활성 thread 수는 워크로드에 따라 다름).

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) 보다 a + (b - a) * (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]

Systolic Array

koa (김신건) — Sat, 13 Jun 2026 00:00:00 GMT

정의

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

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

{}

핵심 아이디어

행렬 곱셈 C = A × B 를 수행할 때:

가중치 정주(Weight Stationary): 가중치는 각 PE 에 미리 적재되어 움직이지 않음
활성화 흐름(Activation Flow): 입력 활성화는 격자를 가로질러 흐름 (좌→우)
부분합 누적: 각 PE 가 받은 입력 × 가중치 결과를 다음 PE 로 전달, 마지막 PE 가 누적합 출력

이 구조의 우아함:

메모리 접근 최소화: 각 가중치는 PE 에 1번 적재 → 수많은 곱셈에 재사용
완벽한 데이터 재사용: 한 활성화 값이 여러 PE 를 지나며 여러 곱셈에 참여
간단한 제어: 모든 PE 가 같은 동작 (clock 동기) → 제어 회로 거의 없음

CPU/GPU 와의 차이

	CPU	GPU	Systolic Array (TPU)
제어 회로 비중	매우 높음	중간	매우 낮음
메모리 접근	빈번 (캐시 의존)	빈번 (HBM)	최소 (정주)
행렬 곱 효율	낮음	높음	최고
다양한 워크로드	모두	대부분	행렬 위주만

한계

유연성 부족: 행렬 곱셈에 최적화. element-wise 연산, 비선형 함수 등은 별도 vector unit 으로 처리
fixed shape: MXU 크기 (예: 256x256) 보다 작은 행렬을 곱하면 활용률이 낮아짐. 모델을 큰 행렬로 합치는 패딩/타일링 필요
희소(sparse) 비효율: 대부분의 element 가 0인 sparse matrix 에서는 비효율. TPU v4+ 에서 SparseCore 별도 추가

김신건의 로그 - 위키 / ml

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

정의

4 가지 모니터 타입

1. Data Quality Monitor

2. Model Quality Monitor

3. Bias Drift Monitor

4. Feature Attribution Drift Monitor

아키텍처

단계별 컴포넌트

Python SDK 클래스

실전 코드 (Data Quality)

1. Endpoint 에 Data Capture 활성화

2. Baseline 생성

3. Monitoring Schedule 등록

4. CloudWatch 알람 연결

Model Quality 의 ground truth 연결

Baseline 파일 형식

statistics.json (예)

constraints.json (예)

지원 데이터 타입 제한

다른 도구와 비교

비용

Best Practice

Model Drift 개념 정리

대안 (2026 신규 종료 이후)

참고

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

정의

왜 등장했는가

형식 정의

인접 데이터셋 (Adjacent Datasets)

ε-Differential Privacy (pure DP)

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

왜 이 정의인가

핵심 개념: Sensitivity

핵심 메커니즘

Laplace Mechanism

Gaussian Mechanism

Exponential Mechanism

Composition

Basic Composition

Advanced Composition (Dwork et al., 2010)

Rényi DP 를 통한 tighter composition

Privacy Budget

Central DP vs Local DP

Central DP (Trusted Curator)

Local DP (LDP)

RAPPOR (Google, 2014)

비교

DP-SGD, 딥러닝 학습의 DP

Opacus (PyTorch)

DP-SGD 의 utility 손실

실배포 사례

Apple (2016~)

Google

US Census (2020)

Microsoft

학술 데이터셋

프레임워크

한계와 유의점

Utility-Privacy Trade-off

ε 해석의 어려움

데이터 카탈로그 문제

결측치와 outlier

Group Privacy 는 다름

정확한 구현이 어려움

관련 개념 비교

참고

Federated Learning: 분산 학습 without central data

정의

왜 필요한가

FedAvg, 기본 알고리즘

왜 그냥 gradient 를 보내지 않는가

배포 유형

Cross-device FL

Cross-silo FL

주요 도전 과제

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

2. System Heterogeneity