Come smettere di scrivere adapter per le reti neurali e riprendere il controllo dei costi dei token

Recentemente, stavo riscrivendo l'integrazione di Claude verso un client aggiornato e mi sono trovato a riflettere. Un giorno i clienti chiedono di connettere GPT-4o, il giorno dopo vogliono Anthropic, e una settimana dopo il dipartimento finanziario chiede da dove venga una bolletta di diverse centinaia di dollari per i test. Ogni volta devo aggiungere logica di gestione degli errori, gestire le chiavi e calcolare manualmente le spese dei token.

Questa routine viene risolta da LLM Gateway del team The Open Co. Il progetto funge da API gateway unificato che accetta chiamate nel formato standard OpenAI e le instrada verso i provider appropriati.

Una Richiesta per Qualsiasi Modello

Il concetto fondamentale è semplice. Invece di integrare SDK multipli, invii una singola richiesta HTTP a un gateway locale o cloud. Il controller identifica automaticamente il provider di destinazione, trasforma il formato e restituisce la risposta.

Attualmente sono supportati i principali provider:

• OpenAI
• Anthropic
• Google Vertex AI
• Altri servizi con API compatibili

Ecco come appare una richiesta standard al gateway:

curl -X POST https://api.llmgateway.io/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $LLM_GATEWAY_API_KEY" \
  -d '{
  "model": "gpt-4o",
  "messages": [
    {"role": "user", "content": "Hello, how are you?"}
  ]
}'

Se hai bisogno di passare a Claude 3.5 Sonnet, la struttura JSON nella tua applicazione rimane la stessa. Solo il nome del modello nel corpo della richiesta cambia.

Tracciamento dei Costi e Metriche di Latenza

Quando più servizi o sviluppatori lavorano con le reti neurali, controllare i limiti diventa difficile. A volte qualcuno esegue uno script con un prompt errato in un ciclo infinito e brucia il budget di un mese in un'ora.

Il gateway si occupa del tracciamento. Ogni transazione viene salvata nel database e il sistema calcola automaticamente:

• Numero di token in input e output
• Costo totale di ogni chiamata
• Tempo di risposta del modello
• Statistiche generali per chiavi e progetti

Attraverso il pannello web, puoi visualizzare grafici pronti all'uso e vedere immediatamente quale modello specifico sta consumando la maggior parte del budget.

Struttura del Progetto ed Esecuzione in Docker

Gli autori hanno creato un monorepo in TypeScript. Sotto il cofano vengono utilizzate tecnologie collaudate:

• Hono gestisce il proxy delle richieste API
• Next.js gestisce l'interfaccia web e il playground
• Drizzle ORM lavora con i database PostgreSQL e Redis
• TypeScript garantisce la tipizzazione end-to-end dei componenti

Puoi distribuire il tuo servizio in un paio di minuti tramite Docker. Gli autori hanno assemblato un'immagine pronta che combina i componenti principali.

docker volume create llmgateway_postgres
docker volume create llmgateway_redis

docker run -d \
  --name llmgateway \
  --restart unless-stopped \
  -p 3002:3002 \
  -p 3003:3003 \
  -p 3005:3005 \
  -p 3006:3006 \
  -p 4001:4001 \
  -p 4002:4002 \
  -v llmgateway_postgres:/var/lib/postgresql/data \
  -v llmgateway_redis:/var/lib/redis \
  -e AUTH_SECRET="$(openssl rand -base64 32 | tr -d '\n')" \
  -e GATEWAY_API_KEY_HASH_SECRET="$(openssl rand -base64 32 | tr -d '\n')" \
  ghcr.io/theopenco/llmgateway-unified:latest

Un piccolo dettaglio dalla documentazione: non montare una cartella dalla macchina host direttamente in /var/lib/postgresql/data. A causa delle specifiche dell'inizializzazione dei permessi di PostgreSQL nel container, il processo potrebbe bloccarsi. I named volume nel comando sopra eliminano questo problema.

Se vuoi provare il sistema prima della distribuzione, gli sviluppatori hanno una versione cloud su llmgateway.io.

Limitazioni della Versione Gratuita

Il repository utilizza una doppia licenza. Il codice principale è distribuito sotto AGPLv3, tuttavia alcune cartelle nel codice sorgente appartengono alla versione Enterprise.

Nella versione free open-source, la cronologia delle chiamate viene conservata per 30 giorni. Se hai bisogno di conservazione illimitata dei log, fatturazione avanzata per utente o separazione dei team all'interno della tua organizzazione, dovrai acquistare una licenza commerciale.

Chi Beneficerà di Questo Strumento

Se la tua applicazione effettua tre richieste al giorno verso un singolo modello, non ha senso configurare un proxy separato. Aggiungeresti solo un ulteriore punto di fallimento e una latenza di rete trascurabile.

Il gateway si dimostrerà utile nelle seguenti situazioni:

• Il progetto utilizza modelli da provider diversi
• È necessario un tracciamento trasparente dei costi dei token tra servizi diversi
• È necessaria la distribuzione del proxy nel proprio ambiente
• È pianificato un rapido switch di fallback a un modello di backup in caso di guasti

Puoi provare il progetto su GitHub. Il README lì è piuttosto minimale, ma il progetto è comprensibile anche senza istruzioni dettagliate.