TorchScript for production in PyTorch - Model Metrics & Evaluation

Metrics & Evaluation - TorchScript for production

Which metric matters for TorchScript in production and WHY

TorchScript is used to make PyTorch models ready for production. The key metric here is inference latency, which means how fast the model can give answers. Faster models make apps feel smooth and save money on servers.

Another important metric is model accuracy. When converting to TorchScript, the model should keep its original accuracy. If accuracy drops, the model is not reliable.

Finally, model size matters because smaller models use less memory and load faster.

Confusion matrix or equivalent visualization

For TorchScript, we check if predictions before and after scripting match. Here is a simple example with 5 samples:

Original Model Predictions: [1, 0, 1, 1, 0]
TorchScript Predictions:     [1, 0, 1, 1, 0]
    

All predictions match, so the conversion kept accuracy.

Precision vs Recall tradeoff with concrete examples

While TorchScript itself does not change precision or recall, it is important to verify these metrics stay the same after conversion.

For example, if your model detects spam emails:

• Precision means how many emails marked as spam really are spam.
• Recall means how many spam emails your model finds out of all spam emails.

If TorchScript conversion lowers recall, your app might miss spam emails. If it lowers precision, good emails might be wrongly marked as spam.

So, always check precision and recall before and after scripting to keep the balance.

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

Good:

• Inference latency reduced by 20% or more compared to original model.
• Accuracy, precision, recall unchanged or within 1% difference.
• Model size reduced or stays the same.

Bad:

• Inference latency is the same or slower.
• Accuracy drops by more than 2%.
• Model size grows significantly, causing memory issues.

Metrics pitfalls when using TorchScript

• Accuracy drop: Sometimes scripting changes model behavior, causing lower accuracy.
• Data leakage: If test data leaks into training, metrics look better but are not real.
• Overfitting: Good training metrics but poor real-world performance.
• Ignoring latency: Only checking accuracy but ignoring speed can cause slow apps.
• Not testing on real inputs: TorchScript may fail on some input types if not tested well.

Self-check question

Your TorchScript model has 98% accuracy but 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.

Key Result

TorchScript should keep model accuracy stable while reducing inference latency for smooth production use.

Practice

1. What is the main purpose of using TorchScript in PyTorch?

easy

A. To increase the size of the model for better accuracy

B. To visualize model training progress

C. To convert PyTorch models into a format optimized for production use

D. To automatically generate training data

Solution

1. Step 1: Understand TorchScript's role

   TorchScript is designed to convert PyTorch models into a form that can run faster and be deployed easily in production environments.

2. Step 2: Compare options

   Options A, B, and D describe unrelated tasks like visualization, model size increase, or data generation, which are not the purpose of TorchScript.

3. Final Answer:

   To convert PyTorch models into a format optimized for production use -> Option C

4. Quick Check:

   TorchScript purpose = convert for production [OK]

Hint: TorchScript = production-ready model format [OK]

Common Mistakes:

• Confusing TorchScript with visualization tools
• Thinking TorchScript generates data
• Assuming TorchScript increases model size

2. Which of the following is the correct way to save a TorchScript model after scripting?

easy

A. torch.save(model, 'model.pt')

B. torchscript.save_model(model, 'model.pt')

C. model.save('model.pt')

D. scripted_model.save('model.pt')

Solution

1. Step 1: Recall TorchScript saving method

   After scripting a model, the resulting scripted model object has a save() method to save it to disk.

2. Step 2: Evaluate options

   torch.save(model, 'model.pt') uses torch.save which is for regular PyTorch models, not scripted ones. model.save('model.pt') is invalid as model.save() does not exist. torchscript.save_model(model, 'model.pt') is not a valid PyTorch API.

3. Final Answer:

   scripted_model.save('model.pt') -> Option D

4. Quick Check:

   Use scripted_model.save() to save TorchScript [OK]

Hint: Use scripted_model.save() to save TorchScript models [OK]

Common Mistakes:

• Using torch.save() instead of scripted_model.save()
• Calling save() on the original model
• Assuming torchscript.save_model() exists

3. Given the code below, what will be the output printed?

import torch
class MyModule(torch.nn.Module):
    def forward(self, x):
        return x * 2

model = MyModule()
scripted = torch.jit.script(model)
print(scripted(torch.tensor(3)))

medium

A. tensor(6)

B. tensor(3)

C. 6

D. Error: scripting failed

Solution

1. Step 1: Understand the model's forward method

   The model multiplies input by 2, so input 3 becomes 6.

2. Step 2: Check scripting and output

   The model is scripted successfully, so calling scripted(torch.tensor(3)) returns tensor(6).

3. Final Answer:

   tensor(6) -> Option A

4. Quick Check:

   Input 3 * 2 = tensor(6) [OK]

Hint: Model doubles input; output = input * 2 [OK]

Common Mistakes:

• Confusing tensor(6) with integer 6
• Expecting error from scripting simple model
• Ignoring tensor wrapper in output

4. What is the error in the following code snippet when trying to trace a model?

import torch
class MyModel(torch.nn.Module):
    def forward(self, x):
        if x.sum() > 0:
            return x * 2
        else:
            return x - 2

model = MyModel()
example_input = torch.tensor([1.0, -1.0])
traced = torch.jit.trace(model, example_input)

medium

A. Syntax error in model definition

B. Tracing fails because the model has data-dependent control flow

C. example_input must be a scalar tensor

D. No error, tracing works fine

Solution

1. Step 1: Identify model control flow

   The model uses an if-statement depending on input data (x.sum() > 0), which is data-dependent control flow.

2. Step 2: Understand tracing limitation

   Tracing records operations from example input but cannot capture data-dependent branches, so it will not handle this correctly.

3. Final Answer:

   Tracing fails because the model has data-dependent control flow -> Option B

4. Quick Check:

   Tracing can't handle data-dependent control flow [OK]

Hint: Tracing fails if model has if/else based on input data [OK]

Common Mistakes:

• Assuming tracing works with all control flow
• Thinking example_input shape causes error
• Ignoring data-dependent branching

5. You want to deploy a PyTorch model with dynamic control flow and save it for production. Which approach is best to create a TorchScript model that handles this correctly?

hard

A. Use torch.jit.script() to convert the model

B. Rewrite the model to remove all control flow before tracing

C. Save the original PyTorch model with torch.save()

D. Use torch.jit.trace() with a fixed example input

Solution

1. Step 1: Identify model characteristics

   The model has dynamic control flow, meaning decisions depend on input data during execution.

2. Step 2: Choose correct TorchScript method

   torch.jit.script() analyzes the model code and supports dynamic control flow, unlike tracing which only records fixed operations.

3. Step 3: Evaluate other options

   Use torch.jit.trace() with a fixed example input (tracing) fails with dynamic control flow. Save the original PyTorch model with torch.save() saves the model but not in optimized TorchScript form. Rewrite the model to remove all control flow before tracing is impractical and changes model logic.

4. Final Answer:

   Use torch.jit.script() to convert the model -> Option A

5. Quick Check:

   Dynamic control flow needs scripting, not tracing [OK]

Hint: Use scripting for models with dynamic control flow [OK]

Common Mistakes:

• Using tracing for dynamic control flow models
• Saving without TorchScript conversion
• Trying to remove control flow instead of scripting