¿Qué funciones permiten la conmutación por error de la GPU a la CPU en un servicio de IA local?
La conmutación por error de GPU a CPU solo funciona cuando el servicio planifica una ruta de ejecución secundaria compatible antes de que el agotamiento de memoria interrumpa una solicitud activa.
Un servidor de IA doméstico puede ejecutar transcripción, búsqueda de imágenes y un LLM en un mismo acelerador hasta que una solicitud larga lleva la memoria más allá de su límite seguro. Simplemente capturar un error de falta de memoria es demasiado tarde si el estado del modelo es incoherente. Una conmutación por error fiable combina control de admisión, pesos compatibles para CPU, estado de solicitud transferible, colas acotadas, señales de estado y una política clara de servicio degradado.
El control de admisión detecta la presión antes de que falle la asignación
La puerta de enlace estima los pesos del modelo, el crecimiento de la caché KV, los tensores temporales, el tamaño del lote y la fragmentación de memoria antes de aceptar una solicitud para GPU. La reserva de margen protege los kernels y las cargas de trabajo simultáneas, mientras que un umbral de presión decide si se debe retrasar, reducir, descargar o redirigir la solicitud.
la memoria KV paginada trata la memoria de la GPU como bloques paginados para que el servicio reduzca la fragmentación y comparta la capacidad de la caché KV de forma más eficiente. Esto eleva el límite operativo seguro, pero no crea memoria ilimitada ni sustituye una ruta de desbordamiento explícita.
Una decisión real de conmutación por error utiliza tanto el consumo previsto como el observado. Las lecturas de memoria libre por sí solas pueden inducir a error porque los asignadores en caché, los kernels pendientes y la reserva de otro servicio pueden ocupar espacio después de la comprobación, pero antes de la siguiente asignación.
La ruta de CPU debe reconstruir un estado del modelo compatible
La ejecución en CPU necesita el mismo tokenizador, revisión del modelo, semántica de cuantización, plantilla de instrucciones, configuración de muestreo y reglas de detención que la ruta de GPU. El servicio puede mantener una réplica de CPU activa, asignar los pesos en memoria mediante mapeo o cargarlos bajo demanda según su presupuesto de tiempo de recuperación.
la inferencia híbrida CPU-GPU demuestra una inferencia híbrida que aprovecha la escasez predecible de activaciones entre CPU y GPU en hardware de consumo. Su diseño muestra que la participación de la CPU puede planificarse como un modo de ejecución, en lugar de tratarse únicamente como una copia de emergencia.
Las solicitudes que ya han generado tokens son más difíciles de mover porque su caché KV y su estado aleatorio deben transferirse o recalcularse. Por ello, muchos servicios domésticos deberían activar la conmutación por error en los límites de las solicitudes y reintentarlas de forma idempotente, en lugar de prometer una migración fluida entre tokens.
El estado, las colas y el modo degradado limitan las consecuencias
Un disyuntor marca la GPU como no disponible después de fallos de asignación repetidos, reinicios del controlador o fallos en las comprobaciones de estado. El nuevo trabajo entra en una cola de CPU independiente con menor concurrencia, límites de contexto más cortos o un modelo de respaldo más pequeño, para que las solicitudes lentas no colapsen el equipo anfitrión.
la colocación de inferencia por niveles coordina la ubicación en CPU, GPU y almacenamiento para ejecutar modelos que superan la memoria del acelerador. Los resultados ilustran la gran diferencia de latencia entre caber en la memoria rápida y depender de niveles más lentos. Esta distinción sigue siendo visible durante las pruebas domésticas posteriores.
El límite del fallo consiste en fingir que la conmutación por error a CPU conserva el mismo nivel de servicio. Un modelo que tarda 20 segundos en GPU puede tardar minutos en CPU, y es posible que los kernels no compatibles ni siquiera se ejecuten. La interfaz debería mostrar el modelo de respaldo, los límites, el retraso estimado y la cancelación, en lugar de quedarse bloqueada en silencio.
Demuestra la conmutación por error bajo una presión de memoria controlada
Reproduce solicitudes cortas, solicitudes largas, solicitudes simultáneas y otra carga de trabajo de GPU mientras reduces gradualmente la memoria disponible. Activa el redireccionamiento previo a la admisión, un fallo de asignación antes de la generación, un reinicio del controlador y una cancelación durante la cola de CPU. El resultado intermedio debe seguir siendo inspeccionable antes de que la automatización continúe.
Compara los resultados con el límite de respaldo descrito en respaldo por memoria de GPU. Registra la tasa de éxito, los efectos secundarios duplicados, la equivalencia de tokens cuando corresponda, la latencia p95, la antigüedad de la cola, la RAM del equipo anfitrión, el tiempo de recuperación y si el usuario vio el estado del modo degradado.
Aprueba el sistema solo cuando no desaparezca ninguna solicitud aceptada y el redireccionamiento a CPU no pueda agotar la memoria del sistema. Si la migración durante una solicitud cambia el resultado o repite una acción de herramienta, limita la conmutación por error a puntos de control seguros y devuelve un error reanudable en todos los demás casos.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Qué funciones permiten establecer un límite de confianza de IA doméstica en torno a archivos confidenciales?
Descubre cómo la clasificación, el acceso limitado por capacidades, el análisis aislado, los filtros de recuperación, la política de salida, las aprobaciones y las...
¿Qué factores determinan si las copias de seguridad basadas en árboles de Merkle detectan cambios silenciosos de manera eficiente?
Aprende cómo el tamaño de los fragmentos, la ramificación, las raíces de confianza, los hashes almacenados en caché, la localidad de los cambios, el...
¿Qué componentes permiten realizar copias de seguridad verificables de índices de IA y del estado de los modelos?
Descubre cómo las instantáneas coordinadas, los manifiestos de contenido, las sumas de comprobación, los bloqueos de versión, los simulacros de restauración y las pruebas...
