GPU-Drosselung unter Linux auf RTX-Spark-Laptops begrenzt die Geschwindigkeit lokaler LLMs

Entwickler, die versuchen, natives Linux auf neuen Nvidia-RTX-Spark-Laptops auszuführen, stehen vor einem kritischen Leistungsengpass, der die KI-Inferenzgeschwindigkeiten drastisch senkt. Ein aktueller technischer Test des MSI Prestige N16 Flip AI Plus zeigt, dass das Betriebssystem zwar korrekt installiert wird, die GPU-Taktgeschwindigkeiten jedoch zusammenbrechen, sobald das Gerät an eine Stromquelle angeschlossen ist. Diese hardware-spezifische Einschränkung macht derzeit das Windows Subsystem for Linux (WSL) zur einzigen praktikablen Option für Hochleistungs-Training und Inferenz lokaler Modelle auf diesen Maschinen.

Was passiert ist

Die RTX-Spark-Plattform, die in Geräten wie dem MSI Prestige, Asus ProArt und Dell XPS zu finden ist, nutzt eine Unified-Memory-Architektur, die für schwere KI-Workloads konzipiert wurde. Diese Laptops werden mit Windows on ARM ausgeliefert und unterstützen bis zu 128 GB RAM, die sich CPU und GPU teilen. Da viele KI-Engineering-Tools primär für Linux entwickelt wurden, versuchen Entwickler naturgemäß, Windows durch eine native Linux-Distribution zu ersetzen oder ein Dual-Boot-Setup einzurichten. Dieser Übergang löst jedoch einen schweren Leistungseinbruch aus, der mit der Firmware des Power-Managements zusammenhängt.

Bei der Ausführung von nativem Linux sinkt die GPU-Taktgeschwindigkeit auf etwa 780 MHz, sobald der Laptop an eine externe Stromquelle angeschlossen ist. Im Gegensatz dazu hält dieselbe Hardware unter Windows oder WSL Lastspitzen über 2 GHz. Diese Diskrepanz ist nicht thermisch bedingt; die Temperaturen bleiben zwischen 40 und 47 °C niedrig. Stattdessen wird die GPU durch eine Firmware-Logik künstlich begrenzt, auf die der Linux-Treiber derzeit keinen Zugriff hat oder die er nicht überschreiben kann. Das Ergebnis ist eine fünfmal geringere Token-Generierungsgeschwindigkeit bei großen Sprachmodellen.

Die Installation von Linux auf diesen Geräten erfordert zudem erhebliche manuelle Konfiguration. Standard-Distributionen wie Debian erkennen oft wesentliche Hardwarekomponenten wie Wi-Fi, Tastaturen oder Touchpads ohne spezifische Kernel-Patches nicht. Erfolgreiche Setups verlassen sich typischerweise auf Distributionen wie Omarchy, die Nvidias Open-Source-Kernel-Treiber enthalten. Selbst nach Erreichen einer stabilen Desktop-Umgebung mit 4K-Ausgabe bei 120 Hz müssen Nutzer die Speicherallokationseinstellungen in Windows anpassen, bevor sie Linux booten, damit das Betriebssystem mehr als nur einen Bruchteil des verfügbaren RAMs nutzen kann.

Wie es funktioniert

Die Ursache der Drosselung ist eine nur unter Windows verfügbare Firmware-Komponente namens Nvidia Platform Controllers and Framework. In Laptop-Formfaktoren verwaltet dieser Controller das gemeinsame Energiebudget zwischen CPU und GPU und stellt sicher, dass keine Komponente die gesamten Liefergrenzen des Gehäuses überschreitet. Im Gegensatz zum Desktop-Gerät DGX Spark, das dedizierte Stromleitungen besitzt, muss der Laptop den Energieverbrauch dynamisch ausgleichen. Die Firmware stellt eine verschlüsselte Tabelle mit Leistungseinstellungen bereit, die der Windows-Treiber entschlüsseln und anwenden kann, sodass die GPU ihre maximale Frequenz erreichen kann.

Linux fehlt ein entsprechender Treiber, der diese Leistungstabelle entschlüsseln kann. Ohne Zugriff auf diese Einstellungen greift der Linux-Kernel im Netzbetrieb standardmäßig auf einen sicheren, stromsparenden Zustand zurück und sperrt den GPU-Takt bei etwa 780 MHz. Interessanterweise kehrt sich dieses Verhalten um, wenn der Laptop im Akkubetrieb läuft: Hier entspricht die Linux-Leistung weitgehend der von Windows, da die Leistungsbeschränkungen anders gehandhabt werden. Versuche, diese Einschränkung durch Software-Workarounds zu umgehen, sind fehlgeschlagen; einige führten sogar zu Kernel-Panics, was darauf hindeutet, dass der Verschlüsselungsschlüssel streng an den Windows-Treiber-Stack gebunden ist.

Wichtige Details

• Natives Linux auf dem MSI Prestige RTX Spark erreicht nur 13,9 Tokens pro Sekunde bei GPT-OSS-120B, verglichen mit 65,4 Tokens pro Sekunde unter Windows.
• Die GPU-Taktgeschwindigkeit ist unter Linux im Netzbetrieb bei etwa 780 MHz gesperrt, gegenüber 2,2 GHz unter Windows.
• WSL performt nahezu identisch zu nativem Windows und erreicht 65,1 Tokens pro Sekunde, da es den Windows-Treiber-Stack nutzt.
• Nutzer müssen die GPU-Speicherreservierung in Windows von 96 GB auf 4 GB reduzieren, bevor sie Linux installieren, damit das Betriebssystem 120 GB RAM sehen kann.
• Das Drosselungsproblem wird durch eine verschlüsselte Power-Management-Tabelle verursacht, auf die nur der Windows-Nvidia-Platform-Controllers-Treiber zugreifen kann.
• Das Deaktivieren des Platform Controllers in Windows reproduziert die Verlangsamung unter Linux und bestätigt, dass diese Komponente für die Leistungslücke verantwortlich ist.

Warum das wichtig ist

Für KI-Ingenieure und ML-Praktiker verändert diese Erkenntnis die Hardware-Empfehlung für portable Entwicklungsumgebungen grundlegend. Das Versprechen eines Linux-nativen Laptops, der mit der Leistung des Desktop-DGX-Spark mithalten kann, bleibt aufgrund dieses Firmware-Locks derzeit unerfüllt. Entwickler, die diese High-End-Maschinen kaufen, in der Erwartung, lokale LLMs auszuführen, Modelle feinabzustimmen oder Tools wie vLLM in einer nativen Linux-Umgebung zu nutzen, werden auf einen schweren Engpass stoßen. Der Leistungseinbruch von 65 auf 14 Tokens pro Sekunde macht Echtzeitinteraktionen mit großen Modellen unter nativem Linux unpraktikabel.

Diese Situation verdeutlicht die wachsende Komplexität bei der Unterstützung von KI-Hardware über verschiedene Betriebssysteme hinweg. Während Nvidia mit CUDA-Unterstützung in den ARM-basierten Windows-Markt drängt, hinkt das Linux-Ökosystem bei der Reife der Treiber für diese spezifischen Hybrid-Architekturen hinterher. Bis Nvidia die Logik des Platform Controllers in seinen Linux-Treiber portiert, sind Entwickler gezwungen, zwischen der Bequemlichkeit der Linux-Tools und der Rohleistung von Windows zu wählen. Diese Fragmentierung erschwert Workflows, die idealerweise plattformunabhängig sein sollten.

Was Sie tun können

• Nutzen Sie das Windows Subsystem for Linux (WSL) für alle schweren KI-Workloads, um volle GPU-Boost-Geschwindigkeiten beizubehalten, während Sie gleichzeitig auf Linux-kompatible Tools zugreifen.
• Erhöhen Sie die WSL-Speicherallokation manuell, da das Standardlimit von 14 GB für große Modelle auf Maschinen mit 128 GB Unified Memory nicht ausreicht.
• Wenn Sie natives Linux verwenden müssen, führen Sie alle intensiven Inferenzaufgaben im Akkubetrieb aus, wo keine Takt-Drosselung stattfindet.
• Passen Sie die GPU-Speicherreservierung in den Windows-Einstellungen auf 4 GB an, bevor Sie Linux installieren, um sicherzustellen, dass das Betriebssystem den Großteil des System-RAMs nutzen kann.
• Verlassen Sie sich nicht auf Standard-Debian- oder Ubuntu-Installer, ohne vorher zu prüfen, ob diese die notwendigen Nvidia-Open-Source-Kernel-Treiber für den RTX-Spark-Chip enthalten.
• Beobachten Sie die Release Notes der Nvidia-Treiber auf Updates bezüglich der Unterstützung des Platform Controllers and Framework unter Linux, da dies der einzige Weg zu einer dauerhaften Lösung ist.