Your laptop does not have to suffer through deep learning. A free Google Colab GPU (Graphics Processing Unit) hands you a real Tesla T4 in a browser tab: no CUDA install, no gaming rig, no bill. This post walks through enabling it, proving it is on with one small check, the session rules that catch beginners, and a timed CPU vs GPU race you can run yourself.

“The best way to get started is to stop talking and begin doing.”

Walt Disney

Last Updated: July 2026 | Tested on: Python 3.14.6 | Difficulty: Beginner | Reading Time: 17 minutes

The CPU vs GPU vs TPU tutorial explained why AI leans on GPUs at all. This one is the hands-on companion: no theory, just the clicks and the two or three lines of code that get you a working GPU. And here is the reassuring part up front. You do not need to buy anything, install CUDA, or own a gaming rig. A borrowed GPU in a browser tab is enough for every deep learning exercise in this series, and your own laptop never has to work hard or heat up, because the heavy math happens on a computer in Google’s data centre, not on your desk.

Do You Even Need a GPU Yet?

Think of a GPU like a professional oven at a commercial bakery. If you are learning to bake bread at home, your ordinary kitchen oven is completely fine, and hauling in a giant industrial one would be a waste of money and space. You only want the big oven once you are baking hundreds of loaves a day. Hardware for AI works the same way. For everything up to deep learning, plain Python, data cleaning, and classic machine learning, your normal laptop is the home oven and it does the job beautifully.

You need a GPU only when you start training neural networks, and even then only because a GPU turns a job that would take hours on your CPU into one that takes minutes. So the honest answer for a beginner is: not yet, and when you do, borrow one for free rather than buy. A GPU does not make your code correct or your model smarter. It just makes the same training finish sooner. If a network trains in two minutes on a CPU, you do not need a GPU for it at all. The moment you feel the wait get painful is the moment to reach for Colab, and not a second earlier.

Turning On a Free GPU in Google Colab

Google Colab is a free notebook that runs in your browser, a bit like a Google Doc but for Python. At the time of writing it hands out a free GPU to anyone with a Google account, which is why the Google Colab GPU is the default starting point for this whole series. Turning it on takes four clicks, and a fresh notebook does not have it enabled by default, so this step matters.

1. Open colab.research.google.com and start a new notebook.
2. Click the menu Runtime, then Change runtime type.
3. Under Hardware accelerator, pick T4 GPU and click Save.
4. The notebook reconnects with a GPU attached. Now confirm it is really there.

Never trust a menu without checking. In a notebook cell, a line starting with an exclamation mark runs a shell command, and nvidia-smi is the tool that reports on an NVIDIA GPU. Running it is how you prove a GPU is attached and see which one you got.

📄 In a Colab cell: ask the GPU to introduce itself

!nvidia-smi

▶ Example output (free Colab, T4 GPU)

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.15    Driver Version: 550.54.15    CUDA Version: 12.4      |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
|===============================+======================+======================|
|   0  Tesla T4              Off | 00000000:00:04.0 Off |                    0 |
| N/A   45C    P8     9W /  70W |      0MiB / 15360MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

What happened here: the table confirms a real GPU is attached, a Tesla T4, and the line that matters most for a beginner is 0MiB / 15360MiB. That is the VRAM, the GPU’s own memory, and you have about 15 GB of it free. Remember from the hardware for AI tutorial that the first question about any model is whether it fits in this number, not how fast it runs.

The output is labelled as an example because this machine has no GPU, so I cannot run nvidia-smi here, but on a real Colab session you will see exactly this shape. If instead you get command not found, the GPU is not enabled, so go back and repeat the Runtime steps.

The One Check That Works on Any Machine

The nvidia-smi command is handy on Colab, but it only knows about NVIDIA cards. Your own laptop might have an NVIDIA GPU, or an Apple silicon chip, or no GPU at all, and you want one check that gives a straight answer everywhere. PyTorch, the deep learning library you will use throughout this series, provides exactly that. The script below asks the two questions that decide where your math runs and picks a device accordingly. This is the check to paste at the top of every notebook.

📄 device_check.py: what will my heavy math run on?

import platform
import torch

# One portable question: what will my heavy math actually run on?
print("Python :", platform.python_version())
print("PyTorch:", torch.__version__)

cuda_ok = torch.cuda.is_available()                       # NVIDIA GPU + CUDA
mps_ok = torch.backends.mps.is_available()                # Apple silicon GPU

if cuda_ok:
    device = "cuda"
    name = torch.cuda.get_device_name(0)
elif mps_ok:
    device = "mps"
    name = "Apple silicon GPU (Metal)"
else:
    device = "cpu"
    name = platform.processor() or "CPU"

print("CUDA available (NVIDIA):", cuda_ok)
print("MPS available (Apple)  :", mps_ok)
print("-> This machine will use:", device, "(" + name + ")")

▶ Output (this laptop, an ordinary CPU)

Python : 3.14.6
PyTorch: 2.12.1+cpu
CUDA available (NVIDIA): False
MPS available (Apple)  : False
-> This machine will use: cpu (Intel64 Family 6 Model 142 Stepping 12, GenuineIntel)

What happened here: this is the real output from the plain laptop I am writing on, which has no GPU, so both checks say False and the script settles on cpu. That is not a problem, it just means heavy training would be slow here. On a Colab session with the T4 enabled, the same script prints CUDA available (NVIDIA): True and chooses cuda (Tesla T4). On a MacBook with Apple silicon, MPS available (Apple): True and it chooses mps. One script, an honest answer on every machine. Notice the device string it produces: you will pass that exact value to PyTorch so your code runs wherever it lands, unchanged.

If you run this on your own Windows or Linux machine and expected True but got False, the usual cause is that you installed the CPU-only build of PyTorch. The fix is to reinstall the CUDA build that matches your driver, following the picker on the official PyTorch site. On a Mac, MPS needs a recent macOS and Apple silicon, not the older Intel Macs.

Where Your Code Actually Runs

Here is the mental model that clears up most Colab confusion. When you use Colab, your laptop is only a screen and a keyboard. The actual computer, with the CPU, the memory, and the GPU, lives in a Google data centre. You type code in the browser, it travels to that rented machine, runs there, and only the results come back to your screen. That is why your own laptop stays cool and quiet even while a GPU is grinding through a big model.

The catch is in the picture too. That rented machine, the Colab VM, is temporary. When your session ends, whether you close the tab, run out of time, or leave it idle too long, the VM is wiped clean and anything saved only on its disk is gone. Your notebook file itself is safe in Google Drive, but files your code created, downloaded datasets, trained model weights, all vanish unless you deliberately saved them somewhere lasting. This one fact explains most of the frustration beginners have with Colab, so keep the picture in mind: the browser is yours and permanent, the machine doing the work is borrowed and temporary.

The Runtime Menu: Tiers, Limits, and Disconnects

The free Google Colab GPU tier gives you a T4, which is genuinely plenty for learning. It trains the small and medium networks in this series comfortably and has enough VRAM for most beginner work. The paid tiers offer newer, faster GPUs with more memory, but you do not need them to learn, so ignore the shinier options until a real job forces your hand.

What you do need to respect are the limits, because the free tier is a shared resource and Google enforces fair use. Say a learner named Aditi leaves a notebook running overnight to train a model. She may come back to find it disconnected, because free sessions are cut off after a stretch of time and also if the tab sits idle with no interaction. There is a rough cap on how many hours per day you get too, and it tightens if the service is busy. None of this is a bug, it is the price of free.

The way to live happily with these limits is to plan for the disconnect instead of being surprised by it. Save your notebook to Google Drive or push it to GitHub, both of which Colab does from its File menu. More importantly, save your trained model weights and any results to Drive during the run, not at the end, so a timeout mid-training costs you the last few minutes rather than the whole afternoon. Treat every Colab session as something that could vanish at any moment, and you will never lose real work.

Kaggle and the Paid Ladder

Colab is not the only free GPU in town. Kaggle Notebooks, run by the same parent company, give you another free GPU with a weekly quota of hours, typically a P100 or a pair of T4s, so you get a separate quota and sometimes more total GPU memory than the free Colab tier. Many learners keep both accounts and switch to Kaggle when their Colab hours run low for the day. It is the same idea, a notebook in the browser with a borrowed GPU, so the device check above works there unchanged.

When free tiers stop being enough, usually because a job needs more hours or more VRAM than they allow, there is a ladder of paid options. Here is an honest snapshot of that ladder as of mid-2026. The prices move constantly, so treat the numbers as ballpark, not gospel, and look past the names to the categories.

Read that top to bottom as a staircase you climb only when forced. Start free, add the second free tier, and pay a little for Colab Pro before you ever rent by the hour. Renting a cloud GPU from a provider like Lambda, RunPod, Modal, or Lightning Studios makes sense for a big one-off job, since a few hours costs less than lunch. Buying hardware sits at the bottom for a reason: it is the last step, not the first.

Your First GPU Win: CPU vs GPU, Timed

Enough setup. Let us feel the payoff. The script below does two things a real network does over and over: a big matrix multiply, and one training step, which is a forward pass, a backward pass, and a weight update on a small net. It times both on whatever device the check found. Run it once on your CPU, then run the identical file on a Colab GPU, and compare.

📄 gpu_win.py: the same work, timed on CPU then GPU

import time
import torch

device = "cuda" if torch.cuda.is_available() else "cpu"
print("Running on:", device)

# A workload the size of a real layer: a 4096 x 4096 matrix multiply,
# then one tiny training step (forward + backward) on a small net.
x = torch.randn(4096, 4096, device=device)
y = torch.randn(4096, 4096, device=device)

def sync():
    if device == "cuda":
        torch.cuda.synchronize()

for _ in range(3):          # warm up
    _ = x @ y
sync()

t0 = time.perf_counter()
for _ in range(10):
    z = x @ y
sync()
matmul_ms = (time.perf_counter() - t0) / 10 * 1000
print(f"4096x4096 matmul   : {matmul_ms:8.1f} ms")

net = torch.nn.Sequential(
    torch.nn.Linear(2048, 2048),
    torch.nn.ReLU(),
    torch.nn.Linear(2048, 2048),
).to(device)
data = torch.randn(512, 2048, device=device)
target = torch.randn(512, 2048, device=device)
opt = torch.optim.SGD(net.parameters(), lr=0.01)

for _ in range(3):          # warm up
    opt.zero_grad()
    loss = ((net(data) - target) ** 2).mean()
    loss.backward()
    opt.step()
sync()

t0 = time.perf_counter()
for _ in range(10):
    opt.zero_grad()
    loss = ((net(data) - target) ** 2).mean()
    loss.backward()
    opt.step()
sync()
step_ms = (time.perf_counter() - t0) / 10 * 1000
print(f"one training step  : {step_ms:8.1f} ms")

▶ Output (this laptop, CPU: real, measured)

Running on: cpu
4096x4096 matmul   :    739.9 ms
one training step  :    143.7 ms

▶ Example output (free Colab, T4 GPU)

Running on: cuda
4096x4096 matmul   :      20.1 ms
one training step  :      4.6 ms

What happened here: the CPU numbers are real, measured on the laptop I am writing on. The matrix multiply took about 740 milliseconds and one training step about 144. On the free Colab T4 the same file runs in single-digit milliseconds, roughly thirty-five times faster on the matmul and thirty times on the training step. The GPU block is labelled as an example because this machine has no GPU to run it, but the shape is exactly what you will see, and the CPU figures above it are an honest anchor to compare against. Sit with that gap for a second.

Training that would keep your laptop busy all afternoon finishes over a coffee break on a borrowed GPU that costs you nothing. That is the whole reason we set this up.

Common Mistakes

• Forgetting to enable the GPU. A fresh Colab notebook has no GPU by default. If torch.cuda.is_available() says False, you skipped the Runtime menu step, not a code bug.
• Trusting the menu without checking. Always run the device check or nvidia-smi in a cell. Assuming the GPU is on and finding out an hour later that it was not is a classic time sink.
• Losing work to a disconnect. The Colab machine is temporary. Saving trained weights only at the very end means a timeout wipes hours of training. Save to Drive during the run.
• Reaching for paid tiers too early. The free T4 handles every exercise here. Paying before you hit a real wall spends money on speed you cannot yet use.
• Expecting a GPU on your own machine automatically. Installing the CPU-only PyTorch build then wondering why cuda is unavailable is common. Match the CUDA build to your driver, or just use Colab.

Best Practices

• Put the device check at the top of every notebook. One glance tells you where your code will run before you waste time waiting on the wrong hardware.
• Write device-agnostic code. The device = "cuda" if torch.cuda.is_available() else "cpu" line lets the same script run on your laptop and on Colab with no edits.
• Mount Google Drive early and save often. Point your model checkpoints at Drive so a disconnect never costs more than the last few minutes.
• Keep a Kaggle account as backup. When Colab hours run low, Kaggle Notebooks give you a second free GPU for the day.
• Climb the cost ladder only when forced. Free, then the other free, then cheap Colab Pro, then rent by the hour. Buying hardware is the last rung, not the first.

Conclusion

Setting up a free Google Colab GPU comes down to a short, calm routine. Enable the GPU from the Runtime menu, prove it is there with nvidia-smi or the portable device check, remember that the machine doing the work is borrowed and temporary so save to Drive as you go, and lean on the free T4 for as long as it carries you, which is a good long while. You do not need to buy anything, and you do not need to worry about your laptop overheating, because the heavy math never touches it.

When a job finally outgrows the free tier, the cost ladder from Kaggle to Colab Pro to hourly cloud rentals is there, climbed one rung at a time.

With a working Google Colab GPU in hand, you are ready to train your first real neural network without waiting all day for it. Or step back and see the whole path on the Python + AI/ML tutorial series home.

Frequently Asked Questions

Interview Questions on Free GPUs

The same ideas as they show up in real interviews, framed as scenarios you can practice out loud.

Q: How would you check, in code, whether a GPU is available before running a model?

In PyTorch you call torch.cuda.is_available() for an NVIDIA GPU and torch.backends.mps.is_available() for Apple silicon, then set a device string accordingly, falling back to "cpu". The standard idiom is device = "cuda" if torch.cuda.is_available() else "cpu". You then move tensors and the model to that device. This makes the same code portable across a laptop, a cloud GPU, and a Mac without edits, which is exactly what an interviewer wants to see.

Q: Why does a Colab session lose downloaded files but keep the notebook?

Colab runs your code on a temporary virtual machine in Google’s cloud. The notebook file lives in Google Drive and persists, but the VM’s local disk is ephemeral and is wiped when the session ends. Anything written only to that local disk, such as datasets or trained weights, is lost. The fix is to mount Google Drive and save important outputs there during the run, so a disconnect costs minutes rather than the whole session.

Q: A model trains fine on Colab but fails on a colleague’s laptop with a CUDA error. What is your first guess?

The most likely cause is a hardware or install mismatch, not the model code. The laptop may have no NVIDIA GPU, or a CPU-only PyTorch build, so torch.cuda.is_available() is False and moving tensors to cuda fails. Or the model needs more VRAM than the laptop’s GPU has, giving a CUDA out of memory error. I would run the device check first, then compare VRAM against the model size before touching the training logic.

Q: When would you move from free Colab to a paid or rented GPU?

When a real limit gets in the way, not before. The two usual triggers are time and memory: sessions that keep disconnecting before a long job finishes, or a model that needs more VRAM than the free T4 offers. The sensible path is to climb gradually, from free Colab to free Kaggle, then cheap Colab Pro for longer sessions, then an hourly cloud rental like Lambda or RunPod for a big one-off job. Buying a GPU is justified only by heavy, repeated use.

Q: What does nvidia-smi tell you, and which number matters most for running a model?

The nvidia-smi command reports on the attached NVIDIA GPU: its model, driver and CUDA version, temperature, power, and memory use. For a beginner deciding whether a model will run, the memory figure, shown as used versus total VRAM, matters most, because a model that exceeds total VRAM will not load at all. It also confirms a GPU is actually present, which is a quick sanity check before assuming any speed-up.

Go deeper: the official Python documentation covers every edge case of this topic.

Related Posts

Previous: Machine Learning Interview Questions: 40-Question Checkpoint

Next: DL: Introduction to Neural Networks, Perceptron to Multi-Layer

Series Home: Python + AI/ML Tutorial Series