Eine schnelle Antwort auf eine einzelne kurze Frage zeigt, dass ein lokales Sprachmodell grundsätzlich läuft. Für eine Infrastrukturentscheidung ist ein Test mit den späteren Aufgaben und ihrer tatsächlichen Last wesentlich aussagekräftiger. Dazu gehören Antwortqualität, Wartezeiten, längere Eingaben, gleichzeitige Nutzung und der Betrieb nach einem Fehler.
Ein Pilot ist besonders nützlich, wenn vorab feststeht, welche Entscheidung sein Ergebnis ermöglichen soll. Beispielsweise: Reicht die vorhandene Umgebung, wird andere Hardware benötigt oder passt ein externer beziehungsweise hybrider Dienst besser? Die Testplanung folgt dieser Frage.
Mit einem kleinen, repräsentativen Aufgabenbestand beginnen
Geeignete Testaufgaben stammen aus dem vorgesehenen Arbeitsablauf: eine kurze fachliche Frage, die Zusammenfassung eines längeren freigegebenen Dokuments oder ein zu prüfender Skriptentwurf. Zu jeder Aufgabe wird festgelegt, woran ein brauchbares Ergebnis erkennbar ist.
Für Wissensfragen gehören erwartete Quellen und Fälle ohne ausreichende Grundlage dazu. Für Code sind fachliche Prüfung und passende Tests nötig. Vertrauliche Originaldaten werden nur in der dafür freigegebenen Umgebung eingesetzt; für die Vorbereitung können geeignete bereinigte oder eigens erstellte Testdaten genügen.
Qualität und Geschwindigkeit getrennt beurteilen
Ein Modell, das schnell falsche Ergebnisse liefert, erfüllt das Ziel nicht. Deshalb werden zuerst fachliche Brauchbarkeit, notwendige Korrekturen und der Umgang mit fehlenden Informationen bewertet. Danach lässt sich vergleichen, mit welcher Antwortzeit und welchem Aufwand diese Qualität erreicht wird.
Modellfassung, Quantisierung, Inferenzsoftware, Einstellungen und Testdaten werden festgehalten. Sonst kann eine schnellere Antwort auf einer geänderten Aufgabe oder einem anderen Qualitätsniveau beruhen. Auch ein wechselnder Dokumentenbestand kann den Vergleich einer RAG-Anwendung verändern.
Die Wartezeit in ihre Bestandteile zerlegen
- Wartezeit bis zum ersten Token
- Sie beschreibt, wann die Ausgabe beginnt. Warteschlange und Verarbeitung der Eingabe können diese Zeit beeinflussen. Zusätzlich sollte die wahrgenommene Zeit vom Absenden in der Anwendung bis zur sichtbaren Antwort gemessen werden.
- Laufende Ausgabe
- Die Geschwindigkeit während der Generierung beeinflusst, wie lange eine längere Antwort benötigt. Ein hoher Gesamtdurchsatz des Servers sagt dabei noch nicht, wie schnell ein einzelner Benutzer seine Antwort erhält.
- Gesamtdauer
- Sie umfasst den vollständigen Anwendungsvorgang. Suche, Dokumentenaufbereitung, Werkzeugaufrufe und Netzwege können hinzukommen.
- Streuung und Fehler
- Typische Werte und langsamere Randfälle werden gemeinsam betrachtet. Anzahl der Messungen, Zeitüberschreitungen und abgebrochene Aufgaben gehören zum Ergebnis.
Die offizielle vLLM-Metrikdokumentation (externer Link) unterscheidet unter anderem Warte-, Eingabe- und Ausgabemessungen. Welche Metriken eine konkrete Laufzeit bereitstellt, wird für die verwendete Version geprüft. Messwerte verschiedener Komponenten müssen denselben Zeitraum und dieselbe Aufgabe beschreiben.
Kurze Chats, lange Kontexte und Gleichzeitigkeit testen
Ein langer Kontext benötigt zusätzliche Verarbeitung und Speicher. Bei gleichzeitigen Anfragen teilen sich mehrere Vorgänge die verfügbaren Ressourcen. Die Ollama-Dokumentation zum Kontext (externer Link) und die vLLM-Optimierungsdokumentation (externer Link) erläutern entsprechende Zusammenhänge; konkrete Einstellungen sind versions- und hardwareabhängig.
Ein sinnvoller Test kombiniert deshalb kurze und längere Eingaben sowie eine zur geplanten Nutzung passende Gleichzeitigkeit. Neben gleichmäßig eintreffenden Anfragen werden auch erwartbare Spitzen betrachtet. Wird mehr Durchsatz durch Batching erreicht, muss weiterhin geprüft werden, ob die einzelnen Antwortzeiten für die Anwender passen.
Ein möglicher Prüfplan
Zunächst dieselben fachlichen Aufgaben einzeln ausführen. Danach kurze Anfragen und freigegebene Dokumentaufgaben gemeinsam testen. Anschließend einen erwartbaren Spitzenzeitraum nachbilden und das Verhalten bei Überlast beobachten. Die Zielwerte werden vorher mit den Anwendern vereinbart.
Dieser Plan ist ein anpassbares Beispiel. Er enthält keine gemessenen DAXS-Leistungszahlen und ersetzt keine Prüfung der konkreten Umgebung.
Start, laufenden Betrieb und Wiederanlauf unterscheiden
Nach einem Neustart muss ein Modell möglicherweise erst geladen werden. Diese kalte Startphase wird getrennt vom bereits geladenen Betrieb gemessen. Schnelle NVMe-Datenträger können Lade- und Datenoperationen unterstützen; daraus folgt keine pauschale Beschleunigung der Token-Generierung eines vollständig im GPU-Speicher liegenden Modells.
Zum Pilot gehören außerdem der Verlust einer Verbindung, ein abgebrochener Auftrag und der Neustart eines Dienstes. Die Anwendung sollte ihren Zustand verständlich anzeigen und einen sinnvollen Wiederholungs- oder Übergabeweg besitzen. Überlast darf nicht stillschweigend zu unvollständigen Ergebnissen führen.
Aus Ergebnissen eine Architekturentscheidung machen
Verglichen werden nutzbare Ergebnisse, Korrekturaufwand, Latenz, Kapazität und laufender Betrieb. Bei den Gesamtkosten zählen auch Administration, Wartung, Energie, Sicherung und erforderliche Verfügbarkeit. Für externe Dienste kommen deren konkrete Nutzungskosten und die vereinbarten Datenwege hinzu.
Das Ergebnis kann ein kleineres passendes Modell, zusätzliche Ressourcen, eine begrenzte Warteschlange oder ein anderes Betriebsmodell sein. Lokale, externe und hybride Ansätze werden anhand derselben Aufgabe bewertet. Ein Pilot soll eine belastbare nächste Entscheidung ermöglichen, nicht den Kauf einer bereits vorausgesetzten Hardware nachträglich begründen.
DAXS plant den Test, richtet eine geeignete Umgebung ein und wertet die Ergebnisse mit Ihrer IT aus. Die technische Grundlage erläutert unsere Fachseite zu lokalen LLM und Infrastruktur. Für angebundene Wissensbestände gehört die Qualität von Suche, Quellen und Berechtigungen in denselben Prüfrahmen.