Întrebări frecvente
Majoritatea paginilor de pe acest site fac o afirmație. Aceasta răspunde la zece întrebări pentru care un cumpărător ar trebui de obicei să ne trimită un e-mail. Acolo unde răspunsul este „încă nu”, spune „încă nu” — o pagină care ar exagera ar valora mai puțin decât nicio pagină, pentru că orice altă pagină de aici este scrisă astfel încât să poată fi verificată.
Unde sunt prelucrate prompturile și completările?
Pe endpointul pe care îl selectează routerul, care este o regiune numită, iar răspunsul îți spune care: blocul llmeu de pe fiecare completare conține inference_region, endpoint_id și sovereignty_class. O valoare de rezidență din politica ta restringe acel set înainte de selecție; este aplicată ca filtru, nu ca preferință, iar catalogue_unknown nu este niciodată rutabil. Două limite la această afirmație. În primul rând, rândurile de regiune sunt date de configurare, nu dovezi ale unor mașini care rulează sau ale unor contracte confirmate cu operatori — documentul privind rezidența spune asta cu propriile cuvinte, iar noi o repetăm aici, nu doar acolo. În al doilea rând, în această implementare nu există GPU: backendul implicit este mock, a cărui regiune este dev-mock, iar mock-ul nu reprezintă un loc. Vezi „Ce se întâmplă dacă nu există GPU?” mai jos. API-ul care face asta este un proces Node, nu parte a acestui site static — llmeu.com însuși servește pagini, nu prelucrează cereri.
apps/api/src/inference.mjs:457 (blocul llmeu din răspuns), packages/router/src/engine.mjs:467 (rezidența este aplicată înainte de punctare), packages/inference/src/mock.mjs:7 (MOCK_REGION = dev-mock), packages/shared/src/catalog-schema.mjs:64 (clasele rutabile)
Sunt păstrate prompturile și completările?
Nu. Corpurile prompturilor și completărilor nu sunt scrise în baza de date. Fiecare apel stochează metadate — modelul cerut și utilizat, versiunea, endpointul, regiunea, clasa de suveranitate, motivul routerului, numărul de tokenuri, latența, costul, starea — iar prompt_stored al rândului este 0. Cele două coloane de corp există în schemă și sunt null. Aplicarea se face prin cod, nu prin text de politică: o cerere a cărei retenție efectivă este altceva decât zero este refuzată, cu 403 retention_exceeds_policy dacă cere mai mult decât permite politica ta și 501 retention_not_implemented dacă este permisă dar neimplementată. Politicile pot stoca 24h, 7d sau 30d ca opțiuni; stocarea opțiunii nu activează stocarea corpului. Dacă o urmărire arată vreodată prompt_stored diferit de 0, acesta este răspunsul de o pagină la „ce ați păstrat” — și îl poți verifica singur cu jq, așa cum arată pagina de dovezi.
packages/shared/src/db/schema.sql:295 (prompt_stored și cele două coloane de corp), 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)
Vă antrenați pe datele clienților?
Nu — nimic din acest produs nu este în măsură să o facă. Nu există nicio cale de cod pentru antrenare sau ajustare fină în API, în procesul web, în router sau în pachetele partajate. API-ul orchestrează o cerere către un backend și o măsoară; nu există ingestie de seturi de date, nici depozit de corpus, nici job de ajustare fină. Corpurile prompturilor și completărilor nu sunt scrise în baza de date, deci nu există nici măcar un corpus stocat pe care să se antreneze. Aceasta este o afirmație despre codul nostru, nu despre datele de antrenare din amonte ale fiecărui model. Modelele care au fost antrenate pe datele altor persoane sau care își divulgă datele de antrenare sunt descrise pe propriile carduri, cu surse, iar unele dintre acele carduri spun că datele de antrenare nu sunt publicate.
apps/api/src/inference.mjs (întreaga cale a cererii: orchestrează, măsoară, nu persistă niciodată), packages/shared/src/db/schema.sql (nicio tabelă de seturi de date sau corpus), packages/content/models.mjs:196 (un card care spune că datele de antrenare nu sunt publicate)
Ce se întâmplă când niciun endpoint nu satisface politica mea de rezidență?
Cererea eșuează. Nu este retrogradată la o regiune apropiată și nu este trimisă altundeva: 409 no_endpoint_for_policy, cu motivul în corpul erorii și endpointurile excluse numite în urmărire. Rezidența este aplicată înainte de punctare, iar failover-ul se mișcă întotdeauna doar în interiorul setului deja filtrat de router — de aceea o reîncercare nu poate scăpa în tăcere de regula pe care ai stabilit-o. Codul o spune într-o singură propoziție: „Niciun endpoint nu satisface rezidența {x}. Rezidența nu este relaxată niciodată în tăcere.” Ce să faci în privința asta: numește o regiune sau o clasă pe care politica ta o permite, lărgește politica în mod deliberat (o decizie, cu o intrare în jurnalul de modificări) sau acceptă că nu există nicio rută pentru acel model sub acea regulă. Un 409 înseamnă că produsul funcționează conform proiectării; modul de eșec pe care îl previne este o cerere care a „reușit” undeva unde nu ai permis.
packages/shared/src/errors.mjs:59 (no_endpoint_for_policy), packages/router/src/engine.mjs:370 (eșecul, înainte de punctare), packages/router/src/engine.mjs:507 (failover-ul nu poate părăsi setul filtrat), apps/api/src/inference.mjs:137 (retenția este verificată înainte de rutare)
Este acest lucru conform cu GDPR sau certificat?
Nu facem această afirmație și nu o vom face — nici „conform cu AI Act”, nici „certificat”, nici „oficial UE”. LLM EU este o companie privată. Nu este o instituție a UE și nu este un organism de evaluare a conformității. „Verificat” pe acest site înseamnă documentat, nu certificat juridic: este o listă de verificare a divulgărilor, punctată după dacă un card declară rezidența, furnizorul, versiunea, retenția, subcontractanții și licența, cu linkuri. Ce putem afirma este ce face codul și unde sunt lacunele: retenție zero impusă în cod; chei API stocate ca hash-uri scrypt, cu secretul afișat o singură dată; fiecare interogare a clientului delimitată după id-ul organizației; limite de rată pe IP, pe cheie și pe organizație; corpurile cererilor limitate și validate. Ce nu este făcut: niciun test de penetrare independent; niciun audit al unei terțe părți; nota de confidențialitate și termenii sunt rezumate; DPA este un model nesemnat și nerevizuit; inventarul subcontractanților este incomplet. Pagina de securitate și indexul juridic enumeră acele lacune în secțiunile lor; acest răspuns le indică în loc să le parafrazeze în ceva mai blând.
docs/product/decisions.md:115 (ADR-006 — nicio ștampilă de conformitate, în niciun text), apps/web/server/pages/docs.mjs:537 (SECURITY_COPY: lista de controale și lacune), apps/web/server/pages/docs.mjs:643 (LEGAL_READINESS: gradul de pregătire pe document)
Este API-ul compatibil cu OpenAI și ce schimbă un client?
URL-ul de bază și nimic altceva. /v1/chat/completions acceptă forma oficială a cererii și returnează forma oficială a răspunsului — choices, usage, streaming ca SSE — astfel încât SDK-urile oficiale funcționează după ce le îndrepți spre noi. Câmpurile suplimentare din corp sunt ignorate, nu respinse, deci un SDK mai nou nu poate rupe o rută mai veche. Ce se adaugă este opțional și aditiv: un obiect llmeu cu spațiu de nume în cerere (residency, task, retention, data_class, policy_id, max_usd_per_1m, allow_partners) și un bloc llmeu în răspuns care conține trace_id, model_used, model_version, provider, endpoint_id, inference_region, sovereignty_class, route_reason, policy_id, retention și estimări de cost. Nu se oferă, în mod deliberat: /v1/completions (501), n > 1 (400), embeddings decât dacă un model de embeddings este efectiv găzduit. Blocul llmeu poate primi câmpuri; eliminarea unuia ar fi o schimbare incompatibilă și ar apărea în jurnalul de modificări.
docs/product/decisions.md:78 (ADR-004), apps/api/src/app.mjs:554 (răspunsul pe care îl citește clientul), apps/api/src/app.mjs:255 (501 la /v1/completions), apps/web/server/pages/docs.mjs:403 (contractul de compatibilitate scris)
Ce se întâmplă dacă nu există GPU?
Răspunde MockBackend, iar acesta o spune în propria ieșire: completarea numește modelul și regiunea, declară că nu au rulat ponderi reale și spune cum se activează inferența proprie (VLLM_BASE_URL, apoi indicatorul gpu_enabled). Regiunea sa este dev-mock, care nu este un loc, iar la un apel mock nu există nicio taxă. GET /readyz raportează ce backenduri sunt active, iar starea de pregătire nu este satisfăcută de un rând de endpoint care spune up — un runtime administrat trebuie să raporteze efectiv healthy, pentru că tot scopul acelei verificări este să prindă un nod ale cărui ponderi se încarcă încă. Registrul de backenduri refuză să înlocuiască mock-ul pentru un endpoint al cărui runtime este vllm; în schimb aruncă o eroare. Rezumatul onest este inconfortabil și merită spus direct: această implementare nu are GPU, deci un apel aici este o demonstrație a conductei, nu o rulare de model. Un succes mock este un succes pe fir; nu este niciodată prezentat ca o rulare reală de model.
packages/inference/src/mock.mjs:49 (răspunsul care numește mock-ul), apps/api/src/app.mjs:157 (starea de pregătire include backendurile administrate), docs/product/decisions.md:131 (ADR-007 — registrul refuză să simuleze un runtime GPU)
Ce înseamnă un card de model marcat catalogue_only?
Înseamnă că înregistrăm modelul în catalog și nu îl servim. Cardul este informație de referință — furnizor, licență, fereastra de context, unde spune furnizorul că rulează, surse pentru fiecare cifră — și niciun endpoint LLM EU nu răspunde pentru el. Cere-l API-ului și primești 404 hosted_unavailable, cu nota „doar în catalog — încă nu este găzduit pe LLM EU”; o pagină pentru el nu afișează niciun preț, pentru că un preț pentru ceva ce nimeni nu poate apela este o afirmație fără nimic în spate. Cererile către acel model merg direct la furnizorul său, în condițiile proprii ale acelui furnizor, iar cardul modelului spune exact asta. Nici insigna opusă nu este o promisiune mai puternică: un model pe care îl găzduim este găzduit într-o regiune numită, cu o clasă de suveranitate numită, iar aceasta este afirmația pe care o poți verifica în urmărire. Nicio insignă nu este o declarație de conformitate.
packages/router/src/engine.mjs:325 (routerul respinge tipul), apps/api/src/app.mjs:235 (404 hosted_unavailable cu nota), apps/web/server/pages/docs.mjs:446 (pagina de prețuri omite catalogue_only)
Cum funcționează astăzi prețurile și creditul?
Prețurile sunt pe milion de tokenuri la intrare și la ieșire, stocate pe endpoint și afișate pe pagina de prețuri și pe cardurile de model, în EUR, derivate dintr-un singur curs USD publicat; registrul însuși stochează micro-USD și scrie cursul pe fiecare rând, astfel încât o factură trecută poate fi reconstruită exact. Fiecare completare returnează cost_estimate_usd și cost_estimate_eur, iar o urmărire înregistrează costul în ambele. Limitele de politică — un plafon pe milion și un plafon zilnic — sunt verificate înainte de rutare, deci o cerere peste buget este refuzată, nu executată. Plățile cu cardul nu sunt activate în această implementare și nimic nu adaugă credit automat: nu există încă o rulare de facturare și nicio cale de credit pentru operator. Consola arată ce s-a cheltuit și ce rămâne. Dacă un indicator stripe_enabled este activat, handlerul de credit acceptă o sumă trimisă fără a verifica dacă a avut loc o plată — de aceea indicatorul trebuie să rămână dezactivat până când verificarea plăților este implementată și testată și de aceea spunem asta aici în loc să oferim un buton de finalizare a comenzii.
docs/product/decisions.md:148 (ADR-008 — micro-USD stocați, EUR afișați), apps/api/src/inference.mjs:457 (estimări de cost pe cerere), apps/web/server/pages/docs.mjs:463 (pagina de prețuri declară că plățile sunt dezactivate), apps/web/server/pages/docs.mjs:559 (handlerul de credit nu verifică plata)
Putem găzdui noi înșine?
Nu prin nimic din ce livrăm astăzi. Nu există o distribuție auto-găzduită: nicio imagine de container, niciun instalator, nicio licență on-premise, niciun contract de suport pentru rularea acestuia în propria infrastructură, iar acest depozit nu este oferit ca implementare suportată. Suprafața de echipă a consolei există, dar rolurile de organizație nu constituie un control de acces complet bazat pe roluri, iar acest lucru este documentat, nu trecut sub tăcere. Ce conține catalogul este o clasă de rezidență numită on_prem_customer — „modelul rulează în infrastructura controlată de client” — și este o clasificare a proprietății și operării unui endpoint, nu o ofertă din partea noastră. Multe dintre modelele din catalog publică ponderi deschise, iar licențele lor (unele necomerciale, unele doar pentru cercetare) sunt pe carduri cu un link, astfel încât poți evalua rularea lor pe cont propriu; aceasta este o decizie despre ponderile altcuiva și licența altcuiva, nu un produs de auto-găzduire de la LLM EU. Pentru o discuție despre on-premise, pagina enterprise este ușa potrivită și este onest că aranjamentul nu există încă.
packages/router/src/engine.mjs:12 (on_prem_customer apare doar în mapările de rezidență), packages/shared/src/catalog-schema.mjs:84 (definiția sa), apps/web/server/pages/docs.mjs:517 (RBAC incomplet, declarat), packages/content/models.mjs:695 (o licență de ponderi deschise pe un card)
Dacă un răspuns de aici este greșit, este un defect și îl tratăm ca atare. Acolo unde codul și această pagină nu sunt de acord, codul câștigă — iar pagina de dovezi, pagina de securitate și indexul juridic sunt locurile unde păstrăm restul detaliilor inconfortabile, în loc să le repetăm de zece ori.
Întrebări la care această pagină nu răspunde: mail@llmeu.com
Dovezi și verificare · Securitate · Juridic · Accesibilitate