Saltar al contenido principal
start_within es obligatorio en cada solicitud de FlexInference. Establece cuánto tiempo puede esperar el enrutador a que la solicitud comience. Utilice default, priority o auto cuando desee un nivel de proveedor directamente. Utilice una duración cuando desee que FlexInference intente primero flex en un modelo compatible con flex, y luego escale a standard si flex no puede comenzar a tiempo. El campo tiene cuatro formas.

​
Las cuatro formas

Enruta al nivel en tiempo real estándar del proveedor con precios estándar: default de OpenAI, standard de Gemini o standard_only de Anthropic. Funciona con cualquier modelo.
default, priority y auto proxy cualquier modelo a su proveedor (OpenAI, Gemini o Anthropic). Solo una duración solicita la carrera flex. Si el modelo no puede usar flex, una duración devuelve 400 (flex_unsupported_for_anthropic o flex_model_not_capable); use un valor de nivel en su lugar.
La carrera flex no está disponible en Claude porque Anthropic no tiene un nivel flex. Una duración start_within en un modelo claude-* devuelve 400 flex_unsupported_for_anthropic. Anthropic sigue funcionando con solicitudes de proxy de nivel default, priority y auto.
Una duración start_within no se puede combinar con parámetros de Chat Completions solo nativos como logprobs o seed. Elimine esos parámetros o use default, priority o auto en su lugar.

​
La carrera flex

Con una duración, FlexInference intenta primero el nivel flex del proveedor (OpenAI o Gemini). flex se factura a la mitad de la tarifa estándar, pero la capacidad es de mejor esfuerzo. El enrutador espera a que la solicitud upstream comience dentro de su plazo:
1

Iniciar flex

FlexInference envía su solicitud al nivel flex y espera a que el proveedor confirme que se está procesando, todo dentro del tiempo que usted estableció.
2

Confirmar flex

Si el proveedor inicia la solicitud a tiempo, FlexInference la confirma. Su respuesta se transmite de vuelta normalmente, facturada a tarifas flex. La respuesta muestra "service_tier": "flex".
3

Escalar a estándar

Si flex no puede comenzar a tiempo, FlexInference la cancela y envía la solicitud a standard. Esto es una escalada del flex más económico a standard, no una degradación. La respuesta muestra "service_tier": "default" (OpenAI) o "standard" (Gemini).
La escalada a standard ocurre solo antes de que flex comience, cuando flex devuelve un 429 (sin capacidad), cualquier 5xx, un fallo previo al inicio, o no inicia antes del plazo. El cambio de flex a standard es el único cambio de nivel que realiza FlexInference. Un fallback de proveedor, donde usted establece un array provider opcional y FlexInference intenta la siguiente ruta después de que una ruta falla transitoriamente, cambia la ruta, nunca el nivel o el modelo. Una clave faltante para cualquier ruta que haya nombrado es un error de configuración en lugar de una falla transitoria, por lo que devuelve un 400 en lugar de continuar. Consulte enrutamiento de proveedores.
Elija la duración más larga que su UX pueda tolerar. Plazos más largos le dan a flex más tiempo para ganar, aumentando la proporción de solicitudes atendidas a la tarifa más económica.

​
Lectura del resultado

Las respuestas 200 exitosas incluyen encabezados de resultado de flex en cada endpoint, tanto para llamadas streaming como no streaming. Las respuestas de error utilizan el cuerpo del error en su lugar. Los valores en vivo de x-flexinference-flex-reason son:
Una duración que no puede ejecutar una carrera flex devuelve 400 (flex_unsupported_for_anthropic en un modelo claude-*, flex_model_not_capable en un modelo OpenAI/Gemini no compatible con flex); las razones del encabezado describen solo las solicitudes que ejecutaron flex o no lo solicitaron.

​
Cuando el pool flex no está disponible

El nivel flex utiliza capacidad compartida y de mejor esfuerzo. Antes de que una solicitud comience, flex puede devolver un 429 cuando no hay capacidad, devolver cualquier 5xx, fallar antes del inicio o no cumplir el plazo. FlexInference luego envía la solicitud a standard. En casos raros, flex falla después de que la solicitud ha sido aceptada y ha comenzado a transmitirse. FlexInference expone esa falla. En una solicitud streaming, usted recibe un evento response.failed terminal. En una solicitud no streaming, usted recibe un 502. No reintenta después de la confirmación porque eso podría enmascarar una solicitud incompleta. Si esto ocurre, reintente, o use default, priority o auto para omitir flex.

​
Reintento de transporte

La carrera flex decide qué nivel atiende su solicitud. El reintento de transporte decide qué sucede cuando ese nivel no puede iniciar. Agregue un objeto retry opcional y FlexInference esperará y volverá a intentar el nivel establecido en caso de una falla upstream transitoria, en lugar de devolverle el error.
Un retry inválido devuelve 400 invalid_retry. FlexInference solo reintenta una falla de transporte genuina previa a la confirmación del nivel establecido: un 429 real, un 5xx real o una conexión que nunca se abrió (upstream_unavailable). No reintenta un 4xx del cliente, una falla de autenticación upstream (upstream_auth_failed), un timeout upstream (upstream_timeout) o una solicitud que el cliente canceló. Esos fallan de la misma manera en un reintento o significan que el emisor ya no está. El reintento vuelve a intentar el nivel que estableció su solicitud, no la rama flex. En una solicitud default, priority o auto, ese es el nivel que usted nombró. En una solicitud de duración que pierde la carrera flex, es el nivel standard al que escaló. El intento flex y la escalada son trabajo propio de la carrera flex y nunca cuentan contra count. Escalar un nivel y reintentar el mismo nivel son pasos separados que se encadenan: flex pierde contra standard, luego standard puede reintentarse a sí mismo. Cuando el proveedor envía un encabezado Retry-After, FlexInference espera ese tiempo en lugar del cronograma de backoff, limitado a 60 segundos para que un valor incorrecto no pueda estacionar su solicitud.
El reintento es solo previo a la confirmación. Se detiene en el momento en que un nivel se confirma, que es la línea de estado 200 tanto para llamadas streaming como no streaming. Una vez que el primer byte está en camino hacia usted, FlexInference nunca reintenta, la misma regla que sigue la carrera flex después de la confirmación. Una falla a mitad de la transmisión, o un 502 no streaming después de un 200 confirmado, se le pasa a usted.
El retry del lado del servidor es independiente de cualquier bucle de reintento en su cliente, y ambos se apilan. Los SDK de FlexInference no reintenta, pero un SDK estándar de OpenAI o Anthropic reintenta dos veces por defecto. Un cliente que reintenta dos veces además de un count de 3 en el servidor genera hasta seis intentos upstream, porque cada intento del cliente ejecuta un presupuesto completo del servidor. Cuando usted establece retry, FlexInference marca la respuesta con x-flexinference-retries con el número de reintentos que ejecutó, para que pueda reducir el max_retries de su propio cliente.

​
Facturación

Con BYOK, FlexInference utiliza su clave de proveedor cifrada almacenada en el lado del servidor; usted no envía claves de proveedor por solicitud. Su proveedor factura su cuenta a la tarifa del nivel que atendió la solicitud. Usted paga tarifas flex cuando flex se confirma y tarifas standard después de la escalada. Un intento flex puede consumir algunos tokens antes de fallar. Su proveedor factura ese uso de la misma manera que lo haría si usted llamara a flex directamente, y FlexInference lo incluye en el uso. FlexInference no añade ningún recargo a sus tokens. Cobra el 20% del dinero que le ahorra, y no cobra nada cuando no hay ahorros.

​
Qué cambia FlexInference

FlexInference puede cambiar el nivel. No cambia el significado de su solicitud ni el resultado del proveedor. Nunca reescribe el estado o el mensaje de un proveedor. Solo normaliza el envelope de error: un error se devuelve con la forma del endpoint que usted llamó (OpenAI en responses y chat, Anthropic en messages, Google en interactions), llevando el estado y el mensaje del proveedor, para que su SDK pueda analizarlo. Consulte Errores.
start_within es obligatorio. Sin él, la solicitud devuelve 400 missing_start_within, incluso con un SDK de OpenAI simple apuntando a nuestra URL base. Si envía un valor que FlexInference no puede leer, obtendrá invalid_start_within. Los valores válidos son "default", "priority", "auto" o una duración como "00h-00m-30s". La palabra standard solía estar permitida y ya no lo está, así que envíe default en su lugar. Consulte Errores para ver la lista completa.