아이폰에서 피아노 연주를 이어 쓰는 1억 2,500만 매개변수 모델

아이폰에서 피아노 연주를 이어 쓰는 1억 2,500만 매개변수 모델

AI 뉴스 썸네일

MIDI 건반으로 몇 음을 연주하면 아이폰이 다음 연주를 실시간으로 만들어 줘요. RollTab 개발자는 14차례 실험을 거쳐 1억 2,500만 매개변수 Transformer를 iPhone 15에서 초당 약 108개 음표까지 생성하도록 다듬었어요. 모델 크기보다 음표 표현과 데이터 정제가 결과를 크게 바꾼 과정이 흥미로워요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
온디바이스 AI	1억 2,500만 매개변수 모델이 iPhone 15에서 초당 약 108개 음표를 만들어요	네트워크 없이 모바일 기기 안에서 실시간 음악 생성을 처리해요
모델 설계	음높이·시작 간격·길이·세기를 음표 하나의 복합 표현으로 묶었어요	무거운 Transformer 백본을 음표당 한 번만 실행해 지연을 줄였어요
학습 데이터	수십만 개 MIDI와 약 3억 개 음표 이벤트를 피아노 중심으로 정제했어요	데이터를 5배 늘린 실험보다 중복과 오염을 걷어낸 데이터가 더 나았어요
선호 학습	Gemini 3.5 Flash의 쌍대 비교 결과로 DPO를 적용했어요	합의된 평가 쌍을 쓴 모델이 자체 평가에서 기본 모델보다 69.05% 더 많이 선택됐어요

1. 피아노 한 음마다 Transformer를 한 번만 실행해요

MIDI는 녹음된 소리가 아니라 음높이, 건반을 누른 시점, 세기, 페달 상태 같은 이벤트를 저장해요. 이 이벤트를 `NOTE_ON`, `NOTE_OFF`, `TIME_SHIFT` 토큰으로 잘게 나누면 모델이 음 하나를 완성하는 데 여러 번 추론해야 해요. 작은 실시간 모델은 음을 끄는 토큰을 놓쳐 소리가 계속 울리는 문제도 겪었어요. 2

개발자는 최종적으로 음표 하나를 `NOTE(pitch, delta_onset, duration, velocity)` 형태로 표현했어요. 음높이와 다음 음이 시작될 때까지의 간격, 음의 길이, 세기를 한 묶음으로 다뤄요. 각 필드는 별도 임베딩과 출력 헤드를 쓰지만, 계산량이 큰 Transformer 백본은 음표마다 한 번만 지나가요. 그 결과 1억 2,500만 매개변수 모델이 iPhone 15에서 약 108 notes/sec에 도달했어요.

728x90

페달 동작도 음표 길이로 바꿨어요

서스테인 페달 이벤트를 모델이 따로 예측하게 두지 않았어요. 전처리 단계에서 페달을 밟고 있는 동안 음표의 지속 시간을 연장해 실제로 들리는 길이를 반영했어요. 같은 음을 다시 누르면 이전 음은 그 시점에서 끝나요. 명시적인 페달 동작은 사라지지만 모델이 관리해야 할 상태가 줄어들어요.

데이터 양보다 피아노에 맞는 정제가 효과가 컸어요

최종 학습 데이터는 수십만 개 MIDI 파일과 약 3억 개 음표 이벤트로 구성됐어요. 여러 악기와 트랙이 뒤섞인 파일을 줄이고, 피아노 중심 자료를 골랐어요. 조옮김이나 일정한 템포 변화에도 같은 곡을 알아볼 수 있는 지문으로 중복을 제거했어요. 같은 곡의 다른 버전이 학습용과 평가용에 나뉘지 않도록 묶어서 분할했어요.

데이터를 약 5배로 늘린 실험에서는 오히려 결과가 나빠졌어요. 잡음이 섞인 자료를 더 넣는 것보다 피아노 연속 생성에 맞는 자료를 남기는 편이 효과적이었다는 개발자의 관찰이에요. 모델 규모도 3,300만, 6,400만, 1억 2,500만 매개변수로 비교했어요. 큰 모델이 더 나았지만 6,400만과의 차이는 아주 크지 않았고, 개발자는 앱의 용량과 지연을 줄이기 위해 중간 크기 모델도 계속 조정하고 있어요. 2

음악의 정답이 하나가 아니라는 문제를 쌍대 비교로 풀었어요

다음 음표 손실만 낮다고 전체 연주가 자연스럽게 이어지는 건 아니었어요. 짧은 피아노 구절 뒤에는 음악적으로 가능한 다음 연주가 여러 개 있기 때문이에요. 반복 음형과 음높이 분포 같은 자동 지표는 명백한 실패를 찾는 데 쓸 수 있었지만, 가장 듣기 좋은 모델을 고르기에는 부족했어요.

개발자는 Gemini 3.5 Flash에 두 연주를 보여 주고 어느 쪽이 더 나은지 비교하게 했어요. 위치 편향을 줄이려고 A와 B의 순서를 뒤집은 비교도 함께 진행했어요. 처음에는 입력 구절과 자연스럽게 이어지는지보다 결과만 듣기 좋은 연주를 고르는 경향이 있었어요. 그래서 입력 구절과의 연결성, 독립적인 음악성을 나눠 평가하고 연결성 점수를 DPO의 주된 신호로 사용했어요.

평가자가 일관되게 동의한 비교 쌍만 사용한 DPO 모델은 같은 Gemini 쌍대 평가에서 사전 학습 기본 모델보다 69.05% 더 많이 선택됐어요. 이 수치는 사람 대상의 독립적인 청취 실험 결과가 아니에요. 선호 데이터를 만든 모델이 평가에도 참여했기 때문에 일반적인 음악 품질 수치로 넓혀 해석하기는 어려워요. 그래도 교차 엔트로피 손실만으로 잡지 못한 연속 생성 차이를 개발 과정에서 가려내는 방법은 보여 줘요. 2

왜 중요한가요

RollTab은 서버에 요청을 보내지 않고 PyTorch 모델을 Core ML로 변환해 아이폰과 아이패드 안에서 전 과정을 실행해요. INT8 양자화로 가중치 크기를 줄였고, 512개 음표에 가까워지면 최근 384개를 남겨 문맥을 다시 만들어요. 연주 입력부터 생성까지 기기 안에서 끝나므로 네트워크 지연에 덜 묶이고, MIDI 연주 데이터를 외부 서버로 보낼 필요도 줄어요. 2

온디바이스 모델을 만들 때는 매개변수 수만 줄여서는 충분하지 않아요. 입력을 어떤 단위로 묶는지에 따라 한 결과를 만들기 위한 추론 횟수와 문맥 사용량이 달라져요. 이 프로젝트에서는 음표의 여러 속성을 한 단계에서 예측하도록 바꾼 일이 실시간 성능에 직접 연결됐어요. 음악 외에도 여러 필드가 한 객체를 이루는 모바일 생성 작업에서 참고할 만한 설계예요.

아직 제약도 남아 있어요. 4개 음표처럼 짧은 입력은 문맥이 부족해 결과가 불안정하고, 아무 입력 없이 만드는 연주는 성공 편차가 커요. 긴 생성에서는 반복이 나타날 수 있어요. 첫 실행 때 Apple 런타임이 기기에 맞게 모델을 최적화하느라 지연도 생겨요. 실제 제품에 적용하려면 평균 생성 속도와 함께 첫 실행 시간, 짧은 입력의 실패율, 반복 생성 빈도를 따로 확인해야 해요. 1

참고 자료

1. 온디바이스에서 피아노를 자동 완성하는 1억 2,500만 매개변수 모델 — GeekNews
2. Training a 125M-parameter Model to Autocomplete Piano — SimEdw's Blog