Notizen zu Lokale KI-Installation und Konfiguration auf einem Linux-System

Wir arbeiten auf einer HP Z-Workstation mit dedizierter Grafikkarte. Konfiguration: HP Workstation Z2 G9 TWR 996Z2ET (via Alltron)

• Intel Core i7-14700K 20-Kern-Prozessor (bis 5.60 GHz)
• 32 GB DDR5-4800-RAM und 1 TB SSD
• Nvidia RTX A2000 mit 12 GB GDDR6-Grafikspeicher
• Windows 11 Pro (vorinstalliert)

Methodik

1. Erstkonfiguration und Betriebssystemauswahl

   • Versuch, die Standard-Windows-Installation mit WSL (Windows Subsystem für Linux) zu nutzen, aber Entscheidung für eine native Linux-Installation, um Virtualisierungsoverhead zu vermeiden.
   • Herunterladen von Ubuntu, aber der Netzverbindung auch über LTS (5G) war sehr langsam. Stattdessen Installation von Fedora Core 41 von einem USB-Stick, der zum Event mitgebracht wurde.
   • Problem mit dem Installer, der die Festplattenpartition nicht löschen konnte. Lösung durch manuelle Partitionierung mit dem Disk Utility.
   • Deaktivierung von Secure Boot, um Kompatibilität mit notwendigen Treibern zu gewährleisten.

2. Systemkonfiguration und Überwachung

   • Aktualisierung des Systems und Installation wesentlicher Komponenten: Python, GCC, Docker und andere Abhängigkeiten.
   • Konfiguration von Docker, um die Ausführung ohne erhöhte Berechtigungen zu ermöglichen und volle Systemfunktionen, einschließlich Grafikunterstützung, zu nutzen.
   • Verwendung von btop zur Überwachung der Systemleistung, insbesondere der GPU-Auslastung während der Modellinferenz.

3. KI-Framework und Modellinstallation

   • Installation von CUDA, Ollama (mit und ohne Docker) und mehrerer KI-Modelle.
   • Probleme mit der GPU-Treiberkompatibilität:
     • Erster Versuch mit Nouveau-Treibern scheiterte.
     • Wechsel zu NVIDIA Open-Source-Treibern, die ebenfalls nicht funktionierten.
     • Letztendliche Lösung durch Installation der NVIDIA-Proprietär-Treiber.
   • CUDA-Installation erforderte mehrere Versuche aufgrund von Abhängigkeits- und Konfigurationsproblemen.
   • Leider konnte die volle Graphikunterstützung in Docker nicht erzielt werden. Stattdessen wurde das KI-Framework Ollama über den Fedora package manager native installiert und ausgeführt.

4. Prototyping eines Retrieval-Augmented Generation (RAG) Systems

   • Retrieval-Augmented Generation (RAG, Abrufgestützte Generierung) ist eine Technik, die generative KI-Modelle mit externen Wissensquellen kombiniert, um die Genauigkeit und Relevanz ihrer Antworten zu erhöhen. Durch die Integration von Daten aus internen und externen Quellen können KI-Modelle aktuelle und spezifische Informationen abrufen, ohne dass ein erneutes Training erforderlich ist.
   • Ein RAG-System besteht typischerweise aus vier Hauptschritten:​
     • Datenindexierung: Externe Daten werden in eine Vektordatenbank umgewandelt und indexiert, um einen effizienten Zugriff zu ermöglichen.​
     • Datenabruf: Bei einer Anfrage wird die entsprechende Information aus der Datenbank abgerufen.​
     • Augmentierung: Die abgerufenen Daten werden mit der ursprünglichen Anfrage kombiniert, um den Kontext zu bereichern.​
     • Antwortgenerierung: Ein KI Modell verarbeitet die augmentierte Anfrage, um eine präzise Antwort zu liefern.​
   • RAG findet Anwendung in Bereichen wie Kundenservice, medizinischer Forschung, juristischer Analyse und vielen weiteren, in denen der Zugriff auf spezifisches Wissen entscheidend ist.
   • Die RAG Methode erschien uns als bester Ansatz. um die im Projekt definierten Aufgabenstellungen mittels KI zu lösen. Deshalb haben wir uns zum Ziel gesetzt, einen RAG Prototypen zu bauen.
   • Dabei wurden zwei Ansätze verfolgt:
     • Einsatz von existierenden, RAG-unterstützenden Lösungen wie Open Web UI, PrivateGPT, Msty. Letzteres wurde aufgrund eines fehlenden Web UIs nicht weiter verfolgt.
     • Implementierung einer Python-basierten eigenen RAG Pipeline aus Open-Source Komponenten wie Vectordatabase, Embedding-Engine und LLM Inference Runtime.
   • Für die Schlusspräsentation wurden alle Dokumente des aktuellen Urner Staatskalender in eine Wissensdatanbank (Vector Database) von Open Web UI eingebunden und via RAG Methode mit KI Modell gemma3:12b und geeigneten "System Prompts" abgefragt. Es konnte illustrativ gezeigt werden, wie RAG die Genauigkeit und Relevanz der KI Antworten erhöht. Allerdings besteht viel auch Verbesserungspotential: Einige im Staatskalender aufgeführte Personenen konnten gar nicht gefunden werden; In andere Fällen ging durch das "chunking" der .pdf Dateien der Kontext verloren. Eine Kombination von RAG, Voll-Text-Suche und besserer Daten-Strukturierung wurde diskutiert.

5. UI- und Workflow-Herausforderungen

   • Instabile Docker Compose-Konfiguration für Ollama und Open Web UI. Da keine Graphikunterstützung in Docker erreicht werden konnte, wurde Ollama extern im ansonsten containerisierten Open Web UI eingebunden.
   • Versuch, Open Web UI im nativen Modus zu betreiben, durch Installation von Python 3.11, Node.js und anderen Abhängigkeiten. Allerdings war die Dokumentation unklar, und der native Modus funktionierte außerhalb von Docker nicht.
   • Ollamas UI war wenig intuitiv, aber erfolgreiche Konfiguration für externe Logins durch Bindung an 0.0.0.0.

6. Leistung und Benutzerfreundlichkeit

   • Beobachtete stille Leistungsdegradation, wenn Modelle auf die CPU ausgelagert wurden, ohne UI-Anzeige des Übergangs. Bei jeden Übergang in den Screensave/Powersave Mode ging die GPU Beschleuningung verloren, und konnte nur via Reboot zurückgewonnen werden.
   • Unübersichtliche Vielzahl von Optionen, Erweiterungen und Vektordatenbanken ohne klare Unterscheidung, was die Entscheidungsfindung erschwerte.
   • Kleinere Modelle funktionierten gut, aber ein 12B-Parameter-Modell konnte nicht vollständig auf einer 12 GB VRAM-GPU geladen werden. Die besten Ergebnisse wurden mit Modell gemma3:12b, welches zwar 12B Parameter haben, aber Dank Q4_K_M Quantisierung nur 8GB VRAM benötigt.

7. Enterprise-Readiness-Bewertung

   • Wir besprechen und identifizieren kritische Lücken, so wie fehlende Authentifizierungsmechanismen, Backup-Lösungen, umfassende Dokumentation und Schulungsressourcen.

8. Erkundung von Alternativen

   • Kurze Bewertung von PrivateGPT einer spanischen Unternehmens als mögliche Alternative.
   • Feststellung der Abhängigkeit von KI-Tools wie ChatGPT für Dokumentation und Fehlerbehebung während des Setup-Prozesses.
   • Berücksichtigung von LM Studio oder OpenCanvas als Alternative zu OpenWebUI, noch aber ohne Implementierung.

9. Reflexion

   • Datacenter- oder Hosting-Optionen wurden aufgrund von Zeitbeschränkungen nicht untersucht, wären aber für die Skalierbarkeit wertvoll gewesen.
   • Rückblickend hätte die Verwendung von VMware oder einer ähnlichen Windows-basierten Lösung viel Zeit gespart, da moderne Arbeitsstationen Kompatibilitätsprobleme mit Linux aufweisen.

Links zu Schweizer und europäischen Cloud-Anbieter mit GPU Angeboten

• Exoscale (Schweiz)
• Infomaniak (Schweiz)
  • auch direkt als Model-as-a-Service
• Scaleway (Frankreich)
  • auch Model-as-a-Service
• Hetzner (Deutschland)
• OHVcloud (Frankreich)

Nächste Schritte

1. Prüfung von weitere Datacenter-Hosting-Optionen für grössere Bereitstellungen.
2. Bewertung von LM Studio, OpenCanvas, Llamafile, und weitere mögliche Ergänzungen oder Ersatzlösungen.
3. Erstellung weiteren geteilten Dokumentation, um Lücken in bestehenden Ressourcen zu schliessen.