vLLM TorchTPU bringt vLLM-Modellbetrieb auf Google Cloud TPUs
Das vLLM-Projekt hat vLLM TorchTPU (vllm-torchtpu) veröffentlicht, ein neues Backend, das vLLM auf Google Cloud TPUs ausführt. Laut Projekt lassen sich die meisten Modelle, die bereits in vLLM laufen, ohne Änderungen am Modellcode auf TPUs betreiben.
- vLLM TorchTPU (vllm-torchtpu) ist ein neues Plugin-Backend, das vLLM auf Google Cloud TPUs ausführt und auf Googles TorchTPU-Stack aufbaut.
- Die meisten Modelle, die in vLLM laufen, lassen sich ohne Änderungen am Modellcode auf TPUs betreiben, mit gleicher CLI, OpenAI-kompatiblem Server und Scheduler.
- Hinzu kommen Pallas-Kernels, alle sechs Parallelisierungsdimensionen von vLLM, KV-Cache-Offloading und disaggregiertes Prefill/Decode-Serving.
- TPU v7x (Ironwood) wird empfohlen und in der CI getestet; v6e, v5e und v5p sind experimentell.
- Ein Community-Pool stellt Beitragenden kostenlose TPU-Zeit zur Verfügung.
Ein Plugin auf Basis von Googles TorchTPU-Stack
vllm-torchtpu baut auf Googles TorchTPU-Stack auf und geht aus der Engineering-Partnerschaft zwischen Inferact und Google hervor, die das vLLM-Team nach eigenen Angaben im vergangenen Monat angekündigt hat. Es handelt sich um ein Out-of-Tree-Plattform-Plugin: Nach der Installation erkennt vLLM es automatisch über den Entry Point vllm.platform_plugins.
Die Modelle laufen über den Standard-Model-Runner von vLLM und werden mit torch.compile(backend="tpu") kompiliert, was auf XLA heruntergebrochen wird. Wie bei GPUs erhält jedes TPU-Gerät einen eigenen Worker-Prozess, die Geräte kommunizieren über torch.distributed. Laut dem vLLM-Team bleiben Scheduler, Worker, KV-Cache-Manager und API-Server unverändert im Upstream-vLLM. Die TPU-spezifische Arbeit liegt darunter, vor allem in JAX/Pallas-Kernels, die als Custom Ops registriert sind.
Die Installation erfolgt mit pip install vllm-torchtpu. Erforderlich sind Python 3.12 auf einer Cloud-TPU-VM; dabei werden passende Versionen von vLLM, torch, torch_tpu und libtpu installiert. Beim ersten Start werden TPU-Graphen für die konfigurierten Shapes kompiliert, was einige Minuten dauern kann. Mit VLLM_XLA_CACHE_PATH lassen sich kompilierte Artefakte über Neustarts hinweg wiederverwenden.
Kernels, Parallelisierung und Serving-Funktionen
Das Projekt setzt auf eigene Pallas-Kernels für Operationen, die von manueller Optimierung auf TPUs profitieren. In der Ankündigung werden unter anderem genannt:
- Ragged Paged Attention v3 für MHA/GQA-Modelle
- dichte und sparse Multi-head Latent Attention (MLA) für DeepSeek, Kimi und GLM
- Gated DeltaNet und Kimi Delta Attention für hybride Linear-Attention-Modelle
- Fused Mixture-of-Experts mit Expert Parallelism
- quantisierte Matrixmultiplikationen in FP8, INT8, MXFP4 und NVFP4
Alle sechs Parallelisierungsdimensionen von vLLM werden auf TPU-Slices mit einem und mit mehreren Hosts unterstützt und lassen sich kombinieren: Tensor-, Data-, Pipeline-, Expert-, Prefill-Context- und Decode-Context-Parallelism. Bei großen MoE-Modellen erzielt das Team nach eigenen Angaben meist den besten Durchsatz mit datenparalleler Attention in Kombination mit Expert Parallelism, etwa DP=8, TP=1 mit EP auf einem einzelnen v7x-Host.
Der Fokus des Teams liegt auf mehrstufigem agentischem und multimodalem Traffic, bei dem Kontexte stetig wachsen und Tool-Ausgaben lang sein können. Dafür nutzt vllm-torchtpu TPU Sync, eine quelloffene C++-Bibliothek, die TPU-Gerätepuffer direkt außerhalb der Python-Laufzeit ausliest. Über die KV-Connector-Schnittstelle von vLLM ermöglicht sie zero-copy KV-Cache-Offloading in den Host-DRAM sowie disaggregiertes Prefill/Decode-Serving über mehrere TPU-Hosts hinweg. Prefill und Decode können unterschiedliche Layouts verwenden, der KV-Cache wird bei der Übertragung neu aufgeteilt.
Speculative Decoding unterstützt MTP, EAGLE-3, DFlash, DSpark sowie N-Gram- und Suffix-Decoding. Automatisches Prefix Caching funktioniert auch für hybride Modelle wie Qwen3.5 und Kimi K3, bei denen der Linear-Attention-Zustand zusammen mit dem KV-Cache zwischengespeichert wird.
Unterstützte Hardware und Modelle
vllm-torchtpu kann die meisten von vLLM unterstützten Modelle bereitstellen. Enthalten sind TPU-spezifische Arbeiten an Kernels, Quantisierung und Parallelisierung für die Familien Qwen, DeepSeek, Kimi, GLM, Llama, GPT-OSS und Gemma. TPU v7x (Ironwood) ist die empfohlene Hardware und wird bei jedem Pull Request in der CI getestet, während v6e, v5e und v5p als experimentell gelten. Eine Seite „Supported Models & Features“ listet validierte Checkpoints auf, und nächtliche Support-Matrizen verfolgen Korrektheit und Benchmark-Ergebnisse auf v7x.
Das Beispiel der Ankündigung betreibt Qwen/Qwen3-Coder-30B-A3B-Instruct-FP8 mit Tensor-Parallel-Size 8, Expert Parallelism, fp8-KV-Cache und asynchronem Scheduling über den gewohnten Befehl vllm serve.
Roadmap und Bedeutung für Anwender
Das Team will, dass neue offene Modelle der großen Familien schon am Veröffentlichungstag auf TPUs laufen. Zur öffentlichen Roadmap gehören eine automatisierte CI-Pipeline, die neue Open-Weight-Modelle binnen 24 Stunden nach Veröffentlichung einbindet, benchmarkt und Support-Matrizen veröffentlicht, außerdem Prefix-, Cache- und Session-bewusstes Routing, llm-d-Routing für TPU-Speicherebenen, PyTorch-Schnittstellen für Tokamax-Kernels und das Serving von Diffusionsmodellen über vllm-omni.
Zudem öffnet das Projekt einen Community Contribution TPU Capacity Pool. Entwickler, die auf vllm-torchtpu aufbauen, können sich um kostenlose TPU-Zeit bewerben, und die Core-Maintainer von vLLM bei Inferact unterstützen bei Design und Pull-Request-Reviews.
Für Teams, die bereits vLLM betreiben, liegt der praktische Nutzen in der Kontinuität: Laut Projekt sind CLI, OpenAI-kompatibler Server, Scheduler und KV-Cache-Manager dieselben wie auf anderer Hardware. Damit dürften TPUs eine direktere Option für den Betrieb offener Modelle werden, wobei Ironwood vorerst das am besten unterstützte Ziel ist.
vLLM: Introducing vLLM TorchTPU
