결정된 AI
무료
Determined AI는 분산 훈련, 자동 슈퍼 매개변수 검색, GPU 클러스터 관리 및 실험 추적 기능을 제공하고 PyTorch 및 TensorFlow를 지원하는 오픈 소스 딥 러닝 훈련 플랫폼입니다.
결정된AI
AI의 핵심 매개변수 및 통계를 결정했습니다.
결정된 AI는 "딥 러닝 훈련을 위한 운영 체제"로 자리매김하고 ML 엔지니어링에서 가장 어려운 분산 조정 문제를 해결합니다. 훈련 작업이 단일 카드에서 여러 노드로 확장되면 코드 수정 비용, 리소스 경쟁 및 실험 혼란이 거의 모든 팀의 피할 수 없는 어려움이 됩니다. 결정된 것은 통합 스케줄링 계층을 통해 이러한 문제를 캡슐화하여 연구자가 모델 자체에만 집중할 수 있도록 합니다.
| 프로젝트 | 공공정보 |
|---|---|
| 공식 포지셔닝 | 오픈 소스 딥 러닝 교육 플랫폼 |
| 핵심역량 | 분산 훈련, 하이퍼파라미터 검색, 실험 추적 GPU 클러스터 관리 |
| 지원되는 프레임워크 | PyTorch, TensorFlow, Keras(KerasTuner 포함) |
| 배포 방법 | 자체 호스팅: Kubernetes, 로컬 에이전트 클러스터 Slurm/PBS, AWS/GCP |
| 액세스 포털 | 웹 UI, CLI(det), Python SDK, REST API |
| 오픈 소스 라이센스 | 아파치 2.0 |
| 코드 저장소 | GitHub determined-ai/determined(3.2k 별, 372 포크, 96 기여자) |
| 최신 버전 | v0.38.1 (2025-03-20) |
| 회사 소유권 | HPE(Hewlett Packard Enterprise) – 2021년 인수 |
| 기술 스택 | Go(44.6%) / Python(27.9%) / TypeScript(24.4%) |
한 문장으로 요약하자면: 또 다른 MLOps 대시보드가 아니라 "다중 머신 및 다중 카드 교육"을 수동 구성에서 선언적 제출로 변경하는 일정 엔진입니다. 핵심 가치는 팀이 단일 머신 코드를 작성해야 하는 정신적 부담을 안고 분산 교육을 완료할 수 있도록 하는 것입니다.
HPE 인수 배경: Defined는 인수 후 엔터프라이즈급 지원 리소스를 확보했습니다. EE(Enterprise Edition) 버전부터 라이센스 키가 필요해졌습니다. OSS 버전과 EE 버전은 SSO 및 RBAC 감사와 같은 엔터프라이즈 기능에서 기능적 차이가 있습니다. 커뮤니티는 OSS 버전이 EE 버전과 동일한 품질의 핵심 교육 기능 업데이트를 계속 받는지 여부에 주의를 기울여야 합니다.
Defined AI의 사용자 및 시장 인지도
GitHub 커뮤니티 활동: 웨어하우스에는 3.2,000개의 별, 372개의 포크, 총 121개의 릴리스(2026~07년 기준) 및 96명의 기여자가 있습니다. 이는 프로젝트가 오픈 소스 MLOps 분야에서 안정적인 관심을 받고 있지만 아직 초인기 순위에 진입하지 않았음을 나타냅니다(MLflow와 같은 유사한 프로젝트는 더 높은 별을 가집니다).
엔터프라이즈 채택: HPE는 금융, 제조, 과학 연구 및 기타 산업 분야의 HPC 고객을 위한 AI 인프라 솔루션에 Defined를 통합합니다. 공개적으로 사용 가능한 채택 사례는 교육 기관과 중간 규모의 ML 팀이 주도하는 반면, 대규모 엔터프라이즈 배포 수는 공개되지 않습니다.
업계 벤치마킹: Kubeflow(완전한 K8s 기본 MLOps) 및 MLflow(실험 추적 + 모델 등록에 편향됨)와 비교할 때, 결정된의 핵심 차이점은 전체 링크 오케스트레이션이 아닌 "훈련 작업 자체의 일정 조정 및 가속화"에 있습니다. 분산 훈련의 하위 필드에서는 Horovod(분산 통신 계층만 해당) 및 Weights & Biases(실험 추적만 해당)와 직접 경쟁하기보다는 보완합니다.
| 비교차원 | AI 결정 | 쿠베플로우 | ML플로우 | 호로보드 |
|---|---|---|---|---|
| 포지셔닝 | 교육 일정 플랫폼 | 전체 링크 MLOps | 실험 추적 + 모델 등록 | 분산형 교육 커뮤니케이션 라이브러리 |
| 분산 교육 | 자동 오케스트레이션 | 수동 구성 필요 | 관련되지 않음 | 통신 기본 요소 제공 |
| 하이퍼파라미터 검색 | 내장(그리드/베이지안/ASHA) | Katib 통합 필요 | 내장되지 않음 | 관련되지 않음 |
| 클러스터 스케줄링 | 내장 대기열 + 할당량 | K8s 기본 스케줄링 | 관련되지 않음 | 관련되지 않음 |
| 시작하기 어려움 | 중간(K8s 기본 사항 필요) | 높음 | 낮음 | 중간 |
결정된 AI의 비용 이점
C면/개별
오픈 소스 버전은 완전 무료입니다(Apache 2.0). 개인은 'pip installdetermined'를 통해 CLI를 설치하고 단일 머신이나 자체 GPU에 로컬 클러스터를 배포할 수 있습니다. 라이선스 비용은 없지만 자체 PostgreSQL + 스토리지 백엔드를 유지 관리하는 데 드는 운영 비용은 부담해야 합니다.
개발자/팀
오픈 소스 버전에는 소프트웨어 라이선스 비용이 없으며 팀은 필요에 따라 배포하도록 선택할 수 있습니다.
- 로컬 에이전트 모드: 운영 및 유지 관리 복잡성이 낮고 기존 GPU 서버를 사용하는 팀에 적합한 베어 메탈 또는 VM에 마스터 + 에이전트를 배포합니다.
- Kubernetes 모드: Helm Chart를 통해 배포되며 이미 K8s 인프라가 있지만 K8s 관리 기능이 필요한 팀에 적합합니다.
- 클라우드 배포:
det Deploy aws/gcp up원클릭 배포, 실제 클라우드 리소스 사용량에 따라 비용 지불, 추가 라이선스 비용 없음.
숨겨진 비용은 주로 PostgreSQL 데이터베이스 관리, 스토리지(S3/GCS/공유 파일 시스템) 구성, 네트워크 및 보안 그룹 정책, 버전 업그레이드 및 마이그레이션 등 운영 및 유지 관리 인력에 반영됩니다.
기업/민영화
HPE는 다음을 포함하는 Enterprise Edition을 제공합니다.
- SSO/SAML 통합
- RBAC 세분화된 권한 감사
- 상용 SLA 및 기술 지원
- ProLiant 서버 등 HPE 하드웨어와 사전 통합된 검증 Nimble Storage
Enterprise Edition 가격은 공개되지 않습니다. HPE 영업을 통해 견적을 받으십시오. 구매 전 확인해야 할 주요 용어: 라이선스가 노드/GPU 또는 사용자 수를 기준으로 청구되는지 여부, 프로덕션 제한 SLA 응답 시간, 업그레이드 경로 및 데이터 마이그레이션 지원 범위가 포함되는지 여부.
| 비용 계층 구조 | 비용 구성 요소 | 일반적인 연간 비용(파생) |
|---|---|---|
| 개인/소규모 팀(OSS) | 라이선스 비용 0 + 클라우드 호스트/GPU 비용 | $0 + 주문형 클라우드 리소스 |
| 중견팀(OSS+자체운영 및 유지보수) | 라이센스비 0 + 운영 및 유지관리 인력 (약 0.5~1명-월/년) | $5K~$15K(운영 및 유지보수 전환) |
| 엔터프라이즈(HPE EE) | 라이센스 비용 + 지원 계약 + 하드웨어 | 사업 확인 필요 |
Defined AI의 주요 기능
-
Zero-modification 분산 교육: 사용자는 교육 스크립트에서
determined.pytorch.PyTorchTrial또는determined.keras.KerasTrial기본 클래스만 사용하면 되며 플랫폼은 그라데이션 동기화(All-Reduce), 데이터 샤딩 및 노드 내결함성을 자동으로 처리합니다. 'torch.distributed.launch' 또는 'tf.distribute.Strategy'를 수동으로 작성할 필요가 없으므로 분산 교육에 대한 진입 장벽이 줄어듭니다.- 전문가 의견: 이 추상화 계층의 숨겨진 이점은 팀이 코드에 분산 논리를 삽입하지 않고도 단일 카드 프로토타입에서 다중 카드 생산으로 직접 전환할 수 있다는 것입니다. 이후에 GPU 수를 늘리려면 학습 코드를 변경하지 않고 YAML 구성에서 'slots_per_trial'만 변경하면 됩니다.
-
적응형 하이퍼파라미터 검색(ASHA): 비동기 연속 반감기 알고리즘을 기반으로 리소스가 제한될 때 잠재력이 낮은 시도를 먼저 제거하고 잠재력이 높은 매개변수 조합에 더 많은 컴퓨팅 성능을 할당합니다. Early Stopping, 그리드 검색, 베이지안 검색을 지원하며 검색 과정에서 검색 공간을 동적으로 조정할 수 있습니다.
- 전문가 의견: ASHA와 플랫폼 스케줄러 간의 협업은 결정됨의 핵심 차이점입니다. 검색 알고리즘은 "다음 매개변수 세트가 무엇인지" 결정할 수 있을 뿐만 아니라 플랫폼 스케줄러를 통해 "선점할 수 있는 시도"를 제어할 수 있으며, 클러스터가 가득 차면 우선순위가 낮은 검색 시도를 자동으로 다운그레이드하여 하이퍼파라미터 검색이 공식 교육 작업을 차단하는 것을 방지합니다.
-
GPU 할당량 및 대기열 예약: GPU 할당량을 리소스 풀(Resource Pool)로 나누는 기능을 지원합니다. 사용자가
det Experiment create를 통해 작업을 제출하면 플랫폼은 자동으로 슬롯을 대기열에 추가하고 예약하고 할당합니다. 단일 사용자가 클러스터를 채우는 것을 방지하기 위해 Priority Scheduler 및 Fair Scheduler를 지원합니다.- 전문가 의견: 스케줄러 + 할당량의 조합은 "GPU 유휴 및 경합 공존"이라는 일반적인 팀 딜레마를 해결합니다. 연구자들은 더 이상 누가 언제 카드를 사용할 것인지 수동으로 협상할 필요가 없으며, 플랫폼은 제출된 작업이 최종적으로 예약되도록 보장하므로 10명 이상의 팀에서 조정 비용을 크게 줄일 수 있습니다.
-
실험 추적 및 자동 스냅샷: 각 교육에 대한 지표(손실/정확도와 같은 시계열), 하이퍼파라미터 구성, 전체 코드 스냅샷(Git Commit + 추적되지 않은 파일) 및 모델 가중치 체크포인트를 자동으로 기록합니다. 웹 UI는 여러 실험 지표의 비교 및 시각화를 지원하며 Checkpoint는 한 번의 클릭으로 훈련을 재개하거나 계속할 수 있습니다.
- 전문가의 관점: 코드 스냅샷의 자동 가로채기는 수동 기록보다 더 안정적입니다. 연구원이 커밋하는 것을 잊어버리더라도 플랫폼은 제출 시 소스 코드를 자동으로 보관합니다. 이는 특히 여러 연구자가 클러스터를 공유하는 경우 실험 재현성에 매우 중요합니다. "이 모델이 어떤 버전의 코드로 실행되었는지"는 더 이상 미스터리가 아닙니다.
-
노트북 및 대화형 작업: 클러스터 GPU 노드에서 Jupyter Notebook, TensorBoard 또는 Shell을 시작하면 GPU 노드에서 직접 계산이 수행됩니다. 노트북의 데이터와 훈련 작업은 동일한 저장 계층(공유 파일 시스템 또는 객체 저장소)을 공유하므로 데이터 전처리 후 훈련 작업을 직접 제출할 수 있습니다.
- 전문가의 관점: 노트북과 교육 작업은 GPU 풀을 공유합니다. 즉, 동일한 카드로 노트북과 교육을 동시에 실행할 수 없습니다. 대화형 작업이 프로덕션 교육 리소스를 차지하지 않도록 노트북을 우선 순위가 낮은 리소스 풀로 제한하거나 별도의 작은 GPU 풀로 제한하는 것이 좋습니다.
-
DeepSpeed 통합: 버전 0.17.0부터 내장된 DeepSpeed 지원, YAML 구성을 통해 ZeRO 최적화(1/2/3단계)를 활성화하여 대규모 모델 교육 시나리오에서 그래픽 메모리 사용량을 줄일 수 있습니다. Defined의 자동 그래디언트 동기화와 함께 ZeRO의 통신 모드와 플랫폼 스케줄러가 함께 작동합니다.
-
핵심 API(하위 수준 인터페이스): Trial 기본 클래스가 필요하지 않은 고급 사용자를 위해 결정됨은 사용자가 최소한의 방해가 되는 방식으로 플랫폼 기능을 통합할 수 있도록 핵심 API를 제공합니다. 훈련 주기 구조를 강제로 수정하지 않고도
det.core.init()를 사용하여 컨텍스트를 획득하여 지표를 기록하고 체크포인트를 저장할 수 있습니다. 이는 Hugging Face Trainer와 같은 타사 교육 라이브러리와 통합할 때 특히 유용합니다.
Defined AI의 모델 및 버전 진화
"OSS + EE" 이중 트랙 릴리스 전략을 채택하기로 결정되었습니다. OSS 버전은 의미론적 버전 관리를 따르고 EE 버전은 OSS 버전 번호 뒤에 '-ee' 접미사를 추가합니다.
메인라인 출시
| 버전 번호 | 출시일 | 핵심 변화 |
|---|---|---|
| v0.32.0 | 2026-05(공식적인 정확한 날짜는 아직 없음) | 성능 최적화 및 버그 수정을 포함한 최신 릴리스 버전 |
| v0.38.1 | 2025-03-20 | 환경 이미지 업데이트 및 종속성 복구를 포함한 최신 안정 버전 |
| v0.38.0 | 2024-11-23 | 검색기 컨텍스트 제거(아키텍처 단순화), 작업 구성 정책(구성 정책) GA, 글로벌 구성 정책 UI |
| v0.37.0 | 2024-09-30 | 신규 실행 객체(Run Centric API), 워크로드 경고(Workload Alerting), 구성 정책 초기 지원 |
| v0.36.0 | 2024-08-24 | Flat Runs 보기 GA, RBAC Webhook, Data Lineage 초기 지원 |
| v0.35.0 | 2024-08-09 | Flat Runs 비교 보기, 메타데이터 필터 검색, K8s Pod to Job 제출, 프레임워크 분할(Framework Splitting) |
| v0.34.0 | 2024-06-29 | 노트북 토큰 인증 K8s 노드 선택기/어피니티는 일시 중지/재개 실행을 지원합니다 |
| v0.33.0 | 2024-05-30 | WebUI 템플릿 관리 Flat Runs 정렬/필터링, 히트맵(Heatmap), Helm 비밀번호 복잡성 확인 |
| v0.32.0 | 2024-04(공식적인 정확한 날짜는 아직 없음) | 템플릿 CRUD API, K8s 다중 RM 지원, 실험적인 일괄 작업 |
버전 관리 관찰
- 속도: 2024년에는 마이너 버전 한 개 정도의 반복 빈도를 2024년에 유지하고, 2025년에 진입한 후에는 속도가 느려질 예정입니다(v0.38.1은 2025-03년에 출시될 예정). 이는 제품 성숙도 향상이나 팀 리소스 조정을 반영할 수 있습니다.
- 아키텍처 진화: v0.35에서 v0.38로의 핵심 추세는 "실험-시험 중앙화"에서 "실행 중앙화"(플랫 실행)로의 마이그레이션과 멀티 테넌트 거버넌스 기능을 향상시키기 위한 구성 정책의 도입입니다.
- Enterprise Edition의 차이점: EE 버전은 SSO 개선(v0.38.0+), 라이선스 키 확인, RBAC 감사 로그 등 엔터프라이즈 기능에서 OSS보다 앞서 있습니다. OSS 사용자는 이러한 기능이 점차 커뮤니티 버전으로 이전되는지, 아니면 오랫동안 EE에만 독점으로 유지되는지 주의해야 합니다.
결정된 AI의 기술적 이점
선언적 훈련 구성: 사용자는 YAML을 통해 훈련 하이퍼파라미터, 리소스 요구 사항(slots_per_trial), 검색 알고리즘 및 예약 전략을 정의하고 플랫폼은 이에 따라 시도를 생성하고 실행을 예약합니다. 이 선언적 추상화의 핵심 장점은 연구자들이 "어떻게 해야 하는지"가 아닌 "무엇을 해야 하는지"를 설명하고, 플랫폼은 백그라운드의 클러스터 로드를 기반으로 "어떤 머신에서 실행할 GPU 수"를 자동으로 결정한다는 것입니다.
자동 그라데이션 동기화(All-Reduce Aggregation): Defined의 Harness 구성 요소는 사용자 교육 코드 위에 그라데이션 동기화 논리(NCCL 또는 Gloo 기반)를 자동으로 주입하므로 사용자가 분산 통신 코드를 작성할 필요가 없습니다. 여러 번의 시도는 각각 할당된 슬롯에서 독립적으로 정방향/역방향으로 진행됩니다. Harness는 각backward()후에 자동으로 All-Reduce 집계 그래디언트를 실행하여 각 노드의 모델 매개변수가 일관되게 유지되도록 합니다. 이 메커니즘을 사용하면 학습 스크립트를 건드리지 않고도 YAML에서slots_per_trial`을 수정하여 단일 카드에서 여러 카드로 확장할 수 있습니다.
ASHA 검색을 위한 협업 예약: 기존 하이퍼파라미터 검색 도구는 스케줄러와 독립적으로 실행되며 검색된 시험은 여전히 리소스 대기열에 있어야 합니다. 결정은 검색기와 스케줄러를 심층적으로 통합합니다. 검색자가 다음 매개변수 세트를 결정한 후 스케줄러는 즉시 시도를 시작할지 여부와 현재 클러스터 로드를 기반으로 우선순위가 낮은 시도를 선점할지 여부를 결정합니다. 이 공동 설계를 통해 클러스터가 가득 찼을 때 하이퍼파라미터 검색이 프로덕션 교육 작업을 차단하지 않을 수 있습니다. 검색 시도는 선점형으로 표시되어 우선 순위가 더 높은 작업이 제출되면 자동으로 GPU를 해제합니다.
이중 트랙 스케줄링(에이전트 RM + K8s RM): 에이전트 RM(자체 관리형 에이전트 클러스터) 및 K8s RM(Kubernetes 기본 스케줄링)의 두 가지 리소스 관리 모드를 지원하는 것으로 확인되었습니다. 에이전트 RM은 베어메탈/HPC 환경에 적합하고 K8s 종속성이 필요하지 않으며 배포가 더 가볍습니다. K8s RM은 K8s 인프라를 이미 보유하고 있는 팀에 적합하며 K8s의 자동 확장 및 축소, 네임스페이스 격리 및 기타 기능을 활용할 수 있습니다. 둘 다 동시에 활성화할 수 있으므로(Multi-RM) 동일한 마스터가 이기종 클러스터를 관리할 수 있습니다.
체크포인트의 스토리지 추상화: 체크포인트는 공유 파일 시스템 S3/GCS 객체 스토리지 또는 HDFS에 대한 스토리지를 지원합니다. 플랫폼은 체크포인트 수명 주기(GC 정책)를 자동으로 유지하고 스토리지 계층 전반에 걸쳐 데이터 마이그레이션을 구성할 수 있습니다. 이 추상화는 훈련 클러스터의 저장과 계산을 분리합니다. 훈련 노드는 상태 비저장 인스턴스일 수 있으며 체크포인트는 실험 실패 후 빠른 복구를 용이하게 하기 위해 외부 개체 저장소에 유지됩니다.
성능 프로파일링 내장: 웹 UI에는 GPU 사용률, 데이터 로드 처리량, 통신 비율과 같은 지표를 확인하여 교육 병목 현상(예: 데이터 로드가 병목 현상인지 또는 통신이 병목 현상인지 여부)을 찾는 데 도움이 되는 교육 성능 분석 도구가 내장되어 있습니다. 이 기능은 Prometheus/Grafana의 추가 통합이 필요하지 않으므로 성능 튜닝을 위한 도구 체인의 복잡성이 줄어듭니다.
코드 웨어하우스에서 Go를 기본 언어로 선택한 경우(44.6%) 마스터 구성 요소가 동시성 성능에 대한 높은 요구 사항을 갖고 있음을 보여줍니다. 즉, 마스터는 수백 개의 에이전트의 하트비트, 일정 결정 및 API 요청을 동시에 관리해야 합니다. 이 시나리오에서는 Go의 Goroutine 모델이 Python보다 더 효율적입니다. Harness(Training Runtime)와 SDK에는 Python(27.9%)이 사용되고, 웹 UI에는 TypeScript(24.4%)가 사용됩니다.
결정된 AI를 사용하는 방법
CLI 설치 및 클러스터 시작
``배쉬
CLI 설치
pip 설치가 결정됨
로컬 클러스터(단일 머신에서 빠른 경험)
로컬 클러스터링 배포
AWS배포
배포 좀 해봐
GCP 배포
GCP를 배포하세요.
### 학습 작업 제출
훈련 스크립트 적응(PyTorch 예):
``파이썬
determined.pytorch에서 PyTorchTrial, DataLoader, PyTorchTrialContext 가져오기
클래스 MyTrial(PyTorchTrial):
def __init__(self, 컨텍스트: PyTorchTrialContext):
self.context = 컨텍스트
self.model = self.context.wrap_model(nn.Sequential(...))
def train_batch(self, 배치, epoch_idx):
손실 = self.model(배치)
self.context.backward(손실)
self.context.step_optimizer(self.optimizer)
{"손실": 손실}을 반환합니다.
YAML 구성 파일(experiment.yaml):
``yaml 이름: my_experiment 진입점:train.py 하이퍼파라미터: 학습 속도: 유형: 더블 최소값: 0.0001 최대값: 1.0 검색자: 이름:adaptive_asha 측정항목: 손실 더 작은_is_더 나은: 사실 최대 시도 횟수: 100 자원: 시험당 슬롯: 8
제출 명령:
``배쉬
실험을 통해 Experiment.yaml을 생성하세요.
배포 옵션 비교
| 배포 방법 | 적용 가능한 시나리오 | 전제조건 | 유지 관리의 복잡성 |
|---|---|---|---|
로컬 클러스터(det 배포 로컬) |
여러 카드를 사용하는 개인 개발/단일 시스템 | 도커 | 낮음 |
AWS AWS 배포 |
클라우드에서 빠른 시작 | AWS 계정 + 할당량 | 중간 |
GCP gcp 배포 |
클라우드에서 빠른 시작 | GCP 계정 + 할당량 | 중간 |
| Kubernetes Helm 차트 | 기존 K8s 클러스터 | K8s 클러스터 + Helm 3 | 중간에서 높음 |
| 에이전트 수동 배포 | 베어메탈/HPC | PostgreSQL + 공유 스토리지 | 높음 |
| Slurm/PBS 통합 | HPC 클러스터 | 슬럼/PBS 상황별 | 높음 |
빠른 검증 경로: 개별 개발자는 마스터와 에이전트가 포함된 단일 노드 클러스터를 로컬에서 5분 이내에 풀업하고 공식 MNIST 샘플 검증 핵심 프로세스를 실행할 수 있는 'pip 설치 결정 && 로컬 클러스터업 배포'를 권장합니다.
결정된 AI를 위한 제품 가격
결정된 AI는 "오픈 소스 코어 + 엔터프라이즈 버전"의 이중 트랙 가격 모델을 채택합니다.
- 오픈 소스 버전(OSS): Apache 2.0 라이센스, 분산 교육, 슈퍼 매개변수 검색, 실험 추적 및 일정 관리를 포함한 모든 기능을 포함합니다. 사용 제한이나 GPU 한도는 없습니다. 자체 운영 및 유지 관리 능력을 갖춘 개인, 학술팀, 중규모 팀에 적합합니다.
- Enterprise Edition(HPE Enterprise Edition): OSS를 기반으로 HPE 하드웨어 사전 통합 검증을 위한 SSO/SAML 통합 RBAC 세분화된 권한 감사 및 상용 SLA 지원을 추가합니다. 가격은 HPE 판매를 통해 연간 구독 기준으로 책정되며 구체적인 청구 단위(노드/GPU/사용자)는 공개되지 않습니다.
- 클라우드 호스팅 버전: HPE는 SaaS 호스팅을 제공하지 않으며 모든 배포가 자체 호스팅됩니다. 운영이 필요 없는 환경을 원한다면
det Deploy aws/gcp를 통해 클라우드에서 빠르게 시작할 수 있지만 관리와 모니터링은 여전히 팀의 몫입니다.
| 버전 | 라이센스 | 가격 | 적용규모 |
|---|---|---|---|
| OSS | 아파치 2.0 | 무료 | 개인부터 중간 규모 팀까지(GPU 100개 미만) |
| EE | 상업용 라이센스 | 사업 확인 필요 | 중견기업 및 대기업(GPU 100개 이상) |
Enterprise Edition을 구매하기 전에 HPE에 확인해야 합니다. GPU 수에 따른 계층별 가격 책정을 지원하는지, 프로덕션 지원 24/7 지원, 업그레이드, 데이터 마이그레이션에 대한 특정 조건이 포함되어 있는지 여부를 HPE에 확인해야 합니다.
결정된 AI 적용 시나리오
-
다중 GPU 클러스터 교육 관리: 팀이 10~100개의 GPU를 공유하는 경우 결정된 대기열 예약은 유휴 낭비를 효과적으로 줄입니다. 연구자는 더 이상 누가 언제 카드를 사용하는지 수동으로 조정할 필요가 없습니다. 슈퍼파라미터 검색은 매개변수 공간을 자동으로 검색하므로 매개변수를 수동으로 수정하고 다시 실행할 필요가 없습니다. 검증 핵심 사항: 대기열 스케줄링에서 우선순위가 높은 작업이 자주 제출되는 경우 우선순위가 낮은 검색 시도를 올바르게 선점하고 복원할 수 있는지 여부.
-
표준화된 실험 파이프라인: 코드 스냅샷, 하이퍼파라미터, 지표 및 체크포인트가 각 교육에 대해 자동으로 기록됩니다. 새로운 연구원이 프로젝트를 맡게 되면 웹 UI에서 과거 실험을 직접 확인하거나, 한 번의 클릭으로 재현하거나, 지정된 체크포인트에서 계속 학습할 수 있습니다. 확인해야 할 핵심 사항: 코드 스냅샷에 추적되지 않은 로컬 수정 파일이 완전히 포함되어 있는지 여부와 체크포인트 GC 전략으로 인해 조기 삭제가 발생할 수 있는지 여부.
-
초대형 모델 훈련(DeepSpeed 통합): 수백억 개의 매개변수가 있는 모델 훈련을 위해 ZeRO Stage 2/3은 비디오 메모리 사용을 최적화하고 결정된 자동 다중 노드 스케줄링과 협력하여 대규모 모델 훈련을 위한 인프라 임계값을 낮춥니다. 검증 초점: DeepSpeed 버전과 확정 버전의 호환성 ZeRO Stage 3에서의 통신 효율성.
-
하이브리드 클라우드/이기종 클러스터 교육: Multi-RM을 통해 로컬 베어메탈 클러스터와 K8s 클러스터의 관리를 클라우드에서 통합하고, 교육 작업은 리소스 요구 사항에 따라 사용 가능한 노드에 자동으로 예약됩니다. 검증 초점: 클러스터 간 체크포인트 동기화 메커니즘 및 네트워크 지연이 분산 교육에 미치는 영향.
-
HPC/학술 연구 컴퓨팅: 과학 연구자들에게 교육 작업을 제출할 수 있는 웹 UI를 제공하기 위해 Slurm/PBS 클러스터에 Defined를 배포하여 수동으로 작업을 제출하는 기존 SSH 방법을 대체합니다. 내장된 실험 추적 기능은 "매개변수 기록을 잊어버림"으로 인해 발생하는 재현 불가능한 문제를 줄입니다. 검증 초점: Slurm 통합 버전은 Job Array를 지원하고 기존 HPC 스케줄링 전략과 공존합니다.
결정된 AI 적용 그룹
-
딥 러닝 연구원/알고리즘 엔지니어: 분산 코드 적응 작업량을 줄이고, 실험 매개변수와 결과를 자동으로 기록하고, 한 번의 클릭으로 여러 실험 지표 세트를 비교하기 위해 자주 분산 훈련 실험을 수행해야 합니다. 그 가치는 GPU가 5~50개 있는 중간 규모 팀에서 가장 두드러집니다.
-
ML 인프라/플랫폼 엔지니어: 팀을 위한 교육 인프라 구축을 담당합니다. 우리는 "제출 및 훈련"의 셀프 서비스 플랫폼을 제공하고 "연구자들이 환경을 구성하고 드라이버를 조정하고 패키지를 패키징하는 데 도움을 주는" 일상적인 지원 작업을 줄이기를 희망합니다. K8s/PostgreSQL 운영과 유지관리 비용의 균형과 효율성 향상에 대한 평가가 필요합니다.
-
HPC 클러스터 관리자: 작업 우선 순위 및 리소스 할당량을 제어하는 기능을 유지하면서 연구원이 웹 UI를 통해 클러스터를 사용할 수 있는 임계값을 낮추기 위해 Slurm/PBS 클러스터를 관리합니다. 기존 스케줄러와의 호환성 여부 및 교체 비용을 확인해야 합니다.
-
기술 의사 결정자(CTO/VP Eng): MLOps 플랫폼 선택을 평가하려면 Kubeflow/MLflow/Determined의 기능 범위와 운영 및 유지 관리 비용을 비교해야 합니다. 결정된 것은 "훈련 효율성 향상"이라는 단일 차원에서 뛰어난 경쟁력을 가지고 있지만 팀에 완전한 모델 배포 및 모니터링 링크가 필요한 경우 다른 도구와 결합해야 할 수도 있습니다.
대중에게 적합하지 않음:
- 단일 카드로 요구 사항을 충족할 수 있는 소규모 팀이나 개인의 경우 결정된 클러스터 배포 및 유지 관리 비용이 이점보다 클 수 있습니다. 'torchrun'이나 'python train.py'를 직접 사용하는 것이 더 가볍습니다.
- 완전한 추론 배포 + A/B 테스트 + 모델 모니터링 링크가 필요한 팀의 경우 결정됨에는 추론 서비스 구성 요소가 포함되어 있지 않으며 KServe/Seldon과 같은 도구와 쌍을 이루어야 합니다.
- K8에 대한 불가피한 의존에 저항하는 팀 - 에이전트 RM 모드를 사용할 수 있지만 대부분의 고급 기능(다중 RM, 자동 크기 조정)은 여전히 K8에 의존합니다.
결정된 AI 요약 및 전망
핵심 역량: 결정된 AI는 "분산 교육 일정 관리"라는 수직 분야의 오픈 소스 커뮤니티에서 가장 완벽한 기본 솔루션을 제공합니다. 선언적 YAML 구성 + 자동 그라데이션 동기화 + ASHA 검색 + GPU 할당량 관리의 조합은 다중 시스템 및 다중 카드 교육을 "각 팀이 자체 휠 만들기"에서 "교육으로서의 구성"으로 변경합니다. GPU 리소스 집약적인(10개 이상의 GPU) ML 팀의 경우 훈련 코드를 변경하지 않고도 GPU 활용도와 실험 효율성을 크게 향상시킬 수 있습니다.
현재 제한사항:
- 학습 곡선은 K8s 배포 및 YAML 구성 이해에 중점을 둡니다. 컨테이너화되지 않은 팀의 경우 첫 번째 배포에 1~2주가 걸릴 수 있습니다.
- OSS 버전과 EE 버전 사이의 기능적 격차에 대한 불확실성이 있습니다. SSO 및 RBAC 감사와 같은 엔터프라이즈 기능은 오랫동안 EE 버전에 잠겨 있었습니다. OSS 버전이 핵심 훈련 기능의 완전한 반복 진행을 유지할 수 있는지 여부는 아직 밝혀지지 않았습니다.
- 커뮤니티 규모(3.2k 별)는 Kubeflow(~14,000 별) 및 MLflow(~18,000 별)보다 작으며, 타사 생태 기여 및 커뮤니티 문제에 대한 응답 속도가 제한될 수 있습니다.
조달/채택 위험 평가: 팀은 먼저 OSS 버전을 기존 클러스터에 파일럿으로 배포하고 1~2개의 일반적인 교육 작업(비핵심 생산 작업)을 선택하여 분산 교육의 사용 용이성과 일정 효과를 확인하는 것이 좋습니다. 파일럿 기간 동안 다음 세 가지 주요 지표에 주의를 기울이는 것이 좋습니다. (1) 교육 제출부터 교육 시작까지의 평균 대기 시간(수동 조정 개선 정도와 비교) (2) 하이퍼파라미터 검색 도입 후 최적의 매개변수를 찾는 데 필요한 시도 횟수와 GPU 시간. (3) 연구원이 플랫폼으로 전환한 후 코드 수정 작업량(추상화 계층이 적을수록 더 효과적입니다). 파일럿 검증을 통과하면 EE 버전의 엔터프라이즈 기능이 필요한지 평가하고, 그 과정에서 HPE를 통해 EE 버전의 가격 조건과 데이터 마이그레이션 경로를 확인합니다.
관련 도구: hugging-face, replicate
버전 정보
- 0.32.0으로 결정 :아직 공식적인 정확한 날짜는 없습니다.
- 0.28.0 결정 :아직 공식적인 정확한 날짜는 없습니다.
사용자 후기