AWS Bedrock의 33개 리전 중 단 하나인 us-west-2에서만 700억 개의 파라미터를 가진 Llama 3.3 모델의 파인튜닝(fine-tuning)이 가능합니다. 개발자들은 리전 간 파이프라인을 구축하거나 번거로운 우회 방법을 감수해야 합니다.
이 발견이 중요한 이유
AWS의 공개 가격 페이지에는 여전히 구형 Llama 2 시리즈의 학습 비용만 기재되어 있습니다. 최신 Llama 3.1 및 3.3 제품군은 완전히 누락되어 있습니다. 엔지니어들은 어떤 리전이 실제로 파인튜닝을 지원하는지, 작업이 대기열(queue)에 얼마나 머무는지, 유휴 시간(idle time)에 비용이 청구되는지 등을 추측해야 하는 상황입니다.
실제 수치
- us-west-2 – Llama 3.3 70B 파인튜닝이 가능한 유일한 리전.
- us-east-1 – Amazon 자체 제작 모델만 지원; Llama 또는 Anthropic 파인튜닝 불가.
- eu-west-2 (London) – Llama가 아닌 단일 모델만 파인튜닝 가능.
- 기타 모든 리전 – Llama 3.3 70B에 대해 “model not available” 오류 반환.
커스텀 튜닝된 Llama 3.3 70B가 필요한 경우, us-west-2에서 작업을 실행하고 데이터를 다른 리전으로 전송하거나, “Custom Model Import” 경로를 시도해야 합니다. 하지만 저자의 시도는 일반적인 하드웨어 오류(hardware error)와 함께 실패했습니다.
Custom Model Import: 위험한 우회로
AWS 문서는 “Custom Model Import”를 통해 200GB 미만의 가중치(weights)를 eu-central-1을 포함한 모든 리전으로 가져올 수 있다고 주장합니다. 하지만 실제로 Llama 3.3 70B(200GB를 훨씬 초과함)를 가져오려는 시도는 반복적으로 “hardware error”를 발생시켰습니다. 현재로서는 us-west-2의 네이티브 파인튜닝 엔드포인트를 사용하는 것이 가장 안전합니다.
비용(과 정신 건강)을 아끼는 두 가지 팁
- 최상위 “InProgress” 플래그를 믿지 마세요. 작업이 해당 상태로 AWS 관리 대기열에 몇 시간 동안 머물러 있어도 실제 컴퓨팅은 실행되지 않을 수 있습니다. 비용 청구는 중첩된
trainingDetails필드가 “Running”으로 바뀔 때부터 시작됩니다. 대기열 유휴 시간에 비용을 지불하지 않으려면 내부 플래그를 확인하세요. - 조급함보다는 인내심이 답입니다. 한 테스트 작업은 학습이 시작되기 전 대기열에서 23시간 동안 머물렀지만, 시작 후에는 문제없이 완료되었습니다. 작업을 중단하고 다시 실행하면 대기열 맨 뒤로 밀려나 전체 대기 시간이 늘어납니다. 대기 시간은 무료이며, GPU 인스턴스가 가동되는 시점부터 비용이 발생합니다.
기타 현장 교훈
- 모델 스키마가 다릅니다. Llama 3.3과 Llama 3.1은 서로 다른 구성 객체(configuration objects)를 사용합니다. 토큰 길이와 같은 제한 사항이 일치하더라도, 한 버전의 JSON 스키마를 다른 버전에 복사하여 붙여넣으면 유효성 검사 오류가 발생합니다.
- 쿼터(Quota)의 특이점. “생성 중(creating status)”인 커스텀 모델에 대한 제한은 전체 작업 쿼터보다 훨씬 낮은 경우가 많습니다. 이전 작업이 여전히 “creating” 상태인 동안 “quota exceeded” 오류가 발생하면, 새 작업을 시작하기 전에 오래된 항목을 삭제하십시오.
- 스토리지 비용 누적. 파인튜닝된 각 체크포인트는 표준 요율로 청구되는 S3 스토리지 용량을 차지합니다. 오래된 버전을 그대로 두면 가치 있는 데이터 없이 월간 청구 금액만 늘어납니다.
결론
프로젝트가 파인튜닝된 Llama 3.3 70B 모델에 달려 있다면, 해당 단계를 us-west-2에서 실행할 계획을 세우거나 커스텀 임포트의 시행착오를 각오해야 합니다. 대기열 상태를 세밀한 수준에서 확인하고, 오래 기다려야 하는 작업을 중단하고 싶은 유혹을 참으며, 스토리지 및 쿼터 사용량을 면밀히 모니터링하십시오.