Es gibt ein leises Prinzip im Yoga, das überraschend gut auf Technologie passt: Setze genau den Einsatz, den der Moment verlangt — nicht mehr und nicht weniger. Die meisten Teams, die heute KI einsetzen, machen das Gegenteil. Sie investieren bei jeder Aufgabe maximalen Aufwand, ob es nötig ist oder nicht, und zahlen für dieses Privileg Token für Token.
Lassen Sie uns darüber sprechen, warum Ihre KI-Kosten weiter steigen — und wie Sie sie wieder auf etwas Bewusstes zurückführen können.
Frontier-Modelle sind darauf ausgelegt, Tokens zu verbrauchen
Die Frontier-Modelle von Anthropic und OpenAI sind wirklich bemerkenswert, und ein großer Teil des Warum ist, dass die neueste Generation pro Anfrage einfach mehr Arbeit erledigt. Sie schließen Schritt für Schritt. Sie „denken“, bevor sie antworten. Sie laufen über längere, mehrstufige agentische Schleifen. Sie liefern gründliche, vorsichtige und kontextreiche Antworten.
Das ist ein echter Gewinn für die Nutzererfahrung. Die Antworten sind besser, sorgfältiger und leistungsfähiger als die knappen Modelle von vor ein paar Jahren. Aber es hat einen strukturellen Nebeneffekt, den man klar benennen sollte:
Diese Modelle werden pro Token bepreist, und sie sind darauf ausgelegt, mehr Tokens zu verwenden.
Mehr Denken, mehr Ausgabe, mehr Hin und Her — all das verbessert die Erfahrung und erhöht den Verbrauch. Die Anreize derjenigen, die Ihnen Tokens verkaufen, und Ihre eigenen Anreize als Käufer zeigen nicht in dieselbe Richtung. Am Ende bezahlen Sie für tiefes Nachdenken bei Aufgaben, die nur eine Ein-Satz-Antwort gebraucht hätten.
Was das ein Unternehmen tatsächlich kostet
Bei einem einzelnen Chat sind die Kosten unsichtbar — ein Bruchteil eines Cents. Das Problem ist die Skalierung.
- Ein Kundenservice-Workflow, der 50,000 Nachrichten pro Tag bearbeitet.
- Eine Content-Pipeline, die Hunderte von Entwürfen erzeugt.
- Ein interner Agent, der sich fünf- oder sechsmal pro Aufgabe in Schleifen dreht, um „es durchzudenken“.
Multiplizieren Sie den Token-Verbrauch pro Aufruf mit dem Overhead durch das Nachdenken, dann mit dem Volumen, dann mit 30 Tagen. Ein Workflow, der im Demo-Setup trivial billig wirkte, wird zu einem ernsthaften, wiederkehrenden Betriebskostenfaktor — und zu einem, der jedes Mal wächst, wenn Sie ein Feature oder einen Kunden hinzufügen. Schlimmer noch: Er ist unvorhersehbar; ein Modell, das sich entscheidet, diesen Monat härter nachzudenken, erhöht stillschweigend Ihre Rechnung, ohne dass jemand eine einzige Zeile neuen Codes ausliefert.
Für ein kleines oder mittelständisches Unternehmen ist genau diese Unvorhersehbarkeit die eigentliche Steuer.
Die lokale Alternative: Ollama
Hier ist der Perspektivwechsel. Nicht jede Aufgabe braucht ein Frontier-Modell. Tatsächlich brauchen die meisten das nicht.
Ollama ermöglicht es Ihnen, leistungsfähige Open-Source-Modelle — Llama, Mistral, Qwen und viele andere — direkt auf Ihrer eigenen Hardware oder auf einem bescheidenen Server auszuführen. Sobald es läuft, sinken die Grenzkosten einer Anfrage auf ungefähr null. Sie haben die Rechenleistung bereits bezahlt; es läuft kein Zähler pro Token mit.
Der Nachteil ist, dass ein lokales 7B–30B-Modell nicht so breit brillant ist wie ein Frontier-Modell. Aber für klar definierte, wiederholbare Arbeit — Klassifizierung, Extraktion, Zusammenfassung, Routing, Entwürfe nach Vorlage — ist ein kleineres lokales Modell mehr als gut genug. Die Kunst besteht darin zu wissen, welche Aufgaben lokal bleiben und welche man eskalieren sollte.
Die benutzerdefinierten Skills von AnythingLLM: der eigentliche Hebel
Hier liegt der Großteil der Einsparungen.
AnythingLLM ist eine Open-Source-Anwendung, die lokale Modelle (über Ollama) in einen sauberen Arbeitsbereich mit Dokumenten-/RAG-Unterstützung einbindet — und, entscheidend, in ein System für benutzerdefinierte Skills. Anstatt ein Modell bei jedem einzelnen Durchlauf von Grund auf selbstständig zu einem Ergebnis denken zu lassen, kodieren Sie den wiederholbaren Teil der Arbeit als deterministischen Skill: echten Code, der zuverlässig ausgeführt wird, Ihre APIs aufruft, Ihre Ausgabe formatiert und nur die wirklich mehrdeutigen Entscheidungen wieder an das Modell zurückgibt.
Das Ergebnis ist ein Hybrid:
- Deterministischer Code übernimmt die schwere, wiederholbare Arbeit — jedes Mal kostenlos und identisch.
- Das Modell wird nur für den kleinen Teil der Aufgabe eingesetzt, der tatsächlich Urteilsvermögen erfordert.
Sie erhalten dasselbe Endergebnis, mit einem Bruchteil des Token-Verbrauchs — weil Sie aufgehört haben, ein Sprachmodell dafür zu bezahlen, einen Prozess neu abzuleiten, den Sie bereits kennen.
Wo MCP-Server ins Spiel kommen
Ein kleines lokales Modell ist nur so nützlich wie das, worauf es zugreifen kann. Dafür sind MCP-(Model Context Protocol)-Server da.
MCP ist ein offener Standard, um KI-Modelle mit Tools, Daten und Live-Systemen zu verbinden — Datenbanken, Dateispeichern, internen APIs, Ticketing-Systemen, Ihrem CRM. AnythingLLM unterstützt MCP-Server, was bedeutet, dass Ihr lokaler Stack kein abgeschotteter Chatbot ist; er ist ein Agent, der echte Daten lesen und über eine saubere, standardisierte Schnittstelle echte Aktionen ausführen kann.
Genau das macht den lokalen Ansatz für ernsthafte Arbeit praktikabel. Die Frontier-Anbieter wollen, dass Sie alles innerhalb ihres tokenbepreisten Kontextfensters erledigen. MCP ermöglicht es Ihnen, die Daten, die Werkzeuge und die deterministische Logik auf Ihrer Seite zu behalten — und Tokens nur für das eigentliche Nachdenken auszugeben.
Praktische Tipps: einen Standard-Skill als optimierten Custom Skill neu aufbauen
So nehmen Sie eine Aufgabe, die Sie derzeit an ein Frontier-Modell geben, und bauen sie so um, dass sie für einen Bruchteil der Kosten läuft.
Analysieren Sie zuerst Ihren Token-Verbrauch. Finden Sie die 3–5 Workflows, die am häufigsten laufen. Dort summieren sich Einsparungen. Optimieren Sie nicht das, was Sie zweimal pro Woche ausführen.
Trennen Sie das Deterministische vom Mehrdeutigen. Schauen Sie sich an, was das Modell bei jedem Aufruf tatsächlich macht. Die Teile, die immer gleich sind — Daten abrufen, ein Format anwenden, Felder validieren, weiterleiten — brauchen überhaupt kein Sprachmodell.
Verschieben Sie die deterministischen Teile in Code. In einem benutzerdefinierten AnythingLLM-Skill wird diese Logik zu einer Handler-Funktion. Sie läuft jedes Mal identisch, mit null Token-Kosten.
Reduzieren Sie den Prompt auf die Entscheidung. Geben Sie dem Modell nur die wirklich mehrdeutige Frage, mit gerade genug Kontext, um sie zu beantworten. Kein vollständiges Wiederholen des gesamten Prozesses bei jedem Aufruf. Kleinerer Input, kleinere Ausgabe, kleinere Rechnung.
Holen Sie Live-Daten über MCP, nicht über den Prompt. Fügen Sie kein 4,000-Token-Dokument einfach in den Kontext ein, wenn ein MCP-Tool genau das benötigte Feld auf Abruf holen kann.
Leiten Sie nach Schwierigkeit weiter. Lassen Sie die alltägliche Version auf einem lokalen Ollama-Modell laufen. Heben Sie das Frontier-Modell für die wirklich schwierigen 5% auf — und lassen Sie Ihren Skill entscheiden, wann eskaliert wird.
Messen Sie Vorher und Nachher. Verfolgen Sie Tokens pro Aufgabe vor und nachher. Teams, die das konsequent tun, erzielen bei ihren Workflows mit dem höchsten Volumen häufig Reduzierungen um 80–95%.
Die bewusste Quintessenz
Frontier-KI ist es wert, dafür zu bezahlen — wenn die Aufgabe es wirklich verlangt. Der Fehler besteht darin, sie als Standard für alles zu verwenden und stillschweigend einen Pro-Token-Zähler zu finanzieren, der darauf ausgelegt ist, weiter zu steigen.
Erledigen Sie Routinearbeit lokal. Kodieren Sie Wiederholbares als benutzerdefinierte Skills. Verbinden Sie es mit der realen Welt über MCP. Heben Sie sich Frontier-Modelle für die Momente auf, die sie wirklich brauchen.
Das ist kein Abkürzen. Das ist einfach der richtige Einsatz für den Moment — und das ist, wie sich herausstellt, gute Praxis auf der Matte und in der Cloud.