--- title: "GPU-Virtualisierung: Thunder Compute Leitfaden" canonical: https://wavect.io/de/blog/thunder-compute-gpu-virtualization-series-a/ language: de description: "Thunder Compute prüfen: GPU-Pooling, MIG, vGPU und Passthrough vergleichen, ROI berechnen, Risiken bewerten und einen Enterprise-Pilot planen." image: "https://wavect.io/img/blog/headers/header_thunder-compute-gpu-virtualization-series-a.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 Min Lesezeit · 21. Aug. 2026 Zuletzt geprüft 21. August 2026 [**Weiter**](/de/blog/local-models-vs-apis-break-even-eu-2026/) # Thunder Computes 13-Mio.-Dollar-Wette auf GPU-Virtualisierung: Einkaufsleitfaden TL;DR Thunder Compute hat eine Series A über 13 Millionen US-Dollar aufgenommen, um seine netzwerkbasierte GPU-Virtualisierung in Enterprise- und Cloud-Provider-Flotten zu bringen. Die Software übersetzt CUDA-Aufrufe in Netzwerknachrichten, löst ungenutzte GPUs von Workloads und weist sie neu zu, ohne die Anwendung zu ändern. Wirtschaftlich ist das dort plausibel, wo teure GPUs reserviert, aber nur stoßweise genutzt, zwischen Teams fragmentiert oder durch starre Servergrenzen blockiert sind. Der Ansatz ersetzt MIG, Time-Sliced vGPU, Passthrough, Batching oder Autoscaling nicht pauschal. Käufer sollten erfolgreiche Arbeit pro Flottenstunde, p95-Latenz, Queue-Zeit, Fehlerbehebung, Kompatibilität und Isolation gegen den bestehenden Stack messen. Kaufe erst nach einem begrenzten Pilot, wenn die zurückgewonnene Kapazität Runtime-Overhead, Integrationskosten und Betriebsrisiko übersteigt. Thunder Compute hat am 19. August 2026 eine Series A über 13 Millionen US-Dollar aufgenommen. Damit soll die GPU-Virtualisierung aus der eigenen Cloud mit mehr als 10.000 Nutzern in Flotten von Unternehmen und Cloud-Providern kommen. Matrix Partners führte die Runde an, Y Combinator und CEAS Investments beteiligten sich. Diese Fakten stammen aus [Thunder Computes Finanzierungsankündigung](https://www.thundercompute.com/blog/thunder-compute-series-a). Für Infrastruktur-Einkäufer zählt jedoch eine schwierigere Frage: Schafft netzwerkbasiertes GPU-Pooling mehr nutzbare Kapazität, als es durch Latenz, Integration und Betriebsrisiko kostet? **Kurzantwort:** GPU-Virtualisierung kann blockierte Kapazität lösen, wenn Workloads stoßweise laufen, GPUs fest an Server oder Teams gebunden sind und Scheduler Leerlauf nicht zurückholen. Sie erzeugt keine zusätzliche Rechenleistung. Sie verändert, wer wann auf eine physische GPU zugreifen kann und wie fein die Flotte zugeteilt wird. Die richtige Methode hängt von Workload, Isolation, Speicher, Netzwerk und Latenz ab. Dieser Artikel beantwortet die Einkaufsfrage zu GPU-Virtualisierung und GPU-Pooling. Unser [Break-even-Rechner für lokale Modelle und APIs](/de/blog/local-models-vs-apis-break-even-eu-2026/) beantwortet davor, ob ein Unternehmen Inferenzkapazität überhaupt selbst besitzen sollte. Wenn du bereits eine GPU-Flotte besitzt oder reservierst, hilft dieser Leitfaden bei der Frage, ob Virtualisierung sie produktiver macht. ## Warum Thunder Computes Series A relevant ist Die Finanzierung ist ein Marktsignal, kein Beleg dafür, dass jede GPU virtualisiert werden sollte. Sie finanziert den Schritt von einer kontrollierten Vendor-Cloud in bestehende Enterprise-Umgebungen. Damit steigt die Beweislast. Ein Cloud-Produkt kontrolliert Hardware, Netzwerk und Workload-Grenzen. Ein Enterprise-Produkt muss mit Kubernetes, Slurm, VMs, Bare Metal, Security-Zonen, Change Windows und unbekannten Workloads funktionieren. Das Auslastungsproblem ist real, Prozentwerte brauchen aber Kontext. CAST AI maß in seinem Datensatz eine durchschnittliche GPU-Auslastung von 5 Prozent. Die Daten stammen aus zehntausenden Kubernetes-Clustern auf AWS, Azure und Google Cloud vor der Optimierung. Gemessen wurde der Anteil bereitgestellter GPU-Rechenzyklen, der über 24 Stunden nützlichen Output erzeugt. Derselbe [Kubernetes Optimization Report 2026](https://cast.ai/reports/kubernetes-optimization-report/) zeigt einen Cluster mit 136 H200 bei 49 Prozent. Die Lücke spricht für bessere Betriebsverfahren, beweist aber weder 5 Prozent für jede Enterprise-Flotte noch Virtualisierung als alleinige Lösung. ## Was ist GPU-Virtualisierung? GPU-Virtualisierung trennt die Sicht eines Workloads auf einen Accelerator von der physischen GPU, die ihn ausführt. Die Abstraktion kann eine ganze GPU einer VM zuweisen, eine GPU in isolierte Teile teilen, Rechenzeit zwischen Mandanten aufteilen oder entfernte GPUs über ein Netzwerk bereitstellen. Ziel sind bessere Zuteilung, Portabilität oder Isolation. Jede Methode verschiebt andere Engpässe und schafft ein anderes Fehlermodell. | Ansatz | Was geteilt wird | Guter Fit | Wichtigster Nachteil | | --- | --- | --- | --- | | PCIe-Passthrough | Eine ganze GPU für eine VM | Maximale Kompatibilität und planbare Leistung | Leerlauf bleibt blockiert | | NVIDIA MIG | Feste Compute- und Speicherteile auf einer unterstützten GPU | Parallele Workloads mit Hardware-Isolation | Statische Größen fragmentieren Kapazität | | Time-Sliced vGPU | GPU-Rechenzeit zwischen VMs | Interaktive oder gemischte Workloads | Durchsatz und Latenz schwanken unter Last | | Netzwerk-GPU-Pooling | GPUs über Servergrenzen und Workloads über das Rechenzentrumsnetz | Stoßweise Flotten mit blockierter Kapazität | Netzwerk- und Kompatibilitäts-Overhead | Diese Optionen ergänzen sich. NVIDIA dokumentiert Time-Sliced vGPU als zeitliche Partitionierung. MIG erstellt räumlich isolierte Instanzen mit eigenen Compute- und Speicherressourcen. MIG-backed vGPU kann beides kombinieren. Die [NVIDIA-Dokumentation zu vGPU-Funktionen](https://docs.nvidia.com/knowledge-base/latest/vgpu-features.html) macht die Unterschiede bei Isolation, Scheduling und unterstützten Plattformen sichtbar. ## Wie Thunder Computes Netzwerk-GPU-Pooling funktioniert Thunder Compute setzt laut eigener Beschreibung an der CUDA-Grenze an. Der Workload sendet bekannte CUDA-Aufrufe. Die Software übersetzt sie in Nachrichten an eine entfernte GPU im Rechenzentrumsnetz. Während der aktiven Nutzung erhält der Workload alleinigen Zugriff. Wenn der Prozess endet oder wartet, kann sich die GPU lösen und einem anderen Workload dienen. Thunder meldet für die eigene Cloud eine erste Verbindung in ungefähr 10 bis 20 Millisekunden und rund 1,8-mal mehr bediente Nutzer mit derselben Flotte. Seltene Edge Cases können laut Anbieter ungefähr doppelt so langsam wie native Ausführung sein. Das sind Herstellerangaben, keine unabhängigen Benchmarks. Sie zeigen den richtigen Einkaufsmaßstab: Miss die zusätzliche erledigte Arbeit der gesamten Flotte, nicht die Geschwindigkeit eines einzelnen Kernels. Architektur und Grenzen beschreibt Thunder im [technischen Überblick zu GPU-over-TCP](https://www.thundercompute.com/blog/how-thunder-compute-works-gpu-over-tcp). ## ROI von GPU-Virtualisierung: zurückgewonnene Kapazität statt Auslastungstheater Ein höherer Auslastungsgraph ist nicht automatisch ein besseres Geschäftsergebnis. Der GPU Duty Cycle kann steigen, während nützlicher Durchsatz, Latenz oder Zuverlässigkeit schlechter werden. Google empfiehlt, KI-Infrastruktur über Scheduling-, Runtime- und Program-Goodput zu messen. Diese Kennzahlen zeigen, ob Ressourcen verfügbar waren, nützliche Schritte abgeschlossen wurden und wie viel Hardwareleistung das Programm extrahierte. Das [Goodput-Modell von Google Cloud](https://docs.cloud.google.com/architecture/framework/perspectives/ai-ml/performance-optimization) ist eine bessere Pilotbasis als ein einzelner GPU-Prozentsatz. Virtualisierungswert pro Monat = vermiedene neue GPU-Kapazität + zusätzliche produktive Flottenstunden + kürzere Queue-Kosten, minus Software, Netzwerk, Integration und Betrieb. Vergleiche Baseline und Testgruppe. Erfasse erfolgreiche Jobs oder Requests, bereitgestellte Accelerator-Stunden, nützliche Accelerator-Stunden, Queue-Zeit, p50- und p95-Latenz, Fehler, Retries, Energie und Engineer-Stunden. Trenne nach Workload-Klasse. Training, interaktive Inferenz und Entwickler-Notebooks in einen Durchschnitt zu werfen, versteckt das Ergebnis. ### Scorecard für den Pilot | Kennzahl | Warum sie zählt | Kaufsignal | | --- | --- | --- | | Erfolgreiche Arbeit pro Flottenstunde | Zeigt zurückgewonnene Kapazität | Verbesserung bleibt nach Fehlern und Retries | | p95-End-to-End-Latenz | Zeigt Netzwerk- und Scheduling-Tails | Bleibt innerhalb des Produktions-SLO | | Queue- und Startzeit | Zeigt schnelleren Kapazitätszugriff | Sinkt für eingeschränkte Workloads | | Kompatibilitätsquote | Findet problematische Kernel und Tools | Repräsentative Workloads laufen ohne Fallbacks | | Recovery und Blast Radius | Testet Infrastrukturfehler | Recovery erfüllt das Runbook | | Kosten pro erfolgreiche Aufgabe | Verbindet Kapazität, Software und Betrieb | Schlägt Flotte und Cloud-Alternative | ## Wo Netzwerk-GPU-Virtualisierung gut passt - **Entwicklungs- und Forschungsflotten:** Notebooks und Experimente wechseln zwischen Rechenzeit und menschlicher Denkzeit. - **Stoßweise Single-GPU-Inferenz:** unabhängige Services haben Peaks zu unterschiedlichen Zeiten. - **Fragmentierte Organisationen:** Teams besitzen getrennte Queues, während andere warten. - **Fest gebuchte Cloud-Kapazität:** die Organisation bezahlt bereits einen fixen Footprint. - **GPU-Sandboxes für Agents:** kurze, I/O-lastige Sessions lassen große Lücken zurück. ## Wo der Ansatz schlecht passen kann - **Eng gekoppelte Multi-GPU-Trainings:** Kommunikation und Topologie können dominieren. - **Dauerhaft gesättigte Jobs:** es gibt kaum Leerlauf zurückzugewinnen. - **Sehr strenge Tail-Latenz:** Netzwerkvarianz kann das SLO brechen. - **Hardwarespezifisches Profiling:** die Abstraktion kann wichtige Details verstecken. - **Unklare Mandantenisolation:** prüfe Memory-Clearing, Identity, Netzwerksegmente, Logs und Fehlergrenzen. ## So führst du einen Enterprise-Pilot durch 1. **Miss die bestehende Flotte zwei Wochen.** Segmentiere nach Workload, GPU, Queue, Team und Tageszeit. 2. **Wähle drei Workload-Formen.** Nimm einen wahrscheinlichen Gewinner, einen latenzsensitiven Fall und einen bekannten Problemfall. 3. **Teste Normal- und Fehlerpfade.** Miss kalte Zuweisung, Steady State, p95, GPU-Reset, Host-Verlust, Netzdegradation, Abbruch und Datenbereinigung. 4. **Berechne den vollen Betrieb.** Addiere Lizenzen, Netzwerk, Integration, Observability, On-call, Security Review und Vendor-Abhängigkeit. 5. **Setze die Entscheidungsschwelle vorher.** Definiere Mindest-Goodput, maximale Latenzverschlechterung, Kompatibilitätsquote und Payback. ## Fragen an Thunder Compute oder andere GPU-Virtualisierungsanbieter - Welche CUDA-Versionen, GPUs, Treiber, Frameworks, Custom Kernels und Profiler werden unterstützt? - Welche Workload-Traces erzeugten die Kapazitätsangabe und was war die Baseline? - Wie verändern sich p50, p95 und p99 je Workload-Klasse? - Was geschieht bei Ausfall von GPU, Host, Switch oder Control Plane? - Wie wird GPU-Speicher gelöscht und welche Evidenz belegt die Isolation? - Ergänzt oder ersetzt das Produkt Kubernetes, Slurm, MIG und bestehende Quoten? - Kann der Kunde Metriken, Policies und Workload-Zuordnungen exportieren? - Hängt der Preis an GPUs, Hosts, zurückgewonnener Kapazität oder Nutzung? ## Fazit: Virtualisierung kann nutzbares Angebot schaffen, aber nur ein Workload-Trace beweist es Thunder Compute greift eine wertvolle Schicht an: Kapazität, die zwischen Workloads, Servern und Organisationsgrenzen festsitzt. Die Series A gibt dem Unternehmen Mittel, das Modell außerhalb der eigenen Cloud zu beweisen. Sie macht aus der gemeldeten Auslastungslücke noch keinen automatischen ROI. Für eine Flotte mit stoßweisen Reservierungen und langen Queues verdient Netzwerk-GPU-Pooling einen kontrollierten Pilot. Bei gesättigtem Multi-GPU-Training, strenger Tail-Latenz oder Problemen, die Batching, Autoscaling, MIG oder Time Slicing bereits lösen, beginne mit den einfacheren Hebeln. Entscheidend ist, welche Abstraktion mehr erfolgreiche Arbeit pro Euro erzeugt, ohne Leistung, Security oder Betrieb zu schwächen. ## FAQ zur GPU-Virtualisierung ### Was ist der Unterschied zwischen GPU-Virtualisierung und GPU-Pooling? GPU-Virtualisierung ist die breite Abstraktion zwischen Workload und physischem Accelerator. GPU-Pooling stellt GPUs über mehrere Server als gemeinsame Ressource bereit. ### Erhöht GPU-Virtualisierung die rohe GPU-Leistung? Nein. Sie kann produktive Flottenkapazität erhöhen, indem sie Leerlauf reduziert. Einzelne Workloads können wegen Scheduling und Netzwerk gleich schnell oder langsamer laufen. ### Ersetzt Thunder Compute NVIDIA MIG? Nicht zwingend. MIG erstellt isolierte Hardwareteile auf einer GPU. Thunder Compute poolt GPUs über ein Netzwerk. Eine Architektur kann beides kombinieren. ### Welche Hauptkennzahl sollte ein Pilot nutzen? Nutze erfolgreiche Arbeit pro Flottenstunde und sichere sie mit p95-Latenz, Queue-Zeit, Fehlerquote, Kompatibilität, Recovery und Gesamtkosten ab. ### Wann sollte ein Unternehmen GPUs nicht virtualisieren? Nicht bei bereits gesättigten Jobs, dominanter Multi-GPU-Kommunikation, sehr strengen Tail-Limits oder nicht belegbarer Isolation und Kompatibilität. ## Das könnte dich auch interessieren.. [**Lokale Modelle vs APIs: Break-even berechnen** Entscheide zuerst, ob eigene GPU-Kapazität APIs wirtschaftlich schlägt.](/de/blog/local-models-vs-apis-break-even-eu-2026/) [**Netflix' vLLM- und Triton-Inferenzstack** So verbessern Batching, Routing und Serving-Architektur die GPU-Ökonomie.](/de/blog/netflix-vllm-triton-inference-stack/) Modelle und Infrastruktur ## In diesem Cluster weiterlesen Modellauswahl, Inferenzkosten, lokaler Betrieb, Kompression und Serving-Architektur. [Mit dem Grundlagenartikel starten**LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen**](/de/blog/self-hosting-llms-eu-cost/) - [Pika Audio API Preise: Sind Soundeffekte wirklich 20x günstiger?](/de/blog/pika-audio-models-api-pricing-2026/) - [AirLLM mit 4 GB VRAM: So funktioniert Layer-wise Inference](/de/blog/airllm-layer-wise-inference-low-vram/) - [Qwen3.8-27B: Computer-Use-Agenten selbst hosten, ohne Screenshots zu exportieren](/de/blog/qwen3-8-27b-self-hosted-computer-use-agents/) - [Der vLLM- und Triton-Stack von Netflix: 7 Produktionslektionen](/de/blog/netflix-vllm-triton-inference-stack/) - [Transformers.js im Browser: Wann lokale KI in dein Produkt gehört](/de/blog/transformers-js-browser-ai-guide/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 11 Min Lesezeit · 21. Aug. 2026 Zuletzt geprüft 21. August 2026 [**Weiter**](/de/blog/local-models-vs-apis-break-even-eu-2026/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/thunder-compute-gpu-virtualization-series-a/#webpage", "@type": "WebPage", "dateModified": "2026-08-21", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-21", "url": "https://wavect.io/de/blog/thunder-compute-gpu-virtualization-series-a/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Thunder Compute hat eine Series A über 13 Millionen US-Dollar aufgenommen, um seine netzwerkbasierte GPU-Virtualisierung in Enterprise- und Cloud-Provider-Flotten zu bringen. Die Software übersetzt CUDA-Aufrufe in Netzwerknachrichten, löst ungenutzte GPUs von Workloads und weist sie neu zu, ohne die Anwendung zu ändern. Wirtschaftlich ist das dort plausibel, wo teure GPUs reserviert, aber nur stoßweise genutzt, zwischen Teams fragmentiert oder durch starre Servergrenzen blockiert sind. Der Ansatz ersetzt MIG, Time-Sliced vGPU, Passthrough, Batching oder Autoscaling nicht pauschal. Käufer sollten erfolgreiche Arbeit pro Flottenstunde, p95-Latenz, Queue-Zeit, Fehlerbehebung, Kompatibilität und Isolation gegen den bestehenden Stack messen. Kaufe erst nach einem begrenzten Pilot, wenn die zurückgewonnene Kapazität Runtime-Overhead, Integrationskosten und Betriebsrisiko übersteigt.", "articleBody": " Blog-Übersicht/AI und Agents/Modelle und Infrastruktur Thunder Computes 13-Mio.-Dollar-Wette auf GPU-Virtualisierung: Einkaufsleitfaden TL;DR Thunder Compute hat eine Series A über 13 Millionen US-Dollar aufgenommen, um seine netzwerkbasierte GPU-Virtualisierung in Enterprise- und Cloud-Provider-Flotten zu bringen. Die Software übersetzt CUDA-Aufrufe in Netzwerknachrichten, löst ungenutzte GPUs von Workloads und weist sie neu zu, ohne die Anwendung zu ändern. Wirtschaftlich ist das dort plausibel, wo teure GPUs reserviert, aber nur stoßweise genutzt, zwischen Teams fragmentiert oder durch starre Servergrenzen blockiert sind. Der Ansatz ersetzt MIG, Time-Sliced vGPU, Passthrough, Batching oder Autoscaling nicht pauschal. Käufer sollten erfolgreiche Arbeit pro Flottenstunde, p95-Latenz, Queue-Zeit, Fehlerbehebung, Kompatibilität und Isolation gegen den bestehenden Stack messen. Kaufe erst nach einem begrenzten Pilot, wenn die zurückgewonnene Kapazität Runtime-Overhead, Integrationskosten und Betriebsrisiko übersteigt. Thunder Compute hat am 19. August 2026 eine Series A über 13 Millionen US-Dollar aufgenommen. Damit soll die GPU-Virtualisierung aus der eigenen Cloud mit mehr als 10.000 Nutzern in Flotten von Unternehmen und Cloud-Providern kommen. Matrix Partners führte die Runde an, Y Combinator und CEAS Investments beteiligten sich. Diese Fakten stammen aus Thunder Computes Finanzierungsankündigung. Für Infrastruktur-Einkäufer zählt jedoch eine schwierigere Frage: Schafft netzwerkbasiertes GPU-Pooling mehr nutzbare Kapazität, als es durch Latenz, Integration und Betriebsrisiko kostet? Kurzantwort: GPU-Virtualisierung kann blockierte Kapazität lösen, wenn Workloads stoßweise laufen, GPUs fest an Server oder Teams gebunden sind und Scheduler Leerlauf nicht zurückholen. Sie erzeugt keine zusätzliche Rechenleistung. Sie verändert, wer wann auf eine physische GPU zugreifen kann und wie fein die Flotte zugeteilt wird. Die richtige Methode hängt von Workload, Isolation, Speicher, Netzwerk und Latenz ab. Dieser Artikel beantwortet die Einkaufsfrage zu GPU-Virtualisierung und GPU-Pooling. Unser Break-even-Rechner für lokale Modelle und APIs beantwortet davor, ob ein Unternehmen Inferenzkapazität überhaupt selbst besitzen sollte. Wenn du bereits eine GPU-Flotte besitzt oder reservierst, hilft dieser Leitfaden bei der Frage, ob Virtualisierung sie produktiver macht. Warum Thunder Computes Series A relevant ist Die Finanzierung ist ein Marktsignal, kein Beleg dafür, dass jede GPU virtualisiert werden sollte. Sie finanziert den Schritt von einer kontrollierten Vendor-Cloud in bestehende Enterprise-Umgebungen. Damit steigt die Beweislast. Ein Cloud-Produkt kontrolliert Hardware, Netzwerk und Workload-Grenzen. Ein Enterprise-Produkt muss mit Kubernetes, Slurm, VMs, Bare Metal, Security-Zonen, Change Windows und unbekannten Workloads funktionieren. Das Auslastungsproblem ist real, Prozentwerte brauchen aber Kontext. CAST AI maß in seinem Datensatz eine durchschnittliche GPU-Auslastung von 5 Prozent. Die Daten stammen aus zehntausenden Kubernetes-Clustern auf AWS, Azure und Google Cloud vor der Optimierung. Gemessen wurde der Anteil bereitgestellter GPU-Rechenzyklen, der über 24 Stunden nützlichen Output erzeugt. Derselbe Kubernetes Optimization Report 2026 zeigt einen Cluster mit 136 H200 bei 49 Prozent. Die Lücke spricht für bessere Betriebsverfahren, beweist aber weder 5 Prozent für jede Enterprise-Flotte noch Virtualisierung als alleinige Lösung. Was ist GPU-Virtualisierung? GPU-Virtualisierung trennt die Sicht eines Workloads auf einen Accelerator von der physischen GPU, die ihn ausführt. Die Abstraktion kann eine ganze GPU einer VM zuweisen, eine GPU in isolierte Teile teilen, Rechenzeit zwischen Mandanten aufteilen oder entfernte GPUs über ein Netzwerk bereitstellen. Ziel sind bessere Zuteilung, Portabilität oder Isolation. Jede Methode verschiebt andere Engpässe und schafft ein anderes Fehlermodell. AnsatzWas geteilt wirdGuter FitWichtigster Nachteil PCIe-PassthroughEine ganze GPU für eine VMMaximale Kompatibilität und planbare LeistungLeerlauf bleibt blockiert NVIDIA MIGFeste Compute- und Speicherteile auf einer unterstützten GPUParallele Workloads mit Hardware-IsolationStatische Größen fragmentieren Kapazität Time-Sliced vGPUGPU-Rechenzeit zwischen VMsInteraktive oder gemischte WorkloadsDurchsatz und Latenz schwanken unter Last Netzwerk-GPU-PoolingGPUs über Servergrenzen und Workloads über das RechenzentrumsnetzStoßweise Flotten mit blockierter KapazitätNetzwerk- und Kompatibilitäts-Overhead Diese Optionen ergänzen sich. NVIDIA dokumentiert Time-Sliced vGPU als zeitliche Partitionierung. MIG erstellt räumlich isolierte Instanzen mit eigenen Compute- und Speicherressourcen. MIG-backed vGPU kann beides kombinieren. Die NVIDIA-Dokumentation zu vGPU-Funktionen macht die Unterschiede bei Isolation, Scheduling und unterstützten Plattformen sichtbar. Wie Thunder Computes Netzwerk-GPU-Pooling funktioniert Thunder Compute", "articleSection": "Entwicklung", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "Thunder Computes Finanzierungsankündigung", "url": "https://www.thundercompute.com/blog/thunder-compute-series-a" }, { "@type": "WebPage", "name": "Kubernetes Optimization Report 2026", "url": "https://cast.ai/reports/kubernetes-optimization-report/" }, { "@type": "WebPage", "name": "NVIDIA-Dokumentation zu vGPU-Funktionen", "url": "https://docs.nvidia.com/knowledge-base/latest/vgpu-features.html" }, { "@type": "WebPage", "name": "technischen Überblick zu GPU-over-TCP", "url": "https://www.thundercompute.com/blog/how-thunder-compute-works-gpu-over-tcp" }, { "@type": "WebPage", "name": "Goodput-Modell von Google Cloud", "url": "https://docs.cloud.google.com/architecture/framework/perspectives/ai-ml/performance-optimization" } ], "dateModified": "2026-08-21", "datePublished": "2026-08-21", "description": "Thunder Compute hat eine Series A über 13 Millionen US-Dollar aufgenommen, um seine netzwerkbasierte GPU-Virtualisierung in Enterprise- und Cloud-Provider-Flotten zu bringen. Die Software übersetzt CUDA-Aufrufe in Netzwerknachrichten, löst ungenutzte GPUs von Workloads und weist sie neu zu, ohne die Anwendung zu ändern. Wirtschaftlich ist das dort plausibel, wo teure GPUs reserviert, aber nur stoßweise genutzt, zwischen Teams fragmentiert oder durch starre Servergrenzen blockiert sind. Der Ansatz ersetzt MIG, Time-Sliced vGPU, Passthrough, Batching oder Autoscaling nicht pauschal. Käufer sollten erfolgreiche Arbeit pro Flottenstunde, p95-Latenz, Queue-Zeit, Fehlerbehebung, Kompatibilität und Isolation gegen den bestehenden Stack messen. Kaufe erst nach einem begrenzten Pilot, wenn die zurückgewonnene Kapazität Runtime-Overhead, Integrationskosten und Betriebsrisiko übersteigt.", "headline": "Thunder Computes 13-Mio.-Dollar-Wette auf GPU-Virtualisierung: Einkaufsleitfaden", "image": "https://wavect.io/img/blog/headers/header_thunder-compute-gpu-virtualization-series-a.svg", "inLanguage": "de", "keywords": "GPU-Virtualisierung, KI-Infrastruktur", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/thunder-compute-gpu-virtualization-series-a/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/thunder-compute-gpu-virtualization-series-a/", "wordCount": 1659 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/models-infrastructure/", "name": "Modelle und Infrastruktur", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/thunder-compute-gpu-virtualization-series-a/", "name": "GPU-Virtualisierung: Thunder Compute Leitfaden | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "GPU-Virtualisierung ist die breite Abstraktion zwischen Workload und physischem Accelerator. GPU-Pooling stellt GPUs über mehrere Server als gemeinsame Ressource bereit." }, "name": "Was ist der Unterschied zwischen GPU-Virtualisierung und GPU-Pooling?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Sie kann produktive Flottenkapazität erhöhen, indem sie Leerlauf reduziert. Einzelne Workloads können wegen Scheduling und Netzwerk gleich schnell oder langsamer laufen." }, "name": "Erhöht GPU-Virtualisierung die rohe GPU-Leistung?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nicht zwingend. MIG erstellt isolierte Hardwareteile auf einer GPU. Thunder Compute poolt GPUs über ein Netzwerk. Eine Architektur kann beides kombinieren." }, "name": "Ersetzt Thunder Compute NVIDIA MIG?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nutze erfolgreiche Arbeit pro Flottenstunde und sichere sie mit p95-Latenz, Queue-Zeit, Fehlerquote, Kompatibilität, Recovery und Gesamtkosten ab." }, "name": "Welche Hauptkennzahl sollte ein Pilot nutzen?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nicht bei bereits gesättigten Jobs, dominanter Multi-GPU-Kommunikation, sehr strengen Tail-Limits oder nicht belegbarer Isolation und Kompatibilität." }, "name": "Wann sollte ein Unternehmen GPUs nicht virtualisieren?" } ] } ```