커스텀 FM 배포와 모델 수명주기

이 시험은 모델 훈련을 범위 밖에 두지만, 훈련이 끝난 모델을 프로덕션에 올리고 갈아 끼우는 일은 skill 1.2.4로 범위 안에 둡니다. 이 노트는 그 경계의 안쪽입니다. 누군가 우리 도메인에 맞게 다듬어 둔 모델이 있다고 치고, 그것을 어디에 어떻게 띄우는지, 새 버전이 나오면 무엇을 거쳐 바꾸는지, 바꾸다 실패하면 어떻게 되돌리는지, 그리고 다 쓴 모델을 어떻게 내보내는지를 차례로 봅니다.

파인튜닝 모델 배포

SageMaker AI 엔드포인트

파인튜닝은 이미 학습된 FM을 우리 데이터로 조금 더 학습시켜 말투·형식·도메인 용어를 모델에 배게 하는 일입니다. 그렇게 만든 모델을 띄우는 자리가 SageMaker AI 엔드포인트입니다. 엔드포인트는 모델을 담은 인스턴스 앞에 붙는 호출 주소이고, 세 단계로 만듭니다 — 모델 산출물(S3의 가중치)과 추론 컨테이너를 묶어 모델을 등록하고, 인스턴스 종류와 수를 적은 엔드포인트 구성을 만들고, 그 구성으로 엔드포인트를 띄웁니다. 이 세 단계가 나뉘어 있는 것이 뒤의 배포·롤백에서 중요합니다. 새 버전을 올릴 때는 새 구성을 만들어 엔드포인트가 가리키는 구성만 바꾸기 때문입니다.

Bedrock과의 갈림

같은 파인튜닝 모델이 Bedrock으로 갈 수도 있습니다. Bedrock 안에서 지원 모델을 커스터마이즈하거나, 밖에서 다듬은 지원 아키텍처의 모델을 Custom Model Import로 들여와 Bedrock API로 부르는 길입니다. 가르는 질문은 「인프라를 직접 고르고 싶은가」입니다. 인스턴스 종류·오토스케일링·컨테이너를 정해야 하면 SageMaker AI, 서버를 신경 쓰지 않고 다른 Bedrock 모델과 같은 API로 부르고 싶으면 Bedrock입니다.

파라미터 효율적 적응

LoRA와 어댑터

모델 전체를 다시 학습하면 모델 크기만 한 사본이 버전마다 생깁니다. 파라미터 효율적 적응(PEFT)은 원래 가중치는 얼린 채 작은 추가 파라미터만 학습하는 기법 묶음이고, 그 대표가 LoRA입니다. LoRA는 크기가 $d \times k$ 인 가중치 행렬 $W$ 를 고치는 대신, 그 변화량을 작은 두 행렬의 곱으로 나타냅니다.

학습되는 것은 $B$ 와 $A$ 뿐이라 파라미터 수가 $d \cdot k$ 에서 $r(d + k)$ 로 줄어듭니다. 이렇게 학습된 작은 파라미터 묶음을 어댑터라고 부르고, 바탕 모델 하나에 어댑터를 바꿔 끼워 여러 업무에 씁니다.

어댑터 배포

배포에서 이 구조가 주는 이득은 바탕 모델을 한 번만 메모리에 올린다는 것입니다. SageMaker AI에서는 엔드포인트에 바탕 모델을 추론 구성 요소(inference component)로 올리고, 어댑터마다 그 위에 얹히는 구성 요소를 따로 만들 수 있습니다. 어댑터는 작아서 빠르게 붙이고 뗄 수 있고, 업무가 열 개라도 큰 모델 사본을 열 개 띄울 필요가 없습니다. 반대로 어댑터를 바탕 가중치에 미리 합쳐 하나의 모델로 내보내면 호출 경로는 단순해지지만 업무마다 전체 크기의 모델이 하나씩 생깁니다. 「업무별로 다른 동작이 필요하지만 GPU 비용을 줄여야 한다」는 서술에는 바탕 하나에 어댑터 여럿을 얹는 구성이 맞습니다.

Model Registry와 자동 배포

버전과 승인 상태

SageMaker Model Registry는 모델 버전의 장부입니다. 같은 용도의 모델은 모델 패키지 그룹 하나에 묶이고, 새로 등록할 때마다 버전 번호가 하나씩 붙습니다. 버전마다 승인 상태가 있어 PendingManualApproval(검토 대기)·Approved(승인)·Rejected(거부) 가운데 하나를 가집니다. 평가 지표와 학습 데이터 위치 같은 메타데이터도 버전에 함께 남아, 어떤 모델이 왜 승인됐는지를 나중에 되짚을 수 있습니다.

승인이 여는 파이프라인

자동 배포는 승인 상태의 변화에서 시작합니다. 검토자가 버전을 Approved로 바꾸면 Model Registry가 Amazon EventBridge로 상태 변경 이벤트를 내고, 규칙이 그 이벤트를 받아 배포 파이프라인(AWS CodePipeline이나 Step Functions)을 깨웁니다. 파이프라인은 스테이징 엔드포인트에 먼저 올려 평가 질문 묶음으로 회귀 테스트를 돌리고, 통과하면 프로덕션 엔드포인트를 갱신합니다.

import boto3

sm = boto3.client("sagemaker")
sm.update_model_package(
    ModelPackageArn="arn:aws:sagemaker:us-east-1:111122223333:model-package/support-llm/7",
    ModelApprovalStatus="Approved",
    ApprovalDescription="회귀 테스트 통과 — 사실 오류율 1.4%",
)

사람이 승인 단추를 누르는 지점을 남겨 두는 것이 이 설계의 요점입니다. 학습과 배포 사이에 검토의 문이 하나 있고, 그 문을 지난 버전만 자동으로 흘러갑니다.

롤백과 수명주기

배포 실패와 롤백

엔드포인트를 새 버전으로 바꿀 때 SageMaker AI는 블루/그린 방식을 씁니다. 지금 트래픽을 받는 옛 묶음(블루)을 둔 채 새 묶음(그린)을 띄우고 트래픽을 옮기는데, 옮기는 방식이 셋입니다 — 한 번에 모두, 카나리(일부만 먼저 옮겨 지켜본 뒤 나머지), 선형(정해 둔 간격으로 같은 몫씩). 옮기는 동안 지켜볼 CloudWatch 경보를 걸어 두면, 경보가 울리는 순간 트래픽이 블루로 돌아가는 것이 자동 롤백입니다.

sm.update_endpoint(
    EndpointName="support-llm",
    EndpointConfigName="support-llm-v7",
    DeploymentConfig={
        "BlueGreenUpdatePolicy": {
            "TrafficRoutingConfiguration": {
                "Type": "CANARY",
                "CanarySize": {"Type": "CAPACITY_PERCENT", "Value": 10},
                "WaitIntervalInSeconds": 600,
            },
            "TerminationWaitInSeconds": 300,
        },
        "AutoRollbackConfiguration": {
            "Alarms": [{"AlarmName": "support-llm-5xx"}, {"AlarmName": "support-llm-p95"}]
        },
    },
)

위 설정은 용량의 10%에 먼저 트래픽을 보내고 600초 동안 경보를 지켜본 뒤 나머지를 옮기며, 다 옮긴 뒤에도 300초 동안 블루를 지우지 않고 남겨 둡니다. 롤백할 곳이 바로 그 블루이므로, 이 대기 시간이 끝나기 전에 문제가 보이면 되돌릴 자리가 아직 살아 있습니다. Model Registry 쪽에서는 문제가 된 버전을 Rejected로 바꿔 파이프라인이 다시 집어 가지 않게 합니다.

퇴역과 교체

모든 모델은 언젠가 내려갑니다. 우리가 다듬은 모델은 더 나은 버전이 승인되면 옛 버전을 퇴역시킵니다 — 트래픽이 0이 된 것을 확인하고, 엔드포인트와 구성을 지우고, Model Registry에는 버전 기록을 남겨 감사 추적이 끊기지 않게 합니다. Bedrock의 공급자 모델에도 수명주기가 있습니다. 모델은 Active에서 Legacy를 거쳐 End-of-Life(EOL)에 이르고, EOL이 지나면 호출할 수 없습니다. 그래서 공급자 모델을 쓰는 애플리케이션은 Legacy 공지를 받는 순간 후속 모델을 평가 질문 묶음으로 검증하고, 앞 노트의 AppConfig 설정 전환으로 갈아 끼울 준비를 해 둡니다. 퇴역은 사건이 아니라 일정이라는 관점이 이 skill이 요구하는 것입니다.

연습 문제

1. 크기가 $4096 \times 4096$ 인 가중치 행렬 하나에 순위 $r = 8$ 인 LoRA를 붙입니다. 학습되는 파라미터 수와, 원래 행렬 대비 비율은?

   65,536개, 약 0.39%. $r(d + k) = 8 \times (4096 + 4096) = 65536$ 이고 원래 행렬은 $4096^2 = 16777216$ 개이므로 $65536 / 16777216 = 0.00390625$ 입니다.
2. 고객 응대·계약 요약·사내 검색 세 업무에 각각 다르게 다듬은 동작이 필요한데 GPU 비용을 최소로 하려 합니다. 가장 알맞은 배포는?
   ① 업무마다 전체 파인튜닝 모델을 하나씩 엔드포인트에 띄운다
   ② 바탕 모델 하나를 추론 구성 요소로 올리고 업무별 LoRA 어댑터를 얹는다
   ③ 어댑터를 바탕 가중치에 합쳐 업무마다 모델을 하나씩 만든다
   ④ 세 업무를 프롬프트 하나에 모두 적는다

   ②. 바탕 모델을 메모리에 한 번만 올리고 작은 어댑터만 바꿔 끼우므로 큰 모델 사본이 하나뿐입니다. ①③은 업무마다 전체 크기의 모델이 생깁니다.
3. 다음 가운데 Model Registry 승인을 계기로 자동 배포를 여는 구성에 들어가는 것을 둘 고르시오.
   ① 모델 버전의 승인 상태를 Approved로 바꾼다
   ② Amazon EventBridge 규칙이 상태 변경 이벤트를 받아 파이프라인을 시작한다
   ③ Bedrock Guardrails가 새 버전의 출력을 거른다
   ④ AWS AppConfig가 엔드포인트 인스턴스 수를 정한다
   ⑤ Amazon Kendra가 모델 버전을 색인한다

   ①과 ②. 승인 상태 변경이 이벤트가 되고, EventBridge 규칙이 그 이벤트로 배포 파이프라인을 깨웁니다.
4. 엔드포인트 용량이 인스턴스 20대이고 카나리 크기를 용량의 10%로 두었습니다. 대기 600초 동안 새 버전이 받는 인스턴스 몫과, 이 동안 경보가 울렸을 때의 동작은?
   ① 2대, 트래픽이 블루로 돌아간다
   ② 2대, 나머지 18대로 그대로 옮긴다
   ③ 10대, 트래픽이 블루로 돌아간다
   ④ 20대, 엔드포인트가 멈춘다

   ①. $20 \times 0.1 = 2$ 대이고, 자동 롤백 경보가 울리면 트래픽이 블루로 돌아갑니다.
5. Bedrock에서 쓰던 공급자 모델이 Legacy로 바뀌었다는 공지를 받았습니다. 가장 먼저 할 일로 알맞은 것은?
   ① EOL 날짜까지 기다렸다가 오류가 나면 바꾼다
   ② 후속 모델을 평가 질문 묶음으로 검증하고 설정 전환을 준비한다
   ③ 같은 모델을 SageMaker AI로 직접 학습한다
   ④ 교차 리전 추론으로 다른 리전의 같은 모델을 쓴다

   ②. Legacy는 EOL로 가는 단계이므로 그 전에 후속 모델을 검증해 두어야 합니다. ①은 장애를 기다리는 것이고, ④는 리전을 바꿔도 같은 모델의 수명주기는 그대로입니다.
6. 블루/그린 배포에서 트래픽을 다 옮긴 뒤 옛 묶음을 바로 지우지 않고 일정 시간 남겨 두는 까닭은?
   ① 비용을 줄이려고
   ② 문제가 늦게 드러났을 때 되돌릴 자리를 남기려고
   ③ 새 묶음의 인스턴스 수를 늘리려고
   ④ Model Registry의 버전 번호를 올리려고

   ②. 롤백은 트래픽을 블루로 되돌리는 것이라 블루가 살아 있어야 합니다. 남겨 두는 동안은 오히려 비용이 더 듭니다.