Martian: Modell-Router mit Embeddings-Klassifikator pro Anfrage

Was ist Martian?

Martian (withmartian.com) ist ein US-basiertes Startup mit Sitz in San Francisco, das 2023 gegründet wurde. Der Kerngedanke: statt für jede Anfrage ein Modell hardcoded zu wählen, überlässt man die Entscheidung einem Klassifikator. Der Klassifikator vergleicht das Embedding der eingehenden Anfrage mit hinterlegten Profilen pro Modell und wählt dasjenige, das für diese Anfrage-Kategorie historisch am besten abschneidet. Das Ergebnis: theoretisch niedrigere Kosten und bessere Antworten, weil teure Modelle nur bei komplexen Anfragen kommen.

Das Produkt ist proprietär und Cloud-only mit Hosting in den USA (AWS us-east). Stand Mai 2026 gibt es keinen Self-Host-Tier und keine EU-Region. Der Endpoint ist OpenAI-kompatibel (https://withmartian.com/api/openai/v1); im Modell-Feld setzt man router/martian-router-v3 oder einen explizit gewählten Provider/Modell-Namen. Der Router wählt anschliessend zwischen rund 20 unterstützten Upstream-Modellen (Claude-Familie, GPT-Familie, Mistral, Llama, Gemini).

Das Geschäftsmodell ist ein USD-Markup pro Million Tokens: typisch USD 0.50 für leichte Routing-Entscheidungen, USD 1-2 bei vollem Klassifikator-Inferenz-Pass. Der eigentliche Modell-Token-Preis wird durchgereicht (kein zusätzlicher Anteil am Provider-Preis). Insgesamt ist Martian damit teurer als ein einfacher Provider-Direct-Call, kann aber bei guter Klassifikation Gesamtkosten senken, weil Anfragen, die ein 7B-Modell ausreichend beantworten, nicht auf GPT-4o landen.

Für fairlane.systems-Mandate ist Martian Stand Mai 2026 ein experimentelles Werkzeug. Wir haben es in Pilot-Setups getestet, kommen aber nicht zu einer breiten Empfehlung – die Klassifikator-Entscheidung ist nicht vorhersagbar, Audit-Pfade sind schwach, und das US-Hosting ist für Mandantendaten nicht passend. In rein forschungs-getriebenen Setups ohne PII kann Martian eine Kostenoptimierung sein.

Warum es konzeptionell interessant ist

Die Grundidee adressiert ein reales Problem. In typischen LLM-Anwendungen sind die meisten Anfragen einfach (Definitionsfragen, kurze Klarstellungen, Faktenabfragen) und nur ein kleiner Anteil komplex (mehrstufige Argumentation, lange Synthese, juristische Analyse). Wer alle Anfragen an Claude Opus schickt, zahlt für einfache Anfragen die Premium-Token-Rate. Wer alle an Mistral 7B schickt, bekommt bei komplexen Anfragen schwache Antworten. Ein Router, der pro Anfrage entscheidet, ist die theoretisch optimale Lösung.

Die Praxis ist schwieriger. Erstens: die Klassifikator-Genauigkeit. Eine Anfrage als "einfach" oder "komplex" einzustufen ist selbst ein nicht-triviales Klassifikations-Problem. Martian veröffentlicht Benchmarks, die rund 15-25% Kosten-Ersparnis gegenüber einer reinen GPT-4o-Konfiguration zeigen – bei vergleichbarer oder leicht besserer Antwort-Qualität. Diese Zahlen sind plausibel, lassen sich aber nicht ohne weiteres auf jeden Use Case übertragen; in der Treuhand-Praxis mit fachspezifischen Anfragen kann die Klassifikation schlechter sein, weil das Training-Set nicht passt.

Zweitens: Audit-Schwäche. Wenn der Router einer Anfrage Claude Opus zuweist und einer zweiten, fast identischen Anfrage Mistral 7B, ist die Entscheidungs-Begründung intransparent. Für einen Auditor unter Art. 957a OR ist "der Klassifikator hat entschieden" keine ausreichende Antwort. Martian liefert pro Anfrage einen Header mit dem gewählten Modell und einem Konfidenz-Score, aber das ist im Vergleich zu deterministischem Routing eine deutliche Audit-Lücke.

Drittens: Lock-in. Das Klassifikator-Profil pro Modell ist intern und proprietär. Wer von Martian zu LiteLLM migrieren will, kann den Routing-Stil nicht 1:1 reproduzieren. Wer eine deterministische Modell-Wahl behalten will, sollte das hier nicht durch einen Klassifikator ersetzen.

Für CH-DSG ist Martian kritisch zu sehen. US-Hosting ohne EU-Region, kein Auftragsdatenverarbeitungs-Vertrag in CH-Standard, kein Self-Host. Für Mandanten-PII ist Martian nicht geeignet; für offene Forschungs- und Marketing-Anfragen ohne PII ist es eine Option, wenn man die Kostenoptimierung explizit messen will.

Wie es funktioniert

Der Einstieg erfolgt über das Martian-Dashboard. Nach Account-Eröffnung und Aufladung von USD-Credits bekommt man einen API-Key (sk-martian-...). Die Anbindung erfolgt OpenAI-kompatibel:

import openai client = openai.OpenAI( api_key="sk-martian-...", base_url="https://withmartian.com/api/openai/v1" ) resp = client.chat.completions.create( model="router", # statt eines konkreten Modell-Namens messages=[{"role":"user","content":"Erläutere bitte die revDSG-Pflichten für Treuhand-Büro."}], extra_body={"router_constraints": {"max_cost_per_1m_tokens": 5, "allowed_providers": ["mistral", "anthropic"]}} ) print(resp.model, resp.choices[0].message.content)

Das Feld model: router aktiviert die Klassifikator-Logik. Die router_constraints (proprietäres Extra-Feld) erlauben Einschränkungen: maximaler Token-Preis, erlaubte Provider, Latenz-Budget. Die Antwort enthält resp.model mit dem tatsächlich genutzten Modell (z. B. mistral/mistral-large-2411).

Die Klassifikator-Logik hat zwei Modi. Im Routing-Lite-Modus wird das Embedding der Anfrage berechnet und gegen vorgehaltene Cluster verglichen – Kosten USD 0.50 pro 1M Embedding-Tokens. Im Routing-Full-Modus läuft zusätzlich ein leichtgewichtiges Klassifikator-Modell, das eine Komplexitäts-Vorhersage liefert – Kosten USD 1-2 pro 1M Tokens. In beiden Fällen wird das Endmodell entsprechend gewählt.

Observability ist eingebaut. Das Dashboard zeigt pro Tag eine Aufschlüsselung der gewählten Modelle, der Kosten und der Antwort-Latenz. Es gibt einen Compare-Modus, in dem die gleiche Anfrage parallel an mehrere Modelle gesendet wird (mit Kosten-Aufschlag) – das hilft beim Justieren der Klassifikator-Profile. Custom-Eval-Sets lassen sich hochladen; der Klassifikator wird dann auf diese Sets feinabgestimmt.

Logging-Retention liegt standardmässig bei 30 Tagen; Export via API in CSV/JSON möglich. Eine WORM-Compliance-Schicht ist nicht eingebaut – wer Audit-Trails für Art. 957a OR braucht, muss die Logs in eigenes S3-mit-Object-Lock spiegeln.

Martian-Vergleichs-Pilot in 5 Schritten

1. 01Account auf withmartian.com eröffnen, USD 50 Credits aufladen, API-Key (sk-martian-...) generieren.
2. 02Test-Set von 100-200 realen Anfragen ohne PII zusammenstellen, in zwei Gruppen (einfach/komplex) labelen.
3. 03Eine Woche lang parallel laufen lassen: Anwendung schickt jede Anfrage einmal an Martian-Router und einmal an statisches Baseline-Modell (z. B. Claude Sonnet).
4. 04Auswertung: Klassifikator-Entscheidungen pro Kategorie, Kosten-Differenz, Antwort-Qualität via LLM-as-Judge oder Mensch-Eval auf 30 Stichproben.
5. 05Entscheidung: bei realer Kostenersparnis > 15% bei vergleichbarer Qualität -> dauerhafte Nutzung für nicht-PII-Workload; sonst Modell-Wahl statisch lassen.

Wann Martian passt

Erstens für Forschungs-Setups, die Modell-Routing-Strategien explizit messen wollen. Wer wissenschaftlich-rigoros vergleichen will, ob Klassifikator-Routing tatsächlich Kosten spart, kann Martian als A-B-Vergleich gegen eine statische Modell-Wahl betreiben.

Zweitens für Hochvolumen-Anwendungen mit gemischter Komplexität ohne PII. Beispiel: ein Marketing-Tool, das täglich 50.000 Texte unterschiedlicher Tiefe generiert. Ein Klassifikator-Router kann hier 15-25% LLM-Kosten einsparen, was bei monatlichen LLM-Ausgaben von USD 5.000+ relevant wird.

Drittens für Test- und Vergleichs-Pipelines. Im Compare-Modus lässt sich die gleiche Anfrage an mehrere Modelle senden – schneller als ein eigener Vergleichs-Stack mit OpenRouter plus selbstgeschriebenem Eval-Code.

Viertens für akademische Setups, in denen Routing-Forschung selbst Gegenstand ist. Wer Klassifikator-Tuning und Modell-Selektion methodisch untersucht, bekommt mit Martian eine produktive Plattform mit eingebautem Eval-Workflow.

In keinem Fall passt Martian für Mandanten-PII unter CH-DSG oder StGB Art. 321. Hier ist der Layer falsch – US-Hosting, Klassifikator-Intransparenz, fehlender Auftragsdatenverarbeitungs-Vertrag in CH-Standard.

Wann NICHT

Erstens bei Mandantendaten unter Berufsgeheimnis. US-Hosting ohne EU-Tier macht jeden Call zum Drittland-Transfer; ohne formale Garantien (DPA, SCCs, ZDR-Modus mit Zertifikat) ist das für StGB-321-Branchen Tabu.

Zweitens, wenn deterministisches Modell-Routing gewünscht ist. Wer pro Anwendungsfall genau wissen will, welches Modell antwortet (etwa für Reproduzierbarkeit, Eval-Konsistenz oder Audit), darf nicht einen Klassifikator dazwischen schalten. Hier sind LiteLLM oder Portkey die richtige Wahl.

Drittens, wenn das Volumen unter ein paar tausend Anfragen pro Tag liegt. Bei niedrigem Volumen ist das USD-Markup pro Million Tokens praktisch unrelevant, der Klassifikator-Aufwand aber konstant. Das Verhältnis aus Aufwand und Einsparpotenzial passt nicht.

Viertens, wenn Audit-Trail-Anforderungen unter Art. 957a OR Pflicht sind. Die Klassifikator-Entscheidung ist intransparent; der Auditor will eine deterministische Begründung, die Martian standardmässig nicht liefert. Eine Eigenbau-Erklärungs-Schicht oben drauf ist Aufwand, der den Vorteil des Routers wieder neutralisiert.

Fünftens, wenn Lock-in vermieden werden soll. Das Klassifikator-Profil ist proprietär und nicht migrierbar. Eine Wechsel-Strategie zurück auf deterministisches Routing erfordert eine Neu-Konzeption.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Martian Documentation – router, model orchestration, constraints · 2026-05
2. Martian Pricing – routing modes, markup, retention · 2026-05
3. Martian Research papers on model routing · 2026-02
4. Martian Privacy Policy – data retention and US hosting · 2026-03