Question 1

Missä kehotteet ja vastaukset käsitellään?

Accepted Answer

Reitittimen valitsemalla päätepisteellä, joka on nimetty alue, ja vastaus kertoo, mikä se on: jokaisen vastauksen llmeu-lohko sisältää inference_region, endpoint_id ja sovereignty_class. Käytäntösi sijaintiarvo rajoittaa tätä joukkoa ennen valintaa; se sovelletaan suodattimena, ei mieltymyksenä, eikä catalogue_unknown ole koskaan reititettävissä. Kaksi rajoitusta tuohon lauseeseen. Ensinnäkin aluerivit ovat konfiguraatiotietoja, eivät todisteita käynnissä olevista koneista tai vahvistetuista operaattorisopimuksista — sijaintidokumentti sanoo tämän omin sanoin, ja toistamme sen täällä sen sijaan, että se olisi vain siellä. Toiseksi tässä käyttöönotossa ei ole ensimmäisen osapuolen GPU-kapasiteettia: pyynnöt palvelee luetteloon tallennetut päätepisteet, ja malli, jolla ei ole aktiivista päätepistettä, on vain luettelossa, joten sitä koskeva pyyntö hylätään nimeltä sen sijaan, että siihen vastattaisiin korvikkeella. Katso "Mitä tapahtuu, jos GPU:ta ei ole?" jäljempänä. Tämän tekevä API on Node-prosessi, ei osa tätä staattista sivustoa — llmeu.com itse vastaa sivuista, se ei käsittele pyyntöjä.

Question 2

Säilytetäänkö kehotteet ja vastaukset?

Accepted Answer

Ei. Prompt- ja completion-runkoja ei kirjoiteta tietokantaan. Jokainen kutsu tallentaa metatiedot — pyydetty ja käytetty malli, versio, päätepiste, alue, suvereniteettiluokka, reitittimen syy, token-määrät, latenssi, kustannus, tila — ja rivin prompt_stored on 0. Kaksi runkosaraketta ovat skeemassa ja ovat null. Pakotus on koodia, ei politiikkatekstiä: pyyntö, jonka tehollinen säilytys on mitä tahansa muuta kuin nolla, hylätään, ja se saa 403 retention_exceeds_policy, jos se pyytää enemmän kuin käytäntösi sallii, ja 501 retention_not_implemented, jos se on sallittu mutta toteuttamatta. Käytännöt voivat tallentaa valintoina 24h, 7d tai 30d; valinnan tallentaminen ei mahdollista rungon tallentamista. Jos jäljitys joskus näyttää prompt_stored muun kuin 0, se on yhden sivun vastaus kysymykseen "mitä säilytit" — ja voit tarkistaa sen itse jq:lla, kuten todistesivu näyttää.

Question 3

Koulutatteko asiakastiedoilla?

Accepted Answer

Ei — mikään tässä tuotteessa ei ole siinä asemassa. API:ssa, web-prosessissa, reitittimessä tai jaetuissa paketeissa ei ole koulutus- tai hienosäätökoodipolkua. API orkestroi pyynnön taustajärjestelmälle ja mittaa sen; datan syöttöä, korpusvarastoa tai hienosäätötyötä ei ole. Prompt- ja completion-runkoja ei kirjoiteta tietokantaan, joten koulutettavaa tallennettua korpustakaan ei ole. Tämä on väite koodistamme, ei jokaisen mallin ylävirran koulutusdatasta. Mallit, jotka on koulutettu muiden datalla tai jotka paljastavat koulutusdatansa, kuvataan omilla korteillaan, lähteineen, ja osa näistä korteista sanoo, että koulutusdataa ei ole julkaistu.

Question 4

Mitä tapahtuu, kun mikään päätepiste ei täytä sijaintikäytäntöäni?

Accepted Answer

Pyyntö epäonnistuu. Sitä ei lasketa läheiseen alueeseen eikä lähetetä muualle: 409 no_endpoint_for_policy, syy virherungossa ja poissuljetut päätepisteet nimettyinä jäljityksessä. Sijaintivaatimus sovelletaan ennen pisteytystä, ja vikasieto liikkuu vain joukossa, jonka reititin on jo suodattanut — siksi uudelleenyritys ei voi hiljaa karata asettamastasi säännöstä. Koodi sanoo sen yhdellä lauseella: "Mikään päätepiste ei täytä sijaintivaatimusta {x}. Sijaintivaatimusta ei koskaan lievennetä hiljaa." Mitä tehdä: nimeä alue tai luokka, jonka käytäntösi sallii, laajenna käytäntöä tarkoituksella (päätös, josta changelog-merkintä) tai hyväksy, että kyseiselle mallille ei ole reittiä kyseisellä säännöllä. 409 on tuotteen toimintaa suunnitellusti; vikatila, jonka se estää, on pyyntö, joka "onnistui" jossain, mitä et sallinut.

Question 5

Onko tämä GDPR-yhteensopiva tai sertifioitu?

Accepted Answer

Ei — emmekä aio: ei "AI Act -yhteensopiva", ei "sertifioitu", ei "Official EU". LLM EU on yksityinen yritys, ei EU:n toimielin eikä vaatimustenmukaisuuden arviointilaitos. "Vahvistettu" tarkoittaa tässä dokumentoitua, ei oikeudellisesti sertifioitua: julkistuslista, joka pisteytetään sen mukaan, kertooko kortti sijaintinsa, tarjoajansa, versionsa, säilytyksensä, aliprosessorinsa ja lisenssinsä, linkkeineen. Mitä alusta tekee, ilmaistaan ehdoin, joihin koodi voidaan sitoa: nollasäilytys pakotettuna, API-avaimet tallennettu scrypt-tiivisteinä ja näytetty kerran, jokainen asiakaskysely rajataan organisaatiotunnuksella, per-IP-, per-avain- ja per-organisaatiorajat, pyyntörungot rajattu ja validoitu. Tietoturvatyöllä ja oikeudellisilla asiakirjoilla on kullakin oma sivunsa.

Question 6

Onko API OpenAI-yhteensopiva, ja mitä asiakas vaihtaa?

Accepted Answer

Perus-URL, eikä mitään muuta. /v1/chat/completions hyväksyy virallisen pyyntömuodon ja palauttaa virallisen vastausmuodon — choices, usage, striimaus SSE:nä — joten viralliset SDK:t toimivat, kun osoitat ne meille. Ylimääräiset runkokentät jätetään huomiotta hylkäämisen sijaan, joten uudempi SDK ei voi rikkoa vanhempaa reittiä. Lisätty on valinnaista ja lisäävää: nimitettu llmeu-objekti pyynnössä (residency, task, retention, data_class, policy_id, max_usd_per_1m, allow_partners) ja llmeu-lohko vastauksessa, joka sisältää trace_id, model_used, model_version, provider, endpoint_id, inference_region, sovereignty_class, route_reason, policy_id, retention ja kustannusarviot. Ei tarjota, tarkoituksella: /v1/completions (501), n > 1 (400), embeddings, ellei embedding-mallia todella ole ylläpidossa. llmeu-lohko voi saada kenttiä; yhden poistaminen olisi rikkova muutos ja näkyisi changelogissa.

Question 7

Mitä tapahtuu, jos GPU:ta ei ole?

Accepted Answer

Reititin palvelee niitä live-päätepisteitä, jotka luettelo tallentaa, ja jokainen vastaus nimeää päätepisteen, alueen ja suvereniteettiluokan, joka vastasi. Malli, jolla ei ole live-päätepistettä, on vain luettelossa: pyyntö sille hylätään nimeltä sen sijaan, että sijainen vastaisi. Ensiosapuolen kapasiteetti tarvitsee konfiguroidun poolin (VLLM_BASE_URL, sitten gpu_enabled-lippu); kunnes sellainen on, kapasiteetti on se, mitä päätepisterivit tallentavat, ja sivut kertovat, mikä se on. GET /readyz raportoi, mitkä taustajärjestelmät ovat ylhäällä, eikä valmius täyty päätepisterivistä, joka sanoo olevansa ylhäällä — hallitun ajoympäristön on todella raportoitava terveeksi, koska koko tuon tarkistuksen tarkoitus on havaita solmu, jonka painot vielä latautuvat. Taustajärjestelmärekisteri kieltäytyy korvaamasta yhtä ajoympäristöä toisella; se heittää sen sijaan. Rehellinen yhteenveto on epämukava ja syytä sanoa suoraan: tässä käyttöönotossa ei ole GPU:ta, joten kutsu täällä on putken esittely, ei malliajo. Sijaisen onnistuminen olisi onnistuminen verkossa eikä muuta, minkä vuoksi sitä ei koskaan esitetä oikeana malliajona.

Question 8

Mitä tarkoittaa mallikortti, joka on merkitty catalogue_only?

Accepted Answer

Se tarkoittaa, että luetteloimme mallin emmekä palvele sitä. Kortti on viitetietoa — tarjoaja, lisenssi, konteksti-ikkuna, missä tarjoaja sanoo sen ajautuvan, lähteet jokaiselle luvulle — eikä mikään LLM EU:n päätepiste vastaa siitä. Pyydä sitä API:lta, niin saat 404 hosted_unavailable, huomautuksella "vain luettelossa — ei vielä ylläpidossa LLM EU:ssa"; sitä koskeva sivu ei ilmoita hintaa, koska hinta jollekin, jota kukaan ei voi kutsua, on väite ilman mitään taustaa. Pyynnöt kyseiselle mallille menevät suoraan sen tarjoajalle, tarjoajan omilla ehdoilla, ja mallikortti sanoo juuri sen. Vastakkainen merkki ei ole sen vahvempi lupaus: mallia, jota ylläpidämme, ylläpidetään nimellyllä alueella ja nimellyllä suvereniteettiluokalla, ja se on väite, jonka voit tarkistaa jäljityksestä. Kumpikaan merkki ei ole vaatimustenmukaisuuslausunto.

Question 9

Miten hinnoittelu ja saldo toimivat tänään?

Accepted Answer

Hinnat ovat miljoonaa tokenia kohden sisään ja ulos, tallennettu päätepistekohtaisesti ja näytetty hinnoittelusivulla ja mallikorteilla, euroina, johdettu yhdestä julkaistusta USD-kurssista; kirjanpito itsessään tallentaa USD-mikroja ja kirjoittaa kurssin joka riville, joten mennyt lasku voidaan rakentaa tarkasti uudelleen. Jokainen completion palauttaa cost_estimate_usd ja cost_estimate_eur, ja jäljitys tallentaa kustannuksen molempina. Käytäntörajat — miljoonakohtainen yläraja ja päiväraja — tarkistetaan ennen reititystä, joten ylibudjetin pyyntö hylätään eikä sitä ajeta. Korttimaksut eivät ole käytössä tässä käyttöönotossa, eikä mikään lisää saldoa automaattisesti: laskuajoa ei ole eikä operaattorin saldopolkua vielä. Konsoli näyttää, mitä on käytetty ja mitä on jäljellä. Jos stripe_enabled-lippu kytketään päälle, saldokäsittelijä hyväksyy lähetetyn summan varmistamatta, että maksu tapahtui — minkä vuoksi lipun on pysyttävä pois päältä, kunnes maksun varmistus on toteutettu ja testattu, ja minkä vuoksi sanomme sen tässä sen sijaan, että tarjoaisimme kassanapit.

Question 10

Voimmeko ylläpitää itse?

Accepted Answer

Ei minkään kautta, mitä toimitamme tänään. Itse ylläpidettävää jakelua ei ole: ei konttikuvaa, ei asentajaa, ei paikallista lisenssiä, ei tukisopimusta tämän ajamiseksi omassa ympäristössäsi, eikä tätä repositoriota tarjota tuettuna käyttöönottona. Konsolin tiimipinta on olemassa, mutta organisaatioroolit eivät ole täydellinen roolipohjainen käyttöoikeuden hallinta, ja se on dokumentoitu eikä ohitettu vihjailulla. Mitä luettelo kyllä sisältää, on sijaintiluokka nimeltä on_prem_customer — "malli ajetaan infrastruktuurissa, jota asiakas hallitsee" — ja se on päätepisteen omistajuuden ja toiminnan luokittelu, ei tarjouksemme. Monet luettelon malleista julkaisevat avoimet painot, ja niiden lisenssit (osa ei-kaupallisia, osa vain tutkimuskäyttöön) ovat korteilla linkkeineen, joten voit arvioida niiden ajamista itse; se on päätös jonkun toisen painoista ja jonkun toisen lisenssistä, ei LLM EU:n self-hosting-tuote. Paikallista keskustelua varten enterprise-sivu on oikea ovi, ja on rehellistä, että järjestelyä ei vielä ole.

Usein kysytyt kysymykset