Ein eigenes Modell, keine gemietete API
Wir bauen und betreiben Small Specialized Language Models: intelligente Systeme, die in deiner Infrastruktur laufen, deine Domäne kennen und mit klaren Kriterien evaluiert werden. Ohne davon abhängig zu sein, dass Preise, Nutzungsregeln oder das Verhalten eines fremden Modells morgen anders sind.
Ein SSLM ist ein passend dimensioniertes Open-Weight-Modell, auf deine Domäne angepasst, in deinem Wissen verankert und hinter einer Standard-API bereitgestellt. Kein Chatbot über deinen Dokumenten, sondern Software mit Gedächtnis, Evaluation und Betrieb.
Gewichte, Korpus und Spuren bleiben in deinem Perimeter. Datenhaltung in der EU, keine Anfragen an Dritte.
Aus variablen Kosten pro Token wird bekannte Infrastruktur. Der Erfolg des Produkts bestraft nicht länger die Rechnung.
Jede Version läuft gegen Szenarien mit erwarteter Antwort. Bricht eine kritische Anfrage, geht das Release nicht raus.
Drei Belastungen, sobald Intelligenz keine Demo mehr ist
Das ist keine ideologische Debatte über Anbieter. Es ist das, was passiert, wenn eine intelligente Funktion echte Nutzer, echte Rechnungen und echte Konsequenzen bekommt.
Die Rechnung wächst mit dem Erfolg
Im Pilotbetrieb sind Kosten pro Token irrelevant. Bei Volumen macht dasselbe Design jeden neuen Nutzer zu variablen Kosten, die niemand geplant hat.
Dein Wissen verlässt den Perimeter
Interne Dokumentation, Verträge, Vorfälle und Kundengespräche gehen zu einem Dritten. In vielen Kontexten ist das keine Vorliebe mehr, sondern eine Anforderung, die begründet werden muss.
Du hängst an Entscheidungen, die du nicht steuerst
Preise, Nutzungsgrenzen, Abkündigungen und Verhaltensänderungen kommen ohne Vorwarnung. Dein Produkt erbt eine fremde Roadmap.
Was wir konkret bauen
Ein SSLM ist kein einzelnes Artefakt. Es sind sechs Schichten, und jede ist eine Entscheidung, die dokumentiert und prüfbar ist.
Offenes Basismodell
Ein Open-Weight-Modell in der Größe, die das Problem braucht, nicht das größte verfügbare. Ausgewählt nach Qualität in deiner Domäne, Lizenz und Betriebskosten.
Domänenkorpus
Dein Wissen als nutzbares Material: was hineinkommt, mit welchen Rechten, unter welcher Lizenz und wer für die Qualität verantwortet.
Spezialisierung
Domänenanpassung mit leichten Adaptern, ohne Training von Null. Das Modell lernt dein Vokabular, deine Formate und deine Art zu antworten.
Verankerung im Wissen
Retrieval über deinem Korpus, damit Antworten konkrete Quellen nennen. Ein „das weiß ich nicht“ ist uns lieber als eine selbstsichere Erfindung.
Kontinuierliche Evaluation
Szenarien mit erwarteter Antwort, kritische Fälle, die ein Release blockieren, und ein Bericht, den auch Nicht-Entwickler lesen können.
Gateway und Betrieb
Eine API im Branchenstandard, Schlüssel pro Projekt und Messung von Nutzung, Latenz und Kosten. Observability ab Tag eins.
Wann sich ein eigenes Modell rechnet
Das Argument ist nicht „immer selbst hosten“. Es gibt ein Volumen, ab dem variable Kosten keinen Sinn mehr ergeben. Setze deine Zahlen ein und finde deinen Break-even.
Millionen Tokens pro Monat, Eingabe und Ausgabe zusammen.
Vereinfachtes Modell: 50/50 zwischen Eingabe und Ausgabe, 720 Betriebsstunden pro Monat und indikative Listenpreise. Im Discovery ersetzen wir das durch deine echten Tarife und deinen echten Traffic.
Bei diesem Volumen lohnt eigene Infrastruktur noch nicht. Ehrlich ist: warten oder mit einem eng gefassten Fall starten.
Liegt dein Volumen unter dem Break-even, sagen wir es: bleib bei einer fremden API und komm zurück, wenn der Traffic es rechtfertigt. Ein SSLM, das sich nicht selbst trägt, ist kein gutes Projekt.
Es wird angeschlossen, nicht eingebaut
Das SSLM lebt außerhalb deines Codes und wird über eine API im Branchenstandard konsumiert. Du tauschst Basis-URL und Schlüssel; der Rest deines Produkts merkt nichts davon.
- Kompatibel mit den Clients und SDKs, die dein Team schon nutzt. Keine proprietären Bibliotheken.
- Koexistenz mit externen Anbietern: Routing nach Anfragetyp, Kosten oder Kritikalität.
- Schlüssel pro Projekt, mit Nutzungsmessung und Spuren, um zu prüfen, wer was fragt.
- Wenn du morgen zurück willst, gehst du zurück. Reversibilität gehört zum Entwurf.
curl https://sslm.internal/v1/chat/completions \
-H "Authorization: Bearer $PROJECT_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "atlas-ops-8b",
"messages": [
{ "role": "user", "content": "..." }
]
}'Drei Formate, in dieser Reihenfolge
Wir verkaufen kein geschlossenes Modell und kein Stundenpaket. Zuerst entscheiden wir, ob es Sinn ergibt, dann bauen wir, was trägt, und bleiben nur im Betrieb, wenn es Wert stiftet.
Discovery
Wochen, um zu beantworten, ob ein SSLM in deinem Fall Sinn ergibt — mit Zahlen und Risiken auf dem Tisch.
- Wissensinventar und rechtliche Machbarkeit der Daten
- Nutzungsszenarien und messbare Qualitätskriterien
- Kostenmodell mit deinem Volumen und deinem Break-even
- Eine ehrliche Empfehlung, auch die es nicht zu tun
Build
Wir bauen das gesamte System: Korpus, Spezialisierung, Verankerung, Evaluation und Gateway.
- Aufbereiteter, nachvollziehbarer Korpus mit klaren Rechten
- Domänenanpassung und Verankerung in Quellen
- Eigenes Set an Evaluationsszenarien
- API, Schlüssel pro Projekt und Nutzungsmessung
- Dokumentation des Modells und seiner Grenzen
Operate
Wir begleiten das Leben des Systems: Qualität, Kosten, Weiterentwicklung des Korpus und Übergabe ans Team.
- Kontinuierliche Evaluation und Regressionskontrolle
- Verfolgung von Kosten, Latenz und Nutzung pro Projekt
- Aktualisierung von Korpus und Modellversionen
- Schulung und Übergabe, um es ohne uns zu betreiben
Woran du erkennst, dass es funktioniert
Die schwierige Frage ist nicht, ob es in einer Demo gut antwortet. Sondern was am Tag passiert, an dem es falsch antwortet und jemand auf der anderen Seite wartet.
- 01
Szenarien mit erwarteter Antwort
Wir definieren gemeinsam, welche Fragen das System treffen muss und was als akzeptable Antwort gilt. Qualität ist dann keine Meinung, sondern eine Zahl.
- 02
Kritische Fälle, die ein Release blockieren
Manche Antworten dürfen nicht falsch sein. Bricht eine davon, geht die Version nicht in Produktion, selbst wenn alles andere besser wurde.
- 03
Antworten mit Quelle
Jede Antwort kann zeigen, aus welchem Ausschnitt deines Wissens sie stammt. Ohne Quelle ist uns ein klares Nein lieber als eine überzeugende Erfindung.
- 04
Dokumentation des Modells
Vorgesehene Nutzung, Daten, bekannte Grenzen und Betrieb. Ein Dokument, das du Kunden, Audit oder einem Technikgremium zeigen kannst.
Was uns vor dem Start gefragt wird
- Ist es nicht schlechter als ein großes Modell?
- Bei allgemeinen Aufgaben ja. In deiner konkreten Domäne und verankert in deinem Wissen trifft ein gut spezialisiertes kleines Modell meist häufiger und antwortet schneller. Wir messen es, bevor wir es behaupten.
- Brauche ich ein Datenteam?
- Zum Start nicht. Du brauchst irgendwo festgehaltenes Wissen und jemanden, der sagen kann, welche Antwort richtig ist. Den Rest übernehmen wir und geben ihn ab.
- Was, wenn morgen ein besseres Modell kommt?
- Das ist zu erwarten und im Entwurf vorgesehen. Korpus, Evaluationsszenarien und Gateway sind deine; das Basismodell ist austauschbar. Dort sammelt sich der Wert.
- Wie lange bis zur Produktion?
- Ein Discovery misst sich in Wochen. Ein erstes Produktionssystem mit engem Umfang in Monaten. Ein wirklich gelöster Fall ist uns lieber als eine halbfertige Plattform.
- Ersetzt das unseren aktuellen Anbieter?
- Nicht zwingend. Üblich ist Koexistenz: das eigene Modell übernimmt das wiederkehrende und sensible Volumen, der externe Anbieter das, was wirklich ein Generalistenmodell braucht.
- Wem gehört das Ergebnis?
- Dir. Korpus, Adapter, Evaluationsszenarien und Infrastruktur sind deine, und die Übergabe ist von Anfang an eingeplant. Wir bauen keine Abhängigkeit von uns.
Sehen wir, ob dein Projekt passt
Fit-Check anfragen