125M piano autocomplete, iPhone에서 초당 108개 음표

피아노 몇 음을 치면 iPhone이 다음 연주를 이어간다. Simon Edwardsson은 125M parameter transformer를 Core ML로 옮겨 iPhone 15에서 초당 약 108개 음표를 생성했다. RollTab이라는 앱은 MIDI keyboard 입력을 받아 전 과정을 기기 안에서 처리한다. 서버 왕복 없이 실시간 반응을 확보했다는 점이 프로젝트의 출발점이다.

가장 큰 선택은 모델 크기가 아니라 MIDI 표현이었다. 음의 시작과 끝을 각각 token으로 만들면 모델이 note-off를 잊어버려 음이 계속 울리는 문제가 생겼다. pitch, velocity, duration을 여러 autoregressive 단계로 나누는 방식은 안정적이지만 느렸다. 최종 구조는 하나의 음표를 pitch, 이전 음과의 시간차, duration, velocity의 다섯 categorical field로 묶었다. transformer 한 번이 완전한 음표 하나를 진행하므로 속도와 context 효율이 함께 좋아졌다.

데이터는 수십만 개의 MIDI 파일로 구성했지만, 양을 늘리는 것만으로는 품질이 오르지 않았다. 공개 자료에는 중복 편곡, 비정상적인 tempo, 피아노와 무관한 track이 섞여 있었다. 저자는 정제 규칙을 강화하고 같은 곡의 다른 버전이 train과 validation에 갈라지지 않도록 묶었다. dataset을 약 5배 키운 실험은 오히려 나빠졌다. 이 프로젝트에서 데이터 선택은 규모보다 강한 변수였다.

학습 후반에는 DPO가 체감 품질을 크게 바꿨다. 여러 continuation을 만든 뒤 pairwise preference로 더 나은 쪽을 고르고, prompt와 잘 이어지는 연주를 선호하도록 학습했다. 저자의 평가에서는 DPO 모델의 continuation이 base model보다 69% 넘게 선택됐다. scheduled sampling도 validation loss는 높였지만 실제 이어 연주 품질을 개선했다. 단일 loss가 생성 음악의 만족도를 제대로 설명하지 못한 사례다.

배포 과정에도 현실적인 제약이 남았다. model weight는 INT8로 줄였지만 Core ML이 첫 실행에서 hardware에 맞게 최적화하는 시간이 길다. 학습 context는 최대 512개 음표였고, 더 긴 연주에서는 오래된 음표를 잘라낸다. 빠른 생성 속도와 긴 음악 구조를 기억하는 능력 사이의 균형은 다음 과제로 남아 있다.

320점과 74개 댓글이 모인 논의는 속도보다 음악성으로 향했다. 초당 108개 음표는 충분하니 계산 여유를 리듬과 구조 개선에 쓸 수 없느냐는 질문, MIDI 출력을 외부 synthesizer로 보내자는 제안, 2003년 Continuator와의 연결이 이어졌다. 반응은 완성품 평가보다 사람이 연주한 짧은 prompt가 전혀 다른 방향으로 이어지는 순간에 집중됐다.

모델은 INT8로 quantize됐고, 최대 512개 음표 context로 학습됐다. 결과가 언제나 자연스럽지는 않지만, 표현 설계와 데이터 정제, preference 학습이 작은 on-device 생성 모델의 병목을 어떻게 바꾸는지 구체적으로 보여준다.

프로젝트 원문 · 커뮤니티 논의