CratonVM
El runtime de Java para inferencia de IA y Big Data a escala
Versión 0.3.0 · Java SE 8–25 · 2M+ líneas de Rust · 20K+ tests automatizados · por Craton Software Company
El bytecode que ya tenés es la entrada.
Compilás con javac y ejecutás con un flag. El analizador lee tu bytecode, decide qué métodos puede bajar a PTX garantizando un resultado idéntico, y mueve esos. Todo lo demás corre en el JIT.
No es un diagrama de la arquitectura, sino un modelo vivo de ella. Tres mecanismos a la vez, con los objetos reales atravesándolos.
Arriba, el analizador bifurca cada método: lo que puede demostrar equivalente va a PTX y al dispositivo; el resto, al JIT. Abajo a la izquierda, un método sube de nivel, y el intérprete sigue ejecutándose mientras el worker de fondo lo compila, porque la generación de código es off-thread por defecto. Abajo a la derecha, las asignaciones caen al heap y ZGC lo marca de forma concurrente, sin detener el programa de arriba.
Java gobierna tu capa de datos y casi nada de tu cómputo.
Reescribir el kernel
En CUDA C, o en un framework que te pide reestructurar el trabajo en torno a su propia API de grafos y anotar cada bucle paralelo. En cualquiera de los dos casos ya hay un segundo lenguaje en code review, un segundo build y un artefacto nativo por plataforma en tu pipeline de release.
Sacar la carga afuera
A un servicio Python, donde tus datos salen de la JVM en cada llamada y donde acabás de sumar un segundo despliegue, una segunda guardia de on-call, una segunda superficie de autenticación y un salto de red en medio de un bucle caliente.
O cambiar el runtime
CratonVM elimina la frontera en lugar de moverla. Tu bytecode es la entrada; la GPU es un destino al que el runtime ya sabe llegar.
cargo build --release -p cratonvm-cli --features gpu-driver
./target/release/cratonvm --gpu -c . MyPipeline
# y para ver cada veredicto y su razón:
./target/release/cratonvm --gpu --print-gpu-decisions -c . MyPipelineEl mismo hardware. Sólo varía el software.
TornadoVM es el framework de GPU para Java más conocido y la comparación justa. Te pide anotar kernels, reestructurarlos en torno a una API TaskGraph y adoptar tipos de arreglo nuevos antes de mover una sola línea. CratonVM no pide nada de eso.
| Kernel de cómputo (16.7M+ elementos) | CPU (HotSpot C2) | TornadoVM GPU | CratonVM GPU | vs HotSpot | vs TornadoVM |
|---|---|---|---|---|---|
| Cadena de división de enteros | 2.179 ms | 27 ms | 7 ms | 311x más rápido | 3.9x más rápido |
| Cadena de división de 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/elemento | 1.298 ms | 26 ms | 7 ms | 185x más rápido | 3.7x más rápido |
| Reducción dot-product (int·int → long) | 1.168 ms | no implementado | 2 ms | 584x más rápido | — |
| Kernel de ray tracing (33.2M píxeles) | 837 ms | 24.3 ms | 12.3 ms | 68x más rápido | 2.0x más rápido |
Medido el 2026-09-07 en un host verificado como inactivo: RTX 2060, TornadoVM 4.0.1 (backend PTX), N = 2²⁴, mejor de 5, en caliente, viaje completo host→dispositivo→host. Cada columna de una fila se ejecutó en la misma sesión, incluidas las líneas base de CPU, así que las columnas son comparables entre sí; y esas líneas base reprodujeron casi exactamente las de la corrida anterior, que es la comprobación de que el montaje es sólido. La fila del ray tracer viene de una medición anterior y no se volvió a correr.
La fila «no implementado» no es un hueco de nuestra tabla. TornadoSnippetReflectionProvider.forBoxed es un stub incondicional tanto en el jar 4.0.1 como en el master actual, así que un kernel @Reduce que necesita ensanchar int→long antes de acumular en un arreglo de reducción de otro tipo no puede ejecutarse ahí. Lo aislamos con tres reproducciones mínimas en la misma GPU en lugar de inferirlo de un stack trace.
Dos teselados, elegidos por la forma de tu salida.
CratonVM incluye GEMM —el cálculo detrás de cada capa de red neuronal, cada bloque de atención y cada pase de inferencia— como kernel de GPU integrado, en fp32 y en fp16. No un único kernel que finge servir para toda forma:
Tesela de 128×128
Mejor intensidad aritmética —64 FMA por cada 16 cargas compartidas— pero cubre un problema de 256×256 en cuatro bloques y deja ociosa la mayor parte de un dispositivo de 30 SM. 58% más rápido en N=1024.
Tesela de 64×64
Menor intensidad por bloque, cuatro veces más bloques, y suficientes para llenar la máquina en tamaños modestos. 67% más rápido en N=256.
El ganador se invierte
Las cabezas de atención pequeñas y las capas de proyección grandes quieren respuestas opuestas. El host elige según el tamaño de la salida, así que obtenés la correcta sin pedirla.
Para el Java que quiere llamar a esto directamente en lugar de depender del offload automático, gpu4j es la API tipada sobre este runtime: GpuBlas, GpuArray residente en el dispositivo, Half en fp16, streams y captura de grafos CUDA — una sola dependencia Maven, sin toolchain de CUDA y sin JNI.
Rendimiento, disponibilidad y heaps que no se congelan bajo carga.
Un recolector para heaps grandes
ZGC por defecto: marcado concurrente, compactación, punteros coloreados y una barrera de lectura, con un modo generacional opcional. Dimensionado para el perfil de memoria que llevan los servicios de datos reales, no un recolector de hace décadas estirado para cubrir una década nueva.
Tu stack ya funciona
Spring y Spring Boot, Tomcat e Hibernate arrancan, corren y pasan sus suites de tests reales sobre CratonVM hoy, respaldados por una base de datos SQL H2 embebida completa. Netty, Quarkus e Hibernate Reactive son los siguientes.
Un único binario autocontenido
Sin JDK que instalar, sin rt.jar, sin imagen base inflada. Descargalo y ejecutalo: en un contenedor, en el edge, en un pipeline, donde sea que vivan tus datos.
Seguro en memoria por construcción
Intérprete, JIT y recolector en Rust seguro allí donde el problema lo permite, cerrando categorías enteras de errores de corrupción de memoria que llevan décadas persiguiendo a los runtimes nativos. Más de 400.000 líneas repartidas en 22 crates.
Un JIT optimizador de verdad
No un intérprete rápido: compilación por niveles, on-stack replacement, eliminación de chequeos de límites y vectorización AVX2 — bucles calientes compilados directamente a x86-64 nativo.
Java moderno, cubierto por completo
De Java 8 a Java 25 — lambdas y streams, records y sealed classes, pattern matching, virtual threads, scoped values. Más de 19.000 tests verificados contra el comportamiento real de HotSpot.
Mejor enterarse de esto acá que en la tercera semana.
El camino automático es angosto
No es una promesa de que Java arbitrario corra en el acelerador. Es la promesa de que lo que sí corre devuelve la misma respuesta, y de que podés preguntar por qué se descartó cualquier cosa.
Sólo NVIDIA, por ahora
El offload a GPU necesita un CratonVM compilado con --features gpu-driver y un dispositivo NVIDIA. El runtime de CPU no tiene ese requisito.
Pre-1.0 y en movimiento
Java SE 8–25 está cubierto y más de 19.000 tests lo respaldan, pero este es un runtime joven. Traenos tu carga de trabajo y te diremos honestamente si está listo para vos.
Traenos una carga de trabajo.
cargo build --release -p cratonvm-cli
./target/release/cratonvm -cp . HelloWorldUn batch que tarda demasiado, un modelo que no podés servir de forma económica, una etapa de pipeline que domina la factura de tu clúster: lo medimos contra lo que usás hoy y te decimos si la respuesta es no.