Die Inferenz kostet mehr, als das Produkt einbringt. Wie senkst du das, ohne die Qualität zu zerlegen?

Miss die Kosten pro Request und finde, wo sie sich konzentrieren, denn Traffic ist meist schief verteilt. Dann in grober Reihenfolge: wiederholte oder fast identische Requests cachen, kaskadieren, damit ein billiges Modell die leichte Mehrheit erledigt und nur unsichere Fälle eskaliert, Quantisierung plus kompilierte Runtime, passend dimensionierte Hardware mit ordentlichem Batching, und schließlich Arbeit streichen, die downstream niemand nutzt.

Ich hole mir zuerst die Kosten pro Request und schneide sie auf, weil Traffic fast immer schief verteilt ist und eine kleine Klasse von Requests dazu neigt, das Budget zu fressen. Der billigste Gewinn ist dann meist Caching. Auf einem System war ein spürbarer Anteil der Requests innerhalb von Minuten exakte Wiederholungen, und ein kurzlebiger Cache mit normalisiertem Input als Key hat für einen Tag Arbeit einen Brocken Last entfernt. Als Nächstes Kaskadierung. Lass ein kleines billiges Modell auf allem laufen und eskaliere nur dann zum teuren, wenn das kleine unsicher ist. Wenn das kleine Modell siebzig Prozent des Traffics souverän erledigt, hast du die Kosten um den größten Teil dieses Anteils gesenkt und behältst die Genauigkeit auf den schweren Fällen, und die Eskalationsschwelle ist gegen ein Qualitätsbudget einstellbar. Danach kommt das Engineering: Quantisierung, eine kompilierte Runtime, Dynamic Batching, damit der Beschleuniger nicht leerläuft, und die Prüfung, ob wir auf Hardware sitzen, die für das Modell überdimensioniert ist. Die letzte Frage ist die unangenehme, nämlich ob jede Vorhersage überhaupt genutzt wird. Ich habe mal eine Pipeline gefunden, die nächtlich die gesamte Nutzerbasis gescort hat, obwohl die Oberfläche immer nur die obersten paar tausend angezeigt hat, und weniger Entities zu scoren war die größte Einzelersparnis.