NVIDIA ha publicado Dory 1.0 4B, un pequeño modelo de razonamiento procedente de Nemotron Labs cuyas capas centrales forman un bloque compartido, aplicable una, dos, tres o cuatro veces a cada token. Según un tutorial de MarkTechPost, este funcionamiento permite ejecutar un mismo archivo en cuatro niveles de cálculo diferentes, sin reentrenamiento.
- NVIDIA publica Dory 1.0 4B, un modelo de razonamiento que reutiliza un bloque central de capas.
- El archivo GGUF aplica cuatro bucles por defecto, mientras que la ficha recomienda dos.
- Conviene fijar manualmente el número de bucles y el commit de llama.cpp.
- El notebook verifica en un servidor la velocidad, la caché y la precisión en GSM8K.
Cada paso adicional por el bloque, llamado bucle, consume más cálculo por token sin añadir ningún parámetro. El tutorial utiliza el motor llama.cpp y un archivo en formato GGUF de 3,7 GB, en cuantificación Q5_K_M, es decir, comprimido para reducir su tamaño en memoria. La versión de llama.cpp empleada corresponde al commit fijado en la ficha del modelo de NVIDIA, ya que el soporte para Dory es aún una pull request en borrador. El nombre del archivo difiere del indicado en la ficha, que menciona dory-q5_k_m.gguf, por lo que el tutorial recomienda verificar su tamaño y su huella SHA-256. El archivo descargado corresponde a la suma de control publicada por NVIDIA.
Una arquitectura leída directamente en el archivo
La cabecera del GGUF describe la estructura del modelo incluso antes de su carga. Dory cuenta con 72 entradas de capas, distribuidas en 16 capas de entrada, 40 capas recurrentes y 16 capas de salida. El bloque recurrente representa 1.840 millones de los 3.980 millones de parámetros del modelo.
La cabecera también indica un número de bucles por defecto de 4, mientras que la ficha del modelo recomienda 2. Un servidor iniciado sin opción explícita funciona, por tanto, con el ajuste más costoso. Según el tutorial, siempre hay que fijar este parámetro manualmente.
A partir de estos datos, el tutorial estima el coste de cada bucle. Un token atraviesa el bloque recurrente una vez por bucle, de modo que cuatro bucles aplican 2,51 veces los parámetros de un solo bucle y leen 2,28 veces los bytes de pesos, siendo esta lectura el factor determinante para un decodificado limitado por la memoria. La caché KV, la memoria que conserva los cálculos de los tokens anteriores, varía según el modo elegido. En modo per_loop, pasa de 306 MiB con un bucle a 816 MiB con cuatro bucles, para un contexto de 4.096 tokens. En modo last_loop, se mantiene en 306 MiB independientemente del número de bucles.
Mediciones para verificar las predicciones
El notebook asociado verifica luego estas estimaciones en un servidor en funcionamiento. Mide la velocidad de decodificación para cada número de bucles, prueba si la caché last_loop modifica las predicciones del modelo y compara las distribuciones de tokens siguientes entre varios ajustes. También lanza una evaluación emparejada sobre 30 preguntas del conjunto de prueba GSM8K, un benchmark de problemas matemáticos, midiendo la precisión, la longitud de las respuestas y el tiempo por pregunta resuelta.
El tutorial precisa que la ficha del modelo anuncia rendimientos en otros benchmarks, como SWE-bench o GPQA, que no se reproducen en este contexto, al igual que el contexto de 256K tokens y el preentrenamiento en NVFP4.
El notebook está accesible en GitHub, en el repositorio de MarkTechPost dedicado a proyectos de agentes y tutoriales. Los autores insisten en dos puntos: fijar explícitamente el número de bucles, ya que el GGUF utiliza cuatro por defecto, y fijar el commit del fork de llama.cpp, porque el soporte de Dory sigue siendo una pull request en borrador.
