저는 CPU에서 Parakeet 음성-텍스트 변환(Speech-to-Text, STT) 속도를 높이는 작업을 시작했습니다. GPU 데모가 아닙니다. 실제 기준점(Baseline)을 설정하고 유지 관문(Keep gate)을 만드는 작업입니다. 저는 모든 ORT 플래그를 일일이 수동으로 관리하고 싶지 않았습니다. 그래서 Grok 4.5를 모델로 사용하는 Neo(저희의 자율 AI 엔지니어링 에이전트)에게 이 문제를 맡기고, 자동 연구(Autoresearch) 스타일의 루프를 요청했습니다: 먼저 프로파일링(Profile)을 수행하고, 주요 RTF(Real-Time Factor) 지표를 고정하며, ≥5%의 유지 관문을 설정하고, 노이즈는 버리며, 품질이 유지될 때만 동결(Freeze)하도록 했습니다.

설정:

• 모델: nvidia/parakeet-tdt-0.6b-v3 (INT8 ONNX 형식)
• 기준점(Baseline): istupakov dynamic INT8 pack
• 런타임(Runtime): ONNX Runtime CPU EP
• 주요 호스트: AMD EPYC 9V74, 8 vCPU
• 주요 지표: medium_15s + long_30s의 기하 평균(Geo-mean) RTF

루프를 통해 발견한 사항:

1. 인코더(Encoder)가 전체 실행 시간(Wall time)의 약 98%를 차지했습니다. 프론트엔드(Frontend)와 디코더(Decoder)는 노이즈 수준이었습니다.
2. 대부분의 런타임 노브(Knobs)는 유지 관문을 통과하지 못했습니다. 스레드(Threads), 아레나(Arenas), 오프라인 ORT 최적화(Offline ORT optimize), RTF를 위한 청킹(Chunking-for-RTF) 등이 해당됩니다. 일부 잔여 3-5%의 변화는 동결할 만한 것이 아닌 노이즈처럼 보였습니다.
3. 최종적으로 유지된 것은 인코더에 대한 정적 QDQ MinMax per-channel 방식이었습니다.
4. EPYC에서 주요 RTF는 0.038156(~26.2배)에서 0.018432(~54.3배)로 개선되었습니다. 이는 RTF가 약 51.7% 낮아진 것이며, Hub dynamic INT8 대비 처리량(Throughput)이 약 2.1배 향상된 것입니다.
5. 동일한 팩(Packs)은 30초 단위 청킹을 사용한 약 28분 분량의 음성 테스트 시 제 Mac에서도 약 1.4배의 성능 향상을 보였습니다. 따라서 단일 호스트에서만 발생한 우연은 아닙니다.

소규모 영어 데이터셋에서의 품질:

• 절대적 JFK WER(Word Error Rate): 두 설정 모두 0.0
• 기준점 대비 쌍별 평균(Pairwise mean) WER: ~0.09
• 완전한 다국어 제품군(Multilingual suite)은 아닙니다. 이 점은 주의 사항으로 간주하십시오.

알아둘 만한 막다른 길(Dead ends):

• 이 FastConformer 그래프에서 QOperator는 실패했습니다.
• 가변 길이 멜(Variable-length mels)에서 백분위수 보정(Percentile calib)이 폭주했습니다.
• 주요 호스트에서 OpenVINO EP를 사용할 수 없었습니다.
• 긴 몇 분 단위의 오디오는 전체 파일에 대해 OOM(Out of Memory)이 발생할 수 있습니다. CLI 청킹이 도움이 되지만, 이는 OOM 경로이지 제가 달성한 동결된 단기/중기 RTF 승리 모델과는 다릅니다.

저는 제품에 대한 결정(동결 여부, 품질 기준, 게시 여부 등)을 내렸습니다. 에이전트는 반복적인 작업(Grind)을 처리했습니다. 저는 판단을 담당했습니다.

참고: 코드 / 스크립트 / 장부 및 모델 가중치는 아래 댓글에 있습니다. 최적화 사다리(Ladder)에 대한 질문은 언제든 환영합니다.