PyTorch 2.14 MPS 메모리 부족: 2026년 연구 훈련을 어떻게 고칠까

PyTorch 2.14 MPS 메모리 부족은 메모리 제한을 먼저 풀어 해결할 문제가 아닙니다. 이번 주에는 실제 텐서 점유, 캐시와 파편화, 계산 그래프, 동적 입력 형태, CPU 대체 실행을 차례로 분리하고, 최소 재현이 안정화된 뒤에만 환경을 고정하시기 바랍니다. 이 순서를 지키면 무리한 설정 변경으로 연구 결과를 오염시키는 일을 줄일 수 있습니다.

이 글은 Apple Silicon에서 모델을 훈련하거나 추론하다 MPS 할당 오류를 받은 연구생을 위한 안내서입니다. Linux GPU와 macOS 결과를 비교해야 하는 연구 소프트웨어 유지 관리자, Mac이 없는 연구실에서 임시 재현 환경을 마련해야 하는 기술 책임자도 대상입니다.

주의: PyTorch 2.14는 2026년 9월 2일 정식 공개되었고 MPS 캐시 할당기와 일부 메모리·복사 경로가 조정되었습니다. 그러나 이 변경이 모든 MPS 메모리 부족이나 메모리 증가를 해결했다는 뜻은 아닙니다. 공식 배포 안내의 변경 범위와 현재 오류를 분리해서 판단해야 합니다.

마지막 갱신: 2026년 9월 12일. 배포 정보는 PyTorch 공식 안내, 메모리 API 문서, Apple의 메모리 압력 설명을 기준으로 확인했습니다.

오류 유형과 기록 기준

먼저 오류를 한 종류로 묶지 않아야 합니다. PyTorch가 MPS 메모리 할당 실패를 반환하는 경우와 macOS가 메모리 압력 때문에 프로세스를 종료하는 경우는 확인할 자료가 다릅니다. 프로그램이 갑자기 느려지고 응답하지 않는 경우에는 운영 체제 전체의 메모리 압력도 살펴봐야 합니다. 반복 실행 뒤 상주 메모리만 계속 증가한다면 코드가 텐서나 계산 그래프를 보존하고 있을 가능성이 있습니다.

다음 항목을 한 번에 기록해 기준선을 만드십시오.

• PyTorch 2.14의 정확한 버전
• Python 버전과 macOS 버전
• Apple Silicon 칩 종류
• 모델 이름, 배치 크기, 입력 해상도 또는 시퀀스 길이
• 훈련인지 추론인지, 오류가 발생한 반복 단계
• 전체 오류 문구와 실행 직전의 메모리 상태

PyTorch 2.14 MPS 메모리 부족을 조사할 때는 버전만 바꾸고 다른 조건을 그대로 두어야 합니다. 입력 형태와 배치 크기까지 동시에 바꾸면 어떤 변경이 문제를 줄였는지 확인할 수 없습니다.

용량과 시스템 압력의 분리

모델이 요구하는 메모리는 파라미터만으로 결정되지 않습니다. 훈련에서는 활성화, 기울기, 최적화기 상태가 추가됩니다. 입력 해상도나 시퀀스 길이가 커지면 활성화가 늘어날 수 있습니다. Apple Silicon의 통합 메모리는 CPU와 GPU가 공유하지만, 물리 메모리 전체를 MPS 작업에 그대로 사용할 수 있다는 의미는 아닙니다.

MPS 상태를 볼 때는 다음 세 값을 구분하십시오.

current_allocated_memory와 driver_allocated_memory의 정의는 각각 PyTorch 메모리 API 문서와 드라이버 할당 메모리 문서에서 확인할 수 있습니다. macOS의 메모리 압력은 Apple 활성 상태 보기 안내를 기준으로 보십시오.

가장 먼저 할 실험은 모델을 바꾸는 일이 아닙니다. 같은 난수 시드로 배치 크기, 입력 형태, 시퀀스 길이 중 하나만 줄이고 여러 반복을 수행하십시오. 줄인 뒤 일정한 상태로 완료된다면 용량 경계에 가까웠을 가능성이 있습니다. 그래도 계속 증가한다면 다음 원인으로 넘어가야 합니다.

캐시와 동적 형태의 흔적

torch.mps.empty_cache()는 사용되지 않는 캐시를 반환할 수 있지만, 현재 텐서가 참조하는 메모리나 계산 그래프를 삭제하지는 않습니다. 따라서 실행 전후 값이 줄지 않았다고 해서 함수가 작동하지 않았다고 결론 내리면 안 됩니다. empty_cache 공식 문서는 이 함수의 범위를 캐시 정리로 설명합니다.

고정된 입력 형태와 변화하는 입력 형태를 각각 실행해 보십시오. 이미지 크기, 문장 길이, 배치 구성이 계속 달라지는 작업이라면 캐시 풀이 여러 형태를 보유하거나 실행 경로가 달라질 수 있습니다. 이때는 다음 순서가 좋습니다.

1. 고정된 입력 하나로 최소 반복문을 실행합니다.
2. 반복 전후의 두 메모리 API 값을 기록합니다.
3. 입력 형태를 하나만 바꾸어 같은 실험을 반복합니다.
4. empty_cache() 실행 전후를 따로 기록합니다.
5. macOS 메모리 압력과 프로세스 종료 여부를 함께 확인합니다.

PyTorch가 제공하는 MPS 메모리 상한 관련 값은 recommended_max_memory 문서에서 확인할 수 있습니다. 이 값을 근거 없이 넘기거나 고수위 제한을 해제하는 방식으로 계속 훈련하는 것은 권하지 않습니다. 시스템 안정성을 잃고 결과 파일도 남기지 못할 수 있기 때문입니다.

계산 그래프와 출력 참조

배치 크기를 낮췄는데도 메모리가 증가한다면 훈련 반복문 안에서 참조가 남는지 확인하십시오. 다음과 같은 코드 구조가 대표적인 원인입니다.

• 손실 텐서를 숫자로 바꾸지 않고 목록에 추가하는 경우
• 기울기가 붙은 예측 결과를 로그 객체에 계속 저장하는 경우
• 숨은 상태를 다음 반복으로 넘기면서 분리하지 않는 경우
• 추론에서 no_grad 또는 inference_mode의 적용 범위를 놓치는 경우
• 기울기 초기화와 결과 정리를 반복 경계 밖에 두는 경우

최소 검증에서는 결과 저장과 상세 로그를 모두 제거하고 한 번에 짧은 반복만 실행하십시오. 그 상태에서 메모리가 안정되면 모델 자체보다 참조 수명이 원인일 가능성이 커집니다. 훈련에서는 상태를 다음 반복으로 넘겨야 할 때 필요한 값만 detach하고, 추론에서는 실제 추론 블록 전체가 의도한 모드에 들어갔는지 확인해야 합니다.

고쳐야 할 코드는 한 번에 하나만 바꾸십시오. 저장 목록 삭제, 상태 분리, 추론 모드 변경을 동시에 적용하면 어느 조치가 효과가 있었는지 알 수 없습니다.

CPU 대체 실행과 연산자 경계

MPS에서 지원되지 않거나 동작에 제약이 있는 연산자가 있으면 CPU 대체 실행이 개입할 수 있습니다. 이 경우 메모리 이동 경로가 달라지고, 입력은 CPU에 남은 채 일부 결과만 MPS로 이동할 수도 있습니다. 모든 메모리 증감을 MPS의 내부 누수로 단정하면 안 되는 이유입니다.

PyTorch MPS 백엔드 안내를 기준으로 모델의 장치 이동과 지원 연산자를 확인하십시오. 또한 CPU 대체 실행과 관련된 환경 변수는 MPS 환경 변수 공식 문서에 설명된 의미와 위험 범위 안에서만 사용해야 합니다.

검증 절차는 다음과 같이 나누는 편이 안전합니다.

• 같은 최소 입력을 CPU에서 실행합니다.
• 같은 입력을 MPS에서 실행합니다.
• 두 환경에서 오류가 발생하는 단계와 출력 요약을 기록합니다.
• 장치 이동 로그를 확인하고 자동 대체인지 명시적 이동인지 구분합니다.
• 결과가 다르면 속도보다 재현성과 수치 차이를 먼저 검토합니다.

특정 조합에서만 발생한 오류 보고는 원인 후보로는 쓸 수 있지만 일반적인 결론으로 확대해서는 안 됩니다. 예를 들어 PyTorch 저장소의 관련 사용자 보고는 해당 버전과 환경의 재현 조건, 진행 상태를 함께 확인해야 합니다.

독립 재현 환경과 판정 기준

기존 개발 환경에는 이전 캐시, 여러 Python 패키지, 다른 운영 도구가 남아 있을 수 있습니다. 따라서 PyTorch 2.14 MPS 메모리 부족을 고치기 전에 깨끗한 Apple Silicon 환경에서 최소 의존성만 설치하십시오. 연구실에 Mac이 없다면 실제 Apple Silicon을 제공하는 JexMac 원격 Mac 안내를 참고해 단기간 재현 환경을 마련할 수 있습니다.

재현 환경은 다음 조건으로 고정하십시오.

1. PyTorch와 Python 버전을 잠금 파일에 기록합니다.
2. 운영 체제와 칩 정보를 함께 남깁니다.
3. 입력 자료와 난수 시드를 고정합니다.
4. 모델을 불러오고 짧은 최소 반복만 실행합니다.
5. 두 메모리 API 값과 시스템 메모리 압력을 기록합니다.
6. 코드 수정 전후의 오류 단계와 출력 요약을 비교합니다.
7. Linux GPU 결과는 별도 기준선으로 보관합니다.

이 과정을 마친 뒤에만 수정, 버전 고정, 이중 운영 중 하나를 선택하십시오. 특정 버전과 운영 체제 조합에서만 오류가 재현되면 해당 조합을 잠시 고정할 수 있습니다. 다만 Apple Silicon 결과가 Linux GPU와 자동으로 동등하다고 선언해서는 안 됩니다. 결과 요약, 수치 허용 범위, 연산자 차이를 별도로 검토해야 합니다.

재현 완료 확인 목록

아래 항목을 모두 확인하지 못했다면 오류가 해결되었다고 기록하지 않는 편이 좋습니다.

• [ ] 전체 오류 문구와 발생 반복을 저장했습니다.
• [ ] PyTorch 2.14, Python, macOS, 칩 정보를 기록했습니다.
• [ ] 배치 크기와 입력 형태를 각각 따로 줄여 보았습니다.
• [ ] current_allocated_memory와 driver_allocated_memory를 함께 기록했습니다.
• [ ] macOS 메모리 압력과 프로세스 종료 여부를 확인했습니다.
• [ ] 출력 목록, 손실 기록, 숨은 상태의 참조를 점검했습니다.
• [ ] 고정 입력과 변화 입력을 나누어 실행했습니다.
• [ ] CPU와 MPS에서 같은 최소 입력을 실행했습니다.
• [ ] 잠금 파일, 재현 스크립트, 입력 자료, 출력 요약을 묶었습니다.
• [ ] Linux GPU 결과와 Apple Silicon 결과를 별도 기준선으로 보관했습니다.

연구실 환경에 맞는 비용 판단

장기간 일정한 고부하 훈련이 목적이고 물리 장치나 대용량 GPU 메모리가 필요하다면 기존 Linux GPU 인프라가 더 적합할 수 있습니다. 반대로 macOS 전용 동작, MPS 오류 재현, 호환성 확인처럼 짧은 검증이 목적이라면 Mac을 직접 구매하기 전에 원격 환경으로 범위를 좁히는 편이 비용과 관리 부담을 함께 계산하기 쉽습니다. JexMac 요금 안내에서 현재 제공 조건을 확인하되, 실제 연구 결과를 만들기 전에는 반드시 본문 절차로 재현성을 검증하십시오.

기존 개인 Mac은 장기간 대여보다 편할 수 있지만, 연구실 공용 장비는 사용 시간 조율과 초기 환경 오염이 문제입니다. Linux 서버는 익숙한 GPU 도구를 제공하지만 macOS와 MPS의 오류를 그대로 재현하지 못합니다. 이런 차이 때문에 현재 환경과 Apple Silicon 환경을 단순히 승패로 비교하기보다, 각각의 검증 역할을 나누는 것이 합리적입니다.

최소 스크립트까지 작성했는데도 코드 문제인지 본체 환경 문제인지 판단되지 않는다면, 깨끗한 Apple Silicon 원격 Mac을 짧게 사용해 오류를 다시 확인하는 방법이 실용적입니다. JexMac의 도움말과 접속 절차를 확인한 뒤 잠금 파일, 입력 자료, 메모리 기록, Linux 대조 결과를 함께 준비하십시오. 오류가 사라지면 원래 환경의 오염 가능성을 조사하고, 계속 재현되면 코드와 특정 버전 조합을 다시 분리하면 됩니다. 이후에도 안정적인 장기 고부하 훈련은 Linux GPU로 유지하고, macOS 검증만 원격 Mac으로 맡기는 이중 운영을 선택할 수 있습니다.

자주 묻는 질문