로컬 음악 생성 속도와 하드웨어 비교: RTF를 제대로 읽는 법

텍스트에서 짧은 효과음을 만드는 모델, 가사와 보컬이 있는 노래를 만드는 모델, 이미 있는 멜로디를 확장하는 모델은 맡은 일이 다릅니다. 생성 길이와 조건도 다르므로 처리 시간만 나열하면 오해하기 쉽습니다. 비교 전에 원하는 작업, 출력 길이, 스테레오 여부, 보컬·가사 포함 여부를 고정하세요.

예를 들어 ‘30초짜리 보컬 없는 신스팝 루프’를 만들고 싶다면, 먼저 모든 후보가 텍스트 조건의 반주를 생성할 수 있는지 확인합니다. 가사 노래 전용 경로와 효과음 생성 경로를 억지로 한 줄에 세우지 마세요. 공통 작업을 지원하는 모델끼리만 나란히 재고, 지원하지 않는 후보는 속도표에서 제외하는 이유를 적으면 구매 선택이 더 명확해집니다.

비교 단위도 결과물에 맞추세요. 곡 생성은 한 곡에 걸린 시간과 실제 길이를 기록하고, 긴 노래를 여러 번 이어 만드는 방식이면 각 세그먼트 수와 이어 붙이기 시간을 함께 적습니다. 배치를 키우면 여러 곡을 한 번에 만드는 처리량³이 달라질 수 있지만, 한 곡이 빨라졌다는 뜻은 아닙니다. 단일 요청 지연시간과 시간당 처리량을 서로 다른 지표로 보고하세요.

RTF(real-time factor)는 생성에 걸린 벽시계 시간 ÷ 출력 음성의 재생 시간입니다. 60초 오디오를 30초에 만들면 RTF 0.5, 즉 실시간의 2배 속도입니다. 120초가 걸리면 RTF 2이며 실시간보다 느립니다. 어떤 저장소는 ‘34배’처럼 역수인 실시간 배수를 RTF라고 부르기도 하므로, 정의와 단위를 먼저 읽고 필요하면 원시 초 단위로 다시 계산하세요.

첫 실행에는 체크포인트⁴ 읽기, 메모리 할당, 컴파일이나 커널 준비가 들어갈 수 있습니다. 이미 적재된 뒤의 연속 생성 시간은 이 비용을 빼므로 새로 앱을 켜는 사용자의 대기 시간과 다릅니다. 첫 요청(콜드 스타트)과 준비 완료 후 요청(웜 런)을 각각 기록하고, 전체 사용자 대기시간도 별도로 남기세요.

아래는 공식 저장소나 모델 카드에 나온 수치입니다. 다만 공개 문구에도 증거의 수준 차이가 있습니다. 구버전 ACE-Step 표와 ACE-Step 1.5 README의 속도 주장은 서로 다른 모델 버전이며, 후자는 프로파일러로 재현한 기기별 결과표가 아닙니다. 빈칸은 속도가 느리다는 뜻이 아니라 이 조사에서 조건을 확인할 수 있는 숫자를 찾지 못했다는 뜻입니다.

음악 생성에는 텍스트·가사 계획 모델, 오디오 토큰⁵ 생성이나 확산 모델⁶, 보코더 또는 VAE⁷ 디코더, 저장·변환 단계가 들어갈 수 있습니다. end-to-end 시간은 사용자가 기다린 총 시간이고, 각 단계 시간은 병목을 찾기 위한 진단값입니다. ACE-Step 1.5 공식 프로파일러는 LLM⁸ 계획, DiT⁹ 확산, VAE 디코딩, 오디오 저장과 전체 벽시계 시간을 나눠 잴 수 있습니다.

YuE2 공식 모델 카드는 세 가지 생성 모드를 RTX 4090에서 비교합니다. RTX 4090 값은 모델 준비 후 32회 생성한 평균이며, GPU 메모리는 NVML 기준 전체 실행 피크입니다.

출력 초는 각 실행 결과의 오디오 길이이고 생성 초는 모델 카드의 동기화된 pipeline¹⁰ 호출 시간입니다. 행별 RTF는 생성 초 ÷ 오디오 초로 계산한 참고값입니다.

카드 설명상 최초 입력 경로 해석과 결과 저장은 시간에서 빠져 있으므로 앱 실행부터 저장까지의 대기시간으로 읽으면 안 됩니다.

같은 프롬프트와 가사, 같은 출력 길이·샘플레이트·채널, 같은 품질 관련 설정을 사용하고 모델 체크포인트·코드 버전·백엔드·정밀도·스텝 수를 기록합니다. 장치 이름뿐 아니라 운영체제와 드라이버/프레임워크 버전도 남기세요. 첫 실행과 워밍업 후 반복을 분리하고 최소 여러 번 재서 중앙값과 범위를 기록합니다. 실패, OOM, 잘린 출력도 숨기지 않습니다.

실제로는 작은 기록표 하나면 시작할 수 있습니다. 예를 들어 ‘모델/리비전, 장치, 백엔드, 정밀도, 길이, 스텝, 첫 실행초, 웜업 뒤 1~5회 초, 출력 실제 길이, peak 메모리, 상태’를 열로 둡니다. 같은 프롬프트와 설정을 그대로 복사해 모델별 요청을 만들고, 각 결과 파일과 로그에 같은 실험 ID를 붙이세요. 설정을 바꾼 실행은 새 행으로 분리합니다.

예를 들어 한 번은 첫 실행이 42초, 다음 다섯 번의 중앙값이 18초, 출력 길이가 30초였다고 합시다. 웜 생성의 conventional RTF는 18÷30=0.60, 실시간 배수는 약 1.67×입니다.

첫 실행까지 포함한 새 실행 대기는 42초로 따로 설명합니다. 원본 표기가 1.67×라면 ‘RTF’라는 말만 옮기지 말고 이처럼 무엇을 나눈 값인지 표기하면 독자가 속도 방향을 뒤집지 않습니다.

비교 뒤에는 숫자만으로 승자를 정하지 말고 질문을 나눠 해석하세요. 매번 앱을 켜고 한 곡을 만들면 첫 실행 대기가 중요하고, 하루 종일 서버를 켜두면 웜 런 중앙값과 처리량이 더 중요할 수 있습니다.

긴 결과에서 DiT나 오디오 토큰 생성이 지배적인지, 짧은 결과에서 계획·로딩 고정비가 크게 보이는지도 단계별 시간으로 살펴봅니다. 음질 설정이나 출력 길이를 낮춰 얻은 빠른 숫자는 원래 설정 결과와 별도 비교로 표시합니다.

음악 모델에서 텍스트 계획 단계만 LLM일 수 있으며 전체 오디오는 확산 반복, 오디오 토큰 자동회귀, 디코딩에서 만들어집니다. 초당 텍스트 토큰 수가 빠른 장치라도 다른 단계가 느릴 수 있습니다. 오디오 생성에서는 초당 오디오 프레임¹¹·토큰, 확산 스텝, 전체 오디오 길이와 end-to-end 초를 함께 봐야 합니다.

NVIDIA CUDA¹², Apple MPS, MLX¹³는 서로 바꿔 끼울 수 있는 이름이 아니라 각 프로젝트가 실제로 구현·지원해야 하는 실행 경로입니다. ACE-Step 1.5 문서는 CUDA/MPS와 LLM의 vLLM·PyTorch¹⁴·MLX 경로를 안내하지만, 모델 구성별 성능은 직접 확인해야 합니다.

YuE2 문서의 기준은 Linux와 24GB BF16¹⁵ NVIDIA GPU입니다. HeartMuLa 공식 예제는 CUDA를 기본으로 합니다.

Mac의 통합 메모리¹⁶나 RTX 5090의 사양만으로 미지원 경로를 해결하거나 처리량을 추정할 수는 없습니다.

가사 선명도, 프롬프트 반영, 곡 구조, 음색은 하나의 보편 점수로 정리하기 어렵습니다. 짧은 샘플을 직접 들어보고 원하는 작업에 맞춰 판단하세요. 모델 가중치와 코드의 라이선스가 다를 수 있으므로 배포·상업 이용 전 해당 버전의 약관과 학습 데이터 안내를 확인하고, 권리자가 허락하지 않은 가사·음원이나 유명인의 목소리를 입력·복제하지 않도록 주의하세요.