Perguntas frequentes
A maioria das páginas deste site faz uma afirmação. Esta responde a dez perguntas que um comprador normalmente tem de nos enviar por email para obter. Quando a resposta é "ainda não", diz "ainda não" — uma página que exagerasse valeria menos do que nenhuma página, porque todas as outras páginas aqui são escritas para serem verificáveis.
Onde são processados os prompts e as conclusões?
No endpoint que o router seleciona, que é uma região nomeada, e a resposta diz-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 um filtro, não como uma 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 evidência de máquinas em funcionamento ou contratos de operador confirmados — o documento de residência diz isto pelas suas próprias palavras, e repetimo-lo aqui em vez de apenas lá. Segundo, nesta implementação não há GPU: o backend predefinido é o mock, cuja região é dev-mock, e o mock não representa um lugar. Ver "O que acontece se não houver GPU?" abaixo. A API que faz isto é um processo Node, não parte deste site estático — o próprio llmeu.com responde a páginas, não processa pedidos.
apps/api/src/inference.mjs:457 (o bloco de resposta llmeu), packages/router/src/engine.mjs:467 (a residência é aplicada antes da pontuação), packages/inference/src/mock.mjs:7 (MOCK_REGION = dev-mock), packages/shared/src/catalog-schema.mjs:64 (as classes encaminháveis)
Os prompts e as conclusões são guardados?
Não. Os corpos dos prompts e das conclusões não são escritos na base de dados. Cada chamada armazena metadados — modelo pedido e usado, versão, endpoint, região, classe de soberania, a razão do router, contagens de tokens, latência, custo, estado — e o prompt_stored da linha é 0. As duas colunas de corpo existem no esquema e são nulas. A aplicação é código, não prosa 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 escolhas; armazenar a escolha 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 a página de evidências mostra.
packages/shared/src/db/schema.sql:295 (prompt_stored e as duas colunas de corpo), 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)
Treinam com dados dos clientes?
Não — nada neste produto está em posição de o fazer. Não há caminho de código de treino ou ajuste fino 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 conjuntos de dados, nem armazenamento de corpus, nem trabalho de ajuste fino. Os corpos dos prompts e das conclusões não são escritos na base de dados, pelo que não há sequer um corpus armazenado para treinar. Isto é uma afirmação sobre o nosso código, não sobre os dados de treino a montante de cada modelo. Os modelos que foram treinados com dados de outras pessoas, ou que divulgam os seus dados de treino, são descritos nas suas próprias fichas, com fontes, e algumas dessas fichas dizem que os dados de treino não são publicados.
apps/api/src/inference.mjs (todo o caminho do pedido: orquestrar, medir, nunca persistir), packages/shared/src/db/schema.sql (nenhuma tabela de conjunto de dados ou corpus), packages/content/models.mjs:196 (uma ficha que diz que os dados de treino não são publicados)
O que acontece quando nenhum endpoint satisfaz a minha política de residência?
O pedido falha. Não é rebaixado para uma região próxima, e não é enviado para mais nenhum lado: 409 no_endpoint_for_policy, com a razão no corpo do erro e os endpoints excluídos nomeados no trace. A residência é aplicada antes da pontuação, e o failover só se move dentro do conjunto que o router já filtrou — e é 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 quanto a isso: nomear uma região ou classe que a sua política permita, alargar a política deliberadamente (uma decisão, com uma entrada no registo de alterações), 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 local que não permitiu.
packages/shared/src/errors.mjs:59 (no_endpoint_for_policy), packages/router/src/engine.mjs:370 (a falha, antes da pontuação), packages/router/src/engine.mjs:507 (o failover não pode sair do conjunto filtrado), apps/api/src/inference.mjs:137 (a retenção é verificada antes do encaminhamento)
Isto está em conformidade com o RGPD ou certificado?
Não fazemos essa afirmação, e não o faremos — nem "em conformidade com o AI Act", nem "certificado", nem "Oficial da UE". A LLM EU é uma empresa privada. Não é uma instituição da UE nem um organismo de avaliação da conformidade. "Verificado" neste site significa documentado, não legalmente certificado: é uma lista de verificação de divulgação, pontuada por se uma ficha indica a sua residência, fornecedor, versão, retenção, subcontratantes e licença, com ligações. O que podemos afirmar é o que o código faz, e onde estão as lacunas: retenção zero aplicada no código; chaves de API armazenadas como hashes scrypt com o segredo mostrado uma vez; cada consulta de cliente limitada por id de organização; limites de taxa por IP, por chave e por organização; corpos de pedido limitados e validados. O que não está feito: nenhum teste de intrusão independente; nenhuma auditoria de terceiros; a política de privacidade e os termos são resumos; o DPA é um modelo não revisto e não assinado; o inventário de subcontratantes está incompleto. A página de segurança e o índice legal listam essas lacunas nas suas próprias secções; esta resposta aponta para elas em vez de as parafrasear para algo mais suave.
docs/product/decisions.md:115 (ADR-006 — nenhum selo de conformidade, em nenhuma string), apps/web/server/pages/docs.mjs:537 (SECURITY_COPY: a lista de controlos e lacunas), apps/web/server/pages/docs.mjs:643 (LEGAL_READINESS: prontidão por documento)
A API é compatível com a OpenAI, e o que é que um cliente muda?
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 — pelo que os SDKs oficiais funcionam depois de os apontar para nós. Os campos extra no corpo são ignorados em vez de rejeitados, pelo que um SDK mais recente não pode quebrar uma rota mais antiga. O que é adicionado é 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 realmente alojado. O bloco llmeu pode ganhar campos; remover um seria uma alteração disruptiva e apareceria no registo de alterações.
docs/product/decisions.md:78 (ADR-004), apps/api/src/app.mjs:554 (a resposta que o cliente lê), apps/api/src/app.mjs:255 (501 em /v1/completions), apps/web/server/pages/docs.mjs:403 (o contrato de compatibilidade escrito)
O que acontece se não houver GPU?
O MockBackend responde, e di-lo na sua própria saída: a conclusão nomeia o modelo e a região, afirma que nenhum peso real foi executado, e diz como ativar a inferência própria (VLLM_BASE_URL, depois o flag gpu_enabled). A sua região é dev-mock, que não é um lugar, e numa chamada mock não há cobrança. GET /readyz reporta quais backends estão ativos, e a prontidão não é satisfeita por uma linha de endpoint que diz up — um runtime gerido deve reportar realmente saudável, porque o objetivo dessa sonda é apanhar um nó cujos pesos ainda estão a carregar. O registo de backends recusa substituir o mock por um endpoint cujo runtime seja vllm; em vez disso, lança uma exceção. O resumo honesto é desconfortável e vale a pena afirmá-lo claramente: esta implementação não tem GPU, pelo que uma chamada aqui é uma demonstração do pipeline, não uma execução de modelo. Um sucesso mock é um sucesso no fio; nunca é apresentado como uma execução real de modelo.
packages/inference/src/mock.mjs:49 (a resposta que nomeia o mock), apps/api/src/app.mjs:157 (a prontidão inclui backends geridos), docs/product/decisions.md:131 (ADR-007 — o registo recusa fingir um runtime de GPU)
O que significa uma ficha de modelo marcada como catalogue_only?
Significa que catalogamos o modelo e não o servimos. A ficha é informação de referência — fornecedor, licença, janela de contexto, onde o fornecedor diz que é executado, fontes para cada valor — e nenhum endpoint da LLM EU responde por ele. Peça-o à API e obtém 404 hosted_unavailable, com a nota "apenas catálogo — ainda não alojado na LLM EU"; uma página para ele não cita nenhum 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 próprios termos desse fornecedor, e a ficha 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.
packages/router/src/engine.mjs:325 (o router rejeita o tipo), apps/api/src/app.mjs:235 (404 hosted_unavailable com a nota), apps/web/server/pages/docs.mjs:446 (o preço ignora catalogue_only)
Como funcionam os preços e o crédito hoje?
Os preços são por milhão de tokens de entrada e saída, armazenados por endpoint e mostrados na página de preços e nas fichas de modelo, em EUR, derivados de uma taxa USD publicada; o livro razão armazena micros USD e escreve a taxa em cada linha, pelo que uma fatura passada pode ser reconstruída exatamente. Cada conclusão devolve cost_estimate_usd e cost_estimate_eur, e um trace regista o custo em ambos. Os limites de política — um limite por milhão e um limite diário — são verificados antes do encaminhamento, pelo que 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 do operador. A consola mostra o que foi gasto e o que resta. Se um flag stripe_enabled for ativado, o gestor de crédito aceita um montante publicado sem verificar que ocorreu um pagamento — e é por isso que o flag deve permanecer desligado até a verificação de pagamento ser implementada e testada, e por que o dizemos aqui em vez de oferecer um botão de checkout.
docs/product/decisions.md:148 (ADR-008 — micros armazenados, EUR exibidos), apps/api/src/inference.mjs:457 (estimativas de custo por pedido), apps/web/server/pages/docs.mjs:463 (a página de preços afirma que os pagamentos estão desligados), apps/web/server/pages/docs.mjs:559 (o gestor de crédito não verifica o pagamento)
Podemos alojar nós próprios?
Não através de nada que forneçamos hoje. Não há distribuição auto-alojada: nenhuma imagem de contentor, nenhum instalador, nenhuma licença on-premise, nenhum contrato de suporte para executar isto na sua própria infraestrutura, e este repositório não é oferecido como uma implementação suportada. A superfície de equipa da consola existe, mas os papéis da organização não são um controlo de acesso baseado em papéis completo, e isso está documentado em vez de ser implicitamente negado. O que o catálogo contém é uma classe de residência chamada on_prem_customer — "o modelo é executado dentro da 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 de investigação) estão nas fichas com uma ligação, para que possa avaliar executá-los você mesmo; isso é uma decisão sobre os pesos de outra pessoa e a licença de outra pessoa, não um produto de auto-alojamento da LLM EU. Para uma conversa on-premise, a página empresarial é a porta certa, e é honesto que o acordo ainda não existe.
packages/router/src/engine.mjs:12 (on_prem_customer aparece apenas em mapeamentos de residência), packages/shared/src/catalog-schema.mjs:84 (a sua definição), apps/web/server/pages/docs.mjs:517 (RBAC incompleto, declarado), packages/content/models.mjs:695 (uma licença de pesos abertos numa ficha)
Se uma resposta aqui estiver errada, é um defeito e tratamo-lo como tal. Quando o código e esta página discordam, o código vence — e a página de evidências, a página de segurança e o índice legal são os locais onde guardamos o resto do detalhe desconfortável em vez de o repetir dez vezes.
Perguntas que esta página não responde: mail@llmeu.com
Evidência e verificação · Segurança · Legal · Acessibilidade