When training on multiple GPUs, the main goal is to speed up training without losing model quality. So, the key metrics are training time per epoch and model accuracy or loss. We want to see if the model learns just as well (accuracy/loss) but faster (time). If accuracy drops, the speed gain is not useful. If training time does not improve, multi-GPU is not effective.
Multi-GPU training in PyTorch - Model Metrics & Evaluation
Multi-GPU training itself does not change the confusion matrix of the model. The confusion matrix shows how well the model predicts classes:
| Predicted Positive | Predicted Negative |
|--------------------|--------------------|
| True Positive (TP) | False Negative (FN) |
| False Positive (FP) | True Negative (TN) |
We compare confusion matrices from single-GPU and multi-GPU training to check if predictions stay consistent.
Multi-GPU training aims to keep model quality the same while speeding up training. If the model trained on multiple GPUs has lower precision or recall, it means the training process might have issues like poor synchronization or batch size effects.
Example: If a cancer detector model trained on one GPU has 90% recall, but on multiple GPUs recall drops to 80%, it means the multi-GPU setup hurt the model's ability to find cancer cases. This is bad even if training is faster.
Good:
- Training time per epoch decreases significantly (e.g., from 60 minutes to 20 minutes).
- Model accuracy and loss remain similar or improve slightly.
- Precision and recall stay stable compared to single-GPU training.
Bad:
- Training time does not improve or improves very little.
- Model accuracy drops noticeably (e.g., from 85% to 75%).
- Precision or recall decrease, indicating worse predictions.
- Training becomes unstable or loss fluctuates wildly.
- Data leakage: If data is not properly split or shuffled across GPUs, the model may see the same data multiple times, inflating accuracy.
- Batch size effects: Multi-GPU training often increases batch size, which can affect learning dynamics and model quality.
- Overfitting: Faster training might cause the model to overfit if early stopping or validation checks are not used.
- Synchronization issues: Improper gradient synchronization can cause model divergence and poor metrics.
- Accuracy paradox: High accuracy with imbalanced data can be misleading; always check precision and recall.
Your multi-GPU model trains 3 times faster than single-GPU but has 98% accuracy and only 12% recall on fraud detection. Is it good for production? Why or why not?
Answer: No, it is not good. Even though accuracy is high, recall is very low. This means the model misses most fraud cases, which is dangerous. For fraud detection, high recall is critical to catch as many frauds as possible. Speed alone does not make the model useful.
Practice
torch.nn.DataParallel in PyTorch?Solution
Step 1: Understand the role of
DataParalleltorch.nn.DataParallelis designed to distribute the model and input data across multiple GPUs to speed up training.Step 2: Compare options
Reducing the model size by pruning layers, converting the model to a CPU-only version, and visualizing the model architecture do not relate to multi-GPU training. Only splitting the model and data across multiple GPUs for faster training correctly describes the purpose.Final Answer:
To split the model and data across multiple GPUs for faster training -> Option CQuick Check:
Multi-GPU training = DataParallel usage [OK]
- Thinking DataParallel reduces model size
- Confusing DataParallel with CPU conversion
- Assuming DataParallel is for visualization
Solution
Step 1: Identify the correct wrapper for multi-GPU
To enable multi-GPU training, PyTorch providestorch.nn.DataParallelwhich wraps the model.Step 2: Check other options
Sequentialchains layers,ModuleListstores layers, andParameteris for tensors, none enable multi-GPU.Final Answer:
model = torch.nn.DataParallel(model) -> Option AQuick Check:
Wrap model with DataParallel for multi-GPU [OK]
- Using Sequential or ModuleList instead of DataParallel
- Trying to wrap model with Parameter
- Forgetting to wrap the model at all
import torch model = MyModel() model = torch.nn.DataParallel(model) model.cuda() inputs = inputs.cuda() outputs = model(inputs) print(outputs.device)What will be printed if multiple GPUs are available?
Solution
Step 1: Understand DataParallel device behavior
When usingDataParallel, the model replicates on all GPUs but the output is gathered on the default device, usuallycuda:0.Step 2: Analyze the print statement
Theoutputs.devicewill show the device of the gathered output tensor, which iscuda:0, not all GPUs or CPU.Final Answer:
cuda:0 -> Option AQuick Check:
DataParallel output device = cuda:0 [OK]
- Expecting output on all GPUs simultaneously
- Thinking output is on CPU
- Assuming output device is cuda:1 or others
model = MyModel() model = torch.nn.DataParallel(model) inputs = inputs.cuda() outputs = model(inputs)The error says: 'Expected all tensors to be on the same device'. What is the likely cause?
Solution
Step 1: Check model and input device placement
The model must be moved to GPU (e.g.,model.cuda()) before wrapping withDataParallelto ensure all parts are on the same device.Step 2: Analyze error cause
If the model is on CPU but inputs are on GPU, the error about device mismatch occurs.Final Answer:
Model is not moved to GPU before wrapping with DataParallel -> Option BQuick Check:
Model and inputs must be on same device [OK]
- Wrapping model before moving to GPU
- Assuming inputs must be on CPU
- Using wrong wrapper like Sequential
Solution
Step 1: Review multi-GPU training steps
UsingDataParallelautomatically splits input batches and sends them to multiple GPUs, so manual splitting is not needed.Step 2: Confirm necessary steps
Wrapping the model, moving it to GPU, and moving inputs to GPU are all required for proper multi-GPU training.Final Answer:
Manually split input batches and send each to a different GPU -> Option DQuick Check:
DataParallel handles input splitting automatically [OK]
- Trying to manually split inputs across GPUs
- Forgetting to move model to GPU
- Not wrapping model with DataParallel
Ready to prove it?
Pass the test and this pattern moves unknown
