You now master the two big frameworks and know when to use each. But there is an uncomfortable truth the TecnoMarket team discovered when reviewing their work from the last few modules: almost everything lives in loose Colab tabs, with cells run out of order, results nobody can reproduce and models saved under names like final_model_v2_GOOD.keras. In 01-05 you set up the basic environment; this lesson makes it professional: you will understand the real hardware and platform options (Colab and its limits, alternatives, a local GPU), how to go from notebook to a reproducible project with scripts and random seeds, how to apply version control to an ML project (and what NOT to push to git), how to monitor training runs with TensorBoard, and where to keep learning once the course ends.

1. Colab in depth: what it gives and what it limits
2. Alternatives: Kaggle Notebooks and other platforms
3. Working locally with a GPU: CUDA and cuDNN
4. From notebook to project: structure and scripts
5. Reproducibility: random seeds and configuration
6. Version control for ML
7. Monitoring training runs with TensorBoard
8. Where to keep learning
9. TecnoMarket's working environment

Google Colab, your companion since 01-05, is a notebook service with a free GPU. It pays to know its rules of the game:

The two limitations that hurt most in practice:

• The disk is ephemeral. Anything you do not save elsewhere (Google Drive, manual download) disappears when the session ends. That is why the ModelCheckpoint from 06-01 pointing at Drive is a lifesaver: if Colab disconnects at epoch 40 of 50, the best model is safe.
• Sessions get cut off. Multi-hour training runs are not reliably feasible on the free plan. Rule of thumb: free Colab for learning and prototyping (this whole course fits there); Pro for serious personal projects; your own hardware or the cloud for sustained professional work.

• Kaggle Notebooks: the most direct free alternative to Colab. It offers a GPU with a weekly quota of hours, plus two advantages of its own: the platform's datasets mount with one click (no downloads), and the public notebooks from competitions are a goldmine of real applied techniques — reading winning solutions is among the most instructive things you can do.
• Papers with Code: not an execution environment but an index that links every paper with its implementation and its benchmarks. When we talked about ResNet in 03-03 or transformers in 05-05, that is where you would find each architecture's reference code and the state of the art of each task.
• Pay-as-you-go cloud (the big providers and GPU-specialized platforms): you rent a GPU machine by the hour. It is the natural step when a serious training run no longer fits in Colab but does not justify buying hardware. Keep it on your radar; you do not need it for this course.

If you have (or are considering buying) a PC with an NVIDIA GPU, you can train locally without session limits. Understand the layers conceptually, because installation errors are almost always a mismatch between them:

• CUDA is NVIDIA's platform for running general-purpose computation on the GPU.
• cuDNN is a library on top of CUDA with the deep learning operations (the convolutions from 03-02, the LSTMs from 04-02) ultra-optimized. Both frameworks use it underneath: that is why their performance ties (06-03).
• Version compatibility (driver ↔ CUDA ↔ cuDNN ↔ framework) is the classic source of headaches. Good news: current versions of PyTorch (and TensorFlow via pip) bundle the necessary CUDA libraries; usually a reasonably up-to-date NVIDIA driver plus the install command shown on each framework's official website is enough.
• Without an NVIDIA GPU there is no CUDA: on Apple Silicon Macs the frameworks use the built-in GPU by another route (Metal/MPS), and on any machine the CPU always works, just more slowly (for the dense networks in this course, perfectly viable).

Verification in both frameworks (always your first step in a fresh environment):

Notebooks are perfect for exploring but terrible as a final product: cells executable in any order, hidden state in memory, hard to version and to automate. The professional transition is moving the stable code into scripts inside a project structure. The tecnomarket-dl/ folder you created in 01-05 grows like this:

The recommended workflow, which is the one TecnoMarket adopts:

1. Explore in a notebook (notebooks/): try ideas, visualize data, iterate fast.
2. Consolidate into src/: when something works, it becomes functions inside modules.
3. Train by script: python src/train.py always produces the same process end to end, runnable by anyone on the team (or by a machine, every night).

A minimal train.py with external configuration:

Why separate the configuration? Because every experiment ends up described by a file: changing the dropout is no longer editing code, it is editing a value; and comparing two experiments is comparing two configs. This is the handcrafted precursor of the tracking tools we will meet shortly.

Two "identical" training runs give different results: random weight initialization (02-01), batch shuffling, dropout (05-04)... To truly compare experiments, fix the random seeds at the top of the script:

Honest nuances:

• With fixed seeds, two runs on the same machine and versions will (almost always) be identical.
• Some GPU operations are non-deterministic by design (for performance); full determinism requires extra options and a speed cost. For everyday work, fixing seeds is enough: it turns "results that dance around" into "comparable results".
• Complete reproducibility is seeds + library versions (your requirements.txt from 01-05, ideally with pinned versions: tensorflow==2.16.1) + configuration (the config.yaml) + the same data.

Git lets you keep the project's history, go back to any point and collaborate without stepping on each other. The basic cycle applied to tecnomarket-dl/:

Git is designed for text (code, configs). Large binary files degrade it:

The .gitignore file at the project root automates it:

The mental rule: git holds whatever lets you REGENERATE the results (code, config, requirements), not the results themselves.

Two names for your radar (you do not need them yet, but you will run into them):

• DVC (Data Version Control): extends the git idea to data and models — git stores a lightweight pointer, the heavy file lives in external storage, and every commit knows which version of the data it used.
• MLflow: experiment tracking — it automatically records parameters, metrics and artifacts for every training run and shows them in a comparable table. It is the industrial version of your config.yaml + spreadsheet of results.

In 06-01 you added the TensorBoard callback; now we are going to actually use it. TensorBoard reads the logs written during training and turns them into interactive charts: loss and accuracy curves, run comparisons, weight histograms.

To view it:

How to read what you will see (connecting with what you have learned):

• Scalars tab: loss/val_loss curves and per-epoch metrics. The divergence between training and validation is the overfitting you learned to fight in 05-04 — here you watch it draw itself live, without waiting for the end.
• Comparing runs: each subdirectory of logs/ shows up as a differently colored curve. Train with dropout 0.2 and 0.4 (two configs, two runs) and compare them overlaid: this turns hyperparameter tuning into a visual decision.
• PyTorch plays too: with torch.utils.tensorboard.SummaryWriter you write the same logs from your explicit loop of 06-02 (writer.add_scalar("loss/train", loss.item(), step)). A single monitoring tool for both of the team's frameworks.

Stable resources, with no URLs that expire — all of them are found by searching their name:

• Official documentation for TensorFlow/Keras and for PyTorch: both include excellent guided tutorials and are the final reference for any API question. PyTorch's official tutorials ("60 Minute Blitz") complement lesson 06-02 perfectly.
• Classic courses and books: the deep learning courses on the major educational platforms (Andrew Ng's are the historical standard); Deep Learning by Goodfellow, Bengio and Courville (the reference theory, free online); Hands-On Machine Learning by Géron (practical, with Keras); the fast.ai course and book (a "code-first" approach, on PyTorch).
• Papers: arXiv (preprints of ongoing research) and Papers with Code (paper + implementation + benchmark). Start with the classics you already know by name from the course: ResNet (03-03), Attention Is All You Need (05-05).
• Communities: Kaggle (competitions and public notebooks), Stack Overflow (specific errors), each framework's official forums and Hugging Face (models and examples).
• Deliberate practice: the best post-course recipe is to pick a public dataset that interests you, replicate the course methodology (prototype → application) and document it in your own git repository. One finished project teaches more than ten tutorials — and it is exactly what we will do together in module 7.

Here is how the data team is organized after this lesson:

1. Exploration: Colab (free for short experiments; Pro for the long training runs of module 7), always with Drive mounted and ModelCheckpoint pointing at it.
2. Project: a tecnomarket-dl git repository with the src/ + config.yaml + requirements.txt structure with pinned versions; data/, models/ and logs/ in .gitignore.
3. Consolidation rule: nothing moves from notebooks/ to src/ without fixed random seeds and without being runnable with python src/train.py end to end.
4. Monitoring: TensorBoard with one subdirectory per experiment; both frameworks write to the same logs/.
5. Pending for when they grow: DVC to version the reviews dataset and MLflow for tracking, noted in the README as the next step.

• Training for hours on Colab without checkpoints on Drive: the disconnection will come, and with an ephemeral disk it takes your model with it. ModelCheckpoint + mounted Drive, always.
• Notebooks with cells run out of order: hidden state makes it "work in my notebook" and fail on re-run. Before signing anything off: Restart & Run All. If it does not survive that, it is not finished.
• Committing data, weights or (worse) credentials: besides bloating the repo, a key pushed to git stays in the history even if you delete it later. Write the .gitignore before the first commit.
• Comparing experiments without fixing seeds: the 0.4% improvement of your new dropout may be pure initialization luck. Fixed seeds first; conclusions second.
• Installing CUDA by hand without needing to: first try the framework's official install command — nowadays it usually includes everything. Only if torch.cuda.is_available() returns False with a GPU present is it time to investigate drivers.
• Tip: give every logs directory and every config a date and a descriptive name (reviews_dropout03_20260824). Your three-weeks-from-now self does not remember what test2_final was.

A TecnoMarket teammate's repository contains: src/train.py, config.yaml, data/customer_reviews.csv (400 MB, with real emails), models/reviews_v3.keras (85 MB), logs/ (2 GB), requirements.txt, api_keys.txt and notebooks/exploration.ipynb. State what should be versioned in git, what should not, and why; write the resulting .gitignore and point out the file that is a problem beyond its size.

A teammate runs the same MNIST network notebook twice, gets 97.68% and 97.41%, and concludes that "the model came out worse the second time". Explain why the conclusion is wrong, which four elements they should fix/record so the experiments are comparable, and write the seed block for a script that uses TensorFlow and numpy.

Write the code outline (Keras) to train the review classifier twice — dropout 0.2 and dropout 0.5 — so that both runs appear as separate, comparable curves in TensorBoard, and explain what you would look at in the curves to decide which of the two values is better.

Solution 1:

• Yes to git: src/train.py, config.yaml, requirements.txt, notebooks/exploration.ipynb (text, lets the work be regenerated).
• No to git: data/ (large and containing personal customer data — beyond the size, pushing it could violate data protection), models/ (regenerable binary), logs/ (regenerable and huge), api_keys.txt.
• The serious problem: api_keys.txt. It is not about size: a committed credential stays in the git history forever (deleting it from the directory does not delete it from old commits) and must be considered compromised — it has to be revoked and regenerated, and the keys moved to environment variables.

Solution 2: The 97.68% vs. 97.41% difference falls within normal random variation: different weight initialization, different batch shuffling, dropout switching off different neurons. There is no "worse model": there are two samples from the same distribution of results. To truly compare: (1) fixed random seeds, (2) library versions pinned in requirements.txt, (3) recorded configuration (config.yaml), (4) the same data and the same train/test split. And run it as a script top to bottom, not cells out of order.

Solution 3:

When you launch tensorboard --logdir logs, each dropout is one curve. What to look at: val_loss (not the training one) — the dropout with the lowest stable validation loss wins; and the gap between each experiment's training and validation curves — if with 0.2 the gap widens epoch after epoch (overfitting, as in 05-04) while with 0.5 they stay together with a similar or better val_loss, 0.5 is the choice.

The TecnoMarket team no longer works in loose tabs: they know what to expect from Colab and when to jump to Kaggle, a local GPU or the cloud; they understand the CUDA/cuDNN layers just enough to diagnose; they have turned their work into a project with src/, configs and random seeds that anyone can reproduce; they version in git whatever regenerates results (and only that, with .gitignore protecting data, weights and credentials); they monitor every experiment in TensorBoard; and they have a map of resources to keep growing. In one word: professionalization.

One last piece of the tools module remains, and it is the one that connects everything to the real world: a model living in models/ is of no use to any TecnoMarket customer. In the next lesson you will learn to save models properly in both frameworks, to package them together with their preprocessing, and to deploy them: from a batch script to a REST API answering live requests.