Software-Systeme aufzubauen, die Analysen nutzen, die auf KI-Methoden basieren, ist heute kein Problem mehr. Es gibt viele vorgefertigte Bausteine. Abhängig von der Art der Anwendung werden jedoch schnell viele, individuelle KI-Modelle je Nutzer benötigt. Das geschieht zum Beispiel, wenn ein Anwender unterschiedliche Projekte durchführt und für jedes ein anderes KI-Modell trainiert und genutzt werden muss. Bei projektspezifischen Klassifikatoren ist das keine Seltenheit. Im Laufe der Zeit können somit viele unterschiedliche Modelle entstehen, die der Nutzer alle gleichzeitig verfügbar haben möchte.

Eventuell wird das Software-System parallel an verschiedene Kunden lizenziert, z.B. in Form einer SaaS-Lösung. In einem solchen Fall multipliziert sich dann die Anzahl der benötigten KI-Modelle schnell zu mehreren hundert, wenn nicht gar tausend davon.

Natürlich sollen die Anfragen für Analysen an das System in Millisekunden beantwortet werden. Leider benötigen Machine-Learning- und Deep-Learning-Modell viele Ressourcen und eine nicht zu vernachlässigende ramp-up-Phase, bis sie nutzbar sind. Am Ende müssten für alle möglichen Modelle Services gestartet und fortwährend laufend vorgehalten werden. Nur so lässt sich die Forderung nach einer Antwort in wenigen Millisekunden für jede Anfrage realisieren.

Das ist betriebswirtschaftlich ein NoGo: Durch den enormen Ressourcenverbrauch entstehen extreme Kosten pro Transaktion und zusätzlich ist es auch ein ökologisches Desaster. Jeweils für sich gesehen, werden die einzelnen Services/KI-Modelle vergleichsweise selten genutzt. Da jedoch alle ständig lauffähig gehalten werden müssen, ergibt sich ein hoher Energieverbrauch bei nur geringem produktivem Nutzen. Green IT ist das wirklich nicht.

Eine Möglichkeit dieser Falle zu entgehen, besteht in einem schnellen Ein- und Auslagern der Modelle je nach Anforderung und Bedarf. Das hört sich einfacher an, als es ist. Nach dem Laden eines KI-Modelles wird während der ramp-up-Phase in vielen Fällen eine ‘arbeitsfähige, interne Struktur’ von diesem erzeugt. Diese interne Struktur ist im Normalfall nicht im Arbeitsspeicher verschiebbar. Ohne eine Erweiterung des Systems, das die Modelle lädt und verarbeitet, ist das Ein- und Auslagern der laufenden KI-Modelle also kaum umsetzbar.

Zuerst wird eine interne Struktur des Modelles benötigt, die nicht von einer speziellen Position im Arbeitsspeicher abhängt. Dabei verbieten sich zum Beispiel Zeiger auf Speicherbereiche und dürfen darin nicht enthalten sein.

In der ramp-up-Phase wird das trainierte Modell geladen und in die neue, interne Struktur gewandelt. Damit ist das KI-System in einem lauffähigen Zustand. Nach Abschluss dieses Initialisierungsschrittes kann durch eine weitere Veränderung von dem internen Modellen ein Dump gezogen und gespeichert werden.

Eine weitere Anpassung des KI-Systems dient anschließend dazu, je nach Arbeitsanforderung das benötigte Modell auszutauschen. Die lauffähigen Dumps benötigen keine ramp-up-Phase mehr, sind nach dem Tausch also sofort nutzbar. Mehrere Caching-Ebenen können für eine weitere Beschleunigung des Austauschvorgangs genutzt werden.

Im Ergebnis dieser Veränderungen des KI-Systems ist dann wirklich ein schneller Austausch von Modellen innerhalb von Millisekunden möglich. Wenige Instanzen des KI-Systems können viele unterschiedliche Modelle nutzen. Das kommt dem Einsatz in einer Microservices-Architektur entgegen. Zusätzlich ergibt sich eine Einsparung von Ressourcen und natürlich die Senkung des Energieverbrauchs – Green IT.

Dieser Artikel erschien zuerst auf  https://matthias.boldt.org/post/flut-an-ki-modellen/