Fine-Tuning and Serving Gemma 4 31B on Google Cloud TPU: A Technical Comparison with GPU Baselines

We present the first end-to-end demonstration of fine-tuning and serving Google's Gemma 4 31B model on TPU hardware, providing an empirical comparison of TPU and GPU platforms for large language model adaptation. Using LoRA on a Google TPU v5p-8 for training and TPU v6e-8 (Trillium) for inference, we document the full set of code-level adaptations required to port a GPU-native training recipe, built on PyTorch, HuggingFace TRL, and FSDP, to the JAX + Tunix/Qwix stack. These adaptations span mesh configuration, LoRA module naming conventions, sharding annotation corrections, gradient checkpointing, data pipeline restructuring, and a custom Orbax-to-safetensors checkpoint merging procedure. For inference, we detail the vLLM-TPU Docker setup necessary to serve Gemma 4 on v6e-8 and characterize the resulting latency and throughput profile. Compared with a 2xH100 GPU baseline under identical hyperparameters, TPU training completes 1.61x faster at 2.12x lower cost. Inference throughput is within 3% across platforms, while TPU achieves 2x lower time-to-first-token (235 ms vs. 475 ms). Together, the TPU configuration is 1.82x cheaper for a representative train-plus-service workload. Our work removes a critical gap in the open tooling ecosystem and provides practitioners with a reproducible, production-ready recipe for Gemma 4 deployment on TPU infrastructure.

Paper

References (10)

03ICI interconnect : TPU chips communicate via the ICI mesh at 900 GB/s bidirectional bandwidth, significantly faster than the H100’s NVLink at ˜900 GB/s total (but NVLink is shared across more links)
04“VerilogEval: Evaluating LLMs for Verilog Code Generation,”ICCAD
05XLA fusion : XLA compiles the forward+backward pass into a single fused kernel per layer, eliminating the kernel launch overhead present in PyTorch’s eager mode, even with FSDP
06Reasoning strip : The CodeV-R1 dataset contains chain-of-thought reasoning in <think>...</think> blocks. We strip these and keep only the <answer> block (or the Verilog fence directly),
07“Gemma 4 31B,”huggingface
08Memory headroom : 411 GB total HBM (training) + fp8 KV cache enables 2 × more concurrent long-context requests
09“CodeV: Empowering LLMs for Verilog Generation through Multi-Level Summarization,”arXiv
10P99 ITL at short context : slightly better tail latency (20.49 ms vs 22.29 ms at 128-token inputs) due to no XLA bucket padding overhead 16

Similar papers

© 2026 NYSGPT2525 LLC