Magnitude beschleunigt offene Modelle um bis zu 2x gegenüber llama.cpp
Launch HN: Magnitude (YC S25) – Self-optimizing inference engine for agents
Magnitude ist eine Open-Source-Inferenz-Engine für Agenten, die sich selbst auf die exakte Hardware optimiert. Sie kompiliert und tunet ihre Kernel direkt auf dem Gerät, wodurch offene Modelle bis zu 2x schneller laufen als mit llama.cpp – mit 92 % schnellerem Decode auf Metal und 19 % auf CUDA. Die Desktop-App verbindet den bevorzugten Agenten per Klick, läuft auf Apple Silicon, NVIDIA, AMD oder reiner CPU und bleibt dabei komplett lokal. Apache 2.0.
Sie liefern vorkompilierte Kernel für breite Hardware-Klassen. Magnitude kompiliert und optimiert seine Kernel auf Ihrem tatsächlichen Gerät, bevor ein Modell läuft, sodass sie zu Ihrem exakten Chip passen.
- kmike84
Wie genau sind die Geschwindigkeitsschätzungen in der UI? Ich frage, weil für Qwen 3.8 (Q8) die in der UI angegebenen Geschwindigkeitszahlen ziemlich schlecht aussehen:
Geschätzte Geschwindigkeit auf deinem Rechner
Kontext-Token Token / Sek
25 000 17
50 000 16
75 000 16
262 144 12
Die 262K-Zahl ist ok, aber bei kleineren Kontextgrößen (<128K) ist sie etwa 2x langsamer als die Zahlen, die ich aus echten mtplx-Sessions für qwen3.8 q8 (mac m5 max) bekomme.
Liegt es an fehlenden Optimierungen, an falschen Zahlen oder an einem Benchmark-Artefakt (z. B. etwas, das für Spec Decoding schwieriger ist als übliche agentische Sessions)?
- happybox2016
2x llama.cpp" auf was, einem M3 Max? Die Metal-Kernel von llama.cpp sättigen bereits die Speicherbandbreite. Der echte Agent-Engpass ist nicht Single-Stream tok/s – es ist der KV-Cache für 5+ gleichzeitige 128k-Kontexte auf 24GB VRAM. Wer betreibt tatsächlich Multi-Agent lokal? A) Nur eine Session B) 2-3 Agents C) 5+ Agents D) Aufgegeben,
- lxe
Auf meiner lokalen Inferenz-Box habe ich einen permanenten Codex-Thread in meinem llama.cpp-Checkout offen, den ich regelmäßig bitte, einen Blick auf aktuell anhängige llama.cpp-PRs zu werfen, etwas Recherche zum neuesten MTP, Dflash und anderen Prediction- oder Attention-Optimierungen zu betreiben, die neuesten Modell-Quants und Finetunes zu recherchieren, lokale llama-Reddit-Threads anzuschauen und im Wesentlichen einen Sweep der Frontier zu machen.
Dann baut es das neueste llama.cpp neu, schnappt sich die PRs, die es für relevant hält, um dagegen zu testen, und führt dann einen Benchmark durch, schließt das Upgrade ab und verifiziert, welches Modell, welche Variante oder sogar ein separates Finetune wir laufen lassen sollten.
Gelegentlich führt es seine eigenen Optimierungen durch und committet sie, die dann von Pull Requests und gemergtem Code abgelöst werden, was im Wesentlichen die Optimierungsrichtung des Modells selbst validiert.
- kmike84
Das scheint eine gute Idee zu sein. Allerdings ist llama.cpp bei der Geschwindigkeit zu schlagen eine niedrige Messlatte :)
Ich fand es eine gute Baseline, aber zumindest auf dem Mac gab es immer etwas deutlich Schnelleres und/oder mit besserem Speicherbedarf – wie du sagst, ds4, omlx, mtplx usw. Es scheint, wenn man lokale LLMs wirklich nutzt, gibt es kaum einen Grund, nicht eine der optimierteren Engines zu verwenden.
3 Hauptfehlerquellen, die ich bei den Engines beobachtet habe:
* Nicht die bestmögliche Spec Decoding verwenden
* Zu viel VRAM für den KV-Cache verwenden (z. B. nahm der KV-Cache in ds4 fast nichts ein, aber riesige Mengen VRAM bei unsloth/llama.cpp für Deepseek-Modelle)
* Verschlechterte Leistung bei großen Kontextgrößen – Benchmarks bei 4K oder 32K sind großartig, aber bei realistischen 100-200K ist es langsamer als eine blöde Baseline
- singh_abinashi
Neugierig, wie die Evals dafür auf echten Agent-Workloads im Vergleich zu synthetischen Benchmarks funktionieren. Meiner Erfahrung nach ändern sich Agent-Kosten- und Latenzprofile stark, sobald eine Tool-Use-Schleife im Spiel ist, weil die Token-Verteilung viel stoßartiger wird als bei einem einzelnen Prompt. Habt ihr auf mehrstufigen Tool-Calling-Traces evaluiert oder hauptsächlich auf Single-Turn?