Sogenannte KI-Workstations wie Nvidias DGX Spark sind durch das Unified-Memory-Konzept gut für große lokale KI-Modelle geeignet. Diese Technik gibt es auch in Apple-Silicon-Macs und im direkten Vergleich arbeiten sie bei großen Sprachmodellen teils sogar schneller und extrem effizient. Bei Video- und Bildgenerierung sieht das anders aus. Wir haben zwei aktuelle Mac Studios gegen Nvidias DGX Spark und AMDs Strix Halo antreten lassen.

Transkript des Videos

(Hinweis: Dieses Transkript ist für Menschen gedacht, die das Video oben nicht schauen können oder wollen. Der Text gibt nicht alle Informationen der Bildspur wieder.)

Guck mal hier, das bin ich, wie ich endlich mal KI-Zeug auf Apple-Rechnern teste. Und direkt Spoiler: Das große, sehr gute Modell gpt-oss-120B habe ich noch auf keinem Rechner, der hier auf meinem Schreibtisch stand, so schnell laufen sehen. Und da standen schon sehr viele und auch sehr teure. Interessant ist dabei: Ein Mac Studio M4 Max mit 128 GB geteiltem Speicher kostet mit knapp 4.200 Euro ungefähr genauso viel wie die Nvidia-DGX-Spark-Workstations, die mit gpt-oss-120B deutlich weniger Tokens pro Sekunde machen. Also Apple, denen man ja nachsagt, KI so ein bisschen zu verschlafen, performt viel besser als die OG-KI-Superfirma Nvidia mit ihrer KI-Workstation? Hä? Ja, beim Anzapfen von solchen großen Sprachmodellen wie gpt-oss-120B ist das auf jeden Fall ganz klar so. Aber bei anderen KI-Sachen, da sieht die Sache schon wieder ganz anders aus. Ich habe übrigens zusätzlich zu dem Mac Studio mit M4 Max auch noch einen M3 Ultra mit 512 GB RAM getestet und noch etliche andere Rechner. Bleibt dran, wird wirklich interessant.

Liebe Hackerinnen, liebe Internetsurfer, herzlich willkommen hier bei …

Wenn ihr euch fragt: lokale KI, ja, was soll das eigentlich bringen? Lokale KI ist super interessant, weil man da nicht mehr auf irgendwelche Anbieter aus USA oder China angewiesen ist, die vielleicht klammheimlich irgendwas ändern an den KI-Modellen. Stellt euch mal vor, ihr habt so in mühsamer Kleinarbeit komplexe Workflows auf ein bestimmtes KI-Modell in der Cloud angepasst, und dann nimmt der Anbieter das aus dem Angebot oder ändert das, und dann läuft euer Kram nicht mehr. Mit lokalen Modellen seid ihr komplett safe, weil die liegen ja bei euch auf der SSD. Problem ist nur: Diese sogenannten Open-Weights-Modelle, Open Source werden die auch manchmal genannt, aber das sind die so gut wie nie, weil man nämlich die Trainingsdaten nicht kennt. Also Open Weights, ich nenne die ab jetzt einfach lokale Modelle. Die waren lange Zeit ziemlich schlecht, aber die holen auf. Die sind auf jeden Fall noch nicht auf dem Stand der State-of-the-Art-Cloud-Modelle wie Gemini 3 oder GPT 5.2, aber man kann damit auf jeden Fall schon arbeiten. Das habe ich hier in diesem Video auch schon mal anschaulicher gezeigt, was man da so machen kann.

Und es gibt natürlich auch Bild- und Videogenerierungsmodelle, die auch lokal laufen und die ziemlich gut sind und die man zum Beispiel auch selbst feintunen kann. Die man also selbst anpassen kann, dass da wirklich der Stil rauskommt, den man gerne haben will. Ganz aktuell ist da zum Beispiel Flux.2 für Bilder aus dem Schwarzwald oder WAN 2.2. für Videos. Das Problem ist nur, und das gilt vor allem für die LLMs: Je besser die Modelle, desto mehr schnellen Speicher brauchen die meistens. Und der schnelle Grafikspeicher von Grafikkarten ist dafür zwar sehr gut geeignet, aber man kriegt im Bereich bis, sagen wir mal, 2.000 Euro für eine Grafikkarte nur maximal 32 GB. Mein aktuelles Open-Weights-LLM, gpt-oss-120B, braucht ungefähr 63 GB Speicher. Ja, schwierig. Und man kann natürlich auch normales RAM verwenden, also statt Grafikspeicher einfach DDR5-RAM, wenn man es sich leisten kann. Aber nur auf DDR5 läuft wirklich kein Modell brauchbar schnell. Seht ihr später auch in den Benchmarks, wie das läuft. Lahm.

Aber es gibt ja auch immer mehr Spezialrechner, die für KI ausgelegt sind. Zum Beispiel die kleine Nvidia-KI-Workstation DGX Spark, die es von etlichen OEMs gibt. Haben wir auch schon mal ein Video zu gemacht, von der Gigabyte-Version. Oder auch die AMD-Halo-Strix-Rechner, zum Beispiel Framework Desktop, da gab es auch schon mal ein Video dazu. Und die nutzen alle Unified Memory, also CPU- und GPU-Speicher sind geteilt und schneller angebunden als normaler, zum Beispiel DDR5-Speicher.

Das Ding ist aber, dass Apple dieses Unified-Memory-Konzept schon lange nutzt. Also seit der Einführung von Apple Silicon vor fünf Jahren, also vor dem KI-Hype. Apple-Silicon-Rechner sind wegen des schnellen Speichers zumindest theoretisch super geeignet für KI. Und auch in der Praxis gilt das so langsam, da wird nämlich immer mehr Software richtig gut angepasst. Also zum Beispiel die zum Abzapfen von Sprachmodellen, also zum Beispiel für so ChatGPT-artige Anwendungen. Bild- und Videogenerierung, ja, da kommen wir später noch zu.

Erst mal Sprachmodelle, zum Beispiel das erwähnte gpt-oss-120B. Ja, und das habe ich auf zwei Apple-Rechnern getestet: einmal auf dem Mac Studio M4 Max mit 128 GB gemeinsamem Speicher für 4174 Euro. Und einmal dem Mac Studio M3 Ultra mit 512 GB gemeinsamem Speicher für 11.674 Euro. Tatsächlich sind beides aktuelle Geräte, denn wenn ihr euch jetzt wundert: Hä, M3: ist das nicht alt? Ne, tatsächlich sind beides aktuelle Geräte, denn wenn man mehr als 128 GB haben will, gibt es kein Gerät mit M4 Max, sondern dann gibt es nur den M3 Ultra. Und Ultra bedeutet in diesem Fall, dass da zwei M3-Einheiten zusammengebacken wurden, das nennt Apple Ultra Fusion. Ja, und obwohl die M4-Generation eine bessere Speicherbandbreite hat, nämlich beim M4 Max 546 GB/s, kriegt man mit dem M3 Ultra trotzdem mehr, weil es sind ja zwei M3-Einheiten, was hier insgesamt 819 GB/s entspricht.

Und was habe ich da nun genau drauf getestet? Ja, drei Sprachmodelle: ein ganz kleines Qwen3-4B, Q4 quantisiert, 2,5 GByte groß, ein mittleres Mistral Small 3.2 24B, auch Q4 quantisiert, das ist 15,2 GByte groß, und ein recht großes gpt-oss-120B mit im MXFP4-Format, 63,4 GByte groß.

So, und ich habe ja bislang die Benchmarks mit LM Studio manuell gemacht. Aber da haben mehrere Leute angemerkt, dass man noch ein bisschen mehr Tokens pro Sekunde mit der llama.cpp-Bibliothek rausholen kann. Die wird zwar von LM Studio intern auch verwendet, aber ist da trotzdem oft langsamer. Außerdem ein großer Vorteil: llama.cpp hat auch einen Benchmark eingebaut, und der differenziert zwischen dem Verstehen des Prompts, also dem Prompt Processing, PP oder Prefill, und der reinen Inferenz, also Decode oder Token-Generation, TG. Ja, und weil ich letzte Woche mehr Zeit hatte als sonst, weil ja kein Video kam, bin ich da richtig reingegangen und habe auf sechs unterschiedlichen Plattformen nicht nur llama.cpp installiert, also über die vorkompilierten Binarys, sondern ich habe llama.cpp auf jeder der Plattformen mit möglichst optimalen Compiler-Flags kompiliert. Das macht keinen riesigen Unterschied, aber bei meinem Test konnte ich da schon ein paar Prozent nachweisen, also im Vergleich zu den einfach runtergeladenen Binarys. Man kann mir also auf jeden Fall nicht vorwerfen, dass ich hier nicht fair getestet habe.

Und jetzt endlich die Ergebnisse, worauf ihr wahrscheinlich schon die ganze Zeit wartet: Tatsächlich haben mit gpt-oss-120B die beiden Apple-Rechner die besten Prompt-Processing-Ergebnisse erzielt, die ich jemals gemessen habe, mit gpt-oss-120B: 86 und 82 Token pro Sekunde. Also wie erwartet etwas mehr beim M3 Ultra, weil höhere Speicherbandbreite als beim M4 Max. Aber eigentlich ist der M4 Max die eigentliche Überraschung, weil der beim Generieren nur eine Leistungsaufnahme von 120 Watt hatte. Und 82 Token pro Sekunde bei 120 Watt, das ist wirklich krass effizient. Der M3 Ultra braucht fast das Doppelte, aber ist immer noch viel effizienter als die Konkurrenz. Also richtig doll ineffizient ist mein Desktop-Rechner mit zugeschalteter RTX4090-Grafikkarte. Der macht tatsächlich 14-mal weniger Token pro Watt als der M4 Max. Die beiden Spezialrechner mit Nvidia DGX Spark und AMD Strix Halo, die liegen im Mittelfeld. Bei den kleineren Modellen, die halt in den superschnellen Videospeicher meiner Grafikkarte passen, ja, da kommen M3 Ultra und M4 Max nur auf Platz 2 und 3. Ich habe übrigens, wie am Anfang schon erwähnt, testweise mal die GPU deaktiviert und geguckt, wie weit man nur mit der CPU kommt. Nicht weit, bei allen den drei Sprachmodellen schon sehr langsam, wie ihr hier sehen könnt.

Achtung, Achtung, jetzt kommt ein kurzer Super-Nerd-Einschub, geht gleich wieder nochmal weiter.

Ja, ich weiß, llama.cpp nutzt GGUF-Modelle. Bei Apple kann man ja auch MLX mit vorkonfigurierten MLX-Modellen verwenden. MLX ist das Apple-Machine-Learning-Framework, also quasi der PyTorch-Konkurrent. Ich habe das mit LM Studio getestet, und tatsächlich waren da meine Ergebnisse mit gpt-oss-120B mit MLX schlechter als mit llama.cpp. Und MLX lief auch auf dem M4 Max mit gpt-oss-120B auch gar nicht, sondern nur mit GGUF. Bei den kleineren Modellen war MLX aber tatsächlich ein ganzes Stück schneller, siehe hier meine Werte. Also das solltet ihr tatsächlich bedenken, und das ist auch die Erklärung dafür, dass LM Studio auf macOS bei den meisten Modellen immer beide Varianten, also GGUF oder GGUF und MLX, anbietet. Nerd-Einschub ist vorbei.

So, das war jetzt alles die Token-Generation. Jetzt kommt noch kurz das Prompt Processing, wo es weniger auf die Speicherbandbreite ankommt. Jetzt ist der M3 Ultra zumindest mit dem großen Sprachmodell gpt-oss-120B immer noch Spitzenreiter. Bei den kleineren Modellen, da gewinnt ganz klar wieder die Nvidia-Grafikkarte, und auf dem zweiten Platz ist der Nvidia-DGX-Spark-Rechner. Einfach weil die Nvidia-Kerne mehr rohe Compute-Pferdestärken mitbringen.

So, aber es gibt ja nun auch noch andere KI-Anwendungsbereiche als LLMs, zum Beispiel Bild-, Videobearbeitung, Generierung und so weiter. Das machen die meisten Menschen heutzutage wohl mit ComfyUI, dieser node-basierten Open-Source-Software. Hier gelten Nvidia-GPUs als de-facto Standard, einfach weil das alles sehr CUDA-fokussiert ist, also CUDA, die Nvidia-exklusive Programmierschnittstelle. Ich war deshalb schon ziemlich positiv überrascht, dass ich auf der ComfyUI-Website direkten macOS-Installer für die Desktop-Variante gefunden habe. Da habe ich mich auf mehr Frickeln eingestellt, und es lief alles super, also zumindest die Installation. Aber als ich dann für meine Tests einfach mal das Flux.2-Template aufgerufen habe und die Modelle runtergeladen hatte, bekam ich dann einfach ganz lapidar diese Fehlermeldung. Ja, und stellt sich raus: Apple Silicon kann nicht mit FP8 umgehen, also dem 8-Bit-Gleitkomma-Format, in dem aber dummerweise so gut wie alle ComfyUI-Modelle vorliegen. Also sowohl für Bildgenerierung als auch für Videogenerierung. Man kann sich damit behelfen, Modelle im FP16-Format zu verwenden, aber das verbraucht deutlich mehr Speicher und ist auch langsamer als FP8. Also wenn man denn auch ein FP16-Modell überhaupt findet. Also man will, also ich will das, auch vielleicht einfach nur die Templates anklicken, und dann funktioniert das, und will da jetzt nicht in den Nodes dann noch so viel rumfummeln. Na ja, bei einigen Workflows reichte das in meinen Tests auch einfach aus, in der Konfiguration von ComfyUI einfach auf FP16 hier umzuschalten. Aber auch nicht immer. Na ja, ich habe auf jeden Fall Flux-Dev stabil laufend bekommen und konnte da die Geschwindigkeit messen. Ja, die Geschwindigkeit auf dem Max war nicht berauschend. Ganz grob kann man sagen: 110 Sekunden für ein Standard-Preset-Flux-Dev-Bild auf dem M4 Max. 65 Sekunden hat der M3 Ultra gebraucht. 35 Sekunden, zum Vergleich, die DGX Spark und nur 12 Sekunden meine RTX 4090.

Und ja, mit Videos fange ich gar nicht erst an, das ist alles noch frickeliger gewesen. Und leider haben bei den ComfyUI-Standard-Workflows auch der riesige Speicher der Apple-Rechner keine Vorteile. Einfach weil die Modelle, die ich da gesehen habe und die ich so kenne, also auch die Videogenerierungsmodelle, die sind so gut wie alle für Grafikkarten-Speichergrößen optimiert. Ja, meistens so im Bereich bis 16 GB, ganz selten mal zwischen 16 und 24 GB.

Also auf jeden Fall: Wenn man hauptsächlich ComfyUI-Sachen machen will, dann ist man mit einem dieser Apple-Rechner nicht wirklich gut bedient. Aber ganz wichtig: Das kann sich natürlich alles ändern. Es sind ja jetzt auf jeden Fall schon Anflüge von einem Aufbrechen des CUDA-Monopols zu spüren. Warten wir das mal ab. Als reine LLM-Abzapfmaschine sind die Mac Studios und eigentlich alle Macs mit genügend Speicher beeindruckend gut geeignet. Und eine Eins mit Sternchen kriegen die wirklich in Sachen Effizienz. Will man allerdings nur Modelle laufen lassen, die in den Speicher einer normalen Grafikkarte passen, also maximal 32 GB, dann fährt man nach wie vor günstiger und meistens auch schneller mit einem x86-Rechner mit einer dedizierten Grafikkarte.

Aber bei Modellen wie gpt-oss-120B mit 63 GB, und meiner Meinung nach fängt das in diesen Speicherbereichen oft erst an, wirklich interessant zu werden, dann gibt es zurzeit nichts Besseres als ein Mac. Also auch in Sachen Preis-Leistung. Also zumindest, wenn man einfach was kaufen will. Klar, man kann sich irgendwelche krassen Rechner frankensteinen mit gebrauchten Grafikkarten, aber das gibt es auf jeden Fall nicht von der Stange. Zumindest nicht zu den Preisen.

Bei anderen KI-Anwendungen als LLMs, ja, also zum Beispiel bei ComfyUI, ja, da ist man auf jeden Fall immer noch mit Nvidia-Hardware besser und vor allem auch unkomplizierter bedient. Mit AMD-Hardware ist es fast noch schwieriger als mit Apple-Hardware. Aber wer weiß, wie lange das alles noch so ist.

Leider, und das muss ich auch sagen, habe ich jenseits von gpt-oss-120B, also jenseits der 63 GB, keine Sprachmodelle gefunden, die deutlich besser sind, also für die sich jetzt 128 oder sogar 512 GB lohnen würden. So Sachen wie DeepSeek und Kimi K2, die sind auf jeden Fall besser, aber die brauchen halt noch mehr als 512 GB. Da muss man dann vielleicht mal mit so Clustern rumexperimentieren. Habe ich schon auf der To-do-Liste, das kommt bald, eventuell. Aber wir wissen auf jeden Fall: In der KI-Welt kann alles sehr schnell gehen. Mal sehen, was sich da in den nächsten Monaten tut. Tschüss!

c’t 3003 ist der YouTube-Channel von c’t. Die Videos auf c’t 3003 sind eigenständige Inhalte und unabhängig von den Artikeln im c’t Magazin. Die Redakteure Jan-Keno Janssen, Lukas Rumpler, Sahin Erengil und Pascal Schewe veröffentlichen jede Woche ein Video.

(sahe)

Das Weltraumteleskop Hubble hat mutmaßlich den Zusammenprall zweier Himmelskörper im System des Sterns Fomalhaut detektiert – und das schon zum zweiten Mal in zwei Jahrzehnten. Wissenschaftler glaubten bisher, dass solche Ereignisse deutlich seltener stattfinden.

Fomalhaut ist ein Stern im Sternbild Piscis Austrinus oder Südlicher Fisch und einer der hellsten Sterne am Himmel. Der nur etwa 25 Lichtjahre entfernte Stern ist mit 440 Millionen Jahren noch vergleichsweise jung – die Sonne ist etwa 4,57 Milliarden Jahr alt. Fomalhaut gehört mit zwei Zwergsternen einem Dreifachsystem an, das von Staubringen umgeben ist, in denen Planeten entstehen.

2004 und 2006 entdeckten Astronomen ein Objekt in einem dieser Gürtel, das sie für einen Exoplaneten hielten und das sie als Fomalhaut B bezeichneten. 2023 wollten sie den Planeten erneut mit dem Hubble-Teleskop betrachten, stellten aber fest, dass er nicht dort war, wo sie ihn erwarteten.

Sie fanden aber einen Lichtpunkt an einer anderen Stelle, nahe der ersten. Beim Vergleich der Bilder habe sich jedoch gezeigt, dass die beiden Lichtpunkte nicht aus derselben Quellen stammen konnten, sagte Jason Wang von der Northwestern University. Sie haben Fomalhaut b umbenannt in Fomalhaut Circumstellar Source 1 (CS1), der zweite Lichtpunkt hat die Bezeichnung Fomalhaut CS2 bekommen.

Kollision von Planetesimalen

Die Forscher erklären das Auftreten und das Verschwinden der Lichtpunkte als Trümmerwolken, die durch die Kollision von Planetesimale, also Bausteinen von Planeten, entstanden. Aus der Helligkeit der Lichtpunkte CS1 und CS2 schlossen sie, dass die kollidierten Objekte selbst um die 60 Kilometer groß gewesen sein müssen – und damit zu klein, um selbst auf den Bildern des Weltraumteleskops sichtbar zu sein. Die sich ausbreitenden Trümmerwolken hingegen werden vom Zentralgestirn angeleuchtet.

„Eine neue Lichtquelle im Staubgürtel, um einen Stern zu entdecken, hat uns überrascht. Das hatten wir nicht erwartet“, sagte Wang. „Unsere Hypothese ist, dass wir innerhalb von zwei Jahrzehnten zwei Kollisionen von Planetesimalen – kleinen Gesteinsobjekten, ähnlich wie Asteroiden – beobachtet haben. Kollisionen von Planetesimalen sind sehr seltene Ereignisse, und das ist das erste Mal, dass wir eine außerhalb unseres Sonnensystems gesehen haben.“

Die Forscher waren zudem erstaunt, dass sie in etwa 20 Jahren gleich zwei solcher Kollisionen beobachtet haben: „Laut der Theorie sollte eine solche Kollision einmal in 100.000 Jahren oder noch seltener auftreten“, sagte Paul Kalas, Astronom an der University of California in Berkeley und Erstautor der Studie in der Fachzeitschrift Science. Die zwei Sichtungen in 20 Jahren könnten seiner Ansicht nach Zufall gewesen sein, oder die theoretischen Modelle müssten angepasst werden.

Die Forscher wollen das Fomalhaut-System künftig mit dem James-Webb-Weltraumteleskop betrachten und erhoffen sich davon neue Erkenntnisse über CS 2 sowie über die Beschaffenheit der kollidierten Planetesimalen – und möglicherweise auch, neue Kollisionen zu beobachten.

(wpl)

USB-Datenträger größer 2 TByte sind längst Realität, und solange es nur darum geht, Dateien von A nach B zu transportieren, stellen sie unter Windows kein Problem dar. Meist sind solche Laufwerke schon ab Werk einsatzbereit und das Betriebssystem erkennt sie wie alle USB-Datenträger automatisch.

Anders sieht es aus, wenn Sie von so einem großen USB-Datenträger booten wollen, beispielsweise um Windows neu zu installieren, es mit dem c’t-Notfall-Windows zu reparieren oder um eine mit c’t-WIMage erzeugte Sicherung wiederherzustellen. Wobei von „wollen“ ja eigentlich keine Rede sein kann, denn wer will so etwas schon? Eigentlich soll der PC ja ganz andere Aufgaben erledigen. In so einer Situation würde es ganz besonders nerven, wenn das Booten vom USB-Datenträger scheitert. Weil es dann meist nicht mal Fehlermeldungen gibt, beginnt das Rätselraten: Liegt es am USB-Datenträger? Am USB-Anschluss? An der BIOS-Konfiguration? Am Bootloader? An noch etwas anderem? Noch verzwickter wird es, wenn das Booten an einem PC gelingt und am anderen nicht, und das ohne ersichtlichen Grund. Wieso das denn?

Ganz verhindern lassen sich solche Probleme zwar nicht, doch die Wahrscheinlichkeit, dass sie auftreten, lässt sich deutlich reduzieren, wenn der USB-Datenträger richtig eingerichtet ist. Dazu müssen Sie den nutzbaren Platz allerdings auf 2 TByte einschränken.

Das war die Leseprobe unseres heise-Plus-Artikels „Windows: Weshalb bootende USB-Datenträger maximal 2 TByte groß sein dürfen“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.