06. 성능·요구사항·플랫폼·실행 모드 — 돌리려면 무엇이 필요하고 얼마나 빠른가

앞 장들에서 Face Landmarker가 무엇을, 어떻게, 왜 하는지를 봤다. 이 장은 실제로 돌릴 때 필요한 것을 정리한다. 모델 크기, 실행 모드, 설정 옵션, 가속(delegate), 플랫폼 요구사항, 그리고 얼마나 빠르고 정확한지의 벤치마크다. 02장의 검출·추적 파이프라인과 05장의 Tasks API 옵션을 이어받는다.

이 장의 수치는 2026-06 조사 시점 기준이다. 모델 번들 파일은 Google 스토리지의 float16/latest 버전이다(파일 last-modified 2023-05-03).

6.1 핵심 요약 — 먼저 읽기

• 번들 1개로 3개 모델이 묶인다. face_landmarker.task 안에 ① 얼굴 검출기(BlazeFace short-range, 입력 192×192) ② 얼굴 메시(478 랜드마크, 입력 256×256) ③ 블렌드셰이프 예측기(52 score, 입력 1×146×2)가 들어간다. 셋 다 float16이다.
• 번들 총 크기는 3,758,596 바이트, 약 3.58 MiB(≈3.76 MB)다. Google 스토리지 content-length로 직접 측정했다.
• 실행 모드는 3가지다: IMAGE / VIDEO / LIVE_STREAM. VIDEO·LIVE_STREAM은 타임스탬프(ms)를 받는다. 프레임 사이를 추적(tracking)해 매 프레임의 검출을 생략하고 지연을 줄인다. 비동기 콜백(result listener)으로 결과를 받는 것은 LIVE_STREAM뿐이다.
• 주요 설정은 7개에 delegate가 더해진다. num_faces=1, 3종 confidence 임계값은 모두 기본 0.5, output_face_blendshapes=false, output_facial_transformation_matrixes=false이다.
• delegate는 CPU/GPU 중에서 고른다. 웹은 delegate: "GPU"(WebGL)를 권장하고, Android·iOS는 BaseOptions에서 지정한다.
• 공식 device별 latency(ms) 수치는 제한적이다. 전체 파이프라인의 ms 벤치마크는 공개돼 있지 않다. 공개된 것은 검출기(BlazeFace short-range)의 Pixel 6 latency와, 얼굴 메시 모델 카드의 정확도(IOD MAE) 수치다. 정확도 수치는 latency가 아니다. 이 점은 6.6절에서 다시 짚는다.

6.2 모델 번들 구성과 크기

번들 안에 무엇이 들어 있나

face_landmarker.task는 하나의 파일이다. 안에는 모델 3개와 메타데이터가 든 번들이 있다.

검출 단계와 메시 단계는 입력 해상도가 다르다. 공식 Face Landmarker 가이드는 검출기 입력을 192×192로 적고, 메시 모델 카드는 메시 입력을 256×256으로 적는다(25% 마진을 두고 크롭한 뒤 리사이즈). 한 가지 주의할 점이 있다. 독립 Face Detector 가이드는 같은 검출기를 128×128로 표기한다. 이 책은 번들 기준인 192×192를 따른다(02장 §2.2와 같은 약속이다).

번들 총 크기 (실측)

Google 스토리지에서 content-length로 직접 확인한 값이다.

번들의 last-modified는 2023-05-03이고, 검출기 단독 tflite는 2023-04-26이다. 검출기는 약 0.23 MB뿐이다. 이를 빼면 나머지 약 3.35 MB가 얼굴 메시와 블렌드셰이프 모델의 몫이다. 두 모델의 개별 파일 크기는 공식적으로 분리 공개되지 않는다. 번들 내부 분할 수치는 출처가 없어 추정하지 않는다.

transformation matrix는 모델이 아니다

output_facial_transformation_matrixes를 켜면 4×4 변환 행렬을 얻는다. 이 행렬은 별도 신경망이 아니다. 검출된 랜드마크를 표준(canonical) 얼굴 메시에 정렬해 계산하는 후처리 결과다(04장 §4.5). 따라서 번들 크기에 큰 별도 모델로 잡히지 않는다.

얼굴 메시 모델 카드 핵심

• 모델 타입: CNN. MobileNetV2-like 커스텀 블록으로 실시간에 맞췄다.
• 입력: 25% 마진을 둔 크롭 얼굴을 256×256으로 리사이즈한다.
• 출력: 478개 3D 랜드마크(1D 텐서로 flatten) + face flag(존재 확률, 임계값 기본 0.5) + 제한적 blendshape(cheekPuff, tongueOut).
• 모델 날짜: 2022-09-15. 라이선스: Apache 2.0.
• 이 모델 카드에는 device별 추론 latency(ms)가 없다. 정확도 지표만 있다(6.7절).

모델 카드가 메시 모델 출력으로 적은 "제한적 blendshape(cheekPuff, tongueOut)"는 학습 부산 출력 표기일 뿐이다. 런타임에 52계수를 내는 것은 별도의 Blendshape V2 모델이다(04장 §4.3). 메시 모델이 표정 계수를 낸다는 뜻이 아니다. 메시 모델이 학습 과정에서 곁가지로 일부 신호를 함께 다뤘다는 표기다. 실제 파이프라인에서 52 블렌드셰이프는 146점 서브셋을 입력받는 2차 모델이 담당한다.

6.3 실행 모드 (Running Mode)

세 모드는 입력의 시간성과 동기·비동기 처리 방식이 다르다. 02장 §2.4에서 성능 관점으로 이미 봤다.

기본값은 IMAGE다. IMAGE와 VIDEO는 호출 스레드를 블로킹한다. 그래서 웹에서는 UI 스레드를 막지 않도록 web worker를 권장하고, 모바일에서는 백그라운드 스레드를 권장한다.

LIVE_STREAM은 즉시 반환한다. 처리 중에 들어온 새 프레임은 버린다(drop). 처리가 끝나면 콜백으로 결과를 준다. 결과에는 입력 타임스탬프가 함께 실려, 어느 프레임의 결과인지 맞출 수 있다.

웹(JS)에서는 모드 표기가 IMAGE와 VIDEO 두 개뿐이다. 라이브 스트림을 포함한 비디오는 VIDEO 모드에서 detectForVideo()로 처리한다. JS에는 별도 비동기 콜백 모드가 드러나지 않는다.

아래 그림은 입력 종류에 따라 어느 모드로 갈라지고, 각 모드의 반환·추적 동작이 어떻게 다른지를 보여 준다.

추적이 지연을 줄이는 원리와 재획득(reacquisition) 분기는 02장 §2.4의 상태도·시퀀스도에서 풀었다.

6.4 설정 옵션 (Config / Options)

Tasks API 공통 옵션이다. 플랫폼별 이름은 snake_case(Python/C++)와 camelCase(Android/iOS/JS)로 표기만 다르다. 의미와 기본값은 같다.

위 기본값은 C++ FaceLandmarkerOptions 헤더와 Python·Android·iOS 가이드에서 모두 같게 확인된다.

동작상 주의할 디테일이 셋 있다.

• smoothing(랜드마크 떨림 완화)은 num_faces가 1일 때만 켜진다. 얼굴이 둘 이상이면 빠진다. 그래서 다중 얼굴을 추적하면 지터가 늘 수 있다(02장 §2.4).
• min_face_presence_confidence는 랜드마크 단계의 임계값이고, min_face_detection_confidence는 검출 단계의 임계값이다. 단계가 다른 별개 게이트다.
• result_callback은 LIVE_STREAM에서만 의미가 있다. IMAGE나 VIDEO에서 지정하면 에러다.

아래 그림은 세 confidence 임계값이 각각 어느 단계의 관문인지, 그리고 출력 옵션과 num_faces가 동작을 어떻게 가르는지를 정리한다.

6.5 Delegate (CPU/GPU)와 가속

선택지

BaseOptions.delegate로 추론 백엔드를 고른다.

웹에서는 공식 예제와 가이드가 실시간 처리에 delegate: "GPU"(WebGL)를 권장한다. CPU도 되지만 비디오 실시간에는 GPU가 유리하다. 웹에서 setOptions()로 delegate를 바꾸는 호출은 async다. resolve를 await한 뒤 detect()를 불러야 running-mode/delegate 충돌 에러를 피한다.

성능 차이 경향 — "GPU=무조건 빠름"은 틀린 일반화

같은 기기에서 CPU와 GPU를 비교한 공개 수치는 검출기 하나뿐이다(BlazeFace short-range, Pixel 6).

이 작은 검출 모델에서는 CPU가 오히려 빠르다. GPU로 보내고 받는 디스패치·전송 오버헤드가 모델 연산량보다 크기 때문이다. "GPU delegate가 항상 빠르다"는 그래서 틀린 일반화다.

일반 경향은 정성적으로만 말할 수 있다(공식 ms 없음). 모델과 연산량이 커지고 해상도가 높아질수록 GPU 이점이 커진다. 모바일에서 연속 프레임을 처리할 때는(VIDEO/LIVE_STREAM) 발열·전력 면에서 GPU가 유리한 경우가 많다. 정확한 ms는 기기·드라이버·해상도에 따라 달라지므로 목표 기기에서 실측하는 편이 낫다.

6.6 플랫폼·언어 지원과 최소 요구사항

출처를 짚어 두면, Android minSdk 24·iOS 12.0·Python 3.9+는 각 setup 가이드 기준이다. 웹의 최소 브라우저 버전은 공식 문서가 구체 숫자를 적지 않는다. 그래서 "WASM과, GPU를 쓰면 WebGL/WebGPU까지 지원하는 최신 브라우저"로만 기술한다. Python 3.9–3.12 범위는 빌드 문서·이슈 트래커 기준이라 시점에 따라 상한이 바뀔 수 있다.

아래 그림은 같은 번들 하나가 네 플랫폼으로 갈라지고, 각 플랫폼이 어떤 가속 백엔드를 쓰는지를 보여 준다.

6.7 성능·벤치마크 — 두 지표를 분리해서 읽기

전체 파이프라인의 공식 device별 latency(ms)/FPS 표는 공개가 제한적이다. 그래서 아래는 세 묶음으로 나눠 정직하게 정리한다. 공식으로 확인된 latency, 정확도 지표, 정성적 경향이다.

가장 중요한 주의 — 두 개의 "정확도" 숫자는 다른 지표다

학습자가 가장 헷갈리는 지점을 먼저 못 박는다. 이 기술에는 "정확도"라는 이름으로 자주 인용되는 서로 다른 두 숫자가 있다. 같은 것으로 섞어 읽으면 안 된다.

왜 분리해야 하나. MNE 3.88%는 블렌드셰이프(표정 계수) 모델의 오차다. IOD MAE 2.62%/3.24%는 메시(랜드마크 위치) 모델의 오차다. 대상 모델이 다르고, 측정하는 지표가 다르고, 출처도 다르다. "이 기술의 정확도는 2.62%다"나 "3.88%다"처럼 한 숫자로 말하면 틀린다. 무엇의 무슨 오차인지를 늘 함께 말해야 한다.

공식 확인된 latency (검출기 한정)

이 값은 검출 단계만의 수치다. 메시와 블렌드셰이프까지 포함한 전체 1프레임 비용은 아니다.

메시 모델 정확도·공정성 (latency 아님)

IOD MAE는 안구간 거리로 정규화한 평균 절대 오차다(단위 %). 위 표의 메시 지표를 좀 더 펼치면 다음과 같다.

해석하면, tracking 모드가 reacquisition보다 정확하다. 02장 §2.4의 "빠르면서 더 정확한 이중 이득"이 여기서 수치로 확인된다. 성별·피부톤 간 편차는 fairness 기준 안에 든다. 다만 이 수치는 "얼마나 빠른가"가 아니라 "얼마나 정확하고 공정한가"임에 유의한다.

blendshape / matrix on-off 비용

output_face_blendshapes=true이면 블렌드셰이프 모델이 한 번 더 추론된다. 이 모델은 메시 출력을 입력으로 받는다(입력 1×146×2). 그만큼 연산이 추가된다. 모델 자체는 매우 가볍다. GHUM 논문 기준 Pixel 6에서 약 1.2 ms다. 단, 공식 ms 단위의 추가 비용 수치는 공개되지 않았다.

output_facial_transformation_matrixes는 후처리 행렬 계산이다. 별도 신경망이 아니라 추론 부담이 작다.

정성적 FPS 경향

BlazeFace·Face Mesh 계열이 모바일 GPU에서 실시간(수십~수백 FPS)을 목표로 설계됐다는 서술은 여러 출처에 있다. 하지만 Face Landmarker(Tasks) 번들에 대한 출처 있는 정확한 FPS 표는 확보하지 못했다. 실무에서는 목표 기기에서 직접 프로파일링하는 편이 낫다. 해상도, num_faces, blendshape on/off, CPU와 GPU 조합을 바꿔 가며 VIDEO/LIVE_STREAM으로 재 보라.

6.8 입력 요구사항

형식·해상도

입력은 RGB 이미지다. Tasks Vision 공통으로 MPImage·ImageData·카메라 프레임을 RGB로 처리한다. 검출 단계는 192×192, 메시 단계는 256×256으로 내부에서 리사이즈한다. 사용자가 원본 해상도를 직접 맞출 필요는 없다. 다만 너무 작거나 멀리 있는 얼굴은 리스케일할 때 품질이 떨어진다.

방향·각도·가시성 (모델 카드 한계)

모델 카드는 셀피(selfie) 모드의 전면 카메라 영상에 맞춰져 있다. 다음 조건에서는 적합하지 않다.

입력 허용 오차는 위치·스케일 10% 시프트와 roll 8°까지다. 두 눈의 중심을 잇는 선이 수평이 되도록 회전 정렬되는 것이 이상적이다. 이 정렬은 02장 §2.2의 ROI 정렬에서 내부적으로 수행한다.

환경·조명·다중 얼굴·용도 제한

조명이 나쁘거나 노이즈·모션이 크거나 얼굴 겹침이 심하면 품질이 떨어지고 지터(inter-frame jittering)가 는다. 학습 시 증강으로 일부는 메워 둔다. 다중 얼굴은 num_faces로 상한을 정한다. 단 num_faces>1이면 smoothing이 빠져 지터가 늘 수 있다(6.4절). 이 모델은 사람 식별이나 생체 인증 용도가 아니다. 생명이 걸린 의사결정에 쓰는 용도도 아니다(모델 카드 명시).

6.9 전체 파이프라인 한눈에 (성능 관점)

아래 그림은 입력 한 장이 모드 분기부터 검출·추적·메시·옵션 출력까지 어떤 경로로 흐르는지를 한눈에 보여 준다.

6.10 한계 및 미확인 항목 (정직 고지)

• 전체 파이프라인의 device별 latency/FPS 공식 표는 확보하지 못했다. 확인된 ms는 검출기(BlazeFace, Pixel 6)뿐이다. 메시·블렌드셰이프까지 포함한 end-to-end ms는 공개가 제한적이다.
• 메시·블렌드셰이프 모델의 개별 파일 크기는 번들 내부 분할이라 공식 분리 수치가 없다. 번들 3.58 MiB에서 검출기 0.23 MiB를 뺀 약 3.35 MiB가 나머지라는 산술 추정만 가능하다.
• 웹 최소 브라우저 버전 숫자는 공식 문서가 명시하지 않는다.
• Python의 GPU delegate 가용성은 플랫폼·빌드에 따라 다르며, 일반적으로 CPU를 쓴다.
• 모델 번들 파일은 float16/latest 기준 2023-05-03 버전이다. 이후 Google이 갱신하면 크기·수치가 달라질 수 있다.

이로써 "무엇을, 어떻게, 왜, 어떻게 돌리나"가 모두 갖춰졌다. 다음 장은 이 모든 조각을 하나의 시나리오로 꿰고 단일 결론으로 마무리한다.

→ 다음 장: 07. Walkthrough와 결론

Sources

모든 URL은 2026-06 조사 시점 접근 기준. 도메인은 ai.google.dev/edge/mediapipe로 통일했다(예전 developers.google.com/edge/mediapipe 경로는 이쪽으로 리다이렉트된다).

• Face landmark detection guide (Tasks, Models/Config/RunningMode 기준): https://ai.google.dev/edge/mediapipe/solutions/vision/face_landmarker
• Face landmark detection — Python (옵션·기본값·패키지): https://ai.google.dev/edge/mediapipe/solutions/vision/face_landmarker/python
• Face landmark detection — Android (Gradle, runningMode): https://ai.google.dev/edge/mediapipe/solutions/vision/face_landmarker/android
• Face landmark detection — iOS (CocoaPods, detect/detectAsync 콜백): https://ai.google.dev/edge/mediapipe/solutions/vision/face_landmarker/ios
• Face landmark detection — Web/JS (@mediapipe/tasks-vision, WASM, GPU delegate): https://ai.google.dev/edge/mediapipe/solutions/vision/face_landmarker/web_js
• Face detector guide (BlazeFace short-range; Pixel 6 CPU 2.94 ms / GPU 7.41 ms; 독립 가이드 128×128 표기): https://ai.google.dev/edge/mediapipe/solutions/vision/face_detector
• Setup guide for Android (minSdk 24): https://ai.google.dev/edge/mediapipe/solutions/setup_android
• Setup guide for iOS (iOS 12.0, Xcode 10.3+): https://ai.google.dev/edge/mediapipe/solutions/setup_ios
• Setup guide for Python (Python 3.9+, pip 20.3+): https://ai.google.dev/edge/mediapipe/solutions/setup_python
• Model Card — MediaPipe Face Mesh V2 (입력 256×256, 478 landmarks, IOD MAE 2.62%/3.24%, 각도·가시성 한계, cheekPuff/tongueOut 학습 부산 표기): https://storage.googleapis.com/mediapipe-assets/Model%20Card%20MediaPipe%20Face%20Mesh%20V2.pdf
• Blendshapes GHUM (arXiv:2309.05782) — 블렌드셰이프 모델 MNE 3.88%, Pixel 6 ≈1.2 ms: https://arxiv.org/abs/2309.05782
• C++ FaceLandmarkerOptions 헤더(기본값 교차검증): https://github.com/google-ai-edge/mediapipe/blob/master/mediapipe/tasks/cc/vision/face_landmarker/face_landmarker.h
• 번들/검출기 파일 크기 — Google 스토리지 HTTP content-length 직접 측정:
  • face_landmarker.task = 3,758,596 bytes (last-modified 2023-05-03): https://storage.googleapis.com/mediapipe-models/face_landmarker/face_landmarker/float16/latest/face_landmarker.task
  • blaze_face_short_range.tflite = 229,746 bytes: https://storage.googleapis.com/mediapipe-models/face_detector/blaze_face_short_range/float16/latest/blaze_face_short_range.tflite

수치 출처·시점 요약