OCI의 NVIDIA Vera Rubin, 멀티 기가와트 규모로 확장 추진… CPU 역할도 커져
NVIDIA와 Oracle은 10월 27일 NVIDIA Vera Rubin의 OCI 정식 출시와 함께 멀티 기가와트 규모 확장 계획을 발표했다. 이번 발표는 새로운 GPU 용량과 모델 호출 사이에 이뤄지는 작업을 위한 독립형 Vera CPU를 결합한다. 그 의미는 더 큰 클러스터에만 그치지 않는다. 고객은 애플리케이션 변화에 따라 이들 리소스를 각각 독립적으로 확장할 수 있다.
Oracle Cloud Infrastructure의 약자인 OCI는 모델을 호출하고 도구를 실행하는 소프트웨어 시스템인 에이전트를 개발하는 개발자들에게 이러한 유연성을 내세우고 있다. 이들 애플리케이션은 답변 생성과 일반적인 컴퓨팅 작업을 번갈아 수행한다. 모델 서빙 용량을 늘린다고 해서 주변 작업이 자동으로 빨라지는 것은 아니다.
핵심적인 긴장 관계는 설치된 컴퓨팅 용량을 확장하는 일과 그 용량의 생산성을 유지하는 일 사이에 있다. Google Cloud는 이미 Ironwood와 Axion을 통해 조율된 CPU 및 가속기 인프라를 홍보하고 있다. Oracle의 발표는 이러한 시스템 수준의 경쟁을 더욱 부각하는 한편, NVIDIA의 CPU 사업이 GPU와 나란히 더 눈에 띄는 위치를 차지하도록 한다.
OCI의 NVIDIA Vera Rubin, 출시와 확장 계획을 결합
즉각적인 제품 출시와 계획된 인프라 확장은 서로 다른 이정표다.
공동 Vera Rubin 확장 발표에서 NVIDIA와 Oracle은 현재 제공 가능 여부와 미래 규모를 구분했다. Vera Rubin NVL72 시스템과 Vera CPU는 OCI에서 정식으로 제공된다. 이들 시스템을 활용해 OCI Superclusters를 멀티 기가와트 규모로 확장하는 일은 여전히 발표된 계획이다.
이 구분은 헤드라인을 해석하는 독자에게 중요하다. 정식 출시는 상용 제품이 마련됐음을 뜻한다. 그렇다고 계획된 확장 전체가 설치되고, 전력이 공급되며, 예약되거나 고객 워크로드에 제공되고 있다는 의미는 아니다.
기가와트는 완료된 컴퓨팅 작업량이 아니라 전력을 측정하는 단위다. 전력 투자를 유용한 AI 서비스로 전환하려면 장비, 네트워킹, 냉각, 소프트웨어, 고객 배포가 필요하다. 따라서 헤드라인은 의도된 인프라 규모를 설명할 뿐, 그에 상응하는 애플리케이션 출력량이 제공됐음을 입증하지는 않는다.
랙 자체는 더 구체적인 기준점이 된다. NVIDIA의 NVL72 사양은 Rubin GPU 72개와 Vera CPU 36개를 결합한 구성을 설명한다. GPU, 즉 그래픽 처리 장치는 모델 학습과 추론, 다시 말해 모델 출력 생성 과정의 핵심인 병렬 연산을 처리한다.
이 구성 요소들은 랙 안에서 함께 작동하지만, 별도 CPU 제품은 다른 구매 결정을 겨냥한다. 도구 실행이나 애플리케이션 서비스를 운영하는 고객은 밀접하게 연결된 모델 서빙 시스템 외부의 컴퓨팅 용량이 필요하다. Oracle과 NVIDIA는 고객이 CPU와 GPU 리소스를 독립적으로 확장할 수 있다고 말한다.
실질적인 의미는 고객이 애플리케이션을 구성하는 방식의 유연성이다. 한 단계가 혼잡해질 때마다 모든 리소스 풀을 반드시 확장할 필요는 없다. 모델 생성, 코드 실행, 검색 또는 다른 단계 중 어느 부분에 추가 용량이 필요한지 평가할 수 있다.
이는 자동적인 효율 향상이 아니라 아키텍처상의 선택지다. 애플리케이션에는 여전히 작업을 적절한 리소스로 보내고 수요 변화에 대응하는 소프트웨어가 필요하다. 독립 확장은 운영자에게 하나의 제어 수단을 더 제공할 뿐, 이를 어떻게 활용할지는 결정해주지 않는다.
구매자 입장에서 이번 발표는 가용성과 제공 방식에 관한 별도 질문을 낳는다. 지금 어떤 구성을 확보할 수 있는가? 어디서 확보할 수 있는가? Oracle은 배포 기간 전체에 걸쳐 어느 정도의 용량을 약속할 수 있는가?
이 질문들은 확장 계획에 얼마나 큰 비중을 둘지도 결정한다. 장기 조달에는 대규모 미래 인프라가 유용한 맥락이 된다. 반면 구체적인 할당량, 지원되는 구성, 배포 일정은 엔지니어링 의사결정에 더 직접적인 근거를 제공한다.
에이전트 워크로드, 모델 호출 사이의 컴퓨팅에 부담 가중
이번 발표는 AI 용량을 주로 GPU 보유량으로 측정하는 팀에 문제를 제기한다.
모델 응답은 에이전트 작업의 일부일 뿐이다. 애플리케이션은 작업을 선택한 뒤 이를 실행하고, 결과를 검토하며, 다음에 무엇을 할지 결정해야 한다. 이 단계들은 서로 다른 컴퓨팅 요구 사항과 서로 다른 지연 원인을 만든다.
오류가 발생한 애플리케이션을 수정하도록 할당된 가상의 코딩 에이전트를 생각해 보자. 이 에이전트는 프로젝트 파일을 검색하고, 모델에 변경안을 제안하도록 요청하며, 테스트를 실행한 후 결과를 다음 판단을 위해 반환한다. 사용자는 하나의 연속된 작업으로 경험하지만, 모델과 테스트 실행기는 서로 다른 일을 수행한다.
생성이 제약 요인일 때는 모델 서빙 용량을 늘리는 것이 도움이 된다. 그러나 테스트가 실행 환경을 기다리거나 의존성 컴파일에 시간을 쓰는 경우에는 효과가 제한적이다. 핵심 질문은 어느 구성 요소의 사양이 가장 인상적인지가 아니라 워크플로가 어디에서 기다리는지가 된다.
NVIDIA와 Oracle은 도구 실행, 코드 테스트, 데이터 검색을 에이전트를 지원하는 CPU 집약적 작업으로 명시적으로 꼽는다. CPU, 즉 중앙 처리 장치는 일반적인 애플리케이션 명령을 실행하고 이 같은 주변 작업의 상당 부분을 관리한다. 양사는 독립형 Vera 용량을 이 단계들을 별도로 지원하는 수단으로 제시한다.
Oracle의 Vera CPU 배포는 초기 배포 규모로 CPU 15만 개를 제시한다. Oracle은 초기 고객 액세스도 언급하며, OpenAI가 에이전틱 워크로드를 위해 Vera를 프로덕션 환경에 도입하고 있다고 밝혔다. 이는 Oracle의 게시물을 통해 제시된 공급업체 및 고객의 발언이다.
CPU 수는 Oracle이 이 제품에 부여하는 규모를 보여준다. 하지만 특정 고객이 몇 개의 프로세서를 예약할 수 있는지, 얼마나 높은 부하로 운영하는지, 어느 정도의 애플리케이션 처리량을 제공하는지는 드러내지 않는다. 이러한 구분은 배포 규모가 운영 근거를 대체하는 일을 막는다.
즉각적인 부담은 인프라 기획자와 AI 애플리케이션 팀에 돌아간다. 이들은 모델 요청과 그 요청이 촉발하는 작업 간의 균형을 이해해야 한다. 가속기 수량을 중심으로 한 조달 절차는 이러한 균형을 충분히 검토하지 못한다.
그렇다고 모든 에이전트 애플리케이션에 특화된 CPU 배포가 필요한 것은 아니다. 일부 워크플로는 대부분의 시간을 외부 서비스를 기다리는 데 쓴다. 다른 워크플로는 도구 실행이 비교적 적으면서 긴 모델 응답을 생성한다. 적절한 리소스 조합은 애플리케이션의 실제 작업 순서에 달려 있다.
같은 원칙은 지식 워크플로에도 적용된다. AI 지식 베이스를 검색하는 어시스턴트는 유용한 답변을 만들기 전에 관련 자료를 검색해야 한다. 문서에 접근할 수 없거나, 권한이 누락됐거나, 검색이 느린 문제는 생성 용량을 추가한다고 보완되지 않는다.
기업 구매자에게 이는 인프라 의사결정을 사용자 경험과 연결한다. 작업 경로의 어느 지점에서든 멈추면 서비스는 느리게 느껴진다. 고객은 지연이 모델, 도구, 데이터베이스, 혹은 이를 조율하는 소프트웨어 중 어디에서 발생했는지 거의 구분하지 않는다.
따라서 이번 발표는 더 폭넓은 평가 기준을 유도한다. 팀은 중간 단계를 포함해 인프라가 완료된 작업을 어떻게 지원하는지 물어야 한다. 이것이 이번 출시가 만들어낸 부담이다. 애플리케이션 성능을 설명하는 일은 설치된 하드웨어를 설명하는 일만큼 중요해지고 있다.
독립 확장은 스케줄링 문제를 해결한다
CPU와 GPU 확장을 분리하는 방식은 애플리케이션이 그 분리를 효과적으로 활용할 수 있을 때만 도움이 된다.
OCI의 NVIDIA Vera Rubin이 제공하는 방식은 아키텍처 수준에서는 단순하다. 모델이 필요로 하는 곳에서는 밀접하게 연결된 리소스를 함께 유지한다. 수요 패턴이 다른 주변 작업에는 별도의 컴퓨팅 용량을 제공한다.
NVIDIA의 Rubin 플랫폼 아키텍처는 조율된 컴퓨팅, 네트워킹, 소프트웨어를 중심으로 설계된 시스템을 설명한다. 프로세서 간 NVIDIA의 고속 연결인 NVLink는 모델 컴퓨팅 시스템 내부의 통신을 지원한다. 이 내부 연결은 별도의 도구 실행 워커 풀을 할당하는 것과는 다른 목적을 가진다.
이 구분은 흔한 오해를 피하게 한다. 독립 확장은 NVL72 랙 내부의 모든 구성 요소가 독립적으로 바뀐다는 뜻이 아니다. 이는 고객이 애플리케이션 인프라 전반에서 서로 다른 CPU 및 GPU 리소스를 확장할 수 있다는 의미다.
코딩 에이전트 사례로 돌아가 보자. 테스트 활동이 급증하면 모델 수요는 비교적 안정적인 상태에서 추가 실행 워커가 필요할 수 있다. 다른 워크로드는 컴파일이나 테스트 증가에 비례하지 않는 더 많은 모델 요청을 생성할 수 있다.
고정 할당은 한 리소스 풀이 충분히 활용되지 않는 동안 다른 풀이 대기열을 형성하게 할 위험이 있다. 독립 풀은 운영자가 이러한 불균형을 조정할 방법을 제공한다. 다만 이점은 소프트웨어가 제약 요인을 인식하고 유용한 용량을 제때 프로비저닝할 수 있는지에 달려 있다.
이때 스케줄링, 즉 사용 가능한 리소스에 작업을 배정하는 일이 핵심이 된다. 애플리케이션은 도구가 어디에서 실행되는지, 어떤 데이터를 받는지, 결과가 언제 반환되는지를 결정해야 한다. 작업이 효율적으로 도달할 수 없다면 추가 프로세서는 불완전한 해답에 머문다.
데이터 배치는 결정을 더 복잡하게 만든다. 워커는 파일, 의존성, 자격 증명, 관련 애플리케이션 상태에 접근해야 한다. 실행을 모델 서빙 인프라에서 분리하면 소프트웨어가 관리해야 할 또 하나의 경계가 생긴다.
이 경계가 본질적으로 단점인 것은 아니다. 더 명확한 할당과 격리를 지원할 수 있다. 그러나 구매자는 별도 리소스 풀의 이점을 평가할 때 그 운영상 결과도 포함해야 한다.
유용한 평가는 대표적인 작업을 제출부터 완료까지 추적한다. 모델 출력 생성, 도구 대기, 코드 실행, 정보 검색, 실패한 단계 재시도에 소요된 시간을 기록한다. 목표는 추가 용량이 결과를 바꾸는 지점을 파악하는 것이다.
성공적인 완료 여부도 중요하다. 더 많은 작업이 실패하거나 추가 시도가 필요하다면 실행 속도가 빨라도 가치가 낮다. 의미 있는 비교는 작업과 승인 기준을 일정하게 유지하면서 소비된 리소스를 살핀다.
이는 발표에서 공개된 결과가 아니라 평가 원칙이다. 어떤 근거가 양사의 효율성 주장을 뒷받침할 수 있는지를 설명한다. 이번 출시는 사용 가능한 아키텍처를 제시한다. 특정 애플리케이션에서의 가치는 고객 측정치가 입증해야 한다.
워크로드가 시간이 흐르며 바뀌면 운영상의 과제는 커진다. 오늘은 주로 질문에 답하는 서비스가 제품 업데이트 이후 더 많은 작업을 수행할 수 있다. 독립 확장은 애플리케이션이 운영자에게 필요한 정보를 제공한다는 전제 아래 대응할 여지를 준다.
이 때문에 CPU 제품은 GPU 출시의 단순한 부속품을 넘어선다. NVIDIA와 Oracle이 애플리케이션 인프라에 참여할 수 있는 또 하나의 영역을 만든다. 고객이 혜택을 얻는지는 그 인프라가 실제 수행하는 작업과 얼마나 긴밀하게 맞아떨어지는지에 달려 있다.
클라우드 경쟁사들이 완전한 AI 애플리케이션을 중심으로 경쟁하고 있다
Oracle의 발표는 AI 모델을 지원하는 범용 컴퓨팅까지 포함한, 조율된 시스템을 둘러싼 경쟁의 일부다.
Google Cloud는 가속기와 CPU 개발을 명시적으로 연결한다는 점에서 유용한 비교 대상이다. Ironwood와 Axion 발표에서는 에이전트 워크플로에 필요한 조율을 다룬다. Ironwood는 머신러닝용으로 특화된 Google의 프로세서인 TPU이며, Axion은 범용 컴퓨팅을 지원한다.
이 비교가 중요한 이유는 아키텍처에 있다. Google은 모델 가속을 애플리케이션 서비스, 데이터 준비 및 그 주변에서 필요한 다른 작업과 함께 설명한다. Oracle과 NVIDIA 역시 이제 Rubin 시스템과 독립적으로 제공되는 Vera CPU를 통해 비슷한 필요성을 강조하고 있다.
그렇다고 동등한 제품이나 성능이 입증되는 것은 아니다. 각 플랫폼은 프로세서, 소프트웨어 환경, 서비스 제공 범위, 배포 방식에서 차이가 있다. 그럼에도 이들 발표는 공통된 구매 질문을 제기한다. 완전한 시스템이 애플리케이션을 얼마나 잘 지원하는가?
Oracle에 있어 독립형 Vera CPU는 NVIDIA 가속기 접근성 이상의 논의를 넓힌다. 회사는 모델 서빙과 그 주변의 실행 작업을 위한 리소스를 제안할 수 있다. 이는 고객이 에이전트를 어디에서 실행할지 결정할 때 평가할 또 하나의 구성을 제공한다.
NVIDIA에 있어 이번 발표는 통합 랙 내부 역할을 넘어 CPU의 상업적 중요성을 확대한다. 고객이 별도의 실행 서비스에 Vera를 채택한다면, NVIDIA는 고객 컴퓨팅 아키텍처의 더 큰 부분에 참여하게 된다.
이 기회를 보편적인 마이그레이션 사례로 혼동해서는 안 된다. 기존 애플리케이션에는 이미 정착된 종속성과 운영 관행이 있다. 팀은 새 구성을 채택하고 유지하는 데 필요한 작업과 비교해 평가해야 한다.
경쟁 압력은 전통적인 서버 배포에도 미친다. Vera를 고려하는 구매자는 이미 도구와 애플리케이션 서비스를 실행 중인 시스템과의 비교를 원할 것이다. 익숙한 인프라는 팀이 자체 워크로드에서의 동작을 이해하고 있으므로 실질적인 기준선이 된다.
따라서 가장 강력한 비교는 고객의 기존 애플리케이션에서 시작한다. 실행 플랫폼을 바꾸는 것이 작업 완료, 응답성, 리소스 소비 또는 운영 안정성을 개선하는지 살펴본다. 구성 요소 수준의 이점은 이 결정의 일부만 다룬다.
소프트웨어 연속성도 중요하다. 이미 모델 서빙 환경을 구축한 기업은 새 구성이 배포 및 지원 프로세스에 어떻게 맞는지 검토하게 된다. 이런 프로세스를 무시하는 하드웨어 평가는 도입에 필요한 작업을 과소평가한다.
이 때문에 경쟁 구도는 근거 없는 승자 주장과 분리되어야 한다. Oracle의 출시로 이용 가능한 선택지가 확대된다. Google의 CPU 및 가속기 전략은 관련 맥락을 제공한다. 어느 발표도 모든 에이전트 워크로드에서 어떤 플랫폼이 최상의 결과를 제공하는지 입증하지는 않는다.
더 큰 변화는 공급업체가 고객에게 무엇을 평가하라고 요구하는지에 있다. 가속기 사양은 여전히 중요하지만, 이를 뒷받침하는 실행 환경도 점차 같은 논의에 포함되고 있다. 인프라 제공업체는 구성 요소가 작업 전반에서 어떻게 협력하는지 설명해야 한다.
OCI에서 NVIDIA Vera Rubin을 추적하는 독자에게 이것이 가장 유용한 경쟁 구도다. 헤드라인은 더 큰 규모의 인프라 투자에 관한 것이다. 구매 결정은 특정 서비스 조합이 현재 구성보다 애플리케이션을 더 효과적으로 지원할 수 있는지에 달려 있다.
가용성과 프로세서 수는 중요한 질문을 남긴다
이번 발표는 제품과 계획을 제시하지만, 고객 생산성의 보편적인 향상을 입증하지는 않는다.
첫 번째 불확실성은 일반 공급과 실질적인 접근성의 연결에 관한 것이다. 공개 출시가 모든 고객의 할당량, 배포 위치 또는 제공 일정을 명시하는 것은 아니다. 구매자는 발표를 구현 계획으로 전환하기 전에 이러한 세부 정보를 알아야 한다.
두 번째는 계획된 멀티기가와트 규모에 관한 것이다. 발표는 확장을 설명하지만, 헤드라인만으로는 완전한 제공 일정을 알 수 없다. 추가 정보가 제공됨에 따라 독자는 목표 규모와 실제 운영 용량을 구분해야 한다.
세 번째는 애플리케이션 결과다. 대규모 CPU 배포와 새로운 GPU 세대만으로 에이전트가 유용한 작업을 얼마나 더 빠르게 완료하는지 정량화할 수는 없다. 이를 위해서는 정의된 워크로드와 명확한 기준선과의 비교가 필요하다.
Oracle의 발표에는 성능 관련 주장이 포함되어 있지만, 독립적으로 평가 가능한 방법론이 뒷받침되지 않는다면 이는 여전히 회사의 주장에 머문다. 구매자는 홍보되는 개선 사항의 구성, 소프트웨어, 워크로드 및 측정 범위를 검토해야 한다.
이 범위는 에이전트에서 특히 중요하다. 프로세서의 실행 속도를 측정하는 일은 모델 호출과 외부 서비스를 포함하는 완전한 작업을 측정하는 일과 다르다. 한 단계의 개선이 전체 워크플로에서 동일한 개선을 입증하지는 않는다.
리소스 활용률과 고객 가치 사이에도 차이가 있다. 바쁘게 작동하는 프로세서는 생산적인 작업, 재시도 또는 불필요한 연산을 처리하고 있을 수 있다. 높은 활동량은 승인 가능한 결과에 기여할 때에만 의미가 있다.
반대로 일부 유휴 용량은 운영 목적에 부합한다. 애플리케이션은 급증하는 수요, 장애 또는 응답 시간 요구 사항에 대비해 여유 용량을 유지할 수 있다. 평가는 피할 수 있는 낭비와 서비스 약속을 지키기 위해 확보한 용량을 구분해야 한다.
독립적인 확장은 의사결정도 애플리케이션 운영자에게 넘긴다. 팀은 언제 용량을 추가할지, 얼마나 유지할지, 종속성이 실패할 때 어떻게 대응할지를 결정해야 한다. 유연성은 가치가 있지만, 측정과 운영 판단이 필요한 선택지를 수반한다.
보안은 또 다른 차원을 더한다. 생성된 코드를 실행하는 에이전트는 환경과 접근 권한에 대한 통제가 필요하다. 격리된 실행 환경인 샌드박스는 해당 코드가 접근할 수 있는 범위를 제한하지만, 그 효과는 주변 구현에 따라 달라진다.
고객은 처리량과 함께 실행 권한, 데이터 처리, 장애 격리를 평가해야 한다. 부적절한 접근 권한을 가진 더 빠른 워커가 더 나은 프로덕션 시스템을 만드는 것은 아니다. 이는 에이전트가 독점 정보를 검색하거나 연결된 엔터프라이즈 도구를 통해 작업할 때 특히 중요하다.
마이그레이션은 별도의 질문을 제기한다. 애플리케이션을 다른 CPU 환경으로 옮기려면 소프트웨어 종속성과 배포 호환성을 확인해야 한다. 관련 작업량은 애플리케이션에 따라 달라지므로, 광범위한 출시 발표가 모든 고객의 경우를 해결할 수는 없다.
이러한 불확실성이 출시의 타당성을 무효화하는 것은 아니다. 이는 이를 정확히 판단하는 데 필요한 증거를 보여준다. 기업들은 명확한 아키텍처적 근거를 갖춘 인프라 옵션을 발표했으며, 그에 따른 운영상 이점은 여전히 워크로드에 따라 달라진다.
따라서 신중한 해석은 구체적이다. 독립적인 CPU 및 GPU 리소스는 고객에게 수요 불일치를 해결할 또 하나의 방법을 제공한다. 이 옵션이 낭비를 줄이거나 응답성을 개선하는지는 애플리케이션 수준의 결과를 통해 입증되어야 한다.
용량 접근성, 고객 측정치, 실행 소프트웨어를 주시하라
다음 증거는 발표된 인프라를 실제 확보 가능한 용량 및 완료된 고객 워크로드와 연결해야 한다.
첫 번째 신호는 더 구체적인 접근성 정보다. 향후 수개월 동안 고객은 지원되는 구성, 배포 위치, 할당 조건 및 확장 이정표를 살펴봐야 한다. 이러한 세부 정보는 발표된 제품이 실질적인 용량으로 어떻게 전환되는지 명확히 해줄 것이다.
더 구체적인 제공 정보는 확장이 단기 고객 계획을 뒷받침한다는 근거를 강화할 것이다. 그에 상응하는 접근성 세부 정보 없이 총규모만 계속 강조된다면, 이 부분의 이야기는 덜 해소된 상태로 남을 것이다.
이 신호는 GPU 시스템과 독립형 CPU에 각각 중요하다. 하나를 채택하는 고객이 다른 하나를 채택하는 고객과 동일한 요구 사항이나 일정에 놓이는 것은 아니다. 별도의 가용성 정보는 독립적 확장 제안을 더 쉽게 평가하게 할 것이다.
두 번째 신호는 완전한 워크플로에 대한 고객 측정이다. 유용한 증거는 애플리케이션, 이전 구성, 변경된 리소스 및 수용 기준을 설명해야 한다. 또한 작업 완료와 리소스 소비에 어떤 변화가 있었는지도 설명해야 한다.
예를 들어 코딩 에이전트 평가는 모델 생성에서 멈추지 않고 실행과 테스트를 포함해야 한다. 검색 애플리케이션은 기반 정보에 대한 접근을 포함해야 한다. 사용자의 작업이 이러한 경계를 넘나드는 과정을 따라갈 때 비교는 더욱 설득력을 갖는다.
추가 Vera 용량이 측정된 실행 제약을 해소한다는 증거는 출시의 핵심 주장을 뒷받침할 것이다. 대부분의 지연이 다른 곳에서 발생한다는 결과는 관련 사용 사례를 좁힐 것이다. 어느 결과든 구매자가 더 정보에 근거한 결정을 내리는 데 도움이 된다.
세 번째 신호는 별도의 리소스 풀을 더 쉽게 운영하게 하는 프로덕션 소프트웨어다. 애플리케이션이 워커 할당, 데이터 접근, 실행 상태 및 장애를 어떻게 처리하는지 살펴봐야 한다. 이러한 역량은 독립 리소스가 조율된 서비스로 기능하는지를 결정한다.
하드웨어 옵션이 자동으로 사용 가능한 애플리케이션 아키텍처를 만들어 주지는 않으므로 이 신호는 주목할 가치가 있다. 운영자는 작업이 어디에서 대기하는지 이해할 수 있는 충분한 가시성과 대응할 수 있는 충분한 통제력을 필요로 한다. 더 나은 조율은 모든 구성 요소가 동일하게 개선될 필요 없이 효율성 사례를 강화할 것이다.
이 세 신호는 OCI에서 NVIDIA Vera Rubin을 추적하는 현실적인 방법을 제공한다. 용량 공개는 제공 문제를 다룬다. 고객 측정치는 가치를 다룬다. 실행 소프트웨어는 이용 가능한 구성 요소를 연결하는 실질적인 작업을 다룬다.
개발자에게 이번 발표는 자체 에이전트 워크플로가 어디에서 시간을 소비하는지 점검할 이유가 된다. 엔터프라이즈 구매자에게는 애플리케이션 수준의 증거를 요청할 이유가 된다. 사용자에게 중요한 결과는 유용한 작업을 안정적으로 완료하는 서비스로 남는다.
새 인프라 구성을 확정하기 전에 대표적인 작업을 시스템 전체에서 추적하고 실제 제약을 파악해야 한다. 제공업체에 이용 가능한 용량과 계획된 확장을 구분하고, 구성 요소 주장을 측정된 애플리케이션 결과와 구분해 달라고 요청하라. 평가에는 실행, 검색, 장애 및 복구를 포함하라. 대안을 비교할 때 워크로드와 수용 기준을 일관되게 유지하라. 이러한 접근 방식은 구매 결정을 고객이 완료해야 하는 작업과 연결한 채 OCI의 NVIDIA Vera Rubin을 공정하게 평가할 수 있게 한다. 애플리케이션의 어느 단계가 추가 CPU 또는 GPU 용량으로 개선될 수 있으며, 어떤 측정으로 그 개선을 보여줄 수 있는가?
