TensorFlow and PyTorch Model Engineering

Introduction and Context

Modern machine-learning practice requires more than selecting an algorithm. A practitioner must represent data as tensors, construct differentiable models, execute efficient training loops, manage hardware, save reproducible artifacts, and deploy models safely. TensorFlow and PyTorch are the two most influential open-source ecosystems for these tasks. Although they differ in programming style and tooling, both implement the same underlying computational ideas: tensor operations, parameterized functions, automatic differentiation, optimization, data pipelines, evaluation, and model serialization.

TensorFlow is strongly associated with Keras, a high-level API that supports concise model construction, standardized training workflows, callbacks, and deployment through the TensorFlow ecosystem. PyTorch emphasizes Pythonic imperative programming, explicit control of computation, and user-defined modules and training loops. Current versions of both frameworks support eager execution, graph or compilation optimizations, accelerator hardware, mixed precision, distributed training, and pretrained models.

This chapter develops equivalent models in both frameworks and explains how engineering decisions affect correctness, performance, maintainability, and deployment. The examples use a multiclass image-classification problem, but the principles apply to tabular, text, audio, and multimodal systems.

Learning Objectives

After studying this chapter, a student should be able to:

1. Explain the roles of tensors, layers, modules, losses, optimizers, and automatic differentiation.

2. Construct equivalent neural networks using Keras/TensorFlow and PyTorch.

3. Prepare datasets and distinguish training, validation, and test responsibilities.

4. Write and analyze training and evaluation loops.

5. Use devices, checkpoints, callbacks, mixed precision, and compilation appropriately.

6. Select TensorFlow or PyTorch according to project requirements rather than personal preference alone.

7. Identify reproducibility, deployment, security, and governance risks in model engineering.

1. A Common Computational Model

A neural network is a parameterized function. For an input tensor x, a model produces an output f(x; theta), where theta denotes trainable parameters. During supervised classification, the model output is compared with a target y using a loss function. Training seeks parameters that reduce loss on the training data while preserving performance on unseen data.

A typical workflow is:

1. Acquire and validate data.

2. Transform examples into tensors with consistent shape, type, and scale.

3. Define a model.

4. Select a loss function and optimizer.

5. Train using minibatches.

6. Evaluate on validation and test data.

7. Save the model, configuration, preprocessing logic, and metadata.

8. Deploy and monitor the resulting system.

The framework does not remove the need for design judgment. Incorrect labels, data leakage, inappropriate metrics, or inconsistent preprocessing cannot be repaired by an elegant API.

Tensors

A tensor is a multidimensional array with a data type, shape, and often an associated device. A scalar has rank zero, a vector rank one, a matrix rank two, and an image batch commonly has rank four. For example, a batch of RGB images may have shape (B, H, W, 3) in the TensorFlow convention or (B, 3, H, W) in the conventional PyTorch convolutional representation. B is batch size, H and W are height and width, and 3 is the number of color channels.

Shape and layout errors are among the most common engineering failures. A tensor may have the correct number of values but still be incompatible with a layer because its dimensions are ordered incorrectly. Data types also matter: model inputs are normally floating-point tensors, while class labels for sparse categorical loss are typically integer tensors.

Parameters, modules, and layers

A layer is a transformation such as a convolution, affine transformation, normalization operation, or activation. A model is a composition of layers. In Keras, layers and models generally inherit from Layer or Model. In PyTorch, trainable computations are organized through nn.Module. Parameters registered inside these structures are discovered by optimizers and included in serialization.

A model may be represented as

h^(l+1) = phi(W^(l)h^(l) + b^(l)),

where h^(l) is the input to layer l, W and b are trainable weights and biases, and phi is an activation function. This expression assumes compatible dimensions and describes a dense layer; convolutional layers replace matrix multiplication with a local spatial operation.

Automatic differentiation

Both frameworks construct or track a computation from which gradients can be calculated. If L(theta) is the minibatch loss, gradient descent updates parameters according to

theta <- theta - eta grad_theta L(theta),

where eta is the learning rate. This rule assumes that the gradient is evaluated at the current parameters and that the optimizer is using the conventional descent sign. Practical optimizers such as Adam modify the update using running estimates of gradients and squared gradients. The framework computes derivatives; the practitioner remains responsible for selecting a suitable loss, learning rate, batch size, and stopping strategy.

2. TensorFlow and Keras Engineering

TensorFlow provides tensor operations, automatic differentiation, accelerators, distributed execution, and deployment tools. Keras provides a user-facing modeling interface. Three common Keras approaches are:

• Sequential models for a simple linear stack of layers.
• The Functional API for directed acyclic graphs with multiple inputs or outputs.
• Subclassing for custom behavior and complex research models.

A Sequential model is readable when each layer has one input and one output. The Functional API is preferable for skip connections, shared layers, and multi-input systems. Subclassing offers maximum flexibility but requires more explicit testing.

A compact classifier can be defined as follows:

```python

import tensorflow as tf

from tensorflow import keras

from tensorflow.keras import layers

model = keras.Sequential([

layers.Input(shape=(28, 28, 1)),

layers.Conv2D(32, 3, activation="relu"),

layers.MaxPooling2D(),

layers.Conv2D(64, 3, activation="relu"),

layers.GlobalAveragePooling2D(),

layers.Dense(10) # logits

])

model.compile(

optimizer=keras.optimizers.Adam(learning_rate=1e-3),

loss=keras.losses.SparseCategoricalCrossentropy(from_logits=True),

metrics=[keras.metrics.SparseCategoricalAccuracy(name="accuracy")]

)

```

The final layer produces ten logits rather than probabilities. For class k, a softmax probability is

p_k = exp(z_k) / sum_j exp(z_j),

where z_k is the kth logit. When `from_logits=True`, the loss applies a numerically stable combined softmax-and-cross-entropy calculation. Applying softmax in the model and also specifying `from_logits=True` is a configuration error. Conversely, if the model outputs probabilities, `from_logits` must be false.

A standard Keras training call is:

```python

callbacks = [

keras.callbacks.EarlyStopping(

monitor="val_loss", patience=3, restore_best_weights=True

),

keras.callbacks.ModelCheckpoint(

"best.keras", monitor="val_loss", save_best_only=True

)

]

history = model.fit(

train_ds,

validation_data=validation_ds,

epochs=30,

callbacks=callbacks

)

```

`compile` configures the loss, metrics, and optimizer. `fit` supplies a standardized training loop. Callbacks can implement early stopping, learning-rate schedules, checkpointing, logging, and custom interventions. Keras is efficient for conventional workflows, but abstraction can conceal details such as gradient accumulation or unusual multi-stage objectives.

For custom behavior, `tf.GradientTape` records operations and computes gradients:

```python

loss_fn = keras.losses.SparseCategoricalCrossentropy(from_logits=True)

optimizer = keras.optimizers.Adam(1e-3)

for x_batch, y_batch in train_ds:

with tf.GradientTape() as tape:

logits = model(x_batch, training=True)

loss = loss_fn(y_batch, logits)

gradients = tape.gradient(loss, model.trainable_variables)

optimizer.apply_gradients(zip(gradients, model.trainable_variables))

```

This loop makes the training procedure visible and is useful when implementing custom losses, multiple optimizers, gradient clipping, or adversarial objectives. `model.fit` and a custom loop can produce different behavior if regularization, training mode, metric updates, or reduction conventions are handled inconsistently.

3. PyTorch Model Engineering

PyTorch models are commonly defined by subclassing `torch.nn.Module`. The `forward` method describes the computation. Layers assigned as attributes are registered, allowing `model.parameters()` to expose trainable parameters.

```python

import torch

from torch import nn

class Classifier(nn.Module):

def __init__(self, number_of_classes=10):

super().__init__()

self.features = nn.Sequential(

nn.Conv2d(1, 32, kernel_size=3),

nn.ReLU(),

nn.MaxPool2d(2),

nn.Conv2d(32, 64, kernel_size=3),

nn.ReLU(),

nn.AdaptiveAvgPool2d((1, 1))

)

self.classifier = nn.Linear(64, number_of_classes)

def forward(self, x):

x = self.features(x)

x = torch.flatten(x, 1)

return self.classifier(x) # logits

model = Classifier().to(device)

loss_fn = nn.CrossEntropyLoss()

optimizer = torch.optim.Adam(model.parameters(), lr=1e-3)

```

`CrossEntropyLoss` expects unnormalized logits and integer class indices. It combines a log-softmax operation with negative log likelihood, so an explicit softmax should normally not be placed before it.

A basic training loop is:

```python

for epoch in range(num_epochs):

model.train()

for x_batch, y_batch in train_loader:

x_batch = x_batch.to(device)

y_batch = y_batch.to(device)

optimizer.zero_grad(set_to_none=True)

logits = model(x_batch)

loss = loss_fn(logits, y_batch)

loss.backward()

optimizer.step()

```

Evaluation must disable training-specific behavior and gradient tracking:

```python

model.eval()

correct = total = 0

with torch.no_grad():

for x_batch, y_batch in validation_loader:

logits = model(x_batch.to(device))

predictions = logits.argmax(dim=1)

correct += (predictions == y_batch.to(device)).sum().item()

total += y_batch.size(0)

accuracy = correct / total

```

`model.train()` enables training behavior in layers such as dropout and batch normalization. `model.eval()` selects inference behavior. `torch.no_grad()` reduces memory use by preventing gradient tracking; it does not itself switch dropout or batch normalization to evaluation mode.

The optimizer accumulates gradients by default. Therefore, `zero_grad` is required before each independent update unless deliberate gradient accumulation is being used. With accumulation over k batches, gradients may be retained for k iterations and the optimizer stepped afterward; loss scaling and effective batch size must then be considered.

4. Datasets, Batching, and Data Integrity

TensorFlow commonly represents input data through `tf.data.Dataset`, while PyTorch uses `Dataset` and `DataLoader`. Both support mapping or transformation, batching, shuffling, prefetching, and parallel loading.

A robust input pipeline should define:

• source files and label construction;
• resizing, normalization, and augmentation;
• data types and tensor layouts;
• training, validation, and test partitions;
• behavior for corrupt or missing examples;
• random seeds and provenance metadata.

Augmentation should generally be applied only to training examples. Validation and test data should represent the intended evaluation distribution. Splitting after near-duplicate or patient-level records have been distributed can create leakage and unrealistically high scores.

Normalization must be consistent between training and inference. If an image channel is transformed using x' = (x - mu) / sigma, the same mu and sigma, calculated from the designated training data, must be used when serving predictions. Storing preprocessing configuration with the model is therefore essential.

5. Devices, Performance, and Compilation

A device is the execution location for tensors and model parameters, such as a CPU, CUDA GPU, or specialized accelerator. In PyTorch, tensors and models must usually be moved to the same device explicitly. TensorFlow often places operations automatically but also supports explicit device scopes and distribution strategies.

Performance depends on more than GPU availability. Bottlenecks may arise from disk access, Python overhead, data decoding, small batches, synchronization, or excessive host-device transfers. Useful practices include:

• profile before optimizing;
• prefetch and parallelize input loading;
• use sufficiently large but memory-safe batches;
• avoid transferring individual examples repeatedly;
• keep tensor shapes and data types consistent;
• verify that the accelerator is actually utilized.

Compilation can reduce Python overhead and fuse operations. TensorFlow can trace functions using `tf.function`; Keras may also use graph execution through its training APIs. PyTorch provides compilation through `torch.compile`, which attempts to optimize eligible model execution. Compilation may have warm-up cost, graph breaks, unsupported operations, or changed debugging behavior. It should be validated for numerical correctness and measured on representative workloads rather than assumed to improve every model.

6. Checkpoints, Reproducibility, and Experiment Management

A checkpoint is a saved training state. A complete training checkpoint may include model parameters, optimizer state, scheduler state, epoch or step number, random-state information, and configuration. Saving only weights may be sufficient for inference but is insufficient for exact training resumption when optimizer momentum or adaptive statistics matter.

PyTorch commonly saves a state dictionary:

```python

torch.save({

"model": model.state_dict(),

"optimizer": optimizer.state_dict(),

"epoch": epoch,

"config": config

}, "checkpoint.pt")

```

TensorFlow/Keras supports the `.keras` format for model architecture, weights, and relevant configuration, as well as checkpoint mechanisms for weights or training state. The selected format should be documented and tested by loading it in a clean environment.

Reproducibility is not identical to repeating a single random seed. It includes fixed code versions, data snapshots, preprocessing, hyperparameters, hardware details, random seeds, and known nondeterministic operations. Deterministic execution can reduce performance and may not be available for every operation. A professional experiment record should report both the intended seed and the observed software and hardware environment.

7. Mixed Precision and Numerical Reliability

Mixed precision uses lower-precision arithmetic, such as float16 or bfloat16, for selected operations while retaining sufficient precision for sensitive calculations. It can reduce memory consumption and increase throughput on supported hardware. However, underflow, overflow, loss scaling, and unsupported operations can affect stability.

TensorFlow provides mixed-precision policies; PyTorch commonly uses `torch.autocast` together with `GradScaler` for float16 workloads. A simplified PyTorch pattern is:

```python

scaler = torch.amp.GradScaler("cuda")

for x_batch, y_batch in train_loader:

optimizer.zero_grad(set_to_none=True)

with torch.autocast(device_type="cuda", dtype=torch.float16):

loss = loss_fn(model(x_batch.to(device)), y_batch.to(device))

scaler.scale(loss).backward()

scaler.step(optimizer)

scaler.update()

```

The exact API can vary by framework version and device. Mixed precision should be introduced after establishing a correct full-precision baseline. Compare loss curves, validation metrics, convergence, and inference outputs. Do not assume that a faster training run is a better run.

8. Transfer Learning and Pretrained Ecosystems

Pretrained models provide parameters learned from a large source dataset. Transfer learning can reduce data requirements and training time, but source and target domains may differ. A common strategy is to replace the final classification head, freeze much of the backbone initially, train the new head, and then fine-tune selected layers with a smaller learning rate.

TensorFlow Hub, Keras applications, and PyTorch ecosystem libraries such as TorchVision provide pretrained architectures and weights. A practitioner must verify the license, training data description, input normalization, expected image size, class mapping, and known limitations. A model pretrained on ordinary photographs may perform poorly on medical images or industrial sensors despite a high source-dataset score.

9. Worked Example: Equivalent Training Decisions

Suppose a four-class image dataset contains 12,000 training examples and 2,000 validation examples. Images are resized to 64 by 64 pixels and represented with three channels. A batch size of 32 is selected.

The number of training minibatches per epoch is the ceiling of 12,000 divided by 32, which is 375 exactly. If the optimizer updates once per minibatch, there are 375 parameter updates per epoch. With 20 epochs, the planned number of updates is 7,500, assuming no early stopping or skipped batches.

Both frameworks can implement the same architecture: two convolutional blocks, global average pooling, and a four-unit linear classifier. To make results comparable, the following must match: data partition, normalization, augmentation, batch size, optimizer family, learning rate, loss interpretation, initialization policy where possible, evaluation metric, and checkpoint selection rule.

If TensorFlow reports validation accuracy after every epoch while PyTorch evaluates only every fifth epoch, the results are not directly comparable for early stopping. Similarly, using a probability output with a logits-based loss in one implementation creates a different and incorrect experiment. Equivalence means matching semantics, not merely using layers with similar names.

10. Illustrative Case: Defect Detection in Manufacturing

Background

An illustrative manufacturing company wants to classify images of components into four categories: acceptable, scratch, dent, and contamination. The inspection camera produces images at high volume, and false negatives are costly because defective parts may reach customers.

Problem

The engineering team initially reports 98 percent accuracy. Investigation shows that images from the same production batch appear in both training and test sets. In addition, the deployed camera uses a different brightness range from the training camera. The system therefore performs poorly in production.

Analysis

The primary failure is not the choice between TensorFlow and PyTorch. It is an invalid evaluation design and an untracked preprocessing dependency. The team also discovers that the minority defect classes are underrepresented, so accuracy hides poor recall for contamination.

Approach and Solution

The data is repartitioned by production batch, ensuring that visually related images remain in one split. Training augmentation simulates realistic illumination variation, while validation and test images remain unmodified except for documented resizing and normalization. The team reports per-class precision, recall, a confusion matrix, and the cost of false negatives.

A Keras baseline is built with `model.fit`, early stopping, and best-validation-loss checkpointing. A PyTorch implementation is created with an explicit loop to support a custom class-weighted loss and detailed logging. Both implementations use the same pretrained backbone, input normalization, and batch construction. A calibration set is held out for selecting an operational decision threshold.

The deployment package includes the model, class order, preprocessing code, framework version, checkpoint identifier, and model card. A monitoring process tracks input brightness, class frequencies, confidence distributions, and confirmed defect rates. When the camera is replaced, the system is revalidated rather than silently updated.

Outcome

The headline accuracy falls from 98 percent to 93 percent under the leakage-free test, but recall for the costly defect class improves substantially and production performance becomes predictable. The lower headline score is evidence of more honest evaluation, not necessarily a worse system.

Learning Points

The case demonstrates that framework selection is secondary to data governance, valid splitting, metric choice, reproducibility, and monitoring. TensorFlow is convenient for standardized training and deployment pipelines; PyTorch is convenient when the team needs highly explicit custom training behavior. Either can support a reliable system when engineering controls are applied.

11. Framework Selection and Professional Practice

TensorFlow/Keras is often advantageous when a team values concise standard training, integrated serving tools, browser or mobile deployment options, and mature production pipelines. PyTorch is often advantageous when researchers require transparent imperative code, rapid experimentation, custom differentiation, and broad research-library integration. These are tendencies rather than absolute rules; both ecosystems are capable of research and production.

Selection criteria should include:

• model and operator support;
• target hardware and deployment environment;
• team expertise and maintenance capacity;
• debugging and profiling requirements;
• interoperability needs;
• licensing and dependency constraints;
• serving latency, memory, and reliability targets;
• availability of pretrained models;
• long-term support and security practices.

Ethical and governance responsibilities include documenting data provenance, protecting personal and confidential data, controlling checkpoint access, scanning dependencies, recording model limitations, testing subgroup performance, and preventing unauthorized model replacement. A checkpoint is a potentially executable or sensitive artifact and should be treated as part of the software supply chain.

12. Contemporary Developments and Best Practices

Current model engineering increasingly combines eager development with compiled execution, distributed training, parameter-efficient fine-tuning, quantization, and standardized model exchange. ONNX and other interoperability mechanisms can help move models between tools, but conversion must be tested because operators, dynamic shapes, preprocessing, and numerical behavior may differ.

Recommended practice is to begin with a small, correct baseline. Unit-test tensor shapes, label ranges, preprocessing, loss behavior, checkpoint restoration, and evaluation code. Overfit a tiny batch as a diagnostic: a sufficiently expressive model should usually reduce training loss substantially on a tiny clean sample. Then establish a reproducible full-precision experiment before introducing compilation, distributed execution, or mixed precision. Profile bottlenecks, record configurations, compare equivalent implementations with controlled experiments, and validate the complete inference pipeline rather than the neural network in isolation.

Chapter Summary

TensorFlow/Keras and PyTorch provide different interfaces to largely shared neural-network concepts: tensors, registered parameters, layers or modules, automatic differentiation, losses, optimizers, datasets, and evaluation. Keras offers standardized workflows through `compile`, `fit`, and callbacks, while PyTorch commonly exposes model behavior and training through explicit modules and loops. Correct model engineering requires matching tensor shapes, data types, logits and probability conventions, training and evaluation modes, preprocessing, and checkpoint semantics. Devices, compilation, mixed precision, and data pipelines can improve efficiency but must be measured and validated. Pretrained models accelerate development while introducing domain, licensing, and compatibility considerations. Framework selection should follow project requirements, deployment constraints, team capabilities, and governance obligations. Reliable AI systems depend at least as much on data integrity, reproducibility, monitoring, and responsible evaluation as on framework choice.

Key Terms

Tensor: A multidimensional array with shape, data type, and usually a device.

Layer: A parameterized or non-parameterized transformation in a neural network.

Module: PyTorch’s object-oriented container for computation and registered parameters.

Logit: An unnormalized score produced before softmax conversion.

Softmax: A function that converts a vector of scores into values summing to one.

Automatic differentiation: Computation of derivatives by tracking operations in a computational graph.

Optimizer: An algorithm that updates trainable parameters using gradients.

Minibatch: A subset of examples used for one gradient update.

Epoch: One complete pass through the training dataset.

Callback: A hook that performs actions during standardized Keras training.

Checkpoint: A saved model or training state used for inference, recovery, or resumption.

Mixed precision: Use of multiple numerical precisions to improve speed or memory efficiency.

Eager execution: Immediate operation execution that supports interactive, imperative programming.

Compilation: Transformation of model computations into an optimized executable representation.

Data leakage: Unintended use of information from evaluation data during training or design.

Transfer learning: Reuse and adaptation of parameters learned from another task or dataset.

Data loader: A component that batches, shuffles, and supplies examples to training.

Reproducibility: Ability to repeat or audit results using recorded data, code, configuration, and environment.

Model serving: Operational delivery of model predictions to users or software systems.

Model card: Documentation describing a model’s intended use, performance, limitations, and risks.

Review Questions

Short Answer Questions

1. What is the difference between a tensor’s shape and its data type?

2. Why should a model using `CrossEntropyLoss` normally output logits rather than softmax probabilities?

3. What is the purpose of calling `model.eval()` in PyTorch?

4. How does a checkpoint containing optimizer state differ from one containing only model weights?

5. Why must validation and test preprocessing be consistent with deployment preprocessing?

Long Answer Questions

1. Compare Sequential, Functional API, and subclassed model construction in Keras. Give an appropriate use case for each.

2. Explain the principal steps in a PyTorch training loop and the role of each step.

3. Discuss how data leakage can produce misleading evaluation results and propose controls to prevent it.

4. Explain the benefits and risks of mixed precision and describe how it should be introduced into a project.

5. Develop a framework-selection argument for a production project that requires custom training, mobile deployment, and long-term maintainability.

Analytical / Application Questions

1. A team uses a sigmoid or softmax layer before a loss configured with `from_logits=True`. Analyze the error and specify two correct alternatives.

2. Design an experiment to determine whether a TensorFlow and PyTorch implementation are genuinely equivalent. Identify the variables that must be controlled.

3. A model has high overall accuracy but poor recall for a rare safety-critical class. Recommend an evaluation, training, and deployment strategy, explaining the trade-offs.

Multiple Choice Questions with Answers

Question 1

Which loss configuration is appropriate when a Keras classifier outputs raw class scores?

A. SparseCategoricalCrossentropy(from_logits=True)

B. MeanSquaredError with labels converted to strings

C. BinaryCrossentropy applied after removing all but one class

D. SparseCategoricalCrossentropy(from_logits=False) with no softmax computation

Correct Answer: A. SparseCategoricalCrossentropy(from_logits=True)

Question 2

What does PyTorch model.eval() primarily do?

A. Deletes gradients from all parameters

B. Switches layers such as dropout and batch normalization to evaluation behavior

C. Moves the model automatically to the GPU

D. Resets the optimizer state

Correct Answer: B. Switches layers such as dropout and batch normalization to evaluation behavior

Question 3

If a dataset has 12,000 examples and the batch size is 32, how many minibatches are processed in one epoch when all examples are used?

A. 32

B. 256

C. 375

D. 384

Correct Answer: C. 375

Question 4

Why is optimizer.zero_grad() normally called before a new PyTorch update?

A. PyTorch otherwise accumulates gradients from previous updates

B. It converts logits into probabilities

C. It changes the model to evaluation mode

D. It saves the model parameters to disk

Correct Answer: A. PyTorch otherwise accumulates gradients from previous updates

Question 5

Which statement best describes mixed precision?

A. It always replaces every tensor with integer values

B. It uses selected lower-precision operations while managing numerical sensitivity

C. It prevents the use of accelerators

D. It guarantees higher validation accuracy

Correct Answer: B. It uses selected lower-precision operations while managing numerical sensitivity

Question 6

Which practice most directly prevents leakage from visually related production images?

A. Increasing the number of epochs

B. Using a larger final classification layer

C. Splitting data by production batch or related group

D. Applying softmax twice

Correct Answer: C. Splitting data by production batch or related group

Question 7

What is a key advantage of a checkpoint that includes optimizer state?

A. It makes labels unnecessary

B. It permits more faithful resumption of training

C. It guarantees freedom from bias

D. It automatically changes the model architecture

Correct Answer: B. It permits more faithful resumption of training

Question 8

Which PyTorch component commonly handles batching, shuffling, and parallel data loading?

A. DataLoader

B. CrossEntropyLoss

C. GradScaler

D. ModuleList only

Correct Answer: A. DataLoader

Question 9

What is the main purpose of a validation set?

A. To replace the training set during optimization

B. To tune decisions and monitor generalization without using the final test estimate

C. To store optimizer momentum

D. To ensure every class has identical pixel values

Correct Answer: B. To tune decisions and monitor generalization without using the final test estimate

Question 10

Which consideration is most relevant when selecting between TensorFlow and PyTorch?

A. The framework’s logo color

B. Whether all models have identical source code

C. Deployment targets, team skills, operator support, and maintenance requirements

D. The number of comments in the training script

Correct Answer: C. Deployment targets, team skills, operator support, and maintenance requirements