Die Forderung klingt einfach: Österreichische Unternehmen sollen ihre KI selbst betreiben, damit vertrauliche Daten nicht zu amerikanischen Technologiekonzernen fließen. Technisch und wirtschaftlich ist die Entscheidung komplizierter. Ein Unternehmen kann ein offenes Modell auf einem Server in Wien ausführen und trotzdem von amerikanischen Chips, internationalen Softwarebibliotheken und einem ausländischen Modellhersteller abhängig bleiben.

„Eigene KI“ ist deshalb kein klarer Produkttyp. Der Begriff kann fünf sehr unterschiedliche Lösungen meinen.

  1. Ein Unternehmen nutzt ein großes Modell über eine Programmierschnittstelle und baut nur die eigene Anwendung.
  2. Es verwendet einen europäischen Anbieter mit regionaler Datenverarbeitung und vertraglichen Kontrollen.
  3. Es betreibt ein frei verfügbares Open-Weight-Modell in einer privaten europäischen Cloud.
  4. Es installiert das Modell auf eigener Hardware und verbindet es mit internen Daten.
  5. Es trainiert ein Basismodell von Grund auf.

Für fast alle österreichischen Unternehmen endet die wirtschaftlich vernünftige Auswahl bei Stufe vier. Das Training eines konkurrenzfähigen Grundmodells verlangt Daten, Rechenleistung und Forschungsteams, die sich nur für spezialisierte Anbieter, sehr große Konzerne oder staatlich koordinierte Vorhaben rechtfertigen lassen.

Der Hauptgrund ist Kontrolle, nicht der Server im Keller

Ein eigener Betrieb lohnt sich, wenn Kontrolle einen messbaren Geschäftswert hat. Das kann bei Betriebsgeheimnissen, Gesundheits- und Verwaltungsdaten, dauerhaft hoher Nutzung, strengen Antwortzeiten oder abgeschotteten Produktionsnetzen der Fall sein. Auch die Möglichkeit, ein Modell über Jahre in einer bekannten Version zu betreiben, kann für regulierte Prozesse wichtig sein.

Datenschutz allein erzwingt jedoch nicht automatisch Selbsthosting. Eine vertraglich abgesicherte API mit geeigneter regionaler Verarbeitung kann sicherer sein als ein schlecht gewarteter eigener Server. Ein System im Haus ist nur so souverän wie seine Updates, Zugriffsrechte, Protokolle, Backups und verantwortlichen Personen.

Der zweite Grund ist wirtschaftliche Planbarkeit bei hoher, gleichmäßiger Last. API-Anbieter verrechnen meist nach Eingabe- und Ausgabetokens. Eigene Hardware verursacht dagegen auch dann Kosten, wenn niemand sie nutzt. Je unregelmäßiger die Nachfrage, desto stärker spricht die Auslastungslogik für eine API oder elastische Cloud. Je stabiler und höher die Last, desto eher kann ein eigener Betrieb günstiger werden.

LLM oder SLM?

Ein großes Sprachmodell ist sinnvoll, wenn Aufgaben stark variieren, komplexes Schlussfolgern erfordern oder viele Sprachen und Werkzeuge verbinden. Ein Small Language Model kann für eng begrenzte Aufgaben wirtschaftlicher und kontrollierbarer sein: Klassifikation, Extraktion, interne Suche, standardisierte Entwürfe oder lokale Assistenz.

Klein bedeutet nicht automatisch zuverlässig. Ein SLM muss mit den tatsächlichen Fällen des Unternehmens getestet werden. Für manche Aufgaben ist ein regelbasiertes Verfahren ohne generative KI weiterhin die bessere Lösung.

Der aktuelle offene Modellmarkt bietet mehrere Klassen:

  • Kleine Modelle mit ungefähr drei bis 14 Milliarden Parametern: etwa Ministral-Varianten. Sie eignen sich für fokussierte Aufgaben, geringere Latenz und begrenzte Hardware.
  • Mittlere offene Modelle: beispielsweise gpt-oss-20b. OpenAI gibt an, dass eine quantisierte Variante mit rund 16 GB Speicher betrieben werden kann. Das macht Tests auf leistungsfähigen Workstations möglich; Produktion verlangt trotzdem Betrieb und Absicherung.
  • Große offene Modelle: etwa Mistral Large 3 oder gpt-oss-120b. Für gpt-oss-120b nennt OpenAI eine 80-GB-GPU als mögliche Einzelkarten-Konfiguration. Hohe Parallelität, Redundanz und lange Kontexte können den Bedarf deutlich erhöhen.
  • Kommerzielle Spitzenmodelle per API: sinnvoll für komplexe Aufgaben, bei denen Qualität wichtiger ist als vollständige Kontrolle der Modellgewichte.

Die Auswahl darf nicht anhand eines öffentlichen Benchmarks erfolgen. Ein österreichischer Betrieb braucht einen eigenen Testsatz: echte Dokumente, Dialekt- und Fachbegriffe, typische Fehlerfälle, erwartete Quellen und klare Abbruchkriterien.

Was kostet der Unterschied?

API-Kosten können erstaunlich niedrig sein. Mistral listete zum Stichtag für Mistral Small 4 Preise von 0,15 Dollar je Million Eingabetokens und 0,60 Dollar je Million Ausgabetokens. OpenAI listete für sein leistungsfähigstes allgemeines Modell deutlich höhere Tokenpreise; effiziente Modelle lagen wesentlich darunter. Preise ändern sich häufig und sagen ohne Nutzungsprofil wenig aus.

Ein transparentes Rechenbeispiel: 100.000 monatliche Vorgänge mit jeweils 4.000 Eingabe- und 1.000 Ausgabetokens ergeben 400 Millionen Input- und 100 Millionen Outputtokens. Beim genannten Mistral-Small-Preis lägen die reinen Modellkosten rechnerisch bei rund 120 Dollar pro Monat. Beim zum Stichtag gelisteten Standardpreis eines Spitzenmodells von 5 Dollar Input und 25 Dollar Output wären es rund 4.500 Dollar. Nicht enthalten sind Suche, Speicherung, Software, regionale Aufschläge, Support und Entwicklung.

Selbsthosting ersetzt diese Tokenrechnung durch eine Gesamtkostenrechnung:

  • GPU oder Cloudinstanz;
  • Strom, Kühlung und Reservekapazität;
  • Inferenzsoftware und Monitoring;
  • IT-Sicherheit und Identitätsverwaltung;
  • Updates, Tests und Modellwechsel;
  • Bereitschaft und Fehlerbehebung;
  • Personal für Daten, Integration und Fachprüfung.

Eine einzelne Workstation kann einen Prototyp betreiben. Ein Produktionsdienst benötigt je nach Kritikalität Redundanz, Backups, Überwachung und einen vereinbarten Wiederanlauf. Der vermeintlich kostenlose Download eines offenen Modells ist daher nur der Beginn der Rechnung.

Für wen zahlt sich welcher Weg aus?

Kleinstunternehmen: In der Regel ist kein eigener Modellbetrieb sinnvoll. Ein geprüftes Standardprodukt oder eine API mit klaren Einstellungen ist günstiger. Ausnahmen sind Unternehmen, deren Produkt selbst KI ist oder die offline an einem sensiblen Spezialfall arbeiten.

KMU: Ein hybrider Weg ist meist am besten. Allgemeine Aufgaben laufen über einen vertraglich kontrollierten Dienst; sensible, häufige oder klar begrenzte Aufgaben können mit einem kleinen privaten Modell getestet werden. Der Betrieb sollte bei einem spezialisierten europäischen Infrastrukturpartner liegen, wenn intern kein Team vorhanden ist.

Große Unternehmen und Konzerne: Sie können mehrere Modelle routen: kleine Modelle für Routine, Spitzenmodelle für schwierige Fälle, private Systeme für sensible Daten. Eigener Betrieb lohnt sich dort, wo Volumen, Schutzbedarf und internes Plattformteam zusammenkommen.

Ministerien und öffentliche Einrichtungen: Private oder gemeinsame staatliche Infrastruktur kann wegen Rechtsdurchsetzung, Kontinuität und sensibler Daten sinnvoll sein. Sie braucht jedoch transparente Beschaffung, unabhängige Kontrolle und klare Beschwerdewege. Ein staatlicher Server macht eine Entscheidung nicht automatisch legitim.

Der österreichische Weg ist hybrid

Vollständige Unabhängigkeit von großen Technologiekonzernen ist kurzfristig unrealistisch. Chips, Modellforschung und Softwarewerkzeuge sind global verflochten. Österreich kann dennoch strategische Handlungsfähigkeit gewinnen: europäische Rechenzentren, offene Modellgewichte, austauschbare Schnittstellen, eigene Datenbestände und Verträge mit echten Exit-Rechten.

A1 und Exoscale positionieren sich als europäische Infrastruktur. Mistral bietet offene und kommerzielle Modelle aus Europa. OpenAI stellt mit gpt-oss ebenfalls offene Gewichte bereit. Entscheidend ist nicht das Herkunftsmarketing, sondern die Architektur: Kann ein Unternehmen das Modell wechseln, ohne Wissen, Prozesse und Daten neu aufzubauen?

Der häufigste Fehler wäre, zuerst Hardware zu kaufen. Der bessere Weg beginnt mit einem begrenzten Anwendungsfall, einem Testsatz und drei vergleichbaren Varianten: günstige API, europäisch verwalteter Dienst und privater Modellbetrieb. Erst danach fällt die Infrastrukturentscheidung.

Entscheidungsregel

Selbsthosting wird prüfenswert, wenn mindestens drei Bedingungen zusammenkommen:

  • besonders sensible oder abgeschottete Daten;
  • dauerhaft hohes und planbares Volumen;
  • strenge Anforderungen an Latenz oder Offline-Betrieb;
  • Bedarf an einer stabilen, eigenen Modellversion;
  • vorhandenes Team für sicheren Betrieb und Evaluation.

Fehlt das interne Team, ist Eigenbetrieb kein Souveränitätsgewinn, sondern ein neues Betriebsrisiko.

Quellen und Arbeitsstand