24. On-Device Learning 단계별 학습 문서

원문 경로: /Users/keumky/Documents/New project 3/sources/mlsysbook/24-ondevice_learning/source.md

짧은 소개

이 장은 AI 모델이 서버에서 한 번 학습된 뒤 기기에서 예측만 하는 방식에서 벗어나, 스마트폰, 웨어러블, IoT 센서 같은 실제 기기 안에서 조금씩 배우고 적응하는 방법을 설명해요.

핵심은 단순히 “기기에서 AI를 실행한다”가 아니에요. 기기 안에서 학습하려면 메모리, 배터리, 발열, 네트워크, 개인정보, 기기별 성능 차이까지 함께 설계해야 해요. 그래서 이 장은 알고리즘 이야기이면서 동시에 시스템 설계 이야기입니다.

읽는 방법

처음부터 모든 세부 수치와 수식을 붙잡기보다 세 번에 나누어 읽는 것이 좋아요.

1. 먼저 목차와 요약을 보며 “왜 기기 안에서 배워야 하는가”를 잡아요.
2. 그다음 중앙 학습, 기기 내 학습, federated learning의 흐름을 그림처럼 연결해요.
3. 마지막으로 메모리, 전력, sparse update, LoRA, replay buffer, MLOps 같은 세부 설계를 하나씩 파고들어요.

이 장을 읽을 때는 다음 질문을 계속 들고 가면 좋아요.

기기에서 직접 배우면 무엇이 좋아질까요?
그 대신 어떤 자원이 부족해질까요?
그래서 모델, 데이터, 운영 방식을 어떻게 줄이고 나눠야 할까요?

이 장의 한 줄 요약

On-device learning은 사용자 데이터가 생기는 기기 안에서 모델을 개인화하고 개선하는 방식이며, 이를 실현하려면 모델 일부만 학습하는 적응 전략, 적은 데이터로 배우는 방법, 여러 기기를 안전하게 조율하는 federated learning, 그리고 배포 후 운영 체계를 함께 설계해야 해요.

1단계: 중학교 수준

1. AI가 “본사 교육”만 받는 시대에서 “현장 교육”도 받는 시대로 가요

기존 AI를 회사 신입사원에 비유해 볼게요.

예전 방식은 본사 연수원에서 모든 교육을 끝낸 뒤, 각 지점으로 직원을 보내는 방식과 비슷해요. 직원은 현장에 가서 손님을 만나지만, 배운 내용을 스스로 바꾸지는 않아요.

On-device learning은 조금 달라요. 직원이 각 지점에서 손님을 직접 만나며 “이 지역 손님은 이런 표현을 자주 쓰는구나”, “이 집은 저녁마다 조명이 어둡구나”, “이 사용자는 이런 단어를 자주 치는구나”처럼 현장에서 조금씩 배우는 방식이에요.

여기서 “지점”이 스마트폰, 시계, 이어폰, 자동차, 센서 같은 기기예요.

2. 왜 굳이 기기 안에서 배울까요?

가장 큰 이유는 네 가지예요.

예를 들어 스마트폰 키보드는 내가 자주 쓰는 이름이나 표현을 더 잘 맞히면 편리해요. 그런데 내가 입력한 문장을 모두 서버로 보내는 것은 불편하고 위험할 수 있어요. 이때 기기 안에서만 조금 배우면 유용해요.

3. 하지만 기기는 작은 책상 같아요

큰 서버는 넓은 연구실 같아요. 컴퓨터도 많고, 전기도 충분하고, 냉각 장치도 좋아요.

반면 스마트폰이나 웨어러블은 작은 책상 같아요. 책을 많이 펼치면 자리가 부족하고, 오래 일하면 뜨거워지고, 배터리도 줄어들어요.

그래서 기기 안에서 AI를 학습시킬 때는 “모델 전체를 다시 가르치자”가 아니라 “정말 필요한 부분만 조금 고치자”가 중요해요.

4. 전체를 바꾸지 않고 작은 손잡이만 조절해요

큰 오디오 장비를 떠올려 볼게요. 음악 전체를 새로 녹음하지 않아도, 볼륨이나 저음, 고음 조절 손잡이를 조금 바꾸면 내 방에 맞는 소리가 나요.

On-device learning에서도 비슷한 일이 일어나요. 이미 잘 배운 큰 모델은 그대로 두고, 작은 조절 손잡이만 바꾸는 식으로 개인화해요.

이 작은 손잡이에 해당하는 것이 bias, adapter, low-rank update, sparse update 같은 방법이에요. 1단계에서는 이름을 외우기보다 “큰 모델 전체를 다시 만들지 않고, 필요한 작은 부분만 조정한다”는 감각만 잡으면 충분해요.

5. 여러 기기가 같이 배우되, 일기장은 보내지 않아요

Federated learning은 반 친구들이 각자 일기장을 집에 둔 채로, 배운 요점만 선생님에게 알려주는 방식과 비슷해요.

각 기기는 자기 데이터로 조금 배워요. 하지만 원본 데이터는 보내지 않아요. 대신 “내가 배워 보니 모델을 이런 방향으로 고치면 좋겠어요”라는 요약된 변화만 서버에 보내요. 서버는 여러 기기의 의견을 모아 전체 모델을 조금 더 좋게 만들어요.

다만 요약 정보만 보낸다고 해서 개인정보 문제가 완전히 사라지는 것은 아니에요. 요약 안에서도 단서가 새어 나올 수 있기 때문에, 추가 보호 장치가 필요해요.

6. 1단계 중간 정리

On-device learning은 “내 기기가 나를 더 잘 이해하도록 현장에서 조금씩 배우는 기술”이에요.

하지만 기기는 작고, 배터리가 있고, 네트워크도 항상 좋지 않아요. 그래서 이 장의 큰 그림은 다음 한 문장으로 잡을 수 있어요.

기기 안에서 배우게 하되, 너무 많이 배우려 하지 말고,
작게 조정하고, 적은 데이터로 배우고, 여러 기기를 조심스럽게 연결해요.

2단계: 고등학교 수준

1. 중앙 학습과 온디바이스 학습의 논리 차이

기존 머신러닝 흐름은 보통 이렇게 생겼어요.

많은 데이터를 서버로 모음
  ↓
서버에서 큰 모델을 학습
  ↓
완성된 모델을 기기에 배포
  ↓
기기는 예측만 수행

On-device learning은 배포 이후에도 기기에서 작은 학습이 계속 일어나요.

서버에서 기본 모델을 미리 학습
  ↓
기기에 모델 배포
  ↓
기기가 자기 로컬 데이터로 조금 적응
  ↓
필요하면 여러 기기의 업데이트를 모아 전체 모델 개선

2. 학습은 추론보다 훨씬 무거워요

추론은 모델이 답을 한 번 내는 일이에요. 예를 들어 키보드가 다음 단어를 예측하는 것이 추론이에요.

학습은 답을 낸 뒤 “얼마나 틀렸는지”를 보고 모델을 고치는 일이에요. 그래서 더 많은 과정이 필요해요.

추론: 입력 → 모델 → 예측

학습: 입력 → 모델 → 예측 → 오차 계산 → 거꾸로 원인 추적 → 모델 수정

단순한 함수로 보면 모델은 이런 식으로 생각할 수 있어요.

[ y = wx + b ]

• (x): 입력이에요.
• (w): 입력을 얼마나 중요하게 볼지 정하는 가중치예요.
• (b): 결과를 살짝 밀어 주는 조정값이에요.
• (y): 예측 결과예요.

학습은 예측값 (y)가 정답과 다를 때, (w)나 (b)를 조금씩 바꾸어 오차를 줄이는 과정이에요. 그런데 기기에서는 모든 (w)를 다 바꾸기 어렵기 때문에, (b)처럼 작은 부분만 조정하거나 작은 adapter만 붙이는 전략을 많이 써요.

3. 세 가지 제약이 항상 함께 움직여요

On-device learning의 핵심 제약은 모델, 데이터, 계산 자원이에요.

이 셋은 따로 움직이지 않아요. 모델을 크게 만들면 메모리와 전력이 늘고, 데이터를 더 저장하면 개인정보와 저장공간 문제가 생기며, 자주 학습하면 배터리와 발열 문제가 생겨요.

4. 모델을 조금만 고치는 방법들

모델 전체를 다시 학습하는 것은 서버에서는 가능해도 기기에서는 너무 무거울 수 있어요. 그래서 다음처럼 “고칠 부분”을 줄여요.

고등학교 수준에서 중요한 것은 “업데이트 범위를 줄이면 자원을 아낄 수 있지만, 너무 줄이면 모델이 충분히 적응하지 못한다”는 균형이에요.

5. 적은 데이터로 배우는 흐름

기기 안 데이터는 서버 데이터처럼 많고 깔끔하지 않아요. 사용자가 몇 번 말한 음성, 하루 동안의 움직임, 몇 번의 키보드 수정처럼 작고 불완전한 신호가 많아요.

그래서 데이터 효율성이 중요해요.

적은 예시가 있음
  ↓
이미 학습된 모델의 지식을 최대한 활용
  ↓
작은 부분만 빠르게 조정
  ↓
과거 예시 일부를 다시 보며 잊어버림을 줄임
  ↓
원본 대신 압축된 특징을 저장해 메모리를 아낌

여기서 “과거 예시를 다시 본다”는 것이 experience replay예요. 새로운 것만 계속 배우면 예전에 알던 것을 잊을 수 있기 때문에, 중요한 과거 경험을 조금씩 섞어 주는 방식이에요.

6. Federated learning의 기본 흐름

Federated learning은 여러 기기가 원본 데이터를 공유하지 않고 함께 모델을 개선하는 방식이에요.

서버가 global model을 보냄
  ↓
각 기기가 local data로 학습
  ↓
각 기기가 model update만 보냄
  ↓
서버가 update를 가중 평균
  ↓
새 global model을 다시 배포

가중 평균은 다음처럼 생각할 수 있어요.

[ \text{새 모델} = \frac{\text{기기 A 데이터 수}}{\text{전체 데이터 수}}\text{A의 모델}

• \frac{\text{기기 B 데이터 수}}{\text{전체 데이터 수}}\text{B의 모델}
• \cdots ]

데이터가 많은 기기의 업데이트를 조금 더 크게 반영하는 식이에요. 하지만 기기마다 데이터 분포가 다르면, 즉 어떤 기기는 영어 키보드 데이터가 많고 어떤 기기는 한국어와 이모지 사용이 많으면, 단순 평균만으로는 문제가 생길 수 있어요. 이 상태를 non-IID data라고 해요.

7. 2단계 중간 정리

On-device learning의 논리 흐름은 다음과 같아요.

기기에서 배우고 싶다
  ↓
그런데 학습은 추론보다 훨씬 무겁다
  ↓
모델 전체가 아니라 일부만 고친다
  ↓
데이터가 적으므로 효율적으로 재사용한다
  ↓
여러 기기의 지식을 모으되 원본 데이터는 보호한다
  ↓
배터리, 발열, 네트워크, 운영 모니터링까지 함께 설계한다

3단계: 대학교 수준

1. Purpose: 이 장이 묻는 근본 질문

원문은 on-device learning을 “학습은 클라우드에서, 추론은 기기에서”라는 오래된 분업을 깨는 변화로 봐요.

기존 ML 시스템은 보통 중앙에서 학습한 모델을 기기에 배포하고, 기기는 고정된 모델로 예측만 했어요. 하지만 실제 세계의 기기는 계속 다른 상황을 만나요. 스마트폰 키보드는 사용자마다 다른 표현을 보고, 스마트홈 기기는 가정마다 다른 생활 리듬을 만나며, 자동차는 지역마다 다른 도로와 날씨를 경험해요.

이런 상황에서 모델이 배포 후에도 현장에서 조금씩 적응할 수 있다면 세 가지가 달라져요.

따라서 이 장의 목적은 on-device learning을 단순한 최적화가 아니라, 모델 학습 위치, 데이터 위치, 업데이트 조율 방식이 바뀌는 시스템 아키텍처 변화로 이해하는 데 있어요.

2. Distributed Learning Paradigm Shift

중앙화된 ML 운영은 안정적인 네트워크, 충분한 계산 자원, 예측 가능한 서버 환경을 전제로 해요. 하지만 edge device로 갈수록 이 전제가 깨져요.

스마트폰, 웨어러블, 자동차, IoT 센서는 다음과 같은 조건에서 동작해요.

• 메모리가 제한돼요.
• 배터리와 발열 문제가 있어요.
• 네트워크가 자주 끊겨요.
• 사용자의 데이터 분포가 서로 달라요.
• 어떤 기기는 최신 칩을 쓰고, 어떤 기기는 매우 작은 마이크로컨트롤러예요.

원문은 Apple A11 Bionic 이후 모바일 칩이 gradient 계산까지 어느 정도 가능해졌다는 점을 언급해요. A11은 이전 세대보다 훨씬 높은 TOPS를 제공했고, Google Pixel Visual Core도 ML에 특화된 연산을 지원했어요. 즉 하드웨어가 좋아지면서 “기기 안 학습”이 현실적인 선택지가 되었지만, 여전히 클라우드와 같은 방식으로 학습할 수는 없어요.

중요한 변화는 lifecycle에도 나타나요. 중앙 학습에서는 “버전 1 배포, 버전 2 배포”처럼 모델 버전을 비교적 선형적으로 관리할 수 있어요. On-device learning에서는 각 기기가 자기 데이터로 다르게 적응하므로 모델 상태가 기기별로 갈라져요. 평가도 중앙 대시보드 하나로 끝나지 않고, 다양한 사용자 집단과 기기 상태를 고려해야 해요.

3. Motivations and Benefits

3.1 왜 필요한가요?

원문은 on-device learning의 동기를 네 가지로 정리해요.

스마트폰 키보드 예시는 제약을 잘 보여줘요. 작은 언어 모델도 gradient update를 하려면 activation과 optimizer state 때문에 수십 MB 단위의 메모리가 필요할 수 있어요. 백그라운드 키보드 앱에 허용되는 메모리가 제한되어 있다면, 한 번의 학습 step만으로도 예산의 큰 부분을 써 버릴 수 있어요. 이 때문에 “학습을 기기에서 한다”는 결정은 곧 “학습을 아주 작고 조심스럽게 한다”는 결정이 돼요.

3.2 언제 하지 말아야 하나요?

원문은 on-device learning이 항상 정답은 아니라고 강조해요. 더 단순한 대안으로 충분할 때가 있어요.

On-device learning을 선택해야 하는 조건은 더 강해요. 예를 들어 법적으로 데이터를 클라우드로 보낼 수 없거나, 네트워크 왕복 시간이 시스템 요구사항보다 길거나, 오프라인에서도 반드시 적응해야 하거나, 실제 성능 향상이 복잡도를 정당화할 만큼 커야 해요.

원문은 지연 시간 기준도 제시해요.

네트워크 왕복이 50-200 ms 수준이라면, 이런 작업에서는 클라우드에 물어보는 구조 자체가 맞지 않을 수 있어요.

3.3 Transfer learning이 기반이에요

기기에서 처음부터 모든 것을 배우는 것은 비현실적이에요. 대신 클라우드에서 미리 배운 모델이 일반적인 특징을 알고 있고, 기기는 그 지식을 자기 상황에 맞게 조금 조정해요.

이것이 transfer learning의 역할이에요. 이미 배운 지식을 가져와서 새로운 사용자, 새로운 환경, 새로운 센서 조건에 빠르게 맞추는 거예요.

3.4 실제 적용 분야

원문은 여러 분야를 다뤄요.

Gboard는 federated learning의 대표 사례로 소개돼요. 원본 타이핑 데이터를 중앙으로 보내지 않고도 많은 기기의 업데이트를 모아 shared model을 개선했어요.

Wake-word detection도 중요한 사례예요. “Hey Siri”, “OK Google” 같은 감지는 항상 켜져 있어야 하므로 전력은 극도로 낮아야 하고, 반응 시간은 짧아야 하며, 잘못 켜지는 빈도도 낮아야 해요. 사용자의 목소리와 공간 음향에 적응하면 성능이 좋아지지만, 음성 데이터는 매우 민감하므로 기기 안 학습이 매력적이에요.

4. Architectural Trade-offs: Centralized vs. Decentralized Training

중앙 학습은 강력한 장점이 있어요. 큰 컴퓨팅 자원, 다양한 데이터, 디버깅과 검증 파이프라인을 활용할 수 있어요. 하지만 다음 전제를 필요로 해요.

• 데이터를 중앙으로 보낼 수 있어야 해요.
• 사용자가 데이터 보관 주체를 신뢰해야 해요.
• 네트워크와 중앙 인프라가 충분히 안정적이어야 해요.
• 하나의 global model이 대부분 사용자에게 잘 맞아야 해요.

Decentralized on-device learning은 이 전제를 바꿔요. 각 기기가 모델 복사본을 갖고, 자기 로컬 데이터로 비동기적으로 적응해요. 이 구조는 privacy와 personalization에 유리하지만, 운영 난이도를 크게 높여요.

중요한 운영 문제는 다음과 같아요.

원문은 많은 실제 배포에서 상당한 비율의 기기가 어떤 시점에는 offline일 수 있다고 말해요. 재접속한 기기는 오래된 모델 상태를 가지고 있을 수 있으므로, 상태 조정과 업데이트 검증이 필요해요. 안전한 시스템은 서명 검증, 기능 테스트, telemetry 확인, 단계적 롤백을 함께 설계해야 해요.

이 변화는 세 단계로 볼 수 있어요.

1. 중앙 학습
   많은 데이터를 모아 global model을 만들어요.

2. 로컬 적응
   기기가 자기 데이터로 모델을 조금 바꿔요.

3. Federated coordination
   여러 기기의 업데이트를 모아 global model도 개선해요.

여기서 중요한 통계적 어려움이 non-IID data예요. IID는 샘플들이 같은 분포에서 독립적으로 나온다는 가정인데, 기기 데이터는 보통 그렇지 않아요. 각 사용자의 언어, 생활 패턴, 센서 환경이 다르기 때문이에요.

5. Design Constraints

5.1 학습은 추론보다 자원 요구가 증폭돼요

On-device inference는 forward pass만 필요해요. 하지만 training은 forward pass, backward pass, gradient 계산, weight update, optimizer state 관리가 필요해요.

원문은 학습이 추론보다 대략 다음 수준으로 부담이 커진다고 설명해요.

이 증폭 때문에, inference를 잘 돌리는 모델이라고 해서 training도 기기에서 잘 된다고 볼 수 없어요.

5.2 Model constraints

모델 크기는 저장공간만의 문제가 아니에요. 학습 중에는 각 layer의 activation을 저장하고, gradient와 optimizer state도 관리해야 해요.

예를 들어 MobileNetV2는 스마트폰에서는 비교적 작은 모델일 수 있지만, SRAM이 수백 KB 수준인 마이크로컨트롤러에서는 너무 커요. 원문은 Arduino Nano 33 BLE Sense 같은 장치가 256 KB SRAM과 1 MB flash를 가진다는 점을 들어, 일반적인 이미지 한 장이나 CNN layer 하나도 큰 부담이 될 수 있음을 설명해요.

모델 제약의 핵심은 다음이에요.

• 큰 transformer나 깊은 CNN을 그대로 학습하기 어렵습니다.
• activation caching이 peak memory를 크게 늘립니다.
• smartwatch나 wearable에서는 배터리와 발열이 사용자 경험을 직접 해칩니다.
• 따라서 MobileNet, SqueezeNet, EfficientNet처럼 가벼운 구조가 중요합니다.

Depthwise separable convolution은 대표적인 경량화 아이디어예요. 표준 convolution을 채널별 필터 적용과 채널 결합으로 나누어 parameter와 연산량을 크게 줄여요. 원문은 큰 convolution에서 parameter 수가 극적으로 줄어드는 예를 통해, 이런 구조가 모바일 AI를 가능하게 만든 배경을 설명해요.

5.3 Data constraints

기기 데이터는 많고 정돈된 서버 데이터와 달라요.

예를 들어 fitness tracker는 운동 중에만 유의미한 데이터를 얻을 수 있고, 카메라는 많은 이미지를 보더라도 사용자가 태그하거나 공유한 일부만 약한 라벨로 쓸 수 있어요. 따라서 전통적인 supervised learning만으로는 부족하고, few-shot, weak supervision, self-supervised, replay 같은 방법이 필요해요.

5.4 Compute constraints

기기 종류에 따라 가능한 학습 수준이 크게 달라요.

STM32F4나 ESP32 같은 장치는 SRAM이 매우 작고 floating-point acceleration이 부족해요. 이 경우에는 8-bit quantization, quantization-aware training, 아주 단순한 SGD가 중요해요.

반면 Apple Neural Engine, Qualcomm Hexagon, Google Tensor 같은 모바일 가속기는 훨씬 강력해요. 하지만 대부분의 모바일 가속기는 여전히 inference에 최적화되어 있어요. Backpropagation은 activation을 저장하고 gradient를 계산하며 weight를 쓰는 작업이 많아서, inference보다 메모리 대역폭과 쓰기 패턴이 훨씬 까다로워요.

5.5 Energy and thermal constraints

학습은 전력과 발열 문제를 직접 일으켜요. 원문은 스마트폰 ML workload가 지속적으로 사용할 수 있는 전력과 짧게 burst할 수 있는 전력이 다르다고 설명해요. 잠깐 높은 성능을 낼 수는 있지만, 오래 지속하면 thermal throttling으로 성능이 떨어져요.

학습 전력은 대략 다음에 쓰여요.

그래서 실용적인 시스템은 보통 다음 조건에서 학습을 수행해요.

• 기기가 충전 중일 때
• 사용자가 적극적으로 쓰지 않을 때
• Wi-Fi에 연결되어 있을 때
• 온도가 안전 범위 안에 있을 때
• 배터리 사용량이 하루 예산을 넘지 않을 때

DVFS는 온도와 부하에 따라 전압과 클럭을 낮추는 장치예요. ML training이 온도를 올리면 클럭이 떨어지고, 학습 속도도 갑자기 낮아질 수 있어요. 좋은 시스템은 throttling이 발생한 뒤 당황하는 것이 아니라, batch size나 학습 강도를 미리 줄여요.

5.6 Memory hierarchy constraints

메모리는 총량만 보면 안 돼요. L1 cache, L2 cache, system memory 사이의 지연 시간 차이가 크기 때문이에요.

원문은 MobileNetV2가 inference 때는 비교적 작아도 training 때는 activation, gradient, optimizer state 때문에 메모리 요구가 수십 MB로 늘 수 있다고 설명해요. 마이크로컨트롤러나 저가형 기기에서는 이 차이가 학습 가능 여부를 결정해요.

중요한 기법은 다음과 같아요.

Gradient checkpointing은 메모리를 절약하기 위해 backward pass 때 일부 activation을 다시 계산하는 방식이에요. 원문은 메모리를 크게 줄일 수 있지만 추가 계산 비용이 든다고 설명해요.

5.7 Constraint-to-solution mapping

원문은 제약을 세 가지 해결 기둥으로 연결해요.

이 세 기둥이 이후 장의 중심 흐름이에요.

6. Model Adaptation

Model adaptation의 목표는 “global model이 이미 잘 아는 것은 보존하고, local variation에 필요한 부분만 바꾸는 것”이에요.

핵심 trade-off는 다음이에요.

더 많이 바꾸면 표현력은 커져요.
하지만 메모리, 계산, 에너지, 불안정성도 커져요.

더 적게 바꾸면 안전하고 가벼워요.
하지만 복잡한 사용자 차이를 못 따라갈 수 있어요.

6.1 Weight freezing과 bias-only adaptation

가장 가벼운 방법은 대부분의 weight를 얼려 두고 bias만 학습하는 거예요.

일반적인 layer는 다음처럼 표현할 수 있어요.

[ y = Wx + b ]

• (W): 입력을 섞고 변환하는 큰 weight matrix예요.
• (b): 출력에 더해지는 bias vector예요.

Full training은 (W)와 (b)를 모두 바꿔요. Bias-only adaptation은 다음처럼 (W)는 고정하고 (b)만 바꿔요.

[ \frac{\partial \mathcal{L}}{\partial W}=0,\quad \frac{\partial \mathcal{L}}{\partial b}\neq 0 ]

[ b \leftarrow b - \eta \frac{\partial \mathcal{L}}{\partial b} ]

여기서 (\mathcal{L})은 손실 함수, (\eta)는 learning rate예요. 이 방식은 저장해야 할 gradient와 optimizer state를 크게 줄여요.

TinyTL은 이 아이디어를 잘 보여주는 사례예요. convolution weight와 batch normalization 통계는 고정하고, bias term이나 작은 residual component만 학습해요. 그 결과 MobileNetV2처럼 수백만 parameter를 가진 모델에서도 실제 업데이트 parameter를 매우 작게 줄일 수 있어요.

Bias-only의 장단점은 분명해요.

6.2 Residual adapter

Bias-only가 너무 약할 때는 frozen backbone 사이에 작은 trainable module을 붙일 수 있어요. 이를 adapter라고 생각하면 돼요.

숨겨진 표현 (h)가 있을 때 residual adapter는 다음처럼 동작해요.

[ h’ = h + A(h) ]

[ A(h) = W_2\sigma(W_1h) ]

여기서 (W_1)은 차원을 작게 줄이고, (W_2)는 다시 원래 차원으로 되돌리는 작은 bottleneck 구조예요. (r \ll d)로 두면 trainable parameter가 작게 유지돼요.

Adapter는 기존 모델을 망가뜨리지 않고 작은 보정 경로를 더해요. 카메라 파이프라인에서는 조명, 렌즈 특성, 사용자 선호에 맞추는 데 쓸 수 있고, 음성 인식에서는 특정 사용자의 발음이나 억양에 맞게 조정할 수 있어요.

6.3 Low-rank adaptation과 LoRA

큰 weight matrix 전체를 바꾸는 대신, 변화량 자체를 낮은 rank의 두 matrix 곱으로 표현할 수 있어요.

[ \Delta W \approx UV^\top ]

원래 (W)가 (m \times n) matrix라면 full update는 (mn)개의 값을 바꿔야 해요. Low-rank update는 (U \in \mathbb{R}^{m \times r}), (V \in \mathbb{R}^{n \times r})만 학습하므로 parameter 수가 (r(m+n))으로 줄어요.

예를 들어 (768 \times 768) matrix는 full update에 589,824개 parameter가 필요해요. rank가 4라면 (768 \times 4 \times 2 = 6,144)개만 학습하면 돼요. 원문은 이것이 약 96% 감소라고 설명해요.

적응된 weight는 다음처럼 볼 수 있어요.

[ W_{\text{adapted}} = W_{\text{frozen}} + UV^\top ]

LoRA는 이 아이디어를 대표하는 방법이에요. 큰 언어 모델을 기기에서 full fine-tuning하려면 메모리와 통신량이 너무 크지만, LoRA adapter만 학습하고 동기화하면 훨씬 현실적이에요. 원문은 거대한 모델 전체를 옮기는 대신 수십 MB 규모의 adapter update를 다루는 것이 모바일 네트워크에서 훨씬 실용적이라고 설명해요.

6.4 Sparse updates

Sparse update는 “어떤 parameter가 이번 task에 가장 중요한가”를 골라 그 부분만 바꾸는 방식이에요.

모델 parameter를 layer별로 (\theta_1,\theta_2,\ldots,\theta_L)라고 할 때, full fine-tuning은 모든 layer를 업데이트해요.

[ \theta_i \leftarrow \theta_i - \eta \frac{\partial \mathcal{L}}{\partial \theta_i} ]

Sparse update는 선택된 집합 (\mathcal{S})에 들어 있는 layer만 바꿔요.

[ \theta_i \leftarrow \begin{cases} \theta_i - \eta \frac{\partial \mathcal{L}}{\partial \theta_i}, & i \in \mathcal{S} \ \theta_i, & i \notin \mathcal{S} \end{cases} ]

문제는 (\mathcal{S})를 어떻게 고르느냐예요. 원문은 contribution analysis를 설명해요.

전체 모델을 고정
  ↓
후보 layer 하나만 잠깐 풀어 학습
  ↓
성능 향상과 비용을 측정
  ↓
메모리 예산 안에서 가장 효율적인 layer 조합 선택

TinyTrain은 meta-training을 통해 어떤 layer가 새 task에 민감한지 미리 학습하고, 배포 시점에 현재 task와 자원 상태에 맞춰 업데이트할 layer를 선택하는 접근이에요.

6.5 Adaptation strategy 비교

7. Data Efficiency

On-device learning의 두 번째 기둥은 적은 데이터에서 최대한 많은 학습 신호를 뽑아내는 일이에요.

원문은 데이터 효율 문제를 네 가지 관점으로 설명해요.

1. 데이터 하나를 얻는 데 사용자 불편, 에너지, 저장공간, 개인정보 비용이 들어요.
2. 데이터를 넓게 모을지, 깊게 모을지 선택해야 해요.
3. 어떤 작업은 몇 번의 예시로 빠르게 적응해야 하고, 어떤 작업은 오래 누적하며 배워도 돼요.
4. 데이터 효율 전략은 model adaptation, federated learning, monitoring과 함께 맞물려야 해요.

7.1 Few-shot learning

Few-shot learning은 아주 적은 예시로 새 사용자나 새 조건에 맞추는 방식이에요.

기기에서 (K)개의 labeled example만 있다고 해 볼게요.

[ D = {(x_i,y_i)}_{i=1}^{K} ]

이때 목표는 전체 모델을 크게 바꾸는 것이 아니라, 제한된 step 안에서 작은 parameter subset을 조정하는 거예요. 원문은 몇 가지 제약을 말해요.

• gradient step 수가 매우 적어야 해요.
• 업데이트되는 parameter 크기가 작아야 해요.
• 기존 지식을 잊지 않아야 해요.

Keyword spotting은 대표 사례예요. 사용자가 custom wake word를 5-10번 녹음하면, 기기는 pretrained acoustic encoder를 고정하고 마지막 classifier나 bias 정도만 조정할 수 있어요. 원본 음성을 서버로 보내지 않아도 사용자의 발음에 맞게 감지 성능을 높일 수 있어요.

7.2 Streaming adaptation

Streaming adaptation은 데이터가 한 번에 모이지 않고 시간 순서대로 계속 들어오는 상황을 다뤄요.

[ \theta_{t+1} = \theta_t - \eta_t \nabla \mathcal{L}(x_t;\theta_t) ]

여기서 (x_t)는 시점 (t)에 들어온 관측값이고, (\eta_t)는 그 시점의 learning rate예요.

이 방식은 실시간 적응에 좋지만, 노이즈와 drift에 민감해요. 그래서 다음 장치가 필요해요.

• learning rate decay
• update gating
• confidence check
• meta-learned initialization
• shadow model과 비교

예를 들어 wearable device는 사용자의 걸음걸이가 시간에 따라 변할 수 있으므로 계속 적응해야 해요. 하지만 일시적 센서 오류를 진짜 변화로 배우면 안 돼요.

7.3 Experience replay

Continual learning에서는 새 데이터를 배우다가 예전 지식을 잊는 catastrophic forgetting이 생겨요. Experience replay는 과거 예시 일부를 buffer에 저장해 두고, 새 데이터와 함께 다시 학습해 이를 줄여요.

Replay buffer를 (\mathcal{M})이라고 하면, 시점 (t)에서 buffer에서 (k)개 예시를 뽑아 다음처럼 업데이트할 수 있어요.

[ \theta_{t+1} = \theta_t - \eta \nabla_\theta \left[ \frac{1}{k} \sum_{i=1}^{k} \mathcal{L}(x_i,y_i;\theta_t) \right] ]

서버에서는 replay buffer를 크게 둘 수 있지만, 기기에서는 수십 개나 수백 개 수준의 compressed sample만 저장해야 할 수 있어요. 그래서 원본 audio나 image 대신 마지막 layer embedding 같은 압축 특징을 저장하는 방식이 유용해요.

Replay의 trade-off는 다음과 같아요.

7.4 Data compression

Data compression은 원본 입력을 낮은 차원의 표현으로 바꿔 저장하고 학습하는 방식이에요.

이미지 (x_i)를 pretrained encoder (f)에 넣어 embedding (z_i)를 얻는다고 해 볼게요.

[ z_i = f(x_i) ]

그다음 작은 decoder나 head (g(z_i;\theta))만 학습해요.

[ \theta_{t+1} = \theta_t

• \eta \nabla_\theta \mathcal{L}(g(z_i;\theta),y_i) ]

이 구조에서는 큰 원본 데이터가 아니라 작은 embedding과 작은 head만 다루므로 메모리와 계산이 줄어요.

원문은 더 나아가 dictionary 기반 표현도 설명해요.

[ X \approx DC ]

여기서 (D)는 basis pattern의 사전이고, (C)는 각 예시가 어떤 basis를 얼마나 쓰는지 나타내는 sparse coefficient예요. 센서 trace처럼 반복 패턴이 있는 데이터에 적합해요.

음성에서는 MFCC가 대표적인 압축 표현이에요. 짧은 audio window를 사람의 청각 특성에 맞춘 소수의 coefficient로 바꾸면, 원본 waveform보다 훨씬 적은 메모리로 keyword spotting에 쓸 수 있어요.

7.5 Data efficiency strategy 비교

실제 시스템은 보통 이들을 조합해요. 예를 들어 keyword spotting은 MFCC로 입력을 압축하고, 사용자의 몇 개 녹음으로 few-shot adaptation을 수행하며, 과거 embedding 일부를 replay buffer에 저장할 수 있어요.

8. Federated Learning

개별 기기에서만 학습하면 한계가 있어요. 한 기기가 배운 유용한 패턴이 다른 기기에는 전달되지 않기 때문이에요.

원문의 음성 assistant 예시를 생각해 볼게요. 어떤 집에서는 특정 단어 발음이 다르고, 어떤 집에서는 특정 전문용어가 자주 쓰이며, 어떤 집에서는 배경 소음이 다르게 나타나요. 각 기기가 자기 사용자에게만 잘 맞으면 global model은 개선되지 않고, local bias가 쌓일 수 있어요.

Federated learning은 이 문제를 해결하기 위해 원본 데이터는 기기에 두고, model update만 모아 collective intelligence를 만드는 방식이에요.

8.1 기본 protocol

Federated learning의 기본 cycle은 다음과 같아요.

서버가 global model 배포
  ↓
선정된 client가 local data sampling
  ↓
각 client가 local training 수행
  ↓
client가 update를 서버로 전송
  ↓
서버가 update를 aggregation
  ↓
새 global model 배포

가장 기본적인 방법은 FedAvg예요. client (k)의 local dataset을 (\mathcal{D}_k), sample 수를 (n_k), round (t) 이후 local parameter를 (\theta_k^{t+1})라고 하면, 서버는 다음처럼 가중 평균을 계산해요.

[ \theta^{t+1}

\sum_{k=1}^{K} \frac{n_k}{n} \theta_k^{t+1} ]

여기서 (n=\sum_k n_k)예요.

FedAvg의 중요한 선택지는 local step 수 (E)예요. (E)가 크면 통신 횟수는 줄지만, 각 기기가 자기 non-IID data에 너무 맞춰져 global model이 발산할 수 있어요. (E)가 작으면 안정적이지만 통신 비용이 커져요.

8.2 Client scheduling

Federated learning에서 모든 기기가 항상 참여할 수는 없어요. 보통 다음 조건을 만족하는 기기만 참여시켜요.

• 충전 중
• Wi-Fi 연결
• idle 상태
• 충분한 배터리와 온도 여유
• 적절한 local data 보유

하지만 이런 조건은 bias를 만들 수 있어요. 고성능 기기, 안정적인 네트워크, 규칙적인 충전 습관을 가진 사용자가 더 자주 참여하고, 저가형 기기나 불안정한 환경의 사용자는 덜 참여할 수 있어요. 그러면 모델이 특정 사용자 집단에 더 잘 맞게 편향될 수 있어요.

이를 줄이려면 stratified sampling, quota-based sampling, fairness budget, importance weighting, availability prediction 같은 scheduling 전략이 필요해요.

8.3 Bandwidth-aware update compression

Federated learning의 큰 병목은 통신이에요. full model이나 full gradient를 매 round 보내면 모바일 네트워크와 배터리 예산을 쉽게 넘어요.

대표적인 압축 방법은 세 가지예요.

통신량이 줄면 참여율도 올라가요. 원문은 update 크기가 커질수록 sustained participation이 급격히 떨어지고, 작은 update일수록 더 많은 기기가 참여할 수 있음을 설명해요. 이는 단순한 네트워크 최적화가 아니라 model quality에도 연결돼요. 더 많은 기기가 참여하면 통계적 다양성이 좋아지기 때문이에요.

8.4 Federated personalization

기본 FL은 하나의 global model을 모든 사용자에게 잘 맞추려 해요. 하지만 실제로는 사용자마다 local loss landscape가 달라요.

전통적인 global objective는 다음처럼 볼 수 있어요.

[ \min_\theta \sum_{k=1}^{K} w_k \mathcal{L}_k(\theta) ]

Personalized FL은 각 client가 자기 parameter (\theta_k)를 갖도록 확장해요.

[ \min_{\theta_1,\ldots,\theta_K} \sum_{k=1}^{K} \left( \mathcal{L}_k(\theta_k)

• \lambda \mathcal{R}(\theta_k,\theta_{\text{global}}) \right) ]

(\mathcal{R})은 local model이 global model에서 너무 멀어지지 않도록 잡아 주는 regularization이고, (\lambda)는 그 강도를 조절해요.

대표 전략은 다음과 같아요.

8.5 Federated privacy

Federated learning은 원본 데이터를 보내지 않지만, privacy가 자동 보장되는 것은 아니에요. Gradient나 weight update에서도 local data의 단서가 새어 나올 수 있어요.

대표 위험은 다음과 같아요.

• Model inversion attack: update를 보고 입력 특성을 복원하려 해요.
• Membership inference attack: 어떤 사용자의 데이터가 학습에 쓰였는지 추론해요.
• Participation pattern leakage: 언제, 얼마나 자주 참여하는지가 민감 정보를 드러낼 수 있어요.

대표 방어는 secure aggregation과 differential privacy예요.

Differential privacy의 (\epsilon) 값은 privacy와 utility의 균형을 정해요. 작을수록 privacy는 강해지지만 noise가 커져 성능이 떨어질 수 있어요.

8.6 Large-scale device orchestration

대규모 FL은 ML 문제이면서 동시에 거대한 분산 시스템 문제예요.

원문은 다음 어려움을 강조해요.

FedAsync 같은 비동기 방식은 느린 기기를 기다리지 않고 update가 도착할 때마다 global model을 갱신해요. 대신 오래된 update에는 낮은 weight를 주는 staleness-aware weighting이 필요해요.

대규모 시스템은 hierarchical aggregation도 고려해요. 모든 client가 하나의 중앙 서버와 직접 조율하기보다, 지역 aggregation server나 edge infrastructure를 통해 update를 모은 뒤 global aggregation을 수행할 수 있어요.

9. Production Integration

이론적으로 좋은 adaptation, data efficiency, FL protocol이 있어도 production에서는 따로따로 두면 실패해요. 실제 시스템은 세 요소를 하나의 운영 체계 안에 묶어야 해요.

9.1 Deployment pipeline transformation

중앙 MLOps는 보통 하나의 model artifact를 학습, 검증, staging, production 순서로 배포해요. On-device learning에서는 artifact가 더 복잡해져요.

배포 대상은 다음을 포함해야 해요.

• base model weight
• device tier별 adaptation policy
• quantization과 runtime configuration
• local update 제한 조건
• rollback checkpoint 정책
• federated participation 설정

예를 들어 microcontroller에는 bias-only policy를 주고, mid-range phone에는 rank가 낮은 LoRA adapter를 주며, flagship phone에는 selective layer update를 허용할 수 있어요.

버전 관리도 계층화돼요.

9.2 Monitoring system evolution

중앙 inference server에서는 요청, 응답, latency, error를 직접 모니터링할 수 있어요. On-device learning에서는 원본 데이터와 개별 예측 로그를 마음대로 수집할 수 없어요.

그래서 privacy-preserving telemetry가 필요해요.

Drift detection도 어렵습니다. 라벨이 없기 때문이에요. 그래서 confidence calibration, input distribution shift, 사용자 correction, task abandonment, shadow baseline과의 비교 같은 간접 신호를 사용해요.

9.3 Continuous training orchestration

On-device learning의 continuous training은 서버에서 정해진 시간에 재학습하는 것과 달라요. 수많은 기기가 각자 가능한 시간에 조금씩 학습해요.

운영 시스템은 다음을 처리해야 해요.

• 일부 기기만 참여하는 partial participation
• 느린 기기와 끊기는 기기를 기다리지 않는 straggler tolerance
• 여러 base model version이 동시에 존재하는 version skew
• 오랫동안 offline이었다가 돌아온 기기의 state reconciliation
• 온도, 배터리, 네트워크 상태에 따른 resource-aware scheduling

원문은 training이 하루 배터리 예산의 작은 비율 안에 들어와야 하고, foreground user experience를 방해하지 않아야 한다고 설명해요.

9.4 Validation strategy adaptation

On-device learning에서는 중앙 held-out test set만으로 충분하지 않아요. 배포 후 기기별 적응이 계속 일어나기 때문이에요.

대표 검증 전략은 다음과 같아요.

중요한 점은 “학습할 수 있다”보다 “학습이 도움이 되는지 감시하고 멈출 수 있다”가 production에서는 더 중요하다는 거예요.

10. Bio-Inspired Learning Efficiency

원문은 생물학적 지능에서 힌트를 얻어요. 인간의 뇌는 약 20 W 정도의 전력으로 계속 배우고 적응해요. 현대 AI accelerator와 비교하면 매우 효율적이에요.

뇌의 효율은 몇 가지 원리에서 나와요.

스마트폰은 카메라, 가속도계, GPS, 터치 이벤트 등 엄청난 unlabeled sensor stream을 만들어내요. 이 데이터는 contrastive learning, masked prediction, self-supervised learning에 쓸 수 있어요.

예를 들어 연속된 카메라 프레임은 같은 장면의 조금 다른 모습이므로 positive pair가 될 수 있고, audio spectrogram의 일부를 가린 뒤 맞히는 방식으로 음성 표현을 배울 수 있어요. 활동 인식 모델은 accelerometer의 시간 패턴에서 label 없이도 유용한 표현을 학습할 수 있어요.

하지만 계속 배우면 catastrophic forgetting이 생겨요. 이를 줄이기 위해 elastic weight consolidation, experience replay, progressive architecture, meta-learning 같은 접근이 필요해요. 원문은 특히 MAML처럼 “새 task에 빨리 적응하는 초기 상태”를 학습하는 방식이 on-device personalization에 잘 맞는다고 설명해요.

실용 원칙은 다음과 같아요.

• Full fine-tuning보다 작은 adapter, bias, head update를 우선해요.
• 강한 offline pretraining으로 기기 학습 부담을 줄여요.
• 충전, idle, 안정적 네트워크 상태에서 opportunistic scheduling을 해요.
• replay buffer, support set, adaptation log를 안전하게 저장해요.
• confidence, drift heuristic, shadow model로 local update를 감시해요.
• 항상 known-good baseline으로 rollback할 수 있어야 해요.
• 통신은 quantization, sparsification, selective transmission으로 줄여요.
• 사용자 동의, 데이터 최소화, 보존 기간, 삭제 권리를 처음부터 설계에 넣어요.

11. Systems Integration for Production Deployment

원문은 5천만 개 기기에 배포된 voice assistant 예시로 세 기둥의 통합을 설명해요.

11.1 Model adaptation layer

기기 성능에 따라 adaptation 기법을 다르게 배치해요.

모든 기기에 같은 학습 전략을 강요하면 안 돼요. 계층별 capability matching이 필요해요.

11.2 Data efficiency layer

모든 기기가 replay를 쓰더라도 buffer 크기는 다를 수 있어요. 원문은 예시로 budget device는 작은 buffer, flagship device는 더 큰 buffer를 둘 수 있다고 설명해요.

또한 새 사용자의 첫 몇 번 interaction만으로 빠르게 개인화하는 few-shot 전략과, 사용자의 발화 패턴이 시간이 지나며 변하는 것을 따라가는 streaming update가 함께 필요해요.

11.3 Federated coordination layer

기기는 배터리와 네트워크 상태가 좋을 때 federated round에 참여해요. LoRA adapter만 동기화하면 full model 동기화보다 통신량이 훨씬 작아져요. Secure aggregation을 사용하면 개별 음성 패턴은 기기 밖으로 직접 노출되지 않으면서 population-scale improvement를 얻을 수 있어요.

11.4 통합 원칙

12. Persistent Technical and Operational Challenges

12.1 Device and data heterogeneity

Edge device는 성능 차이가 극단적이에요. ARM Cortex-M 계열 마이크로컨트롤러부터 고성능 스마트폰 프로세서까지 clock, RAM, SIMD, FPU, NPU 지원이 크게 달라요.

소프트웨어도 달라요. OS 버전, driver, runtime, TensorFlow Lite Micro, ONNX Runtime Mobile, custom inference stack 등이 섞여 있으면 같은 모델도 미묘하게 다르게 동작할 수 있어요.

연결성도 달라요. 어떤 기기는 항상 Wi-Fi와 전원에 연결되어 있고, 어떤 기기는 드물게 켜지며 모바일 데이터만 써요. 이 차이는 training frequency, update compression, model format을 모두 바꿔요.

12.2 Non-IID data distribution

Federated learning은 데이터가 중앙에 모이지 않기 때문에 IID 가정을 만족하기 어려워요. 각 기기의 gradient가 서로 충돌할 수 있고, local update가 자기 사용자에게 과적합될 수 있으며, global aggregation이 특정 참여 집단에 치우칠 수 있어요.

가능한 완화책은 다음과 같아요.

• personalization layer
• importance weighting
• adaptive aggregation
• clustered FL
• client diversity-aware scheduling

하지만 어떤 방법이 최적인지는 application context와 data fragmentation의 성격에 따라 달라요.

12.3 Distributed system observability

중앙 validation data가 없으면 local adaptation이 실제로 좋아지고 있는지 알기 어려워요. 특히 streaming adaptation에서는 작은 drift가 오래 누적되어 성능을 천천히 망칠 수 있어요.

예를 들어 음성 모델이 일시적인 배경 소음에 너무 적응하면, 나중에는 진짜 wake word를 놓치거나 false positive가 늘 수 있어요.

원문은 다음 방어를 제안해요.

12.4 Dynamic environment에서의 평가 지표

On-device learning은 inference benchmark만으로 평가할 수 없어요. 학습 자체의 효율을 봐야 해요.

즉 “빠른 예측”과 “좋은 적응”을 함께 측정해야 해요.

12.5 Resource management

Training은 사용자 작업과 같은 compute, memory bandwidth, energy, thermal headroom을 공유해요. 작은 parameter만 업데이트해도 backward pass는 관련 layer를 거쳐야 하므로 instruction과 memory traffic이 늘어요.

마이크로컨트롤러에서는 몇 초의 학습도 에너지 budget에 큰 영향을 줄 수 있어요. Energy harvesting device라면 지속 학습은 거의 불가능하고, 한 시간에 몇 초만 학습하는 duty cycling이 필요할 수 있어요.

또한 activation caching은 weight보다 더 큰 메모리를 요구할 수 있어요. 512 KB 이하 RAM 같은 환경에서는 adapter나 low-rank update조차 careful memory planning 없이는 어려울 수 있어요.

12.6 Failure modes

원문은 몇 가지 실패 유형을 강조해요.

12.7 Compliance, auditability, and auditable autonomy

의료, 금융, 안전 중요 시스템에서는 모델이 배포 후 스스로 변한다는 사실이 큰 규제 문제를 만들어요. 중앙 학습에서는 학습 데이터, checkpoint, metric을 기록해 추적할 수 있지만, 기기 내 학습에서는 각 기기가 고유한 경로로 변해요.

문제는 다음이에요.

• 어떤 local data가 모델 변화에 영향을 줬는지 알기 어려워요.
• 성능 보증 범위를 벗어났는지 중앙에서 즉시 알기 어려워요.
• GDPR의 삭제 권리처럼 특정 사용자 영향 제거가 복잡해져요.
• replay buffer나 local support set이 공격 대상이 될 수 있어요.
• adapted model이 잘못된 결정을 내렸을 때 책임 소재가 모호해질 수 있어요.

따라서 원문은 “auditable autonomy”가 필요하다고 설명해요. 즉 시스템이 현장에서 적응하더라도, 외부 요구사항인 추적 가능성, 재현성, 사용자 보호를 만족해야 한다는 뜻이에요.

12.8 Robust AI와 security foundation

On-device learning은 새로운 공격 표면을 만들어요. 악성 client가 federated update를 오염시킬 수 있고, hardware fault가 잘못된 gradient를 만들 수 있으며, local drift가 global alarm 없이 진행될 수 있어요.

Byzantine-resilient aggregation은 이런 문제를 줄이기 위한 분산 시스템 기법이에요. 일부 client가 악성이거나 고장났더라도 전체 aggregation이 망가지지 않게 해요. 다만 통신과 계산 overhead가 커질 수 있어요.

이 장의 결론은 분명해요. On-device learning은 privacy와 personalization을 위한 강력한 도구이지만, production-ready system이 되려면 robustness, security, privacy, MLOps가 선택 사항이 아니라 필수 구성요소예요.

13. Fallacies and Pitfalls

원문은 흔한 오해를 따로 정리해요.

오해 1. On-device learning은 cloud training과 같은 수준으로 적응할 수 있다

그렇지 않아요. 기기는 메모리, 계산, 에너지, 데이터 품질에서 훨씬 제약이 커요. 목표는 cloud-scale training을 흉내 내는 것이 아니라, 제한된 조건에서 의미 있는 local improvement를 얻는 거예요.

오해 2. Federated learning은 자동으로 개인정보를 보호한다

원본 데이터를 보내지 않는 것은 중요하지만 충분하지 않아요. Gradient와 update에서도 정보가 샐 수 있어요. Secure aggregation, differential privacy, clipping, noise, 참여 패턴 보호가 함께 필요해요.

오해 3. 로컬 적응은 항상 generic model보다 낫다

로컬 데이터가 너무 적거나 noisy하거나 bias가 강하면 적응이 오히려 성능을 떨어뜨릴 수 있어요. 좋은 시스템은 local adaptation이 도움이 되는지 판단하고, 필요하면 generic baseline으로 돌아가야 해요.

오해 4. 모든 기기를 비슷하게 보면 된다

edge device는 RAM, compute, 전력, 네트워크가 수천 배까지 차이 날 수 있어요. 한 기기에서 잘 되는 방법이 다른 기기에서는 실패할 수 있어요. tiered strategy와 graceful degradation이 필요해요.

오해 5. 개별 기기만 최적화하면 전체 시스템도 잘 된다

Federated learning과 on-device learning은 전체 orchestration 문제예요. 연결 끊김, version skew, partial participation, stale update, rollback, fairness, compliance까지 함께 관리해야 해요.

14. 3단계 최종 정리

On-device learning은 다음 네 문장으로 정리할 수 있어요.

1. 기기 안 학습은 personalization, privacy, latency, offline robustness를 가능하게 해요.
2. 하지만 training은 inference보다 메모리, 계산, 에너지를 크게 더 요구해요.
3. 그래서 bias-only, adapter, LoRA, sparse update, few-shot, replay, compression, federated learning 같은 절약형 기법을 조합해야 해요.
4. production에서는 기법 자체보다 device-aware deployment, privacy-preserving monitoring, rollback, distributed validation, compliance까지 포함한 시스템 설계가 성패를 결정해요.

복습 질문

1. On-device inference와 on-device learning은 어떤 점에서 다르며, 왜 learning이 더 어렵나요?
2. On-device learning이 personalization, latency, privacy, infrastructure efficiency에 어떻게 기여하나요?
3. Feature-based personalization이나 lookup table로 충분한 경우와 on-device learning이 필요한 경우를 어떻게 구분할 수 있나요?
4. Training이 inference보다 메모리와 계산을 더 많이 쓰는 이유를 forward pass, backward pass, optimizer state 관점에서 설명해 보세요.
5. Bias-only adaptation은 어떤 상황에 적합하고, 어떤 domain shift에는 부족할 수 있나요?
6. Residual adapter와 LoRA는 왜 frozen backbone 위에 작은 trainable component를 더하는 방식으로 이해할 수 있나요?
7. Sparse update에서 업데이트할 layer 집합 (\mathcal{S})를 잘못 고르면 어떤 문제가 생길까요?
8. Few-shot learning, streaming adaptation, experience replay, data compression은 각각 어떤 데이터 제약을 해결하나요?
9. Federated Averaging에서 local step 수 (E)를 크게 하면 어떤 장점과 위험이 생기나요?
10. Federated learning이 원본 데이터를 보내지 않더라도 개인정보 위험이 남는 이유는 무엇인가요?
11. Client scheduling이 fairness 문제를 만들 수 있는 이유를 예시로 설명해 보세요.
12. On-device learning production monitoring에서 shadow model과 confidence gate가 필요한 이유는 무엇인가요?
13. 기기 이질성이 model deployment, resource scheduling, federated aggregation에 어떤 영향을 주나요?
14. Local adaptation이 generic model보다 나빠질 수 있는 경우는 어떤 경우인가요?
15. “Auditable autonomy”가 on-device learning에서 중요한 이유를 규제, rollback, 책임 소재 관점에서 설명해 보세요.