In this guide
You do not need to own a GPU to train a deep learning model as a student. Google Colab's free tier hands you a cloud GPU — most commonly an NVIDIA T4 — inside a Jupyter-style notebook that runs in your browser, with the common ML libraries preinstalled. It is the single most practical training environment for final-year deep learning projects, and it is also the environment most students misuse: they discover the session limits the night before a deadline, lose twelve hours of training to a disconnect, and learn about checkpointing the hard way.
This guide covers Colab the way you will actually use it: what the free tier genuinely gives you, the first-notebook setup, mounting Google Drive so your data and checkpoints survive, the session and idle limits with strategies for each, and a clear-eyed comparison with Kaggle's free GPUs so you know when to switch.
What the free tier actually gives you
A free Colab notebook runs on Google's cloud with:
- A GPU on request — the free tier most commonly allocates an NVIDIA T4 (16 GB VRAM), though the exact hardware varies by availability and region. You get it by selecting a GPU runtime; it is not on by default.
- A CPU-only fallback — usable for data preprocessing and small models, but not for training CNNs of any real size.
- Preinstalled libraries — PyTorch, TensorFlow, scikit-learn, and the usual scientific stack, already installed and GPU-enabled. You can
pip installanything else. - ~12 GB of system RAM and roughly 100+ GB of transient disk per session — the disk vanishes when the runtime is recycled.
What it does not give you: any guarantee of availability. Free GPUs are a shared pool; at busy times you may wait, get a weaker allocation, or be told no GPU is available. Plan your training schedule with slack, not on the assumption that a T4 is always one click away.
The mental model: Colab free is a borrowed workstation that can be reclaimed at any time. Everything valuable — data, code, checkpoints, results — lives on Google Drive. The notebook itself is disposable.
First notebook: the five-minute setup
- Go to colab.research.google.com and sign in with a Google account. Create a new notebook.
- Enable the GPU: Runtime > Change runtime type > Hardware accelerator > GPU (T4 is the common free allocation; leave the rest default). Then run:
import torch
print(torch.__version__)
print(torch.cuda.is_available()) # must be True
print(torch.cuda.get_device_name(0))
If cuda.is_available() is False, you are on a CPU runtime — recheck the runtime type setting. This two-line check belongs at the top of every training notebook; students have trained for hours on CPU without noticing.
- Check what you actually got:
!nvidia-smi
This prints the GPU model and memory. Note it in your training log — "trained on a T4" is a legitimate line in your report's methodology, and it explains your batch-size choices.
Mounting Google Drive: the non-negotiable step
The Colab VM's disk is ephemeral: when the session ends, everything on it is gone. Google Drive is your persistent storage. Mount it at the start of every notebook:
from google.colab import drive
drive.mount('/content/drive')
Then organise one project folder, for example /content/drive/MyDrive/ml-project/, containing data/, checkpoints/, and results/. Two rules:
- Never store the only copy of your dataset on the VM disk. Download or copy it to Drive once; every session copies from Drive to the fast local disk (
/content/) at the start. - Save checkpoints to Drive every epoch, not just at the end. A disconnect at epoch 47 of 50 with no checkpoint is a rite of passage you want to skip. The few seconds of Drive write time per epoch are cheap insurance.
Copying large datasets from Drive to local disk each session is slow. For datasets above a few GB, keep a zipped copy on Drive, unzip to /content/ at session start, and delete it at the end — or better, use Kaggle's API inside Colab to pull the dataset directly, since Colab-to-internet bandwidth is generous.
The limits, honestly documented
Free Colab has three limits that shape how you work. All are documented by Google and subject to change; the strategies below do not:
| Limit | What it is | How to work with it |
|---|---|---|
| Maximum session length | A single runtime lasts up to ~12 hours, then it is recycled | Design training runs to fit in 10-hour windows; checkpoint every epoch so any run is resumable |
| Idle timeout | The runtime disconnects after roughly 90 minutes of inactivity | Keep the tab active during training; do not rely on "leave it overnight untouched" — save checkpoints regardless |
| Usage quotas | Heavy sustained GPU use triggers temporary restrictions ("you have reached your limit") | Spread training across days; use smaller experiments for tuning and reserve long runs for the final configuration |
A note on the tricks you will find online for evading the idle timeout: scripts that fake activity violate Colab's terms and get accounts restricted. The honest approach — checkpointing to Drive and resuming — is also the more robust one, because it survives genuine disconnects too. Build the resumable habit once and every limit becomes an inconvenience instead of a disaster.
The resumable training pattern
This is the single most valuable code pattern in the guide. Save a checkpoint containing the model state, the optimizer state, and the epoch number; on startup, load the latest one if it exists:
import torch, os, glob
CKPT_DIR = '/content/drive/MyDrive/ml-project/checkpoints'
os.makedirs(CKPT_DIR, exist_ok=True)
def save_checkpoint(model, optimizer, epoch, path):
torch.save({
'epoch': epoch,
'model_state': model.state_dict(),
'optimizer_state': optimizer.state_dict(),
}, path)
def latest_checkpoint():
files = sorted(glob.glob(os.path.join(CKPT_DIR, 'ckpt-*.pt')))
return files[-1] if files else None
# at startup
start_epoch = 0
ckpt = latest_checkpoint()
if ckpt:
data = torch.load(ckpt, map_location='cuda')
model.load_state_dict(data['model_state'])
optimizer.load_state_dict(data['optimizer_state'])
start_epoch = data['epoch'] + 1
print('Resumed from', ckpt)
# in the training loop
for epoch in range(start_epoch, NUM_EPOCHS):
train_one_epoch(model, optimizer, loader)
save_checkpoint(model, optimizer, epoch,
os.path.join(CKPT_DIR, 'ckpt-%03d.pt' % epoch))
With this pattern, a recycled runtime costs you at most one epoch. Without it, it costs you the whole run. There is no third option.
Running out of GPU memory: the diagnosis table
"CUDA out of memory" is the most common Colab error, and it is almost always fixable without a bigger GPU:
| Symptom | Likely cause | Fix |
|---|---|---|
| OOM on the first batch | Batch size too large for 16 GB VRAM | Halve the batch size; the T4's 16 GB is generous but not infinite |
| OOM halfway through epoch one | Activation memory growing (large input resolution) | Reduce input image size (e.g. 224 instead of 512) or use gradient accumulation |
| OOM only with a specific model | Model genuinely too large | Switch to a smaller backbone (ResNet-50 instead of ResNet-152) or use mixed precision |
| OOM after several successful epochs | Memory leak: tensors held across iterations (e.g. appending losses without .item()) |
Detach and convert scalars: loss.item(); avoid keeping computation graphs alive |
Two techniques worth knowing by name:
- Gradient accumulation simulates a large batch with small memory: run N small batches, sum the gradients, then step the optimizer once. Same effective batch size, fraction of the memory.
- Mixed precision (
torch.cuda.amp) trains in float16 where safe, roughly halving memory and speeding up T4 training noticeably. For student-scale CNNs it is nearly free performance — enable it early, not as a last resort.
TPUs, runtimes, and when CPU is fine
Colab also offers free TPUs. For most student projects, ignore them: TPU support in PyTorch (via XLA) adds setup friction, and the T4 GPU is simpler and better documented. The exception is large Transformer fine-tuning where a TPU's memory helps — but that is a second-project problem, not a first.
Use the CPU runtime deliberately for: dataset preprocessing and exploratory analysis (no GPU needed, and CPU sessions face fewer quotas), and quick architecture sanity checks on tiny data subsets. A useful discipline is to develop the full pipeline on CPU with 1% of the data, then move to GPU only for real training runs. It saves your GPU quota for the runs that matter.
Colab vs Kaggle: when to switch
Kaggle also offers free GPU/TPU notebooks — currently around 30 hours of GPU per week with a session model of its own. Neither is "better" in general; they suit different phases:
| Dimension | Google Colab (free) | Kaggle (free) |
|---|---|---|
| GPU availability | Shared pool, variable; T4 most common | Weekly quota (~30 h), generally predictable |
| Persistent storage | Google Drive (15 GB free shared) | Kaggle datasets + output versioning |
| Dataset access | Manual upload / Drive / API pulls | One-click attach of any Kaggle dataset |
| Session length | Up to ~12 h, ~90 min idle timeout | Similar session model, quota-metered |
| Collaboration | Shareable notebook links, Drive sharing | Built-in versioning and public notebooks |
| Ideal use | General training, Drive-centred workflow | Kaggle-hosted datasets, quota-predictable runs |
The practical student strategy: use Kaggle when your dataset lives on Kaggle (attaching it is instant, no download step), and use Colab when your workflow centres on Drive or you need the more flexible environment. Many students end up using both — prototyping on Colab, running the quota-predictable long jobs on Kaggle. A pneumonia detection model built on transfer learning, an image captioning CNN-LSTM, and a custom CNN on MNIST are all comfortably within what these free tiers handle — the MNIST-scale project trains in minutes, the transfer-learning ones in a few checkpointed sessions.
Troubleshooting: the errors you will actually see
| Error | Meaning | Fix |
|---|---|---|
torch.cuda.is_available() returns False |
CPU runtime selected | Runtime > Change runtime type > GPU; re-run |
| "No backend with GPU available" / allocation fails | Free GPU pool exhausted | Wait and retry; try off-peak hours; fall back to Kaggle |
| "Your session crashed" after OOM | Runtime ran out of memory (GPU or RAM) | Reduce batch size / image size; check for leaks; restart runtime (Runtime > Restart runtime clears leaked state) |
| Drive mount asks for auth every session | Normal — auth does not persist | Re-run the mount cell; consider it part of session startup |
pip install breaks preinstalled packages |
Version conflict with Colab's pinned stack | Install with --quiet, and prefer versions compatible with the preinstalled torch; restart runtime after installs |
| Training slow despite GPU | Data loading bottleneck (CPU-bound preprocessing) | Increase DataLoader workers, pin memory, move augmentation to GPU where supported |
A session-startup checklist
Paste this at the top of every training notebook and run it in order:
- Runtime type set to GPU;
torch.cuda.is_available()is True;!nvidia-sminoted in the log - Drive mounted; project folder exists with
data/,checkpoints/,results/ - Dataset copied from Drive to
/content/(or attached/pulled fresh) - Latest checkpoint loaded if one exists — training resumes, never restarts from zero
- Batch size chosen for the actual GPU memory (start conservative, scale up)
- Checkpoint saving to Drive every epoch confirmed in the training loop
- Random seeds set (Python, NumPy, torch) and logged, so the run is reproducible
From notebook to report to deployment
A trained model in a notebook is not a finished project. Log the essentials for your report as you go: GPU type, batch size, epochs, optimizer and learning rate, the exact dataset version, and the train/val/test split — these six lines are the methodology paragraph your examiner expects. When the model is ready to leave the notebook, the model deployment guide walks through turning a checkpoint into something a user can actually run. And if you have not yet picked the project, the ML project ideas guide matches task types to datasets sized for free-tier training.
A two-week training schedule that respects the quotas
Free-tier training rewards planning. Here is a realistic schedule for a transfer-learning image classifier — the shape of most student deep-learning projects:
| Day | Session | Goal |
|---|---|---|
| 1–2 | CPU runtime | Data exploration, preprocessing pipeline, train/val/test split, tiny-subset sanity run |
| 3 | GPU, 2 h | Baseline: frozen backbone + linear head, establish the number to beat |
| 4–5 | GPU, 2 × 3 h | Hyperparameter sweep on learning rate and augmentation strength (short 10-epoch runs) |
| 6–7 | — | Analyse: learning curves, confusion matrix, failure cases; decide the final configuration |
| 8–10 | GPU, 2 × 8 h | Final training runs (full unfreeze) with checkpointing; keep the two strongest runs |
| 11–12 | GPU, short | Test-set evaluation of the chosen checkpoint only; export the model |
| 13–14 | CPU | Write-up, figures, demo preparation |
Notice the pattern: GPU time is spent only where GPUs matter. The analysis days in the middle are where projects actually improve — staring at which classes confuse the model beats running a fourth random hyperparameter grid. Total GPU usage stays well inside free-tier comfort, spread across days so usage quotas never bite.
Colab Pro: should a student pay?
Google sells Colab Pro/Pro+ with more compute units, longer runtimes, and priority GPU access. Honest guidance for students:
- Try the free tier first, properly. Most final-year projects — including transfer-learning CNNs and small LSTMs — complete on free Colab with the checkpointing discipline in this guide. Paying to compensate for lost checkpoints is paying for a habit problem.
- Consider one month of Pro only for a specific crunch: the final long training run before submission, when you know the configuration and just need uninterrupted hours. It is a targeted purchase, not a subscription lifestyle.
- Never pay before the pipeline is solid. Money does not fix a data leak, a broken augmentation, or an OOM you have not diagnosed. The free tier forces you to build a clean pipeline; that discipline transfers.
Whatever you choose, the techniques in this guide (checkpointing, mixed precision, gradient accumulation) apply identically on paid tiers — they just buy you margin.
Sharing, presenting, and submitting from Colab
A Colab notebook is also a presentation artifact. A few practices that make it one:
- Restart and run all before sharing. Runtime > Restart and run all, then read the notebook top to bottom. If it does not reproduce cleanly in order, it will not reproduce for your examiner either.
- Save a copy with outputs. File > Save a copy in Drive after the final run, so the shared version shows the training curves and metrics inline. A notebook full of empty outputs proves nothing.
- Link from GitHub. Colab notebooks open directly from GitHub URLs (paste the GitHub link into colab.research.google.com). Keep the notebook in your project repo — it is part of the deliverable, and version control beats "final_v7_REAL.ipynb".
- Export for the report. File > Download > .ipynb for the appendix; screenshots of key cells (the
nvidia-smioutput, the final metrics) go into the report body as figures with captions.
What not to put in a notebook
Colab notebooks get shared — with teammates, examiners, and sometimes publicly. Treat every cell as potentially public:
- Never hardcode API keys, tokens, or passwords in a cell. Use Colab's secrets manager (the key icon in the left sidebar): store the secret there and read it with
userdata.get('NAME'). A Kaggle API key pasted into a shared notebook is compromised the moment it is shared. - Do not commit large datasets to Git. The notebook goes in the repo; the data stays on Drive or Kaggle with a download cell at the top. Anyone cloning your repo should be able to reproduce the data step from that cell.
- Scrub personal paths before publishing.
/content/drive/MyDrive/...is fine; anything with your name or personal folder structure is worth renaming to the neutralml-project/layout used in this guide.
Frequently asked questions
Can I just leave training running overnight?
You can, but do not rely on it. The ~90-minute idle timeout and the ~12-hour session cap mean an unattended run can die at any point — which is fine if checkpoints save to Drive every epoch, because you resume in the morning. "Leave it overnight" without checkpointing is how a week's work becomes a story.
Can I use two Google accounts to double my quota?
Colab's terms tie usage to fair use, and juggling accounts to evade limits risks restrictions on all of them. The sustainable answer is the one in this guide: efficient pipelines, checkpointing, and Kaggle as the second free venue. Two legitimate free platforms used well beat one account used anxiously.
Why did my GPU change from a T4 to something slower?
Free-tier allocation depends on pool availability — you get what is free when you request it, and it varies by time of day and region. Note whatever you get (nvidia-smi) in your training log. If your batch size was tuned for 16 GB and you land on a smaller GPU, halve the batch and use gradient accumulation rather than fighting OOM errors.
Is it okay to run a notebook from my phone?
For monitoring, yes — the Colab mobile page shows cell outputs. For actual work, no: keep the tab active on a desktop during training so the session is not reclaimed for inactivity, and do your editing where you can see what you are doing.
Putting it together
Colab's free GPU removes the hardware excuse from student deep learning — but only if you treat the environment as what it is: borrowed, temporary, and quota-limited. Mount Drive, checkpoint every epoch, design runs to fit the session window, keep batch sizes honest about 16 GB of VRAM, and keep Kaggle in reserve for quota-predictable stretches. Do that, and a free browser tab trains models that would have needed a lab workstation five years ago.
Want one of these built for you? Chat on WhatsApp with the project name and your deadline, and you will get a written quotation with scope, price and delivery date.