SwiftQK: Fast and Communication-Efficient Tensor Parallelism for Query-Key Normalization

Stel je voor dat je probeert een enorme, ongelooflijk slimme robothersen te draaien die verhalen kan schrijven, wiskundige problemen kan oplossen en kan chatten als een mens. Dit "brein" wordt een Large Language Model (LLM) genoemd. Om dit te laten werken, gebruiken wetenschappers duizenden krachtige computerchips genaamd GPU's. Maar deze chips hebben een probleem: ze zijn als briljante maar kleine werkers die tegelijkertijd maar een kleine hoeveelheid informatie in hun zakken kunnen dragen. Om grote problemen op te lossen, moeten ze samenwerken door briefjes naar elkaar toe te sturen. Deze teamwork wordt "Tensor Parallelism" genoemd.

Echter, er is een lastig onderdeel van het robotbrein genaamd "Query-Key Normalization". Denk aan dit als een kwaliteitscontrole waarbij de robot controleert of zijn gedachten gebalanceerd en stabiel zijn voordat hij begint met schrijven. In het verleden moest elke werker, om deze controle uit te voeren, zijn hele schrift aan alle andere werkers laten zien, zodat ze een enkele "balansscore" konden berekenen. Dit betekende een enorme verkeersopstopping van briefjes die heen en weer werden gestuurd, wat alles vertraagde. De onderzoekers in dit artikel merkten op dat deze verkeersopstopping de belangrijkste reden was waarom hun super snelle robotbrein vastliep. Ze wilden een manier vinden om de kwaliteitscontrole uit te voeren zonder dat iedereen zijn hele schrift hoefde te tonen en uit te wisselen.

Ontmoet SwiftQK, een slimme nieuwe truc uitgevonden door een team van computerwetenschappers om deze verkeersopstopping op te lossen. In plaats van elke GPU te dwingen zijn hele schrift uit te wisselen (wat enorm groot en traag is), verandert SwiftQK de spelregels. Het realiseert zich dat je, om de "balansscore" te berekenen, niet het hele schrift nodig hebt; je hebt alleen één getal nodig dat de totale "luidheid" of "energie" van de briefjes vertegenwoordigt.

Hier is hoe SwiftQK werkt, met behulp van een speelse analogie: Stel je een groep vrienden voor die probeert het totale volume van een liedje te achterhalen dat op hun telefoons wordt afgespeeld. Op de oude manier zou iedereen zijn volledige songtekst naar de groep moeten schreeuwen zodat ze die allemaal bij elkaar kunnen optellen. Dat duurt eeuwig. Met SwiftQK fluistert elke vriend slechts één getal — het totale volume van hun liedje — naar de groep. De groep telt deze paar getallen bij elkaar op om het totale volume direct te krijgen.

Maar SwiftQK fluistert niet alleen; het doet iets nog slimmer. Terwijl de vrienden hun getallen naar elkaar fluisteren, staan de anderen niet zomaar stil te wachten. Ze beginnen onmiddellijk aan hun eigen huiswerk (het vermenigvuldigen van hun briefjes met een speciale waarde). Het "fluisteren" (communicatie) en het "huiswerk" (berekening) gebeuren tegelijkertijd, perfect overlappend, zodat er geen tijd verloren gaat. De onderzoekers noemen dit een "deadlock-safe persistent kernel", wat een chique manier is om te zeggen dat ze een systeem hebben opgezet waarbij iedereen precies weet wanneer hij moet praten en wanneer hij moet werken, zodat niemand blijft wachten op een vriend die bezig is.

De resultaten van deze nieuwe methode zijn indrukwekkend. Wanneer het team SwiftQK testte op recente, krachtige taalmodellen, ontdekten ze dat het de "kwaliteitscontrole"-stap 81,4% tot 93,9% sneller maakte vergeleken met de oude methode van het uitwisselen van volledige schriften. In een praktijktest waarbij de robot vragen beantwoordde voor veel mensen tegelijk, verminderde SwiftQK de tijd die nodig was om een reactie te krijgen (de zogenaamde TPOT) met 29,5% vergeleken met de standaardmethode. Zelfs in vergelijking met een iets verbeterde versie van de oude methode, die ook probeerde getallen te fluisteren, was SwiftQK nog steeds 14,3% sneller.

Het artikel laat zien dat door slim te zijn over welke data gedeeld moet worden en door ervoor te zorgen dat de computers werken terwijl ze praten, we deze enorme AI-breinen veel soepeler en sneller kunnen laten draaien. Het bewijst dat je niet een hele bibliotheek hoeft te versturen om een enkele typefout te herstellen; soms is het versturen van een enkel getal genoeg, zolang je het maar op het juiste moment doet.