Self-Hosted LLMs

Inhalt

Der Kurs besteht aus den folgenden Themen und kann je nach Publikum erweitert oder angepasst werden. Die Beispiele konzentrieren sich auf offene Modelle und Open-Source-Werkzeuge, die du auf eigener Hardware betreiben kannst. Für Inhouse-Kurse wählen wir Modelle, Hardware-Szenarien und Use Cases, die zum Publikum passen.

– Warum digitale Souveränität bei LLMs:

• Datenschutz: dokumentierte Leaks und Aufbewahrungspflichten bei öffentlichen Anbietern
• Rechtliche und geopolitische Abhängigkeiten, Jurisdiktion der Anbieter
• Wirtschaftliche Lage der grossen Anbieter und was das für die Preise heisst
• Lock-in, abgekündigte Modelle und Verfügbarkeit als Betriebsrisiko
• Wann ein externer Anbieter trotzdem die richtige Wahl ist – Drei Betriebsmodelle im Vergleich:
• Public: ChatGPT, Claude oder Mistral als Service nutzen
• Hosted: AWS Bedrock, Azure AI Foundry, Google Vertex AI – und europäische bzw. schweizerische Anbieter, wenn die Jurisdiktion zählt
• Local: eigene Hardware, volle Kontrolle, volle Verantwortung
• Trade-offs bei Kontrolle, Aufwand, Kosten und Compliance
• Offene Modelle aus Europa und der Schweiz, etwa Apertus von ETH, EPFL und CSCS – Der Speicher als eigentlicher Engpass:
• Warum der Speicher die Grenze setzt und nicht die FLOPS
• Speicherbudget: Parameter, KV-Cache und Workspace
• Kontextlänge und was sie mit dem Speicherbedarf macht
• Warum die Speicherbandbreite bestimmt, wie schnell ein Modell antwortet
• Durchsatz, Latenz und Tokens pro Sekunde selber messen – Quantisierung:
• Was Quantisierung mit den Gewichten macht
• Verfahren und Stufen: Q8, Q4, K-Quants, AWQ, GPTQ
• Trade-off zwischen gespartem Speicher und Qualitätsverlust
• Quantisierte Modelle herunterladen oder selber quantisieren – Modell-Architektur und Modellwahl:
• Grosse Generalisten gegen kleine Spezialisten
• Dense gegen Mixture of Experts: die aktiven Parameter bestimmen die Geschwindigkeit, alle Parameter zusammen den Speicherbedarf
• Modellnamen auf Hugging Face lesen: Name, Version, Grösse, aktive Parameter, Quantisierung
• Lizenzen offener Modelle und was sie für dich bedeuten
• Grössenklassen nach verfügbarem Speicher: bis 16 GB, 24 bis 96 GB, und was nur im Cluster läuft – Hardware und Sizing:
• Consumer-GPUs, professionelle GPUs und Apple Silicon mit Unified Memory
• Faustregeln: welches Modell braucht wie viel Speicher
• Sizing für mehrere gleichzeitige Nutzende
• Kaufen oder mieten, Amortisation gegenüber API-Kosten
• Mehr aus vorhandenen GPUs holen, etwa mit Batch-Jobs über Nacht – Betrieb mit llama.cpp und Ollama:
• GGUF-Modelle laden und Parameter setzen
• Ollama im Alltag: Modelfiles, Offloading, GPU-Layers
• Die OpenAI-kompatible API als De-facto-Standard
• Wo es beim Betrieb mit mehreren Nutzenden nicht mehr reicht – Produktiver Betrieb mit vLLM:
• PagedAttention und effiziente KV-Cache-Verwaltung
• Continuous Batching und Durchsatz-Optimierung
• vLLM per CLI serven und aus Python nutzen
• GPU-Memory-Utilization, Kontextlänge und API-Keys konfigurieren
• Abgrenzung zu Alternativen wie TGI und SGLang
• Benchmarking und Kapazitätsplanung – Applikationen gegen das eigene LLM bauen:
• OpenAI-kompatible Clients auf die eigene Base-URL zeigen
• Structured Output, Tool Calling und Streaming mit offenen Modellen
• Embeddings und RAG mit lokalen Modellen
• Fallback- und Routing-Strategien zwischen lokal und extern – Fine-Tuning kleiner Spezialmodelle:
• Wann Fine-Tuning, wann Prompting, wann RAG – und wann gar kein LLM
• Fine-Tuning ist nicht Training von Null: was realistisch machbar ist
• LoRA und QLoRA als bezahlbarer Weg
• Fine-Tuning mit Unsloth, Datensatz aufbereiten und GPU-Bedarf abschätzen
• Adapter ausliefern und mit vLLM servieren – Evaluierung und Qualitätssicherung:
• Warum öffentliche Benchmarks für deinen Use Case wenig aussagen
• Eigenes Test-Harness mit repräsentativen Prompts aufbauen
• Nichtdeterminismus: mehrfache Läufe, Scoring und Regressionstests
• Modelle, Versionen und Quantisierungsstufen objektiv vergleichen
• Wann sich eine eigene Evaluierung lohnt und wann nicht – Ausblick auf den Betrieb im Team und im Unternehmen:
• vLLM auf Kubernetes, GPU-Sharing und Time-Slicing
• Mehrere Modelle und Teams auf gemeinsamer Hardware
• Monitoring von GPU-Auslastung, Latenz und Kosten
• Zugriff, Auditierbarkeit und der Weg zu einer eigenen LLM-Plattform – Best Practices und Ausblick:
• “Dare to go small” – die kleinste Lösung, die den Use Case erfüllt
• Referenzarchitekturen für den eigenen LLM-Betrieb
• Entwicklung offener Modelle und Hardware einschätzen

Die Teilnehmenden betreiben eigene Modelle auf echter Hardware, vergleichen Quantisierungsstufen und Architekturen mit eigenen Messungen und nehmen einen fundierten Entscheid mit, welche AI-Workloads sie künftig selber hosten.

Der effektive Kursinhalt kann, abhängig von Trainer, Durchführung, Dauer und Konstellation der Teilnehmer:innen, von obigen Angaben abweichen.