# GPUs on Cloud Run: running your own model, what it costs, and where the start goes

> Cloud Run attaches an NVIDIA L4 or RTX PRO 6000 to an instance and scales it to zero. What a deploy needs, a sample model image we built and timed, where the cold start goes, and the cost.

Published 2026-10-12 · Updated 2026-10-13 · [By Exodus team](https://exodus.elim.io/about) · Performance, Pricing
<https://exodus.elim.io/blog/gpus-on-cloud-run>

Cloud Run GPUs are an NVIDIA L4 with 24 GB or an RTX PRO 6000 Blackwell with 96 GB, one per instance, started in about 5 seconds and scaled to zero. A GPU service needs instance-based billing and, for an L4, at least 4 vCPU and 16 GiB. The smallest L4 instance costs $1.05 an hour in europe-west1, and most of a cold start is loading the model.

## In short

- A project starts with a quota of 3 GPUs per region, granted on the first deploy; an RTX PRO 6000 needs at least 20 vCPU and 80 GiB.
- The smallest L4 instance costs $1.05 an hour without zonal redundancy, $763.96 a month if it never stops; a `g2-standard-4` VM with the same L4 costs $568.15, so above roughly 18 hours a day the VM is cheaper.
- An idle GPU instance is kept up to 10 minutes after its last request and billed for them: about $0.17 each time on the small L4.
- In our test the port answered in 3.5 s and the model was ready at 59.5 s. Keep the model small, ship it in the image or in Cloud Storage, and warm it up before the first user arrives.

Prices are list prices of October 12, 2026, in europe-west1. Scaled to zero, a GPU service costs nothing.

## What Cloud Run gives you

Google's GPU page lists two GPUs. The L4 has 24 GB of GPU memory (VRAM), enough for a quantized model (stored with fewer bits per weight) of a few billion parameters. The RTX PRO 6000 Blackwell has 96 GB; Google's announcement says it serves "up to 70B+ parameter models". Both are on demand, and a GPU service still scales to zero.

The rules from the same page:

- **One GPU per instance.** With sidecar containers, the GPU goes to one of them.
- **Drivers are installed by Google**, version 580.x.x with CUDA 13.0, mounted under `/usr/local/nvidia/lib64` and added to `LD_LIBRARY_PATH`.
- **About 5 seconds.** An instance with a GPU starts in approximately 5 seconds "at which point the processes running in your container can start to use the GPU". Loading your model comes after.
- **Services, jobs and worker pools** all take a GPU. GPUs for services became generally available on April 7, 2025, for jobs on October 21, 2025, and the RTX PRO 6000 on April 13, 2026, per the release notes.

### Regions

The L4 is offered in `europe-west1`, `europe-west4`, `us-central1`, `us-east4`, `asia-southeast1` and, by invitation only, `asia-south1`. The RTX PRO 6000 is offered in `europe-west4`, `us-central1`, `asia-southeast1` and `asia-south2`. If your other services run elsewhere, the GPU service can live in a GPU region alone; our [region guide](https://exodus.elim.io/blog/choosing-a-cloud-run-region) covers the trade-off.

## When it fits, and when it does not

A GPU on Cloud Run fits work that comes and goes: an internal assistant used in office hours (an [AI agent backend](https://exodus.elim.io/blog/an-ai-agent-backend-on-cloud-run) that calls a hosted model needs no GPU at all), a transcription or embedding service called a few hundred times a day, a nightly batch job. You pay for the hours instances exist and nothing for the rest.

It fits badly when the GPU is busy all day. An L4 instance that never stops costs $763.96 a month on Cloud Run; a `g2-standard-4` Compute Engine VM with the same L4, 4 vCPU and 16 GB costs $568.15 a month in the same region at on-demand list prices, before its disk. Above roughly 18 hours of use a day the VM is cheaper; our [VM guide](https://exodus.elim.io/blog/compute-engine-vm-to-cloud-run) covers the other differences. It also fits badly when users cannot wait for a cold start and you cannot pay for a warm instance.

## Before the first deploy

### Instance-based billing

Most Cloud Run services bill only while a request is in flight. A GPU service cannot: Google's page says "You must use instance-based billing to use the GPU feature". The GPU, CPU and memory are billed for the whole life of each instance, from the start to the shutdown, with a minimum of one minute. There is no per-request fee. In `gcloud` this is the flag `--no-cpu-throttling`. Our [billing guide](https://exodus.elim.io/blog/request-based-or-instance-based-billing) explains the two modes.

The consequence is in the autoscaling page: Cloud Run keeps an idle instance for up to 10 minutes after its last request when it has a GPU. With instance-based billing those minutes are billed. One request after a quiet hour can therefore cost the start, the answer and up to ten idle minutes: about $0.17 of idle time alone for the smallest L4 instance.

### CPU and memory

An L4 needs at least 4 vCPU and 16 GiB of memory; Google recommends 8 vCPU and 32 GiB. An RTX PRO 6000 needs at least 20 vCPU and 80 GiB. The help of `gcloud run deploy` says the same for the L4:

![Terminal output. A curl request to the Service Usage API lists our project's four Cloud Run GPU quotas in europe-west1, L4 and RTX PRO 6000 with and without zonal redundancy, all 0. Then the help of the --gpu flag: values 0 or 1, and 1 GPU requires at least 4 CPU and 16Gi of memory](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-4ded562afed2dacb06c7ed863abeeaba86427cb8406f29003c46fcd65b0a3a74-680x310-svg/bytes "Our project's GPU quotas before any GPU deploy, and gcloud's own rule for the minimum size")

### Quota

GPUs are limited per project and per region. Google's quotas page lists the GPU quotas at 0 by default; the first deploy that uses an L4 or an RTX PRO 6000 in a region grants 3 GPUs without zonal redundancy. That is three instances at once, across all services in the region. A service's maximum instances cannot be set above the quota.

Our project, which has never deployed a GPU, shows all four quotas at 0 in `europe-west1`. You can read yours through the Service Usage API with your own token:

```shell
(umask 077; gcloud auth print-access-token | sed 's/^/Authorization: Bearer /' > token)
curl -s -H @token \
  "https://serviceusage.googleapis.com/v1beta1/projects/PROJECT_ID/services/run.googleapis.com/consumerQuotaMetrics?view=FULL&pageSize=200" \
  | jq -r '.metrics[] | select(.metric | test("gpu")) | .metric as $m
      | .consumerQuotaLimits[].quotaBuckets[] | select(.dimensions.region == "europe-west1")
      | "\($m | ltrimstr("run.googleapis.com/"))  \(.effectiveLimit // 0)"'
rm token
```

More GPUs take a quota request in the console. Google says requests without zonal redundancy "are more likely to be granted and will be made available more quickly".

### Zonal redundancy

A Cloud Run service runs across the zones of its region, and traffic moves away from a failed zone. For GPUs the other zones may have no spare capacity, so Cloud Run offers a choice:

- **Zonal redundancy on**, the default for services and worker pools: Google reserves GPU capacity in other zones for your service. The L4 costs $0.0002909 a second instead of $0.0001867, and the SLA is 99.95%.
- **Zonal redundancy off** (`--no-gpu-zonal-redundancy`): failover is best effort. The GPU is about 36% cheaper and the SLA is 99.5%.

Jobs support only the second. Google's tutorials turn it off, and so does this guide; turn it on when users would notice an hour of outage.

## A sample: Ollama with a model inside the image

Ollama runs open-weight models behind a small HTTP API, and Google's Cloud Run tutorial uses it. That tutorial pulls the model from the internet at every start, which Google's best practices page calls the slowest and least predictable way, so our sample downloads the weights at build time. The `Dockerfile`:

```dockerfile
FROM ollama/ollama:0.40.3

# Ollama listens on Cloud Run's port, keeps models in the image and never unloads them.
ENV OLLAMA_HOST=0.0.0.0:8080 \
    OLLAMA_MODELS=/models \
    OLLAMA_KEEP_ALIVE=-1 \
    OLLAMA_NUM_PARALLEL=4

# Download the weights at build time, so a new instance never fetches them from the internet.
ARG MODEL=gemma3:4b
ENV MODEL=${MODEL}
RUN ollama serve & sleep 5 && ollama pull "$MODEL"

COPY start.sh /start.sh
ENTRYPOINT ["/bin/sh", "/start.sh"]
```

And `start.sh` next to it:

```shell
#!/bin/sh
# Start the server, then load the model into GPU memory and answer one short prompt,
# so the first real request does not pay for the loading and the warm-up.
ollama serve &
until ollama list >/dev/null 2>&1; do sleep 0.2; done
ollama run "$MODEL" "Reply with one word: ready" >/dev/null
wait
```

`gemma3:4b` is 3.2 GB on disk; on our machine it took 3.5 GB of GPU memory with four parallel slots, far inside the L4's 24 GB. Pass another model with `--build-arg MODEL=...`.

Build it with Cloud Build on a larger machine, because the image is big, then deploy it to an L4 in Belgium:

```shell
gcloud artifacts repositories create models \
  --repository-format=docker --location=europe-west1

gcloud builds submit \
  --tag europe-west1-docker.pkg.dev/PROJECT_ID/models/ollama-gemma:1 \
  --machine-type=e2-highcpu-32 --disk-size=100

gcloud run deploy ollama-gemma \
  --image europe-west1-docker.pkg.dev/PROJECT_ID/models/ollama-gemma:1 \
  --region europe-west1 \
  --gpu 1 --gpu-type nvidia-l4 --no-gpu-zonal-redundancy \
  --cpu 8 --memory 32Gi --no-cpu-throttling \
  --concurrency 4 --max-instances 1 \
  --timeout 600 \
  --no-allow-unauthenticated
```

The service is private: a request without an identity token gets 403. To try it from your machine, run the proxy and call it on localhost:

```shell
gcloud run services proxy ollama-gemma --region europe-west1 --port 9090

curl http://localhost:9090/api/generate \
  -d '{"model": "gemma3:4b", "prompt": "What is a container?", "stream": false}'
```

Your app calls it with an ID token and the Invoker role, as our [IAM guide](https://exodus.elim.io/blog/iam-for-a-cloud-run-app) shows.

We built and ran this image on our build machine but did not deploy it: a GPU deploy in our project is a production change.

![A diagram in three lanes. A public web service with CPU only calls a private GPU service over HTTPS with an ID token. The GPU service has an instance with 1 L4 GPU of 24 GB, 4 or more vCPU and 16 or more GiB, and more instances within the GPU quota, all on instance-based billing, idle minutes included. At every start the model comes from the image, for models under 10 GB, or from Cloud Storage](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-d21ffccc240ef933f016afc08f42af08ae756e29d03d04aa26a0047614671b3e-680x430-svg/bytes "The usual shape: a CPU service in front, a private GPU service behind it, and the model loaded at every start")

## Where a cold start goes

Google's guide to AI cold starts splits a start into four phases: about 5 s to attach the GPU and its drivers, 1 to 2 s to stream the image, 5 to 15 s for the inference engine to initialize, and then the time to move the weights into GPU memory, which depends on the model's size and where it comes from.

We timed the sample image on our build machine, which has an NVIDIA RTX 3080 with 10 GB, mounting the driver libraries where Cloud Run mounts them. This is not Cloud Run and not an L4, so the absolute numbers are ours; the shape is what matters.

![Two timelines of a cold start of the sample image, Ollama with gemma3:4b, median of 3 runs on the GPU and 2 on the CPU, on our build machine. GPU, an RTX 3080 with 10 GB: port open in 3.5 s, the model loaded and warm at 59.5 s, then 102 tokens in 0.71 s, 150 tokens a second. CPU only, 20 threads: port open in 0.5 s, loaded and warm at 6.3 s, then 84 tokens in 9.36 s, 9 tokens a second](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-1242b72ef518fe0f3aae5fabe1f1a1a1e384e0d4e1fce08d2609f1e33d8bbebe-680x380-svg/bytes "The port opens in seconds; the model takes the rest. The GPU starts slower and then answers sixteen times faster")

Three things stood out:

- **The port opens long before the model is ready.** Ollama answered on its port in 3.5 s; the model was loaded and warm at 59.5 s. Cloud Run's default startup probe only checks the port, so it passes at 3.5 s and requests then wait inside Ollama.
- **Loading is not the end.** Without the warm-up line in `start.sh`, the model was loaded at 40.6 s and the first real request still took 17 s; the next ones took 0.9 s. A one-word prompt at startup moves that wait out of a user's request.
- **The GPU is for answers, not starts.** On the CPU alone the same image was ready in 6.3 s, then answered at 9 tokens a second instead of 150.

What helps, from Google's pages:

- **Small, quantized models.** Google recommends 4-bit models in fast formats such as GGUF, never pickle checkpoints.
- **The model in the image** for models under 10 GB. Cloud Run streams images, so a large image starts without being downloaded whole first.
- **Cloud Storage for larger models**, downloaded in parallel at startup with `gcloud storage cp` or mounted as a volume, with Direct VPC and Private Google Access, as Google advises. Our [Cloud Storage guide](https://exodus.elim.io/blog/files-and-uploads-with-cloud-storage) covers volume mounts.
- **A longer startup probe** when the model takes minutes. With a GPU the probe may wait up to 1,800 seconds instead of 600; our [health checks guide](https://exodus.elim.io/blog/health-checks-and-startup-probes) has the settings.
- **A wake-up call.** Google's cold start guide suggests calling a cheap endpoint, such as Ollama's `/api/tags`, when the user opens a chat, so the start runs while they type.
- **A minimum instance** removes the cold start at the full price, $763.96 a month for the smallest L4, because the idle rate does not apply to GPUs. Our [minimum instances guide](https://exodus.elim.io/blog/min-instances-and-startup-cpu-boost) covers the setting.

## Concurrency: one instance, how many requests

Cloud Run scales on request concurrency and CPU, not on GPU use: Google says Cloud Run "does not automatically scale the number of instances based on GPU utilization". So the concurrency setting decides when a second GPU instance starts.

For Ollama, Google's tutorial sets `--concurrency` equal to `OLLAMA_NUM_PARALLEL`, 4 in our sample, and at most twice that for a busier GPU. Above it, requests queue inside Ollama, and that queue does not make Cloud Run scale out. For other servers, Google's rule of thumb is (model instances x parallel queries per model) + (model instances x ideal batch size): 3 copies taking 4 queries each in batches of 4 give 24. Then test under load; our [concurrency guide](https://exodus.elim.io/blog/concurrency-on-cloud-run) covers the setting.

Set `--max-instances` too: within the quota, it caps what a spike can cost.

## What it costs

GPU prices are the same in `europe-west1`, `europe-west4`, `us-central1` and `us-east4`; `asia-southeast1` costs about 20% more. Per second, at list prices of October 12, 2026:

- L4 GPU: **$0.0001867** without zonal redundancy, **$0.0002909** with it.
- RTX PRO 6000 GPU: **$0.00036522** without, **$0.00056913** with.
- CPU on instance-based billing: $0.000018 per vCPU-second; memory $0.000002 per GiB-second.

So an hour of one instance costs:

- L4 at the minimum, 4 vCPU and 16 GiB: **$1.05** without zonal redundancy, $1.42 with it.
- L4 at Google's recommended 8 vCPU and 32 GiB: **$1.42**.
- RTX PRO 6000 at its minimum, 20 vCPU and 80 GiB: **$3.19**, or $3.92 with zonal redundancy.

The GPU is 64% of the small L4 instance's price.

![A horizontal bar chart of one GPU instance for a month, 730 hours, list prices of Oct 12, 2026. L4 with 4 vCPU and 16 GiB in Belgium: 1 hour a day $31.83, 8 hours a day $254.65, always on $763.96, always on with zonal redundancy $1,037.80. A g2-standard-4 Compute Engine VM with an L4, always on, without its disk: $568.15. RTX PRO 6000 with 20 vCPU and 80 GiB in the Netherlands, always on: $2,326.36](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-f6e976a05ce38dee8410b172b36a87198055a43e4e7aa656feb6a993f755aa84-680x452-svg/bytes "A GPU instance for a month: cheap when it runs an hour a day, dearer than a VM when it never stops")

A few rules move these numbers:

- **The free tier covers CPU and memory only.** Instance-based services get 240,000 vCPU-seconds and 450,000 GiB-seconds a month, worth $5.22; there is no free GPU time. Google's own example of an L4 service in `europe-west1` comes to $822.40 a month, and $827.62 without that free tier: the same $5.22. Our [free tier guide](https://exodus.elim.io/blog/the-cloud-run-free-tier-explained) explains how it is applied.
- **No committed use discount for GPUs.** The pricing page lists 1-year and 3-year discounts for CPU and memory and none for the GPU lines.
- **Idle minutes are billed.** Each scale-up can leave up to 10 idle minutes behind it, $0.17 each on the small L4.
- **Source deploys build on a bigger machine.** With a GPU, `gcloud run deploy --source` builds on `e2-highcpu-8` instead of `e2-standard-2`, which costs more per build minute.
- **The image is stored.** A model inside the image is a copy in Artifact Registry for every version you keep.

## Jobs and worker pools with a GPU

A Cloud Run job runs tasks to completion, which suits batch work such as transcription or embedding a document set. With a GPU a task may run for at most 1 hour, instead of 168 hours without one, and jobs must turn zonal redundancy off. Each parallel task takes a GPU, so keep `--parallelism` below your quota. An hour of an L4 task at the minimum size costs $1.05.

```shell
gcloud run jobs create transcribe \
  --image IMAGE_URL --region europe-west1 \
  --gpu 1 --gpu-type nvidia-l4 --no-gpu-zonal-redundancy \
  --cpu 4 --memory 16Gi \
  --tasks 10 --parallelism 3 --task-timeout 1h
```

A worker pool, an always-on group of instances without a URL, takes a GPU the same way, with zonal redundancy on by default. Our [services, jobs and worker pools guide](https://exodus.elim.io/blog/cloud-run-services-jobs-and-worker-pools) explains which to choose.

## What breaks

- **No quota.** The first deploy grants 3 GPUs, shared by every service in the region, and `--max-instances` cannot be set above the quota.
- **Zonal redundancy on, quota off.** Services default to zonal redundancy, but the automatic grant of 3 GPUs is for GPUs without it. Deploy with `--no-gpu-zonal-redundancy`, or request the other quota first.
- **Request-based billing.** A GPU service must use instance-based billing; Google's tutorial says `--no-cpu-throttling` "is required for enabling GPU".
- **The wrong region.** `europe-west1` has the L4 but not the RTX PRO 6000. Check the list before you pick a region for the rest of the app.
- **A probe that passes too early.** A TCP probe passes before the model loads, so the first requests wait and may hit the request timeout. Warm the model in the start script and set `--timeout` for that wait, or probe an endpoint that answers only when the model is ready.
- **A model pulled at startup.** Every new instance downloads gigabytes from outside Google and fails when that registry is down.
- **A model too large for the GPU.** What does not fit in VRAM spills to system memory and slows sharply. Pick a quantized size that fits with its context.
- **CUDA newer than the driver.** The driver supports CUDA 13.0. A newer CUDA needs NVIDIA's forward compatibility packages.
- **A public endpoint.** A model behind `--allow-unauthenticated` is a GPU anyone on the internet can keep busy at your expense.

## Checklist

1. Pick a GPU region; check that it has the GPU you need.
1. Read your GPU quotas; plan on 3 GPUs per region until a request is granted.
1. Choose a model that fits the GPU's memory with its context, quantized, in a fast format.
1. Put the model in the image if it is under 10 GB, else in Cloud Storage with Direct VPC; never download it from the internet at startup.
1. Load and warm the model in the start script, and give the startup probe and the request timeout room for it.
1. Deploy with `--gpu 1`, `--gpu-type`, `--no-cpu-throttling`, at least 4 vCPU and 16 GiB for an L4, `--max-instances` within the quota, and `--no-allow-unauthenticated`.
1. Set `--concurrency` to what the model server runs at once.
1. Decide on zonal redundancy: off for a first service, on when an hour of outage matters.
1. Work out the month: hours a day times $1.05 for the small L4, plus idle minutes, against $568.15 for a VM.

## Where Exodus comes in

Exodus does not plan GPUs today. We added `torch` and `transformers` to a copy of one of the CLI's sample apps and ran `exodus audit` and `exodus report`: neither mentions a GPU, and the estimate prices CPU and memory only. If your app needs a GPU, the report's cost is short by the GPU's hours, and the split in this guide is a decision for you and your coding agent, which can read this guide through `exodus kb` and `exodus ask`.

## FAQ

### How much does a GPU on Cloud Run cost per hour?

An L4 instance at its minimum size, 4 vCPU and 16 GiB, costs $1.05 an hour in europe-west1 without zonal redundancy and $1.42 with it. An RTX PRO 6000 at 20 vCPU and 80 GiB costs $3.19, or $3.92 with zonal redundancy. There is no free GPU time and no committed use discount for the GPU.

### How long does a Cloud Run GPU instance take to start?

The GPU and its drivers are ready in about 5 seconds; the rest is the model. On our build machine, not on Cloud Run, the port opened in 3.5 s and the model was loaded and warm at 59.5 s. Without the warm-up prompt the model was loaded at 40.6 s and the first request still took 17 s.

### Which regions offer GPUs on Cloud Run?

The L4 is offered in europe-west1, europe-west4, us-central1, us-east4, asia-southeast1 and, by invitation, asia-south1. The RTX PRO 6000 is offered in europe-west4, us-central1, asia-southeast1 and asia-south2.

### Can Cloud Run jobs use a GPU?

Yes. A job task with a GPU may run for at most 1 hour instead of 168, jobs must turn zonal redundancy off, and each parallel task takes a GPU from the quota, so keep --parallelism below it.

### Does Cloud Run scale on GPU utilization?

No. Cloud Run scales on request concurrency and CPU, so the concurrency setting decides when a second GPU instance starts. For Ollama, Google's tutorial sets it equal to the number of parallel requests the server runs.

## Sources

1. [GPU support for services, Cloud Run, Google (NVIDIA RTX PRO 6000 Blackwell with 96 GB of GPU memory and L4 with 24 GB; drivers pre-installed, version 580.x.x, CUDA 13.0; instances start in approximately 5 seconds; one GPU per instance, attached to one container; RTX PRO 6000 needs at least 20 CPU and 80 GiB, L4 at least 4 CPU and 16 GiB, 8 CPU and 32 GiB recommended; regions: RTX PRO 6000 in asia-southeast1, asia-south2, europe-west4, us-central1, L4 in asia-southeast1, asia-south1 by invitation, europe-west1, europe-west4, us-central1, us-east4; instance-based billing required, no per-request fees, minimum instances charged at the full rate even when idle; GPU billed for the entire instance lifecycle; source deploys with a GPU build on e2-highcpu-8; zonal redundancy on by default, reserves capacity in other zones at a higher price; first use in a region grants 3 GPUs of quota without zonal redundancy; increases without zonal redundancy are more likely to be granted; maximum instances cannot exceed the quota; driver libraries under /usr/local/nvidia/lib64 added to LD_LIBRARY_PATH; gcloud flags --gpu, --gpu-type nvidia-l4 or nvidia-rtx-pro-6000, --no-gpu-zonal-redundancy; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/configuring/services/gpu)
2. [Best practices: AI inference on Cloud Run services with GPUs, Google (Cloud Storage downloaded concurrently is recommended, container images for models under 10 GB, the internet is slow and unpredictable; Cloud Storage loading needs Direct VPC with all-traffic egress and Private Google Access; base images from Deep Learning Containers or NVIDIA; 4-bit quantized models, fast formats such as GGUF, no pickle checkpoints; Ollama can open its port before the model is loaded; Cloud Run does not scale on GPU utilization; maximum concurrency rule of thumb (model instances x parallel queries) + (model instances x batch size), 24 in the example; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/configuring/services/gpu-best-practices)
3. [Cloud Run pricing, Google (instance-based services: CPU $0.000018 per vCPU-second, memory $0.000002 per GiB-second; GPU per second: L4 $0.0001867 without zonal redundancy and $0.0002909 with, RTX PRO 6000 $0.00036522 and $0.00056913; no committed use discount listed for GPUs; jobs list only the prices without zonal redundancy; instance-based billing covers the whole instance life with a minimum of 1 minute, rounded up to 100 ms; free tier for instance-based services 240,000 vCPU-seconds and 450,000 GiB-seconds a month; example 3, an L4 service in europe-west1, $822.40 a month, $827.62 without the CPU and memory free tier; read Oct 12, 2026)](https://cloud.google.com/run/pricing)
4. [Cloud Billing Catalog API, Cloud Run SKUs (service 152E-C115-5142): the same GPU, CPU and memory prices in europe-west1, europe-west4, us-central1 and us-east4; asia-southeast1 higher (L4 $0.00022404 per second); read Oct 12, 2026](https://docs.cloud.google.com/billing/docs/reference/rest/v1/services.skus/list)
5. [Cloud Billing Catalog API, Compute Engine SKUs (service 6F81-5844-456A): G2 in europe-west1, $0.02751452 per vCPU-hour, $0.003223414 per GiB-hour, NVIDIA L4 $0.6166603 per GPU-hour, on demand; read Oct 12, 2026](https://cloud.google.com/compute/gpus-pricing)
6. [GPU machine types, Compute Engine, Google (g2-standard-4: 4 vCPUs, 16 GB of memory, 1 NVIDIA L4 with 24 GB; read Oct 12, 2026)](https://docs.cloud.google.com/compute/docs/gpus)
7. [Configure GPUs for Cloud Run jobs, Google (L4 and RTX PRO 6000 for jobs; non-zonal redundancy only, --no-gpu-zonal-redundancy required; same quota grant of 3; parallelism should stay below the GPU quota; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/configuring/jobs/gpu)
8. [GPU support for worker pools, Cloud Run, Google (both GPU types, zonal redundancy on by default; updated Oct 9, 2026, read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/configuring/workerpools/gpu)
9. [Cloud Run quotas and limits, Google (job tasks up to 168 hours, or 1 hour with GPUs; GPU instance quotas per project per region, 0 by default; new projects get 3 L4 GPUs without zonal redundancy on the first service; if peak GPU usage is not close to the quota, Google might decrease it; read Oct 12, 2026)](https://docs.cloud.google.com/run/quotas)
10. [Cloud Run SLA, Google (Cloud Run service non-GPU 99.95%; GPU with zonal redundancy 99.95%, without 99.5%; 99.9% and 99.5% in the regions listed separately; read Oct 12, 2026)](https://cloud.google.com/run/sla)
11. [Cloud Run release notes, Google (GPUs for services GA on Apr 7, 2025; europe-west1 added Mar 11, 2025; GPUs for jobs GA on Oct 21, 2025; RTX PRO 6000 Preview on Feb 2, 2026 and GA on Apr 13, 2026; worker pools GA on Apr 14, 2026; source deploys with a GPU build on e2-highcpu-8, 'a moderate increase in the overall cost'; L4 driver 580.x.x on Aug 11, 2026; read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/release-notes)
12. [About instance autoscaling, Cloud Run, Google (idle instances kept up to 15 minutes, or 10 minutes for GPUs; read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/about-instance-autoscaling)
13. [Configure container health checks, Cloud Run, Google (startup probe period and total time up to 600 seconds, 1,800 for GPU; read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/configuring/healthchecks)
14. [Run LLM inference on GPUs with Gemma 4 and Ollama, Cloud Run tutorial, Google (Ollama with --concurrency equal to OLLAMA_NUM_PARALLEL, at most twice it for utilization; OLLAMA_KEEP_ALIVE=-1; --no-allow-unauthenticated and gcloud run services proxy; the model is pulled at startup; read Oct 12, 2026)](https://docs.cloud.google.com/run/docs/tutorials/gpu-gemma-with-ollama)
15. [A Guide to AI Cold Starts on Cloud Run, Google Cloud blog, May 27, 2026 (four phases: GPU and drivers about 5 s, image streaming 1 to 2 s, engine initialization 5 to 15 s, then the model into GPU memory; Cloud Storage FUSE does not parallelize the first download; with instance-based billing the idle time between requests is billed; a wake-up call to a non-inference endpoint such as Ollama's /api/tags; read Oct 12, 2026)](https://cloud.google.com/blog/topics/developers-practitioners/a-guide-to-ai-cold-starts-on-cloud-run)
16. [High-performance inference meets serverless compute with NVIDIA RTX PRO 6000 on Cloud Run, Google Cloud blog, Feb 2, 2026 (96 GB, 1.6 TB/s, models up to 70B+ parameters, up to 44 vCPU and 176 GB of RAM per instance; read Oct 12, 2026)](https://cloud.google.com/blog/products/serverless/cloud-run-supports-nvidia-rtx-6000-pro-gpus-for-ai-workloads)
17. [Ollama FAQ (preloading a model; keep_alive and OLLAMA_KEEP_ALIVE, a negative value keeps the model loaded; read Oct 12, 2026)](https://docs.ollama.com/faq)
18. [gcloud run deploy, gcloud run jobs create, gcloud run worker-pools deploy, gcloud builds submit, Google Cloud SDK (--gpu accepts 0 or 1 and needs 4 --cpu and 16Gi --memory; --gpu-type; --[no-]gpu-zonal-redundancy; --[no-]cpu-throttling; --startup-probe keys; builds on e2-highcpu-32 with --machine-type and --disk-size; checked against gcloud 587.0.0 help on Oct 12, 2026)](https://docs.cloud.google.com/sdk/gcloud/reference/run/deploy)
19. Exodus team: on Oct 12, 2026 we read our own project's Cloud Run GPU quotas in europe-west1 (all 0, nothing deployed with a GPU), and built and timed the sample image on our build machine, an RTX 3080 with 10 GB, outside Cloud Run: port open in 3.5 s, gemma3:4b loaded and warmed in 59.5 s, a 102-token answer in 0.71 s at 150 tokens a second; on the CPU alone 6.3 s and 9.4 tokens a second; without the warm-up prompt the first answer took 17 s; exodus 0.1.1 reports nothing about a torch dependency