상태: 초안 (2026-10-16), 실측 모음. 서버 쪽 단계는 이 시리즈에서 집 랩의 8GB급 노트북용 GPU 한 장으로 잰 값이고, 운영 작업자(서버 GPU, 다른 작업과 카드를 나눠 씀)와 브라우저 끝단 값은 저장소
docs/tt/PERFORMANCE.md의 실측(2026-10-11–15)을 인용했습니다. 폰 안의 시간과 인터넷 구간은 미실측입니다. 시리즈 「비전 모델 읽기 3」 8편(마지막). 모델 자체는 TT Score 모델 해부에 있습니다.
TT Score 실시간 경로의 실제 예산표
목차
1. 길 한 번 따라가기
카메라 점수판(/tt/play/cam)에서 「자동 점수」 를 켜면 이렇게 흐릅니다.
- 폰(브라우저): 카메라 화면을 최대 30fps 로 잡아 512×288 에 가운데 맞춤으로 줄이고, JPEG(품질 0.7)로 만들어 앞에 「번호 + 찍은 시각」 8바이트를 붙여 WebSocket 으로 보냅니다. 답을 못 받은 프레임이 3장 쌓이면 보내기를 쉽니다.
- 웹 서버: 로그인·좌석·하루 한도를 보고 프레임을 그대로 GPU 작업자에게 중계합니다. 크기·속도 상한(초당 36장)을 여기서 한 번 더 지킵니다.
- GPU 작업자: JPEG 를 풀어 정규화하고, 세션마다 마지막 3장으로 창을 만듭니다. 기다리는 세션들의 최신 창을 한 배치로 공 모델에 넣고, 밀린 창은 새 창으로 덮습니다.
- 후처리: 마지막 프레임의 히트맵에서 공 덩어리를 찾고, 추적기로 이어 붙이고, 바운드·네트·랠리 끝을 규칙으로 찾고, 학습된 작은 CNN 이 바운드를 한 번 더 걸러 냅니다. 심판 규칙이 점수를 정합니다.
- 답: 공 위치는 프레임마다, 바운드·판정은 생길 때 JSON 으로 돌아가고 폰이 그립니다.
2. 예산표
| 단계 | 어디서 | 잰 값 | 출처·조건 | 줄이는 방법(편) |
|---|---|---|---|---|
| 카메라 잡기 | 폰 | 미실측 | — | — |
| 512×288 줄이기 + JPEG | 폰 | 미실측(서버 CPU 흉내 0.27 + 0.30ms) | 이 시리즈 1편 | 7편(기기 안) |
| 업로드(JPEG 12–18KB) | 인터넷 | 미실측 | 크기는 운영 설계 실측 | 5·7편(작게 보내기) |
| 웹 서버 중계 | 서버 | 미실측(따로 재지 않음) | — | — |
| JPEG 풀기 | 작업자 CPU | 0.31ms | 이 시리즈 1편 | — |
| 정규화 | 작업자 CPU | 1.35ms | 이 시리즈 1편 | GPU 에서 하기(1편, 미실측) |
| 창 쌓기 + GPU 로 | CPU → GPU | 1.76ms | 이 시리즈 1편 | uint8 로 옮기기(1편, 미실측) |
| 공 모델 추론 | GPU | 15.2ms(FP32) · 10.0ms(FP16) · 4.3ms(FP16 + 컴파일) | 실험용 GPU, 2·3편 | 2·3편 |
| 같은 추론, 운영 서버 GPU | GPU | 창 하나 10.5ms(쉬는 카드) · 34ms(다른 작업 2–3개와) | 성능 문서 2.9.8 | 6편(카드 나누기) |
| 히트맵 CPU 로 + 덩어리 찾기 | GPU → CPU | 0.18 + 0.07ms | 이 시리즈 1편 | — |
| 탁구대 따라가기(광류·컷 판단) | 작업자 CPU | p50 1.72 · p95 1.77ms | 성능 문서 2.12(조용한 노드) | 5편(가끔만 다시 찾기) |
| 바운드 규칙의 앞보기 | 엔진 | 3프레임(60fps 50ms, 30fps 100ms) | 엔진 설정 | — |
| 랠리 끝 판단 | 엔진 | 공이 일정 시간 안 보여야 끝 | 엔진 설정 | 1편(늦은 정답 대 틀린 답) |
| 답 내려받기 + 그리기 | 인터넷·폰 | 미실측 | — | — |
GPU 작업자 쪽만 더하면 약 19ms 로, 30fps 의 한 프레임(33.3ms) 안에 들어갑니다. 실시간 작업자 한 세션이 30fps 를 받아 내는 것과 맞습니다.
3. 끝에서 끝까지 잰 값
단계를 더한 값과 실제로 잰 끝단 값은 다릅니다. 줄에서 기다린 시간, 스레드 사이 넘김, 같은 카드의 다른 작업이 더해지기 때문입니다.
| 무엇을 | 잰 값 | 조건(운영 성능 문서) |
|---|---|---|
| 작업자 왕복, 세션 1 | p50 24–28ms · p99 31–32ms, 29.4fps | 같은 노드의 클라이언트, TTS 와 카드 공유(4.2) |
| 작업자 왕복, 세션 3 동시 | 세션마다 16–20fps, p50 70–95ms, p99 약 127ms | 같음, 보낸 프레임의 21–30% 가 덮여 버려짐(4.2) |
| 브라우저 끝에서 끝 | p50 65 · p90 84 · p99 146ms, 24.6fps | 헤드리스 브라우저 가짜 카메라 → 실제 중계 → 작업자, 카드 경합 중(4.1) |
| 랠리 끝 → 판정이 브라우저에 도착 | 중앙 0.67–0.90초 | 운영 엔진 코드를 시각 단위로 돌린 재현기, 공개 영상 여러 조건, 잡기 흔들림·왕복 60ms·작업자 15ms 를 운영에 가깝게 둔 값(2.14). 목표 1.5초 |
마지막 줄이 사용자가 실제로 느끼는 지연입니다. 프레임 하나의 왕복(수십 ms)보다 열 배 이상 깁니다. 판정은 「공이 바닥에 떨어졌거나 밖으로 나갔다」 를 확인해야 내릴 수 있는데, 공이 잠깐 가려진 것과 랠리가 끝난 것을 구분하려면 일정 시간 공이 안 보이기를 기다려야 하기 때문입니다. 연구 기록에서는 이 기다림을 줄이면 판정 지연의 p90 이 크게 줄지만 승자 정확도가 조금 떨어져, 아직 바꾸지 않았습니다(진행 중 연구).
이것이 1편의 Streaming Perception 과 같은 구조입니다. 늦은 정답과 이른 오답 사이의 거래이고, 모델을 몇 ms 빠르게 하는 것으로는 이 숫자가 거의 움직이지 않습니다.
4. 그럼 무엇부터 줄이나
| 하고 싶은 것 | 가장 큰 지렛대 | 근거 |
|---|---|---|
| 판정을 빨리 | 랠리 끝 판단(기다림 대 정확도) | 3절 |
| 한 카드에 세션을 더 | 추론: FP16 + 컴파일(15.2 → 4.3ms, 실험용 GPU) | 2·3편. 켜기 전 공 위치 동일성 확인 필요 |
| 지연 꼬리를 줄이기 | 카드를 다른 작업과 나누지 않기 | 6편(10.5 → 34ms) |
| 느린 회선에서도 | 512×288·JPEG 품질 유지, 업로드 대역 약 3Mbit/s | 7편 |
| 서버 없이 | 탁구대 찾기부터 폰으로 | 4·7편 |
2편에서 FP16 의 공 위치는 FP32 와 판정이 모두 같았지만, 그 측정은 실험용 GPU 에서 경기 한 편의 388프레임이었습니다. 운영에서 켜려면 운영 GPU 와 여러 경기·열화 조건에서 다시 확인해야 합니다.
5. 아직 못 잰 칸
- 폰 안의 시간: 카메라 잡기, 줄이기, JPEG 인코딩, 그리기. 기종마다 다를 것입니다.
- 인터넷 구간과 웹 서버 중계를 따로 뗀 지연. 지금의 끝단 값은 이 둘을 합쳐서만 잽니다.
- 운영 GPU 에서의 FP16·컴파일 효과와 정확도.
- 공 모델을 폰 안에서 돌렸을 때의 속도(7편).
6. 시리즈를 마치며
이 시리즈에서 가장 자주 나온 문장은 「재 보니 예상과 달랐다」 였습니다. 곱셈을 8배 줄였는데 1.6배 빨라졌고(4편), 묶으면 빨라질 줄 알았던 배치는 이 GPU 에서 오히려 느렸고(6편), 정밀도를 반으로 줄인 것보다 JPEG 압축이 공 위치를 더 많이 흔들었습니다(2편). 그리고 사용자가 느끼는 지연은 모델이 아니라 판정 규칙의 기다림이 정했습니다(이 글). 논문과 문서는 방향을 알려 주지만, 숫자는 자기 모델·자기 기기·자기 사용 방식에서 재야 나옵니다.
티티 한마디. 제가 공을 찾는 데는 15ms 면 되는데, 점수판이 바뀌기까지는 0.8초쯤 걸려요. 공이 진짜 떨어졌는지 잠깐 지켜보거든요. 서두르다 틀리는 것보다 낫잖아요!
참고 문헌
- 우리 측정: 이 시리즈 1–7편의 실측(원자료는 저장소 밖 연구 기록), 저장소
docs/tt/PERFORMANCE.md2.9.8·2.12·2.14·4.1·4.2 - TT Score 모델 해부 시리즈: README
- Li, M., Wang, Y.-X., Ramanan, D. (2020). Towards Streaming Perception. ECCV 2020. https://arxiv.org/abs/2005.10420