Preguntas frecuentes
Casi todas las páginas de este sitio afirman algo. Esta responde a diez preguntas que un comprador normalmente tiene que enviarnos por correo para obtener. Cuando la respuesta es "todavía no", dice "todavía no": una página que exagerara valdría menos que ninguna página, porque todas las demás páginas de aquí están escritas para poder ser comprobadas.
¿Dónde se procesan los prompts y las respuestas?
En el endpoint que selecciona el router, que es una región con nombre, y la respuesta te dice cuál: el bloque llmeu de cada respuesta incluye inference_region, endpoint_id y sovereignty_class. Un valor de residencia en tu política restringe ese conjunto antes de la selección; se aplica como filtro, no como preferencia, y catalogue_unknown nunca es enrutable. Dos límites a esa frase. Primero, las filas de región son datos de configuración, no prueba de máquinas en funcionamiento ni de contratos de operador confirmados; el documento de residencia lo dice con sus propias palabras, y lo repetimos aquí en lugar de solo allí. Segundo, en este despliegue no hay GPU: el backend por defecto es el mock, cuya región es dev-mock, y el mock no representa un lugar. Consulta "¿Qué ocurre si no hay GPU?" más abajo. La API que hace esto es un proceso Node, no forma parte de este sitio estático: llmeu.com sirve páginas, no procesa solicitudes.
apps/api/src/inference.mjs:457 (el bloque de respuesta llmeu), packages/router/src/engine.mjs:467 (la residencia se aplica antes de la puntuación), packages/inference/src/mock.mjs:7 (MOCK_REGION = dev-mock), packages/shared/src/catalog-schema.mjs:64 (las clases enrutables)
¿Se conservan los prompts y las respuestas?
No. Los cuerpos de los prompts y las respuestas no se escriben en la base de datos. Cada llamada almacena metadatos —modelo solicitado y utilizado, versión, endpoint, región, clase de soberanía, el motivo del router, recuentos de tokens, latencia, coste, estado— y el prompt_stored de la fila es 0. Las dos columnas de cuerpo existen en el esquema y son nulas. La aplicación efectiva es código, no prosa de política: se rechaza toda solicitud cuya retención efectiva sea distinta de cero, con 403 retention_exceeds_policy si pide más de lo que permite tu política, y 501 retention_not_implemented si está permitida pero no implementada. Las políticas pueden almacenar 24h, 7d o 30d como opciones; almacenar la opción no habilita el almacenamiento del cuerpo. Si alguna vez una traza muestra prompt_stored distinto de 0, esa es la respuesta de una página a "qué conservasteis", y puedes comprobarlo tú mismo con jq, como muestra la página de evidencia.
packages/shared/src/db/schema.sql:295 (prompt_stored y las dos columnas de cuerpo), 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)
¿Entrenáis con datos de clientes?
No — nada en este producto está en condiciones de hacerlo. No hay ninguna ruta de código de entrenamiento ni de ajuste fino en la API, el proceso web, el router ni los paquetes compartidos. La API orquesta una solicitud a un backend y la mide; no hay ingesta de conjuntos de datos, ni almacén de corpus, ni trabajo de ajuste fino. Los cuerpos de los prompts y las respuestas no se escriben en la base de datos, así que ni siquiera hay un corpus almacenado con el que entrenar. Eso es una afirmación sobre nuestro código, no sobre los datos de entrenamiento anteriores de cada modelo. Los modelos que se entrenaron con datos de otras personas, o que divulgan sus datos de entrenamiento, se describen en sus propias fichas, con fuentes, y algunas de esas fichas indican que los datos de entrenamiento no se publican.
apps/api/src/inference.mjs (toda la ruta de la solicitud: orquestar, medir, nunca persistir), packages/shared/src/db/schema.sql (ninguna tabla de conjuntos de datos ni de corpus), packages/content/models.mjs:196 (una ficha que indica que los datos de entrenamiento no se publican)
¿Qué ocurre cuando ningún endpoint satisface mi política de residencia?
La solicitud falla. No se degrada a una región cercana ni se envía a ningún otro sitio: 409 no_endpoint_for_policy, con el motivo en el cuerpo del error y los endpoints excluidos nombrados en la traza. La residencia se aplica antes de la puntuación, y el failover solo se mueve dentro del conjunto que el router ya filtró, que es por lo que un reintento no puede escapar en silencio de la regla que fijaste. El código lo dice en una frase: "No endpoint satisfies residency {x}. Residency is never relaxed silently." Qué hacer al respecto: indica una región o clase que tu política sí permita, amplía la política de forma deliberada (una decisión, con una entrada en el registro de cambios) o acepta que no existe ruta para ese modelo bajo esa regla. Un 409 es el producto funcionando tal como se ha diseñado; el modo de fallo que evita es una solicitud que "tuvo éxito" en un lugar que no permitías.
packages/shared/src/errors.mjs:59 (no_endpoint_for_policy), packages/router/src/engine.mjs:370 (el fallo, antes de la puntuación), packages/router/src/engine.mjs:507 (el failover no puede salir del conjunto filtrado), apps/api/src/inference.mjs:137 (la retención se comprueba antes del enrutamiento)
¿Cumple esto el RGPD o está certificado?
No hacemos esa afirmación, y no la vamos a hacer: ni "conforme al Reglamento de IA", ni "certificado", ni "Official EU". LLM EU es una empresa privada. No es una institución de la UE ni un organismo de evaluación de la conformidad. "Verificado" en este sitio significa documentado, no certificado legalmente: es una lista de comprobación de divulgación, puntuada según si una ficha indica su residencia, proveedor, versión, retención, subencargados y licencia, con enlaces. Lo que sí podemos afirmar es lo que hace el código y dónde están las carencias: retención cero aplicada en código; claves de API almacenadas como hashes scrypt con el secreto mostrado una sola vez; cada consulta de cliente acotada por el id de organización; límites de tasa por IP, por clave y por organización; cuerpos de solicitud limitados y validados. Lo que no está hecho: ninguna prueba de penetración independiente; ninguna auditoría de terceros; la política de privacidad y los términos son resúmenes; el DPA es una plantilla sin revisar y sin firmar; el inventario de subencargados está incompleto. La página de seguridad y el índice legal enumeran esas carencias en sus propias secciones; esta respuesta remite a ellas en lugar de parafrasearlas en algo más suave.
docs/product/decisions.md:115 (ADR-006 — ningún sello de conformidad, en ninguna cadena), apps/web/server/pages/docs.mjs:537 (SECURITY_COPY: la lista de controles y carencias), apps/web/server/pages/docs.mjs:643 (LEGAL_READINESS: preparación por documento)
¿Es la API compatible con OpenAI, y qué tiene que cambiar un cliente?
La URL base, y nada más. /v1/chat/completions acepta la forma de solicitud oficial y devuelve la forma de respuesta oficial —choices, usage, streaming como SSE—, así que los SDK oficiales funcionan después de apuntarlos hacia nosotros. Los campos adicionales del cuerpo se ignoran en lugar de rechazarse, de modo que un SDK más nuevo no puede romper una ruta más antigua. Lo que se añade es opcional y aditivo: un objeto llmeu con espacio de nombres propio en la solicitud (residency, task, retention, data_class, policy_id, max_usd_per_1m, allow_partners) y un bloque llmeu en la respuesta con trace_id, model_used, model_version, provider, endpoint_id, inference_region, sovereignty_class, route_reason, policy_id, retention y estimaciones de coste. No se ofrece, deliberadamente: /v1/completions (501), n > 1 (400), embeddings salvo que haya realmente un modelo de embeddings alojado. El bloque llmeu puede ganar campos; eliminar uno sería un cambio incompatible y aparecería en el registro de cambios.
docs/product/decisions.md:78 (ADR-004), apps/api/src/app.mjs:554 (la respuesta que lee el cliente), apps/api/src/app.mjs:255 (501 en /v1/completions), apps/web/server/pages/docs.mjs:403 (el contrato de compatibilidad escrito)
¿Qué ocurre si no hay GPU?
Responde el MockBackend, y lo dice en su propia salida: la respuesta nombra el modelo y la región, indica que no se ejecutaron pesos reales y explica cómo activar la inferencia propia (VLLM_BASE_URL, y luego el flag gpu_enabled). Su región es dev-mock, que no es un lugar, y en una llamada al mock no hay cargo alguno. GET /readyz informa de qué backends están activos, y la preparación no se satisface con una fila de endpoint que diga up: un runtime gestionado debe informar realmente de que está sano, porque el objetivo de esa sonda es precisamente detectar un nodo cuyos pesos aún se están cargando. El registro de backends se niega a sustituir el mock por un endpoint cuyo runtime sea vllm; en su lugar lanza un error. El resumen honesto es incómodo y merece decirse con claridad: este despliegue no tiene GPU, así que una llamada aquí es una demostración del pipeline, no una ejecución de un modelo. Un éxito del mock es un éxito en la conexión; nunca se presenta como una ejecución real de un modelo.
packages/inference/src/mock.mjs:49 (la respuesta que nombra el mock), apps/api/src/app.mjs:157 (la preparación incluye backends gestionados), docs/product/decisions.md:131 (ADR-007 — el registro se niega a simular un runtime de GPU)
¿Qué significa una ficha de modelo marcada como catalogue_only?
Significa que catalogamos el modelo y no lo servimos. La ficha es información de referencia —proveedor, licencia, ventana de contexto, dónde dice el proveedor que se ejecuta, fuentes para cada dato— y ningún endpoint de LLM EU responde por él. Si pides ese modelo a la API, obtienes 404 hosted_unavailable, con la nota "catalogue only — not hosted on LLM EU yet"; una página sobre él no cita ningún precio, porque un precio para algo que nadie puede llamar es una afirmación sin nada detrás. Las solicitudes a ese modelo van directamente a su proveedor, bajo los términos de ese proveedor, y la ficha del modelo dice exactamente eso. La insignia opuesta tampoco es una promesa más fuerte: un modelo que alojamos está alojado en una región con nombre con una clase de soberanía con nombre, y esa es la afirmación que puedes comprobar en la traza. Ninguna de las dos insignias es una declaración de conformidad.
packages/router/src/engine.mjs:325 (el router rechaza el tipo), apps/api/src/app.mjs:235 (404 hosted_unavailable con la nota), apps/web/server/pages/docs.mjs:446 (los precios omiten catalogue_only)
¿Cómo funcionan hoy los precios y el crédito?
Los precios son por millón de tokens de entrada y de salida, se almacenan por endpoint y se muestran en la página de precios y en las fichas de modelo, en EUR, derivados de una única tasa publicada en USD; el libro mayor en sí almacena micros de USD y escribe la tasa en cada fila, de modo que una factura pasada puede reconstruirse con exactitud. Cada respuesta devuelve cost_estimate_usd y cost_estimate_eur, y una traza registra el coste en ambas monedas. Los límites de política —un tope por millón y un tope diario— se comprueban antes del enrutamiento, así que una solicitud que supera el presupuesto se rechaza en lugar de ejecutarse. Los pagos con tarjeta no están habilitados en este despliegue, y nada añade crédito automáticamente: todavía no hay ejecución de facturas ni vía de crédito de operador. La consola muestra lo gastado y lo que queda. Si se activa el flag stripe_enabled, el gestor de crédito acepta un importe enviado sin verificar que se haya producido un pago, y por eso el flag debe permanecer desactivado hasta que la verificación de pagos esté implementada y probada, y por eso lo decimos aquí en lugar de ofrecer un botón de pago.
docs/product/decisions.md:148 (ADR-008 — se almacenan micros, se muestra EUR), apps/api/src/inference.mjs:457 (estimaciones de coste por solicitud), apps/web/server/pages/docs.mjs:463 (la página de precios indica que los pagos están desactivados), apps/web/server/pages/docs.mjs:559 (el gestor de crédito no verifica el pago)
¿Podemos autoalojarlo?
No con nada de lo que publicamos hoy. No hay distribución autoalojada: ni imagen de contenedor, ni instalador, ni licencia on-premise, ni contrato de soporte para ejecutar esto en tus propias instalaciones, y este repositorio no se ofrece como despliegue compatible. La superficie de equipo de la consola existe, pero los roles de organización no son un control de acceso basado en roles completo, y eso está documentado en lugar de darse por supuesto. Lo que sí tiene el catálogo es una clase de residencia llamada on_prem_customer —"the model runs inside infrastructure the customer controls"—, y es una clasificación de la titularidad y la operación de un endpoint, no una oferta nuestra. Muchos de los modelos del catálogo publican pesos abiertos, y sus licencias (algunas no comerciales, algunas solo para investigación) están en las fichas con un enlace, para que puedas evaluar ejecutarlos tú mismo; esa es una decisión sobre los pesos de otro y la licencia de otro, no un producto de autoalojamiento de LLM EU. Para una conversación sobre on-premise, la página de empresas es la puerta adecuada, y es honesto decir que el acuerdo todavía no existe.
packages/router/src/engine.mjs:12 (on_prem_customer solo aparece en las asignaciones de residencia), packages/shared/src/catalog-schema.mjs:84 (su definición), apps/web/server/pages/docs.mjs:517 (RBAC incompleto, declarado), packages/content/models.mjs:695 (una licencia de pesos abiertos en una ficha)
Si una respuesta de aquí es incorrecta, es un defecto y lo tratamos como tal. Cuando el código y esta página discrepan, gana el código, y la página de evidencia, la página de seguridad y el índice legal son los lugares donde guardamos el resto del detalle incómodo en lugar de repetirlo diez veces.
Preguntas que esta página no responde: mail@llmeu.com
Evidencia y verificación · Seguridad · Legal · Accesibilidad