Question 1

Onde são processados os prompts e as conclusões?

Accepted Answer

No endpoint que o router seleciona, que é uma região nomeada, e a resposta indica-lhe qual: o bloco llmeu em cada conclusão contém inference_region, endpoint_id e sovereignty_class. Um valor de residência na sua política restringe esse conjunto antes da seleção; é aplicado como filtro, não como preferência, e catalogue_unknown nunca é encaminhável. Dois limites a essa frase. Primeiro, as linhas de região são dados de configuração, não prova de máquinas em funcionamento ou de contratos de operador confirmados — o documento de residência diz isto pelas suas próprias palavras, e repetimo-lo aqui em vez de apenas ali. Segundo, nesta implementação não há capacidade de GPU própria: os pedidos são servidos pelos endpoints que o catálogo regista, e um modelo sem endpoint ativo é apenas de catálogo, pelo que um pedido para ele é recusado pelo nome em vez de ser respondido por um substituto. Ver «O que acontece se não houver GPU?» abaixo. A API que faz isto é um processo Node, não faz parte deste site estático — o próprio llmeu.com responde a páginas, não processa pedidos.

Question 2

Os prompts e as conclusões são conservados?

Accepted Answer

Não. Os corpos de prompt e completion não são gravados na base de dados. Cada chamada armazena metadados — modelo solicitado e usado, versão, endpoint, região, classe de soberania, o motivo do router, contagens de tokens, latência, custo, estado — e o prompt_stored da linha é 0. As duas colunas de corpo existem no schema e são nulas. A aplicação é feita por código, não por texto de política: um pedido cuja retenção efetiva seja diferente de zero é recusado, com 403 retention_exceeds_policy se pedir mais do que a sua política permite e 501 retention_not_implemented se for permitido mas não implementado. As políticas podem armazenar 24h, 7d ou 30d como opções; armazenar a opção não permite armazenar o corpo. Se um trace alguma vez mostrar prompt_stored diferente de 0, essa é a resposta de uma página a "o que guardou" — e pode verificá-lo você mesmo com jq, como mostra a página de evidências.

Question 3

Treinam com dados de clientes?

Accepted Answer

Não — nada neste produto está em posição de o fazer. Não existe qualquer caminho de código de treino ou fine-tuning na API, no processo web, no router ou nos pacotes partilhados. A API orquestra um pedido a um backend e mede-o; não há ingestão de datasets, nem armazenamento de corpus, nem tarefa de fine-tune. Os corpos de prompt e completion não são gravados na base de dados, por isso não existe sequer um corpus armazenado para treinar. Isto é uma afirmação sobre o nosso código, não sobre os dados de treino upstream de todos os modelos. Os modelos que foram treinados com dados de outras pessoas, ou que divulgam os seus dados de treino, são descritos nos seus próprios cartões, com fontes, e alguns desses cartões dizem que os dados de treino não são publicados.

Question 4

O que acontece quando nenhum endpoint satisfaz a minha política de residência?

Accepted Answer

O pedido falha. Não é rebaixado para uma região próxima, nem enviado para outro sítio: 409 no_endpoint_for_policy, com o motivo no corpo do erro e os endpoints excluídos indicados no trace. A residência é aplicada antes da pontuação, e o failover só se move dentro do conjunto que o router já filtrou — é por isso que uma nova tentativa não pode escapar silenciosamente à regra que definiu. O código di-lo numa frase: "Nenhum endpoint satisfaz a residência {x}. A residência nunca é relaxada silenciosamente." O que fazer: indicar uma região ou classe que a sua política permita, alargar a política deliberadamente (uma decisão, com entrada no changelog), ou aceitar que não existe rota para esse modelo sob essa regra. Um 409 é o produto a funcionar como concebido; o modo de falha que evita é um pedido que "teve sucesso" num sítio que não permitiu.

Question 5

Isto está conforme ao RGPD ou certificado?

Accepted Answer

Não — e não vamos: nem "conforme ao AI Act", nem "certificado", nem "Oficial da UE". A LLM EU é uma empresa privada, não uma instituição da UE e não um organismo de avaliação da conformidade. "Verificado" aqui significa documentado, não certificado juridicamente: uma lista de divulgação pontuada por o cartão indicar a sua residência, fornecedor, versão, retenção, subcontratantes e licença, com ligações. O que a plataforma faz é expresso em termos pelos quais o código pode ser responsabilizado: retenção zero aplicada, chaves de API armazenadas como hashes scrypt e mostradas uma vez, todas as consultas de clientes delimitadas por id de organização, limites de taxa por IP, por chave e por organização, corpos de pedido limitados e validados. O trabalho de segurança e os documentos legais têm cada um a sua página.

Question 6

A API é compatível com a OpenAI, e o que é que um cliente altera?

Accepted Answer

O URL base, e nada mais. /v1/chat/completions aceita a forma oficial do pedido e devolve a forma oficial da resposta — choices, usage, streaming como SSE — por isso os SDKs oficiais funcionam depois de os apontar para nós. Campos extra no corpo são ignorados em vez de rejeitados, para que um SDK mais recente não quebre uma rota mais antiga. O que é acrescentado é opcional e aditivo: um objeto llmeu com namespace no pedido (residency, task, retention, data_class, policy_id, max_usd_per_1m, allow_partners) e um bloco llmeu na resposta com trace_id, model_used, model_version, provider, endpoint_id, inference_region, sovereignty_class, route_reason, policy_id, retention e estimativas de custo. Não oferecido, deliberadamente: /v1/completions (501), n > 1 (400), embeddings a menos que um modelo de embeddings esteja efetivamente alojado. O bloco llmeu pode ganhar campos; remover um seria uma quebra de compatibilidade e apareceria no changelog.

Question 7

O que acontece se não houver GPU?

Accepted Answer

O router serve os endpoints ativos que o catálogo regista, e cada resposta nomeia o endpoint, a região e a classe de soberania que respondeu. Um modelo sem endpoint ativo é apenas de catálogo: um pedido para ele é recusado pelo nome em vez de ser respondido por um substituto. A capacidade própria precisa de um pool configurado (VLLM_BASE_URL, depois o flag gpu_enabled); até existir, a capacidade é a que as linhas de endpoint registam, e as páginas dizem qual é. GET /readyz reporta quais backends estão up, e a prontidão não é satisfeita por uma linha de endpoint que diga up — um runtime gerido tem de reportar healthy, porque o objetivo dessa sonda é apanhar um nó cujos pesos ainda estão a carregar. O registo de backends recusa substituir um runtime por outro; em vez disso, lança erro. O resumo honesto é desconfortável e vale a pena dizê-lo claramente: esta implementação não tem GPU, por isso uma chamada aqui é uma demonstração do pipeline, não uma execução de modelo. Um sucesso de substituto seria um sucesso no fio e nada mais, razão pela qual nunca é apresentado como uma execução real de modelo.

Question 8

O que significa um cartão de modelo marcado como catalogue_only?

Accepted Answer

Significa que catalogamos o modelo e não o servimos. O cartão é informação de referência — fornecedor, licença, janela de contexto, onde o fornecedor diz que corre, fontes para cada valor — e nenhum endpoint da LLM EU responde por ele. Peça-o à API e recebe 404 hosted_unavailable, com a nota "apenas de catálogo — ainda não alojado na LLM EU"; uma página para ele não indica preço, porque um preço para algo que ninguém pode chamar é uma afirmação sem nada por trás. Os pedidos para esse modelo vão diretamente para o seu fornecedor, sob os termos desse fornecedor, e o cartão do modelo diz exatamente isso. O selo oposto também não é uma promessa mais forte: um modelo que alojamos está alojado numa região nomeada com uma classe de soberania nomeada, e essa é a afirmação que pode verificar no trace. Nenhum dos selos é uma declaração de conformidade.

Question 9

Como funcionam hoje os preços e o crédito?

Accepted Answer

Os preços são por milhão de tokens de entrada e saída, armazenados por endpoint e apresentados na página de preços e nos cartões de modelo, em EUR, derivados de uma única taxa USD publicada; o ledger armazena micros USD e grava a taxa em cada linha, para que uma fatura passada possa ser reconstruída exatamente. Cada completion devolve cost_estimate_usd e cost_estimate_eur, e um trace regista o custo em ambos. Os limites de política — um teto por milhão e um teto diário — são verificados antes do routing, por isso um pedido acima do orçamento é recusado em vez de executado. Os pagamentos com cartão não estão ativados nesta implementação, e nada adiciona crédito automaticamente: ainda não há execução de faturas nem caminho de crédito de operador. A consola mostra o que foi gasto e o que resta. Se um flag stripe_enabled for ativado, o handler de crédito aceita um montante submetido sem verificar que ocorreu um pagamento — é por isso que o flag tem de permanecer desligado até a verificação de pagamento estar implementada e testada, e por isso o dizemos aqui em vez de oferecer um botão de checkout.

Question 10

Podemos fazer self-hosting?

Accepted Answer

Não através de nada que entreguemos hoje. Não existe distribuição self-hosted: nem imagem de contentor, nem instalador, nem licença on-premise, nem contrato de suporte para executar isto no seu próprio ambiente, e este repositório não é oferecido como uma implementação suportada. A superfície de equipa da consola existe, mas as roles de organização não são um controlo de acesso baseado em funções completo, e isso está documentado em vez de ser subentendido. O que o catálogo tem é uma classe de residência chamada on_prem_customer — "o modelo corre em infraestrutura controlada pelo cliente" — e é uma classificação da propriedade e operação de um endpoint, não uma oferta nossa. Muitos dos modelos no catálogo publicam pesos abertos, e as suas licenças (algumas não comerciais, algumas apenas para investigação) estão nos cartões com uma ligação, para que possa avaliar executá-los você mesmo; isso é uma decisão sobre pesos de outra pessoa e licença de outra pessoa, não um produto de self-hosting da LLM EU. Para uma conversa sobre on-premise, a página enterprise é a porta certa, e é honesto que o acordo ainda não existe.

Perguntas frequentes