Bild: KI-generiert mit Google Gemini / stk
Ein eigens dafür trainiertes Small Language Model kann Support-Tickets oft besser sortieren als ein deutlich größeres Allzweckmodell. Ob sich der Eigenbetrieb rechnet, entscheidet trotzdem selten der Token-Preis. Wo kompakte KI-Modelle Sinn ergeben, wo sie scheitern und welche Architektur beides einkalkuliert.
40.000 Support-Anfragen im Monat, per E-Mail und über ein Formular – so sieht der Posteingang bei einem Maschinenbauer aus. Jede Anfrage gehört in eine von 14 Fachkategorien und braucht eine Prioritätsstufe, während Kundennummer, Seriennummer und Störungsbild aus dem Fließtext in strukturierte Felder überführt werden müssen.
Pro Anfrage kommen rund 1.200 Eingabe- und 150 Ausgabe-Token zusammen. Bei Token handelt es sich um die Abrechnungseinheit der Anbieter, im Deutschen ungefähr ein halbes Wort. Macht 48 Millionen Eingabe- und sechs Millionen Ausgabe-Token pro Monat. Bei drei US-Dollar je Million Eingabe- und 15 je Million Ausgabe-Token kostet ein Spitzenmodell der aktuellen Generation damit 234 US-Dollar. Für die komplette Ticketverarbeitung.
Kostenrechnung: Token-Preise begründen den Eigenbetrieb selten
Im niedrigen zweistelligen Bereich landet dieselbe Menge bei einem kompakten Cloud-Modell. Und der eigene Server? Anschaffung, Strom, Wartung, Betreuung – gegenüber 234 US-Dollar Cloud-Kosten amortisiert sich die Hardware nicht, weil bei diesem Volumen die meiste Zeit Leerlauf herrscht.
Kundendaten stecken in jeder einzelnen Anfrage – bei der Cloud-Nutzung verlassen sie das Haus. Das gibt den Ausschlag. Auch die Latenz und der Wunsch, ein bewährtes Modell einzufrieren, statt alle paar Monate hinter der nächsten Anbieterentscheidung herzulaufen, sprechen für eigene Hardware. Die GPU kommt also doch ins Haus. Das Whitepaper zeigt, wie Unternehmen On-Premise-KI strategisch planen und technisch umsetzen können.
Größenklasse: Der Speicherbedarf schlägt die Parameterzahl
Verbindlich definiert ist der Begriff Small Language Model nirgends. Zwischen hundert Millionen und fünf Milliarden Parametern – also den trainierten Werten, die das Modell ausmachen – zieht eine Messstudie den Rahmen. Von einer bis acht Milliarden reicht er in der nächsten Übersicht. Viel Spielraum für Marketing. Für den reinen Gewichtsspeicher gilt immerhin eine Faustregel: zwei Gigabyte je Milliarde Parameter bei halber Präzision, vier bei voller.
Aushebeln lässt sich diese Rechnung durch zusätzliche Modellbestandteile. Rund 16 Gigabyte umfasst der unquantisierte E4B-Checkpoint der Gemma-Familie, obwohl E4B nur vier Milliarden effektive Parameter bezeichnet. Schuld sind große Embedding-Tabellen für jede Modellschicht, nachzulesen in der Modellkarte. Es zählt in erster Linie der konkrete Checkpoint und nicht sein Name.
Hinzu kommt das Kontextfenster. Je länger die Eingabe, desto größer der KV-Cache – und mit ihm wachsen Speicherbedarf und Antwortzeit. Der Maschinenbauer misst deshalb mit den 1.200 Eingabe-Token, die er tatsächlich braucht, statt mit dem Maximum.
Aufgabenzuschnitt: Enge Zielräume sichern verlässliche Ergebnisse
Ein enger Zielraum und maschinell prüfbare Ergebnisse sprechen für ein kompaktes Modell. Tickets sortieren. Freitext in ein festes Schema übertragen. Definierte Programmfunktionen aufrufen – immer dieselben, immer nach demselben Muster. Bei der Textklassifikation schlagen kleinere, auf die Aufgabe trainierte Modelle sogar größere Zero-Shot-Modelle, wie eine Studie zeigt.
Heikel wird es bei offenen Anfragen, die mehrere Planungsschritte benötigen, verstreute Quellen zusammenführen sollen oder eine Fachdomäne betreffen, die im Training kaum vorkam. Das größte Risiko stellen aber Fehler dar, die keine Prüfroutine bemerkt. Selbst eine Übersicht zu agentischen Systemen, die ausdrücklich „SLM first“ empfiehlt, setzt für komplexere Fälle weiterhin auf den Wechsel zu einem großen Modell.
Benchmarks: Das Prompt-Format verschiebt Rangfolgen
Auf ARC-Challenge, GSM8K, MATH und TruthfulQA traten sieben Modelle der Familien Gemma, Phi und Qwen unter den gleichen Bedingungen an, nachzulesen in einer kontrollierten Vergleichsstudie. Vorn lag nicht das größte. 0,675 gewichtete Genauigkeit erreichte die Variante mit vier Milliarden effektiven Parametern – bei 14,9 Gigabyte Grafikspeicher. Ihre deutlich größere Schwester kam über 0,663 nicht hinaus und brauchte dafür 48,1 Gigabyte, also mehr als das Dreifache.
Was solche Ranglisten wert sind, zeigte dann ein simpler Wechsel des Prompt-Formats: Von 0,67 auf 0,11 sackte ein Reasoning-Modell auf GSM8K ab. Dieselben Aufgaben, dieselben Gewichte – geändert wurde nur die Prompting-Strategie. Ohne die verwendeten Prompts bleibt eine Rangliste deshalb kaum nachprüfbar. Hinzu kommt: Begutachtet ist die Vergleichsstudie nicht, sie liegt als Preprint vor.
Zur Vorauswahl reicht die Parameterzahl allein ohnehin nicht, weniger Parameter stehen darüber hinaus auch nicht automatisch für weniger Energieverbrauch. Auf Raspberry Pi 5 und Jetson-Boards entschieden GPU-Beschleunigung, Speicherbandbreite und Modellarchitektur, wie eine Messstudie demonstriert. Es bleibt nur der eigene Test – mit den eigenen Prompts auf genau der Hardware, die später zum Einsatz kommen soll.
Modellfamilien: Lizenz und Kontextfenster bestimmen die Auswahl
Vier Dinge entscheiden bei der Vorauswahl: Lizenz, Kontextfenster, Speicherbedarf unter realistischer Last und Reife des Ökosystems. Hersteller-Benchmarks helfen beim Sortieren, mehr nicht – die Vergleichsbasis sucht sich der Anbieter selbst aus.
| Modell | Größe | Merkmale | Lizenz |
|---|---|---|---|
| Gemma 4 E2B/E4B | 2 bis 4 Mrd. effektive Parameter, E4B-Checkpoint rund 16 GB | Multimodal, mit Daten in über 140 Sprachen vortrainiert, 128K Kontext | Apache 2.0 |
| Granite 4 Nano / Micro | 350 Mio. bis 3 Mrd. Parameter | RAG und Function Calling, je nach Variante Hybrid aus Mamba-2 und Transformer oder reiner Transformer | Apache 2.0 |
| Phi-4-mini | 3,8 Mrd. Parameter | Mathematik, Reasoning und Function Calling, 128K Kontext | MIT |
| Qwen3.5-2B | 2 Mrd. Parameter, Checkpoint rund 4,6 GB | Thinking- und normaler Antwortmodus | Apache 2.0 |
Ausgewählte kompakte Modellfamilien, Stand August 2026.
Frei herunterladbare Gewichte, aber trotzdem keine Open-Source-Lizenz – dieser Fall kommt häufiger vor, als Produktseiten vermuten lassen. Mal bleibt die kommerzielle Nutzung beschränkt, mal steht mit der nächsten Version etwas anderes im Kleingedruckten. Maßgeblich ist die Lizenz genau jener Modellversion, die später produktiv läuft.
Dieselbe Skepsis verdienen Herstellerzahlen. Über 70 Prozent Speicherersparnis bei langen Kontexten reklamiert IBM für Granite 4.2. Gegen welches Modell? Bei welcher Kontextlänge? Ohne Antwort bleibt es nur Werbung.
Feintuning: Adapter senken die Anpassungskosten
Alle Gewichte eines Modells anzupassen, kann sich kaum ein Mittelständler leisten. LoRA umgeht das: Die ursprünglichen Gewichte bleiben unangetastet, trainiert werden nur kleine Zusatzmatrizen daneben. QLoRA setzt solche Adapter auf quantisierte Grundmodelle und passt damit ein 65-Milliarden-Modell auf einer einzigen GPU mit 48 Gigabyte an.
Wann greift was? Für Fakten, die sich laufend ändern (Dokumente, Preise, Richtlinien), ist RAG zuständig. Feintuning bringt dem Modell bei, wie es antworten soll: Format, Stil, Fachbegriffe des Hauses, Werkzeugauswahl. Weniger kostet vor allem der Trainingslauf. Daten aufräumen, annotieren, testen, das Modell später pflegen – diese Posten fehlen in Projektplänen mit schöner Regelmäßigkeit.
Entscheidungsmatrix: Klare Kriterien lenken die Modellwahl
Spricht für kompakte Modelle
- Der Zielraum der Aufgabe ist klar begrenzt und beschreibbar
- Das Ergebnis lässt sich per Schema oder Regel automatisch prüfen
- Die Aufgabe fällt häufig und in ähnlicher Form an
- Ein repräsentativer Testdatensatz mit Fehlertaxonomie existiert
Spricht für größere Modelle
- Die Anfrage bleibt offen, mehrdeutig oder unvorhersehbar
- Die Aufgabe verlangt offene Schlussfolgerungen
- Jeder Fall verläuft anders und verlangt mehrstufige Planung
- Das Modell beherrscht die Fachdomäne im Test nur unzureichend
Bleibt die Zuordnung unklar, wandert die Aufgabe in den Eskalationspfad, bis ein eigener Test die Zuverlässigkeit des kompakten Modells belegt.
Systemarchitektur: Die Umgebung sichert das Ergebnis
Ein großes Sprachmodell einfach durch ein kleines zu ersetzen, schöpft dessen Vorteile noch nicht aus. Entscheidend ist vielmehr die gesamte Verarbeitungskette, bei der das kleine Modell klar abgegrenzte Aufgaben bekommt: Es klassifiziert Anfragen, extrahiert Informationen oder entscheidet, welches Werkzeug zum Einsatz kommt. Die Ein- und Ausgabe sind fest vorgegeben; RAG greift nur auf freigegebene Quellen zu. Und wenn das Modell unsicher ist, übernimmt ein größeres Modell oder ein Mensch. So bleibt der Spielraum für Fehler klein – und die Vorteile eines SLM kommen tatsächlich zum Tragen.
Eines gehört nie in den Prompt: die Berechtigungsprüfung. Wer ein Modell über Zugriffsrechte entscheiden lässt, kann durch präparierte Eingaben dessen Entscheidungen manipulieren. Die Berechtigungsprüfung muss deshalb im Code durchgesetzt werden – dort widersteht sie solchen Eingriffen. Mitzuschreiben sind außerdem Erfolgsrate, Fehlerklasse, Latenz und Kosten pro erfolgreicher Aufgabe. Fehlt dieses Protokoll, fehlt später der Maßstab für das Nachfolgemodell.
Regulierung: Die Anwendung bestimmt die Risikoklasse
Eine anwendungsspezifische Risikoanalyse empfehlen NIST AI 600-1 und das BSI, und zwar unabhängig davon, wo das Modell läuft. Als eigenen Angriffsweg führt das BSI manipulierte externe Datenquellen. Nach Anwendung, Rolle und Risikokategorie fragt auch die EU-Verordnung 2024/1689 – die bloße Parameterzahl entscheidet nicht.
Herkunft, Angaben zu Trainingsdaten und Lizenzbedingungen gehören ebenso in die Dokumentation wie die Laufzeitumgebung – vergleichbar mit dem Nachweis für Infrastruktur, siehe Infrastructure as Code: Der Testumzug beweist die Portabilität.
Auswahlverfahren: Ein Praxistest schlägt Hersteller-Benchmarks
Zwei bis vier Wochen dauert ein brauchbarer Praxistest, in dem mehrere Kandidaten auf einem eigenen Testdatensatz unter identischen Bedingungen antreten. Vier Kennzahlen kommen auf den Prüfstand: Zuerst zählt die Erfolgsquote bei der eigentlichen Geschäftsaufgabe. Danach wird geprüft, wie zuverlässig das Modell kritische Felder ausfüllt. Halluzinationsrate und Kosten pro gelöster Aufgabe gehören ebenfalls ins Protokoll.
Zwei Prüfungen beantworten Herstellerangaben selten: das Verhalten bei deutschen Fachtexten und die Robustheit im Fall von schlechten Vorlagen. Tippfehler, Scans, die mitten im Absatz abbrechen, Formate, die keiner Spezifikation folgen – so sehen Produktionsdaten in aller Regel aus. Genau daran scheitern Modelle, die im Benchmark glänzen.
Fazit: Kosten pro Vorgang schlagen jeden Benchmark
Was heißt das nun für den Maschinenbauer? Groß gegen klein ist die falsche Frage, der Token-Preis ebenfalls. Er muss zwischen zwei Architekturen wählen: Entweder erledigt ein einzelnes Modell alle Aufgaben – oder die Arbeit wird verteilt. Lokal läuft, was sich lokal erledigen lässt, während schwierige Fälle bei einem größeren Modell landen.
Drei Merkmale sprechen für ein kompaktes Sprachmodell: Die Aufgabe ist eng zugeschnitten, fällt oft an und eine Maschine kann das Ergebnis prüfen. Ob sich das rechnet, verrät keine Benchmark, sondern eine Zahl aus dem eigenen Betrieb: die Kosten für jeden erfolgreich abgeschlossenen Vorgang.
Autor: Stefan Kuhn