Qué nos dicen 2.122 tokens por segundo —y qué dejan fuera

El 27 de septiembre, NaiveAI publicó su artículo técnico sobre Naive-N0.5-Flash. Según lo comunicado, NaiveRT, optimizado para la decodificación de un solo flujo en los rollouts de aprendizaje por refuerzo, alcanza 2.122 tokens por segundo mediante un modelo borrador DFlash fusionado para decodificación especulativa. Las condiciones declaradas importan: ocho GPU, el mejor intervalo de un segundo entre 41 solicitudes HTML/SVG, la función de pensamiento desactivada y el tiempo de procesamiento inicial (prefill) excluido. Es una medición del propio desarrollador; SlateMoth no la ha reproducido de forma independiente. [1]

La pregunta útil es qué parte de la espera real de una persona abarca esta medición. Una velocidad máxima de decodificación describe solo una parte de la solicitud. No indica directamente cuánto tarda en terminar una modificación de código, un informe o una tarea de un agente. Para los equipos que evalúan modelos, separar estas preguntas ayuda a valorar con justicia un resultado de ingeniería prometedor.

Proponemos tres relojes. El primero va desde el envío de la solicitud hasta la primera salida utilizable, e incluye la espera y el procesamiento de la entrada que percibe quien la envía. El segundo mide el tiempo de generación restante, desde esa primera salida hasta que se completa la respuesta. El tercero sigue la tarea entera, desde su envío hasta su aceptación, incluidas las llamadas a herramientas, las pruebas y los reintentos necesarios. Mejorar una parte de ese recorrido no implica reducir en igual medida el tiempo total.

Pensemos en una tarea hipotética de edición de código: cargar el proyecto y llegar a la primera salida lleva 12 segundos, la generación lleva 8 segundos y las pruebas, 40 segundos. Aunque la generación se acelere cuatro veces, el total solo baja de 60 a 54 segundos: un ahorro del 10 %. Son cifras ilustrativas, no mediciones de NaiveAI. La lección es medir dónde se va el tiempo antes de trasladar un aumento de velocidad anunciado a todo el flujo de trabajo.

Un pico breve tampoco aclara si la generación mantiene esa velocidad durante una respuesta larga o con varias solicitudes simultáneas. Conviene pedir tiempos de respuesta completos y distribuciones de latencia bajo la carga que espera el equipo. Hay que distinguir la velocidad de una sola solicitud del rendimiento agregado: atender más solicitudes por segundo y terminar antes la tarea de una persona resuelven problemas distintos.

La ficha del modelo enumera 309.000 millones de parámetros totales y 15.500 millones de parámetros activos. Sus indicaciones de despliegue en FP8 señalan que los pesos ocupan aproximadamente 315 GB y que la inferencia necesita memoria de GPU adicional. También indican que el diseño de atención dispersa conserva íntegra la caché KV. Estos datos evitan una lectura errónea habitual: el número de parámetros activos no significa que el modelo completo quepa en la memoria necesaria para un modelo denso de ese tamaño. [2]

Para decidir sobre un despliegue, hay que registrar los pesos y la precisión reales, el hardware y sus interconexiones, la versión del entorno de ejecución, la longitud del contexto y las solicitudes simultáneas. Después, medir el uso de memoria y los fallos en esa configuración. Una ruta de cálculo con menos parámetros activos puede ser valiosa sin que todos los despliegues sean pequeños. La cuantización, la descarga de componentes a otra memoria o un motor de servicio distinto deben evaluarse como configuraciones independientes; no se les puede atribuir la cifra máxima original.

Hay un límite de publicación que conviene hacer visible. El artículo técnico describe NaiveRT como código abierto, pero también dice que el contenido del código fuente mencionado estará disponible a más tardar el 12 de octubre. Cuando lo comprobamos el 28 de septiembre, el repositorio de NaiveRT enlazado devolvió un error 404. Por eso no pudimos examinar en esa dirección el entorno de ejecución ni sus scripts de pruebas de rendimiento. Esto no demuestra que el resultado sea falso ni que no haya pesos del modelo disponibles. Limita lo que podemos verificar hoy. [1] [3]

Hasta que se puedan examinar los materiales pertinentes y repetir el experimento, conviene tratar la velocidad como un resultado comunicado por el desarrollador bajo condiciones específicas. Tampoco se puede deducir de una prueba de velocidad con el pensamiento desactivado el rendimiento en trabajos que exigen razonamiento prolongado. La calidad y el tiempo deben medirse juntos en el modo que realmente se usará para la tarea.

Empiece con un conjunto pequeño de tareas representativas y defina el éxito antes de ejecutarlas. Para un cambio de código, podría exigir que funcione el comportamiento solicitado, que pasen las pruebas de regresión y que no se modifiquen archivos ajenos. Para un documento, que estén los datos necesarios y que las citas respalden lo afirmado. Mida el intento completo, incluidos los fallos y el trabajo repetido, en vez de conservar solo el resultado más vistoso.

Mantenga fijos el conjunto de tareas, los permisos de las herramientas y las reglas de aceptación al cambiar el modelo o la configuración del servicio. Registre el tiempo hasta la primera salida, el tiempo total transcurrido, la proporción de tareas aceptadas y el coste por tarea aceptada. Incluya entradas cortas y largas, la concurrencia habitual y ejecuciones repetidas. Una muestra rápida puede justificar más investigación; no describe la experiencia de todos los usuarios.

La mejor oportunidad para acelerar la decodificación está en las cargas de trabajo donde la generación ocupa de verdad la mayor parte de la espera. Una generación larga y principalmente secuencial puede beneficiarse mucho si se mantiene la calidad. Un flujo dominado por la búsqueda de información, herramientas lentas o revisión humana puede beneficiarse menos. Ninguna de las dos observaciones resta mérito al trabajo de ingeniería; indican dónde conviene probarlo primero.

El informe de NaiveAI ofrece a los equipos una hipótesis concreta que vale la pena probar: otro diseño de inferencia podría acortar el trabajo dominado por la generación. Hemos leído la metodología publicada, pero no hemos ejecutado el modelo ni reproducido el pico. La siguiente evidencia que conviene buscar es código del entorno de ejecución accesible, una configuración repetible y resultados en tareas representativas. Una decisión de adopción útil depende de la rapidez con que el sistema entrega un resultado aceptable para la carga de trabajo propia.