이 문서에서는 LLM 기반 워크로드를 한 기본 모델에서 다른 모델로 마이그레이션하기 위한 6단계 프로세스를 설명합니다. 각 단계에서 고려해야 할 사항, Microsoft Foundry 기능이 적용되는 작업 및 다양한 종류의 팀에 대해 작업이 어떻게 변경되는지에 대해 설명합니다.
모델 마이그레이션의 의미
프로덕션에서 실행하는 모든 모델에는 사용 중지 날짜가 있습니다. 사용하는 모델이 교체되거나 최신 모델이 워크로드에 더 나은 서비스를 제공할 때 마이그레이션합니다. 모델을 바꾸는 것은 한 줄만 고치면 되는 변경이 아닙니다. 모델이 달라지면 톤, 서식, JSON 구조, 지연 시간, 비용, 도구 호출 방식이 눈에 띄지 않게 바뀔 수 있고, 그 결과 이전 동작에 의존하는 다운스트림 코드가 망가질 수 있습니다.
성공적인 마이그레이션은 애플리케이션의 동작을 유지하거나 측정 가능한 방식으로 개선합니다. 성공하려면 광범위한 출시 전에 드리프트를 감지하고, 안전하게 적응하고, 품질을 증명하는 반복 가능한 프로세스가 필요합니다.
마이그레이션 시기
마이그레이션은 일반적으로 네 가지 이유 중 하나로 시작됩니다.
- 모델이 지원 종료될 예정입니다. Foundry에서 일반적으로 사용 가능한 모든 모델은 사용 중지 날짜와 함께 제공되며, 노인 가족은 시간이 지남에 따라 대체됩니다. 사용 중지 정책 및 날짜는 Foundry 모델 수명 주기 및 지원 정책 및 모델 사용 중지 일정을 참조하세요.
- 더 나은 모델을 사용할 수 있습니다. 최신 모델은 워크로드에 필요한 더 높은 품질, 낮은 비용, 더 나은 대기 시간 또는 기능(예: 구조화된 출력 또는 향상된 도구 호출)을 제공합니다.
- 비용 또는 대기 시간 문제로 인해 변경이 발생합니다. 현재 모델의 대기 시간 또는 단위 비용이 더 이상 요구 사항을 충족하지 않습니다.
- 역량 격차가 제품 개발을 가로막고 있습니다. 현재 모델은 제품에 필요한 작업을 수행할 수 없습니다.
사용 중지 날짜에 어떤 일이 발생하나요
모델 사용 중지 시 Azure 수행하는 일은 용량을 구매하는 방법에 따라 다르며 Foundry는 각 경로에 대해 서로 다른 용어를 사용합니다.
-
표준, 글로벌 표준 및 데이터 영역 표준(종량제) 배포는 지역별 롤링 일정에 따라 자동으로 업그레이드 됩니다.
versionUpgradeOption을(를) 다음 중 하나로 설정하여 타이밍을 제어할 수 있습니다:OnceNewDefaultVersionAvailable,OnceCurrentVersionExpired또는NoAutoUpgrade(이는 사용 중지 시점에 배포가 작동을 중지함을 의미). 우선 순위 처리는 동일한 경로를 따릅니다. - 프로비저닝된 (PTU) 배포는 자동으로 업그레이드되지 않습니다. 직접, 현재 위치(가동 중단 없이 20~30분에 걸쳐 트래픽이 전환됨) 또는 병행(새 배포를 구축하고, 테스트한 다음, 트래픽을 전환하고, 기존 배포를 삭제) 방식으로 마이그레이션합니다.
- 일괄 배포 는 새 모델을 배포하고, 작업을 다시 제출하고, 이전 배포를 사용 중지하는 병렬 경로를 따릅니다.
어떤 경로가 적용되든 개발자 챌린지는 동일합니다. 설정된 날짜에 트래픽이 다른 모델에 도달하기 시작합니다. 여전히 응답하는 엔드포인트가 앱이 여전히 올바르게 동작한다는 의미는 아니므로 자동 업그레이드 및 수동으로 마이그레이션된 워크로드 모두 이 문서에서 설명하는 평가 및 유효성 검사의 이점을 누릴 수 있습니다.
사용 중지일 전에 마이그레이션하세요
자동 업그레이드는 마이그레이션 계획이 아니라 종량제 배포에 대한 안전망일 뿐입니다. 프로비저닝된 배포에는 보호 장치가 없습니다. 어느 쪽이든 마이그레이션 계획을 대체하는 것은 아닙니다. 두 가지 정책 약정을 통해 최종 기한을 기다리지 않고 자신의 일정에 따라 마이그레이션할 수 있습니다.
- 교체 모델은 Global Standard에서 사용 중지되기 약 90일 전과 이전 버전이 사용 중지되는 프로비전된 지역에서 사용 중지되기 약 30일 전에 사용할 수 있게 됩니다. 이 창을 사용하여 새 모델을 평가하고 수동으로 마이그레이션합니다.
- 사용 중지 날짜는 연장할 수 없습니다. 예외 프로세스는 없으므로 계획하지 않은 날짜는 계속 적용됩니다.
시작하는 데 지원 중단 공지가 필요하지 않습니다. 최신 모델이 더 저렴하거나, 더 빠르거나, 더 능력 있는 경우 지금 프로세스를 통해 실행합니다. 계획적으로 마이그레이션하면 서비스 종료일은 형식적인 절차에 불과해집니다. 마이그레이션이 되풀이되기 때문에 프로세스를 반복할 수 있도록 하는 것이 좋습니다.
마이그레이션 프로세스를 사용해야 하는 사용자
마이그레이션 프로세스는 팀이 더 큰 제품 또는 플랫폼 내에서 LLM 기반 기능을 빌드하고, 대략 분기별 주기로 마이그레이션하며, 각 마이그레이션을 의도적으로 실행하는 명확한 소유자(예: 중앙 플랫폼 팀 또는 앱 팀)가 있는 경우에 가장 적합합니다.
이 프로세스는 모델이 제품인 AI 네이티브 팀에도 적합합니다. 단계는 동일하지만 엄격한 시퀀스가 아닌 병렬로 더 빠르고 자주 실행됩니다.
이 프로세스에서는 기본 모델, 즉 모델 카탈로그에 게시된 대로 가중치 수준 사용자 지정 없이 배포하는 모델 간에 이동하는 것으로 가정합니다. 미세 조정된 워크로드는 범위에 포함되지 않습니다. 자체 학습 및 배포 사용 중지 시계를 가지고 있기 때문에 자동 업그레이드할 수 없습니다. 미세 조정된 워크로드를 조정한다는 것은 프롬프트 및 스키마 변경보다는 증류 또는 다시 학습을 의미합니다. 미세 조정된 배포를 실행하는 경우 교체 기본 모델에 대해 조기에 다시 조정하도록 계획합니다.
마이그레이션 단계
마이그레이션은 6단계로 이동합니다. 각 단계에서는 다음 단계에서 사용하는 출력을 생성합니다. 마이그레이션 단계는 다음과 같습니다.
발견 → 평가 → 조정 → 검증 → 배포 → 폐기
다음 표에서는 각 단계와 이를 지원하는 Foundry 기능 및 도구에 대해 설명합니다. Foundry로만 표시된 경우가 아니면 Microsoft Foundry와 Azure OpenAI 모두에서 기능을 사용할 수 있습니다. 즉, Azure OpenAI에 해당하는 기능이 없습니다.
이 문서의 뒷부분에 나오는 단계별 섹션에서는 각 단계가 존재하는 이유, 성공적인 결과, 고려해야 할 사항, 각 기능을 사용해야 하는 경우 및 단계가 일반적으로 중단되는 위치를 설명합니다.
| Phase | Description | 기능 및 도구 |
|---|---|---|
| Discover | 모델 변경이 오고 있거나 필요한지 알아보고 작업 여부를 결정합니다. |
|
| 평가 | 대상 모델을 선택하고 작동 가능한지 확인합니다. |
|
| 적응 | 새 모델에서 현재 워크로드를 재생하고, 동작 변경을 진단하고, 프롬프트, 매개 변수, 도구 정의, 출력 스키마 및 주변의 호출 코드를 다시 엔지니어링합니다. |
|
| 유효성 검사 | 품질 루브릭에 맞게 조정된 워크로드를 채점하여 배송이 안전한지 여부를 결정합니다. |
|
| 롤아웃 | 단계적 노출을 통해 프로덕션에 배포하고, 실제 동작을 모니터링한 뒤 적용을 확정하거나 롤백합니다. |
|
| 중지 | 기존 배포를 중단하고, 용량을 확보하고, eval을 보관하고, 다운스트림 문서를 업데이트하세요. |
|
마이그레이션하기 전에: 테스트 데이터 세트 준비
이 준비 단계에서는 마이그레이션 작업이 시작되기 전에 대표 입력, 예상 출력 및 합의된 성공 조건 집합을 조합합니다. 이 세트는 프로세스 중간 단계에서 반드시 필요한 선행 조건입니다. 입력이 없으면 Adapt 단계에서 다시 실행할 수 없고, 정답 데이터와 평가 기준이 없으면 Validate 단계에서 점수를 산정할 수 없습니다.
고려해야 할 사항
- 대상을 선택하기 전에 데이터 세트를 빌드합니다. 데이터 세트는 후보 모델이 아닌 워크로드를 설명하므로 Discover와 병렬로 어셈블할 수 있습니다.
- 실제 또는 가상 소스에서 입력을 수집합니다. 캡처된 프로덕션 트래픽 또는 큐레이팅된 도메인 예제를 CSV 또는 JSONL로 사용합니다. 대표 데이터가 아직 없으면 시뮬레이터를 사용하여 가상 및 적대적 입력을 생성합니다.
- 필요하기 전에 계측을 캡처하십시오. 프로덕션 콘텐츠 캡처는 옵트인이며 소급되지 않으므로 기록하지 않은 트래픽을 평가할 수 없습니다. 이제 로깅 프롬프트, 응답, 대기 시간 및 토큰 수를 시작합니다.
- 데이터 세트를 고정합니다. 마이그레이션 전 과정에서 입력, 정답 데이터, 성공 기준을 고정해 두세요. 변경된 항목이 있으면 더 이상 원본 결과와 대상 결과를 비교할 수 없습니다.
또한 배포 유형(표준, 프로비저닝 또는 Batch)을 포함하여 워크로드에서 사용하는 모델 배포의 인벤토리가 필요합니다. 각 원본 모델에 대해 사용 중지 날짜와 모델 사용 중지 일정에서 대체를 제안합니다.
1단계: 검색
검색 단계의 목적은 모델 변경이 오고 있거나 가치가 있음을 인식하고 작동 여부를 결정하는 것입니다. 출력은 go/no-go 결정이며 현재 모델을 유지하는 것이 유효한 선택입니다. 성공적인 결과는 사용 중단 날짜, 교체 모델 및 마이그레이션 기간을 제공하거나 현재 모델을 유지하기 위한 의도적인 결정을 제공하는 초기 구조화된 신호입니다.
고려해야 할 사항
- 은퇴 날짜는 무엇이며 실제로 얼마나 많은 활주로가 있습니까? 지원 종료일에서 검증 및 배포에 걸리는 시간을 뺀 시점을 실제 마감일로 간주하세요.
- 명명된 추천 교체가 있습니까, 아니면 후보자를 직접 후보명단에 추가해야 합니까?
- 변경 내용이 규정 준수 또는 지역 제약 조건을 수반하나요(규제된 워크로드, 가용성 및 인증의 경우 품질이 중요하기 전에 종종 중요)?
일반적으로 중단되는 위치
각 팀은 이메일, 포털 배너 또는 내부 메시지 등 제각각의 경로를 통해 사용 중지 사실을 알게 되며, 그 신호도 뒤늦게 알아차립니다. 그 지연으로 이미 빠듯한 시간적 여유가 더 줄어듭니다. 솔로 개발자와 소규모 팀은 종종 발표가 아닌 프로덕션 오류에서 은퇴를 발견합니다.
가져온 내용
사용 중지 일정 및 모델 API는 안정적인 계약에 데이터를 노출합니다. 성숙한 조직은 얇은 내부 알림 계층을 맨 위에 추가하여 올바른 소유자에게 라우팅합니다.
2단계: 평가
평가 단계의 목적은 후보 대상 모델을 선택하고 실행할 수 있는지 확인하는 것입니다. 즉, 롤백이 가능하도록 올바른 지역, 올바른 배포 유형, 충분한 할당량 및 가용성을 현재 모델과 함께 제공합니다. 성공적인 결과는 튜닝이 시작되기 전에 지역, SKU, 할당량 및 비용이 확인되는 후보 모델 중에서 명확한 선택입니다.
고려해야 할 사항
- 후보자 간 품질 및 포지셔닝. 여러 모델을 동시에 검토 중일 때는 공개 벤치마크에서 가장 높은 점수를 받은 모델만 볼 것이 아니라, 품질을 기준으로 자신의 워크로드에 맞는 모델을 판단하세요.
- 자체 트래픽 비용 가격 책정 구조는 모델 세대 간에 이동합니다. 추론 토큰, 캐시된 입력 및 구조적 출력 오버헤드는 단위 경제성을 2배 이상 높일 수 있으므로 정가가 아닌 기록 트래픽에 대한 월별 비용을 예상할 수 있습니다.
- 운영 가용성. 지역, SKU 및 할당량을 확인하고 대상을 원본과 나란히 실행하여 롤백 경로를 유지할 수 있는지 확인합니다.
- 규정 준수 확인 규제된 워크로드의 경우 품질이 대화에 들어가기 전에 인증 및 지역 가용성이 후보 목록을 필터링할 수 있습니다.
일반적으로 중단되는 위치
여러 후보의 포지셔닝이 불분명할 때 선택 마비가 나타납니다. Teams는 선택한 모델을 해당 지역 또는 SKU에서 사용할 수 없다는 중간 계획만 발견합니다. 또는 비용 예측에 따르면 새 모델은 실제 트래픽에서 실질적으로 더 비싸다는 것을 알 수 있습니다.
가져온 내용
벤치마크는 공용 데이터 세트에 대해 계산되므로 순위표를 결승선이 아닌 필터로 처리하고 자신의 워크로드에 대한 후보 명단을 확인합니다. 비용 예측은 동일한 내용입니다. 월별 보기는 트래픽 데이터가 있으면 간단하게 고유한 토큰 로그에서 제공됩니다.
3단계: 적응
적응 단계의 목적은 워크로드가 새 모델에서 제대로 작동하도록 하는 것입니다. 기존 워크로드를 변경되지 않은 상태로 재생하고(모델 기반 동작 변경을 격리하기 위해) 변경된 내용을 진단한 다음 반복적으로 다시 엔지니어링합니다. 성공적인 결과는 모든 변경 내용이 추적되는 실제 또는 대표 트래픽에 대한 병렬 동작 비교입니다.
적응은 프롬프트 편집 그 이상입니다.
프롬프트가 가장 눈에 띄는 표면이지만 마이그레이션은 일반적으로 다음 네 가지 다른 항목에 영향을 줍니다.
-
매개변수.
temperature,top_p,max_tokens및 추론 노력 제어 기능은 세대 간에 일대일로 대응되지 않으며, 최신 모델 계열은 일부 매개변수를 지원하지 않을 수 있습니다. - 도구 정의. 이전 모델을 안정적으로 안내하는 인수 이름, 설명 및 필수 필드를 다시 입력하거나 강화해야 할 수 있습니다.
- 출력 스키마. 모델은 구조화된 출력을 준수하는 방식이 다릅니다. 이전 모델이 느슨하게 충족하는 스키마에 명시적 제약 조건을 추가해야 하거나 마지막으로 스키마를 적용할 수 있습니다.
- 통화 코드. API 표면 및 SDK 차이점(채팅 완료와 응답, 스트리밍 셰이프 및 신규 또는 이름이 바뀐 요청 필드). 이전 응답 셰이프를 가정한 다운스트림 구문 분석을 업데이트해야 할 수도 있습니다.
에이전트 및 워크플로 워크로드의 경우 스키마 및 도구 호출 작업이 프롬프트 작업보다 중요한 경우가 많습니다.
고려해야 할 사항
- 튜닝하기 전에 원래 상태로 다시 재생합니다. 변경 없이 대상 모델에서 현재 구성을 실행합니다. 이 방법은 모델이도입한 변경 내용과 변경된 동작을 구분하는 데 도움이 되며 기준선을 제공합니다.
- 실제로 어떤 변화가 일어나는지 보세요. 장황함, 추론 깊이, 구조화된 출력 준수, 도구 호출 형식, 거부 방식, 그리고 지연 시간 편차는 모두 흔히 달라집니다.
- 실제 트레이스를 재생해 도구 호출 회귀 문제를 포착합니다. 추가 필드, 이름이 바뀐 인수 및 변경된 시퀀싱 표면은 실제 추적에서만 나타나며, 단일 턴 벤치마크에서는 나타나지 않습니다.
- 변경 내용을 추적합니다. 프롬프트 재설계는 하기 쉽지만 잃기 쉽습니다. 원본을 유지하고 변경된 내용과 이유를 기록합니다.
Foundry 기능
세 가지 Foundry 기능은 다음 단계를 지원합니다.
- 프롬프트 최적화 프로그램은 에이전트 플레이그라운드의 시스템 지침 필드 바로 아래에 있는 최적화 단추입니다. 프롬프트 엔지니어링 모범 사례를 사용하여 지침을 재구성하고, 각 변경에 대한 단락별 추론을 표시하며, 반복 루프를 지원합니다. "JSON 스키마를 정확하게 유지" 와 같은 제안을 추가하고 다시 최적화합니다. Foundry에서만 사용할 수 있으며, Azure OpenAI에서는 사용할 수 없습니다.
- 에이전트 최적화 는 에이전트 워크로드에 대한 지침, 도구 및 모델 선택을 함께 조정합니다. Foundry에서만 사용할 수 있으며, Azure OpenAI에서는 사용할 수 없습니다.
- 시뮬레이터 는 재생할 프로덕션 데이터가 없는 경우 가상 및 적대적 입력을 생성합니다.
일반적으로 중단되는 위치
포함된 제품 관련 워크로드의 경우 진단 루프가 수동이므로 이 단계는 일반적으로 가장 많은 시간이 걸립니다. 팀이 프롬프트를 다시 실행하고, 차이점을 비교하고, 변경된 내용이나 이유를 거의 기록하지 않습니다.
가져온 내용
- 최적화 프로그램에서 시작한 다음 확인합니다. 데이터 세트에 맞추지 않고 단일 패스에 일반적인 모범 사례를 적용하고 도구 정의 또는 출력 스키마 대신 명령 텍스트를 튜닝합니다. 출력을 강력한 초안으로 처리합니다. 먼저 원래 프롬프트를 복사한 다음(버전 기록이 없음) 변경 내용을 신뢰하기 전에 고정된 데이터 세트에 대해 다시 평가합니다.
- 가족 간 이동을 위한 추가 실습 작업을 계획합니다. "대상 모델 X에 최적화" 흐름이 없으므로 모델 패밀리 간에 이동하는 데는 의도적인 프롬프트 및 스키마 변환이 포함됩니다.
- 필요하기 전에 트래픽을 기록합니다. 리플레이의 품질은 캡처 품질에 달려 있으며, 콘텐츠 캡처는 명시적으로 선택해야 하고 소급 적용되지 않습니다.
4단계: 유효성 검사
유효성 검사 단계의 목적은 조정된 워크로드가 큐레이팅된 데이터 세트의 품질 루브릭에 대해 점수를 매기어 배송하기에 안전한지 여부를 결정하는 것입니다. 루브릭은 규칙 기반, 참조 기반, LLM-as-judge, 사용자 검토 또는 도메인별 프레임워크일 수 있습니다. 성공적인 결과는 앱 팀과 검토자가 모두 믿는 고정된 데이터 세트에서 실행되는 신뢰할 수 있는 평가 제품군을 제공하는 것입니다.
유효성 검사는 한 단계이지만 두 개의 터치포인트가 있으므로 단일 줄 끝 이벤트로 처리하지 마세요.
- 일찍 준비합니다. 마이그레이션하기 전, 적응하기 전에 데이터 세트 및 성공 조건을 고정합니다. 이러한 변경이 이루어지는 순간 원본 및 대상은 비교할 수 없습니다.
- 늦게 게이트를 통과했고, 두 번에 나눠 통과했습니다. 먼저 고정된 세트에서 현재 모델을 실행해 소스 기준선, 즉 넘어야 할 수치를 설정합니다. 그런 다음 동일한 집합에서 대상 을 채점하고 결정합니다.
고려해야 할 사항
- 데이터 세트와 조건을 고정된 상태로 유지합니다. 이는 결과를 비교 가능한 상태로 유지하기 위한 프로세스에서 가장 중요한 단일 분야입니다.
- 승인과 직결되는 세 가지 차원을 측정하세요: 품질(평가자 또는 검토자 점수), 대기 시간(첫 번째 토큰이 생성되기까지의 시간과 처리량으로, 현재 마이그레이션 중인 호출만 기준으로 측정), 비용(요청당 입력 토큰 비용과 출력 토큰 비용).
- 루브릭을 워크로드와 일치합니다. 임상 요약 루브릭, 에이전트에 대한 도구 호출 시퀀싱 어설션 또는 기존 사용자 피드백 신호는 일반 점수보다 더 의미가 있을 수 있습니다.
- 게이트를 AI 네이티브 팀을 위한 신호로 간주하세요. 일회성 통과/실패가 아니라 모든 커밋에서 평가가 지속적으로 실행되고 롤아웃과 융합됩니다.
Foundry 기능
두 개의 Foundry 기능은 다음 단계를 지원합니다.
- Azure AI 평가 SDK에는 30개 이상의 기본 제공 평가기가 포함되어 있으며, 접지성, 관련성, 검색, 일관성, 유창성, 참조 기반 메트릭(F1, BLEU 및 ROUGE), 안전성, 에이전트 및 Azure OpenAI 채점자를 포함합니다. 또한 작업별 루브릭용으로 사용자 지정된 심판 역할의 LLM도 포함됩니다.
- 포털 평가 는 모델, 에이전트, 데이터 세트 및 추적 대상에 대해 동일한 평가자를 실행합니다.
숫자가 비교할 수 있도록 고정된 데이터 세트의 원본 및 대상 모두 에 대해 동일한 계산기 집합을 실행합니다.
| 차원 | 측정할 내용 | Where |
|---|---|---|
| Quality | 원본과 대상 간 평가자 점수 | Azure AI 평가 SDK, 포털 평가 |
| Latency | 첫 토큰 생성 시간 및 처리량 | 벤치마크 순위표, 운영 메트릭 |
| Cost | 요청당 입력 및 출력 토큰 비용 | 평가 출력, 모델 가격 책정 |
일반적으로 중단되는 위치
대부분의 팀에는 평가 도구 모음이 없으며 종종 직접 빌드합니다. 규제 대상 워크로드의 경우 의무적인 인적 검토 또는 품질 관리 검토가 그 위에 추가로 이루어져 병목이 됩니다. 이러한 마이그레이션은 적응이 아닌 유효성 검사 시 중단됩니다.
가져온 내용
평가자는 실행할 준비가 되었지만 자체 프로덕션 트래픽에서 도메인 관련 테스트 집합을 큐레이팅하는 것은 모델(비 에이전트) 워크로드에 대한 실습 작업입니다. 이러한 요구는 준비 단계 자체에 대한 비용을 지불하는 이유입니다.
5단계: 롤아웃
이 단계의 목적은 유효성이 검증된 구성을 단계별로 프로덕션으로 승격하는 것입니다. 즉, 비프로덕션이 먼저, 카나리아 또는 가중치가 적용된 비율, 더 광범위한 노출입니다. 전체에서 실시간 대기 시간, 오류 및 이상적으로는 마이그레이션 전 기준에 대한 품질을 확인합니다. 그런 다음 커밋하거나 롤백합니다. 성공적인 결과는 카나리아, 가중치 또는 섀도 트래픽을 통한 점진적 노출, 대기 시간 및 오류를 초과하는 라이브 품질 신호 및 유지된 롤백 경로입니다.
고려해야 할 사항
- 배포 유형을 파악합니다. 배포 유형에 따라 메커니즘이 결정됩니다. 표준 패밀리 배포는 사용자가 제어하는 일정에 따라 자동 업그레이드할 수 있습니다. 프로비저닝된 배포, 일괄 처리 배포 및 파인튜닝된 배포는 수동으로 마이그레이션해야 합니다. 다음 표에서는 형식별 메커니즘을 보여 줍니다.
- 롤백 복도를 유지합니다. 문제가 없다고 확신할 때까지 이전 배포에 계속 접근할 수 있게 유지하세요. 증거가 아닌 사용 중단 기한에 의해 강제된 롤백 결정은 너무 늦게 시작한 경고 신호입니다.
- 카나리아를 사용할 수 없는 경우 그림자 또는 미러 모드를 사용합니다. 규제 흐름(PHI, 금융 거래)은 종종 실제 고객 트래픽에 새 모델을 노출할 수 없습니다. 마찬가지로 프로덕션 입력에서 새 모델을 오프라인으로 실행하고 사용자에게 영향을 주지 않고 출력을 이전 모델과 비교합니다.
- 오프라인 평가에서 놓친 회귀가 있는지 살펴보십시오. 실제 사용자 지연 시간과 예외적인 경우의 동작은 실제 운영 부하에서만 드러납니다.
배포 유형별 마이그레이션 메커니즘
| 배포 유형 | 마이그레이션 접근 방식 | Quota |
|---|---|---|
| 표준, 글로벌 표준, 데이터 영역 표준 | 순차적인 일정에 따라 자동 업그레이드
versionUpgradeOption(NoAutoUpgrade, OnceCurrentVersionExpired 또는 OnceNewDefaultVersionAvailable)을 사용하여 타이밍을 제어합니다. 우선 순위 처리는 동일한 경로를 따릅니다. |
자동으로 전달 |
| 할당됨 | 수동: 현재 위치(트래픽이 20~30분 동안 이동) 또는 병렬(새 배포, 트래픽 이동, 이전 배포 삭제). | 먼저 대상 모델 할당량 확인 |
| Batch | 병행 방식: 새 모델을 배포하고 작업을 다시 제출한 다음 이전 배포를 중단합니다. | 대상 모델 할당량 확인 |
| 미세 조정(이 문서의 범위를 벗어났습니다). | 자동으로 업그레이드되지 않음; 학습 및 배포에 대해 각각 별도의 사용 중지 일정 적용. 대체 기반 모델로 재튜닝하거나 대체 기반 모델에 증류하세요. | 대상 모델 할당량 확인 |
트래픽이 이동한 후에는 지속적인 평가를 구성하여 근본 원인 분석을 위해 추적과 연결된 Foundry Observability 대시보드에서 프로덕션 트래픽 중 샘플링한 일정 비율을 점수화하고, 품질이 저하되면 Azure Monitor 경고를 받도록 합니다.
일반적으로 중단되는 위치
오프라인 평가가 누락된 품질 회귀는 프로덕션 부하에 따라 나타납니다. 롤백 결정은 종종 증거가 아닌 사용 중단 기한에 의해 강제됩니다. 이는 마이그레이션이 너무 늦게 시작되었다는 신호입니다.
가져온 내용
두 배포 간의 가중치 기반 라우팅은 자체 게이트웨이 또는 애플리케이션 계층에서 구현되며, 롤백 기간은 일정 기간 동안 이전 배포를 즉시 되돌릴 수 있는 상태로 유지하기 위한 의도적인 선택입니다(임베디드 팀은 일반적으로 약 30일을 원합니다). 둘 다 한 번 디자인하고 모든 마이그레이션을 다시 사용할 가치가 있습니다.
6단계: 사용 중지
폐기 단계의 목적은 기존 배포를 폐기하고, 용량을 확보하며, 평가 아티팩트를 보관하고, 변경 사항을 고객 대면 문서, 마케팅 페이지, 지원 런북, 그리고 보존이 필요한 감사 로그 등 하위 관련 대상에 전달하는 것입니다. 결국 이전 배포는 사라졌고, 배포 수는 감소하고, 단원은 다음 주기로 진행됩니다.
고려해야 할 사항
- 은퇴를 정리뿐만 아니라 거버넌스로 취급합니다. 규제 대상 워크로드의 경우 보존 의무로 인해 아티팩트를 수년간 보관해야 할 수 있습니다.
- 원본이 실제로 사라졌는지 확인합니다. 이전 버전이 사용 중지되었는지 확인한 다음, 용량 소비를 중지할 수 있도록 배포를 삭제합니다.
- 학습한 내용을 다음 단계에 반영하세요. 새 프로덕션 추적을 골든 데이터 세트로 다시 접어 다음 마이그레이션이 더 저렴하게 시작되도록 합니다.
일반적으로 중단되는 위치
팀에서 사용 중지 절차를 건너뛰어 좀비 배포가 누적됩니다. 적극적으로 은퇴하지 않는 팀은 동료보다 훨씬 더 많은 라이브 배포를 수행하며, 그 중 대부분은 이전 마이그레이션의 구조적 파편입니다. 일반적인 누락된 하위 단계는 커뮤니케이션입니다. 마케팅 및 제품 설명서는 교환 후에도 여전히 이전 모델을 참조합니다.
가져온 내용
관찰성 대시보드는 배포 수가 감소하는 것을 보여 주지만, 여전히 부하를 부담하는 배포를 결정하는 것은 팀에서 내리는 판단 호출입니다. 은퇴를 희망보다는 명시적인 추적 작업으로 만듭니다.
마이그레이션은 단순히 양자택일로 이루어지는 경우가 드뭅니다.
실제 마이그레이션은 분할 상태인 경우가 많습니다. 워크로드의 일부는 새 모델에서 실행되는 반면 대기 시간이 중요하거나 위험 수준이 높은 경로는 이전 경로에 유지되고 때로는 몇 주 동안 유지됩니다. 이전 모델에서 새 모델로의 단일 스위치가 아닌 부분 롤아웃 및 부분 롤백을 계획합니다. 사용 중지는 일반적으로 롤아웃보다 몇 주에서 몇 달까지 늦어지는 경우가 많으며, 그렇게 오래 남아 있는 기존 배포가 바로 스프롤로 나타납니다.
관련 콘텐츠
- Foundry 모델 수명 주기 및 지원 정책에서 지원 중단 및 지원 일정을 이해하기
- 모델 사용 중지 일정에서 사용 종료 날짜 및 대체 모델 확인
- 사용 중지된 Microsoft Foundry 모델에서 이미 사용 중지된 항목 보기
- 모델 벤치마크 및 순위표와 후보 모델 비교
- 프롬프트 최적화 프로그램에서 프롬프트 최적화를 사용하여 프롬프트를 새 모델에 맞게 조정
- Foundry 포털에서 평가를 실행하여 전환하기 전에 품질 유효성 검사
- 생성 AI에서 관찰 가능성을 사용하여 마이그레이션된 워크로드 모니터링