audio.cpp 0.9.1: PocketTTS CPU…

audio.cpp v0.9.1이 10월 7일(UTC) 릴리스됐다. 여러 변경 가운데 PocketTTS의 CPU 경로를 좁게 겨냥한 최적화가 들어 있다.

기존 CPU Mimi 업샘플러는 대각 가중치를 32MiB 밀집 표현으로 펼쳐 썼다. 이번 변경은 프레임워크에 이미 있던 64KiB depthwise 모듈을 쓰고, 스트리밍 오버랩·세션 소유 그래프 캐시·기존 GPU 경로는 그대로 둔다.

바뀐 파일은 PocketTTS 소스 두 개뿐이며 프레임워크, ggml, 인터페이스 변경은 없다.

밀집 전개 대신 depthwise 모듈을 쓰는 이유

대각 가중치는 채널마다 독립적인 연산이라, 밀집 행렬로 펼치면 대부분이 0인 표현을 들고 다니는 셈이다. depthwise(채널별) 모듈은 그 구조를 그대로 살린다.

모델을 줄이거나 출력 품질을 낮춘 개선과는 성격이 다르다. GPU 배포가 이 CPU 전용 변경에서 이득을 기대할 근거도 없다.

스트리밍 음성에서는 첫 오디오가 나오는 시간과 발화 전체를 끝내는 시간이 서로 다른 질문이다. 정상 상태 디코더 수치는 국소 병목을 짚어주지만, 새 세션의 첫 응답 속도까지 말해주지는 않는다.

실시간 계수(RTF)는 처리 시간을 오디오 길이로 나눈 값으로, 낮을수록 빠르다. 같은 Debug 빌드와 요청에서 4스레드 디코더 프레임 시간은 30.50ms에서 10.11ms로, 세션 RTF는 0.461에서 0.207로 내려갔다.

2스레드에서는 34.98ms에서 14.58ms, 세션 RTF는 0.557에서 0.302였다. 프로세스 전체 CPU 최대 RSS는 663.5MiB에서 603.9MiB로 줄었다.

프레임 중앙값은 처음 두 번의 호출을 빼고 계산했고, 세션 수치는 그래프 초기화를 포함한다. CPU·CUDA·Vulkan에서 스트리밍과 연속 요청 출력이 바이트 단위로 같았고, Metal과 HIP은 실행하지 않았다.

모두 메인테이너 측정이며 독립 재현은 아니다.

같은 릴리스의 HTDemucs 변경은 모든 곳에서 빨라졌다는 요약이 맞지 않음을 보여준다. 8초 입력, 8스레드의 웜 요청에서 CPU는 5.056초에서 5.407초로 약 7% 느려졌다.

같은 조건의 Vulkan(RTX 5090)은 248ms에서 148ms로 약 40% 빨라졌다.

기존 CPU 구현은 HTDemucs가 시간 프레임에 쓰는 배치 차원을 무시했다. 재작성 뒤 공식 Python 대비 drums/other 코사인 유사도는 0.683/0.924에서 0.999974/0.999998로 올랐으니, 정확도가 다른 경로끼리의 시간 비교인 셈이다.

배포 판단에는 비교 조건을 그대로 맞추는 방식이 현실적이다. 같은 모델, 입력 텍스트, 스레드 수, 출력 모드를 고정하고 새 세션과 반복 요청을 나눠 기록한다.

경과 시간뿐 아니라 스트리밍 청크와 연속 요청 사이의 연속성도 확인 대상이다. 이 글에서 수행한 테스트가 아니라 대상 시스템에서 해볼 수 있는 점검이다.

릴리스 바이너리가 요구할 수 있는 AVX-512 지원 여부는 Linux 표준 도구로 먼저 확인할 수 있다.

grep -o -m1 avx512f /proc/cpuinfo

출력이 비어 있으면 릴리스가 함께 배포한 portable 빌드(예: audio-v0.9.1-bin-ubuntu-x64-cpu-portable.tar.gz)가 대상이다.

해당 CPU 단계가 싸져도 다른 단계가 요청 시간을 지배하면 애플리케이션 체감 이득은 국소 개선보다 작아진다. 반대로 큰 임시 표현을 피한 것만으로도 메모리 측면의 가치는 있어 보인다.

릴리스 노트는 GitHub 러너의 자동 CPU 감지 때문에 최근 빌드가 AVX-512를 겨냥하는 경향이 있다고 적었다. 충돌이 나면 호환 범위가 넓은 portable 버전을 쓰라고 안내한다.

호환되지 않는 실행 파일로 생긴 충돌은 모델이나 최적화 자체가 지원되지 않는다는 증거가 아니다.

이번 패치는 라이브러리 전체의 속도 배율이 아니라 PocketTTS CPU 업샘플러라는 한 경로의 비용 구조를 바로잡은 변경이다.