gpu4j
Álgebra matricial y precisión media, en Java puro
Versión 0.4.0 · Java 17+ · Apache-2.0 · io.github.craton-co:gpu4j-core
Las operaciones que un modelo realmente ejecuta
Un transformer se pasa la vida multiplicando matrices. gpu4j pone esa operación — junto con la precisión media y los pesos residentes — detrás de una llamada Java tipada, para que la inferencia y la preparación de datos corran dentro de tu aplicación JVM y no al lado, en un servicio aparte.
Los pesos del modelo dominan la memoria de la GPU, así que la precisión media no es una microoptimización: define si un modelo entra en el hardware que ya tenés. gpu4j almacena los operandos en binary16 mientras acumula en precisión completa, reduciendo a la mitad la memoria que ocupa un tensor de pesos sin ceder la exactitud que importa a las profundidades que usa un transformer.
Y la integración sigue siendo mínima. Sin kernels que escribir, sin toolchain de CUDA en tus máquinas de build, sin puente a Python y sin una segunda base de código que mantener sincronizada: el núcleo numérico vive en la misma aplicación, el mismo proceso y el mismo despliegue que los datos sobre los que opera.
| Kernel de cómputo (16,7M+ elementos) | CPU (HotSpot C2) | TornadoVM GPU | CratonVM GPU | vs HotSpot | vs TornadoVM |
|---|---|---|---|---|---|
| Cadena de divisiones enteras | 2.179 ms | 27 ms | 7 ms | 311x más rápido | 3,9x más rápido |
| Cadena de divisiones en doble precisión | 1.784 ms | 135 ms | 82 ms | 21,8x más rápido | 1,6x más rápido |
| 128 multiplicaciones-sumas por elemento | 1.298 ms | 26 ms | 7 ms | 185x más rápido | 3,7x más rápido |
| Reducción de producto punto | 1.168 ms | no implementado | 2 ms | 584x más rápido | n/d |
| Kernel de ray tracing, 7680x4320 | 837,1 ms | 24,29 ms | 12,29 ms | 68x más rápido | 2,0x más rápido |
Medido en una RTX 2060 con el viaje completo host→dispositivo→host, y cada resultado verificado por checksum bit a bit contra HotSpot. Estas son las cifras de CratonVM, el runtime sobre el que se ejecuta gpu4j. La metodología completa se publica junto con CratonVM.
El pipeline que ya tenés, acelerado en el lugar
Tus jobs de Spark, tus operadores de Flink, tus transformaciones ETL y tus funciones de scoring ya están escritos en Java. Las etapas numéricas que dominan tu tiempo de reloj pueden pasar al acelerador sin convertirse en un servicio aparte.
Ningún servicio nuevo en el diagrama
gpu4j es una biblioteca en tu classpath, no un sidecar que operar. El trabajo acelerado corre en el mismo proceso que la aplicación dueña de los datos, lo que elimina el salto RPC, el costo de serialización y la segunda guardia de on-call que trae consigo un servicio de cómputo separado.
Movimiento de datos que no se come la ganancia
Llevar los datos al acelerador y traer los resultados de vuelta es donde muchas integraciones con GPU pierden en silencio su ventaja. gpu4j mueve los arreglos en bloque a la velocidad del hardware, así que la aritmética que pagaste es la aritmética que obtenés.
Reducciones que las alternativas no cubren
El producto punto y las reducciones son la base de la búsqueda por similitud, el scoring y la analítica. El motor las acelera 98x respecto de una JVM de producción — una carga que el principal framework Java para GPU no implementa en absoluto.
Testeable en el pipeline que ya tenés
Una biblioteca de GPU que solo funciona sobre hardware de GPU es una biblioteca que tu CI no puede testear. Un backend sustituto se instala en una línea, así que el código que tu equipo escribe contra esta API se testea en cualquier agente de build, sin dispositivo.
La Ventaja Técnica
Por qué los expertos eligen gpu4j
Datos que permanecen en el dispositivo
GpuArray es un búfer residente en el dispositivo con un ciclo de vida real. Los pesos que se suben una vez quedan residentes entre llamadas, así que un paso de decodificación que multiplica por los mismos pesos en cada token paga la transferencia una sola vez y no por token — la diferencia entre una demo y un despliegue. También hay reserva exclusiva en dispositivo para resultados intermedios que el host nunca lee.
Un modelo de orden que ya conocés
GpuStream y GpuFuture son el modelo de concurrencia que cualquier desarrollador Java ya maneja. El trabajo de un mismo stream se ejecuta en orden y los streams independientes se solapan, de modo que podés encadenar una secuencia larga y esperar una sola vez al final, o esperar cada paso cuando necesitás su resultado. La transposición es una lectura, no una copia: cualquiera de los operandos se lee transpuesto en el lugar, sin tensor duplicado.
Correcto antes que rápido
Cada resultado acelerado se verifica bit a bit contra la JVM estándar. Cuando el runtime no puede garantizar una respuesta idéntica, ejecuta tu método en CPU en lugar de adivinar, y te explica por qué. Una aceleración que cambia tus números es un riesgo, no una característica.
Equipos para los que fue construido
Equipos de plataforma de IA/ML
Equipos que sirven modelos desde un stack JVM y quieren álgebra matricial y precisión media sin levantar un servicio Python al lado de su aplicación.
Equipos de ingeniería de datos
Equipos cuyos pipelines de Spark o Flink están limitados por etapas numéricas y prefieren acelerarlas en el lugar antes que partir el pipeline entre dos runtimes.
Equipos de plataforma Java
Equipos que mantienen un parque Java grande y necesitan rendimiento de GPU sin sumar un perfil de contratación CUDA ni una segunda base de código.
Equipos cuantitativos y científicos
Equipos que hacen álgebra lineal densa sobre la JVM y necesitan resultados predecibles y verificados bit a bit, no una respuesta rápida de procedencia incierta.
Agregá una sola dependencia
<dependency>
<groupId>io.github.craton-co</groupId>
<artifactId>gpu4j-core</artifactId>
<version>0.4.0</version>
</dependency>gpu4j: la GPU, desde el Java que realmente escribirías. Desarrollado por Craton Software Company.
gpu4j está en desarrollo activo. Las cifras de GPU se midieron en una NVIDIA RTX 2060 y varían según el hardware, el tamaño del problema y la forma de los datos; las cifras de selección de kernel son del lado del dispositivo y las de sobrecarga de lanzamiento son del lado del host, y ninguna es la latencia de una llamada de extremo a extremo, que incluye además la transferencia host↔dispositivo. Los benchmarks comparativos mantienen el hardware constante y varían sólo el software. El lado del dispositivo requiere CratonVM compilado con soporte de GPU y una GPU NVIDIA. Java es una marca registrada de Oracle y/o sus filiales.