Question 1

Hol dolgozzák fel a promptokat és a completionöket?

Accepted Answer

Azon a végponton, amelyet az útválasztó kiválaszt, és amely egy megnevezett régió; a válasz megmondja, melyik: minden completion llmeu blokkja tartalmazza az inference_region, endpoint_id és sovereignty_class adatokat. Az Ön szabályzatában szereplő rezidenciaérték a kiválasztás előtt korlátozza ezt a halmazt; szűrőként alkalmazzuk, nem preferenciaként, és a catalogue_unknown soha nem útválasztható. Két korlát vonatkozik erre a mondatra. 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 rezidencia-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 első féltől származó GPU-kapacitás: a kéréseket a katalógusban rögzített végpontok szolgálják ki, és egy olyan modell, amelyhez nincs élő végpont, csak katalógusban szerepel, így a rá vonatkozó kérést név szerint elutasítjuk, nem pedig egy helyettesítővel válaszolunk rá. Lásd alább: „Mi történik, ha nincs GPU?”. Az ezt végző API egy Node-folyamat, nem része ennek a statikus webhelynek — a llmeu.com maga oldalakat szolgál ki, nem dolgoz fel kéréseket.

Question 2

Megőrzik a promptokat és a completionöket?

Accepted Answer

Nem. A prompt- és completion-törzsek nem kerülnek az adatbázisba. Minden hívás metaadatokat tárol — kért és használt modell, verzió, végpont, régió, szuverenitási osztály, a router indoka, tokenszámok, késleltetés, költség, állapot —, é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 hibával, ha többet kér, mint amit a szabályzata engedélyez, és 501 retention_not_implemented hibával, ha engedélyezett, de nincs megvalósítva. A szabályzatok 24h, 7d vagy 30d értéket tárolhatnak választásként; 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 tartottál meg” — és ezt magad is ellenőrizheted jq-val, ahogy a bizonyítékoldal mutatja.

Question 3

Tanítotok ügyféladatokon?

Accepted Answer

Nem — ebben a termékben semmi sincs olyan helyzetben, hogy ezt tehetné. Nincs tanítási vagy finomhangolási kódútvonal az API-ban, a webes folyamatban, a routerben vagy a megosztott csomagokban. Az API egy kérést vezényel a backend felé, és méri azt; nincs adatkészlet-betöltés, nincs korpusztár és nincs finomhangolási feladat. A prompt- és completion-törzsek nem kerülnek az adatbázisba, így még egy tárolt korpusz sincs, amin tanítani lehetne. Ez a kódunkra vonatkozó állítás, nem minden modell upstream tanítási adataira. Azok a modellek, amelyeket mások adatain tanítottak, vagy amelyek közzéteszik a tanítási adataikat, a saját kártyáikon vannak leírva, forrásokkal, és néhány ilyen kártya azt mondja, hogy a tanítási adatok nincsenek publikálva.

Question 4

Mi történik, ha egyetlen végpont sem felel meg a rezidencia-szabályzatomnak?

Accepted Answer

A kérés meghiúsul. Nem kerül lefokozásra egy közeli régióra, és nem kerül máshová küldésre: 409 no_endpoint_for_policy, az ok a hibaszövegben, a kizárt végpontok pedig a trace-en megnevezve. A rezidencia a pontozás előtt kerül alkalmazásra, és a failover soha nem mozog a router által már szűrt halmazon kívül — ezért egy újrapróbálkozás nem tud csendben kikerülni a beállított szabályt. 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élyez, tudatosan szélesítsd a szabályzatot (döntés, changelog-bejegyzéssel), vagy fogadd el, hogy abban a szabályban nincs útvonal ahhoz a modellhez. A 409 a termék tervezett működése; az a hibaeset, amelyet megelőz, egy olyan kérés, amely olyan helyen „sikerült”, ahol nem engedélyezted.

Question 5

GDPR-kompatibilis vagy tanúsított ez?

Accepted Answer

Nem — és nem is leszünk azok: nem „AI Act-kompatibilis”, nem „tanúsított”, nem „hivatalos EU”. Az LLM EU magáncég, nem uniós intézmény és nem megfelelőségértékelő szervezet. Az „ellenőrzött” itt dokumentáltat jelent, nem jogilag tanúsítottat: egy közzétételi ellenőrzőlista pontozva aszerint, hogy egy kártya feltünteti-e a rezidenciáját, szolgáltatóját, verzióját, megőrzését, alvállalkozóit és licencét, hivatkozásokkal. Amit a platform tesz, olyan kifejezésekkel van megfogalmazva, amelyek számon kérhetők a kódon: nulla megőrzés kikényszerítve, az API-kulcsok scrypt-hash-ként tárolva és egyszer megjelenítve, minden ügyféllekérdezés szervezetazonosítóra szűkítve, IP-nkénti, kulcsonkénti és szervezetenkénti sebességkorlátok, a kéréstörzsek mérete korlátozva és érvényesítve. A biztonsági munka és a jogi dokumentumok külön oldallal rendelkeznek.

Question 6

OpenAI-kompatibilis az API, és mit kell megváltoztatnia egy ügyfélnek?

Accepted Answer

A bázis URL-t, és semmi mást. A /v1/chat/completions elfogadja a hivatalos kérésformátumot, és a hivatalos válaszformátumot adja vissza — choices, usage, streamelés SSE-ként —, így a hivatalos SDK-k működnek, miután ránk irányítod őket. A további törzsmezőket figyelmen kívül hagyja, nem utasítja el, így egy újabb SDK nem tud megtörni egy régebbi útvonalat. Amit hozzáadunk, az opcionális és additív: egy névtérbe ágyazott 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 trace_id, model_used, model_version, provider, endpoint_id, inference_region, sovereignty_class, route_reason, policy_id, retention és költségbecslések mezőket hordoz. 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.

Question 7

Mi történik, ha nincs GPU?

Accepted Answer

A router azt szolgálja ki, amit a katalógus élő végpontként nyilvántart, és minden válasz megnevezi a végpontot, a régiót és a szuverenitási osztályt, amely válaszolt. Egy élő végpont nélküli modell csak katalógusban létezik: a rá vonatkozó kérés név szerint elutasításra kerül, nem pedig egy helyettesítő válaszol rá. Az első féltől származó kapacitáshoz konfigurált pool kell (VLLM_BASE_URL, majd a gpu_enabled jelző); amíg ilyen nincs, a kapacitás az, amit a végpontsorok rögzítenek, és az oldalak megmondják, melyik az. A GET /readyz jelenti, mely backends vannak fent, és a ready állapotot nem elégíti ki egy „up” állapotú végpontsor — egy felügyelt futásidejű környezetnek ténylegesen egészségesnek kell jelentkeznie, mert a próba egész célja, hogy elkapjon egy olyan csomópontot, amelynek a súlyai még töltődnek. A backend-nyilvántartás megtagadja, hogy egy futásidejű környezetet egy másikkal helyettesítsen; ehelyett kivételt dob. Az őszinte összefoglaló kényelmetlen, és érdemes egyenesen kimondani: ennek a telepítésnek nincs GPU-ja, így az itteni hívás a pipeline bemutatása, nem modellfuttatás. Egy helyettesítő siker siker lenne a vezetéken, és semmi több, ezért soha nem mutatjuk be valódi modellfuttatásként.

Question 8

Mit jelent a catalogue_only jelölésű modellkártya?

Accepted Answer

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 válaszol érte. Kérdezd meg tőle az API-t, és 404 hosted_unavailable-t kapsz, ezzel a megjegyzéssel: „catalogue only — not hosted on LLM EU yet”; egy oldal érte nem idéz árat, mert egy ár olyasmiért, amit senki sem tud meghívni, olyan állítás, amely mögött nincs semmi. A modellhez intézett 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 ellentétes jelvény sem erősebb ígéret: egy általunk hosztolt modell egy megnevezett régióban, megnevezett szuverenitási osztállyal van hosztolva, és ezt az állítást ellenőrizheted a trace-en. Egyik jelvény sem megfelelőségi nyilatkozat.

Question 9

Hogyan működik ma az árazás és a kredit?

Accepted Answer

Az árak bemeneti és kimeneti millió tokenenként értendők, végpontonként tárolva, és az árazási oldalon valamint a modellkártyákon jelennek meg, EUR-ban, egy közzétett USD-árfolyamból származtatva; maga a főkönyv USD-mikrokat 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ékeket, és egy trace mindkettőben rögzíti a költséget. A szabályzati limitek — egy millióra vonatkozó felső korlát és egy napi felső korlát — az útvonalválasztás előtt ellenőrzésre kerülnek, így egy keret túllépő kérés elutasításra kerül, nem pedig lefut. A kártyás fizetés ezen a telepítésen nincs engedélyezve, és semmi nem ad hozzá automatikusan kreditet: még nincs számlázási futás és nincs operátori kreditútvonal. A konzol mutatja, mennyi fogyott el és mennyi maradt. Ha egy stripe_enabled jelző be van kapcsolva, a kreditkezelő elfogad egy beérkező összeget anélkül, hogy ellenőrizné, megtörtént-e a fizetés — ezért kell a jelzőnek kikapcsolva maradnia, amíg a fizetésellenőrzés meg nincs valósítva és tesztelve, és ezért mondjuk ezt itt ahelyett, hogy fizetési gombot kínálnánk.

Question 10

Tudunk önhosztolni?

Accepted Answer

Nem azzal, amit ma szállítunk. Nincs önhosztolt disztribúció: nincs konténerkép, nincs telepítő, nincs helyszíni licenc, nincs támogatási szerződés ahhoz, hogy ezt a saját környezetében futtassa, és ez a repository nincs támogatott telepítésként kínálva. A konzol csapatfelülete létezik, de a szervezeti szerepkörök nem jelentenek teljes szerepkör-alapú hozzáférés-vezérlést, és ez dokumentálva van, nem pedig kimondatlanul elfedve. Amit a katalógus viszont tartalmaz, az egy on_prem_customer nevű rezidenciaosztá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 publikál nyílt súlyokat, és a licenceik (némelyik nem kereskedelmi, némelyik csak kutatási célra) hivatkozással a kártyákon vannak, így értékelheti, hogy saját maga futtatja ő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. Helyszíni beszélgetéshez a vállalati oldal a megfelelő ajtó, és az őszinteséghez hozzátartozik, hogy ez a konstrukció még nem létezik.

Gyakran ismételt kérdések