Google Colab: Pick a Runtime Accelerator and Keep Data Past Disconnect

Desired outcome

You open a Colab notebook, train a model for an hour, close the tab, and return to find the runtime gone. Files saved to /content and packages installed with !pip are deleted when the VM is reclaimed. Even worse, the notebook may still say GPU while the kernel is running on CPU. This guide shows how to choose a runtime accelerator, verify it is actually attached, and persist data to Google Drive so a disconnect does not destroy the work.

Prerequisites

• A Google account with access to Google Colab.
• An existing or new Colab notebook opened in a browser.
• Google Drive access if you want files to persist across sessions.
• Permission to change the runtime type; view-only shared notebooks may not allow runtime changes.

1. Choose the runtime type

Colab assigns a virtual machine (VM) to each notebook session. The VM can run with no accelerator, a CPU, a GPU such as T4 or A100, or a TPU. The accelerator is released when the runtime disconnects or stays idle too long.

Open the notebook, then select Runtime > Change runtime type. Under Hardware accelerator, choose one of:

• None — CPU only, suitable for lightweight preprocessing.
• CPU — general-purpose compute without graphics acceleration.
• T4 GPU — NVIDIA Tensor Core GPU; a common default for machine-learning training.
• A100 GPU — higher-memory accelerator; availability depends on your account tier and region.
• TPU — Tensor Processing Unit; requires TPU-specific code paths.

Click Save. Changing the accelerator restarts the runtime, which clears all in-memory variables and installed packages. Do this before loading large datasets or starting training.

2. Verify the accelerator is attached

The runtime header may show a GPU name, but you should confirm the running kernel can see the device.

Run this in a code cell:

!nvidia-smi

Where: any Colab code cell. Permissions: none beyond notebook edit access.

Expected result: if a GPU is attached, the command prints an NVIDIA driver table with the GPU model and memory. If you selected CPU or None, the command fails or returns no GPU entries.

Risk: a successful nvidia-smi does not mean the GPU has free memory. A large model can still trigger an out-of-memory error and crash the runtime.

For TensorFlow workloads, you can also run:

import tensorflow as tf
print(tf.config.list_physical_devices('GPU'))

An empty list means no GPU is visible to the kernel.

3. Mount Google Drive for durable storage

The Colab filesystem under /content is ephemeral. When the runtime is reset or reclaimed after idle time, every file, downloaded dataset, and !pip install package under /content is deleted. Google Drive persists across sessions, though file input/output is slower than the VM's local disk.

Run this in a code cell:

from google.colab import drive
drive.mount('/content/drive')

Where: a code cell near the top of the notebook. Permissions: your Google account must authorize Colab to access Drive; Colab displays an authorization URL and asks for a confirmation code.

Expected result: after authorization, files appear under /content/drive/MyDrive. List them with:

!ls -la /content/drive/MyDrive

Risk: Do not paste API keys, passwords, or secrets into cells. Notebook cell contents and version history can be exposed to collaborators.

4. Copy outputs to Drive before disconnect

Treat /content as a scratchpad. Save models, datasets, and logs to a Drive folder so they survive a runtime restart.

Example configuration: copy a local training output folder to Drive:

!cp -r /content/training_output /content/drive/MyDrive/colab_projects/my_experiment/

Placeholders: replace /content/training_output with your actual output path and my_experiment with a project name.

Expected check: run !ls /content/drive/MyDrive/colab_projects/my_experiment/ and confirm the files are present.

If you installed Python packages with !pip install -q package-name, reinstall them after every runtime reconnect unless you use a custom Colab environment or startup script.

5. Reconnect and resume

After a disconnect or idle reclaim:

1. Reopen the notebook and reconnect to the runtime.
2. Re-select the accelerator if the runtime was wiped.
3. Re-mount Drive with drive.mount('/content/drive').
4. Reinstall required packages.
5. Copy inputs back from Drive to /content for faster local I/O, run your work, then copy outputs back to Drive.

Expected checks

Check	Command or location	Pass condition
Accelerator selected	Runtime > Change runtime type header	Chosen accelerator appears in the runtime header
GPU visible to kernel	!nvidia-smi	NVIDIA table lists the selected GPU model
Drive mounted	!ls /content/drive/MyDrive	Your Drive folders and files are listed
Data persisted	Restart runtime, then list a Drive path	Files copied to Drive remain after restart

Limitations

• No guaranteed session length: idle VMs are reclaimed after a period of inactivity. Long-running training should checkpoint to Drive frequently.
• Quotas vary: GPU and TPU availability and priority depend on account type and region; free-tier users may receive lower-priority or preemptible accelerators.
• Slower Drive I/O: reading and writing large datasets directly from /content/drive is slower than using /content. Copy data to local disk for active work.
• No guaranteed headless execution: closing the browser tab may stop background execution. Do not rely on Colab for unattended jobs unless you have verified the runtime stays alive.
• State loss on restart: changing runtime type restarts the VM and clears variables. Save notebook state to Drive before switching accelerators.

Recovery options

If you no longer need Drive access in a notebook, unmount it in a code cell:

drive.flush_and_unmount()

This ends the Drive session for that notebook. To undo a runtime-type change, open Runtime > Change runtime type again, select a different accelerator, and restart; remember that each restart clears in-memory state.

Practical verification

Create a temporary file under /content, restart the runtime, and confirm the file is gone. Then copy the same file to /content/drive/MyDrive, restart the runtime, re-mount Drive, and confirm the file still exists. This demonstrates the difference between ephemeral local storage and persistent Drive storage.