RTX 5090 und M4 MacBook Air: Kann man damit spielen?

 (scottjg.com)
1 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • An ein M4 MacBook Air wurde eine RTX 5090 eGPU angeschlossen, und Spiele wurden in einer Linux-VM ausgeführt; dafür mussten das Fehlen von macOS-Treibern und Thunderbolt-Beschränkungen umgangen werden
  • Für die Umsetzung waren ein virtuelles PCI-Gerät apple-dma-pci, das Umgehen von DART-Mappings, ein kprobes-basierter Patch für den NVIDIA-Treiber sowie Änderungen an QEMU/HVF nötig
  • Cyberpunk 2077 lief auf dem M4 Air + eGPU mit 4K RT Ultra 27 fps und wurde mit DLSS-Frame-Generation bei bis zu 111 fps spielbar
  • Steckt dieselbe RTX 5090 in einem normalen PCIe-PC, ist sie je nach Spiel 2- bis 4-mal schneller; FEX-, Proton-, VM- und Thunderbolt-Overhead bleiben erheblich
  • Noch größer ist der Effekt bei AI-Inferenz: Das Qwen-Prefill des M4 Air verkürzt sich um etwa das 100-Fache, und die Single-Stream-Generierung steigt von rund 22 tok/s auf 155 tok/s

Grenzen von Thunderbolt-eGPU und Apple-Silicon-Macs

  • Aufbau einer Thunderbolt-eGPU

    • Eine Desktop-GPU wie die RTX 5090 wird in ein Thunderbolt-Dock gesteckt, das PCIe in Thunderbolt umsetzt und dann über den USB-C-Port mit dem M4 MacBook Air verbunden wird
    • Thunderbolt tunnelt PCIe über ein USB-C-Kabel, daher erscheint das Thunderbolt-Gerät aus Sicht des Computers nicht als USB-, sondern als PCIe-Gerät
    • Thunderbolt 4 bietet maximal 40 Gbit/s mit 4 PCIe-Lanes, wobei durch das Tunneling ein kleiner Leistungsverlust entsteht
    • Unter Linux und Windows wird eine eGPU normalerweise wie ein etwas langsameres PCIe-Gerät erkannt und funktioniert mit bestehenden Treibern fast sofort
    • Das erste Hindernis ist, dass macOS auf Apple Silicon standardmäßig keine NVIDIA- oder AMD-GPU-Treiber mitliefert

  • Umgehung per Linux-VM

    • Linux auf Apple-Silicon-Macs auszuführen ist möglich, aber der aktuelle Linux-Kernel unterstützt auf Apple Silicon noch kein Thunderbolt, sondern nur interne Geräte und USB3
    • Führt man auf dem macOS-Host eine 64-Bit-ARM-Linux-VM aus, kann macOS die Thunderbolt-Geräte verarbeiten und Linux die NVIDIA-GPU
    • Für ARM64-Windows gibt es keine NVIDIA-Kartentreiber, daher wurde Linux verwendet
    • Der macOS-eGPU-Treiber von tinygrad funktioniert nur innerhalb des tinygrad-Stacks und eignete sich daher nicht als allgemeiner Treiber für AI-Inferenz oder Spiele

PCI-Passthrough unter macOS implementieren

  • PCI BAR und DMA

    • Damit eine VM mit einem PCI-Gerät kommunizieren kann, müssen PCI BARs (Base Address Registers) und DMA funktionieren
    • PCI BARs sind Speicherbereiche, die ein PCI-Gerät zum Lesen und Schreiben mit dem Computer verwendet; damit PCI-Passthrough funktioniert, müssen diese Bereiche in die VM gespiegelt werden
    • DMA (Direct Memory Access) ist ein Verfahren, bei dem das Gerät direkt auf den Arbeitsspeicher des Computers zugreift, ohne dass die CPU Daten kopieren muss

  • Hypervisor.framework und BAR-Mapping

    • Beim Start einer VM ruft QEMU Hypervisor.framework über hv_vm_map() auf, um das Speicherlayout des Gasts einzurichten
    • Verbindet man sich mit dem PCIDriverKit-Treiber auf dem Host und mappt mit IOConnectMapMemory64() den Gerätespeicher in den Prozess, lässt sich BAR0-Speicher lesen
    • Liest man BAR0[0], wird 0x1b2000a1 ausgegeben, eine gerätespezifische Konstante der RTX 5090
    • Wenn QEMU den Gerätespeicher direkt in den Gast mappt, kann der Gast unmittelbar mit der GPU kommunizieren, aber anfangs stürzte der Host-Kernel ab, sobald die VM den PCI-BAR-Speicher berührte
    • Die Ursache war, dass QEMU auch bei RAM-Gerät-/MMIO-Mappings HV_MEMORY_EXEC setzt; durch einen Workaround, der EXEC bei Gerät-/MMIO-Mappings entfernt, ließ sich die Host-Panic vermeiden
    • Dieser Ansatz ist etwa 30-mal schneller als das Abfangen jedes einzelnen Zugriffs, aber weil hv_vm_map() keinen ARM-Device-Memory-Subtype angeben kann, sind BAR-Schreibzugriffe etwa 10-mal langsamer als im Normalfall

DMA- und DART-Beschränkungen umgehen

  • Grenzen von DART auf Apple Silicon

    • Apple Silicon besitzt eine hardwareseitige Einheit namens DART, ähnlich einer IOMMU, die auch als Sicherheitsgrenze dient, damit Geräte nicht beliebig auf Host-Speicher zugreifen können
    • Bei Thunderbolt-Geräten über PCIDriverKit waren drei Einschränkungen besonders gravierend
      • Wegen eines Mapping-Limits von etwa 1,5 GB lassen sich die für CUDA und moderne Spiele nötigen Speicherabbildungen im Bereich von 8–16 GB nicht einfach beibehalten
      • Wegen einer Obergrenze von rund 64k Mappings laufen Mapping-Tabellen voll, wenn viele kleine DMA-Puffer verwendet werden
      • Adresse und Alignment lassen sich nicht direkt wählen, daher passt ein virtuelles IOMMU-Modell, bei dem der Gast die DMA-Adresse festlegt, nicht gut
    • Ein Ansatz mit restricted-dma-pool, der DMA auf einen vorallokierten Bereich beschränkt, funktionierte bei einfachen Geräten, passte aber nicht zum GPU-Treiber

  • Virtuelles PCI-Gerät apple-dma-pci

    • QEMU wurde um ein virtuelles PCI-Gerät namens apple-dma-pci erweitert, das zusammen mit der durchgereichten GPU in die VM eingefügt wird
    • Ein Gast-Kernel-Treiber fängt die DMA-Mapping-Aufrufe des NVIDIA-Treibers ab, erstellt für jede DMA-Anfrage bei Bedarf ein Mapping und entfernt es wieder, sobald der Puffer freigegeben wird
    • In dieser Struktur muss nicht der gesamte Gast-RAM, sondern nur das jeweils aktive Working Set der DMA-Puffer innerhalb des 1,5-GB-Limits bleiben
    • Der Gast-Treiber ersetzt, bevor der NVIDIA-Treiber die GPU verwendet, dessen DMA-Operationen durch benutzerdefinierte DMA-Ops und behandelt map_page, unmap_page, map_sg, unmap_sg, alloc und free als dünne Wrapper
    • Auf der Host-Seite leitet QEMU die Anfrage an den PCIDriverKit-Treiber weiter, der das eigentliche DART-Mapping ausführt und anschließend die DMA-Adresse zurück in den Gast-Speicher schreibt

  • NVIDIA-Alignment-Problem und kprobes-Patch

    • Beim Ausführen von CUDA-Workloads traten Kernel-Logs mit NV_ERR_INVALID_OFFSET und Alignment-Problemen rund um RM_PAGE_SIZE_HUGE auf
    • Die problematische Allokation war eine 16-MB-Allokation vom Typ UVM_RM_MEM_TYPE_SYS, bei der der NVIDIA-Treiber mit 2-MB-Pages arbeitete und dadurch in Konflikt mit den Alignment-Vorgaben geriet
    • Im Treiber gab es bereits einen Workaround, der bei NV_ERR_NO_MEMORY mit der Standard-Page-Größe erneut versucht, aber NV_ERR_INVALID_OFFSET nicht behandelte
    • Mithilfe von kprobes im Linux-Kernel wurde bei Aufrufen von nvUvmInterfaceMemoryAllocSys() pageSize auf UVM_PAGE_SIZE_DEFAULT erzwungen
    • So ließ sich auch ohne Änderungen am NVIDIA-Treiber eine kleinere Page-Größe anfordern, wodurch einfache Workloads funktionierten

  • Mit Mapping-Koaleszierung die 64k-Grenze umgehen

    • Bei höheren Spieleinstellungen entstehen viele kleine Mappings, wodurch die Grenze von rund 64k Mapping-Einträgen überschritten wird
    • In den Mapping-Logs waren über 90 % der Mappings 4 kB groß; sie waren nicht zusammenhängend, traten aber in Clustern auf
    • Der Gast-Speicher wurde in Regionen fester Größe wie 256 kB aufgeteilt; wenn ein 4-kB-Puffer gemappt wurde, wurde der ganze Cluster gemappt, sodass spätere Allokationen im selben Cluster das bestehende Mapping wiederverwenden konnten
    • Dieses Verfahren mappt etwas mehr Speicher als die tatsächlich aktiven Puffer, blieb in den getesteten Workloads aber unter der Grenze von etwa 1,5 GB
    • Die Zahl aktiver Mappings sank dadurch um etwa das 4-Fache, was genug Spielraum schuf, um anspruchsvolle Spiele mit höchsten Einstellungen zu starten

VM-Performance verbessern

  • vCPU-Scheduling

    • Ein Problem war, dass Benchmark-Ergebnisse stark zufällig schwankten und oft 50 % langsamer ausfielen
    • Offenbar setzte QEMU für vCPU-Threads keine Priorität, sodass der Scheduler der VM nicht genug Laufzeit gab
    • Durch einen Patch im QEMU-Startpfad der vCPU mit pthread_set_qos_class_self_np(QOS_CLASS_USER_INTERACTIVE, 0) und pthread_setschedparam(..., SCHED_RR, ...) wurde eine hohe Priorität vergeben

  • Total Store Ordering und FEX-Emu

    • Die VM läuft mit arm64-Linux, aber die meisten kommerziell verfügbaren Spiele sind x86-64-Windows-Binaries, daher wurden Proton) und FEX-Emu zusammen verwendet
    • x86 verwendet Total Store Ordering (TSO), bei dem Stores für andere Kerne in Programmreihenfolge sichtbar werden, während ARM ein schwächeres Speicherordnungsmodell nutzt
    • Apple Silicon besitzt einen hardwareseitigen TSO-Modus pro Thread, den Hypervisor.framework ab macOS 15+ verfügbar macht
    • Es wurde ein Patch von UTM übernommen, um auf der vCPU in ACTLR_EL1 Bit 1 zu setzen und die softwarebasierte TSO-Emulation von FEX-Emu abzuschalten
    • Schaltet man die softwarebasierte TSO-Emulation ohne das Hardware-Bit ab, stürzt Geekbench 6 mitten im Lauf ab
    • Die Gastleistung mit FEX und CPU-TSO liegt etwa 50 % unter der nativen Host-Performance

Spieleleistung

  • Cyberpunk 2077

    • Cyberpunk 2077 wurde auf M4 Air mit nativem macOS, M4 Air + eGPU, einem Intel MacBook Pro 2020 + eGPU, M5 Max mit nativem macOS, M5 Max + eGPU sowie einem Gaming-PC mit i5-12600K + RTX 5090 getestet
    • + Framegen verwendet in eGPU-/nativem-PCIe-Setup DLSS 4x und bei nativen macOS-Konfigurationen FSR 2x
    • Bei 720p Low war die GPU-Last gering, daher dominierten CPU- sowie Emulations-/Virtualisierungs-Overhead; das M4 Air nativ mit 61 fps war schneller als das M4 Air + eGPU mit 49 fps
    • Bei 1080p High war das M5 Max mit nativem macOS mit 131 fps schneller als das M5 Max + eGPU mit 68 fps; wenn die integrierte GPU ausreicht, wirkt sich der Overhead stärker aus
    • Das M4 Air mit nativem macOS kam bei 1080p RT Ultra nur auf 7 fps, das M4 Air + eGPU dagegen auf 30 fps und mit Frame-Generation auf 119 fps
    • In 4K wird die GPU zum Flaschenhals; das M4 Air + eGPU erreichte bei RT Ultra 27 fps und mit DLSS-Frame-Generation 111 fps, also ein spielbares Niveau
    • Der Gaming-PC mit nativer PCIe-Anbindung war mit 100 fps bei 4K RT Ultra und 282 fps mit DLSS-Frame-Generation am schnellsten
    • Das M5 Max + eGPU erreichte bei 4K RT Ultra 47 fps und mit Frame-Generation 145 fps und war damit ungefähr 30–70 % schneller als das M4 Air + eGPU

  • Andere Spiele und Benchmarks

    • In GravityMark sank die Leistung um etwa 20 %, wenn dieselbe GPU statt über einen PCIe-Slot über Thunderbolt angebunden wurde; das M4 Air + eGPU war etwa 31 % langsamer als eine native PCIe-Anbindung
    • In Shadow of the Tomb Raider hob die eGPU das M4 Air bei 4K nativ von 8 fps auf 40 fps an und verbesserte auch 1080p von nativen 26 fps auf 42 fps
    • Die eGPU-Leistung in Shadow of the Tomb Raider war bei 1080p und 4K fast gleich, was zeigt, dass der Flaschenhals nicht die GPU, sondern die CPU unter FEX ist
    • Horizon Zero Dawn Remastered verlangte selbst mit den niedrigsten 720p-Einstellungen mehr als 1,5 GB DMA-Speichermapping auf einmal, sodass der Benchmark nicht starten konnte
    • Doom (2016) lief in der eGPU-Konfiguration und erreichte laut Performance-Overlay 49 fps, blieb dabei stets über 30 fps
    • Crysis Remastered war bis zu etwa 4-mal langsamer als auf dem Gaming-PC, lief aber auch auf dem M4 MacBook Air mit spielbaren Frameraten

AI-Inferenzleistung

  • Qwen 3.6

    • Getestet wurde ein Qwen-35B-MoE-Modell in 4-Bit-Quantisierung mit 3B aktiven Parametern
    • Auf der NVIDIA-GPU kamen vLLM und die NVFP4-Version zum Einsatz, auf Apple Silicon vllm-mlx und ein 4-Bit-MLX-quantisiertes Modell
    • Die Benchmarks wurden mit llama-benchy ausgeführt
    • Die Thunderbolt-eGPU verlor gegenüber PCIe etwa 9 % Leistung, blieb aber ziemlich nah an PCIe, weil der Großteil der Verarbeitung auf der Karte selbst stattfand
    • Die RTX 5090 war bei der Single-Stream-Generierung 6,5-mal schneller als das M4 Air, 2,1-mal schneller als das M4 Max Mac Studio und 1,2-mal schneller als das M5 Max MacBook Pro
    • Bei einem 4K-Token-Prompt brauchte das M4 MacBook Air für das Prefill 17 Sekunden, mit derselben M4-Air-Konfiguration plus eGPU sank das auf 150 ms und war damit 120-mal schneller
    • Erhöhte man die Zahl paralleler Anfragen von 1 auf 4, stieg der Gesamtdurchsatz der RTX-5090-Konfiguration um etwa das 3-Fache, während Apple-Silicon-Macs schlechter skalierten

  • Gemma 4

    • Gemma 4 31B ist kein sparsames MoE, sondern ein dichtes 31B-Modell, bei dem jedes Token durch alle Parameter laufen muss
    • Die integrierte GPU des M4 Air kam in den Tests nicht über 2–3 Token pro Sekunde hinaus und wurde damit als praktisch unbrauchbar eingestuft
    • Alle vLLM-basierten RTX-5090-Konfigurationen lagen mit rund 50 t/s innerhalb weniger Prozentpunkte beieinander; das M4 Max Mac Studio erreichte rund 22 t/s, das M5 Max MacBook Pro rund 27 t/s
    • Auch beim Prefill blieb die RTX 5090 stets unter 400 ms, während das M4 Max für das Parsen eines 4K-Token-Prompts bis zu 21 Sekunden und das M5 Max etwa 7,5 Sekunden brauchten
    • Die vLLM-Konfigurationen erzielten bei 4 gleichzeitigen Anfragen etwa den 3,5-fachen Durchsatz, während das MLX-Backend auf dem Mac bei 4 Requests kaum weiter zulegte

Direkt nutzbar und stabil?

  • Deployment- und Build-Voraussetzungen

    • Im aktuellen Zustand ist das Ganze noch nicht auf dem Niveau „herunterladen und direkt starten“, da ein spezielles Apple-Entitlement erforderlich ist
    • Dieses Entitlement wurde angefragt, aber es gibt noch keine Antwort; die Wartezeit kann mehrere Monate betragen
    • In der Zwischenzeit lässt sich der Treiber selbst bauen, wobei der betreffende Mac im Signaturzertifikatskonto enthalten sein muss
    • Weder das Deaktivieren von SIP noch ein Reduced Security Mode sind nötig
    • Der Code ist unter qemu-vfio-apple verfügbar
    • Der enthaltene Launcher lädt automatisch ein vorkompiliertes Ubuntu-Image herunter, in dem bereits der spezielle apple_dma-Treiber installiert ist

  • Stabilität

    • Die Stabilität ist derzeit noch nicht gut
    • In FEX gibt es aktuell einen Bug, bei dem Steam häufig in einer Schleife abstürzt, und in dieser Konfiguration scheint das Problem noch gravierender zu sein
    • Das Starten bestimmter Spiele kann mehrere Minuten dauern
    • Wegen des DMA-Mapping-Limits können Mappings im Lauf der Zeit fragmentieren, sodass womöglich kein Platz mehr für ein neues Spiel bleibt
    • In diesem Fall muss die Linux-VM gestoppt und die GPU ab- und wieder angesteckt werden, um alle DMA-Mappings zu löschen, bevor man es erneut versucht
    • Am stabilsten läuft derzeit AI, und für diesen Einsatzzweck funktioniert die Lösung sehr gut
    • Es wird daran gearbeitet, die Patches in Upstream-QEMU zu integrieren; idealerweise soll das Ganze am Ende in gängigen QEMU-Distributionen wie UTM enthalten sein und sofort funktionieren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Hacker-News-Kommentare

  • Ich habe das VM-Team seit Jahren um VM-GPU-Passthrough gebeten. Ich habe an Apple-Silicon-Mac-Pro-Arbeit gearbeitet, und es hätte viel mehr Sinn ergeben, wenn man eine GPU im Gehäuse an eine Linux-VM hätte durchreichen können
    Leider wurde die Anfrage nicht angenommen, aber es ist cool, dass andere es zum Laufen gebracht haben

    • Der Passthrough-Teil hier scheint meiner Ansicht nach über eine standardmäßige DriverKit-Schnittstelle implementiert zu sein. Das heißt, PCIe-BARs lassen sich bereits in den Userspace mappen, ohne macOS zusätzlich zu modifizieren
      Am Ende wirkt es wie eine Frage, ob ein Virtual-Machine-Monitor wie QEMU diese Schnittstelle zusätzlich zu etwas wie Linux VFIO übernimmt. Wenn von Virtualization.framework die Rede ist, dann ist das selbst schon fast eine Art Virtual-Machine-Monitor, daher frage ich mich, was in macOS aus dieser Sicht genau fehlen soll
    • Dazu gibt es zwei halbwegs interessante Punkte. Erstens scheint Virtualization.framework etwas Ähnliches wie Host-GPU-Passthrough zu unterstützen. Nicht für eGPUs, sondern für die integrierte GPU, und der Hauptzweck scheint zu sein, dass ein macOS-Gast sich GPU-Zeit mit dem Host teilt und dabei Beschleunigung bekommt
      Kürzlich wurden auch in QEMU-Mainline Patches aufgenommen, die zusammen mit virtio-gpu einen „venus server“ verwenden, um Ähnliches für Linux-Gäste unter Hypervisor.framework zu unterstützen. Zweitens scheint es intern bei Apple Unterstützung für PCI-Passthrough für Virtualization.framework zu geben. Der Framework-Code selbst wird zwar an Kunden ausgeliefert, scheint aber von kexts oder Kernel-Komponenten abzuhängen, die in normalem macOS nicht enthalten sind. Ich weiß nicht, ob Apple jemals vorhat, das öffentlich freizugeben, aber es ist klar, dass bei Apple jemand über diese Funktion nachgedacht hat
    • Wie wahrscheinlich ist es, dass es künftig wieder einen Mac Pro geben wird? Ich frage mich, ob Apple irgendwann einen Computer bauen kann, der Siracusa zufriedenstellt, und ob sie auch ein „Believe“-Shirt haben
    • Die Hälfte des Problems in diesem Beitrag scheint sich mit Speicherzugriffsproblemen zu beschäftigen, die durch die QEMU/VM-Grenze entstehen. Vielleicht übersehe ich etwas Dummes, aber wenn man Ubuntu in Docker startet, würden die NVIDIA-Treiber dann nicht trotzdem geladen? Dann würde der Speicher ja weiter OSX gehören, und man müsste nicht gegen Apples Speicherverwaltung ankämpfen
    • Ich denke immer noch, dass das Fehlen von NVIDIA-GPU-Unterstützung im Mac Pro eine der größten verpassten Chancen der Tech-Branche bleibt
      Wie auch immer, der Mac Pro ist inzwischen ein totes Produkt. Mit Verkäufen nur an Audio-/Video-Profis ist eben irgendwann Schluss

  • Großartiger Beitrag. Die Gaming-Benchmarks sind unterhaltsam, aber praktisch gesehen ist der Teil über LLM-Leistungsverbesserungen wirklich interessant
    Apples Plattform ist dank viel RAM ein zugängliches Umfeld, in dem sich lokale Modelle leicht ausführen lassen, aber die relativ langsame Prompt-Verarbeitung wird oft übersehen. Wie im Beitrag zitiert, braucht das M4 MacBook Air bei einem 4K-Token-Prompt 17 Sekunden fürs Parsen, bevor es mit der Antwortgenerierung beginnt; mit eGPU sind es nur 150 ms, also 120-mal schneller. Wenn man nur mit kleinen Chats an LLMs herumspielt, fällt das Prefill-Problem kaum auf, aber sobald man sie für größere Aufgaben nutzt, wird die Rechengrenze zum Flaschenhals. Auch die TTFT-Diagramme sehen zunächst nicht schlecht aus, aber wenn man liest, dass die Mac-Plattform auf Log-Skala dargestellt werden musste, weil sie bei der reinen GPU-Rechenleistung viel zu langsam war, wirkt das gleich anders

    • Ich bin kein Experte, aber mich würde interessieren, ob jemand weiß, warum TTFT auf dem Mac so viel schlechter ist. Im Beitrag heißt es nur, dass diese Phase Compute-bound sei, aber ich frage mich, ob es wirklich so einfach ist oder ob MLX vielleicht auch weniger optimiert ist
    • Es mag kleinlich klingen, aber tatsächlich ist es 113-mal schneller
      Wenn der Autor die Ergebnisse so darstellt, kann das einen voreingenommenen Eindruck erwecken, aber ich glaube nicht, dass das hier wirklich der Fall ist
    • Nimm einfach oMLX. Mit Qwen3.6 bekomme ich bei der Prompt-Verarbeitung 300 Token/s und bei der Token-Generierung 30 Token/s

  • Dass OpenGL unter macOS nicht mehr gut unterstützt wird und das Spiel deshalb selbst mit CrossOver nicht vollständig spielbar ist, scheint zu stimmen
    Doom unterstützt allerdings offenbar Vulkan, und vielleicht reicht es, MoltenVK VK_NV_glsl_shader hinzuzufügen. Das dürfte deutlich weniger Arbeit sein, als eine RTX 5090 an ein M4 zu hängen, aber trotzdem Applaus für Scott. Auch die Geschwindigkeit bei lokaler KI-Inferenz ist ziemlich cool, ein wirklich verrücktes Projekt

  • Ziemlich beeindruckend. Mein Eindruck war, dass eGPU auf Apple Silicon einfach nicht funktioniert
    Apple sieht das genauso. „Zur Verwendung einer eGPU ist ein Mac mit Intel-Prozessor erforderlich.“ Außerdem waren die offiziell unterstützten eGPUs alle AMD und nicht NVIDIA. https://support.apple.com/en-us/102363

    • Hier geht es nicht darum, eine eGPU unter macOS zu nutzen. Zum Beispiel kann man nicht den Chrome-Browser unter macOS mit Beschleunigung über diese eGPU ausführen
      Hier wird diese eGPU in eine Linux-VM getunnelt

  • Zuerst dachte ich, das wäre ein Beitrag darüber, eine VM mit dem langsamen tinygrad-Treiber zu betreiben, aber tatsächlich war es ein deutlich besserer Ansatz
    Schade, dass Apple das nicht besser unterstützt und die 1,5-GB-Fenstergrenze lockert, dann wäre es viel einfacher. Arm hat generell einige Eigenheiten rund um PCIe-Geräte, aber zumindest unter Linux ist vieles deutlich einfacher geworden, weil die meisten aktuellen Treiber arm64 als erstklassige Plattform behandeln

    • Ich bin mir nicht sicher, aber ich glaube nicht, dass die Langsamkeit bei tinygrad am macOS-Hosttreiber selbst liegt. Es scheint sehr ähnlich zu sein wie das, was ich mache: PCI-BARs in den Userspace mappen und die GPU dann per Python-Code ansteuern
      Meine Vermutung ist, dass tinygrad vor allem deshalb langsam ist, weil die tinygrad-Inferenz-Engine für diese öffentlichen LLM-Modelle noch nicht stark optimiert ist. Wahrscheinlich floss der Großteil der Arbeit in die Optimierung des Stacks für Georges Hardwarefirma im Bereich autonomes Fahren. Da man vorhandene CUDA-Kernel in dieser Engine nicht einfach direkt ausführen kann, ist der Engineering-Aufwand viel höher. Ich frage mich auch, ob mein Projekt sich den macOS-Hosttreiber mit ihnen teilen könnte. Ein paar Änderungen wären wohl nötig, aber es scheint einiges an Überschneidungen zu geben

  • Die Aussage „Der erste Schritt bei den meisten Projekten heutzutage ist, so ungern man es zugibt, die KI zu fragen“ bedeutet wahrscheinlicher, dass die KI einem etwas erklärt, das sie selbst nicht weiß
    Das erinnert mich daran, wie ich gestern mit ChatGPT darüber gestritten habe, ob eine 5070TI überhaupt eine echte Grafikkarte ist. ChatGPT wollte mich ständig korrigieren und behauptete, es gebe keine 5070TI und ich müsse wohl eine 4070ti gemeint haben

    • Selbst nachdem sie den Fehler eingestehen, wiederholen sie denselben Fehler oft weiter
      Ich habe Claude gebeten, eine HTML-Seite über PowerShell 7 zu erstellen, und es schrieb, 7.4 sei die neueste LTS-Version. Ich gab einen Link dazu, dass 7.6 im März veröffentlicht wurde, und bat um eine neue Version mit aktuellen Informationen, aber es erstellte fast dieselbe Seite und wiederholte erneut die gleiche Behauptung, dass 7.4 die neueste Version sei
    • LLMs sind generell nicht gut positioniert, um bei hochaktuellen Themen starke Urteile über Plausibilität zu fällen
      Trotzdem war ChatGPTs Antwort auf den ursprünglichen Beitrag genau richtig. Die Zusammenfassung als „sehr tiefgehend“, „praktisch fast unbrauchbar“ und „aus Forschungsperspektive“ beschreibt diesen Beitrag selbst perfekt
    • Zu sehen, wie die gesamte Wirtschaft einer Supermacht und fast ihre komplette Onlinekultur von Furby besessen sind, war eines der seltsamsten Dinge, die ich je erlebt habe
    • Deshalb nutze ich den Grok expert mode. Er sucht aggressiv im Web, und das ist viel besser, als sich auf ein Jahr alte Daten zu verlassen
    • Ich hatte einmal eine Diskussion mit GPT-OSS 120B darüber, dass Cascade-Lake-Xeon-Workstation-CPU-Teile keine GPU haben. Das Modell behauptete mit voller Überzeugung das genaue Gegenteil

  • Das ist wirklich beeindruckend. Ich habe noch eine 5090 übrig und betreibe claw-like auf einem M4 Mini; wenn man sie zur Stabilität in so etwas wie einen 3D-gedruckten Rahmen steckt und an einen TB-Port anschließt, könnte das für lokale Inferenz ein ziemlich nützliches Werkzeug werden
    Man bräuchte allerdings irgendeine Vorrichtung, die Dinge wie die Stromversorgung sauber absichert. Das Problem ist, dass max-num-seqs und max-model-len miteinander in Konflikt geraten, und außerhalb eines rein einzelnen Client-Modus braucht man sozusagen mehrere Slots

  • Wenn es durch Apples Freigabeprozess käme, sähe das für KI-Inferenz ziemlich nützlich aus. Ich wollte NVIDIA-GPUs schon immer mit einem Mac Mini nutzen, und auf diesem Weg könnte man CUDA direkt ausführen. Wirklich cool