Сначала проверьте, содержит ли установленная сборка PyTorch поддержку MPS и доступен ли backend на этом Mac; затем отдельно разберите ошибку миграции, неподдерживаемый оператор и ограничение типа данных. На этой неделе не переносите весь проект и не считайте CPU fallback успешным ускорением: сначала проверьте представительную задачу и сопоставьте результаты.
Эта инструкция предназначена исследователям, у которых torch.backends.mps.is_available() возвращает False, либо модель падает после переноса на MPS. Она также пригодится сотрудникам лабораторий, которые настраивают среду для других пользователей.
Последнее обновление: 23 октября 2026 года. Сведения сверены с официальным описанием PyTorch 2.14, документацией MPS для этой версии и текущей документацией переменных среды MPS. Перед публикацией результатов работы ещё раз проверьте текущую документацию: описание поддержки и исправления могут обновляться.
Рубеж первый: сборка поддерживает MPS, но Mac может быть недоступен
PyTorch 2.14 включает изменения, связанные с Apple Silicon, однако номер версии не подтверждает, что конкретный Python-процесс может использовать MPS или что все операции проекта будут выполнены на GPU. В описании выпуска PyTorch 2.14 перечислены улучшения для Apple Silicon, а не гарантия совместимости всех моделей и операторов.
Различайте два результата проверки:
torch.backends.mps.is_built()сообщает, включена ли поддержка MPS в установленной сборке PyTorch.torch.backends.mps.is_available()сообщает, доступен ли MPS в текущей среде исполнения.
Эти проверки отвечают на разные вопросы. Положительный результат первой не означает положительного результата второй. Документация MPS backend в PyTorch 2.14 описывает проверку доступности и требования среды; проверяйте по ней актуальные условия для установленной версии и конкретного Mac.
Запустите диагностику в том же терминале и тем же способом, которыми запускаете исследовательский проект:
import platform
import sys
import torch
print("Python:", sys.executable)
print("PyTorch:", torch.__version__)
print("Платформа:", platform.platform())
print("Архитектура:", platform.machine())
print("MPS built:", torch.backends.mps.is_built())
print("MPS available:", torch.backends.mps.is_available())
Сохраните вывод в журнал эксперимента. Так вы зафиксируете, какой интерпретатор, версия PyTorch и архитектура реально использовались. Если сравниваете результаты с коллегой, передавайте именно этот вывод, а не только имя окружения: одинаково названные Conda- или venv-среды могут указывать на разные установленные пакеты.
Почему MPS собран, но недоступен при запуске? Сначала проверьте, действительно ли процесс работает на Apple Silicon Mac и соответствует ли система условиям, указанным в документации PyTorch для MPS. Затем проверьте, не запускается ли скрипт в другом окружении, контейнере или удалённой сессии, чем то, где вы установили пакет. Не меняйте сразу версию PyTorch: если импортируется не та установка, переустановка в случайном окружении только добавит ещё одну версию для диагностики.
Рубеж второй: импорт падает или разные терминалы показывают разное
Ошибка импорта, неожиданная версия библиотеки или различающиеся результаты проверки MPS чаще указывают на смешение окружений, чем на неисправность аппаратной части. Важна не команда установки сама по себе, а связь между выбранным Python, установленным пакетом и процессом, который запускает исследование.
Сверьте путь интерпретатора из sys.executable с тем Python, которым вы выполняете установку. Для проверки пакета используйте этот же интерпретатор:
python -m pip show torch
Если работаете через IDE, Jupyter или планировщик заданий, отдельно выясните, какой интерпретатор выбран там. Терминал может открывать одно окружение, а ядро ноутбука — другое. После переключения проекта проверьте путь к Python ещё раз, затем повторите вывод is_built() и is_available().
Не подбирайте команду установки по старой инструкции, не сверив платформу, версию Python и требуемый пакет. Официальный селектор установки PyTorch предназначен для выбора актуального варианта под вашу систему. Используйте его и проверяйте результат в активном окружении. Когда импорт завершился, зафиксируйте версию и тестируйте MPS отдельно от полного проекта — так установка не будет смешана с проблемой конкретного оператора.
В лабораторном журнале записывайте команду запуска и путь к интерпретатору вместе с версией PyTorch. Иначе повторный запуск на другом компьютере может проверять не ту среду, которую вы считали воспроизводимой.
Рубеж третий: перенос модели прошёл, но оператор или тип данных не поддерживается
Перенос тензора или модели на MPS и исполнение каждого оператора на MPS — разные этапы. Вызов .to("mps") может завершиться успешно, а позже вычисление остановится на операции, которой не хватает реализации для этого backend. Это не обязательно означает, что PyTorch установлен неправильно.
Сначала прочитайте полное сообщение об ошибке и найдите конкретное имя операции и тип данных. Затем сократите пример до операции, которая воспроизводит сбой. В минимальном скрипте оставьте создание входа, проблемный вызов и, если нужно, перенос результата. Сохраните форму тензора, dtype и параметры, от которых зависит ошибка. Такой пример позволяет проверить ограничение без запуска всей модели и обработки исследовательских данных.
Отдельно проверьте тип данных. Документация MPS указывает известные ограничения типов; сверьте их с описанием типов данных в документации PyTorch MPS. Если код использует float64, не считайте это обычной ошибкой установки. Попытка принудительно заменить тип на float32 может повлиять на численную точность и выводы эксперимента. Сначала установите, допускает ли это научный протокол, а затем сопоставьте метрики и результаты с исходным вычислением.
Можно ли включить PyTorch MPS fallback, если не поддерживается оператор? Переменная PYTORCH_ENABLE_MPS_FALLBACK=1 позволяет направлять неподдерживаемые MPS-операции на CPU. Это обход ограничения выполнения, а не доказательство, что вся задача ускоряется на GPU. Кроме того, не следует считать fallback универсальным способом обойти ограничения типа данных: проверьте сообщение об ошибке и документацию, потому что неподдерживаемый оператор и неподдерживаемый тип — разные причины. Назначение переменных среды описано в официальной справке PyTorch.
Для диагностического запуска задайте переменную перед стартом процесса:
export PYTORCH_ENABLE_MPS_FALLBACK=1
python ваш_скрипт.py
Сравните поведение с запуском без этой переменной и сохраните оба результата. Если приложение заработало только с fallback, отметьте это в журнале как смешанный путь выполнения. Не называйте такую конфигурацию полностью работающим GPU-запуском и не сравнивайте её время с чистым MPS без оговорок.
Рубеж четвёртый: скрипт завершился, но путь вычислений и научный результат не проверены
Успешное завершение программы ещё не показывает, что целевая операция была выполнена на MPS, и не подтверждает правильность научного результата. Сначала проверьте устройство тензоров и модели в ключевых точках кода:
device = torch.device("mps")
model = model.to(device)
batch = batch.to(device)
print("Устройство модели:", next(model.parameters()).device)
print("Устройство входа:", batch.device)
Эта проверка подтверждает размещение указанных объектов, но сама по себе не удостоверяет, что все дальнейшие операции поддерживаются MPS и нигде не используется fallback. Проверьте проблемную операцию отдельно, повторите тест без fallback и изучите журнал выполнения. Если результат зависит от конкретного слоя, упростите пример до него и сопоставьте поведение на CPU.
Затем выберите репрезентативный фрагмент своей задачи: тот, где есть реальные типы данных, характерные формы входа, важные преобразования и контрольный результат. Проверьте не только факт завершения, но и критерии, которыми пользуется ваша группа: допустимую численную погрешность, итоговые метрики, устойчивость вывода и соответствие протоколу. Критерии задаёт исследование, а не само наличие MPS.
При сравнении CPU и MPS фиксируйте входные данные, параметры запуска, случайные состояния и версии среды. Однако одинаковое начальное состояние не гарантирует побитового совпадения между платформами: изучите разъяснение PyTorch о воспроизводимости и случайности и заранее определите, какая степень совпадения достаточна для вашей задачи. Для подтверждения вычислений на Apple Silicon также полезен материал Apple о Metal и PyTorch, но он не заменяет проверку совместимости конкретного проекта.
Как сопоставить научные результаты MPS и CPU? Запустите один и тот же обезличенный контрольный набор в обоих режимах, проверьте выходы и заранее выбранные метрики, затем оцените расхождения относительно требований эксперимента. Если различие влияет на вывод или превосходит установленный допуск, не переключайте основной расчёт на MPS до выяснения причины. При этом не требуйте побитового совпадения без обоснования: проверяйте именно критерий, значимый для проекта.
Маршрут проверки перед решением о переносе
Пройдите пункты по порядку. Если на каком-то шаге причина не установлена, остановитесь там и соберите минимальный воспроизводимый пример, прежде чем менять параметры полного проекта.
- [ ] Запустить диагностику тем же Python, которым запускается проект, и сохранить
sys.executable, версию PyTorch и архитектуру. - [ ] Сопоставить
is_built()иis_available()с требованиями среды в официальной документации MPS. - [ ] Если сборка MPS отсутствует, проверить активное окружение и заново выбрать установку через официальный селектор PyTorch.
- [ ] Если MPS собран, но недоступен, проверить Mac, условия системы и отсутствие переключения на другой интерпретатор или удалённый контекст.
- [ ] Если падает вычисление, записать имя операции, dtype и минимальный пример; не смешивать ошибку оператора с проблемой импорта.
- [ ] Проверить поведение с fallback и без него, указав, где именно выполняется расчёт и есть ли ограничение точности.
- [ ] Сравнить контрольный результат с CPU по критериям лаборатории и принять решение о переносе только после проверки.
Выбор вычислительного маршрута: MPS, CPU или HPC
Когда собраны диагностические данные, выбирайте не самый новый backend, а маршрут, который соответствует требованиям исследования. В таблице приведены условия решения, а не обещания о производительности: скорость зависит от проекта и должна измеряться на его репрезентативной задаче.
| Маршрут | Выбирайте, если | Что проверить до основного расчёта |
|---|---|---|
| MPS на Mac | Проверка показывает доступность, критические операции выполняются, а контрольные результаты проходят критерии проекта | Путь вычислений, dtype, численные расхождения и поведение без fallback |
| CPU | Нужно локализовать ошибку, подтвердить базовый результат или MPS пока не проходит приёмку | Достаточность CPU для текущей задачи и совпадение с контрольными данными |
| Университетский HPC | Проекту нужна существующая лабораторная инфраструктура, а целевая среда и зависимости там подтверждены | Совместимость кода, очередь и правила доступа, версии библиотек и сопоставимость результата |
| Приостановить перенос | Ошибка связана с типом данных или результат выходит за допустимый допуск | Требования протокола, причина расхождения и возможность валидировать преобразование |
Если работа уже проходит на HPC, Mac с MPS не обязан заменять кластер: используйте его для проверки совместимости и разработки только там, где это подтверждено. Если же для воспроизводимого сценария необходим именно macOS, но подходящего компьютера у лаборатории нет, сравните условия доступа и стоимость на странице тарифов VMSPIN. Это имеет смысл после проверки проекта, а не вместо неё.
После диагностики: закрепить решение и повторить проверку
Зафиксируйте выбранный маршрут в конфигурации проекта: какая среда запускалась, включался ли fallback, какие типы данных использовались и какие контрольные результаты прошли проверку. Если исследовательский код меняет зависимость или оператор, повторите сокращённый тест до запуска полного анализа. Так последующее обновление пакета не будет незаметно менять условия эксперимента.
Когда передавать задачу на HPC? Выбирайте кластер, если ваша группа уже проверила там нужную среду или проекту требуется вычислительный процесс, которого Mac-маршрут не обеспечивает. Если же цель — проверить именно совместимость с macOS, HPC не заменит такой тест: используйте Mac на минимальном обезличенном примере и затем решайте, нужен ли перенос всего процесса.
Передайте коллегам не только вывод программы, но и диагностический журнал, команду запуска, критерии сверки и результат проверки с fallback. Без этих сведений другой исследователь может повторить запуск в другой среде и получить внешне похожий, но методически иной результат.
Если для контрольного теста нужен настоящий Mac, а покупать устройство ради разовой проверки нецелесообразно, можно посмотреть условия удалённого доступа к Mac через VMSPIN. Удалённая среда подходит для проверки macOS-зависимого кода, но не заменяет университетский HPC для задач, которым он необходим. Сначала подтвердите на обезличенном примере, что проект проходит MPS-проверку; затем сопоставьте доступный вариант с вашим протоколом и сроком работы.