NVIDIA Labs ha presentado cuTile-rs, un proyecto de investigación que lleva el modelo de propiedad y seguridad de memoria de Rust a la programación de kernels para GPU. La herramienta, publicada en el repositorio NVlabs/cutile-rs, ofrece un lenguaje específico de dominio (DSL) en Rust para escribir kernels tile-based que se compilan en tiempo de ejecución (JIT) a través de CUDA Tile IR hasta generar un cubin ejecutable en la GPU.
El núcleo de la propuesta es la extensión de la disciplina de ownership de Rust más allá del lanzamiento del kernel: los tensores mutables se particionan en fragmentos disjuntos antes del lanzamiento, los inmutables se comparten, y los launchers generados preservan la propiedad mientras el trabajo en la GPU está en vuelo. El mismo modelo admite lanzamientos síncronos, pipelines asíncronos y reproducción de CUDA graphs. Para los casos que requieran control de bajo nivel, la herramienta ofrece opt-outs locales.
El flujo de trabajo se articula en torno a la macro #[cutile::module], que captura el AST de Rust de cada kernel y lo embebe en el binario del host. Cuando el kernel es necesario, cuTile-rs lo compila JIT a través de CUDA Tile IR. Un ejemplo de suma vector-tensor muestra la sintaxis: el cuerpo del kernel declara el tensor de salida como mutable exclusivo y los de entrada como inmutables compartidos, mientras el host particiona la salida en bloques de 128 elementos y llama a .sync() para ejecutar.
Los autores, Melih Elibol, Jared Roesch, Isaac Gelado, Eric Buehler y Michael Garland, han publicado el artículo académico "Fearless Concurrency on the GPU" en arXiv (2606.15991). Las mediciones, realizadas con cuTile-rs 0.2.0 sobre una NVIDIA B200, arrojan 7 TB/s en operaciones element-wise —aproximadamente el 91% del pico de ancho de banda de memoria— y 2 PFlop/s en GEMM, equivalente al 92% del pico denso en fp16. Este último resultado, según el repositorio, es competitivo con cuBLAS. Los microbenchmarks de sobrecarga por seguridad indican que Rust seguro en GEMM persistente alcanza 2,07 PFlop/s con M=N=K=8192, a solo un 0,3% de la variante equivalente escrita directamente en Tile IR de bajo nivel.
El proyecto también evalúa Grout, un motor de inferencia para Qwen3 desarrollado en colaboración con Hugging Face sobre cuTile-rs. En decodificación batch-1, Grout alcanza 171 tokens/s con Qwen3-4B en una RTX 5090 y 82 tokens/s con Qwen3-32B en una B200, cifras que los autores califican como competitivas con el estado del arte en tareas de inferencia limitadas por ancho de banda, según su análisis de roofline sobre HBM.
En cuanto a requisitos, cuTile-rs necesita una GPU NVIDIA con capacidad de cómputo sm_80 o superior, recomendándose CUDA 13.3, que ofrece cobertura completa desde sm_80 e incorpora funciones de Tile IR 13.3 como empaquetado FP4 y MMA block-scaled. También requiere Rust 1.89 o superior y está probado en Ubuntu 24.04. El repositorio incluye un Nix flake para facilitar la configuración.
Los propios autores reconocen que el software está en una fase temprana y bajo desarrollo activo, por lo que cabe esperar errores, funciones incompletas y cambios de API. Aun así, subrayan que esperan recibir反馈 de la comunidad para orientar su evolución. Como proyectos complementarios dentro del ecosistema NVIDIA figuran cuTile Python, TileGym con ejemplos y patrones de ajuste, y cuda-oxide, un compilador experimental Rust-a-CUDA para kernels estilo SIMT. Para la comunidad Rust también existe el backend NVPTX de rustc, que genera PTX directamente.
En definitiva, cuTile-rs plantea una pregunta de fondo: si las garantías de seguridad de memoria y ausencia de carreras de datos que Rust aporta al software de sistema pueden trasladarse sin coste perceptible al rendimiento al dominio de la computación en GPU. Las cifras publicadas sugieren que la respuesta, al menos para kernels tile-based sobre hardware B200, es afirmativa: la sobrecarga se mide en décimas de porcentaje frente a código de bajo nivel. Falta por ver cómo evolucionará la API, qué adopción real consigue entre desarrolladores de Rust y si el modelo de ownership se extiende de forma natural a patrones más complejos que los kernels element-wise y GEMM ya evaluados.