Will my T4 VM stop working before 1 August 2027?

No. Google's end of support page says resources running NVIDIA T4 GPUs continue to function normally until that date. From 1 August 2027 you cannot create, launch or access any Google Cloud resource that runs them, which includes starting a VM that already exists.

Can I just change my existing VM from a T4 to an L4?

Not in place. A T4 attaches to an N1 general purpose machine, while the L4 lives on the accelerator-optimized G2 series, and you cannot convert one machine type into the other on a running instance. You create a new G2 or G4 instance, move Local SSD contents to a Persistent Disk first, then detach the Persistent Disk volumes from the old instance and attach them to the new one.

What happens to my committed use discount on T4 GPUs?

Existing active one year and three year commitments stay valid until their scheduled expiration date, but you cannot purchase or renew three year commitments for T4 GPUs. If a commitment expires anywhere near August 2027, decide what replaces it before it renews on its own.

NVIDIA T4 end of support: August 2027 and the L4 move

Say a twenty person video studio in Guatemala City has two Google Cloud VMs with NVIDIA T4 GPUs attached. One runs nightly transcoding. The other is a Windows virtual workstation that an editor logs into from home three days a week. Both were built in 2021 by a contractor who has long since moved on. Nobody opens the Cloud console anymore, because nothing is broken.

That is the profile a GPU end of support notice hurts most. The machines keep working right up to the day they stop, and the day is already on the calendar.

What changed, and the date that matters

In the Google Cloud release notes for 22 September 2026, Compute Engine marked the NVIDIA T4 GPUs (nvidia-tesla-t4 and nvidia-tesla-t4-vws) and the NVIDIA P4 GPUs (nvidia-tesla-p4 and nvidia-tesla-p4-vws) as deprecated, with an end of support date.

The end of support date for both is 1 August 2027. Google's own end of support page states it plainly: until that date, resources running T4 GPUs keep working normally, and as of 1 August 2027 you cannot create, launch or access any Google Cloud resource that runs them. The P4 follows the same date and the same wording.

This is not a preview or a rumour. It sits in the published deprecation pages, and it has a sibling that already landed: the NVIDIA P100 reached end of support on 15 September 2026, ten days before we wrote this. If you were still on a P100, that decision has already been made for you.

The wording to take seriously is access. This is not only a ban on creating new machines. A VM that exists but cannot be started after that date is an offline machine with a disk attached, and the disk keeps billing.

Who this affects among small and mid-sized businesses

The T4 was the workhorse of cheap GPU compute for years. It is cheap enough that small teams put it on things a larger company would never accelerate. In client projects we see it in five places.

Inference on an N1 VM. A single T4 attached to a general purpose machine, running a transcription model, an OCR pipeline, an image classifier or a recommendation service.
Virtual workstations. The -vws variants exist for CAD, video editing and 3D work delivered to a remote desktop. Compute Engine attaches the NVIDIA RTX Virtual Workstation licence automatically when you create that kind of instance, which is why the cost sits quietly inside the VM line on the bill.
GKE node pools. A node pool pinned to T4 accelerators in a cluster somebody set up once.
Dataflow pipelines and Managed Service for Apache Spark jobs whose worker configuration names the T4 explicitly.
Cloud Workstations configurations and Gemini Enterprise Agent Platform workloads that reference the T4 as their accelerator.

The common thread is that in every one of those places the GPU model is written into a config file, a template or a Terraform resource, not chosen by a human each morning. Nobody is going to notice the deprecation by looking at a screen. Something has to go and read the configuration.

What we check first on a client project

Before anyone proposes a migration, we want a complete list. The first pass is one command per project, from the documented set of common Compute Engine commands:

gcloud compute instances list \
  --filter="guestAccelerators.acceleratorCount>0" \
  --format="table(name,zone,guestAccelerators.acceleratorType,guestAccelerators.acceleratorCount,disks.type)"

Run it against every project in the organisation, not just the one called production. GPU VMs have a habit of living in a project named after a proof of concept from three years ago.

Then we check the places that command does not reach:

Instance templates and managed instance groups. The running VMs may be fine while the template that recreates them still names a T4. That is the failure that wakes you up at 3am after an autoscaling event in August 2027.
GKE node pools. List the node pools and read the accelerator on each, including pools scaled to zero.
Dataflow templates and Spark job definitions that set a worker accelerator.
Cloud Workstations configurations.
Infrastructure code. Terraform, Deployment Manager, shell scripts in a repo. Grep for tesla-t4 and tesla-p4 across every repository, including the ones nobody has committed to in a year.
Committed use discounts. Existing one year and three year commitments on T4 stay valid until their scheduled expiration, but new three year commitments on T4 cannot be purchased or renewed. Any commitment that would expire close to August 2027 needs a decision now rather than an automatic renewal into a dead end.
Whether the workload still needs a GPU. Some of the pipelines we inherit were accelerated because a T4 was cheap, not because the maths required it. Two of the migrations are a delete.

The move, in the order we do it

Google's recommended targets are the G2 machine series with NVIDIA L4 GPUs and the G4 machine series with NVIDIA RTX PRO 6000. The important structural detail, and the one that surprises people: you cannot change an existing instance in place from an N1 general purpose machine type to an accelerator-optimized machine type. There is no edit that turns a T4 VM into an L4 VM. You build a new instance and move the data.

Pick the target and the zone. G2 and G4 are not offered in every zone that offered T4. Check the GPU locations page for your region before you promise anyone the machine stays where it is. Sometimes the honest answer is that the workload moves region, and that has latency and data residency consequences worth raising early.
Rescue Local SSD data. If the old instance uses Local SSD disks with anything you want to keep, copy their contents to a Persistent Disk volume first. Local SSD data does not survive the move, and it does not survive a stop.
Create the new G2 or G4 instance. Install the drivers fresh. For a virtual workstation this means the NVIDIA RTX Virtual Workstation drivers, not the standard ones.
Move the Persistent Disk volumes. Detach from the old instance, attach to the new one.
Re-test the actual workload before deleting anything. The T4 is Turing and the L4 is Ada Lovelace. A container image with a pinned CUDA or driver version, a compiled kernel, or a model artefact built for a specific compute capability can refuse to load. This is where the real work is, and it is the reason we do not schedule the migration for July 2027.
Update everything that creates machines. Instance templates, GKE node pools, Dataflow worker settings, workstation configurations, Terraform. A migrated VM with an un-migrated template is not migrated.
Delete the old instances only after a full business cycle has run clean on the new ones. A month end is a good marker for most of our clients.

Cost and risk notes

We will not print GPU prices here, because they move and a stale figure in a blog post is worse than no figure. Price your specific configuration in the Google Cloud pricing calculator on the day you plan, and check it again before you commit.

What we can tell you is that the shape of the bill changes. A T4 was an accelerator you attached to an N1 machine you sized yourself, so CPU and GPU were independent. G2 and G4 are accelerator-optimized series with fixed ratios of GPU to vCPU and memory. If your T4 box was a small CPU with one GPU, the nearest supported machine may give you more CPU than you asked for. That is not automatically more expensive, because Google's guidance says customers moving from T4 to L4 can see two to four times better performance, and a job that finishes in a third of the time on a per-second billed machine can land cheaper even at a higher hourly rate. Measure your own workload. Do not accept either the optimistic or the pessimistic version without a benchmark.

Three risks we flag on every one of these projects:

The forgotten machine. August 2027 feels far away, which is exactly why the editor's virtual workstation will still be on a T4 in July 2027. Put the inventory in a ticket with a date, not in someone's head.
The commitment trap. Renewing a discount on hardware with a published end of support date locks money to a machine you have to leave.
The silent template. Autoscaling and node repair recreate machines from templates. A template that names a retired accelerator turns a quiet Tuesday into an outage.

How Guanacos Tech helps

We do this as a fixed piece of work: inventory every GPU across every project, map each one to a workload and an owner, test the L4 or RTX PRO 6000 replacement against the real job, and hand you a migration plan with dates that sit well before the deadline rather than on top of it. If the honest answer for a given workload is that it no longer needs a GPU, we say that too, and the cost saving is yours.

If you want a second pair of eyes on a Google Cloud project you inherited, that is the kind of thing our Google Cloud consulting for small teams work starts with. Book a 30 minute call and bring your project IDs.

NVIDIA T4 and P4 GPUs lose support on 1 August 2027: the migration we plan now