Langer Kontext macht Inferenz zu einem Speicherverwaltungsproblem

Das gleiche Modell kann unterschiedliche Lasten erzeugen

Eine kurze Frage und eine lange Dokumentenanalyse verwenden möglicherweise dasselbe Modell, stellen jedoch sehr unterschiedliche Anforderungen an das System. Es muss mehr Kontext verarbeitet werden und der Dienst muss seinen Betriebszustand beibehalten, während er eine Antwort generiert. Mehrere gleichzeitige Anfragen vervielfachen diese Anforderungen.

Aus diesem Grund ist eine Demonstration mit einer Eingabeaufforderung eine schwache Grundlage für die Dimensionierung einer Produktionsdienstleistung. Das Speicherprofil hängt von der Mischung der Anforderungen und den verwendeten Einstellungen ab, nicht nur von der auf der Modellkarte aufgedruckten Parameteranzahl.

Vorfüllen und Dekodieren erledigen unterschiedliche Aufgaben

Inferenz unterscheidet üblicherweise die Verarbeitung der Eingabe, oft als Vorfüllung bezeichnet, von der anschließenden Generierung von Ausgabetokens oder Dekodierung. Diese Phasen können von unterschiedlichen Planungs- und Ressourcenoptionen profitieren. Die Dynamo-Architektur von NVIDIA unterstützt explizit disaggregierte Inferenz, Routing unter Berücksichtigung des zwischengespeicherten Kontexts und die Verwaltung des Caches über Speicherebenen hinweg. NVIDIA Dynamo: verteilte Inferenzarchitektur ↗

Das ist ein Beweis dafür, dass der Software-Stack das Problem angeht. Es besteht kein Anspruch darauf, dass die Trennung der Phasen jede Bereitstellung verbessern wird. Zusätzliche Koordination und Datenverschiebung sind mit Kosten verbunden, und ein kleiner Dienst benötigt möglicherweise nicht die Komplexität eines verteilten Designs.

Zwischengespeicherter Kontext ist nützlich, aber nicht kostenlos

Durch die Wiederverwendung geeigneter zwischengespeicherter Zustände können wiederholte Arbeiten vermieden werden. Das Halten dieses Zustands verbraucht Ressourcen, und das Verschieben zwischen Speicherorten oder Speicherebenen kann zu Datenverkehr und Latenz führen. Der Nutzen hängt davon ab, ob Anfragen tatsächlich genügend Kontext wiederverwenden, um die Vereinbarung zu rechtfertigen.

Ein Dokumentassistent, der wiederholt Fragen zu demselben Material stellt, verhält sich möglicherweise anders als ein Dienst, der nicht zusammenhängende Anfragen erhält. Ein Benchmark sollte das erwartete Wiederverwendungsmuster darstellen und nicht davon ausgehen, dass es sich bei jeder Anfrage um einen Cache-Treffer handelt.

Es sollte auch enthalten, was passiert, wenn der Cache kalt, voll oder nicht verfügbar ist. Diese Bedingungen sind bei Neustarts und Nachfragespitzen von Bedeutung, wenn ein Dienst häufig über die geringste freie Kapazität verfügt.

Größe für die Anforderungsverteilung

Messen Sie typische und anspruchsvolle Eingaben, erwartete Ausgabelängen und realistische Parallelität. Zeichnen Sie die maximale Speichernutzung, die Zeit bis zur ersten Ausgabe und die nachhaltige Generierungsleistung auf. Behalten Sie beim Systemvergleich die Einstellungen für die Ausgabequalität bei.

Das Ergebnis deutet möglicherweise auf einen Beschleuniger mit größerem Speicher, eine andere Planungsstrategie oder eine strengere Anwendungsbeschränkung für den Kontext hin. Es kann sich auch herausstellen, dass durch Softwareänderungen genügend Kapazität bereitgestellt wird, ohne dass ein Hardwareaustausch erforderlich ist.

Die Kauflektion besteht darin, den Speicher nicht als statische Modellgrößenberechnung zu behandeln. Ein funktionierender Inferenzdienst verfügt über eine sich ändernde Anzahl von Anforderungen. Das Verständnis dieser Population bietet eine viel stärkere Grundlage für die Auswahl von GPU-Speicher, Host-Ressourcen und der Software, die zu ihrer Koordinierung verwendet wird.