A10 vs T4 임베딩 추론 벤치마크: BGE-m3-ko + TEI (Azure Spot VM)¶
BGE-m3-ko와 TEI를 사용한 실측입니다. 단건 지연, 배치 처리량, 청크 길이를 나눠 보고 GPU 선택과 증설의 기준을 비교합니다.
AI Search + Agent 구성(Indexer 미사용, Push API)에서 TEI로 서빙한 dragonkue/BGE-m3-ko의 추론 성능을 A10·T4에서 실측 비교
관련 문서: GPU vLLM RAG 가이드 | Custom 임베딩 적재 가이드 | BGE-M3 vs Qwen3 품질 비교
작성일: 2026-07-22
📌 핵심 요약¶
| 항목 | T4 (NC4as_T4_v3) | A10 (NV36ads_A10_v5) | 배율 (A10/T4) |
|---|---|---|---|
| 단건 레이턴시 mean | 5.59 ms | 3.97 ms | 1.4× |
| 단건 레이턴시 p95 | 6.10 ms | 4.38 ms | 1.4× |
| 최대 처리량 (~500자 청크) | 61 texts/s | 301 texts/s | 4.9× |
| 최대 처리량 (~1,000자 청크) | 23 texts/s | 130 texts/s | 5.5× |
| 1M 청크(500자) 적재 소요 | 4.5 hr | 0.9 hr | 5× |
- 쿼리 경로(단건 추론): 양쪽 모두 single-digit ms — latency-bound 구간으로, 전체 검색 응답 시간에서 차지하는 비중이 상대적으로 작음. QPS 스윕 실측 기준 T4 1대는 ~200 QPS(40자 쿼리)까지 p50 ~6ms 유지, 초과 시 큐잉 지연 — 안전 운용 상한 ~150 QPS/대 → 증설 기준
- 적재 경로(배치 추론): throughput-bound 구간에서 본 테스트 환경 기준 A10 처리량이 T4 대비 약 5배 수준으로 측정. T4는 ~60 texts/s 부근에서 GPU 사용률·전력이 상한에 도달했으며, 본 벤치마크 조건에서는 batch size/concurrency 조정만으로는 유의미한 추가 향상을 확인하지 못함
- 공개 스펙 교차검증 — FP16 Tensor TFLOPS비 1.9×, Flash Attention 지원 차이, 메모리 대역폭 2×가 주요 원인으로 추정되며, 공개 스펙 기반 예측 범위(4.3~5.8×)와 실측 결과의 방향성이 일치 → 교차검증 섹션
- 대체 전략: A10 수급 불가 시, 본 측정 조건 기준 A10 × N ≈ T4 × 5N(500자) / × 6N(1,000자) 수준으로 대체 산정 — 최소 SKU(NC4as) × N 구성 시 VM 비용 기준 등가 처리량 확보 가능 → 대체 전략
⚠️ 측정 범위: 본 측정은 임베딩 생성 구간(TEI
/embed)만 대상이며, Azure AI Search 문서 업로드 및 인덱싱 시간은 포함하지 않는다. 실제 End-to-End 적재 시간은 Search 서비스 SKU, 문서 크기, 배치 크기 및 서비스 부하에 따라 달라질 수 있다. 또한 측정값은 모델, 텍스트 길이·토큰 분포, 서빙 엔진 버전, 드라이버 버전, 배치 설정 및 운영 환경에 따라 달라질 수 있다.
벤치마크 구성¶
| 항목 | T4 VM | A10 VM |
|---|---|---|
| VM SKU | Standard_NC4as_T4_v3 (Spot) | Standard_NV36ads_A10_v5 (Spot) |
| GPU | Tesla T4 16GB GDDR6 (Turing TU104, CC 7.5) | A10-24Q 24GB GDDR6 (Ampere GA102, CC 8.6, full-GPU vGPU 프로필) |
| vCPU / RAM | 4 vCPU / 28GB (16 vCPU 교차검증 완료, 하단 참고) | 36 vCPU / 440GB |
| 드라이버 | 610.43.02 (CUDA) | 570.211.01 (GRID) |
| 리전 / OS | southcentralus / Ubuntu 22.04 Gen2 | 동일 |
| 서빙 엔진 | TEI turing-1.8 |
TEI 86-1.8 |
| 모델 | dragonkue/BGE-m3-ko (XLM-RoBERTa, 568M params, 1024-dim, max 8192 tokens) | 동일 |
| TEI 옵션 | --max-client-batch-size 128 --auto-truncate, normalize=true |
동일 |
| 측정 위치 | VM 내부 localhost 호출 — 네트워크 RTT 변수 제거 | 동일 |
구성 시 주의사항:
- NVadsA10v5 시리즈 중 full-GPU 프로필(NV36ads, A10-24Q 24GB 단독 점유) 사용. NV6/12/18ads는 GPU fractional 파티션(1/6~1/2) — 본 결과 적용 불가
- T4는 TEI Turing 전용 이미지(turing-1.8) 필수. Turing은 TEI experimental 지원, Flash Attention 기본 비활성화
- NVIDIA 드라이버는 Azure VM extension NvidiaGpuDriverLinux(Microsoft.HpcCompute)로 설치 — GRID/CUDA 자동 판별. A10은 GRID 드라이버 필수 (수동 CUDA 드라이버 설치 시 vGPU 라이선스 실패)
- 실행 스크립트: bench/
⚠️ vCPU 격차(4 vs 36)의 결과 왜곡 여부 교차검증 완료. T4 VM을 NC16as_T4_v3(16 vCPU)로 리사이즈 후 동일 벤치마크 5라운드 재실행: - 500자 최대 처리량 61.0 texts/s (4 vCPU: 61.3) / 1,000자 22.6 (4 vCPU: 23.4) / 단건 5.86ms (4 vCPU: 5.59ms) — vCPU 4배 증가에도 측정 오차(±3%) 이내 - 부하 중 GPU util 100% / CPU idle ~80% → 병목은 GPU 연산(compute-bound), host CPU 무관 - 결론: 본 문서의 T4 수치는 NC4as/NC16as 모든 SKU에 동일 적용 가능
측정 시나리오¶
Indexer 미사용 구성의 임베딩 호출 경로 2종:
① 쿼리 경로 (실시간): Agent/AI Search Custom Vectorizer → /embed (항상 단건)
② 적재 경로 (Push API): 앱 → 청킹 → /embed (배치) → AI Search Push
| 시나리오 | 입력 | 측정 방식 |
|---|---|---|
| A. 단건 레이턴시 | 한국어 쿼리 ~40자 | 순차 100회 × 5라운드, mean/p50/p95 |
| B. 배치 처리량 (500자) | 한국어 청크 ~530자 | 256건, batch size × concurrency 8조합 스윕 × 5라운드 |
| C. 배치 처리량 (1,000자) | 한국어 청크 ~1,050자 | 128건, batch=32 / conc=4 × 3라운드 |
🧪 결과 1: 단건 레이턴시 (Custom Vectorizer 경로)¶
5라운드 × 100회 = 500회 측정:
| GPU | mean | p50 | p95 | min | max |
|---|---|---|---|---|---|
| T4 | 5.59 ms | 5.52 ms | 6.10 ms | 5.34 ms | 8.89 ms |
| A10 | 3.97 ms | 3.90 ms | 4.38 ms | 3.70 ms | 5.57 ms |
분석: - A10 1.4× 우위이나 절대값은 양쪽 모두 single-digit ms - 하이브리드 검색 E2E 응답 대비 벡터화 비중은 상대적으로 작음 (E2E가 수십 ms급인 저지연 환경이라면 1.6ms 차이의 비중은 커질 수 있음) - 라운드 간 편차 ±0.1ms — 재현성 확보
🧪 결과 2: 배치 처리량 — 500자 청크 (Push API 적재 경로)¶
5라운드 평균 texts/s (256건 기준):
| batch × concurrency | T4 | A10 | 배율 |
|---|---|---|---|
| 1 × 1 | 59.3 | 150.0 | 2.5× |
| 1 × 4 | 60.1 | 202.7 | 3.4× |
| 1 × 8 | 60.4 | 257.1 | 4.3× |
| 8 × 4 | 61.3 | 279.7 | 4.6× |
| 32 × 1 | 60.4 | 271.1 | 4.5× |
| 32 × 4 | 58.4 | 295.5 | 5.1× |
| 32 × 8 | 55.9 | 297.3 | 5.3× |
| 64 × 4 | 55.7 | 301.2 | 5.4× |
라운드 간 표준편차: T4 ≤2.1, A10 ≤6.1 texts/s (CV ~2%) — 5회 반복 전부 재현.
분석:
- T4: ~60 texts/s 부근에서 상한 도달. 본 벤치마크 조건에서는 batch/concurrency 조정만으로는 유의미한 추가 향상을 확인하지 못했으며, 64×4에서는 오히려 소폭 하락(스케줄링 오버헤드 추정). 부하 중 nvidia-smi: GPU util 100%, power draw 69W/70W(TDP cap 도달), CPU idle 73% → GPU compute/power 제약으로 판단 (TEI 버전 업그레이드, quantization 등 서빙 스택 차원의 최적화는 본 측정 범위 외)
- A10: batch=1에서도 concurrency 스케일링 유효(150→257, TEI dynamic batching 효과), batch 증가 시 ~300 texts/s 포화. 최대 부하에서도 GPU util ≤84% — SM occupancy 여유 잔존
- 격차 요인(추정): Ampere 3세대 Tensor Core(SM당 2× FP16 처리량) + FP16 Tensor 연산비(65 vs 125 TFLOPS) + TEI Flash Attention 지원 차이의 복합
🧪 결과 3: 배치 처리량 — 1,000자 청크¶
3라운드 평균 (batch=32, conc=4):
| GPU | texts/s | 500자 대비 |
|---|---|---|
| T4 | 23.4 | -62% |
| A10 | 129.7 | -57% |
| 배율 | 5.5× |
분석: - 시퀀스 길이 증가 시 배율 5.4× → 5.5×로 확대 - 원인: attention 연산량 O(N²) 스케일링 — 이미 포화 상태인 T4가 더 민감하게 하락 - 장문(1,000자+) 위주 코퍼스일수록 A10 우위 확대
교차검증: 공개 스펙·벤치마크와의 정합성¶
실측 배율(4.9~5.5×)의 타당성을 공개 자료로 검증. 공개 스펙과 실측 결과의 방향성이 일치하며, 이론 TFLOPS비(1.9×)를 하한선으로 아래 3개 요인이 주요 원인으로 추정된다. (TEI 내부 구현, dynamic batching 동작, 드라이버 버전, 토큰 분포 등도 영향 요인이므로 정확한 기여도 분해는 본 측정 범위 외)
공식 스펙 비교 (NVIDIA 데이터시트)¶
| 항목 | T4 | A10 | 배율 |
|---|---|---|---|
| 아키텍처 / Compute Capability | Turing (TU104) / 7.5 | Ampere (GA102) / 8.6 | — |
| FP16 Tensor TFLOPS (dense) | 65 | 125 | 1.9× |
| 메모리 대역폭 | 300 GB/s | 600 GB/s | 2.0× |
| TDP | 70 W | 150 W | 2.1× |
| CUDA 코어 | 2,560 | 9,216 | 3.6× |
| Tensor Core 세대 | 2세대 | 3세대 (SM당 FP16 FMA 2×) | — |
실측 배율(4.9~5.5×) > 스펙비(1.9×)의 추정 메커니즘¶
- T4 70W power cap — 패시브 쿨링·저전력 폼팩터 설계로 70W가 하드 리밋. 지속 배치 부하에서 boost clock 유지 불가 → 이론 peak TFLOPS 미도달 (실측: GPU 100% + 69W/70W 포화 확인). 지속 부하 기준 유효 격차 ~2.5–3×
- TEI의 Turing Flash Attention 기본 비활성화 — TEI 공식 README: "Flash Attention is turned off by default for the Turing image as it suffers from precision issues". FlashAttention-2는
cp.async등 Ampere(CC 8.0+) 전용 명령 의존 → Turing 미지원. 결과적으로 T4는 O(N²) HBM 왕복의 standard attention, A10은 SRAM-fused FA 커널로 동작. 시퀀스 길이에 비례해 격차 확대 — 실측 500자 4.9× → 1,000자 5.5× 패턴과 일치 - 메모리 대역폭 2× — BGE-m3(XLM-RoBERTa encoder) 배치 추론은 레이어 간 activation 이동이 지배하는 memory bandwidth-bound 워크로드
곱셈 효과 추정: 1.9× (compute) × ~1.5–2× (FA 유무) × 잔여 대역폭 효과 ≈ 4.3–5.8× — 실측 4.9~5.5×가 이 범위 안에 있어 방향성이 일치
단건 1.4×의 정합성 — 단건 추론은 SM under-utilization 상태의 latency-bound 구간. 배치·FA·대역폭 이점 미발현, 세대 간 clock/IPC 차이만 반영 → 1.3~1.5× 예측과 일치.
vGPU 오버헤드 — NV36ads_A10_v5 = A10 1장 전체(24GB) 단독 점유, time-slicing 없음. A10-24Q 프로필의 paravirtualization 오버헤드 ~5–10% → bare-metal A10 대비 본 실측이 오히려 보수적 수치.
참고: BGE-M3 + TEI + T4/A10 조합의 공개 처리량 벤치마크 부재 (MLPerf Inference는 BERT-large, T4↔A100 중심) — 본 실측이 해당 구성의 1차 자료. MLPerf T4↔A100 BERT 추론 격차(8–12×) × A10≈A100의 70–80% 연산 성능으로 유추한 A10↔T4 5–8× 범위와도 부합.
출처: T4 데이터시트 · A10 데이터시트 · TEI README (Turing FA 경고) · FlashAttention (Turing 미지원) · NVadsA10_v5 문서 · Ampere 마이크로아키텍처
대체 전략: A10 수급 불가 시 T4 스케일아웃¶
A10 물량 확보가 불가한 경우, 동등 처리량을 확보하기 위한 T4 대체 구성 산정 기준. vCPU 교차검증(GPU compute-bound 확인)이 근거 — T4 계열 최소 SKU(NC4as_T4_v3, 4 vCPU)로도 GPU 처리량은 동일하므로 처리량/달러 최적점 = 최소 SKU × N.
스케일 업/아웃 옵션별 효과¶
| 방법 | 처리량 효과 | 근거 |
|---|---|---|
| T4 1장에 TEI 다중 인스턴스 | ❌ 0% | GPU util 100% + 70W TDP cap 포화 (실측) — SM time-slicing 경합만 추가. MPS는 단일 프로세스 미포화 시에만 유효, MIG는 Turing 미지원 |
| 파이프라인 병렬화 (청킹∥임베딩∥푸시) | △ wall time 10~20% 단축 | CPU/GPU/네트워크 자원 비중첩 — producer-consumer 큐로 오버랩. 처리량 상한(임베딩 단계)은 불변 |
| T4 VM 수평 확장 (N대 + LB) | ✅ ~선형 (N×60 texts/s) | VM별 독립 GPU — 간섭 없음 |
등가 배수: A10 N대 → T4 몇 대로 대체?¶
본 측정 조건 기준 처리량 비(500자 4.9×, 1,000자 5.5×)로 환산한 산술 등가:
| 기준 (A10 대수) | 500자 워크로드 | 1,000자 워크로드 |
|---|---|---|
| A10 × 1 (301 texts/s) | T4 × 5 수준 (305 texts/s) | T4 × 6 수준 (140 vs 130 texts/s) |
| A10 × 2 (602 texts/s) — 현행 | T4 × 10 수준 (610 texts/s) | T4 × 12 수준 (281 vs 259 texts/s) |
| A10 × N | T4 × 5N | T4 × 6N |
⚠️ 위 등가는 단일 노드 실측치의 산술 배수다. 실제 환경에서는 LB 분배 편차, 콜드스타트/warmup, Spot eviction, 요청 크기 불균형 등으로 유효 처리량이 이보다 낮아질 수 있으므로 여유분(+1대 이상) 산정을 권장한다.
비용 비교 — PAYG(정규 VM) 기준¶
대체 구성 시 비용이 오히려 늘지 않는지 확인 목적. Azure Retail Prices API 조회 (2026-07, southcentralus 기준 — 리전별 단가 상이): NC4as_T4_v3 $0.631/hr, NV36ads_A10_v5 $3.84/hr
| 구성 | 시간당 (southcentralus) | A10 등가 대비 |
|---|---|---|
| A10 × 2 (기본 구성) | $7.68/hr | 기준 |
| T4 × 10 (500자 등가 대체) | $6.31/hr | 약 -18% |
| T4 × 12 (1,000자 등가 대체) | $7.57/hr | -1% (사실상 동률) |
위 절감률은 VM 비용만 기준으로 관찰된 수치다. 노드 수 증가에 따른 운영비(모니터링, 패치, 장애 대응 인력)를 포함한 TCO는 환경별로 재산정이 필요하다. 결론: 대체 구성이라도 VM 비용은 등가 이하 — 비용이 대체를 막는 요인은 아님.
- LB는 A10 × 2 기본 구성에도 이미 존재하는 공통 요소 — 비교 시 비용 차이 없음
- 노드 수 증분 부대비용: OS 디스크(P10급) ~$0.02/hr × 추가 노드 수 → T4 10대 기준 +$0.2/hr 수준 (무시 가능)
- 상시 운영이면 1-year Savings Plan/RI 적용 시 30~60% 추가 절감 여지 (양쪽 공통)
엔드포인트 아키텍처¶
기존 A10 × 2 구성의 LB backend pool을 T4 노드로 교체/확장하는 형태 — TEI는 stateless HTTP(POST /embed)라 L4 분배로 충분:
앱(청킹 파이프라인) ──> Internal Standard LB (:8080) ──> backend pool
│ health probe: GET /health (TEI 내장)
├─ vm-t4-01 (NC4as_T4_v3)
├─ vm-t4-02
└─ vm-t4-N # VMSS 구성 시 증감·복구 자동화
| 옵션 | 적합도 | 비고 |
|---|---|---|
| Internal Standard LB | ✅ 권장 | L4, 저비용, health probe로 노드 장애 자동 제외 |
| VMSS + LB | ✅ 운영 자동화 | 노드 증감·재생성 자동. Spot 혼용 시 eviction 복구 포함 |
| Application Gateway | △ 과잉 | TLS 종료·L7 라우팅 필요 시에만 — 비용·홉 추가 |
| 클라이언트 사이드 라운드로빈 | △ 적재 전용이면 가능 | 적재 파이프라인이 유일한 클라이언트면 IP 리스트 셔플로 충분 — LB 불요 |
설계 파라미터:
- 분배 모드: 기본 5-tuple hash — 배치 요청이 요청 단위로 분산되므로 세션 어피니티 불요 (활성화 시 편중 발생)
- Health probe: TEI /health — 모델 로딩(콜드스타트 ~1-2분) 중 자동 제외
- 노드당 최적 부하 유지: batch 8~32 / conc 4 × N대 → 파이프라인 전체 concurrency = 4N
- 노드 장애 시 처리량 (N-1)/N로 우아한 성능 저하 — N≥5면 노드 1대 손실 시에도 80%+ 유지
- 쿼리 경로(Custom Vectorizer) 겸용 가능 — LB 홉 <1ms, 단건 5.6ms 대비 무시 가능
쿼리 트래픽 증가 시 증설 기준 — QPS 스윕 실측¶
T4 1대(NC4as_T4_v3, TEI turing-1.8, BGE-m3-ko)에 오픈루프 고정 도착률로 단건 쿼리(~40자)를 주입하며 포화 지점을 실측 (30s/단계, 3라운드 스윕 — bench_qps_sweep.py):
| 도착률 (QPS) | p50 | p95 | p99 | GPU util | 판정 |
|---|---|---|---|---|---|
| 50 | 9.2 ms | 9.5 ms | 10.0 ms | 39% | 여유 |
| 100 | 5.6 ms | 6.0 ms | 8.7 ms | 41% | 여유 |
| 150 | 5.6 ms | 5.8 ms | 9.4 ms | 64% | 안전 운용 상한 권장 |
| 180 | 6.0 ms | 6.5 ms | 12.5 ms | 76% | 여유 소진 접근 |
| 200 | 6.0 ms | 6.9 ms | 19.2 ms | 90% | 무릎(knee) — 큐잉 직전 |
| 210 | 15.1 ms | 19.2 ms | 27.5 ms | 95% | 큐잉 시작 (p50 2.5×) |
| 250 | 24.0 ms | 28.1 ms | 29.7 ms | 97% | 큐잉 지연 지속 |
| 400 | 74.0 ms | 93.9 ms | 128 ms | 99% | 과부하 |
| 450+ | 557~896 ms | 900~965 ms | 937~983 ms | 100% | 폭주 (수용 불가) |
핵심 관찰: - 무릎 지점: ~200 QPS (GPU util ~90%) — 이 지점까지 p50은 베이스라인(~6ms) 유지, 초과 즉시 p50이 2.5× 점프(6→15ms)하며 큐잉 지연 시작. 도착률에 비례해 지연 누적, 450 QPS부터 지수적 폭주 - 안전 운용 상한: ~150 QPS/대 (GPU ~64%, p99 <10ms) — 무릎 대비 25% 마진 - 단문 쿼리(40자)의 상한(200 QPS)은 500자 청크 처리량(60 texts/s)의 3.3배 — attention O(N²)·토큰 수 비례로 per-query 연산량이 낮기 때문. 즉 쿼리 경로와 적재 경로의 노드당 수용량은 별도 산정 필요 - 저부하(5~50 QPS) 구간의 mean 9~10ms > 100 QPS의 5.6ms — GPU idle clock(power 30W)에서 dynamic batching 미형성 시 오히려 느림. 부하 증가 시 clock boost + 배치 효율로 개선 (레이턴시-부하 관계가 단조 증가가 아님)
증설 트리거 (실측 기반):
| 지표 | 임계값 | 근거 |
|---|---|---|
| 노드당 쿼리 QPS | > 150 (40자 기준) | 무릎(200 QPS) 대비 25% 마진 |
| GPU utilization (지속) | > 70~80% | 90%가 무릎 — 선제 증설 구간 |
| 임베딩 p50 레이턴시 | 베이스라인의 2× (≈12ms+) | 무릎 초과 시 p50 2.5× 점프 실측 |
| 임베딩 p99 레이턴시 | > 20ms | 200 QPS에서 p99 19ms — 큐잉 전조 |
- p50 기반이 가장 민감 — 무릎 초과가 p50에 즉시 반영됨 (p99는 무릎 전부터 완만히 상승해 노이즈 있음)
- VMSS 구성 시 GPU util 70% 기준 autoscale 룰로 자동화 가능
- 쿼리·적재 혼용 주의: 동일 풀에서 Push 적재(대형 배치)와 쿼리를 겸용하면 적재 배치의 GPU 점유로 쿼리 레이턴시가 상승. 이 경우 증설보다 ① 적재 시간대 분리 또는 ② backend pool 분리(쿼리 전용 + 적재 전용)가 우선 — 쿼리 단독으로 150 QPS/대를 초과하는 경우보다 적재 간섭이 원인인 경우가 흔함
측정 조건: 단일 노드 localhost 호출(네트워크 홉 제외), ~40자 한국어 쿼리 고정. 쿼리 길이가 길어지면 상한이 낮아지며(500자 기준 ~60 QPS), LB 경유·실트래픽 분포에서는 무릎이 다소 앞당겨질 수 있음.
대체 구성 판단¶
| 관점 | T4 × 5N (대체 구성) | A10 × N (기본 구성) |
|---|---|---|
| 시간당 VM 비용 (500자) | 약 -15~18% (등가 이하) | 기준 |
| 시간당 VM 비용 (1,000자) | 동률 (6N대 필요) | 기준 |
| 수급 | ✅ T4는 구세대로 상대적 수급 안정 | Spot/리전에 따라 물량 변동 |
| 장애 내성 | 노드당 1/5N 손실 | 노드당 1/N 손실 (N≥2면 SPOF 없음) |
| 운영 복잡도 | 관리 포인트 5N (probe·드라이버 패치) | ✅ 관리 포인트 N |
| 스케일 증분 | ✅ 60 texts/s 단위 미세 조정 | 301 texts/s 단위 |
정리: A10 물량 확보가 불가한 시점에는 T4 × 5N(500자 기준, 1,000자 위주면 6N) 구성으로 처리량·비용 모두 등가 수준 확보 가능. LB 등 엔드포인트 구조는 기존과 동일하므로 backend pool 교체만으로 전환 가능. 노드 수 증가에 따른 관리 포인트 확대는 VMSS 자동화로 완화. 실환경 편차(LB 분배·warmup·eviction)를 감안해 여유분 +1대 이상 산정을 권장.
결론 및 권장¶
| 시나리오 | 권장 GPU | 근거 |
|---|---|---|
| 쿼리 벡터화 (실시간 검색 경로) | 둘 다 가능 | 4~6ms — latency-bound, E2E 응답 대비 비중 작음 |
| 대량 초기 적재 (Push API, 데드라인 존재) | A10 | 본 측정 기준 약 5~5.5× — 1M 청크 기준 0.9hr vs 4.5hr |
| 상시 증분 적재 (소량) | T4 충분 | 60 texts/s = 21.6만 건/hr — 증분 볼륨 대비 과분 |
| 장문(1,000자+) 위주 코퍼스 | A10 | 시퀀스 길이 비례 격차 확대 (측정 기준 5.5×) |
위 권장은 본 측정 환경(TEI 1.8, dragonkue/BGE-m3-ko, 한국어 텍스트) 기준이며, 실제 결과는 모델·텍스트 길이·서빙 엔진 버전·배치 설정·운영 환경에 따라 달라질 수 있다.
운영 파라미터: - Push 파이프라인 최적점: T4 = batch 8~32 / conc 4 (초과 시 역효과), A10 = batch 32~64 / conc 4~8 - 1M+ 청크 적재: A10 1대 ≈ T4 5대 — A10 수급 불가 시 T4 × 5N으로 대체 산정 → 대체 전략 참고 - Spot eviction 대비: Push 파이프라인에 retry + checkpoint(마지막 성공 문서 ID) 필수. 본 측정 중 eviction 미발생 - A10 Spot 수급 주의: NVadsA10_v5 Spot은 수급 변동성이 크며 특정 시간대에는 할당이 실패할 수 있다. 운영 환경에서는 PAYG 또는 예약 인스턴스(RI/Savings Plan)와의 조합 검토를 권장
재현 방법¶
인프라 생성 + 벤치마크 실행 명령
# 1. Spot VM 생성 (southcentralus, docker+container-toolkit은 cloud-init으로)
az group create -n rg-embed-bench -l southcentralus
az vm create -g rg-embed-bench -n vm-t4-bench --image Ubuntu2204 \
--size Standard_NC4as_T4_v3 --priority Spot --eviction-policy Deallocate --max-price -1 \
--admin-username azureuser --ssh-key-values ~/.ssh/embed_bench_key.pub \
--os-disk-size-gb 128 --nsg-rule NONE --custom-data cloud-init-gpu.yaml
az vm create -g rg-embed-bench -n vm-a10-bench --image Ubuntu2204 \
--size Standard_NV36ads_A10_v5 --priority Spot --eviction-policy Deallocate --max-price -1 \
--admin-username azureuser --ssh-key-values ~/.ssh/embed_bench_key.pub \
--os-disk-size-gb 128 --nsg-rule NONE --custom-data cloud-init-gpu.yaml
# 2. NSG에 내 IP만 SSH 허용 + NVIDIA 드라이버 확장 (GRID/CUDA 자동 판별)
az network nsg rule create -g rg-embed-bench --nsg-name vm-t4-benchNSG -n allow-ssh-myip \
--priority 100 --source-address-prefixes <MY_IP>/32 --destination-port-ranges 22 --access Allow --protocol Tcp
az vm extension set -g rg-embed-bench --vm-name vm-t4-bench \
--name NvidiaGpuDriverLinux --publisher Microsoft.HpcCompute --version 1.11
# (a10도 동일)
# 3. TEI 기동 — T4는 turing 태그, A10은 86 태그
sudo docker run -d --gpus all --name tei -p 8080:80 -v /opt/tei-data:/data \
ghcr.io/huggingface/text-embeddings-inference:turing-1.8 \
--model-id dragonkue/BGE-m3-ko --max-client-batch-size 128 --auto-truncate # T4
sudo docker run -d --gpus all --name tei -p 8080:80 -v /opt/tei-data:/data \
ghcr.io/huggingface/text-embeddings-inference:86-1.8 \
--model-id dragonkue/BGE-m3-ko --max-client-batch-size 128 --auto-truncate # A10
# 4. 벤치마크 (VM 내부에서 localhost로 실행 — 네트워크 변수 제거)
python3 bench_embed_gpu.py --gpu t4 --rounds 5 # 시나리오 A+B (500자)
python3 bench_embed_gpu.py --gpu t4 --rounds 3 --chunk-chars 1000 # 시나리오 C (1,000자)
원시 데이터 (5라운드 전체)
- 단건 레이턴시(mean_ms) 라운드별 — T4: 5.51 / 5.63 / 5.57 / 5.64 / 5.60, A10: 3.88 / 3.95 / 3.95 / 4.09 / 3.98 - 최대 조합(64×4) texts/s 라운드별 — T4: 57.0 / 56.3 / 54.2 / 57.1 / 53.7, A10: 303.4 / 297.5 / 303.4 / 303.1 / 298.4 - 1,000자(32×4) texts/s — T4: 24.2 / 23.4 / 22.7, A10: 128.0 / 131.1 / 130.0 - 부하 중 GPU 상태 — T4: util 100%, power 69W/70W(TDP cap), CPU idle 73% / A10: util ≤84% - **T4 16 vCPU(NC16as_T4_v3) 교차검증** — 단건 mean_ms: 5.76 / 5.94 / 5.93 / 5.85 / 5.82, 최적 조합 texts/s(500자): 63.6 / 62.3 / 61.8 / 60.6 / 59.9, 1,000자(32×4): 22.5 / 23.0 / 22.3 — 4 vCPU 결과와 오차범위 내 동일. 부하 중 GPU 100% / 62W, CPU idle 80.7%부록: 비용 참고¶
Spot 기준 실험 — 가격은 시점·리전 변동성이 커 참고 수준으로만 기재.
- southcentralus, 2026-07: T4(NC4as_T4_v3) Spot $0.183/hr · PAYG $0.631/hr / A10(NV36ads_A10_v5) Spot $0.710/hr · PAYG $3.84/hr
- 1M 청크(500자) 적재 비용: Spot — A10 $0.65 ≈ T4 $0.83 / PAYG — T4 $2.87 < A10 $3.53