Lightning-AI/pytorch-lightning · error · RuntimeError
Cannot set the dtype explicitly. Please use module.to(new_dt
Error message
Cannot set the dtype explicitly. Please use module.to(new_dtype).
What it means
The `_DeviceDtypeModuleMixin` (used by Lightning modules to track device/dtype) defines a `dtype` property with a setter that deliberately raises, because dtype must be changed through `module.to(new_dtype)` so the change propagates to parameters and buffers. Assigning `obj.dtype = torch.float16` triggers this RuntimeError (the setter exists mainly to block the infinite-recursion path that a bare property would cause).
Source
Thrown at src/lightning/fabric/utilities/device_dtype_mixin.py:42
class _DeviceDtypeModuleMixin(Module):
__jit_unused_properties__: list[str] = ["device", "dtype"]
def __init__(self) -> None:
super().__init__()
self._dtype: Union[str, torch.dtype] = torch.get_default_dtype()
# Workarounds from the original pytorch issue:
# https://github.com/pytorch/pytorch/issues/115333#issuecomment-1848449687
# `get_default_device` only honors the `torch.device` context manager from 2.8 onwards
self._device = torch.get_default_device() if _TORCH_GREATER_EQUAL_2_8 else torch.empty(0).device
@property
def dtype(self) -> Union[str, torch.dtype]:
return self._dtype
@dtype.setter
def dtype(self, new_dtype: Union[str, torch.dtype]) -> None:
# necessary to avoid infinite recursion
raise RuntimeError("Cannot set the dtype explicitly. Please use module.to(new_dtype).")
@property
def device(self) -> torch.device:
device = self._device
# make this more explicit to always include the index
if device.type == "cuda" and device.index is None:
return torch.device(f"cuda:{torch.cuda.current_device()}")
return device
@override
def to(self, *args: Any, **kwargs: Any) -> Self:
"""See :meth:`torch.nn.Module.to`."""
# this converts `str` device to `torch.device`
device, dtype = torch._C._nn._parse_to(*args, **kwargs)[:2]
_update_properties(self, device=device, dtype=dtype)
return super().to(*args, **kwargs)View on GitHub (pinned to 9fed5c27d2)
Solutions
- Replace assignment with a `.to()` call: `module.to(torch.float16)`.
- If storing a target dtype for later, keep it in a plain attribute with a different name (e.g. `self._target_dtype`).
- Audit code for any `x.dtype = ...` on Lightning modules.
Example fix
# before model.dtype = torch.float16 # after model.to(torch.float16)
Defensive patterns
Strategy: validation
Validate before calling
# there is nothing to pre-validate; simply never assign .dtype model.to(torch.float16) # correct way
Try / catch
try:
model.dtype = torch.float16
except RuntimeError:
model.to(torch.float16) Prevention
- Never assign to module.dtype; always use .to(dtype).
- Store intended dtypes in separate named attributes.
- Grep codebases for `.dtype =` during PyTorch->Lightning migration.
When it happens
Trigger: Executing `model.dtype = torch.float16` (or any dtype assignment) on a LightningModule or Fabric-managed module that mixes in `_DeviceDtypeModuleMixin`, instead of calling `.to()`.
Common situations: Porting plain PyTorch code that assigned `.dtype` on wrapper/inner modules; helper functions trying to record intended dtype on a module; stale tutorials using attribute assignment.
Related errors
- {mode!r} only works with `dtype=torch.float16`, but you chos
- Device should be CPU, got {device} instead.
- `devices` selected with `CPUAccelerator` should be an int >
- Device should be CUDA, got {device} instead.
- You requested to find {num_devices} devices but there are no
AI-assisted analysis of Lightning-AI/pytorch-lightning@9fed5c27d2 (2026-08-28).
Data as JSON: /api/errors/6baccea3f1186d26.
Report an issue: GitHub.