Amazon Trainium 학습, 네이티브 PyTorch로 Nvidia에 도전

Amazon은 10월 20일 Trainium용 네이티브 PyTorch 지원을 출시하며, 연구자들이 이미 사용하는 워크플로를 통해 Nvidia의 학습 소프트웨어 우위에 도전장을 냈다. 이제 Amazon Trainium 학습에는 PyTorch 모델 코드를 Amazon의 가속기에 연결하는 소프트웨어 구성 요소인 TorchNeuron이라는 공개 베타 백엔드가 제공된다. PyTorch는 개발자가 모델을 정의하고 학습하며 실행하는 데 사용하는 프레임워크다.

이 변화가 중요한 이유는 학습 하드웨어 경쟁이 연산 성능만으로 결정되지 않기 때문이다. 연구자들은 낯선 디바이스에 맞춰 소프트웨어를 다시 구축하지 않고도 모델을 변경하고, 실패를 점검하며, 실험을 반복해야 한다. 가속 컴퓨팅을 위한 프로그래밍 환경인 Nvidia의 CUDA 플랫폼은 이러한 경험의 기준점으로 남아 있다.

10월 23일자 SemiAnalysis 평가는 컴파일 지연과 미완성 호환성 문제와 함께 고무적인 실사용 증거를 제시했다. 새롭게 형성되는 경쟁의 핵심은 Amazon이 Trainium을 일상적인 연구에 실용적인 선택지로 만들 수 있는지에 있다. 이는 Amazon이 학습 워크로드 전반에서 Nvidia를 앞질렀다는 의미는 아니다.

Amazon Trainium 학습, 네이티브 PyTorch 경로 확보

Amazon은 연구자와 자사 칩 사이의 소프트웨어 계약을 바꾸고 있다.

AWS의 TorchNeuron 공개 베타는 Trainium2 및 Trainium3 인스턴스를 지원한다. 회사는 개발자가 표준 PyTorch 인터페이스를 유지하면서 neuron 디바이스를 선택할 수 있다고 설명한다. 또한 디바이스별 연산 루틴을 작성하기 위한 Amazon의 인터페이스인 Neuron Kernel Interface를 통해 커스텀 연산자도 지원한다.

이 발표는 연구자가 이해하는 모델과 반드시 수용해야 하는 하드웨어 스택 사이의 거리라는 실질적 장애물을 겨냥한다. 실험의 별도 버전을 유지해야 한다면, 유망한 가속기라도 매력이 떨어진다.

네이티브 통합은 그러한 수용 작업이 어디에서 이뤄지는지를 바꾼다. 이상적으로는 하드웨어 백엔드가 디바이스별 작업을 더 많이 흡수해 연구자가 기존 모델 정의에 더 가까이 머물 수 있게 한다. 이는 전담 가속기 전문가가 없는 팀에도 Amazon이 보다 분명하게 진입할 수 있는 길을 제공한다.

다만 표현에는 여전히 주의가 필요하다. 네이티브 지원은 통합 방식을 설명하는 말일 뿐, 모든 연산·라이브러리·워크로드에서 동일한 동작을 보장하지는 않는다. 공개 베타라는 점 역시 개발자가 지원 범위가 계속 변화할 수 있음을 예상해야 한다는 신호다.

연구팀에 중요한 구분은 실험을 시작하는 일과 연구 프로그램을 지속하는 일 사이에 있다. 시작하려면 모델이 로드되고 실행되어야 한다. 지속하려면 아키텍처 변경, 디버깅, 평가, 소프트웨어 업데이트가 계속 관리 가능한 수준에 머물러야 한다.

이후의 활동에 더는 예외적인 노력이 필요하지 않게 된다면 Amazon Trainium 학습의 경쟁력은 높아진다. 성공적인 시연은 진입점을 만들 수 있다. 반복되는 일상적 실험이 그 진입점이 신뢰할 수 있는 작업 환경이 되는지를 결정한다.

예를 들어, 언어 모델에서 각 예측에 어떤 정보가 영향을 주는지 결정하는 구성 요소인 어텐션 메커니즘을 수정하는 팀을 생각해 볼 수 있다. 이 팀은 수정안을 기준선과 비교해야 한다. 하드웨어 선택이 별도의 연구 프로젝트가 되어서는 안 된다.

이 사례는 이 발표가 인프라 전문가를 넘어선 이유를 설명한다. 연구자들은 도구가 자신에게 시도할 수 있게 해주는 실험을 기준으로 도구를 선택하기도 한다. 따라서 하드웨어 호환성은 팀이 주어진 시간 안에 탐구할 수 있는 질문에 영향을 미친다.

기업 구매자에게도 시사점은 구체적이다. 조달 비교에는 워크로드를 안정적으로 유지하는 데 필요한 엔지니어링 작업이 포함되어야 한다. 소프트웨어 부담 때문에 실험이 비현실적이라면 디바이스를 이용할 수 있다는 사실만으로는 큰 의미가 없다.

따라서 당장의 변화는 Trainium을 평가하라는 더 폭넓은 초대에 가깝다. AWS는 그러한 평가를 위한 익숙한 인터페이스를 제공했다. 팀이 계속 사용할지는 해당 인터페이스 아래에서의 동작, 특히 코드가 준비된 시연에서 벗어날 때의 동작에 달려 있다.

Nvidia, 연구자들이 시간을 쓰는 지점에서 압박받아

경쟁의 틈새는 고립된 하드웨어 점수가 아니라 연구를 이전하는 데 필요한 노력에 있다.

Nvidia가 이 이야기의 주된 경쟁자인 이유는 Amazon이 GPU 학습을 둘러싼 소프트웨어 습관을 겨냥하고 있기 때문이다. GPU는 병렬 연산을 위해 설계된 프로세서다. 연구자들은 디버깅, 라이브러리, 축적된 팀 지식을 포함해 이를 둘러싼 전체 작업 환경을 평가한다.

이러한 투자는 기존 플랫폼에 머물 강력한 이유가 된다. 조직은 어떤 실패가 일상적인 것인지, 어떤 변경에 주의가 필요한지, 내부 전문성이 어디에 있는지를 알고 있다. 하드웨어를 옮기면 이러한 이해가 흔들릴 수 있다.

Amazon의 접근 방식은 전환 부담을 직접 겨냥한다. 연구자들이 익숙한 인터페이스를 유지할 수 있다면, 시험해 보기 전부터 대안을 거부할 이유가 줄어든다. 구매자가 어느 플랫폼의 성능이 더 나은지 결정하기 전에도 이는 경쟁상 이점이다.

따라서 Nvidia에 가해지는 압박은 구체적이다. AWS는 하드웨어 평가가 연구 프로세스를 덜 방해하도록 만들려 한다. Nvidia는 더 접근하기 쉬운 대안을 얻은 팀들의 선호를 계속 얻어야 한다.

이 압박을 즉각적인 이전 전망으로 혼동해서는 안 된다. 연구실은 기존 GPU 인프라를 유지하면서 Trainium을 검토할 수 있다. 평가는 최종적으로 얼마나 많은 작업이 옮겨갈지를 확정하지 않은 채 선택지를 넓힌다.

대규모 학습 워크플로를 구성하기 위한 PyTorch의 프레임워크인 TorchTitan은 유용한 기준점이다. 이 프로젝트는 모듈형 모델 정의와 구성 가능한 분산 실행, 즉 여러 디바이스에 걸친 연산을 설명한다. 따라서 기존 학습 기반을 조정하는 연구팀에 관련성이 있다.

전략적 가치는 그 기반을 유지하는 데 있다. 팀은 모든 하드웨어 실험이 과학 작업의 영구적인 분기를 만들기를 원하지 않는다. 구현이 서로 가까울수록 결과를 비교하기 쉬워진다.

이 때문에 추론에서의 성공이 학습 적합성을 자동으로 입증할 수는 없다. 추론은 학습된 모델을 사용해 출력을 생성한다. 연구 학습에서는 개발자가 아키텍처, 데이터, 최적화 선택지를 검토하는 동안 모델 파라미터가 변경된다.

서빙 워크로드는 안정된 경로를 세심하게 최적화하는 데 가치를 둘 수 있다. 연구 워크로드는 변화에 대한 관용도 요구한다. 가속기는 공급업체가 특별히 준비하지 않은 실험도 지원해야 한다.

구매자에게 이는 경쟁을 다르게 해석할 필요가 있음을 시사한다. 관련된 질문은 팀이 주어진 인력과 인프라로 얼마나 많은 유의미한 연구를 완료하는가다. 하드웨어 처리량은 설정 노력과 문제 진단 시간과 함께 그 결과에 기여한다.

Amazon이 이러한 추가 부담을 줄인다면 신뢰할 만한 기회를 갖게 된다. Nvidia는 자사 작업 환경이 팀의 생산성을 더 높이는 영역에서 우위를 유지한다. 경쟁 양상은 워크로드, 소프트웨어 의존성, 이를 운영하는 사람들의 전문성에 따라 달라질 것이다.

이러한 차이 때문에 폭넓은 승자 선언은 시기상조다. 동시에 이 발표가 중요한 이유이기도 하다. AWS는 하드웨어 선호가 오래 지속되는 연구자의 업무 시간을 두고 경쟁하고 있다.

네이티브 PyTorch가 실험 반복 과정을 바꾼다

Amazon의 도전 뒤에 있는 메커니즘은 모델 코드 변경부터 동작 평가까지의 경로를 단축하는 데 있다.

AWS의 네이티브 PyTorch 백엔드는 PyTorch의 표준 확장 메커니즘을 사용해 Trainium을 디바이스로 등록한다. 문서는 개발자가 호출할 때 연산이 실행되는 즉시 실행과, 캡처된 연산을 실행 전에 소프트웨어가 최적화하는 컴파일 실행을 설명한다.

이 모드는 실험의 서로 다른 시점에 활용된다. 대화형 실행은 아이디어가 아직 확정되지 않은 동안 개발자가 동작을 점검하는 데 도움이 된다. 연산이 안정화되고 반복 실행에 추가 최적화가 필요해지면 컴파일이 매력적인 선택지가 된다.

실질적인 이점은 연구 코드를 버리지 않고 이 두 시점 사이를 오갈 수 있다는 데 있다. 연구자는 변경 사항을 탐색하고, 작동 여부를 확인한 뒤, 성능을 검토할 수 있다. 이 순서를 지원하는 백엔드는 실험 작업의 실제 진행 과정에 부합한다.

AWS 문서는 익숙한 실행 방식이 컴파일 비용을 없애지는 않는 이유도 설명한다. 이전에 본 적 없는 연산 형태는 처음 사용될 때 컴파일이 필요할 수 있다. 캐시된 결과는 이후 실행에 도움이 될 수 있지만, 최초 대기 시간은 여전히 연구자가 겪는 경험의 일부다.

이 세부 사항은 통합의 이야기를 남은 마찰과 연결한다. 인터페이스는 익숙하게 느껴질 수 있지만 그 아래에서는 낯선 멈춤이 발생할 수 있다. 개발자는 얼마나 많은 반복 시간을 절약할 수 있는지 추정하기 전에 두 계층을 모두 이해해야 한다.

이 관점에서 설명한 TorchNeuron은 책임의 변화다. 더 많은 적응 작업이 백엔드로 옮겨가고, 연구자는 더 익숙한 코드를 유지한다. 지원 범위나 성능이 부족한 영역에서는 디바이스별 엔지니어링이 여전히 필요하다.

같은 문서는 실행 모드별 폴백 동작도 구분한다. 즉시 실행 모드에서는 지원되지 않는 연산자가 경고와 함께 컴퓨터의 범용 프로세서인 CPU에서 실행될 수 있다. 컴파일 환경에서는 백엔드가 변환할 수 없는 연산이 컴파일 실패를 일으킬 수 있다.

이 구분은 성공적으로 실행된 결과를 평가할 때 중요하다. 완료만으로 의도한 연산이 가속기에서 계속 수행됐다는 사실이 입증되지는 않는다. 작동하는 실험과 효율적으로 가속된 실험은 별개의 결과다.

예시 연구 그룹의 경우 평가는 실제 수행하는 작업을 따라야 한다. 표준 모델은 기준선을 만든다. 의미 있는 아키텍처 변경은 호환성이 준비된 경로를 넘어 확장되는지를 드러낸다.

그런 다음 그룹은 과학적 결과와 이를 얻는 데 필요한 노력을 비교할 수 있다. 수정된 실험이 올바르게 동작하지만 광범위한 수리가 필요하다면, 인터페이스 개선은 약속의 일부만 실현한 것이다.

Amazon의 소프트웨어 전략은 이러한 평가 시도를 더 쉽게 만든다. 장기적 가치는 백엔드가 연구자들이 만드는 정돈되지 않은 변경을 얼마나 일관되게 처리하느냐에 달려 있다. 이것이 네이티브 통합과 더 폭넓은 학습 사업을 연결하는 지점이다.

더 접근하기 쉬운 시작점은 잠재 사용자층을 넓힌다. 신뢰할 수 있는 실험 반복 과정은 이 사용자들이 계속 사용할 이유를 제공한다.

품질 관리는 정확성과 대기 시간을 모두 다뤄야 한다

학습 소프트웨어는 결과를 보존하면서 실험을 실용적으로 반복할 수 있게 할 때 신뢰를 얻는다.

SemiAnalysis의 Trainium 학습 테스트는 16개 Trainium2 칩에서 즉시 실행 모드의 Qwen3-32B 처리량이 초당 11,099토큰, 컴파일 모드에서는 14,156토큰이라고 보고했다. 토큰은 언어 모델이 처리하는 텍스트 단위다. 이는 워크로드별 측정치이며 일반적인 Nvidia 비교는 아니다.

이 매체는 gpt-oss 학습 레시피에서 27분 17초의 컴파일 대기 시간이 있었다고도 보고했다. Trainium3 FlexAttention 평가는 96개 사례 중 89개를 통과했으며, 나머지 사례는 컴파일 시간 제한을 초과했다. FlexAttention은 어텐션 변형을 정의하기 위한 PyTorch 인터페이스다.

그러한 결과는 신중한 해석을 뒷받침한다. 이 스택은 실질적인 훈련 실험을 실행할 수 있지만, 대기 시간은 여전히 연구 활용성에 중요한 요소다. 반복 실행이 빨라졌다고 해서 그 단계에 도달하기까지 소요된 시간이 사라지는 것은 아니다.

이 차이는 짧은 실험에서 특히 중요해진다. 아이디어를 검증하는 연구자라면 초기 결과를 얻는 데 걸리는 시간을 더 중시할 수 있다. 더 긴 실행은 준비 비용을 더 많은 유의미한 연산에 분산할 수 있다.

이는 성능 보고에서 준비, 실행, 성공적인 완료를 구분해야 한다는 뜻이다. 이를 하나의 유리한 수치로 합치면 연구자가 플랫폼을 계속 사용할지 결정하는 경험의 핵심 부분을 가릴 수 있다.

정확성에는 또 다른 조건이 따른다. 빠르게 실행되지만 다르게 학습하는 모델은 그 속도가 유용해지기 전에 조사가 필요하다. 수치적 일치는 선택한 정밀도와 테스트 조건에서 계산이 충분히 일관된 결과를 내는지 확인하는 것을 의미한다.

AWS는 TorchNeuron testing methodology에서 광범위한 자동화 테스트를 설명한다. 축소된 구성으로 10만 개의 Hugging Face 모델을 대상으로 모델 스윕을 수행하고, 실행, 컴파일, 폴백 동작을 기록한다고 밝혔다. 이는 공급업체가 보고한 적용 범위 주장이다.

같은 설명에 따르면 8월에 약 15만4,000건의 업스트림 테스트 결과가 나왔고, 이 중 약 6만9,000건은 건너뛰었다. 일부 건너뛰기는 PyTorch 적격성 규칙을 따랐으며, 다른 일부는 Neuron 적용 범위 결정에 따른 것이었다. 초기 제외 항목으로는 희소 연산과 동적 형태가 제시됐다.

소프트웨어 변경 사항을 자동으로 테스트하는 지속적 통합은 여기서 중요하다. 백엔드 개선이 다른 영역의 회귀를 만들 수 있기 때문이다. 유용한 테스트 시스템은 연구자가 비용이 큰 실험 도중 이를 발견하기 전에 그러한 회귀를 식별한다.

테스트 규모만으로 신뢰성을 입증할 수는 없다. 독자는 무엇이 실행됐고, 무엇이 건너뛰어졌으며, 테스트 구성이 자신의 워크로드와 얼마나 유사한지 알아야 한다. 광범위한 카탈로그 스윕은 나열된 모든 모델에 대한 완전한 훈련 검증을 대체할 수 없다.

가장 강력한 근거는 투명한 적용 범위 보고와 재현 가능한 외부 결과를 결합하는 방식일 것이다. AWS의 공개 자료는 그러한 검증을 위한 자료를 제공한다. SemiAnalysis의 경험은 호의적인 출시 문구가 가릴 수 있는 문제를 포함한 외부 관점을 제공한다.

Amazon Trainium 훈련은 두 측면에서 평가받아야 한다. 실험이 정확하게 완료되는지, 그리고 팀이 과도한 지연 없이 이를 반복할 수 있는지다. 한 측면의 진전이 다른 측면의 약점을 가려서는 안 된다.

프로파일러는 Amazon에 또 다른 경쟁 수단을 제공한다

느린 실행에 대한 더 나은 가시성은 초기 결과가 기대에 미치지 못하더라도 가속기를 더 쉽게 개선하게 할 수 있다.

Neuron Explorer는 Amazon의 프로파일링 도구로, 엔지니어가 성능을 조사할 수 있도록 실행을 기록하는 소프트웨어다. AWS의 hardware profiling tools는 시스템 수준 활동과 디바이스 수준 활동을 구분한다. 이 도구는 타임라인, 소스 코드 링크, 종속성 정보, 메모리 뷰를 제공한다.

이 기능들은 호환성과는 다른 문제를 해결한다. 모델이 실행되기 시작한 뒤 개발자는 왜 대기하는지 파악해야 한다. 느린 단계는 연산, 데이터 이동, 통신 또는 가속기 외부에서 수행되는 작업 때문일 수 있다.

총 소요 시간은 증상을 알려 준다. 유용한 추적은 원인을 찾는 데 도움을 준다. 이 차이는 엔지니어가 목표를 정한 변경을 할 수 있는지, 아니면 반복적인 추측을 통해 조사해야 하는지를 결정한다.

예를 들어, 하나의 예시 훈련 작업은 연산이 진행되기 전에 데이터 이동을 기다리는 데 시간을 보낼 수 있다. 산술 연산만 개선해도 그 종속성은 그대로 남는다. 명확한 타임라인은 엔지니어의 관심을 실제로 진행을 제한하는 작업으로 돌릴 수 있다.

이것이 프로파일러 품질이 경쟁 분석에 포함되어야 하는 이유다. 하드웨어 사양은 사용 가능한 역량을 설명한다. 진단 도구는 개발자가 그 역량을 특정 모델에 유용한 실행으로 전환하도록 돕는다.

네이티브 통합과의 연결도 실용적이다. 익숙한 모델 코드는 초기 실행까지의 거리를 줄인다. 명확한 프로파일링은 그 실행에서 동작에 대한 설명에 이르는 거리를 줄인다.

이러한 개선은 함께 훈련을 둘러싼 엔지니어링 작업을 다룬다. 성능 우위를 보장하지는 않는다. 그러나 팀이 그러한 우위가 존재하는지 더 쉽게 발견하게 할 수 있다.

“GPU impossible”이라는 표현에는 절제가 필요하다. SemiAnalysis는 Trainium의 세분화된 프로파일링 경험에 대한 열의를 설명하기 위해 이 표현을 사용한다. 이 표현이 Nvidia 하드웨어에 연산 루틴 내부 활동을 관찰할 수단이 전혀 없다는 주장으로 확대되어서는 안 된다.

Nvidia는 가속기에서 실행되는 루틴인 커널 내부의 이벤트를 기록하는 메커니즘인 in-kernel event tracing을 문서화하고 있다. 이 기능의 존재는 방어 가능한 비교 범위를 특정 작업에서의 통합, 가시성, 개발자 노력으로 좁힌다.

그럼에도 이는 의미 있는 비교다. 두 플랫폼은 관련 정보를 제공할 수 있지만, 이를 수집하고 해석하는 데 필요한 작업량은 다를 수 있다. 관련 판단은 엔지니어가 수행해야 하는 조사 과정에 관한 것이다.

따라서 구매자는 실제로 해결되지 않은 성능 문제를 바탕으로 프로파일러를 평가해야 한다. 매력적인 스크린샷만으로는 도구가 팀의 답을 찾는 데 얼마나 효과적인지 입증할 수 없다. 실행 가능한 진단을 만들어 내는 추적이 더 강력한 근거를 제공한다.

분석은 진단과 해결 사이의 경계도 유지해야 한다. 워크로드가 왜 멈추는지 아는 것이 소프트웨어나 하드웨어가 그 정체를 제거할 수 있음을 보장하지는 않는다. 더 나은 가시성은 적합하지 않은 플랫폼을 거부하는 결정을 포함해 의사결정을 개선한다.

Amazon의 기회는 이러한 결정을 더 빠르고 더 충분한 정보에 기반해 내릴 수 있도록 만드는 데 있다. 이는 모든 워크로드가 유리한 결과를 내지 않더라도 훈련 제안을 강화할 수 있다.

지속 가능한 훈련 대안을 입증할 조건

다음 근거는 반복 시간, 유지되는 호환성, 지원된 시연을 넘어선 채택을 추적해야 한다.

향후 몇 달간 첫 번째 신호는 초기 컴파일 대기 시간의 재현 가능한 감소다. 릴리스 발표는 동일한 모델 및 의미 있는 아키텍처 변경 사항과 함께 비교되어야 한다. 그렇지 않으면 더 빠른 결과는 다른 실험을 반영했을 수 있다.

중요한 결과는 신뢰할 수 있는 결과에 이르는 경로가 짧아지는 것이다. 정확성과 반복 실행이 비슷한 수준으로 유지되는 가운데 준비 과정이 개선된다면 Amazon의 연구 제안은 강화된다. 일반적인 변경에서도 대기가 지속된다면 네이티브 인터페이스는 상당한 부담을 해결하지 못한 채 남는다.

이 평가는 새 실행과 반복 실행을 모두 포함해야 한다. 연구자는 캐시된 컴파일 결과에서 비롯된 이점과 익숙하지 않은 워크로드에 도움이 되는 개선을 구분해야 한다. 둘 다 중요하지만 일상적 활용성에 대해서는 서로 다른 질문에 답한다.

두 번째 신호는 소프트웨어 업데이트를 견디는 호환성이다. 출시 시점의 인터페이스 지원은 출발점을 마련한다. 팀은 연구가 변화하는 과정에서도 모델, 종속성, 디바이스 백엔드가 계속 함께 작동해야 한다.

새롭게 지원되는 연산, 남아 있는 제외 항목, 회귀에 대한 투명한 보고를 지켜봐야 한다. 예외 목록이 줄어들면 Amazon이 더 많은 적응 작업을 흡수하고 있다는 근거가 강화된다. 사용자 코드에서 반복적인 수정이 필요하다면 그 근거는 약해진다.

이 지점에서 개발 전략으로 설명되는 TorchNeuron은 출시 슬로건보다 더 유용해진다. 그 가치는 사용자가 시간이 지나면서 피할 수 있는 하드웨어별 유지보수의 양에 달려 있다. 인터페이스는 그 약속의 시작이다.

세 번째 신호는 다양한 훈련 워크로드를 실행하는 팀의 상세한 보고다. 유용한 설명은 무엇을 옮겼는지, 무엇을 조정해야 했는지, 무엇이 기존 인프라에 남았는지를 밝혀야 한다. 또한 일반적인 공급업체 지원과 예외적인 엔지니어링 지원을 구분해야 한다.

이러한 보고는 독자가 경험이 준비된 레시피를 넘어 확장되는지 판단하는 데 도움이 된다. 독립적인 재현은 근거를 더욱 강화한다. 좁은 범위의 시연만으로는 실질적 채택의 폭을 확신하기 어렵다.

독자에 따라 의미도 다르다. 개발자는 실제 실험에 맞춰 평가할 또 하나의 환경을 얻는다. 기업 구매자는 마이그레이션 노력과 유지보수에 대해 더 정확한 질문을 던질 이유를 얻는다.

AI 제품 사용자는 간접적인 영향을 예상해야 한다. 더 나은 인프라 선택은 제품 팀이 엔지니어링 시간을 배분하고 모델 개선을 추진하는 방식에 영향을 줄 수 있다. 이 발표 자체가 사용자가 접하는 애플리케이션의 특정 개선을 입증하는 것은 아니다.

전환 과정을 따르는 팀은 유리한 결과와 함께 벤치마크 설정, 소프트웨어 버전, 실패 설명을 보존해야 한다. searchable knowledge base는 다음 백엔드 릴리스가 비교 기준을 바꿀 때에도 그러한 근거를 계속 활용할 수 있게 한다.

팀이 잘 이해하는 연구 워크로드부터 시작한 뒤, 코드 변경부터 검증된 결과까지의 전체 경로를 평가하라. 준비 시간, 실행 동작, 디버깅 노력, 유지보수 필요 사항을 기록하라. 비교는 반복하려는 작업에 연결해 유지하라. Amazon Trainium 훈련은 이제 이 평가에 더 익숙한 경로를 제공하며, 퍼블릭 베타는 남은 격차를 더 넓은 사용자층에 드러낸다. 호환성 공개 자료를 성능 결과와 함께 읽고, 소프트웨어가 발전함에 따라 결정을 다시 검토하라. 유용한 질문은 팀이 보유한 자원으로 더 신뢰할 수 있는 실험을 얼마나 더 많이 완료할 수 있는가다. 자신의 워크로드에서 그 결과를 입증하는 플랫폼을 선택하라.