KI-Inferenz ohne Cloud: Was Anyway Systems für Handel & Bildung bedeutet

80 bis 90 Prozent der KI-Rechenleistung entfallen auf Inferenz – also auf das „Antworten“ eines Modells im laufenden Betrieb, nicht auf das Training. Genau dort entsteht in der Praxis der meiste Ärger: Kosten explodieren, Latenz nervt im Live-Betrieb, und bei sensiblen Daten wird’s schnell unangenehm.

Passend dazu kommt aus der Schweiz ein Ansatz, der vielen IT- und Digitalverantwortlichen im Einzelhandel und an Hochschulen sofort bekannt vorkommen dürfte: Warum schicken wir jede Anfrage in ein entferntes Rechenzentrum, wenn wir die Antwort auch lokal erzeugen könnten? Forschende der EPFL (Labor für verteilte Informatik) untersuchen mit Anyway Systems eine Alternative zur zentralisierten Cloud-Inferenz – mit koordinierten Ressourcen in lokalen Netzwerken.

Für unsere Serie „KI in Bildung und Forschung“ ist das mehr als ein Forschungshäppchen. Es ist ein Signal: KI-Infrastruktur wird wieder „greifbarer“ – und damit planbarer für Schulen, Universitäten, Retail-IT und E-Commerce-Teams, die 2026 nicht nur Prototypen, sondern stabile KI-Services brauchen.

Was „KI-Inferenz ohne Cloud“ wirklich heißt – und warum es jetzt relevant ist

KI-Inferenz ohne Cloud bedeutet: Anfragen werden lokal verarbeitet, ohne dass Daten und Prompts an externe Cloud-Modelle gesendet werden. Das ist nicht „anti Cloud“, sondern eine nüchterne Architekturoption – besonders dort, wo Datenhoheit, Latenz und laufende Kosten zählen.

Drei Gründe, warum das Thema im Dezember 2025 besonders heiß ist:

1. Datenschutz und Souveränität sind operativ geworden. Es geht nicht mehr nur um „Compliance“, sondern um die Frage, ob Kundendaten, interne Dokumente oder Lern- und Prüfungsdaten überhaupt die Organisation verlassen dürfen.
2. Inferenz ist der Dauerläufer im Budget. Training macht Schlagzeilen, Inferenz macht Rechnungen.
3. Retail und Bildung brauchen Echtzeit. Personalisierung am POS, Betrugserkennung, Nachfrageprognosen oder Tutor-Systeme im Learning Management: Wenn die Antwort zu spät kommt, ist sie wertlos.

Anyway Systems setzt genau dort an: lokale Ausführung von Open-Source-Modellen, koordiniert über mehrere Rechner – und so fehlertolerant, dass der Dienst auch bei Ausfällen weiterläuft.

Anyway Systems von der EPFL: Der Kernansatz in Klartext

Anyway Systems verteilt KI-Inferenz automatisch über mehrere verbundene Computer im lokalen Netzwerk. Statt eine einzelne „Monster-GPU“ vorauszusetzen, koordiniert die Software die vorhandenen Maschinen und hält den Dienst stabil.

Verteilte Inferenz statt zentraler „KI-Box“

Die EPFL beschreibt, dass Anyway Systems Open-Source-LLMs lokal betreiben kann, indem es die Rechenleistung mehrerer Rechner zusammenführt. Das ist für viele Organisationen attraktiv, weil es vorhandene Infrastruktur nutzt:

• GPU-Workstations aus Data-Science-Teams
• Server im lokalen Rechenraum
• dedizierte Maschinen im Filialnetz (Retail)
• Edge-Server in Campus- oder Behördennetzen

Selbststabilisierung: Nicht hübsch, sondern nützlich

Spannend ist der Hinweis auf Selbststabilisierungstechniken aus der verteilten Datenverarbeitung. Übersetzt: Das System ist darauf ausgelegt, weiterzulaufen, auch wenn einzelne Knoten ausfallen oder kurz „zicken“.

In der Realität ist genau das der Unterschied zwischen Demo und Betrieb:

• Eine Filiale verliert kurz die Verbindung zu einem Knoten.
• Ein GPU-Treiber hängt nach einem Update.
• Ein Rechner wird nachts neu gestartet.

Wenn die Inferenz dann komplett tot ist, ist KI im Handel sofort „unzuverlässig“ – und das Projekt politisch verbrannt.

Kosten- und Hardware-These: LLMs müssen nicht immer Rechenzentren bedeuten

Die EPFL nennt als Beispiel: Ein Modell wie „GPT-120B“ könne auf vier Rechnern mit Standard-GPUs betrieben werden – zu geschätzten Kosten von rund 10’000 Franken. Der Punkt ist weniger die exakte Zahl als die Botschaft: Die Untergrenze für produktive LLM-Inferenz sinkt, wenn man gut verteilt.

Pilotversuche zeigen laut EPFL leicht erhöhte Latenz ohne Genauigkeitsverlust. Das ist ein fairer Trade-off in vielen Szenarien – gerade dort, wo Datenabfluss oder Cloud-Abhängigkeiten schwerer wiegen als ein paar zusätzliche Millisekunden.

Was das dem Einzelhandel und E-Commerce konkret bringt

Für Retail und E-Commerce ist lokale Inferenz ein Architekturhebel, um Personalisierung, Analytics und Prozess-KI näher an Daten und Entscheidungspunkte zu bringen. Drei typische Anwendungsfelder profitieren sofort.

1) Personalisierung in Echtzeit: Empfehlungen, die nicht warten

Wenn ein Kunde im Onlineshop klickt oder in der Filiale per App scannt, zählt Tempo. Eine lokale Inferenz-Instanz kann:

• Session-basierte Empfehlungen erzeugen
• Produktfragen beantworten (Chat/Voice)
• Alternativen vorschlagen bei Out-of-Stock

Wichtig ist dabei weniger „KI-Magie“ als predictable latency. Cloud kann schnell sein – bis sie es nicht ist (Netzweg, Peaks, Rate-Limits). Ein lokales Cluster ist langweilig, aber zuverlässig.

2) Sensible Daten: Kundenservice, Reklamationen, interne Dokumente

Viele Händler wollen KI für:

• Zusammenfassung von Kundenanfragen
• Klassifikation von Reklamationsgründen
• Extraktion aus PDFs (Lieferanten, Verträge)

Der Knackpunkt: Sobald personenbezogene Daten oder vertrauliche Dokumente im Prompt landen, wird Cloud zur Governance-Frage. Lokale Inferenz reduziert Datenbewegung massiv – und macht Audits einfacher.

3) Bestandsmanagement & Nachfrageprognosen: KI näher an die Quelle

Filial- und Lagerdaten sind oft verteilt. Eine lokale oder regionale Inferenz-Schicht (z. B. pro Logistikzentrum) kann:

• Abweichungen in Abverkaufsmustern erkennen
• automatische Ursachenhypothesen liefern (Promotion, Wetter, lokale Events)
• Nachbestellvorschläge textlich begründen (wichtig für Akzeptanz)

Gerade in der Schweiz, wo Filialnetze häufig kompakt, aber heterogen sind, ist „lokal rechnen, zentral steuern“ ein realistischer Mittelweg.

Warum das auch für Bildung & Forschung ein realistischer Weg ist

In der Bildung ist lokale Inferenz nicht nur Datenschutz, sondern Didaktik. Wer KI an Schulen, Fachhochschulen oder Universitäten ernsthaft einführen will, braucht Systeme, die lehr- und prüfungstauglich sind.

Lernplattformen und Tutor-Systeme: Datenschutz ohne Feature-Verzicht

Ein KI-Tutor, der Aufgaben erklärt, arbeitet zwangsläufig mit:

• Leistungsdaten
• Lernständen
• ggf. sensiblen Inhalten (z. B. Förderbedarf)

Lokale Inferenz ermöglicht, solche Systeme on-prem oder campusnah zu betreiben – ohne dass jede Interaktion an Dritte geht. Für Hochschulen, die Forschungsdaten schützen müssen, ist das ebenso relevant.

Forschungspraxis: Reproduzierbarkeit und Kontrolle

In Forschungsprojekten ist Cloud oft ein Problem, weil:

• Modellversionen sich ändern
• Abhängigkeiten und Preise schwanken
• Protokollierung/Logging nicht frei gestaltet werden kann

Ein lokales Inferenz-Setup sorgt dafür, dass Experimente vergleichbar bleiben – und Studierende Infrastrukturkompetenz lernen, statt nur API-Nutzung.

Entscheidungshilfe: Wann lokale Inferenz sinnvoll ist (und wann nicht)

Lokale Inferenz lohnt sich, wenn Datenhoheit, stabile Kosten und kontrollierbare Latenz wichtiger sind als maximale Modellvielfalt. Ein pragmatischer Check:

Gute Kandidaten

• Verarbeitung sensibler Kundendaten (Support, CRM-nahe Workflows)
• interner Wissensassistent (Dokumente, Richtlinien, SOPs)
• Filial- oder Lageranalysen mit Echtzeitanforderungen
• Campus-KI für Lernplattformen und Forschung

Weniger gute Kandidaten

• stark schwankende Lastspitzen ohne Puffer
• Use-Cases, die ständig neue proprietäre Modelle brauchen
• Teams ohne Betriebskompetenz (Monitoring, Updates, Security)

Ein bewährtes Zielbild: Hybrid statt dogmatisch

Ich halte Hybrid-Architekturen für die realistischste Strategie 2026:

• lokal für sensible Daten und „always-on“ Prozesse
• Cloud für Experimente, sehr große Modelle oder saisonale Peaks

So verhindert man den typischen Fehler: Entweder „alles Cloud“ (und später Governance-Schmerz) oder „alles on-prem“ (und später Kapazitätsfrust).

Umsetzung in 30 Tagen: Ein Mini-Fahrplan für Retail-Teams

Wenn du das Thema testen willst, brauchst du kein Großprojekt – aber klare Kriterien. So würde ich starten:

1. Use-Case auswählen, der messbar ist (z. B. interne FAQ/Policy-Assistenz oder Reklamationsklassifikation).
2. Datenfluss skizzieren: Welche Daten landen im Prompt? Wo dürfen sie gespeichert werden? Wer darf Logs sehen?
3. Latenz-Ziel definieren (z. B. < 800 ms für Chat-Antwortstart, < 2 s für vollständige Antwort).
4. Hardware-Inventur: Welche GPUs/Server sind vorhanden? Welche stehen nachts ungenutzt?
5. Betrieb festlegen: Patch-Prozess, Monitoring, Zugriffskontrolle, Rollenmodell.
6. Erfolg messen (nicht nur „Accuracy“):
   • Bearbeitungszeit im Support
   • Abbruchraten im Chat
   • Kosten pro 1’000 Anfragen
   • Quote „Weiterleitung an Menschen“

Der wichtigste Satz fürs Steering Committee: „Wir testen nicht KI. Wir testen, ob Inferenz lokal zuverlässig betreibbar ist.“ Das ist eine andere Diskussion – und viel produktiver.

Was man aus der EPFL-Entwicklung jetzt mitnehmen sollte

Anyway Systems ist noch nicht „der Standard“ – aber die Richtung ist klar: Inferenz wird dezentraler, weil es ökonomisch, regulatorisch und technisch Sinn ergibt. Für den Handel bedeutet das: Personalisierung und Analytics müssen nicht zwangsläufig über Dritt-Clouds laufen. Für Bildung und Forschung bedeutet es: KI kann näher an Lernende, Lehrende und Daten – ohne den Kontrollverlust.

Wenn du 2026 Leads, Umsatz oder Studienerfolg mit KI verbinden willst, führt kein Weg an Infrastrukturfragen vorbei. Das Modell ist selten das Problem. Die Inferenz-Architektur entscheidet, ob KI im Alltag bleibt.

Zum Weiterdenken: Wenn Inferenz lokal wird – welche KI-Funktion würdest du als Erstes aus der Cloud zurückholen, weil sie zu nah an deinen sensiblen Daten ist?