Viele Anfragen auf einmal statt nacheinander
- Matt
Für einen Vergleich habe ich 36 Anfragen an ein Sprachmodell geschickt, sauber nacheinander: Anfrage, Antwort abwarten, nächste Anfrage. Whipyard, mein Vermittler vor der Grafikkarte, hat daraus ein Desaster gemacht. In der Lücke zwischen zwei Anfragen sah es nur noch wartende Aufträge eines anderen Modells, entlud meins, lud das andere, und für meine nächste Anfrage ging es wieder zurück. Das Modell wurde 20-mal in sieben Minuten geladen, jedes Mal rund zehn Sekunden.
Der Scheduler kann nur einplanen, was er sieht. Bei synchronen Einzelanfragen sieht er immer genau eine. Also alles auf einmal und asynchron abgeben:
POST /v1/chat/completions
X-Whipyard-Submit: async
X-Whipyard-Priority: 20
Whipyard antwortet sofort mit einer Auftrags-ID, die Ergebnisse holt man später ab. Weil jetzt alle 36 in der Warteschlange stehen, laufen sie auf einer einzigen Ladung durch.
Zusätzlich hält der Scheduler inzwischen Wort: Wurde für einen wartenden Auftrag schon etwas entladen, laufen er und die bereits wartenden Aufträge desselben Modells zuerst. Ein Nachlaufen, also das Modell nach jeder Anfrage vorsorglich ein paar Sekunden geladen zu lassen, habe ich bewusst nicht eingebaut. Das würde schlechte Clients belohnen.
Der Haken: Asynchron heißt Abfragen, und die Ergebnisse müssen irgendwo liegen, bis sie jemand abholt. Das hat mir später die Platte gefüllt. Worum es bei Whipyard überhaupt geht, steht im Beitrag zum Türsteher für die Grafikkarte. Das Muster ist alt, schon HTTP kennt dafür den Status 202 Accepted.