Lokaler KI-Betrieb im Mittelstand: Was von Maartens Klassiker nach drei Jahren bleibt
Maschinenbauer, 90 Mitarbeitende, Südwestdeutschland. Der Geschäftsführer kommt mit einem ausgedruckten Blogartikel ins Erstgespräch — genau dieser hier, von Maarten Balliauw, handgeschrieben unterstrichen an drei Stellen. "Wir wollen das intern betreiben. Kein OpenAI, keine Cloud, keine monatliche Rechnung." Ich nicke. Ich kenne dieses Gespräch. Es kommt in meinen Mandaten alle paar Monate vor, und es endet fast immer anders als erwartet.
Nicht weil der Artikel falsch wäre. Sondern weil er aus einer Welt kommt, in der jemand technisch versiert ist, Spaß an C# hat, und "es läuft" als Erfolgskriterium gelten lässt. Im Mittelstand braucht es mehr als das.
Was Balliauw beschreibt
Maartens Artikel von Juni 2023 ist technisch sauber und hatte zum Erscheinungszeitpunkt echten Neuigkeitswert. Er zeigt, wie man mit LlamaSharp — einem .NET-Binding für Georgi Gerganovs llama.cpp-Framework — ein quantisiertes Sprachmodell (WizardLM, 7 Milliarden Parameter, ca. 4 GB auf der Festplatte) direkt auf dem eigenen Rechner betreibt. Kein API-Key, kein Stripe-Konto, kein Azure. Der Artikel führt durch Download, NuGet-Installation und eine vollständige Chat-Session in C#.
Das war 2023 nicht selbstverständlich. CPU-Inferenz mit akzeptabler Geschwindigkeit hatte sich gerade erst aufgetan — llama.cpp war wenige Monate alt, und dass das überhaupt funktionierte, war technisch bemerkenswert. Balliauw erklärt das ehrlich, inklusive der damaligen Einschränkungen: kein macOS-Support, Speicherbedarf bis 10 GB. Ein fairer Einstieg für Entwickler, die wissen wollen, was technisch möglich ist.
Wie das in einem KMU wirklich landet
Ich sage das ohne Ironie: Das technische Grundprinzip stimmt. Aber der Weg vom funktionierenden Proof-of-Concept zum produktiven Einsatz in einem Unternehmen mit 50 bis 250 Mitarbeitenden hat drei blinde Flecken, die in einem Entwicklerartikel systembedingt nicht auftauchen.
Erstens: Das Kostenargument hält selten einer ehrlichen Rechnung stand.
"Kein OpenAI" klingt nach Sparen. Aber was kostet lokaler Betrieb wirklich? Für 20 Mitarbeitende, die ein Modell mehrmals täglich nutzen, brauchst du GPU-Hardware — eine NVIDIA RTX 4090 oder besser, je nach Modellgröße. Das sind 1.500 bis 4.000 Euro einmalig. Dazu kommen Strom, Kühlung, Wartung und — was fast immer vergessen wird — die Personalzeit für Updates, Monitoring und den ersten Absturz um 17:45 Uhr an einem Freitag. Dagegen: Die OpenAI-API kostet für ein 100-Personen-Unternehmen mit moderatem Nutzungsverhalten selten mehr als 150 bis 300 Euro im Monat. Wer rechnet das wirklich durch?
Zweitens: LlamaSharp hat eine Stabilitätshistorie, die man kennen sollte.
Zwischen Version 0.3.0 — dem Stand des Artikels — und den aktuellen Releases hat sich die API mehrfach substanziell verändert. In einem Mandatsprojekt hatten wir Ende 2024 eine interne .NET-Lösung auf einer älteren LlamaSharp-Version — das Upgrade hat uns sechs Personentage Rewriting gekostet. Nicht katastrophal, aber auch kein Randnotiz. Wer eine Kernanwendung auf einem sich schnell ändernden OSS-Binding aufbaut, muss das als Risikoposition einpreisen.
Drittens: Was der Artikel ausspart, ist der Betrieb selbst.
Wie aktualisierst du das Modell, wenn ein besseres erscheint? Wie skalierst du auf fünf gleichzeitige Nutzer? Wie loggst du Anfragen so, dass du im Streitfall weißt, was die KI deinen Mitarbeitenden konkret geraten hat? Das sind keine Exotenfragen — das sind die Fragen, die in jedem ernsthaften Einsatz innerhalb von 90 Tagen auftauchen. Und sie tauchen in Entwicklertutorials strukturell nicht auf, weil die Zielgruppe dort Einzelpersonen mit Laptops sind, keine Betriebe mit Haftungsrisiken.
Was sich wirklich lohnt — und für wen
Lokale LLMs im Mittelstand sind keine schlechte Idee. Aber das "Warum" muss stimmen.
Sinnvoll, wenn: - Du in einer regulierten Branche arbeitest — Medizin, Recht, Steuerberatung — und Daten physisch nicht das Haus verlassen dürfen. Nicht aus Paranoia, sondern weil das eure Haftungsgrundlage ist. - Ihr Batch-Verarbeitung macht: Dokumente klassifizieren, Belege auslesen, Reports strukturieren — Prozesse, die nachts laufen und keine Echtzeit-Qualität benötigen. - Jemand im Haus diese Aufgabe wirklich bekommt. Nicht "der IT-Kollege macht das nebenbei".
Nicht sinnvoll, wenn: - Das primäre Argument "kostenlos" ist. Das stimmt nach vollständiger Rechnung fast nie. - Ihr erwartet, die Ausgabequalität von GPT-4o zu erreichen. Lokale 7B-Modelle sind deutlich besser geworden — aber für komplexe, nuancierte Aufgaben ist die Lücke noch real. - Niemand im Haus weiß, was eine GGUF-Datei ist — und das auch nach dem Projekt nicht wissen soll.
Eine Alternative, die ich seit 2024 in vielen Mandaten einsetze: Ollama als lokale Laufzeitumgebung mit OpenAI-kompatibler REST-API. Es lässt sich in jede bestehende Applikation integrieren — .NET, Python, PHP, egal — ohne tiefes Framework-Binding. Stabiler, simpler. Und du kannst Modelle tauschen, ohne Code anzufassen.
Meine Empfehlung
Lies Maartens Artikel — er ist technisch valide und zeigt dir, was machbar ist. Aber bevor du anfängst, beantworte dir diese eine Frage: Warum darf das Modell nicht auf einem Server bei einem EU-Anbieter laufen?
Wenn die Antwort konkret und haftungsrelevant ist, dann lohnt sich der Aufwand. Wenn die Antwort "na ja, irgendwie Cloud" ist, dann spar dir die Infrastruktur.
Für .NET-Teams, die trotzdem lokal testen wollen: LlamaSharp funktioniert. Aber plant Puffer für API-Änderungen ein, und haltet eure Geschäftslogik vom Modell-Binding entkoppelt — so dass ihr das Binding tauschen könnt, ohne die Applikation neu zu schreiben.
Der vollständige Original-Beitrag von Maarten Balliauw: Running Large Language Models locally – Your own ChatGPT-like AI in C#
Du willst wissen, ob lokaler KI-Betrieb für euren konkreten Fall die richtige Entscheidung ist — oder ob ihr Geld für etwas ausgebt, das eine API-Rechnung billiger löst? → 30 Min Klartext-Sparring
— Bernhard