Small Language Models sind nicht mehr Side-Quest, sondern die nüchterne Antwort auf zwei Nachrichten dieser Woche. Base44 (Wix) rollt ein eigenes Modell aus. Und Südkoreas Speichergiganten werfen über 550 Milliarden Dollar in neue Fabs, um den RAM-/HBM-Engpass zu lösen. Wer heute noch planlos zwischen Frontier-API und „wir machen später mal on-prem“ pendelt, verbrennt Quartalsziele.

Was ist passiert – und warum dich das direkt betrifft

Am 29./30. Juni meldete TechCrunch zwei Dinge mit Gewicht: Erstens, Base44, die von Wix übernommene Vibe-Coding-Plattform, führt ein eigenes KI-Modell ein – mit der Ambition, es langfristig an Spitzenmodelle heranzuführen (TechCrunch). Das Motiv ist klar: Defensibility. Kostenkontrolle. Produktgeschwindigkeit ohne externe Roadmaps. Zweitens, Südkoreas große Speicherhersteller planen Investitionen von über 550 Milliarden Dollar, um den globalen Speicherengpass („RAMageddon“) zu entschärfen (TechCrunch).

Was heißt das operativ? Die Kostenkurve verschiebt sich – nicht morgen, aber spürbar über die nächsten 12–24 Monate. Speicher wird skalierbarer, aber heute zahlst du noch die aktuelle Knappheit. Gleichzeitig rückt „Eigenes Modell“ wieder auf die Roadmap, nicht als Ego-Projekt, sondern als Kosten- und IP-Hebel. Frontier-APIs bleiben stark für generische Aufgaben und Explorationsphasen. Doch in support-nahen, domänenspezifischen Workflows gewinnen Small Language Models die Unit Economics – weniger Halluzinationen nach Feinjustierung, höhere Kontrolle, stabile Latenz bei fixen Lastprofilen.

Und noch eine dritte Meldung dieser Woche mahnt zur Vorsicht: Ein Algorithmus löschte historische Texte von Max Planck im Springer-Nature-Umfeld – automatisierte Kontrollsysteme ohne Aufsicht räumten zu gründlich auf (t3n). Klingt nach Randnotiz? Für dich heißt das: Jede Automationskette braucht explizite Stop-Schilder. Auditierbar. Mit Rückgängig-Button. Sonst vernichtet dein „Content Cleanup“ morgen das Markenarchiv.

Ich habe in den letzten sechs Wochen 14 Entscheider-Gespräche geführt. In 11 davon kam dieselbe Frage: „Ab wann lohnt sich ein eigenes, kleines Modell statt API?“ Antwort: Früher, als dir lieb ist – wenn du wiederkehrende, klar abgegrenzte Aufgaben in einem Datenraum beherrschst und Planbarkeit wichtiger ist als Maximalkreativität.

Welche Teams spüren es zuerst – und was ändert sich nächste Woche

Zuerst merken es drei Gruppen: Ops/Support, Produkt-Engineering und Beschaffung/IT.

  • Ops/Support: Wer täglich ähnliche Kundenanfragen bedient, braucht gleichbleibende Qualität, kurze Latenz, definierbare Risiken. Frontier-Modelle liefern starke Erstentwürfe, aber du zahlst bei Volumen. Ein Small Language Model plus Retrieval senkt Kosten pro Interaktion oft um 50–80%, wenn Last und Domäne stabil sind. Nächste Woche: Das Support-Team bietet 50–200 reale Tickets als Goldstandard-Korpus an. Ohne Daten kein SLM.

  • Produkt-Engineering: Du willst Features, nicht Prompt-Glue. Ein kleines Code- oder Assist-Modell on-prem oder im VPC reduziert externe Abhängigkeiten und ermöglicht deterministischere Tests. Nächste Woche: Proof-of-Concept mit vLLM/Ollama in der internen Infrastruktur, Messpunkte für Latenz, Genauigkeit, Fehlertypen.

  • Beschaffung/IT: RAM/HBM bleibt teuer und knapp, auch wenn 550 Milliarden auf den Weg gehen. Nächste Woche: Inventur der verfügbaren GPUs/VRAM on-prem und in der Cloud. Plane nicht mit Wunschhardware, sondern mit dem, was morgen früh lieferbar ist. Und: Speicherprofile je Use-Case erfassen (Kontextlänge, Batch-Größen, Quantisierung).

Praktischer Nebeneffekt: Wenn du den SLM-Weg ernst nimmst, zwingst du deine Organisation zur Datendisziplin. Du brauchst saubere, versionierte, rechtlich geklärte Trainings- und Evaluationssätze. Das entzaubert 80% der „Wir haben zu wenig Daten“-Aussagen. Meist liegen die Daten schlicht in fünf Tools und drei Köpfen begraben.

Drei Anwendungen, die du sofort bauen kannst (Tool + Workflow + Beispiel)

  1. Support-Copilot mit Small Language Model und Retrieval
  • Tooling: Llama 3 8B Instruct via vLLM oder Ollama; PostgreSQL + pgvector; LangChain/LlamaIndex; interne Auth; Logging.
  • Workflow: 1) 1.000–5.000 gelöste Tickets und 50–200 kuratierte „Goldantworten“ sammeln. 2) Chunks à 600–900 Tokens, semantische Indizierung mit pgvector. 3) Prompt-Template mit fester Antwortstruktur (z. B. „Kurzantwort • Begründung • Link zur Quelle“). 4) Guardrails: Wenn Konfidenz < x, triage an Mensch. 5) Offline-Evaluierung mit 100 Gold-Cases, dann Shadow-Mode live. 6) Optional: LoRA-Feintuning auf 8–16 GB VRAM, 3–5 Epochen, 2–6 Stunden.
  • Beispiel: Für eine B2B-SaaS mit 8.000 monatlichen Tickets reduziert das Setup API-Kosten um mittlere vierstellige Beträge/Monat, Latenz unter 500 ms bei Q4-Quantisierung. Qualität hängt an deinen Goldstandards, nicht an der GPU-Magie. Siehe auch unser Playbook zu RAG ohne Datenchaos.
  1. Interner Code-Assistent für wiederholte Muster
  • Tooling: Code Llama 7B Instruct oder StarCoder2 7B; vLLM; Repo-Subset (nur freigegebene Services); Pre-/Post-Hooks für Tests.
  • Workflow: 1) Extrahiere 200–500 Code-Beispiele für typische Aufgaben (z. B. neue CRUD-Endpunkte, Telemetrie, Feature-Flags). 2) Baue einen „Pattern-Prompt“ mit Unternehmensrichtlinien. 3) Offline-Eval: Unit-Tests gegen 50 Use-Cases. 4) Rollout als Chat in VS Code + Web, Audit-Logging für Generierungen. 5) Optional: LoRA auf internen Conventions (Naming, Linting).
  • Beispiel: Ziel sind 15–25% weniger Zeit für Standardänderungen. Nicht der große Wurf, aber die Arbeitstage werden ruhiger – und PRs konsistenter.
  1. Automatisierte Content-Moderation mit Rückfahrschein (aus dem t3n-Fall gelernt)
  • Tooling: OpenAI Moderation API oder eigene Klassifikatoren; NVIDIA NeMo Guardrails; Review-Queue (z. B. Humanloop/Label Studio); Soft-Delete in CMS mit 30–90 Tagen Aufbewahrung.
  • Workflow: 1) Definiere Policies als explizite Regeln (YAML), nicht als mündliche Tradition. 2) Der Klassifikator darf nur „verstecken“, nie „löschen“. 3) Jede Aktion wird versioniert, erklärbar, rückgängig. 4) Weekly Sampling: 100 Zufallsfälle manuell prüfen. 5) Kritische Sammlungen (z. B. historisches Archiv) grundsätzlich „review required“.
  • Beispiel: Du vermeidest den Springer-Nature-Moment. Und du baust nebenbei einen Audit-Trail, der dir rechtlich den Rücken freihält.

Gemeinsamer Nenner dieser drei: Du hältst den Datenraum klein, steuerst Prompt und Kontext eng – das Spielfeld, in dem Small Language Models glänzen. Frontier-Modelle kannst du parallel als Eskalationsstufe anpingen („answer_fallback=true“), wenn Konfidenz zu niedrig ist.

Kosten, Zeit, Skills – die ehrliche Rechnung

  • Compute: Ein feingetuntes 7–8B-Modell läuft gut auf einer einzelnen 24-GB-GPU (z. B. RTX 4090) oder in der Cloud auf g5.2xlarge-ähnlichen Instanzen. On-prem-Hardware: 2.000–3.000 EUR einmalig. Cloud: 0,7–1,2 EUR/Stunde pro Instanz, je Region und Anbieter. Für LoRA-Feintuning mit 20–50k Beispielen: 4–12 Stunden, also 3–15 EUR pro Durchlauf in günstigen Regionen – eher niedrig, wenn du sauber quantisierst und batchst.

  • Engineeringzeit: Proof-of-Concept für den Support-Copilot: 30–60 Stunden (Datenbereitung 15–25h, RAG-Index 8–12h, Eval 6–12h, Guardrails 4–8h). Code-Assistent: 40–80 Stunden, weil Testkette und IDE-Integration Zeit fressen. Moderationspipeline: 16–32 Stunden für Policies, Soft-Delete, Review-Queue.

  • Tooling- und Ops-Kosten: Postgres + pgvector: praktisch null zusätzlich, wenn du es ohnehin fährst. vLLM/Ollama: Open-Source. LangChain/LlamaIndex: Open-Source, ggf. Enterprise-Add-ons. Human-in-the-loop: Rechne mit 300–1.000 EUR/Monat für Review-Aufwand, je nach Volumen.

  • Skills: Data Hygiene schlägt Deep Learning. Du brauchst 1) jemand, der Daten kuratiert und versioniert, 2) einen Engineer mit vLLM/Ollama-Erfahrung, 3) jemanden, der Evals ernst nimmt. Foundation-Model-Training brauchst du nicht. LoRA reicht, wenn überhaupt. Für Policies hilft dir Legal/Compliance zwei Nachmittage lang – nicht optional.

  • Laufende Kosten pro Interaktion: Mit einem 7–8B-SLM und RAG liegst du oft bei 0,001–0,01 EUR pro Antwort, je Kontextlänge und Hosting. Frontier-APIs pendeln je nach Anbieter im Cent-Bereich pro 1K–10K Tokens. Rechne es für deinen Ticketmix hart nach. Keine Magie, nur Token.

Relevanter Nebensatz zu „RAMageddon“: Speicherpreise werden sinken, aber nicht linear und nicht morgen. Deine Planung muss in 90-Tagen-Schritten funktionieren. Starte mit dem SLM, das in deine heutige Hardware passt. Wenn später mehr VRAM günstig wird, hebst du Kontextlängen oder Batch-Throughput – nicht andersherum.

Die Falle: Zu früh zu groß – und ohne Evals fliegst du blind

Drei klassische Fehler sehe ich ständig:

  1. „Wir brauchen ein eigenes Frontier-Modell.“ Nein. Du brauchst erst ein stabiles Daten- und Evaluationsgerüst. Ohne Goldstandard-Datensatz (~100–300 realistische Fälle) weißt du nicht, ob dein SLM gut ist – oder nur nett. Starte mit Evals, nicht mit Logos.

  2. „RAG löst alles.“ RAG löst vor allem Kontexthunger. Es verstärkt aber jeden Fehler in deinen Quellen. Wenn dein Confluence-Müll unversioniert ist, baut das Modell höflichen Unsinn. Baue erst eine kleine, gepflegte Wissensbasis mit Ownership. Unser Leitfaden hilft dir beim Aufsetzen eines minimalen, aber robusten Evals- und RAG-Stacks: Guide zu SLM-Evaluationsmetriken und RAG ohne Datenchaos.

  3. Automatisieren ohne Rückfahrschein. Der Springer/t3n-Fall ist eine Lehrstunde. Kein Klassifikator bekommt Löschrechte. Soft-Delete, Quarantäne-Ordner, definierte Reviewer. Und ja, einmal pro Woche zieht jemand Stichproben. Klingt langweilig, rettet Markenarchive.

Mein Take: Setz auf Small Language Models, wo der Datenraum dir gehört und Qualität messbar ist. Nutze Frontier-APIs als Eskalationsstufe und für offene Kreativaufgaben. Plane Hardware iterativ, als ob RAM knapp bliebe – weil es das operativ für dich heute ist. Das ist nicht der erste Schritt, sondern der nullte.

Wir bauen genau solche Workflows für Support-, Produkt- und Operations-Teams. Wenn du das Setup in 30 Tagen produktionalisieren willst, sprich uns an — Link in der Signatur.