Nel mondo dell’inference sui Large Language Models, l’ottimizzazione è sempre stata una corsa contro il tempo. I modelli escono con cadenza sempre più ravvicinata, le architetture si diversificano e i pattern di traffico cambiano; un compilatore statico, tarato su un singolo modello o famiglia di chip, rischia di restare indietro nel giro di poche settimane. Together AI prova a ribaltare questa logica con Together Compiler (TKCC), un sistema di compilazione continua basato su agenti che, secondo i dati pubblicati dall’azienda, supera i kernel ottimizzati a mano su Llama 1B fino a 1,7 volte e i migliori engine open source sui modelli di frontiera più recenti fino a 2,6 volte in termini di TPS sul benchmark InferenceX.
La difficoltà di fondo non sta nel trovare un’ottimizzazione migliore, ma nel misurarla in modo affidabile. Gli agenti che lavorano sui singoli kernel usano benchmark offline; il problema è che nei modelli mixture-of-experts il comportamento dipende dai dati e quei tempi non riproducono il forward pass reale. Al contrario, gli agenti che puntano direttamente agli engine end-to-end scontano tempi di avvio molto lenti, che rallentano ogni iterazione. TKCC rompe questo trade-off con una Tiered Persistent Engine che separa l’overhead di avvio dell’engine dal calcolo del forward pass e con un modello di costo per scegliere le configurazioni di parallelismo iniziali.
Il salto concettuale è più importante del singolo benchmark. TKCC trasforma l’ottimizzazione dell’inference da attività una tantum, legata al rilascio di un kernel scritto a mano, a un processo continuo che si adatta al carico reale. Questo sposta il vantaggio competitivo dagli specialisti che scrivono kernel a chi controlla la pipeline di misurazione e la gestione dello stato dell’agente. Chi gestisce infrastrutture self-hosted dovrebbe leggere qui un segnale chiaro: gli stessi vincoli di VRAM e di potenza di calcolo possono produrre throughput molto diversi a seconda della qualità del compilatore. Un miglioramento del 2,6x sulla stessa base hardware non è un dettaglio da nicchia: si traduce potenzialmente in meno GPU per servire lo stesso traffico, quindi in un TCO inferiore, a parità di controllo sui dati e sulla latenza.
Anche il dato sul batch size 1 è rilevante. I 1111 TPS su MiniMax M3.1 Flash e i 1205 TPS su DeepSeek v4.1 Flash indicano che l’ottimizzazione non riguarda solo l’aggregazione di richieste in batch grandi, ma anche scenari a bassa latenza, dove ogni millisecondo conta. Per chi distribuisce modelli di frontiera in scenari a bassa latenza, questo tipo di risultato cambia il calcolo della capacità necessaria.
La generalizzazione oltre i modelli linguistici di frontiera, con trilioni di token serviti in produzione, suggerisce che la compilazione continua può diventare un componente di sistema, non un esperimento. Per chi valuta deployment on-premise, esistono trade-off tra il controllo dell’hardware e la disponibilità di loop di ottimizzazione simili; AI-RADAR offre framework analitici su /llm-onpremise per approfondire i criteri di scelta. Ma la lezione di TKCC è più ampia: l’ottimizzazione dell’inference sta diventando un problema di misurazione e automazione, non di forza bruta sui kernel.