Lange context verandert gevolgtrekking in een geheugenbeheerprobleem

Hetzelfde model kan verschillende belastingen veroorzaken

Een korte vraag en een lange documentanalyse kunnen hetzelfde model gebruiken, terwijl er zeer verschillende eisen aan het systeem worden gesteld. Er moet meer context worden verwerkt en de service moet de werkende status behouden terwijl deze een antwoord genereert. Meerdere gelijktijdige verzoeken vermenigvuldigen deze eisen.

Dit is de reden waarom een ​​demonstratie met één prompt een zwakke basis is voor het dimensioneren van een productiedienst. Het geheugenprofiel is afhankelijk van de mix van verzoeken en de gebruikte instellingen, en niet alleen van het aantal parameters dat op de modelkaart is afgedrukt.

Voorinvullen en decoderen doen verschillend werk

Inferentie maakt doorgaans onderscheid tussen de verwerking van de invoer, vaak prefill genoemd, en de daaropvolgende generatie van uitvoertokens of decodering. Deze fasen kunnen profiteren van verschillende plannings- en resourcekeuzes. De Dynamo-architectuur van NVIDIA ondersteunt expliciet gedesaggregeerde gevolgtrekking, routering die rekening houdt met in de cache opgeslagen context en beheer van cache over geheugenlagen heen. NVIDIA Dynamo: gedistribueerde inferentiearchitectuur ↗

Dat is een bewijs dat de softwarestack het probleem aanpakt. Er wordt niet beweerd dat het scheiden van de fasen elke implementatie zal verbeteren. Extra coördinatie en gegevensverplaatsing brengen kosten met zich mee, en een kleine dienst heeft misschien niet de complexiteit van een gedistribueerd ontwerp nodig.

Gecachte context is nuttig, maar niet gratis

Hergebruik van een geschikte cachestatus kan herhaald werk voorkomen. Het behouden van die status verbruikt bronnen, en het verplaatsen ervan tussen locaties of geheugenlagen kan verkeer en latentie veroorzaken. Het voordeel hangt af van de vraag of verzoeken daadwerkelijk voldoende context hergebruiken om de regeling te rechtvaardigen.

Een documentassistent die herhaaldelijk vragen stelt over hetzelfde materiaal kan zich anders gedragen dan een dienst die niet-gerelateerde verzoeken ontvangt. Een benchmark moet het verwachte hergebruikpatroon weergeven, in plaats van aan te nemen dat elk verzoek een cachetreffer is.

Het moet ook bevatten wat er gebeurt als de cache koud, vol of niet beschikbaar is. Deze omstandigheden zijn van belang tijdens herstarts en pieken in de vraag, wanneer een dienst vaak de minste reservecapaciteit heeft.

Grootte voor de verzoekverdeling

Meet typische en veeleisende inputs, verwachte outputlengtes en realistische gelijktijdigheid. Registreer piekgeheugengebruik, tijd tot eerste uitvoer en duurzame generatieprestaties. Houd de instellingen voor de uitvoerkwaliteit vast bij het vergelijken van systemen.

Het resultaat kan wijzen op een versneller met een groter geheugen, een andere planningsstrategie of een strengere toepassingslimiet op de context. Het kan ook uitwijzen dat softwarewijzigingen voldoende capaciteit bieden zonder hardwarevervanging.

De aankooples is om te voorkomen dat het geheugen wordt behandeld als een statische berekening van de modelgrootte. Een werkende inferentiedienst heeft een wisselende populatie van verzoeken. Het begrijpen van deze populatie geeft een veel sterkere basis voor het kiezen van GPU-geheugen, hostbronnen en de software die wordt gebruikt om deze te coördineren.