Metal-Shim beschleunigt TinyLlama in macOS-VM um 16.36×

Nur zwei gemeldete Capability-Werte trennten llama.cpp von 16.36× schnellerer Token-Generierung mit TinyLlama. Forscher änderten diese Werte innerhalb einer macOS-VM auf einem M1 Ultra. Physische GPU, Gast-Kernel und Modell blieben unverändert.

Damit lässt sich der Engpass klar eingrenzen. Bei einigen Metal-Workloads in Apple-Silicon-VMs bremst nicht die Hardware, sondern eine konservative Softwaremeldung. Die GPU könnte den schnelleren Code ausführen, doch die Anwendung wird auf einen langsameren Pfad geschickt.

Francesco Bonacci und Johnny Franks führten die Tests mit Lume durch, Cuas Virtualisierungs-Stack für macOS. Ihre Veröffentlichung enthält Quellcode, Build-Skripte, Capability-Probes und rohe Benchmark-Logs. Diese Reproduzierbarkeit ist entscheidend, weil Apple das zugrunde liegende Verhalten nicht als stabile, öffentliche Kompatibilitätszusage dokumentiert.

Apples Virtualization.framework stellt dem macOS-Gastsystem ein virtuelles Grafikgerät bereit. Der Gast übermittelt Metal-Workloads über einen für Virtualisierung ausgelegten Treiber, anschließend führt der Host sie auf der physischen Apple-GPU aus. Das unterscheidet sich von der direkten PCI-Gerätezuweisung, die unter Linux meist als GPU-Passthrough bezeichnet wird.

Die unveränderte Tahoe-VM meldete eine GPU-Familie der Apple-5-Generation, höchstens 32 KB Threadgroup-Speicher und keine Unterstützung für SIMD-Group-Matrizen. llama.cpp übernahm diese gemeldeten Grenzen und wählte ältere GPU-Kernel.

Das ist wie eine freie Schnellstraße mit dem falschen Tempolimit. Die Strecke wäre schnell genug, aber die Software bremst, weil das Schild es verlangt.

Die Forscher entwickelten eine prozessgebundene Metal-Kompatibilitätsschicht, die ausgewählte Capability-Abfragen abfängt. Sie verändert die an einen einzelnen Gastprozess gemeldeten Werte für Apple-Familie und Threadgroup-Speicher. Die getesteten llama.cpp-Builds konnten dadurch neuere Pfade für SIMD-Group-Reduktion, Matrizen und bfloat16 verwenden.

Die enge Begrenzung ist zentral. Andere Prozesse im Gastsystem behielten ihre Standardeinstellungen, und der Workload lief weiterhin über Apples bestehenden paravirtualisierten GPU-Pfad. Der Shim änderte nur, welche Fähigkeiten eine Anwendung der virtuellen GPU zutraute, nicht die darunterliegende VM-Architektur.

TinyLlama 1.1B erzielte auf einem M1 Ultra mit 48-Core-GPU den größten relativen Sprung. Die Prompt-Verarbeitung stieg von 432 auf 4,787 Token pro Sekunde, ein Plus von 11.08×. Die Token-Generierung wurde 16.36× schneller. Die modifizierte VM erreichte 98% der Prompt-Leistung des Bare-Metal-Systems und 72.06% bei der Generierung.

Bei größeren Modellen zeigte sich dasselbe Grundmuster:

• Google’s Gemma 4 12B QAT Q4_0 stieg bei der Prompt-Verarbeitung von 71.66 auf 515.76 Token pro Sekunde, also um 7.20×. Die Generierung legte von 3.41 auf 49.67 Token pro Sekunde zu, ein Faktor von 14.54×. Das entsprach 99.59% der Bare-Metal-Geschwindigkeit bei Prompts und 94.82% bei der Generierung.
• Meta’s Muse Glimmer 30B Q4_K-M verbesserte sich bei Prompts von 25.83 auf 194.97 Token pro Sekunde, also um 7.55×. Die Generierung stieg von 2.38 auf 21.08 Token pro Sekunde, ein Faktor von 8.87×.
• Die Leistung von MLX-LM blieb unverändert. Geänderte Capability-Meldungen beschleunigen nicht automatisch jede Metal-Anwendung.

Die Aussagekraft der Daten ist bewusst eng begrenzt. Die meisten Tests liefen auf einem einzelnen M1 Ultra mit macOS 26.6.1 als Host und macOS 26.5.2 im Gastsystem. Für TinyLlama und Gemma wurden die Medianwerte aus zehn Durchläufen verwendet. Muse Glimmer basierte auf drei Durchläufen und lief auf einem Host, den sich der Test mit einer weiteren, zeitweise aktiven VM teilte.

Der Muse-Test deckte außerdem nur textbasiertes llama.cpp ab. Ollama, multimodale Inferenz und Speculative Decoding wurden nicht getestet. Die Ergebnisse belegen, was in dieser Konfiguration funktionierte. Sie sind keine allgemeine Leistungsgarantie für macOS-Virtualisierung.

Der Shim hängt zudem von privatem, versionsabhängigem Verhalten der Metal-Implementierung im Gastsystem ab, warnen die Autoren. Apple könnte dieses Verhalten mit jedem Release ändern. Als die Forscher umfassendere Metal-3-Unterstützung meldeten, forderte MLX eine Residency-Funktion an, die das virtuelle Gerät nicht bereitstellen konnte. Der veröffentlichte Shim verändert deshalb ausschließlich die getesteten Werte.

Genau darin liegt der Zielkonflikt: Ein breiteres Capability-Profil kann schnellere Kernel freischalten, Anwendungen aber auch zu nicht unterstützten Funktionen lenken. Jede Kombination aus Chip, macOS-Versionen und Metal-API muss separat validiert werden.

Wer lokale Inferenzserver oder automatisierte Worker in macOS-VMs betreibt, sollte deshalb zuerst den tatsächlich gewählten GPU-Pfad messen, bevor zusätzliche Hardware gekauft wird. Ein prozessspezifischer Shim kann erhebliche Leistung zurückholen, ohne die VM-Architektur anzutasten. Dafür braucht es reproduzierbare Tests, Prüfsummen und einen Rollback-Pfad. Die Veröffentlichung empfiehlt, die Aktivierung per Umgebungsvariablen oder LaunchAgent auf den jeweiligen Workload zu beschränken.

Wenn Apples virtuelle GPU diese neueren Kernel sicher ausführen kann, warum meldet Virtualization.framework dann nicht standardmäßig die Fähigkeiten, die llama.cpp für ihre Auswahl benötigt?