내 머신에서 벤치마크
HayaKoe 가 내 하드웨어에서 얼마나 빠른지 직접 재보는 페이지입니다.
레포지토리를 클론해 둔 상태라면 커맨드 한 줄로 끝납니다.
왜 직접 재나요?
TTS 추론 속도는 CPU 세대·메모리 대역폭·ONNX Runtime 버전·백그라운드 부하에 크게 의존합니다.
문서는 참고 정도만 하고, 직접 내 PC 에서 돌려보는 쪽이 훨씬 정확합니다.
값을 한 번 측정해 놓으면, 어디에 어떻게 쓸 수 있을지 결정할 때도 큰 도움이 됩니다.
용어 — 배속
HayaKoe 는 성능 지표로 배속 (speed factor) 을 씁니다.
배속 = 생성된 오디오 길이(초) ÷ 추론에 걸린 시간(초)1.0x 이상이 나왔을 때 준실시간이라고 느낄 수 있습니다.
물론 빠르면 빠를수록 더 좋습니다.
예를 들어 10초짜리 음성을 만든다고 생각해 보세요.
1.0x— 꼭 10초를 기다려야 음성을 다 받습니다5.0x— 2초면 됩니다10.0x— 1초면 됩니다
벤치마크 실행
레포지토리에 포함된 dev-tools 의 벤치마크 CLI 를 쓰시면 됩니다.
uv run poe cli benchmark실행하면 인터랙티브 메뉴에서 CPU (ONNX), GPU (torch.compile), CPU + GPU 중 하나를 고를 수 있습니다.
워밍업 2 회 + 측정 5 회로 짧음·중간·김 세 가지 길이의 텍스트를 자동으로 돌려주고, 결과를 표로 정리해 보여줍니다.
측정이 끝나면 같은 내용이 HTML 레포트로도 benchmarks/ 아래에 저장되고, 브라우저로 바로 열어줍니다.
결과 읽는 법
CPU + GPU 를 함께 돌렸을 때 터미널에 대략 이런 형태로 찍힙니다.
숫자는 머신마다 다릅니다 (아래는 라이젠 3950X / RTX 3080 조합에서, 다른 작업을 돌리던 중에 겸사겸사 측정된 값입니다).
배속 = 오디오 길이 ÷ 추론 시간 (높을수록 빠름)
예: 10.0x → 1초 분량의 음성을 0.1초 만에 생성
벤치마크 결과
┏━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━┓
┃ 백엔드 ┃ 텍스트 ┃ 추론 시간 ┃ 오디오 길이 ┃ 배속 ┃
┡━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━┩
│ ONNX (CPU) │ 짧음 │ 0.393s │ 0.8s │ 2.1x │
│ ONNX (CPU) │ 중간 │ 1.297s │ 4.1s │ 3.2x │
│ ONNX (CPU) │ 김 │ 3.318s │ 11.0s │ 3.3x │
│ torch.compile (CUDA) │ 짧음 │ 0.182s │ 0.9s │ 4.7x │
│ torch.compile (CUDA) │ 중간 │ 0.547s │ 4.9s │ 8.9x │
│ torch.compile (CUDA) │ 김 │ 0.747s │ 12.4s │ 16.6x │
└──────────────────────┴────────┴───────────┴─────────────┴───────┘
벤치마크 완료!
benchmarks/benchmark_20260414_211131.html
? 브라우저에서 열시겠습니까? Yes한 문장이 길수록 배속이 잘 나옵니다
모델 호출마다 고정 오버헤드가 있어서, 긴 문장일수록 그 오버헤드가 더 잘 분산됩니다.
단, HayaKoe 는 긴 텍스트를 내부적으로 문장 단위로 쪼개 돌리기 때문에 문장이 많다고 무조건 빨라지진 않습니다.
워밍업은 반드시 제외
첫 호출에는 ONNX 세션 초기화나 (GPU 라면) torch.compile 그래프 컴파일 시간이 섞여 있습니다.
CLI 가 WARMUP = 2 로 앞 두 번을 버리는 이유입니다.
다른 프로세스가 없는 상태에서
브라우저·빌드·백그라운드 다운로드를 정리한 뒤에 재야 값이 안정적입니다.
여러 번 돌려서 분산 확인
같은 벤치마크를 2~3 회 돌려 보세요.
배속이 몇 % 이내로 재현되면 그 값을 좀 더 신뢰할 수 있습니다.
편차가 크면 다른 프로그램이 자원을 쓰고 있을 수도 있습니다.
라즈베리파이 4B 에서는 어떨까
HayaKoe 는 arm64 환경에서도 그대로 동작합니다. 참고로 Raspberry Pi 4B 에서 같은 벤치마크를 돌린 결과는 다음과 같습니다.
- Linux 6.8 · aarch64 · Python 3.10 · ONNX Runtime 1.23.2
| 텍스트 | 추론 시간 | 오디오 길이 | 배속 |
|---|---|---|---|
| 짧음 | 3.169s | 0.8s | 0.3x |
| 중간 | 13.042s | 4.1s | 0.3x |
| 김 | 35.119s | 10.8s | 0.3x |
대화형 UI 에 실시간으로 쓰기엔 빠듯한 수준 (0.3x, 약 3 배 느림) 이지만, 오프라인 배치 합성이나 개인 프로젝트용으로는 그대로 쓸 수 있습니다.
첫 실행 모델 다운로드는 오래 걸릴 수 있습니다 (~10 분)
라즈베리파이처럼 SD 카드 I/O · 네트워크가 느린 환경에서는 BERT · Synthesizer · 스타일 벡터 가중치를 HuggingFace 에서 받는 데만 10 분 가까이 걸릴 수 있습니다.
한 번 받아 두면 hayakoe_cache/ 에 캐시되어 다음 실행부터는 바로 뜹니다.
로그에 뜨는 ORT / HF 경고는 무시해도 됩니다
실행 중에 다음 두 경고가 섞여 찍힐 수 있습니다. 둘 다 CPU 추론 동작·결과에는 영향이 없으니 그대로 진행하세요.
Warning: You are sending unauthenticated requests to the HF Hub. ...
[W:onnxruntime:Default, device_discovery.cc:...] GPU device discovery failed: ...- HF 익명 요청 경고 — HuggingFace 에 토큰 없이 요청한다는 알림. 다운로드 속도·레이트 리미트에만 영향을 줍니다.
HF_TOKEN환경변수를 설정하면 사라집니다. - ORT GPU 탐색 실패 경고 — ONNX Runtime 이 시스템에 GPU 가 있는지 훑다가 실패한 것. 라즈베리파이처럼 GPU 가 없는 환경에서는 정상 동작이고, CPU 추론에 아무 영향이 없습니다.
배속이 1.0x 근처라면
CPU 로 측정했는데 배속이 1.0x 에 가까우면, 실서비스에서 실시간으로 쓰기엔 빠듯합니다.
몇 가지 선택지가 있습니다.
- GPU 로 전환 — 가장 확실한 해결책입니다.
- 문장 단위 스트리밍 — 대화형 UI 라면 전체 합성을 기다리지 않고 첫 문장부터 흘려보내는 방법이 있습니다 (문장 단위 스트리밍).