모델 벤치마크는 작업이 좁고, 프로토콜이 명시적이며, 모든 백분율이 베이스라인 (Baseline) 옆에 위치할 때 가장 효과적입니다. 이 노트는 그러한 접근 방식을 따릅니다: 하나의 작업, 고정된 레이블 (Labels), 투명한 점수 산정, 그리고 표본 크기나 인프라에 따라 해석이 달라질 수 있는 명확한 주의 사항을 포함합니다.

우리는 ZeroGPU의 Responses API에서 호스팅되는 전문 분류기인 DeBERTa-v3-small과, 동일한 기사 스니펫 (Snippets) 및 동일한 폐쇄형 IAB Content Taxonomy 3.1 Tier-1 레이블 세트에 대해 범용 Gemini 모델 (gemini-flash-latest)을 비교합니다.

목표는 보편적인 승자를 선언하는 것이 아닙니다. 두 시스템이 동일한 좁은 프로덕션 (Production) 작업에서 평가될 때 어떤 일이 발생하는지 보여주는 것입니다.

측정 대상

작업 (Task): 짧은 편집 텍스트를 정확히 하나의 Tier-1 IAB 카테고리 (18개 레이블의 폐쇄형 세트)로 매핑합니다.

주요 지표 (Primary metric): Tier-1 정확도 (Accuracy). 정규화 (대소문자, 공백, 문장 부호, "&" 대 "and" 등) 후 예측된 레이블이 참조 값과 일치하는 예시의 비율입니다.

동일한 50개 예시에 대한 베이스라인 (Baselines)

이 베이스라인들은 하한선을 정의합니다: 10%에 가까운 결과는 프로덕션에 유용하지 않습니다.

ZeroGPU에서 실행하는 방법

평가는 일관된 프롬프트 (Prompts)와 점수 산정을 사용하여 표준 API 추론 (Inference)으로 실행됩니다:

• 전송 (Transport): 표준 인증을 포함한 /v1/responses로의 HTTP POST
• 모델 (Model): deberta-v3-small (호스팅된 분류기 SKU)
• 프롬프트 형태 (Prompt shape): 다음을 포함하는 채팅 스타일 입력
  • 허용된 모든 Tier-1 레이블을 나열하고 단일 문구 레이블을 요구하는 시스템 메시지 (System message)
  • 기사 텍스트를 포함하는 사용자 메시지 (User message)

각 예시는 고정된 50개 샘플의 골든 세트 (Golden set)를 기준으로 점수가 매겨집니다.

지연 시간 (Latency)은 클라이언트가 관찰한 요청당 엔드 투 엔드 (End-to-end) 실제 시간 (네트워크, 스케줄링, 추론 포함)입니다. 이는 합성 마이크로벤치마크 (Synthetic microbenchmark)가 아닙니다.

Gemini 실행 방법 (매칭된 설정)

각 스니펫은 다음을 포함하는 단일 텍스트 블록으로 Gemini generateContent에 전송됩니다:

• 동일한 18개 레이블 리스트 (18-label list)
• 동일한 지시어: "정확히 하나의 레이블로, 있는 그대로 답변하세요 (reply with exactly one label, verbatim)"

이는 서로 다른 API를 사용하더라도 작업 정의(task definition)를 일치시킵니다.

지연 시간 (Latency)은 동일하게 측정됩니다: 클라이언트가 관찰한 요청당 왕복 시간 (round-trip per request). 사용 메타데이터를 사용할 수 없는 경우 처리량 (Throughput, tokens/sec)은 생략됩니다.

결과 (동일한 50개 샘플 골든 세트 (golden set))

여기서 정확도와 지연 시간은 함께 움직입니다: DeBERTa는 이 데이터 세트에서 약 1.3초의 평균 지연 시간으로 완벽한 정확도에 도달한 반면, Gemini Flash는 동일한 평가 루프 하에서 약 27초에 92%에 도달했습니다.

단일 레이블 라우팅 (single-label routing) 워크로드의 경우, 이러한 지연 시간 격차는 운영상 매우 유의미합니다.

Accuracy Comparison

비용 (할인 전 리스트 가격)

벤치마크 노트에는 정확도와 함께 가격 맥락이 포함되어야 합니다.

토큰 리스트 요금 (100만 토큰당 USD):

Gemini 열은 Google이 공개한 API 요율에 따른 Flash급 가격을 반영합니다. gemini-flash-latest 별칭은 계정 내 활성화된 Flash SKU에 매핑됩니다.

대규모 Tier-1 라우팅의 경우, 분류기 (classifier) SKU는 주로 출력 토큰 가격 때문에 범용 생성 모델 (general-purpose generation models)보다 총 소유 비용 (TCO, total cost of ownership)이 더 낮게 나타납니다.

예산을 세우기 전에 항상 실시간 가격을 확인하십시오.

Cost Comparison

왜 여기서는 CPU 우선 서빙 (CPU-first serving)이 더 나은 성능을 낼 수 있는가

Tier-1 IAB 라우팅과 같은 좁은 범위의 분류 워크로드 (classification workloads)의 경우, CPU 우선 서빙 (CPU-first serving)이 종종 실질적인 선택지가 됩니다:

• 작은 모델들은 GPU 배치 (batching) 없이도 효율적으로 실행됩니다.
• 온라인 트래픽은 낮은 배치 (low-batch) 패턴으로 유입됩니다.
• 작업의 본질은 생성 (generation)이 아닌 고정된 레이블 판별 (fixed-label discrimination)입니다.
• 피크 처리량 (peak throughput)보다 예측 가능한 지연 시간 (predictable latency)이 더 중요합니다.

이러한 벤치마크 형태에서 CPU는 차선책 (fallback)이 아닙니다. 종종 더 빠른 경로가 됩니다.

핵심 요약 (Takeaway)

빠르고 결정론적인 (deterministic) Tier-1 라우팅을 위해서는 호스팅된 분류기 (hosted classifier)가 종종 올바른 추상화 (abstraction)입니다: 더 높은 정확도, 더 낮은 지연 시간, 그리고 더 단순한 비용 구조를 제공합니다.

동일한 텍스트에 대한 개방형 생성 (open-ended generation)의 경우에는 Gemini급 모델이 여전히 적절한 도구로 남습니다. 본 벤치마크는 해당 모델이 적절하지 않은 특정 작업을 분리하여 다루고 있습니다.

Results Dashboard

ZeroGPU에서 deberta-v3-small 실행하기

ZeroGPU 모델 카탈로그에서 deberta-v3-small을 선택하고 Responses API (POST /v1/responses)를 통해 분류 요청을 보내세요.

zerogpu.ai에서 시작하세요: 워크스페이스를 생성하고, 카탈로그에서 모델을 복사한 뒤, 실제 운영 트래픽을 라우팅하기 전에 본인만의 골든 세트 (golden set)를 다시 실행해 보세요.