Offline-KI für Messaging-Plattformen: warum lokale Modelle zählen

Fast jede KI-Funktion, die heute in Messaging-Software steckt, ist ein Mietverhältnis. Sie läuft auf fremden Servern, sie wird nach fremden Preisen abgerechnet, und sie funktioniert nur so lange, wie die Leitung zwischen Ihrem Gebäude und deren Gebäude steht. Für die meisten Käufer ist das ein vertretbarer Handel. Für eine Bank, die eine Messaging-Plattform in einer DMZ betreibt, für eine Behörde in einem abgeschotteten Netz oder für einen Reseller in einem Markt, dessen Währung sich dieses Jahr um 30 Prozent bewegt hat, scheidet es schlicht aus. In diesem Leitfaden geht es darum, was wirklich passiert, wenn Sie die Cloud aus der Gleichung nehmen: was ein lokales Modell ehrlich kann, was es nicht kann, und das Entwurfsmuster, mit dem Sie beides bekommen, ohne das Produkt auf eines von beiden zu setzen.

Warum Cloud-KI in der DMZ und in regulierten Umgebungen ausscheidet

Es gibt drei getrennte Mauern, und Käufer stoßen meist in dieser Reihenfolge daran.

Die Netzwerkmauer. Eine Messaging-Plattform, die OTP für eine Bank terminiert, steht nicht im offenen Internet. Sie steht in einer DMZ, oder tiefer, hinter einer Firewall-Richtlinie, die jemand geschrieben hat, dessen Beruf es ist, Nein zu sagen. Ausgehendes HTTPS zu einem KI-Anbieter ist kein Häkchen: Es ist ein Change Request, ein Review, ein Eintrag im Risikoregister, und im abgeschotteten Fall ist es schlicht unmöglich, weil aus diesem Raum überhaupt keine Route hinausführt. Jede Funktion, die nach Hause telefoniert, ist für diesen Kunden eine Funktion, die es nicht gibt. Das ist weder hypothetisch noch selten: Es ist die normale Gestalt der wertvollsten Kunden dieser Branche.

Die Datenmauer. Selbst wo eine Route existiert, ist der Inhalt das Problem. Eine Umschreibungsanfrage trägt den Nachrichtentext mit sich, und der Nachrichtentext ist ein Kundenname, eine Kontoreferenz, ein Einmalpasswort, eine Mahnung, ein Arzttermin. Das an einen Dritten zu schicken heißt, Fragen zu Auftragsverarbeitung, Unterauftragsverarbeitern, Speicherfristen, Zuständigkeit und Drittlandtransfer zu beantworten, für jede Nachricht, für immer. Auf einige dieser Fragen gibt es gute Antworten. In einem regulierten Markt ist “der Text verlässt das Gebäude nie” ein deutlich kürzeres Gespräch als jede einzelne davon.

Die kommerzielle Mauer. Der Preis von Cloud-KI ist eine Entscheidung, die im Vorstand eines anderen Unternehmens fällt. Tarife ändern sich, kostenlose Stufen schließen, Modelle werden nach einem Zeitplan abgekündigt, den Sie nicht festlegen, und ein Schlüssel kann an einem beliebigen Dienstag widerrufen oder gedrosselt werden. Wenn die Vorzeigefunktion Ihres Produkts daran hängt, haben Sie ein Geschäft auf einer Abhängigkeit gebaut, die Sie nicht steuern. Betreiber in Schwellenmärkten spüren das am härtesten, denn ein in USD ausgewiesener Preis und ein in Landeswährung ausgewiesener Umsatz bewegen sich nicht gemeinsam.

Keine dieser Mauern bedeutet, dass KI vom Tisch ist. Sie bedeuten, dass die KI in Ihrem Gebäude leben können muss.

Was lokale Modelle wirklich können, und was nicht

Hier zählt Ehrlichkeit mehr als Begeisterung, denn der Abstand zwischen dem Marketing und der Maschine ist der Ort, an dem Projekte sterben.

Was sie gut können. Ein kleines instruktionsoptimiertes Modell, etwas im Bereich von 3 bis 8 Milliarden Parametern, quantisiert und lokal über llama.cpp oder Ollama auf normaler CPU bereitgestellt, ist bei eng umrissener Textarbeit wirklich gut. Eine Nachricht wärmer, kürzer oder förmlicher umschreiben. Ton und Grammatik glätten. Einen Übersetzungsentwurf vorlegen, den ein Mensch freigibt. Eine Supportfrage aus einem abgerufenen Dokument beantworten. Für einen Chatbot die Absicht klassifizieren und eine kurze, fast vorgeschriebene Antwort erzeugen. Genau das sind die Aufgaben, die eine Messaging-Plattform braucht, und sie haben alle dieselbe Gestalt: kurze Eingabe, kurze Ausgabe, enge Aufgabe, ein Mensch in der Nähe.

Was sie schlecht können. Langes mehrstufiges Schlussfolgern. Einen großen, verwickelten Kontext zusammenhalten. Feinsinniges kreatives Schreiben, das beim ersten Versuch sitzen muss. Alles, wo der Unterschied zwischen einer guten und einer hervorragenden Antwort echtes Geld wert ist. Ein Spitzenmodell aus der Cloud ist darin spürbar besser, und etwas anderes zu behaupten hilft niemandem.

Die Einschränkung, die alle vergessen: das Tempo. Ein lokales Modell auf CPU liefert grob 10 bis 25 Token pro Sekunde. Ein Umschreiben mit 200 Token dauert damit etwa 8 bis 20 Sekunden. Für einen Nutzer, der auf “umschreiben” klickt und wartet, ist das in Ordnung. Für einen Live-Chatbot, der unter Last Kunden bedient, ist es knapp, und genau dort fügen Sie eine bescheidene GPU hinzu, halten die Antworten kurz, oder schicken diese eine Funktion an eine Cloud-Engine. Keine Klugheit macht aus einer CPU ein Rechenzentrum.

Die praktische Folge. Entwerfen Sie Ihre Prompts gegen das native Modell, nicht gegen das aus der Cloud. Nativ ist die schwächste Engine, die Sie je betreiben werden, und gerade deshalb ist sie der Boden: Wenn ein Prompt dort eine brauchbare Antwort liefert, liefert er sie überall. Stimmen Sie ihn dagegen auf ein Spitzenmodell ab und fallen dann auf nativ zurück, ist genau dieser Rückfall der Moment, in dem Ihre Funktion Sie blamiert, und er kommt zum denkbar schlechtesten Zeitpunkt. Bauen Sie auf den Boden, und jede Steigerung ist ein Geschenk.

Das Muster der wählbaren Engine: nativ als Standard, Ihr Schlüssel optional

Der Fehler ist, das als Entweder-oder zu behandeln. Lokal oder Cloud, nehmen Sie eines und leben Sie damit. Die bessere Antwort ist, die Engine zu einer Einstellung zu machen und die Schnittstelle zu einem Vertrag.

Im Offline-KI-Entwurf von Smppcube wählt der Administrator die Engine einmalig in den globalen Einstellungen. Native lokale Modelle sind der Standard und immer verfügbar. Ein Cloud-Anbieter unter dem eigenen Schlüssel des Administrators ist optional, für Installationen, die mehr Leistung wollen und eine Route ins Internet haben. Alles dahinter, Umschreiben, Übersetzen, Chatbot, Journeys, Kampagnentexte, RAG, ruft eine einzige interne Schnittstelle auf und weiß weder noch interessiert es sich dafür, was dahintersteckt. Ändern Sie die Einstellung, und jede Funktion folgt gleichzeitig, ohne neue Verdrahtung.

Drei Details sorgen dafür, dass das in der Praxis funktioniert und nicht nur auf einer Folie.

Eine Gestalt, gebaut auf dem Standard. Die Schnittstelle ist auf den OpenAI-kompatiblen chat-completions-Vertrag gebaut, der den nativen Server und die große Mehrheit der Anbieter mit einem einzigen Codepfad abdeckt. Anthropic bekommt einen einzigen zusätzlichen Adapter. Das ist die gesamte Integrationsfläche, und deshalb ist das Hinzufügen eines Anbieters eine Einstellungsänderung und kein Projekt.

Embeddings sind eine eigene Einstellung. Abruf und Chat sind verschiedene Aufgaben mit verschiedener Ökonomie, und das Embedding-Modell wird unabhängig vom Chat-Modell gewählt. Sie können den Abruf lokal über Ihre eigenen Dokumente laufen lassen und den Chat gleichzeitig auf eine Cloud-Engine richten, oder umgekehrt, und der Tausch des einen rührt das andere nie an.

Der Rückfall auf nativ ist der Sicherheitsboden. Schlüssel werden im Ruhezustand verschlüsselt, in Protokollen geschwärzt und mit einem harten Ausgabenlimit pro Engine gedeckelt. Wird das Limit erreicht, hat der Anbieter eine Störung, bricht die Leitung ab, fällt die Plattform automatisch auf nativ zurück und die Funktion arbeitet weiter. Niemand wird nachts geweckt und kein Bildschirm bricht. Genau dieses Stück macht die Wahl der Cloud sicher: Sie vertrauen dem Anbieter nicht Ihre Verfügbarkeit an, Sie leihen sich seine Leistung mit einem Boden darunter.

Und eine Grenze, die man laut aussprechen sollte: KI ist hier assistierend, nicht autonom. Kampagnen bleiben von Menschen freigegeben. RAG-Antworten tragen die Leitplanke “steht nicht in der Dokumentation”, statt etwas Plausibles zu erfinden. Ein Offline-Modell, das selbstbewusst Dinge erfindet, ist schlechter als gar kein Modell, und die Leitplanke zählt umso mehr, je kleiner das Modell ist.

Die eine Aufgabe, die immer nativ ist: Spam

Es gibt genau eine KI-Funktion, die nie eine Engine-Wahl bekommt, und der Grund ist lehrreich.

Die Spam-Prüfung läuft auf dem heißen Pfad der Nachricht. Jede einzelne Nachricht geht hindurch, was bedeutet: Die Prüfung darf praktisch nichts kosten und darf nie auf einen Netzwerksprung warten. In Smppcube sind das fastText plus Regeln, in etwa einem Zehntel einer Millisekunde, nie ein LLM. Bei 3.000.000 Nachrichten im Monat ist ein Cloud-Aufruf von 200 ms je Nachricht kein Kostenproblem, sondern ein physikalisches: Ihr Durchsatz bricht ein und Ihre Warteschlange staut sich hinter der Latenz eines Dritten.

Die Regel zählt so viel wie der Mechanismus: markieren, nicht blockieren. Der Filter kennzeichnet, was nach Spam aussieht, und überlässt Ihnen die Entscheidung über den Versand. Ein falsch Positives, das den OTP-Verkehr eines Kunden lautlos abwürgt, ist ein weit teurerer Fehler als eine markierte Nachricht, über die ein Mensch kurz schaut. Das ist die allgemeine Regel für KI auf einem heißen Pfad, und deshalb ist der schnelle, langweilige, offline laufende Klassifikator das richtige Werkzeug, nicht das beeindruckende.

Die Zahlen, ehrlich gerechnet

Lassen Sie das dahingesagte “KI ist teuer” beiseite und rechnen Sie nach, denn die Antwort fällt bei verschiedenen Volumen wirklich verschieden aus.

Leichte assistive Nutzung ist in der Cloud billig. Fünfzig Kundennutzer mit je vierzig Umschreibungen am Tag sind rund 60.000 Aufrufe im Monat. Bei etwa tausend Token je Aufruf sind das 60 Millionen Token, was bei einem Modell der Mittelklasse irgendwo bei 30 bis 60 USD im Monat landet. Wer Ihnen erzählt, allein die Token-Rechnung rechtfertige bei diesem Volumen den Wechsel auf nativ, verkauft Ihnen etwas. In dieser Größenordnung gehen Sie wegen der DMZ und wegen der Daten auf nativ, nicht wegen der Rechnung.

Chatbots ändern die Gestalt. Stellen Sie nun einen RAG-Chatbot vor den eingehenden Verkehr. Zwanzigtausend Gespräche im Monat zu je sechs Runden sind 120.000 Aufrufe, und jeder trägt abgerufenen Kontext mit sich, sagen wir 4.500 Token für Ein- und Ausgabe zusammen. Das sind rund 540 Millionen Token im Monat, je nach Modell 200 bis 400 USD, oder 2,400 bis 4,800 USD im Jahr. Der unangenehme Teil ist die Richtung: Diese Rechnung wächst mit jedem Wachstum des Geschäfts, das heißt, der Erfolg hebt Ihre Kosten genau in dem Quartal, in dem Sie die Marge wollten.

Nativ hat keinen Zähler. Ein nativer Aufruf kostet null. Die Kosten von nativ sind die Maschine: ein vorhandener Server mit Luft, oder rund 40 bis 80 USD im Monat an zusätzlicher Kapazität, flach, ob Sie tausend Aufrufe machen oder eine Million. Gegen eine einmalig bezahlte Plattformlizenz, die ohnehin auf Ihrem eigenen Blech läuft, nach derselben Mieten-oder-Besitzen-Logik wie im Leitfaden zum selbst gehosteten Gateway, hört die KI-Position auf, ein variabler Kostenblock zu sein, und wird Teil der Maschine, die Sie längst gekauft haben.

Die ehrliche Zusammenfassung: Bei leichter Nutzung gehen Sie wegen der Souveränität auf nativ und wegen der Qualität in die Cloud, und das Geld ist in beiden Fällen ein Rundungsfehler. Bei Chatbot-Volumen ist nativ spürbar günstiger und, wichtiger noch, planbar. Planbarkeit ist das, was Ihnen erlaubt, einem Kunden einen Preis für ein ganzes Jahr zu nennen.

Ehrlich entscheiden

Wenn Ihre Installation eine saubere Route ins Internet hat, keine Vorgabe zur Datenresidenz kennt und Sie bei einer Handvoll wertvoller Aufgaben das bestmögliche Ergebnis wollen, nutzen Sie eine Cloud-Engine mit Ihrem eigenen Schlüssel. Das ist eine gute Entscheidung, und das Muster von oben trägt sie vollständig. Nativ für Spam und Abruf, Cloud für das Schreiben, und der Rückfall immer scharf.

Gehen Sie zuerst auf nativ, sobald eines davon zutrifft: Ihre Plattform lebt in einer DMZ oder in einem abgeschotteten Netz; Ihre Kunden fragen nach Unterauftragsverarbeitern, bevor sie nach dem Preis fragen; Ihr Umsatz steht in einer Währung, die dem USD nicht folgt; oder Ihr KI-Volumen hat die Gestalt eines Chatbots und wächst. Und gehen Sie ohnehin zuerst auf nativ, wenn Sie ein Produkt an Kunden ausliefern, deren Umgebungen Sie nicht kontrollieren, denn eine Funktion, die eine Route ins Internet braucht, ist eine Funktion, die es für einen Teil Ihres Marktes stillschweigend nicht gibt.

Was sich zu entwerfen lohnt, ist nicht lokal gegen Cloud. Es ist, dass die Wahl demjenigen gehört, dem die Server gehören, dass sie eine Einstellung ist und kein Umbau, und dass der Boden darunter immer hält. Ziehen Sie das Kabel, und es denkt weiter. Alles andere ist Geschmackssache.