PyTorch 2.14 MPS에서 SVD·QR·Cholesky가 네이티브로 도는 이유 | DAKER 커뮤니티

Mac에서 PyTorch로 수치 계산을 할 때, 모델 일부는 MPS에서 돌고 행렬 분해는 CPU로 넘어가는 순간이 체감 성능을 크게 갈라놓곤 합니다. 특히 SVD, QR, Cholesky처럼 자주 쓰는 선형대수가 중간에 기기를 오가면 복사와 동기화 비용이 한 스텝 전체에 영향을 줄 수 있습니다.

PyTorch 2.14 MPS는 이런 지점을 줄이는 변화가 있습니다. float32·complex64 경로에서 SVD, QR, Cholesky 등을 네이티브 Metal 커널로 처리하면서, Apple Silicon 환경에서 행렬 연산을 같은 device 위에서 더 길게 이어가기 쉬워졌습니다.

PyTorch 2.14 MPS는 SVD, QR, Cholesky 등 선형대수를 네이티브 Metal 커널로 돌려 CPU 왕복을 줄입니다.

무엇이 달라졌나

이전에는 어텐션이나 일반 텐서 연산은 MPS에서 처리하더라도, 분해 연산 단계에서 CPU로 빠지는 경우가 있었습니다. 이때 생기는 메모리 복사와 동기화는 단순한 구현 차이를 넘어 실제 실행 시간 차이로 이어집니다.

이번 변화의 핵심은 자주 쓰는 분해 연산이 MPS에 네이티브로 들어왔다는 점입니다. 같은 dtype과 같은 배치 조건에서 device를 바꾸지 않고 끝나는지가 실제 사용감에 큰 차이를 만듭니다.

재현해 볼 실험 조건

변화를 확인하려면 MPS와 CPU를 같은 조건으로 비교해 보면 됩니다. 원문 기준으로는 다음 세 가지를 점검하면 됩니다.

동일 float32 행렬로 SVD·QR·Cholesky를 MPS와 CPU에서 각각 실행합니다.
결과 오차와 wall time, 그리고 device 간 복사 횟수를 기록합니다.
작은 배치에서는 GPU 런치 오버헤드가 클 수 있으니, 행렬 크기 구간을 나눠 비교합니다.

이 비교에서 중요한 것은 단순히 MPS를 켰는지가 아니라, 어떤 dtype과 어떤 크기에서 네이티브 경로가 실제로 작동하는지입니다.

실무에서 먼저 확인할 점

모든 경우에 MPS가 유리한 것은 아닙니다. float64는 Metal에 더블이 없어 CPU로 남고, 아주 작은 행렬은 런치 비용 때문에 CPU가 더 나을 수 있습니다. 또 Cholesky는 complex에서 이전 경로 오류가 고쳐졌다는 점이 실무 체크 포인트입니다.

Mac 환경에서는 MPS 사용 여부보다 어느 dtype·크기가 네이티브인지 기록해 두는 편이 더 안전합니다.

함께 봐야 할 API도 있습니다. matrix_rank·pinv·cond처럼 SVD에 의존하는 API는 기반 분해 경로가 바뀌면 같이 영향을 받습니다. 따라서 개별 연산만 보지 말고 의존 경로 전체를 한 번에 점검하는 것이 좋습니다.

반면 비에르미트 eig는 아직 이후 과제로 남아 있습니다. 이 연산이 필요한 워크로드라면 대체 경로를 미리 정해 두는 편이 안정적입니다.

Mac 학습·제출 환경에서 남겨둘 메모

학습이나 제출 환경이 Mac이라면, PyTorch 2.14 여부와 MPS 사용 여부를 제출 노트에 적어두면 비교와 재현에 도움이 됩니다. 같은 코드라도 버전과 device 경로에 따라 실행 특성이 달라질 수 있기 때문입니다.

참고 자료

https://daker.ai/public/learning/tracks/pytorch-practice-advanced-track
https://daker.ai/public/learning/materials/pytorch-advanced-2-embedding-self-attention-mini-i

Mac에서 MPS 선형대수를 써 보셨다면, 어떤 행렬 크기와 dtype에서 차이가 가장 크게 느껴졌는지 궁금합니다.