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 proveedor tiene un ajuste de Máximo de llamadas concurrentes por clave (su anulación del límite de tasa). Limita cuántas llamadas al LLM ejecuta en paralelo una sola clave de API, abarcando todos los flujos que usan la clave: el reparto del enriquecimiento multiespecialización, la clasificación, el arbitraje y la generación de esquemas/muestras.
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 → Valores predeterminados. Si hay uno definido para la tarea en cuestión, 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 o comprobaciones de estado | Sí (mediante sincronización de precios o validación) |
| 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.