Quattro condizioni, un compito: quanto costano davvero la decodifica speculativa e la scelta dello strumento agente

Quattro copie indipendenti e isolate dello stesso repository Cloudflare Worker hanno ricevuto lo stesso compito, sullo stesso commit: aggiungere un registro D1 durevole affinché un aggiornamento webhook di Telegram non venga mai pianificato due volte, anche in presenza di duplicati concorrenti o di un errore di database transitorio e ambiguo, più un lavoro di 14 giorni che elimina solo le righe terminali. Quattro condizioni lo hanno eseguito: un Qwen3.8-27B locale con decodifica speculativa disattivata, lo stesso modello con decodifica speculativa attivata (draft-mtp, n=3), e un GPT-5.6 "Luna" ospitato con livello di ragionamento "max" tramite due strumenti agente diversi, la modalità standard di DSH e l'app Codex Desktop di OpenAI stessa. Un reviewer indipendente ha poi valutato ogni invio secondo la stessa rubrica da 100 punti leggendo il diff, eseguendo personalmente `type-check` e la suite di test, e verificando uno per uno tutti gli 11 scenari di test richiesti.

Tutti e quattro hanno ottenuto 99 o 100 punti su 100. La qualità del codice non era quindi ciò che distingueva le quattro condizioni in questo compito — lo era la durata netta del compito. Per ogni condizione, il tempo di attesa per l'approvazione e la compattazione automatica del contesto sono stati esclusi dal tempo misurato, perché entrambi sono sovraccarico, non lavoro del modello; tutte le durate qui sotto sono già valori netti.

Ciò che era pura attesa — e ciò che non lo era

La modalità standard di DSH solleva una richiesta di escalation della sandbox (ad esempio per permettere al config loader di Vitest di avviare un processo figlio) e attende che un essere umano clicchi su "consenti"; l'intervallo tra questa richiesta e il clic è puro tempo di reazione, non lavoro dell'agente, ed è stato escluso dalla misurazione. Inoltre, una volta che la finestra di contesto si riempie, DSH esegue di propria iniziativa una chiamata di riepilogo automatico, senza alcun intervento umano, ma che consuma comunque minuti reali — anche questo tempo è escluso.

Un singolo clic di approvazione da solo ha rappresentato 11:53 esclusi dall'esecuzione DSH+Luna. Il tempo netto del compito per la modalità standard di DSH + Luna è di 11:45 — davanti ai 13:48 di Codex Desktop, che non ha sollevato alcuna richiesta di approvazione comparabile. Lo stesso calcolo vale per le due esecuzioni locali di Qwen: MTP disattivato ha avuto 5:54 esclusi su due compattazioni automatiche, MTP n=3 solo 1:42 esclusi su una.

Che cosa ha davvero ottenuto la decodifica speculativa

Il tempo netto del compito per lo stesso modello locale è sceso da 54:48 con decodifica speculativa disattivata a 19:57 con decodifica attivata — 2,7 volte più veloce, con il throughput di output che è passato da 33,8 a 55,5 token al secondo. Il numero di chiamate agli strumenti si è mosso nella direzione opposta: MTP disattivato ha richiesto 93 chiamate per raggiungere lo stesso risultato, MTP n=3 solo 61. Nessuno di questi numeri è stimato; entrambi provengono direttamente dagli eventi di chiamata agli strumenti della sessione DSH.

Andare più veloci significa codice peggiore?

No. Ogni invio ha superato `type-check` e la sua suite di test completa, ha coperto tutti gli 11 scenari di test richiesti con asserzioni comportamentali anziché un semplice confronto di stringhe SQL, e ha implementato correttamente la parte più difficile della specifica: una richiesta SQL atomica (`INSERT ... ON CONFLICT`) con lo stesso token di richiesta riutilizzato tra i tentativi, in modo che una rilettura dopo una risposta persa e un nuovo tentativo venga riconosciuta come la richiesta riuscita del chiamante stesso invece che come un duplicato. Nessuno ha toccato un file vietato, aggiunto una dipendenza o mostrato alcun segno di delega. Le due detrazioni di un punto erano entrambe semplici questioni di collocazione — la pulizia di retention innescata a ogni webhook accettato invece che tramite il trigger cron esistente, e una funzione di finalizzazione cresciuta leggermente oltre l'indicazione "mantieni la route piccola" del compito — non bug di comportamento.

Un rischio di progettazione da verificare su tutte e quattro

Un reviewer, lavorando sull'invio Luna/Codex Desktop, ha notato qualcosa che la rubrica non valuta. Quell'invio genera un token di richiesta nuovo a ogni invocazione del Worker invece di derivarlo in modo deterministico dall'ID dell'aggiornamento. Se ogni tentativo all'interno del ciclo di retry di una singola consegna segnala al chiamante un errore transitorio, mentre uno di quei tentativi in realtà ha eseguito il commit in silenzio, la riga resta nello stato "processing" sotto un token che nessuna richiesta futura conosce. Una nuova consegna di Telegram è una nuova richiesta HTTP con un token appena generato; legge il token ormai diverso della riga esistente, lo tratta come la richiesta di qualcun altro, e l'aggiornamento può restare bloccato permanentemente. Poiché la retention elimina solo le righe terminali, non viene mai ripulito nemmeno in quel modo. Questo non è stato riverificato in modo indipendente sul codice esatto di generazione del token delle altre tre implementazioni, quindi va considerato come una domanda da approfondire su tutte e quattro, non come un difetto confermato in una sola.

Limiti

Si tratta di una singola ripetizione per condizione, un test pilota. Il manifesto stesso del benchmark raccomanda almeno tre ripetizioni per condizione con un ordine nuovamente randomizzato prima di considerare definitiva una classifica. La contabilità dei token locale e cloud non è un'unità comune: DSH somma input nuovo, output e letture cache come tre contatori additivi separati, mentre Codex Desktop dichiara un contatore di input cumulativo in cui l'input in cache è già un sottoinsieme; non calcolate quindi un rapporto attraverso questo confine. I token di output al secondo sono una misura del tempo fino al risultato utile, non un benchmark isolato di velocità di decodifica: include il tempo di esecuzione degli strumenti per ogni esecuzione, oltre alla coda di rete e API per le due esecuzioni cloud. Le due esecuzioni cloud dichiarano, nelle proprie intestazioni di sessione, finestre di contesto diverse per lo stesso modello, il che non è stato risolto in modo indipendente e potrebbe riflettere percorsi di routing del provider diversi piuttosto che una reale differenza di modello. Il rischio di riga bloccata descritto sopra è stato identificato in un invio e non è stato verificato in modo indipendente sul codice esatto di generazione del token degli altri tre.

Il risultato pulito di questo test è il confronto sulla decodifica speculativa: stesso modello, stesso hardware, un solo parametro cambiato, una differenza di 2,7 volte senza alcun costo di qualità in questa esecuzione. Il risultato più confuso è il confronto tra gli strumenti agente: la modalità standard di DSH e Codex Desktop hanno prodotto una quantità nettamente diversa di sovraccarico estraneo al compito sullo stesso modello che svolgeva lo stesso lavoro, e questo sovraccarico era invisibile finché i log di sessione non sono stati letti evento per evento. Prima di considerare uno dei due numeri come una proprietà dello strumento anziché di questa singola esecuzione, servono tre ripetizioni per condizione con ordine randomizzato, e idealmente una logica di approvazione che non metta il tempo di reazione di un essere umano in mezzo a una normale escalation della sandbox.

Prove e fonti dei marchi

Le misurazioni sono state ricostruite da quattro export di sessione conservati: tre file `session.jsonl` di DSH e l'export di token-usage e rollout della CLI di Codex Desktop.

• Qwen3 (QwenLM) – organizzazione GitHub ufficiale
• llama.cpp (ggml-org) – repository ufficiale
• DeepSeek – logo ufficiale nel repository DeepSeek-VL
• OpenAI – organizzazione GitHub ufficiale