Nutanix와 Supermicro는 10월 21일, 공동으로 설계된 프라이빗 AI 추론 시스템 구축 계획을 발표했습니다. 이들의 release는 익숙한 구매 제안(buying proposition), 적은 통합 작업량이라는 장점과 함께, 테스트할 가치가 있는 운영상의 질문을 결합합니다. 바로 '관리 평면(management plane)이 실패했을 때 무엇이 계속 실행되는가?'입니다.
계획된 솔루션은 Supermicro 서버, Nutanix 소프트웨어, NVIDIA GPU 및 Spectrum-X 네트워킹을 통합합니다. 이번 발표에 따르면, 전용 Nutanix 관리 클러스터는 GPU 실행을 방해하지 않으면서도 관리 평면 실패로부터 보호하는 것을 목표로 합니다. 또한 별도의 통합 스토리지 서비스를 식별했으며, 2027년 초 가동 가능성을 목표로 하고 있습니다.
이 내용은 계획 및 예상 기능에 대한 것입니다. 이 발표는 측정된 비용 절감액을 확립하거나 실제 고객 설치 환경에서의 장애 동작을 입증하지는 않습니다.
운영 분석: 무엇이 계속되어야 하는지 정의하기
중단 없는 GPU 실행에 대한 진술은 애플리케이션 레벨의 수용 테스트가 필요합니다. 기존 프로세스가 계속 실행되는 것은 유용한 관찰 중 하나입니다. 사용자가 성공적인 응답을 받는 것은 또 다른 경우입니다. 이 테스트는 둘을 구별해야 합니다.
프라이빗 추론 배포를 위해, 저는 전달 팀에게 장애 시나리오를 선택하기 전에 서비스 경계를 정의해 달라고 요청할 것입니다. 해당 약속에는 확립된 요청 처리, 새로운 요청 처리, 모델 로딩, 인증, 그리고 비정상적인 서빙 인스턴스를 대체하는 능력이 포함되어야 합니다.
관리 중단은 이러한 활동에 다르게 영향을 미칠 수 있습니다. 그 답변은 단순히 클러스터를 분리하는 것이 모든 종속성을 제거한다는 가정보다는, 제안된 아키텍처와 관찰된 테스트에서 나와야 합니다.
중단 기간과 복구 과정 동안 예상되는 동작을 문서화하십시오. 운영자가 개입해야 하는 시점과 안전하게 수행할 수 있는 조치를 포함해야 합니다.
대표 워크로드를 이용한 테스트 종속성
수용 계획(acceptance plan)은 현실적인 요청 패턴을 가진 작동하는 추론 서비스(inference service)를 테스트해야 합니다. 모델 버전, 서빙 구성(serving configuration), 입력 및 출력 길이, 동시성(concurrency), 관련 캐시 상태를 기록하십시오. 정상 작동과 통제된 장애 상황을 비교할 때 이러한 조건들을 일관되게 유지해야 합니다.
다음으로 관리(management), 서빙(serving), 스토리지 경계를 가로지르는 종속성을 식별하십시오. 어떤 서비스가 메타데이터, ID, 네트워크 구성 또는 스토리지에 지속적인 접근이 필요한지 문의하십시오. 목적은 발표된 제품의 특정 약점을 추정하는 것이 아니라, 복원력(resilience) 증거가 필요한 경로를 찾는 것입니다.
공급업체와 허용되는 장애 주입 방법(failure-injection method)에 동의하고 적절한 테스트 환경을 사용하십시오. 요청 오류, 응답 지연 시간(response latency), 복구 시간(recovery time) 및 모든 수동 조치를 기록하십시오. 실패한 구성 요소가 다시 사용할 수 있게 된 후 서비스가 의도된 상태로 돌아가는지 확인하십시오.
성공적인 테스트는 다른 엔지니어가 검사하고 반복할 수 있는 기록을 남겨야 합니다.
스토리지 동작도 동일하게 검토에 포함시키십시오
해당 발표는 스토리지 클러스터를 데이터 수집(ingestion), 체크포인팅(checkpointing) 및 캐시 워밍(cache warming)을 위해 배치합니다. 구매자들에게 이는 스토리지 부분이 서비스 수용 논의에 포함됨을 의미합니다.
저는 모델 로딩, 요청 서빙, 그리고 서빙 인스턴스 재시작을 포함하는 작업 부하 순서(workload sequence)를 요청할 것입니다. 어떤 단계가 스토리지에 의존하며 제안된 구성 하에서 얼마나 걸리는지 관찰하십시오. 안정 상태 테스트만으로는 복구 경로가 크게 검토되지 않을 수 있습니다.
캐싱이 결과를 개선하는 경우, 워밍(warm) 실행과 콜드(cold) 실행의 구분을 유지하십시오. 이미 상주했던 것이 무엇인지, 그것이 어떻게 상주하게 되었는지, 그리고 용량이나 배치가 변경될 때 무슨 일이 발생하는지를 기록하십시오. 이러한 세부 사항은 유리한 결과가 일상적인 요청에 적용되는지, 재시작에 적용되는지, 아니면 모델의 첫 사용에 적용되는지를 설명하는 데 도움이 됩니다.
서비스 경계에서의 경제성 비교
발표에서 언급된 낮은 토큰당 비용은 정량화된 결과라기보다는 목표입니다. 특정 배포 환경에 대해 이를 평가하려면, 계산에 포함될 비용과 유지되어야 할 서비스 품질을 정의해야 합니다.
비교 시에는 관리 및 스토리지 자원, 소프트웨어 및 운영 노력을 포함하여 서빙을 지원하는 데 필요한 인프라를 고려해야 합니다. 활용 가정을 명시하고, 복구용으로 보유되는 용량과 정상 트래픽을 처리하는 자원을 구분해야 합니다.
그런 다음 동일한 워크로드와 응답 요구사항 하에서 유효 출력을 비교하십시오. 애플리케이션의 지연 시간(latency) 요구사항을 충족하지 못하면서 더 많은 출력을 생성하는 구성은, 이를 일관되게 충족하는 구성과는 다른 질문에 답하고 있는 것입니다.
계획된 통합이 조달 및 조립 과정을 간소화할 수는 있지만, 구매자는 여전히 결과 서비스에 대한 증거가 필요합니다. 명확한 장애 격리 테스트(failure-isolation test), 문서화된 스토리지 복구 경로(storage recovery path), 그리고 명시적인 경제 비교는 운영자가 시스템이 가용해졌을 때 이를 평가할 수 있는 실질적인 방법을 제공합니다.