AesCode 8B: come stimare il costo di un’attività di generazione di codice estetico

Perché il costo per token non basta

Il costo di generazione di una pagina con AesCode 8B non si riduce necessariamente ai token in ingresso e in uscita. Il modello produce artefatti visivi strutturati in HTML e CSS; il flusso descritto dal progetto comprende anche il rendering del risultato in un browser e il controllo di proprietà del codice e della pagina. Se un risultato non soddisfa i criteri definiti, un team può decidere di correggerlo o di generare una nuova versione.

Conviene quindi distinguere il costo dell’inferenza, quello della verifica e quello delle iterazioni. In una distribuzione locale, queste componenti possono coinvolgere risorse diverse: l’inferenza può usare una GPU, mentre il rendering e alcuni controlli possono richiedere CPU, memoria e browser. Il costo economico dipende da come vengono assegnate tali risorse e dalla politica adottata per i nuovi tentativi.

La documentazione di AesCode descrive il metodo e i suoi verificatori, ma non pubblica tariffe, latenze per verifica o un tasso universale di successo al primo tentativo. Le cifre di questa guida sono variabili per un calcolo personalizzato, non misurazioni di AesCode 8B. Neppure la valutazione aggregata del progetto equivale alla probabilità che una specifica attività superi tutti i criteri di un prodotto.

Le componenti del costo

Una stima utile separa le fasi del flusso invece di assegnare un costo unico a ogni generazione. L’inferenza comprende l’elaborazione del prompt e la produzione di HTML e CSS. La sua durata dipende, tra gli altri fattori, dall’hardware, dalla configurazione del modello, dalla lunghezza dell’input e dal numero di token generati.

La verifica descritta dal progetto renderizza l’HTML in un browser Playwright ed esegue controlli deterministici. Tra le proprietà esaminate figurano l’esecuzione, il testo, i limiti degli elementi, i dati di tabelle e grafici, il layout semantico e lo spazio bianco. Il repository documenta il funzionamento di questi controlli, ma non il consumo di risorse né la latenza per attività.

L’iterazione entra in gioco quando il flusso richiede un’altra generazione o una correzione dopo aver rilevato un problema. I team non ripetono necessariamente il processo nello stesso modo: alcuni fissano un numero massimo di tentativi, altri correggono solo il codice, altri ancora prevedono una revisione umana. Il costo medio dipende da questa politica, dalle risorse impiegate in ogni fase e dai risultati osservati su attività rappresentative.

Modello di calcolo e ipotesi

Per stimare il costo dell’inferenza per tentativo, si può dividere il numero di token generati per la velocità effettiva di generazione. Il risultato è una stima del tempo necessario. Se il costo della GPU è espresso per ora, il tempo può essere convertito in questa unità e moltiplicato per la tariffa o il costo interno corrispondente. Questa approssimazione non rappresenta da sola l’utilizzo complessivo del sistema, soprattutto in presenza di richieste concorrenti o risorse condivise.

La verifica va valorizzata in base alle risorse che usa davvero. Se Playwright e i verificatori consumano CPU, applicare automaticamente una tariffa oraria della GPU non riflette necessariamente il costo effettivo. Per una stima più accurata, conviene misurare e valutare separatamente ciascun tipo di risorsa. L’esempio di codice mantiene una tariffa comune solo per illustrare la struttura del calcolo.

Il fattore 1/p può stimare il numero medio di tentativi soltanto a determinate condizioni: tentativi indipendenti, probabilità di successo costante e ripetizione fino al successo senza un limite ai retry. In questo caso si calcola prima il costo complessivo di inferenza e verifica per tentativo, poi si applica una sola volta il fattore atteso. Il tasso di successo al primo tentativo, da solo, non dimostra che queste ipotesi siano valide. Se i tentativi successivi cambiano strategia, costo o probabilità, oppure se esiste un limite al loro numero, il modello va adattato.

def calcola_tco(token_output, token_al_secondo, costo_gpu_ora, tempo_verifica_sec, tasso_successo):
    if token_al_secondo <= 0 or costo_gpu_ora < 0 or tempo_verifica_sec < 0:
        raise ValueError("Tempi e costi devono essere validi")
    if not 0 < tasso_successo <= 1:
        raise ValueError("tasso_successo deve essere tra 0 e 1")

    tempo_inferenza = token_output / token_al_secondo
    costo_inferenza = (tempo_inferenza / 3600) * costo_gpu_ora
    costo_verifica = (tempo_verifica_sec / 3600) * costo_gpu_ora
    fattore_iterazione = 1 / tasso_successo

    return (costo_inferenza + costo_verifica) * fattore_iterazione

Esempio ipotetico: 100 presentazioni

Supponiamo, solo per illustrare il calcolo, un output medio di 5.000 token generato a 50 token al secondo, una verifica di 10 secondi per tentativo e un costo di 2 USD all’ora. L’esempio applica la stessa tariffa a inferenza e verifica per semplificare i conti: non afferma che la verifica consumi GPU né che questi valori corrispondano a un’installazione reale di AesCode 8B.

Con queste ipotesi, l’inferenza dura 100 secondi e la verifica altri 10 secondi per tentativo. Il costo complessivo è 110/3600 × 2 = 0,061111 USD per tentativo. Supponendo inoltre un tasso di successo dell’80%, tentativi indipendenti, probabilità costante e ripetizione illimitata fino all’accettazione, il fattore medio è 1/0,8 = 1,25. Il costo stimato per attività accettata è quindi 0,061111 × 1,25 = circa 0,076389 USD. Per 100 attività, la stima è 7,64 USD.

L’esempio non è una tariffa né un risultato misurato. Modificare la velocità, la durata della verifica, il costo delle risorse, il tasso di successo o la politica dei retry cambia il risultato. Sotto queste ipotesi, la relazione tra costo atteso e probabilità di successo è inversa, non esponenziale.

Come ottenere una stima personalizzata

Una stima operativa dovrebbe basarsi sullo stesso hardware, sulla stessa configurazione e sul flusso previsto per la distribuzione. Prima di misurare, definisci che cosa significa accettare un’attività: per esempio, quali requisiti di contenuto devono essere soddisfatti e quali difetti visivi comportano il rifiuto. Senza criteri stabili, il tasso di successo non permette di confrontare le configurazioni in modo coerente.

Registra separatamente inferenza, rendering e ciascuna verifica. Per ogni attività, annota i token in ingresso e in uscita, la durata e le risorse utilizzate a ogni tentativo, gli errori rilevati e il numero di retry. Se il flusso limita i tentativi, consente correzioni parziali o richiede una revisione umana, includi queste regole nel calcolo invece di presumere che lo stesso processo venga ripetuto fino al successo.

Il set di test dovrebbe rappresentare i prompt, le immagini di riferimento e i tipi di pagina previsti nell’applicazione. Una prova ridotta può fornire una prima approssimazione, ma il suo tasso di successo non garantisce risultati analoghi per altre attività. Complessità, carico concorrente, configurazione del browser e hardware possono modificare sia i tempi sia i costi.

Portata dei risultati e limiti della stima

La valutazione pubblicata del progetto riporta risultati aggregati su 300 campioni di infografiche, con tre generazioni per prompt e senza selezione tra le generazioni. Queste metriche descrivono le prestazioni del benchmark e le relative dimensioni di valutazione; non costituiscono un tasso generale di successo al primo tentativo per qualsiasi applicazione, prompt o criterio di accettazione. Inoltre, una pagina che supera i controlli deterministici non è per questo automaticamente pronta per la consegna senza una revisione visiva.

Il repository descrive il rendering con Playwright, sei verificatori deterministici e canali di valutazione visiva. Non pubblica il costo o la durata di ogni verifica, il consumo di CPU o GPU per attività né un tasso universale di successo iniziale. La configurazione usata in una valutazione non permette, da sola, di dedurre la memoria necessaria o le prestazioni su hardware diverso.

Il risultato del calcolo va quindi letto come una stima condizionata dalle misurazioni e dalle ipotesi adottate. Separare i costi di GPU e CPU, rendere esplicita la politica dei retry e usare criteri di accettazione riproducibili aiuta a confrontare le distribuzioni; non garantisce che costo o qualità restino invariati al cambiare di hardware, carico o prompt.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.