Sintesi Tecnica: Ottimizzazione basata sul carico di lavoro per la traduzione di sottotitoli in tempo reale su dispositivi

Problematica

Questo lavoro affronta i vincoli specifici della traduzione di sottotitoli in tempo reale da inglese a cinese tradizionale (variante di Taiwan) su dispositivi locali. A differenza del serving di modelli linguistici general-purpose o della traduzione automatica a lungo contesto, questo carico di lavoro è caratterizzato da:

• Input e output brevi: Le richieste consistono in un singolo cue di sottotitolo corrente con un contesto precedente limitato (fino a tre cue).
• Inferenza con batch-size-uno: La riproduzione interattiva impedisce l'uso di ottimizzazioni per batch elevati.
• Latenza e privacy rigorose: Le traduzioni devono essere generate entro la finestra di visualizzazione del sottotitolo su hardware consumer (ad es. Apple M-series) senza trasmettere dati al cloud.

In queste condizioni, le ottimizzazioni tradizionali per sequenze di attenzione lunghe o per l'alto throughput offrono benefici limitati. Al contrario, gli overhead fissi per richiesta, il calcolo durante la decodifica e i costi di proiezione del vocabolario diventano i colli di bottiglia primari. Il profiling preliminare indica che, dopo l'applicazione della quantizzazione GGUF (che riduce i costi dei blocchi Transformer), la fase di proiezione del vocabolario diventa un fattore dominante nella latenza di decodifica.

Metodologia

La soluzione proposta, LocalSubs, si basa sul modello di traduzione multilingue LMT-60-0.6B. La strategia di ottimizzazione è guidata dal carico di lavoro, concentrandosi sulla riduzione della dimensione della proiezione in uscita e sul miglioramento della densità dei token per il dominio specifico.

1. Riprogettazione del Vocabolario e del Tokenizer

L'originale vocabolario da 151k token è stato sostituito con un tokenizer ByteLevel BPE personalizzato da 64k token, addestrato specificamente su testi di sottotitoli in inglese e cinese tradizionale di Taiwan.

• Impatto: Questo riduce la dimensione della proiezione in uscita di circa il 57,9% (da 151.936 a 64.024).
• Efficienza: Il nuovo tokenizer aumenta la densità dei caratteri cinesi (1,40 caratteri per token rispetto a 1,05), riducendo il numero di token necessari per generare lo stesso testo.

2. Migrazione degli Embedding e Adattamento a Due Stadi

La sostituzione del tokenizer invalida la matrice di embedding originale. Gli autori propongono una pipeline di adattamento specifica:

1. Migrazione degli Embedding: I nuovi embedding dei token vengono inizializzati tramite corrispondenza a livello di stringa. I token esistenti vengono copiati direttamente; i nuovi token sono inizializzati mediando gli embedding delle loro decomposizioni in sub-token del tokenizer originale.
2. Calibrazione degli Embedding: Segue un adattamento a due stadi. In primo luogo, i livelli Transformer vengono congelati mentre gli embedding, l'head di output e i parametri RMSNorm vengono aggiornati per allineare il nuovo spazio di embedding con lo spazio semantico pre-addestrato.
3. Fine-Tuning Supervisionato Completo (SFT): L'intero modello viene quindi sottoposto a fine-tuning su un dataset di sottotitoli filtrato per qualità e bilanciato per lunghezza (233.088 esempi).

3. Protocollo di Valutazione

• Qualità: Valutata su un sottoinsieme fisso di 500 esempi del set di test OpenSubtitles2024 tramite giudizi di preferenza a coppie contro un anchor fisso di Google Translate, giudicati da GPT-4o.
• Performance: Misurazioni preliminari della latenza sono state condotte su un Apple M2 utilizzando llama.cpp con quantizzazione GGUF Q5_K_M e il backend Metal.

Risultati Chiave

Qualità della Traduzione

• Win Rate: LocalSubs ha ottenuto un win rate del 59,2% (escludendo i pareggi) contro Google Translate.
• Confronto: Questo è paragonabile al win rate del 64,6% ottenuto da GPT-4o mini sotto lo stesso protocollo di valutazione, nonostante LocalSubs operi sotto rigidi vincoli di dispositivo locale, batch-size-uno e senza dipendenza da API remote.
• Utilizzo del Contesto: Il modello beneficia significativamente del contesto su cue brevi. Su un sottoinsieme di 260 risposte brevi, il win rate con contesto (73,1%) è stato notevolmente superiore rispetto a quello senza contesto (68,6%).
• Dipendenza dalla Lunghezza del Cue: Le performance sono più forti su cue brevi (82,0% di win rate per 1–3 parole) e diminuiscono all'aumentare della lunghezza del cue, scendendo al 45,7% per 8–15 parole e al 12,5% per 16+ parole.

Latenza e Throughput

• Accelerazione: Un modello di profiling preliminare con vocabolario da 64k ha mostrato un incremento di velocità di 1,63× nella latenza media end-to-end (56,8 ms vs 92,7 ms) rispetto al baseline con vocabolario da 151k su Apple M2 Metal.
• Throughput: Il throughput di decodifica è aumentato da 63,3 a 96,0 token/s (1,52×).
• Riduzione dei Token: Il modello da 64k ha generato il 40,0% in meno di token in uscita (4,00 vs 6,67) e ha utilizzato il 7,7% in meno di token di prompt per l'input in inglese.

Significato e Rivendicazioni

Il paper sostiene che, per carichi di lavoro su dispositivi locali con input brevi e bassa latenza, la riprogettazione del tokenizer è una decisione critica dell'architettura di serving, non una semplice scelta di pre-processing. Riducendo la dimensione del vocabolario, il sistema abbassa direttamente il costo computazionale dello strato di proiezione in uscita, che diventa il collo di bottiglia dopo la quantizzazione.

Il lavoro dimostra che un modello compatto da 0,6B, quando adattato con un tokenizer specifico per il dominio e una strategia strutturata di migrazione degli embedding, può raggiungere una qualità di traduzione competitiva con i modelli commerciali in cloud (GPT-4o mini) soddisfacendo al contempo rigorosi vincoli di privacy e latenza.

Limitazioni e Lavori Futuri

Gli autori mantengono una posizione modesta riguardo alle loro affermazioni:

• Riproducibilità: I risultati sulla latenza sono preliminari; i log grezzi, i commit specifici di llama.cpp e i checksum del modello non sono stati completamente conservati per il modello valutato finale.
• Valutazione: I giudizi a coppie si affidano a GPT-4o senza uno snapshot registrato, e l'audit umano è ancora necessario. Il confronto tra LocalSubs e GPT-4o mini è stato indiretto (entrambi rispetto a Google Translate), non un confronto diretto testa a testa.
• Gap di Performance: Il modello fatica con i cue più lunghi, spesso omettendo dettagli o fallendo nel preservare il significato completo.
• Direzioni Future: Gli autori danno priorità a confronti controllati tra diverse dimensioni di vocabolario (32k/64k/151k) sotto impostazioni identiche, valutazione stratificata per scenario completo e la costruzione di una tassonomia degli errori verificata manualmente.