Deployment

Serie: Self-Hosted LLMs für Datensouveränität | Code: GitHub TL;DR - Für eilige Leser Was wir bauen: vLLM auf Kubernetes mit Mistral-7B (4-bit quantized) OpenAI-kompatible API für einfache Integration Monitoring mit Prometheus/Grafana out-of-the-box Kostenoptimiert mit scale-to-zero Tech-Stack: vLLM 0.14.1, Mistral-7B-AWQ, Kubernetes (EKS), g6.xlarge (L4 GPU) Code: Alle Manifeste auf GitHub | Willst du mehr? Inhaltsverzeichnis Inhaltsverzeichnis Schnellstart: Warum vLLM auf Kubernetes? Was wollen wir erreichen? Teil 1: Design-Entscheidungen Architekturüberblick Serving Framework Auswahl (vLLM vs TGI vs Triton) Quantisierung (AWQ 4-bit) Hardware-Wahl (g6.xlarge mit L4) Teil 2: Kubernetes Deployment ...

In den letzten beiden Posts haben wir den Agenten evaluiert und abgesichert. Er liefert gute Ergebnisse und läuft nicht aus dem Ruder. Aber er ist immer noch Code auf einem Laptop. Kein anderes System kann ihn aufrufen. Niemand sieht, was er tut. Und wenn der Prozess abstürzt, ist alles weg. Zwei Dinge fehlen: Sichtbarkeit und Erreichbarkeit. Tracing: Sehen, was der Agent tut Ein klassischer ML-Service hat vorhersagbare Metriken: Latenz, Throughput, Error Rate. Bei einem Agenten ist das anders. Ein Run kann 3 Knoten durchlaufen oder 8. Der Token-Verbrauch wächst mit jedem Schritt, weil jeder Knoten den akkumulierten Kontext aller vorherigen Schritte als Input bekommt. Standard-Monitoring-Metriken zeigen, dass ein Run lange dauerte — aber nicht warum und nicht welcher Knoten das Bottleneck war. ...