Ungleich verteilten Speicher nicht vorschnell korrigieren
Auf einem Server war der Arbeitsspeicher für ein großes lokales Modell bewusst stark ausgelastet. Der zweite Rechner hatte noch Reserven. Daraus entstand die Frage, ob kleinere CPU-Modelle dorthin umziehen könnten, ohne ihre eigentliche Aufgabe zu verschlechtern.
Die Namen der Prozessoren lieferten dafür keine ausreichende Antwort. Entscheidend waren die tatsächlich nutzbaren Ressourcen und die konkrete Anwendung. Statt einen pauschalen Geschwindigkeitsverlust anzunehmen, haben wir Modelle und Aufgaben gezielt miteinander verglichen.
Zuerst vergleichbare Bedingungen herstellen
Ein fairer Versuch benötigt denselben Modellstand, passende Einstellungen und identische Eingaben. Auch Kontextlänge und gleichzeitig laufende Aufgaben beeinflussen das Ergebnis. Werden mehrere Einstellungen auf einmal verändert, lässt sich eine Abweichung später schlecht erklären.
In meiner Versuchsreihe wurden außerdem die tatsächlich verfügbaren CPU-Ressourcen des Behälters geprüft. Die Kerne des physischen Rechners sind nicht automatisch vollständig in jedem Gast nutzbar. Eine ungeeignete Threadvorgabe kann den Vergleich zusätzlich verzerren.
Kaltstart und warmen Betrieb getrennt messen
Eine erste Anfrage muss möglicherweise noch das Modell laden. Spätere Anfragen können bereits auf ein geladenes Modell treffen. Diese beiden Fälle beantworten unterschiedliche Fragen und gehören getrennt in den Bericht.
Ollama liefert über die Schnittstelle unter anderem Lade- und Auswertungszeiten sowie Tokenzahlen. Daraus lassen sich Vergleiche aufbauen. Bei Streaming ist für die gefühlte Wartezeit zusätzlich interessant, wann die erste tatsächliche Ausgabe eintrifft. Eine hohe Ausgaberate allein erklärt nicht die gesamte Antwortzeit.
Die Aufgabe entscheidet über den Standort
Bei einem Telefongespräch ist eine schnelle Reaktion besonders wichtig. Eine Hintergrundanalyse kann eher etwas länger dauern. In meiner Anlage blieb deshalb das Telefonmodell am schnelleren bisherigen Standort, während geeignete kleinere Hintergrundmodelle auf den zweiten Rechner wechselten.
Ein Einbettungsmodell wurde ebenfalls nach seiner Aufgabe bewertet. Für einen regelmäßig laufenden Index kann ein langsamerer einzelner Aufruf noch gut passen. Wichtig ist, dass der gesamte Arbeitsablauf innerhalb seines Zeitrahmens bleibt und die Ergebnisse nach dem Wechsel weiter verwendbar sind.
Vorladung hilft, benötigt aber eine Grenze
Modelle im Speicher bereitzuhalten vermeidet wiederholtes Laden, belegt jedoch dauerhaft Arbeitsspeicher. Vorladung sollte deshalb nur für tatsächlich benötigte Modelle eingerichtet werden. Ein reserviertes, noch ungenutztes Modell muss nicht allein wegen seiner Existenz geladen bleiben.
Nach der Verteilung wurden in meiner Anlage die benötigten Hintergrundmodelle vorgehalten, andere nur bei Bedarf geladen. Die Überwachung kontrolliert diesen Zustand und berücksichtigt eine Speicherreserve. Die neue Aufteilung muss auch nach einem Neustart wieder nachvollziehbar entstehen.
Messwerte sind eine Entscheidungshilfe
Zum Abschluss zählen nicht nur einzelne Zahlen: Funktionieren die angebundenen Anwendungen, stimmt der verwendete Endpunkt und bleibt der Hauptrechner tatsächlich entlastet? Auch der Rückweg auf die bisherige Konfiguration gehört zur Vorbereitung.
Die Versuchsreihe war kein allgemeiner Leistungstest für jede Last. Gleichzeitige Telefongespräche und vollständige Sicherungsläufe wurden damit nicht als Gesamtszenario nachgewiesen. Ihr Nutzen lag in einer begründeten Aufteilung: zeitkritische Aufgaben am passenden Standort und freie Ressourcen für geeignete Hintergrundarbeit.