2026 Cellpose 4.2.1.1 Mac GPU Not Enabled? Troubleshoot with MPS

Cellpose finishes, but you cannot tell whether your Mac GPU did any work.

This week, check MPS in the exact Python environment that launches Cellpose, verify the run’s GPU setting, then validate the model and each 2D or 3D processing stage separately. PyTorch MPS can provide a GPU path on Apple Silicon, but that does not mean the entire segmentation workflow runs on the GPU.

This guide is for graduate students running Cellpose on a Mac who need to confirm the selected backend.
It also helps researchers deciding whether masks meet project criteria.
Lab administrators can use it to separate Python, device-selection, and task-flow problems.

Separate a backend failure from a slow workflow

A long run is not proof that Cellpose fell back to CPU. Total elapsed time can include image loading, preprocessing, model inference, mask construction, and post-processing. A stage that does not dominate runtime can also obscure whether GPU inference occurred. Conversely, a PyTorch installation that can see MPS does not prove that Cellpose selected it for this run.

Use evidence from the specific run rather than judging by the overall clock. First establish whether the backend is available in the environment you actually use. Then confirm that Cellpose requested GPU execution and check the task path. Finally, review the segmentation output independently of the device question.

The distinction matters in both directions:

• Backend unavailable: the active PyTorch build or macOS setup cannot expose MPS.
• Backend available but not selected: the Python check passes, but the Cellpose entry point or its options do not request GPU use.
• Inference runs, another stage is slower: the model and surrounding mask workflow may use different operations or device paths.
• The task completes but the output is unsuitable: successful execution does not demonstrate that the masks satisfy scientific criteria.

Cellpose’s official release record for version 4.2.1.1 is the version-specific starting point. Do not apply a behavior described for another release to this installation without checking whether the relevant code or documentation changed.

A progress bar, a completed output file, and MPS availability answer different questions. Record them as separate checks.

Check MPS in the same Python environment

A common source of confusion is testing one Python installation and launching Cellpose from another. A terminal, GUI launcher, notebook kernel, and environment manager can each point to different interpreters. If your diagnostic runs in one environment while Cellpose runs in another, the check does not describe the task in question.

PyTorch documents MPS availability checks through torch.backends.mps.is_built() and torch.backends.mps.is_available(). Its MPS backend guide also lists macOS 12.3 or later as the documented operating-system requirement for the MPS backend. Confirm the actual machine and software environment against the current documentation; a version requirement by itself does not establish that MPS is available in your active build.

Run a small diagnostic using the interpreter that will launch Cellpose:

python -c "import sys, torch; print(sys.executable); print(torch.__version__); print('MPS built:', torch.backends.mps.is_built()); print('MPS available:', torch.backends.mps.is_available())"

Read both Boolean values:

• If is_built() is false, the installed PyTorch build does not include MPS support.
• If the build check is true but is_available() is false, PyTorch reports that MPS cannot be used in the current runtime environment.
• If both are true, MPS is exposed to that Python process. This does not yet prove Cellpose selected it.

Also note the printed Python executable and PyTorch version. Compare the executable with the one used for the Cellpose command or application. If they differ, rerun the diagnostic in the correct environment rather than trying random installation changes.

The PyTorch backend interface documentation describes the backend checks. Use those checks as an environment diagnosis, not as an end-to-end Cellpose test. If the installation guide for your Cellpose setup specifies a compatible PyTorch installation path, follow that guidance and verify the result again in the same interpreter. The Cellpose installation documentation is the relevant reference for its installation context.

Verify how this Cellpose run requests GPU use

When MPS is available, inspect the launch path before reinstalling anything. A command-line run, GUI session, and script can have different options or use different Python environments. Check which one you actually launched, then inspect that version’s supported options.

For a command-line installation, open the help output for the cellpose command resolved in your active environment. Compare the available GPU options with the Cellpose CLI documentation. Make sure you have not relied on a setting from a different release or copied an option into a command that is using another executable.

For a GUI or a Python script, check the corresponding controls or API in the documentation for that entry point. The Cellpose API reference is useful when the task is started from code. Confirm that the model call and its GPU-related argument match the installed API; do not infer selection from a separate PyTorch test.

A controlled check is more useful than changing several settings at once:

1. Record the command or application used to start the run.
2. Record the Python executable and Cellpose version for that launch.
3. Check the documented GPU option for that exact entry point.
4. Run a small, permitted image using the same model and task type as the real workflow.
5. Save the startup messages and output so you can compare runs after a change.

If you are using an environment variable to allow unsupported operations to fall back to CPU, inspect its effect rather than treating a successful run as proof of full GPU execution. PyTorch documents PYTORCH_ENABLE_MPS_FALLBACK in its MPS environment-variable reference. That setting can permit CPU fallback for operations that are not supported by MPS; it does not convert those operations into GPU work. Keep a note of whether it is set when you report results.

Treat inference and mask processing as different checks

Cellpose workflows include more than running a model. The model may perform inference, while mask generation and subsequent handling involve additional operations. Their device support and behavior can depend on the Cellpose version, model, and task. This is why “MPS is available” and “the complete workflow is accelerated” are not interchangeable claims.

Check the exact path you use:

• Identify the Cellpose version and model used for the experiment.
• Establish whether the task is 2D or 3D and note any preprocessing or post-processing steps.
• Compare the relevant release notes with the implementation used by the installed version.
• Separate timing or errors from model inference, mask construction, and later analysis where your workflow makes that possible.
• Confirm whether any configured fallback changes where an operation executes.

Cellpose’s device-assignment implementation can help you understand how the documented code selects a device. Use it alongside the release notes for version-specific interpretation. Documentation on a current page may describe behavior that differs from the older installation you are investigating, so match the source to your installed release before drawing a conclusion.

For a 3D job, test the path actually used by the project rather than extrapolating from a successful 2D run. A 2D test confirms only the tested setup and task. Likewise, a 3D run completing successfully does not establish that each operation used MPS. If you cannot identify a stage’s device behavior from the applicable documentation, report it as unverified rather than labelling the whole workflow GPU-accelerated.

Validate the masks against research criteria

A run can finish without an exception and still produce masks that are not acceptable for your study. Device status is a software-execution question. Whether a segmentation is fit for a research purpose is a scientific validation question. Keep the two decisions separate in lab notes and project review.

Start with representative images that you are permitted to use in the test environment. Include typical samples and known difficult cases where possible. Compare the resulting masks with an approved baseline, expert-reviewed annotations, or another project-specific reference. Look for errors that matter to your analysis, such as missed objects, merged regions, boundary changes, or downstream measurements that shift beyond the project’s acceptance criteria.

Record enough information for another team member to reproduce the comparison:

• Cellpose and PyTorch versions, model, and launch method.
• The relevant GPU setting and MPS availability result.
• The task type, including whether it is 2D or 3D.
• Input image identity or a permitted anonymized identifier.
• Any preprocessing, post-processing, and fallback settings.
• The project’s approval criterion and who reviewed the output.

Cellpose’s output documentation describes its generated outputs. Use that reference to identify the artifacts you should inspect, then apply the project’s own scientific criteria. Do not treat a matching filename, a non-empty mask, or a single successful test as evidence that the segmentation is valid.

For human-subject, unpublished, or otherwise controlled data, check institutional rules before moving images to a different machine or service. A technically suitable Mac is not automatically an approved data environment. If you need to evaluate a remote environment, first confirm the institution’s data-handling requirements and the machine’s actual software and hardware details. The osxmesh privacy information is one place to review service-related privacy terms; it does not replace your institution’s approval process.

Compare the next step against the evidence

Use the table as a routing aid, not as a claim that a particular Mac, Cellpose model, or workflow will meet your project’s requirements. If you cannot establish the backend and task behavior, classify the result as unverified and use a known, approved environment for acceptance.

FAQ: MPS checks and research validation

Why can a PyTorch MPS check pass while a Cellpose run still appears CPU-bound?

The check establishes that PyTorch exposes MPS to the diagnostic process. It does not show that Cellpose used the same interpreter or requested GPU execution. The visible delay may also come from preprocessing or mask handling. Compare executable paths, launch options, logs, and the task implementation before diagnosing a backend failure.

Does every stage of a 3D Cellpose task run on MPS?

No blanket conclusion is safe. Device use can differ between inference and other stages, and it may depend on the version, model, and exact task path. Check the release notes and implementation corresponding to your installation. If the documentation does not establish a stage’s device behavior, mark it as unknown and test that path directly.

What counts as evidence that the segmentation is acceptable for a study?

Use a project-defined validation method, not just successful execution. Compare masks and relevant downstream measurements on representative, permitted images against an approved baseline or reviewed reference. Include difficult cases, document the model and settings, and have the responsible researcher apply the project’s acceptance criteria.

Should you switch environments if MPS remains uncertain?

Switch only when the project requires a verified Apple Silicon MPS run and your current environment cannot establish it. First confirm that the proposed environment has the required hardware and software and is approved for the data. A different Mac does not automatically solve a software-path problem or satisfy institutional data rules.

Choose a verified Mac only when the project needs one

If your lab currently relies on Linux or Windows systems, those machines may remain the right choice for established analysis workflows. But they cannot by themselves verify execution on Apple Silicon macOS. Borrowed Macs can introduce interpreter drift, unclear GPU settings, and limited reproducibility if the configuration is not recorded. Buying hardware solely for a temporary compatibility check may also be difficult to justify when the project needs only a short validation window.

If the study specifically requires an Apple Silicon MPS check, a rented remote Mac can be a practical temporary test path—but only after you confirm the available machine, software conditions, access method, and institutional data rules. Do not assume a service provides a particular chip, guarantees MPS behavior, or is approved for sensitive data. Review the actual osxmesh plan details and, if a requirement is unclear, ask through osxmesh support before moving project data or scheduling validation.

The decision should follow the evidence: repair the active Python and Cellpose path when the issue is configuration; use a validated environment when the project requires one you cannot verify locally. A temporary remote Mac is worth considering for bounded testing, not as a substitute for scientific review or for a stable, long-running workload that requires dedicated hardware and controlled data handling.

Frequently asked questions