Î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 în mod normal să ne trimită 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ă fiecare altă pagină de aici este scrisă pentru a putea fi verificată.
Unde sunt prelucrate prompturile și completările?
Pe endpointul pe care îl selectează routerul, care este o regiune numită, iar răspunsul vă spune care: blocul llmeu de la fiecare completare conține inference_region, endpoint_id și sovereignty_class. O valoare de rezidență din politica dumneavoastră constrânge acel set înainte de selecție; este aplicată ca filtru, nu ca preferință, iar catalogue_unknown nu este niciodată rutabil. Două limite la acea propoziț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 de rezidență spune acest lucru în propriile cuvinte, iar noi îl repetăm aici, nu doar acolo. În al doilea rând, în această implementare nu există capacitate GPU first-party: cererile sunt servite de endpointurile pe care le înregistrează catalogul, iar un model fără endpoint activ este doar catalog, astfel încât o cerere pentru el este refuzată pe nume, nu răspunsă de un substitut. Vezi „Ce se întâmplă dacă nu există GPU?” mai jos. API-ul care face acest lucru este un proces Node, nu parte din acest site static — llmeu.com însuși servește pagini, nu procesează cereri.
apps/api/src/inference.mjs:457 (blocul de răspuns llmeu), packages/router/src/engine.mjs:467 (rezidența este aplicată înainte de scorare), packages/shared/src/catalog-schema.mjs:64 (clasele rutabile)
Sunt păstrate prompturile și completările?
Nu. Corpurile promptului și ale completării nu sunt scrise în baza de date. Fiecare apel stochează metadate — modelul solicitat și utilizat, versiunea, endpointul, regiunea, clasa de suveranitate, motivul routerului, numărul de tokenuri, latența, costul, starea — iar prompt_stored din rând este 0. Cele două coloane de corp există în schemă și sunt null. Aplicarea este cod, nu text de politică: o cerere a cărei retenție efectivă este orice altceva decât zero este refuzată, cu 403 retention_exceeds_policy dacă cere mai mult decât permite politica dumneavoastră ș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ă vreo urmă arată vreodată prompt_stored altfel decât 0, acesta este răspunsul de o pagină la „ce ați păstrat” — și îl puteț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 poziția de a face asta. Nu există nicio cale de cod pentru antrenare sau fine-tuning în API, în procesul web, în router sau în pachetele comune. API-ul orchestrează o cerere către un backend și o măsoară; nu există ingestie de seturi de date, nicio stocare de corpus și niciun job de fine-tune. Corpurile promptului și ale completării 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 upstream 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 de cerere: orchestrează, măsoară, nu persistă niciodată), packages/shared/src/db/schema.sql (nicio tabelă de set 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 îndeplinește politica mea de rezidență?
Cererea eșuează. Nu este retrogradată la o regiune apropiată și nu este trimisă nicăieri altundeva: 409 no_endpoint_for_policy, cu motivul în corpul erorii și endpointurile excluse numite pe trace. Rezidența se aplică înainte de scorificare, iar failoverul se mută mereu doar în interiorul setului deja filtrat de router — de aceea o reîncercare nu poate scăpa în tăcere de regula pe care ați stabilit-o. Codul o spune într-o propoziție: „Niciun endpoint nu îndeplinește rezidența {x}. Rezidența nu este relaxată niciodată în tăcere.” Ce să faceți în privința asta: numiți o regiune sau o clasă pe care politica dvs. o permite, lărgiți politica în mod deliberat (o decizie, cu o intrare în changelog), sau acceptați că nu există nicio rută pentru acel model sub acea regulă. Un 409 este produsul funcționând conform proiectării; modul de eșec pe care îl previne este o cerere care a „reușit” undeva unde nu ați permis.
packages/shared/src/errors.mjs:59 (no_endpoint_for_policy), packages/router/src/engine.mjs:370 (eșecul, înainte de scorificare), packages/router/src/engine.mjs:507 (failoverul nu poate părăsi setul filtrat), apps/api/src/inference.mjs:137 (retenția este verificată înainte de rutare)
Este conform GDPR sau certificat?
Nu — și nu vom spune asta: nu „conform cu AI Act”, nu „certificat”, nu „Oficial UE”. LLM EU este o companie privată, nu o instituție a UE și nu un organism de evaluare a conformității. „Verificat” aici înseamnă documentat, nu certificat legal: o listă de verificare a divulgării punctată după dacă un card declară rezidența, furnizorul, versiunea, retenția, subprocesatorii și licența, cu linkuri. Ce face platforma este afirmat în termeni pe care codul îi poate susține: retenție zero aplicată, chei API stocate ca hashuri scrypt și afișate o singură dată, fiecare interogare a clientului delimitată după id-ul organizației, limite de rată per-IP, per-cheie și per-organizație, corpuri de cerere limitate și validate. Munca de securitate și documentele legale au fiecare propria pagină.
docs/product/decisions.md:115 (ADR-006 — nicio ștampilă de conformitate, în niciun șir), apps/web/server/pages/docs.mjs:537 (SECURITY_COPY: lista de controale și lacune), apps/web/server/pages/docs.mjs:643 (LEGAL_READINESS: pregătirea per document)
API-ul este 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 îndreptați spre noi. Câmpurile suplimentare din corp sunt ignorate în loc să fie respinse, așa că un SDK mai nou nu poate rupe o rută mai veche. Ce se adaugă este opțional și aditiv: un obiect llmeu namespaced î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 sunt oferite, în mod deliberat: /v1/completions (501), n > 1 (400), embeddings dacă nu este chiar găzduit un model de embedding. Blocul llmeu poate primi câmpuri; eliminarea unuia ar fi o schimbare incompatibilă și ar apărea în changelog.
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?
Routerul servește orice endpointuri live pe care le înregistrează catalogul, iar fiecare răspuns numește endpointul, regiunea și clasa de suveranitate care a răspuns. Un model fără endpoint live este doar în catalog: o cerere pentru el este refuzată pe nume în loc să primească un răspuns de la un înlocuitor. Capacitatea first-party necesită un pool configurat (VLLM_BASE_URL, apoi flagul gpu_enabled); până când există unul, capacitatea este cea pe care o înregistrează rândurile de endpoint, iar paginile spun care este aceea. GET /readyz raportează care backenduri sunt active, iar starea de pregătire nu este satisfăcută de un rând de endpoint care spune că este activ — un runtime administrat trebuie să raporteze efectiv sănătos, pentru că exact acesta este scopul acelei sonde: să prindă un nod ale cărui ponderi încă se încarcă. Registrul de backenduri refuză să înlocuiască un runtime cu altul; î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 pipeline-ului, nu o rulare de model. Un succes de înlocuitor ar fi un succes pe fir și nimic mai mult, motiv pentru care nu este niciodată prezentat ca o rulare reală de model.
apps/api/src/app.mjs:157 (starea de pregătire include backenduri administrate), docs/product/decisions.md:131 (ADR-007 — registrul refuză să falsifice 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ță, fereastră de context, unde spune furnizorul că rulează, surse pentru fiecare cifră — și niciun endpoint LLM EU nu răspunde pentru el. Cereți-l API-ului și primiți 404 hosted_unavailable, cu nota „doar în catalog — încă nu este găzduit pe LLM EU”; o pagină pentru el nu citează 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 puteți verifica pe trace. 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 (prețurile omit catalogue_only)
Cum funcționează prețurile și creditul astăzi?
Prețurile sunt per milion de tokenuri intrare și ieșire, stocate per endpoint și afișate pe pagina de prețuri și pe cardurile de model, în EUR, derivate dintr-un singur curs USD publicat; registrul în sine stochează micros 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 un trace înregistrează costul în ambele. Limitele de politică — un plafon per milion și un plafon zilnic — sunt verificate înainte de rutare, astfel încât o cerere peste buget este refuzată în loc să fie rulată. Plățile cu cardul nu sunt activate pe această implementare și nimic nu adaugă credit automat: nu există încă nicio rulare de facturare și nicio cale de creditare pentru operator. Consola arată ce s-a cheltuit și ce rămâne. Dacă un flag stripe_enabled este pornit, handlerul de credit acceptă o sumă postată fără a verifica dacă a avut loc o plată — motiv pentru care flagul trebuie să rămână oprit până când verificarea plății este implementată și testată și pentru care spunem asta aici în loc să oferim un buton de checkout.
docs/product/decisions.md:148 (ADR-008 — micros stocați, EUR afișați), apps/api/src/inference.mjs:457 (estimări de cost per cerere), apps/web/server/pages/docs.mjs:463 (pagina de prețuri afirmă că plățile sunt oprite), apps/web/server/pages/docs.mjs:559 (handlerul de credit nu verifică plata)
Putem face self-hosting?
Nu prin nimic din ce livrăm astăzi. Nu există o distribuție self-hosted: nicio imagine de container, niciun instalator, nicio licență on-premise, niciun contract de suport pentru rularea acestuia în propria dumneavoastră infrastructură, iar acest repository nu este oferit ca implementare suportată. Suprafața de echipă a consolei există, dar rolurile organizației nu sunt control de acces complet bazat pe roluri, iar acest lucru este documentat în loc să fie subînțeles. Ce include 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 puteți evalua rularea lor singur; aceasta este o decizie despre ponderile altcuiva și licența altcuiva, nu un produs de self-hosting de la LLM EU. Pentru o discuție 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, afirmat), packages/content/models.mjs:695 (o licență open-weight 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 incomode, în loc să le repetăm de zece ori.
Întrebări la care această pagină nu răspunde: mail@llmeu.com