Ray Train DLC, EKS에서 분산 학습을 위한 이미지 빌드 제거

AWS는 10월 28일, 맞춤형 컨테이너 이미지를 빌드하지 않고 Ray Train DLC를 사용하는 8-GPU 학습 예제를 공개했다. 패키징된 소프트웨어 환경인 Deep Learning Container는 학습 프레임워크와 네트워킹 라이브러리를 제공한다. 남는 작업은 클러스터 구성과 워크로드 검증이다.

이 예제는 AWS의 관리형 Kubernetes 서비스인 Amazon EKS에서 두 대의 g6.12xlarge 인스턴스에 걸쳐 언어 모델 Qwen2.5-1.5B를 실행한다. Kubernetes는 여러 머신에서 컨테이너화된 애플리케이션을 조율한다. AWS는 GPU 간 모델 상태를 분산하는 학습 방식인 PyTorch FSDP를 사용해 인스턴스 간 통신을 시험한다.

이로써 비교 대상은 구체화된다. AWS가 유지보수하는 학습 환경과 팀이 동일한 소프트웨어 스택을 직접 유지보수하는 방식의 비교다. 다만 샘플은 무작위로 생성된 모델 입력인 랜덤 토큰 배치를 사용한다. 이는 유용한 모델 적응이 아니라 인프라를 검증한다. 팀은 분산 실행을 위한 출발점을 얻지만, 데이터셋 준비, 평가, 프로덕션 복구는 여전히 별도의 결정 사항이다.

Ray Train DLC가 EKS 팀에 바꾸는 점

즉각적인 변화는 공개된 이미지에서 분산 학습 작업까지 이어지는 문서화된 경로를 이용할 수 있다는 점이다. AWS의 분산 학습 샘플은 컨테이너 패키징을 특정 클러스터 구성과 연결한다. 이 예제는 학습이 쉬워진다는 일반적 약속보다 더 좁고 실행 가능한 내용을 제공한다.

유의미한 변화는 공유 학습 환경을 누가 유지보수하는지가 달라진다는 데 있다.

맞춤형 이미지는 애플리케이션 팀이 의존성을 구성할 책임을 지게 한다. 이 책임은 Python 프레임워크 설치를 넘어선다. GPU 실행과 통신은 학습 스크립트 외부의 라이브러리를 포함해 함께 작동해야 하는 구성 요소에 의존한다.

공개된 이미지는 이러한 조립 작업에 다른 소유자를 부여한다. 애플리케이션 팀은 결과 환경이 자신의 요구 사항을 충족하는지 여전히 선택해야 한다. 그러나 동등한 환경을 직접 유지보수하기로 결정하기 전에 기존 아티팩트를 평가할 수 있다.

이 구분은 팀이 이미 무엇을 학습하고 싶은지 알고 있을 때 가장 중요하다. 환경 호환성 문제를 해결하는 데 쓰는 시간은 데이터셋이나 평가 프로세스를 직접 개선하지 않는다. 첫 실험에서 이 작업을 제거하면 더 일찍 워크로드를 조사할 여지가 생긴다.

이 발표에는 정확한 일정도 필요하다. AWS의 Ray Train 컨테이너 변경 이력에 따르면 초기 이미지는 2026년 8월 26일, 버전 1.1은 9월 1일에 출시됐다. 10월의 게시물은 해당 컨테이너 제품군의 최초 출시가 아니라 이를 활용한 배포 가이드다.

이 연표는 뉴스의 가치를 바꾼다. AWS는 이전에 출시한 패키징이 재현 가능한 분산 환경에 어떻게 들어맞는지 문서화하고 있다. 새롭게 발명된 학습 알고리즘이라는 인상을 주지 않으면서, 소프트웨어 제공과 클러스터 운영의 연결에 초점을 맞춰야 한다.

엔지니어링 관리자의 경우 판단의 틀이 더 쉬워진다. 별도 학습 이미지를 유지보수하는 일이 공개 환경에 없는 기능을 제공하는지 물을 수 있다. 이는 모든 분산 학습 프로젝트에 자체 컨테이너 빌드가 필요하다고 가정하는 것보다 구체적이다.

플랫폼 엔지니어에게 이 예제는 로컬 요구 사항과 비교할 수 있는 참조 구성을 제공한다. 차이는 명시적인 검토 항목이 된다. 팀은 어떤 변경이 워크로드에 속하고 어떤 변경이 기존 인프라 관례를 반영하는지 식별할 수 있다.

공개된 경로는 예외를 설명하기도 더 쉽게 만든다. 조직에 다른 프레임워크 빌드나 특수 확장이 필요하다면, 그 요구 사항은 추가 유지보수를 정당화할 수 있다. 그러면 맞춤형 이미지는 기본 출발점이 아니라 문서화된 필요에 따라 만들어진다.

이 모든 것이 보편적인 적합성을 입증하는 것은 아니다. 팀이 검토할 수 있는 실용적 대안을 제시할 뿐이다. 가장 타당한 해석은 AWS가 이 특정 분산 학습 환경을 평가하기 시작하는 데 필요한 환경 구성 작업을 줄였다는 것이다.

부담은 맞춤형 이미지 유지보수로 이동한다

AWS의 학습 컨테이너 스택에는 분산 실행 프레임워크인 Ray와 머신러닝 프레임워크인 PyTorch가 포함된다. 또한 GPU 컴퓨팅 플랫폼인 CUDA와 GPU 간 통신을 위한 NVIDIA 라이브러리인 NCCL도 번들로 제공한다.

네트워킹 구성 요소에는 긴밀하게 결합된 워크로드를 위한 AWS 네트워크 인터페이스인 Elastic Fabric Adapter와 AWS OFI NCCL 플러그인이 포함된다. 이 플러그인은 NCCL을 네트워킹 제공자와 연결한다. AWS는 릴리스를 게시하기 전에 결합된 환경을 테스트한다고 밝힌다.

맞춤형 이미지를 선택하는 팀은 이제 동일한 통합 작업을 직접 맡아야 할 이유가 필요하다.

그렇다고 맞춤형 환경이 쓸모없어진 것은 아니다. 조직에는 승인된 의존성, 특수 빌드 또는 내부 배포와 관련된 요구 사항이 있을 수 있다. 이러한 요구는 여전히 타당하다. 부담은 기존 아티팩트가 이미 해결한 패키징 작업을 일상적으로 중복하는 데 있다.

여러 머신에 걸쳐 학습 작업을 실행할 수 있는지 조사하는 가상의 엔지니어링 그룹을 생각해 보자. 이들의 초기 질문은 분산 동작에 관한 것이다. 별도 이미지를 빌드하면 그 질문에 도달하기 전에 또 다른 조사 과제가 생긴다.

유지보수되는 기준 환경은 이 순서를 단축할 수 있다. 그룹은 먼저 참조 환경을 평가하고 실제 비호환성을 기록한다. 맞춤화 여부에 대한 결정은 실행 전에 세운 가정이 아니라 워크로드에서 수집한 증거를 따른다.

이는 한 컨테이너가 항상 더 나은 성능을 낸다는 주장이 아니라 운영상 비교다. 신중하게 유지보수된 내부 이미지는 동일한 기술 요구 사항을 충족할 수 있다. 차이는 소유권, 업데이트 절차, 환경을 계속 사용 가능하게 유지하는 데 필요한 노력에 있다.

공개된 이미지는 팀이 자체 플랫폼 작업을 설명하는 방식도 바꾼다. 더 적은 소프트웨어를 패키징한다고 해서 기여가 줄어드는 것은 아니다. 플랫폼 엔지니어는 액세스 제어, 리소스 배치, 관측 가능성, 조직의 학습 워크로드 요구 사항에 집중할 수 있다.

기준 환경이 공유되면 이러한 책임을 분리하기가 더 쉬워진다. 여러 실험이 같은 환경을 사용한다면 검토자는 코드와 구성의 차이에 집중할 수 있다. 실험마다 별도 이미지를 사용하면 이 비교를 정리하기가 어려워진다.

이점은 여전히 도입 규율에 달려 있다. 팀은 어떤 아티팩트를 사용했고 어떤 추가 의존성을 도입했는지 기록해야 한다. 그렇지 않으면 명목상 공유되는 기준 환경이 작업 간 서로 다른 실행 환경을 숨길 수 있다.

따라서 Ray Train DLC는 유지보수의 면제가 아니라 유지보수에 관한 선택지를 제공한다. AWS는 공개된 조립 환경을 책임진다. 이를 도입하는 조직은 수용 기준, 배포 정책, 업데이트 시점에 대한 결정을 책임진다.

합리적인 내부 검토에서는 맞춤형 환경이 무엇을 가능하게 하는지, 누가 이를 유지보수하는지, 호환성을 어떻게 확인하는지를 물어야 한다. 이 질문들은 공개 컨테이너가 우세하다고 전제하지 않는다. 다만 평가할 수 있을 만큼 상충 관계를 가시화한다.

더 넓은 함의는 간단하다. 애플리케이션별 작업은 애플리케이션별 패키징을 정당화해야 한다. 워크로드가 유지보수되는 환경에 맞는다면, 또 다른 빌드를 소유하는 일은 지속적인 의무를 수반하는 선택이 된다.

FSDP는 네트워킹을 학습 설계의 일부로 만든다

샤딩은 GPU가 협력하는 방식을 바꾸기 때문에 네트워킹 스택이 중요하다. 완전 샤딩 학습에서 FSDP는 파라미터, 그래디언트, 옵티마이저 상태를 워커 간에 분산한다. 파라미터는 학습된 값을 보유하고, 그래디언트는 업데이트를 안내하며, 옵티마이저 상태는 업데이트 과정을 추적한다.

샤딩된 단위가 계산하기 전에 워커는 필요한 파라미터를 수집한다. 역방향 계산 후에는 그래디언트를 동기화하고 분할한다. 이 방식은 복제된 상태를 줄이는 대신 학습 설계가 수용해야 하는 통신을 도입한다.

메모리 절감과 통신 요구 사항은 동일한 엔지니어링 결정에 포함돼야 한다.

이 상충 관계는 호환되는 네트워킹 라이브러리를 제공하는 일이 실질적 가치가 있는 이유를 설명한다. 학습 환경에는 단순히 작동하는 모델 import 이상이 필요하다. 선택한 분산 전략에 필요한 교환도 지원해야 한다.

관련된 비교는 단순히 GPU가 많으냐 적으냐가 아니다. 통신 비용을 고려한 뒤에도 워크로드가 상태 분산의 이점을 얻는지 여부다. 성공적인 실행은 동작 가능성을 입증하고, 성능 측정은 그 구성이 유용한지를 입증한다.

PyTorch는 이 균형이 달라지기 때문에 여러 샤딩 전략을 문서화한다. 완전 샤딩은 더 많은 상태를 분산하고, 하이브리드 방식은 머신 내부의 샤딩과 머신 간 복제를 결합한다. 이러한 선택지가 존재한다는 사실은 참조 구성을 보편적 최적값으로 취급해서는 안 된다는 근거가 된다.

또 다른 분산 학습 시스템인 DeepSpeed는 중요한 업계 참고 사례를 제공한다. ZeRO 접근 방식 역시 학습 상태를 분할한다. PyTorch는 DeepSpeed의 ZeRO Stage 3를 FSDP의 영감으로 명시하며, AWS 샘플을 확립된 기술적 흐름 안에 위치시킨다.

이러한 맥락은 새로움을 적절한 수준으로 유지한다. 여기서 AWS의 기여는 패키징된 실행 환경과 배포 경로에 관한 것이다. 복제된 학습 상태를 줄인다는 기본 개념은 이 가이드보다 앞선다.

접근 방식을 비교하는 팀에 유용한 질문은 어떤 전략이 모델과 운영 제약에 맞는가이다. 컨테이너의 가용성은 한 접근 방식을 조사하는 데 필요한 노력을 줄일 수 있다. 하지만 분산 학습 시스템 간의 비교를 결정하지는 않는다.

하드웨어 설명에도 주의가 필요하다. AWS는 g6.12xlarge에 NVIDIA L4 GPU 4개, 호스트 메모리 192 GiB, 40 Gbps 네트워킹이 있다고 명시한다. 이 사양은 이 워크로드에서 측정된 학습 처리량이 아니라 인스턴스를 설명한다.

네트워크 대역폭 수치만으로 실험이 얼마나 빨리 끝날지를 답할 수는 없다. 학습에는 계산과 통신이 모두 포함되며, 둘의 관계는 워크로드가 결정한다. 독자는 하드웨어 사양을 애플리케이션 성능 주장으로 바꾸지 않도록 주의해야 한다.

같은 주의는 메모리 추정에도 적용된다. 지속적인 모델 상태가 학습 중 발생하는 모든 할당을 나타내지는 않는다. 중간 계산, 임시 버퍼, 워크로드 설정도 작업이 적합한지 평가할 때 중요하다.

실질적인 해석은 샤딩이 엔지니어링상의 교환을 만든다는 것이다. 특정 메모리 요구를 줄이는 대신 조율을 늘린다. 패키징된 네트워크 스택은 모든 워크로드에 유리한지 결정하지 않으면서 이 교환의 필수 부분을 해결한다.

이 때문에 통신 경로는 명시적으로 검증할 가치가 있다. 컨테이너는 구성 요소를 제공하지만, 실험은 그 구성 요소가 실제 클러스터에서 어떻게 동작하는지 확인해야 한다.

컨테이너는 고정된 채 클러스터 구성은 달라진다

AWS의 KubeRay 배포 가이드는 이미지가 Kubernetes에 어떻게 들어맞는지 보여준다. KubeRay는 Ray 리소스를 관리하는 컨트롤러인 오퍼레이터다. RayCluster 구성은 조율을 담당하는 헤드와 컨테이너를 실행하는 Kubernetes 단위인 워커 Pod를 설명한다.

이 가이드는 GPU 워커를 헤드와 분리합니다. 또한 이미지의 Ray 버전, Ray가 알리는 GPU 수, Kubernetes 리소스 할당이 일치해야 합니다. 이는 이미지와 관련된 구성 책임입니다.

이미지 빌드를 생략하면 클러스터 구성이 배포의 명시적인 일부로 남습니다.

이 경계는 그렇지 않으면 얽히기 쉬운 질문들을 분리해 준다는 점에서 유용합니다. 이미지는 제공되는 소프트웨어 환경을 결정합니다. 클러스터 구성은 해당 환경이 어디에서 실행되고 프로세스에 어떤 장치가 할당되는지를 결정합니다.

장치 가용성은 특히 중요합니다. 컨테이너 내부의 라이브러리는 사용하도록 설계된 장치에 대한 접근 권한을 대신할 수 없습니다. 따라서 배포 검토에서는 패키지화된 종속성과 워커에 할당된 리소스를 모두 살펴봐야 합니다.

Ray Train의 런처는 또 다른 조정 계층을 추가합니다. TorchTrainer는 워커 프로세스 전반에서 훈련 함수를 실행합니다. ScalingConfig는 워커 수와 가속기 요구 사항을 설명하여 이러한 결정을 워커별 훈련 루프 외부에 둡니다.

이 분리는 팀이 변경 사항을 더 명확하게 정리할 수 있게 합니다. 모델 실험이 자동으로 다른 클러스터 토폴로지를 요구해서는 안 됩니다. 클러스터 용량의 변경도 자동으로 모델 훈련 로직을 다시 작성해야 한다는 뜻은 아닙니다.

재현 가능한 평가를 위해 유용한 산출물은 실행을 둘러싼 선택 사항 전체입니다. 여기에는 이미지 식별자, 클러스터 구성, 작업 코드, 워크로드 설정이 포함됩니다. 모델 이름만 기록하면 설명되지 않는 부분이 너무 많습니다.

“재현 가능”이라는 말에도 범위를 정한 의미가 필요합니다. 배포 입력을 반복하는 것은 동일한 훈련 결과를 보장하는 것과 다릅니다. 팀은 인프라, 실행 동작, 모델 품질 결과 중 무엇을 재현하는지 밝혀야 합니다.

공개된 구성은 그중 첫 번째를 확립하는 데 도움이 될 수 있습니다. 이는 로컬 수정 사항을 검토할 수 있는 기준점을 제공합니다. 수정된 설정이 왜 다르게 동작하는지 설명할 필요까지 없애 주지는 않습니다.

워크로드 변경도 인프라 변경과 같은 수준의 주의를 받아야 합니다. 제출 시점에 종속성을 추가하면 기본 이미지를 유지하면서 작업 환경을 변경할 수 있습니다. 이러한 추가 사항도 실험 기록에 포함되어야 합니다.

바로 이 지점에서 팀 문서화가 운영상 유용해집니다. 엔지니어는 관찰 결과 자체와 함께 그 관찰을 만들어 낸 구성에 접근할 수 있어야 합니다. 완료된 작업의 스크린샷만으로는 그 뒤의 모든 결정을 설명할 수 없습니다.

검색 가능한 지식 베이스는 팀이 배포 결정과 조사 메모를 보존하는 데 도움이 될 수 있습니다. 이는 구성 파일이나 로그를 대체하지 않으면서 검토와 인수인계를 지원합니다.

따라서 고정 이미지 접근 방식은 복잡성을 정리하는 방식을 바꿉니다. 소프트웨어 패키징을 공유 기준선으로 만들고 배포 차이는 구성에서 드러나게 합니다. 팀은 참조 설정을 자체 표준으로 간주하기 전에 여전히 그러한 차이를 점검해야 합니다.

합성 실행만으로는 유용한 파인튜닝을 입증할 수 없다

샘플의 무작위 입력은 의도적인 단순화입니다. 데이터셋을 초기 설정의 일부로 만들지 않고도 실행 경로를 점검할 수 있게 합니다. 독자가 결과가 무엇을 입증하는지 이해한다면, 이는 인프라 점검에 적절합니다.

완료된 분산 작업과 유용하게 훈련된 모델에는 서로 다른 증거가 필요합니다.

첫 번째는 실행에 관한 것입니다. 워커가 시작되고, 참여하며, 요청된 계산을 완료하는지 여부입니다. 두 번째는 학습에 관한 것입니다. 결과 모델이 정의된 작업에서 허용 가능한 성능을 내는지 여부입니다. 어느 결과도 자동으로 다른 결과를 제공하지는 않습니다.

이 구분은 브리프가 기존 모델에 추가 훈련을 수행한다는 의미의 파인튜닝을 설명하기 때문에 특히 중요합니다. 예시는 해당 모델에서 훈련 작업을 실행합니다. 무작위 입력은 실제 작업에서의 개선을 입증하지 않습니다.

따라서 샘플을 적용하는 팀은 자사 데이터가 답하도록 의도된 질문을 정의해야 합니다. 여기에는 훈련 후 어떤 동작을 허용 가능한 것으로 볼지 결정하는 일도 포함됩니다. 이 정의가 없으면 인프라 성공이 제품 진척도를 보여 주는 오해의 소지가 있는 대리 지표가 될 수 있습니다.

평가는 훈련 중 사용되는 수치적 목표값인 손실의 해석도 바꿉니다. 보고된 손실 값은 구성된 계산을 설명합니다. 그것만으로는 조정된 모델이 배포 요구 사항을 충족한다는 사실을 입증하지 못합니다.

다음 경계는 저장된 진행 상태에 관한 것입니다. Ray의 영구 스토리지 가이드는 멀티 노드 훈련에서 체크포인트를 위한 공유 대상 위치를 요구합니다. 체크포인트는 훈련 상태를 보존하므로 작업을 재개하거나 나중에 결과를 사용할 수 있습니다.

Ray는 체크포인트를 저장하는 워크로드와 지표만 보고하는 실행을 구분합니다. 체크포인트를 저장하지 않으면 지표는 로컬에서 집계할 수 있습니다. 따라서 합성 실행 점검은 장기 훈련 워크로드에 필요한 스토리지 동작을 입증하지 못한 채 완료될 수 있습니다.

이 구분은 실무상 중요한 결과를 낳습니다. 팀은 가치 있는 훈련에 이 설정을 의존하기 전에 필요한 상태를 저장하고 다시 불러올 수 있는지 검증해야 합니다. 컨테이너를 재시작하는 것은 실험의 진행 상태를 복구하는 것과 같지 않습니다.

소유권 문제도 여기서 다시 등장합니다. 공개된 이미지는 호환되는 라이브러리를 제공할 수 있지만, 채택하는 팀은 산출물이 저장될 위치와 접근 가능한 사람을 여전히 정의해야 합니다. 이러한 요구 사항은 워크로드와 조직에서 비롯됩니다.

성능 주장은 그 자체의 증거도 필요합니다. 소스 안내서는 구성을 제시하고 검증 경로를 설명합니다. 이를 이 구성이 Qwen에 가장 빠른 선택지임을 보여 주는 독립적인 비교로 읽어서는 안 됩니다.

공정한 비교는 대안을 살피는 동안 워크로드와 측정 조건을 일관되게 유지해야 합니다. 그렇지 않으면 입력 처리나 훈련 설정의 차이가 인프라 비교가 실제로 측정하는 대상을 흐릴 수 있습니다.

이 이야기를 논쟁적으로 보이게 하려고 비판적 반응을 꾸며낼 이유도 없습니다. 문서화된 기술적 한계만으로도 충분한 검토가 가능합니다. 적절한 질문은 증거가 의도한 운영 결정을 뒷받침하는지 여부입니다.

인프라 개념 증명으로서 이 샘플은 정의된 실행 경로를 다룹니다. 프로덕션 도입을 위해서는 팀의 데이터, 산출물, 복구, 작업 결과에 관한 추가 증거가 필요합니다. 이러한 결정을 분리해 두면 샘플과 그 한계를 모두 더 쉽게 활용할 수 있습니다.

실제 워크로드, 전송 증거, 이미지 업데이트를 주시하라

다음으로 유용한 전개는 구체적인 엔지니어링 관찰입니다. 향후 몇 달간 독자는 공개된 환경을 실제 훈련 작업의 요구와 연결하는 증거를 찾아야 합니다. 특히 세 가지 신호가 중요하며, 순서도 정해져 있습니다.

가장 강력한 후속 자료는 합성 입력을 대체한 뒤에도 무엇이 반복 가능한지 보여 줄 것입니다.

첫째, 훈련 동작과 작업 평가를 모두 포함한 실제 워크로드 보고를 주시해야 합니다. 보고서는 결과를 해석할 수 있을 만큼 모델, 데이터 처리, 설정을 명확히 식별해야 합니다. 완료만으로는 조정된 모델의 품질을 입증할 수 없습니다.

체크포인트 복구도 그 증거에 수반되어야 합니다. 저장된 상태에서 성공적으로 재개되는 워크로드는 합성 실행이 남겨 둔 운영상 질문에 답합니다. 이는 초기 연결성 점검을 넘어 해당 환경을 도입해야 할 근거를 강화할 것입니다.

실망스러운 작업 결과가 컨테이너를 자동으로 무효화하는 것은 아닙니다. 데이터와 훈련 선택도 결과에 영향을 미칩니다. 유용한 보고서는 실행 실패와 모델링 실패를 분리하여 시스템의 어느 부분에 주의가 필요한지 명확히 합니다.

둘째, 통제된 성능 측정과 함께 제시되는 전송 증거를 주시해야 합니다. 전송 증거란 워커가 실제로 어떤 통신 경로를 사용했는지 보여 주는 관찰을 의미합니다. 이러한 관찰은 EFA 지원 인스턴스의 존재만으로 추론하는 대신 처리량 결과와 함께 제시되어야 합니다.

비교는 연결성과 효율성도 구분해야 합니다. 의도한 경로가 작동함을 확인하는 것은 결과를 해석하는 데 필요합니다. 그렇다고 워크로드가 사용 가능한 하드웨어를 효율적으로 활용한다는 사실까지 입증하는 것은 아닙니다.

이러한 조건을 공개하는 보고서는 패키징 주장을 강화할 것입니다. 이는 팀이 자체 환경에서 제공된 스택의 동작을 점검할 수 있음을 보여 줄 것입니다. 반대로 설명되지 않은 차이는 추가 진단이나 더 명확한 지침이 필요한 영역을 드러낼 것입니다.

셋째, 이미지 업데이트가 반복 가능한 실험에 어떻게 반영되는지 주시해야 합니다. AWS의 변경 로그는 이미 릴리스와 번들 구성 요소를 구분합니다. 컨테이너를 도입하는 팀은 자체 업데이트 프로세스가 이전 실행 환경의 식별성을 어떻게 보존하는지 평가해야 합니다.

컨테이너 이미지의 콘텐츠 식별자인 다이제스트는 특정 실행에서 사용된 아티팩트를 기록하는 데 도움이 됩니다. 이 기록은 구성 및 워크로드 변경과 함께 남겨야 합니다. 그렇지 않으면 팀은 어떤 변경이 다른 결과를 설명하는지 판단하는 데 어려움을 겪을 수 있습니다.

이 신호는 Ray Train DLC의 지속적인 유지보수 가치와 관련됩니다. 조직이 업데이트를 신중하게 도입하고 회귀를 명확히 조사할 수 있을 때 공개된 환경은 지속적인 가치를 제공합니다. 초기 빌드 단계의 제거는 그러한 관계의 일부일 뿐입니다.

지금 샘플을 평가하는 독자라면, 먼저 결정에 필요한 증거를 정의하십시오. 공개된 구성을 참조점으로 사용하고 정확한 환경을 기록하며 연결성 점검을 워크로드 결과와 분리하십시오. 그다음 실제 데이터를 도입하고 저장 상태 복구를 검증하며 일관된 조건에서 측정치를 비교하십시오. 다른 엔지니어가 무엇이 바뀌었는지 이해할 수 있도록 배포 기록을 훈련 결과와 함께 보관하십시오. Ray Train DLC는 팀에 유지관리되는 시작 환경을 제공하며, 이를 업무에 적합하게 만드는 증거는 도입하는 팀이 마련합니다. 현재 훈련 프로세스의 어느 부분에 실제로 커스텀 이미지가 필요하며, 어느 부분은 먼저 이 공유 기준선을 평가하는 편이 도움이 될까요?