DataParallel basics in PyTorch - Model Metrics & Evaluation

Metrics & Evaluation - DataParallel basics

Which metric matters for DataParallel and WHY

When using DataParallel in PyTorch, the main goal is to speed up training by using multiple GPUs. The key metric to watch is training throughput, which means how many samples your model processes per second. This shows if DataParallel is helping your model train faster. Also, keep an eye on model accuracy or loss to make sure splitting data across GPUs does not harm learning.

Confusion matrix or equivalent visualization

DataParallel itself does not change prediction results or confusion matrix. But here is a simple confusion matrix example for a classification model trained with DataParallel:

      | Predicted Positive | Predicted Negative |
      |--------------------|--------------------|
      | True Positive (TP): 80 | False Negative (FN): 20 |
      | False Positive (FP): 10 | True Negative (TN): 90 |
    

Totals: TP + FP + TN + FN = 200 samples. This matrix helps calculate precision and recall to check model quality.

Precision vs Recall tradeoff with examples

DataParallel speeds up training but does not directly affect precision or recall. However, if DataParallel causes bugs or synchronization issues, model quality might drop.

Example:

• High precision needed: Spam filter should avoid marking good emails as spam. DataParallel helps train faster but keep precision high.
• High recall needed: Cancer detection must find all cancer cases. DataParallel should not reduce recall by causing training errors.

What "good" vs "bad" metric values look like for DataParallel

Good:

• Training throughput increases significantly (e.g., 2x speed on 2 GPUs).
• Model accuracy and loss remain similar to single GPU training.
• No errors or crashes during training.

Bad:

• Training speed does not improve or gets slower.
• Model accuracy drops noticeably.
• Errors like mismatched tensor sizes or synchronization problems.

Common pitfalls with DataParallel metrics

• Accuracy paradox: Faster training but model quality drops unnoticed if only speed is checked.
• Data leakage: Incorrect data splitting across GPUs can leak test data into training.
• Overfitting indicators: Faster training might cause overfitting if validation metrics are ignored.
• GPU memory imbalance: Unequal data splits cause some GPUs to be idle, reducing speed gains.

Self-check question

Your model trained with DataParallel shows 98% accuracy but 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. You should improve recall before using the model in production.

Key Result

DataParallel should increase training speed without hurting model accuracy or recall.

Practice

1. What is the main purpose of torch.nn.DataParallel in PyTorch?

easy

A. To convert a model to run only on CPU

B. To run a model on multiple GPUs by splitting input data automatically

C. To reduce the size of the model parameters

D. To change the model architecture dynamically during training

Solution

1. Step 1: Understand DataParallel's role

   DataParallel helps use multiple GPUs by splitting input data and running model copies in parallel.

2. Step 2: Compare options

   Only To run a model on multiple GPUs by splitting input data automatically describes this behavior correctly; others describe unrelated tasks.

3. Final Answer:

   To run a model on multiple GPUs by splitting input data automatically -> Option B

4. Quick Check:

   DataParallel = multi-GPU input splitting [OK]

Hint: DataParallel splits input across GPUs automatically [OK]

Common Mistakes:

• Thinking DataParallel changes model architecture
• Confusing DataParallel with CPU-only mode
• Believing it reduces model size

2. Which of the following is the correct way to wrap a PyTorch model model with DataParallel?

easy

A. model = torch.DataParallel(model)

B. model = torch.nn.parallel.DataParallel(model)

C. model = torch.nn.DataParallel(model)

D. model = torch.parallel.DataParallel(model)

Solution

1. Step 1: Recall correct import path

   DataParallel is in torch.nn, so correct usage is torch.nn.DataParallel.

2. Step 2: Check options

   model = torch.nn.DataParallel(model) matches the correct usage; others are incorrect or incomplete.

3. Final Answer:

   model = torch.nn.DataParallel(model) -> Option C

4. Quick Check:

   Correct import path = torch.nn.DataParallel [OK]

Hint: DataParallel is in torch.nn module [OK]

Common Mistakes:

• Using torch.DataParallel instead of torch.nn.DataParallel
• Confusing torch.nn.parallel with torch.nn
• Confusing with other torch submodules

3. Given the code below, what will be the output shape of output if input shape is (8, 3, 32, 32) and 2 GPUs are used?

import torch
import torch.nn as nn

model = nn.Linear(32*32*3, 10)
model = nn.parallel.DataParallel(model)
input = torch.randn(8, 3, 32, 32)
input = input.view(8, -1)
output = model(input)
print(output.shape)

medium

A. torch.Size([8, 10])

B. torch.Size([4, 10])

C. torch.Size([16, 10])

D. RuntimeError due to shape mismatch

Solution

1. Step 1: Understand input and model

   Input is reshaped to (8, 3072) and model outputs 10 features per input.

2. Step 2: DataParallel splits batch across 2 GPUs

   Batch of 8 splits into 2 batches of 4, processed in parallel, outputs combined back to (8, 10).

3. Final Answer:

   torch.Size([8, 10]) -> Option A

4. Quick Check:

   Output shape = batch size x output features = (8, 10) [OK]

Hint: Output batch size stays same after DataParallel [OK]

Common Mistakes:

• Thinking output batch size halves with GPUs
• Confusing input reshape with output shape
• Expecting runtime error due to DataParallel

4. What is the likely cause of this error when using DataParallel?

RuntimeError: Expected tensor for argument #1 'input' to have scalar type Float but got Double

Code snippet:

model = torch.nn.parallel.DataParallel(model)
input = torch.randn(8, 3, 32, 32, dtype=torch.double)
output = model(input)

medium

A. Input batch size is too large for GPUs

B. DataParallel requires input to be on CPU only

C. Model is not wrapped correctly with DataParallel

D. Input tensor dtype does not match model parameters dtype

Solution

1. Step 1: Analyze error message

   Error says input tensor is Double but model expects Float tensors.

2. Step 2: Check input and model dtypes

   Model parameters default to Float; input is Double, causing mismatch and error.

3. Final Answer:

   Input tensor dtype does not match model parameters dtype -> Option D

4. Quick Check:

   Dtype mismatch causes runtime error [OK]

Hint: Ensure input and model dtypes match before DataParallel [OK]

Common Mistakes:

• Assuming DataParallel only works on CPU
• Not checking tensor data types
• Thinking batch size causes dtype errors

5. You want to speed up training on 4 GPUs using DataParallel. Your model has a batch normalization layer. What should you be careful about to avoid incorrect training behavior?

hard

A. BatchNorm layers behave differently in DataParallel; use SyncBatchNorm or move to DistributedDataParallel

B. DataParallel automatically fixes BatchNorm issues, no action needed

C. Remove BatchNorm layers before using DataParallel

D. Increase batch size to avoid BatchNorm problems

Solution

1. Step 1: Understand BatchNorm behavior in DataParallel

   BatchNorm computes stats per device, which can cause inconsistent normalization across GPUs.

2. Step 2: Recommended solutions

   Use SyncBatchNorm to sync stats or switch to DistributedDataParallel for correct BatchNorm behavior.

3. Final Answer:

   BatchNorm layers behave differently in DataParallel; use SyncBatchNorm or move to DistributedDataParallel -> Option A

4. Quick Check:

   BatchNorm needs syncing or DDP for multi-GPU [OK]

Hint: BatchNorm needs syncing or DDP on multiple GPUs [OK]

Common Mistakes:

• Assuming DataParallel handles BatchNorm correctly by default
• Removing BatchNorm layers unnecessarily
• Only increasing batch size without syncing stats