Domande frequenti
La maggior parte delle pagine di questo sito fa un'affermazione. Questa risponde a dieci domande che un acquirente di solito deve inviarci via email per ottenere. Dove la risposta è "non ancora", dice "non ancora" — una pagina che esagerasse varrebbe meno di nessuna pagina, perché ogni altra pagina qui è scritta per essere verificabile.
Dove vengono elaborati i prompt e i completamenti?
Sull'endpoint selezionato dal router, che è una regione denominata, e la risposta ti dice quale: il blocco llmeu su ogni completamento riporta inference_region, endpoint_id e sovereignty_class. Un valore di residenza nella tua policy vincola quell'insieme prima della selezione; viene applicato come filtro, non come preferenza, e catalogue_unknown non è mai instradabile. Due limiti a questa frase. Primo, le righe delle regioni sono dati di configurazione, non prova di macchine in esecuzione o contratti con operatori confermati — il documento sulla residenza lo dice con le sue parole, e noi lo ripetiamo qui invece che solo lì. Secondo, su questo deployment non c'è GPU: il backend predefinito è il mock, la cui regione è dev-mock, e il mock non rappresenta un luogo. Vedi "Cosa succede se non c'è una GPU?" sotto. L'API che fa questo è un processo Node, non parte di questo sito statico — llmeu.com stesso risponde alle pagine, non elabora richieste.
apps/api/src/inference.mjs:457 (il blocco di risposta llmeu), packages/router/src/engine.mjs:467 (la residenza viene applicata prima dello scoring), packages/inference/src/mock.mjs:7 (MOCK_REGION = dev-mock), packages/shared/src/catalog-schema.mjs:64 (le classi instradabili)
I prompt e i completamenti vengono conservati?
No. I corpi dei prompt e dei completamenti non vengono scritti nel database. Ogni chiamata memorizza metadati — modello richiesto e usato, versione, endpoint, regione, classe di sovranità, motivo del router, conteggi token, latenza, costo, stato — e il campo prompt_stored della riga è 0. Le due colonne dei corpi esistono nello schema e sono null. L'applicazione è codice, non prosa di policy: una richiesta la cui retention effettiva è diversa da zero viene rifiutata, con 403 retention_exceeds_policy se chiede più di quanto consenta la tua policy e 501 retention_not_implemented se è consentita ma non implementata. Le policy possono memorizzare 24h, 7d o 30d come scelte; memorizzare la scelta non abilita la memorizzazione del corpo. Se una traccia mostra mai prompt_stored diverso da 0, quella è la risposta in una pagina a "cosa avete conservato" — e puoi verificarlo tu stesso con jq, come mostra la pagina delle evidenze.
packages/shared/src/db/schema.sql:295 (prompt_stored e le due colonne dei corpi), apps/api/src/inference.mjs:83 (IMPLEMENTED_RETENTION = zero), apps/api/src/inference.mjs:89 (403 retention_exceeds_policy), apps/api/src/inference.mjs:97 (501 retention_not_implemented), docs/product/decisions.md:62 (ADR-003)
Usate i dati dei clienti per l'addestramento?
No — nulla in questo prodotto è in grado di farlo. Non esiste un percorso di codice per addestramento o fine-tuning nell'API, nel processo web, nel router o nei pacchetti condivisi. L'API orchestra una richiesta verso un backend e la misura; non c'è ingestione di dataset, né archivio di corpus, né job di fine-tuning. I corpi dei prompt e dei completamenti non vengono scritti nel database, quindi non c'è nemmeno un corpus memorizzato su cui addestrare. Questa è un'affermazione sul nostro codice, non sui dati di addestramento upstream di ogni modello. I modelli che sono stati addestrati sui dati di altre persone, o che divulgano i loro dati di addestramento, sono descritti nelle loro schede, con le fonti, e alcune di quelle schede dicono che i dati di addestramento non sono pubblicati.
apps/api/src/inference.mjs (l'intero percorso della richiesta: orchestra, misura, non persiste mai), packages/shared/src/db/schema.sql (nessuna tabella dataset o corpus), packages/content/models.mjs:196 (una scheda che dice che i dati di addestramento non sono pubblicati)
Cosa succede quando nessun endpoint soddisfa la mia policy di residenza?
La richiesta fallisce. Non viene declassata a una regione vicina, e non viene inviata altrove: 409 no_endpoint_for_policy, con il motivo nel corpo dell'errore e gli endpoint esclusi indicati nella traccia. La residenza viene applicata prima dello scoring, e il failover si muove solo all'interno dell'insieme già filtrato dal router — ecco perché un nuovo tentativo non può sfuggire silenziosamente alla regola che hai impostato. Il codice lo dice in una frase: "Nessun endpoint soddisfa la residenza {x}. La residenza non viene mai rilassata silenziosamente." Cosa fare: indica una regione o una classe che la tua policy consente, amplia la policy deliberatamente (una decisione, con una voce nel changelog), oppure accetta che non esista una rotta per quel modello con quella regola. Un 409 è il prodotto che funziona come progettato; la modalità di errore che previene è una richiesta che "riesce" in un luogo che non hai consentito.
packages/shared/src/errors.mjs:59 (no_endpoint_for_policy), packages/router/src/engine.mjs:370 (il fallimento, prima dello scoring), packages/router/src/engine.mjs:507 (il failover non può uscire dall'insieme filtrato), apps/api/src/inference.mjs:137 (la retention viene controllata prima del routing)
Questo è conforme al GDPR o certificato?
Non facciamo questa affermazione, e non la faremo — non "conforme all'AI Act", non "certificato", non "Ufficiale UE". LLM EU è una società privata. Non è un'istituzione UE e non è un organismo di valutazione della conformità. "Verificato" su questo sito significa documentato, non legalmente certificato: è una checklist di informativa, valutata in base al fatto che una scheda dichiari residenza, fornitore, versione, retention, subprocessori e licenza, con link. Quello che possiamo affermare è ciò che fa il codice, e dove sono le lacune: zero retention applicata nel codice; chiavi API memorizzate come hash scrypt con il segreto mostrato una volta; ogni query dei clienti limitata per organization id; limiti di frequenza per IP, per chiave e per organizzazione; corpi delle richieste limitati e validati. Quello che non è fatto: nessun penetration test indipendente; nessun audit di terze parti; l'informativa privacy e i termini sono riepiloghi; il DPA è un modello non rivisto e non firmato; l'inventario dei subprocessori è incompleto. La pagina di sicurezza e l'indice legale elencano queste lacune nelle rispettive sezioni; questa risposta rimanda a esse invece di parafrasarle in qualcosa di più morbido.
docs/product/decisions.md:115 (ADR-006 — nessun bollino di conformità, in nessuna stringa), apps/web/server/pages/docs.mjs:537 (SECURITY_COPY: l'elenco dei controlli e delle lacune), apps/web/server/pages/docs.mjs:643 (LEGAL_READINESS: prontezza per documento)
L'API è compatibile con OpenAI e cosa deve cambiare un cliente?
L'URL di base, e nient'altro. /v1/chat/completions accetta la forma di richiesta ufficiale e restituisce la forma di risposta ufficiale — choices, usage, streaming come SSE — quindi gli SDK ufficiali funzionano dopo che li indirizzi verso di noi. I campi extra del body vengono ignorati invece che rifiutati, così un SDK più recente non può rompere una rotta più vecchia. Ciò che viene aggiunto è opzionale e additivo: un oggetto llmeu con namespace nella richiesta (residency, task, retention, data_class, policy_id, max_usd_per_1m, allow_partners) e un blocco llmeu nella risposta che riporta trace_id, model_used, model_version, provider, endpoint_id, inference_region, sovereignty_class, route_reason, policy_id, retention e stime di costo. Non offerto, deliberatamente: /v1/completions (501), n > 1 (400), embeddings a meno che un modello di embedding sia effettivamente ospitato. Il blocco llmeu può acquisire campi; rimuoverne uno sarebbe un cambiamento incompatibile e comparirebbe nel changelog.
docs/product/decisions.md:78 (ADR-004), apps/api/src/app.mjs:554 (la risposta che legge il client), apps/api/src/app.mjs:255 (501 su /v1/completions), apps/web/server/pages/docs.mjs:403 (il contratto di compatibilità scritto)
Cosa succede se non c'è una GPU?
Il MockBackend risponde, e lo dice nel proprio output: il completamento nomina il modello e la regione, dichiara che nessun peso reale è stato eseguito e spiega come attivare l'inferenza first-party (VLLM_BASE_URL, poi il flag gpu_enabled). La sua regione è dev-mock, che non è un luogo, e su una chiamata mock non c'è addebito. GET /readyz riporta quali backend sono attivi, e la readiness non è soddisfatta da una riga endpoint che dice up — un runtime gestito deve effettivamente riportare healthy, perché lo scopo di quella sonda è proprio intercettare un nodo i cui pesi sono ancora in caricamento. Il registro dei backend rifiuta di sostituire il mock a un endpoint il cui runtime è vllm; lancia invece un'eccezione. Il riepilogo onesto è scomodo e vale la pena dirlo chiaramente: questo deployment non ha GPU, quindi una chiamata qui è una dimostrazione della pipeline, non un'esecuzione di modello. Un successo del mock è un successo sulla rete; non viene mai presentato come un'esecuzione reale di modello.
packages/inference/src/mock.mjs:49 (la risposta che nomina il mock), apps/api/src/app.mjs:157 (la readiness include i backend gestiti), docs/product/decisions.md:131 (ADR-007 — il registro rifiuta di simulare un runtime GPU)
Cosa significa una scheda modello contrassegnata come catalogue_only?
Significa che cataloghiamo il modello e non lo serviamo. La scheda è informazione di riferimento — fornitore, licenza, finestra di contesto, dove il fornitore dice che viene eseguito, fonti per ogni dato — e nessun endpoint LLM EU risponde per esso. Chiedilo all'API e ottieni 404 hosted_unavailable, con la nota "solo catalogo — non ancora ospitato su LLM EU"; una pagina per esso non cita alcun prezzo, perché un prezzo per qualcosa che nessuno può chiamare è un'affermazione senza nulla dietro. Le richieste a quel modello vanno direttamente al suo fornitore, secondo i termini del fornitore stesso, e la scheda del modello dice esattamente questo. Anche il badge opposto non è una promessa più forte: un modello che ospitiamo è ospitato in una regione denominata con una classe di sovranità denominata, e questa è l'affermazione che puoi verificare nella traccia. Nessuno dei due badge è una dichiarazione di conformità.
packages/router/src/engine.mjs:325 (il router rifiuta il kind), apps/api/src/app.mjs:235 (404 hosted_unavailable con la nota), apps/web/server/pages/docs.mjs:446 (il pricing salta catalogue_only)
Come funzionano oggi prezzi e credito?
I prezzi sono per milione di token in entrata e in uscita, memorizzati per endpoint e mostrati sulla pagina dei prezzi e sulle schede dei modelli, in EUR, derivati da un unico tasso USD pubblicato; il registro stesso memorizza micros USD e scrive il tasso su ogni riga, così una fattura passata può essere ricostruita esattamente. Ogni completamento restituisce cost_estimate_usd e cost_estimate_eur, e una traccia registra il costo in entrambe. I limiti delle policy — un tetto per milione e un tetto giornaliero — vengono controllati prima del routing, quindi una richiesta fuori budget viene rifiutata invece che eseguita. I pagamenti con carta non sono abilitati su questo deployment, e nulla aggiunge credito automaticamente: non c'è ancora né un ciclo di fatturazione né un percorso di credito operatore. La console mostra quanto è stato speso e quanto resta. Se viene attivato un flag stripe_enabled, il gestore del credito accetta un importo inviato senza verificare che sia avvenuto un pagamento — ed è per questo che il flag deve restare disattivato finché la verifica dei pagamenti non è implementata e testata, e perché lo diciamo qui invece di offrire un pulsante di checkout.
docs/product/decisions.md:148 (ADR-008 — micros memorizzati, EUR visualizzati), apps/api/src/inference.mjs:457 (stime di costo per richiesta), apps/web/server/pages/docs.mjs:463 (la pagina dei prezzi dichiara che i pagamenti sono disattivati), apps/web/server/pages/docs.mjs:559 (il gestore del credito non verifica il pagamento)
Possiamo fare self-hosting?
Non tramite nulla che distribuiamo oggi. Non esiste una distribuzione self-hosted: nessuna immagine container, nessun installer, nessuna licenza on-premise, nessun contratto di supporto per eseguirlo nella tua infrastruttura, e questo repository non è offerto come deployment supportato. La superficie team della console esiste, ma i ruoli dell'organizzazione non sono un controllo degli accessi basato sui ruoli completo, e questo è documentato invece di essere lasciato implicito. Ciò che il catalogo porta è una classe di residenza chiamata on_prem_customer — "il modello viene eseguito all'interno dell'infrastruttura controllata dal cliente" — ed è una classificazione della proprietà e della gestione di un endpoint, non un'offerta da parte nostra. Molti dei modelli nel catalogo pubblicano pesi aperti, e le loro licenze (alcune non commerciali, alcune solo per ricerca) sono sulle schede con un link, così puoi valutare di eseguirli da solo; quella è una decisione su pesi di altri e licenze di altri, non un prodotto di self-hosting di LLM EU. Per una conversazione on-premise, la pagina enterprise è la porta giusta, ed è onesto che l'accordo non esista ancora.
packages/router/src/engine.mjs:12 (on_prem_customer compare solo nelle mappature di residenza), packages/shared/src/catalog-schema.mjs:84 (la sua definizione), apps/web/server/pages/docs.mjs:517 (RBAC incompleto, dichiarato), packages/content/models.mjs:695 (una licenza open-weight su una scheda)
Se una risposta qui è sbagliata, è un difetto e lo trattiamo come tale. Dove il codice e questa pagina non concordano, vince il codice — e la pagina delle evidenze, la pagina di sicurezza e l'indice legale sono i luoghi in cui teniamo il resto dei dettagli scomodi invece di ripeterli dieci volte.
Domande a cui questa pagina non risponde: mail@llmeu.com