Cactus: Edge-Inferenz mit Hybrid-Cloud-Ausweichroute

Welches Problem Cactus adressiert und für wen

Ein Modell auf einem Telefon auszuführen ist kein reines Kernel-Problem. Es braucht eine Quantisierung, die den Speicherbedarf senkt, ohne das Modell unbrauchbar zu machen, eine Laufzeitumgebung für ARM-Prozessoren, eine API, die Anwendungen ansprechen können, und eine Antwort auf die Frage, was passiert, wenn das lokale Modell sich seiner Sache nicht sicher ist. Cactus liefert alle vier Teile in einem Repository: Cactus Quants, Cactus Kernels, Cactus Graph und Cactus Engine. Die Zielgruppe ist entsprechend eng umrissen: Entwickler, die C oder C++ schreiben und ihre Inferenz auf iPhone, iPad, Vision Pro, Android-Geräten oder Wearables betreiben wollen. Das README nennt als Einsatzfelder Mobilgeräte, Wearables, Smart Home und Robotik. Der Stack ist auf C++ aufgebaut, mit Bindings für Swift, Kotlin, Flutter, React Native, Python und Rust. Wer eine reine Python-Erfahrung sucht, findet hier nur eine dünne Schicht über einem nativen Kern.

Der Schichtenaufbau: Engine, Graph, Kernels, Quants

Das README zeigt den Aufbau als vier übereinanderliegende Ebenen. Ganz unten sitzt Cactus Quants mit einer rotationsbasierten Quantisierungstechnik, die laut Beschreibung alle Gewichtstensoren von 4 Bit bis 1 Bit abdeckt. Darüber liegen die Cactus Kernels, CPU- und GPU-Kernels für Apple-, Samsung- und Pixel-Geräte, wobei docs/cactus_kernels.md ARM-NEON-SIMD-Kernels für Matmul, Attention, Konvolution, Quantisierung, DSP und Bildverarbeitung nennt. Die dritte Ebene ist Cactus Graph, ein laut README zero-copy Rechengraph mit Tensoroperationen. Ganz oben steht die Cactus Engine mit OpenAI-kompatiblen APIs für Text, Sprache und Vision. Der Datenfluss, den das Graph-Beispiel zeigt, ist explizit: Eingaben werden mit Precision::FP16 und Precision::INT8 deklariert, Operationen wie graph.matmul und graph.transpose darauf angewendet, dann folgt set_input, execute und get_output. Nach der Ausführung steht graph.hard_reset() im Beispiel, was darauf hindeutet, dass der Graph selbst keinen automatischen Speicherverwaltungszyklus mitbringt. Wer diese Ebene direkt nutzt, verwaltet den Lebenszyklus selbst.

Installation und der erste Lauf

Der kürzeste Weg führt über Homebrew auf dem Mac. Das README nennt zwei Schritte: brew install cactus-compute/cactus/cactus, danach cactus run. Ohne Argument lädt beziehungsweise konvertiert cactus run ein Modell, falls es nicht gefunden wird. Wer ein konkretes Modell will, gibt den HuggingFace-Namen mit: cactus run Cactus-Compute/needle. Für Modelle, die nicht vorab auf HuggingFace unter Cactus-Compute liegen, sieht die Dokumentation cactus convert [HF-Name] vor, bezeichnet diesen Weg aber selbst als experimentell. cactus download [HF-Name] lädt vorbereitete Modelle. Für Messungen gibt es cactus benchmark, optional mit --ios oder --android. Auf der C-Ebene beginnt die Integration mit #include "cactus_engine.h" und einem Aufruf von cactus_init, der einen Pfad zum Gewichtsordner und einen Pfad zu Textdateien für automatisches RAG entgegennimmt. Der dritte Parameter ist ein boolescher Wert. Die Generierung läuft über cactus_complete mit JSON-Nachrichten, einem Antwortpuffer, Options-JSON und mehreren nullptr-Parametern für Tools, Streaming-Callback, Nutzerdaten und PCM-Audiopuffer. Die Options im Beispiel sind max_tokens und stop_sequences.

Was die Qualitätstabellen über CQ2 verraten

Die interessanteste Stelle der Dokumentation ist die Tabelle zur Genauigkeit von Gemma-4-E2B-it über verschiedene Bitbreiten, gemittelt über drei Seeds. CQ4 liegt bei den meisten Aufgaben auf oder über dem F16-Ausgangswert: HumanEval steigt von 54.88 auf 57.11, BFCL Parallel-Multi von 78.00 auf 83.33, ARC-E bleibt praktisch gleich. CQ3.26 ist gemischtpräzise und hält sich bei MMLU mit 57.63 gegenüber 62.33 noch im Rahmen, fällt bei GSM8K aber auf 66.20. Der Bruch kommt bei CQ2.54: GSM8K stürzt auf 22.00, HumanEval auf 15.24, BFCL Parallel auf 30.00. Bei uniformem CQ2 ist das Modell für diese Aufgaben praktisch unbrauchbar, GSM8K liegt bei 0.40 und HumanEval bei 1.02. Das ist keine Nebenbemerkung, sondern die zentrale Einschränkung des Projekts. Wer CQ2 wegen des Speicherplatzes wählt, bekommt bei strukturierten Aufgaben kaum noch verwertbare Ausgaben. Die Tabelle selbst weist außerdem darauf hin, dass CQ3.26 und CQ2.54 mixed-precision sind, während CQ2, CQ3 und CQ4 uniform quantisiert werden.

Hybrid-Routing und die Confidence-Schwelle

Cactus Hybrid ist der Teil, der die Edge-Entscheidung nicht dogmatisch behandelt. Laut README werden schwierige Anfragen automatisch an die Cloud geroutet, sobald die Konfidenz des lokalen Modells unter einen Schwellwert fällt. Die Beispielantwort der Engine macht das konkret: Sie enthält die Felder confidence mit 0.8193 und confidence_threshold mit 0.7, dazu cloud_handoff als booleschen Wert. Der Schwellwert ist modellabhängig, wie der Kommentar im Beispiel vermerkt. Die Antwort liefert außerdem time_to_first_token_ms, total_time_ms, prefill_tps, decode_tps, ram_usage_mb sowie Token-Zähler für Prefill, Decode und Gesamt. Das ist für den Betrieb nützlich, weil sich damit nachvollziehen lässt, wie oft das lokale Modell tatsächlich übernimmt. Der Widerspruch, den man aushalten muss: Das Projekt positioniert sich als On-Device-Engine, liefert aber gleichzeitig einen Mechanismus, der Anfragen an die Cloud abgibt. Wer ausschließlich offline arbeiten will oder muss, deaktiviert dieses Verhalten, verliert damit aber die Fälle, in denen das kleine Modell überfordert ist.

Die Benchmark-Zahlen und ihre Grenzen

Das README listet Inferenzgeschwindigkeiten für sechs Geräte, gemessen mit Gemma-4-E2B-CQ4 bei 1k-Kontext-Prefill und Decode über 100 Token, ohne spekulative Dekodierung oder MTP. Auf einem Mac M5 Max stehen 2964tps Prefill und 154tps Decode, auf einem iPhone 15 Pro 517tps und 26tps. Für Vision nennt die Tabelle Bildkodierungszeiten von 0.09s auf dem M5 Max bis 1.15s auf dem iPhone 15 Pro, für Transkription 0.15s bis 0.82s bei 20 Sekunden Audio. Diese Zahlen stammen aus dem Repository und wurden hier nicht nachgemessen. Auffällig ist, dass die Mac-Werte die Mobilwerte um den Faktor vier bis sechs beim Decode übertreffen, während der RAM-Bedarf über die Geräteklassen hinweg zwischen 633MB und 1348MB liegt. Für ein Telefon mit 6GB oder 8GB Arbeitsspeicher bleibt nach einem 1k-Kontext-Modell also nicht mehr viel übrig, und das ist der eigentliche Engpass, nicht die Tokenrate. Die zusätzlichen Einzelwerte für LFM2.5-VL-1.6B, Qwen3-1.7B und die kleineren LFM-Varianten zeigen, dass die Tokenrate stark vom gewählten Modell abhängt.

Needle und die Modellabdeckung

Neben dem allgemeinen Stack pflegt das Projekt mit Needle ein eigenes Modell: 26 Millionen Parameter, zugeschnitten auf Tool-Calling auf dem Gerät. Der Aufruf lautet cactus run Cactus-Compute/needle mit optionalem --tools my_tools.json im OpenAI-Function-Calling-Format, standardmäßig mit einem Demo-Toolset. Das ist ein sinnvoller Zuschnitt, weil Funktionsaufrufe mit kleinen Modellen oft scheitern, bevor die Generierungsqualität überhaupt relevant wird. Bei der allgemeinen Modellabdeckung ist die Dokumentation dagegen zurückhaltend: Jedes HuggingFace-Modell lasse sich mit cactus convert konvertieren, allerdings experimentell. Besonders getestet seien Liquid, Gemma, Whisper, Parakeet und Qwen. Diese Formulierung ist ehrlich, sollte aber als Warnung gelesen werden. Wer ein Modell außerhalb dieser Familien einsetzt, betreibt die Konvertierung auf eigenes Risiko und hat keine Zusicherung, dass die Quantisierung die Ausgabequalität hält. Eine Alternative wie llama.cpp hat hier den Vorteil einer deutlich breiteren Gemeinschaft, die GGUF-Konvertierungen und Quantisierungsvarianten für viele Architekturen bereits erprobt hat.

Lizenz, Wartung und was vor der Integration zu prüfen ist

Die Lizenzangabe des Repositories lautet NOASSERTION. Das bedeutet, dass die automatische Erkennung keine eindeutige Standardlizenz identifizieren konnte. Wer Cactus kommerziell einsetzen will, muss das LICENSE-File im Repository selbst lesen und gegebenenfalls rechtlichen Rat einholen. Aus der Repository-Beschreibung lässt sich dazu nichts ableiten, und eine Vermutung wäre hier fehl am Platz. Zur Wartung: Die letzten drei Releases v2.0.1, v2.1.0 und v2.2.0 liegen zwischen Juli und September 2026, mit Abständen von etwa einem Monat. Das deutet auf aktive Entwicklung hin, sagt aber nichts über die Stabilität der API zwischen den Versionen. Die Engine-Signatur von cactus_complete mit neun Parametern, von denen mehrere im Beispiel nullptr sind, ist ein Kandidat für Breaking Changes, wenn neue Fähigkeiten wie Audio oder Tools hinzukommen. Wer Cactus einbettet, sollte die C-API hinter einer eigenen schmalen Abstraktion kapseln, statt cactus_engine.h direkt durch die Anwendung zu reichen. Das ist keine allgemeine Empfehlung, sondern folgt aus der Parameterliste dieses konkreten Funktionssignatur.

Redaktionelles Fazit

Für Teams, die Text, Sprache und Vision auf iPhone, iPad oder Android ohne Cloud-Zwang betreiben wollen und C oder C++ nicht scheuen, ist Cactus einen Integrationsversuch wert, sofern die Lizenzfrage vorher geklärt ist. Wer eine stabile, breit getestete Modellabdeckung braucht oder auf CQ2 und CQ3.26 angewiesen ist, sollte Abstand nehmen: GSM8K fällt dort von 73.67 auf 0.40 beziehungsweise 66.20. Prüfe zuerst das LICENSE-File im Repository, dann die Werte in docs/cactus_quants.md für das eigene Zielmodell und erst danach die eigene Pipeline.

Offizielle Quellen

1. cactus-compute/cactus on GitHub
2. Issues
3. Project website
4. README
5. Releases