notizia

Apple consente ai modelli di grandi dimensioni di imparare a essere pigri: sputare il primo gettone più velocemente e mantenere la precisione

2024-08-02

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina



Rapporto sul cuore della macchina

Dipartimento editoriale di Machine Heart

Essere pigri ti fa lavorare meglio.

Llama 3.1 è appena uscito, lo hai già provato? Anche se il tuo PC ha le specifiche più recenti, potresti comunque riscontrare un ritardo significativo quando esegui la versione 8B più piccola. Per migliorare l’efficienza del ragionamento del modello, i ricercatori hanno ideato una varietà di metodi, ma molti di essi faranno sì che il modello sacrifichi una certa accuratezza.

Recentemente, un gruppo di ricerca di Apple e Meta AI ha proposto un nuovo metodo in grado di aumentare la velocità di inferenza della fase di preriempimento di Llama 2 fino a più di 2 volte, garantendo allo stesso tempo che la precisione non diminuisca in modo significativo. L'accelerazione di 3.1 fornisce qualche ispirazione. Chiamano questo approccio LazyLLM, che sta per Lazy Large Language Model.



Titolo dell'articolo: LazyLLM: potatura dinamica dei token per un'inferenza LLM efficiente a lungo contesto

Indirizzo del documento: https://arxiv.org/abs/2407.14057

Allora come fanno a rendere LLM pigro? Per comprendere il loro metodo, dobbiamo prima sapere qual è il processo di inferenza LLM standard basato su prompt. In poche parole, il processo è diviso in due fasi: precompilazione e decodifica, come mostrato nella Figura 1.



Nella fase di prepopolamento, il modello calcola e salva la cache KV di ciascun token nel prompt e prevede il primo token. Chiamiamo il tempo trascorso nella fase di prepopolamento "time to first token (TTFT)".

Alla fase di preriempimento segue la fase di decodifica. In questa fase, il modello utilizza nuovamente il KV memorizzato nella cache per decodificare iterativamente il token successivo finché non viene soddisfatto il criterio di arresto.

Durante la fase di prepopolamento, tutti i livelli Transformer utilizzano tutti i token nel prompt. TTFT può essere lento quando il prompt è lungo perché l'attuale miglior LLM basato su Transformer è sia profondo che ampio e il costo dell'attenzione informatica cresce quadraticamente con il numero di token nel prompt. Ad esempio, Llama 2 (versione 7B) impila 32 strati di Transformers e la dimensione del modello è 4096. In questo caso, TTFT richiede 21 volte il walltime di ogni successiva fase di decodifica, che rappresenta circa il 23% del tempo di generazione totale sul benchmark LongBench.

Pertanto, per rendere efficiente l'inferenza LLM, l'ottimizzazione del TTFT è un passaggio molto critico.

Sebbene l'ottimizzazione dell'inferenza LLM sia un'area di ricerca attiva, molti metodi si concentrano sul miglioramento della velocità di inferenza della fase di decodifica. I ricercatori hanno prestato poca attenzione al miglioramento del TTFT. Alcuni risultati della ricerca basata sulla compressione possono implicitamente migliorare il TTFT riducendo la dimensione del LLM.

Un'altra direzione di ricerca è quella di migliorare il TTFT nell'ambito dell'architettura statica del trasformatore. Per questa direzione di ricerca, sorge spontanea una domanda: tutti i token tempestivi sono essenziali quando si genera il primo token?

La Figura 2 mostra i risultati dell'analisi LLM sul benchmark LongBench.



Si può vedere che per il primo token generato, i punteggi di attenzione dei token di input sono molto scarsi, il che dimostra che molti token nel prompt di input sono ridondanti e, anche se vengono rimossi, non influenzeranno la previsione del successivo gettone. Questa osservazione è la base per il LazyLLM proposto dal team.

I vantaggi di LazyLLM includono un'ampia gamma di applicazioni, nessuna necessità di formazione e buoni risultati. La Figura 3 mette a confronto LLM standard e LazyLLM.



PigroLLM

La Figura 4 mostra la struttura generale di LazyLLM.



Partendo dal contesto completo, LazyLLM eliminerà gradualmente i token, riducendo così gradualmente il numero di calcoli utilizzati per ottenere il modello finale. Tieni presente che LazyLLM consente al modello di selezionare diversi sottoinsiemi di token in diversi passaggi di generazione, anche se alcuni di essi potrebbero essere stati eliminati nei passaggi precedenti. Rispetto all'eliminazione statica (tutti i token vengono eliminati contemporaneamente), l'eliminazione dinamica ottimizza la previsione del token successivo in ogni passaggio di generazione, il che aiuta a mantenere le prestazioni del modello.

Potatura progressiva dei token

Alcuni studi precedenti hanno utilizzato con successo la potatura dei token per ottimizzare l'inferenza LLM. Tuttavia, questi metodi devono accumulare mappe di attenzione complete dei primi token previsti per analizzare l'importanza dei token tempestivi prima che inizi la potatura. Pertanto, non sono adatti per ridurre il TTFT perché devono ancora calcolare tutte le cache KV durante la fase di pre-riempimento.

In confronto, LazyLLM è "molto pigro" e calcolerà solo i token importanti per prevedere il token successivo a partire dalla prima iterazione dell'inferenza (fase di precompilazione).

Nella prima iterazione, una sfida chiave è stata determinare l’importanza di ciascun token. Ispirandosi a ricerche precedenti che mostravano che gli stati nascosti dei token si evolvono mentre passano attraverso gli strati Transformer, la soluzione del team è quella di utilizzare l'eliminazione dei token strato per strato in ogni fase di generazione. Nello specifico, utilizzano la mappa dell'attenzione di ciascun livello per determinare l'importanza del token di input rispetto al token da prevedere.

Dopo aver calcolato il punteggio di confidenza del token, un altro problema difficile è determinare la soglia per l'eliminazione del token.

Nello specifico, per livelli diversi e attività diverse, questa soglia può cambiare al variare del punteggio di attenzione. La soluzione del team è utilizzare la strategia di selezione del percentile top-k. Nello specifico, se il punteggio di confidenza di un token è inferiore al kesimo percentile nel token di input, viene eliminato. Una volta eliminato, un token non partecipa più al calcolo di tutti i livelli successivi.

Cioè, i token utilizzati dai livelli successivi sono un sottoinsieme dei token utilizzati dai livelli precedenti.

Esperimenti successivi mostrano che quando la posizione dello strato di potatura e il numero di token potati sono diversi, anche le prestazioni cambieranno. Nello specifico, per lo stesso livello Transformer, man mano che sempre più token vengono rimossi mediante la potatura, le prestazioni del modello diminuiranno gradualmente.

Hanno anche scoperto che, rispetto alla potatura negli strati iniziali, si ottenevano prestazioni migliori quando la potatura veniva eseguita negli strati successivi, indicando che gli strati successivi sono meno sensibili alla potatura simbolica. Per bilanciare meglio velocità e precisione, il team ha utilizzato la potatura progressiva come mostrato nella Figura 4, conservando più token nei primi strati e riducendo poi gradualmente il numero di token man mano che passano agli strati successivi.

Aux Cache (cache ausiliaria)

Non è presente alcuna cache KV nella fase di prepopolamento e ogni token è rappresentato in uno stato nascosto. Pertanto, l'eliminazione progressiva dei token può essere ottenuta rimuovendo lo stato nascosto dei token eliminati. Tuttavia, estendere l’eliminazione progressiva dei token alle successive fasi di decodifica non è semplice. Il motivo è che ogni fase di decodifica utilizza il buffer KV calcolato nella fase di preriempimento per calcolare l'attenzione. Poiché LazyLLM esegue l'eliminazione progressiva dei token nella fase di prepopolamento, il KV di un token eliminato in un determinato livello non verrà visualizzato nella cache KV del livello successivo.

Come promemoria, il framework LazyLLM consente a ogni passaggio di generazione di scegliere un diverso sottoinsieme di token dalla sequenza completa dei token di input in ogni passaggio, indipendentemente dal fatto che siano stati eliminati nei passaggi precedenti. Ad esempio, nella successiva fase di decodifica, i token eliminati che non esistono nella cache KV potrebbero essere riselezionati per il calcolo dell'attenzione. In questo caso, il modello non può recuperare la cache KV per questi token.

Una soluzione intuitiva a questo problema è passare i token attraverso l'origine del Transformer. Tuttavia, ciò comporta un doppio conteggio dello stesso token e, in ultima analisi, un rallentamento della velocità di generazione complessiva.

Per risolvere questo problema, il team ha introdotto un'altra cache oltre alla cache KV originale: Aux Cache (cache ausiliaria).

Se i KV a cui sono stati eliminati i token (come T4 e T7 nella Figura 4) non vengono visualizzati nella cache KV dei livelli successivi, i loro stati nascosti verranno salvati dalla Aux Cache per il recupero nelle iterazioni successive.

Come mostrato nella Figura 4, in ogni fase di decodifica, ogni livello Transformer recupera prima la cache KV dei token precedenti (se esiste). Per quei token che non sono nella cache KV, i loro stati nascosti vengono recuperati direttamente dalla Aux Cache del livello precedente senza dover passare nuovamente attraverso il livello precedente. Aux Cache garantisce che ciascun token venga calcolato al massimo una volta in ciascun livello Transformer e garantisce inoltre che LazyLLM sia più veloce del LLM standard nel suo livello più lento.

sperimentare

Il team ha testato questo nuovo approccio "pigro" su due grandi modelli linguistici: Llama 2 7B e XGen 7B. Il LLM standard per il confronto è lo stesso modello di checkpoint pre-addestrato rilasciato pubblicamente senza alcuna formazione aggiuntiva.

Il benchmark sperimentale è LongBench, un benchmark multi-task per la comprensione di contenuti lunghi. Il benchmark LongBench contiene 16 set di dati e prevede 6 attività, tra cui domande e risposte su un singolo documento, domande e risposte su più documenti, riepilogo, apprendimento a poche riprese, attività di sintesi e completamento del codice.

La metrica di valutazione è l'efficacia e l'efficienza di ciascun metodo in termini di accelerazione del TTFT rispetto al compromesso di accuratezza.

risultato

La tabella 1 fornisce i risultati di accelerazione e precisione del TTFT per LazyLLM, LLM standard e altri metodi di base.



In questa tabella, la linea di base si riferisce all'inferenza LLM standard. Il rilascio casuale dei token si riferisce all'esecuzione della potatura casuale sui token. L'eliminazione statica del token si riferisce all'esecuzione di un'eliminazione una tantum sul token di input in base al metodo di attenzione dei precedenti livelli Transformer durante la fase di preriempimento. La compressione dei prompt è il metodo di compressione dei prompt che utilizza LLM per rimuovere la ridondanza nel contesto di input.

Come si può vedere dalla Tabella 1, LazyLLM è completamente superiore nell'accelerazione TTFT, mentre la diminuzione della precisione è sostanzialmente trascurabile. Va sottolineato che l'utilizzo di LLM per comprimere i prompt richiede molti calcoli. Pertanto, anche se la compressione richiesta rende l'inferenza più rapida, il suo TTFT effettivo è più lungo dell'LLM standard.

Impatto sulla velocità di costruzione complessiva

Per valutare l'impatto del nuovo metodo sulla velocità di generazione complessiva, il team ha analizzato la percentuale di token rapidi utilizzati nei calcoli e l'accelerazione di generazione, vedere Tabella 2.



Si può vedere che la percentuale di token utilizzati nei calcoli di LazyLLM è sempre inferiore al 100%, il che dimostra che LazyLLM non ha esaurito tutti i token nel prompt alla fine della generazione, ma teoricamente il modello può utilizzare tutti i token. Ciò può fornire un'ulteriore accelerazione al processo di generazione complessivo per diverse attività.

Tassi di caduta a diversi livelli

Il team ha inoltre analizzato l'impatto della posizione dello strato di potatura e del numero di token potati. I risultati sono mostrati nella Figura 6.



Si può vedere che quando la potatura viene eseguita allo stesso livello Transformer, meno token rimangono, peggiore sarà la prestazione del modello. Ciò è anche coerente con la nostra comprensione intuitiva. Inoltre, rispetto all'esecuzione della potatura nel livello Transformer precedente, la potatura nei livelli successivi si tradurrà in prestazioni migliori, il che dimostra che i livelli successivi sono meno sensibili alla potatura dei token.

Sulla base di queste osservazioni si può affermare che l’efficacia del token pruning progressivo è dimostrata.

Crescita progressiva del KV

Infine, il team ha anche cercato di comprendere gli aspetti interni del modello utilizzando la logica di potatura dei token. Nello specifico, vogliono conoscere la percentuale di utilizzo cumulativo dei token prompt e la corrispondente proporzione inutilizzata. Questo "utilizzo cumulativo dei token" può essere definito in modo equivalente come la dimensione della cache KV in ogni passaggio. La Figura 7 mostra l'utilizzo cumulativo di questi token prompt in ogni fase di LazyLLM.



Questo risultato supporta l'ipotesi che molti token non verranno mai selezionati dal modello (anche se il modello potrebbe teoricamente utilizzare tutti i token nel prompt.

Considerando che il modello può comunque mantenere l'accuratezza dell'esecuzione delle attività, si può concludere che il modello può effettivamente scartare i token che non influiscono sulla qualità dell'output.