Ein lokal betriebenes KI-System ist mehr als ein Modell auf einer GPU. Es braucht eine Inferenz-Laufzeit, eine abgesicherte API, Benutzer- und Rechteverwaltung, optional eine Wissensschicht sowie Monitoring und einen klaren Update-Prozess. Ich baue diese Schichten auf eigener Hardware, einer passenden Appliance wie NVIDIA DGX Spark oder einem dedizierten Server zusammen.
Ihr Team kann das System über eine Browser-Oberfläche ähnlich wie ChatGPT nutzen. Interne Anwendungen können über einen OpenAI-kompatiblen Endpunkt darauf zugreifen, sodass die Geschäftslogik nicht eng an eine einzelne Laufzeit gebunden ist.
Die technische Architektur
- Modell & Inferenz: Open-Weight-Modelle werden nach Aufgabe, Sprachqualität, Lizenz, Kontextlänge und verfügbarem Speicher ausgewählt — nicht nach einer pauschalen Bestenliste.
- Serving-Schicht: Ollama eignet sich für überschaubare Installationen und einfache Modellverwaltung. vLLM ist eine Option für parallele Nutzer, kontinuierliches Batching und einen leistungsfähigen OpenAI-kompatiblen API-Endpunkt. TensorRT-LLM prüfe ich, wenn NVIDIA-spezifische Optimierung den zusätzlichen Betriebsaufwand rechtfertigt.
- Zugang: Open WebUI oder eine vorhandene interne Oberfläche mit persönlicher Anmeldung, Rollen und getrennten Arbeitsbereichen.
- Wissen: Bei Bedarf ergänzt eine RAG-Pipeline das Modell um freigegebene Dokumente; Qdrant oder Postgres mit pgvector übernehmen die Vektorsuche.
- Betrieb: Container, Netzwerksegment, TLS, Secrets, Logs, Metriken, Backups und ein dokumentierter Modell- und Update-Prozess.
Ollama oder vLLM?
- Ollama ist häufig der pragmatische Start für ein kleines Team, wenige gleichzeitige Anfragen und unkomplizierte Modellwechsel.
- vLLM wird interessant, wenn mehrere Nutzer oder Anwendungen gleichzeitig zugreifen, Durchsatz und GPU-Auslastung wichtig werden oder ein stabiler API-Dienst benötigt wird.
- Gehostete APIs bleiben sinnvoll, wenn ein Spitzenmodell, seltene Nutzung oder ein schneller Start wirtschaftlich besser passt. Lokal und Cloud können über eine Routing-Schicht kombiniert werden.
Die Entscheidung fällt nach einem kurzen Lasttest mit Ihren echten Eingaben. Modellgröße allein beantwortet weder Qualität noch Latenz oder Gesamtkosten.
Was vor der Freigabe gemessen wird
- Qualität auf einem repräsentativen Satz Ihrer Aufgaben
- Zeit bis zum ersten Token, Generierungsgeschwindigkeit und Verhalten bei parallelen Anfragen
- GPU- und Arbeitsspeicherbedarf bei realistischer Kontextlänge
- Fehlerfälle, Timeouts und Fallback auf ein alternatives Modell oder einen manuellen Prozess
- Protokollierung, ohne unnötig vertrauliche Prompt-Inhalte zu sammeln
Leistungsumfang
- Hardware- und Betriebsmodell vergleichen, optional vor einer Anschaffung
- Basissystem, GPU-Treiber und Container-Laufzeit einrichten und härten
- Modell, Quantisierung, Kontextgrenzen und Inferenzparameter anhand von Tests konfigurieren
- Browser-Oberfläche und OpenAI-kompatiblen API-Zugang mit Rollen einrichten
- optional RAG, Unternehmens-Login, Modell-Routing oder externe API-Fallbacks integrieren
- Monitoring, Backup, Update- und Wiederherstellungsweg dokumentieren
- Administratoren und Anwender einweisen
Realistische Grenzen
Lokal bedeutet nicht automatisch, dass keinerlei Daten das Firmennetz verlassen. Updates, Telemetrie, externe APIs, Integrationen und Fernwartung werden deshalb ausdrücklich geprüft und begrenzt. Ein lokales Modell ersetzt außerdem nicht pauschal die leistungsfähigsten gehosteten Modelle. Ich vergleiche lokale und gehostete Varianten anhand derselben Aufgaben und empfehle die Architektur, die fachlich und wirtschaftlich passt.
Hardware, Strom, Wartung und Support bleiben Betriebskosten. Eine Appliance lohnt sich nicht wegen eines Etiketts, sondern wenn Datenklasse, Auslastung, Latenz, Verfügbarkeit oder Integrationsbedarf dafür sprechen.