¿Cómo afecta la localidad NUMA a la inferencia de IA doméstica con varias GPU?

La localidad NUMA afecta a la inferencia cuando los hilos de la CPU, la memoria del sistema y las GPU se comunican a través de dominios no locales en lugar de permanecer cerca de su ruta PCIe.

Un servidor doméstico de IA con dos sockets puede exponer dos grandes grupos de RAM y varias GPU como una sola máquina, pero el acceso no es uniforme. Un proceso programado en un socket puede preparar tensores en la memoria conectada al otro antes de transferirlos a una GPU situada bajo una raíz PCIe diferente. El impacto depende de la ubicación del modelo, la preparación en el host, el tráfico del paralelismo de tensores, la topología de interconexión, el procesamiento por lotes y de si la carga está limitada por el cómputo o por las transferencias.

NUMA Convierte un Grupo de Memoria en un Acceso Dependiente de la Distancia

En un sistema NUMA, cada socket de CPU o dominio de cómputo tiene memoria más cercana a algunos núcleos que a otros. El software puede direccionar la capacidad combinada, pero un acceso remoto debe atravesar una interconexión. Esa ruta suele tener una latencia y un ancho de banda disponible diferentes de los de la memoria local.

La topología NUMA también afecta al DMA de la GPU, porque las páginas del host pueden estar lejos del complejo raíz PCIe de la GPU. La planificación de la CPU y la ubicación de la memoria son decisiones independientes, y es posible que una máquina virtual no vea automáticamente la topología del host necesaria para alinearlas.

El efecto es pequeño cuando el tráfico de memoria del host es menor en comparación con el cómputo de la GPU. Aumenta durante la carga del modelo, la descarga de trabajo a la CPU, la tokenización, las copias a búferes fijados, las sincronizaciones frecuentes o las cargas que desbordan la VRAM. La capacidad NUMA no garantiza la localidad NUMA.

La Ubicación de las GPU Añade una Segunda Topología a la Ruta del Modelo

Varias GPU pueden estar conectadas a distintos sockets de CPU, conmutadores PCIe o particiones integradas en el encapsulado. Un tensor que se mueve entre dos aceleradores puede utilizar una ruta directa entre dispositivos, un enlace dedicado de GPU, un conmutador PCIe o una ruta que implique la memoria del host y un salto entre sockets. Estas rutas no son equivalentes.

Las investigaciones sobre GPU con múltiples particiones indican que el acceso no uniforme y la comunicación entre particiones pueden aumentar la contención y la latencia de los kernels. Las estrategias de ubicación varían según si los datos se comparten globalmente, parcialmente o solo dentro de un grupo de trabajo o una partición.

La partición del modelo debería seguir la topología que transporta la mayor parte del tráfico repetido. Las capas adyacentes o el estado de atención ubicados a través de una frontera lenta pueden comunicarse en cada token, mientras que una división con menos comunicación puede tolerar la distancia. Contar las GPU sin mapear sus enlaces oculta la relación relevante.

El Paralelismo de Tensores Puede Convertir la Localidad en un Coste por Token

La inferencia con paralelismo de tensores divide las operaciones de una capa entre varias GPU y combina los resultados parciales mediante operaciones colectivas. Esto puede permitir trabajar con modelos más grandes y utilizar más capacidad de cómputo, pero la comunicación se repite en muchas capas y tokens. Por tanto, una ruta remota se convierte en un coste recurrente, no en una penalización única de la carga del modelo.

El paralelismo de tensores funciona mejor cuando los enlaces entre aceleradores y la ubicación de los fragmentos admiten la sincronización necesaria. Añadir una GPU al otro lado de una frontera NUMA o PCIe más débil puede aumentar la capacidad y, aun así, ofrecer un incremento de rendimiento menor de lo que sugiere el número de dispositivos.

La colocación con paralelismo de datos o por solicitudes puede ser mejor cuando los modelos caben de forma independiente y las solicitudes pueden permanecer locales. El paralelismo de tensores se vuelve necesario cuando un modelo no cabe en un solo dispositivo, pero el tamaño del lote, la frecuencia de las operaciones colectivas y la interconexión determinan si la capacidad adicional también mejora la velocidad.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

El Primer Acceso y la Migración de Hilos Pueden Romper una Distribución Intencionada

Los sistemas operativos suelen ubicar la memoria cerca del hilo que accede por primera vez a cada página. Si la inicialización se ejecuta en un socket y los trabajadores de inferencia lo hacen después en otro, las páginas pueden permanecer remotas. La migración del planificador también puede alejar los hilos de preparación de la CPU de la memoria y la GPU a las que estaban destinados.

La conciencia NUMA conecta los bancos de memoria locales con los sockets de CPU que acceden a ellos de forma más eficiente. Fijar los hilos de la CPU sin controlar la asignación de memoria, o fijar la memoria sin alinear la GPU, solo resuelve una parte de la ruta.

Una distribución estable puede requerir afinidad de CPU, políticas de memoria, asignación de dispositivos y un lanzamiento de procesos consciente de la topología. Los contenedores y las máquinas virtuales añaden otra capa de mapeo. El objetivo no es fijarlo todo a ciegas, sino mantener las rutas de productores, búferes y consumidores de mayor volumen dentro del dominio práctico más cercano.

La Localidad Importa Más Durante Fases Específicas de la Inferencia

La carga del modelo hace hincapié en el movimiento del almacenamiento al host y del host a la GPU. El prellenado procesa muchos tokens del prompt y puede utilizar operaciones matriciales más grandes, mientras que la decodificación avanza repetidamente uno o unos pocos tokens y puede volverse sensible al ancho de banda de memoria, la sincronización y la sobrecarga del lanzamiento de kernels. Por tanto, los efectos de NUMA pueden cambiar dentro de una misma solicitud.

Los efectos NUMA de la GPU muestran que una planificación consciente de la ubicación puede mejorar la atención al alinear el trabajo con los dominios de memoria y la reutilización de la caché. La conclusión es más limitada que una mejora de velocidad universal: la ganancia aparece cuando el patrón de compartición del kernel coincide con el mapeo consciente de la topología.

Un benchmark que informe únicamente de los tokens por segundo medios puede ocultar una latencia elevada del primer token o un escalado deficiente con un lote concreto. Registra por separado el tiempo de carga, el rendimiento del prellenado, la latencia entre tokens, el tráfico de los enlaces de las GPU, los accesos NUMA remotos y el ancho de banda de memoria de la CPU.