Gestione proveedores y modelos de LLM, sincronice modelos desde registros externos, ejecute comprobaciones de estado y configure claves de API por organización para una facturación independiente.
Entity Enricher admite una amplia gama de proveedores de LLM. Cada proveedor puede tener varios modelos con precios, capacidades y configuración individuales.
Muchos equipos enrutan el tráfico de LLM a través de una pasarela de IA corporativa, un endpoint regional o un provider que no está integrado; por ejemplo, un proxy LiteLLM empresarial, Cloudflare AI Gateway o Alibaba DashScope (para modelos Qwen). Estos se añaden como su propio provider Standard (compatible con OpenAI) con una URL base personalizada.
acme-openai-gw). Los nombres integrados como openai o anthropic están reservados. https://gateway.example.com/v1. Este campo es obligatorio para cualquier proveedor para el que Entity Enricher no tenga un cliente integrado. https:// públicas. Los rangos de loopback y privados (localhost, 10.x, 192.168.x) se rechazan para evitar el SSRF: un servidor autoalojado debe ser accesible por internet. Para un Ollama local, utilice en su lugar el túnel dedicado de Ollama./v1 de OpenAI (chat completions, /models). {endpoint}/models para verificar la clave y la URL base antes de ejecutar un enriquecimiento.Cada llamada realizada con una clave API se regula según el presupuesto que el proveedor concede a esa clave — solicitudes y tokens por minuto, por modelo —, de modo que una ejecución en paralelo nunca provoque errores 429. El presupuesto no se escribe a mano: se lee de las propias cabeceras de respuesta del proveedor, se aprende a partir de un rechazo cuando el proveedor no indica nada o, como último recurso, lo escribe un propietario.
Esto es independiente del límite de trabajos concurrentes máximos de su plan, que limita cuántos trabajos de enriquecimiento ejecuta toda su organización a la vez en todos los proveedores.
Cada modelo registra sus capacidades, que se muestran como iconos en el selector de modelos:
| Capacidad | Descripción |
|---|---|
| Visión | Puede procesar imágenes y entradas visuales |
| Llamadas a herramientas | Admite llamadas a funciones / uso de herramientas |
| Entrada de audio | Puede procesar entradas de audio |
| Entrada de PDF | Puede procesar documentos PDF |
| Almacenamiento en caché de prompts | Admite almacenamiento en caché de prompts para reducir costes |
| Razonamiento | Capacidades de pensamiento extendido / cadena de razonamiento |
| Embeddings | Convierte el texto en un vector en lugar de responder: es con lo que se resuelven los ID semánticos. Los modelos de embedding forman su propia familia, con su propio tamaño de vector, y nunca aparecen en un selector de enriquecimiento |
Indicar un modelo es opcional. El enriquecimiento, la generación de esquemas y la generación de muestras aceptan auto —y tratan un modelo omitido como auto—, que se resuelve en el servidor, por tarea, en el momento en que arranca el trabajo. La ejecución informa de qué modelo eligió, así que automático nunca significa opaco.
Los propietarios pueden fijar un modelo preferido por tarea en Configuración → Organización → Selección de modelo. Si hay uno definido para la tarea en curso, prevalece.
A falta de un modelo fijado, se elige el modelo con la mejor puntuación combinada de sus benchmarks de fuentes de puntuación: sus propias mediciones de calidad, velocidad y coste sobre sus propios esquemas. Si no hay ninguna fuente de puntuación, la solicitud se rechaza en lugar de hacer suposiciones.
Activar la búsqueda web, o adjuntar un documento que deba enviarse tal cual, restringe los candidatos a los modelos capaces de hacerlo; y si ninguno cumple, obtiene un error explícito en lugar de una degradación silenciosa.
También se puede vetar un modelo en una sola tarea sin desactivarlo: un modelo que enriquece bien pero genera esquemas deficientes puede ocultarse únicamente en los selectores de generación de esquemas y de muestras, ya sea para su organización o de forma global por un administrador. Sigue plenamente disponible en todo lo demás: un instrumento más suave que la desactivación descrita a continuación.
Mantenga actualizados los precios de los modelos sincronizándolos desde registros externos. El proceso de sincronización detecta automáticamente los modelos nuevos, los cambios de precio y los modelos eliminados.
La fuente de precios predeterminada. Obtiene los datos del registro comunitario de LiteLLM en GitHub, con nombres reales de modelos de API, precios, longitudes de contexto y capacidades.
Cubre ~30 proveedores. No incluye nombres para mostrar, benchmarks ni velocidad de generación.
Una fuente alternativa de pricepertoken.com. Incluye nombres visibles, benchmarks (puntuaciones de programación y matemáticas) y velocidad de generación (tokens por segundo).
Cubre ~20 proveedores. Proporciona metadatos más completos que LiteLLM.
Un catálogo oficial autenticado de identificadores de modelos GLM, con precios extraídos directamente de la documentación de Z.AI y las carencias de capacidades investigadas allí mismo.
Reemplaza las entradas de Z.AI importadas anteriormente desde LiteLLM y PricePerToken.
Valide de forma proactiva si los modelos son accesibles ejecutando un prompt mínimo de comprobación de estado. Esto detecta los modelos defectuosos antes de que los usuarios encuentren errores durante el enriquecimiento.
Las comprobaciones de estado pueden ejecutarse en todos los models, en los models de un provider específico o en un solo model. Los resultados se transmiten en tiempo real mediante SSE con una barra de progreso que muestra el recuento de aciertos y fallos.
Cuando una llamada de enriquecimiento falla con un error de «modelo no encontrado», el modelo se desactiva automáticamente para evitar fallos repetidos. Esto sucede en tiempo real durante las operaciones normales de enriquecimiento.
| Motivo de desactivación | Establecido por | ¿Reactivado automáticamente? |
|---|---|---|
| Modelo no encontrado | Errores de enriquecimiento, comprobaciones de estado o un sondeo de capacidades al que no responde ninguna ruta | Sí (mediante sincronización de precios o validación) |
| Sin salida estructurada | Sondeo de capacidades: ni la herramienta ni el canal nativo en ninguna ruta accesible | Sí, solo mediante un sondeo de capacidades posterior |
| Sincronización eliminada | Sincronización de precios (el modelo desapareció) | Sí (si el modelo reaparece en el registro) |
| Manual | Conmutador de administrador en la interfaz | No (solo reactivación manual) |
Las organizaciones pueden configurar sus propias claves de API de proveedores de LLM para facturación y seguimiento de uso independientes. El sistema utiliza una resolución de claves de dos niveles con selección LRU:
Claves por organización configuradas en la página de Claves de API. Admite varias claves por proveedor con rotación LRU. Cifradas con Fernet.
Claves para todo el sistema gestionadas por los administradores. Compartidas entre todas las organizaciones. También admite varias claves por proveedor con rotación LRU.
Cada enriquecimiento registra qué clave se utilizó, de modo que puede hacer un seguimiento de los costes por clave. Las claves admiten comprobaciones de estado y contadores de uso. Dentro de un grupo, la siguiente clave elegida es la clave habilitada con la marca de tiempo de último uso más antigua; una clave solo sale de la rotación cuando usted la deshabilita manualmente, por lo que un error del proveedor nunca retira en silencio una clave del servicio. Aprenda a gestionar las claves en la guía Claves de API.
Exporte toda la configuración de proveedores y modelos como JSON para hacer una copia de seguridad o transferirla a otra instancia. La importación siempre es una operación de upsert: los proveedores y modelos existentes se identifican por nombre y se actualizan en su lugar, mientras que los nuevos se agregan; no se elimina nada.
La exportación incluye los ajustes del proveedor, las configuraciones de modelos, los precios, las capacidades y las especificaciones canónicas de los modelos, pero nunca las claves de API, que se almacenan por separado. Tras importar, configure las claves de API por separado. Los administradores del sistema respaldan el catálogo global completo; los propietarios de la organización exportan e importan únicamente los proveedores y modelos de su propia organización: el catálogo global compartido no se puede crear ni editar mediante importación.
La página de modelos presenta el catálogo global a cualquier persona: precios del proveedor, capacidades medidas y las puntuaciones que cada modelo obtuvo en los escenarios de benchmark publicados como fuentes de puntuación globales. Lee dos archivos JSON estáticos que reescribe la actualización nocturna de modelos y que usted puede descargar y reutilizar. Los modelos que el proveedor ya no ofrece (desactivados como «modelo no encontrado») quedan fuera; el resto de modelos del catálogo aparece en la lista.
/data/models.json — la tabla: una entrada por proveedor × modelo, con tablas de referencia para proveedores, escenarios y especificaciones./data/benchmarks.json — todos los resultados de benchmark públicos, agrupados por clave de modelo.Ambos se sirven con un ETag y una caché pública de una hora, codificados en gzip cuando el cliente lo acepta. El campo version se incrementa ante cualquier cambio al que un consumidor deba adaptarse.
generated_at, counts, default_weightsCuándo se escribió el archivo, cuántos modelos, proveedores y escenarios contiene, y la combinación de calidad / velocidad / coste (en porcentaje) detrás de cada puntuación global.providers[], scenarios[], specs{}Tablas de consulta: los modelos hacen referencia a un proveedor y a los escenarios por índice; specs son las puntuaciones públicas de benchmark de los pesos (inteligencia, código, matemáticas y el resto en extra), indexadas por clave canónica para que los revendedores de un mismo modelo las compartan.models[].key, model, display_name, canonical_keyLa clave compuesta que acepta la API (provider::model), el id del modelo sin procesar, su etiqueta y la identidad entre proveedores.models[].pricingPrecios de lista del proveedor en USD por millón de tokens: input, output, cache_read, cache_write, cache_write_1h, reasoning_output, más web_search_per_query con su unidad. Antes de cualquier comisión del plan.models[].capabilities[]Los flags vigentes: vision, pdf_input, audio_input, audio_output, video_input, tool_calls, tool_choice, response_schema, strict_structured_output, reasoning, reasoning_effort, web_search, prompt_caching, embeddings, requires_streaming. Un flag ausente es false o no medido.models[].context_length, max_input_tokens, max_output_tokens, deprecation_date, latencyLímites, la fecha de retirada del fabricante cuando se ha anunciado y las cifras de latencia recopiladas (tokens por segundo, tiempo hasta el primer token).models[].enrichment_capable, disabled_tasks[]Si el modelo dispone siquiera de un canal de salida estructurada y las tareas para las que la aplicación nunca lo ofrece (la clasificación y el arbitraje requieren llamadas a herramientas; la generación de esquemas y de muestras se rige por la condición de generación de esquemas).models[].scores{task}Por tipo de tarea (enrichment, schema_generation, sample_generation): la media de calidad, velocidad y coste sobre los escenarios públicos de esa tarea, la puntuación global con los pesos predeterminados y los índices de los escenarios. La velocidad y el coste son relativos a los demás modelos del mismo escenario.El cálculo de las puntuaciones de calidad, velocidad y coste se explica en Puntuación de benchmarks.