Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Aumenta el tráfico de modelos a través de Unity Gateway de forma gradual al lanzar una carga de trabajo o cambiar de modelo. Esta guía se aplica a modelos propietarios y de peso abierto proporcionados por Azure Databricks y a modelos accesibles a través de proveedores externos conectados.
Aumente el tráfico gradualmente
La capacidad disponible depende del modelo, proveedor, región y modo de servicio. Las peticiones pueden encontrarse con errores temporales de capacidad incluso cuando el tráfico se mantiene dentro de los límites de tasa configurados. Un aumento de cuota por sí solo no reserva capacidad de servicio.
Para aumentar el rendimiento:
- Revisa los límites de tasa del servicio configurados y los límites para el modelo o proveedor externo. Estima las tasas de tokens de entrada y salida y las solicitudes concurrentes, incluyendo tamaños representativos de prompt y respuesta.
- Empieza en un nivel de tráfico estable y conocido. Para una carga de trabajo nueva, empiece con una carga pequeña que sea representativa.
- Aumenta el tráfico poco a poco. Mantén cada nivel estable mientras monitorizas la tasa de éxito de la solicitud, la latencia, el uso de tokens, la profundidad de la cola y los errores de limitación o capacidad. Aumenta de nuevo solo cuando la carga de trabajo sea estable y cumpla con los objetivos operativos de tu aplicación.
- Si la limitación de velocidad, los errores de capacidad o la latencia superan la tolerancia de tu aplicación, pausa el incremento gradual y vuelve al último nivel estable de tráfico. Reducir la concurrencia y poner en cola o posponer trabajos de menor prioridad.
Elige tamaños de pasos y periodos de observación en función de tu carga de trabajo y de las directrices del modelo o proveedor. Repite esta validación al cambiar de modelo, regiones o capacidad de servicio.
Gestionar errores de limitación de velocidad y capacidad
Inspecciona tanto el estado HTTP como el cuerpo de error de la API a la que llamas. Los códigos de error y los mensajes pueden variar entre APIs unificadas y nativas de proveedores.
| Respuesta | Sentido y acción |
|---|---|
429 Too Many Requests |
Un límite de tasa configurado o una limitación del servicio downstream impide que se procese la solicitud. Algunos proveedores también limitan los aumentos bruscos del tráfico. Identifica el límite desde el cuerpo de error, reduce la tasa de solicitudes y aumenta el tráfico gradualmente. Si el error requiere un cambio de cuota o facturación, resuelve esa condición antes de intentarlo de nuevo. |
503 Service Unavailable |
El servicio o modelo temporalmente no puede atender la solicitud. Esto puede ocurrir durante un aumento de tráfico, incluso por debajo de los límites de frecuencia configurados. Vuelva a intentarlo dentro de un presupuesto limitado y pause el aumento gradual si los errores persisten. |
| Otros errores por sobrecarga de proveedor | Algunas APIs de proveedores usan otras respuestas, como 529, para indicar una sobrecarga temporal. Sigue las indicaciones de error del proveedor y la API que uses. |
Un error de capacidad por sí solo no establece que el autoescalado esté en curso ni indica cuándo la capacidad está disponible.
Configurar reintentos
- Respeta el
Retry-Afterencabezado cuando la respuesta lo incluya. De lo contrario, vuelva a intentar las solicitudes afectadas por errores transitorios de limitación y capacidad con retroceso exponencial y vibración aleatoria. - Limita el total de intentos y el tiempo transcurrido para ajustarlos al presupuesto de latencia de tu aplicación. Si persisten errores, reduce el tráfico en lugar de añadir más intentos.
- Comprueba el comportamiento de reintentos del SDK antes de añadir reintentos de aplicación. Ten en cuenta los reintentos en las distintas capas para que no multipliquen la carga.
- Gestiona los errores después de que empiece una respuesta en streaming en el consumidor del stream. Repetir una petición tras recibir la salida puede duplicar la salida o duplicar el trabajo.
Para errores persistentes, contacta con tu equipo de cuenta de Databricks con IDs de solicitud, marcas de tiempo, nombres de modelos y proveedores, tasas de tokens observadas, concurrencia y la cronología de la rampa de tráfico. Para proveedores externos conectados, también comprueba el estado del servicio y los límites de cuenta del proveedor.
Inferencia por lotes
Para cargas de trabajo grandes offline con modelos compatibles, utiliza AI Functions, que gestionan la paralelización, los retries y el escalado. Sigue su guía de inferencia por lotes en lugar de aplicar un bucle de reintento separado a cada fila.