Implementazione a livello aziendale del gateway di inferenza LLM: Abbiamo ridotto gli errori di tipo 429 dal 13% allo 0, risparmiando anche il 28% dei costi.

Durante la promozione del Black Friday dello scorso mese, il nostro team tecnico di e-commerce transfrontaliero di Singapore ha trascorso 36 ore consecutive in sala di controllo, lavorando senza sosta. Abbiamo seguito attentamente la curva della percentuale di successo delle richieste e per un soffio non siamo esultati… L’anno scorso, nello stesso periodo di promozione, abbiamo avuto problemi a causa del limite di traffico imposto da un singolo fornitore di servizi LLM (Large Language Model).Il 13% delle richieste per la generazione delle descrizioni dei prodotti restituisce un errore 429.Il sistema di gestione del negozio è andato in tilt per quasi 4 ore, e abbiamo ricevuto più di 2000 lamentele dai clienti.

Prima di tutto: cosa esattamente è un gateway di inferenza per il deployment a livello aziendale?

Non si tratta di un nuovo framework sofisticato; in sostanza, funziona come uno strato di gestione del traffico che si trova tra i tuoi servizi aziendali e le varie interfacce degli LLM (Large Language Models). I parametri chiave sono molto semplici da comprendere e da utilizzare:Con un carico normale, il ritardo di pianificazione non deve superare i 10 ms.Se si supera questo limite, significa semplicemente che si sta rallentando il progresso del business.

Tre benefici concreti che abbiamo ottenuto dopo aver superato gli ostacoli.

• Prima di tutto, abbiamo eliminato direttamente il rischio di limitazione del traffico: ora riceviamo richieste da 3 importanti fornitori di LLM (Large Language Models) contemporaneamente, e il gateway assegna automaticamente le richieste al nodo che ha la quota disponibile più alta e risponde più velocemente. Il picco di QPS durante il Black Friday di quest’anno è stato 2,3 volte superiore a quello dello scorso anno, e non si è verificato nemmeno un singolo caso di errore tipo 429 (error code 429) durante tutto il processo.
• In secondo luogo, i costi sono diminuiti in modo evidente: abbiamo instradato automaticamente le richieste per la generazione di etichette di prodotti a bassa priorità verso modelli più efficienti in termini di rapporto qualità-prezzo, senza dover modificare il codice sorgente del business. In soli 7 giorni, si è risparmiato il 28% sui costi legati all’utilizzo dei token.
• Infine, si è risparmiato il lavoro di duplicazione sul lato del server: in precedenza, ogni volta che si cambiava il modello o si aggiungeva un nuovo fornitore di servizi, era necessario modificare individualmente le interfacce di 3 moduli aziendali; ora tutto viene configurato a livello di gateway, e il lavoro può essere completato in mezza giornata.

Non guardare solo i vantaggi: abbiamo inciampato davvero in questi 3 problemi.

Nella prima settimana di attività abbiamo già avuto un incidente: dopo aver attivato la funzione di fallback automatico, il gateway ha reindirizzato un insieme di richieste di testi personalizzati ad alta priorità che avrebbero dovuto essere elaborate dal GPT-4 a modelli meno performanti, con risultati molto inferiori. Di conseguenza, più di 200 contenuti pubblicitari degli inserzionisti sono risultati non conformi, e abbiamo dovuto compensare con buoni promozionali per un valore di poco meno di diecimila euro. Solo in seguito abbiamo capito che non tutte le richieste sono adatte a essere degradate automaticamente; in scenari particolarmente sensibili è necessario aggiungere regole di verifica di backup.

Ci sono ancora molti problemi legati ai costi di cui non si è parlato: se il tuo QPS (Number of Queries Per Second) rimane per lungo tempo al di sotto di 10, i costi di server e manutenzione del gateway stesso potrebbero essere più elevati rispetto ai pacchetti di quota più avanzati offerti dai fornitori di LLM (Large Language Models). In questo caso, non ha senso insistere nell’utilizzare il gateway.

Inoltre, non credete a quelle promesse di “funzionalità complete pronte all’uso immediato”. Abbiamo provato 3 gateway open source, ma le regole di distribuzione del traffico predefinite non si adattavano affatto alle esigenze del settore dell’e-commerce. Solo regolando le regole di ponderazione abbiamo impiegato ben 2 giorni.

Chi dovrebbe partecipare? Chi, in realtà, non ha affatto bisogno di sprecare tempo…

Dai direttamente i criteri di giudizio, senza indugiare:

• È possibile prendere in considerazione una delle seguenti condizioni: un numero di richieste al LLM superiore a 10.000 al giorno, l’utilizzo di più di due modelli contemporaneamente, o requisiti di disponibilità del servizio superiori al 99,9%.
• Se il tuo team è una piccola startup con meno di 5 persone, il tuo business principale non è strettamente legato all’utilizzo di grandi modelli (LLM), e le spese mensili per l’LLM non superano lo stipendio di un ingegnere del backend, non provare a implementare una soluzione per il deployment a livello aziendale. È più conveniente utilizzare direttamente le interfacce native dei fornitori di servizi.

Due suggerimenti pratici per chi si avvicina per la prima volta

Non effettuare il cambio completo all’improvviso: inizia con il 10% del traffico a bassa priorità per una settimana di test in modalità “grayscale”, concentrandoti su due indicatori principali: verifica se si verificano richieste ripetute e se i ritardi causati dal processo di scheduling sono effettivamente entro i limiti accettabili. Noi abbiamo iniziato testando il traffico relativo alle risposte automatiche post-vendita per 3 giorni, e solo dopo aver confermato che non c’erano problemi abbiamo proceduto con il cambio sulle attività principali dell’azienda.

Domanda: Dovrei costruire il gateway da zero? Risposta: A meno che nel vostro team non ci siano persone particolarmente disponibili, è meglio utilizzare una versione open source già pronta e modificarla. Ciò vi risparmierà almeno due mesi di lavoro e garantirà una maggiore stabilità del sistema.