Running Gemma 4 on EC2 G5g: Graviton2 AMD with NVIDIA GPU

An engineer successfully ran Google's Gemma 4 E2B model on AWS EC2 G5g, a Graviton2 (aarch64) instance with an NVIDIA T4G GPU, achieving 43.1 tokens per second after patching vLLM. The deployment required overcoming three major obstacles: missing architecture support in official builds, a version floor that only the newest vLLM clears, and a 64 KiB shared memory limit. The engineer found that AWS's Deep Learning ARM64 AMI includes PyTorch with sm_75 support, avoiding a from-source PyTorch build, but vLLM's own kernels required compilation for the Turing architecture.

A field report on serving Google's Gemma 4 E2B on AWS EC2 G5g — a Graviton2 aarch64 host with an NVIDIA T4G Turing, SM 7.5 GPU. Three obstacles: an arch list nobody publishes for this combination, a version floor that only the newest vLLM clears, and 64 KiB of shared memory that stops the model dead. Plus the seven things I documented wrong before I had a box. | Model | google/gemma-4-E2B-it reference bf16 release | | Hardware | AWS EC2 g5g.4xlarge — Graviton2 + 1x NVIDIA T4G, compute capability 7.5, 15,360 MiB | | Base image | Deep Learning ARM64 AMI OSS Nvidia Driver GPU PyTorch 2.12 Ubuntu 24.04 | | Software | torch 2.12.0+cu132 · CUDA 13.2 · vLLM v0.27.2rc0 built from source for sm 75 | | Result | 43.1 tok/s single-stream greedy, 329,579-token KV cache — after one patch to vLLM | G5g is the only instance AWS has ever shipped that puts an NVIDIA GPU behind a Graviton host. It launched in 2020, it never got a successor, and Graviton is now on its fifth generation without one. That matters more than it sounds. The Arm-plus-CUDA world moved on to NVIDIA's own Arm CPU — Grace, paired with SM 9.0 and 10.0 parts. Turing stayed well supported, on x86. G5g is the only hardware that is aarch64 and compute capability 7.5, and almost nobody publishes a build for that combination. I put a rig on one anyway. The packaging problem was the quick part. Everything after it — a compiler that was not there, a version floor I did not expect, and 32 KiB of shared memory — took far longer, because none of it fails where you are looking. Start with the obvious candidate. vllm/vllm-openai:v0.27.1 publishes both platforms under one tag, and you can read the arch lists straight out of the image config without pulling a layer: docker buildx imagetools inspect vllm/vllm-openai:v0.27.1 --format '{{json .Image}}' linux/amd64 7.5 8.0 8.6 8.9 9.0 10.0 12.0 linux/arm64 8.0 8.7 8.9 9.0 10.0 11.0 12.0 The one architecture this hardware needs is the only entry the two images disagree on. The arm64 list is Ampere and up, because that is what ships as an Arm-plus-NVIDIA system: A100, Jetson Orin, GH200, Blackwell. Turing is not on that list and never will be. Normally a missing target degrades to JIT from embedded PTX. Not here. The Dockerfile says so, with a comment: Do not add +PTX here: vLLM filters torch's top-level PTX flag when it converts global gencode flags into per-kernel arch lists. So it does not run slowly. It fails outright, with no kernel image is available for . execution on the device The rest of the ecosystem splits the same way. Check before you plan anything: | Artifact | 7.5 on arm64 | State | |---|---|---| vllm/vllm-openai arm64 | no | Current. Never had it. | nvcr.io/nvidia/pytorch arm64 | through 24.10 | Dropped by 24.12. | drikster80/vllm-aarch64 | yes | Abandoned Sept 2024. vLLM 0.6.1, far too old for Gemma 4. | | PyPI torch aarch64 | no | Built for 9.0 / 10.0 / 12.0. | AWS ARM64 GPU DLAMI | yes | Maintained. PyTorch 2.2 through 2.12. | This is the finding that saves the whole exercise, and I nearly wrote it off. I had assumed PyTorch's aarch64 CUDA wheels lacked sm 75 and that a from-source PyTorch build was coming. That is true of the PyPI wheels. It is not true of AWS. Read on two different DLAMIs, on the box: torch 2.7.0+cu128 'sm 75', 'sm 90', 'sm 100', 'sm 120' torch 2.12.0+cu132 'sm 75', 'sm 80', 'sm 90', 'sm 100', 'sm 110', 'sm 120' AWS sells G5g, so AWS keeps Turing in the build — right through PyTorch 2.12 on CUDA 13.2, an image cut three months ago. PyTorch never needs building. Only vLLM's own kernels do, and CMake takes the arch list without argument: -- CUDA target architectures: 7.5 CMake Warning: Pytorch version 2.11.0 expected for CUDA build, saw 2.12.0 instead. That warning is worth reading twice, and I come back to it below. Two things the DLAMI does not give you, neither of them documented anywhere I could find. There is no nvcc . The image ships the driver and a torch built against CUDA, not the toolkit. You need the keyring and cuda-toolkit-13-2 from NVIDIA's sbsa repo — not the x86 one, which is an easy reflex to get wrong on an Arm box. And vLLM now wants Rust. Its vllm-rs frontend needs setuptools rust plus a toolchain, and the failure is a bare ModuleNotFoundError: No module named 'setuptools rust' thrown from metadata generation, several minutes in. No vLLM tag pins torch 2.12. They go 2.11, then jump to 2.13. I reasoned that building older code against a newer runtime was the safer direction, took v0.26.0, and spent an hour being wrong about it. It builds fine. It then dies on model load: transformers.integrations.heterogeneity.configuration utils.AmbiguousGlobalPerLayerAttributeError: 'head dim' is a per-layer attribute and may vary across layers. Gemma 4's head dim is not one number, and current transformers refuses to hand out a global value for it. vLLM's config converter was still doing a flat getattr config, "head dim", 0 . The per layer config handling that copes with it landed in v0.27.2rc0 — not v0.27.1, which I also checked. The newest tag was the only one that worked. If you take one process lesson from this: reach for the latest release first, and make the constraint say out loud what stopped you when you fall back. With the build working the server still would not start, and this failure has nothing to do with Arm or packaging. It is this model against this chip. Gemma4 model has heterogeneous head dimensions {'sliding attention': 256, 'full attention': 512}. FA4 not available, forcing TRITON ATTN backend. Read that as a chain, because every link is load-bearing: TRITON ATTN . VLLM ATTENTION BACKEND is not a recognised variable in v0.27 — it logs Unknown vLLM environment variable detected and carries on. I set it twice before I read the warning. head size=512 wants about 96 KiB of shared memory per block.Turing's shared memory is two numbers, and both are real. The default static limit per block is 48 KiB — that is what torch.cuda.get device properties .shared memory per block reports, 49,152 bytes. A kernel that needs more has to opt in through the dynamic shared-memory attribute, and even then it tops out at 64 KiB . Ampere and later have 164 KiB and up. Triton opts in, so it is measuring against the 64 KiB ceiling. It still does not fit: triton.runtime.errors.OutOfResources: out of resource: shared memory, Required: 98304, Hardware limit: 65536 Refused outright. Not slow, not degraded — the kernel will not launch, and it takes the engine down during CUDA graph capture, which is late enough that you have already watched the weights load and the KV cache get sized. The fix is small. Shrink the KV tile until the query block and the K/V tiles fit inside the budget, and drop the software pipeline to one stage. Gate it on pre-Ampere so it is a no-op on every other card: if current platform.get device capability 0 < 8: smem budget = 60000 esz = q.element size def fits t : return BLOCK M + 2 t head size esz <= smem budget while TILE SIZE PREFILL 16 and not fits TILE SIZE PREFILL : TILE SIZE PREFILL //= 2 while TILE SIZE DECODE 16 and not fits TILE SIZE DECODE : TILE SIZE DECODE //= 2 launch num stages = 1 With that in vllm/v1/attention/ops/triton unified attention.py , graphs capture, the engine comes up in 76 seconds, and the model serves. This is not upstream. It lives on my instance and has to be reapplied on any vLLM upgrade, which makes it the obvious thing to send back. 67 minutes on a g5g.4xlarge at MAX JOBS=12 , and the majority of it is FlashAttention. vLLM compiles FA2 and FA3 regardless of TORCH CUDA ARCH LIST — I watched it grind sm90 Hopper instantiations on a build targeting 7.5 only. FA2 needsConstraining VLLM FA CMAKE GPU ARCHES should cut that dramatically. I did not try it, because by the time I understood what I was looking at the build was 45 minutes in and interrupting it would have cost more than finishing. I wrote the rig's documentation before provisioning anything. Seven claims in it were wrong, and every correction came off the machine rather than out of an argument. This is the part I would keep if I kept nothing else. | What I wrote | What the box said | |---|---| PyTorch aarch64 lacks sm 75 | AWS DLAMI has it, on both versions I checked | | bfloat16 is a hard failure here | Torch upconverts; vLLM logs Casting torch.bfloat16 to torch.float16 and proceeds | | The backend is XFORMERS | TRITON ATTN , forced, not selectable | VLLM ATTENTION BACKEND picks it | Not a recognised variable. I had shipped dead config. | | w4a16 needs sm80+ Marlin | The build compiled sm75 kernel float16 u4b8 float16.cu.o | | The GPU has 16 GB | 15,360 MiB | /v1/completions returns an empty body | It returns ': ok: ok: ok: ok' — garbage, not silence | That last one has teeth. If you health-check by testing for an empty response, this endpoint passes while producing nonsense. Use /v1/chat/completions and read the text. One claim is still standing only because I never tested it: whether g5g.xlarge 's 8 GiB of host RAM can stage 9.5 GiB of weights. Safetensors loading is mmap-backed, so I suspect it can. It is labelled untested rather than stated as fact, which is where it should have been all along. content: 'Site Reliability Engineering SRE is a discipline that applies software engineering principles to infrastructure and operations problems to create highly reliable, scalable, and efficient systems.' finish reason: stop usage: 19 prompt / 32 completion / 51 total | Measure | Value | |---|---| | Throughput, single stream greedy | 42.9 tok/s @ 64, 43.1 @ 256 | | KV cache | 2.95 GiB, 329,579 tokens | | Concurrency at 16k context | 20.12x | | GPU memory while serving | 13,501 / 15,360 MiB | | Engine init | 76.4 s, graph capture 17 s | | Memory bandwidth, measured | 277.0 GB/s read · 234.3 GB/s copy 320.1 theoretical | Before reading too much into 43 tok/s, note what the memory does. The T4G has GDDR6, not HBM — 256-bit bus at 5,001 MHz, so 320 GB/s theoretical. I measured Single run, single stream, no repeats and no variance figure. One sample per cell, and taken with the clamped tiles, so it is a floor rather than a characterisation. My Inferentia port measured about 44 tok/s for E2B on one core, which is the same neighbourhood — but that is a different harness on different silicon and I would not put the two in one table. | Symptom | Cause | |---|---| no kernel image is available | Stock arm64 image. No 7.5, no PTX. Build from source. | OutOfResources: shared memory | Turing's 64 KiB against a 512-wide head. Clamp the tiles. | AmbiguousGlobalPerLayerAttributeError | vLLM older than v0.27.2rc0. | No module named 'setuptools rust' | Missing Rust toolchain for vllm-rs . | nvcc: not found | PyTorch DLAMI has no toolkit. Install cuda-toolkit-13-2 sbsa . | Unknown vLLM environment variable | You set VLLM ATTENTION BACKEND . It does nothing. | | Healthy endpoint, nonsense output | You checked /v1/completions . Use chat completions. | Take the AWS ARM64 GPU PyTorch DLAMI — it is the only maintained aarch64 stack that still carries sm 75 . Add cuda-toolkit-13-2 from the sbsa repo and a Rust toolchain, because the image ships neither. Build vLLM v0.27.2rc0 or newer from source with TORCH CUDA ARCH LIST=7.5 and use existing torch.py , and patch the Triton attention kernel to fit Turing's shared memory before you try to start it. Serve with --dtype float16 and --kv-cache-dtype auto . Nothing here failed loudly, and nothing failed where I was looking. The packaging gap I built the rig around was already solved by AWS; the thing that actually stopped me was 32 KiB of shared memory and a model whose global attention heads are twice as wide as its sliding ones. Hardware this far off the mainstream will keep producing that shape of surprise — the fix is not to reason harder about it, but to get to a box sooner and let it tell you. Measured on EC2 g5g.4xlarge spot, us-east-1a. NVIDIA T4G, compute capability 7.5,