KI-Workloads auf Kubernetes und Talos

Ein LLM-Endpoint, eine Vektordatenbank, eine Agenten-Laufzeit: alles Pods mit CPU, Speicher und Storage. Der Unterschied liegt in der kurzzeitig hohen Last (ein Agent kann Minuten Denkzeit pro Anfrage verbrennen), der Zustandsabhängigkeit (Gedächtnisgraphen und Indizes sind wertvoll) und der Kostenkonzentration (ein Modelserver kann schwerer wiegen als alle anderen Dienste zusammen). Die Plattformantworten sind die bekannten - mit schärferem Augenmerk angewandt.

• Definieren Sie CPU- und Speicher-Requests und -Limits bewusst. Speicher- und CPU-Limits wirken unterschiedlich. Prüfen Sie Sättigung und Auswirkungen auf benachbarte Workloads.
• Agenten-Laufzeiten von Model Serving trennen - Agenten skalieren mit Anfragerate, Modelle mit VRAM/RAM; vermischt werden beide unschedulbar
• Node-Pools oder Labels für Schwergewichte nutzen - speicherhungrige Pods auf geeignete Knoten pinnen vermeidet stille Pending-Zustände
• Realistische Probes setzen - Modell-Kaltstarts dauern Sekunden; eine Startup-Probe, die zu früh aufgibt, erzeugt Restart-Schleifen, die wie Abstürze aussehen

1. Embeddings und Retrieval zuerst

   Beginnen Sie mit Embedding-Endpoints und einem Vector Store - sie liefern private Suche und RAG zu moderatem Preis und vermitteln die Betriebsmuster, bevor grössere Modelle kommen.

2. Kleine Modelle hinter stabiler API

   Bedienen Sie Modelle über ein internes Gateway, damit Konsumenten nie den Modellnamen kennen. Ein Backend-Tausch wird so zu einem Deployment statt zu einem Refactoring.

3. Persistenten Kontext in eine Wissensschicht

   Halten Sie persistenten Kontext in einem eigenen Dienst wie Cognee mit klaren Zugriffskontrollen, Backups und Aufbewahrung. Ein gemeinsamer Wissensdienst darf vertraulichen Projektkontext nicht anderen Projekten offenlegen.

4. GPU erst bei gemessenem Bedarf

   GPU-Knoten kommen, wenn Latenz oder Wartezeiten den Bedarf beweisen - nicht vorher. Pool labeln, bei Mischbetrieb mit Taints isolieren und als Plattform-Posten budgetieren.

• Erfassen Sie Anfrageergebnisse und autorisierte Werkzeugaktionen mit Korrelations-ID. Protokollieren Sie standardmässig keine rohen Prompts, Kundendaten oder Geheimnisse.
• Tokens, Latenz und Queue-Tiefe pro Modell verfolgen - Kostenüberraschungen kommen über diese Kanäle
• Wachstum der Gedächtnisschicht selbst beobachten - Graphen und Indizes wachsen; Retention braucht einen Verantwortlichen
• Auf Drift zwischen Git und Cluster alarmieren - GitOps macht 'wer hat was geändert' zur beantworteten Frage
• KI-Dienste in dieselben Dashboards und Runbooks wie alles andere aufnehmen - separates Tooling verrottet

UHL beschreibt die Talos-Praxis und Kubernetes-Leistungen öffentlich. Das Diagramm ist eine Referenztopologie und weder Benchmark noch Zusage, dass jede Modellgrösse auf die aktuelle Plattform passt. Dimensionierung und Abnahme müssen am vorgesehenen Workload gemessen werden.

1. Nachfrage

   Erfassen Sie Modell und Version, Kontextlänge, erwartete parallele Anfragen, Anfragegrösse, Ziel-Latenz und zulässigen eingeschränkten Betrieb.

2. Platzierung und Kapazität

   Dokumentieren Sie CPU, Speicher, Beschleunigerbedarf, Node-Auswahl, Datenwachstum und Startverhalten. Prüfen Sie Verdrängung und Speicherüberschreitung auf Staging.

3. Wiederherstellung und Freigabe

   Benennen Sie persistente Daten, Wiederherstellungsziel, Backup-Verantwortung und Rücknahmeverfahren. Testen Sie eine Wiederherstellung und erfassen Sie das Ergebnis vor Zeitversprechen.

• Der Lasttest bildet vorgesehene Anfragen und Parallelität ab.
• Startup-, Readiness- und Liveness-Probes entsprechen dem tatsächlichen Modellverhalten.
• Monitoring erfasst Latenz, Fehler, Warteschlange und Auslastung ohne sensible Prompts zu protokollieren.

• Kubernetes-Ressourcenverwaltung erklärt Requests und Limits.
• Die Talos-Linux-Dokumentation beschreibt das Verwaltungsmodell des Betriebssystems.