Model and Modality Playbooks14 de septiembre de 2026Flatkey Team

Guía del catálogo de modelos de IA: cómo leer proveedores, endpoints, grupos y precios

Usa esta guía del catálogo de modelos de IA para interpretar proveedores, endpoints, grupos, disponibilidad, unidades de precio y evidencia de uso antes del enrutamiento en producción.

Guía del catálogo de modelos de IA: cómo leer proveedores, endpoints, grupos y precios

Actualizado: 14 de septiembre de 2026

Una Guía del catálogo de modelos de IA: cómo leer proveedores, endpoints, grupos y precios es útil porque los catálogos de modelos ahora hacen más que listar nombres. Un catálogo de producción es una superficie de enrutamiento. Indica a producto, ingeniería y finanzas qué proveedor posee la ruta, qué forma de API está admitida, qué grupo o plan puede usarla, qué unidad se factura y si el modelo está lo bastante sano para tráfico real.

El error costoso es leer un catálogo como si fuera una clasificación. Una fila con el nombre de un modelo famoso aún puede ser incorrecta para tu carga de trabajo si la forma del endpoint no coincide con tu SDK, la unidad de facturación no es comparable, la ruta está limitada a un grupo que no utilizas o el estado de disponibilidad no está listo para producción.

Esta guía de catálogo de modelos de IA ofrece a los equipos de producto una forma práctica de leer un catálogo de modelos antes de seleccionar, probar o enrutar tráfico a través de cualquier API gateway de IA. Usa el directorio público de modelos de Flatkey y su documentación como ejemplo de trabajo, pero la lista de verificación se aplica a catálogos directos de proveedores, catálogos de gateways y catálogos internos de plataformas.

Respuesta rápida: cómo leer un catálogo de modelos de IA

Lee un catálogo de modelos de IA en este orden:

  1. Proveedor: quién opera el modelo o la ruta upstream.
  2. ID del modelo: la cadena exacta que tu aplicación debe enviar.
  3. Compatibilidad de endpoint: qué forma de API acepta la ruta, como chat compatible con OpenAI, Responses, Anthropic, Gemini, imágenes, video, embeddings o una ruta nativa.
  4. Grupo o plan: qué grupo de cuenta, grupo de rutas, grupo de cuota o plan de facturación puede usar la fila.
  5. Estado de disponibilidad: si la ruta está activa, degradada, desconocida, en vista previa, acceso anticipado, obsoleta o próximamente disponible.
  6. Unidad de precio: si la facturación es por 1M de tokens de entrada/salida, tokens almacenados en caché, imagen, segundo, solicitud, carácter, minuto u otra unidad.
  7. Evidencia de uso: si tu solicitud de prueba aparece en los registros con el modelo esperado, el estado, los recuentos de tokens, la ruta, la clave y el costo.

La respuesta corta en esta Guía del catálogo de modelos de IA: cómo leer proveedores, endpoints, grupos y precios es: no elijas un modelo solo por la columna de precio. Elígelo después de que el proveedor, el endpoint, el grupo, el estado, la unidad de precio y la evidencia del registro de uso coincidan con tu carga de trabajo.

Instantánea actual del catálogo de modelos de Flatkey

La documentación actual de Flatkey describe una URL base compatible con OpenAI, https://router.flatkey.ai/v1, además de endpoints de API para completaciones de chat, Responses, embeddings, generación de imágenes, tareas de video y listado de modelos. El endpoint /v1/models devuelve ID de modelos y proveedores en un formato compatible con OpenAI, mientras que el Directorio de modelos público es el lugar en vivo para inspeccionar precios, estado de salud, compatibilidad de endpoints y páginas de detalle de modelos.

El 14 de septiembre de 2026, el directorio público de modelos de Flatkey exponía campos de fila que son directamente relevantes para la revisión del catálogo:

Campo del catálogo Qué te indica Valores de ejemplo observados en el directorio público
model_name La cadena o fila de modelo que necesitas probar. gpt-5.6-sol, deepseek-v4-pro, seedance-2.5, gemini-3-flash-preview, claude-sonnet-5
vendor_name El proveedor o propietario del catálogo detrás de la ruta. OpenAI, DeepSeek, ByteDance, Google, Anthropic, catálogo Flatkey
supported_endpoint_types Qué formato de solicitud puede aceptar el modelo. openai, openai-response, anthropic, gemini, openai-video, video
availability_status Si la ruta parece actualmente utilizable. available, unknown_failure
display_pricing.billing_kind La familia de unidades de precio. token, per_second, request
enable_groups / group pricing Qué ruta o grupo comercial puede llamar a la fila y cómo se ajusta su precio. Entradas de rutas agrupadas como plg en los datos de la página pública

Toma esta instantánea como evidencia de cómo está estructurado el catálogo, no como una tabla de precios permanente. La documentación de referencia de Flatkey señala explícitamente a los lectores de vuelta a flatkey.ai/models, flatkey.ai/pricing y flatkey.ai/status para que las filas de modelo, los precios y el estado de salud puedan actualizarse sin una nueva versión de la documentación.

Lee los proveedores antes de leer los nombres de los modelos

El proveedor es el primer campo porque un nombre de modelo por sí solo no te dice hacia dónde va el tráfico, qué contrato aplica o qué límites operativos importan.

Usa el campo de proveedor para responder:

Pregunta Por qué importa
¿Esta ruta está operada por el proveedor original del modelo, una pasarela, una nube de inferencia o un proxy interno? Cambia el soporte, el precio, el registro, el manejo de datos y la responsabilidad de los incidentes.
¿La fila representa un endpoint oficial o un modelo re-proveído? Los equipos de producto necesitan saber si el comportamiento debe coincidir con la API oficial del proveedor.
¿Hay varias filas con nombres similares de distintos proveedores? Una etiqueta qwen, deepseek, gemini o claude puede ocultar diferencias regionales, de compatibilidad o de plan.
¿Contra qué proveedor debería conciliar finanzas? La unidad de facturación y la referencia del precio de lista pueden venir del proveedor, mientras que la factura puede venir de la pasarela.

Para Flatkey, el posicionamiento aprobado es una clave, un saldo y acceso oficial a modelos en proveedores como OpenAI, Anthropic, Google, DeepSeek, Alibaba, Z.ai, Moonshot y ByteDance. Eso hace que la transparencia del proveedor sea especialmente importante. Si una fila del catálogo no deja claro el proveedor y la clase de ruta, pide aclaración antes de aprobar la fila para producción.

Lee los endpoints como contratos, no como etiquetas

El soporte de endpoints es un contrato entre tu aplicación y la ruta. Decide si tu cliente actual, el cuerpo de la solicitud, el controlador de streaming, el analizador de tool calls y la lógica de contabilización de uso pueden funcionar sin reescritura.

La documentación REST de Flatkey enumera estos endpoints públicos de la API:

Endpoint Uso típico
/v1/chat/completions Chat y generación de texto compatibles con OpenAI
/v1/responses Flujos de trabajo con estado o con capacidad de herramientas al estilo Responses para modelos compatibles
/v1/embeddings Embeddings vectoriales
/v1/images/generations Generación de imágenes
/v1/videos Creación de tareas de generación de video
/v1/videos/{task_id} Consulta de estado de tareas de video
/v1/videos/{task_id}/content Descarga de video completado
/v1/models Lista de modelos disponibles para la cuenta

Una fila del catálogo que dice openai no es lo mismo que una fila que dice anthropic, gemini, openai-response, openai-video o video. Un modelo puede admitir más de una familia de endpoints, pero aun así debes probar la ruta exacta que usará tu aplicación.

Para esta guía del catálogo de modelos de IA, usa el campo de endpoint para escribir un breve contrato de compatibilidad:

catalog_endpoint_contract:
  workload: support_ticket_summary
  model_id: selected-model-id
  provider: provider-name
  endpoint_type: openai
  base_url: https://router.flatkey.ai/v1
  endpoint_path: /v1/chat/completions
  required_features:
    - streaming
    - tool_calls
    - structured_json
    - usage_fields
  pass_condition:
    - existing_sdk_initializes
    - response_parser_accepts_output
    - usage_log_matches_model
    - fallback_policy_is_documented

Si falla un elemento de ese contrato, el modelo puede seguir siendo útil, pero no es una ruta plug-and-play para esa carga de trabajo.

Lee los grupos como una política de ruta y coste

Los grupos son fáciles de pasar por alto porque parecen etiquetas internas de la plataforma. No los pases por alto. Un grupo puede decidir quién puede usar una ruta, qué multiplicador de precio se aplica, qué clave está permitida, qué cuota se consume y qué reserva de fallback está disponible.

En un catálogo de gateway, los grupos a menudo representan una o más de estas políticas:

Significado del grupo Qué verificar
Plan comercial ¿Esta cuenta o equipo tiene acceso al precio mostrado?
Pool de rutas ¿Qué clase de canal upstream o cuenta de proveedor maneja el tráfico?
Entorno de producto ¿Esta ruta está aprobada para dev, staging, producción o un cliente específico?
Ámbito de presupuesto ¿Qué clave, equipo, workspace o presupuesto del cliente se carga?
Lista de अनुमति ¿Está permitido el modelo para datos regulados, funciones públicas o autonomía de agentes?
Familia de fallback ¿Puede este grupo hacer fallback a otra ruta sin romper la calidad o la política?

La posición del producto de Flatkey incluye gobernanza de subclaves, presupuestos, listas de अनुमति de modelos, registros de uso y un saldo compartido. Eso significa que la fila del catálogo y el panel de uso deben coincidir. Si un gerente de producto aprueba un modelo en el catálogo pero la clave de producción no está en el grupo correcto, ingeniería descubrirá el problema como un 403, un 429, una omisión de fallback o una sorpresa de facturación.

Lea los precios por unidad antes de comparar filas

El precio es el campo del catálogo de modelos que más se interpreta mal. Una guía del catálogo de modelos de IA debe obligar a convertir cada precio a su unidad real antes de que alguien lo compare.

No compare estas unidades como si fueran iguales:

Unidad de precio Carga de trabajo común Riesgo en la revisión del catálogo
Tokens de entrada Chat con mucho prompt, resumización, generación aumentada por recuperación Los prompts largos y el contexto recuperado pueden dominar el costo.
Tokens de salida Razonamiento, redacción, generación de código, extracción Las completaciones largas pueden dominar el costo incluso cuando la entrada parece barata.
Tokens de entrada en caché Prompts del sistema reutilizados, almacenamiento en caché de prompts, almacenamiento en caché de contexto Las tasas de acierto y fallo de caché deben medirse por separado.
Tokens de salida de imagen o precio por imagen Generación y edición de imágenes La resolución, la calidad, las imágenes de referencia, los reintentos y la tasa de aceptación cambian el costo real.
Por segundo Generación de video y algunas rutas de medios La duración y los clips fallidos/editados importan más que el número de solicitudes.
Por solicitud Búsqueda, herramientas, utilidades de imagen, enriquecimiento, APIs personalizadas La tasa de éxito de las solicitudes y la política de reintentos determinan el costo final.
Por minuto o carácter Voz, transcripción, texto a voz, flujos de trabajo similares a OCR El número de canales, el idioma, los complementos y el modo por lotes pueden cambiar el costo.

Las páginas de precios de los proveedores también usan nombres diferentes. OpenAI, Anthropic, Google Gemini y DeepSeek separan actualmente alguna combinación de precios de entrada, salida, entrada en caché, lectura/escritura de caché o acierto/fallo de caché en su documentación pública de precios actual. Por eso una revisión del catálogo debe almacenar la URL de la fuente en vivo y la fecha de revisión, en lugar de copiar un precio permanente en una tarea del roadmap.

Use esta fórmula normalizada:

accepted_workload_cost =
  (primary_attempt_cost
   + retry_cost
   + fallback_cost
   + cached_or_uncached_delta
   + media_or_tool_addons)
  / accepted_outputs

Luego añada el contexto de decisión:

production_cost_decision =
  accepted_workload_cost
  + latency_penalty
  + manual_review_cost
  + incident_risk
  + data_policy_constraints

Esa segunda línea es la razón por la que la celda de precio más barata rara vez es la respuesta final.

Lea el estado antes del tráfico de producción

El estado de disponibilidad debe ser un filtro, no una nota al pie. Un modelo puede verse perfecto en proveedor, endpoint y precio, pero aun así ser la elección incorrecta para producción si es solo de vista previa, está degradado, limitado por región, obsoleto, falta en su cuenta o falla las comprobaciones de salud.

Use estas clases de estado:

Clase de estado Qué hacer
Disponible y probado Candidato para un despliegue controlado después de la verificación del registro de uso.
Disponible pero no probado Ejecute una prueba rápida antes de asignar tráfico de producción.
Vista previa, beta, acceso anticipado o limitado Úselo para experimentos, salvo que el producto acepte explícitamente el riesgo del ciclo de vida.
Degradado o con alta latencia Manténgalo como no predeterminado o de respaldo solo si la carga de trabajo lo tolera.
Fallo desconocido Trátelo como bloqueado hasta que la ruta se verifique.
Obsoleto o con apagado programado No inicie trabajo nuevo a menos que exista un motivo breve de migración.
Próximamente No lo incluya en los compromisos de lanzamiento.

La documentación de Flatkey dirige las comprobaciones de estado del modelo a la página de estado en vivo. Para una decisión de producción, el campo de estado debe guardarse con la fecha, el ID del modelo, el tipo de endpoint, la clave o grupo, y un ID de solicitud real.

Use este flujo de trabajo siempre que un equipo de producto pregunte si un modelo del catálogo es seguro de usar.

  1. Abra el Directorio de modelos de Flatkey.
  2. Busque el ID exacto del modelo, no solo el nombre del proveedor.
  3. Registre el proveedor, el soporte de endpoint, el estado de disponibilidad, la unidad de precios, el acceso de grupo y la fecha de revisión actual.
  4. Abra la tarificación de Flatkey y la página de precios del proveedor correspondiente.
  5. Escriba la unidad de coste normalizada: por 1M tokens de entrada, tokens de salida, tokens en caché, imagen, segundo, solicitud u otra unidad.
  6. Ejecute una prueba rápida de bajo riesgo a través del base_url previsto, la ruta del endpoint y el ID del modelo.
  7. Confirme que la solicitud aparece en los registros de uso de Flatkey con el modelo esperado, la clave, el estado, los conteos de tokens o la unidad de medios, y el coste.
  8. Defina las reglas de respaldo antes de enviar usuarios reales: activador, número de reintentos, modelos de respaldo permitidos, control de calidad y campos de registro.
  9. Revise el registro del catálogo con producto, ingeniería, finanzas y seguridad antes de establecer la ruta como predeterminada.

La parte importante es el paso 7. Una fila del catálogo es una promesa. Una fila del registro de uso es la evidencia de que la promesa coincidió con su cuenta, clave, grupo y carga de trabajo.

Plantilla: registro de revisión del catálogo de modelos de IA

Copie esta plantilla en un documento interno de lanzamiento:

ai_model_catalog_review:
  review_date: 2026-09-14
  reviewer: product_owner_or_platform_owner
  workload: resumen_de_atención_al_cliente
  business_owner: support_product
  environment: staging
  catalog:
    catalog_url: https://flatkey.ai/models
    model_id: selected-model-id
    provider: provider-name
    endpoint_types:
      - openai
    group_or_plan: approved-group
    availability_status: available
    pricing_unit: per_1m_input_and_output_tokens
  compatibility:
    base_url: https://router.flatkey.ai/v1
    endpoint_path: /v1/chat/completions
    sdk: openai-python
    streaming_required: true
    tool_calls_required: false
    structured_output_required: true
  cost:
    provider_pricing_url: provider-pricing-page
    flatkey_pricing_url: https://flatkey.ai/pricing
    cost_formula: accepted_workload_cost
    cache_assumption: measured_not_assumed
  evidence:
    smoke_test_request_id: req_example
    usage_log_verified: true
    output_parser_passed: true
    p95_latency_ms: measured
    fallback_tested: false
  decision:
    status: approve_for_limited_rollout
    rollout_limit: 5_percent_of_traffic
    fallback_route: selected-fallback-model
    next_review_date: 2026-09-21

Esta plantilla mantiene práctico el Guía del catálogo de modelos de IA: cómo leer proveedores, endpoints, grupos y precios. El resultado no es una lista de preferencias. Es un registro de decisión auditable.

Errores comunes en el catálogo de modelos de IA

Error 1: Tratar proveedor y familia de modelos como si fueran el mismo campo

El proveedor es el propietario aguas arriba o el propietario de la ruta. La familia de modelos es un grupo de nombres. Están relacionados, pero no son intercambiables. Registre ambos.

Error 2: Asumir que compatible con OpenAI significa que todos los endpoints funcionan

Una configuración compatible con OpenAI puede reducir el trabajo de migración, pero no demuestra que funcionen todos los endpoints, eventos de streaming, formas de tool-call, campos de uso o parámetros de medios para cada modelo. Pruebe la familia exacta de endpoints en la fila del catálogo.

Error 3: Comparar el precio por token con el precio por medios

La facturación por token, por imagen, por segundo y por solicitud no debe fusionarse en una sola columna de precio. Normalícelo al costo por salida aceptada para la carga de trabajo.

Error 4: Ignorar los grupos hasta el despliegue

Si la clave de producción no tiene अनुमति para llamar al grupo que aprobó, la decisión del catálogo está incompleta. Valide el acceso al grupo con la clave que realmente se va a poner en producción.

Error 5: Copiar una fila de precio sin una fecha de revisión

Los precios del proveedor y de la pasarela pueden cambiar. Guarde la URL de origen, la fecha de revisión, el ID del modelo, la unidad de precio y la evidencia del registro de uso de una solicitud de prueba.

El estado del catálogo debe activar la prueba de humo. No debe sustituirla. La aprobación para producción necesita al menos una solicitud a través de la misma clave, endpoint, modelo y grupo.

Cuándo ayuda más un catálogo unificado de modelos de IA

Un catálogo unificado de modelos ayuda más cuando un equipo tiene más de uno de estos problemas:

  • Las claves de varios proveedores están dispersas entre servicios, agentes y entornos.
  • El producto quiere comparar rutas de texto, imagen, video, embeddings y herramientas en un solo flujo de trabajo.
  • Finanzas quiere evidencia de costos a nivel de solicitud en lugar de facturas separadas de cada proveedor.
  • La ingeniería de plataforma necesita reglas de fallback, verificaciones de estado y listas de अनुमति de modelos.
  • Seguridad necesita saber qué ruta manejó qué carga de trabajo.
  • Los equipos necesitan pasar de un modelo a otro sin reescribir cada cliente.

Flatkey está posicionado para este patrón: una clave de API, un router compatible con OpenAI, un directorio de modelos en vivo, registros de uso, acceso a modelos/herramientas a través de un solo saldo y controles operativos para equipos. Eso no elimina la debida diligencia. Le da al equipo un solo lugar para realizarla.

FAQ

¿Qué es un catálogo de modelos de IA?

Un catálogo de modelos de IA es una lista searchable de rutas de modelos y sus metadatos: ID del modelo, proveedor, endpoints compatibles, unidad de precio, disponibilidad, grupos o planes, y a veces ventana de contexto, modalidad, estado de salud, límites y enlaces de uso.

¿Por qué importa el campo de proveedor?

El campo de proveedor te dice quién es el propietario del modelo o la ruta subyacente. Afecta el soporte, las referencias de precios, los límites, los avisos del ciclo de vida, el comportamiento regional, el manejo de datos y la respuesta a incidentes.

¿Qué significa compatibilidad de endpoint en un catálogo de modelos?

La compatibilidad de endpoint te dice qué forma de API acepta una fila de modelo. Por ejemplo, una fila puede admitir chat compatible con OpenAI, Responses, solicitudes compatibles con Anthropic, solicitudes nativas de Gemini, generación de imágenes, generación de video o embeddings. Tu SDK y tu parser deben coincidir con el endpoint que elijas.

¿Los grupos son lo mismo que los niveles de precios?

A veces, pero no siempre. Los grupos pueden representar planes comerciales, conjuntos de rutas, políticas de acceso, ámbitos de claves, ámbitos de presupuesto o familias de fallback. Trata los grupos como política de ruta hasta que el propietario de la plataforma confirme el significado exacto.

¿Cómo deben comparar los equipos los precios de los modelos?

Compara los precios de los modelos por carga de trabajo, no por la fila bruta del catálogo. Normaliza tokens de entrada, tokens de salida, tokens en caché, imágenes, segundos, solicitudes, reintentos, intentos de fallback y salidas aceptadas en una sola fórmula de costo.

¿Debería confiar en una fila del catálogo de modelos sin probarla?

No. Una fila del catálogo es un punto de partida útil, pero la aprobación para producción debe incluir una prueba rápida a través de la clave exacta, la URL base, el endpoint, el ID del modelo y el grupo que planeas usar.

¿Cómo ayuda Flatkey con la revisión del catálogo de modelos?

Flatkey ofrece a los equipos un solo lugar para inspeccionar filas de modelos, enrutar a través de una URL base compatible con OpenAI, comparar superficies de precios en vivo, verificar el estado de salud del modelo y revisar los registros de uso. Eso facilita auditar las decisiones del catálogo en producto, ingeniería y finanzas.

El paso final en una Guía del catálogo de modelos de IA: cómo leer proveedores, endpoints, grupos y precios no es elegir un modelo. Es probar la ruta.

Antes del lanzamiento, tu equipo debería poder mostrar:

  • El ID exacto del modelo y el proveedor.
  • El tipo de endpoint y la ruta del SDK.
  • El grupo o plan que concede acceso.
  • La unidad de precio actual y la URL de origen.
  • El estado de disponibilidad y la fecha de revisión.
  • Un ID de solicitud de prueba rápida.
  • Una fila del registro de uso que muestre modelo, clave, estado, tokens o unidad multimedia y costo.
  • Una regla de fallback y rollback.

Si esos campos están completos, el catálogo está cumpliendo su función. Si faltan, la decisión sobre el modelo sigue siendo una suposición.

Fuentes consultadas