PyTorch 2.14 MPS 캐싱 할당자 변화: 긴 디코드에서 예약 메모리와 복사 경로를 어떻게 볼까 | DAKER 커뮤니티

Apple Silicon에서 긴 생성이나 디코드를 돌릴 때, 실제 사용 메모리보다 예약 메모리가 계속 불어나는 모습이 더 신경 쓰일 때가 있습니다. 특히 같은 프롬프트 길이와 배치로 반복해도 예약 풋프린트가 한쪽으로만 커진다면, 성능보다 먼저 안정성을 점검하게 됩니다.

PyTorch 2.14에서는 MPS 캐싱 할당자가 큰 할당을 버킷으로 묶고 배치 힙을 활용해, 이런 구간에서 예약 메모리가 필요 이상으로 커지던 경로를 다듬었습니다. 여기에 CPU↔MPS 복사 경로도 짧아져, 긴 디코드처럼 할당과 해제가 반복되는 워크로드에서 함께 살펴볼 만한 변화가 생겼습니다.

PyTorch 2.14에서 MPS 캐싱 할당자가 큰 할당을 버킷으로 묶어 예약 메모리 증가를 막고, 배치 힙으로 단편화를 줄입니다.

이번 변화에서 먼저 볼 지점

핵심은 피크 메모리 하나만 보는 것이 아니라, 긴 디코드 구간에서 예약 메모리 추이가 안정적으로 유지되는지 확인하는 데 있습니다. 이번 변화는 MPS 선형 디코드 커널이나 CTC 손실 지원과는 다른 축에 있습니다. 초점은 할당자와 복사 경로입니다.

원문 기준으로, 큰 할당은 버킷으로 묶이고 배치 힙을 통해 단편화를 줄이는 방향으로 정리됐습니다. 또한 CPU↔MPS 복사에서는 핀드 버퍼 블릿과 연속 동일 dtype 커널 경로가 언급됩니다. 따라서 비교를 할 때도 단순히 얼마나 빨라졌는지보다, 긴 디코드에서 예약 메모리가 한없이 커지지 않는지에 더 주목하는 것이 좋습니다.

얼마나 줄었는지보다 긴 디코드 구간에서 예약 메모리가 안정적인지가 더 중요한 관찰 포인트입니다.

재현해 볼 실험 조건

비교는 같은 모델, 같은 프롬프트 길이, 같은 배치로 맞춰 두고 2.14 전후 또는 할당자 관련 변경 전후를 나눠 보는 방식이 적절합니다. 짧은 디코드와 긴 디코드를 각각 돌려 예약 메모리와 할당 추이를 기록하면, 변화가 어느 구간에서 드러나는지 파악하기 쉽습니다.

가능하다면 연속 동일 dtype 복사와 핀드 호스트 버퍼 경로가 실제로 쓰이는지도 프로파일 한 줄 정도로 함께 남기면 좋습니다. 같은 입력을 반복했을 때 예약 메모리가 계속 커지지 않는지 보는 것도 중요합니다. 만약 커진다면 shape, 버전, 재현 스텝을 함께 정리해 두면 다음 비교가 쉬워집니다.

실험이 끝난 뒤에는 기기, 버전, 시퀀스 길이, 예약 메모리 관찰을 한 줄로 남겨 두면 됩니다. 이런 기록이 있어야 다음 참가자도 같은 조건으로 따라오기 쉽습니다.

실무에서 바로 확인할 포인트

긴 MPS 디코드에서는 피크 메모리만 따로 보지 말고 예약 메모리 추이도 함께 보는 것이 좋습니다. 학습 노트나 실험 메모에는 시퀀스 길이와 함께 예약 메모리가 안정적이었는지 여부를 남겨 두면 비교가 쉬워집니다.

또 하나는 실험 축을 섞지 않는 것입니다. 이번 확인은 할당과 복사 경로에 관한 내용이므로, 선형 디코드 커널 실험과 한 번에 묶기보다 분리해서 보는 편이 해석에 도움이 됩니다.

이번 글의 초점은 할당자와 복사 경로이며, 다른 MPS 기능 변화와는 분리해 보는 편이 좋습니다.

관련 DAKER 학습

PyTorch 실전 고급 트랙에서 실전 관점의 PyTorch 이슈를 이어서 볼 수 있고, 비교 결과나 재현 메모는 DAKER 커뮤니티에 남기면 맥락을 공유하기 좋습니다.

참고 자료

https://daker.ai/public/learning/tracks/pytorch-practice-advanced-track
https://daker.ai/community

Apple Silicon에서 긴 디코드를 돌릴 때, 여러분 환경에서는 예약 메모리 추이가 2.14 전후로 어떻게 달라졌는지 궁금합니다.