제6부 생성형 AI 플랫폼

6.4 NeMo III — SFT·PEFT(LoRA)

6.4.1 이 장에서 배우는 것 / 선수 지식

6.3에서 거대 모델 사전학습의 병렬화를 봤다. 그러나 6.1의 적응 스펙트럼이 말하듯, 대부분의 팀은 사전학습이 아니라 커스터마이즈를 한다 — 기성 모델을 자기 도메인·형식·행동에 맞추는 일. 이 장은 그 핵심 두 방법을 판다: SFT(지도 미세조정) — instruction-response로 모델 행동을 바꾸는 것 — 과 PEFT/LoRA — 전체 가중치 대신 소수 어댑터만 학습해 비용이 낮고 빠르게 적응하는 것.

핵심 통찰: LoRA는 "파인튜닝 중 가중치 변화가 저랭크(low-rank)"라는 관찰을 이용해, 거대 가중치를 동결하고 작은 두 행렬만 학습한다. 그 결과 옵티마이저 상태가 어댑터 크기로 줄어(6.3의 메모리 폭발 회피) 단일 GPU에서도 큰 모델을 적응시키고, 수 MB 크기의 어댑터를 여럿 만들어 교체하거나 동시에 서빙한다. 이것이 실무 커스터마이즈의 가성비 지점이다.

배우는 것:

• SFT — instruction-response 데이터 형식, 챗 템플릿(system/user/assistant), 손실 마스킹(응답 토큰에만 손실), 패킹(6.2).
• LoRA — 저랭크 분해 W + BA 원리, 왜 통하나, 하이퍼파라미터(rank·alpha·target modules).
• QLoRA·변형 — 양자화 베이스 + LoRA로 메모리 더 절감.
• 다중 어댑터 운영 — 작은 어댑터 여럿 저장·교체·동시 서빙(multi-LoRA), TRT-LLM/NIM 연결(5.9·6.7).
• SFT vs LoRA 트레이드오프 — 용량·메모리·데이터·여러 작업.
• 데이터 형식·LoRA config·학습·병합/서빙의 흐름(실습).

선수 지식: 6.1(적응 스펙트럼 — LoRA=스타일·SFT=능력), 6.2(데이터·패킹·토크나이저), 6.3(메모리·옵티마이저 상태), 5.9(다중 LoRA 서빙·양자화), 1.14(정밀도·QLoRA). 정렬(RLHF/DPO)은 6.5. 환경은 6.2.

정직: LoRA·SFT의 수학·원리는 안정적이지만, NeMo의 PEFT API·config 키·지원 변형(LoRA·DoRA·IA3 등)은 버전 의존이다. 이 장은 개념·형식·의사결정을 중심에 두고 코드는 한 형태를 예시 — 정확한 인자는 그 버전 문서로 확인. 수치는 환경 의존 개략값.

6.4.2 SFT — instruction으로 행동을 바꾼다

베이스(사전학습) 모델은 "다음 토큰 예측"만 안다. SFT는 instruction-response 쌍으로 학습해 모델이 지시를 따르고·특정 형식·어조로 답하게 만든다.

SFT 데이터(한 예시):

{
  "system": "너는 정중한 고객 지원 봇이다.",
  "user":   "환불 절차를 알려줘.",
  "assistant": "환불은 다음 절차로 진행됩니다: 1) ... 2) ..."
}

수천~수십만 개의 이런 예시로 학습 → 모델이 그 행동·형식을 습득한다.

챗 템플릿. 멀티턴·역할(system/user/assistant)을 모델이 구분하도록 특수 토큰·형식으로 감싼다:

<|system|>너는 정중한...<|end|>
<|user|>환불 절차를...<|end|>
<|assistant|>환불은 다음...<|end|>

템플릿은 모델·토크나이저에 맞춰야 한다(6.2 토크나이저 일관성). 학습·추론 템플릿 동일.

손실 마스킹(핵심). SFT는 응답(assistant) 토큰에만 손실을 계산하고 프롬프트(system/user) 토큰은 마스킹한다:

왜: 모델이 '사용자 입력을 생성하도록' 학습하면 안 됨. '응답을 생성'하도록만. 마스킹 누락 시: 모델이 프롬프트도 외워 비정상적인 행동·과적합.

패킹(6.2)은 SFT에서 특히 중요하다 — 짧은 예시가 많아 패딩 낭비가 크다. 패킹 + 경계 마스킹으로 효율을 높인다.

핵심: SFT의 세 불변식 — 챗 템플릿 일관성(학습=추론), 손실 마스킹(응답만), 토크나이저 일관성(6.2). 셋 중 하나라도 어기면 모델이 이상하게 행동한다. SFT는 전체 가중치를 학습(full fine-tune)하거나, LoRA로(6.4.3) 할 수 있다.

6.4.3 LoRA — 저랭크 어댑터

전체 SFT는 모든 가중치를 학습해 메모리·데이터가 크다(6.3). LoRA(Low-Rank Adaptation) 는 베이스 가중치를 동결하고, 각 가중치 행렬에 저랭크 보정만 더해 그것만 학습한다.

왜 통하나. 파인튜닝 중 일어나는 가중치 변화(ΔW)는 본질적으로 저랭크라는 관찰 — 적은 방향으로 충분히 적응된다. 그래서 r=8~64 같은 작은 랭크로도 full fine-tune에 근접한다(작업·데이터 의존).

메모리 이점(6.3과 연결):

옵티마이저 상태 폭발(6.3)을 회피 → 단일 GPU에서도 큰 모델 적응 가능.

하이퍼파라미터:

6.4.4 QLoRA·변형 — 메모리 더 줄이기

QLoRA: 베이스 모델을 양자화(예: 4비트, 5.4~5.5) 해 동결하고, 그 위에 LoRA 어댑터(고정밀)를 학습한다.

다른 변형(가용성 버전 의존): DoRA(크기·방향 분해로 LoRA 개선), IA3(스케일 벡터만) 등. 핵심은 같다 — 소수 파라미터만 학습.

견해: 메모리가 부족하면 QLoRA(4비트 베이스 + LoRA)로 단일 GPU에서도 큰 모델을 적응한다. 품질이 최우선이고 메모리 여유가 있으면 일반 LoRA(BF16 베이스). 둘 다 full SFT보다 1~2자릿수 비용이 낮다.

6.4.5 다중 어댑터 — 여럿 만들고 동시에 서빙

LoRA 어댑터는 수 MB(전체 모델은 수십 GB)라, 작업마다 어댑터를 따로 만들어 운영하는 것이 강력하다.

작업에 맞는 어댑터를 '교체'(베이스는 공유, 재배포 불필요). 더 나아가: 한 서버가 '여러 어댑터를 동시에' 서빙한다(multi-LoRA, 5.9·6.7) — 요청마다 다른 어댑터를 적용해 한 베이스로 여러 맞춤 모델 제공.

운영 이점:

• 저장·배포: 어댑터가 작아 수십 개를 두고 교체. 베이스는 한 벌.
• multi-LoRA 서빙: TRT-LLM/NIM이 여러 어댑터를 동시에 적재해 요청마다 다른 어댑터 적용(5.9) → 한 GPU로 여러 맞춤 모델. 베이스 가중치·KV는 공유.
• 병합(merge) 옵션: 어댑터를 베이스에 병합(W ← W + (alpha/r)·BA — 순전파와 같은 스케일을 반드시 포함)해 단일 모델로 만들 수도 있다(교체 불가·오버헤드 0). 다중 어댑터를 쓸 거면 병합하지 않고 분리 유지.

견해: 여러 작업·테넌트를 한 베이스로 서비스하면 LoRA 다중 어댑터가 매우 효율적이다(메모리·운영). 단일 고정 작업이면 병합해 오버헤드를 없애도 된다. multi-LoRA 서빙은 SaaS·멀티테넌트 LLM의 핵심 패턴.

6.4.6 워크스루 — SFT/LoRA 흐름

데이터 형식 → LoRA config → 학습 → 서빙(개념, 인자 버전 의존).

# sft_data.jsonl — 한 줄에 한 예시(형식은 레시피 의존)
{"system":"...","conversations":[{"role":"user","content":"..."},{"role":"assistant","content":"..."}]}

# LoRA config(개념) — full SFT 대비 peft 섹션만 추가
model:
  restore_from_path: base_model.nemo     # 기성 베이스
  peft:
    peft_scheme: lora                    # lora / dora / none(=full SFT)
    lora_tuning:
      adapter_dim: 16                    # rank r
      alpha: 32                          # 스케일
      target_modules: [attention_qkv, attention_dense, mlp]   # 어느 가중치에
      adapter_dropout: 0.05
  data:
    train_ds: { file_names: [sft_data.jsonl], ... }
    # 손실 마스킹·챗 템플릿은 데이터 처리에서(응답에만 손실)
  optim: { lr: 1e-4 }                    # full SFT보다 보통 높은 LR 가능(어댑터만)

# 학습(스크립트·런처 버전 의존). 단일/소수 GPU로도 가능(LoRA 메모리 이점)
python megatron_gpt_finetuning.py --config-path ... --config-name lora_config
# 산출: 작은 어댑터 체크포인트(수 MB)

# 서빙: 어댑터를 TRT-LLM/NIM에 적용(multi-LoRA, 5.9·6.7) 또는 베이스에 병합

평가(잊지 말 것). 적응 후 반드시 평가: 목표 작업 지표 + 회귀(원래 능력이 망가지지 않았나, catastrophic forgetting). LoRA는 베이스를 동결해 망각이 덜하지만, SFT는 과적합·망각 위험이 더 크다 — 검증셋·일반 벤치로 확인.

6.4.7 중간 점검 (체크포인트)

• [ ] SFT의 데이터 형식(instruction-response·챗 템플릿)과 손실 마스킹(응답에만)·패킹의 필요를 안다.
• [ ] LoRA의 W + BA 저랭크 원리, 왜 통하나(ΔW 저랭크), 메모리 이점(옵티마이저 상태 회피, 6.3)을 설명한다.
• [ ] LoRA 하이퍼파라미터(rank·alpha·target modules)의 역할을 안다.
• [ ] QLoRA가 양자화 베이스로 메모리를 더 줄임을 안다.
• [ ] 다중 어댑터(교체·multi-LoRA 동시 서빙·병합)의 운영 이점을 설명한다.
• [ ] SFT vs LoRA를 용량·메모리·데이터·여러 작업으로 선택하고, 평가·망각 점검을 한다.

증상→의심: SFT 후 모델이 프롬프트도 생성·이상 → 손실 마스킹 누락(응답만 학습해야) → 마스킹 확인. 추론 출력 형식 깨짐 → 챗 템플릿 학습≠추론 불일치 → 동일 템플릿. LoRA 용량 부족(적응 약함) → rank·target modules↑. LoRA 과적합 → rank↓·dropout·데이터↑. 메모리 OOM(LoRA여도) → 베이스가 큼 → QLoRA(4비트 베이스). 적응 후 원래 능력 저하 → catastrophic forgetting → LoRA(동결)·데이터 혼합·평가. 여러 작업 배포 번거로움 → 다중 어댑터·multi-LoRA(5.9).

6.4.8 트레이드오프·대안

커스터마이즈 방법 선택(적응 스펙트럼 6.1의 중간).

견해: LoRA가 커스터마이즈의 기본 출발점이다 — 비용이 낮고, 빠르고, 여러 어댑터를 운영하며, 망각이 덜하다. 스타일·형식·도메인 어조 적응은 대부분 LoRA로 충분. full SFT는 LoRA로 부족한 깊은 행동·능력 변화에만(데이터·메모리 감당될 때). 그리고 지식은 LoRA가 아니라 RAG로(6.1 반복). 메모리가 부족하면 QLoRA. 어느 쪽이든 평가·망각 점검 필수.

비엔비디아 정직: LoRA·QLoRA·SFT는 공개 연구·표준 기법으로 HF PEFT·기타 프레임워크도 제공한다(6.1 도구 중립). NeMo의 강점은 대규모 병렬(6.3)·multi-LoRA 서빙(TRT-LLM/NIM)·엔비디아 스택 통합이다. 중소 규모 LoRA는 HF PEFT가 매우 간편 — 규모·기존 스택으로 선택.

6.4.9 흔한 함정

• 손실 마스킹 누락. SFT에서 프롬프트에도 손실을 주면 모델이 사용자 입력을 생성하도록 학습 → 이상 행동·과적합. 응답 토큰에만 손실.
• 챗 템플릿 불일치. 학습 템플릿과 추론 템플릿(특수 토큰·형식)이 다르면 출력이 깨짐. 동일 템플릿·토크나이저(6.2).
• 지식을 LoRA/SFT로. 최신·사실 지식은 RAG로(6.1). 파인튜닝은 지식을 굳히고 환각을 안 준다.
• LoRA rank를 맹목적으로 키움. rank↑가 항상 좋은 것이 아니다 — 용량·크기↑, 과적합 위험. 작업·데이터로 8~64 탐색.
• target modules 부족. attention만 LoRA하면 용량 부족할 수 있다 — MLP 포함 등 조정. 너무 많으면 어댑터 커짐.
• 평가·망각 점검 생략. 적응 후 목표 지표 + 원래 능력(일반 벤치)을 봐야 catastrophic forgetting을 검출한다.
• 다중 어댑터인데 병합. 여러 작업을 쓸 거면 병합하면 교체 불가 — 분리 유지(multi-LoRA). 단일 고정이면 병합 OK.
• QLoRA 품질 미검증. 4비트 베이스는 약간의 품질 영향 가능 — 태스크 지표로 확인.

6.4.10 연습문제

연습 1 (손실 마스킹). SFT에서 손실 마스킹이 무엇이고 왜 필요한지, 마스킹을 빼면 어떤 일이 생기는지 설명하라.

연습 2 (LoRA 원리). LoRA가 W + BA로 소수 파라미터만 학습하는 구조를 설명하고, (a) 왜 메모리(특히 옵티마이저 상태)가 급감하나, (b) 왜 저랭크로 충분한가?

연습 3 (방법 선택). 다음에 LoRA·QLoRA·full SFT 중 무엇을 권하나: (a) 8-GPU로 13B 모델에 회사 어조 적응, (b) 단일 24GB 소비자 GPU로 큰 모델 파인튜닝, (c) LoRA로 시도했으나 깊은 도메인 추론이 안 늘어남.

연습 4 (다중 어댑터). 한 베이스 모델로 고객지원·코드·요약 세 작업을 서비스한다. (a) LoRA 다중 어댑터의 운영 이점, (b) multi-LoRA 서빙이 무엇인지, (c) 언제 병합하나?

연습 5 (평가·망각). 코드 LoRA를 학습했더니 코딩은 늘었는데 일반 대화가 어색해졌다. (a) 무슨 현상이고, (b) LoRA가 full SFT보다 이것이 덜한 이유, (c) 진단·완화책은?

6.4.11 요약 · 다음 장

• SFT는 instruction-response로 모델 행동을 바꾼다 — 챗 템플릿 일관성·손실 마스킹(응답에만)·토크나이저 일관성의 세 불변식과 패킹(6.2)이 핵심.
• LoRA는 베이스를 동결하고 저랭크 보정 W + BA만 학습한다(ΔW가 저랭크라 통함) → 옵티마이저 상태 폭발 회피(6.3)로 비용이 낮고 빠르며 단일 GPU도 가능. 하이퍼파라미터는 rank·alpha·target modules.
• QLoRA(4비트 베이스 + LoRA)는 메모리를 더 줄인다. 다중 어댑터는 작업마다 수 MB 어댑터를 두고 교체·동시 서빙(multi-LoRA)·병합한다.
• LoRA가 커스터마이즈의 기본, full SFT는 깊은 능력 변화에만, 지식은 RAG로(6.1). 어느 쪽이든 목표+회귀(망각) 평가 필수.
• 정직: LoRA·QLoRA는 공개 표준 기법(HF PEFT도), config·변형은 버전 의존, 모든 적응은 평가와 함께.

다음 장: 6.5 NeMo IV — 정렬(RLHF·DPO). SFT로 instruction을 따르게 했으니, 이제 사람 선호·정책에 맞게 정렬한다. 보상 모델·RLHF의 구조, 더 단순한 DPO(선호 쌍 직접 최적화), 그리고 정렬이 유용성·안전성·형식을 어떻게 다듬는지를 실습으로 본다. 이로써 NeMo 학습 묶음(6.2~6.5)을 마무리한다.