Две докладвани стойности за възможностите на GPU деляха llama.cpp от 16,36-кратно ускорение при генерирането на токени с TinyLlama. Изследователите промениха тези стойности в macOS виртуална машина върху M1 Ultra. Физическият GPU, ядрото на гост системата и моделът останаха същите.
Това стеснява причината до софтуерен bottleneck. При някои Metal натоварвания във виртуални машини с Apple Silicon консервативно обявените възможности могат да ограничат производителността повече от самия хардуер. GPU може да изпълни по-бързия код, но приложението получава сигнал да избере по-бавен път.
Francesco Bonacci и Johnny Franks проведоха тестовете чрез Lume, стека на Cua за macOS виртуализация. Тяхната публикация на изследването включва изходен код, build скриптове, capability probes и сурови benchmark логове. Възпроизводимостта е решаваща, защото Apple не представя поведението зад този подход като стабилен публичен договор за съвместимост.
Virtualization.framework на Apple предоставя виртуално графично устройство на гост системата с macOS. Тя подава Metal задачите през драйвер, съобразен с виртуализацията, а хостът ги изпълнява върху физическия Apple GPU. Това не е същото като директното присвояване на PCI устройство, което обикновено се нарича GPU passthrough при Linux.
Стандартната VM с Tahoe докладва GPU семейство от ерата на Apple 5, максимум 32 KB threadgroup памет и липса на поддръжка за SIMD-group матрици. llama.cpp прие тези ограничения и избра по-стари GPU kernels.
Представете си бърз път с грешен знак за ограничение на скоростта. Пътят е свободен, но софтуерът намалява, защото знакът му казва да го направи.
Изследователите създадоха Metal compatibility shim, който работи само в рамките на конкретен процес и прихваща избрани заявки за възможностите на GPU. Той променя стойностите за Apple семейството и threadgroup паметта, връщани към един процес в гост системата. Така тестваните версии на llama.cpp успяха да използват по-новите пътища за SIMD-group reduction, матрични операции и bfloat16.
Този ограничен обхват е важен. Останалите процеси в гост системата запазиха стандартните си настройки, а натоварването продължи да минава през съществуващия паравиртуализиран GPU път на Apple. Shim-ът промени какво едно приложение смята, че може виртуалният GPU, а не архитектурата на VM под него.
TinyLlama 1.1B постигна най-голямото относително ускорение върху M1 Ultra с 48-ядрен GPU. Обработката на prompt се повиши от 432 на 4 787 токена в секунда, или 11,08 пъти. Генерирането на токени се ускори 16,36 пъти. Модифицираната VM достигна 98% от производителността при prompt директно върху хардуера, а при генериране достигна 72,06%.
По-големите модели показаха същата обща тенденция:
- Gemma 4 12B QAT Q4_0 на Google се повиши от 71,66 на 515,76 prompt токена в секунда, или 7,20 пъти. Генерирането нарасна от 3,41 на 49,67 токена в секунда, или 14,54 пъти. Това съответства на 99,59% от скоростта за prompt директно върху хардуера и 94,82% от скоростта при генериране.
- Muse Glimmer 30B Q4_K-M на Meta премина от 25,83 на 194,97 prompt токена в секунда, или 7,55 пъти. Генерирането се повиши от 2,38 на 21,08 токена в секунда, или 8,87 пъти.
- Производителността на MLX-LM не се промени. Промяната на докладваните възможности не ускорява автоматично всяко Metal приложение.
Данните умишлено имат тесен обхват. Повечето тестове са проведени върху един M1 Ultra с macOS 26.6.1 на хоста и macOS 26.5.2 в гост системата. Резултатите за TinyLlama и Gemma използват медиани от десет измервания. Muse Glimmer използва три измервания и работи върху хост, споделен с друга VM, която периодично е била активна.
Тестът с Muse обхваща и текстовия режим на llama.cpp. Не са тествани Ollama, мултимодална инференция или speculative decoding. Резултатите показват какво работи в тази конкретна конфигурация, а не обещават универсално ускорение при macOS виртуализация.
Авторите предупреждават и за друга зависимост: shim-ът разчита на непублично поведение в Metal имплементацията на гост системата, което може да се променя между версиите. Apple може да го промени при следващо издание. Когато изследователите обявили по-широка поддръжка на Metal 3, MLX поискал residency функционалност, която виртуалното устройство не можело да предостави. Затова публикуваният shim променя само тестваните стойности.
Тук е основният компромис. По-широк профил от възможности може да отключи по-бързи kernels, но може и да насочи приложенията към неподдържани функции. Всяка комбинация от чип, версия на macOS и Metal API трябва да се валидира отделно.
За екипи, които пускат локални inference сървъри или автоматизирани workers в macOS VM, практичната следваща стъпка е да измерят кой GPU път избира приложението, преди да купят още хардуер. Shim за конкретен процес може да върне значителна част от загубената производителност без промяна в архитектурата на VM. Това обаче изисква възпроизводими тестове, checksums и план за връщане назад. Публикацията препоръчва активирането да се ограничава за всяко натоварване чрез environment variables или LaunchAgent.
Ако виртуалният GPU на Apple може безопасно да изпълнява тези по-нови kernels, какво пречи на Virtualization.framework да докладва възможностите, от които llama.cpp се нуждае, за да ги избира по подразбиране?
