Kubernetes für KI-Inferenz

Kubernetes für KI-Inferenz

0:00 Wir kommen zum letzten Modul, und es führt dorthin, wo Kubernetes derzeit am schnellsten wächst: Sprachmodelle im eigenen Betrieb. Das ist kein Modethema, sondern eine handfeste Frage — viele Unternehmen wollen ihre Daten nicht an einen externen Anbieter geben, und dann bleibt der eigene Cluster. Nur verhält sich diese Arbeitslast anders als alles bisher: Die Hardware ist unteilbar und extrem teuer, der Start dauert Minuten statt Sekunden, und die Kennzahlen, nach denen wir in Modul 6 skaliert haben, taugen hier nicht.

0:30 Dieselben Prinzipien also, aber neue Größenordnungen. Acht Kapitel, von der Grafikkarte bis zur Kostenrechnung.

GPUs in den Cluster bringen

0:37 Beginnen wir mit der Hardware, und mit dem ersten grundlegenden Unterschied zu Modul 5: Diese Ressource verhält sich nicht wie Rechenzeit. Sie ist unteilbar, sie ist knapp, und sie ist teuer. Das verändert fast jede Entscheidung, die darauf aufbaut. In Modul 5 haben wir gelernt, Rechenzeit in Millikernen anzufordern — ein Viertelkern, kein Problem. Bei einer Grafikkarte gibt es das lange nicht: ganze Karte oder keine.

1:02 Und damit der Planer sie überhaupt sieht, muss ein Baustein auf jedem Knoten sie melden — herkömmlich ein Geräte-Plugin, das eine herstellereigene Ressource ankündigt. In der Praxis installiert man das nicht einzeln, sondern nimmt einen Operator: Er bündelt Treiber, Laufzeitschicht, Plugin und die Kennzeichnung der Knoten.

1:20 Das ist eine dieser Stellen, an denen man dankbar auf eine fertige Lösung zurückgreift, statt Treiberfassungen von Hand zu pflegen. Der Ausschnitt sieht vertraut aus, und genau darin steckt die Falle. Beachten Sie: Es steht nur eine Grenze da, keine Anforderung. Der Hinweis unten erklärt warum — bei dieser Ressource sind Anforderung und Grenze stets gleich, weil es keine Bruchteile gibt. Kubernetes setzt die Anforderung deshalb selbst.

1:47 Wer beides unterschiedlich angibt, bekommt eine Ablehnung. Die zweite wichtige Stelle ist die Knotenauswahl unten: Sie stellt sicher, dass dieser Pod auf einem Knoten mit Karte landet. Und das Bild, das dort als Image steht, ist eine Inferenz-Engine — die sehen wir uns in Kapitel 4 genauer an. Fünf Bestandteile, und ihre Reihenfolge ist die Kette vom Blech zur Beschreibung: Treiber spricht die Karte an, Laufzeitschicht reicht sie in den Container, Plugin meldet sie an den Knotendienst, Kennzeichnung macht sie auffindbar.

2:19 Fehlt ein Glied, ist die Karte nicht nutzbar — und die Fehlermeldung nennt selten das richtige Glied. Der Hinweis unten benennt einen teuren Alltagsfehler: Ohne Kennzeichnung der Knoten landen Pods ohne GPU-Bedarf auf den teuersten Maschinen. Ihre Protokollsammlung belegt dann eine Karte für zehntausend Euro. Die fünfte Zeile brauchen wir übrigens in Kapitel 8 — ohne Messwerte keine Skalierung.

2:42 Vier Gründe, und der erste bestimmt alle anderen: Eine Karte kostet ein Vielfaches eines normalen Knotens und darf nicht leer laufen. Bei gewöhnlichen Knoten ist etwas Verschnitt gleichgültig; hier ist er ein Budgetposten. Der zweite ist die Kennzeichnung von vorhin — ohne Markierung mischen sich gewöhnliche Pods auf die teuren Maschinen.

3:01 Der dritte ist eine ungewohnte Größenordnung: Der Start ist langsam, weil Treiber, Abbild und Modell Zeit brauchen; Kapitel 7 widmet sich dem ganz. Und der vierte verändert die Erwartungshaltung: Die Zahl der Karten ist begrenzt, Warten ist der Normalfall — nicht die Ausnahme. Der erste Punkt ist der aus der Code-Folie und passiert bei jedem ersten Manifest: Anforderung ohne Grenze, und der Pod wird abgelehnt.

3:25 Der zweite ist das Kostenleck aus der Tabelle. Der dritte ist ein Betriebsthema, das man kennen sollte, weil es so unangenehm zuschlägt: Treiberfassung und Kernfassung des Knotens laufen auseinander — nach einem Knoten-Update lädt der Treiber nicht mehr, und die Karte ist verschwunden. Und der vierte ist eine Erwartung, die naheliegt und falsch ist: Zwei Pods teilen sich nicht einfach eine Karte. Dafür braucht es Kapitel 3, und es ist nicht umsonst.

Dynamic Resource Allocation

3:51 Jetzt zum Nachfolger des Geräte-Plugins, und der ist mehr als eine Umbenennung: Er ändert das Modell, nach dem Geräte angefordert werden. Seit Kubernetes 1.35 ist er endgültig da. Geräte anfordern wie Datenträger, nicht wie Rechenzeit. Der alte Weg kennt nur Stückzahlen: eine Karte, zwei Karten. Welche, mit wie viel Speicher, welcher Bauart — dazu kann er nichts sagen.

4:15 Die Dynamic Resource Allocation beschreibt Geräte stattdessen wie beständige Datenträger, und wer Modul 5 kennt, erkennt das Muster: Eine Geräteklasse fasst gleichartige Karten zusammen, eine Anforderung verlangt daraus ein Gerät, und der Pod verweist auf die Anforderung. Genau wie bei Speicherklasse, Anforderung und Einbindung.

4:35 Und die Auswahl geschieht über Ausdrücke auf Geräteeigenschaften — Sie können also nach Speichergröße fragen statt nach Stückzahl. Zwei Stellen, ein Name — und genau in dieser Doppelung liegt der häufigste Anfängerfehler, wie der letzte Stolperstein zeigt. Oben wird die Anforderung für den Pod benannt, unten verweist der Container darauf.

4:55 Beachten Sie den Hinweis, denn er beschreibt eine bewusste Entscheidung mit praktischen Folgen: Die Anforderung gehört zum Pod, nicht zum Container. Mehrere Container dürfen sie also gemeinsam nutzen — nützlich etwa für einen Beiwagen, der Messwerte von der Karte liest. Und die Vorlage im Namen bedeutet: Je Pod entsteht eine eigene Anforderung. Das ist fast immer, was Sie wollen.

5:18 Vier Objekte, und drei davon schreiben Sie: Klasse und Vorlage einmal, und die Anforderung entsteht daraus. Der Unterschied zwischen den beiden mittleren Zeilen ist wichtig: Eine feste Anforderung ist ein einzelnes Gerät, das geteilt wird — eine Vorlage erzeugt je Pod eine eigene. Wer das verwechselt, teilt unbeabsichtigt.

5:36 Die vierte Zeile ist die interessanteste, und der Hinweis unten erklärt, warum es eine Verbesserung ist: Die Meldung kommt von einem Treiber im Cluster, der Knoten trägt seine Geräte nicht mehr selbst ein. Damit weiß die Steuerungsebene, was es gibt — und kann vorher planen statt hinterher zu scheitern. Drei Gewinne und eine ehrliche Nicht-Veränderung.

5:57 Auswahl nach Eigenschaften statt Stückzahl ist der Hauptgewinn — Sie fragen nach einer Karte mit achtzig Gigabyte, nicht nach „einer Karte". Gemeinsame Nutzung ist jetzt beschreibbar statt gar nicht möglich. Und Herstellereinstellungen wandern von der Knotenkonfiguration in die Arbeitslast, wo sie hingehören. Die letzte Zeile ist die, auf die es mir ankommt, und der Hinweis darunter formuliert sie deutlich: Verdrängung gibt es auch jetzt nicht.

6:23 Ein wichtiger Pod kann einen laufenden nicht hinauswerfen — er bleibt ausstehend, bis ein Gerät frei wird. Rechnen Sie mit Warteschlangen, nicht mit Vorfahrt. Der erste Punkt ist die Namensdoppelung aus der Code-Folie, und sein Fehlerbild ist unangenehm: Der Pod läuft, bekommt aber kein Gerät zugewiesen, und niemand beschwert sich.

6:42 Der zweite ist das unbeabsichtigte Teilen aus der Tabelle. Der dritte ist die fehlende Verdrängung, und er kostet vor allem Zeit: Ein wichtiger Lauf wartet unbemerkt in der Warteschlange, weil niemand nach ausstehenden Pods sieht. Richten Sie sich dafür eine Meldung ein. Und der vierte ist ein Doppelbetrieb, der zu widersprüchlichen Buchungen führt: Geräte-Plugin und dynamische Zuweisung für dieselben Karten — beide glauben, sie hätten sie.

Eine Karte, mehrere Arbeitslasten

7:07 Jetzt zu der Frage, an der sich entscheidet, ob kleine Modelle wirtschaftlich zu betreiben sind. Eine Karte für ein Modell mit zwei Milliarden Parametern ist Verschwendung — die Karte langweilt sich. Teilen geht also. Aber, und das ist die Botschaft dieses Kapitels: nicht umsonst. Zwei Wege, und sie sind grundverschieden. Zeitscheiben lassen mehrere Container abwechselnd rechnen — wie mehrere Programme auf einem Prozessor.

7:33 Einfach einzurichten, eine Konfigurationszeile, und ohne jede Trennung von Speicher und Fehlern. Die Aufteilung in Geräteinstanzen zerlegt die Karte dagegen in der Hardware in kleinere, vollständige Karten, mit eigenem Speicher und eigener Fehlerdomäne. Das ist die echte Trennung — verfügbar nur auf neueren Modellen. Denken Sie an ein Großraumbüro gegen mehrere abgeschlossene Räume.

7:56 Beides teilt eine Fläche, aber nur eines trennt die Nutzer voneinander. Fünf Zeilen — deshalb wird dieser Weg so oft gewählt. Sie sagen: Aus dieser einen Karte mach vier meldbare Einheiten. Danach kann der Planer vier Pods darauf legen, und alles sieht wunderbar aus. Aber lesen Sie den Hinweis genau, denn er ist die halbe Wahrheit dieses Kapitels: Physisch bleibt es eine einzige Karte.

8:19 Es gibt nicht mehr Speicher, nicht mehr Rechenleistung, nicht mehr Bandbreite — nur eine andere Buchführung. Vier Pods teilen dieselbe Karte und bekommen jeder ein Viertel der Zeit. Was das für den Speicher bedeutet, ist der Kern der nächsten beiden Folien. Fünf Vergleichszeilen, und die ersten zwei sind die entscheidenden.

8:39 Bei Zeitscheiben ist weder Speicher noch Fehler getrennt — und deshalb steht unten eine ungewöhnlich deutliche Warnung, die ich so weitergebe, weil sie in der Dokumentation ausdrücklich so steht: Zeitscheiben trennen weder Speicher noch Fehler zwischen den Nutzern. Praktisch heißt das: Belegt ein Pod den ganzen Kartenspeicher, stürzt der andere ab. Und ein Absturz auf der Karte kann beide mitnehmen.

9:01 Für mehrere Arbeitslasten desselben Teams ist das vertretbar. Für verschiedene Mandanten ist es keine Option — dort brauchen Sie Instanzen oder eigene Karten. Das Lernziel ist zweiteilig: belegen, welches Gerät ein Pod tatsächlich bekommen hat, und die Wirkung einer Teilung messen. Geschafft ist es, wenn zwei Pods nachweislich auf derselben Karte laufen, ihre Antwortzeiten messbar über denen eines Pods allein liegen, und die Belegung im Messdienst sichtbar ist.

9:28 Wer schneller fertig ist, macht die eigentlich lehrreiche Variante: dasselbe mit einem Modell, das den Kartenspeicher fast ausfüllt. Der Speicherfall ist der überzeugende — bei Zeitscheiben stürzt dann einer der beiden ab. Und dieses Erlebnis erklärt die Warnung von der letzten Folie besser als jede Dokumentation. Der erste Punkt ist die Warnung aus der Tabelle, jetzt als Fehler: Zeitscheiben für Trennung halten und zwei fremde Arbeitslasten aufeinander setzen.

9:54 Der zweite ist eine falsche Erwartung mit hübscher Logik: Vier Scheiben verlangt, drei davon selbst genutzt — und trotzdem bekommen alle gleich viel, denn Anteile lassen sich hier nicht zusichern. Der dritte ist der Speicherfall aus der Aufgabe, und er passiert ohne Warnung. Und der vierte ist ein Handgriff, den man vergisst: Instanzen eingerichtet, aber die Profilnamen in den Manifesten nicht mitgezogen — dann fragen Ihre Pods nach einer Ressource, die es nicht mehr gibt.

Was eine Inferenz-Engine anders macht

10:20 Bevor wir Modelle ausliefern, ein Kapitel über das Innenleben. Ohne dieses Wissen wirkt die halbe Konfiguration der folgenden Kapitel willkürlich — man setzt Werte, weil sie in einem Beispiel standen. Es geht um den Unterschied zwischen einem Modell und einem Dienst. Ein Sprachmodell erzeugt Text Wort für Wort und muss dabei den Zwischenzustand aller bisherigen Wörter im Kartenspeicher halten — je länger das Gespräch, desto mehr Speicher.

10:46 Und eine Inferenz-Engine ist im Kern ein Speicherverwalter für genau diesen Zustand. Ihr erster Trick: Sie legt ihn in gleichgroßen Blöcken ab statt in einem Stück. Das vermeidet Verschnitt und macht gemeinsame Anfangsstücke teilbar — wie eine Speicherseitenverwaltung im Betriebssystem, und genau von dort ist die Idee entlehnt.

11:05 Ihr zweiter Trick: Sie nimmt neue Anfragen zwischen zwei Wörtern in den laufenden Stapel auf, statt sie warten zu lassen. Vier Wirkungen, und sie sind erheblich — es geht nicht um Prozente, sondern um Vielfache bei der Zahl gleichzeitiger Anfragen. Der zweite Punkt ist der, der im Alltag am meisten spart und den man ausnutzen sollte: Gemeinsame Anfangsstücke liegen nur einmal im Speicher.

11:27 Wenn alle Ihre Anfragen dieselbe lange Systemanweisung tragen — und das ist die Regel —, dann wird sie einmal gespeichert statt hundertmal. Der dritte beseitigt eine Wartezeit, die früher selbstverständlich war: Keine Anfrage wartet auf das Ende der vorigen. Und der vierte fasst es aus Kostensicht zusammen: Die Karte bleibt beschäftigt, statt zwischen zwei Stapeln zu ruhen.

11:49 Vier Angaben, und laut Beschriftung entscheiden sie alles — was leicht untertrieben klingt und zutrifft. Der Modellname sagt, was geladen wird. Die Kontextlänge legt fest, wie lang ein einzelnes Gespräch werden darf. Der Speicheranteil sagt, wie viel Kartenspeicher die Engine belegen darf. Und die letzte Angabe verteilt das Modell über Karten — dazu Kapitel 6.

12:11 Der Hinweis unten beschreibt das Zusammenspiel, das man verstehen muss: Kontextlänge und Speicheranteil bestimmen zusammen, wie viele Anfragen gleichzeitig passen. Eine großzügige Kontextlänge kostet Sie also Parallelität, und zwar unmittelbar. Das ist die zentrale Abwägung beim Betrieb. Fünf Kennzahlen, und der Hinweis unten teilt sie sauber in zwei Gruppen: Die ersten beiden fühlt der Nutzer, die letzten beiden steuern die Skalierung aus Kapitel 8.

12:39 Die Zeit bis zum ersten Wort ist die, die als Reaktionsfähigkeit erlebt wird — danach liest der Mensch mit, und die Zeit je weiterem Wort muss nur schnell genug für flüssiges Lesen sein. Beide sind etwas völlig anderes als der Gesamtdurchsatz, und genau diese Verwechslung ist der dritte Stolperstein. Merken Sie sich: Nutzer erleben Latenz, Betreiber bezahlen Durchsatz. Beides gleichzeitig zu maximieren geht nicht.

13:03 Der erste Punkt ist verführerisch: den Speicheranteil auf eins setzen, um alles auszunutzen — und der Engine keinen Rand für Ausschläge lassen. Der zweite ist die Abwägung aus der Code-Folie in Fehlerform: Eine sehr lange Kontextgrenze gewählt, und die Zahl gleichzeitiger Anfragen bricht ein. Fragen Sie sich, wie lang Ihre Gespräche wirklich werden.

13:22 Der dritte ist die Verwechslung aus der Tabelle — Durchsatz und Antwortzeit in eine Zahl gemischt, obwohl sie gegenläufig sind. Und der vierte ist die Mittelwertfalle aus Modul 6, hier besonders schädlich: Für die Zeit bis zum ersten Wort zählen Perzentile, nicht Mittelwerte.

Modelle ausliefern mit KServe

13:38 Jetzt bringen wir das Modell in Betrieb — und zwar nicht mit Deployment, Service und Route einzeln, sondern mit einem Objekt. Alles aus Modul 5 und 6 steckt darin, nur beschrieben aus Sicht des Modells. Das ist ein guter Moment, um zu sehen, wie weit wir gekommen sind. KServe beschreibt Modelldienste als eigene Objekte, und es gibt zwei Sorten: eine für klassische Vorhersagemodelle und eine eigene für generative. Uns interessiert die zweite.

14:06 Sie benennt Modellquelle und Modellname, die Zahl der Abbilder, den Weg des Verkehrs und die Aufteilung über Karten. Und der entscheidende Satz ist der letzte: Darunter entstehen die gewohnten Objekte — samt Weg über die Gateway API aus Modul 5. Es ist also keine Parallelwelt, sondern eine Abkürzung. Was Sie in Modul 5 gelernt haben, gilt weiter; Sie schreiben es nur nicht mehr selbst.

14:30 Beachten Sie, was hier alles nicht steht: kein Selektor, kein Service, keine Route, keine Probes. Nur Quelle, Name und Anzahl. Und der Hinweis unten erklärt die eine Stelle, die tatsächlich verwirrt — warum Quelle und Name doppelt auftauchen. Die Quelle sagt, woher das Modell kommt: hier aus einem Modell-Verzeichnis im Netz.

14:50 Der Name ist der, den Aufrufe später nennen, also das, was Ihre Anwendung in die Anfrage schreibt. Beide sind hier zufällig gleich, müssen es aber nicht sein — und dass sie verwechselt werden, ist der erste Stolperstein dieses Kapitels. Zwei Blöcke. Der obere ist bemerkenswert leer — drei Schlüssel mit leeren Klammern. Das heißt: Nimm die Voreinstellungen und richte mir Tor, Weg und Verteiler ein.

15:15 Was in Modul 5 drei Manifeste waren, sind hier drei leere Klammerpaare. Der untere Block ist der vertraute Container samt Kartenanforderung aus Kapitel 1. Und der Hinweis unten beschreibt eine Besonderheit, die wichtig ist: Der Verteiler wählt das Abbild nicht zufällig, sondern nach Zustand seines Zwischenspeichers. Er lenkt eine Anfrage dorthin, wo das Anfangsstück schon liegt — eine Lastverteilung, die den Inhalt kennt. Das kann kein gewöhnlicher Service.

15:44 Vier Fähigkeiten, und die erste ist der Grund, warum sich das so schnell verbreitet: eine Schnittstelle nach dem Muster des bekannten Anbieters. Vorhandene Anwendungen sprechen sie schon — Sie tauschen eine Adresse und einen Schlüssel, und der Rest bleibt. Die zweite spart die teure Karte im Leerlauf, und Kapitel 7 sagt, was das kostet. Die dritte ist das schrittweise Ausrollen aus Modul 6, hier je Modellfassung.

16:08 Und dann lesen Sie den Hinweis unten und nehmen ihn ernst: Das Projekt ist im Reifegrad Incubating, die generativen Objekte tragen noch eine Alpha-Fassung. Das heißt: Es funktioniert, und es kann sich ändern. Ihre Aufgabe: ein Sprachmodell als beschriebenes Objekt ausliefern und seine Schnittstelle von außen belegen. Geschafft ist es, wenn der Dienst über die Schnittstelle nach OpenAI-Muster mit erzeugtem Text antwortet und die Messwerte der Engine im Messdienst erscheinen.

16:37 Der zweite Teil ist die Vorbereitung für Kapitel 8 — ohne Messwerte keine Skalierung. Wer schneller fertig ist, rollt eine zweite Modellfassung schrittweise aus. Und ein Vorschlag aus der Notiz, den ich unterstütze: Vergleichen Sie das Ergebnis mit Ihrem Deployment aus Modul 5. Es steckt alles drin, nur kürzer beschrieben — und das sieht man erst im Vergleich.

16:58 Der erste Punkt ist die Verwechslung von Quelle und Name, und ihr Fehlerbild ist irritierend: Der Dienst läuft tadellos und weist jeden Aufruf ab, weil der genannte Modellname unbekannt ist. Der zweite ist banal und kostet einen Nachmittag: Zugangsdaten für die Modellquelle vergessen, und der Start scheitert beim Herunterladen — bei einem großen Modell nach mehreren Minuten.

17:18 Der dritte ist die Alpha-Fassung aus der Tabelle; wer sie ohne Fassungspflege betreibt, wird beim Update überrascht. Und der vierte kommt aus Modul 6 zurück und wird uns in Kapitel 7 beschäftigen: auf null skaliert, und die erste Anfrage läuft in eine Zeitüberschreitung.

Verteilte Inferenz

17:34 Jetzt der Teil, der aus einem Dienst ein verteiltes System macht. Bisher hatten wir ein Modell auf einer Karte. Was aber, wenn das Modell nicht auf eine Karte passt? Dann wird es aufgeteilt — und plötzlich reden wir über Netzbandbreite zwischen Karten. Zwei Gründe, verteilt zu arbeiten. Der erste ist Zwang: Große Modelle passen nicht auf eine Karte.

17:55 Der zweite ist eine Erkenntnis über die Arbeit selbst, und die finde ich interessant: Die zwei Phasen der Erzeugung haben ungleiche Bedürfnisse. Das Verarbeiten der Eingabe lastet die Karte gleichmäßig aus — sie rechnet. Das Erzeugen der Wörter danach wartet dagegen auf Speicher, die Rechenwerke langweilen sich. Zwei so verschiedene Aufgaben auf derselben Hardware auszulegen heißt, für beide einen Kompromiss zu wählen.

18:20 Getrennt betrieben lassen sie sich eigenständig auslegen — und genau das ist die aktuelle Entwicklung. Der obere Block teilt das Modell auf: hier über vier Karten innerhalb eines Knotens. Der untere trennt die Phasen und gibt der Eingabeverarbeitung eigene Abbilder. Und der Hinweis unten benennt die Schwelle, die Sie überschreiten: Sobald Arbeiter beschrieben sind, läuft der Dienst über mehrere Knoten statt auf einem.

18:44 Das ist ein qualitativer Sprung, nicht ein Zahlenwert — ab hier ist die Netzverbindung zwischen den Knoten Teil Ihrer Antwortzeit, und Ausfälle einzelner Knoten treffen einen zusammenhängenden Verbund. Gehen Sie diesen Schritt, wenn Sie ihn brauchen, und nicht vorher. Vier Arten, und die erste ist die häufigste. Sie teilt Schichten des Modells über Karten — und der Hinweis unten sagt, was das kostet: Bandbreite zwischen den Karten, weil bei jedem Wort Zwischenergebnisse ausgetauscht werden.

19:12 Deshalb bleibt sie meist innerhalb eines Knotens, wo die Karten direkt verbunden sind. Die Fließband-Aufteilung verteilt Abschnitte über Knoten und kommt mit weniger Austausch aus. Die Daten-Aufteilung ist schlicht das, was wir in Modul 6 Skalierung genannt haben: mehr Abbilder für mehr Durchsatz. Und die letzte betrifft eine Modellbauart, bei der nur ein Teil der Gewichte je Anfrage aktiv ist.

19:35 Vier Wirkungen, und der zweite Punkt schließt an den Verteiler aus Kapitel 5 an: Anfragen werden dorthin gelenkt, wo das Anfangsstück schon im Speicher liegt. Zusammen mit dem dritten Punkt ergibt das den eigentlichen Gewinn: Wiederkehrende Systemanweisungen werden nur einmal verarbeitet. Bei einem Assistenten mit einer langen, immer gleichen Anweisung ist das keine Feinoptimierung, sondern ein erheblicher Teil der Arbeit.

19:59 Und der vierte Punkt ist die Zusammenfassung, die diese Architektur überhaupt rechtfertigt: Die Zeit bis zum ersten Wort sinkt, ohne den Durchsatz zu opfern. Erinnern Sie sich — sonst sind das gegenläufige Ziele. Der erste Punkt ist die Bandbreitenfalle aus der Tabelle: Tensor-Aufteilung über Knoten hinweg verlangt und am Netz gescheitert — es läuft, und es ist erschütternd langsam.

20:21 Der zweite ist unnötige Komplexität, und ich nenne ihn ausdrücklich: Die Phasen zu trennen, obwohl das Modell auf eine Karte passt, ist Aufwand ohne Gewinn. Der dritte ist eine halbe Architektur — verteilt betreiben ohne Verteiler, der den Zwischenspeicher kennt, verschenkt genau das, wofür man verteilt hat. Und der vierte ist eine Erwartung, die man einmal aussprechen muss: Mehr Karten verkürzen die Antwortzeit einer einzelnen Anfrage nicht. Sie erhöhen den Durchsatz.

Kaltstart und Modell-Artefakte

20:49 Jetzt die achtzig Sekunden, in denen niemand eine Antwort bekommt. Das ist eine Größenordnung, mit der wir in diesem Seminar noch nicht zu tun hatten — und sie entscheidet, ob das Herunterskalieren auf null aus Modul 6 hier nützlich oder untragbar ist. Rechnen wir kurz: Ein Modell mit acht Milliarden Parametern belegt zweistellige Gigabyte.

21:09 Die müssen geholt, gelesen und in den Kartenspeicher geladen werden — dazu kommen Abbild und Treiber. Diese Zeit ist der Kaltstart, und die Größenordnung ist eine Minute oder mehr, nicht eine Sekunde. Und dann kommt der nüchterne Satz, der dieses Kapitel prägt: Verkürzen lässt er sich nur, indem man Wege abschneidet. Es gibt keinen Trick, der das Laden beschleunigt — es gibt nur weniger weit holen, oder gar nicht mehr laden. Modell nah vorhalten, Karten warm halten, Abbilder vorziehen.

21:38 Der Kern ist die letzte Zeile: Das Modell kommt nicht aus dem Netz, sondern aus einer Ablage im Cluster. Statt bei jedem Start zwanzig Gigabyte über die Internetleitung zu ziehen, liegen sie neben dem Cluster. Und dann lesen Sie den Hinweis, denn dort steht eine echte Falle: Mehrfach lesbar einzubinden ist Pflicht. Eine gewöhnliche Ablage lässt sich nur von einem Pod gleichzeitig einbinden — und damit kann nur ein Abbild starten.

22:02 Ihre Skalierung aus Kapitel 8 wäre blockiert, und zwar mit einer Meldung über einen wartenden Datenträger, die niemand mit Skalierung in Verbindung bringt. Vier Abschnitte und je ein Gegenmittel — das ist eine ordentliche Diagnoseliste. Die ersten zwei sind billig zu beheben: Abbild vorziehen, Modell nah vorhalten. Die letzten zwei sind es nicht, und der Hinweis unten sagt es klar: Sie kosten Geld im Leerlauf. Eine warm gehaltene Karte ist eine bezahlte Karte, die nichts tut.

22:31 Genau das ist die Abwägung dieses Kapitels, und sie ist nicht technisch, sondern kaufmännisch: Was kostet Ihnen eine Minute Wartezeit, und was kostet Ihnen eine Stunde Leerlauf? Beantworten Sie das mit Zahlen, dann ist die Entscheidung leicht. Das Lernziel ist eine Methode, nicht ein Ergebnis: die Anteile einer Startzeit einzeln messen und gezielt den größten davon angehen.

22:54 Geschafft ist es, wenn die Zeit von der ersten Anfrage bis zur ersten Antwort im kalten Zustand mindestens halbiert ist — und jeder Anteil einzeln belegt. Wer schneller fertig ist, rechnet die Kosten eines warm gehaltenen Abbilds gegen die gesparte Wartezeit; das ist die Abwägung von der letzten Folie mit echten Zahlen.

23:12 Und die Notiz enthält den Satz, der für dieses ganze Modul gilt: Zuerst messen, dann optimieren. Geraten wird hier fast immer falsch. Der erste Punkt ist die Reihenfolge aus der Aufgabe: auf null skalieren, ohne die Kaltstartzeit gemessen zu haben — Sie sparen Geld und erfahren erst von Nutzern, was es gekostet hat. Der zweite ist die Einbindungsfalle aus der Code-Folie, und ihr Fehlerbild führt in die Irre.

23:35 Der dritte ist ein Kostenposten, den man leicht übersieht, weil er auf einer anderen Rechnung steht: Das Modell bei jedem Start aus dem Netz holen kostet Bandbreite, und bei einem Anbieter kostet ausgehende Bandbreite Geld. Und der vierte ist die andere Hälfte derselben Buchführung: ein warmes Abbild vorhalten und in der Kostenrechnung vergessen.

Skalieren, messen, rechnen

23:55 Und damit zum Abschluss, in dem Modul 6 und Modul 8 zusammenkommen. Wir haben dort gelernt, an der Ursache zu skalieren statt an der Wirkung — hier zeigt sich, wie richtig das war. Nicht die Auslastung der Karte entscheidet, sondern die Warteschlange. Der erste Satz ist die Pointe: Die Auslastung einer Karte ist als Steuergröße untauglich.

24:16 Sie liegt bei einer arbeitenden Engine fast immer hoch — die Engine ist ja genau dafür gebaut, die Karte beschäftigt zu halten. Neunzig Prozent bedeuten also nicht „überlastet", sondern „funktioniert". Aussagekräftig ist, was die Engine selbst meldet: die Zahl wartender Anfragen und die Belegung ihres Zwischenspeichers. Und genau darauf skaliert der ereignisgetriebene Weg aus Modul 6 — hier zahlt sich aus, dass wir ihn dort besprochen haben.

24:42 Neue Karten beschafft danach ein Knoten-Autoskalierer, und das dauert Minuten. Fünf Zeilen, und sie sind das konkrete Ergebnis des ganzen Moduls: Wir fragen den Messdienst nach wartenden Anfragen und skalieren bei mehr als fünf. Das ist die Ursache, nicht die Wirkung — genau die Unterscheidung aus Modul 6. Und der Hinweis unten gibt Ihnen eine Diagnoseregel mit, die ich mir merken würde: Bleibt diese Zahl dauerhaft über null, fehlen Karten — nicht Rechenzeit.

25:10 Sie können dann so viele Abbilder anfordern, wie Sie wollen; ohne freie Karten bleiben sie ausstehend. Das ist der Moment, in dem eine Beschaffung ansteht und keine Konfigurationsänderung. Fünf Größen mit klarem Urteil, und die erste ist mit „untauglich" bewertet — das ist eine ungewöhnlich deutliche Aussage für eine Tabelle, und sie ist berechtigt.

25:31 Die beiden guten sind die, die die Engine meldet. Die vierte ist interessant differenziert: Als Ziel geeignet, als Regelgröße träge — Sie sollten also über die Zeit bis zum ersten Wort ein Versprechen abgeben, aber nicht darauf regeln. Und dann lesen Sie den Hinweis, denn er beschreibt eine Eigenheit dieses Bereichs: Es skalieren zwei Ebenen — Abbilder je Karte und Karten je Cluster.

25:53 Die zweite dauert Minuten, und darauf muss Ihre Planung eingestellt sein. Vier Sätze, und sie sind die betriebswirtschaftliche Zusammenfassung des Moduls. Bezahlt wird die Karte nach Zeit, nicht nach erzeugten Wörtern — das ist die Ausgangslage, und daraus folgt alles. Also zählt, wie viele Wörter je Kartenstunde herauskommen; das ist Ihre eigentliche Kennzahl, nicht die Auslastung.

26:16 Der dritte Punkt ist der wichtigste: Leerlauf ist der teuerste Zustand, und ohne Skalierung der häufigste. Und der vierte ist eine feine Unterscheidung, die man sich klar machen sollte: Teilen und Stapeln senken die Kosten je Wort — die Kosten je Stunde senken sie nicht. Die senkt nur Abschalten. Drei Alternativen, der Vollständigkeit wegen — und mit einer klaren Einordnung.

26:38 Der Inferenzserver eines Herstellers unterstützt viele Modellformate und bringt eigene Betriebslogik mit. Ein verteiltes Rechenframework ist stark, wenn Vor- und Nachverarbeitung wesentlich sind. Und der dritte Weg ist der, den fast alle zuerst gehen: die Engine im eigenen Deployment, mit voller Kontrolle. Lesen Sie dazu den Hinweis unten, denn er ist eine ehrliche Warnung aus der Praxis: Der eigene Weg ist als Einstieg verlockend und endet meist beim Nachbauen der Objekte aus Kapitel 5 — nur schlechter und ohne Pflege.

27:09 Die letzte Übung des Seminars, und sie hat bewusst eine kaufmännische Einheit. Machen Sie eine Skalierung an den Messwerten der Engine fest und drücken Sie ihre Wirkung in Wörtern je Kartenstunde aus. Geschafft ist es, wenn unter Last Abbilder hinzukommen und die Wartezeit sinkt, im Leerlauf verschwinden — und für beide Zustände eine Kostenrechnung je tausend Wörter vorliegt.

27:29 Wer schneller fertig ist, vergleicht das mit einer Skalierung nach Kartenauslastung. Und die Notiz sagt, warum diese Aufgabe am Ende steht: Die Kostenzahl je tausend Wörter ist die Sprache, in der dieses Seminar endet — und in der Sie es weitergeben können. Der erste Punkt ist das Urteil aus der Tabelle als Erlebnis: nach Kartenauslastung skaliert, und Sie kleben dauerhaft an der Obergrenze, ohne dass es an der Last liegt.

27:53 Der zweite ist eine Zeitrechnung, die man vorher machen muss: Die Beschaffungszeit neuer Karten dauert Minuten — wenn Ihre Beruhigungszeit kürzer ist, skalieren Sie ins Leere und wieder zurück. Der dritte ist der Kaltstart aus Kapitel 7, und er verbindet die letzten zwei Kapitel. Und der vierte ist die Abwägung aus Kapitel 4, jetzt als Warnung: Durchsatz optimiert und die Zeit bis zum ersten Wort dabei verdoppelt — die Rechnung sieht besser aus, die Nutzer sind unzufrieden.

Was ab hier trägt

28:20 Vier Sätze aus diesem Modul, und damit endet das Seminar. Eine Karte ist unteilbar und teuer — Leerlauf ist der eigentliche Kostenposten, nicht die Auslastung. Geräte werden angefordert wie Datenträger, nicht gezählt wie Rechenzeit. Skaliert wird nach dem, was die Engine meldet. Und der Kaltstart entscheidet, ob Herunterskalieren auf null tragbar ist.

28:42 Blicken wir kurz zurück: Wir haben in Modul 1 mit einer Textdatei angefangen, die beschreibt, wie ein Image entsteht. Am Ende steht ein Cluster, der Sprachmodelle nach Warteschlange skaliert. Dazwischen liegt immer dasselbe Prinzip — beschreiben, prüfen, messen. Das trägt weiter, auch wenn die Werkzeuge wechseln.