Proxmox VE für ARM64: NVIDIA Grace Hopper und Vera machen den Hypervisor KI-rechenzentrumsfähig

Was Proxmox am 5. August 2026 angekündigt hat

Die Proxmox Server Solutions GmbH aus Wien hat am 5. August 2026 die erste offizielle ARM64-Edition von Proxmox VE veröffentlicht. Was auf den ersten Blick wie eine reine Plattformerweiterung klingt – ein Hypervisor, der jetzt auch auf einer zweiten CPU-Architektur läuft –, ist im Kontext von KI-Rechenzentren mehr als eine technische Randnotiz. Bestätigt ist die Ankündigung durch die Proxmox-Pressemitteilung selbst sowie unabhängig durch The Register, StorageReview und CNX Software, die den Launch am 6. beziehungsweise 7. August aufgriffen.

Technische Basis der neuen Edition ist Debian 13.5 „Trixie" mit Linux-Kernel 7.0 als Standardkernel – identisch zur x86-64-Basis von Proxmox VE 9.2, das bereits am 21. Mai 2026 erschienen war. Das ist der entscheidende Unterschied zu vielen früheren ARM-Portierungen im Open-Source-Umfeld: Proxmox baut nicht parallel einen abgespeckten „ARM-Zweig", sondern zieht dieselbe Codebasis, dieselben Paketquellen und denselben Release-Rhythmus über beide Architekturen.

Für Admins, die Proxmox bislang nur aus dem Homelab oder von kleineren x86-Clustern kennen, mag das nach einer Nische klingen. Für Rechenzentrumsbetreiber und Systemhäuser, die zunehmend GPU-Serversysteme auf ARM-Basis verbauen, ist ein reifer, produktionstauglicher Open-Source-Hypervisor mit ARM64-Support dagegen ein Baustein, der bislang schlicht gefehlt hat. Bisher bedeutete „ARM-Server virtualisieren" meist: proprietäre Hypervisor-Stacks der Serverhersteller, eingeschränkte KVM-Bordmittel ohne Managementebene, oder Bare-Metal-Betrieb ohne Virtualisierung überhaupt.

Der Unterschied zwischen „läuft auf ARM" und „ist rechenzentrumsfähig" liegt genau in dieser Managementebene. Ein Bare-Metal-Betrieb mag für einen einzelnen GPU-Server ausreichen. Sobald aber mehrere Knoten zu einem Cluster zusammenwachsen, Workloads live migriert, Snapshots gefahren, Ressourcen fein partitioniert oder Backups zentral orchestriert werden sollen, braucht es genau die Werkzeugebene, die Proxmox seit Jahren auf x86-64 liefert: Cluster-Dateisystem, Weboberfläche, Rollen- und Rechteverwaltung, REST-API für Automatisierung und eine einheitliche Backup-Lösung über Proxmox Backup Server. Dass diese komplette Werkzeugkette jetzt eins zu eins auf ARM64 verfügbar ist, ist der eigentliche Unterschied zu einem reinen Kernel- oder Hypervisor-Port.

Volle Feature-Parität statt Beta-Krücke

Der naheliegende Verdacht bei jedem „Port auf eine neue Architektur" lautet: eingeschränkter Funktionsumfang, experimenteller Status, Komponenten, die erst in einem der nächsten Releases nachgereicht werden. Bei Proxmox VE für ARM64 ist das nach aktuellem Stand nicht der Fall. Die zentralen Subsysteme laufen in identischen Versionen wie unter x86-64 9.2:

• KVM/QEMU 11.0 als Virtualisierungs-Unterbau für vollwertige virtuelle Maschinen, inklusive Live-Migration und den üblichen QEMU-Geräteemulationen.
• LXC 7.0 für Linux-Container – der ressourcenschonende zweite Virtualisierungspfad, den Proxmox neben klassischen VMs seit jeher anbietet.
• ZFS 2.4 als Storage- und Dateisystem-Unterbau mit Snapshots, Replikation und Checksummen – ein Kernstück jeder Proxmox-Installation, das jetzt nativ auf ARM64 mitläuft.
• Der vollständige Ceph-Storage-Stack, inklusive Ceph Squid 19.2 und Ceph Tentacle 20.2, für verteilten, hochverfügbaren Blockspeicher über mehrere Knoten hinweg.

Diese Aufzählung ist deshalb mehr als Marketingprosa, weil jede einzelne Komponente in der Vergangenheit ein typischer Show-Stopper bei ARM-Portierungen war. Ceph etwa gilt traditionell als speicher- und I/O-hungrig genug, dass Portierungen auf neue Architekturen oft mit Monaten Verzug hinter dem x86-Release herlaufen. Dass der komplette Stack von Tag eins an mitläuft, deutet darauf hin, dass Proxmox die ARM64-Unterstützung nicht nachträglich aufgesetzt, sondern von vornherein im selben Build- und Testsystem mitgeführt hat.

Komponente	Version x86-64 (9.2)	Version ARM64	Funktionsumfang
Basissystem	Debian 13.5 „Trixie"	Debian 13.5 „Trixie"	identisch
Kernel	Linux 7.0	Linux 7.0	identisch
KVM/QEMU	11.0	11.0	identisch
LXC	7.0	7.0	identisch
ZFS	2.4	2.4	identisch
Ceph-Stack	Squid 19.2 / Tentacle 20.2	Squid 19.2 / Tentacle 20.2	identisch

Für Admins, die bereits x86-basierte Proxmox-Cluster betreiben, hat das eine angenehme Konsequenz: Der Migrationsaufwand liegt fast vollständig auf der Hardware- und Treiberebene, nicht in der Bedienung. Wer die Proxmox-Weboberfläche, die Cluster-Logik, Backup-Jobs mit Proxmox Backup Server oder die API kennt, findet auf ARM64 dasselbe Verhalten vor – kein zweites Produkt mit eigener Lernkurve, sondern derselbe Stack auf anderem Silizium.

Eine technische Einschränkung gehört allerdings zu jeder ehrlichen Einordnung dazu, auch wenn Proxmox sie in der Pressemitteilung nicht in den Vordergrund stellt: Feature-Parität bedeutet nicht Binärkompatibilität zwischen den Architekturen. Ein ARM64-Hypervisor virtualisiert nativ ARM64-Gastsysteme – bestehende x86-64-VM-Images lassen sich nicht einfach vom einen Proxmox-Knoten auf den anderen verschieben und dort mit voller Geschwindigkeit weiterlaufen lassen. Wer auf einen ARM64-Cluster wechselt, benötigt entsprechend ARM64-fähige Gastbetriebssysteme und -Images, was in der Praxis kein großes Hindernis mehr ist, da Debian, Ubuntu, RHEL und die gängigen Container-Basis-Images seit Jahren vollwertige ARM64-Varianten pflegen – aber es ist ein Punkt, den man bei der Migrationsplanung nicht übersehen sollte. Für gemischte Umgebungen bedeutet das faktisch: getrennte Knotenpools statt eines homogenen Clusters über beide Architekturen hinweg, zumindest solange keine spezialisierten Übersetzungsschichten mit vertretbarem Performance-Verlust zum Einsatz kommen.

NVIDIA Grace Hopper und Vera: die unterstützte Hardware

Der ARM64-Support ist kein Selbstzweck – er ist gezielt auf zwei NVIDIA-Plattformen zugeschnitten, die beide für KI-Workloads entwickelt wurden.

Grace Hopper: CPU und GPU auf einem Superchip

NVIDIA Grace Hopper (GH200) kombiniert eine ARM-basierte Grace-CPU mit einer Hopper-GPU auf einem gemeinsamen Modul, verbunden über NVLink-Chip-to-Chip (NVLink-C2C) mit rund 900 GB/s Bandbreite zwischen CPU und GPU. Der eigentliche Clou ist das Unified-Memory-Modell: CPU und GPU teilen sich einen kohärenten Adressraum, sodass Daten nicht mehr explizit zwischen Host- und GPU-Speicher kopiert werden müssen. Für Trainings- und Inferenz-Workloads mit großen Modellen – klassisches Terrain für CUDA-beschleunigte Pipelines – reduziert das den Overhead, der sonst beim Verschieben von Gewichten und Aktivierungen zwischen Speicherbereichen entsteht.

Vera: die nächste CPU-Plattform

Vera ist NVIDIAs Nachfolge-Plattform für die Grace-CPU-Generation und für den Einsatz zusammen mit kommenden GPU-Generationen als Rechenzentrums-Superchip-Kombination konzipiert. Für Betreiber ist der genaue Mikroarchitektur-Fortschritt zweitrangig – entscheidend ist, dass NVIDIA mit Vera denselben Weg konsequent weitergeht: ARM-CPU-Kerne, eng gekoppelt mit der GPU, optimiert auf Speicherbandbreite und Energieeffizienz statt auf reine Einzelkern-Taktfrequenz.

Damit setzt NVIDIA seine Strategie fort, den klassischen PCIe-Flaschenhals zwischen CPU und Beschleuniger zu umgehen, statt ihn mit immer schnelleren PCIe-Generationen nur zu verschieben. Für Betreiber selbst gehosteter Sprachmodelle ist das mehr als eine Fußnote: Je größer die Modelle und je knapper der verfügbare VRAM pro GPU wird, desto stärker schlägt jede zusätzliche Kopieroperation zwischen Host- und Gerätespeicher auf die effektive Antwortzeit durch. Ein Architekturmodell, das CPU- und GPU-Speicher als einen gemeinsamen, kohärenten Pool behandelt, verschiebt genau diesen Engpass – unabhängig davon, ob die konkrete Workload Training oder Inferenz ist.

Gemeinsame Entwicklung mit NVIDIA und Supermicro

Der ARM64-Support ist nach Angaben von Proxmox nicht im Alleingang entstanden, sondern Ergebnis einer technischen Zusammenarbeit mit NVIDIA und Supermicro. Konkret erfolgte die Validierung gemeinsam auf NVIDIA-Grace-Hopper-Superchip-Serversystemen – also genau der Hardware-Kategorie, für die der Support gedacht ist, statt auf generischen ARM-Entwicklungsboards. Supermicro tritt dabei als Hardware-Partner auf, der Referenzsysteme für den Rechenzentrumseinsatz bereitstellt.

Bemerkenswert ist die Aussage von Proxmox, die Software laufe bereits in „ausgewählten Enterprise-Produktionsumgebungen" – der ARM64-Support ist also keine reine Ankündigung auf dem Papier, sondern hat vor der öffentlichen Freigabe bereits einen Praxistest in produktivem Umfeld durchlaufen. Für ein Open-Source-Projekt, das traditionell stark community-getrieben arbeitet, ist eine direkte, benannte Kollaboration mit einem GPU-Hersteller und einem Serverhersteller dieser Größenordnung ein ungewöhnlich enger Schulterschluss.

Für das Ökosystem hat das zwei Konsequenzen. Erstens verkürzt die gemeinsame Validierung die Zeit, bis Fehler auf realer Zielhardware statt in Emulation gefunden werden – ein Grund, warum die ARM64-Edition offenbar direkt mit voller statt schrittweiser Feature-Parität startet. Zweitens signalisiert die Kooperation Serverherstellern jenseits von Supermicro, dass ein offener, lizenzkostenfreier Hypervisor für ihre Grace-Hopper- und Vera-Plattformen existiert – was die Verfügbarkeit entsprechender Referenzsysteme am Markt tendenziell beschleunigen dürfte, auch wenn dazu noch keine belastbaren Zahlen vorliegen.

Aus Sicht deutscher Systemhäuser und Rechenzentrumsbetreiber ist besonders die Kombination aus beiden Partnern interessant. Supermicro liefert seit Jahren einen großen Teil der GPU-Server, die europäische Mittelständler für On-Premise-KI-Projekte beschaffen – häufig auf x86-Basis, aber mit wachsendem ARM-Portfolio. Dass ausgerechnet dieser Hersteller als Referenzpartner für die Proxmox-Validierung fungiert, senkt die praktische Hürde für Systemhäuser, ARM-basierte Grace-Hopper- oder Vera-Server künftig als reguläre Beschaffungsoption neben klassischen x86-Rack-Servern zu führen, statt sie als exotisches Sonderprojekt zu behandeln.

Warum ARM64 im KI-Rechenzentrum jetzt an Fahrt gewinnt

Der Proxmox-Schritt fällt nicht in ein Vakuum, sondern in einen Trend, der sich seit einiger Zeit abzeichnet: ARM-Serverchips gewinnen im Rechenzentrum an Boden, weil Performance-pro-Watt zum limitierenden Faktor wird, sobald KI-Cluster in die Größenordnung mehrerer Racks wachsen. ARM-Kerne sind pro Kern typischerweise sparsamer als x86-Kerne vergleichbarer Leistung, was bei Tausenden Kernen pro Rechenzentrum in spürbar geringerem Strom- und Kühlbedarf resultiert – ein Faktor, der angesichts steigender Strom- und Kühlkosten sowie der bekannten Preissprünge bei Arbeitsspeicher- und HBM-Komponenten zunehmend Budgetrelevanz bekommt.

Für KI-Workloads verschärft sich dieser Effekt zusätzlich, weil Inferenz-Cluster oft nicht durch Rohrechenleistung, sondern durch Speicherbandbreite und Interconnect-Latenz limitiert sind. Genau hier setzen Grace Hopper und Vera an: Die enge NVLink-C2C-Kopplung zwischen CPU und GPU reduziert Datenbewegung, statt sie über einen klassischen PCIe-Umweg zu erzwingen. Das ist ein Architekturvorteil, der unabhängig davon greift, ob darüber x86- oder ARM-Kerne sitzen – aber NVIDIA hat ihn bislang konsequent mit ARM-basierten Grace-CPUs kombiniert.

Das heißt nicht, dass x86 im KI-Rechenzentrum verdrängt wird. Für Kompatibilität mit bestehender Software, für Legacy-Anwendungen, für heterogene Workloads jenseits reiner GPU-Beschleunigung und für die schiere Tiefe des x86-Software-Ökosystems bleibt x86-64 auf absehbare Zeit die pragmatischere Wahl. Wo sich der Umstieg auf ARM lohnt, ist eher der klar abgegrenzte Fall: dedizierte, dichte GPU-Inferenz-Cluster, bei denen CPU-Anbindung, Speicherbandbreite und Energieeffizienz pro Rack den Ausschlag geben und ein hoher Grad an Standardisierung auf wenige, klar definierte Workloads besteht.

Verschärft wird die Energiefrage zusätzlich durch die Preisentwicklung bei Arbeitsspeicher- und HBM-Komponenten, die wir bereits an anderer Stelle im Detail eingeordnet haben: Wenn Speicherbausteine knapper und teurer werden, steigt der wirtschaftliche Druck, jeden verbauten Gigabyte Speicher möglichst effizient zu nutzen – ein Argument, das zusätzlich für Architekturen mit gemeinsam genutztem, kohärentem Speicher spricht, statt Daten redundant zwischen getrennten CPU- und GPU-Speicherbereichen vorzuhalten. Details dazu finden Sie in unserer Analyse zum DRAM- und HBM-Preisschock bei KI-Servern.

Was das für On-Premise-KI-Cluster im Mittelstand bedeutet

Für die meisten mittelständischen Unternehmen, die aktuell über den Aufbau oder Ausbau einer On-Premise-KI-Infrastruktur nachdenken, ist die ehrliche Einordnung: Grace-Hopper- und Vera-Systeme sind derzeit teures Rechenzentrums-Equipment, kein Sofort-Umstieg für eine erste On-Premise-Installation mit ein bis vier GPU-Karten. Wer heute ein Projekt plant, wird weiterhin auf bewährte x86-Serverplattformen mit einzeln steckbaren GPUs setzen – aus Gründen der Beschaffbarkeit, der Ersatzteilversorgung und weil das Software-Ökosystem rund um Treiber, Monitoring und Backup auf x86 schlicht ausgereifter ist.

Die Signalwirkung ist trotzdem real, und sie wirkt auf zwei Ebenen. Erstens erweitert sich mittelfristig die Herstellerauswahl bei GPU-Servern: Wo bislang praktisch jede ernstzunehmende On-Premise-KI-Beschaffung auf x86-Boards hinauslief, entsteht mit validierten ARM-Referenzsystemen eine zweite, wachsende Beschaffungsschiene – relevant vor allem für Unternehmen, die in zwei bis drei Jahren einen größeren Kapazitätsausbau planen und heute schon die Marktentwicklung im Blick behalten wollen.

Zweitens fügt sich der Schritt in einen Kontext, den viele IT-Verantwortliche gerade ohnehin bearbeiten: die Migrationswelle weg von VMware, ausgelöst durch die Lizenzpolitik seit der Broadcom-Übernahme. Proxmox VE hat sich in diesem Zusammenhang bereits als ernstzunehmende Open-Source-Alternative auf x86 etabliert – viele Mittelständler, die aktuell ihre allgemeine Server-Virtualisierung von VMware auf Proxmox umstellen, tun das ohnehin unabhängig von jeder KI-Initiative, allein aus Kostengründen. Dass dieselbe, lizenzkostenfreie Plattform künftig auch auf ARM-basierten KI-Servern zur Verfügung steht, bedeutet: Wer aus dem VMware-Lock-in aussteigt, muss sich nicht zusätzlich an einen zweiten proprietären Hypervisor für seine künftige GPU-Infrastruktur binden. Das ist ein Baustein für Unternehmen, die Wert auf Unabhängigkeit von einzelnen Lizenzmodellen legen – ein Thema, das sich mit unserem Ansatz für souveräne, selbst kontrollierte KI-Infrastruktur deckt.

Praktisch heißt das für ein IT-Team, das bereits einen VMware-Ausstieg plant: Die Proxmox-Kenntnisse, die im Rahmen der Migration der klassischen Server-Landschaft aufgebaut werden – Cluster-Betrieb, Backup-Strategie, Storage-Anbindung, Berechtigungskonzept –, lassen sich später eins zu eins auf einen möglichen ARM-basierten KI-Cluster übertragen. Es entsteht kein zusätzlicher Werkzeugbruch zwischen „klassischer IT-Virtualisierung" und „KI-Infrastruktur", wie es bei einer Kombination aus VMware für den Serverraum und einem separaten, herstellerspezifischen KI-Stack sonst häufig der Fall wäre.

Grenzen und offene Fragen des ARM64-Supports

Bei aller Reife auf Softwareseite bleibt der praktische Radius der Ankündigung eng gefasst. Drei Einschränkungen sollten IT-Verantwortliche im Blick behalten, bevor sie ARM64-Proxmox in konkrete Planungen aufnehmen:

Hardware-Kategorie	Support-Status
NVIDIA Grace Hopper	Vollständig unterstützt, gemeinsam validiert
NVIDIA Vera	Vollständig unterstützt, gemeinsam validiert
Andere UEFI-ARMv9-A-Hardware	„Best-Effort" – läuft, aber ohne Garantie
ARMv8-A-Systeme	„Generally works as well" – funktioniert i. d. R., ungetestet im Detail
Raspberry Pi / Einplatinencomputer	Nicht unterstützt

Erstens fehlt außerhalb der beiden NVIDIA-Plattformen jede breite, offiziell zugesicherte Hardware-Unterstützung. Wer auf einem anderen ARM-Server experimentiert, tut das auf eigenes Risiko und ohne Anspruch auf Fehlerbehebung durch Proxmox. Zweitens steht dem ARM64-Zweig naturgemäß nicht dieselbe jahrzehntelange Praxiserfahrung gegenüber wie der x86-64-Codebasis, die seit der ersten Proxmox-VE-Version 2008 kontinuierlich gehärtet wurde – Kinderkrankheiten in Edge Cases sind bei einer derart neuen Plattform nicht auszuschließen, selbst wenn der Kern bereits produktiv im Einsatz ist. Drittens ist das Ökosystem an Treibern, Storage-Controllern und Firmware-Tools für generische ARM-Server im Rechenzentrum insgesamt schmaler als im x86-Umfeld, was die Erweiterung des Hardware-Supports über Grace Hopper und Vera hinaus nicht zu einer reinen Softwarefrage macht.

Realistisch ist, dass Proxmox den unterstützten Hardware-Kreis in künftigen Punkt- und Major-Releases schrittweise erweitert, sobald weitere ARM-Serverplattformen ausreichend verbreitet und für eine Validierung im selben Umfang zugänglich sind wie die aktuellen NVIDIA-Systeme über die Supermicro-Partnerschaft. Ein konkreter Zeitplan dafür liegt öffentlich nicht vor.

Ein weiterer offener Punkt betrifft die Randbereiche des Betriebs, die bei einer x86-Installation als selbstverständlich gelten: Firmware-Updates, Out-of-Band-Management, RAID- und HBA-Controller-Treiber sowie die Integration in bestehende Monitoring- und Alerting-Ketten. Auf x86-Servern sind diese Werkzeuge über Jahrzehnte gewachsen und herstellerübergreifend weitgehend standardisiert. Im ARM-Server-Segment ist dieser Reifegrad – auch außerhalb von Proxmox – insgesamt noch geringer, selbst wenn die Basisplattform der Server-Firmware zunehmend auf gemeinsamen Standards wie einer SBSA-konformen UEFI-Umgebung aufbaut. Wer heute einen ARM64-Proxmox-Piloten aufsetzt, sollte diese Randthemen ausdrücklich mit einplanen, statt sie stillschweigend als „funktioniert schon wie gewohnt" vorauszusetzen.

Fazit: Ein früher, aber ernstzunehmender Meilenstein

Drei Punkte fassen zusammen, was am 5. August 2026 tatsächlich passiert ist: Proxmox VE läuft offiziell und mit voller Feature-Parität auf ARM64. Der Support ist gezielt auf NVIDIA Grace Hopper und Vera zugeschnitten, nicht auf ARM-Hardware im Allgemeinen. Und die Entwicklung ist Ergebnis einer engen technischen Zusammenarbeit mit NVIDIA und Supermicro, inklusive Praxiseinsatz in Enterprise-Produktionsumgebungen vor dem öffentlichen Release.

Für IT-Verantwortliche, die On-Premise-KI-Cluster planen, lautet die Handlungsempfehlung entsprechend zweigeteilt. Aktuelle Projekte – insbesondere die typische Mittelstandsgröße mit ein bis acht GPU-Karten – sollten weiterhin auf der bewährten x86-64-Basis umgesetzt werden, für die Beschaffung, Support und Software-Ökosystem am ausgereiftesten sind. Gleichzeitig gehört ARM64-Proxmox ab sofort auf den Radar der mittel- bis langfristigen Infrastrukturplanung: als zusätzliche, lizenzkostenfreie Option für den Fall, dass künftige Kapazitätserweiterungen auf dichtere, energieeffizientere GPU-Systeme setzen sollen, und als weiteres Argument für alle, die im Zuge der VMware-Migrationswelle ohnehin nach einer herstellerunabhängigen Virtualisierungsstrategie suchen.

Wenn Sie Ihre On-Premise-KI-Infrastruktur für die kommenden Jahre planen – ob auf x86 oder mit Blick auf künftige ARM-Optionen – beraten wir Sie zu Hardware-Wahl, Hypervisor-Strategie und GPU-Anbindung auf Basis Ihrer konkreten Workloads.

Quellen & Primärbelege

Alle Zahlen, Versionsangaben und Fakten in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. Proxmox: Pressemitteilung ARM64-Support Primärquelle der Ankündigung vom 5. August 2026
2. StorageReview: Proxmox ARM64 Bestätigung von Feature-Parität und NVIDIA-Grace-Hopper/Vera-Support
3. The Register: Proxmox auf ARM Artikel vom 6. August 2026, Details zu Hardware-Limitierungen inkl. Raspberry-Pi-Ausschluss
4. CNX Software: Proxmox aarch64 Technische Einordnung des offiziellen 64-Bit-ARM-Supports

Häufig gestellte Fragen zu Proxmox VE für ARM64

Ab wann ist Proxmox VE offiziell für ARM64 verfügbar und worauf basiert die Version?

Proxmox VE für ARM64 ist seit dem 5. August 2026 offiziell verfügbar. Die Version basiert auf Debian 13.5 „Trixie" mit Linux-Kernel 7.0 als Standard – identisch zur x86-64-Basis von Proxmox VE 9.2.

Läuft Proxmox VE auf ARM64 mit vollem Funktionsumfang oder nur eingeschränkt?

Proxmox VE für ARM64 bietet vollständige Feature-Parität zur x86-64-Version: KVM/QEMU 11.0, LXC 7.0, ZFS 2.4 und der komplette Ceph-Storage-Stack (inkl. Ceph Squid 19.2 und Tentacle 20.2) stehen identisch zur Verfügung.

Läuft Proxmox VE für ARM64 auch auf einem Raspberry Pi?

Nein. Offiziell und vollständig unterstützt werden ausschließlich NVIDIA Grace Hopper und NVIDIA Vera Plattformen. Für andere UEFI-basierte ARMv9-A-Hardware (und ARMv8-A) gibt es nur „Best-Effort"-Support – Einplatinencomputer wie der Raspberry Pi fallen laut Proxmox und The Register explizit heraus.

Warum ist der ARM64-Support von Proxmox für On-Premise-KI-Cluster relevant?

NVIDIA Grace Hopper und Vera sind CPU-GPU-Superchip-Plattformen, die speziell für KI-Workloads mit hoher Speicherbandbreite entwickelt wurden. Mit offiziellem Proxmox-Support können Unternehmen ihre KI-Infrastruktur erstmals auf einer bewährten Open-Source-Virtualisierungsplattform betreiben, statt auf proprietäre Hypervisor-Lösungen angewiesen zu sein – ein Baustein für souveräne, selbst kontrollierte KI-Cluster.