Metal-shim i macOS-VM ga 11 til 16 ganger raskere llama.cpp
Åpner en prosess-avgrenset Metal-shim fra Cua opp nyere GPU-kjerner i macOS-VM-er, slik at llama.cpp kjører 11 til 16 ganger raskere enn i en uendret gjest.
Selskapet Cua publiserte 11. august en forskningsutgivelse som fjerner et flaskehalslag de færreste visste var der. En macOS-gjest under Apples Virtualization.framework får en paravirtualisert GPU, og i Cuas standard Tahoe-image rapporterte den enheten seg som Apple-familie 5, med 32 KB maksimalt threadgroup-minne og uten støtte for SIMD-gruppematriser. Metal-programmer velger kjerner ut fra nettopp de svarene, så llama.cpp tok en tregere vei enn maskinvaren under faktisk kunne kjøre.
Shimen endrer to svar, og bare for én enkelt gjesteprosess: den rapporterer Apple-familie 9 og hever threadgroup-minnet til 64 KB. Det var nok til at llama.cpp slo på SIMD-gruppematriser, SIMD-gruppereduksjon og bfloat16.
Tallene kommer fra en M1 Ultra med 48-kjerners GPU. Med TinyLlama 1.1B gikk prompt-prosessering fra 431,86 til 4 786,70 token i sekundet, altså 11,08 ganger, og token-generering fra 12,63 til 206,60, altså 16,36 ganger. Prompt-farten traff 98,25 prosent av bar-metall-resultatet på samme maskin, mens genereringen stoppet på 72,06 prosent. Med Googles Gemma 4 12B i QAT Q4_0 ble gevinsten 7,20 og 14,54 ganger, og der nådde den oppgraderte gjesten 99,59 og 94,82 prosent av bar metall.
Det viktigste forbeholdet kom i Hacker News-tråden, der utgivelsen fikk 198 poeng samme dag.
«Dette vil ikke gjøre llama.cpp raskere for alle, bare for de som kjører det i denne bestemte typen Virtualization.framework-VM» — Simon Willison, utvikler
«Riktig. Disse tallene gjelder llama.cpp inne i macOS-gjestekonfigurasjonen vi testet. Bar-metall-llama.cpp er upåvirket» — Francesco Bonacci, medforfatter av utgivelsen
Navnet «GPU passthrough» er også misvisende. Ekte passthrough, slik VFIO gjør det på x86-Linux, tildeler en fysisk PCI-enhet til den virtuelle maskinen gjennom en IOMMU. Her skjer ingenting slikt: arbeidet går fortsatt gjennom Apples paravirtualiserte grafikkvei, og shimen endrer bare hva den veien rapporterer om seg selv.
Gevinsten er heller ikke universell inne i VM-en. Cua testet MLX-LM 0.31.3 med samme oppsett og fikk 1,005 ganger på prompt og 0,993 på generering, altså flatt, fordi MLX allerede var rask i standardgjesten. Metoden hviler dessuten på privat, versjonsfølsom oppførsel i gjestens Metal-implementasjon, og Cua skriver at Apple kan endre den mellom macOS-utgivelser.
Hva bør du gjøre?
- Kjører du modeller i en macOS-VM, se på stderr fra llama.cpp for hvilken Apple-familie gjesten rapporterer. Familie 5 med bfloat16 avslått betyr at du taper på kjernevalg, ikke på maskinvare.
- Ikke forvent noe på bar metall. Kjører du llama.cpp direkte på Mac-en, er det ingenting å hente her.
- Test din egen kombinasjon av vert og gjest før du bygger på dette. Cua tester hver kombinasjon separat nettopp fordi oppførselen ikke er dokumentert av Apple.
KI-kuratert — innholdet er generert av KI-agenter basert på originalkilden.