Qwen3-8B en NVFP4 con kernels en Rust: lo que enseña CUDA Oxide 0.3

Por Alan Sonny

X (Twitter) Facebook Pinterest LinkedIn Email WhatsApp

NVIDIA ha mostrado con CUDA Oxide 0.3, publicada el 31 de octubre de 2026, que ya es posible ejecutar un modelo de lenguaje completo con kernels escritos en Rust: la vista previa cute-rs incluida en la versión mueve Qwen3-8B entero, de 36 capas, en BF16 y en NVFP4, y el modelo de voz Qwen3-TTS 1.7B sobre una GPU Blackwell de consumo.

Las claves de Qwen3 en Rust con CUDA Oxide 0.3 en 20 segundos

NVIDIA lanzó CUDA Oxide 0.3 el 31/10/2026 dentro de su proyecto CUDA Rust.
La vista previa cute-rs ejecuta Qwen3-8B completo en BF16 y NVFP4 y Qwen3-TTS 1.7B en una RTX 5090.
En NVFP4, los pesos ocupan 3,56 veces menos que en BF16.
Son demostraciones de funcionalidad de un proyecto experimental, no una prueba de que Rust supere a CUDA C++.

CUDA Oxide es el compilador de NVIDIA para escribir kernels de GPU en Rust siguiendo el modelo SIMT (Single Instruction, Multiple Threads), el mismo que usa CUDA C++. Compila a PTX (Parallel Thread Execution), el lenguaje intermedio que el controlador traduce para cada GPU. La versión 0.3 llega con casi 600 commits de más de 45 colaboradores y trae cambios de infraestructura, como el paso a Rust estable 1.99.1 y un runtime compartido con cutile-rs, que revistacloud.com detalla en su análisis de la versión. Para quien trabaja con modelos, lo interesante está en otra parte: en lo que se ha conseguido ejecutar.

Esos modelos no corren con el backend SIMT nativo, sino con cute-rs-preview, una implementación experimental en Rust de CuTe, la capa de layouts de CUTLASS (CUDA Templates for Linear Algebra Subroutines, la biblioteca de NVIDIA para multiplicación de matrices y álgebra lineal en GPU). cute-rs genera código a través del compilador fijado de CUTLASS 4.7 y, en la versión 0.3.0, solo acepta dos objetivos: sm_100a, la clase B200 de centro de datos, y sm_120a, la serie GeForce RTX 50. Hopper queda fuera.

Qwen3-8B en NVFP4: 3,64 GiB de pesos en lugar de 12,94

El ejemplo qwen3_8b_cute implementa el decodificador completo de Qwen3-8B: 36 capas, dimensión oculta de 4.096, 32 cabezas de consulta y 8 de clave-valor con atención agrupada (GQA). Funciona en dos precisiones. En BF16 (bfloat16, coma flotante de 16 bits) usa multiplicaciones en Tensor Cores; en NVFP4, el formato de 4 bits de NVIDIA con un factor de escala FP8 por cada bloque de 16 valores, aprovecha las conversiones por hardware de Blackwell. Según el README del ejemplo, los pesos de las 36 capas ocupan 3,64 GiB en NVFP4 frente a 12,94 GiB en BF16, de ahí la reducción de 3,56 veces que citan las notas de la versión. Quien quiera repasar el formato tiene en noticias.ai una explicación de cómo funciona NVFP4 para inferencia de baja precisión.

El mismo README publica mediciones propias en una RTX 5090. En decodificación con un solo lote, la versión NVFP4 en cute-rs da 114,0 tokens por segundo, frente a 69,8 en BF16. En la fase de prellenado con 32 tokens, 632,8 tokens por segundo en NVFP4 y 333,7 en BF16. NVIDIA compara también con una implementación de referencia en CuTeDSL, la variante Python de CuTe, que obtiene 75,8 tokens por segundo en decodificación. El repositorio atribuye esa diferencia a cómo se reparte el trabajo (un warp de 32 hilos por fila de salida frente a un hilo por fila) y a la ejecución asíncrona, no al lenguaje. Conviene leer estas cifras con cautela: las publica el propio proyecto, el modo de prueba completo genera pesos sintéticos en la GPU (aunque admite cargar el checkpoint de Hugging Face) y no hay comparación con motores de inferencia de producción.

Entre los 14 kernels de ejemplo que acompañan a cute-rs aparecen las piezas habituales de un transformer: RMSNorm, SwiGLU, RoPE con caché KV, una red feed-forward en BF16, atención FMHA para prellenado y decodificación, decodificación MLA con caché paginada, un GEMV en NVFP4 y un GEMM con escalado por bloques que usa TMA (Tensor Memory Accelerator, el motor de copias asíncronas de memoria de NVIDIA).

Qwen3-TTS: de texto a audio con Rust en la GPU

El segundo modelo, qwen_decoder_cute, convierte texto en un archivo WAV a 24 kHz con Qwen3-TTS-12Hz-1.7B-CustomVoice. El reparto es claro: Python prepara los tokens de texto y Rust ejecuta el modelo. Un componente llamado Talker genera el primer código de audio, un predictor más pequeño completa los otros quince de cada grupo y un decodificador de forma de onda convierte esos grupos en muestras. Funciona en RTX 5090 (sm_120a). Es el mismo modelo que en noticias.ai ya se probó para clonar voces en local sin APIs de pago, aunque aquí el interés está en la pila de kernels y no en el uso final.

Lo que cute-rs añade frente a escribir estos kernels en Python es que layouts, descriptores TMA, pipelines productor-consumidor y operaciones de Tensor Cores se expresan como tipos de Rust y se comprueban antes de generar código. La matriz de compatibilidad del proyecto recoge 48 casos de error de compilación probados para cute-rs y 30 para ctm-rs. También deja claro lo que falta: no hay soporte para kernels agrupados, MoE, entradas mixtas ni FP8 en esa matriz. En la rama principal, ya después de la 0.3.0, ha aparecido una capa MoE de Nemotron-3 en NVFP4 para sm_100a, que todavía no forma parte de ninguna versión publicada.

Un proyecto experimental, no un sustituto de CUDA C++

NVIDIA no presenta CUDA Rust como algo listo para producción. Su blog técnico de septiembre lo decía en inglés sin rodeos; en traducción propia, «ambos proyectos están en fase temprana y ninguno está listo para producción». El README del repositorio lo define como un proyecto de investigación y avisa de fallos y cambios de API. Las notas de la 0.3 hablan de mejoras de compilador para Blackwell y Hopper que buscan, también en traducción propia, «cerrar la distancia con CUDA C++ ajustado a mano», lo que reconoce que esa distancia sigue ahí.

El otro camino del proyecto, cutile-rs, sigue el modelo CUDA Tile que NVIDIA ya ofrece en Python con cuTile y también en C++. Según el blog de NVIDIA, está más avanzado que cuda-oxide y ya lo usan Grout, de Hugging Face, y mistral.rs. Desde esta versión ambos comparten buffers, streams y CUDA graphs, así que un mismo motor de inferencia podría mezclar kernels Tile y SIMT.

Para montar cuda-oxide hace falta Rust 1.99.1 fijado con los componentes rustc-dev y llvm-tools, CUDA Toolkit 13.0 o superior, la herramienta cargo-oxide y, para cute-rs, el compilador de CUTLASS que instala la propia herramienta. La versión añade depuración DWARF con cuda-gdb, diagnósticos de registros y spills y trazas de eventos dentro del kernel, además de 241 pruebas de humo en GPU. No es el primer intento de llevar Rust a las GPU de NVIDIA: proyectos comunitarios como rust-cuda y Rust-GPU llevan años en ello, y la documentación de cuda-oxide afirma que NVIDIA colabora con los mantenedores de rust-cuda.

Preguntas frecuentes

¿Qué modelos de IA ejecuta CUDA Oxide 0.3?

La vista previa cute-rs incluye Qwen3-8B completo de 36 capas en BF16 y NVFP4, y Qwen3-TTS 1.7B para convertir texto en voz. Ambos funcionan en una RTX 5090.

¿Cuánta memoria ahorra NVFP4 frente a BF16 en Qwen3-8B?

Según el proyecto, los pesos de las 36 capas pasan de 12,94 GiB en BF16 a 3,64 GiB en NVFP4, 3,56 veces menos.

¿Es Rust más rápido que CUDA C++ para inferencia?

No hay datos que lo demuestren. Las demostraciones prueban que los modelos funcionan, y la única comparación publicada es con una referencia en CuTeDSL, no con CUDA C++ ni con motores de producción.