Can I compare tokens per second from different tokenizers directly?

Treat such figures cautiously. Token definitions, output content, and measurement conditions can differ across providers.

What if the API does not stream?

Measure complete-response duration and task completion. Do not claim a first-token result that your client cannot observe.

Should failed runs be excluded?

No. Record timeouts, retries, and rejected artifacts because they affect practical completion time and cost.

Do I need a large benchmark before a pilot?

No. Start with a small representative task and broaden measurement only when a meaningful uncertainty requires it.

초당 토큰 수를 넘어 Mercury 3 지연 시간을 측정하는 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Mercury 3 official announcement cover artwork

작업이 시작된 순간부터 출력물을 실제로 사용할 수 있을 때까지 Mercury 3의 시간을 측정하세요. 첫 응답까지의 시간, 전체 응답 시간, 도구 사용 시간을 포함한 총시간을 기록하세요. 초당 토큰 수는 생성 과정의 일부만 보여 줍니다. 출력 전 대기 시간과 모델 작업이 끝난 뒤 필요한 작업은 반영되지 않을 수 있습니다.

명시적인 승인 기준이 있는 작은 테스트 케이스 하나를 사용하고, 프롬프트, 입력 파일, 도구 환경, 모델 설정을 기록해 두세요. 기본 동작을 파악하고 병목을 드러내는 데는 이것으로 충분합니다. 실패가 발생하거나 결정이 쉽지 않아 추가 근거가 필요할 때만 시험 범위를 넓히세요.

어떤 타임스탬프를 수집해야 하나요?

타임스탬프 또는 소요 시간	확인할 수 있는 내용
요청 전송	클라이언트 측 시작 시점
첫 콘텐츠 수신	스트리밍이 적용되는 경우의 체감 응답성
전체 응답 수신	요청 전체 소요 시간
도구 실행 완료	모델 외부에서 실행된 시간
산출물 승인	작업이 실제로 요구 사항을 충족할 때까지 걸린 시간

시간을 측정할 때는 단조 시계를 사용하는 클라이언트 타이머를 쓰고 스트리밍 사용 여부를 기록하세요. 제공업체를 비교한다면 연결 설정과 재사용 연결 조건을 일관되게 유지하세요. 스트리밍을 사용하지 않는 요청으로 첫 토큰 동작을 추론하지 마세요.

공정한 테스트 프롬프트는 어떻게 선택하나요?

실제적이고 범위가 명확한 작업을 선택하세요. 예를 들어 승인된 문서에서 지정된 필드를 추출하거나 복사한 저장소에 작은 변경 사항을 적용할 수 있습니다. 실행할 때마다 입력과 필수 출력은 동일하게 유지하세요. 결과를 해석할 수 있도록 모델 식별자, 추론 수준 설정, 출력 한도를 기록하세요.

Mercury 3 개요에서는 공급업체의 처리량 수치만으로는 이 작업 수준의 측정을 대체할 수 없는 이유를 설명합니다.

도구는 결과에 어떤 영향을 주나요?

모델 대기 시간과 도구 실행 시간을 구분하세요. 느린 NAS 읽기, 페이지 탐색 또는 외부 검색이 여러 단계로 이뤄진 작업의 대부분을 차지할 수 있습니다. 실패한 시도에 소요된 시간을 무시하지 말고 재시도, 잘못된 도구 인수, 반복된 파일 읽기 횟수를 기록하세요.

에이전트 하네스 체크리스트를 사용해 각 지연의 원인이 어느 구성 요소에 있는지 파악하세요. 모델 호출이 작업 시간에서 차지하는 비중이 작다면, 생성 아키텍처를 바꾸는 것보다 스토리지 액세스나 작업 설계를 개선하는 편이 더 중요할 수 있습니다.

몇 번 실행해야 하나요?

한 번 실행해 보면 연결 상태와 명백한 정확성 문제를 확인하는 데 도움이 됩니다. 몇 번 반복했을 때 결과가 일관되면 실질적인 차이를 파악할 수 있지만, 정밀한 신뢰도나 안정적인 꼬리 백분위수를 주장하기에는 충분하지 않습니다. 배포의 중요도나 성능 차이에 대한 결정이 미묘한 경우에만 추가로 측정하세요.

실패를 항상 공개하세요. 여러 번 실패한 시도 중 빠르게 성공한 실행 하나만 골라서는 대표성 있는 근거가 되지 않습니다. 집중 워크플로 점검 가이드에서 간단한 승인 방법을 확인할 수 있습니다.