¿Puede un servicio de IA local recurrir a la CPU cuando la memoria de la GPU está llena?
Sí, pero la conmutación por error fiable de la CPU debe diseñarse antes de que se llene la memoria de la GPU; la mayoría de los procesos de inferencia no se recuperan de forma transparente de un OOM inesperado.
Un servidor de IA doméstico puede responder rápidamente en su GPU hasta que un prompt más largo, un lote más grande, una solicitud de imagen o un segundo modelo consume la VRAM restante. La siguiente asignación puede fallar aunque la RAM del sistema y la CPU estén inactivas. Que la solicitud sobreviva depende del entorno de ejecución: algunos pueden colocar los pesos en la CPU desde el principio, mientras que otros necesitan un trabajador de CPU independiente y un enrutador que reintente de forma segura.
La descarga a la CPU y la conmutación por error de la CPU resuelven problemas distintos
La descarga a la CPU es una estrategia de ubicación del modelo. Algunas capas, tensores o componentes de la canalización residen en la RAM del sistema y se trasladan al acelerador cuando es necesario, lo que reduce la VRAM requerida para una solicitud normal. La conmutación por error de la CPU es un comportamiento del servicio: cuando la ruta de la GPU no está disponible o rechaza una solicitud, otro trabajador la acepta y ejecuta un modelo compatible con la CPU sin perder el trabajo.
Hugging Face Accelerate expone métodos de descarga a la CPU que trasladan deliberadamente el estado del modelo entre la memoria de la CPU y un dispositivo de ejecución. Se trata de una ejecución heterogénea planificada, no de una respuesta de emergencia después de que un estado arbitrario de CUDA haya fallado. El modelo, el mapa de dispositivos, los hooks y el presupuesto de memoria se preparan antes de que comience la inferencia.
Un modelo descargado parcialmente puede estar usando ya la CPU y seguir dependiendo de la GPU para cada token. Si la GPU falla, ese proceso no necesariamente puede continuar en la CPU desde el token interrumpido. La verdadera conmutación por error normalmente reinicia la solicitud en un trabajador preparado para la CPU. Esta distinción explica por qué una aplicación puede anunciar compatibilidad con la CPU y aun así devolver un error de OOM en lugar de completar la solicitud actual.
La VRAM puede llenarse después de que un modelo se cargue correctamente
Los pesos del modelo son solo una parte del presupuesto de memoria. La caché de valores y claves crece con la longitud de secuencia activa y la concurrencia, los kernels temporales necesitan espacio de trabajo, los codificadores de imágenes o audio añaden tensores y un asignador de memoria puede reservar bloques para reutilizarlos. Por tanto, un modelo que cabe al iniciarse puede fallar con un contexto largo o varios usuarios simultáneos.
PyTorch utiliza un asignador de memoria en caché, por lo que la memoria indicada como reservada no es idéntica a la memoria de tensores activos. La fragmentación y las asignaciones realizadas fuera del framework pueden reducir aún más el margen utilizable. Un activador de conmutación por error debe supervisar las asignaciones rechazadas y el estado del trabajador, no inferir la seguridad a partir de un único número del panel ni del hecho de que la carga del modelo se haya completado correctamente.
Por eso, una regla estática de «el tamaño del modelo es inferior a la VRAM» es incompleta. Un servicio puede establecer un límite de contexto inferior, limitar las secuencias simultáneas o dejar sin utilizar un porcentaje de la VRAM para proteger las asignaciones del entorno de ejecución. Estos controles previenen más fallos que el cambio reactivo a la CPU, porque mantienen el proceso de la GPU en un estado conocido y conservan una latencia predecible para las solicitudes aceptadas.
El reintento automático solo es seguro cuando la solicitud se puede reproducir
Después de un OOM, el enrutador puede marcar como no saludable al trabajador de la GPU, liberarlo o reiniciarlo y reproducir la solicitud original en un trabajador de la CPU. Esto funciona para la generación de texto ordinaria cuando no se ha producido ningún efecto externo. Es más difícil con respuestas en streaming, canalizaciones de imágenes con semillas aleatorias o agentes que ya pueden haber llamado a una herramienta.
Los frameworks también pueden distribuir modelos grandes entre dispositivos desde el principio. La inferencia de modelos grandes de Accelerate admite mapas de dispositivos y la ubicación en la CPU o el disco cuando un modelo supera la capacidad de un dispositivo. Este enfoque puede mantener una solicitud activa dentro de un único grafo de ejecución planificado, pero intercambia velocidad por capacidad y no debe confundirse con enrutar una solicitud fallida a un servicio independiente.
La afirmación de conmutación por error deja de aplicarse cuando la CPU no tiene suficiente RAM, el entorno de ejecución no dispone de kernels compatibles con la CPU, la solicitud ya ha producido una acción irreversible o la latencia prevista de la CPU supera el tiempo de espera del cliente. En esos casos, devuelve un error de capacidad controlado o coloca la solicitud en una cola. Reintentar silenciosamente puede duplicar efectos secundarios o hacer que los usuarios esperen mucho más de lo que promete la interfaz.
Demuestra la conmutación por error con una prueba de memoria deliberada
Ejecuta un trabajador de GPU y otro de CPU detrás de un enrutador y envía una solicitud que supere el perfil de la GPU sin superar la RAM del sistema. Registra el primer fallo, la decisión de reintento, la hora de inicio de la CPU, el resultado final y si la conexión del cliente sobrevive. Repite primero con el streaming desactivado y, después, prueba la cancelación, el tráfico simultáneo y una solicitud de agente con una herramienta simulada.
La ejecución parcial en la GPU es una referencia útil porque los entornos de ejecución como la inferencia de llama.cpp pueden colocar una parte configurable del trabajo del modelo en los aceleradores y conservar la ejecución en la CPU. Compara los perfiles de GPU, de división planificada entre CPU y GPU y de fallback independiente en la CPU. Un modelo de carga de trabajo de IA híbrida ayuda a separar la conmutación por capacidad del enrutamiento habitual a la nube.
Considera fiable el diseño solo si el reintento se completa una vez, conserva la identidad de la solicitud, evita acciones duplicadas de herramientas y restaura el trabajador de GPU sin descartar trabajos no relacionados. Si la finalización en la CPU es demasiado lenta, úsala como una ruta de seguridad que preserve la cola, no como un equivalente interactivo. El objetivo operativo es una degradación gradual, no fingir que los niveles de servicio de la CPU y la GPU son intercambiables.
| Comportamiento | ¿Preparado antes del OOM? | ¿Puede salvar la solicitud actual? |
|---|---|---|
| Descarga a CPU/GPU | Sí | Normalmente, dentro del grafo planificado |
| Menor concurrencia de la GPU | Sí | Impide admitir trabajo inseguro |
| El enrutador reintenta en la CPU | Sí | Sí, si se puede reproducir |
| Cambio no planificado dentro del proceso | No | Normalmente no |
Preguntas frecuentes
¿Vaciar la caché de la GPU crea una conmutación por error?
No. Liberar la caché puede hacer que haya bloques reservados sin usar disponibles, pero no crea ejecución en la CPU, no repara un estado de solicitud dañado ni garantiza que haya suficiente memoria contigua para la siguiente asignación.
¿El fallback en la CPU producirá la misma respuesta?
Puede hacerlo si se utilizan los mismos pesos, precisión, prompt, tokenizador y estado de muestreo. Aun así, distintos kernels, cuantización, semillas o un estado de streaming reiniciado pueden cambiar el resultado exacto.
¿Es mejor un modelo más pequeño que la conmutación por error de la CPU?
A menudo, para un servicio interactivo. Un modelo de GPU más pequeño puede ofrecer una latencia predecible, mientras que la conmutación por error a la CPU protege la disponibilidad para solicitudes excepcionales. Ambos mecanismos resuelven objetivos de servicio distintos y pueden combinarse.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Cómo afecta la reducción de resolución de series temporales a la detección de anomalías en hogares inteligentes?
Descubre cómo el ancho de los intervalos, la agregación, el antialiasing, los datos faltantes, la duración de los eventos y la retención multiescala cambian...
¿Cómo combina una cuadrícula de ocupación las señales débiles del hogar inteligente?
Aprende cómo las celdas espaciales, los modelos de sensores, las actualizaciones de log-odds, la atenuación, la evidencia correlacionada y los umbrales convierten señales débiles...
¿Cómo afecta la normalización fotométrica a la agrupación privada de rostros?
Descubre cómo la corrección de la iluminación cambia los recortes faciales, los embeddings, las distancias entre clústeres, los umbrales, la sobrenormalización y la evaluación...
