Gyakran ismételt kérdések
Az oldal legtöbb lapja állít valamit. Ez tíz olyan kérdésre válaszol, amelyeket egy vevőnek általában e-mailben kellene tőlünk megkérdeznie. Ahol a válasz „még nem”, ott „még nem” szerepel — egy túlzó oldal kevesebbet érne, mint a semmilyen oldal, mert itt minden más oldal ellenőrizhetőnek íródott.
Hol dolgozzák fel a promptokat és a completionöket?
Azon a végponton, amelyet a router kiválaszt, amely egy megnevezett régió, és a válasz megmondja, melyik: a llmeu blokk minden completionön tartalmazza az inference_region, endpoint_id és sovereignty_class értékeket. A szabályzatodban szereplő residenciaérték már a kiválasztás előtt szűkíti ezt a halmazt; szűrőként alkalmazzuk, nem preferenciaként, és a catalogue_unknown soha nem irányítható. Két korlát tartozik ehhez a mondathoz. Először, a régiósorok konfigurációs adatok, nem futó gépek vagy megerősített üzemeltetői szerződések bizonyítékai — a residencia dokumentum a saját szavaival mondja ezt, és mi itt is megismételjük, nem csak ott. Másodszor, ezen a telepítésen nincs GPU: az alapértelmezett backend a mock, amelynek régiója dev-mock, és a mock nem képvisel helyet. Lásd alább: „Mi történik, ha nincs GPU?”. Az API, amely ezt teszi, egy Node-folyamat, nem része ennek a statikus oldalnak — a llmeu.com maga oldalakat szolgál ki, nem dolgoz fel kéréseket.
apps/api/src/inference.mjs:457 (a llmeu válaszblokk), packages/router/src/engine.mjs:467 (a residencia pontozás előtt kerül alkalmazásra), packages/inference/src/mock.mjs:7 (MOCK_REGION = dev-mock), packages/shared/src/catalog-schema.mjs:64 (az irányítható osztályok)
Megőrzik a promptokat és a completionöket?
Nem. A prompt- és completion-törzsek nem íródnak az adatbázisba. Minden hívás metaadatokat tárol — a kért és használt modellt, verziót, végpontot, régiót, szuverenitási osztályt, a router indokát, tokenszámokat, latenciát, költséget, állapotot —, és a sor prompt_stored értéke 0. A két törzsoszlop létezik a sémában, és null. A kikényszerítés kód, nem szabályzati próza: az a kérés, amelynek tényleges megőrzése bármi más, mint nulla, elutasításra kerül, 403 retention_exceeds_policy válasszal, ha többet kér, mint amit a szabályzatod enged, és 501 retention_not_implemented válasszal, ha engedélyezett, de nincs megvalósítva. A szabályzatok választhatóan tárolhatnak 24h, 7d vagy 30d értéket; a választás tárolása nem teszi lehetővé a törzs tárolását. Ha egy trace valaha 0-tól eltérő prompt_stored értéket mutat, az az egylapos válasz arra, hogy „mit tartottatok meg” — és ezt magad is ellenőrizheted jq-val, ahogy a bizonyítékoldal mutatja.
packages/shared/src/db/schema.sql:295 (prompt_stored és a két törzsoszlop), 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)
Tanítotok ügyféladatokon?
Nem — ebben a termékben semmi sincs olyan helyzetben, hogy ezt tehetné. Nincs tanítási vagy finomhangolási kódút az API-ban, a webes folyamatban, a routerben vagy a megosztott csomagokban. Az API egy kérést orchestrál egy backend felé, és méri azt; nincs adathalmaz-betöltés, nincs korpusztár és nincs fine-tune feladat. A prompt- és completion-törzsek nem íródnak az adatbázisba, így még egy tárolt korpusz sincs, amin tanítani lehetne. Ez a mi kódunkra vonatkozó állítás, nem minden modell upstream tanítási adataira. Azokat a modelleket, amelyeket mások adatain tanítottak, vagy amelyek felfedik a tanítási adataikat, a saját kártyáik írják le, forrásokkal, és néhány ilyen kártya azt mondja, hogy a tanítási adatok nincsenek közzétéve.
apps/api/src/inference.mjs (a teljes kérésút: orchestrálás, mérés, soha nem perzisztálás), packages/shared/src/db/schema.sql (nincs adathalmaz- vagy korpusztábla), packages/content/models.mjs:196 (egy kártya, amely azt mondja, hogy a tanítási adatok nincsenek közzétéve)
Mi történik, ha egyetlen végpont sem felel meg a residencia-szabályzatomnak?
A kérés meghiúsul. Nem minősül le egy közeli régióra, és nem kerül máshová: 409 no_endpoint_for_policy, az indok a hibátörzsben, a kizárt végpontok pedig megnevezve a trace-en. A residencia a pontozás előtt kerül alkalmazásra, és a failover soha csak a router által már szűrt halmazon belül mozog — ezért egy újrapróbálkozás nem tud csendben kikerülni a beállított szabály alól. A kód egy mondatban kimondja: „No endpoint satisfies residency {x}. Residency is never relaxed silently.” Mit lehet tenni: nevezz meg egy régiót vagy osztályt, amelyet a szabályzatod enged, szélesítsd a szabályzatot szándékosan (döntés, changelog-bejegyzéssel), vagy fogadd el, hogy az adott modellhez az adott szabály mellett nincs útvonal. A 409 a termék tervezett működése; az a hibaeset, amelyet megelőz, egy olyan kérés, amely „sikeres” volt valahol, amit nem engedélyeztél.
packages/shared/src/errors.mjs:59 (no_endpoint_for_policy), packages/router/src/engine.mjs:370 (a hiba, pontozás előtt), packages/router/src/engine.mjs:507 (a failover nem hagyhatja el a szűrt halmazt), apps/api/src/inference.mjs:137 (a megőrzést az útválasztás előtt ellenőrzik)
Ez GDPR-kompatibilis vagy tanúsított?
Nem teszünk ilyen állítást, és nem is fogunk — sem „AI Act compliant”, sem „certified”, sem „Official EU”. Az LLM EU magántársaság. Nem EU-s intézmény, és nem megfelelőségértékelő szervezet. Az „ellenőrzött” ezen az oldalon dokumentáltat jelent, nem jogilag tanúsítottat: ez egy közzétételi ellenőrzőlista, amelyet az alapján pontozunk, hogy egy kártya megadja-e a residenciát, szolgáltatót, verziót, megőrzést, alfeldolgozókat és licencet, hivatkozásokkal. Amit állíthatunk, az az, hogy mit tesz a kód, és hol vannak a hiányok: a nulla megőrzés kódban kikényszerítve; az API-kulcsok scrypt hashként tárolva, a titok egyszer megjelenítve; minden ügyféllekérdezés szervezeti azonosítóra szűrve; IP-nkénti, kulcsonkénti és szervezetenkénti sebességkorlátok; a kéréstörzsek maximálva és validálva. Ami nincs meg: nincs független penetrációs teszt; nincs külső audit; az adatvédelmi tájékoztató és a feltételek összefoglalók; a DPA egy felül nem vizsgált, aláíratlan sablon; az alfeldolgozói leltár hiányos. A biztonsági oldal és a jogi áttekintés a saját szakaszaikban sorolják fel ezeket a hiányokat; ez a válasz rájuk mutat, ahelyett hogy valami szelídebbé átfogalmazná őket.
docs/product/decisions.md:115 (ADR-006 — semmilyen szövegben nincs megfelelőségi pecsét), apps/web/server/pages/docs.mjs:537 (SECURITY_COPY: a kontroll- és hiánylista), apps/web/server/pages/docs.mjs:643 (LEGAL_READINESS: dokumentumonkénti készenlét)
Az API OpenAI-kompatibilis, és mit kell megváltoztatnia egy ügyfélnek?
A base URL-t, és semmi mást. A /v1/chat/completions elfogadja a hivatalos kérésalakot, és a hivatalos válaszalakot adja vissza — choices, usage, SSE-ként streamelve —, így a hivatalos SDK-k működnek, miután ránk irányítod őket. Az extra törzsmezőket figyelmen kívül hagyjuk, nem utasítjuk el, így egy újabb SDK nem tudja eltörni a régebbi útvonalat. Ami hozzáadott, az opcionális és additív: egy névtérbe tett llmeu objektum a kérésben (residency, task, retention, data_class, policy_id, max_usd_per_1m, allow_partners), és egy llmeu blokk a válaszban, amely tartalmazza a trace_id, model_used, model_version, provider, endpoint_id, inference_region, sovereignty_class, route_reason, policy_id, retention értékeket és költségbecsléseket. Szándékosan nem kínáljuk: /v1/completions (501), n > 1 (400), embeddings, kivéve ha ténylegesen hosztolunk embedding modellt. Az llmeu blokk kaphat új mezőket; egy mező eltávolítása törő változás lenne, és megjelenne a changelogban.
docs/product/decisions.md:78 (ADR-004), apps/api/src/app.mjs:554 (a válasz, amelyet a kliens olvas), apps/api/src/app.mjs:255 (501 a /v1/completions esetén), apps/web/server/pages/docs.mjs:403 (az írásos kompatibilitási szerződés)
Mi történik, ha nincs GPU?
A MockBackend válaszol, és ezt a saját kimenetében is megmondja: a completion megnevezi a modellt és a régiót, közli, hogy nem futott valódi súly, és megmondja, hogyan lehet bekapcsolni a first-party inferenciát (VLLM_BASE_URL, majd a gpu_enabled flag). A régiója dev-mock, ami nem egy hely, és egy mock hívásért nincs díj. A GET /readyz jelenti, mely backendez vannak fent, és a készenlétet nem elégíti ki egy up állapotú végpontsor — egy kezelt runtime-nak ténylegesen healthy állapotot kell jelentenie, mert a próba egész célja az, hogy elkapjon egy olyan node-ot, amelynek súlyai még töltődnek. A backend registry megtagadja, hogy a mockot olyan végpont helyettesítse, amelynek runtime-ja vllm; inkább dob egy hibát. Az őszinte összefoglaló kényelmetlen, és érdemes nyíltan kimondani: ezen a telepítésen nincs GPU, így az itteni hívás a folyamat demonstrációja, nem modellfuttatás. A mock siker siker a vezetéken; soha nem mutatjuk valódi modellfuttatásként.
packages/inference/src/mock.mjs:49 (a válasz, amely megnevezi a mockot), apps/api/src/app.mjs:157 (a készenlét tartalmazza a kezelt backendeket), docs/product/decisions.md:131 (ADR-007 — a registry megtagadja egy GPU runtime színlelését)
Mit jelent a catalogue_only jelölésű modellkártya?
Azt jelenti, hogy a modellt katalogizáljuk, de nem szolgáljuk ki. A kártya referencia-információ — szolgáltató, licenc, kontextusablak, ahol a szolgáltató szerint fut, minden adathoz forrás —, és egyetlen LLM EU-végpont sem felel érte. Ha az API-tól kéred, 404 hosted_unavailable választ kapsz, ezzel a megjegyzéssel: „catalogue only — not hosted on LLM EU yet”; egy oldal erről nem idéz árat, mert egy olyan dolog ára, amit senki sem hívhat, olyan állítás, amely mögött nincs semmi. Az arra a modellre irányuló kérések közvetlenül a szolgáltatójához mennek, annak saját feltételei szerint, és a modellkártya pontosan ezt mondja. Az ellenkező jelvény sem erősebb ígéret: egy általunk hosztolt modell egy megnevezett régióban, megnevezett szuverenitási osztállyal fut, és ez az az állítás, amelyet a trace-en ellenőrizhetsz. Egyik jelvény sem megfelelőségi nyilatkozat.
packages/router/src/engine.mjs:325 (a router elutasítja a kindot), apps/api/src/app.mjs:235 (404 hosted_unavailable a megjegyzéssel), apps/web/server/pages/docs.mjs:446 (az árazás kihagyja a catalogue_only-t)
Hogyan működik ma az árazás és a kredit?
Az árak bemeneti és kimeneti millió tokenenként értendők, végpontonként tárolva, és az árazási oldalon és a modellkártyákon jelennek meg, EUR-ban, egy közzétett USD-árfolyamból származtatva; a ledger maga USD micros-t tárol, és minden sorra ráírja az árfolyamot, így egy korábbi számla pontosan rekonstruálható. Minden completion visszaadja a cost_estimate_usd és cost_estimate_eur értéket, és egy trace mindkét pénznemben rögzíti a költséget. A szabályzati limitek — egy millióra vonatkozó plafon és egy napi plafon — az útválasztás előtt ellenőrzésre kerülnek, így a keret túllépése esetén a kérés elutasításra kerül, nem fut le. Ezen a telepítésen a kártyás fizetés nincs engedélyezve, és semmi nem ad hozzá automatikusan kreditet: még nincs számlázási futás és nincs operator credit útvonal. A konzol mutatja, mennyit költöttek és mennyi maradt. Ha egy stripe_enabled flag be van kapcsolva, a credit handler elfogad egy beküldött összeget anélkül, hogy ellenőrizné, történt-e fizetés — ezért kell a flagnak kikapcsolva maradnia, amíg a fizetésellenőrzés meg nincs valósítva és tesztelve, és ezért mondjuk ezt itt, ahelyett hogy checkout gombot kínálnánk.
docs/product/decisions.md:148 (ADR-008 — micros tárolva, EUR megjelenítve), apps/api/src/inference.mjs:457 (kérésenkénti költségbecslések), apps/web/server/pages/docs.mjs:463 (az árazási oldal kimondja, hogy a fizetés ki van kapcsolva), apps/web/server/pages/docs.mjs:559 (a credit handler nem ellenőrzi a fizetést)
Tudjuk saját magunk hosztolni?
Nem azon keresztül, amit ma szállítunk. Nincs önhosztolási disztribúció: nincs konténerkép, nincs telepítő, nincs on-premise licenc, nincs támogatási szerződés ahhoz, hogy ezt a saját környezetedben futtasd, és ez a repository nem támogatott telepítésként érhető el. A konzol csapatfelülete létezik, de a szervezeti szerepek nem jelentenek teljes szerepalapú hozzáférés-vezérlést, és ez dokumentálva van, nem pedig elbagatellizálva. Amit a katalógus tartalmaz, az egy on_prem_customer nevű residenciaosztály — „a modell az ügyfél által ellenőrzött infrastruktúrán fut” —, és ez egy végpont tulajdonlásának és üzemeltetésének osztályozása, nem a mi ajánlatunk. A katalógusban sok modell tesz közzé nyílt súlyokat, és a licenceik (némelyik nem kereskedelmi, némelyik csak kutatási célú) hivatkozással szerepelnek a kártyákon, így értékelheted, hogy magad futtatod őket; ez mások súlyairól és mások licencéről szóló döntés, nem az LLM EU önhosztolási terméke. On-premise beszélgetéshez a vállalati oldal a megfelelő ajtó, és az az őszinte, hogy a megállapodás még nem létezik.
packages/router/src/engine.mjs:12 (az on_prem_customer csak residencia-leképezésekben fordul elő), packages/shared/src/catalog-schema.mjs:84 (a definíciója), apps/web/server/pages/docs.mjs:517 (hiányos RBAC, kimondva), packages/content/models.mjs:695 (egy nyílt súlyú licenc egy kártyán)
Ha egy válasz itt hibás, az hiba, és hibaként kezeljük. Ahol a kód és ez az oldal ellentmond, a kód nyer — a bizonyítékoldal, a biztonsági oldal és a jogi áttekintés pedig azok a helyek, ahol a többi kényelmetlen részletet tartjuk, ahelyett hogy tízszer megismételnénk.
Kérdések, amelyekre ez az oldal nem válaszol: mail@llmeu.com
Bizonyíték és ellenőrzés · Biztonság · Jogi · Akadálymentesítés