Cuando AlphaFold2 revolucionó el descubrimiento de fármacos en 2020, su éxito dependió enteramente de las cerca de 170.000 estructuras de proteínas recolectadas por científicos desde 1971 y preservadas en el Protein Data Bank. La data medida es la columna vertebral de todos los modelos de IA, pero con el ritmo actual de sensores y detectores, nadie necesita esperar 50 años para acumular datos suficientes para hacer ciencia con IA.
El cuello de botella se mueve. Instalaciones como el Linac Coherent Light Source II (LCLS-II), que genera pulsos de fotones a una tasa de repetición de 1 MHz, o los modernos scanners CT industriales y radios definidos por software de alto ancho de banda, expulsan datos a tasas que la arquitectura clásica de "recolectar, almacenar, analizar" nunca fue diseñada para soportar.
NVIDIA DAQIRI (Data Acquisition for Integrated Real-time Instruments) propone una respuesta concreta: mover la adquisición de datos a una arquitectura adaptable centrada en software en lugar de la rigidez del diseño actual centrado en hardware. La librería forma parte del NVIDIA Holoscan Platform y conecta detectores y sensores de alto ancho de banda directamente al ecosistema de software NVIDIA: Holoscan para procesamiento multi-modal en tiempo real, TensorRT para inferencia, y nvCOMP para compresión streaming.
¿Qué problema resuelve DAQIRI?
El esquema tradicional almacena primero y procesa después. Con sensores modernos eso ya no escala. DAQIRI permite preprocesar la data en el origen, abriendo la posibilidad de mitigar pérdida de información del data deluge mientras acelera el camino entre la recolección y el descubrimiento científico.
Concretamente, los streams de instrumentos pueden ir directo a sistemas de supercomputación de borde equipados con una NVIDIA ConnectX NIC. Esos sistemas pueden ir desde un NVIDIA DGX Spark hasta una IGX Platform o soluciones de rack como RTX Pro Server o VR200, según la carga de cómputo que cada instrumento requiera.
El enfoque le da a los investigadores insight inmediato sobre la data entrante, mientras prepara salidas seleccionadas para procesamiento downstream en facilidades de supercomputación.
A-GHOST: rescatar datos que el LHC descarta
El upgrade High-Luminosity Large Hadron Collider (HL-LHC) en el CERN aumentará la luminosidad en un factor de 10 respecto al diseño original. Para procesar tasas de datos mucho más altas, el detector ATLAS actualizará su sistema de selección actual: seguirá siendo de dos etapas, pero ahora con un ancho de banda de eventos seleccionados de 1 MHz (antes 100 kHz) después de la primera etapa, y hasta 10 kHz (antes 1 kHz) después de la segunda etapa hacia almacenamiento. Aún con esta tasa aumentada, se rechazará más del 99% de todas las colisiones en el sistema online.
El proyecto A-GHOST usa DAQIRI para aplicar búsquedas con IA más potentes sobre el stream que el camino de selección nominal descarta. Para lograrlo, lleva las GPU más cerca de la data cruda del detector usando networking eficiente.
El esfuerzo R&D, liderado por CERN Openlab junto con científicos de la University of Chicago y UCL, explora un enlace streaming entre los tableros de FPGA personalizados planeados para el HL-LHC y una granja de procesamiento habilitada con GPU. La arquitectura permitirá análisis en tiempo real del stream completo desplegando modelos como Convolutional Auto-Encoders (CAEs), temporal Convolutional Neural Networks (TCCN) y arquitecturas basadas en transformers.
¿Cómo funciona DAQIRI por dentro?
DAQIRI está diseñada para manejar datos Ethernet de alto ancho de banda, incluyendo tráfico UDP y RoCE v2, a tasa de línea de cientos de Gbps. Para lograrlo, la arquitectura puentea completamente el kernel Linux.
Aprovechando el Data Plane Development Kit (DPDK), DAQIRI ofrece acceso zero-copy, ruteando data directamente desde el NIC a los buffers DMA de la GPU. Este mecanismo de bypass del kernel reduce la latencia y el overhead de CPU típicamente asociados con stacks de red tradicionales.
Características clave
- Alto throughput, baja latencia: tasa de línea en cualquier interfaz con tuning adecuado de hardware y CPU/NUMA
- Procesamiento de recepción customizado: reordenamiento automático de paquetes, conversión de tipo de dato, y flow steering basado en hardware
- Cero copias de memoria a GPU: acceso directo al ring buffer del NIC (batched + Header Data Split) hacia el tensor en GPU mantiene la latencia en tiempo de tránsito PCIe
- Configuración YAML: configuraciones de red optimizadas y editables para despliegue rápido
- Backends flexibles: Linux Sockets, DPDK y RoCEv2 según demanda
- APIs C++ y Python: aplicaciones tiempo real interconectadas con otras librerías GPU en minutos, no horas
Aunque el movimiento de datos subyacente depende de optimizaciones de red de bajo nivel, DAQIRI abstrae esa complejidad para los constructores de instrumentos. Los desarrolladores pueden orquestar el pipeline con APIs C++ y Python accesibles, configuradas vía archivos YAML legibles. En lugar de gestionar paquetes individuales o asignaciones manuales de memoria, DAQIRI agrupa automáticamente los paquetes entrantes directamente en tensores GPU.
Walkthrough: configurando un stream
Las aplicaciones DAQIRI parten con un archivo de configuración. El config describe el camino de los datos antes de que la aplicación corra: qué NIC usar, qué GPU posee los buffers de paquetes, cómo filtrar y cómo ensamblar los payloads recibidos para procesamiento downstream.
%YAML 1.2
---
daqiri:
cfg:
version: 1
stream_type: "raw" # Camino de alta velocidad DPDK/GPUDirect.
master_core: 3 # CPU para administrar DAQIRI.
log_level: "info"Después se definen las regiones de memoria GPU que usará. rx_packets es donde aterrizan los buffers crudos vía GPUDirect; rx_tensor es el tensor reordenado que consume la carga GPU. Los tamaños de buffer dejan explícita la expansión int4 a fp16.
memory_regions:
- name: "rx_packets"
kind: "device" # Paquetes aterrizan en memoria GPU.
affinity: 0 # GPU 0.
num_bufs: 16384
buf_size: 8192 # Headers + secuencia + 8000B payload.
- name: "rx_tensor"
kind: "device"
affinity: 0
num_bufs: 128
buf_size: 32768000 # 1024 paquetes * 8000 bytes int4 * 4 tras fp16.Luego se asocia la config a la interfaz de recepción física. Esto nombra el NIC por dirección PCIe, habilita aislamiento de flujo, y asigna una cola de polling.
interfaces:
- name: "rx0"
address: "0000:00:00.0"
rx:
flow_isolation: true
queues:
- name: "q0"
id: 0
cpu_core: 9
batch_size: 1024
timeout_us: 2000
memory_regions: ["rx_packets"]Finalmente, la regla de flujo restringe el tráfico aceptado al stream UDP esperado y envía paquetes coincidentes a la cola 0:
flows:
- name: "data_flow"
id: 100
action: {type: queue, id: 0}
match: {udp_src: 4096, udp_dst: 4096}La configuración de reorder convierte los payloads de los paquetes en la forma del tensor que la aplicación realmente quiere: salta headers de paquete, usa números de secuencia para restaurar el orden, agrupa 1024 paquetes, y convierte payloads int4 compactos en valores fp16 como parte del paso de reorder en GPU.
¿Por qué es relevante para LatAm?
Para grupos de investigación universitarios en la región que trabajan con FPGAs custom (sincrotrones, microscopía electrónica, software-defined radio) DAQIRI baja drásticamente la barrera de entrada. El esquema clásico requería ingeniería de protocolos de red bajo nivel; DAQIRI lo reemplaza con un YAML y un loop C++ corto. Combinado con un DGX Spark (hardware de tier inferior pensado para edge AI), un laboratorio chico puede armar un sistema de adquisición con inferencia online sin construir un clúster de servidores tradicional.
Los ejemplos del Cocktail Book en GitHub cubren configuraciones de hardware comunes y son editables para casos específicos.
