Entre 96,1% y 98,2% del rendimiento. Eso conservó la inferencia cifrada de DeepSeek-R1 corriendo sobre ocho GPU NVIDIA B200, comparada contra la misma configuración con el cifrado apagado. El dato viene del blog de desarrolladores de NVIDIA, en un artículo del 22 de septiembre de 2026 que describe cómo el framework TensorRT LLM se adapta cuando la carga corre dentro de un entorno de computación confidencial.

La inferencia de modelos de lenguaje procesa cada vez más información sensible y contexto propietario, en equipos personales, dentro de empresas y en sectores regulados. Cuando eso pasa, los datos tienen que procesarse dentro de un entorno de confianza. Esa es la promesa de la computación confidencial de NVIDIA, que combina máquinas virtuales confidenciales con la memoria cifrada, GPU confidenciales y enlaces NVLink cifrados para correr cargas de producción sobre hardware de confianza.

El problema es que esa protección cambia supuestos que el software da por sentados. Frameworks como TensorRT LLM alcanzan su rendimiento combinando optimizaciones propias con el cómputo acelerado de NVIDIA, y están construidos sobre cómo se mueve la memoria, cómo se miden los tiempos, cómo se planifica el trabajo y cómo se comunican varias GPU entre sí. Cuando la ejecución pasa a ser segura, esas cuatro cosas dejan de comportarse igual, y si el runtime no se adapta aparece el sobrecosto.

El artículo apunta a quienes evalúan inferencia confidencial sobre GPU NVIDIA Blackwell y entrega, además de las cifras, una metodología controlada que cada equipo puede repetir sobre su propia carga.

¿Qué carga de trabajo deja ver el costo del cifrado?

No cualquiera lo muestra. Un volumen alto de solicitudes amortiza los costos fijos del cifrado, porque las esperas de una petición se solapan con el trabajo de otra, y el efecto se vuelve difícil de observar.

Para exponerlo hay que elegir una carga con contexto de entrada largo, generación de salida extendida y concurrencia baja. El contexto largo estresa el movimiento de datos durante el prellenado, la generación extendida amplifica el pequeño sobrecosto por token durante el decodificado, y la concurrencia baja impide esconder esos costos detrás de otras peticiones. El equipo de ingeniería de rendimiento de NVIDIA usó esas tres características para la carga que evaluó.

Cómo se mide, con el cifrado encendido y apagado

La misma carga corre en dos condiciones, con la computación confidencial desactivada y activada, manteniendo constantes el modelo, el hardware, la versión del framework, los largos de secuencia, el paralelismo y la concurrencia, de modo que lo único que cambia sea el estado del cifrado. En cada nivel de concurrencia se calculan dos números.

  • Rendimiento de salida retenido: 100 x (tokens de salida por segundo con cifrado encendido ÷ tokens de salida por segundo con cifrado apagado)
  • Sobrecosto de latencia por token de salida (TPOT): 100 x (TPOT con cifrado encendido ÷ TPOT con cifrado apagado - 1)

NVIDIA presenta la configuración exacta de hardware y software en una tabla del artículo original, y sobre ella aplicó la comparación. Con esas dos fórmulas, un equipo de rendimiento puede cuantificar cuánto de su propia línea base sin cifrar sobrevive al activar el cifrado para la carga que le interesa servir, en vez de aceptar un número medido sobre otra carga, en otro hardware y con otra versión del framework.

Los resultados entre concurrencia 1 y 16

Con el cifrado encendido, el rendimiento de tokens de salida se mantuvo entre el 96,1% y el 98,2% de la línea base. La latencia media por token quedó entre 1,2% y 4,3% por encima.

Figura 1. Rendimiento de tokens de salida con cifrado encendido respecto de la línea base sin cifrado, con concurrencia de 1 a 16. Retuvo entre 96,1% y 98,2%
Figura 2. TPOT medio con cifrado activado respecto de la línea base, con concurrencia de 1 a 16. El cifrado agregó entre 1,2% y 4,3% de latencia por token, y menos es mejor

¿De dónde sale el sobrecosto y cómo se reduce?

La arquitectura de computación confidencial de NVIDIA Blackwell introduce rutas de seguridad impuestas por hardware para proteger los datos y las cargas mientras se usan. NVIDIA las detalla aparte, en Hardware-Rooted AI Security That Won't Slow You Down. Lo que sigue es cómo esas rutas rompen supuestos del runtime y qué hace TensorRT LLM al respecto.

El movimiento de datos entre el host y la GPU

En la configuración confidencial del B200, las transferencias desde el host hacia la GPU pasan por un búfer intermedio cifrado por software, porque la GPU no puede acceder directamente a la memoria protegida de la máquina virtual confidencial. Eso cambia el comportamiento que el framework espera. La memoria fija deja de entregar su ventaja habitual de transferencia asíncrona, y algunas copias terminan bloqueando el hilo que las llamó.

  • Del host a la GPU: TensorRT LLM elige la memoria según el estado del cifrado y usa memoria paginable en las rutas afectadas, en vez de recurrir siempre a memoria fija.
  • De la GPU al host: la lectura repetida de tokens y datos de muestreo se mueve a un trabajador asíncrono, para que las copias protegidas no bloqueen al planificador principal durante el decodificado. El cambio está en el PR #11573 de TensorRT LLM.

Un reloj estable para el autotuner

El autotuner de kernels compara tácticas candidatas usando eventos CUDA. En la configuración confidencial probada, las marcas de tiempo de esos eventos entregaron una señal inestable, y con una medición inestable el autotuner puede terminar eligiendo una táctica más lenta que la mejor disponible.

La solución fue cambiar de reloj. Bajo cifrado, TensorRT LLM mide las tácticas con el %globaltimer de la GPU y conserva los eventos CUDA fuera de ese entorno. El detalle está en el PR #11657.

La comunicación entre varias GPU

El multicast NVLS, la versión de NVLink SHARP, no está disponible en las configuraciones confidenciales del B200. Sin él, NCCL_SYMMETRIC no puede entregar el beneficio de multicast para el que existe, y aun así puede cobrar los costos de registro de memoria y de sincronización entre rangos antes de caer en una ruta colectiva sin multicast.

La recomendación de NVIDIA para quien desarrolla frameworks es detectar si NVLS está disponible y elegir el algoritmo de comunicación que minimice la latencia para ese tamaño de mensaje, esa topología y esa carga.

Qué hacer antes de desplegar

Con las tres adaptaciones puestas, la inferencia confidencial de DeepSeek-R1 conservó más del 96% del rendimiento de tokens de salida y mantuvo el sobrecosto de latencia por token bajo el 5% sobre ocho GPU B200. NVIDIA insiste en que el cifrado no reemplaza al trabajo de ingeniería de rendimiento, sino que lo vuelve más necesario, porque el framework tiene que saber que está corriendo protegido.

Su recomendación para las organizaciones que llevan inferencia privada a producción es tratar la configuración de seguridad y la optimización de la inferencia como un mismo problema de despliegue, un trabajo de ingeniería que cruza toda la pila y no una casilla que se marca al final. Activar el cifrado, atestiguar el entorno y medir con la carga exacta que se va a servir, no con una de referencia. La documentación está en NVIDIA Trusted Computing y las notas de versión de TensorRT LLM.