Es gibt einen Fehlermodus in Retrieval-augmentierten Systemen, den niemand in die Demo packt. Man stellt eine Frage, das System bettet sie ein, holt die zehn besten Chunks, stopft sie in einen Prompt, und das Modell schreibt eine flüssige Antwort, die auf genau jenen zehn Chunks aufbaut, die zufällig am höchsten bewertet wurden.
Wenn die Antwort einen elften Chunk gebraucht hätte, erfährt man es nicht. Man bekommt so oder so denselben selbstbewussten Absatz.
Die Lösung ist kein besserer Embedder. Sie besteht darin, etwas noch einmal nachsehen zu lassen — und genau das tut das RLM.
Zwei Komponenten, klar getrennt
Der Sidecar ist ein Flotten-Agent. Er läuft dort, wo die Rechenleistung ist, meldet, was er hat, und bedient Inferenzanfragen. Der Fantom MCP Server registriert sich als einer der Master, an die ein Sidecar berichtet.
Das RLM ist ein Retrieval-Sprachmodell — ein eigenes Modell, dessen Aufgabe nicht das Schreiben von Prosa ist, sondern das Sammeln. Es ruft iterativ Code-Suchwerkzeuge auf, bis es genau den Code hat, der für die Antwort nötig ist, und gibt dann die gesammelten Belege plus einen kurzen Entwurf zurück. Ein separater Synthese-Schritt macht daraus die endgültige, mit Quellen belegte Antwort.
Diese Trennung ist wichtig. Das sammelnde Modell ist auf Werkzeugnutzung optimiert und darf klein und schnell sein. Das Synthese-Modell ist aufs Schreiben optimiert. Wenn man ein einziges Modell beides machen lässt, bekommt man eine Antwort, die entweder schlecht recherchiert oder schlecht geschrieben ist.
Wie sich die Flotte meldet
Der Sidecar initiiert die Verbindung, nicht der Server — was die richtige Richtung ist, wenn die Rechenleistung auf Workstations liegt, die kommen und gehen.
Das Wire-Protokoll ist bewusst klein gehalten. Ein Sidecar öffnet einen WebSocket und sendet register mit seiner Adresse, seinem Hostnamen und seinen Containern. Danach sendet er heartbeat-Frames mit Containern, Zahl der aktiven Anfragen und einem Status-Blob. Der Master antwortet mit registered und kann command- und config-Frames zurückschicken. Ist der WebSocket nicht verfügbar, funktioniert derselbe Austausch über HTTP-Endpunkte für Heartbeat, Poll und Result.
Fantom MCP erteilt derzeit keine Arbeitsbefehle über diesen Kanal — die eigentlichen Inferenzaufrufe laufen über HTTP. Was es sehr wohl tut: Es wertet jeden Heartbeat nach Fähigkeitsdaten aus, sodass die Routing-Schicht immer weiß, welche Rollen gerade tatsächlich bedient werden.
Ein Detail, das erwähnt sein will, weil es auf die harte Tour gelernt wurde: Diese Registry wird bei jedem Heartbeat neu geschrieben — read-modify-write — in eine Konfigurationsdatei, die auch Sucheinstellungen enthält. Eine frühere Version gab bei einem zerrissenen Lesevorgang ein leeres Objekt zurück, sodass ein einziger korrupter Read nur noch die Sidecar-Liste persistieren und alles andere löschen konnte — einschließlich des Backups. Lesevorgänge stellen sich jetzt aus einem daneben liegenden Backup wieder her, und Schreibvorgänge sind atomar. Flotten-Code fasst die Konfiguration weit häufiger an, als irgendjemand erwartet.
Die Sammelschleife
Hier ist, was tatsächlich passiert, wenn eine Frage eintrifft.
Das Modell erstellt einen Plan, setzt Tool-Aufrufe ab, und die Ergebnisse werden mit begrenzter Nebenläufigkeit eingesammelt. Belegblöcke werden aufgeteilt, zusammengeführt und gegen das Kontextfenster budgetiert — das dynamisch vom Serving-Endpunkt gelesen und nicht hartkodiert wird, weil dieselbe Schleife gegen unterschiedliche Modelle mit unterschiedlichen Limits läuft.
Wenn das Zurückgekommene nicht ausreicht, geht es noch einmal von vorn. Genau darin liegt der gesamte Unterschied zum One-Shot-Retrieval: Das System darf bemerken, dass es nicht genug hat.
Eine kürzliche Optimierung zeigt gut, wo die eigentlichen Kosten liegen. Statt bei jedem Erweiterungsschritt neu einzubetten, wird die Anfrage einmal eingebettet, und die Suche weitet sich parallel auf benachbarte Chunks aus, wobei der Reranker bei diesem Erweiterungsdurchlauf übersprungen wird. Das Teure am „noch einmal nachsehen“ war nie das Nachsehen — es war das redundante Neukodieren derselben Frage.
Fehlschlag ist ein erstklassiger Pfad
Jeder Endpunkt in dieser Kette gehört zu einer Maschine, die schlafen, gerade neu starten oder beschäftigt sein kann. Deshalb gilt im gesamten RLM-Pfad eine unmissverständliche Regel: Jeder Endpunktfehler liefert null zurück, und der Aufrufer fällt zurück. Es wird nie geworfen.
Das klingt wenig ambitioniert. In der Praxis ist es genau das, was das Feature auf einer echten Flotte nutzbar macht, wo „der RLM-Host ist offline“ die Antwort verschlechtern und nicht einen Stacktrace im Editor eines Steuerungstechnikers erzeugen sollte. Der Standard-Fallback-Modus ist rein lokal, und der Sammelschritt ist eine Erweiterung des Retrievals, keine Voraussetzung dafür.
Kapazität ohne Hardware
Das letzte Teil verbindet das Ganze mit der Cloud. Ein Sidecar kann eine Rolle statt an sein lokales Modell an OpenRouter weiterleiten, und Fantom MCP behandelt jede solche Paarung als virtuellen Container — ein eigener logischer Provider, benannt nach dem Muster <PCName>-OR-<Role>, der echte Serving-Kapazität ohne GPU und ohne VRAM dahinter repräsentiert.
So verteilt sich Embedding gleichzeitig über lokale GPUs und die Cloud, und so bekommt Reranking überhaupt ein Backend in einer Flotte, deren Maschinen mit anderer Arbeit ausgelastet sind.
Zwei Eigenschaften dieser Anordnung sind es wert, klar benannt zu werden:
- Discovery läuft über HTTP, nicht über den Heartbeat. Der Heartbeat trägt einen gekürzten Snapshot, der keine Daten zu virtuellen Containern enthält. Ein System, das sie aus dem Heartbeat auslesen wollte, würde stillschweigend für immer nichts finden — und dabei aussehen, als funktioniere es.
- Der API-Schlüssel berührt Fantom MCP nie. Der Sidecar hält ihn. Fantom benennt immer nur einen Provider und ein Modell. Nichts im Discovery-Pfad liest, speichert, loggt oder transportiert einen Schlüssel.
Wie diese Provider dann ausgewählt, freigegeben und budgetiert werden, ist Thema des nächsten Beitrags.
Der Fantom MCP Server ist source-available unter github.com/Project-SandStar/FantomMcpServer.