FrogNano: RL puro y 1.500 tareas sintéticas para un agente de código de 4B
TL;DR
- Verificado (model card, 11/10/2026): FrogNano es un agente de código de 4,66B parámetros derivado de Qwen3.5-4B que Microsoft post-entrenó exclusivamente con RL sobre ~1.500 tareas sintéticas de ingeniería de software, ejecutando los tests de verdad como recompensa. Sin SFT, sin trayectorias de modelos mayores. SWE-bench Verified pasa del 39,4% del base al 61,5% en cinco iteraciones (+22,1 puntos, ~56% relativo).
- Verificado (model card): en los benchmarks held-out que no vio durante el entrenamiento la cosa baja: 37,6% en SWE-bench Pro, 31,1% en Terminal-Bench 2.0 y 47,3% en PatchEval-Verified. Que el vendor publique los números malos sin que nadie se los pida es, honestamente, poco común.
- El «sin destilación» tiene letra pequeña: no hay trayectorias de un modelo más grande que imitar, cierto. Pero el curriculum de las 1.500 tareas lo genera un “AI task-authoring model” (TaskPilot), que fabrica enunciados, parches de referencia y tests ocultos. El abstract dice “without traditional distillation from larger models”. La frontera se ha movido, no desaparecido.
- Trampa multimodal confirmada: el config hereda el tower de visión de Qwen3.5-4B y varios GGUF comunitarios se etiquetan
image-text-to-text, pero la propia ficha lo dice claro: imagen y vídeo unsupported, sin post-entrenar ni evaluar. Si lo descargas para visión, te llevas las manos a la cabeza. - El ecosistema de cuants le ha ganado al repo oficial: a 11/10/2026, 19 repos derivados suman 48.902 descargas frente a las 1.348 del oficial; solo el GGUF de bartowski acumula 34.307 (25 veces el oficial). Ningún cuant tiene evaluación de calidad publicada, y el card avisa de que los formatos cuantizados “have not yet been validated”.
Qué es FrogNano (y por qué es una señal, no una ficha más)
FrogNano no es un modelo nuevo de cero: es Qwen3.5-4B — el base de 4,66B parámetros de Alibaba, multimodal y con licencia Apache 2.0 — pasado por un post-entrenamiento agéntico que Microsoft describe en un tech report en arXiv (2609.07925, sept 2026). La receta, según el model card publicado el 22 de septiembre: RL puro sobre ~1.500 entornos sintéticos de tareas SWE, recompensa por tests ejecutables, y un harness propio minimalista llamado Leaf que solo ofrece cinco herramientas (leer/escribir/editar ficheros, búsqueda glob y shell). El repositorio con el harness está en GitHub desde el 25 de agosto (microsoft/FrogNano, licencia MIT).
Dos cosas hacen interesante esta ficha. La primera es la arquitectura: 32 capas híbridas con 3 capas de atención lineal por cada 1 de atención completa (configuración verificada en el config.json, intervalo 4), lo que abarata muchísimo el contexto largo. La segunda es el claim metodológico: según el abstract del tech report, esto demuestra que se pueden entrenar agentes de código competitivos solo con tareas sintéticas, sin “traditional distillation from larger models”. Si la lectura sobrevive al escrutinio — y tiene matices, que es justo lo que viene abajo —, la barrera de entrada para entrenar un coding agent útil baja del «tenemos un frontier model como profesor» al «tenemos tests que se ejecutan».
La curva completa, verificada contra el model card, con Avg@3 sobre SWE-bench Verified usando Leaf:
| Etapa | SWE-bench Verified (Avg@3) |
|---|---|
| Base Qwen3.5-4B | 39,4% |
| Iteración RL 1 | 49,1% |
| Iteración RL 2 | 53,1% |
| Iteración RL 3 | 56,7% |
| Iteración RL 4 | 59,1% |
| Iteración RL 5 | 61,5% |
+22,1 puntos en cinco iteraciones con ~1.500 tareas sintéticas en total. Todo es del vendor y no hay evaluación independiente a 11/10/2026 — así que léelo como «esto declara Microsoft», no como medición propia. Pero la forma de la curva es pública por iteración, cosa que muchos vendors con modelos mucho más grandes no publican ni de lejos.
Los held-out: dónde baja la fiesta
| Benchmark | Rol | Resultado (Avg@3) | Notas del propio card |
|---|---|---|---|
| SWE-bench Verified | Validación | 61,5% | 500 issues de repos Python; es el set que guía el entrenamiento |
| SWE-bench Pro | Held-out | 37,6% | 731 tareas más largas, 11 repos, Python/JS/TS/Go |
| Terminal-Bench 2.0 | Held-out | 31,1% | 89 tareas de sysadmin, seguridad, ML y cómputo científico |
| PatchEval-Verified | Held-out | 47,3% | 230 CVEs reales (2015-2025) de reparación de vulnerabilidades |
El patrón es el esperable y está bien documentado por el propio vendor: el modelo rinde donde su entrenamiento le ha enseñado la forma de las tareas (issues de repos Python, un issue → un parche) y baja de manera sustancial fuera de esa distribución: casi 24 puntos en Pro y más de 30 en Terminal-Bench. En Pass@3 — si al menos una de tres muestras lo clava — sube al 71,0% en Verified y 47,6% en Pro, lo que sugiere que con un buen verificador externo o reintentos selectivos hay margen.
La metodología está descrita con un detalle que agradecerán los escépticos: presupuesto de 150 pasos de interacción y ~131K tokens de contexto por trayectoria, temperatura 0,6, y una regla honesta — agotar el presupuesto no cuenta como fallo automático, pero los parches que no aplican o los estados finales inválidos sí. También declaran que, en las trayectorias de evaluación analizadas, “no successful reward hacks were identified”. Que un modelo de 4B pase tests de verdad, sin haber visto las soluciones, es exactamente lo que este benchmark mide; la objeción interesante no está en los números, está en cómo se generaron las tareas. Vamos allá.
Anatomía del «sin destilación»: qué dice y qué no dice
Lo que FrogNano no usa, verbatim del model card: «no stronger-model solution trajectories, actions, reasoning traces, or patch targets». Ni salida de GPT-next ni de Claude como objetivo de imitación en ninguna fase del post-entrenamiento agéntico. Esto es verificable en la descripción del pipeline y es una distinción real: la imitación de trayectorias (behavior cloning de un profesor) es la receta clásica de destilación, y aquí no está.
Lo que sí usa: TaskPilot, que el propio card describe como un “AI task-authoring model” que genera, desde snapshots reales de repositorios, los enunciados, los parches de referencia y los tests ocultos con los que se evalúa y premia al agente. Es decir: el curriculum lo escribe otro modelo, calibrándolo en vivo contra la frontera de aprendibilidad del checkpoint actual — tareas descartadas si son triviales, imposibles o saturadas según los rollouts de la propia política. El abstract no dice sin destilación a secas: dice “without traditional distillation from larger models”, y esa palabra “traditional” carga todo el peso.
Mi lectura, con la letra pequeña sobre la mesa: el conocimiento para resolver repos no está viniendo de un profesor explícito, pero tampoco del aire. Está en (1) el checkpoint base de Qwen3.5-4B — preentrenado por otro vendor, con todo su conocimiento destilado del corpus —, (2) el modelo de autoría de tareas que genera los problemas y sus soluciones de referencia, y (3) el gradiente que los tests ejecutables aplican sobre trayectorias de la propia política. Lo que desaparece es la imitación paso a paso de un agente superior; lo que queda es una tubería donde modelos grandes siguen decidiendo qué sabe el pequeño, solo que repartido entre el preentreno y el generador de curriculum. Esto no es desacreditar el resultado — la curva es real y la recompensa es ejecutable —, es acotar qué enseña: no «ya no hacen falta modelos grandes», sino «no hacen falta trayectorias de modelos grandes si tienes tareas sintéticas bien calibradas y tests que no mienten».
Este matiz tiene historia en el sitio: en destilación on-policy vs off-policy y la dirección del KL vimos que imitar salidas de un profesor (off-policy) y aprender de tus propios rollouts con una señal de calidad (on-policy) son bestias distintas; FrogNano es un caso límite de lo segundo donde la señal la fabrica otro modelo. Y en UniEVO-VL vimos auto-mejora con datos sintéticos sin profesor externo, con el mismo riesgo de fondo: si quien escribe el curriculum tiene techos, el alumno hereda el techo con doble cifra decimal.
El ecosistema de cuants le ganó al repo oficial (y nadie ha medido nada)
A 11/10/2026, menos de tres semanas después del release, la búsqueda de FrogNano en Hugging Face devuelve 20 repos. Las descargas hablan solas:
| Repositorio | Formato | Descargas (11/10) |
|---|---|---|
| bartowski/FrogNano-4B-2609-GGUF | GGUF (IQ2_M a Q8_0, bf16, imatrix) | 34.307 |
| NANI-Nithin/FrogNano-4B-2609-GGUF | GGUF | 3.645 |
| webmp3/Sakura-FrogNano-4B-2609-GGUF | GGUF | 3.361 |
| mradermacher/FrogNano-4B-2609-i1-GGUF | GGUF dinámico | 2.681 |
| mradermacher/FrogNano-4B-2609-GGUF | GGUF estático | 1.714 |
| microsoft/FrogNano-4B-2609 (oficial) | safetensors BF16 | 1.348 |
| prithivMLmods/FrogNano-4B-2609-GGUF | GGUF | 879 |
| PollardWeights/FrogNano-4B-2609-Pollard | GGUF | 838 |
Los 19 repos comunitarios suman 48.902 descargas: 36 veces el repo oficial. En MLX para Apple Silicon, dicksondickson tiene oQ4e/oQ5e/oQ6e/oQ8e (583 descargas sumadas) — incluida una variante con la capa MTP de draft que trae el checkpoint —, y hay EXL3, ONNX y NVFP4. El patrón ya lo documentamos con Kolibri-1: los cuants comunitarios superan al oficial en descargas antes de que exista una sola medición de calidad. Aquí es más agresivo todavía porque el modelo es pequeño y corre en un portátil.
Dos advertencias antes de instalar nada. La primera, del propio card: «CPU-only servers, desktop operating systems, mobile devices, and optimized or quantized FrogNano formats have not yet been validated». Traducción: los cuants no son versión oficial comprimida, son experimentos comunitarios sobre un modelo cuyo vendor aún no ha validado ni el formato cuantizado ni el destino doméstico. Si tus resultados en Q4_K_M no salen, no hay a quién reclamar. La segunda es la trampa multimodal, que va en la siguiente sección porque se pega a la arquitectura.
Y una confesión de bulto que desluce cualquier comparación rápida: el «4B» del nombre son 4,66B parámetros exactos en los safetensors, verificado en la API. El card lo admite: «approximately 4.66-billion-parameter checkpoint requires about 9.3 GB» en BF16 solo de pesos. No es ocultación deliberada — la convención de redondeo a 4B es vieja —, pero cuando compares contra otros modelos de 4B reales, recuerda que este tiene un 15% más de parámetros que el redondeo sugiere.
La trampa multimodal: vision heredada, visión inexistente
El config.json de FrogNano trae vision_config completo (tower de visión de 24 capas, hidden 1024) más image_token_id y video_token_id: el modelo literalmente contiene los pesos para ver imágenes y vídeo, heredados de Qwen3.5-4B. El model card es igual de explícito en el otro sentido: «vision components are inherited but not post-trained», y en los casos de uso fuera de alcance: «Image and video use are unsupported despite components inherited from the base model».
El problema es la capa de encima: varios cuants comunitarios — bartowski, el Sakura de webmp3, los GPTQ-MLX de roman220220 — publican pipeline_tag: image-text-to-text en su ficha de Hugging Face. Ese tag es un artefacto de la clase del modelo base, no una promesa de funcionalidad. Y no es el único señuelo: bartowski distribuye hasta el proyector de visión convertido (mmproj-FrogNano-4B-2609-f16.gguf, 0,67 GB) — o sea, todo lo necesario para que llama.cpp acepte imágenes en un modelo cuyo vendor declara la visión explícitamente no soportada. Si buscas «modelo de visión pequeño local», FrogNano aparece en tus resultados con cara de multimodal, y lo que vas a obtener es un modelo que no fue post-entrenado para ver, no fue evaluado para ver y cuyo fabricante te lo dice en la ficha. ¿Funcionará un poco? Quizá haga algo, hereda pesos de un base multimodal. ¿Sabrás qué degrada el cuant sobre esos pesos? No hay ni una medición pública.
Es la misma lección de pi-harness y los modelos locales que superan a Claude Code: en los modelos agénticos pequeños, lo que importa no es solo el checkpoint, es el sistema alrededor — harness, herramientas, sandbox — y ninguna tabla de Hugging Face etiqueta eso.
Qué hardware lleva esto (y qué le falta a la ficha)
Los requisitos declarados son mínimos y el propio card confiesa lo que aún no ha validado:
| Qué | Valor | Estado |
|---|---|---|
| Pesos BF16 | ~9,3 GB | Declarado por el vendor; sigue del KV cache y del runtime |
| GPU mínima | «GPU servers», perfil exacto sin especificar | El card lo admite: «must still be validated before release» |
| Runtime | SGLang para los rollouts; Qwen3.5 es compatible con Transformers, vLLM, SGLang y KTransformers | Documentado |
| Contexto evaluado | ~131K tokens combinados (entrada + salida) | 150 pasos por trayectoria, 8.192 tokens por turno |
| CPU-only, desktop, móvil, cuants | No validados | Verbatim del card, a 11/10/2026 |
Un par de números propios, para dimensionar: el checkpoint son 4.659.865.088 parámetros, que en BF16 son 9,32 GB de pesos — cuadra con la cifra del card y lo puedes tener en un portátil con GPU de 12 GB con margen justo para contexto corto. El KV cache es barato por diseño: con 8 de cada 32 capas de atención completa (4 KV heads × 256 de head_dim), son ~32 KiB por token en BF16, unos ~4,3 GB a 131K tokens — estimación mía a partir del config, no cifra del vendor, y los estados de las capas lineales (Gated DeltaNet) se añaden aparte. En cuantización de pesos el modelo entra sobrado en una máquina doméstica — el Q4_K_M de bartowski ocupa 2,80 GB —; lo que nadie ha medido es cuánta calidad se queda por el camino.
La limitación de contexto, ojo, es del agente, no de la arquitectura: max_position_embeddings en el config es 262.144. El card habla de ~131K como contexto combinado evaluado del agente, con presupuesto de turnos. Y hay un detalle de entrenamiento que explica buena parte de la curva: las iteraciones 1-4 entrenaron con 65.536 tokens de contexto y 75 turnos; la quinta subió a ~131K y 150. El último salto de rendimiento (59,1 → 61,5) llega exactamente cuando el agente puede mirar más repo y dar más pasos. Leer más contexto es gratis en esta arquitectura; es la ventaja del híbrido de atención lineal.
Cuándo gana y cuándo pierde
Gana si: investigas o construyes agentes de código con hardware pequeño y quieres un punto de partida agéntico real en 4B — navegación de repos, edición multi-fichero, ejecución de tests — sin pagar ni servir un frontier model. Si tu dominio es el suyo (inglés, repos Python-heavy, suites de tests reproducibles, tareas bien acotadas) y lo ejecutas dentro de un sandbox con control como Leaf, el card declara exactamente para eso. Para experimentar con RL ejecutable y síntesis de tareas, es de las fichas más completas que ha publicado nadie: curva por iteraciones, metodología, análisis de reward hacking.
Pierde si: esperas un asistente generalista (no lo es ni lo pretende), visión (no soportada, por mucha etiqueta que veas), otros idiomas (solo inglés reclamado) o lenguas fuera del eje Python/JS/TS/Go. Y pierde por diseño si lo quieres para producción autónoma: el card admite que el post-entrenamiento “did not use dedicated safety-preference, refusal, harmful-content, or adversarial datasets” y que el modelo “should not be considered independently safety-aligned”, sin red-teaming de producto. Es un artefacto de investigación que exige revisión humana de cada parche, sandbox y tests de regresión. Que un vendor de tamaño Microsoft escriba eso en su propia ficha es raro, y a mi favor cuenta como honestidad, no como defecto.
Qué haría yo: si tengo un portátil con 16 GB de GPU y curiosidad, me bajaría el Q4_K_M de bartowski y lo probaría dentro de un harness con sandbox — el valor está en el sistema, no en chatear con el checkpoint — midiendo en mis propios tasks de repo, no en SWE-bench. En producción, ni de broma aún: modelo de investigación sin alignment independiente, cuants sin validar y un held-out (Terminal-Bench 31,1%) que recuerda que fuera de su distribución es otro modelo. Lo que sí copiaría ya es la idea: recompensa ejecutable y curriculum sintético calibrado a la frontera de aprendibilidad — el mismo patrón que OpenAI, Anthropic y los labs de agentes están persiguiendo por otros caminos, publicado aquí con la receta a la vista.
Qué vigilar
- La licencia contradictoria del propio repo. La tabla del model card dice «License: Apache License 2.0», pero el YAML del frontmatter y la API de Hugging Face etiquetan
license: mit(verificado 11/10/2026, sigue así). No es simbólico: condiciona qué puedes hacer con los pesos. Yo no resuelvo ambigüedades legales por deducción; si te importa comercialmente, el contacto del card es [email protected]. Esperable que lo arreglen — en cualquier dirección. - Validación de cuants y hardware doméstico. El card lo deja a las puertas: formatos cuantizados y desktop sin validar. Cuando aparezcan mediciones de calidad de los GGUF/MLX — de terceros, no del que lo cuantiza —, este párrafo de la ficha envejecerá rápido.
- TaskPilot como pieza separada. La síntesis de tareas calibradas a la frontera de aprendibilidad es la innovación transferible de esta ficha, más que el checkpoint. Si Microsoft la suelta como código o paper detallado — el repo del harness está vivo (último push 08/10/2026) —, es lo que cambiará cómo se entrenan agentes pequeños fuera de los labs.
- Evaluación independiente. A día de hoy, todo pasa por el vendor. La cifra que de verdad informaría: FrogNano evaluado por terceros en Leaf contra otros 4B (Qwen3.5-4B tal cual, Gemma de 4B, modelos de la familia Qwen con harnesses estándar). Si cae el 61,5% a la primera de cambio, habremos aprendido que la curva era del curriculum; si aguanta, la tesis de las tareas sintéticas gana un punto entero.
Fuentes
- Model card microsoft/FrogNano-4B-2609 y README raw — curva RL, held-out, TaskPilot, limitaciones, licencia (verificado 11/10/2026)
- Tech report: FrogNano: Training a 4B Coding Agent via Online Task Synthesis — abstract, metodología y análisis (arXiv 2609.07925, v1 07/09/2026); accesible también vía aka.ms/frognano-tech-report
- API de Hugging Face del repo oficial — 4.659.865.088 parámetros, 1.348 dl / 147 likes, tags (11/10/2026)
- config.json — 32 capas híbridas 3:1, max_position_embeddings 262.144, vision_config, tokens imagen/vídeo (11/10/2026)
- API HF search=FrogNano — ecosistema de cuants y descargas por repo (11/10/2026) · bartowski/FrogNano-4B-2609-GGUF — cuants IQ2_M a Q8_0 (Q4_K_M: 2,80 GB) y mmproj f16 incluido pese a visión no soportada
- microsoft/FrogNano en GitHub — Leaf harness, MIT, creado 25/08/2026, último push 08/10/2026 · Qwen/Qwen3.5-4B — base multimodal, Apache 2.0