Question 1

Hvor behandles prompts og completions?

Accepted Answer

På det endpoint, routeren vælger, som er en navngivet region, og svaret fortæller dig hvilken: llmeu-svarblokken på hver completion indeholder inference_region, endpoint_id og sovereignty_class. En residency-værdi i din politik begrænser det sæt før valget; den anvendes som et filter, ikke som en præference, og catalogue_unknown er aldrig routbar. To begrænsninger ved den sætning. For det første er regionsrækker konfigurationsdata, ikke bevis for kørende maskiner eller bekræftede operatøraftaler — residency-dokumentet siger dette med sine egne ord, og vi gentager det her i stedet for kun der. For det andet er der i denne deployment ingen first-party GPU-kapacitet: anmodninger betjenes af de endpoints, kataloget registrerer, og en model uden et live-endpoint er kun i kataloget, så en anmodning om den afvises ved navn i stedet for at blive besvaret af en stedfortræder. Se "Hvad sker der, hvis der ikke er nogen GPU?" nedenfor. Den API, der gør dette, er en Node-proces, ikke en del af dette statiske websted — llmeu.com besvarer selv sider, det behandler ikke anmodninger.

Question 2

Gemmes prompts og completions?

Accepted Answer

Nej. Prompt- og completion-bodies skrives ikke til databasen. Hvert kald gemmer metadata — model anmodet om og brugt, version, endpoint, region, suverænitetsklasse, routerens begrundelse, tokenantal, latency, omkostning, status — og rækkens prompt_stored er 0. De to body-kolonner findes i skemaet og er null. Håndhævelsen er kode, ikke policyprosa: en anmodning, hvis effektive opbevaring er andet end nul, afvises, med 403 retention_exceeds_policy, hvis den beder om mere, end din politik tillader, og 501 retention_not_implemented, hvis den er tilladt, men ikke implementeret. Politikker kan gemme 24h, 7d eller 30d som valg; at gemme valget aktiverer ikke lagring af body'en. Hvis en trace nogensinde viser prompt_stored anderledes end 0, er det ét-sides-svaret på "hvad gemte I" — og du kan selv kontrollere det med jq, som evidenssiden viser.

Question 3

Træner I på kundedata?

Accepted Answer

Nej — intet i dette produkt er i stand til det. Der er ingen trænings- eller finjusteringskodevej i API'en, webprocessen, routeren eller de delte pakker. API'en orkestrerer en anmodning til en backend og måler den; der er ingen datasætindtagelse, intet korpuslager og intet finjusteringsjob. Prompt- og completion-bodies skrives ikke til databasen, så der er ikke engang et gemt korpus at træne på. Det er en udtalelse om vores kode, ikke om hver models upstream-træningsdata. Modeller, der blev trænet på andres data, eller som offentliggør deres træningsdata, er beskrevet på deres egne kort, med kilder, og nogle af disse kort siger, at træningsdataene ikke er offentliggjort.

Question 4

Hvad sker der, når ingen endpoint opfylder min residenspolitik?

Accepted Answer

Anmodningen mislykkes. Den nedgraderes ikke til en nærliggende region, og den sendes ikke andre steder hen: 409 no_endpoint_for_policy, med årsagen i fejlbody'en og de udelukkede endpoints navngivet på trace'en. Residens anvendes før scoring, og failover flytter kun inden for det sæt, routeren allerede har filtreret — hvilket er grunden til, at et retry ikke stille kan undslippe den regel, du har sat. Koden siger det i én sætning: "No endpoint satisfies residency {x}. Residency is never relaxed silently." Hvad man kan gøre ved det: navngiv en region eller klasse, som din politik tillader, udvid politikken bevidst (en beslutning, med en changelog-post), eller accepter, at der ikke findes nogen rute for den model under den regel. En 409 er produktet, der fungerer som designet; den fejltilstand, den forhindrer, er en anmodning, der "lykkedes" et sted, du ikke tillod.

Question 5

Er dette GDPR-compliant eller certificeret?

Accepted Answer

Nej — og det vil vi ikke: ikke "AI Act-compliant", ikke "certificeret", ikke "Official EU". LLM EU er en privat virksomhed, ikke en EU-institution og ikke et overensstemmelsesvurderingsorgan. "Verified" betyder her dokumenteret, ikke juridisk certificeret: en oplysningscheckliste, der scores efter, om et kort angiver sin residens, udbyder, version, opbevaring, underleverandører og licens, med links. Hvad platformen gør, er formuleret i vendinger, som koden kan holdes op på: nul opbevaring håndhævet, API-nøgler gemt som scrypt-hashes og vist én gang, hver kundeforespørgsel afgrænset efter organisations-id, per-IP-, per-nøgle- og per-org-ratebegrænsninger, anmodningsbodies begrænset og valideret. Sikkerhedsarbejde og de juridiske dokumenter har hver deres side.

Question 6

Er API'en OpenAI-kompatibel, og hvad skal en kunde ændre?

Accepted Answer

Base-URL'en, og intet andet. /v1/chat/completions accepterer den officielle anmodningsform og returnerer den officielle svarform — choices, usage, streaming som SSE — så de officielle SDK'er virker, når du peger dem på os. Ekstra body-felter ignoreres i stedet for at blive afvist, så et nyere SDK ikke kan bryde en ældre rute. Det, der tilføjes, er valgfrit og additivt: et namespaced llmeu-objekt i anmodningen (residency, task, retention, data_class, policy_id, max_usd_per_1m, allow_partners) og en llmeu-blok i svaret med trace_id, model_used, model_version, provider, endpoint_id, inference_region, sovereignty_class, route_reason, policy_id, retention og omkostningsestimater. Ikke tilbudt, med vilje: /v1/completions (501), n > 1 (400), embeddings medmindre en embedding-model faktisk hostes. llmeu-blokken kan få felter; at fjerne et ville være en breaking change og ville fremgå af changelog'en.

Question 7

Hvad sker der, hvis der ikke er nogen GPU?

Accepted Answer

Routeren betjener, hvad end kataloget registrerer af live endpoints, og hvert svar navngiver det endpoint, den region og den suverænitetsklasse, der svarede. En model uden et live endpoint er kun katalog: en anmodning om den afvises ved navn i stedet for at blive besvaret af en stand-in. Førsteparts-kapacitet kræver en konfigureret pool (VLLM_BASE_URL, derefter gpu_enabled-flaget); indtil en findes, er kapaciteten, hvad endpoint-rækkerne registrerer, og siderne siger, hvad det er. GET /readyz rapporterer, hvilke backends der er oppe, og readiness opfyldes ikke af en endpoint-række, der siger oppe — en managed runtime skal faktisk rapportere healthy, fordi hele pointen med den probe er at fange en node, hvis vægte stadig indlæses. Backend-registret nægter at erstatte én runtime med en anden; det kaster i stedet. Det ærlige resumé er ubehageligt og værd at sige klart: denne deployment har ingen GPU, så et kald her er en demonstration af pipelinen, ikke en modelkørsel. En stand-in-succes ville være en succes på wire'en og intet mere, hvilket er grunden til, at det aldrig præsenteres som en rigtig modelkørsel.

Question 8

Hvad betyder et modelkort markeret catalogue_only?

Accepted Answer

Det betyder, at vi katalogiserer modellen og ikke hoster den. Kortet er referenceinformation — udbyder, licens, kontekstvindue, hvor udbyderen siger, den kører, kilder til hvert tal — og intet LLM EU-endpoint svarer for den. Bed API'en om den, og du får 404 hosted_unavailable, med noten "catalogue only — not hosted on LLM EU yet"; en side for den angiver ingen pris, fordi en pris for noget, ingen kan kalde, er et krav uden noget bag. Anmodninger til den model går direkte til dens udbyder, under udbyderens egne vilkår, og modelkortet siger præcis det. Det modsatte badge er heller ikke et stærkere løfte: en model, vi hoster, hostes i en navngivet region med en navngivet suverænitetsklasse, og det er det krav, du kan kontrollere på trace'en. Intet af badge'erne er en compliance-erklæring.

Question 9

Hvordan fungerer prissætning og kredit i dag?

Accepted Answer

Priser er per million tokens ind og ud, gemt per endpoint og vist på prissiden og modelkortene, i EUR, afledt af én offentliggjort USD-kurs; ledgeren selv gemmer USD-micros og skriver kursen på hver række, så en tidligere faktura kan rekonstrueres nøjagtigt. Hver completion returnerer cost_estimate_usd og cost_estimate_eur, og en trace registrerer omkostningen i begge. Politikgrænser — et per-million-loft og et dagligt loft — kontrolleres før routing, så en anmodning over budget afvises i stedet for at blive kørt. Kortbetalinger er ikke aktiveret i denne deployment, og intet tilføjer kredit automatisk: der er ingen fakturakørsel og ingen operatørkreditvej endnu. Konsollen viser, hvad der er brugt, og hvad der er tilbage. Hvis et stripe_enabled-flag tændes, accepterer kredithåndteringen et indsendt beløb uden at verificere, at en betaling er sket — hvilket er grunden til, at flaget skal forblive slukket, indtil betalingsverifikation er implementeret og testet, og hvorfor vi siger det her i stedet for at tilbyde en checkout-knap.

Question 10

Kan vi selvhoste?

Accepted Answer

Ikke gennem noget, vi leverer i dag. Der findes ingen selvhostet distribution: intet container-image, ingen installer, ingen on-premise-licens, ingen supportkontrakt til at køre dette i jeres eget setup, og dette repository tilbydes ikke som en understøttet deployment. Konsollens team-flade findes, men organisationsroller er ikke komplet rollebaseret adgangskontrol, og det er dokumenteret i stedet for at blive tiet væk. Hvad kataloget derimod har, er en residensklasse kaldet on_prem_customer — "modellen kører inden for infrastruktur, som kunden kontrollerer" — og det er en klassificering af et endpoints ejerskab og drift, ikke et tilbud fra os. Mange af modellerne i kataloget offentliggør åbne vægte, og deres licenser (nogle ikke-kommercielle, nogle kun til forskning) er på kortene med et link, så du kan vurdere at køre dem selv; det er en beslutning om andres vægte og andres licens, ikke et selvhostingprodukt fra LLM EU. For en on-premise-samtale er enterprise-siden den rigtige indgang, og det er ærligt, at ordningen ikke findes endnu.

Ofte stillede spørgsmål