An engineer saves a fitted cuML model on a GPU workstation using joblib and ships the file to a colleague who tries to load it. Loading fails. The colleague has the same cuML and CUDA library versions installed but is working on a machine that has no GPU. Which explanation is the most likely root cause of the load failure?
- AA cuML model holds GPU-resident state and depends on the CUDA runtime and a device at load time, so deserialising it on a machine with no GPU cannot restore that device state. Correct
- BThe joblib file is corrupted in transit, because joblib archives cannot be transferred between machines without first re-exporting them to a plain text format.
- Cjoblib strips the model's learned parameters during saving, so any loaded cuML model must be refitted before use regardless of the hardware on the loading machine.
- DMatching cuML versions are insufficient, because the file can only load when the colleague also has the identical CPU model and clock speed as the machine that saved it.
Why A is correct: Correct: cuML estimators are GPU-native and their persisted state assumes a CUDA device is available; restoring the object on a host with no GPU cannot reconstruct the device-side arrays, so the load fails.
Why B is wrong: Tempting because transfer corruption is a real failure mode, but joblib produces ordinary binary files that transfer like any other file; the relevant difference here is the absence of a GPU, not the transport mechanism.
Why C is wrong: Tempting because some workflows do require refitting, but joblib serialises the fitted parameters faithfully; it does not strip learned state, and a GPU-equipped machine would load the same file without needing a refit.
Why D is wrong: Tempting because environment matching matters for reproducibility, but deserialisation does not depend on identical CPU hardware; the decisive missing component here is a CUDA-capable GPU, not a matching processor.