Google의 에이전틱 AI CPU 수요, 유휴 컴퓨팅에 대한 검토 촉발
Google은 AI 에이전트가 새로운 CPU 수요를 만들어낼 것이라고 말한다. 그러나 에이전트의 실행 환경은 긴 시간 동안 대기 상태로 머물 수 있다. 따라서 Google의 에이전틱 AI CPU 수요는 단순히 프로세서를 추가하는 것보다 더 까다로운 문제를 수반한다. 유휴 하드웨어를 예약하지 않으면서도 지속적인 소프트웨어 작업자를 즉시 사용할 수 있게 유지해야 하기 때문이다. 애플리케이션 코드를 실행하는 범용 프로세서인 CPU는 에이전트가 답변 생성에서 나아가 소프트웨어를 조작하기 시작할 때 핵심 요소가 된다.
10월 30일 EE Times 인터뷰에서 Google Cloud 임원 Mark Lohmeyer는 에이전트가 서비스를 호출하고, 웹사이트를 탐색하며, 코드를 실행한다고 설명했다. 이러한 활동은 모델 주변의 컴퓨팅 작업을 늘린다. 병렬 계산에 최적화된 프로세서인 GPU와 Google의 특수 머신러닝 칩인 TPU는 여전히 모델 계산의 상당 부분을 담당한다. 그러나 주변 애플리케이션에는 별도의 실행 용량이 필요하다.
이는 클라우드 플랫폼과 기업 인프라 팀에 부담을 준다. 모델 서빙 속도를 중심으로 설계된 시스템도 에이전트가 작업 공간을 기다리거나 세션 상태를 잃거나 불필요하게 리소스를 예약하면 기대에 못 미칠 수 있다. AWS도 유사한 실행 서비스를 추진하고 있어 구매자에게 경쟁적 비교 기준을 제공한다. 핵심 경쟁은 지속적으로 예약된 환경과, 비활성 컴퓨팅을 해제하면서 에이전트의 작업을 보존하는 인프라 사이에서 벌어진다.
Google의 에이전틱 AI CPU 수요는 모델 서빙을 넘어선다
Google의 주장은 특수 AI 프로세서를 대체하는 것이 아니라 AI 모델을 둘러싼 인프라에 관한 것이다.
AI 및 컴퓨팅 인프라 부문을 총괄하는 Google의 부사장 겸 총괄 매니저 Lohmeyer는 에이전트 워크로드 논의에서 이 차이를 설명했다. EE Times에 따르면 에이전트는 사용자의 요청을 일반적인 소프트웨어 실행이 수반되는 하위 작업으로 나눈다. 그 결과 워크로드는 간헐적으로 발생하며, 프로세서·스토리지·리소스 관리에 서로 다른 요구 사항을 만든다.
중요한 점은 모델이 행동을 선택한 뒤에 일어나는 일이다. 그럴듯한 지시를 만들어내는 것과 지시된 작업을 완료하는 것은 서로 다른 리소스를 소비한다. 브라우저는 페이지를 불러와야 하고, 프로그램은 실행돼야 하며, 애플리케이션은 결과를 반환해야 한다. 의사결정에 지능을 추가한다고 해서 이러한 작업이 사라지지는 않는다.
에이전트란 모델을 활용해 목표를 향한 행동을 선택하고 수행하는 소프트웨어를 뜻하며, 이 단계들을 연결한다. 그 유용성은 전체 순서에 달려 있다. 다음 실행 환경을 사용할 수 있게 되기까지 너무 오래 걸린다면 모델의 빠른 응답은 제한적인 이점만 제공한다.
이는 모델 서빙 용량과 함께 CPU 요구 사항에도 주목해야 하는 이유를 설명한다. 모델 서빙은 학습된 모델을 실행해 출력을 생성하는 것을 의미한다. 에이전트의 전체 실행에는 이 작업뿐 아니라 이를 둘러싼 코드와 서비스도 포함된다. 모델만 측정하면 애플리케이션 일부가 성능 평가에서 빠지게 된다.
이 인터뷰 역시 모든 상황에 적용되는 단일 프로세서 우승자를 제시하지는 않는다. Lohmeyer는 Google Cloud가 Arm 기반 Axion 칩과 함께 Intel 및 AMD 프로세서를 사용한다고 설명했다. Arm과 x86은 소프트웨어가 실행하는 기계 명령을 결정하는 프로세서 명령어 세트 계열이다. 서로 다른 에이전트 워크로드는 코어 성능, 코어 수, 연결된 스토리지의 서로 다른 조합에 유리할 수 있다.
이 구분은 제목을 해석할 때 중요하다. 에이전트 활동 증가가 모든 CPU 범주에 똑같이 이득이 된다는 뜻은 아니다. 프로그램 실행이 대부분인 워크로드는 외부 서비스를 기다리는 시간이 대부분인 워크로드와 다르다. 구매자는 여전히 자신이 실제로 실행할 작업을 이해해야 한다.
Google의 에이전트 인프라는 이제 이 주장을 더 구체적으로 만든다. 10월 22일 Google은 Gemini 업무 작업을 이미 지원하는 서비스라고 설명하며 Agent Compute Engine을 공개했다. 발표는 향후 몇 달 내 고객 프리뷰 제공을 목표로 했다. 11월 1일 기준으로 이 표현을 정식 출시로 해석해서는 안 된다.
이 순서는 인터뷰에 구체적인 맥락을 제공한다. Google은 이를 해결하기 위한 상용 서비스를 준비하면서 실행 문제를 설명하고 있다. 이는 해당 기업의 엔지니어링 설명을 관련성 있게 만드는 동시에, 독자가 문서화된 아키텍처와 예상되는 고객 혜택을 구분해야 할 이유를 제공한다.
인프라 팀이 대기 비용을 떠안는다
직접적인 부담은 유용한 작업이 간헐적으로 발생하는 사이에도 에이전트 환경을 준비 상태로 유지해야 하는 팀에 돌아간다.
지속적인 환경은 상호작용 사이에 작업 자료를 보존한다. 여기에는 파일, 설치된 소프트웨어, 애플리케이션 상태가 포함될 수 있다. 지속성은 긴 작업 전반에 걸쳐 에이전트를 유용하게 만들지만, 리소스 관리를 복잡하게 한다. 정보를 계속 사용할 수 있게 하는 일과 프로세서를 계속 할당하는 일은 별개의 요구 사항이다.
리포지토리 변경 작업을 수행하는 코딩 어시스턴트를 생각해 보자. 이 어시스턴트는 파일을 읽고, 프로그램을 실행하며, 모델 출력을 기다리고, 개발자에게 승인을 요청한다. 이러한 대기 시간 내내 작업 공간은 중요하게 유지된다. 하지만 프로세서까지 같은 기간 내내 예약 상태를 유지할 필요는 없다.
이는 측정된 고객 배포 사례가 아니라 예시 워크로드다. 세션 경과 시간이 실제 실행 수요를 잘못 나타낼 수 있는 이유를 보여준다. 비활성 상태인 세션도 여전히 가치가 있을 수 있다. 열려 있는 모든 세션을 계속 바쁜 상태로 취급하면 이 차이가 가려진다.
그 결과는 애플리케이션의 비즈니스 모델에도 영향을 미친다. 에이전트 경험을 구매하는 고객은 완료된 작업과 신뢰할 수 있는 연속성을 원한다. 인프라 제공업체는 어느 정도의 하드웨어를 예약할지 결정하면서 이러한 결과를 제공해야 한다. 잘못된 할당은 사용자의 결과를 개선하지 못한 채 운영 비용만 높일 수 있다.
이때 작업 실행에 사용되는 가용 프로세서 용량의 비율인 에이전트 CPU 활용률이 중요해진다. 그러나 평균 활용률 수치가 전체 경험을 설명하지는 못한다. 많은 대기 중인 에이전트가 동시에 활성화될 때 어려움을 겪는 플랫폼도 평균 사용률은 낮게 나타날 수 있다.
이는 상충하는 운영 요구 사항을 만든다. 제공업체는 용량을 효율적으로 공유하려 하고, 사용자는 작업이 재개될 때 즉시 접근할 수 있기를 기대한다. 시스템이 다시 활성화되는 활동을 처리할 수 있을 때만 환경을 빽빽하게 배치하는 것이 도움이 된다. 사용량이 많은 시기의 지연은 세션을 계속 이용 가능하게 유지하는 이점을 없앨 수 있다.
Google의 9월 15일 Agent Substrate 설명은 유휴 실행 환경과 활동 급증을 명시적으로 다룬다. Google은 에이전트 실행을 기반 머신 관리와 분리하는 소프트웨어를 설명한다. 또한 워크로드마다 동일한 보안 요구 사항을 공유하지 않는다는 점을 반영해 서로 다른 격리 방식을 제공한다.
이 부담은 기업 조달로도 이어진다. 이제 용량 논의에는 에이전트가 어떻게 일시 정지하고, 작업을 보존하며, 재개하는지도 포함돼야 한다. 프로세서 사양만으로는 이러한 질문에 답할 수 없다. 실행이 간헐적으로 발생하는 사이의 서비스 동작이 구매 대상 제품의 일부가 된다.
이는 내부 책임 구조도 바꾼다. 애플리케이션 팀은 에이전트 프레임워크를 선택할 수 있고, 플랫폼 팀은 소프트웨어를 실행하는 환경인 런타임을 관리할 수 있다. 어느 팀도 비활성 리소스 할당을 측정하지 않으면 불필요한 소비가 책임 경계 사이에서 발생할 수 있다. 그로 인한 문제는 모델 평가가 아니라 인프라 청구서에서 드러난다.
개발자에게 실질적인 시사점은 아키텍처에 있다. 오래 지속되는 사용자 경험이 반드시 똑같이 오래 지속되는 프로세서 예약을 요구해서는 안 된다. 플랫폼이 이 두 수명을 분리할 수 있는지가 유용한 프로토타입이 서비스로 얼마나 원활하게 확장되는지를 결정한다.
지속적인 작업 공간은 지속적으로 예약된 컴퓨팅에 도전한다
핵심 설계 질문은 에이전트가 일시적으로 필요하지 않은 하드웨어를 반납하면서도 작업 환경을 유지할 수 있는지다.
기존 애플리케이션도 이미 유휴 기간을 처리하므로, 이 근본적 문제에는 선례가 있다. 에이전트 워크로드는 신뢰하기 어려울 수 있는 코드와 개인화된 지속형 작업 공간을 결합함으로써 이를 더욱 첨예하게 만든다. 환경은 중단이 이어져도 유용하게 남아야 하며, 불필요한 영구 할당이 되어서는 안 된다.
마이크로VM은 하드웨어 가상화를 이용해 실행 환경을 격리하는 경량 가상 머신이다. 샌드박스는 코드를 제한하고 접근을 통제하기 위한 제한된 환경이다. 이 개념들은 에이전트 플랫폼에서 겹치지만, 구현 메커니즘과 보안 목적이라는 서로 다른 것을 설명한다.
메커니즘만으로 경제성이 결정되지는 않는다. 작고 격리된 머신도 아무 작업을 하지 않는 동안 리소스를 예약할 수 있다. 효율성은 서비스가 전체 수명 주기를 어떻게 관리하는지에 달려 있다. 환경을 시작하고, 일시 정지하고, 보존하고, 복원하고, 삭제하는 모든 과정이 중요한 작업이 된다.
실행 상태의 저장된 표현을 뜻하는 스냅샷은 연속성을 보존하는 방법을 제공한다. 이 상태를 복원하면 처음부터 환경을 다시 구축하지 않아도 된다. 그러나 저장과 복원에는 스토리지와 데이터 이동도 수반된다. 워크로드를 활성 메모리에서 꺼내면 요구 사항은 다른 곳으로 이동한다.
따라서 CPU 계획은 스토리지 계획과 분리할 수 없다. 환경 복원에 긴 지연이 생긴다면 프로세서를 해제하는 이점은 줄어든다. 마찬가지로 모든 것을 무기한 보존하면 스토리지 의무가 계속 늘어날 수 있다. 완전한 설계에는 활성 실행뿐 아니라 보존 상태에 대한 정책도 필요하다.
Google의 지속적인 에이전트 환경 기술 설명은 파일과 메모리를 보존하면서 비활성 세션을 체크포인트하는 방식을 다룬다. 체크포인팅은 복구 가능한 실행 상태를 저장하는 것을 의미한다. Google은 또한 장기 지속 자격 증명을 게스트 환경 외부에 보관하고 제어된 게이트웨이를 통해 요청을 라우팅하는 방식을 설명한다. 이는 독립적인 보안 조사 결과가 아니라 해당 설계에 대한 기업의 설명이다.
더 넓은 분석 관점에서 연속성은 시스템의 속성이 된다. 사용자는 에이전트를 진행 중인 작업으로 경험하지만, 그 아래 인프라는 서로 다른 리소스 상태를 거칠 수 있다. 성공적인 구현은 작업을 잃거나 접근 제어를 약화하지 않으면서 이러한 전환을 숨긴다.
AWS는 6월 22일 Lambda MicroVMs를 공개하며 유용한 비교 사례를 제시했다. AWS는 직접적인 수명 주기 제어와 보존된 상태를 갖춘, 사용자가 작성했거나 AI가 생성한 코드를 위한 격리 환경을 설명한다. 이 구현은 회사의 경량 가상화 기술인 Firecracker를 기반으로 한다.
이 비교는 공통된 인프라 문제가 존재한다는 점을 뒷받침한다. 그러나 Google과 AWS의 서비스가 동일한 성능을 내거나, 똑같은 워크로드를 지원하거나, 동등한 운영 제약을 부과한다는 것을 입증하지는 않는다. 두 회사가 공개한 설명은 완성된 비교가 아니라 평가의 출발점을 제공한다.
Google의 에이전트 인프라는 따라서 에이전트 애플리케이션의 일부로 실행 환경을 관리하는 더 큰 전환에 속한다. 여기서 중요한 경쟁은 단순히 어느 제공업체가 더 많은 프로세서 코어를 제공하느냐가 아니다. 유용한 작업을 보존하고, 재개된 활동을 처리하며, 리소스 소비를 이해하기 쉽게 만드는 서비스가 무엇이냐에 달려 있다.
구매자에게 이 차이는 평가 질문을 바꾼다. 빈 환경이 얼마나 빨리 시작되는지만 묻는 것으로는 충분하지 않다. 더 많은 것을 보여주는 질문은 종속성과 보존된 작업이 있는 실제 워크스페이스가 중단 후 다시 서비스로 복귀하는 방식에 관한 것이다.
더 높은 에이전트 밀도가 CPU 수요 전망을 입증하지는 않는다
추가 CPU 작업에 관한 신뢰할 만한 설명은 시장에 추가 하드웨어가 얼마나 필요할지를 보여주는 증거와는 다르다.
Google의 에이전틱 AI CPU 수요에는 상반된 힘이 작용한다. 에이전트 작업이 늘어나면 추가 실행 작업이 발생한다. 더 나은 리소스 공유는 일정 수의 에이전트를 지원하는 데 필요한 하드웨어를 줄인다. 순결과는 도입 수준, 워크로드 강도, 인프라 개선의 효과에 따라 달라진다.
Google 자체 엔지니어링 자료는 이 구분이 중요한 이유를 보여준다. 회사는 7월 30일 에이전트 밀도 벤치마크에서 고정된 머신 구성으로 OpenClaw 워크로드를 테스트했다. 실행 및 리소스 관리 변경을 통해 더 많은 에이전트를 지원했다고 보고했다. 이러한 결과는 특정 워크로드와 설정에 관한 것이다.
이를 프로덕션 배포를 위한 보편적 배수로 받아들여서는 안 된다. 에이전트마다 유지하는 메모리 양, 실행하는 소프트웨어, 대기 시간대가 다르다. 보안 구성도 애플리케이션에 제공되는 리소스에 영향을 준다. 밀도 결과가 의미를 유지하려면 그 결과를 둘러싼 조건이 함께 제시되어야 한다.
반대 방향에서도 같은 주의가 필요하다. CPU 작업이 증가할 것이라는 전망이 모든 에이전트에서 프로세서가 제약 리소스가 된다는 점을 입증하지는 않는다. 일부 애플리케이션은 모델 응답을 기다리는 데 더 많은 시간을 쓸 것이다. 다른 애플리케이션은 외부 서비스 제한이나 스토리지 지연에 부딪힐 수 있다.
따라서 에이전트 CPU 활용률은 더 폭넓은 측정 지표의 일부로서 유용하다. 높은 수치는 생산적인 실행을 나타낼 수 있지만, 경합과 작업 지연을 동반할 수도 있다. 낮은 수치는 낭비를 뜻할 수 있지만, 의도적으로 확보한 예비 용량을 반영할 수도 있다. 해석에는 애플리케이션의 성능 및 안정성 데이터가 필요하다.
상업적 단위도 중요하다. 실행된 에이전트 수를 세면 유용한 작업을 거의 완료하지 못하는 서비스가 더 좋아 보일 수 있다. 활성 세션 수를 세면 반복적인 실패나 포기된 작업이 가려질 수 있다. 완료되고 승인된 결과는 인프라 개선이 고객에게 혜택을 주는지 평가하는 더 엄격한 기준을 제공한다.
“에이전트”라는 단어 자체에도 또 다른 불확실성이 있다. 짧은 코드 실행 요청과 지속되는 브라우저 워크스페이스는 모두 이 이름으로 불릴 수 있다. 그러나 이들의 프로세서 및 지속성 요구 사항은 다르다. 이를 구분 없는 단일 수요 범주로 합산하면 실제 리소스 요구를 결정하는 워크로드 구성이 가려진다.
이 때문에 CPU 이야기는 어떤 아키텍처가 승자라고 선언하는 일을 피해야 한다. Intel, AMD, Arm 기반 설계는 더 폭넓은 서비스 구성 안에서 경쟁한다. 소프트웨어 호환성, 메모리 용량, 스토리지 액세스는 프로세서 실행 속도와 함께 결과에 영향을 줄 수 있다. 애플리케이션 수준 비교에서는 성공 기준을 일관되게 유지해야 한다.
가장 강하게 뒷받침되는 결론은 시장 전망보다 더 제한적이다. Google은 일반적인 실행 작업을 에이전트 서비스의 중요한 구성 요소로 파악했다. 이 회사의 제품 방향은 지속 세션과 간헐적 활동 사이의 간극을 다룬다. 그 결과 발생하는 하드웨어 수요의 규모는 여전히 실증적으로 검증해야 할 문제다.
이는 도입 증가와 효율성 향상 모두의 가능성을 남긴다. 에이전트가 더 많은 워크플로에서 유용해진다면, 더 나은 리소스 공유에도 불구하고 총 실행량은 늘어날 수 있다. 도입이 기대에 미치지 못한다면, 인프라 개선만으로 지속적인 수요가 만들어지지는 않는다. 기술 메커니즘은 기회를 설명하지만 최종 규모를 입증하지는 않는다.
격리는 더 높은 활용률 추구 속에서도 유지되어야 한다
유휴 리소스를 회수하는 일은 플랫폼이 고객에게 필요한 보안 경계와 작업 상태를 보존할 때에만 가치를 만든다.
에이전트는 모델 출력과 외부 정보의 영향을 받는 코드를 실행할 수 있다. 이는 애플리케이션 개발자가 작성하고 검토한 소프트웨어만 실행하는 경우와는 다른 신뢰 관계를 만든다. 런타임은 운영자가 명시적으로 작성하지 않은 작업까지 고려해야 한다.
격리는 실행 환경이 접근할 수 있는 범위를 제한한다. 권한 부여는 하나의 ID가 수행하도록 허용된 작업을 결정한다. 이 제어들은 관련돼 있지만 서로 다른 문제를 해결한다. 격리된 환경도 시스템이 정당하게 부여한 액세스를 오용할 수 있다.
이 구분은 흔한 범주 오류를 막는다. 안전한 실행 경계가 에이전트가 요청을 올바르게 이해한다는 사실을 보장하지는 않는다. 또한 허용된 모든 작업이 사용자의 의도에 부합한다는 점도 보장하지 않는다. 인프라 제어는 실행을 제한하고, 애플리케이션 제어는 작업을 관리한다.
효율성 논의에서는 두 계층을 모두 보존해야 한다. 더 많은 작업을 공유 하드웨어에 통합할수록 신뢰할 수 있는 분리의 중요성이 커진다. 세션을 보존하면 유지 데이터와 액세스 만료에 관한 문제도 추가된다. 워크스페이스를 재개한다고 해서 더 이상 적절하지 않은 권한까지 조용히 복원되어서는 안 된다.
내부 문서를 읽고 브리핑을 준비하는 기업 리서치 에이전트를 생각해 보자. 에이전트는 진행 상황을 유지할 수 있을 만큼의 연속성이 필요하다. 하지만 액세스 권한은 여전히 현재 사용자 권한을 반영해야 한다. 저장된 워크스페이스와 권한 부여 결정은 서로 대체 가능한 기록으로 취급해서는 안 된다.
이 사례는 인프라 설계와 정보 품질도 연결한다. 프로세스를 보존하는 일은 시스템이 올바른 출처와 작업 자료를 유지할 때에만 도움이 된다. 검색 가능한 지식 기반을 구축하는 팀은 진행 중인 작업 전반에서 기술적 근거를 검색 가능하게 유지해야 한다는 관련 조직적 과제에 직면한다. 이러한 관심사는 런타임 지속성을 보완하지만 이를 대체하지는 않는다.
운영상의 복원력도 동등한 주목을 받아야 한다. 정상 조건에서 올바르게 재개되는 환경도 쓰기 작업이 중단되거나 연결이 실패한 뒤에는 다르게 동작할 수 있다. 구매자는 일시 중지 후 무엇이 남고 애플리케이션이 무엇을 다시 만들어야 하는지 이해할 필요가 있다. 그렇지 않으면 겉보기의 연속성이 불완전한 복구를 숨길 수 있다.
같은 원칙은 정리 작업에도 적용된다. 작업을 멈춘 에이전트는 명시적인 보존 정책에 따라 결국 리소스를 해제해야 한다. 모든 것을 무기한 유지하면 불필요한 책임이 생긴다. 너무 적극적으로 삭제하면 인프라가 지원하도록 설계된 지속적 경험이 훼손된다.
이는 기본 설계를 무시하지 않으면서 Google의 주장을 신중하게 검토해야 하는 이유다. 회사 문서는 의도된 경계와 동작을 설명한다. 독립적인 테스트와 운영 경험은 이러한 기능이 실제 애플리케이션 조건에서 어떻게 동작하는지를 입증한다. 어느 하나를 다른 하나로 대체해서는 안 된다.
구매 관점의 시사점은 구체적이다. 격리, 연속성, 리소스 효율성을 함께 평가하라. 한 차원만 최적화하고 나머지를 불분명하게 남겨 두는 서비스는 완전한 인프라 문제를 해결하지 못한다. 중요한 결과는 수용 가능한 보안 및 운영 모델 안에서 제공되는 유용한 작업이다.
다음 증거는 액세스, 워크로드, 결과에서 나와야 한다
이 이야기의 다음 단계는 에이전트에 CPU가 필요하다는 추가 주장보다 고객이 관찰할 수 있는 실행 동작에 달려 있다.
첫 번째 신호는 Agent Compute Engine에 대한 실질적 액세스다. Google의 10월 발표는 앞으로 몇 달 안에 프리뷰 제공이 이뤄질 가능성을 시사한다. 향후 몇 달 동안 공개되는 액세스 조건, 지원 구성, 운영상 제한은 고객이 이 아키텍처를 어떻게 평가할 수 있는지를 보여줄 것이다.
프리뷰는 논의를 관찰 가능한 서비스 동작으로 옮겨 이 이야기를 강화할 것이다. 제한된 액세스도 유용한 증거를 제공할 수 있지만 비교를 제한할 수 있다. 문서는 Google의 내부 사용 설명만으로 독자가 경계를 추론하게 두기보다 이러한 제한을 명확히 밝혀야 한다.
두 번째 신호는 대표 워크로드 테스트다. 유용한 비교에는 같은 작업 안에서 활성 실행, 대기, 중단, 복구가 포함되어야 한다. 빠르게 시작하지만 재개 성능이 떨어지는 환경은 일관된 연속성을 제공하지 못한다. 마찬가지로 반복 전환이 작업을 방해한다면 효율적인 유휴 상태의 중요성은 줄어든다.
이러한 테스트는 워크로드와 그 주변 조건을 공개해야 한다. 메모리 요구 사항, 보존된 파일, 동시성, 격리 설정은 모두 해석에 영향을 준다. 동등한 애플리케이션 요구 사항 아래 AWS 또는 기타 관련 실행 서비스도 포함하면 비교가 더 유익해진다.
개선된 리소스 관리가 완료율과 응답성을 유지한다면 이 증거는 Google의 주장을 강화할 것이다. 절감 효과를 위해 용인하기 어려운 지연이나 더 좁은 애플리케이션 호환성을 감수해야 한다면 상업적 근거는 약화될 것이다. 어느 결과든 고립된 프로세서 벤치마크보다 더 많은 정보를 제공한다.
세 번째 신호는 완료된 작업에 관한 고객 보고다. 기업 배포는 모델 선택 이후에도 실행 인프라가 중요한 제약으로 남는지 보여줄 수 있다. 또한 지속 환경이 운영 복잡성을 정당화할 만큼 작업 완료를 개선하는지도 보여줄 수 있다.
이러한 보고서는 모델 문제와 런타임 문제를 구분해야 한다. 잘못된 작업을 선택하는 에이전트의 실패는 재개할 수 없는 환경의 실패와 다르다. 이를 하나의 성공 수치로 합치면 인프라를 평가하기 어려워진다. 분리하면 구매자가 어떤 개선이 중요한지 이해하는 데 도움이 된다.
이러한 신호가 함께 나타나면 Google의 에이전틱 AI CPU 수요를 더 쉽게 평가할 수 있게 된다. 서비스 액세스는 고객이 사용할 수 있는 것을 보여준다. 대표 테스트는 실행이 어떻게 동작하는지 보여준다. 고객 결과는 최종 시스템이 지속적인 배포를 뒷받침할 만큼 충분한 가치를 만드는지를 보여준다.
현재 보도는 강조점의 분명한 변화를 뒷받침한다. 에이전트 애플리케이션은 실행이 중단되는 시기를 포함해 모델을 둘러싼 소프트웨어 실행에 주의를 기울여야 한다. CPU는 이 작업에 여전히 필수적이며, 지속성과 리소스 관리는 플랫폼이 이를 얼마나 효율적으로 제공하는지를 결정한다.
조직이 실제로 에이전트에게 완료시키고 싶은 워크플로부터 시작하라. 어떤 단계가 코드를 실행하고, 어떤 단계가 대기하며, 어떤 단계가 보존된 파일이나 권한을 필요로 하는지 파악하라. 잠재적 제공업체에 동일한 작업과 승인 기준을 사용해 이러한 전환을 시연하도록 요청하라. 평가의 초점을 완료된 작업, 복구 가능한 상태, 이해 가능한 리소스 소비에 맞춰라. 이 접근 방식은 새로운 서비스를 이용할 수 있게 될 때 개발자와 구매자가 Google의 주장을 실질적으로 평가할 수 있는 방법을 제공한다. 결정은 광범위한 CPU 수요 전망을 받아들이는 문제라기보다, 플랫폼이 지속적인 에이전트 경험을 경제적으로 지원하는지 확인하는 문제에 더 가깝다. 에이전트가 할 일이 없을 때 그 에이전트의 컴퓨터에는 무슨 일이 일어나는가?
