AYXZA Relay · Universal AI Gateway

Sezione commerciale · 01 / 03

Perché AYXZA Relay

Integrare l'AI in un prodotto non è più "chiamare un'API". Significa gestire cinque vendor diversi, contenere i costi, garantire continuità di servizio e proteggere i dati. AYXZA Relay risolve tutti questi problemi con una libreria sola.

Il problema Senza gateway

✗Codice duplicato per ogni provider (OpenAI, Anthropic, Gemini…)
✗Lock-in tecnico: cambiare modello = rifare l'integrazione
✗Costi fuori controllo, nessuna visibilità per tenant
✗Un provider down = servizio down
✗Dati sensibili inviati al cloud, nessuna opzione on-prem
✗RAG/knowledge base da costruire da zero ogni volta

La soluzione Con AYXZA Relay

+API unica: forge.chat() funziona con qualsiasi modello
+Switch provider via configurazione, zero refactoring
+Tracking costi per chiamata, tenant, modello — esportabile
+Failover automatico tra provider in millisecondi
+Ollama locale per dati sensibili, zero rete esterna
+Modulo Knowledge Base con pgvector incluso

Costi a confronto · instradamento intelligente

AYXZA Relay instrada ogni richiesta verso il modello più economico in grado di soddisfare il task. Costo per 1M token, valori indicativi pubblici 2026.

Input Output

Con routing automatico verso modelli "small" per task semplici e modelli "frontier" solo dove serve, il costo medio per richiesta scende tipicamente del 60–80%.

Casi d'uso tipici

01

SaaS multi-tenant

Tracking costi per cliente, limiti per piano, modelli diversi per tier. Tutto out-of-the-box.

02

Enterprise on-premise

Ollama locale per dati riservati, fallback cloud opzionale per task non-sensibili.

03

Knowledge base aziendale

RAG su documenti interni con pgvector, re-index automatica, isolation per tenant.

04

Agenti & chains

Multi-step orchestration, output strutturato nativo (Gemini, OpenAI) e allegati multimodali (PDF, immagini) sui prompt.

05

Migrazione provider

Cambia modello con una riga di config. A/B test tra provider senza toccare il codice.

06

Alta disponibilità

Failover trasparente: se OpenAI è giù, la richiesta passa ad Anthropic in <100ms.

Impatto economico

Stima conservativa su un prodotto SaaS con 10.000 chiamate AI/giorno.

Tempo sviluppo risparmiato

~3 mesi

Integrazione 5 provider, tracking, fallback, RAG

Riduzione costi API

60–80%

Con routing model-size adaptive + cache

Uptime AI features

99,95%

Con failover multi-provider configurato

Sezione tecnica · 02 / 03

Architettura

Libreria Python pura, stateless dove possibile, con persistenza su PostgreSQL + pgvector. Nessuna dipendenza da servizi esterni se non i provider LLM stessi.

Architettura a strati

Dal client applicativo ai provider, passando per il gateway core.

flowchart TB subgraph CLIENT["CLIENT APPLICATIONS"] A1["Web App"] A2["Backend API"] A3["CLI / Scripts"] end subgraph FORGE["AYXZA Relay · Gateway Library"] GW["Unified API
forge.chat · forge.embed · forge.rag"] subgraph CORE["Core Services"] R["Router
model selection"] C["Cache
semantic + exact"] T["Tracking
cost · tenant · model"] F["Fallback
provider failover"] K["Knowledge Base
RAG + pgvector"] end GW --> R R --> C C --> T T --> F GW -.-> K end subgraph PROV["LLM PROVIDERS"] P1["OpenAI"] P2["Anthropic"] P3["Google Gemini"] P4["Google Vertex"] P5["Ollama local"] end DB[("PostgreSQL
+ pgvector")] CLIENT --> GW F --> P1 F --> P2 F --> P3 F --> P4 F --> P5 T --> DB K --> DB

Flusso di una richiesta con fallback

Provider primario non disponibile, fallback automatico al secondario.

sequenceDiagram autonumber participant App as Client App participant Forge as AYXZA Relay participant Cache as Cache Layer participant P1 as OpenAI primary participant P2 as Anthropic fallback participant DB as PostgreSQL App->>Forge: forge.chat(prompt, model="auto") Forge->>Cache: lookup(prompt_hash) Cache-->>Forge: miss Forge->>P1: POST /v1/chat/completions P1-->>Forge: 503 Service Unavailable Note over Forge: Fallback trigger < 100ms Forge->>P2: POST /v1/messages P2-->>Forge: 200 OK + tokens Forge->>Cache: store(prompt_hash, response) Forge->>DB: log(tenant, model, cost, latency) Forge-->>App: response (transparent)

Pipeline RAG · Knowledge Base

Ingestion → chunking → embedding → retrieval → generation.

flowchart LR D["Documents
PDF · MD · HTML"] S["Source Registry
staleness tracking"] CH["Chunker
shared utility"] EM["Embedder
text-embedding-004
768-dim"] VS[("pgvector
HNSW index")] Q["User query"] QE["Query embedding"] RT["Retrieval
global + tenant chunks"] GEN["LLM Generation
any provider"] D --> S --> CH --> EM --> VS Q --> QE --> RT VS -.-> RT RT --> GEN

API in azione

Una manciata di righe per chat, fallback automatico, tracking e RAG.

# 1. Inizializzazione — provider configurati una volta sola
from forge_ai import Forge

forge = Forge(
    providers=["openai", "anthropic", "gemini", "ollama"],
    fallback_chain=["openai", "anthropic"],
    tracking=True,
    tenant_id="acme-corp",
)

# 2. Chat — il router sceglie il modello migliore per il task
response = forge.chat(
    prompt="Riassumi questo contratto in 3 punti",
    model="auto",           # o "claude-sonnet-4-5", "gpt-4o", "llama3.1:70b"
    max_tokens=500,
)
print(response.text, response.cost_usd, response.provider_used)

# 3. Output strutturato nativo (Gemini / OpenAI)
from pydantic import BaseModel
class Invoice(BaseModel):
    total: float
    vat: float
    items: list[str]

invoice = forge.chat(
    prompt="Estrai i dati da questa fattura...",
    output_schema=Invoice,
).parsed

# 4. RAG — knowledge base con isolamento per tenant
forge.kb.add_source(name="company-policies", files=["./docs/*.pdf"])
answer = forge.rag(
    query="Qual è la policy sui rimborsi spese?",
    sources=["company-policies"],
)

# 5. Locale — stesso codice, modello Ollama on-prem
private = forge.chat(prompt="...", model="ollama:llama3.1:70b")

Capability matrix

Capability	OpenAI	Anthropic	Gemini	Vertex	Ollama
Chat completion	●	●	●	●	●
Streaming	●	—	●	—	●
Structured output (native)	●	—	●	●	—
Function calling	●	●	●	●	●
Embeddings	●	—	●	●	●
Vision · multimodal	●	●	●	●	●
On-premise · air-gapped	—	—	—	—	●

Requisiti

Python 3.12+
PostgreSQL 14+ con estensione pgvector
Chiavi API dei provider scelti (opzionale per Ollama)
Ollama installato localmente per LLM on-prem

Stack tecnologico

SQLAlchemy 2.x async
Pydantic v2 per validazione e schemi
Alembic per migrazioni database
httpx con retry policy esponenziale
Test suite 900+ test, copertura E2E

Provider supportati · 03 / 03

Provider integrati

Tutti i principali vendor LLM cloud, più un adapter OpenAI-compatible che raggiunge motori cloud (Groq, DeepSeek, OpenRouter) e locali (Ollama, vLLM) air-gapped.

OA

OpenAI

GPT-4o · GPT-4o-mini · o3

Frontier reasoning, function calling completo, structured output nativo.

AN

Anthropic

Claude Opus · Sonnet · Haiku

Long-context (200K+), eccellente per reasoning lungo e analisi documentale.

GG

Google Gemini

Gemini 2.x · text-embedding-004

Multimodale nativo, embeddings 768-dim, ottimo rapporto costo/performance.

VX

Google Vertex AI

Enterprise GCP · EU residency

Stesso modello Gemini con SLA enterprise, billing GCP, data residency EU.

OL

Ollama

Llama · Mistral · Qwen · local

Esecuzione 100% locale, zero rete esterna, ideale per dati sensibili e GDPR. Lo stesso adapter OpenAI-compatible raggiunge anche motori cloud (Groq, DeepSeek, OpenRouter).

++

Provider custom

extensible api

Aggiungere un nuovo provider richiede ~150 righe Python implementando l'interfaccia Provider.

Contattaci

Per valutare un'integrazione, discutere un caso d'uso o ricevere una demo personalizzata sul tuo prodotto.

Contattaci →