NVIDIA cuObject, 파일을 넘어 AI 스토리지 접근 확대… 상호운용성은 아직 미완성
NVIDIA는 9월 30일 cuObject 클라이언트 및 서버 라이브러리를 정식 출시하며 가속화된 AI 스토리지 접근 범위를 기존 파일 시스템 너머로 확장했다. NVIDIA cuObject는 서버 CPU를 거치지 않고 객체 데이터를 이동하기 위한 표준화된 API와 RDMA 와이어 프로토콜을 추가한다.
회사는 GPU에서 시작된 스토리지 요청을 처리하기 위한 SCADA Server SDK도 공개했다. SCADA는 Scaled Accelerated Data Access의 약자로, 대량의 세분화된 스토리지 작업을 위해 설계된 프레임워크다. IBM은 이미 이 SDK를 활용해 초기 Storage Scale 프로토타입을 구축했다.
이번 발표는 AI 인프라에 지속적으로 존재해 온 분열을 겨냥한다. 객체 스토리지는 대용량과 친숙한 S3 호환 인터페이스를 제공하는 반면, 고성능 학습 및 추론 파이프라인은 흔히 더 빠른 파일 시스템이나 로컬 스크래치 스토리지에 의존한다. NVIDIA는 cuObject로 이 격차를 좁히려 하지만, 더 큰 상호운용성 계획은 아직 완성되지 않았다.
NVIDIA cuObject, 제품 라이브러리에서 산업 제안으로 확장
중요한 변화는 NVIDIA가 또 하나의 스토리지 라이브러리를 출시했다는 점만이 아니다. 클라우드 및 스토리지 제공업체에 공통의 가속 객체 프로토콜로 수렴할 것을 요구하고 있다.
NVIDIA 발표에 따르면 cuObject 클라이언트와 서버 라이브러리는 모두 정식 출시됐다. NVIDIA는 서버 측 통합을 검토하는 스토리지 제공업체를 위해 cuObject Server 2.0.0도 공개했다.
클라이언트 라이브러리는 GPU 애플리케이션, 데이터 로더 또는 미들웨어 계층 내부에 위치한다. 애플리케이션 수준의 객체 작업을 RDMA 데이터 경로에 연결한다. 원격 직접 메모리 접근, 즉 RDMA는 네트워크 하드웨어가 등록된 메모리 영역 간에 데이터를 직접 전송하도록 한다.
서버 라이브러리는 객체 스토리지 서비스와 통합된다. 등록된 버퍼를 관리하고 데이터를 클라이언트로 또는 클라이언트에서 이동시키는 RDMA 작업을 수행한다. 이 시스템은 GPU 메모리 또는 시스템 메모리를 대상으로 할 수 있다.
이 설계는 GPUDirect Storage가 완전히 해결하지 못한 문제를 다룬다. GPUDirect Storage는 이미 스토리지와 GPU 메모리 간 직접 경로를 제공했지만, 가장 널리 알려진 인터페이스인 cuFile은 파일 접근에 초점을 맞췄다. 많은 AI 데이터세트는 대신 객체 인터페이스 뒤에 존재한다.
학습 샘플, 문서, 이미지, 체크포인트 및 생성 산출물을 S3 호환 리포지터리에 보관하는 조직에는 이 차이가 중요하다. 이러한 시스템은 대규모 네임스페이스 전반으로 확장할 수 있고 스토리지를 컴퓨팅에서 분리하기 때문에 매력적이다. 그러나 기존 객체 접근은 보통 TCP 스택과 CPU가 관리하는 버퍼를 거친다.
NVIDIA cuObject는 객체 지향 제어 작업을 유지하면서 페이로드 경로를 변경한다. 클라이언트는 조정된 S3 소프트웨어 개발 키트를 통해 익숙한 GET 또는 PUT 요청을 계속 보낼 수 있다. 이후 객체 데이터는 일반적인 TCP 데이터 경로 대신 RDMA를 통해 이동할 수 있다.
정식 출시는 개발자에게 지원되는 출발점을 제공하지만, NVIDIA는 xio-sig를 통해 더 폭넓은 목표를 추진하고 있다. 이 그룹은 파일 접근에서 객체 접근으로 범위를 확장하고 있으며, 클라이언트 API, 와이어 프로토콜 및 적합성 테스트를 위한 별도 작업을 계획하고 있다.
Google Cloud는 cuObject 관련 참여 확대를 검토하고 있다. Microsoft도 xio-sig 이사회에 참여할 계획이라고 밝혔다. IBM의 SCADA 프로토타입은 초기 그룹에 스토리지 벤더를 추가하지만, 프로토타입이 프로덕션 지원과 동등한 것은 아니다.
이 구분은 이 이야기의 핵심이다. NVIDIA는 이제 다운로드 가능한 구성 요소, 문서 및 상호운용성을 논의하는 파트너를 보유하고 있다. 그러나 여러 검증된 프로덕션 구현을 갖춘 성숙한 멀티벤더 객체 스토리지 표준은 아직 없다.
따라서 이번 출시는 구체적이면서도 잠정적이다. 개발자는 지금 라이브러리 평가를 시작할 수 있다. 더 큰 약속은 클라우드 플랫폼, 스토리지 벤더, 프레임워크 및 애플리케이션 개발자가 동일한 인터페이스를 채택하는 데 달려 있다.
NVIDIA cuObject가 제어와 데이터를 분리하는 방식
NVIDIA cuObject는 S3 스타일 제어 메시지를 익숙한 경로에 유지하면서 객체 페이로드를 RDMA로 이동시킨다.
cuObject 아키텍처는 각 작업을 제어 플레인과 데이터 플레인으로 나눈다. 표준 S3 GET 및 PUT 요청은 제어 흐름의 일부로 남는다. 조정된 S3 SDK는 RDMA 전송을 설명하는 메타데이터를 추가한다.
객체 페이로드는 다른 경로를 따른다. 클라이언트는 메모리 영역을 등록하고 전송에 필요한 정보를 담은 RDMA 토큰을 생성한다. 이 토큰은 사용자 지정 헤더를 통해 HTTP 요청에 첨부된다.
스토리지 게이트웨이는 요청을 파싱하고 적절한 데이터 노드가 작업을 수행하도록 지시한다. 해당 노드는 cuObject 서버 API를 통해 로컬 버퍼를 등록한다. 이후 RDMA 쓰기 또는 읽기를 사용해 페이로드를 푸시하거나 풀한다.
RDMA 작업이 완료된 후 성공적인 게이트웨이 응답이 제어 트랜잭션을 마무리한다. 이 분리는 애플리케이션이 객체 의미 체계를 유지하면서 서버 CPU를 주된 페이로드 경로에서 제외할 수 있게 한다.
이 접근 방식은 원시 대역폭 이상을 겨냥한다. 많은 가속기가 동시 스토리지 작업을 생성할 때 CPU 처리는 제약이 될 수 있다. 각 페이로드의 TCP 처리를 피하면 메타데이터, 조정, 보안 및 기타 서비스에 CPU 용량을 남겨둘 수 있다.
현재 구현은 일반적으로 DC라고 불리는 Dynamically Connected 전송 방식을 사용한다. DC는 모든 클라이언트와 스토리지 서버 쌍 사이에 신뢰성 연결을 유지하지 않아도 된다. 이 특성은 대규모 컴퓨팅 클러스터가 많은 스토리지 노드에 접근할 때 유용하다.
NVIDIA는 InfiniBand 및 RoCEv2를 통한 DC 지원을 문서화하고 있다. RoCEv2는 필요한 동작을 지원하도록 구성된 Ethernet 네트워크에서 RDMA 트래픽을 전송한다. 두 옵션 모두 라이브러리 설치를 넘어선 인프라 계획을 요구한다.
클라이언트는 변경되지 않은 S3 엔드포인트와 상호작용하지도 않는다. NVIDIA 문서는 통합에 클라이언트 측 S3 SDK 및 서버 측 스토리지 소프트웨어의 수정이 필요하다고 설명한다. 이러한 변경은 가속 경로를 만들고 RDMA 메타데이터를 교환한다.
지원 작업에는 GET, PUT, 멀티파트 업로드 작업 및 바이트 범위 읽기가 포함된다. 범위 접근은 애플리케이션이 전체 객체를 GPU 메모리로 전송하는 대신 대형 객체의 일부만 필요로 할 때 관련된다.
이 아키텍처는 일반적인 스테이징 단계를 제거할 수 있다. 전통적인 AI 파이프라인은 흔히 객체 리포지터리에서 로컬 또는 분산 스크래치 파일 시스템으로 데이터를 복사한다. 이후 컴퓨팅 노드는 이 중간 계층에서 읽는다.
스테이징은 예측 가능한 성능을 제공할 수 있지만, 용량을 소비하고 운영 작업을 추가한다. 팀은 복사를 예약하고, 동기화를 모니터링하며, 오래된 데이터를 정리하고, 어떤 데이터세트에 빠른 스토리지를 할당할지 결정해야 한다.
NVIDIA cuObject는 객체 스토리지에서 가속기 메모리로 이어지는 더 평평한 경로를 제안한다. 엔드 투 엔드로 지원될 경우, 애플리케이션은 또 다른 전체 복사본을 먼저 만들지 않고도 기본 객체 리포지터리에서 읽을 수 있다.
이 이점이 모든 중간 작업을 없애는 것은 아니다. 데이터에는 여전히 디코딩, 압축 해제, 검증, 배치 처리 또는 변환이 필요할 수 있다. 스토리지 소프트웨어 역시 RDMA를 통해 페이로드를 전달하기 전에 내부 버퍼를 사용할 수 있다.
따라서 이번 출시는 전체 데이터 파이프라인이 아니라 전송 기회를 바꾼다. 애플리케이션은 여전히 형식, 접근 권한, 객체 메타데이터 및 장애 복구를 관리해야 한다. 스토리지 벤더는 가속 경로를 자체 배치 및 내구성 시스템에 연결해야 한다.
NVIDIA cuObject는 이러한 구성 요소 간 통합 계층으로 가장 잘 작동한다. 객체 스토어, S3 제어 플레인, 데이터 로더 또는 네트워킹 패브릭을 대체하지는 않는다.
SCADA Server SDK, GPU 쪽으로 요청 제어 이동
SCADA Server SDK는 또 다른 병목을 다룬다. 스토리지 한계에 도달하기도 전에 조정 작업이 CPU를 압도할 수 있는 수많은 소규모 요청이다.
대규모 순차 전송에서는 대역폭이 명확한 지표가 된다. 상당한 크기의 샘플이나 체크포인트를 읽는 학습 작업은 각 전송 전반에 걸쳐 요청 오버헤드를 분산할 수 있다. 제어 작업은 전체 작업에서 차지하는 비중이 작아진다.
추론 및 검색 시스템은 다른 패턴을 만든다. 시맨틱 검색, 추천, 사기 탐지 및 에이전트 메모리는 더 많은 소규모 조회를 생성할 수 있다. GPU는 높은 동시성으로 이러한 작업을 발행할 만큼 충분한 병렬 작업을 보유할 수 있다.
기존 스토리지 소프트웨어는 CPU가 이러한 요청을 구성하고, 제출하고, 완료할 것을 전제로 한다. 요청 크기가 작아지고 작업 수가 늘어날수록 이 설계의 효율은 낮아진다. 고정 처리 비용이 각 트랜잭션에서 더 큰 비중을 차지한다.
SCADA는 GPU 기반 클라이언트가 공통 인터페이스를 통해 스토리지 요청을 시작하도록 한다. 새 SDK는 타사 스토리지 제공업체에 그러한 요청을 수신하는 서버를 구축할 방법을 제공한다. 서버는 RDMA를 통해 데이터를 반환하기 전에 로컬 또는 원격 스토리지에서 요청을 처리할 수 있다.
이 SDK는 모든 스토리지 시스템이 내부 설계를 GPU에 직접 노출하도록 요구하지 않는다. 대신 SCADA 서버는 공유 클라이언트 인터페이스와 벤더별 스토리지 로직을 연결하는 가교 역할을 한다.
IBM은 IBM Storage Scale용 SDK 기반 초기 서버를 시연했다. 이 프로토타입에서 SCADA 클라이언트는 IBM이 구축한 서버로 요청을 보낸다. 이 서버는 공통 요청 모델을 Storage Scale에 연결한다.
이는 초기 상호운용성 신호이지만, 여전히 제한적이다. NVIDIA는 IBM 프로토타입에 대한 독립적인 프로덕션 결과를 공개하지 않았다. 발표에는 비교 가능한 지연 시간, 처리량 또는 CPU 사용률 측정값도 제공되지 않는다.
SCADA에는 서버 SDK 외의 지원 작업도 포함된다. NVIDIA는 NVMe 큐 접근을 프로비저닝하기 위한 Storage Lender Service를 공개했다. 명령줄 유틸리티 역시 SCADA 구성 요소의 구성과 배포를 돕기 위한 용도다.
Storage-Next 이니셔티브는 더 넓은 산업 맥락을 제공한다. NVIDIA는 이 그룹에 플래시, 컨트롤러, 스토리지 시스템, 클라우드 인프라 및 애플리케이션 개발 분야의 벤더와 고객 40여 곳이 참여한다고 말한다.
이 그룹은 GPU 주도 스토리지가 어떻게 동작해야 하는지 정의하려 시도하고 있다. 작업 범위는 대규모 데이터 이동과 소규모의 세분화된 작업을 모두 다룬다. 목표는 벤더 협업을 상호운용 가능한 인터페이스와 표준으로 전환하는 것이다.
이 시점은 변화하는 AI 데이터 접근 패턴을 반영한다. 학습은 여전히 중요하지만, 프로덕션 추론은 컨텍스트 검색, 도구 호출, 데이터베이스 조회 및 영속 메모리를 도입한다. 각 사용자 요청은 여러 하위 데이터 작업을 촉발할 수 있다.
긴 컨텍스트 서비스는 GPU 메모리 외부에도 압박을 만든다. 키-값 캐시 데이터는 이전에 처리된 토큰의 어텐션 상태를 기록한다. 이 상태를 가속기 메모리에 유지할 수 없을 때 시스템에는 이를 효율적으로 반환할 수 있는 다른 계층이 필요하다.
스토리지는 가속기 메모리보다 저렴하고 용량이 크지만, 지연 시간 특성은 다르다. SCADA는 병렬성을 통해 GPU가 이 격차를 견디도록 시도한다. 많은 GPU 스레드는 CPU 주도 요청 시퀀스를 기다리는 대신 여러 작업을 진행 중 상태로 유지할 수 있다.
이 개념은 cuObject를 대체하기보다 보완한다. NVIDIA cuObject는 S3 호환 객체 스토리지에 대한 가속 접근에 초점을 맞춘다. SCADA는 스토리지 구현 전반에서 GPU가 시작하는 세분화된 접근에 초점을 둔다.
함께 이들은 NVIDIA의 영향력을 컴퓨팅 영역에서 가속기와 저장된 데이터를 연결하는 프로토콜 영역으로 확장한다. 이러한 확장이 이번 발표의 핵심 경쟁 압력을 만든다.
개방형 인터페이스와 공급자별 가속의 경쟁
핵심 경쟁은 공유 가속기-스토리지 인터페이스와 각 클라우드 또는 스토리지 공급자에 맞춰 구축된 별도 통합 방식 사이에서 벌어진다.
RDMA 기반 객체 스토리지는 폭넓게 채택된 공통 와이어 프로토콜이 부족했다. GPU에 직접 접근하려는 개발자는 기존 S3 전송에 의존하거나, 중간 파일 시스템을 사용하거나, 특정 공급자의 가속 경로를 중심으로 구축할 수 있었다.
각 선택지는 서로 다른 비용을 수반한다. 기존 접근 방식은 호환성을 유지하지만 CPU 및 TCP 오버헤드도 그대로 남긴다. 스테이징은 데이터 복제와 맞바꾸어 데이터 지역성을 개선할 수 있다. 공급자별 통합은 우수한 성능을 낼 수 있지만 또 다른 종속성을 만든다.
NVIDIA는 xio-sig를 통해 이러한 파편화를 줄이려 한다. xio-sig organization은 클라이언트 API, 가속 와이어 프로토콜, 적합성 테스트 모음을 위한 별도의 cuObject 작업을 설명한다. 같은 조직에는 관련 cuFile 작업도 포함돼 있다.
인터페이스를 공개한다고 해서 호환 가능한 동작이 보장되는 것은 아니므로 적합성 검증이 중요하다. 구현체는 요청 의미론, 메모리 등록, 오류 처리, 보안 경계, 폴백 동작에 합의해야 한다. 장애와 동시성 상황에서도 일관되게 작동해야 한다.
공개 시점 기준으로 해당 공개 조직은 창립 참여자들이 계층을 통합하고 검증한 뒤 코드가 공개될 것이라고 밝히고 있다. 상태 페이지 역시 그 공개 전에 스택이 적합성 테스트를 통과해야 한다고 명시한다.
이는 NVIDIA의 발표와 완성된 상호운용성 계층 사이에 의미 있는 간극이 있음을 뜻한다. 저장소 구조는 마련됐고 의도된 구성 요소도 명명됐다. 다만 실제 프로덕션에 투입할 수 있는 구현의 상당 부분은 아직 공개 릴리스를 기다리고 있다.
Google Cloud와 Microsoft의 참여는 대규모 객체 스토리지 플랫폼을 운영하는 클라우드 공급자라는 점에서 중요한 신뢰성을 더한다. 이들의 참여는 xio-sig가 NVIDIA가 통제하지 않는 인프라도 수용할 수 있는지 시험하는 계기가 된다.
다만 파트너들의 약속 수준은 다르다. Google Cloud는 cuObject에 대한 더 폭넓은 참여를 검토하고 있으며, Microsoft는 이사회 참여 의향을 밝혔다. 어느 쪽의 발표도 자사 객체 서비스에서 일반 고객이 사용할 수 있게 된다는 점을 단독으로 확인하지는 않는다.
IBM의 프로토타입은 더 구체적인 구현 사례를 제공하지만, SCADA와 Storage Scale에 관한 것이다. 여러 독립적인 S3 호환 플랫폼이 하나의 프로덕션 검증 프로토콜을 통해 cuObject 트래픽을 교환할 수 있음을 입증하지는 않는다.
스토리지 기업에도 자체 가속 방식을 유지할 이유가 있다. 공급자별 경로는 차별화된 캐싱, 배치, 보안 또는 데이터 서비스를 제공할 수 있다. 공유 프로토콜은 상호운용성을 위해 충분히 폭넓어야 하지만, 이러한 기능을 지워서는 안 된다.
NVIDIA에도 자체적인 전략적 이해관계가 있다. 스토리지에서 GPU 메모리까지 이어지는 공통 경로는 더 큰 데이터세트에서 NVIDIA 가속기를 쉽게 사용하게 할 수 있다. 또한 네트워킹 제품, DPU, CUDA 소프트웨어, 스토리지 파트너를 조율된 아키텍처로 끌어들일 수 있다.
그렇다고 상호운용성 추진이 본질적으로 폐쇄적이라는 뜻은 아니다. 공개된 조직은 현재 저장소에 Apache-2.0 라이선스를 적용하고 있으며, 적합성 작업은 통합 위험을 낮출 수 있다. 그러나 거버넌스와 구현 세부 사항이 결과물이 얼마나 개방적인지를 결정할 것이다.
다른 가속기 공급자들도 또 하나의 시험대가 된다. NVIDIA의 게시물은 컴퓨팅 수요를 설명하면서 GPU, TPU, XPU를 언급한다. 진정으로 이식 가능한 스토리지 인터페이스라면 모든 계층에서 하나의 가속기 아키텍처에 의존해서는 안 된다.
가장 분명한 증거는 NVIDIA 이외의 구현체가 공유 테스트를 통과하는 데서 나올 것이다. 일반적인 프레임워크 내 지원도 중요하다. 개발자에게 조직 가입 여부보다 중요한 것은 기존 애플리케이션이 재작성 없이 백엔드를 바꿀 수 있는지다.
스토리지 구매자에게 실질적인 질문은 이식성이다. 인터페이스는 여러 지원 제품에서 애플리케이션 동작을 유지할 때 가치가 있다. 하나의 검증된 조합에 묶인 빠른 경로는 업계 표준이 아니라 여전히 통합 방식이다.
일반 공급이 배포 위험을 없애지는 않는다
라이브러리는 제공되지만, 프로덕션 도입에는 여전히 특수 네트워크, 수정된 소프트웨어, 신중한 메모리 관리, 신뢰할 수 있는 벤치마크가 필요하다.
cuObject release notes에 따르면 클라이언트는 2026년 8월 버전 1.3.0에 도달했다. 이전 릴리스에는 멀티패스 페일오버, 페일백, IPv6 지원이 추가됐다. 버전 1.3.0은 오래된 RDMA 토큰을 무효화하는 방법을 추가했다.
이러한 추가 사항은 운영상 우려를 해소하지만, 같은 문서에는 중요한 제한 사항도 나열돼 있다. 단일 메모리 등록 호출은 최대 크기가 4 GiB 미만이다. 동일한 등록 버퍼에서는 동시 GET 및 PUT 작업이 지원되지 않는다.
호스트 메모리 전송에는 등록된 버퍼가 필요하다. cuObject I/O 실행을 위한 스레드 풀이 없다는 점을 비롯해 일부 구성 동작은 cuFile과 다르다. 애플리케이션은 이 경로를 채택하기 전에 이러한 제약을 이해해야 한다.
메모리 수명 관리에는 특히 주의가 필요하다. 작업이 아직 진행 중인 동안 클라이언트는 버퍼를 재사용하거나 등록 해제해서는 안 된다. 오류 처리 역시 키가 재사용된 뒤 오래된 요청이 메모리 영역에 접근하지 못하도록 막아야 한다.
이러한 요구 사항은 고성능 RDMA 소프트웨어에서 드문 일이 아니다. 그럼에도 책임은 애플리케이션, 프레임워크, 스토리지 개발자에게 더 많이 이전된다. 잘못된 통합은 진단하기 어려운 장애를 일으킬 수 있다.
네트워크도 중요하다. InfiniBand 또는 RoCEv2 기반 DC 전송은 적절한 어댑터, 스위치, 라우팅, 구성을 전제로 한다. 조직은 인프라 작업 없이 일반 네트워크 전반에 가속 경로가 나타날 것이라 기대할 수 없다.
RoCE 배포는 혼잡과 패브릭 설계에 민감할 수 있다. 멀티패스 동작, 장애 복구, 텔레메트리는 현실적인 트래픽 조건에서 테스트해야 한다. 실험실에서 전송에 성공했다고 해서 클러스터 전체에서 예측 가능한 성능이 입증되는 것은 아니다.
보안도 동등한 주의를 기울일 만하다. 직접 데이터 이동은 페이로드 경로에서 CPU 개입을 줄이지만, 권한 부여를 우회할 수는 없다. 시스템에는 어떤 프로세스가 각 등록 영역과 저장 객체에 접근할 수 있는지 결정하는 신뢰할 수 있는 제어 계층이 여전히 필요하다.
NVIDIA는 SCADA가 권한 없는 애플리케이션 작업과 권한 있는 설정 구성 요소를 분리한다고 설명한다. 이러한 구조는 올바르게 구현될 경우 데이터 경로를 보호할 수 있다. 스토리지 공급자는 여전히 이를 테넌트 격리, 감사, 자격 증명 관리, 권한 철회와 연결해야 한다.
이번 발표에는 cuObject를 기존 S3, 스테이징 파일 접근 또는 공급자별 대안과 비교하는 표준화된 벤치마크가 없다. IBM 프로토타입의 성능 향상도 정량화하지 않았다.
이러한 누락은 광범위한 성능 결론을 막는다. RDMA는 복사와 CPU 처리를 줄일 수 있지만, 애플리케이션 결과는 객체 크기, 접근 패턴, 스토리지 매체, 네트워크 토폴로지, 동시성, 전처리에 따라 달라진다.
대규모 순차 읽기는 최적화된 파일 시스템을 통해서도 이미 충분한 성능을 낼 수 있다. 매우 작은 요청은 플래시 변환 계층, 메타데이터 서비스, 애플리케이션 동기화 등 다른 곳의 한계를 드러낼 수 있다.
SCADA를 둘러싼 independent storage analysis는 그 차이를 강조한다. 대량 전송과 세밀한 읽기는 서로 다른 요구 사항을 부과하므로, 하나의 헤드라인 처리량 수치로 둘 다 설명할 수 없다.
따라서 개발자는 NVIDIA cuObject를 보장된 성능 결과가 아니라 평가할 경로로 다뤄야 한다. 테스트에는 실제 객체 크기, 대표적인 동시성, 기존 변환 과정, 예상되는 장애 시나리오를 사용해야 한다.
신뢰할 수 있는 개념 검증은 대역폭 이상을 측정해야 한다. 꼬리 지연 시간, 서버 CPU 사용량, GPU 활용률, 메모리 등록 오버헤드, 복구 시간, RDMA 경로를 사용할 수 없게 될 때의 동작을 추적해야 한다.
팀은 폴백 동작도 검증해야 한다. 프로덕션 애플리케이션에는 서버가 RDMA를 지원하지 않거나 패브릭 구성 요소에 장애가 발생했을 때의 정의된 대응이 필요하다. 일반 객체 접근과의 호환성은 최고 가속 성능만큼 중요할 수 있다.
가장 강한 회의론은 기술적 가능성보다 채택에 관한 것이다. NVIDIA는 구성 요소를 구축할 수 있음을 보여줬다. 그러나 폭넓은 공급자가 여러 릴리스 주기에 걸쳐 호환 가능한 구현을 유지할 것인지는 아직 보여주지 못했다.
NVIDIA SCADA Server SDK 릴리스 이후 주목할 점
NVIDIA cuObject가 공유 인프라가 될지, 최적화된 파트너 통합의 집합으로 남을지를 보여줄 세 가지 신호가 있다.
첫 번째 신호는 작동하는 적합성 테스트를 수반한 공개 xio-sig 코드다. 이 조직은 cuObject 클라이언트 API, 와이어 프로토콜, 적합성 테스트 모음을 위한 저장소를 식별했다. 이들 저장소에는 인터페이스 설명만이 아니라 실질적인 구현이 필요하다.
독립적으로 유지되는 클라이언트와 서버 전반에서 테스트를 통과한다면 NVIDIA의 상호운용성 주장은 더욱 강해질 것이다. 지연, 좁은 테스트 범위, 하나의 하드웨어 조합에 대한 의존성은 이를 약화시킬 것이다.
두 번째 신호는 클라우드 및 스토리지 공급자의 프로덕션 지원이다. Google Cloud의 평가와 Microsoft의 계획된 이사회 참여는 의미 있지만, 고객 대상 가용성은 더 중요하다.
구매자는 지원되는 서비스 조합, 문서화된 배포 요구 사항, 명확한 호환성 매트릭스를 살펴봐야 한다. IBM Storage Scale을 넘어서는 더 많은 SCADA 서버 구현도 SDK가 다양한 스토리지 설계 전반으로 일반화되는지 시험할 것이다.
세 번째 신호는 워크로드별 증거다. 공급업체는 학습 데이터 수집, 체크포인트 작업, 검색, 시맨틱 검색, 추론 캐시 접근을 위한 재현 가능한 결과를 공개해야 한다. 이 테스트는 표준 객체 전송, 스테이징 워크플로, RDMA 지원 경로를 비교해야 한다.
결과에는 최고 처리량뿐 아니라 CPU 사용량과 꼬리 지연 시간도 포함돼야 한다. 또한 객체 크기, 네트워크 구성, 스토리지 매체, 장애 동작도 공개해야 한다. 이러한 맥락이 없으면 성능 수치를 적용하기 어렵다.
개발자는 아키텍처 연구를 위해 기다릴 필요가 없다. 애플리케이션이 객체 데이터를 스테이징하는 위치를 파악하고, 스토리지 전송에서 CPU 시간을 프로파일링하며, 요청 크기 분포를 측정할 수 있다. 이 작업은 cuObject 또는 SCADA가 실제 병목을 해결하는지 드러낸다.
마지막 질문은 RDMA가 데이터를 더 빠르게 이동할 수 있는지가 아니다. 여러 공급자가 애플리케이션을 좁은 스택에 가두지 않으면서 하나의 신뢰할 수 있는 경로를 제공할 수 있는지가 중요하다. 적합성 저장소, 지원되는 공급업체 제품, 재현 가능한 워크로드 테스트를 지켜봐야 한다. 이러한 신호가 NVIDIA cuObject가 이식 가능한 AI 스토리지 계층이 될지, 또 하나의 특수 가속 옵션이 될지를 결정할 것이다.
