Il contesto lungo trasforma l'inferenza in un problema di gestione della memoria

Lo stesso modello può creare carichi diversi

Una domanda breve e un'analisi di un documento lungo possono utilizzare lo stesso modello ponendo al sistema richieste molto diverse. È necessario elaborare più contesto e il servizio deve mantenere lo stato funzionante mentre genera una risposta. Più richieste simultanee moltiplicano tali richieste.

Questo è il motivo per cui una dimostrazione con un prompt è una base debole per dimensionare un servizio di produzione. Il profilo di memoria dipende dal mix di richieste e dalle impostazioni utilizzate, non solo dal conteggio dei parametri stampati sulla scheda modello.

La precompilazione e la decodifica svolgono un lavoro diverso

L'inferenza distingue comunemente l'elaborazione dell'input, spesso chiamata prefill, dalla successiva generazione di token di output, o decodifica. Queste fasi possono trarre vantaggio da diverse scelte di pianificazione e risorse. L'architettura Dynamo di NVIDIA supporta esplicitamente l'inferenza disaggregata, il routing che considera il contesto memorizzato nella cache e la gestione della cache tra livelli di memoria. NVIDIA Dynamo: architettura di inferenza distribuita ↗

Questa è la prova che lo stack software sta risolvendo il problema. Non si intende affermare che separare le fasi migliorerà ogni implementazione. Il coordinamento aggiuntivo e lo spostamento dei dati comportano costi e un servizio di piccole dimensioni potrebbe non richiedere la complessità di una progettazione distribuita.

Il contesto memorizzato nella cache è utile, ma non gratuito

Il riutilizzo di uno stato memorizzato nella cache adatto può evitare lavori ripetuti. Mantenere quello stato consuma risorse e spostarlo tra posizioni o livelli di memoria può introdurre traffico e latenza. Il vantaggio dipende dal fatto che le richieste riutilizzino effettivamente un contesto sufficiente per giustificare l'accordo.

Un assistente documentale che pone ripetutamente domande sullo stesso materiale potrebbe comportarsi in modo diverso da un servizio che riceve richieste non correlate. Un benchmark dovrebbe rappresentare il modello di riutilizzo previsto anziché presupporre che ogni richiesta sia un successo nella cache.

Dovrebbe includere anche cosa succede quando la cache è fredda, piena o non disponibile. Queste condizioni sono importanti durante i riavvii e i picchi di domanda, quando un servizio spesso ha la capacità di riserva minima.

Dimensione per la distribuzione delle richieste

Misura input tipici e impegnativi, lunghezze di output previste e concorrenza realistica. Registra l'utilizzo massimo della memoria, il tempo necessario per ottenere il primo output e le prestazioni di generazione sostenute. Mantieni fisse le impostazioni della qualità di output quando confronti i sistemi.

Il risultato può suggerire un acceleratore di memoria più grande, una diversa strategia di pianificazione o un limite di applicazione più rigido nel contesto. Potrebbe anche rivelare che le modifiche al software forniscono capacità sufficiente senza una sostituzione dell'hardware.

La lezione sull'acquisto è quella di evitare di trattare la memoria come un calcolo statico delle dimensioni del modello. Un servizio di inferenza funzionante ha una popolazione di richieste in continua evoluzione. Comprendere che la popolazione fornisce una base molto più forte per scegliere la memoria GPU, le risorse dell'host e il software utilizzato per coordinarli.