9.2 처리량과 비용 산정 - 내 장비에서 직접 재서 계산하기
오디오·프레임 추출, 비전 모델, LLM의 실측 처리 시간을 바탕으로 샘플링 간격과 중복 제거가 전체 처리 시간에 미치는 영향을 계산하고, 로컬과 클라우드 선택 기준, 측정 절차와 큐 설계를 설명합니다.
#모델 성능표 대신 내 장비의 숫자
"1시간 영상을 분석하는 데 얼마나 드나요?"는 가장 많이 받는 질문인데, 모델 소개 자료의 속도는 조건이 다른 환경에서 잰 값이라 그대로 쓸 수 없습니다. 하드웨어, 양자화, 입력 해상도, 출력 길이에 따라 몇 배씩 달라집니다. 믿을 수 있는 숫자는 내 장비에서 내 입력으로 잰 값뿐입니다. 이 글은 제 장비에서 잰 값과, 그 값으로 계산하는 방법입니다.
#실측값
환경: 윈도우 PC, NVIDIA RTX 5070 Ti 16GB, 로컬 qwen3.8:27b(Q4_K_M).
| 단계 | 측정 | 결과 |
|---|---|---|
| 오디오 추출(16kHz 모노) | 10분 영상 | 0.21초 (실시간의 약 2,800배속) |
프레임 추출(10초마다 640px JPEG, select 방식) |
10분 영상, 60장 | 0.68초 |
| 비전 모델(1280×720 프레임 1장, 글자 + 장면 설명) | 4장 | 7.7~13.5초, 평균 9.9초 |
| LLM 메타데이터(입력 391토큰, 출력 572토큰) | 대본 7구간 | 30.1초 |
| LLM 메타데이터(키워드 5개로 제한한 프롬프트) | 같은 대본 | 19.6초 |
여기서 세 가지를 읽을 수 있습니다.
- 이 합성 영상에서는 FFmpeg 추출 시간이 매우 짧았습니다. 코덱, 해상도, 저장 장치에 따라 달라지지만, 비용의 대부분은 모델 호출에서 발생했습니다.
- 비전 모델은 프레임 1장에 약 10초입니다. 1시간 영상(약 108,000프레임)을 모두 보면 약 300시간입니다. 프레임을 줄이는 것이 가장 큰 절감입니다.
- LLM 시간은 입력보다 출력 쪽에 좌우되는 것으로 보입니다. 같은 입력에서 키워드를 줄이는 프롬프트로 바꾸자 30.1초가 19.6초가 되었습니다(두 번째 실행의 출력 토큰 수는 따로 기록하지 않았습니다).
#용량 계산
영상 길이, 샘플링 간격, 중복 제거 후 남는 비율, 프레임당 처리 시간으로 전체 처리 시간을 계산합니다. 측정한 시간은 GPU와 CPU가 섞여 쓰였을 수 있는 경과 시간이므로 "GPU 시간"이 아니라 "처리 시간"입니다.
def capacity(video_hours, interval_s, sec_per_frame, keep_ratio=1.0):
frames = video_hours * 3600 / interval_s * keep_ratio
return frames, frames * sec_per_frame / 3600
평균 9.88초/프레임(4장 평균)으로 계산한 결과입니다.
| 영상 분량 | 샘플링 간격 | 중복 제거 후 남는 비율 | 분석할 프레임 | 처리 시간 | 연속 가동 일수 |
|---|---|---|---|---|---|
| 1,000시간 | 10초 | 100% | 360,000 | 988시간 | 약 41일 |
| 1,000시간 | 60초 | 100% | 60,000 | 165시간 | 약 7일 |
| 1,000시간 | 10초 | 30% | 108,000 | 296시간 | 약 12일 |
| 10,000시간 | 60초 | 30% | 180,000 | 494시간 | 약 21일 |
같은 1,000시간이라도 샘플링 간격과 중복 제거만으로 처리 시간이 988시간에서 165~296시간으로 줄어듭니다. 중복 제거 후 남는 비율 30%는 가정입니다. 자막이 계속 바뀌는 뉴스와 같은 화면이 오래 이어지는 강연은 다르므로 자기 소재로 측정해야 합니다.
비용을 줄이는 순서는 대개 다음과 같습니다.
- 분석 목적을 좁힙니다. 글자를 읽을 필요가 없다면 해상도와 빈도를 낮춥니다.
- 싼 필터를 먼저 씁니다. 장면 전환 검출, 해시 중복 제거(8장 3편), 무음 제외 같은 단계는 모델 호출 없이 입력을 줄입니다.
- 작업에 맞는 크기의 모델을 씁니다. 글자만 읽으면 되는 일에 큰 범용 모델은 낭비일 수 있습니다.
- 한 번만 분석합니다. 입력 해시와 모델·프롬프트 해시로 중복 실행을 막습니다(9장 1편).
#로컬과 클라우드 서비스 선택
| 기준 | 로컬(자체 서버) | 클라우드 API |
|---|---|---|
| 데이터 반출 | 외부로 나가지 않음 | 영상·음성·텍스트가 외부로 전송됨(9장 3편) |
| 비용 구조 | 초기 장비 + 전기·운영. 많이 돌릴수록 단가가 내려감 | 사용량에 비례. 소량이면 유리 |
| 처리량 | 장비 수에 묶임. 갑작스러운 대량 처리에 약함 | 확장이 쉬움. 다만 호출 제한(rate limit) 있음 |
| 품질·갱신 | 쓰는 모델에 고정. 갱신은 직접 | 모델이 자주 갱신되어 결과가 바뀔 수 있음 |
| 운영 부담 | 드라이버, 모델 관리, 장애 대응 | 연동과 비용 감시 |
정답은 없습니다. 민감한 소재(미공개 방송분, 개인 식별 정보 포함)는 로컬, 공개된 소재의 대량 처리는 클라우드처럼 소재 등급별로 나누는 경우가 많습니다. 어느 쪽이든 9장 1편처럼 모델 버전을 기록해야 합니다.
#측정 절차
- 대표 입력을 장르별로 고릅니다(쉬운 것만 고르지 않습니다).
- 워밍업 호출을 버립니다. 첫 호출은 모델 적재로 느립니다.
- 같은 입력을 여러 번 돌려 중앙값(p50)과 느린 쪽(p95)을 기록합니다. 평균만 보면 가끔 길어지는 호출이 가려집니다.
- 입력 크기와 출력 크기(토큰 수, 해상도)를 같이 기록해서 시간이 어디에서 늘어나는지 봅니다.
- 동시에 여러 건을 돌렸을 때 처리량이 얼마나 늘어나는지도 재야 합니다. GPU 하나에 작업을 겹치면 오히려 느려질 수 있습니다.
#큐 설계와의 연결
AI 작업은 오래 걸리고 자주 실패하며 비용이 듭니다. 5장 7편의 작업 큐 원칙(원자적 선점, 상태 머신, 재시도, 멱등성)이 그대로 필요합니다. 추가로 다음을 둡니다.
- 작업 종류별 큐와 우선순위(긴급 소재 먼저, 대량 재처리는 한가한 시간에)
- 작업별 시간 제한(모델 호출이 멈추는 경우 대비)과 재시도 상한
- 예상 처리 시간을 용량 계산 결과로 사용자에게 안내("이 소재의 분석은 약 N시간 뒤 완료")
- 비용 상한(일일 호출 수, 일일 GPU 시간)을 넘으면 자동 중단하고 알림
#정리
- 모델 소개 자료의 속도가 아니라 내 장비·내 입력으로 잰 값을 씁니다(워밍업 제외, p50·p95 기록).
- 이 환경에서 비전 모델은 프레임당 약 10초라서, 샘플링 간격과 중복 제거가 총 비용을 가장 크게 좌우했습니다(1,000시간 기준 988시간 → 165~296시간).
- LLM은 입력 길이보다 출력 쪽에서 시간이 늘어나는 것으로 보였습니다(출력 토큰 수를 함께 기록하세요).
- 로컬과 클라우드는 소재의 민감도와 처리량으로 나누고, 큐에는 우선순위·시간 제한·비용 상한을 둡니다.
#참고 자료
링크는 2026-10-28에 열람이 되는 것을 확인했습니다. 규격과 도구 문서는 개정될 수 있으므로 적용하기 전에 최신 판을 확인하세요.