KI ohne Cloud

Open Models sind schnell geladen und schwer zu betreiben

Nach dem Workshop kannst du ein Open-Weights-Modell auf eine GPU bringen, über eine OpenAI-compatible API anbieten, messen, was es tut, immer nur eine Sache ändern und das Ergebnis erklären. Du entscheidest mit Zahlen und kannst sagen, was jede Entscheidung kostet.

Im Mittelpunkt steht Inference Engineering: was zwischen dem Eingang eines Requests und dem letzten Token passiert, welche Ressource begrenzt und was du bei jeder Änderung eintauschst. Jede Optimization tauscht Quality, Latency, Throughput, Concurrency, Memory, Kosten und Betriebsaufwand gegeneinander. Keine Konfiguration ist für jeden Workload die schnellste, nur eine passt zu deinem.

Drei Phasen

• Verstehen und starten. Moderne Modelle, GPU-Grundlagen, Sizing von Weights und KV Cache, Prefill und Decode, Model Selection. Danach dein erster vLLM Server.
• Messen und optimieren. TTFT, Inter-Token Latency und Throughput aus einem Benchmark Harness. Dann Concurrency, Continuous Batching, KV Cache, Quantization und Parallelism, pro Experiment ein Hebel.
• Betreiben. Production Architecture, Container, Metrics und Dashboards, Scaling, Security und digitale Souveränität. RAG, Tool Calling und Agents kommen zuletzt, als Layer über der Inference, immer zurückgebunden an Kapazität und Kosten.

Echte GPUs, ein gemeinsamer Server pro Gruppe

Du arbeitest auf GPUs vom Typ NVIDIA RTX PRO 6000 Blackwell Server Edition mit 96 GB Memory. Der Trainer stellt pro Gruppe von drei bis fünf Personen eine Maschine bereit, und du verbindest dich per SSH. Eine Gruppe teilt sich einen vLLM Server, sodass du Queueing, Batching und Contention aus erster Hand erlebst.

Durch alle fünf Labs führt ein Dokument, der Inference Report. Er beginnt mit einem Workload und endet mit einer Production Architecture, die du vor einer anderen Gruppe verteidigst.

Am Ende hast du:

• Modelle für vier Szenarien ausgewählt und die Trade-offs verteidigt
• einen vLLM Server betrieben und gelesen, was er zu Memory und KV Cache meldet
• ihn bei mehreren Concurrency-Stufen gemessen, mit p50- und p95-Latencies
• pro Experiment eine Einstellung geändert und vorher und nachher verglichen
• GPU- und Server-Metrics auf einem Grafana Dashboard gelesen
• ein lokales Modell aus Code mit einem JSON Schema aufgerufen
• eine Production Inference Architecture entworfen und benannt, was jede Entscheidung kostet

Für wen

Software-, ML-, Platform- und DevOps-Engineers und Architekten, die entscheiden, wie eine Organisation Open Models betreibt, oder die sie betreiben werden. Du arbeitest auf der Kommandozeile und liest Python. GPU- oder CUDA-Erfahrung brauchst du nicht, und du musst kein Modell trainiert haben.

Was du brauchst

Einen Laptop mit git, ssh, docker, python3 (ab 3.11) und curl, etwa 20 GB freien Speicherplatz und einen SSH Key. Eine GPU, ein Cloud-Account oder ein Hugging-Face-Token sind nicht nötig. Die Vorbereitung findest du auf deiner Workshop-Seite, sobald du angemeldet bist.

Vor dem ersten Modul

Du kommst mit einem Laptop an, der die GPU-Maschine deiner Gruppe erreicht.

• Preflight und Zugang. Prüfe deinen Laptop, schick dem Trainer deinen öffentlichen SSH-Key und teste den Login auf die GPU-Maschine deiner Gruppe. Keine GPU nötig.
  Aufgabe: Preflight ausführen und Login testen

Verstehen und starten

Du lernst, was ein Modell von einer GPU verlangt, berechnest ein Deployment auf dem Papier, wählst Modelle für einen Workload aus und startest deinen ersten vLLM Server.

1. Einstieg: Warum Modelle selbst betreiben. Sechs Gründe für den Eigenbetrieb eines Modells und ihr Preis, fünf Dimensionen der Souveränität, Training, Fine-Tuning und Inference im Vergleich.
2. Moderne Language Models. Wie aus einem Prompt Tokens und das nächste Token werden. Layer, KV Heads und Parameter bestimmen das Memory, Active Parameters den Compute.
3. GPU-Grundlagen für Inference. Welches Limit eine GPU zuerst trifft, wie du Datasheets ohne Dense-Sparse-Verwechslung liest und Workloads mit Ops:Byte auf der Roofline einordnest.
4. GPU Sizing: Weights, KV Cache, Overhead. Weights, KV Cache und Overhead für ein Modell abschätzen und die KV Capacity mit dem Sizing-Script gegen das Start-up-Log des Servers prüfen.
   Aufgabe: Prediction für das GPU Memory mit dem Sizing-Script prüfen
5. Inference-Mechanik: Prefill, Decode, Latency. Ein Request durch Prefill und Decode: TTFT, ITL und Tokens pro Sekunde, und warum Decode auf das Memory wartet und Prefill auf Compute.
6. Modellauswahl. Das kleinste Modell wählen, das deine Aufgabe zuverlässig löst: günstige Prüfungen zuerst, Lizenz pro Repository, Memory Fit per Arithmetik, eigene Eval.
7. Lab 1: Modelle für vier Szenarien auswählen. Wähle Modell, Precision, Engine und Context für vier Szenarien, prüfe den Fit mit sizing.py und halte fest, worauf du bei jeder Wahl verzichtest.
   Aufgabe: Wähle Modelle für vier Szenarien und verteidige sie
8. Erstes vLLM-Deployment (Trainer-Demo). Sieh, wie vllm serve aus Weights eine OpenAI-kompatible API macht, rufe sie mit curl und Python auf und lies das Start-up-Log.
9. Lab 2: erster Inference Server. Verfolge einen Request vom Prompt bis zu den Metrics auf einem gemeinsamen vLLM-Server und prüfe deine KV-Rechnung gegen das Server-Log (2 %).
   Aufgabe: Verfolge einen Request durch deinen ersten Inference Server

Messen und optimieren

Du sagst voraus, wo der Bottleneck liegt, und misst ihn dann. Jede Optimization ist eine einzelne Änderung, die du vorher und nachher vergleichst.

10. Checkpoint: Bottleneck-Predictions. Baue die Kette Client, API, vLLM, Modell, GPU nach und mache Predictions für Bottleneck, Metric und Richtung von sechs Änderungen, bevor du misst.
11. Inference messen. Lerne, welche Metric welche Frage beantwortet, warum Percentiles genug Requests brauchen und wie sich Closed Loop, Open Loop und Goodput unterscheiden.
12. Lab 3: Benchmark der Baseline. Führe einen Concurrency-Sweep mit 1, 4, 8 und 16 auf der Baseline aus, sichere die Ergebnisse mit Provenance und finde das Knee.
    Aufgabe: Führe einen Benchmark der Baseline bei vier Concurrency-Stufen aus
13. Continuous Batching. Wie der vLLM-Scheduler in jedem Step den Batch bildet, was ein Limit für laufende Requests bei Throughput und TTFT bewirkt und was Chunked Prefill kostet.
14. KV Cache, PagedAttention und Prefix Caching. Warum der KV Cache die Concurrency begrenzt, was PagedAttention ändert, welche drei Signale Memory Pressure zeigen und wann ein Prefix Prefill spart.
15. Quantization. Was weniger Bits bei Weights, Activations und KV Cache bringen und kosten, wie du eine Quality Probe ehrlich liest, mit FP8-Ergebnissen auf einer GPU.
16. Parallelism: Replicas, Tensor, Pipeline, Expert. Was Replicas, Tensor, Pipeline und Expert Parallelism teilen, was über die Verbindung geht und die Rechnung, wann eine zweite GPU hilft. Nie gemessen.
    Aufgabe: Berechne, ob der All-Reduce den Gewinn einer zweiten GPU auffrisst
17. Lab 4: das Deployment optimieren. Teste einen Hebel mit einer Prediction und einer geänderten Variable, berichte den Trade-off zuerst: Quantization, Prefix Cache, KV-Pool, Batch-Cap.
    Aufgabe: Teste einen Optimierungshebel und berichte seinen Trade-off
18. Trainer-Demos: Speculative Decoding und OOM. Speculative Decoding lohnt bei Copy Tasks, kostet bei neuem Text unter Last. Zwei Starts müssen scheitern. Drei Demos ohne Ergebnis. Drei Folien bleiben.

Betreiben

Du machst aus einem Server einen Service: Architecture, Container, Metrics, Scaling und Security. RAG und Agents folgen als Layer darüber, und am Ende verteidigst du ein Design.

19. Production Architecture. Die Hops zwischen Request und GPU, was an jedem scheitern kann, und wie State, Streaming, Time-outs, Retries und Queues sich verhalten.
20. Containerization und reproduzierbare Deployments. Warum docker run ein Deployment nicht festhält: Host, Image, Mounts, was du pinnst, und wie du ein Client-Image gegen den Gruppen-Endpoint startest.
    Aufgabe: Baue und starte das Client-Image
21. Observability: Metrics, Dashboards, Incident Investigation. Mit vLLM-Metrics klären, ob der Service up, schnell genug und saturated ist, das Dashboard Row für Row lesen und einen Incident diagnostizieren.
    Aufgabe: Diagnostiziere einen Incident am Dashboard
22. Scaling-Strategien. Größere GPU, mehr Replicas oder geteiltes Modell: was jedes bringt, wie die Start-up Time Autoscaling bremst und wie aus einem SLO eine GPU-Zahl wird.
23. Security, Compliance und digitale Souveränität. Erfasse, wohin Prompts, Logs, Embeddings und Weights gehen, trenne Infrastructure von Application Security und bewerte ein Setup pro Workload.
    Aufgabe: Erstelle die Data-Flow-Map für den Workshop-Pod
24. RAG ohne Framework-Hype. RAG in sieben lesbaren Schritten, zwei davon Model Calls: Chunking, ähnlich ist nicht relevant, Aktualität und die zusätzlichen Prompt-Tokens.
    Aufgabe: Führe RAG mit und ohne Retrieval aus
25. Tool Calling, MCP und Agents. Tool Calling als Protokoll der Anwendung, Structured Output mit JSON-Schema, MCP und wie aus einem Request mehrere Model Calls werden.
    Aufgaben: Rufe das Modell aus Code mit einem JSON-Schema auf; Führe das Token-Ledger eines Tool-Calling-Agents aus
26. Lab 5: Production Architecture Challenge. Eine Inference-Plattform für eines von vier Szenarien entwerfen, dimensionieren und verteidigen, rückwärts vom SLO zu GPUs, Kosten und Risiken.
    Aufgabe: Entwirf und verteidige eine Inference-Plattform für den Produktivbetrieb
27. Architecture Defenses, Decision Framework, Abschluss. Verteidige deine Lab-5-Architektur, stelle die Fragen, die schwache Belege aufdecken, und gehe die 15 Entscheidungsfragen für einen neuen Workload durch.