Investigadores de la Northeastern University, University of Minnesota y University of Connecticut publicaron SparseDitto el 5 de agosto de 2026 — un sistema que implementa agentes LLM para sintetizar kernels GPU personalizados para operaciones de matriz dispersa. Para la misma operación de matriz dispersa, cuSPARSE muestra una brecha de desempeño de 350x entre formatos de almacenamiento CSR y Blocked-ELL. Esa varianza no es un caso extremo — es el estado predeterminado de la computación dispersa.
Los kernels de matriz dispersa — SpMV, SpMM, SpGEMM — sustentan el entrenamiento de GNN, análisis de grafos y computación científica. El desempeño depende de cómo se distribuyen los valores distintos de cero y cómo eso se asigna a los patrones de acceso a memoria de GPU. CSR funciona bien para matrices con longitudes de fila irregulares. Blocked-ELL explota la regularidad para alcanzar Tensor Cores. COO, HYB y media docena de formatos generados por compilador cada uno tienen sus propios regímenes de desempeño. Antes de SparseDitto, el estado del arte era elegir un formato para todas las entradas (incorrecto la mayoría de las veces) o usar un clasificador ML estático para seleccionar entre un menú fijo de kernels existentes (limitado por lo que está en el menú).
SparseDitto descarta el menú. Su pipeline tiene tres etapas: un modelo aditivo ligero ingiere características estructurales de la matriz de entrada — distribución de longitud de fila, densidad de valores distintos de cero, regularidad de bloque — y clasifica estrategias de ejecución candidatas. Un planificador consciente de la arquitectura propone diseños de kernel ajustados a la jerarquía de memoria de la GPU objetivo. Los agentes de codificación y verificación implementan cada diseño, lo ejecutan en el hardware objetivo e iteran utilizando mediciones de latencia real como retroalimentación. El bucle se cierra en la GPU, no en simulación.
En una NVIDIA RTX PRO 6000, SparseDitto logra una aceleración de media geométrica de 2.68x sobre cuSPARSE en tres operadores dispersos y diversos benchmarks de matrices, con un pico de 146.61x. En un H200, la media geométrica es 2.79x, pico 78.5x. La brecha entre media geométrica y pico refleja la varianza subyacente: algunas matrices caen donde un kernel generado supera dramáticamente cualquier baseline de formato fijo; otras ven ganancias modestas.
El resultado operacionalmente más significativo es 3.39x: la aceleración en entrenamiento GCN de lote completo. El entrenamiento de GNN es donde las operaciones dispersas dominan el tiempo de ejecución total — la creación de perfiles del entrenamiento completo de GraphSAGE por lotes muestra que SpMM representa el 83.6% del tiempo total de entrenamiento. Una mejora de 3.39x en ese kernel se traduce directamente en el rendimiento del entrenamiento.
Dos restricciones prácticas importan. Primero, SparseDitto genera un kernel por cada triple matriz-operador-GPU. Para servicio de inferencia con matrices de peso disperso fijas, la generación es un costo offline único. Para entrenamiento con patrones de dispersidad que cambian dinámicamente — poda iterativa, esparsificación dinámica — las matemáticas de amortización cambian. Segundo, el sistema fue evaluado en RTX PRO 6000 y H200; el comportamiento en otras arquitecturas (A100, B200, AMD MI300X) aún no se ha caracterizado.
La arquitectura SparseDitto — clasificador basado en features → planificador de candidatos → agente de codificación LLM → verificación con hardware en bucle — es un patrón general para operaciones donde el desempeño es sensible al formato o sensible a la distribución de entrada. La atención dispersa, diseños personalizados de GEMM cuantizado y enrutamiento MoE esparsificado tienen la misma estructura: el desempeño varía 10–100x por opción de configuración, el ajuste estático es insuficiente y el espacio de soluciones es demasiado grande para búsqueda manual. SparseDitto prueba que los agentes LLM pueden cerrar ese bucle en hardware real.
Si su stack de GNN o inferencia dispersa ejecuta cuSPARSE con selección de formato predeterminada, está ejecutando el kernel incorrecto para sus matrices específicas en su GPU específica. La brecha puede ser cientos de x, no porcentaje.