Prueba un agente de código Flint de 23 GB antes de asignarle trabajo real

Tienes una estación de trabajo o un único acelerador, y un agente de código cuantizado está pidiendo una porción de tu trabajo real. La pregunta de la prueba es si sobrevive a tu repositorio, a tu tolerancia de latencia y a tu definición de un parche correcto. Una prueba local acotada debe ser lo suficientemente pequeña para ejecutarse hoy y lo suficientemente estricta para detectar un entorno defectuoso.

Flint, de Recursive, se lanzó el 21 de octubre de 2026 bajo Apache 2.0, con 39,8 mil millones de parámetros totales y unos 2,5 mil millones activos por token. El número de parámetros activos es lo que hace plausible una conversación en una estación de trabajo. En una sesión de 128K, Flint produjo entre 47 y 70 tokens por segundo, mientras que Dense Qwen3.8 27B logró aproximadamente 11 y lo superó en cuatro de seis benchmarks. Si tu agente actual es más lento, un parche que llega en segundos puede cambiar tu flujo de trabajo incluso cuando la precisión es similar. La brecha de velocidad es la razón por la que una prueba local debe ser más estricta que una demostración.

La memoria es la primera barrera

Los pesos son solo parte de la huella. La ruta cuantizada tiene menos que ver con el cómputo bruto y más con el margen. El contexto, el sistema operativo y tu editor necesitan espacio mientras el modelo se ejecuta. Una máquina que puede cargar los pesos aún puede tartamudear cuando la sesión crece, por lo que el primer elemento de la lista es una comprobación de memoria, no una puntuación de benchmark. La ruta cuantizada y la ruta de precisión completa son pruebas diferentes, así que no las compares como si fueran la misma carga de trabajo. Una ejecución en estación de trabajo es una prueba de margen de memoria; una ejecución en BF16 es una prueba de la pila de servicio.

Ejecuta la barrera local antes de la puntuación

Usa la lista como barrera local. Cada elemento es una configuración o medición rápida, y cada uno protege una parte diferente del veredicto. Guarda las notas junto a la ficha del modelo, porque el entorno es parte del resultado. Usa el mismo repositorio para cada intento y el mismo tiempo de espera.

• Confirma los requisitos de hardware: la compilación de 4 bits ocupa unos 23 GB, Recursive sugiere 48 GB de memoria de sistema y el checkpoint BF16 necesita unos 80 GB, por lo que un único B300 o H200 puede alojar una réplica bajo la configuración SGLang incluida; anota si el proceso se mantiene dentro de la memoria recomendada.
• Registra la pila de inferencia, los ajustes de muestreo y el presupuesto de salida antes del primer prompt.
• Cronometra un prompt corto y registra los tokens por segundo, luego compara esa velocidad de decodificación con tu agente actual en el mismo prompt.
• Configura el arnés para puntuar pass@1 en al menos cinco intentos.
• Cuenta cualquier solución que dependa de la recuperación web como un fallo; la evaluación Terminal-Bench de Recursive marca esas soluciones como fallos.
• Anota las advertencias de los benchmarks antes de citar cifras de SWE-bench.

Los primeros elementos protegen la ejecución, los intermedios hacen comparable el cronometraje y los últimos hacen honesta la puntuación. Trata la lista como una regla de parada, no como una tabla de puntuaciones. Si un elemento falla, detente y corrige el entorno antes de juzgar el modelo. Un parche que pasa en un sandbox ajustado aún puede fallar en tu repositorio.

Los kernels pueden cambiar la velocidad

La velocidad importa porque un agente de código solo es útil si puedes esperar a que responda. La Eureka Machine de Recursive creó kernels que hicieron que Flint generara texto un 55% más rápido en NVIDIA RTX Spark sin modificar los pesos. Una primera ejecución lenta puede ser un problema de kernel, no de modelo, así que comprueba la capa de servicio antes de culpar al checkpoint. Un cambio de kernel puede importar más que un pequeño ajuste de pesos.

Puntúa intentos repetidos con la recuperación web como fallo

Los anclajes reportados de Flint son 74,2% en SWE-bench Verified, 89,7% en SWE-bench Pro v2 y 54,9% en Terminal-Bench 2.1, con cada cifra promediada en un mínimo de cinco ejecuciones. Esos son anclajes útiles, no un sustituto de tu propio conjunto de tareas. Cuando tu arnés deja que el modelo copie una solución de la web, estás probando un producto diferente. Puntúa el parche, no la explicación.

Mantén la lista de verificación junto a tus notas de evaluación. Asigna trabajo solo cuando el entorno, la velocidad y la puntuación apunten en la misma dirección.