Tocca “Run” su un assistente di punta di GPT e poi guarda il filatore. I secondi si estendono in pochi minuti, i metri di token si arrampicano e il contatore sulla fattura aperta si insinua più in alto. Latenza e costi sono diventati l’imposta invisibile sul boom del modello di linguaggio di grandi dimensioni, specialmente quando una singola query dura può innescare migliaia di token di inferenza fresca. Una nuova proposta di ricerca chiamata calcolo del sonno sostiene che quei token sono spesso spesi nella fase sbagliata del flusso di lavoro. Invece di stipare tutti i ragionamenti nel momento in cui l’utente colpisce, perché non lasciare che il modello “pensa” durante le sue ore di inattività, trasformi il contesto grezzo in intuizioni riutilizzabili e tagli il conto quando arriva finalmente la vera domanda?
L’idea sembra familiare a chiunque abbia mai programmato un indice di database o un codice compilato prima della spedizione: preprocesso mentre nessuno sta guardando, rispondi all’istante quando lo sono. Tuttavia, l’applicazione di quella mentalità ai modelli di lingua richiede nuovi parametri di riferimento, una contabilità attenta e la prova che lo sforzo offline si trasferisce alla precisione online. Kevin Lin e colleghi di Letta e UC Berkeley forniscono esattamente tali prove in “Sleep -time CalcoE i loro numeri suggeriscono un ripensamento di come i cicli della GPU del budget per prodotti AI aziendale.
Il ridimensionamento tradizionale del tempo dice a un LLM di lavorare di più quando la domanda è difficile: campionare più catene di pensiero, estendere la traccia di ragionamento, le risposte di ravviva o forcella dozzine di risposte candidate in parallelo. Questi trucchi aumentano l’accuratezza per i compiti di matematica, codifica e conoscenza, ma gonfiano anche la latenza e lo scarico del portafoglio. Gli utenti aspettano; I venditori pagano. Peggio ancora, il paradigma presuppone che ogni query sia un One -off apolide che arriva con il suo intero contesto nella stessa richiesta.
Nel mondo reale, i contesti persistono. I robot di supporto clienti rileggono la stessa base di conoscenza, gli agenti di codifica navigano nello stesso repository e i copiloti di ricerca rivisitano un corpus di documenti condiviso. Gli autori sostengono che in questi contesti statali, enormi pezzi di ragionamento siano eseguiti in modo ridondante. Sleep -time Calcola Exploit che ridondanza lasciando che il modello preveda il contesto durante le finestre inattive, crei una rappresentazione distillata e pronta per l’inferenza e la memorizza per un riutilizzo successivo. Quando l’utente finalmente lo chiede, l’LLM risponde in una frazione dei token perché gran parte del sollevamento pesante è già cotto nel prompt.
Perché il calcolo del sonno riscrive la curva dei costi
I ricercatori formalizzano il flusso di lavoro in due fasi. Durante Sonno Il modello vede solo il contesto Cprevede probabili angoli di interesse e produce un contesto riscritto C’ che contiene detrazioni intermedie, riassunti strutturati o frammenti a catena memorizzati nella cache. Durante Test -time la query dell’utente Q arriva. Il modello ora riceve C’ Invece del contesto grezzo e può raggiungere la risposta corretta con un budget di calcolo molto più piccolo B. Poiché le ore di inattività sono economiche e parallelizzabili, l’organizzazione paga tassi di bassa priorità per la preelaborazione e preserva la capacità di inferenza premium per la reattività del campo dell’utente.
Per quantificare il beneficio, il team ha diviso due classiche suite di matematica – GSM -SyMbolic e AIME – in Statale Varianti in cui ogni problema viene scomposto in un paragrafo di contesto e una domanda separata. Hanno anche costruito GSM -symbolic multi -queryin cui ogni contesto genera diverse domande correlate, imitando un utente che continua a colpire lo stesso documento. La matrice di valutazione ha confrontato il basale GPT -4O, GPT -4O -Mini, O1, O3 -Mini, Claude Sonnet e DeepSeek – R1 in tre condizioni: ridimensionamento del tempo standard, calcolo del sonno con budget offline e pass-@k campionamento parallelo.
Cosa mostrano gli esperimenti
Attraverso ogni modello tranne il più piccolo O1, la strategia del sonno spinto verso l’esterno la frontiera di accuratezza. SU Sympolic Stateful GSM E Aime statale Il rapporto degli autori:
- 5 × inferiore Token di test per colpire la stessa precisione delle corse sequenziali di base della catena sequenziale.
- 13 percento Acquisizione di precisione su GSM quando il budget offline ha ridimensionato fino a cinque generazioni parallele del sonno.
- 18 percento Accuratezza guadagno su AIME con tracce di ragionamento offline di maggiore efficace.
- 2,5 × riduzione Nel costo medio per query quando dieci domande correlate hanno condiviso lo stesso contesto preelaborato.
Forse più sorprendente, calcolo del sonno Batti il pass canonico@k Trucco a pari budget di test. Passaggio-@k presuppone che un verificatore Oracle possa scegliere istantaneamente il meglio k Risposte campionate, una stampella non realistica in produzione. Il calcolo del sonno raggiunge una maggiore precisione senza quel lusso perché il ragionamento pesante vive già C’.
Il payoff è sensibile a quanto sia prevedibile l’eventuale domanda. Quando i ricercatori hanno confuso gli elementi GSM dalla probabilità di registro che Llama -2 ha assegnato alla domanda data il contesto, il delta di accuratezza tra il sonno e la linea di base si è ampliato per il quintile più prevedibile. In un inglese semplice: più ovvia è la domanda di follow -up, più grande è la vittoria dalla preparazione in anticipo dei compiti.
I numeri sono una cosa; Le implicazioni del prodotto sono un’altra. Gli autori eseguono un vero test di repository chiamato SWE -FATURE in cui un agente deve modificare tre o più file per implementare una funzione. Con solo budget di test bassi, l’uso del token di calcolo di calcolo del sonno di circa il 50 percento mentre corrisponde a F1, il che significa un fusione più veloce e le fatture più basse di GPU sui robot di integrazione continua. A budget molto elevati, il ragionamento classico del tempo di test ha riacquistato un leggero vantaggio in precisione, suggerendo una politica ibrida: allocare il calcolo offline in modo aggressivo quando la latenza conta o quando i contesti verranno riutilizzati, rientrano a ricche catene online solo per query con un solo off o altamente imprevedibili.
Il framework apre anche porte per la generazione di dati sintetici. Se il ragionamento del tempo produce ricche rappresentazioni di lingua naturale di una base o documento di codice, quegli stessi artefatti diventano dati di addestramento per futuri lungimiranze, un ciclo virtuoso in cui il pensiero offline semina la prossima generazione di miglioramenti del modello senza raschiare più testo su Internet.
Operativamente, la tecnica invita domande ingegneristiche. Quanto spesso dovrebbe aggiornare la cache di contesto? Quanto può essere grande C’ Cresci prima che annulla il risparmio token? Quali cicli inattivi sono davvero gratuiti in un cluster condiviso? Eppure nessuno di questi ostacoli sembra formidabile come l’attuale realtà del pagamento dei prezzi in tempo reale per il ragionamento ridondante. Le aziende che già programmano build notturne, gattoni dell’indice di ricerca o viste materializzate hanno modelli mentali per questa ottimizzazione.
Come LLMS stanno diventando tranquillamente gli ultimi storici della città
Dove il pensiero offline si adatta successivo
Il calcolo del sonno non è un proiettile d’argento. Le domande che al cieco al sistema o ai contesti che mutano troppo rapidamente richiederanno comunque nuove catene di pensiero. L’articolo stesso flags apre la ricerca su politiche adattive che prevedono quando gli investimenti offline ripagheranno, forse stimando l’entropia del contesto o la distribuzione dell’intenzione dell’utente. Anche così, il core da asporto si trova: i modelli di linguaggio di grandi dimensioni non devono pensare solo quando l’utente sta guardando. Prendendo in prestito un trucco di elaborazione a vecchia età – stasera il lavoro di domani – gli sviluppatori possono tagliare latenza, ridurre le bollette e scalare ancora la scala di accuratezza.
Il risultato: La tua prossima funzione LLM potrebbe non richiedere un modello più grande o un budget di ragionamento più profondo. Potrebbe semplicemente richiedere prima di far dormire il modello sul problema.