Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Inferencia y orquestación de la CPU

Descripción general de

Las instancias de CPU son una opción de procesamiento de primera clase para una amplia gama de cargas de trabajo de IA en Amazon EKS. Desde modelos de lenguaje reducido (SLM) y la clásica inferencia de aprendizaje automático hasta canalizaciones de datos y orquestación de agentes, las CPU ofrecen una excelente relación precio-rendimiento, una amplia disponibilidad de capacidad y una semántica de programación familiar de Kubernetes.

La CPU y la GPU son complementarias, no competitivas. A medida que los procesos de inteligencia artificial de los agentes se van haciendo más complejos, la superficie de trabajo de la CPU crece con ellos: cada llamada de inferencia va acompañada de la ejecución de herramientas, el ensamblaje del contexto, la búsqueda vectorial, las barreras y la lógica de orquestación que se ejecuta en la CPU. Recomendamos diseñar arquitecturas que utilicen ambos tipos de procesamiento de forma deliberada, colocando cada carga de trabajo en el nivel en el que ofrezca la mejor relación costo-rendimiento.

No todas las cargas de trabajo necesitan una GPU. El enrutamiento, la clasificación, la recuperación, la incrustación, la orquestación y una parte cada vez mayor de la inferencia de modelos de lenguaje se ejecutan de forma eficaz en la CPU. Current-generation Las instancias de CPU de arm64 y x86 ofrecen una excelente relación precio-rendimiento para la inferencia de aprendizaje automático. En combinación con la consolidación de nodos de Karpenter, el escalado basado en eventos de KEDA y el servicio cuantificado de modelos, esto proporciona una solución lista para la producción que los equipos de plataformas pueden utilizar sin una gran experiencia en GPU.

Esta guía es para:

Qué aprenderá:

¿Por qué usar CPU para cargas de trabajo de IA?

Los canales de IA de producción distribuyen el trabajo en muchos niveles de cómputo. Las CPU gestionan el enrutamiento, la clasificación, la recuperación, la orquestación y una parte cada vez mayor de las inferencias. Current-generation Las instancias de CPU ofrecen una buena relación precio-rendimiento y una programación conocida de Kubernetes, lo que las convierte en una opción práctica para muchas cargas de trabajo de IA.

Hay tres factores que hacen que la CPU sea atractiva para estas cargas de trabajo:

Capacidad y disponibilidad

Las instancias de GPU suelen requerir reservas de capacidad con semanas de antelación. Las instancias de CPU están ampliamente disponibles en todas las regiones de AWS sin complementos de dispositivo especializados, sin configuración de DRA ni particiones MIG. Cuando necesite escalar rápidamente, la capacidad de la CPU es la opción más disponible.

Economía

Current-generation Las instancias de CPU ofrecen una buena relación precio-rendimiento para la inferencia de aprendizaje automático. Para los equipos que realizan FinOps revisiones o administran clústeres con varios usuarios, la diferencia de coste entre la CPU y la GPU es significativa, especialmente en el caso de los SLM cuantificados, en los que la aceleración de la GPU ofrece una rentabilidad decreciente. Recomendamos realizar una evaluación comparativa de las familias de instancias disponibles (Graviton, AMD e Intel) para encontrar el mejor coste por token para su carga de trabajo.

Simplicidad operativa

Los módulos de CPU utilizan la programación estándar de Kubernetes (afinidad de nodos requestslimits, distribución de topología). Sin complementos de dispositivo, sin programadores personalizados, sin tipos de recursos. nvidia.com/gpu Los equipos que desean ejecutar cargas de trabajo de IA sin una gran experiencia en GPU pueden acelerar la producción en la CPU.

Aumenta la superficie de la CPU en las canalizaciones de agentes

En los procesos de inteligencia artificial de los agentes, cada llamada de inferencia de la GPU va acompañada de trabajo de la CPU: ejecución de herramientas, ensamblaje del contexto, búsqueda vectorial, incrustación de búsquedas, barreras de protección, validación de respuestas, gestión de la memoria y lógica de orquestación. A medida que los agentes se hacen más complejos (más herramientas, cadenas más largas, razonamiento en varios pasos), estas cargas de trabajo de la CPU crecen de forma superlineal. Protocolos como el MCP (Model Context Protocol) lo amplifican aún más: cada llamada a la herramienta MCP desencadena la recuperación, la transformación y el formateo de datos que se ejecutan íntegramente en la CPU.

CPU o GPU/Trainium: ¿cuándo elegir cada una

Marco de decisiones sobre cargas de trabajo

La elección del cómputo adecuado para una carga de trabajo de IA se reduce a cuatro dimensiones:

Utilice la siguiente tabla como matriz de decisiones.

Flujo de trabajo comparativo rápido

Antes de decidirte por una familia de instancias, te recomendamos realizar una evaluación comparativa estructurada en la que se comparen las familias de CPU candidatas (arm64 y x86) con las de GPU en función de una única métrica comparable: el coste por cada 1000 consultas con la latencia de p95 objetivo. Implementa un nodo por familia con una configuración de modelo idéntica (misma cuantificación, tamaño de contexto y número de subprocesos), realiza pruebas de carga para cada uno de ellos y compara. Si una instancia de CPU cumple con el SLO de tu p95, es probable que gane en cuanto a costes. Si no lo consigue por un pequeño margen, prueba la última generación de esa familia antes de pasarte a la GPU. Si la latencia sigue siendo demasiado alta en tu objetivo de simultaneidad, esa es la señal para transferir la carga de trabajo a la GPU.

Patrones de producción

Patrón 1: IA de agencia: SLM Pre-Filter en la CPU con escalación de LLM

La mayoría de los flujos de trabajo de los agentes ejecutan los mismos patrones restringidos de forma repetida: clasifican la solicitud, eligen una herramienta, extraen datos estructurados y validan una respuesta. Estas tareas no requieren un modelo de 70 B de parámetros.

Las investigaciones sobre los SLM (ar Xiv:2506.02153) demuestran que los modelos con parámetros inferiores a 10 000 B, cuando se especializan para un dominio, pueden igualar o superar a los LLM de gran tamaño en subtareas restringidas y, al mismo tiempo, funcionar de manera eficiente en la CPU con un coste y una latencia significativamente más bajos. Cuando un modelo se ajusta con precisión para un dominio específico, su menor tamaño hace que sea más preciso y económico que recurrir a un LLM de uso general.

En este patrón, un SLM en la CPU gestiona la mayoría de las solicitudes de principio a fin. Una capa de enrutamiento (que también se ejecuta en la CPU) escala solo los casos realmente complejos a un GPU-hosted LLM.

Componentes que se ejecutan en la CPU:

Componentes de: GPU/Trainium

Por qué funciona este patrón: en muchos flujos de trabajo de agencias, un SLM puede clasificar o extraer del 60 al 80% de las solicitudes. Por cada llamada de LLM que evites, también evitas el trabajo de la CPU que supone armar una ventana de contexto de gran tamaño, poner barreras en caso de respuesta prolongada y gestionar estados complejos. El nivel de CPU se escala de forma independiente del nivel de GPU.

Las categorías de carga de trabajo de la CPU en una canalización de agencias típica incluyen: ejecución de herramientas (llamadas al servidor MCP, llamadas a la API, consultas a bases de datos), ensamblaje de contextos, búsqueda vectorial e incrustación de búsquedas, lógica de orquestación y planificación, filtros de seguridad y barreras de seguridad, validación y formateo de respuestas, memoria de agentes y administración del estado, y. logging/observability

Este patrón también se ajusta a un ciclo de vida de ajuste preciso: recopile datos de dominio en los nodos de la CPU, realice ajustes en la GPU y, a continuación, vuelva a implementar el modelo cuantificado en la CPU para realizar inferencias a un costo sustancialmente menor que un punto final LLM. Una investigación de LoRa Land (ar Xiv:2405.00732) muestra que los modelos 7B ajustados tienen un rendimiento superior GPT-4 en la mayoría de las tareas de dominio específicas probadas, lo que hace que la opción de «ajustar un modelo pequeño y ejecutarlo en la CPU» sea viable para muchos casos de uso de producción.

Patrón 2: CPU Model Farm High-Density

Los canales de aprendizaje automático de producción utilizan de forma rutinaria cientos o miles de modelos más pequeños: incrustaciones, recomendadores, clasificadores, calificadores y modelos de visión artificial BERT-based . Estos modelos, que son ligeros por sí solos, se vuelven caros cuando a cada uno se le asignan sus propios recursos de GPU.

Recomendamos un servicio de CPU de alta densidad (agrupar varios modelos por nodo TorchServe o utilizar Triton en la CPU), con Karpenter gestionando el ciclo de vida de los nodos y KEDA escalando en función de la carga observada.

Este patrón se extiende de forma natural a las arquitecturas RAG: la incrustación, la generación, la fragmentación de documentos y la recuperación, OpenSearch todo ello se ejecuta de forma rentable en los nodos de la CPU, y los resultados se envían a un LLM solo para el último paso de generación. GPU-hosted La granja de CPU gestiona el volumen; la GPU, la complejidad.

Para los sectores regulados (servicios financieros, sanidad, gobierno), este patrón es especialmente atractivo: cientos de modelos especializados que se ejecutan en la VPC en la CPU, con registros de auditoría completos y datos que nunca salen de la cuenta. El requisito de conformidad para la autogestión de las inferencias se alinea naturalmente con la ventaja económica que supone la CPU para los modelos sub-8B.

Mejores prácticas de optimización

Cuantización

No es práctico ejecutar un modelo 7B con un BF16 completo en la CPU; ejecutarlo con la cuantificación del cuarto trimestre es viable y rentable. Comprender por qué la cuantificación ayuda a la CPU es clave para tomar buenas decisiones de infraestructura.

Por qué la cuantificación es importante para la inferencia de la CPU. La inferencia de la CPU depende del ancho de banda de la memoria, no del cómputo. Durante la fase de decodificación (generación de los tokens de uno en uno), se leen todos los pesos del modelo en la RAM para cada token producido. La CPU pasa la mayor parte del tiempo esperando a que lleguen los datos de la memoria, no haciendo cálculos. Un modelo 7B con el modelo BF16 ocupa aproximadamente 14 GB; en el modelo Q4_K_M, se reduce a unos 4 GB. Como el obstáculo es el traslado de bytes de la RAM a los núcleos de la CPU, un modelo 3,5 veces más pequeño lee 3,5 veces más rápido, lo que se traduce casi directamente en una generación de fichas 3,5 veces más rápida. Esta es la razón por la que la cuantificación es la optimización más impactante para la inferencia de la CPU y por la que las nuevas generaciones de CPU con más canales de memoria producen inferencias más rápidas incluso a la misma velocidad de reloj.

Recomendamos crear su motor de inferencia con backends optimizados para la arquitectura (ARM NEON/SVE2 para arm64, AVX-512/AMX para x86), establecer el recuento de subprocesos igual al recuento de vCPU y seleccionar los formatos de cuantificación Q4_K_M o Q8_0.

En los modelos sub-2B, la CPU gana en relación precio-rendimiento frente a la GPU. Estos modelos son lo suficientemente pequeños como para que la aceleración de la GPU proporcione un beneficio mínimo, mientras que el costo por hora es significativamente mayor. Si su carga de trabajo puede utilizar un modelo inferior a 2B, la CPU es el valor predeterminado recomendado.

Architecture-specific optimizaciones: en arm64, las instancias Graviton de la generación actual son compatibles con el SVE2. Cree su motor de inferencia con la bandera adecuada para su objetivo. -march En la versión x86, son compatibles AVX-512 con las instancias EPYC de AMD y las instancias Intel Xeon añaden AMX para la aceleración matricial. Como la inferencia depende del ancho de banda de la memoria, las nuevas generaciones de CPU con más canales de memoria DDR5 producen inferencias más rápidas incluso a la misma velocidad de reloj. Al elegir los tipos de instancias, priorice el ancho de banda de la memoria por encima del número de núcleos.

Dimensionamiento de la ventana de contexto: en el caso de las cargas de trabajo de clasificación y enrutamiento, las entradas suelen tener menos de 200 fichas y las salidas, de 2 a 3 fichas. Si se establece una ventana de contexto pequeña (por ejemplo, 512 fichas) en lugar de la predeterminada de 2048, se reduce el uso de memoria caché en KV y se mejora la latencia por solicitud. Aumente la ventana de contexto únicamente si las entradas son realmente largas.

Flash Attention: active Flash Attention si su motor de inferencia lo admite. Flash Attention reduce el uso de memoria para el cálculo de la atención al evitar la materialización de toda la matriz de atención. En la CPU, el beneficio es menor que en la GPU, pero sigue siendo útil para entradas más largas.

Bin-packing para un servicio denso

Para los modelos clásicos de aprendizaje automático e incrustación (normalmente de menos de 500 MB cada uno), el objetivo es la máxima densidad de pods por nodo con una latencia de cola estable. Hay dos factores que determinan si lo logras: solicitudes de recursos precisas y subprocesos controlados.

Base su uso observado requests de p50-p90 bajo una carga realista. Utilice Ricitos de Oro, recomendaciones de VPA o histogramas de Prometheus de una prueba de carga. Los valores predeterminados casi siempre son incorrectos en ambas direcciones.

Las bibliotecas ML (PyTorchONNX Runtime, MKL, OpenBLAS) generan tantos subprocesos como vCPU pueden ver en el nodo, no las CPU asignadas al pod. En un nodo denso con 20 pods, cada pod intenta generar 32 subprocesos. El nodo se acelera al cambiar de contexto y la latencia de p99 aumenta. Corrija esto de forma explícita:

env:
  - name: OMP_NUM_THREADS
    value: "2"          # match your cpu request (2000m = 2 threads)
  - name: MKL_NUM_THREADS
    value: "2"
  - name: OPENBLAS_NUM_THREADS
    value: "2"
  - name: INTRA_OP_NUM_THREADS    # PyTorch / ONNX Runtime
    value: "2"
  - name: NUM_INTER_THREADS
    value: "1"          # keep inter-op parallelism minimal

Establezca cada valor igual o inferior a su solicitud de CPU. Para los módulos con más de 4 núcleos, el punto de referencia comienza con 2 a 4 subprocesos. Muchos modelos pequeños funcionan mejor con menos subprocesos debido a la eficiencia de la memoria caché. Si usa HPA con muchos módulos delgados, casi siempre ganan entre 1 y 2 subprocesos por módulo.

Programación y optimización de costes

Dos prácticas se combinan para reducir considerablemente los costes de inferencia de la CPU: las instancias puntuales con la consolidación de Karpenter y las imágenes de contenedores de varios arcos.

La consolidación de Karpenter funciona bien para la inferencia de la CPU, ya que los módulos de inferencia sin estado situados detrás de una cola o un balanceador de carga toleran las interrupciones sin problemas. Configure la consolidación para actuar en los nodos infrautilizados con un presupuesto que limite las interrupciones simultáneas (por ejemplo, el 20% de los nodos a la vez) a fin de evitar caídas de capacidad durante la reducción de la escala. Las nodePool especificaciones de Karpenter permiten combinar Spot y On-Demand capacidad en un solo grupo, con Spot como la opción preferida y como alternativa. On-Demand

La creación de imágenes con varios arcos (arm64yamd64) desbloquea aún más esta funcionalidad. Con ambas arquitecturas disponibles, Karpenter puede seleccionar entre una amplia gama de familias de instancias (Graviton, AMD, Intel) en función del precio y la disponibilidad en tiempo real. Esto resulta especialmente útil para las cargas de trabajo puntuales, en las que la diversificación entre tipos de instancias y arquitecturas reduce la frecuencia de las interrupciones. Utilice docker buildx una canalización de CI con compilaciones multiplataforma para producir un único manifiesto que abarque ambas arquitecturas.

Optimización del inicio de contenedores

Cuando Karpenter aprovisiona un nuevo nodo (ampliándolo o reemplazándolo por Spot), el motor de ejecución del contenedor debe extraer la imagen de inferencia antes de que el pod pueda iniciarse. En el caso de imágenes de inferencia de varios GB, esto puede añadir entre 30 y 60 segundos al inicio del pod.

Recomendamos usar Bottlerocket como sistema operativo de nodo para las cargas de trabajo de inferencia, en combinación con el snapshotter SOCI en modo paralelo. pull/unpack SOCI reemplaza la extracción secuencial de capas predeterminada por descargas basadas en fragmentos paralelos, lo que reduce significativamente los tiempos de extracción de imágenes para imágenes de gran tamaño. No es necesario realizar cambios en las imágenes del contenedor.

Para obtener una guía de configuración detallada, consulte la sección Rendimiento de esta guía, que trata sobre la configuración de SOCI, la extracción previa de instantáneas de EBS y las estrategias de caché en tiempo de ejecución de los contenedores.

Observabilidad

Sin observabilidad en la capa del modelo, se escala a ciegas. Recomendamos exponer las métricas de Prometheus para cada servicio de inferencia y utilizarlas para impulsar los paneles operativos y de escalado de KEDA.

La mayoría de los servidores de inferencia (llama.cpp, vLLM, Triton) exponen las métricas en un punto final. TorchServe Prometheus-compatible /metrics Los nombres de las métricas varían según el servidor, pero los conceptos son los mismos.

Métricas clave para instrumentar:

Escalado automático: escala en función de la profundidad de la cola, no del uso de la CPU

La utilización de la CPU es una métrica de saturación. Alcanza su punto máximo cuando la latencia ya se ha degradado. Cuando el escalado automático basado en la utilización reacciona, los usuarios ya están esperando.

La profundidad de las colas (solicitudes deferred/waiting) es uno de los principales indicadores. Aumenta antes de que disminuya la latencia, ya que las solicitudes comienzan a ponerse en cola cuando todos los espacios de procesamiento están ocupados. Al aumentar la profundidad de las colas, se aprovisionan nuevas réplicas mientras las existentes siguen respondiendo con normalidad.

KEDA admite la combinación de múltiples métricas en una sola fórmula de escalado mediante scalingModifiers (requiere KEDA 2.12+). El patrón recomendado para las cargas de trabajo de inferencia consiste en combinar las solicitudes en curso con las solicitudes en cola, lo que supone una gran ponderación de la métrica de colas:

advanced:
  scalingModifiers:
    formula: "running + (waiting * 10)"
    target: "25"
    activationTarget: "5"

La fórmula running + (waiting * 10) significa que incluso 3 solicitudes en cola elevan la métrica combinada a 55, muy por encima del objetivo de 25. El escalado se activa antes de que la latencia disminuya. El valor activationTarget de 5 evita que el ruido desencadene eventos innecesarios de escala desde cero.

Evaluación de la calidad del modelo para las cargas de trabajo CPU-First

La implementación de un SLM cuantificado en la CPU es una decisión de costo y latencia. Solo tiene sentido si el modelo sigue produciendo resultados correctos y útiles para su carga de trabajo.

Los modelos más pequeños o la cuantificación reducen los costes informáticos, pero pueden reducir la calidad. El impacto varía. Las cargas de trabajo que funcionan bien en la CPU (clasificación, extracción, enrutamiento, resumen, incrustaciones) suelen conservar una buena calidad en el B-7B rango de 3 si cuentan con la cuantificación y los avisos adecuados.

¿Qué evaluar

Las diferentes cargas de trabajo se degradan de diferentes maneras:

Un flujo de trabajo de evaluación práctico

Recomendamos crear un control de calidad antes de la producción, de forma similar a como se realizaría una prueba de carga antes de elegir un tipo de instancia. El flujo de trabajo consta de cuatro etapas:

¿Cómo recuperar la calidad

Si el modelo funciona mal, pruebe lo siguiente en orden de esfuerzo:

Referencias