Title: FAQ LLM: prompts, reten%C3%A7%C3%A3o e resid%C3%AAncia %E2%80%94 LLM EU Canonical: https://llmeu.com/pt/faq/ Markdown mirror: https://llmeu.com/pt/faq.md Machine-readable: https://llmeu.com/llms.txt (index) - https://llmeu.com/llms-full.txt (full catalogue) - https://llmeu.com/llms-catalogue.json # Perguntas frequentes A maioria das p%C3%A1ginas deste site faz uma afirma%C3%A7%C3%A3o. Esta responde a dez perguntas que um comprador normalmente tem de nos enviar por email para obter. Quando a resposta %C3%A9 %C2%ABainda n%C3%A3o%C2%BB, diz %C2%ABainda n%C3%A3o%C2%BB %E2%80%94 uma p%C3%A1gina que exagerasse valeria menos do que nenhuma p%C3%A1gina, porque todas as outras p%C3%A1ginas aqui s%C3%A3o escritas para serem verific%C3%A1veis. ## Onde s%C3%A3o processados os prompts e as conclus%C3%B5es? No endpoint que o router seleciona, que %C3%A9 uma regi%C3%A3o nomeada, e a resposta indica-lhe qual: o bloco llmeu em cada conclus%C3%A3o cont%C3%A9m inference_region, endpoint_id e sovereignty_class. Um valor de resid%C3%AAncia na sua pol%C3%ADtica restringe esse conjunto antes da sele%C3%A7%C3%A3o; %C3%A9 aplicado como filtro, n%C3%A3o como prefer%C3%AAncia, e catalogue_unknown nunca %C3%A9 encaminh%C3%A1vel. Dois limites a essa frase. Primeiro, as linhas de regi%C3%A3o s%C3%A3o dados de configura%C3%A7%C3%A3o, n%C3%A3o prova de m%C3%A1quinas em funcionamento ou de contratos de operador confirmados %E2%80%94 o documento de resid%C3%AAncia diz isto pelas suas pr%C3%B3prias palavras, e repetimo-lo aqui em vez de apenas ali. Segundo, nesta implementa%C3%A7%C3%A3o n%C3%A3o h%C3%A1 capacidade de GPU pr%C3%B3pria: os pedidos s%C3%A3o servidos pelos endpoints que o cat%C3%A1logo regista, e um modelo sem endpoint ativo %C3%A9 apenas de cat%C3%A1logo, pelo que um pedido para ele %C3%A9 recusado pelo nome em vez de ser respondido por um substituto. Ver %C2%ABO que acontece se n%C3%A3o houver GPU?%C2%BB abaixo. A API que faz isto %C3%A9 um processo Node, n%C3%A3o faz parte deste site est%C3%A1tico %E2%80%94 o pr%C3%B3prio llmeu.com responde a p%C3%A1ginas, n%C3%A3o processa pedidos. apps/api/src/inference.mjs:457 (o bloco de resposta llmeu), packages/router/src/engine.mjs:467 (a resid%C3%AAncia %C3%A9 aplicada antes da pontua%C3%A7%C3%A3o), packages/shared/src/catalog-schema.mjs:64 (as classes encaminh%C3%A1veis) ## Os prompts e as conclus%C3%B5es s%C3%A3o conservados? N%C3%A3o. Os corpos de prompt e completion n%C3%A3o s%C3%A3o gravados na base de dados. Cada chamada armazena metadados %E2%80%94 modelo solicitado e usado, vers%C3%A3o, endpoint, regi%C3%A3o, classe de soberania, o motivo do router, contagens de tokens, lat%C3%AAncia, custo, estado %E2%80%94 e o prompt_stored da linha %C3%A9 0. As duas colunas de corpo existem no schema e s%C3%A3o nulas. A aplica%C3%A7%C3%A3o %C3%A9 feita por c%C3%B3digo, n%C3%A3o por texto de pol%C3%ADtica: um pedido cuja reten%C3%A7%C3%A3o efetiva seja diferente de zero %C3%A9 recusado, com 403 retention_exceeds_policy se pedir mais do que a sua pol%C3%ADtica permite e 501 retention_not_implemented se for permitido mas n%C3%A3o implementado. As pol%C3%ADticas podem armazenar 24h, 7d ou 30d como op%C3%A7%C3%B5es; armazenar a op%C3%A7%C3%A3o n%C3%A3o permite armazenar o corpo. Se um trace alguma vez mostrar prompt_stored diferente de 0, essa %C3%A9 a resposta de uma p%C3%A1gina a "o que guardou" %E2%80%94 e pode verific%C3%A1-lo voc%C3%AA mesmo com jq, como mostra a p%C3%A1gina de evid%C3%AAncias. 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 de clientes? N%C3%A3o %E2%80%94 nada neste produto est%C3%A1 em posi%C3%A7%C3%A3o de o fazer. N%C3%A3o existe qualquer caminho de c%C3%B3digo 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%C3%A3o h%C3%A1 ingest%C3%A3o de datasets, nem armazenamento de corpus, nem tarefa de fine-tune. Os corpos de prompt e completion n%C3%A3o s%C3%A3o gravados na base de dados, por isso n%C3%A3o existe sequer um corpus armazenado para treinar. Isto %C3%A9 uma afirma%C3%A7%C3%A3o sobre o nosso c%C3%B3digo, n%C3%A3o 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%C3%A3o descritos nos seus pr%C3%B3prios cart%C3%B5es, com fontes, e alguns desses cart%C3%B5es dizem que os dados de treino n%C3%A3o s%C3%A3o publicados. apps/api/src/inference.mjs (todo o caminho do pedido: orquestrar, medir, nunca persistir), packages/shared/src/db/schema.sql (sem tabela de dataset ou corpus), packages/content/models.mjs:196 (um cart%C3%A3o que diz que os dados de treino n%C3%A3o s%C3%A3o publicados) ## O que acontece quando nenhum endpoint satisfaz a minha pol%C3%ADtica de resid%C3%AAncia? O pedido falha. N%C3%A3o %C3%A9 rebaixado para uma regi%C3%A3o pr%C3%B3xima, nem enviado para outro s%C3%ADtio: 409 no_endpoint_for_policy, com o motivo no corpo do erro e os endpoints exclu%C3%ADdos indicados no trace. A resid%C3%AAncia %C3%A9 aplicada antes da pontua%C3%A7%C3%A3o, e o failover s%C3%B3 se move dentro do conjunto que o router j%C3%A1 filtrou %E2%80%94 %C3%A9 por isso que uma nova tentativa n%C3%A3o pode escapar silenciosamente %C3%A0 regra que definiu. O c%C3%B3digo di-lo numa frase: "Nenhum endpoint satisfaz a resid%C3%AAncia {x}. A resid%C3%AAncia nunca %C3%A9 relaxada silenciosamente." O que fazer: indicar uma regi%C3%A3o ou classe que a sua pol%C3%ADtica permita, alargar a pol%C3%ADtica deliberadamente (uma decis%C3%A3o, com entrada no changelog), ou aceitar que n%C3%A3o existe rota para esse modelo sob essa regra. Um 409 %C3%A9 o produto a funcionar como concebido; o modo de falha que evita %C3%A9 um pedido que "teve sucesso" num s%C3%ADtio que n%C3%A3o permitiu. packages/shared/src/errors.mjs:59 (no_endpoint_for_policy), packages/router/src/engine.mjs:370 (a falha, antes da pontua%C3%A7%C3%A3o), packages/router/src/engine.mjs:507 (o failover n%C3%A3o pode sair do conjunto filtrado), apps/api/src/inference.mjs:137 (a reten%C3%A7%C3%A3o %C3%A9 verificada antes do routing) ## Isto est%C3%A1 conforme ao RGPD ou certificado? N%C3%A3o %E2%80%94 e n%C3%A3o vamos: nem "conforme ao AI Act", nem "certificado", nem "Oficial da UE". A LLM EU %C3%A9 uma empresa privada, n%C3%A3o uma institui%C3%A7%C3%A3o da UE e n%C3%A3o um organismo de avalia%C3%A7%C3%A3o da conformidade. "Verificado" aqui significa documentado, n%C3%A3o certificado juridicamente: uma lista de divulga%C3%A7%C3%A3o pontuada por o cart%C3%A3o indicar a sua resid%C3%AAncia, fornecedor, vers%C3%A3o, reten%C3%A7%C3%A3o, subcontratantes e licen%C3%A7a, com liga%C3%A7%C3%B5es. O que a plataforma faz %C3%A9 expresso em termos pelos quais o c%C3%B3digo pode ser responsabilizado: reten%C3%A7%C3%A3o zero aplicada, chaves de API armazenadas como hashes scrypt e mostradas uma vez, todas as consultas de clientes delimitadas por id de organiza%C3%A7%C3%A3o, limites de taxa por IP, por chave e por organiza%C3%A7%C3%A3o, corpos de pedido limitados e validados. O trabalho de seguran%C3%A7a e os documentos legais t%C3%AAm cada um a sua p%C3%A1gina. docs/product/decisions.md:115 (ADR-006 %E2%80%94 sem selo de conformidade, em qualquer 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%C3%A3o por documento) ## A API %C3%A9 compat%C3%ADvel com a OpenAI, e o que %C3%A9 que um cliente altera? O URL base, e nada mais. /v1/chat/completions aceita a forma oficial do pedido e devolve a forma oficial da resposta %E2%80%94 choices, usage, streaming como SSE %E2%80%94 por isso os SDKs oficiais funcionam depois de os apontar para n%C3%B3s. Campos extra no corpo s%C3%A3o ignorados em vez de rejeitados, para que um SDK mais recente n%C3%A3o quebre uma rota mais antiga. O que %C3%A9 acrescentado %C3%A9 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%C3%A3o 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. docs/product/decisions.md:78 (ADR-004), apps/api/src/app.mjs:554 (a resposta que o cliente l%C3%AA), 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%C3%A3o houver GPU? O router serve os endpoints ativos que o cat%C3%A1logo regista, e cada resposta nomeia o endpoint, a regi%C3%A3o e a classe de soberania que respondeu. Um modelo sem endpoint ativo %C3%A9 apenas de cat%C3%A1logo: um pedido para ele %C3%A9 recusado pelo nome em vez de ser respondido por um substituto. A capacidade pr%C3%B3pria precisa de um pool configurado (VLLM_BASE_URL, depois o flag gpu_enabled); at%C3%A9 existir, a capacidade %C3%A9 a que as linhas de endpoint registam, e as p%C3%A1ginas dizem qual %C3%A9. GET /readyz reporta quais backends est%C3%A3o up, e a prontid%C3%A3o n%C3%A3o %C3%A9 satisfeita por uma linha de endpoint que diga up %E2%80%94 um runtime gerido tem de reportar healthy, porque o objetivo dessa sonda %C3%A9 apanhar um n%C3%B3 cujos pesos ainda est%C3%A3o a carregar. O registo de backends recusa substituir um runtime por outro; em vez disso, lan%C3%A7a erro. O resumo honesto %C3%A9 desconfort%C3%A1vel e vale a pena diz%C3%AA-lo claramente: esta implementa%C3%A7%C3%A3o n%C3%A3o tem GPU, por isso uma chamada aqui %C3%A9 uma demonstra%C3%A7%C3%A3o do pipeline, n%C3%A3o uma execu%C3%A7%C3%A3o de modelo. Um sucesso de substituto seria um sucesso no fio e nada mais, raz%C3%A3o pela qual nunca %C3%A9 apresentado como uma execu%C3%A7%C3%A3o real de modelo. apps/api/src/app.mjs:157 (a prontid%C3%A3o inclui backends geridos), docs/product/decisions.md:131 (ADR-007 %E2%80%94 o registo recusa fingir um runtime de GPU) ## O que significa um cart%C3%A3o de modelo marcado como catalogue_only? Significa que catalogamos o modelo e n%C3%A3o o servimos. O cart%C3%A3o %C3%A9 informa%C3%A7%C3%A3o de refer%C3%AAncia %E2%80%94 fornecedor, licen%C3%A7a, janela de contexto, onde o fornecedor diz que corre, fontes para cada valor %E2%80%94 e nenhum endpoint da LLM EU responde por ele. Pe%C3%A7a-o %C3%A0 API e recebe 404 hosted_unavailable, com a nota "apenas de cat%C3%A1logo %E2%80%94 ainda n%C3%A3o alojado na LLM EU"; uma p%C3%A1gina para ele n%C3%A3o indica pre%C3%A7o, porque um pre%C3%A7o para algo que ningu%C3%A9m pode chamar %C3%A9 uma afirma%C3%A7%C3%A3o sem nada por tr%C3%A1s. Os pedidos para esse modelo v%C3%A3o diretamente para o seu fornecedor, sob os termos desse fornecedor, e o cart%C3%A3o do modelo diz exatamente isso. O selo oposto tamb%C3%A9m n%C3%A3o %C3%A9 uma promessa mais forte: um modelo que alojamos est%C3%A1 alojado numa regi%C3%A3o nomeada com uma classe de soberania nomeada, e essa %C3%A9 a afirma%C3%A7%C3%A3o que pode verificar no trace. Nenhum dos selos %C3%A9 uma declara%C3%A7%C3%A3o 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 (os pre%C3%A7os ignoram catalogue_only) ## Como funcionam hoje os pre%C3%A7os e o cr%C3%A9dito? Os pre%C3%A7os s%C3%A3o por milh%C3%A3o de tokens de entrada e sa%C3%ADda, armazenados por endpoint e apresentados na p%C3%A1gina de pre%C3%A7os e nos cart%C3%B5es de modelo, em EUR, derivados de uma %C3%BAnica taxa USD publicada; o ledger armazena micros USD e grava a taxa em cada linha, para que uma fatura passada possa ser reconstru%C3%ADda exatamente. Cada completion devolve cost_estimate_usd e cost_estimate_eur, e um trace regista o custo em ambos. Os limites de pol%C3%ADtica %E2%80%94 um teto por milh%C3%A3o e um teto di%C3%A1rio %E2%80%94 s%C3%A3o verificados antes do routing, por isso um pedido acima do or%C3%A7amento %C3%A9 recusado em vez de executado. Os pagamentos com cart%C3%A3o n%C3%A3o est%C3%A3o ativados nesta implementa%C3%A7%C3%A3o, e nada adiciona cr%C3%A9dito automaticamente: ainda n%C3%A3o h%C3%A1 execu%C3%A7%C3%A3o de faturas nem caminho de cr%C3%A9dito de operador. A consola mostra o que foi gasto e o que resta. Se um flag stripe_enabled for ativado, o handler de cr%C3%A9dito aceita um montante submetido sem verificar que ocorreu um pagamento %E2%80%94 %C3%A9 por isso que o flag tem de permanecer desligado at%C3%A9 a verifica%C3%A7%C3%A3o de pagamento estar implementada e testada, e por isso o dizemos aqui em vez de oferecer um bot%C3%A3o de checkout. docs/product/decisions.md:148 (ADR-008 %E2%80%94 micros armazenados, EUR apresentados), apps/api/src/inference.mjs:457 (estimativas de custo por pedido), apps/web/server/pages/docs.mjs:463 (a p%C3%A1gina de pre%C3%A7os indica que os pagamentos est%C3%A3o desativados), apps/web/server/pages/docs.mjs:559 (o handler de cr%C3%A9dito n%C3%A3o verifica o pagamento) ## Podemos fazer self-hosting? N%C3%A3o atrav%C3%A9s de nada que entreguemos hoje. N%C3%A3o existe distribui%C3%A7%C3%A3o self-hosted: nem imagem de contentor, nem instalador, nem licen%C3%A7a on-premise, nem contrato de suporte para executar isto no seu pr%C3%B3prio ambiente, e este reposit%C3%B3rio n%C3%A3o %C3%A9 oferecido como uma implementa%C3%A7%C3%A3o suportada. A superf%C3%ADcie de equipa da consola existe, mas as roles de organiza%C3%A7%C3%A3o n%C3%A3o s%C3%A3o um controlo de acesso baseado em fun%C3%A7%C3%B5es completo, e isso est%C3%A1 documentado em vez de ser subentendido. O que o cat%C3%A1logo tem %C3%A9 uma classe de resid%C3%AAncia chamada on_prem_customer %E2%80%94 "o modelo corre em infraestrutura controlada pelo cliente" %E2%80%94 e %C3%A9 uma classifica%C3%A7%C3%A3o da propriedade e opera%C3%A7%C3%A3o de um endpoint, n%C3%A3o uma oferta nossa. Muitos dos modelos no cat%C3%A1logo publicam pesos abertos, e as suas licen%C3%A7as (algumas n%C3%A3o comerciais, algumas apenas para investiga%C3%A7%C3%A3o) est%C3%A3o nos cart%C3%B5es com uma liga%C3%A7%C3%A3o, para que possa avaliar execut%C3%A1-los voc%C3%AA mesmo; isso %C3%A9 uma decis%C3%A3o sobre pesos de outra pessoa e licen%C3%A7a de outra pessoa, n%C3%A3o um produto de self-hosting da LLM EU. Para uma conversa sobre on-premise, a p%C3%A1gina enterprise %C3%A9 a porta certa, e %C3%A9 honesto que o acordo ainda n%C3%A3o existe. packages/router/src/engine.mjs:12 (on_prem_customer aparece apenas em mapeamentos de resid%C3%AAncia), packages/shared/src/catalog-schema.mjs:84 (a sua defini%C3%A7%C3%A3o), apps/web/server/pages/docs.mjs:517 (RBAC incompleto, declarado), packages/content/models.mjs:695 (uma licen%C3%A7a de pesos abertos num cart%C3%A3o) Se uma resposta aqui estiver errada, %C3%A9 um defeito e tratamo-la como tal. Quando o c%C3%B3digo e esta p%C3%A1gina discordarem, o c%C3%B3digo prevalece %E2%80%94 e a p%C3%A1gina de evid%C3%AAncias, a p%C3%A1gina de seguran%C3%A7a e o %C3%ADndice legal s%C3%A3o os locais onde guardamos o resto dos detalhes inc%C3%B3modos em vez de os repetirmos dez vezes. Perguntas a que esta p%C3%A1gina n%C3%A3o responde: [mail@llmeu.com](mailto:mail@llmeu.com) [Evid%C3%AAncia e verifica%C3%A7%C3%A3o](/pt/docs/evidence/) %C2%B7[Seguran%C3%A7a](/pt/security/) %C2%B7[Jur%C3%ADdico](/pt/legal/) %C2%B7[Acessibilidade](/pt/accessibility/)