지금 구조에서 지연(latency)이 발생하는 지점은 크게 ① 오디오 청크 단위가 크다 ② 디스크 I/O 왕복 ③ ASR가 청크 전체를 한 번에 처리 ④ LLM 번역이 순차 대기 이렇게 네 곳입니다. 각각을 손볼 수 있습니다.
1. 오디오 윈도우/스텝을 줄이기
지금은 10초 윈도우, 8초 스텝이라 최소 8~10초의 지연이 구조적으로 깔려 있습니다.
config.py의WINDOW_SECONDS를 10 → 3~4초,OVERLAP_SECONDS를 2 → 1초 정도로 줄이면 체감 지연이 크게 줄어듭니다.- 대신 청크가 짧아지면 ASR 정확도가 떨어질 수 있으니(문맥 부족), LLM 번역 프롬프트의
previous_translation컨텍스트 활용을 더 강화해서 보완해야 합니다.
2. 고정 시간 윈도우 대신 VAD(음성 구간 검출) 기반 청킹
지금처럼 무조건 N초마다 자르는 대신, webrtcvad나 silero-vad 같은 걸로 침묵 구간에서 끊기로 바꾸면 문장 단위로 자연스럽게 분절되어 번역 품질과 반응속도가 동시에 좋아집니다. recorder.py의 _check_buffer 로직을 시간 기반 → VAD 기반으로 교체하는 방향입니다.
3. 디스크 왕복 없애기
recorder.py가 WAV로 저장(sf.write) → asr.py가 다시 읽는(sf.read) 구조인데, 이 파일 I/O가 불필요한 지연입니다. numpy 배열을 큐에 그대로 넣고 asr.transcribe()가 배열을 직접 받도록 바꾸면 저장/로드 시간을 아낄 수 있습니다.
4. ASR을 스트리밍 방식으로
Wav2Vec2는 원래 청크 전체를 한 번에 forward하는 구조라 완전한 스트리밍엔 한계가 있습니다. 더 실시간에 가깝게 하려면:
- 부분 청크 추론: 청크가 다 차기 전에도 지금까지 쌓인 오디오로 중간 추론을 돌려서 먼저 화면에 띄우고, 청크가 완성되면 최종본으로 교체
- 또는 스트리밍 특화 모델(Whisper streaming 변형, RNNT 계열)로 교체
5. GPU 활용도 점검
지금 코드가 mps 아니면 무조건 cpu로 가는데, CUDA(NVIDIA GPU) 체크가 빠져 있습니다.
if torch.cuda.is_available():
self.device = torch.device("cuda")
elif torch.backends.mps.is_available():
self.device = torch.device("mps")
else:
self.device = torch.device("cpu")환경이 NVIDIA GPU라면 이 부분만 고쳐도 ASR 속도가 크게 개선됩니다.
6. LLM 번역 latency 줄이기
translator.py는llm.invoke()로 응답 전체를 기다린 뒤 출력합니다. 스트리밍 응답(llm.stream())으로 바꿔서 토큰이 생성되는 대로 출력하면 체감 지연이 줄어듭니다.- 로컬 LLM 모델 자체를 더 작고 빠른 모델(예: 더 작은 파라미터의 Gemma/Qwen)로 바꾸는 것도 직접적인 효과가 있습니다.
temperature는 이미 0.1로 낮게 설정되어 있어 이 부분은 괜찮습니다.
7. 큐/스레드 병목 확인
현재는 ASR 워커 1개, 번역 워커 1개로 고정되어 있습니다. ASR과 LLM 중 어느 쪽이 병목인지 로그의 asr_time/llm_time을 비교해서, 병목인 쪽의 워커 스레드 수를 늘리는 것도 효과적입니다(단, GPU 메모리·로컬 LLM 서버 동시 요청 처리량 고려 필요).
우선순위 추천: 체감 효과가 가장 큰 건 ① 윈도우/스텝 축소와 ④ VAD 기반 청킹입니다. 여기에 ③ 디스크 I/O 제거, ⑥ LLM 스트리밍 출력을 더하면 즉각적인 개선을 느낄 수 있을 것입니다.
