Dweve

Core por dentro: más de 2.900 operaciones en 12 backends

Cientos de miles de kernels ajustados a mano. Más de 2.900 operaciones en 76 categorías. 25 formatos numéricos y 12 backends. Así es Core, la base de...

Core por dentro: más de 2.900 operaciones en 12 backends

Qué nos dice el número de operaciones

La multiplicación de matrices parece una sola tarea. Sin embargo, su implementación depende del significado de los valores, de cómo se almacenan, de cómo se acumulan los resultados parciales y del hardware que ejecuta el trabajo. Una matriz binaria empaquetada y otra de coma flotante pueden compartir una operación abstracta y, aun así, necesitar reglas numéricas y código distintos.

Core es la base de cómputo de Dweve para entrenamiento e inferencia. Su catálogo público reúne cientos de miles de kernels ajustados a mano para más de 2.900 operaciones en 76 categorías, 25 formatos numéricos y 12 backends. Estas cifras describen partes distintas del sistema. Una operación da nombre al cálculo. Un formato numérico define la representación. Un backend identifica el destino de ejecución. Un kernel implementa una combinación concreta de esas opciones.

Entender esta distinción es más útil que tratar el catálogo como una única cifra de funcionalidades. Un desarrollador necesita saber si existe la combinación que necesita y qué contrato sigue.

Más de 2.900 operaciones en 76 categorías; 25 formatos numéricos; 12 backends. Cientos de miles de kernels ajustados a mano implementan las opciones de ejecución disponibles.

El cálculo y su representación van de la mano

Pensemos en una reducción: tomar un conjunto de valores y combinarlos para obtener un resultado. La palabra «suma» deja varias preguntas sin respuesta. ¿Son las entradas enteros con signo, valores de punto fijo o de coma flotante? ¿Qué representación almacena el resultado acumulado? ¿Qué ocurre si el siguiente valor no cabe en ella?

Core vincula estas opciones a la operación. Su contrato de ejecución incluye el tipo de dato, el ancho, el empaquetado, el acumulador, el backend, el conjunto de instrucciones, la política de despacho y el modo de determinismo. Cambiar cualquiera de estos elementos puede cambiar el significado del cálculo, aunque la operación conserve el mismo nombre.

Los 25 formatos numéricos abarcan familias binarias, ternarias, enteras, de punto fijo, adaptativas y de coma flotante. El nombre de una familia es solo el punto de partida para describir la aritmética. También importan el ancho, el signo, la escala y la disposición en memoria. Por eso, el catálogo debe leerse como un conjunto de combinaciones disponibles, no como una garantía de que cada operación exista en todos los formatos imaginables y en cualquier destino.

Un formato de intercambio tampoco resuelve todas las cuestiones de ejecución. ONNX describe un grafo de cálculo con entradas, salidas y operadores tipados. Así, los sistemas comparten una descripción del modelo, pero el entorno de ejecución sigue teniendo que implementar esos operadores. La documentación de conceptos de ONNX explica esta diferencia entre representar el grafo y ejecutarlo.

Para entender una opción de ejecución, ten en cuenta la operación, la representación, el acumulador, el backend y las reglas de repetición. Este diagrama muestra un ejemplo representativo, no una matriz de cobertura.

12 backends y opciones de ejecución explícitas

Los 12 backends de Core abarcan ejecución escalar, conjuntos de instrucciones de CPU y destinos GPU y portátiles. La lista pública incluye Scalar, SSE2, AVX2, AVX-512, NEON, SVE2, CUDA, ROCm, Metal, Vulkan, WebGPU y WASM. Son rutas de ejecución dentro de Core, no versiones distintas de un modelo.

El despacho selecciona en el host actual una implementación compatible con la operación y su contrato de ejecución. La ruta elegida queda registrada junto con su celda de ejecución, el host y el motivo de la selección. Así se pueden inspeccionar las opciones que se aplicaron realmente en cada ejecución.

La portabilidad también tiene límites. Por ejemplo, la documentación de WebAssembly distingue entre un formato binario portátil y las API que ofrece el entorno anfitrión. La ejecución en un navegador y fuera de él puede dar acceso a interfaces distintas. La documentación de portabilidad de WebAssembly aporta contexto sobre esta diferencia. La etiqueta de un backend, por sí sola, no describe el entorno de una aplicación.

El lugar de Core dentro de Dweve

Core utiliza la biblioteca de primitivas para las operaciones fundamentales y las integra en el sistema de cómputo. Loom se construye sobre Core y utiliza la biblioteca de solvers para sus tareas de razonamiento. Cada componente tiene una responsabilidad clara: las primitivas proporcionan operaciones básicas, Core ejecuta los cálculos y Loom construye su razonamiento sobre esa base.

Dweve es el servicio. Fabric es su API y portal, a través del cual personas y aplicaciones acceden al servicio. Fabric no sustituye la función de cómputo de Core ni la función de razonamiento de Loom. La interfaz y los sistemas que la respaldan tienen propósitos distintos.

Core utiliza la biblioteca de primitivas. Loom se construye sobre Core y utiliza la biblioteca de solvers. Fabric es la API y el portal del servicio Dweve.

Empieza por la ejecución que necesitas

Al evaluar un sistema de cómputo, empieza por un cálculo concreto y la representación que requiere. Después, pregunta qué backend lo ejecutará, qué reglas se aplican al acumulador y al empaquetado, y qué contrato de repetición se declara. Así, el catálogo se convierte en una herramienta útil para el equipo.

Las cifras públicas de Core describen la amplitud del catálogo. El contrato de ejecución explica cómo interpretarlo. Ambos aspectos deben considerarse juntos: qué trabajo cubre el sistema y qué implica usar una implementación concreta.