Die p99-Latenz deines Modells liegt bei 400 Millisekunden und das Produkt braucht 50. Wie gehst du das an?

Erst profilen, dann optimieren: zerleg die 400 Millisekunden in Feature-Abruf, Preprocessing, den Forward Pass und Netzwerk, denn das Modell ist oft nicht der größte Anteil. Dann greif das größte Stück an. Typische Gewinne sind Nebenläufigkeit bei Feature-Lookups, Caching, Quantisierung, eine kompilierte Runtime, ein destilliertes Modell und Arbeit vom Request-Pfad wegzuschieben. Ziel ist explizit p99, nicht der Mittelwert.

Ich würde das Modell nicht anfassen, bevor ich eine Aufschlüsselung habe. Ich trace einen Request end to end und messe Feature-Abruf, Deserialisierung, Preprocessing, den Forward Pass, Postprocessing und Netzwerk. Jedes Mal, wenn ich das bei einem Service gemacht habe, der sich langsam anfühlte, war das Modell eine Minderheit der Zeit. Der letzte lag bei rund 400 Millisekunden gesamt, davon etwa 90 im Modell und über 200 im Warten auf drei sequenzielle Feature-Lookups gegen einen entfernten Store. Das zu beheben war kein ML-Problem, es hieß, sie nebenläufig abzusetzen und die zwei zu cachen, die sich nur täglich änderten, und allein das hat den größten Teil des Wegs gebracht. Danach schaue ich aufs Modell: Dynamic Batching, int8-Quantisierung oder der Export in eine kompilierte Runtime wie ONNX Runtime oder TensorRT, was bei kleineren Modellen häufig ein Faktor zwei bis drei ohne Genauigkeitsverlust ist. Die andere Sache speziell zu p99 ist, dass ein Tail so weit über dem Median meist gar nicht Compute ist, sondern Queueing unter Last, ein Cold Start auf einer frischen Replik oder Garbage Collection. Ich prüfe also, ob p50 schon in Ordnung ist, denn wenn ja, heißt die Lösung Kapazität und warme Pools.