fix: 서버 AI 경로 2세션 FPS 저하 원인 확인

작업 내용

최신 부하 측정 결과 2세션 수신 FPS 21.86으로 25 FPS 기준 미달, 4세션 이후 단계 미실행
마이그레이션 시점 측정은 8세션까지 약 30 FPS, RTT 평균 14.3ms
최신 측정 서버 처리 지연 평균 38.22ms로 프레임 예산 33.3ms 초과
세션당 AI 요청 1건 동기 처리 구조로 AI 왕복 지연이 FPS 상한을 결정
같은 GPU 서버 10-10 실방송 AI gRPC p50 19.8ms, 처리 fps 28.6 정상 기록
의심 원인 1. AI 블러 기본 DEFAULT_PIXEL_SIZE 2에서 1 변경
근거: innolive-ai 1ea3c6c(10-03) service/mosaic.py 변경, 667c0be(10-12)로 main 반영, 커밋 메시지에 변경 이유 없음
근거: v6 모델 기준 pixel 1에서 2세션 22.83 FPS·37.68ms, pixel 2에서 29.76 FPS·27.28ms
근거: v7 모델 기준 pixel 1에서 2세션 21.86 FPS·38.22ms, pixel 2에서 28.95 FPS·29.36ms
실제 원인인가: 맞음, 2세션 FPS 저하의 주원인, 처리 지연 약 10ms 증가
조치: 육안 화질 차이 없음 확인 후 pixel 2 복원 수용, fix: restore-blur-pixel-size/#44 innolive-ai#45
의심 원인 2. AI 모델 v7 가중치 교체
근거: innolive-ai f4e3ab4(10-15) best.pt 6,532,054 B에서 54,461,738 B로 교체
근거: pixel 2 기준 v6 대비 v7 처리 지연 2세션 +2.1ms, 4세션 +3.4ms, 4세션 FPS 24.87에서 22.91
실제 원인인가: 부분 원인, 다세션 지연을 추가로 증가시키는 2순위 요인
의심 원인 3. 얼굴 합성 머지의 나머지 코드 변경
근거: 10-10 시점 65cac3b와 77e68d2 + pixel 2의 2세션 29.55·29.76 FPS, 4세션 25.12·24.87 FPS로 동등
실제 원인인가: 아님
의심 원인 4. 마이그레이션 시점 이후 AI 파이프라인 처리 용량 변화
근거: 10-10 시점 코드 65cac3b도 4세션 25.12 FPS·33.94ms, 8세션 16.30 FPS·58.80ms로 마이그레이션 시점 8세션 약 30 FPS 미재현
근거: 세션 증가에 따라 처리 지연 28ms, 34ms, 59ms로 증가, CPU 258%, 462%, 679%로 증가, GPU 사용률 낮음
근거: AI 미경유 bypass 모드는 8세션 30 FPS·CPU 526% 유지, 병목은 AI 경로
실제 원인인가: 맞음, 다세션 용량 저하는 10-10 이전부터 존재하는 AI 경로 처리량 한계, 워커 수 확장 효과는 재측정 대기
의심 원인 10. AI 워커 프로세스 수와 세션 배정 방식
근거: 워커 2개(GPU당 1) 기준 4세션 24.87 FPS·34.35ms, 8세션 16.30 FPS·58.80ms, 워커 4개(GPU당 2) 기준 4세션 27.28 FPS·30.66ms, 8세션 20.58 FPS·43.94ms
근거: 2세션은 워커 2개 29.76 FPS, 워커 4개 29.80 FPS로 동등, 워커 1개당 동시 스트림 수가 지연을 결정
근거: Go ai.Pool.Next()는 활성 스트림 수와 무관한 라운드로빈, 파이프라인 재시작마다 카운터 증가로 운영 2세션도 한 워커 몰림 가능
근거: v7·pixel 2 4세션 60초 워커 2개 23.21 FPS·37.35ms, 워커 4개 25.08 FPS·33.90ms
실제 원인인가: 맞음, 워커당 동시 스트림 수가 지연을 결정, 라운드로빈 편중 시 운영 2세션도 워커당 2스트림
조치: 활성 스트림 최소 워커 배정, fix: ai-least-loaded-worker/#477 #481
의심 원인 5. AI 프레임 wire format 차이
근거: raw yuv420p 전송은 9/15 추가, 마이그레이션 시점은 jpeg 전송
근거: v6·pixel 2 기준 jpeg wire 2·4·8세션 29.96·25.32·16.60 FPS, raw와 같은 수준
실제 원인인가: 아님
의심 원인 6. 측정 도구·지표 정의 차이
근거: 이전 RTT·구간 수신율과 최신 서버 처리 지연·수신 FPS의 집계 방식 상이
실제 원인인가: 확인 대기, 마이그레이션 시점 측정 조건 기록 부재
의심 원인 7. Go 서버 최근 변경
근거: fail-closed 블러(feat: fail-closed 출력을 화면 전체 블러로 전환 #463)·화면 전체 블러(feat: 화면 전체 블러 on/off 추가 #465)는 AI 실패·토글 시에만 동작, 정상 AI 경로 변경은 AnonymizationMode 필드 추가뿐
실제 원인인가: 아님, 같은 Go 서버 이미지에서 AI 워커만 바꿔 FPS 회복 확인
의심 원인 8. 네트워크·디코더 손실
근거: RTP 손실 0%, 프레임 차이 27.14%와 stale drop 27.18% 일치
실제 원인인가: 아님, 손실 전량이 처리 큐의 stale drop
의심 원인 9. 같은 서버의 vLLM 서비스 재시작 반복
근거: vllm-server.service 설정 파일 부재로 10초마다 즉시 실패, 1회 CPU 84ms
실제 원인인가: 아님, 별도 정리 대상

작업 체크리스트

완료 기준

의심 원인별 실제 원인 여부 판정 기록
AI 워커 버전별 서버 처리 지연·수신 FPS 비교표 기록
수정 반영 후 운영 워커 기준 2세션 수신 FPS 25 초과

참고

AI 워커 버전별 측정 결과 (2026-10-16)

같은 Go 서버 이미지 c6276d9·같은 측정 도구·입력 720p30.ivf, AI 워커만 테스트 포트(50061/50062)로 교체
운영 워커는 변경하지 않음, 운영 활성 세션 0에서 측정
e·b·d는 단계당 60초(2→4→8→12), a·c는 단계당 40초(2→4→8)

구성	모델	pixel	세션	수신 FPS	서버 처리 지연	stale drop	CPU
운영 `0637e9b` (10-16 측정)	v7	1	2	21.86	38.22 ms	27.18%	237%
`e` `0637e9b` 테스트 워커	v7	1	2	22.71	37.36 ms	24.41%	247%
`b` `77e68d2`	v6	1	2	22.83	37.68 ms	24.02%	253%
`d` `0637e9b`	v7	2	2	28.95	29.36 ms	3.58%	264%
`d` `0637e9b`	v7	2	4	22.91	37.71 ms	23.60%	457%
`c` `77e68d2`	v6	2	2	29.76	27.28 ms	0.87%	250%
`c` `77e68d2`	v6	2	4	24.87	34.35 ms	17.01%	461%
`a` `65cac3b` (10-10 시점)	v6	2	2	29.55	28.09 ms	1.54%	258%
`a` `65cac3b` (10-10 시점)	v6	2	4	25.12	33.94 ms	16.20%	462%
`a` `65cac3b` (10-10 시점)	v6	2	8	16.30	58.80 ms	45.67%	679%

e 테스트 워커 대조 측정이 운영 워커 측정값을 재현, 테스트 워커 교체 방식 유효
a·c 첫 실행은 테스트 포트 TIME_WAIT 충돌로 실패, 구성별 포트 분리 후 재측정
pixel 1→2: 2세션 처리 지연 약 10ms 감소, 25 FPS 기준 회복
v6→v7 (pixel 2): 처리 지연 2세션 +2.1ms, 4세션 +3.4ms
10-10 시점 코드도 4세션 경계, 8세션 16.30 FPS로 마이그레이션 시점 8세션 약 30 FPS 미재현

다세션 저하 원인 분리 측정 (2026-10-16)

기준 AI 워커 77e68d2 v6·pixel 2, 단계 2→4→8, 단계당 40초, 같은 Go 서버 이미지 c6276d9

구성	바꾼 값	세션	수신 FPS	서버 처리 지연	stale drop	CPU
`g`	`AI_PRIVACY_MODE=bypass`	2	30.00	0.00 ms	미수집	143%
`g`	`AI_PRIVACY_MODE=bypass`	4	30.00	0.00 ms	미수집	249%
`g`	`AI_PRIVACY_MODE=bypass`	8	30.00	0.00 ms	미수집	526%
`h`	`AI_FRAME_WIRE_FORMAT=jpeg`	2	29.96	26.09 ms	미수집	251%
`h`	`AI_FRAME_WIRE_FORMAT=jpeg`	4	25.32	33.17 ms	15.46%	469%
`h`	`AI_FRAME_WIRE_FORMAT=jpeg`	8	16.60	56.19 ms	44.68%	718%
`i`	AI 워커 4개 (GPU당 2)	2	30.06	미수집	미수집	255%

AI 미경유 시 Go 서버·FFmpeg·부하 클라이언트는 8세션 30 FPS 유지, 다세션 병목은 AI 경로
jpeg wire는 raw(c·a)와 같은 수준, wire format은 원인 아님
i는 2세션 측정 중 운영 활성 세션 발생으로 측정 도구가 중단, 재측정 대기

AI 워커 수 확장 측정 (2026-10-16)

기준 AI 워커 77e68d2 v6·pixel 2, 단계 2→4→8, 단계당 40초

구성	세션	수신 FPS	서버 처리 지연	stale drop	CPU
워커 2개 (`c`·`a`)	4	24.87·25.12	34.35·33.94 ms	17.01%·16.20%	461%·462%
워커 2개 (`a`)	8	16.30	58.80 ms	45.67%	679%
워커 4개 (`i`)	2	29.80	27.22 ms	미수집	255%
워커 4개 (`i`)	4	27.28	30.66 ms	8.95%	529%
워커 4개 (`i`)	8	20.58	43.94 ms	31.40%	1,005%

워커를 GPU당 2개로 늘리면 8세션 16.30에서 20.58 FPS, 지연 58.80에서 43.94ms로 개선, 기준 25 FPS 미달
8세션 CPU 1,005%, bypass 8세션 526% 대비 AI 경로가 프레임당 CPU 비용의 큰 몫 차지, GPU 사용률은 낮음
워커 프로세스 단위 직렬 처리와 프레임당 CPU 처리 비용이 함께 다세션 병목으로 작용

4세션 60초 워커 수 비교 (2026-10-16)

기준 AI 워커 77e68d2 v6·pixel 2, 4세션 단일 단계 60초

구성	측정	수신 FPS	서버 처리 지연	stale drop	CPU
워커 2개 (`j`)	60초 완료	24.75	34.25 ms	17.59%	447%
워커 4개 (`k`)	운영 세션 발생으로 약 28초에서 중단	26.06	미수집	미수집	538%
워커 4개 (`i`, 40초)	40초 완료	27.28	30.66 ms	8.95%	529%

워커 2개 4세션 결과는 40초 측정(24.87 FPS·34.35ms)을 재현
워커 4개는 부분 측정과 40초 측정 모두 워커 2개보다 높음, 워커 1개당 동시 스트림 수가 4세션 지연에 영향
운영 Go 서버 라운드로빈 배정 특성상 운영 2세션도 한 워커에 몰리면 이 4세션·워커 2개 조건과 같은 부하
이후 측정 기준은 운영 구성 v7·pixel 2로 변경

운영 구성 4세션 60초 워커 수 비교 (2026-10-16)

기준 AI 워커 0637e9b v7·pixel 2(innolive-ai#45 반영 후 운영 구성), 4세션 단일 단계 60초, 운영 활성 세션 0

구성	수신 FPS	서버 처리 지연	stale drop	CPU
워커 2개 (GPU당 1, 현재 운영)	23.21	37.35 ms	22.75%	445%
워커 4개 (GPU당 2)	25.08	33.90 ms	16.34%	531%

워커 4개에서 수신 FPS +1.87, 처리 지연 -3.45ms, stale drop -6.41%p, CPU +86%p
워커 수 확장은 실효과 확인, 4세션도 25 FPS 경계 수준으로 단독 해결책 아님
v6·pixel 2 워커 2개 4세션 24.75 FPS 대비 v7은 -1.54 FPS·+3.1ms, v7 모델 추가 비용 재확인
운영 라운드로빈 배정 시 동시 2세션이 한 워커에 몰리면 워커 2개 4세션과 같은 워커당 부하로 23 FPS 수준 예상

PR fix: ai-least-loaded-worker/#477 #481 세션 교체 실측: 동시 2세션에서 main 라운드로빈 27.35·27.29 FPS·30.24ms·stale 8.41%, PR 활성 최소 배정 29.63·29.28 FPS·27.49ms·stale 1.74%
상세 결과는 fix: ai-least-loaded-worker/#477 #481 댓글 기록

PR fix: ai-least-loaded-worker/#477 #481 교대 반복 실측 3회씩: 동시 2세션 C 수신 FPS 평균 main 27.02 → PR 29.30, 처리 지연 30.65 → 27.79ms, stale drop 9.50 → 2.34%, 값 범위 비중첩
상세 결과는 fix: ai-least-loaded-worker/#477 #481 댓글 기록

merge: fix/ai-least-loaded-worker/#477

AI 워커 동시 처리 구조 확인 (innolive-ai `0637e9b` 소스)

추론·추적은 워커 프로세스당 단일 스레드 1줄, service/runtime.py:235 ThreadPoolExecutor(max_workers=1)와 asyncio.Lock
블러 합성도 워커당 단일 스레드, ai_processor_server.py:188 max_workers=1, 동시 처리 상한 MOSAIC_MAX_INFLIGHT = 2(91행)
운영 env의 AI_ENCODE_WORKERS·AI_BATCH_WAIT_MS·AI_CONFIDENCE는 코드에서 읽지 않는 값, 변경 효과 없음
ultralytics가 OMP_NUM_THREADS=1·cv2.setNumThreads(0) 고정, 추적기 gmc_method: sparseOptFlow가 매 프레임 CPU 광류 계산
워커당 직렬 처리 구조가 GPU 유휴·CPU 증가·세션 수 비례 지연 증가와 워커 수 확장 시 개선 결과를 설명
PR fix: ai-least-loaded-worker/#477 #481 병합 완료(73f04af), 배포 후 innolive_ai_target_active_streams 균등 배정 확인 대기

Navigation Menu

Repository navigation

fix: 서버 AI 경로 2세션 FPS 저하 원인 확인 #477

작업 내용

작업 체크리스트

완료 기준

참고

AI 워커 버전별 측정 결과 (2026-10-16)

다세션 저하 원인 분리 측정 (2026-10-16)

AI 워커 수 확장 측정 (2026-10-16)

4세션 60초 워커 수 비교 (2026-10-16)

운영 구성 4세션 60초 워커 수 비교 (2026-10-16)

AI 워커 동시 처리 구조 확인 (innolive-ai `0637e9b` 소스)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

fix: 서버 AI 경로 2세션 FPS 저하 원인 확인 #477

Description

작업 내용

작업 체크리스트

완료 기준

참고

Activity

finefinee commented on Oct 16, 2026

AI 워커 버전별 측정 결과 (2026-10-16)

finefinee commented on Oct 16, 2026

다세션 저하 원인 분리 측정 (2026-10-16)

finefinee commented on Oct 16, 2026

AI 워커 수 확장 측정 (2026-10-16)

finefinee commented on Oct 16, 2026

4세션 60초 워커 수 비교 (2026-10-16)

finefinee commented on Oct 16, 2026

운영 구성 4세션 60초 워커 수 비교 (2026-10-16)

finefinee commented on Oct 16, 2026

finefinee commented on Oct 16, 2026

finefinee commented on Oct 16, 2026

AI 워커 동시 처리 구조 확인 (innolive-ai 0637e9b 소스)

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

AI 워커 동시 처리 구조 확인 (innolive-ai `0637e9b` 소스)