Measuring and Reducing WebGPU Dispatch Overhead for LLM Inference
Diese Arbeit zeigt auf, dass der WebGPU-Dispatch-Overhead und nicht die Kernel-Qualität der primäre Flaschenhals für die Single-Batch-LLM-Inferenz in Browsern ist, wobei sie demonstriert, dass einfache Messungen die Kosten aufgrund von Synchronisationskonflikten überschätzen, und zu dem Schluss kommt, dass die Reduzierung der Dispatch-Anzahl durch Amortisation die effektivste Optimierungsstrategie darstellt.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie versuchen, ein massives, komplexes Videospiel auf einem Computer auszuführen, aber Sie müssen dies über einen sehr strengen, sicherheitsbewussten Manager tun, der nicht zulässt, dass Sie direkt auf die Hardware zugreifen. Dies ist die Welt, in der man Künstliche Intelligenz (speziell Large Language Models, oder LLMs) innerhalb eines Webbrowsers ausführt. Diese Modelle sind die Gehirne hinter Chatbots, die Geschichten schreiben, Matheaufgaben lösen und Gespräche führen können. Um sie auf Ihrem Laptop oder Telefon schnell laufen zu lassen, ohne einen Supercomputer zu benötigen, verwenden Entwickler ein spezielles Werkzeug namens WebGPU. Denken Sie an WebGPU als einen universellen Übersetzer, der es Ihrem Browser ermöglicht, mit Ihrer Grafikkarte zu kommunizieren (dem Teil, der normalerweise Videospiele rendert), damit diese die schwere Mathematik für die KI erledigen kann.
Es gibt jedoch einen Haken. In der Vergangenheit, als Entwickler versuchten, diese KI-Modelle schneller zu machen, konzentrierten sie sich darauf, die einzelnen mathematischen Schritte (genannt „Kernels“) effizienter zu gestalten, so als würde man den Motor eines Autos polieren. Aber dieses Paper stellt eine andere Frage: Was, wenn das Auto eigentlich in Ordnung ist, aber der Fahrer zu viel Zeit damit verbringt, ein- und auszusteigen? In der Welt des Browsers erfordert jeder einzelne mathematische Schritt einen „Dispatch“ – eine Anfrage, die vom Browser an die Grafikkarte gesendet wird, um die Arbeit zu starten. Das große Rätsel war: Wie viel Zeit wird tatsächlich dadurch verschwendet, dass man diese Anfragen sendet, im Vergleich zur Zeit, die für die eigentliche Mathematik aufgewendet wird? Das Verständnis dessen ist entscheidend, denn wenn wir zu viel Zeit nur damit verschwenden, den Computer zur Arbeit aufzufordern, wird sich der Chatbot langsam und träge anfühlen, egal wie intelligent die Mathematik dahinter ist.
Der „Stop-and-Go“-Verkehrsstau
Der Forscher in diesem Paper entdeckte, dass alle die Geschwindigkeit dieser KI-Anfragen falsch gemessen haben. Stellen Sie sich vor, Sie messen, wie lange ein Lieferfahrer braucht, um ein Paket abzugeben. Wenn Sie ihn messen, von dem Moment an, als er das Lager verlässt, zum Haus fährt, das Paket abliefert und dann den ganzen Weg zurück zum Lager fährt, um das nächste zu holen, dann messen Sie die gesamte Rundreise. Aber in der realen Welt der KI fährt der Fahrer nach jedem einzelnen Paket nicht zurück zum Lager. Er liefert einen ganzen Stapel Pakete auf einmal aus und fährt erst ganz am Ende zurück.
Das Paper zeigt, dass frühere Messungen wie das Timing dieser vollen Rundreise für jedes einzelne Paket waren. Sie haben die Zeit, die benötigt wird, um die Anfrage zu senden (den Dispatch), mit der Zeit verwechselt, die man damit verbringt, auf die Antwort des Computers zu warten (Synchronisation). Diese „Wartezeit“ ist riesig – es ist wie eine Pause von 450 Mikrosekunden. Als Forscher diese Wartezeit zu jedem einzelnen Schritt hinzufügten, glaubten sie, die Kosten für das Senden einer Anfrage seien etwa 20 Mal höher als sie eigentlich sind.
Durch die Verwendung einer neuen Methode namens „Sequential-Dispatch“ fand der Autor heraus, wie man nur den Akt des Sendens der Anfrage misst, ohne die lange Wartezeit dazwischen. Er fand heraus, dass die wahren Kosten viel niedriger sind: zwischen 24–36 Mikrosekunden auf einigen Systemen (Vulkan) und 32–71 Mikrosekunden auf anderen (Metal). Interessanterweise ist dieser Kostenfaktor identisch, egal ob der Computer „Float32“- oder „Float16“-Zahlen verwendet (zwei verschiedene Arten, Dezimalzahlen zu speichern), was beweist, dass die Verzögerung von den Regeln des Browsers kommt und nicht von der Mathematik selbst.
Der wahre Flaschenhals: Zu viele Stopps
Nachdem sie den wahren Preis einer einzelnen Anfrage kannten, fragte das Team: „Spielt das überhaupt eine Rolle?“ Um dies herauszufinden, führten sie ein kontrolliertes Experiment durch. Sie nahmen ein Standard-KI-Modell und änderten die Art und Weise, wie es verpackt war. Anstatt 876 winzige Anfragen an die Grafikkarte zu senden, um ein einziges Wort Text zu verarbeiten, wurden einige der Schritte „fusioniert“ (zusammengeklebt), sodass die Karte nur noch 564 Anfragen erhalten musste.
Hier ist der Clou: Sie haben die Mathematik innerhalb der Anfragen nicht schneller gemacht. Sie haben den Code nicht intelligenter gestaltet oder weniger Speicher verwendet. Sie haben lediglich die Anzahl der Male reduziert, mit denen der Browser an die Tür der Grafikkarte klopfen musste.
Das Ergebnis? Die KI wurde 53 % schneller. Die Zeit, die benötigt wurde, um das erste Wort einer Antwort zu generieren, sank von 71,4 ms auf 41,6 ms.
Dieses Experiment bewies, dass bei der gebräuchlichsten Einstellung (der Verarbeitung eines Wortes gleichzeitig, bekannt als „Batch Size 1“) das Hauptproblem nicht die langsame Mathematik oder der volle Speicher ist. Das Problem ist schlichtweg, dass es zu viele „Klopfzeichen an der Tür“ gibt. Der Autor schloss die Idee explizit aus, dass besserer Mathematikcode oder geringerer Speicherverbrauch der Grund für die Geschwindigkeitssteigerung war. Das Einzige, was sich änderte, war die Anzahl der Dispatches.
Was dies für die Zukunft bedeutet
Das Paper kommt zu dem Schluss, dass wir, wenn wir wollen, dass Browser KI-Chatbots reibungslos ausführen, aufhören sollten, jeden einzelnen mathematischen Schritt zu perfektionieren, und stattdessen damit beginnen sollten, sie zusammenzufassen. Es ist, als würde man erkennen, dass man, um einen Lieferwagen schneller zum Haus zu bringen, nicht den Fahrer schneller rennen lassen sollte, sondern sicherstellen sollte, dass er einen größeren Karton trägt, damit er nicht so viele Fahrten machen muss.
Der Autor schlägt vor, dass die Lösung in der „Dispatch-Amortisierung“ liegt – ein eleganter Weg zu sagen, dass wir die Kosten dieser „Klopfzeichen“ über viele Aufgaben verteilen müssen, damit die Verzögerung nicht so stark ins Gewicht fällt. Er weist darauf hin, dass dies nicht nur Änderungen in der Software erfordern könnte, die die KI ausführt, sondern potenziell auch in den WebGPU-Regeln selbst, indem man dem Browser vielleicht erlaubt, einen „Command Graph“ (eine vorgeplante Route) zu akzeptieren, anstatt jeden einzelnen Schritt einzeln zu prüfen.
Obwohl diese Erkenntnisse auf spezifischer Hardware (wie der NVIDIA RTX 5090) und einer spezifischen Art der KI-Ausführung basieren, ist die Botschaft klar: Für den Moment ist das Geheimnis für schnellere KI in Ihrem Browser nicht ein schnellerer Motor, sondern weniger Stopps.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.