AMD EPYC, Google TPU 8tx 구동… GPU 서버를 넘어 역할 확대
AMD는 11월 9일 5세대 EPYC 프로세서가 Google의 TPU 8tx 호스트를 구동하며, AI 인프라에서의 역할을 GPU 서버를 넘어 확장한다고 발표했다. AMD EPYC TPU 배포는 범용 프로세서와 AI 연산용 특수 가속기인 Google의 Tensor Processing Unit을 결합한다. 핵심 약속은 기존의 스토리지 및 네트워크 암호화만으로는 빈틈이 남는 처리 과정 중 민감한 정보를 보호하는 데 있다.
이로써 이번 발표는 통상적인 가속기 속도 경쟁을 넘어선 의미를 갖는다. Google은 EPYC 조합을 독립적으로 확인했으며, 이는 Google의 맞춤형 AI 하드웨어 플랫폼 내 AMD의 명시된 배포 사례를 제공한다. 경쟁의 핵심은 Intel도 겨루는 영역인, 해당 가속기 아래에서 신뢰 기반을 공급하는 주체가 누구인지에 있다.
기업 구매자에게 당면한 문제는 실질적이다. 즉, 이 시스템이 수용하기 어려운 운영상 마찰 없이 기밀 워크로드를 지원할 수 있는지다. AMD에게 전략적 기회는 더 넓다. 가속기 고객은 Google 실리콘을 선택하면서도 EPYC 프로세서 수요를 만들 수 있다.
AMD EPYC TPU 배포가 실제로 바꾸는 것
이번 발표는 새로운 EPYC 프로세서 세대를 소개하는 것이 아니라, 구체적인 호스트 배포 사례를 확립한다.
AMD는 TPU 호스트 배포에서 5세대 EPYC를 Google Cloud TPU 8tx의 프로세서 기반으로 명시했다. AMD는 데이터 준비, 워크로드 조정, 가속기와의 통신에 걸친 역할을 설명한다.
AMD는 또한 이 시스템이 가속기 보안 제어와 함께 가상화 워크로드 보호 기술인 Secure Encrypted Virtualization을 사용한다고 밝혔다. 회사에 따르면 가속기 검증은 보호된 메모리에 접근하기에 앞서 이뤄진다. AMD의 설명은 암호화된 호스트 메모리와 전송, 가속기 실행 중의 하드웨어 격리를 결합한다.
이는 구체적인 아키텍처 주장이다. 이를 플랫폼에서 실행되는 모든 애플리케이션이 안전하다는 포괄적 표현으로 확대해서는 안 된다. 발표는 보호된 컴퓨팅 기반을 제시하지만, 애플리케이션 설계와 운영 정책은 별개의 문제로 남는다.
AI 서비스는 주된 수치 계산보다 더 큰 범위이므로 이 구분은 중요하다. 정보는 애플리케이션을 통해 들어와 지원 소프트웨어를 거쳐 모델에 도달하고, 궁극적으로 출력이 된다. 프로세서 배포는 이러한 단계를 수용 가능한 보안 설계 아래 연결하는 데 기여할 때 전략적 의미를 갖는다.
AMD에게 명시된 Google 배포 사례는 해당 설계에 참여한다는 근거를 제공한다. 이것이 Google이 구매할 프로세서 수량을 확립하는 것은 아니다. 또한 해당 배포가 AMD 매출에 기여하는 규모나 상업적 조건, 다른 호스트 프로세서를 대체하는 일정도 공개하지 않는다.
독자는 고객 선택과 시장 리더십 측정도 구분해야 한다. 명시된 배포 사례는 산업 지배력 주장보다 더 제한적인 결론을 뒷받침한다. 리더십을 확립하려면 출하량, 설치된 시스템, 워크로드 범위 또는 다른 명확히 정의된 지표 전반에서 비교 가능한 근거가 필요하다.
그러한 제한적인 결론도 여전히 중요하다. AMD는 이를 지원하는 프로세서를 통해 맞춤형 가속기 배포에 참여할 수 있다. 따라서 AMD의 기회는 고객이 AMD 자체 AI 가속기를 선택하는 시스템을 넘어 확장된다.
구매자에게 유용한 변화는 평가할 수 있는 또 하나의 식별된 구성이다. 조달팀은 이제 기밀 AI를 전반적 개념으로만 논의하는 대신, 이 특정 조합에 관해 목표를 분명히 한 질문을 할 수 있다. 이는 기술 실사의 출발점을 개선하지만, 평가를 완료하는 것은 아니다.
이번 발표는 구매 논의의 어휘도 바꾼다. 의도된 워크로드에 민감한 데이터가 포함될 경우 호스트 선택은 가속기 선택과 함께 다뤄져야 한다. 이를 부수적인 서버 세부 사항으로 취급하면 실행과 보호 모두에 관여하는 구성 요소를 간과할 위험이 있다.
Google, 기존 TPU 실리콘을 중심으로 보안 구성
Google의 발표는 시스템 구성을 강조하며, 맞춤형 가속화를 중심으로 설계된 제품에서 호스트 프로세서에 가시적인 역할을 부여한다.
Google은 TPU 8tx 시스템이 TPU 8t와 동일한 실리콘을 사용하고 5세대 EPYC 호스트와 결합한다고 밝혔다. Google은 이 구성을 기밀 추론, 즉 기존 모델을 실행해 출력을 생성하는 작업과 더 작은 규모의 학습 워크로드에 맞춰 제시한다.
Google은 추가 학습 데이터를 사용해 기존 모델을 조정하는 미세 조정도 지원한다고 설명한다. 제안된 대상에는 민감한 정보를 다루는 규제 산업의 기업과 정부가 포함된다. 회사는 전문 암호화 기능에 대한 수요가 고객 피드백에서 비롯됐다고 설명한다.
이러한 포지셔닝은 이번 발표가 시스템 제공 형태로 나오는 이유를 설명한다. 민감한 AI 워크로드를 평가하는 구매자에게는 모델을 실행할 수 있는 가속기만으로 충분하지 않다. 보안팀이 평가할 수 있고 운영팀이 유지할 수 있는 환경이 필요하다.
기밀 엔지니어링 기록을 검토하는 가상의 기업용 어시스턴트를 생각해 보자. 모델의 답변은 중요하지만 문서와 조직의 독점 모델도 자산이다. 배포 결정은 둘 사이에서 정보를 이동시키는 소프트웨어를 포함해 이들 모두를 고려해야 한다.
더 빠른 가속기만으로는 이 결정을 해결할 수 없다. 조직이 주변 환경을 승인할 수 없다면 추가 연산 속도는 구매 가치가 제한적이다. 따라서 보안은 사용 가능한 용량을 활용하기 위한 전제조건이 될 수 있다.
이는 고객이 이미 시스템을 승인하거나 배포했다는 근거가 아니라 제품 포지셔닝에서 도출되는 분석적 함의다. 공급업체의 목표 고객층이나 출시 설명 어느 것도 도입을 확립하지 않는다. 구매자는 여전히 자체 요구사항과 연결된 근거가 필요하다.
기존 실리콘에 대한 강조는 여기서 혁신을 해석하는 방식도 바꾼다. 새로운 시스템은 새 가속기 칩을 도입하지 않고도 다른 운영 요구사항을 해결할 수 있다. 상업적 질문은 이 구성이 구매자가 인식하고 검증할 수 있는 문제를 해결하는지 여부가 된다.
이는 기술적 역량과 배포 가능한 역량 사이에 유용한 구분을 만든다. 기술적 역량은 구성 요소가 무엇을 지원하는지에 관한 것이다. 배포 가능한 역량에는 이를 책임 있게 사용하기 위해 필요한 주변 소프트웨어, 문서화된 한계, 지원 체계, 승인 절차가 포함된다.
AMD에게 이러한 구분은 통합에 주목하게 한다. 호스트 프로세서는 완전한 배포 요구사항에 부합할 때 더 큰 가치를 갖는다. 전략적 이점은 단순히 독립적으로 경쟁력 있어 보이는 사양을 갖는 데 있지 않고, 시스템에 기여하는 방식에 달려 있다.
Google에게 이 제품은 보호된 AI 처리에 관해 질문하는 고객에게 더 구체적인 답을 제공한다. 그 답이 충분한지는 고객이 검토할 수 있는 세부 사항에 달려 있다. 제품 발표는 그 대화를 시작하지만, 실제 운영 근거가 그 범위를 결정한다.
Intel, 동일한 신뢰 호스트 역할을 두고 경쟁
핵심 경쟁은 보호된 AI 실행 아래의 프로세서 플랫폼에 관한 것이며, AMD와 Intel은 모두 이 계층에 진입할 경로를 제공한다.
Intel의 복합 인증 워크플로는 보호된 CPU 환경과 AI에 널리 사용되는 가속기인 지원 NVIDIA 그래픽 처리 장치의 증거를 결합한다. 인증은 비밀 정보를 맡기기 전에 컴퓨팅 환경에 관한 암호학적 증거를 확인하는 것을 의미한다.
Intel은 기밀 가상 머신을 위한 하드웨어 보호 기능인 Trust Domain Extensions를 이 구성의 일부로 설명한다. 가상 머신은 공유 하드웨어에서 실행되는 격리된 소프트웨어 컴퓨터다. Intel 문서는 GPU만의 검증으로는 완전한 기밀 컴퓨팅 솔루션을 확립할 수 없다고 설명한다.
이는 AMD의 Google 배포 사례에 대한 구체적인 경쟁 기준을 제공한다. Intel은 다른 가속기 생태계에 참여하지만, 구매 질문은 겹친다. 어떤 호스트 플랫폼이 구매자에게 필요한 보호된 환경을 지원하는가?
이 비교가 TPU와 GPU 시스템 간 동등성을 확립하는 것은 아니다. 소프트웨어 요구사항, 지원되는 구성, 운영 특성은 별도로 평가해야 한다. 다만 호스트 프로세서 보안이 일반적인 서버 벤치마킹을 넘어 경쟁상 중요성을 갖는 이유는 보여준다.
이러한 경로 중 선택하는 구매자는 의도된 애플리케이션에서 시작해야 한다. 지원되는 모델과 승인된 보안 설계는 느슨하게 비교 가능한 헤드라인보다 중요하다. 어느 공급업체의 아키텍처 설명도 모든 워크로드에 대한 보편적 승자를 제시하지는 않는다.
AMD에게 Google과의 조합은 차별화된 기준점을 만든다. Intel에게 NVIDIA와의 문서화된 작업은 확립된 경쟁 접근법을 보여준다. 양사 모두에 대한 압력은 전체 구성을 더 쉽게 평가하고 배포하며 유지할 수 있도록 만드는 데 있다.
이러한 압력은 효과적인 영업 논증에 필요한 요소를 바꾼다. 프로세서 성능은 여전히 중요하지만, 민감한 워크로드는 증거 수집, 소프트웨어 지원, 보호된 정보의 처리에 관한 질문도 제기한다. 경쟁 제안은 이들을 함께 다뤄야 한다.
호스트 플랫폼은 엔지니어링 노력에도 영향을 미칠 수 있다. 시스템 간 이동에는 배포 절차, 검증 기록, 운영 도구의 변경이 필요할 수 있다. 구매자는 유사한 보안 용어가 손쉬운 마이그레이션을 뜻한다고 가정하지 말고 이러한 요구사항을 직접 검토해야 한다.
이는 명확한 문서화에 대한 유인을 만든다. 한계가 이해 가능한 플랫폼은 보안 검토자에게 평가할 구체적인 대상을 제공한다. 여러 공급업체가 시스템의 서로 다른 부분을 제공할 때는 특히 포괄적인 보장이 추가 질문을 낳는다.
따라서 경쟁의 이해관계는 단일 설계 선택보다 더 넓다. 각 배포는 고객 요구사항과 시스템 통합에 대한 공급업체의 경험을 강화할 수 있다. 그러나 향후 선택은 여전히 별개의 결정이며, 이번 발표가 독점성을 확립하는 것은 아니다.
AMD EPYC TPU 배포는 AMD에 이 경쟁에서 구체적인 위치를 제공한다. Intel의 경쟁 작업은 이번 발표를 경쟁 없는 카테고리 승리로 해석하는 것이 타당하지 않음을 보여준다. 의미 있는 비교는 검증된 구성과 구매자 요구사항에 관한 것이다.
기업 팀에게 이 경쟁은 검토 가능한 대안을 만들어낼 때 유용하다. 마케팅 언어가 아키텍처 간 차이를 가릴 때는 유용성이 줄어든다. 조달은 테스트와 승인 과정 전반에 걸쳐 이러한 차이를 보존해야 한다.
기밀 AI는 전체 신뢰 경계에 달려 있다
호스트와 가속기를 보호한다고 해서 이들과 연결된 모든 애플리케이션, 사용자 상호작용 또는 목적지가 자동으로 보호되는 것은 아니다.
신뢰 경계는 보안 설계가 보호 범위 안에 포함하는 구성 요소와 행위자를 정의한다. 기밀 AI에 관한 주장을 해석하기 전에 이 경계를 이해하는 일은 필수적이다. 그렇지 않으면 같은 표현이 아키텍처가 제공하는 것보다 훨씬 광범위한 보호를 암시할 수 있다.
NVIDIA가 공개한 기밀 컴퓨팅 경계는 이러한 원칙을 보여주는 유용한 사례다. 해당 문서는 인프라 관리자에 대한 보호와 보호 환경 내부 소프트웨어에 대한 신뢰를 구분한다. 또한 기밀성과 서비스 가용성을 구별한다.
이러한 설명은 TPU 8tx의 정확한 한계를 규정하는 것이 아니라 NVIDIA가 지원하는 구성에 관한 것이다. 그 방법론적 의미는 보안 평가에 명시적인 가정과 제외 항목이 필요하다는 데 있다. 구매자는 Google 배포 환경에 대해서도 이와 유사하게 구체적인 답변을 요청해야 한다.
실질적인 평가는 자산에서 시작한다. 조직은 고객 프롬프트, 독점 모델 파라미터, 검색된 문서 또는 생성 결과에 관심을 가질 수 있다. 자산마다 서로 다른 서비스를 거칠 수 있으므로, 모델 실행 환경만으로 보호 수준을 추론할 수는 없다.
다음으로는 조직이 제한하려는 주체의 정체를 살펴봐야 한다. 인프라 관리자가 보호 메모리를 읽지 못하도록 막는 것은 애플리케이션 운영자를 제한하는 것과는 다른 문제를 다룬다. 의미 있는 보안 주장은 어느 문제를 해결하는지 밝혀야 한다.
애플리케이션 동작은 또 다른 구분을 만든다. 권한을 가진 소프트웨어가 민감한 정보를 승인된 외부 대상에게 전송하는 경우, 하드웨어 격리만으로 해당 비즈니스 행위가 적절했는지 판단할 수는 없다. 애플리케이션의 권한과 정책은 여전히 중요하다.
기밀 문서를 검색한 뒤 요약을 생성하는 내부 연구 보조 도구를 생각해 보자. 모델 실행이 보호 환경 내부에서 이루어지더라도 검색 서비스와 출력 대상은 여전히 검토할 필요가 있다. 이는 공개된 TPU 고객 배포 사례가 아니라 가상의 워크플로다.
문제 해결이나 분석을 위해 애플리케이션 활동을 기록하는 로그에도 같은 논리가 적용된다. 보호된 연산도 애플리케이션이 보존하기로 선택한 출력을 만들 수 있다. 구매자는 서비스 전반에서 그러한 선택이 어떻게 이루어지는지 이해해야 한다.
이 때문에 인프라 보호와 정보 관리는 같은 계획 논의에 포함되어야 한다. 검색 가능한 지식 베이스를 구축하는 팀도 문서 접근과 허용된 사용에 대해 명확한 결정을 내려야 한다. 하드웨어 보안은 그 설계의 다른 부분을 다룬다.
강력한 평가는 실패 시 동작도 살펴봐야 한다. 검증에 실패할 경우 워크로드가 중단되는지, 민감한 자료가 계속 비공개로 유지되는지를 조직은 알아야 한다. 정상 조건에서 성공적인 시연이 이루어졌다고 해서 이 질문에 답이 되는 것은 아니다.
이러한 고려 사항은 보호된 실행의 가치를 낮추지 않는다. 구매자가 무엇을 구매하는지와 어떤 책임이 남아 있는지를 명확히 할 뿐이다. 보안 경계가 정확할수록 그 이점을 평가하기 쉬워진다.
따라서 AMD EPYC TPU 구성에서 아직 답이 필요한 과제는 구체적이다. 고객은 전체 환경, 허용되는 상태, 운영상 한계에 대해 검토 가능한 설명을 필요로 한다. 어느 한 공급업체에 대한 일반적인 신뢰가 그 기록을 대체할 수는 없다.
성능 주장은 워크로드 수준의 근거가 필요하다
보호된 가속기의 속도가 이를 사용하는 전체 애플리케이션의 성능을 입증하지는 않는다.
GPU 시스템에 관한 독립 연구는 구매자가 주변 소프트웨어를 검토해야 하는 이유를 보여준다. 이는 TPU 8tx를 직접 벤치마크한 것이 아니며, 그 결과를 Google 아키텍처에 적용해서는 안 된다. 그 가치는 헤드라인 성능 주장이 해결하지 못한 질문을 식별하는 데 있다.
Amean Asad와 Ansgar Grunseid는 NVIDIA B200 하드웨어와 Intel의 보호 가상 머신 기술을 사용한 기밀 추론 벤치마크를 보고했다. 이들의 프리프린트는 올바르게 구성된 스택에서 처리량 오버헤드가 약 1~3%인 반면, 기본 구성에서는 30~40%의 성능 저하가 발생한다고 설명한다.
처리량은 시스템이 시간에 따라 완료하는 작업량을 측정한다. 보고된 차이는 소프트웨어 구성이 관측 결과에 상당한 영향을 줄 수 있음을 시사한다. 그렇다고 기밀 AI의 보편적인 오버헤드나 Google 시스템에서 기대할 결과를 입증하는 것은 아니다.
Hang Yin과 Kevin Wang의 별도 프리프린트는 Blackwell GPU 시스템의 보호된 데이터 전송을 검토한다. 저자들은 보호된 호스트 환경과 가속기 사이의 이동을 애플리케이션 성능 저하의 원인으로 지목한다. 이들의 분석은 그 영향을 가속기의 로컬 연산과 구분한다.
이 두 논문은 좁지만 유용한 결론을 뒷받침한다. 완전한 워크로드를 평가해야 한다는 것이다. 이는 AMD 배포 환경에 대한 독립 검증이 아니라 다른 플랫폼에 관한 연구 보고서다. 어느 쪽도 TPU 8tx에 특정 성능 저하를 부여할 근거는 제공하지 않는다.
구매자에게 관련 있는 벤치마크는 의도한 서비스와 유사해야 한다. 대화형 보조 도구와 백그라운드 문서 처리 작업은 우선순위가 다를 수 있다. 지속적인 처리량에서 좋은 성능을 내는 구성도 간헐적인 요청에서는 다른 경험을 제공할 수 있다.
테스트는 시작 단계와 안정 운영 단계도 구분해야 한다. 모델 로딩, 환경 준비, 이미 확립된 세션 제공은 서로 다른 단계다. 이를 단일 평균으로 합치면 특정 애플리케이션에 가장 중요한 단계를 가릴 수 있다.
또 다른 유용한 구분은 요청 완료와 관련된다. 모델은 텍스트를 빠르게 생성할 수 있지만 전체 서비스는 지원 작업을 기다릴 수 있다. 최종 사용자는 전체 상호작용을 경험하므로, 가속기 측정만으로는 구매 판단에 불완전한 신호를 제공한다.
비교 전반에 걸쳐 보안은 활성화된 상태로 유지되어야 한다. 그렇지 않으면 구매자는 한 구성의 성능과 다른 구성의 보호를 승인할 위험이 있다. 유용한 결과는 조직이 실제로 운영하려는 환경의 성능이다.
엔지니어링 노력도 평가에 포함되어야 한다. 허용 가능한 동작에 전문적인 튜닝이 필요하다면, 팀은 누가 이를 유지하는지 이해해야 한다. 기술적으로 달성 가능한 결과는 직원이 일관되게 재현할 수 있는 지원 구성과는 운영상 의미가 다르다.
따라서 이 연구는 판정을 내리는 대신 평가를 더 정교하게 만든다. 겉보기에 작은 아키텍처 또는 소프트웨어 세부 사항도 면밀한 검토가 필요한 이유를 보여준다. 구매자는 재현 가능한 증거, 명확한 구성 기록, 실제 배포 조건을 반영한 테스트를 요구해야 한다.
이 기준은 AMD와 Google이 구체적으로 자신들의 주장을 입증할 기회를 제공한다. 또한 경쟁 플랫폼이 좋은 성과를 낼 여지도 남긴다. 발표는 배포 환경을 확립하지만, 애플리케이션 테스트는 그 적합성을 확립한다.
이 배포 환경의 도달 범위를 보여줄 세 가지 신호
다음 증거는 배포 준비 상태, 독립적인 워크로드 결과, 확인 가능한 고객 도입의 순서로 살펴봐야 한다.
향후 몇 달 동안 가장 먼저 주목할 신호는 실행 가능한 배포 정보다. 구매자는 지원 구성, 접근 조건, 운영 문서, 검증에 관한 명확한 설명을 필요로 한다. 세부 정보가 많아질수록 이 제안을 평가하기 쉬워지고 실질적 의미도 강화된다.
핵심 구분은 아키텍처를 설명하는 것과 조직이 이를 승인할 수 있도록 하는 것 사이에 있다. 문서는 엔지니어가 제품의 주장과 자체 애플리케이션 요구 사항을 연결할 수 있게 해야 한다. 기저 설계가 유망하더라도 이 단계의 모호성은 단기적 유용성을 제한할 수 있다.
보안 문서는 승인 여부가 구체적인 가정에 달려 있기 때문에 특히 주의 깊게 살펴봐야 한다. 구매자는 보호되는 구성 요소, 여전히 신뢰해야 하는 서비스, 변경 사항을 처리하는 절차를 식별할 수 있어야 한다. 명확한 답변은 배포 환경을 둘러싼 불확실성을 줄일 것이다.
두 번째 신호는 대표 워크로드에 대한 독립적이고 재현 가능한 테스트다. 유용한 증거는 전체 서비스 구성과 활성화된 보호 기능을 보고해야 한다. 그런 맥락이 없는 결과는 대안을 비교하는 데 더 약한 근거가 된다.
테스트에는 일반적인 성능과 함께 운영상 동작도 포함되어야 한다. 조직은 검증 실패, 유지보수, 복구 중에 어떤 일이 일어나는지 이해해야 한다. 유리한 속도 측정은 주장을 강화할 수 있지만, 이와 별개의 질문들을 해결하지는 못한다.
불리한 결과 역시 신중하게 해석해야 한다. 특정 워크로드의 한계가 전체 플랫폼에 가치가 없다는 것을 뜻하지는 않는다. 이는 해당 구성이 어디에 잘 맞지 않는지, 어디에서 다른 접근 방식을 고려해야 하는지를 식별한다.
세 번째 신호는 확인 가능한 프로덕션 도입이다. 워크로드, 승인 절차, 운영 경험을 설명하는 실명 고객 계정은 일반적인 관심 표명보다 더 강력한 상업적 증거가 된다. 이는 관련성 있는 설계 선택과 폭넓게 유용한 배포 패턴을 구분하는 데 도움이 된다.
AMD의 경우 반복적인 선택은 EPYC가 서로 다른 가속기 선택 전반에서 수요를 확보할 수 있다는 주장을 강화할 것이다. 단일 발표만으로는 그 패턴을 확립할 수 없다. 다음으로 의미 있는 증거는 추정된 재무 기여가 아니라 추가로 문서화된 사용 사례다.
Intel의 경우 경쟁 고객 배포 사례는 자사의 보호된 호스트 플랫폼이 겹치는 요구 사항을 얼마나 효과적으로 충족하는지 보여줄 것이다. 같은 구매 결정을 두고 경쟁하기 위해 기업들이 동일한 아키텍처를 가질 필요는 없다. 구매자의 워크로드와 보안 기준을 충족하는 구성이 필요하다.
엔터프라이즈 팀은 비교를 실행하기 전에 해당 기준을 정의함으로써 지금 준비할 수 있다. 그러면 제품 시연이 전체 평가 의제를 결정하는 일을 막을 수 있다. 또한 새로운 정보가 공개될 때 이를 더 쉽게 해석할 수 있다.
기밀성 요구 사항이 명시적인 워크로드에서 시작한 뒤, 민감한 정보가 이동하는 모든 위치를 매핑하라. 어떤 구성 요소가 보호 환경 내부에 속하는지, 누가 이를 통제하는지, 그 신뢰를 뒷받침하는 증거가 무엇인지 물어야 한다. 동등한 요구 사항 아래에서 전체 서비스를 대안과 비교하라. 성능과 함께 배포 노력을 기록하고, 승인 과정에서 해결되지 않은 가정을 계속 드러내 두어야 한다. 애플리케이션이 내부 기록을 검색한다면 권한, 로깅, 출력 처리도 평가에 포함하라. AMD EPYC TPU 배포는 구매자가 조사할 수 있는 구체적인 구성을 제공한다. 이를 통해 보호된 AI 실행에 대해 더 정확한 질문을 던지고, 조직이 실제로 운영하려는 서비스에 부합하는 증거를 요구하라.
