Die Zukunft der AI-Forschung: vom Rezept zum Meal Kit

Kernaussagen (TL;DR)

• Explosion bei AI-Papers = Fortschritt + zugleich eine „Noise Tax“

  • 2013 → 2023 jährliche AI-Papers: ~102.000 → ~242.000
  • Im selben Zeitraum Anteil von AI an allen CS-Papers: 21,6 % → 41,8 %

• Je mehr Papers erscheinen, desto stärker explodieren die Kosten für Auswahl/Reproduzierbarkeit/Betrieb

  • Es wird mehr gelesen, aber Produkte werden weniger stabil
  • Je stärker man SOTA hinterherläuft, desto schlechter werden Reproduzierbarkeit und Betriebsfähigkeit

• Wenn man Papers in Produktion bringt, tauchen fast immer vier Fehlermodi auf

• Deshalb ist das Signal für 2026 einfach:
  DIY (Rezept selbst umsetzen) ↓ / Packaging (Meal Kit) ↑

  • Statt „Paper lesen und implementieren“ gewinnt die sofort deploybare Einheit
  • Packaging wie NVIDIA NIM / SLM / Ollama schafft eine Bewegung hin zur Standardisierung

---

Problemdefinition: AI-Papers sind „Michelin-Rezepte“

Der Autor vergleicht AI-Forschungspapiere mit Rezepten von Michelin-Köchen.
Das Rezept selbst ist nicht das Problem. Nur unsere Küche ist eine andere.

Papers entstehen in einer perfekten Küche.

• H100-Cluster
• sauber aufbereitete Datensätze
• versteckte Tricks, optimiert für die Experimentierumgebung

Sobald dieses Rezept jedoch in die Praxis kommt (On-Prem, Legacy, Compliance, Betrieb), wiederholt sich dasselbe Muster.

---

Vom Paper zur Produktion: 4 Fehlermodi

1) Broken Utensils (Infrastruktur)

• Paper-Ergebnisse basieren auf Tausenden von H100-GPUs

• Die Realität sind kleine GPUs / begrenzter VRAM / eingeschränkte Netzwerke

• Das Problem ist nicht „die Performance sinkt ein wenig“
  → Das Phänomen selbst tritt gar nicht auf

• Häufige Symptome:

  • „Es läuft zwar, aber das erwartete Verhalten fehlt“
  • Die Pipeline endet erfolgreich, aber das promised behavior erscheint nicht

2) Spoiled Ingredients (Daten)

• Papers setzen bereinigte Daten voraus

• Reale Daten vor Ort sind:

  • Logs, gescannte PDFs, Legacy-Dokumente, Schema-Änderungen, unklare Herkunft

• RAG/Inferenz kippt sofort in Halluzinationen, wenn Struktur, Belege oder Konsistenz brechen

• Noch gefährlicher ist:

  • Es wirkt flüssig und überzeugend, daher glaubt man es eher
  • „Sieht plausibel aus, ist aber falsch“ ist am teuersten

3) Missing Salt (Engineering-Details)

• Der Bereich „Season to taste“ ist der größte

• Die eigentlichen Entscheidungspunkte sind:

  • Initialisierung / Scheduler / Feintuning in 0,001-Schritten / Prompt-Templates

• So etwas passt nicht auf 8 Paper-Seiten

• In der Praxis trennt sich genau hier die Spreu vom Weizen:

  • Nicht das Rezept, sondern die geheime Würzung (Bedingungen für Reproduzierbarkeit) entscheidet über das Ergebnis

4) Responsibility Gap (Verantwortung)

• Wenn es scheitert, lautet das Fazit oft so:

  • „Die Mathematik stimmt. Das Problem ist eure Umgebung.“

• Die Verantwortung für diese Lücke wandert nach unten im Stack
  → Am Ende trifft es die Person, die das Paper gelesen und empfohlen hat.

• Kommt es zu Ausfällen oder Audits, ist es plötzlich „das System, das wir gebaut haben“

---

Zwei strukturelle Grenzen: Warum man DIY aufgibt

A) Paper-Explosion = Noise Tax

Je mehr Papers erscheinen, desto stärker explodieren die Auswahlkosten.

• Es wird mehr gelesen, aber Produkte werden weniger stabil
• Je stärker man SOTA hinterherläuft, desto schlechter wird die Betriebsfähigkeit
• Das ist kein „Wissensreichtum“, sondern ein „Auswahlkostenproblem“

B) Veränderung der Kapitalrichtung: „Paper“ → „Betrieb“

Geld wandert von „neuen Rezepten“ hin zu betriebsfähigen Paketen.
Auch die Investitionsfrage hat sich verändert.

• Demo oder Betrieb?
• Sind Kosten/Latenz/Observability/Auditierbarkeit beherrschbar?

Betriebsrisiken laufen meist auf diese drei Punkte hinaus:

• Kostenrisiko: Als PoC funktioniert es, im Betrieb explodiert es
• Vertrauensrisiko: Wenn Belege oder Quellen brechen, ist auch eine plausibel klingende Antwort riskant
• Verantwortungsrisiko: Bei Ausfällen oder Audits liegt die Verantwortung bei uns

---

Das stärkste Signal für 2026: Packaging

AI Meal Kit = Ready-to-deploy + eine Deployment-Einheit mit klarer Grenze der Verantwortung im Fehlerfall

Das Fazit für 2026 lautet also:

> Packaging beats ingenuity.

Vier Marktsignale

Signal #1) NVIDIA NIMs

• Modellkonfiguration, Abhängigkeiten und Optimierungen sind im Container fixiert
• Weniger Rätselraten bei der Toolchain
• Die geheime Würzung ist bereits enthalten.
• Die Botschaft: „Tune less. Run more.“

Signal #2) SLMs

• Es gibt mehr „Rezepte, die zur eigenen Küche passen“
• Die Möglichkeit für lokalen Betrieb und Edge-Betrieb steigt
• Die Richtung ist: bounded / predictable / cheaper to operate

Signal #3) AI in a Box

• Server werden nicht mehr als „Bauteile“, sondern als „fertige Produkte“ verkauft
• Inklusive RAG, Sicherheit und Grundeinstellungen
• Effekt: Es entsteht eine klare Grenze dafür, wer die Lücke verantwortet

Signal #4) Ollama / LM Studio

• Die Schwierigkeit der Einrichtung sinkt stark
• Die Zahl der Betreiber steigt
• Wenn es mehr Betreiber gibt, entwickelt sich der Markt immer gleich: Die Standardisierung beschleunigt sich

---

Praxisperspektive: Indikatoren auf einen Blick

• Compute Fit: Lässt sich die Ziel-Performance auf „unserer GPU/unserem VRAM“ reproduzieren?
• Data Fit: Bleiben bei den Eingabedaten „Struktur/Belege/Quellen“ erhalten?
• Hidden Salt: Sind die für die Reproduktion nötigen Skripte/Prompts/Tuning-Werte versionsfixiert?
• Owner: Wo liegt die Verantwortungsfläche, wenn etwas scheitert? (bei uns? beim Vendor? beim Paket?)
• Ops: Sind Observability (Logs/Metriken), Rollback, Kostenobergrenzen und Auditierbarkeit im Design enthalten?

---

Fazit

2026 gewinnt nicht das „intelligentere Modell“, sondern
die Deployment-Einheit, die seltener explodiert.

Papers werden weiter erscheinen, aber der Markt kauft verpackte Intelligenz.
Auch Teams müssen sich entscheiden.

• ob sie weiter Rezepte implementieren
• oder auf Meal-Kit-Niveau paketieren und betreiben

One-liner

> „Papers verkaufen Ideen, der Markt kauft Betrieb.“