Lokale und hybride Inferenz

Nicht jeder Prompt braucht ein Frontier-Modell im Rechenzentrum eines anderen. Bromure Agentic Coding kann Open-Weight-Coding-Modelle direkt auf der GPU deines Macs mit Apples MLX-Framework ausführen — kein Cloud-Umweg, keine Abrechnung pro Token und kein Code, der die Maschine verlässt. Ein Arbeitsbereich kann vollständig auf dem Gerät laufen, weiterhin die Cloud mit einem Sicherheitsnetz auf dem Gerät nutzen oder die beiden Agent für Agent mischen.

Lokale Inferenz ist eine Entscheidung pro Arbeitsbereich, orthogonal zu Fusion: Fusion entscheidet, wie viele Modelle einen Prompt beantworten, während das Routing entscheidet, welches Backend ihn beantwortet. Dieses Kapitel erklärt, wo die Inferenz läuft, wie der Modellkatalog und die Downloads funktionieren, die drei Routing-Modi und die hybride Policy-Engine, wie du einen einzelnen Agenten auf ein lokales Modell verweist und wie du das Verhalten der Engine beobachtest. Die feldweise Einstellungsreferenz für den Bereich findest du unter Lokale Modelle – Einstellungen.

Hinweis: Alles hier läuft auf dem Mac-Host, nicht innerhalb der VM. Virtualization.framework gibt dem Linux-Gast keinen Zugriff auf GPU, Metal oder MLX, sodass die Inferenz auf dem Gerät auf macOS stattfinden und vom Gast über die Übertragungsgrenze erreicht werden muss. Apple Silicon (M1 oder neuer) ist erforderlich — dieselbe Voraussetzung wie für die App selbst.

Wo die Inferenz läuft

Die Engine ist in die App integriert; es gibt nichts zu installieren, keine Python-Umgebung und keinen externen Server wie Ollama, LM Studio oder eine selbst gehostete vLLM-Instanz, auf die man verweisen müsste. Wenn eine Sitzung Inferenz auf dem Gerät benötigt, startet die App eine private MLX-Engine und verdrahtet den Gast-Agenten damit.

Der Engine-Kindprozess

Die MLX-Engine läuft als überwachter Kindprozess des eigenen Binärprogramms der App (bromure-cli model _mlx-engine), nicht innerhalb der App selbst. Dies ist eine bewusste Isolierung: Das Laden eines Modells, das für den Speicher des Macs zu groß ist, beendet nur den Engine-Kindprozess, niemals die App oder ihre laufenden VMs. Der Elternprozess startet eine abgestürzte Engine automatisch neu, bis zu dreimal; danach gibt er mit der Log-Zeile engine child crashed repeatedly — giving up (a model likely OOMs this Mac) auf. Der Kindprozess wird beendet, wenn die App beendet wird, und jeder durch einen harten Absturz hinterlassene Waise wird beim nächsten Start eingesammelt.

Eine Engine bedient jeden geöffneten Arbeitsbereich. Sie bindet einen vom Kernel zugewiesenen Loopback-Port an 127.0.0.1 — niemals 0.0.0.0 und niemals den herkömmlichen 11434 (dieser Port bleibt frei, sodass eine separate Ollama- oder LM-Studio-Installation weiterhin funktioniert). Sie lädt mehrere Modelle parallel innerhalb eines Speicherbudgets, das dem vereinheitlichten Speicher des Hosts minus 16 GB entspricht (mit einer Untergrenze von 8 GB), lädt jedes Modell bei der ersten Nutzung verzögert und verdrängt das am längsten nicht genutzte, wenn das Budget knapp wird. Das Öffnen oder Schließen eines Arbeitsbereichs konfiguriert die laufende Engine live über einen Admin-Endpunkt neu — ohne Neustart.

Während die Engine aufwärmt, zeigen die Sitzungsfenster eine Status-Pille mit der Aufschrift Lokale Engine wird gestartet… an, die verschwindet, sobald die Engine auf eine Bereitschaftsprüfung antwortet.

Wie der Gast die Engine erreicht

Agenten in der VM sprechen niemals direkt mit der Engine. Sie zielen auf den synthetischen Host https://bromure.llm — ein Name ohne echtes DNS —, und der hostseitige MITM-Proxy fängt ihn ab, wendet dasselbe Prompt-Injection-Scanning und dieselbe Trace-Erfassung an, die er auf den Cloud-Verkehr anwendet, und leitet die Anfrage an die Engine auf dem Host weiter. Lokale Inferenz ist daher niemals ein blinder Fleck: Sie überquert dieselbe Übertragungsgrenze und landet im selben Audit-Trail wie ein Aufruf an Anthropic.

Agenten sind auf einen Sentinel-Modellnamen bromure-local fixiert, den der Host auf das derzeit aktive Modell des Arbeitsbereichs umleitet. Das Umschalten des aktiven Modells ist eine hostseitige Umleitung ohne Agenten-Neustart — der Agent fragt weiterhin nach bromure-local und bekommt einfach ein anderes Modell dahinter.

Hinweis: Ein Modell, dessen Architektur die MLX-Engine noch nicht unterstützt, scheitert mit einem klaren, permanenten Fehler — „its architecture … isn't supported by the on-device engine yet — pick a different model“ —, der als Client-Fehler zurückgegeben wird, sodass der Agent es nicht in einer Schleife erneut versucht.

Der Modellkatalog

Der Katalog ist eine kuratierte Liste vorkonvertierter MLX-Modelle, jedes geprüft auf das eine, was beim agentischen Coding am wichtigsten ist: Quantisierte Modelle brechen häufig beim Tool-Calling, daher trägt jeder Katalogeintrag ein Abzeichen für die Tool-Calling-Verifizierung. Einträge erfassen außerdem eine Downloadgröße und eine Mindestanforderung an den vereinheitlichten Speicher, die der Bereich in ein RAM-Eignungs-Gate umsetzt.

Ein Basiskatalog wird mit der App ausgeliefert, sodass der Bereich am ersten Tag offline funktioniert. Beim Start ruft die App einen aktualisierten Katalog von https://dl.bromure.io/mlx/catalog.json ab; ein neueres Manifest ersetzt den Basiskatalog vollständig (es wird nicht zusammengeführt). Ein aus dem veröffentlichten Katalog entferntes Modell verschwindet aus der Liste — es sei denn, du hast es bereits installiert, in welchem Fall es als installierter Zusatz erhalten bleibt.

Modelle, die im Basiskatalog ausgeliefert werden

Der gebündelte Katalog ist ein Satz von Qwen3-Coding-Modellen über verschiedene Speicherstufen hinweg. Alle vier sind Tool-Calling-verifiziert:

Das Modell mit 8 Milliarden Parametern läuft auf jedem unterstützten Mac; das Mixture-of-Experts-Modell mit 480 Milliarden Parametern benötigt eine 512-GB-Maschine (einen M3 Ultra) und ist aus diesem Grund nicht als empfohlen markiert. Ein aktualisierter Katalog kann ohne App-Update neuere oder größere Builds hinzufügen.

Abzeichen und das RAM-Eignungs-Gate

Jede Zeile im Bereich (und jede Zeile von bromure-cli model catalog) trägt zwei Abzeichen:

• Eine Größenstufe — S für Modelle, die 16 GB oder weniger benötigen, M bis 32 GB, L bis 64 GB, XL darüber.
• Ein Eignungsurteil gegenüber dem vereinheitlichten Speicher deines Macs: Passt, Knapp oder Passt nicht. „Passt“ erfordert das Minimum des Modells plus 16 GB Spielraum für das Betriebssystem und alles andere; „Knapp“ bedeutet, dass es mit wenig Reserve lädt; „Passt nicht“ bedeutet, dass das Minimum des Modells deinen Speicher übersteigt. Passt-nicht-Zeilen sind ausgegraut und können nicht ausgewählt oder heruntergeladen werden.

Zum Beispiel liest sich das Qwen3-8B-Modell (16 GB Minimum) auf einem 16-GB-Mac als Knapp und auf 32 GB oder mehr als Passt; Qwen3-Coder 30B-A3B (32 GB Minimum) liest sich ab 48 GB als Passt.

Ein Modell außerhalb des Katalogs verwenden

Der Katalog ist ein kuratiertes Menü, kein Zaun. Jedes Hugging-Face-Repository, das bereits im MLX-Format vorliegt, kann über seinen org/repo-Namen von der Kommandozeile geholt werden (siehe Kommandozeilenreferenz); ein solches Modell wird als ungetestet behandelt — es trägt keine Tool-Calling-Garantie und keine RAM-Eignungs-Zusicherung. Repositories im GGUF-Format werden rundweg abgelehnt, weil GGUF der Weg für Ollama und llama.cpp ist, nicht für MLX:

That's a GGUF (Ollama/llama.cpp) model — Bromure serves MLX weights only.

Modelle herunterladen und speichern

Die Gewichte werden direkt von huggingface.co durch einen eingebauten, reinen Swift-Downloader geholt — kein Python, kein mlx_lm.convert, keinerlei Konvertierung. Der Downloader liest die Dateiliste des Repositorys aus der Hugging-Face-API, streamt jede Gewichtsdatei in eine temporäre .partial-Datei und benennt sie atomar an ihren Platz um; Dokumentation, Bilder und etwaige GGUF-Dateien im Repository werden übersprungen. Bevor er startet, scheitert eine Speicherplatz-Vorabprüfung schnell, statt deine Festplatte zu füllen:

Not enough disk space: 40 GB free, but about 270 GB is needed.

Wo Modelle liegen

Heruntergeladene Gewichte landen in einem flachen Layout pro Repository unter deinem Application-Support-Verzeichnis:

~/Library/Application Support/BromureAC/models/<org>--<name>/

Jedes Verzeichnis enthält die config.json des Modells, seine .safetensors-Shards und seinen Tokenizer. Downloads sind ein globaler Seiteneffekt, geteilt über jeden Arbeitsbereich — ein Modell einmal zu holen, macht es allen verfügbar. Modelle, die zuvor von anderen Werkzeugen in ~/.cache/huggingface/hub zwischengespeichert wurden, werden einmalig per Hardlinks in dieses Verzeichnis migriert, sodass nichts zweimal heruntergeladen wird.

Download-Zustände im Bereich

Das Aktionselement in jeder Modellzeile spiegelt ihren Zustand wider:

Da der Downloader auf Dateiebene fortsetzbar ist, muss ein unterbrochener Holvorgang niemals von vorn beginnen, und ein Teildownload wird niemals mit einer funktionierenden Installation verwechselt — eine Sentinel-Datei während des Vorgangs markiert ihn, bis das letzte Byte gelandet ist.

Tipp: Das erste Modell, das du herunterlädst, wird automatisch als aktives Modell des Arbeitsbereichs festgelegt, sodass ein frischer Arbeitsbereich mit einem Klick von „kein lokales Modell“ zu „bereit zum Bedienen“ übergeht.

Lokale Modelle für einen Arbeitsbereich aktivieren

Öffne den Arbeitsbereich im Arbeitsbereich-Browser, klicke auf Arbeitsbereich bearbeiten und wähle den Bereich Lokale Modelle (das mintfarbene CPU-Symbol). Der Bereich beginnt als einzelner Schalter; die Modus-Auswahl und die Modellliste erscheinen erst, sobald die lokale Inferenz eingeschaltet ist.

1. Schalte Lokale Modelle aktivieren ein („Ein Coding-Modell auf diesem Mac statt in der Cloud ausführen.“). Dies stellt das Routing des Arbeitsbereichs von Cloud weg; das erneute Ausschalten stellt Cloud wieder her.
2. Wähle einen Modus:
   • Lokal — immer auf dem Gerät hält jede Anfrage auf diesem Mac. Wie der Bereich anmerkt, sind die Antworten privat, aber langsamer und durch das Modell begrenzt, das du in den Speicher bekommst.
   • Hybrid — Cloud, Rückfall auf lokal sendet Anfragen wie üblich an die Cloud und fällt nur dann auf das Modell auf dem Gerät zurück, wenn die Cloud nicht erreichbar ist — Cloud-Geschwindigkeit und -Qualität mit einem lokalen Sicherheitsnetz.
3. In der Modellliste — überschrieben mit Modelle · N GB vereinheitlichter Speicher, wobei N der Speicher deines Macs ist — Herunterladen eines Modells und dann Auswahl als aktiv mit dem Radiopunkt links davon. Ausgegraute Zeilen benötigen mehr Speicher, als dein Mac hat.
4. Klicke auf Sichern.

Der Routing-Modus und die Auswahl des aktiven Modells bleiben beim Sichern bestehen; Downloads geschehen, da sie global sind, sofort, ob du sicherst oder nicht. Wenn die Modelle, die du auswählst, zusammen nahe an oder mehr als den Speicher deines Macs benötigen würden — die Engine bedient sie parallel, sodass sich ihr Speicher summiert —, zeigt der Bereich eine Warnung und bittet dich, eines wegzulassen oder kleinere Modelle zu wählen.

Die vollständige Feldliste und die Standardwerte findest du unter Lokale Modelle – Einstellungen.

Routing: Cloud, Lokal und Hybrid

Routing ist die übergeordnete Entscheidung pro Arbeitsbereich, welches Backend den LLM-Verkehr eines Agenten bedient. Es hat drei Werte:

Die Auswahl von Lokal oder Hybrid aktiviert automatisch den MITM-Abfangpfad — du legst dafür niemals einen separaten Schalter um. Jeder beantwortete Zug wird im Trace mit einem Served-by-Marker versehen, der aufzeichnet, welches Backend geantwortet hat: cloud oder local-<model>. Du kannst ihn im Trace-Inspektor lesen, um Zug für Zug zu bestätigen, wohin eine hybride Sitzung tatsächlich gegangen ist.

Routing ist ein Standard pro Arbeitsbereich, der im Bereich festgelegt wird, aber es kann auch auf einer laufenden VM von der Kommandozeile mit bromure-cli vm routing geändert werden (siehe Kommandozeilenreferenz).

Hinweis: Lokales Routing leitet den Verkehr eines Agenten zu Anthropic- und OpenAI-Hosts (und dem bromure.llm-Sentinel) an die Engine um. Es kapert keinen Agenten, der selbst bereits auf echte Cloud-Zugangsdaten fixiert ist — etwa behält ein Abonnement-Claude-Agent, der sich einen Arbeitsbereich teilt, seinen echten Cloud-Verkehr. Um einen bestimmten Agenten unabhängig vom Arbeitsbereich-Routing lokal zu erzwingen, verwende dessen eigenen Auth-Modus Lokales Modell, siehe unten.

Die hybride Rückfall-Richtlinie

Hybrid ist kein einzelner Schalter, sondern eine kleine Policy-Engine, die darauf abgestimmt ist, eine Coding-Trajektorie niemals durch einen Modellwechsel während des Flugs zu unterbrechen. Jede Entscheidung wird an einer Sitzungsgrenze getroffen und ist dann klebrig — sobald eine Konversation an ein Backend geleitet wird, bleibt sie dort für den Rest dieser Sitzung (der Kohärenzschutz).

Was einen Rückfall auf lokal auslöst

Für eine neue Sitzung gewinnt die erste Regel, die zutrifft, in dieser Reihenfolge: eine bereits fixierte klebrige Sitzung, ein erschöpftes Cloud-Token-Budget, eine ungesunde Cloud (das Gesundheits-Gate), eine Split-Verhältnis-Zuweisung und andernfalls die Cloud. Während einer Anfrage, die bereits zur Cloud unterwegs ist, erzwingen zwei Dinge eine sofortige Wiederholung auf dem lokalen Modell und fixieren die Sitzung für ihre Lebensdauer lokal:

• Harte Fehler — eine verweigerte oder abgelaufene Verbindung oder ein HTTP 429, 529 oder 5xx vom Anbieter.
• Eine verpasste weiche Frist — kein erstes Token innerhalb des TTFT-Budgets (standardmäßig 5 Sekunden).

Darunter liegt ein konservatives Gesundheits-Gate: Die Cloud wird nach mindestens drei Fehlern in den letzten etwa zehn Anfragen als ungesund markiert oder wenn der exponentiell gewichtete gleitende Durchschnitt der TTFT über 8 Sekunden steigt, und sie erholt sich erst nach drei sauberen, schnellen Prüfungen. Während die Cloud ungesund ist, gehen neue Sitzungen direkt lokal, ohne dass jede zuerst die Strafe des weichen Timeouts zahlt. Die Backends werden niemals gegeneinander gerennt — es gibt kein spekulatives Hedging und keine doppelten Ausgaben; der Rückfall feuert erst nach einem echten Auslöser.

Die einstellbaren Stellschrauben

Drei Stellschrauben werden freigelegt, und nur über die Kommandozeile gegen eine laufende VM (siehe Kommandozeilenreferenz). Sie bleiben pro Arbeitsbereich bestehen, werden aber ignoriert, es sei denn, das Routing ist Hybrid:

Die Interna des Gesundheits-Gates (die 8-Sekunden-EWMA-Schwelle, das Fehlerfenster und die Anzahl der Erholungsprüfungen) sind fest und nicht vom Benutzer einstellbar.

Lokale Modelle als Agenten-Backend

Routing ist eine arbeitsbereichweite Achse, aber du kannst auch einen einzelnen Agenten auf die lokale Engine verweisen und den Rest des Arbeitsbereichs in der Cloud belassen. Im Agenten-Tab des Arbeitsbereichs hat jeder Agent — Claude Code, Codex oder Grok — eine Auth-Modus-Auswahl, deren Optionen Lokales Modell umfassen. Wähle es, wähle ein installiertes Modell, und dieser Agent läuft vollständig gegen die Engine auf dem Gerät mit Dummy-Cloud-Schlüsseln, die die Engine ignoriert; das MITM wendet dieselben Schutzmaßnahmen an wie auf den Cloud-Verkehr.

Dies macht gemischte Arbeitsbereiche möglich — zum Beispiel Claude Code auf einem Abonnement neben Codex auf einem lokalen Modell. Profilweites lokales Routing kapert niemals den echten Verkehr eines Cloud-Agenten, und der Lokal-Modus pro Agent sickert niemals zu den anderen durch. Wenn du die lokale Inferenz im Bereich Lokale Modelle ein- oder ausschaltest, hält die App den Auth-Modus jedes Agenten automatisch im Gleichschritt.

Lokale Modelle in Fusion

Ein lokales Modell ist auch ein gültiger Teilnehmer in Fusion, der Multi-Modell-Synthese-Funktion, und es kann dort eine von zwei Rollen spielen:

• Als Bein. Setze unter Zu fusionierende Modelle ein Häkchen bei Lokales Modell und wähle ein installiertes Modell; seine Entwurfsantwort tritt dem Panel neben Claude, Codex und Grok bei. Da es auf deinem Mac läuft, ist es ein leistungsfähiges Extra-Bein zu null marginalen Kosten.
• Als Judge. Wähle Lokal als Fusion-Judge-Anbieter, um die Analyse- und Synthesestufe vollständig auf dem Gerät auszuführen und den gesamten Bewertungsschritt aus der Cloud herauszuhalten.

Beide Rollen benötigen mindestens ein heruntergeladenes lokales Modell; bis dahin sind die entsprechenden Zeilen im Fusion-Bereich ausgegraut mit einem Hinweis, hier zuerst eines herunterzuladen. Siehe Fusion für den vollständigen Panel-Workflow.

Tool-Call-Reparatur

Der dominierende Fehlermodus quantisierter Modelle im agentischen Einsatz besteht darin, einen Tool-Call als reinen Text auszugeben, statt als strukturierten Aufruf, den der Agent ausführen kann. Ein Reparatur-Proxy sitzt vor der Engine — der Gast und die lokale MITM-Route zeigen beide auf ihn, nicht auf die nackte Engine — und rettet diese Fälle transparent.

Für jede Antwort puffert er die Ausgabe und re-parst die vielen ad-hoc-Formen, in denen ein Modell einen Aufruf durchsickern lassen könnte, darunter:

<function name="write_file" arguments='{…}'>
<tool_call>{…}</tool_call>
[{"name": "…", "parameters": {…}}]

sowie Qwen3-Coders natives <function=Name><parameter=k>v</parameter></function>-Format und Gemmas Kanalformat. Er synthetisiert korrekte Tool-Use-Blöcke aus dem, was er findet, und gibt die Nachricht erneut als protokollkorrektes SSE in der nativen Wire-Form des Agenten aus. Er erkennt außerdem eine festgefahrene Präambel — bei der das Modell eine Aktion erzählt („Now I'll create the file:“) und dann seinen Zug beendet, ohne das Tool jemals aufzurufen — und fragt bis zu zweimal erneut, um den fehlenden Aufruf wiederherzustellen. Eine Tool-Format-Erinnerung wird an den System-Prompt angehängt, wann immer Tools deklariert werden.

Die Reparatur ist für die lokale Inferenz immer eingeschaltet und benötigt keine Konfiguration. Engine-Probleme werden in wire-native Fehlerkörper umgewandelt, sodass der Agent den echten Grund statt eines generischen Fehlers anzeigt, zum Beispiel:

Local inference engine unreachable (starting up, reloading a model, or stopped) — retry in a moment.

Die Engine überwachen

Zwei Fenster im Menü Window lassen dich die Inferenz auf dem Gerät beobachten, ohne Console.app zu öffnen.

Inferenz-Metriken

Window → Inference Metrics… öffnet ein Live-Telemetrie-Panel (Fenstertitel Inference Metrics), überschrieben mit der Bezeichnung Local inference und der Loopback-Adresse der Engine. Es parst die Prometheus-Metriken der Engine in Karten — Decode tok/s, Prefill tok/s, Running, Waiting, In flight, Avg latency, Cache hit, Metal mem, Gen tokens und Prompt tokens — plus eine Loaded models-Liste und eine All metrics-Aufklappung mit der Rohtabelle.

Das Fenster fragt alle 5 Sekunden ab, und nur solange es geöffnet ist. Decode- und Prefill-Raten sind absichtlich kumulative Lebensdauerverhältnisse, sodass sie sich als stabile Durchschnitte lesen und nicht als sprunghafte Deltas pro Sekunde. Wenn die Engine ausgefallen ist, zeigt das Panel engine not reachable, und während einer langen Generierung kann es kurz engine busy (timed out) anzeigen.

Inferenz-Engine-Log

Window → Inference Engine Log… öffnet ein Live-Tail (Fenstertitel Inference Engine Log) der Ausgabe des Engine-Kindprozesses plus der Lebenszyklus-Ereignisse des Elternprozesses — Modell-Ladevorgänge, „serving“, Statistiken pro Anfrage und jeden OOM-, Absturz-, Neustart- oder Ladefehler. Zeilen sind farbcodiert (rot für Fehler, grün für gesunde Ereignisse, orange für Warnungen, blau für laufende Arbeiten). Die Werkzeugleiste bietet ein Filter…-Feld, ein Auto-scroll-Kontrollkästchen, Copy und Clear; wenn noch nichts geschehen ist, liest es sich als No inference-engine activity yet. Der Puffer ist ein speicherinterner Ring, begrenzt auf 5.000 Zeilen, und jede Zeile wird auch auf die stderr der App gespiegelt, sodass der Start von bromure-cli aus einem Terminal dir eine dauerhafte Kopie gibt.

Kommandozeilenreferenz

Die Modell- und Routing-Befehle sprechen mit der Steuerungs-API der laufenden App, sodass die App (oder ihr Agent) laufen muss. Die Befehle, die auf eine bestimmte VM wirken, nehmen ein abschließendes <vm>-Argument, das eine VM-ID oder ein Arbeitsbereichsname ist. Persistente Standardwerte pro Arbeitsbereich werden in den oben beschriebenen GUI-Bereichen bearbeitet; diese Befehle wirken auf eine Live-Sitzung. Siehe Automatisierung und CLI für den umgebenden Befehlssatz.

Modellverwaltung:

bromure-cli model catalog [--all] [--offline]
bromure-cli model pull <catalog-id | org/repo>
bromure-cli model ls
bromure-cli model use <catalog-id | org/repo> <vm>
bromure-cli model rm <catalog-id | org/repo>

Routing- und Hybrid-Richtlinie für eine laufende VM:

bromure-cli vm routing cloud|local|hybrid <vm>
bromure-cli vm hybrid budget <tokens> <vm>
bromure-cli vm hybrid ttft <seconds> <vm>
bromure-cli vm hybrid split <0-100> <vm>
bromure-cli vm fusion enable|disable <vm>

vm routing legt den Backend-Modus fest; die drei vm hybrid-Stellschrauben stimmen die Rückfall-Richtlinie ab (und greifen nur, wenn das Routing Hybrid ist). vm fusion aktiviert das orthogonale Multi-Modell-Panel und ist in Fusion dokumentiert.

Interne Diagnosebefehle

Diese versteckten Unterbefehle existieren für Entwicklung und Fehlerbehebung und sind nicht Teil des alltäglichen Workflows. Der Engine-Kindprozess selbst wird von der App als bromure-cli model _mlx-engine --config <path> gestartet.

Befehl	Zweck
bromure-cli model _mlx-serve <repo>	Startet den In-Process-MLX-Server für ein Modell und blockiert, gibt seinen Port und Schlüssel für curl-Tests aus.
bromure-cli model _mlx-selftest <repo>	Lädt ein Modell, generiert einmal und gibt TTFT und Decode tok/s aus.
bromure-cli model _repair-serve --engine-port <port>	Führt den Tool-Call-Reparatur-Proxy eigenständig gegen eine laufende Engine aus.
bromure-cli model _tc-test <path>	Führt die Tool-Call-Rettung an einer gespeicherten Textdatei aus, um die Extraktion durchgesickerter Aufrufe zu prüfen.
bromure-cli model _spec-bench <main-repo> --draft <draft-repo>	Benchmarkt spekulatives Decodieren aus versus ein für ein Modellpaar.

Leistungserwartungen

Inferenz auf dem Gerät tauscht Geschwindigkeit gegen Datenschutz und Kosten, und der Tausch ist real — setze die Erwartungen entsprechend:

• Der Durchsatz skaliert mit dem Modell und dem Chip. Ein kleines Modell wie Qwen3 8B ist auf jedem unterstützten Mac flott; die großen Mixture-of-Experts-Builds sind langsamer und benötigen weit mehr Speicher. Das Fenster Inference Metrics zeigt die tatsächlichen Decode- und Prefill-Raten auf deiner Hardware — die ehrliche Zahl, mit der du planen solltest.
• Die erste Anfrage bezahlt für ein Modell-Laden. Eine kalte Engine zeigt Lokale Engine wird gestartet…, während sie aufwärmt; große Gewichte brauchen echte Zeit, um in den Speicher zu laden, bevor das erste Token erscheint. Nachfolgende Anfragen überspringen dies.
• Mehrzügige Agenten-Schleifen werden nach dem ersten Zug billiger. Die Engine hält einen Präfix-KV-Cache pro Konversation (bis zu vier Sitzungsslots pro Modell), sodass jeder Agenten-Zug nur die neuen Tokens vorlädt, statt das gesamte Transkript — und eine Nebenkette verdrängt nicht den Cache der Hauptkonversation.
• Die Generierung ist serialisiert. Die Engine führt eine Generierung nach der anderen aus, sodass sich mehrere ausgelastete Sitzungen die GPU teilen, statt wirklich parallel zu laufen.
• Reasoning-Modelle denken stumm. Bei Modellen, die einen <think>-Block ausgeben, wird der Block immer entfernt, bevor die Antwort den Agenten erreicht — du erhältst die Qualität ohne die Transkript-Aufblähung.

Tipp: Wenn ein lokales Modell sich langsam anfühlt oder stockt, öffne zuerst das Fenster Inference Engine Log: Modell-Ladevorgänge, Verdrängungen, OOM-Neustarts und Fehler wegen nicht unterstützter Architektur tauchen dort alle im Klartext auf, was schneller ist als vom Agenten aus zu raten.