Models loaded in bfloat16 crash on MPS with a float64 conversion error, so the pipeline never runs

Problem

Many diffusion models load their components in bfloat16 by default, and under stock behavior that configuration crashes on MPS — the pipeline doesn't run at all. Operations that internally promote to float64 fail on the MPS backend, for example RoPE positional embeddings computed with double_precision=True:

TypeError: Cannot convert a MPS Tensor to float64 dtype as the MPS framework doesn't support float64

Desired outcome: an Apple Silicon user can load one of these models and get a successful generation without manually intervening in the loading process to change dtypes by hand.

Origin

Reported by Joshua Bretag. Surfaces on Apple Silicon (MPS) when running a pipeline whose components were loaded in bfloat16; not specific to a single node.

Impact

Apple Silicon is a primary desktop target for Griptape Nodes users. Because bfloat16 is the default dtype rather than an opt-in, this affects models on the default path, and the failure is total — generation never starts. The only workaround today is for the user to discover the dtype constraint themselves and intervene in loading.

Repro / evidence

1. On an Apple Silicon machine (MPS device), load a model whose components default to bfloat16.
2. Run a generation.
3. The pipeline fails with the float64 conversion error above rather than producing output.

Relevant code in this repo:

• modular_diffusion_nodes_library/artifact_utils/component_artifact.py — torch_dtype defaults to "bfloat16" on the component artifact base class and is resolved via getattr(torch, self.torch_dtype) at each materialize site (_materialize_hf_repo, _materialize_single_file, _materialize_local_dir). The dtype is fixed at artifact creation time, with no device-awareness at that point.
• modular_diffusion_nodes_library/utils/pipeline_utils.py — optimize_diffusion_pipeline() and its _automatic_optimize_diffusion_pipeline() helper have an mps branch, but it covers memory checks, VAE slicing, and CPU-offload behavior only. Nothing in the optimize path considers device dtype constraints, so there is no MPS-aware dtype override anywhere between artifact creation and execution.

Related: issue 42 covers a separate MPS gap (int8-quantized video pipelines hitting the unimplemented aten::_int_mm operator). Both point at the same underlying theme — device capability constraints not being accounted for on the MPS path — but they are distinct failures with distinct causes.