OCP 2026에서 공개된 Microsoft Maia 300: 4개 가속기 트레이 내부

Microsoft는 OCP 2026에서 4개 가속기를 탑재한 Maia 300 트레이를 공개하며, 칩 사양을 넘어 자사가 계획한 2027년 AI 인프라를 실물로 선보였다. 각 가속기에는 4세대 적층형 고대역폭 메모리인 HBM4 288GB가 탑재되며, 열 설계 전력은 950와트로 명시됐다. OCP 2026에서 공개된 Microsoft Maia 300은 냉각, 배선, 전력 공급, 유지보수 접근성 등 이러한 핵심 수치를 뒷받침하는 엔지니어링이 얼마나 큰 비중을 차지하는지 보여준다.

핵심 비교 대상은 Microsoft의 맞춤형 추론 인프라와 Nvidia의 통합 랙 시스템이다. 추론은 학습된 모델을 실행해 답변을 생성하거나 다른 작업을 수행하는 것을 의미한다. 두 회사 모두 개별 프로세서를 넘어선 설계를 추구하지만, 물리적 구현 방식은 다르다. 빠른 가속기라도 밀집된 시설에서 현실적으로 운영할 방법이 필요하기 때문에 이러한 선택은 중요하다.

ServeTheHome은 Microsoft의 10월 12일 발표에 이어 10월 27일 현장 취재 기사를 게재했다. 이 전시는 패키징과 시스템 통합을 구체적으로 논의할 근거를 제공한다. 다만 양산 가능성, 독립적으로 측정된 효율성, 고객 배포 일정까지 입증하는 것은 아니다. 특히 Microsoft가 자체 AI 제품을 어떻게 제공하려 하는지 추적하는 독자에게는 이러한 경계를 이해하는 것이 하드웨어를 더 유익하게 해준다.

OCP 2026에서 공개된 Microsoft Maia 300, 트레이 자체가 핵심이 되다

가장 유용한 새로운 증거는 조립된 트레이로, Microsoft의 가속기 사양을 직접 확인 가능한 시스템 설계와 연결한다.

Patrick Kennedy의 4개 가속기 트레이 취재는 액체 냉각 가속기 플레이트, 광범위한 케이블링, 대형 팬 구획을 설명한다. 후면은 랙 전원, 냉각 장치, 가속기들을 연결하는 네트워크에 연결된다. 이러한 관찰은 Microsoft 칩을 둘러싼 실제 하드웨어 구성을 드러낸다.

행사 시점도 정확히 짚을 필요가 있다. OCP Global Summit은 캘리포니아주 새너제이에서 10월 12일부터 15일까지 열렸다. 이후의 기사 게재일은 별도의 10월 27일 제품 출시가 아니라 취재 일정에 따른 것이다. Microsoft의 발표와 실물 전시는 같은 큰 발표의 일부다.

조립된 트레이는 프로세서 도면만으로는 알 수 없는 질문에 답한다. 엔지니어는 주요 부품이 어떻게 결합되는지 살피고, 전력·액체·네트워크 연결이 어디로 들어오는지 확인할 수 있다. 어떤 부품이 같은 인클로저를 공유하는지도 볼 수 있다. 이러한 세부 사항은 성능을 측정하지는 않지만 배포 개념을 더 쉽게 평가하게 해준다.

이 조립체를 공개하는 것과 실제 운영 중인 대규모 배포 환경을 보여주는 것에는 의미 있는 차이가 있다. 전시는 특정 물리적 구성이 존재함을 보여준다. 그러나 제조 일관성, 긴급한 상황에서의 교체 절차, 지속적인 서비스 중의 동작을 드러내지는 않는다. 독자는 눈에 보이는 모든 연결부를 완성된 운영 역량의 증거로 받아들이지 않아야 한다.

사진 역시 기술 문서로서 한계가 있다. Kennedy는 일부 커넥터를 잠정적으로 식별하며, 정확한 정체가 해석의 영역임을 분명히 했다. 이러한 불확실성은 관찰 내용에 그대로 따라붙어야 한다. 커넥터의 외형만으로는 전기적 특성, 지원 프로토콜, 모든 케이블의 용도를 확정할 수 없다.

인프라 팀에는 이 트레이가 추측성 워크스테이션 활용 사례보다 더 유용한 출발점이 된다. Microsoft는 클라우드 인프라 프로그램을 설명해 왔으며, 전시된 하드웨어도 그 구도에 부합한다. 공개 전시만으로 소매용 가속기 제품이나 폭넓게 이용 가능한 개발자용 머신이 나온다는 사실이 확립되는 것은 아니다.

따라서 중요한 변화는 구체적이다. 이제 Microsoft의 차세대 Maia는 서버 조립체로 논의할 수 있다. 관심은 이를 설치하고, 냉각하고, 연결하고, 정비하는 데 필요한 작업으로 옮겨간다. 이러한 요소가 발표된 실리콘 역량 중 얼마가 실제 사용 가능한 용량이 되는지를 결정할 것이다.

Microsoft의 추론 전략, 자체 배포 팀에 부담을 주다

Microsoft가 처음으로 해결해야 할 실행 과제는 맞춤형 하드웨어를 자사가 운영하는 서비스용 안정적인 용량으로 전환하는 일이다.

Microsoft는 Maia 배포 전략에서 2027년 Maia 300의 프로덕션 배포를 목표로 제시했다. 또한 Microsoft 제품 및 서비스의 주요 추론 시스템으로 Maia를 만들 계획이다. 이러한 목표는 프로그램 평가에서 내부 도입을 핵심 요소로 만든다.

발표에 따르면 Maia 200은 Microsoft Copilot 워크로드를 포함해 이미 프로덕션 환경에서 사용되고 있다. Microsoft는 해당 세대의 운영 경험이 Maia 300에 반영됐다고 말한다. 이는 세대 간의 실질적인 연결고리를 만들지만, 기존의 모든 워크로드가 수정 없이 이전된다는 사실까지 입증하지는 않는다.

서비스와 하드웨어를 모두 소유하면 긴밀한 조율의 기회가 생긴다. 서비스 팀은 워크로드를 설명하고, 하드웨어 및 소프트웨어 팀은 그 수요에 맞춰 최적화할 수 있다. 동시에 이 구조는 의무도 만든다. 모델이 바뀌고, 애플리케이션이 성장하며, 운영 요구사항이 진화하는 동안 누군가는 이러한 최적화를 유지해야 한다.

프로젝트 맥락을 읽고, 편집안을 생성하며, 도구를 호출하는 코딩 어시스턴트를 생각해 보자. 사용자는 단계 사이의 대기 시간을 포함한 전체 순서를 경험한다. 모델 실행 속도가 빨라져도 그 실행이 지연에 기여하는 부분에서만 도움이 된다. 하드웨어 발표만으로 개발자에게 실제로 전달되는 개선을 독립적으로 입증할 수는 없다.

제품 팀에 중요한 질문은 인프라가 실제 요청 패턴을 지원하는지 여부다. 긴 입력, 짧은 답변, 혼잡한 시간대, 예측하기 어려운 도구 호출은 서로 다른 요구를 부과한다. 평균 워크로드를 중심으로 선택한 시스템이라도 그 평균을 벗어나는 요청을 처리할 계획이 필요하다.

배포 팀은 또 다른 종류의 압박을 받는다. 시설 준비 상태, 하드웨어 공급, 소프트웨어 지원, 서비스 적격성 검증을 함께 갖춰야 한다. 냉각 인프라보다 먼저 도착한 가속기는 유용한 용량을 제공할 수 없다. 서비스 팀의 승인 검사를 통과하지 못한 소프트웨어 경로를 갖춘 완성된 랙도 마찬가지다.

이 때문에 외부 공급업체를 대체한다는 광범위한 주장보다 Microsoft 자체의 운영 결과가 더 많은 것을 보여준다. 성공적인 내부 배포는 회사가 맞춤형 시스템을 지속적인 수요에 맞출 수 있음을 보여줄 것이다. 그렇다고 관련 없는 워크로드 전반이나 모든 고객의 요구사항에서 우월함이 자동으로 입증되는 것은 아니다.

기업 구매자도 이 구분을 분명히 유지해야 한다. 공급업체의 하드웨어 효율은 서비스 용량에 영향을 줄 수 있지만, 특정 고객 결과를 약속하지는 않는다. 구매자는 여전히 응답 시간, 가용성, 지원 모델, 운영 약속을 평가해야 한다. 이것들이 Microsoft의 인프라 투자와 실제로 사용할 수 있는 비즈니스 서비스를 연결한다.

메모리와 데이터 이동이 아키텍처의 우선순위를 설명한다

Maia 300의 사양은 연산 능력만을 유일한 제약으로 보지 않고, 연산을 공급하고 조율하는 데 중점을 둔다.

Microsoft는 가속기당 최대 메모리 대역폭을 18TB/s로 명시한다. 대역폭은 데이터가 얼마나 빠르게 이동할 수 있는지를 나타내고, 288GB 용량은 메모리가 얼마나 많은 데이터를 담을 수 있는지를 나타낸다. 두 지표는 서로 다른 제약을 다룬다. 워크로드에 메모리 공간이 충분해도 데이터 대기 시간에 소요될 수 있다.

Microsoft의 Maia 300 아키텍처에 따르면 전체 랙은 167킬로와트 범위 안에서 24개 트레이에 걸쳐 96개 가속기를 포함한다. Microsoft는 데이터 배치와 이동에 소프트웨어가 지시하는 접근 방식도 설명한다. 이는 독립적으로 측정된 애플리케이션 결과가 아니라 회사가 제시한 사양과 아키텍처 설명이다.

용량과 대역폭의 차이는 메모리가 강조되는 이유를 설명한다. 모델에는 파라미터와 작업 정보를 저장할 공간이 필요하다. 실행 중 시스템은 필요한 정보를 처리 하드웨어로 반복적으로 가져와야 한다. 다른 리소스가 연산 장치에 충분히 데이터를 공급하지 못할 때 연산 역량을 추가해도 이점은 제한적이다.

컨텍스트 처리에는 또 다른 고려사항이 있다. 텍스트 생성 중 재사용되는 저장된 어텐션 정보인 KV 캐시는 다른 모델 데이터와 함께 메모리를 차지한다. 대화가 길어지면 이 저장 요구량이 늘어날 수 있다. 실질적 결과는 메모리 용량만이 아니라 모델, 요청 구성, 서빙 설정에 따라 달라진다.

질문에 답하기 전 여러 기술 문서를 검토하는 어시스턴트를 상상해 보자. 더 큰 가용 메모리 예산은 작업 정보를 수용하는 데 도움이 될 수 있다. 그러나 시스템은 여전히 관련 자료를 가져오고 모델을 효율적으로 실행해야 한다. 메모리가 늘어난다고 어시스턴트가 더 나은 근거를 선택하거나 더 나은 답변을 만든다는 사실이 입증되지는 않는다.

같은 구분은 여러 가속기에 걸쳐서도 적용된다. 워크로드가 여러 장치에 걸치면 유용한 실행은 로컬 처리뿐 아니라 통신에도 달려 있다. 가속기가 하나의 워크로드에서 협력하도록 해주는 연결인 스케일업 네트워킹은 성능 논의의 일부가 된다. 랙이 가치 있는 이유는 구성 요소가 함께 효과적으로 작동할 수 있기 때문이다.

따라서 소프트웨어는 설계가 약속하는 가치의 상당 부분을 담당한다. 불필요한 이동 없이 데이터가 적절한 처리 리소스에 도달하도록 작업을 배치해야 한다. 이를 위해서는 하드웨어 레이아웃과 모델의 실행 패턴을 모두 알아야 한다. 사양표만으로는 이 조율이 얼마나 일관되게 성공하는지 보여줄 수 없다.

정밀도 선택은 또 다른 의존성을 도입한다. 저정밀 표현은 수치를 저장하거나 처리하는 데 더 적은 비트를 사용한다. 데이터 요구량을 줄일 수 있지만, 배포 환경은 여전히 허용 가능한 모델 동작을 보존해야 한다. 더 빠른 구성은 답변이 애플리케이션의 품질 요구사항을 충족할 때에만 서비스에 도움이 된다.

이러한 메커니즘은 메모리 중심 설계가 경쟁 결과를 입증하지 않으면서도 주목할 가치가 있는 이유를 설명한다. 관련 증거는 정의된 조건에서 리소스 개선과 완료된 요청을 연결해야 한다. 최대 대역폭만으로는 그러한 연결을 제공할 수 없다. 이는 애플리케이션 테스트가 살펴봐야 할 아키텍처 우선순위를 보여준다.

Maia와 Nvidia는 물리적 통합에서 서로 다른 선택을 드러낸다

가장 명확한 비교 대상은 시스템 구성 방식이며, 전시만으로 정면 성능 우열을 판단할 수는 없다.

ServeTheHome은 Vera Rubin 시스템에서 케이블링을 줄이려는 Nvidia의 노력과 대비해 Microsoft의 광범위한 내부 케이블링을 강조한다. 두 접근 방식 모두 조립, 접근성, 교체에 관한 현실적인 질문을 제기한다. 사진은 눈에 보이는 차이를 입증하지만, 어느 설계가 더 쉽게 운영될지는 입증하지 않는다.

Nvidia의 Rubin 플랫폼 발표는 처리, 네트워킹, 지원 하드웨어를 아우르는 통합 시스템을 설명한다. 또한 계획된 배포업체 중 하나로 Microsoft를 언급한다. 이 맥락은 중요하다. Microsoft의 맞춤형 가속기 프로그램과 Nvidia 인프라 사용은 공존할 수 있다.

따라서 비교는 공급업체와의 결별을 전제로 하기보다 구현 선택에 초점을 맞춰야 한다. Microsoft는 외부 플랫폼을 계속 도입하면서도 자체 서비스 조합에 유리한 방향을 모색할 수 있다. 워크로드마다 서로 다른 시스템이 정당화될 수 있다. Maia 디스플레이와 Nvidia의 발표 어느 쪽도 양측 간 최종 배분을 규정하지는 않는다.

케이블은 시각적 판단에 신중함이 필요한 이유를 보여주는 유용한 사례다. 케이블은 연결을 물리적으로 명확히 드러내고 유연한 배선을 가능하게 할 수 있다. 동시에 올바른 설치와 취급이 필요한 부품을 추가한다. 이러한 구성이 유지보수에 도움이 되는지는 접근성, 라벨링, 교체 절차, 그리고 주변 기계 설계에 따라 달라진다.

더 통합된 연결 시스템은 이러한 문제를 다른 곳으로 옮긴다. 조립 단계를 바꾸고 일부 수동 연결을 줄일 수 있지만, 정렬과 기계적 인터페이스의 중요성은 커진다. 어느 접근 방식을 평가하든 눈에 보이는 케이블 수를 세는 것만으로는 충분하지 않다. 운영자는 전체 절차와 그 장애 모드에 관한 근거를 필요로 한다.

정비성은 고장 난 부품을 교체하기 위해 기술자가 어떤 부분을 건드려야 하는지에도 달려 있다. 관련 어셈블리를 바로 꺼낼 수 있는가? 절차상 인접한 구성 요소를 분리해야 하는가? 시스템은 교체가 성공했음을 어떻게 확인하는가? 이는 전시된 Maia 하드웨어에 관한 문서화된 답변이 아니라 평가를 위한 질문이다.

냉각 역시 외관과 운영 근거 사이에 비슷한 차이를 만든다. Maia 트레이는 가속기 주변의 액체 냉각과 다른 구성 요소를 위한 상당한 공기 흐름을 결합한다. 콜드 플레이트는 액체가 공급되는 열전달 표면으로, 특정 위치의 열을 처리한다. 이는 전체 인클로저의 환경 요구 사항을 설명하지는 않는다.

시설 운영 팀에게 이는 액체와 공기가 여전히 동일한 평가의 일부임을 뜻한다. 이들은 전체 열 설계와 그것이 실내 조건과 어떻게 상호작용하는지 이해해야 한다. 액체 연결부가 존재한다고 해서 배포 과정에서 공기 흐름 계획이 불필요해지는 것은 아니다.

따라서 Microsoft Maia 300 Shown at OCP 2026를 지켜보는 독자는 이 트레이를 특정 통합 전략의 증거로 받아들여야 한다. 엔지니어링 선택은 검토할 수 있을 만큼 충분히 드러나 있다. 하지만 그 운영상 이점은 기술자, 시설 팀, 소프트웨어 운영자가 동일한 시스템을 함께 마주하게 되는 검증과 배포 단계에서 확인해야 할 문제로 남아 있다.

효율성 주장은 비교 가능한 워크로드와 완전한 전력 산정이 필요하다

Microsoft의 효율성 전망은 정의된 운영 조건에서 비교 가능한 테스트가 그 의미를 입증하기 전까지는 회사 측 주장에 머문다.

Microsoft는 Maia 300이 선도적인 GPU 기반 시스템보다 메가와트당 토큰을 40% 더 제공할 것으로 예상된다고 말한다. 토큰은 모델이 처리하거나 생성하는 텍스트 단위다. 이 주장은 전력 대비 출력을 다루지만, 헤드라인만으로는 보편적인 경쟁 순위를 매기기에 충분한 세부 정보가 제공되지 않는다.

의미 있는 비교에는 식별 가능한 기준선이 필요하다. 독자는 Microsoft가 어떤 경쟁 하드웨어 및 소프트웨어 구성을 사용했는지, 모델과 워크로드는 무엇이었는지 알아야 한다. 이러한 세부 정보 없이는 백분율만으로 Maia가 특정 Nvidia 배포 환경과 어떻게 비교되는지 판단할 수 없다. 결과가 애플리케이션 간에 어떻게 이전되는지도 알 수 없다.

시스템은 서로 다른 계산 경로를 통해 비슷해 보이는 답변을 낼 수 있으므로 모델 구성도 중요하다. 수치 정밀도, 모델 버전, 실행 설정은 속도와 출력 품질 모두에 영향을 줄 수 있다. 비교는 이러한 조건을 통제하거나 차이점을 설명해야 한다. 그렇지 않으면 결과에 하드웨어 효과와 다른 변경 사항이 뒤섞인다.

응답 시간은 총출력만큼 중요하다. 처리량은 시간당 완료된 작업을 측정하는 반면, 지연 시간은 개별 요청에 걸리는 시간을 측정한다. 시스템은 요청을 더 오래 대기시키는 방식으로 전체 처리량을 높일 수 있다. 이러한 절충은 일부 서비스에는 적합할 수 있지만 다른 서비스에는 불리할 수 있다.

워크로드 구성은 추가적인 변동을 만든다. 긴 프롬프트를 읽는 것과 긴 답변을 생성하는 것은 시스템에 서로 다른 요구를 부과한다. 동시 요청 역시 리소스 공유 방식을 바꾼다. 유용한 벤치마크라면 독자가 해당 워크로드가 자신의 환경과 유사한지 판단할 수 있도록 이러한 조건을 공개해야 한다.

전력 측정에도 그에 못지않게 명확한 경계가 필요하다. 열 설계 전력은 배포된 에너지 사용량 전체를 측정한 값이 아니라 구성 요소 설계 정격이다. 호스트, 네트워킹, 냉각, 지원 장비도 모두 영향을 미친다. 양측에 서로 다른 구성 요소를 포함한 비교는 계산이 정확하더라도 오해를 불러올 수 있다.

따라서 랙 범위와 가속기 정격은 서로 다른 질문에 답한다. 운영자는 시설을 계획할 때 하나를 다른 하나로 대체할 수 없다. 각 수치에 어떤 장비와 운영 가정이 포함되는지 알아야 한다. 가장 유용한 공개는 이러한 경계를 측정된 워크로드와 연결하는 것이다.

가용성 역시 평가에 포함되어야 한다. 중단 없는 실행 중 효율적으로 답변을 생성하는 시스템도 장애와 유지보수를 처리해야 한다. 이는 실험실 결과를 무효화하지 않는다. 다만 그 결과가 전체 플릿 서비스 효율성보다 더 좁은 질문에 답한다는 의미다.

이러한 주의 사항이 Microsoft의 전망이 틀렸다는 뜻은 아니다. 이는 이를 평가하는 데 필요한 정보를 정의한다. 여기서 검토한 공개 자료는 기술적 근거와 배포 목표를 뒷받침한다. 하지만 동등한 서비스 조건에서 Maia 300이 모든 대안을 능가한다는 점을 독립적으로 입증하지는 않는다.

엔지니어링 팀이 취할 실질적 대응은 의사결정 기록에서 이 구분을 유지하는 것이다. 검색 가능한 지식 베이스는 사양, 벤치마크 조건, 개정 사항을 함께 보관할 수 있다. 유용한 습관은 인프라 선택을 정당화하는 데 사용하기 전에 각 출처가 실제로 무엇을 입증하는지 기록하는 것이다.

디스플레이가 운영 용량이 되는지를 보여줄 세 가지 신호

다음 근거는 Maia의 물리적 설계를 문서화된 소프트웨어 준비 상태, 측정 가능한 서비스 동작, 그리고 프로덕션 배포와 연결해야 한다.

첫 번째 신호는 추가적인 배포 및 소프트웨어 세부 정보다. Microsoft의 10월 발표는 독자들에게 11월 Ignite에서 이어질 논의를 참고하라고 안내한다. 유용한 공개라면 지원 워크로드, 개발 도구, 계획된 가용성의 범위를 식별할 것이다. 이러한 세부 사항은 하드웨어가 운영 환경에 어떻게 들어가는지를 명확히 해준다.

더 명확한 로드맵은 이 트레이가 실행 가능한 배포 계획을 나타낸다는 견해를 강화할 것이다. 광범위한 아키텍처 언어에 계속 의존한다면 소프트웨어 경로는 평가하기 어렵게 남는다. 어느 결과든 같은 어셈블리의 추가 사진보다 더 중요하다. 독자에게는 누가 어떤 조건에서 시스템을 사용할 수 있는지에 관한 근거가 필요하다.

맞춤형 하드웨어는 실제 통합 작업을 만들어내기 때문에 소프트웨어 문서는 특히 유용한 정보가 될 것이다. 모델 지원에는 정의, 버전 경계, 운영 지침이 필요하다. 특정 모델 계열이 관련 있다는 설명만으로는 지원되는 모든 구성을 설명할 수 없다. 엔지니어는 모델과 프로덕션 서비스 사이의 작업을 이해할 만큼 충분히 구체적인 정보가 필요하다.

두 번째 신호는 재현 가능한 성능 공개다. 여기에는 모델, 요청 패턴, 응답 시간 요구 사항, 출력 품질 기준, 전력 측정 경계가 식별되어야 한다. 독립적인 테스트는 신뢰를 더하겠지만, 상세한 회사 측 측정치도 논의를 개선할 수 있다. 핵심 단계는 비교를 검토 가능하게 만드는 것이다.

동일한 서비스 요구 사항 아래에서의 우위 근거는 Microsoft의 효율성 주장을 강화할 것이다. 좁은 구성에만 한정된 이점은 더 구체적인 해석을 뒷받침할 것이다. 어느 결과도 아키텍처를 일축할 필요는 없다. 대신 설계의 우선순위가 유용한 운영상 이점으로 이어지는 지점을 밝힐 것이다.

세 번째 신호는 언급된 2027년 프로덕션 목표를 향한 구체적인 진전이다. 향후 몇 달 동안 독자는 명시된 서비스, 검증 이정표, 정확한 배포 표현을 살펴봐야 한다. 준비 작업과 프로덕션 운영은 서로 다른 단계다. 보도는 발표가 실제로 어떤 단계를 설명하는지 식별해야 한다.

프로덕션 근거는 Microsoft가 맞춤형 하드웨어를 서비스 용량으로 전환할 수 있다는 주장을 강화할 것이다. 수정된 일정이나 더 좁은 출시 범위는 이 평가를 바꿀 것이다. 출하 대수만으로는 납품된 장비가 반드시 활성 서비스 용량과 같지는 않으므로 불완전한 근거에 머문다. 관련된 결과는 지속적인 운영 조건에서 유용한 작업을 수행하는 것이다.

개발자에게 이러한 신호는 디스플레이를 중심으로 애플리케이션 계획을 다시 작성하지 않고도 하드웨어를 추적할 방법을 제공한다. 구매자에게는 지원 서비스와 측정 가능한 결과에 관해 물어볼 질문을 제공한다. 인프라 운영자에게는 설치와 유지보수를 평가하는 데 필요한 문서를 가리킨다.

Microsoft Maia 300 Shown at OCP 2026 사양을 기준선으로 유지한 뒤, 향후 공개 내용을 이에 맞춰 비교하라. 지원되는 워크로드, 정의된 측정 방법, 명확한 배포 단계를 찾아라. 발표된 개선 사항이 팀이 실제로 사용하는 서비스에 도달하는지 물어라. 해결되지 않은 질문을 헤드라인 주장과 함께 보존해 후속 근거가 답할 수 있게 하라. 이 트레이는 Microsoft의 접근 방식을 검토할 수 있을 만큼 구체화하지만, 다음 공개 내용은 그것이 어떻게 신뢰할 수 있는 용량이 되는지 설명해야 한다. 이 하드웨어 발표를 구매 또는 아키텍처 가정으로 바꾸기 전에, 팀은 어떤 문서화된 서비스 결과를 확인해야 할까?