Inception의 Mercury 3 출시, 순차적 AI 생성에 도전장

Inception은 10월 19일 Mercury 3를 출시하며 NVIDIA GPU에서 초당 1,068토큰의 생성 속도를 제공한다고 주장했다. Mercury 3 출시는 익숙한 제약에 도전한다. AI 어시스턴트의 성능을 높일수록 사용자는 더 오래 기다려야 하는 경우가 많다는 제약이다. 여러 텍스트 토큰을 함께 다듬는 확산 아키텍처는 이 제약을 관리하는 다른 방식을 제시한다.

회사는 GPT-6 Luna와 Claude Haiku 5.5를 포함한 속도 중심 모델을 상대로 Mercury를 포지셔닝한다. 이들의 주장은 인터랙티브 제품의 대기 시간 예산 안에서 유용한 추론을 제공하는 데 초점을 둔다. 핵심 경쟁은 아키텍처에 있다. 병렬 텍스트 정제 방식과 이전 토큰을 기반으로 출력을 순차적으로 구축하는 자기회귀 생성 방식의 경쟁이다.

개발자에게 이 발표는 애플리케이션 설계에 관한 실질적인 질문을 제기한다. 작업 정확도를 희생하지 않으면서 생성이 크게 빨라진다면 제품은 시간 예산을 다르게 쓸 수 있다. 다른 문서를 확인하거나, 다른 브라우저 작업을 시도하거나, 더 빨리 답변을 반환할 수 있다. 하지만 출력 속도만으로 어떤 애플리케이션이 유용한 작업을 먼저 끝내는지는 입증되지 않는다. 이 차이가 헤드라인 수치에 얼마나 비중을 둘지를 결정한다.

Mercury 3 출시가 실제로 바꾸는 것

Mercury 3는 개발자가 기존 프로덕션 워크로드와 비교 평가할 수 있는 새 확산 모델을 제공한다.

Inception의 Mercury 3 발표에 따르면, 이 모델은 입력과 출력을 위한 작업 공간인 100만 토큰 컨텍스트 윈도우를 지원한다. 회사는 벤치마크 성능이 속도 최적화 프런티어 모델과 경쟁할 만하다고 말한다. 이는 모든 배포 환경에 관한 독립적으로 확립된 결론이 아니라 공급업체의 주장이다.

이번 출시는 아키텍처에 관한 논쟁이 이제 접근 가능한 제품과 함께 제시된다는 점에서 중요하다. 개발자는 출력을 비교하고, 실패 사례를 살펴보며, 병렬 생성이 자신의 애플리케이션을 개선하는지 시험할 수 있다. 이는 확산 방식의 가능성만을 따로 논하는 것보다 더 유용한 논의를 만든다.

Inception은 Mercury 3의 전체 파라미터 수가 Mercury 1보다 40배 이상 많다고도 주장한다. 파라미터는 모델의 행동을 형성하는 학습된 값이다. 회사는 이러한 규모 확대를 확산 언어 모델이 스케일에 따라 개선된다는 근거로 제시한다.

이 주장은 신중한 해석이 필요하다. 더 큰 모델이 모든 작업에서 자동으로 더 좋은 성능을 내는 것은 아니며, 상대적 크기는 절대적인 파라미터 수를 공개하지 않는다. 상업적으로 중요한 것은 향상된 역량이 구매자가 실제로 마주하는 속도, 신뢰성, 배포 제약 속에서도 유지되는지다.

100만 토큰 윈도우는 개발자가 시도할 수 있는 범위도 넓히지만, 그 안의 모든 내용을 성공적으로 이해한다는 보장은 아니다. 애플리케이션은 방대한 문서나 긴 대화 기록을 제공할 수 있다. 모델이 관련 세부 정보를 일관되게 식별하는지는 별도의 품질 문제로 남는다.

가용성은 비교 지능보다 검증하기 쉽다. Vercel의 AI Gateway 출시 공지는 Mercury 3가 10월 19일 자사 서비스를 통해 제공되기 시작했음을 확인한다. 이는 유통 경로를 확립하지만, 성능 주장은 측정의 대상으로 남겨 둔다.

엔지니어링 팀에 이러한 사실은 자동적인 마이그레이션이 아니라 평가를 뒷받침한다. 새 모델은 프로덕션 트래픽을 받을 자격을 얻기 전에 관심을 받을 만할 수 있다. 팀은 아키텍처를 자신들의 프롬프트, 도구, 문서, 사용자 기대의 구체적인 조합과 연결하는 근거가 필요하다.

따라서 이 발표는 이용 가능한 선택지를 바꾼다. 유용한 동작이 대기 시간에 의해 제한되는 애플리케이션을 위해 개발자에게 또 하나의 후보를 제공한다. 순차적 생성이 한계에 도달했거나 확산 방식이 모든 비교에서 이긴다는 점까지 확립하는 것은 아니다.

이처럼 범위를 좁힌 해석도 여전히 중요하다. 구매자가 이미 운영 중인 시스템 안에서 대안을 시험할 수 있을 때 생성 아키텍처 경쟁은 의미 있는 결과를 낳는다.

사용자 대기 시간을 만드는 제품에 압력이 집중된다

즉각적인 압력은 답변 품질과 수용 가능한 응답 시간을 반복해서 맞바꾸는 애플리케이션에 가해진다.

대화형 인터페이스가 유용한 상태로 남을 수 있는 시간에는 한계가 있다. 기술적으로 정확한 답변도 사용자가 상호작용을 포기한 뒤에 도착할 수 있다. 반대로 즉각적인 답변은 오류를 포함할 경우 더 많은 일을 만들 수 있다.

제품 팀은 이를 모델 선택 문제로 부르든 사용자 경험 문제로 부르든 이미 이러한 결과의 균형을 맞추고 있다. Mercury는 이 결정에 또 하나의 후보를 추가한다. 그 관련성은 애플리케이션의 어느 부분이 대기 시간 예산을 소모하는지에 달려 있다.

웹사이트에서 수행할 작업을 모델이 선택하는 소프트웨어인 브라우저 에이전트를 생각해 보자. 이는 페이지를 관찰하고, 무엇을 할지 결정하고, 작업을 실행한 뒤 결과를 살펴봐야 한다. 모델 생성은 이 더 큰 순서 안에서 발생한다.

생성이 각 주기의 상당한 비중을 차지한다면 이를 줄이는 것은 전체 작업 시간을 단축할 수 있다. 페이지 로딩이나 외부 서비스가 지배적이라면 개선 폭은 더 작아진다. 사용자가 이를 체감하려면 아키텍처의 이점이 애플리케이션을 거쳐야 한다.

같은 논리는 지원 어시스턴트에도 적용된다. 더 빠른 생성은 대화를 더 즉각적으로 느끼게 할 수 있다. 하지만 계정 정보 확인, 정책 문서 검색, 권한 획득은 여전히 어시스턴트가 유용한 답변을 제공하는 시점을 결정할 수 있다.

튜터링 제품에서 중요한 결과는 학생이 문제에 몰입해 있는 동안 피드백이 도착하는지다. 속도는 힌트의 정확성과 교육적 가치만큼 중요하다. 유창하지만 오해를 부르는 설명은 또 다른 종류의 지연을 만든다.

이러한 사례는 즉각적인 시장 변화를 전제하지 않고도 누가 압박을 받는지 설명한다. 인터랙티브 제품 개발자는 기존 모델 선택을 다시 검토할 이유가 있다. 순차적 모델 제공업체는 응답 시간이 도입에 큰 영향을 미치는 워크로드에서 새로운 비교 기준을 마주한다.

구매자는 모델 제공업체에 가해지는 압력과 애플리케이션 팀에 가해지는 압력도 구분해야 한다. 더 빠른 모델이 자동으로 더 나은 제품을 만드는 것은 아니다. 팀은 여전히 대기 시간을 줄일지, 검증을 추가할지, 더 많은 작업을 시도할지를 결정한다.

이 결정은 사용자가 받는 결과에 영향을 미친다. 절감된 시간을 추가 추론에 쓰면 눈에 보이는 응답 시간은 변하지 않은 채 정확도가 높아질 수 있다. 같은 답변을 더 빨리 반환하면 다른 이점을 만든다. 어느 쪽이든 측정이 필요하다.

따라서 Mercury 3 vs autoregressive 시스템의 이면에 있는 질문은 구체적이다. 같은 애플리케이션 제약 아래 어떤 접근법이 더 빨리 수용 가능한 결과를 제공하는가? 원시 생성 속도 비교는 이 질문의 일부에만 답한다.

이는 경쟁의 초점을 완료된 작업에 둔다. 모델 제공업체는 속도를 홍보할 수 있지만, 그 속도가 고객 경험을 어디에서 바꾸는지는 애플리케이션 팀이 입증해야 한다.

병렬 정제는 대기가 발생하는 지점을 바꾼다

확산 방식은 생성 과정을 바꾸지만, 그 변화가 최종 경험을 개선하는지는 애플리케이션 설계가 결정한다.

Inception의 확산 언어 연구는 여러 토큰을 병렬로 예측하도록 학습된 Mercury 모델을 설명한다. 토큰은 단어와 단어 조각을 포함해 모델이 처리하는 텍스트 단위다. 이는 엄격한 왼쪽에서 오른쪽 순서로 각 후속 토큰을 생성하는 방식과 다르다.

확산 모델은 반복적인 업데이트를 통해 형성 중인 출력을 정제한다. 병렬 예측이 계산 없이 답변이 나타난다는 뜻도, 정제에 의존성이 없다는 뜻도 아니다. 이는 작업이 구성되는 방식을 바꾼다.

이 논문은 Mercury 3의 독립 평가가 아니라 이전 Mercury Coder 모델을 다룬다. 이는 해당 아키텍처 접근법의 배경을 제공한다. 이전 측정치를 새 모델 성능의 증거로 그대로 가져와서는 안 된다.

Mercury 3 설명을 찾는 독자에게 핵심적인 차이는 생성이 어디에서 함께 일어날 수 있는가에 있다. 순차적 시스템은 진행하면서 이전에 생성된 텍스트에 의존한다. 확산 시스템은 정제 과정에서 여러 위치를 업데이트할 수 있다.

이 차이는 텍스트를 빠르게 생성할 기회를 만들지만, 제품 측면의 질문도 제기한다. 애플리케이션은 언제 안정적인 출력을 받는가? 그 출력을 바탕으로 언제 안전하게 행동할 수 있는가? 작업에 또 다른 외부 관찰이 필요하면 어떻게 되는가?

브라우저 작업은 이 경계를 보여 준다. 모델은 작업을 빠르게 준비할 수 있지만, 해당 작업이 일어나기 전에는 페이지 변경을 살펴볼 수 없다. 병렬 텍스트 생성은 외부 세계의 의존성을 제거하지 않는다.

마찬가지로 문서 모음에 기반해 답변하는 어시스턴트는 응답을 근거에 기반하도록 만들기 전에 관련 증거가 필요하다. 더 빠른 생성은 프로세스의 한 구성 요소를 줄일 수 있다. 누락된 소스 자료를 복구하거나 필요한 접근 확인을 대체할 수는 없다.

Inception의 이전 검색 파이프라인 분석은 반복적인 모델 호출 때문에 검색이 생성 지연에 특히 민감하다고 주장한다. 기본 논리는 간단하다. 워크플로 전반에 걸쳐 반복되는 절감은 단일 응답에서의 절감보다 더 중요할 수 있다.

하지만 워크플로는 이 절감분을 쓸 수 있는 여러 지점도 제공한다. 애플리케이션은 답변 전에 추가 소스를 검토할 수 있다. 후보 답변을 비교하거나, 주장을 검증하거나, 충분한 증거가 확보되면 더 일찍 중단할 수 있다.

이러한 가능성은 보편적인 결과를 확립하지 않으면서도 메커니즘을 흥미롭게 만든다. 더 많은 생성 텍스트는 더 나은 결정을 뒷받침할 수 있지만, 중복된 추론을 만들 수도 있다. 더 빠른 실수는 다른 아키텍처를 통해 도착하더라도 여전히 실수다.

따라서 Mercury 3 vs autoregressive 비교는 생성 전략을 바꾸기 전에 작업을 동일하게 유지해야 한다. 그렇지 않으면 더 긴 답변이나 다른 추론 예산이 무엇이 결과를 만들었는지 흐릴 수 있다.

아키텍처 차이는 설계 선택지를 넓히므로 주목할 가치가 있다. 그 실질적 가치는 애플리케이션이 그 선택지를 정확한 답변, 성공적인 작업, 또는 더 짧은 대기로 바꿀 때 드러난다.

생성 속도는 완료 작업 벤치마크가 아니다

헤드라인 속도 수치는 응답 시간, 신뢰성, 작업 성공에 관한 핵심 질문을 답하지 못한다.

처리량은 시간에 따라 생성된 출력을 측정한다. 지연 시간은 응답이나 결과를 기다리는 동안 경험하는 지연을 측정한다. 이 지표들은 상호작용하지만 성능의 서로 다른 측면을 설명한다.

첫 토큰까지의 시간은 출력이 시작되기 전 사용자가 기다리는 시간을 측정한다. 종단 간 응답 시간은 요청 제출부터 결과 수신까지의 더 넓은 경로를 포함한다. 모델은 한 측정치에서는 우수할 수 있지만 애플리케이션은 다른 지점에서 여전히 제약을 받을 수 있다.

Vercel의 Mercury 3 사양은 모니터링 인터페이스에서 실시간 처리량과 첫 토큰까지의 시간을 구분한다. 하나의 속도 수치만으로는 상호작용의 시작과 완료를 모두 설명할 수 없기 때문에 이 구분은 유용하다.

1,068토큰 수치는 따라서 Inception의 주장으로 귀속되어야 한다. 검토한 출처는 모든 제공업체, 요청 길이 또는 트래픽 조건에서 그 속도가 재현된다고 입증하지 않는다. 또한 보편적인 완료 작업 우위를 입증하지도 않는다.

공급업체 벤치마크와 파트너 경험은 구분해야 한다. 기업의 평가는 선택한 조건에서 정해진 작업 집합을 측정한다. 파트너의 프로덕션 사례는 실무적 맥락을 더하지만, 여전히 유리한 워크로드를 반영할 수 있다.

Inception의 출시에는 브라우저 에이전트 테스트에 대한 TinyFish의 설명이 포함된다. 이 파트너는 실제 탐색 작업 50개 중 50%를 완료했다고 보고한다. 이는 추가로 살펴볼 만한 유용한 근거이지만, 일반적인 브라우징 신뢰성을 입증하기에는 범위가 너무 좁다.

브라우저 시스템의 결과는 모델뿐 아니라 주변 소프트웨어에도 좌우된다. 작업 선택, 사용 가능한 액션, 페이지 상태, 복구 동작은 모두 성공에 영향을 미친다. 비교에는 어떤 조건이 동일하게 유지됐는지 보여줄 만큼 충분한 세부 정보가 필요하다.

Mercury를 GPT-6 Luna 또는 Claude Haiku 5.5와 비교할 때도 같은 주의가 필요하다. 이 모델들을 언급하는 것은 Inception이 의도한 경쟁 구도를 보여준다. 그렇다고 모든 벤치마크 결과가 기업의 문서 모음이나 지원 큐에 그대로 적용되는 것은 아니다.

추론 설정 역시 비교에 영향을 준다. 더 많은 연산을 할당받은 모델은 다른 속도로 다른 답을 낼 수 있다. 구매자는 결과를 대표적인 것으로 간주하기 전에 어떤 구성에서 테스트됐는지 이해해야 한다.

부하 상황에서의 신뢰성은 또 다른 차원을 더한다. 빠른 시연은 특정 결과가 가능하다는 점을 보여줄 수 있다. 프로덕션 평가는 요청이 다양해지고 트래픽이 불규칙해질 때 그 결과가 얼마나 일관되게 나타나는지를 묻는다.

일반적인 경험만큼 가장 느린 경험도 중요하다. 애플리케이션은 대부분의 시간에 빠르게 느껴질 수 있지만, 가끔 발생하는 긴 대기 시간은 신뢰를 훼손할 수 있다. 평균만으로는 불만이나 이탈을 유발하는 상호작용을 감출 수 있다.

출력 길이는 해석을 더욱 복잡하게 만든다. 더 많은 텍스트를 생성하는 모델은 실제 답변을 전달하는 데 더 오래 걸리면서도 높은 처리량을 보일 수 있다. 간결성은 근본적인 생성 속도를 바꾸지 않고도 사용자 경험을 개선할 수 있다.

기업 구매자에게는 모든 속도 측정에 정확도가 함께 고려되어야 한다. 직원이 이후에 출력을 수정해야 한다면 더 짧은 응답 시간의 가치는 제한적이다. 재작업은 완료된 작업 평가에 포함돼야 한다.

이러한 한계가 출시 자체를 무효화하는 것은 아니다. 이는 고무적인 아키텍처 주장의 간극과 구매 결정 사이의 차이를 보여준다. 적절한 회의적 관점은 성공이나 실패를 가정하기보다 비교 가능한 근거를 요구한다.

유용한 평가는 그 간극을 드러내야 한다. 모델이 무엇을 했는지, 애플리케이션에 얼마나 시간이 걸렸는지, 그리고 결과가 대안과 동일한 수용 기준을 충족했는지 설명해야 한다.

배포 결정은 모델 속도를 넘어선다

더 빠른 생성 엔진은 애플리케이션의 근거, 권한, 운영 요구사항에 부합할 때 가치를 발휘한다.

Mercury 3 출시는 기존 시스템의 한 구성 요소를 재평가할 기회를 만든다. 그렇다고 그 시스템을 이해하는 데 필요한 작업이 사라지는 것은 아니다. 애플리케이션에는 답변을 제공하는 모델보다 더 많은 종속성이 있다.

지식 어시스턴트에서 모델은 다른 곳에서 선택된 정보를 받는다. 관련 자료를 찾는 과정인 검색은 모델이 사용할 수 있는 내용을 결정한다. 응답이 아무리 빠르게 나타나더라도 근거가 누락되면 답변 품질은 제한된다.

사용자가 내부 업무에 관해 질문할 때 이 구분은 중요하다. 올바른 답은 최근의 결정, 첨부 파일 또는 접근이 제한된 문서에 달려 있을 수 있다. 더 빠른 생성이 올바른 출처를 찾는 일을 대신할 수는 없다.

검색 가능한 지식 기반은 이 워크플로의 관련 부분을 다룬다. 기술 문서를 체계화하면 관련 근거를 더 쉽게 검색하고 검토할 수 있다. 뒷받침 정보가 제공될 때 생성 속도는 더 유용해진다.

이는 Mercury와 remio의 통합을 입증하는 근거가 아니라 애플리케이션 설계상의 연결점이다. 지식 조직화와 모델 서빙은 정보 워크플로 안에서 서로 다른 문제를 해결한다. 구매자는 각 요소를 그것이 통제하는 결과에 따라 평가해야 한다.

통합 호환성에도 한계가 있다. 익숙한 요청 형식은 테스트를 시작하는 데 필요한 노력을 줄일 수 있다. 그러나 대체 모델이 지시, 도구 요청 또는 불확실한 근거를 처리할 때 동일하게 동작한다는 점을 보장하지는 않는다.

어시스턴트는 문법적으로 유효한 출력을 생성하면서도 잘못된 액션을 선택할 수 있다. 문서 형식을 따르면서도 중요한 단서를 간과할 수 있다. 주변 소프트웨어가 응답을 받아들이더라도 이러한 실패는 행동 평가를 요구한다.

지원 제품의 경우 수용 기준은 실제 제공되는 서비스를 반영해야 한다. 올바른 정책 설명, 적절한 에스컬레이션, 완료된 계정 조치는 서로 다른 결과다. 이를 하나의 인상으로 묶으면 약점이 가려질 수 있다.

리서치 어시스턴트의 경우 출처 충실도는 별도로 주목할 가치가 있다. 응답은 서로 양립할 수 없는 주장을 섞으면서도 정밀하게 들릴 수 있다. 애플리케이션이 근거와 결론의 관계를 보존할 때에만 더 빠른 출력이 유용하다.

운영 요구사항 역시 모델 적합성을 결정할 수 있다. 팀은 요청이 어떻게 처리되는지, 어떤 데이터 정책이 적용되는지, 중단 상황에서 무엇이 발생하는지 이해해야 한다. 이러한 질문은 생성 아키텍처와 관계없이 계속 중요하다.

상업적 평가는 완전한 워크플로를 고려해야 한다. 개별 응답을 빠르게 끝내는 모델도 재시도나 사람의 검토를 요구할 수 있다. 더 느린 모델 역시 추가 연산이 수용률을 높이지 못한다면 낭비가 될 수 있다.

이 때문에 배포 결정은 구체적인 워크로드와 연결된 상태를 유지해야 한다. 광범위한 순위는 맥락을 제공하지만, 모든 조직의 문서, 권한, 사용자 기대, 오류 허용 수준을 포착할 수는 없다.

Mercury 3를 비즈니스 관점에서 이해하려는 독자에게 이 제안은 연산과 대기 시간을 배분하는 또 하나의 선택지다. 도입 사례는 그 선택지가 애플리케이션의 측정 가능한 결과를 개선하는지에 달려 있다.

성공적인 평가는 더 광범위한 약속에 앞서 제한적인 배포를 정당화할 수 있다. 또한 모델이 잘 맞지 않는 작업을 식별할 수도 있다. 두 결과 모두 아키텍처에 대한 열정을 실제 업무의 근거로 대체하기 때문에 유용하다.

세 가지 신호가 이점의 확장 가능성을 보여줄 것이다

다음 근거는 독립적인 측정, 실제 애플리케이션 결과, 지속적인 배포 동작을 연결해야 한다.

첫 번째 신호는 공개된 조건에서 품질과 속도를 측정하는 독립 비교다. 여기에는 모델 설정, 작업 집합, 출력 길이, 서빙 구성이 명시돼야 한다. 이 세부 정보가 없다면 구매자는 비교가 자신의 의도된 사용 사례와 유사한지 판단할 수 없다.

설득력 있는 결과는 수용 기준이 일정하게 유지될 때 Mercury가 유용한 이점을 유지한다는 점을 보여줄 것이다. 독립적인 재현은 병렬 정제가 공급업체가 선택한 사례를 넘어 실질적인 이점을 제공한다는 주장을 강화할 것이다.

더 약한 결과 역시 중요하다. 어려운 프롬프트나 더 긴 입력에서 이점이 크게 줄어든다면, 개발자는 배포를 위한 더 명확한 경계를 갖게 될 것이다. 이는 모델의 잠재적 가치를 지우기보다 사용 사례를 정교화한다.

두 번째 신호는 짧아진 대기 시간과 성공적인 업무를 연결하는 애플리케이션 보고다. 브라우저 에이전트, 튜터링 제품, 지원 어시스턴트는 서로 다른 테스트를 제공한다. 각각은 사용자가 실제로 중요하게 여기는 결과를 보고해야 한다.

브라우저 에이전트의 경우 완료율과 복구 동작은 경과 시간과 함께 고려돼야 한다. 튜터에게는 반응성과 함께 피드백의 품질이 중요하다. 지원 업무에서는 첫 문장의 속도보다 해결된 요청이 더 중요하다.

더 빠른 생성이 상호작용을 개선하면서 정확도를 보존한다면, 이러한 환경의 근거는 출시 서사를 강화할 것이다. 절감된 시간이 재시도, 외부 지연 또는 추가 검토로 사라진다면 그 서사는 약화될 것이다.

세 번째 신호는 초기 배포 이후에도 일관된 동작이다. 구매자는 워크로드가 확장되고 트래픽이 변화할 때 측정된 성능이 지속되는지 살펴봐야 한다. 초기 액세스는 가능성을 보여줄 수 있지만, 지속적인 사용은 그 가능성이 얼마나 폭넓게 유지되는지를 드러낸다.

여기에는 모델 동작의 안정성, 제공업체 문서의 명확성, 실패 처리도 포함된다. 애플리케이션 팀은 변화를 진단할 수 있을 만큼의 일관성이 필요하다. 그렇지 않으면 벤치마크상의 이점은 신뢰할 수 있는 서비스로 전환하기 어려워질 수 있다.

경쟁사의 대응 역시 이 마지막 신호에 포함된다. 순차 모델 제공업체는 서빙을 개선하고, 불필요한 출력을 줄이거나, 더 나은 작업 정확도를 제공할 수 있다. 각 접근 방식이 변화함에 따라 관련 비교도 계속 움직일 것이다.

이 신호들은 중심적인 아키텍처 질문을 즉각적인 대체 예측으로 바꾸지 않으면서 유지한다. 병렬 정제는 검증할 만한 신뢰성 있는 제품 주장을 갖고 있다. 순차 생성은 공정하게 측정돼야 하는 비교 기준으로 남는다.

Mercury 3 출시는 애플리케이션 제작자가 이 비교를 이용할 수 있게 한다는 점에서 주목할 가치가 있다. 그 중요성은 개발자가 출시를 위해 선택된 조건 밖에서도 유용한 이점을 재현할 수 있는지에 달려 있다.

AI 제품을 구축한다면 대기 시간이 이미 유용성을 제한하는 워크플로를 선택하고, 동일한 수용 기준으로 모델을 비교하라. 검색, 도구 액션, 재시도, 검토를 포함해 사용 가능한 결과에 도달하기까지의 전체 시간을 기록하라. 잘못된 답변을 속도 계산에서 제외하지 말고 결과에 포함하라. AI 소프트웨어를 구매한다면 공급업체에 워크플로의 어느 부분이 개선됐는지, 고객이 그 차이를 경험했는지 물어보라. 실질적인 질문은 이 아키텍처가 허용 가능한 정확도로 사용자가 업무를 더 빨리 완료하도록 돕는지다. 이 질문으로 Mercury 3를 평가하고, 독립 측정과 프로덕션 근거가 마련되면 답을 다시 검토하라.