비용 및 지연 시간 조정

먼저 전체 파이프라인 측정하기#

모든 Results 객체는 자체 실행 시간을 단계별로 나눕니다:

from ultralytics import YOLO

model = YOLO("yolo26n.pt")
video = "https://github.com/ultralytics/assets/releases/download/v0.0.0/solutions_ci_demo.mp4"
totals = {"preprocess": 0.0, "inference": 0.0, "postprocess": 0.0}
for n, r in enumerate(model.predict(video, stream=True, verbose=False), 1):
    for stage in totals:
        totals[stage] += r.speed[stage]
print({stage: round(ms / n, 1) for stage, ms in totals.items()}, "ms per frame")

{'preprocess': 0.7, 'inference': 36.1, 'postprocess': 0.7} ms per frame

여기서는 추론이 모델 실행 시간의 95%를 차지하므로 모델 관련 조치가 효과가 있습니다. 디코딩과 자체 싱크도 같은 방식으로 시간을 측정한 다음(time.perf_counter()을 각각 감싸서 측정), 결과에 따라 다음 규칙을 적용합니다:

조치별 성능 순위표#

위에서부터 시도하고 예산을 충족하면 중단합니다:

수치는 YOLO26, TensorRT, OpenVINO 벤치마크 표와 아래 측정값에서 가져왔습니다. 실제 결과는 다를 수 있으므로 직접 측정하세요.

더 작은 모델#

COCO에서 측정한 YOLO26 벤치마크 표:

CPU에서는 모델을 한 단계씩 줄일 때마다 2.2~2.5배 빨라집니다. COCO의 정확도 차이는 최악의 경우입니다. 대형 객체를 다루는 3클래스 창고 검출기는 80클래스 일반 검출기보다 m에서 n으로 줄였을 때 성능 저하가 훨씬 적은 경우가 많으므로, 자체 검증 세트에서 더 작은 모델을 반드시 테스트해야 합니다.

더 작은 입력 크기#

연산량은 픽셀 수에 대략 비례하므로 imgsz=480은 640 크기의 약 56%에 해당하는 연산만 필요합니다. 테스트용 노트북의 CPU에서 ONNX Runtime, 배치 크기 1로 측정한 결과입니다(bus.jpg에서 25회 실행한 중앙값):

판단 기준: 새 크기에서 가장 작은 주요 객체가 여전히 약 10픽셀 이상이면 시도해 보세요. 객체가 작거나 멀리 있는 경우(드론, 카메라에서 멀리 떨어진 선반)에는 해상도를 유지하고 대신 모델 크기를 줄입니다.

프레임 수 줄이기#

추론이 프레임 속도의 병목이고 장면이 천천히 움직인다면 vid_stride=N으로 N번째 프레임마다 검출을 실행하고 트래커로 그 사이를 연결합니다:

import time

from ultralytics import YOLO

model = YOLO("yolo26n.pt")
video = "https://github.com/ultralytics/assets/releases/download/v0.0.0/solutions_ci_demo.mp4"
model.predict(video, vid_stride=30, verbose=False)  # warm up so the first timing is fair

for stride in (1, 2, 3):
    start, ids, frames = time.perf_counter(), set(), 0
    for r in model.track(video, stream=True, vid_stride=stride, tracker="bytetrack.yaml", classes=[0], verbose=False):
        frames += 1
        if r.boxes.is_track:
            ids.update(r.boxes.id.int().tolist())
    print(f"vid_stride={stride}: {frames} frames in {time.perf_counter() - start:.2f} s, {len(ids)} person IDs")

vid_stride=1: 62 frames in 2.66 s, 32 person IDs
vid_stride=2: 31 frames in 1.19 s, 30 person IDs
vid_stride=3: 20 frames in 0.95 s, 28 person IDs

프레임 수를 절반으로 줄이면 실행 시간도 대략 절반이 되며, 트래커는 ID 32개 중 30개를 유지했습니다. vid_stride=3에서는 ID 4개를 놓쳤으며, 이 보행 속도의 장면에서는 여기서 중단해야 한다는 신호입니다.

클라우드 비용 절감하기#

비용은 인스턴스 사용 시간을 유용한 작업량으로 나눈 값입니다. 이 카드와 같은 화면에서 필요한 수치 두 가지를 확인할 수 있습니다. 시간당 비용(여기서는 vCPU 1개와 4GiB에 $0.17)과 처리 작업량(대부분 유휴 상태인 엔드포인트가 P95 226ms로 24시간 동안 요청 59건 처리)입니다. 그런 다음:

• 사용률을 높입니다. GPU 사용률이 30%라면 비용의 70%가 낭비됩니다. 스트림을 배치 처리하거나(이전 강의 참조) Triton Inference Server를 통해 서비스를 제공합니다.
• 적정 규모를 사용합니다. 대형 GPU가 필요하다고 가정하기 전에 더 작은 GPU 또는 OpenVINO를 사용하는 CPU에서 벤치마크를 실행합니다.
• 배치 작업에는 스팟 또는 선점형 용량을 사용합니다. 보관된 동영상을 다시 처리하는 작업은 중단을 감당할 수 있지만, 라이브 스트림은 그렇지 않습니다.

주의할 점#