A model with 97% accuracy that only exists in your Python session is worth exactly zero to the business. The TecnoMarket team is clear about this: the review classifier from 04-03 only delivers value when the website can query it live, and the photo classifier from 05-03 only saves work when the warehouse system invokes it for every new product. This lesson closes the cycle that began with that timid model.save() in 02-05: you will learn the saving formats of Keras and PyTorch and when to use each, why the preprocessing must be saved together with the model, the options for serving predictions (from a batch script to a REST API with FastAPI, with a complete example), ONNX as a bridge between frameworks, and how to validate and watch over a model before and after deploying it. It is the last mile: where deep learning becomes a product.

1. Saving and loading in Keras: .keras, SavedModel and weights-only
2. Saving and loading in PyTorch: state_dict and checkpoints
3. The model does not travel alone: saving the preprocessing
4. Serving a model: options at scale
5. A REST API with FastAPI for TecnoMarket's reviews
6. ONNX: the bridge format
7. Validating before deploying and monitoring afterwards
8. TecnoMarket's deployment checklist

In 02-05 you ran model.save("tecnomarket-dl/models/mnist_dense_v1.keras") and moved on. Let's make it professional: Keras has three ways to save, each with its use case.

Practical note: the ModelCheckpoint from 06-01 writes in .keras format; you already had half this lesson learned.

PyTorch revolves around the state_dict: a {parameter_name: tensor} dictionary with all the model's weights. The canonical way to save is that dictionary, not the model object:

Why not save the whole model with torch.save(model, ...)? It can be done, but it serializes references to your code (class, module, paths): loading it months later with the project reorganized, it breaks. The state_dict is just named tensors: robust and portable. It is the analog of Keras's "weights only" — in PyTorch, the default option.

To resume a training run, the weights are not enough: Adam (02-04) keeps per-parameter internal statistics that must be restored too. The professional pattern:

Here is the mistake that breaks the most deployments, and it is conceptual, not technical. Your model learned from transformed data: if in production it receives raw data, or data transformed differently, its predictions will be garbage without raising any error. Remember two cases from the course:

• In 04-04, the demand predictor trained on sales scaled by a scaler fitted on the training set (carefully avoiding data leakage). If in production you feed it raw euros where it expected values in [0, 1], it will predict nonsense with complete self-confidence.
• In 04-03, the review classifier uses a TextVectorization layer whose vocabulary was learned from the training corpus. A different vocabulary = different indices = a different "language": the network would receive gibberish.

The golden rule: the (preprocessing, model) pair IS the deployable unit. They never travel separately.

Option A is the safest (impossible to desynchronize); B is the most flexible. Whichever you choose: same files versioned together, under the same version name.

"Deploying" does not always mean "standing up a server". There is a scale of options, from least to most complex, and the professional move is choosing the smallest one that covers the need:

A minimal batch script (sometimes the best architecture is the most boring one):

TF Serving and TorchServe stay noted on your radar: they are the natural evolution when scale starts to squeeze, and they consume precisely the "production" formats from the first part (SavedModel and packaged state_dict).

Let's serve the review classifier live. FastAPI is a modern, minimalist Python web framework, ideal for wrapping a model. Installation: pip install fastapi uvicorn.

Explanation of the decisions:

1. Load at startup: loading the model takes seconds; a prediction, milliseconds. Loading it on every request would kill the API. The load goes at module level.
2. Pydantic (BaseModel) defines and validates the input: if a JSON without text arrives, FastAPI returns a clear error automatically, without the model seeing anything.
3. The endpoint is POST because it sends data in the request body.
4. Thanks to option A (vectorizer inside), the API receives raw text: zero risk of desynchronized preprocessing.
5. The response includes the model version (traceability) and the human_review field: the same confidence threshold + human review queue pattern we designed in 03-04, now in production.

Start it and try it:

With this, any TecnoMarket system (the website, the customer service CRM) consumes the model with a simple HTTP request, knowing nothing about deep learning.

In 06-03 we noted down ONNX (Open Neural Network Exchange): a standard model interchange format. The idea: you train wherever you like, export to .onnx, and run with ONNX Runtime almost anywhere (Python, C#, Java, mobile...), without installing the source framework.

When it pays off: handing a model to a team working in another language or framework, unifying inference across models of different origins (exactly TecnoMarket's case after the 06-03 decision: Keras in production, PyTorch in exploration), or exploiting ONNX Runtime's inference optimizations. Minimal good practices: after exporting, compare the outputs of the original model and the ONNX one on a test batch (they must match up to decimals) — and remember that external preprocessing still travels separately, here too.

Deploying is not an act of faith; it is a process with two guards:

Before: validation on a frozen set. The team maintains a fixed and versioned test set (real reviews labeled by hand, never used for training — the anti-leakage discipline from 04-04 elevated to team policy). Every production candidate, whether Keras or PyTorch (the rule agreed in 06-03), must:

1. Match or beat the current production model's metrics on that set.
2. Also be checked on the critical segments (short reviews, new products): a model that is better "on average" can be worse exactly where it hurts most.
3. Pass a smoke test of the complete deployable unit: spin up the API with the final artifact and verify known predictions end to end.

Afterwards: monitoring data drift. The world changes and production data slowly moves away from the training data: TecnoMarket launches new categories, review vocabulary evolves ("BLE pairing doesn't work" did not exist in the original corpus). Performance decays in silence: no exception, no error log, just increasingly worse predictions. Minimal conceptual watch:

• Log every prediction with its confidence and the model version (that is why the API returns it).
• Watch indirect signals: the percentage of cases sent to human review rising, the confidence distribution shifting, and the human reviewers' corrections as a continuous sampling of the truth.
• Define the action threshold in advance: "if X worsens by more than Y for Z weeks, retrain with recent data" — and the retrained model goes through the frozen set again. The cycle closes.

The list the team goes through before every production release:

1. Model saved in the right format (.keras / state_dict) with a version name (reviews_v3), not final_model_GOOD.
2. Preprocessing saved and versioned together with the model (inside the graph or as a paired artifact).
3. Metrics on the frozen set ≥ the current model, critical segments included.
4. Random seeds, config and library versions recorded (the reproducibility from 06-04): this model can be rebuilt from scratch.
5. Smoke test of the deployable unit: API spun up locally, known predictions verified end to end.
6. The API response includes the model version and a confidence signal; doubtful cases go to the human review queue (03-04).
7. Active monitoring: prediction logging and drift alerts defined before launch, not after the first scare.
8. Rollback plan: the previous version (reviews_v2) stays archived and ready to restore in minutes.

• Deploying the model without its preprocessing (or with a different version of it): the number one silent failure. No error, just absurd predictions with high confidence. The deployable unit is the pair, always.
• torch.save(model, ...) of the whole object: works today, breaks when you refactor the project. State_dict + the class's code, as a rule.
• Forgetting model.eval() when loading in PyTorch for inference: with dropout active, every request to your API would give a different prediction for the same review (you saw it in 06-02; in production it is a baffling bug).
• Loading the model inside the endpoint: every request would take seconds and the API would crawl. Load once at startup; predict many times.
• Validating on a test set that changes: if every candidate is measured against different data, the comparisons mean nothing. Frozen and versioned set.
• Trusting that "if there are no errors, it works": degradation from data drift throws no exceptions. Without monitoring, your model may have been wrong for months by the time someone notices.
• Tip: after every save, do the full cycle in a clean interpreter: load, predict on 3 known examples, compare with the expected values. Thirty seconds that catch 90% of serialization problems.

For each situation, state the appropriate saving mechanism and why: (a) module 7's PyTorch training will take three nights on Colab and must be resumable every morning; (b) the Keras photo classifier must be handed to the platform team to serve it with TF Serving; (c) you want to archive the Keras review classifier to pick it up again (even retrain it) in six months; (d) the backend team, which programs in C# and does not want to install PyTorch, needs to run the fraud model.

The demand predictor from 04-04 is deployed as a batch script. In testing it had an 8% mean error; in production it predicts absurd quantities (thousands of units of a product that sells dozens), with no error in the logs. The script loads demand_v2.keras correctly and the database delivers the sales properly. What is the most likely cause, why does no error appear, and which two changes would you make to fix it and to keep it from happening again?

Extend review_api.py with a POST /classify_batch endpoint that receives a list of reviews (up to 100) and returns a list of results, taking advantage of the fact that the model predicts more efficiently in batches than one at a time. Also add a GET /health endpoint that returns {"status": "ok", "model_version": "reviews_v3"} and explain what it is for in production.

Solution 1:

• (a) Full PyTorch checkpoint (dict with model_state, optimizer_state and epoch) saved to Drive every epoch: resuming requires Adam's state, not just weights.
• (b) SavedModel (model.export(...)): it is the self-contained format TF Serving consumes directly.
• (c) .keras: a single file with architecture, weights and optimizer; in six months, load_model and carry on (retraining included).
• (d) ONNX: export with torch.onnx.export and deliver the .onnx; the backend runs it with ONNX Runtime for C#, no PyTorch. (After verifying the outputs match the original.)

Solution 2: Most likely cause: the script applies the scaler wrongly (or not at all) — it uses one refitted on other data, a desynchronized version, or feeds raw sales to a model that expected scaled values; forgetting the inverse transform of the output also fits. There is no error because the shapes and dtypes are valid: the model operates on "legal" numbers but at the wrong scale — the classic silent failure. Fixes: (1) deploy the pair as a unit — load demand_scaler_v2.joblib versioned alongside the model, same version suffix, and apply transform to the input and the inverse to the output; (2) add a smoke test to the checklist: after each deployment, predict on 3 known historical cases and compare with the expected values before writing anything to the purchasing table (plus a range validation: if the prediction falls outside the reasonable historical range, alert and do not publish).

Solution 3:

The efficiency key: a single call to model.predict with the 100 reviews (the batch parallelism running through the whole course), not 100 calls. The /health endpoint (health check) lets the infrastructure verify every few seconds that the API is alive and which version it serves: if it stops responding, it gets restarted or an alert fires automatically — and during a deployment it confirms the new version is actually live.

The circle opened by the model.save() of 02-05 closes. You now know how to save with judgment (.keras/SavedModel/weights in Keras; state_dict and checkpoints in PyTorch), you know the deployable unit is the preprocessing + model pair (the scaler from 04-04 and the vocabulary from 04-03 always travel with their network), you know how to choose the serving approach for the need (batch → FastAPI → model servers → edge), you have ONNX as a bridge between worlds, and you understand that deploying requires validating against a frozen set beforehand and monitoring data drift afterwards — all condensed into TecnoMarket's checklist.

And with this, module 6 is complete: you know TensorFlow from the inside, you speak PyTorch, you know how to choose between them, you work with a professional environment and discipline, and you take models all the way to production. Techniques (modules 2-5) and tools (module 6): the toolbox is full. In module 7 we will empty it entirely: we will build TecnoMarket's complete projects end to end — image classification, text generation, anomaly detection, a GAN and the fine-tuning of a pretrained model. It stops being a course; it starts being a portfolio.