Agente de fin de semana con una GPU: empieza con un modelo de 8B

Tienes una GPU de consumo, unas pocas horas y ninguna ganas de una factura de API por uso. La prueba de agente con una GPU es sencilla: elige el modelo de invocación de herramientas más pequeño que quepa en tu GPU, delimita su alcance a una sola tarea y trata los benchmarks del proveedor como un techo, no como una promesa. Es una puerta de fin de semana antes de gastar dinero en un montaje más grande. Granite 4.2 es un fuerte primer candidato para una prueba de fin de semana con una GPU.

Empieza con el modelo de 8B

IBM Research puso Granite 4.2 a disposición el 25 de agosto de 2026, como modelos de razonamiento de solo decodificador denso de 3B, 8B y 30B con licencia Apache 2.0. El modelo de 8B está pensado para ejecutarse en una sola GPU, el de 3B está pensado para portátiles y el de 30B está pensado para infraestructura empresarial. Para un banco de pruebas de fin de semana, el modelo de 8B es el tamaño que hay que probar primero.

El modelo de 3B no es simplemente más pequeño. Los modelos de 8B y 30B de Granite 4.2 recibieron una etapa de aprendizaje por refuerzo agéntico para ingeniería de software, uso de terminal y búsqueda web, mientras que el modelo de 3B no. Los modelos más grandes suelen ser más capaces, pero también exigen más infraestructura, más ajuste y más paciencia. El modelo de 8B te da un primer intento realista de un agente autoalojado sin empujarte a una configuración larga.

Ajusta los pesos cuantizados

Antes de instalar nada, comprueba si los pesos caben en tu GPU. IBM proporcionó versiones cuantizadas de Granite 4.2 en FP8, NVFP4, MXFP4 y GGUF para uso local y en el edge. Esas compilaciones importan para la inferencia local con memoria limitada. Tu GPU tiene una configuración viable de fin de semana cuando puede alojar el modelo 8B cuantizado más el contexto que necesitas. La factura de tokens se mantiene pequeña por ahora.

Los tres modelos de Granite 4.2 fueron preentrenados desde cero con aproximadamente 15 billones de tokens y tienen ventanas de contexto que alcanzan los 512.000 tokens. La ventana de 512.000 tokens no es el valor predeterminado de fin de semana. Usa el contexto largo como reserva. No asumas que el nombre de un modelo es suficiente. El mismo modelo se comporta de manera diferente según el formato cuantizado, el software que lo ejecuta y la cantidad de contexto que mantengas abierto. Empieza con un contexto corto y una tarea simple, y solo amplía si la máquina se mantiene cómoda. Cuando la ejecución se ralentice o se bloquee, reduce la longitud del contexto y vuelve a probar antes de cambiar el modelo.

Delimita una tarea primero

La parte agéntica de los datos de ajuste fino supervisado de Granite 4.2 fue 69 % ingeniería de software, con proporciones menores para invocación de herramientas, uso de terminal, matemáticas, búsqueda y acción, por lo que un asistente de código es una tarea natural para empezar. Un asistente amplio que debe buscar, resumir y actuar a través de muchas herramientas necesita un alcance más reducido. Una tarea estrecha te da una señal más limpia en una ventana corta de construcción.

Tu agente de fin de semana necesita un trabajo enfocado y una condición de parada clara. Puede invocar una herramienta, devolver una respuesta y detenerse. No necesita gestionar un historial largo ni un flujo de trabajo complejo. La regla de parada es parte del diseño. Un modelo que termina un trabajo pequeño es más fácil de depurar que uno que sigue preguntando. Una tarea demasiado amplia hace que el modelo parezca débil y convierte el fin de semana en depuración de alcance en lugar de construir algo útil. Puedes juzgar la adecuación por el tamaño de la tarea, el número de herramientas y la condición de parada.

Trata los benchmarks como un techo

Los resultados de benchmark reportados por el proveedor de Granite 4.2 muestran al modelo de 30B en 57,00 en SWE-Bench Verified y 29,24 en Terminal-Bench 2.1, con el modelo de 8B en 47,67 y 20,56 en las mismas pruebas. Usa esos números para clasificar opciones y luego prueba el trabajo real. Tu tarea de fin de semana será más estrecha, más desordenada y menos estandarizada que una suite de benchmarks. Las puntuaciones más altas del 30B no son el resultado que deberías esperar en tu tarea. La pregunta real es si el modelo hace el trabajo de forma fiable en tu configuración.

No dejes que una puntuación alta reemplace un pequeño experimento. Los benchmarks muestran fortaleza en una clase de tarea. No pueden decirte si tu prompt, herramientas y datos se comportarán de la misma manera. Para un agente de fin de semana, la prueba útil es sencilla: dale al modelo un trabajo estrecho, un pequeño conjunto de herramientas y una condición de parada. Mira si termina sin corrección constante. Los finales limpios te dan una base; los desordenados significan que ajustas la tarea antes de culpar al modelo.