{"slug": "gemma-4-on-a-tesla-t4-part-2-the-minimum-gce-vm-and-a-script-to-drive-it", "title": "Gemma 4 on a Tesla T4, Part 2: The Minimum GCE VM and a Script to Drive It", "summary": "A developer published a step-by-step guide for deploying Gemma 4 E2B on a Google Compute Engine instance with a single Tesla T4 GPU, using a minimal n1-standard-2 host and a 250 GB data disk mounted at /opt1. The writeup reconstructs the gcloud create command from the running VM's metadata and documents the post-boot software install, reporting 362 seconds from `vllm-t4 start` to a healthy vLLM endpoint with 13,371 MiB of the T4's 15,360 MiB claimed. A companion set of Python MCP tools manages the vLLM deployment, while the `vllm-t4` shell script owns host state such as the swapfile and reboot checklist.", "body_md": "*This article provides a step by step deployment guide for **Gemma 4 E2B** to a **Tesla T4** hosted GPU enabled system. A suite of Python MCP tools is built to simplify management of the vLLM hosted deployment. Part 1 measured which checkpoint the card runs fastest; this part builds the machine underneath it, installs the stack after first boot, and walks through `vllm-t4`, the shell script that owns the host state the MCP tools do not.*\n\n[github.com/xbill9/gemma4-dev/tree/main/gpu-vllm-t4-2b](https://github.com/xbill9/gemma4-dev/tree/main/gpu-vllm-t4-2b)\n\n| Host | Compute Engine `n1-standard-2` ,`us-west2-b` — 2 vCPU, 7.8 GB RAM | \n| GPU | 1x Tesla T4, Turing, compute capability 7.5, 15360 MiB | \n| Image | `debian-13-trixie-v20260609` , no driver preinstalled | \n| Disks | 32 GB pd-ssd boot, 250 GB pd-balanced at `/opt1` | \n| Software | vLLM 0.29.0, torch 2.13.0+cu130, driver 615.71.09 | \n| Result | **362 s** from`vllm-t4 start` to a healthy endpoint, 13371 MiB of 15360 claimed | \n\nPart 1 began with the GPU already working. This part begins with a Google Cloud project and nothing in it.\n\nThe work splits in two. Everything before first boot is a single `gcloud` command whose choices are GPU choices: which zone sells a T4, what a GPU does to the maintenance policy, and how much disk to attach given where the checkpoints land. Everything after first boot is software on a Debian image that ships no NVIDIA driver at all.\n\n`gcloud` authenticated locally\nRead from the instance metadata server and the guest OS on the running VM:\n\n```\nmachine-type: n1-standard-2\nzone:         us-west2-b\nimage:        projects/debian-cloud/global/images/debian-13-trixie-v20260609\nscheduling:   {\"automaticRestart\":\"TRUE\",\"onHostMaintenance\":\"TERMINATE\",\"preemptible\":\"FALSE\"}\ndisks:        [{\"deviceName\":\"debian13\",\"type\":\"PERSISTENT-SSD\"},\n               {\"deviceName\":\"persistent-disk-1\",\"type\":\"PERSISTENT-BALANCED\"}]\nTesla T4, 7.5, 15360 MiB, 615.71.09\nnproc: 2\nMemTotal: 7436 MiB\n```\n\nOn Compute Engine the T4 attaches to the N1 machine family, so the host shape is an N1 choice. This one is the smallest N1 that has been used for this work. Two vCPU costs startup time, and 7.8 GB of RAM is the number that decides the swapfile section below.\n\nThe command below is reconstructed from the running VM's own metadata — machine type, zone, image, scheduling policy and both disk types are read back from the instance, and the accelerator from `nvidia-smi`. Re-running the create call was out of scope for this article.\n\n```\ngcloud compute instances create gemma4-t4 \\\n  --zone=us-west2-b \\\n  --machine-type=n1-standard-2 \\\n  --accelerator=type=nvidia-tesla-t4,count=1 \\\n  --maintenance-policy=TERMINATE \\\n  --restart-on-failure \\\n  --image-project=debian-cloud \\\n  --image-family=debian-13 \\\n  --boot-disk-size=32GB \\\n  --boot-disk-type=pd-ssd \\\n  --create-disk=name=gemma4-t4-data,size=250GB,type=pd-balanced,auto-delete=no\n```\n\nThree flags in there are about the GPU.\n\n`--maintenance-policy=TERMINATE` is required on any instance with an attached GPU. Compute Engine live-migrates ordinary VMs during host maintenance and cannot migrate one with a GPU, so the API rejects the default `MIGRATE` policy. The metadata confirms what the instance ended up with:\n\n```\n{\"automaticRestart\":\"TRUE\",\"onHostMaintenance\":\"TERMINATE\",\"preemptible\":\"FALSE\"}\n```\n\nPairing it with `--restart-on-failure` means maintenance stops the VM and brings it back. The server process does not come back with it, and neither does the swapfile — there is a reboot checklist at the end of this article for that reason.\n\nThe boot disk is 32 GB and the model cache goes on a second 250 GB disk mounted at `/opt1`:\n\n```\nNAME     SIZE TYPE MOUNTPOINT\nsda       32G disk\n├─sda1  31.9G part /\n├─sda14    3M part\n└─sda15  124M part /boot/efi\nsdb      250G disk /opt1\n```\n\nA bf16 E2B checkpoint is 10.2 GB and the QAT build is 8.3 GB, so both together are most of a 32 GB root disk before pip has unpacked a CUDA torch wheel. Splitting them keeps the root disk for the OS and puts every multi-gigabyte write on the larger, cheaper volume. `~/.cache` is a symlink to `/opt1/cache`, so Hugging Face downloads land there without any environment variable.\n\nThe data disk is mounted from `/etc/fstab` and survives a reboot:\n\n```\nUUID=8bd96fe8-e301-41d9-8ccc-8123ce89c4a8 /opt1 ext4 discard,defaults,nofail 0 2\nMounted on    1B-blocks        Avail\n/           33570021376   8450138112\n/tmp         3898789888   3897544704\n/opt1      263086084096 200857059328\n```\n\nThree filesystems, and the two multi-gigabyte writes an install makes land on different ones. `/tmp` is its own 3.9 GB filesystem, which is where pip unpacks wheels, and a CUDA torch plus its NVIDIA runtime dependencies do not fit in it. A single `df /` reports the wrong answer for all three writes.\n\nThe Debian 13 image carries no NVIDIA driver. `nvidia-smi` does not exist on a fresh boot. The driver comes from NVIDIA's own CUDA repository for Debian 13:\n\n```\n/etc/apt/sources.list.d/cuda-debian13-x86_64.list:\ndeb [signed-by=/usr/share/keyrings/cuda-archive-keyring.gpg] https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/ /\nsudo apt-get install -y linux-headers-$(uname -r)\nwget https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/cuda-keyring_1.1-1_all.deb\nsudo dpkg -i cuda-keyring_1.1-1_all.deb\nsudo apt-get update\nsudo apt-get install -y nvidia-driver\n```\n\nWhat that pulls in:\n\n```\nlinux-headers-7.1.8+deb13-cloud-amd64   7.1.8-1~bpo13+1\nnvidia-driver                           615.71.09-2\nnvidia-driver-cuda                      615.71.09-2\nnvidia-kernel-open-dkms                 615.71.09-2\nnvidia-kernel-support                   615.71.09-2\n```\n\nThe kernel module is the open variant and DKMS compiles it against the running kernel, so the matching `linux-headers` package has to be installed first. The running kernel here is `7.1.8+deb13-cloud-amd64` and its headers come from backports, so the headers install gets its own line ahead of the driver.\n\nReboot, then check:\n\n``` bash\n$ nvidia-smi --query-gpu=name,compute_cap,memory.total,driver_version --format=csv\nname, compute_cap, memory.total [MiB], driver_version\nTesla T4, 7.5, 15360 MiB, 615.71.09\n```\n\nCompute capability 7.5 is Turing, and it is the number that governs everything in Part 1: no bfloat16 datapath, no fp8, and a 64 KiB shared-memory ceiling per block that the Triton attention kernel has to be clamped to fit.\n\n7.8 GB of RAM, and the VM ships with no swap. vLLM is killed by the kernel while staging E2B weights without some, which reads as a crash with no traceback.\n\n```\nsudo fallocate -l 16G /opt1/swapfile\nsudo chmod 600 /opt1/swapfile\nsudo mkswap /opt1/swapfile\nsudo swapon /opt1/swapfile\n```\n\nThe swapfile lives on the data disk, so the file itself persists. `/etc/fstab` has no swap line, so a reboot leaves the file in place and disabled. While serving the QAT build, 3592 MiB of the 16 GB is in use.\n\nThere are two interpreters on this host and the default is the one with no room:\n\n``` php\npython3             -> pyenv 3.12.13, site-packages on /        8.45 GB free\n/usr/bin/python3.13 -> user site at /opt1/pyuser            200.86 GB free\n```\n\nThe MCP server runs under `python3`. vLLM runs under `/usr/bin/python3.13` with `PYTHONUSERBASE=/opt1/pyuser`, which puts its packages on the large disk. A relocated user site is the same interpreter's own site directory on a different filesystem, so site-packages stays system-wide and no virtualenv is involved.\n\nBoth redirections below are load-bearing on this host — one for where packages land, one for where pip unpacks them:\n\n```\nPYTHONUSERBASE=/opt1/pyuser PIP_CACHE_DIR=/opt1/pipcache TMPDIR=/opt1/tmp \\\n  /usr/bin/python3.13 -m pip install --user --break-system-packages -U \\\n  --upgrade-strategy eager \\\n  --extra-index-url https://download.pytorch.org/whl/cu130 vllm\n```\n\nvLLM pins torch to an exact version, so this moves torch with it. Installing torch with `--no-deps` skips cuDNN and the NVIDIA runtime wheels, and `import torch` then fails on `libcudnn.so.9`.\n\n```\ntorch        2.13.0+cu130\ntransformers 5.17.0\ntriton       3.7.1\nvllm         0.29.0\n```\n\nThe published cu130 wheels carry `sm_75`, so Turing needs no source build. `make arch` asks the interpreter for the list instead of reading the directory.\n\nGemma 4 mixes two attention widths — 256 in its sliding-window layers, 512 in its global layers — and vLLM forces its Triton backend for that mix. At width 512 the kernel asks for more shared memory than a Turing block allows. `make patch` clamps the tile sizes in the installed vLLM:\n\n```\n✅ **Patched**, in the site-packages this host's `python3` imports.\n\n__FILE__/opt1/pyuser/lib/python3.13/site-packages/vllm/v1/attention/ops/triton_unified_attention.py\nCLAMP PRESENT\nOCCURRENCES 1\n```\n\nReinstalling or upgrading vLLM reverts it, because the patch edits a file in site-packages and pip replaces that file. Re-run `make verify-patch` after any vLLM change.\n\n`vllm-t4`\nAt this point the host is ready and the remaining job is running the server. The rig's `tpu.env` holds every serving value, and the MCP tools cover capacity, architecture and patching. Three things are neither rig config nor MCP concerns: the swapfile, launching a process that outlives the shell, and waiting for the endpoint to answer.\n\n`~/bin/vllm-t4` owns those three. Every serving value it passes to vLLM is read out of the rig's `tpu.env` at call time and none is spelled in the script:\n\n``` php\nrigval() {\n  sed -n \"s/^$1=//p\" \"$rig/tpu.env\" | tail -1\n}\n```\n\n`tpu.env` is a dotenv file whose comments are prose, so sourcing it would both fail as shell and drag `TMPDIR` and `PYTHONUSERBASE` into the calling shell. Reading one key at a time keeps the file authoritative without importing it.\n\n`nohup`\n`make serve` runs `python3 -c \"asyncio.run(server.start_vllm_server())\"`. asyncio terminates the child subprocess when that short-lived interpreter exits, so the engine is gone about a second after launch, having written nothing to the log. The Part 1 sweep was started under the long-lived MCP server process, where the parent stays alive.\n\n`vllm-t4 start` launches with `nohup` and `disown` from bash, and writes the same `run/vllm.pid` and `run/vllm.log` that the rig's own status and stop tools read, so the script and the MCP tools agree about what is running.\n\n| Command | What it does | \n|---|---|\n| `vllm-t4 start` | Enable swap, confirm the clamp, launch detached, wait for `/health` , print status | \n| `vllm-t4 start nowait` | The same, returning as soon as the process is up | \n| `vllm-t4 stop` | `make stop` — SIGTERM to the pid, VRAM released on exit | \n| `vllm-t4 status` | `make status` — serving or not, plus claimed VRAM | \n| `vllm-t4 query` | `make query` — one chat completion against the endpoint | \n| `vllm-t4 log` | `tail -f` on`run/vllm.log` | \n| `vllm-t4 swap` | Create and enable the swapfile, without starting anything | \n\nFour environment variables override the defaults:\n\n| Variable | Default | Use | \n|---|---|---|\n| `VLLM_T4_RIG` | `$HOME/gemma4-dev/gpu-vllm-t4-2b` | Point at a different rig directory | \n| `VLLM_T4_SWAPFILE` | `/opt1/swapfile` | Put swap on another volume | \n| `VLLM_T4_SWAPSIZE` | `16G` | Size it differently | \n| `VLLM_T4_WAIT` | `1800` | Seconds to wait for `/health` | \n\n`start` Runs Three Guards Before It Launches\nEach guard costs less than the failure it prevents.\n\n**Swap**, because the engine is killed during weight loading without it and the kernel log is the only place that says so. `ensure_swap` creates the file if it is absent, enables it if it exists, and reports when it is already on.\n\n**The clamp**, because an unpatched engine spends minutes loading and then dies with an out-of-resources error that gets attributed to configuration. The check matches the verifier's positive string and refuses on anything else:\n\n```\ncase $out in\n  *'✅ **Patched**'*) echo \"$prog: Turing clamp confirmed\" ;;\n  *) echo \"$out\" >&2\n     die \"the Turing clamp is not confirmed -- run 'make -C $rig patch'\" ;;\nesac\n```\n\nA verifier that cannot import vLLM at all answers neither way, so a whitelist of known-bad strings would admit every unknown-bad one. Matching the single good answer fails closed.\n\n**The config**, because an empty value from `tpu.env` becomes an empty CLI argument. Every key is checked for a value and `PYTHON_BIN` for executability before anything launches.\n\n``` bash\n$ vllm-t4 start\nvllm-t4: swap already on: /opt1/swapfile (16777212 KB)\nvllm-t4: Turing clamp confirmed\nvllm-t4: starting google/gemma-4-E2B-it-qat-w4a16-ct on 127.0.0.1:8000\nvllm-t4: pid 17215, log /home/xbill_glitnir_com/gemma4-dev/gpu-vllm-t4-2b/run/vllm.log\nvllm-t4: waiting up to 1800s for http://127.0.0.1:8000/health\n     0s  VRAM 0 MiB, 0 %\n    75s  VRAM 0 MiB, 0 %\n    90s  VRAM 1093 MiB, 10 %\n   105s  VRAM 9005 MiB, 10 %\n   166s  VRAM 9301 MiB, 0 %\n   181s  VRAM 8403 MiB, 0 %\n   241s  VRAM 13371 MiB, 0 %\n   347s  VRAM 13371 MiB, 0 %\nvllm-t4: healthy after 362s -- http://127.0.0.1:8000\n✅ Serving at http://127.0.0.1:8000 (pid 17215).\n\nVRAM 13371 MiB, 15360 MiB, 0 %\n```\n\nVRAM is printed beside the clock because for the first minutes a compiling engine and a dead one look identical from outside, and claimed device memory is what tells them apart. The shape of that column is the startup: nothing for 75 seconds while Python imports and the weights are read off disk, 9005 MiB once the weights are resident, a dip to 8403 while the engine profiles, then 13371 when the KV cache is allocated.\n\nThe same start, in `run/vllm.log`:\n\n```\nnon-default args: {'host': '127.0.0.1', 'model': 'google/gemma-4-E2B-it-qat-w4a16-ct', 'dtype': 'float16', 'max_model_len': 16384, 'gpu_memory_utilization': 0.9, 'max_num_seqs': 8}\nCasting torch.bfloat16 to torch.float16.\nUsing MarlinLinearKernel for CompressedTensorsWNA16\nModel loading took 8.02 GiB memory and 88.981559 seconds\nAvailable KV cache memory: 4.66 GiB\nGPU KV cache size: 519,681 tokens, Maximum concurrency for 16,384 tokens per request: 31.72x\ninit engine (profile, create kv cache, warmup model) took 61.77 s (compilation: 2.59 s)\n```\n\n`Casting torch.bfloat16 to torch.float16` is the checkpoint's stored dtype meeting `--dtype float16` from `tpu.env`. Turing has no bfloat16 datapath, so PyTorch would upconvert regardless; setting the flag makes the conversion a decision with a record.\n\nCompilation took 2.59 s here against 112.77 s on the first start of this stack, because `torch.compile` caches its artifacts under `~/.cache` and that cache is warm. A first start on a fresh VM pays the full compile, and on 2 vCPU it is the largest single item in the wall clock.\n\n`status` and `query`\n\n``` bash\n$ vllm-t4 status\n✅ Serving at http://127.0.0.1:8000 (pid 17215).\n\nVRAM 13371 MiB, 15360 MiB, 0 %\nbash\n$ vllm-t4 query\n{\n    \"model\": \"google/gemma-4-E2B-it-qat-w4a16-ct\",\n    \"choices\": [{\"message\": {\"role\": \"assistant\",\n      \"content\": \"A TPU, or Tensor Processing Unit, is a specialized type of integrated circuit designed to significantly accelerate the mathematical operations central to training and running machine learning models, particularly those involving matrix multiplications.\"},\n      \"finish_reason\": \"stop\"}],\n    \"system_fingerprint\": \"vllm-0.29.0-9a66a08c\",\n    \"usage\": {\"prompt_tokens\": 18, \"total_tokens\": 56, \"completion_tokens\": 38}\n}\n```\n\nThat target posts to `/v1/chat/completions`. Raw `/v1/completions` returns an empty string on an instruction-tuned checkpoint, so an empty result there means the wrong endpoint was called.\n\nThe server is the standard OpenAI-compatible one, on `127.0.0.1:8000`:\n\n``` bash\n$ curl -fsS http://127.0.0.1:8000/v1/models\n{\"object\":\"list\",\"data\":[{\"id\":\"google/gemma-4-E2B-it-qat-w4a16-ct\",\"object\":\"model\",\n \"owned_by\":\"vllm\",\"root\":\"google/gemma-4-E2B-it-qat-w4a16-ct\",\"max_model_len\":16384}]}\ncurl -fsS http://127.0.0.1:8000/v1/chat/completions \\\n  -H 'Content-Type: application/json' \\\n  -d '{\"model\":\"google/gemma-4-E2B-it-qat-w4a16-ct\",\n       \"messages\":[{\"role\":\"user\",\"content\":\"Name the four inner planets, comma separated.\"}],\n       \"temperature\":0,\"max_tokens\":64}'\nMercury, Venus, Earth, Mars\nusage: {'prompt_tokens': 18, 'total_tokens': 26, 'completion_tokens': 8}\n```\n\nStreaming works the same way, with `\"stream\": true`:\n\n```\nchunks: 16\ndata: {\"object\":\"chat.completion.chunk\",\"choices\":[{\"delta\":{\"role\":\"assistant\",\"content\":\"\"}}]}\ndata: {\"object\":\"chat.completion.chunk\",\"choices\":[{\"delta\":{\"content\":\"1\"}}]}\n...\ndata: [DONE]\n\nassembled: 1, 2, 3, 4, 5\n```\n\nPrometheus metrics are on `/metrics`, which is the route to per-request counters without a benchmark tool:\n\n```\nvllm:num_requests_running{engine=\"0\",model_name=\"google/gemma-4-E2B-it-qat-w4a16-ct\"} 0.0\nvllm:prompt_tokens_total{...} 53.0\nvllm:generation_tokens_total{...} 49.0\n```\n\nThe model id in every request body has to match what `/v1/models` reports, which is `MODEL_NAME` from `tpu.env`. Serving the bf16 build for an A/B means overriding `MODEL_NAME` and `MODEL_SAFETENSORS_BYTES` in the environment, and the id in the request body changes with it.\n\n``` bash\n$ vllm-t4 start                                  # one is already running\nvllm-t4: already running (pid 14977) -- 'vllm-t4 status', or 'vllm-t4 stop' first   [exit 1]\n\n$ vllm-t4 bogus\nusage: vllm-t4 [start|stop|status|query|log|swap] [nowait]                          [exit 2]\n\n$ vllm-t4 swap                                   # already enabled\nvllm-t4: swap already on: /opt1/swapfile (16777212 KB)                              [exit 0]\n\n$ VLLM_T4_RIG=/nonexistent vllm-t4 status\nvllm-t4: rig not found: /nonexistent (set VLLM_T4_RIG)                              [exit 1]\n```\n\nIf the engine dies during the wait, the script prints the last 20 log lines and points at the kernel log, because a memory kill leaves no traceback in vLLM's own output:\n\n```\nif [ -z \"`running_pid`\" ] ; then\n  echo \"$prog: the engine died during startup; last 20 log lines:\" >&2\n  tail -20 \"$rig/run/vllm.log\" >&2\n  echo \"$prog: if there is no traceback, check 'dmesg -T | grep -i oom'\" >&2\nbash\n$ vllm-t4 stop\n✅ Sent SIGTERM to vLLM (pid 14977). VRAM is released on exit.\n\nThe T4 stays attached and the VM stays billed — stopping the server is not releasing capacity here.\n```\n\nVRAM returns to `0 MiB, 15360 MiB` within seconds. Swap is left enabled, since it costs nothing idle and the next start needs it.\n\nThe VM and its attached T4 bill by the hour whether vLLM runs or not. `gcloud compute instances stop gemma4-t4 --zone us-west2-b` stops the instance charge and keeps both disks, which keep billing at the much lower storage rate. Deleting the instance with `auto-delete=no` on the data disk leaves the 250 GB of checkpoints for the next VM.\n\nThree things come back on their own and one does not.\n\n|  | Survives a reboot | \n|---|---|\n| `/opt1` data disk | 🟢 in `/etc/fstab` | \n| NVIDIA driver | 🟢 DKMS module, loads at boot | \n| Turing clamp | 🟢 a file in site-packages | \n| `/opt1/swapfile` | ❌ the file persists, the `swapon` does not | \n\n`vllm-t4 start` re-enables swap every time, so the checklist after a reboot is one command. Adding a swap line to `/etc/fstab` makes it survive on its own.\n\nThe goal of this article was to build the smallest Compute Engine VM that serves Gemma 4 E2B on one Tesla T4, deploy the stack after first boot, and document the script that runs it. The key to the solution was keeping the rig's `tpu.env` authoritative for every serving value and giving the script only the three things that are host state: the swapfile, a detached launch, and waiting for the endpoint. The measured results were:\n\n`vllm-t4 start` to a healthy endpoint on a warm compile cache, `--maintenance-policy=TERMINATE` is required for an attached GPU, and stops the VM during host maintenance`swapon` does not survive a reboot`df` reports the wrong free space for all three writes the install makes\nOne Tesla T4 on one `n1-standard-2` VM in `us-west2-b`, Debian 13, vLLM 0.29.0 on torch 2.13.0+cu130, driver 615.71.09. The start timing is a single run on a warm `torch.compile` cache; a first start on a fresh VM pays the full compilation, which was 112.77 s on this host. The `gcloud compute instances create` command is reconstructed from the running instance's metadata and was not re-executed. Throughput figures for the two checkpoints are in Part 1.\n\nThe strategy for using MCP for Tesla T4 deployment and benchmarking was validated with an incremental step by step approach.", "url": "https://wpnews.pro/news/gemma-4-on-a-tesla-t4-part-2-the-minimum-gce-vm-and-a-script-to-drive-it", "canonical_source": "https://dev.to/gde/gemma-4-on-a-tesla-t4-part-2-the-minimum-gce-vm-and-a-script-to-drive-it-3gk1", "published_at": "2026-09-22 17:24:01+00:00", "updated_at": "2026-09-22 17:53:14.137440+00:00", "lang": "en", "topics": ["ai-infrastructure", "large-language-models", "mlops", "ai-tools", "agent-protocols"], "entities": ["Gemma 4 E2B", "Tesla T4", "Google Compute Engine", "vLLM", "NVIDIA", "Debian", "PyTorch", "MCP"], "alternates": {"html": "https://wpnews.pro/news/gemma-4-on-a-tesla-t4-part-2-the-minimum-gce-vm-and-a-script-to-drive-it", "markdown": "https://wpnews.pro/news/gemma-4-on-a-tesla-t4-part-2-the-minimum-gce-vm-and-a-script-to-drive-it.md", "text": "https://wpnews.pro/news/gemma-4-on-a-tesla-t4-part-2-the-minimum-gce-vm-and-a-script-to-drive-it.txt", "jsonld": "https://wpnews.pro/news/gemma-4-on-a-tesla-t4-part-2-the-minimum-gce-vm-and-a-script-to-drive-it.jsonld"}}