Hören Sie auf, das Unternehmen auf CUDA zu setzen: Ein CTO-Playbook 2026 für KI‑Portabilität

Wenn Ihre KI‑Roadmap NVIDIA auf ewig voraussetzt, sind Sie nur ein Lieferantengespräch von einem Vorstands‑Vorfall entfernt. Performance pro Dollar verbessert sich rasant, Verfügbarkeit ist sprunghaft, und sogar Modellanbieter prüfen eigene Chips. Anthropic soll mit Samsung über einen eigenen Beschleuniger sprechen; zugleich zeigt eine frische Welle von Posts, dass sich Performance‑pro‑Dollar fast monatlich verbessert. Es geht nicht darum, wer „gewinnt“. Es geht darum, dass Sie es sich nicht leisten können, sich darum zu kümmern. Ihr Stack muss dort laufen, wo im nächsten Quartal der günstige, verfügbare Chip liegt.

Der Hardware‑Markt hat sich wieder vom Commodity‑Markt wegbewegt

Vor zwei Jahren bedeutete „GPU“ CUDA, und CUDA bedeutete NVIDIA. 2026 haben Sie Optionen — und genau deshalb brauchen Sie einen Portabilitätsplan.

• NVIDIA H100: Goldstandard für Durchsatz und Reife des Ökosystems. 80–94 GB HBM, ausgereifte Kernel (FlashAttention, Triton), breite Cloud‑Verfügbarkeit. 8x‑Instanzen on demand liegen je nach Region und Bindung meist im hohen zweistelligen bis niedrigen dreistelligen USD/Stunde.
• AMD MI300X: 192 GB HBM pro GPU ist die Schlagzeile. Dieser Speichervorsprung erlaubt größere Batch‑Größen, längere Kontexte und weniger Sharding‑Spielchen. ROCm ist so weit gereift, dass Mainstream‑Inferenzstacks produktiv sind und keine Forschungsprojekte mehr.
• Intel Gaudi (Gaudi2/3): Erstaunlich wettbewerbsfähiges Preis/Leistungs‑Verhältnis in manchen Clouds, starke BF16‑Leistung, eigene Interconnect‑Story und ein Hersteller, der Rabatte geben will.
• Google TPU (v5e/v5p): Nach wie vor gut für Training in großem Maßstab und für Inferenz, wenn Sie in GCP bleiben und XLA sauber ansteuern können.
• Edge und On‑Device: Apple Silicon (Metal), Vulkan‑Klasse‑GPUs und CPUs mit AVX‑512 oder AMX. Kein Trainings‑Arbeitspferd — aber entscheidend für private, latenzarme Inferenz, bei der Daten das Gerät nicht verlassen dürfen.

Speicher, nicht FLOPs, ist meist der begrenzende Faktor in der Inferenz. Die 192 GB des MI300X halten Multi‑Tenant‑Serving ehrlich, weil Frankenstein‑Sharding vermieden wird. H100 punktet oft beim reinen Tokens/s‑Durchsatz dank Kernel‑Reife. TPUs sehen großartig aus — bis ein nicht unterstützter Op auftaucht. Ihre Kosten schwanken mit Batch‑Größe, Kontextlänge und der Existenz (oder dem Fehlen) eines guten, für Ihr Modell passenden Fused‑Attention‑Kernels. Darum schlägt Portabilität den Vendor‑Glaubenskrieg.

Was „portabel“ für CTOs wirklich bedeutet

Die meisten Teams halten Portabilität für „wir können ONNX exportieren“. Das ist Schritt eins, nicht das Ziel. Echte Portabilität umfasst sechs Ebenen. Prüfen Sie jede davon.

• Gewichtsformat: safetensors für Sicherheit und Geschwindigkeit; ONNX oder OpenXLA‑Kompilierungspfade für breite Ziele; GGUF für CPU/Edge via llama.cpp.
• Graph‑IR: ONNX oder StableHLO/XLA ermöglichen Retargeting, ohne ewig in PyTorch Eager zu leben. TVM/IREE können für Nicht‑NVIDIA‑Pfade nach Vulkan/Metal/ROCm/CUDA kompilieren.
• Runtime: vLLM, Text Generation Inference (TGI), llama.cpp oder MLC LLM. Wählen Sie mindestens zwei mit unterschiedlichen Backend‑Abhängigkeiten.
• Kernels: FlashAttention, Triton, gefusete MLPs. Häufig zuerst für CUDA. Sie brauchen ROCm‑ oder HIP‑Äquivalente oder einen IR‑Compiler, der Ops ausreichend gut fused, ohne maßgeschneidertes CUDA.
• Quantisierung und Speicherlayout: FP16/BF16 als gemeinsamer Nenner; INT8/INT4 (AWQ, GPTQ, SmoothQuant) steigert den Durchsatz, verengt aber die Portabilität, sofern Sie keine Methoden wählen, die backend‑übergreifend unterstützt werden.
• Serving‑Schicht und Scheduler: Continuous Batching und Paged Attention (z. B. in vLLM) senken die Kosten, können aber backend‑sensitiv sein. Ihre Serving‑Schicht muss über die Hardware hinweg dieselbe API anbieten.

Ein Entscheidungsrahmen für 2026: Wählen Sie Ihre Portabilitäts‑Spur

Spur 1: Dual‑Sourcing der Inferenz (CUDA + ROCm) für 80 % der Use Cases

Wenn Sie Modelle der 7B–70B‑Klasse für Chat, Retrieval‑augmented Generation und Code betreiben, ist dies der pragmatische Standard. Behalten Sie NVIDIA wegen der Kernel‑Reife als ersten Pfad und halten Sie AMD als voll validierte, produktionsfähige Zweitquelle.

• Runtime: vLLM als primärer Serving‑Stack. Unterstützt CUDA und zunehmend ROCm, liefert starkes Continuous Batching und integriert sauber mit Tokenizern und OpenAI‑artigen APIs.
• Fallback: TGI oder llama.cpp für spezielle Modelle oder CPU/Metal‑Fallbacks.
• Quantisierung: Halten Sie zwei freigegebene Varianten je Modell: BF16/FP16 und INT8. Behandeln Sie INT4 als opportunistisch, bis Ihr Nicht‑CUDA‑Backend seine Stabilität bewiesen hat.
• Infra: Pflegen Sie zwei Golden‑Container‑Images: eines mit CUDA und Vendor‑Libs, eines mit ROCm. Fixieren Sie Driver‑Toolkit‑Versionen und veröffentlichen Sie SBOMs.

Wann wählen: Sie wollen nächste Quartal kaufen, was am Spotmarkt verfügbar ist — nicht, was der letztjährige Plan annahm. Sie müssen 20–40 % Inferenzkosten sparen, ohne Modelle neu zu trainieren oder Business‑Logik umzuschreiben.

Spur 2: IR‑first‑Kompilierung (ONNX/OpenXLA + IREE/TVM) für Edge und exotische Beschleuniger

Wenn Sie mobile oder eingebettete Inferenz ausliefern oder Optionalität über TPU und künftige Spezialchips wünschen, investieren Sie in IR‑first. Sie tauschen etwas absoluten Durchsatz gegen die Freiheit, schnell umzuparametrisieren.

• Compiler‑Stack: Export zu ONNX oder StableHLO, dann mit IREE oder TVM nach Vulkan, Metal, CUDA oder ROCm kompilieren.
• Runtime: MLC LLM als Rundum‑Sorglos‑Pfad für Phones und Desktops; nutzt TVM für mehrere Backends.
• APIs: Frieren Sie Ihre öffentliche API an der Serving‑Schicht ein. Halten Sie Compiler‑Entscheidungen vor Produktteams verborgen.

Wann wählen: Sie müssen on‑device laufen wegen Datenschutz oder Latenz, oder Sie erwarten Nicht‑GPU‑Beschleuniger in Ihrer Beschaffung. Sie wollen einen einzigen Codepfad für Vulkan/Metal/ROCm/CUDA.

Spur 3: CPU‑first‑Sicherheitsnetz für SLOs und DR

Es wird Tage geben, an denen Sie keine GPU bekommen. Ein robuster CPU‑Pfad hält Ihre P99 und SLAs stabil während GPU‑Engpässen, Upgrades oder Sicherheitsvorfällen.

• Runtime: llama.cpp oder MLC LLM für CPU, mit GGUF‑Gewichten. Zielen Sie auf AVX‑512 oder AMX, wo verfügbar.
• Scope: Kleinere Modelle (3B–7B) mit aufgabenspezifischen Fine‑Tunes für „gut genug“, wenn GPUs fehlen.
• Use: Canary‑ und Notfall‑Kapazität sowie private On‑Device‑Inferenz für regulierte Segmente.

Die einzigen zwei Metriken, die zählen: Kosten pro 1K Tokens und First‑Token‑Latenz

Ignorieren Sie generische „TFLOPs“‑Vergleiche. Ihre Kundschaft spürt zwei Dinge: Wie lange bis zum ersten Token und was jedes Tausend Tokens bei Ihren SLOs kostet.

• Kosten pro 1K Tokens: Nähern Sie als (Instanz‑$/Stunde) dividiert durch (Tokens/Sekunde × 3600) für einen fixierten Kontext/Batch‑Grad an. Continuous Batching drückt den Wert zu Ihren Gunsten; winzige, interaktive Prompts nicht.
• First‑Token‑Latenz (FTL): Getrieben durch Scheduler, Modellgröße, gefusete Kernel und Speicherbewegungen. Ein CUDA‑Stack mit reifem FlashAttention kann beim FTL eine größere‑Speicher‑ROCm‑Konfiguration schlagen, selbst bei vergleichbarem Gesamtdurchsatz.

Hier der Clou: Mit passendem Batching und guten Kernels kann die interne Kosten‑pro‑1K‑Tokens für ein 7B‑Modell auf unter einen Cent fallen — sowohl auf H100 als auch auf MI300X. Cloud‑APIs verlangen pro 1K Tokens weiterhin einen Aufpreis für Einfachheit und Verfügbarkeit. Ihr Portabilitätsplan ist der Hebel, mit dem Sie die Differenz einfangen — wenn ein anderer Anbieter dieses Quartal günstiger ist.

Prüfen Sie Ihren Stack an einem Nachmittag auf CUDA‑Annahmen

Bevor Sie über Multi‑Vendor reden, beweisen Sie, dass Sie nicht CUDA‑hartverdrahtet sind. Beauftragen Sie eine/n Senior, diese Checkliste abzuarbeiten und bis EOD zu berichten.

• Code‑Grep: Suchen Sie nach expliziten CUDA‑Only‑Imports (torch.cuda, cupy, Triton‑Kernels), hartkodierten Device‑Strings und nvidia/cuda‑Basis‑Images in Dockerfiles.
• Wheel‑Lock: Listen Sie gepinnte Wheels. Wenn torch und xformers auf CUDA‑Builds gepinnt sind, notieren Sie ROCm‑Äquivalente und ob Ihr Python‑Resolver sauber tauschen kann.
• Custom Ops: Inventarisieren Sie Triton‑ oder CUDA‑Erweiterungen. Identifizieren Sie pro Stück ROCm/HIP‑Parität oder eine IR‑Compiler‑Alternative.
• Kernels: Bestätigen Sie Ihre Attention‑Kernel‑Story auf beiden Seiten. FlashAttention‑Parität existiert auf ROCm inzwischen, aber nicht jede Modellvariante ist abgedeckt.
• Serving: Läuft Ihr Serving‑Binary heute auf ROCm? Falls nein: Was fehlt — Kernel, Treiber oder Packaging?
• CI: Haben Sie wenigstens einen ROCm‑Job? Wenn die Antwort „nein“ ist, ist Ihre Portabilitätsfrage beantwortet.

Bauen Sie ein Portabilitäts‑Harness — einmal

Portabilität ist keine Folie; sie ist eine Testsuite. Behandeln Sie sie wie Release Engineering.

• Standard‑Model‑Bundle: Zippen Sie Gewichte (safetensors), Tokenizer, Prompt‑Vorlagen und ein Manifest mit Quantisierung sowie erwarteten Ausgaben für Golden Prompts.
• Golden Prompts: 100–200 Prompts, die Ihre realen Workloads abbilden: kurze Chats, 8–32K‑Kontexte, RAG mit langen Kontexten, Code‑Completion, Streaming.
• Metriken: Pro Backend Tokens/s im Gleichlauf, First‑Token‑Latenz, VRAM‑ und vCPU‑Auslastung erfassen. Leiten Sie $/1K Tokens aus Ihren realen Instanzpreisen ab.
• Container: Veröffentlichen Sie pro Backend Images als Artefakte: CUDA, ROCm, CPU/Metal. Pinnen Sie Driver‑Toolkit‑Kombinationen. Inklusive SBOMs und Scans auf bekannte CVEs.
• Auf Zahlen gaten: Ein PR fällt durch, wenn ein Backend bei Kosten oder FTL >10 % regressiert, ohne Ausnahmegenehmigung. Diese Gates in Ihre CD einbinden.

Serving‑Stacks, die Hardware‑Wechsel überleben

Wählen Sie zwei, nicht einen.

• vLLM: Hochdurchsatz‑Batching, Multi‑Backend‑Kurs (zuerst CUDA, ROCm zunehmend tragfähig) und eine OpenAI‑artige API. Exzellenter Standard für Server‑Inferenz.
• TGI: Solider CUDA‑Pfad, brauchbare ROCm‑Story für viele Modelle, starke Hugging‑Face‑Integration. Gute Zweitquelle.
• llama.cpp: Das Schweizer Taschenmesser. CPU‑, Metal‑, Vulkan‑Backends mit GGUF. Geringerer Durchsatz, aber unverzichtbar als Fallback und für Edge.
• MLC LLM: Bester Weg, auf Mobile und diverse Desktop‑GPUs via TVM zu shippen. Nützlich, wenn die Produktroadmap On‑Device erfordert.

Was auch immer Sie wählen, stabilisieren Sie Ihre öffentliche API und Auth davor. Ihre App sollte nicht wissen oder sich kümmern, welches Backend diese Woche live ist.

Quantisierung ohne böse Überraschungen

• Standardisieren Sie auf BF16/FP16 als Baseline und INT8 für Durchsatz. Behandeln Sie INT4 als Optimierungsstufe mit expliziten Abnahmetests für Genauigkeit und Halluzinationsraten.
• Wählen Sie Methoden, die reisen: SmoothQuant und AWQ sind breit unterstützt; GPTQ‑Varianten können backend‑fragil sein.
• Testen Sie lange Kontexte: Quantisierung interagiert bei Long‑Context‑Attention in manchen Kernels ungünstig. Nehmen Sie 32K+‑Kontexttests ins Harness auf, wenn Ihr Produkt das unterstützt.

Training und Fine‑Tuning: Seien Sie ehrlich zum Umfang

Volle Pretraining‑Portabilität ist ein Forschungsetat. Für Startups und Scale‑ups: Fokussieren Sie auf Inferenz und parameter‑effizientes Tuning.

• LoRA/QLoRA‑Fine‑Tunes auf CUDA und ROCm sind 2026 tragfähig. Führen Sie sie dort aus, wo Kapazität verfügbar ist, aber halten Sie Ihr Serving zuerst portabel.
• Gaudi und TPU können hervorragende Trainings‑Optionen sein. Lassen Sie deren Trainingssieg Sie nicht zu exklusivem Serving darauf zwingen, wenn Ihre Unit Economics später H100 oder MI300X verlangen.

Security und Betrieb bekommen keinen Freifahrtschein

Multi‑Backend bedeutet Exposure durch mehrere Treiber und Runtimes. Ziehen Sie die Hygieneschrauben an.

• Treiber: Nutzen Sie herstellergepflegte Treiber‑Container oder Kernel‑Module mit CVE‑Tracking. Installieren Sie keine Treiber ad hoc auf Hosts.
• Repro: Hermetische Builds mit gepinnten Compilern (Triton, TVM) und verifizierten Wheels. Erzeugen Sie SBOMs und Attestierungen.
• Isolation: Für Multi‑Tenant‑Nodes MIG auf NVIDIA und überall cgroup‑Isolation. Verhindern Sie, dass Kernel‑Panics eines Runtimes andere mitreißen.
• Observability: Exportieren Sie Hardware‑Counter (HBM‑Bandbreite, SM‑Auslastung), nicht nur Tokens/s. Alarmieren Sie bei First‑Token‑Latenz‑Regressionen, nicht nur beim 95.‑Perzentil‑Durchsatz.

Wer betreibt das? Bauen Sie ein „Zwei‑Pizzen“‑Compiler‑Team

Wenn Sie alle KI‑Arbeit in Feature‑Teams lassen, stirbt Portabilität an tausend TODOs. Stellen Sie 2–3 Engineers ab, deren Job es ist, Modelle überall lauffähig zu machen.

• Skills: PyTorch 2.x Graph Capture, Triton, FlashAttention, ROCm/HIP‑Grundlagen, ONNX/XLA und ein IR‑Compiler (TVM oder IREE).
• Mandat: Verantworten Sie das Portabilitäts‑Harness, Golden‑Model‑Bundles, Container‑Images und Performance‑Gates. Besitzen Sie Vendor‑Benchmarks und Inputs für die Beschaffung.
• Cadence: Vierteljährlicher „Futures Day“, um neue SKUs und Clouds zu testen, mit schriftlicher Buy/No‑Buy‑Empfehlung basierend auf $/1K Tokens und FTL.

Nearshore‑Hebel: Nutzen Sie Geografie zu Ihrem Vorteil

Wenn Ihr Hauptsitz in den USA ist, verschafft Ihnen ein Nearshore‑Pod in Brazil 6–8 Stunden Overlap und Zugang zu alternativer Kapazität. 2026 tauchen MI300X und Gaudi oft zuerst in Nicht‑US‑Regionen und Regional‑Clouds auf. Nutzen Sie diese Arbitrage.

• Topologie: Halten Sie interaktiven Traffic in‑Region (US‑East/West), um P95‑Latenz zu schützen. Leiten Sie Batch‑Inferenz und Fine‑Tunes in die günstigste Region — Südamerika, Europa, wo immer der Spotmarkt lächelt.
• Ops: Das Nearshore‑Team betreibt das Portabilitäts‑Harness und zertifiziert neue Regionen/Hardware, während Ihr Kernteam Features shippt.

Die Provokation

Portabilität ist kein akademisches Ideal. Sie ist der Mechanismus, der Ihnen erlaubt, nächstes Quartal zu kaufen, was günstig und verfügbar ist — ohne Ihr Produkt umzuschreiben oder SLAs neu zu verhandeln. NVIDIA ist womöglich weiterhin meist Ihre beste Option. Gut — ein Portabilitätsplan erleichtert es, das mit Zahlen gegenüber der Beschaffung zu belegen. Und wenn nicht, sind Sie nicht das Unternehmen, das 30 % mehr zahlt, weil der Code ROCm nicht buchstabieren kann.

Ein 30‑Tage‑Aktionsplan

• Woche 1: Führen Sie das CUDA‑Audit durch. Erstellen Sie eine einseitige Gap‑Liste. Stellen Sie einen zweiten Backend‑Job (ROCm oder CPU) in der CI auf.
• Woche 2: Bauen Sie das Portabilitäts‑Harness: Golden‑Model‑Bundles, Prompts und Performance‑Gates. Containerisieren Sie CUDA‑ und ROCm‑Images mit SBOMs.
• Woche 3: Zertifizieren Sie zwei Runtimes (z. B. vLLM auf CUDA und ROCm, llama.cpp auf CPU/Metal). Erzeugen Sie den ersten $/1K‑Tokens‑ und FTL‑Report über Hardware, die Sie diese Woche mieten können.
• Woche 4: Präsentieren Sie ein Beschaffungs‑Briefing mit drei Optionen: „Bleiben“, „25 % auf AMD verlagern“ und „CPU‑Fallback hinzufügen“. Inklusive Kosten, Risiko und Zeitplan. Entscheiden Sie und setzen Sie um.

Wesentliche Erkenntnisse

• Performance‑pro‑Dollar verschiebt sich quartalsweise; koppeln Sie Ihre Kostenkurve nicht an eine Roadmap eines einzigen Anbieters.
• Echte Portabilität umfasst Gewichte, IR, Runtime, Kernels, Quantisierung und Serving — nicht nur „wir können ONNX exportieren“.
• Wählen Sie zwei Serving‑Stacks und zwei Backends. vLLM + CUDA/ROCm, mit llama.cpp als CPU/Metal‑Sicherheitsnetz, deckt die meisten Bedürfnisse ab.
• Messen Sie, was zählt: Kosten pro 1K Tokens und First‑Token‑Latenz unter Ihren realen Workloads.
• Quantisieren Sie mit Augenmaß: Halten Sie FP16/BF16 und INT8 als freigegebene Stufen; behandeln Sie INT4 als optional, bis Nicht‑CUDA‑Parität belegt ist.
• Stellen Sie ein kleines „Compiler‑Team“ auf, das Harness, CI‑Gates und Vendor‑Benchmarks verantwortet.
• Nutzen Sie Nearshore‑Kapazität, um neue Hardware zu qualifizieren und regionale Preisarbitrage auszuschöpfen, ohne US‑User‑Latenz zu opfern.

Author: Diogo Hudson Dias