Iniciar sesiónContactoEmpieza gratis
Base URL and SDK Migration27 de julio de 2026Flatkey Team

Una URL base compatible con OpenAI para pruebas de prompts con múltiples modelos

Mantén tu SDK de OpenAI, cambia una sola URL base y compara varios modelos con un flujo controlado de pruebas de prompts y transición a producción.

Una URL base compatible con OpenAI para pruebas de prompts con múltiples modelos

Tu aplicación ya sabe cómo llamar a un cliente compatible con OpenAI. Añadir la elección del modelo no debería requerir reconstruir esa integración para cada proveedor.

Flatkey te ofrece una sola URL base compatible con OpenAI:

https://router.flatkey.ai/v1

Apunta tu cliente existente del SDK de OpenAI a esa URL, usa una clave API de Flatkey y elige el modelo que quieras probar en el campo model. Tu envoltorio de solicitudes, el conjunto de datos de prompts, la rúbrica de evaluación y el código de tu aplicación pueden seguir centrados en una sola interfaz.

Eso hace que Flatkey sea una opción práctica cuando tu equipo está listo para comparar modelos, pero no quiere que la configuración de cuentas específica de cada proveedor y las reescrituras del cliente se conviertan en el proyecto de evaluación.

The lowest-friction path from one model to a shortlist

Una evaluación típica de modelos empieza con una pregunta simple: ¿puede otro modelo mejorar la calidad, la latencia o el coste de esta carga de trabajo?

El trabajo de implementación puede eclipsar rápidamente esa pregunta. Las integraciones separadas crean variables de entorno, patrones de autenticación, comportamiento de reintento, adaptadores de respuesta, paneles y relaciones de facturación अलगadas. Cuando el entorno de pruebas está listo, el experimento de prompt original se ha convertido en un proyecto de infraestructura.

Una URL base compatible con OpenAI cambia la secuencia. Mantienes una sola forma de cliente y conviertes el modelo en la variable principal.

Keep stable Change deliberately Validate per model
SDK and request wrapper base_url once Output quality
Prompt dataset model for each run Latency distribution
Evaluation rubric Model-specific parameters when needed Token usage and cost
Result storage Timeout or retry settings when justified Tool and structured-output behavior
Application-side observability Production routing only after evaluation Error and refusal patterns

El objetivo no es fingir que todos los modelos se comportan de forma idéntica. El objetivo es eliminar la variabilidad de integración evitable para que tu equipo pueda dedicar más tiempo a medir las diferencias que importan.

Change the base URL, not your whole SDK layer

Si ya usas el SDK de OpenAI para Python, el cambio principal en el cliente es pequeño:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["FLATKEY_API_KEY"],
    base_url="https://router.flatkey.ai/v1",
)

El mismo patrón funciona con el cliente JavaScript de OpenAI:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.FLATKEY_API_KEY,
  baseURL: "https://router.flatkey.ai/v1",
});

Después de eso, usa un ID de modelo del directorio de modelos actual de Flatkey en la solicitud. No codifiques de forma fija supuestos sobre el modelo a partir de una hoja de cálculo o artículo antiguo; la disponibilidad y las capacidades de los modelos pueden cambiar.

response = client.chat.completions.create(
    model=os.environ["EVAL_MODEL_ID"],
    messages=[
        {"role": "system", "content": "Responde usando la política proporcionada."},
        {"role": "user", "content": evaluation_prompt},
    ],
    temperature=0,
    max_tokens=800,
)

Esta es la ventaja central de adopción: tu aplicación puede mantener su cliente compatible con OpenAI mientras tu evaluación cambia la selección del modelo.

Un flujo de trabajo de pruebas de prompts con múltiples modelos y enfoque específico

Usa el siguiente flujo de trabajo para convertir una migración de URL base en una decisión que tu equipo pueda defender.

1. Congela el contrato de la solicitud

Parte de una solicitud que ya represente la carga de trabajo de producción. Mantén lo siguiente fijo durante la primera pasada de comparación:

  • Prompts del sistema y del usuario
  • Ejemplos de entrada
  • Temperatura y límites de tokens
  • Definiciones de herramientas o esquema de respuesta
  • Política de tiempo de espera
  • Rúbrica de evaluación

Si cambias el prompt, el modelo y la política de reintentos al mismo tiempo, no sabrás qué cambio produjo el resultado.

2. Crea un conjunto de evaluación pequeño y representativo

No empieces con cientos de prompts sintéticos. Comienza con 20 a 50 ejemplos que cubran los casos que tus usuarios realmente crean:

  • Solicitudes comunes y de alta frecuencia
  • Entradas largas o desordenadas
  • Instrucciones ambiguas
  • Casos sensibles para la seguridad o propensos a rechazo
  • Casos límite de salida estructurada
  • Casos de llamada a herramientas, si tu aplicación usa herramientas

Elimina datos privados y secretos antes de enviar tráfico de evaluación. El mejor conjunto de evaluación es lo bastante pequeño como para inspeccionarlo y lo bastante representativo como para exponer fallos significativos.

3. Ejecuta los mismos casos a través de cada modelo candidato

Mantén fijos la URL base de Flatkey y el envoltorio de la solicitud. Recorre los IDs de modelo de tu lista corta.

import time

candidate_models = [
    "MODEL_ID_A",
    "MODEL_ID_B",
    "MODEL_ID_C",
]

results = []

for model_id in candidate_models:
    for case in evaluation_cases:
        started_at = time.perf_counter()
        try:
            response = client.chat.completions.create(
                model=model_id,
                messages=case["messages"],
                temperature=0,
                max_tokens=case.get("max_tokens", 800),
            )
            elapsed_ms = round((time.perf_counter() - started_at) * 1000)
            results.append({
                "case_id": case["id"],
                "model": model_id,
                "latency_ms": elapsed_ms,
                "output": response.choices[0].message.content,
                "usage": response.usage.model_dump() if response.usage else None,
                "error": None,
            })
        except Exception as error:
            results.append({
                "case_id": case["id"],
                "model": model_id,
                "latency_ms": None,
                "output": None,
                "usage": None,
                "error": type(error).__name__,
            })

Utiliza marcadores de posición en los ejemplos compartidos y selecciona los IDs de modelo actuales del directorio en vivo antes de ejecutar la prueba. Confirma también que cada candidato admita las capacidades que necesita tu carga de trabajo.

4. Puntúa el resultado, no la reputación del modelo

Una hoja de evaluación útil separa los requisitos estrictos de las preferencias.

Dimensión Pregunta de ejemplo Tratamiento sugerido
Corrección ¿La respuesta satisfizo la tarea? Evaluador humano o específico de la tarea
Seguimiento de instrucciones ¿Obedeció las restricciones y el formato? Aprobado/fallido más notas
Salida estructurada ¿El payload se pudo parsear y coincidió con el esquema? Validación automatizada
Comportamiento de herramientas ¿Las llamadas fueron válidas y se seleccionaron de forma adecuada? Controles automatizados más revisión
Latencia ¿Cuánto tardaron las solicitudes exitosas? Percentiles mediano y de cola
Fiabilidad ¿Con qué frecuencia fallaron o caducaron las solicitudes? Tasa de error por clase
Uso ¿Cuántos tokens de entrada y salida se informaron? Por caso y agregado
Coste ¿Cuánto costaría la carga de trabajo evaluada? Calcular con el precio actual

Rechaza cualquier candidato que incumpla un requisito estricto, aunque sea económico. Entre los modelos restantes, compara las compensaciones que importan para tu producto.

5. Vuelve a probar a los finalistas con comportamiento de producción

La primera pasada debe ser controlada. La pasada de finalistas debe ser realista.

Prueba el streaming si tu interfaz lo utiliza. Prueba las llamadas a herramientas si tu agente usa herramientas. Prueba las salidas estructuradas si el código posterior las procesa. Ejercita tus ajustes reales de tiempo de espera y reintentos, y verifica cómo maneja tu aplicación los límites de tasa, las transmisiones interrumpidas, las respuestas mal formadas y los estados de finalización ambiguos.

Flatkey's Usage Logs pueden ayudarte a confirmar que las solicitudes llegaron al gateway e inspeccionar la actividad de solicitudes. Mantén también los IDs de solicitud y los datos de tiempo del lado de la aplicación, para que puedas conectar la visibilidad del gateway con la experiencia del usuario.

Para detalles de reintentos y cambio, utiliza la guía de migración del cliente de OpenAI para límites de tasa y reintentos.

La compatibilidad es un punto de partida, no una promesa de comportamiento idéntico

Una API compatible con OpenAI reduce el trabajo de migración del cliente. No hace que distintos modelos sean intercambiables.

Antes de aprobar un modelo para producción, verifica:

  • El ID exacto del modelo está disponible actualmente.
  • El modelo admite el endpoint y la modalidad que necesitas.
  • Los parámetros requeridos se aceptan y se comportan como esperas.
  • Las llamadas a herramientas, las salidas JSON o estructuradas y el streaming superan tus pruebas.
  • Los límites de tokens se ajustan a tus entradas y salidas reales.
  • El comportamiento de seguridad coincide con los requisitos de tu producto.
  • Los tiempos de espera, los reintentos y el manejo de errores no crean trabajo duplicado o ambiguo.
  • El precio actual se ajusta a la mezcla de tráfico esperada.

Si necesita una lista de verificación de ingeniería más amplia, consulte la guía de migración de la pasarela de API compatible con OpenAI. Esta página es intencionalmente más específica: está dirigida a equipos que ya entienden el patrón de migración y quieren convertir un cambio de una sola URL base en una prueba justa de múltiples modelos.

Lista práctica de verificación para el corte

Pase de la evaluación a producción solo cuando pueda responder sí a cada punto.

  • Paridad de solicitudes: El finalista funciona con su prompt real, mensajes, herramientas y patrones de salida.
  • Umbral de calidad: Supera los requisitos estrictos de su rúbrica.
  • Manejo de fallos: Su aplicación gestiona de forma segura los límites de tasa, los tiempos de espera y las respuestas interrumpidas.
  • Observabilidad: Registra el modelo, la latencia, el uso, la clase de error y un identificador de solicitud de la aplicación.
  • Modelo de costes: Ha calculado el gasto esperado a partir de los precios actuales y un uso realista de tokens.
  • Rollback: Puede volver al modelo o configuración anterior sin publicar un cambio de código.
  • Plan canary: Puede exponer el cambio a una fracción limitada del tráfico antes de desplegarlo por completo.

La interfaz estable facilita el rollback y las pruebas repetidas porque la superficie de integración se mantiene consistente. Su decisión de modelo puede cambiar sin obligar a introducir cada vez en la aplicación una nueva capa de cliente específica del proveedor.

Empiece con una sola URL base y una carga de trabajo real

Si su equipo ya usa un SDK compatible con OpenAI, el siguiente paso útil no es otra discusión de arquitectura. Es una prueba controlada con sus propios prompts.

  1. Cree una cuenta de Flatkey y una clave de API.
  2. Establezca base_url en https://router.flatkey.ai/v1.
  3. Seleccione una lista corta de modelos del directorio actual.
  4. Ejecute los mismos casos representativos en cada modelo.
  5. Revise conjuntamente la calidad, la latencia, la fiabilidad, el uso y el coste actual.

Compare los precios actuales de los modelos y elija su lista corta, luego ejecute la primera evaluación con el mismo cliente que ya usa su aplicación.

Preguntas frecuentes

¿Cuál es la URL base compatible con OpenAI de Flatkey?

Use https://router.flatkey.ai/v1. Configúrela en su cliente compatible con OpenAI y autentíquese con una clave de API de Flatkey.

¿Necesito reemplazar el SDK de OpenAI?

No. La guía de inicio rápido de Flatkey documenta el uso de los SDK de Python y JavaScript de OpenAI con la URL base de Flatkey. Aun así, debería probar cada función de solicitud y cada capacidad del modelo de las que dependa su aplicación.

¿Puedo comparar varios modelos con el mismo código de prompts?

Sí. Mantenga estables el cliente, el conjunto de datos de prompts y la lógica de evaluación, y luego cambie el valor de model para cada candidato. Las capacidades y parámetros específicos del modelo siguen requiriendo validación.

¿La compatibilidad con OpenAI es lo mismo que un comportamiento idéntico del modelo?

No. La compatibilidad reduce los cambios de integración. Los modelos pueden diferir en la calidad de salida, el uso de herramientas, el comportamiento de salida estructurada, la latencia, los límites, el comportamiento de seguridad y el coste.

¿Qué debo medir en una prueba con múltiples modelos?

Mida la corrección de la tarea, el seguimiento de instrucciones, la validez del esquema o de la herramienta, la latencia, la tasa de error, el uso de tokens y el coste actual. Defina requisitos estrictos antes de comparar preferencias.

¿Dónde debo consultar los precios de los modelos?

Utiliza la página de precios en vivo de Flatkey en lugar de copiar los precios en un documento de evaluación de larga duración.