El Qwen3.8 de 35B que nunca existió: anatomía de un fantasma en los repositorios oficiales

TL;DR

El 14 de agosto, el commit que añadió soporte de Qwen3.8 a ms-swift (el framework oficial de fine-tuning de Alibaba) incluía dos entradas para un Qwen3.8-35B-A3B y su variante FP8. Ese modelo no existía públicamente
El 16 de agosto a las 01:58 UTC, el commit a45f1d4 (“fix wrong model-ids”) borró ambas entradas y las sustituyó por el Qwen3.8-27B real. Cuatro horas después, otro commit eliminó model-ids duplicados
r/LocalLLaMA detectó el borrado casi en tiempo real: el hilo acumuló 504 puntos y 140 comentarios
Las dos lecturas posibles: un model-id erróneo en un PR (la explicación oficial implícita) o un modelo filtrado por accidente que aún no ha salido. Ninguna se puede descartar con la evidencia pública actual
Esto no es curiosidad de archivo: los repos de infraestructura se han convertido en la mejor fuente de inteligencia sobre lanzamientos futuros, y conviene saber leerlos

El commit que borró un modelo

ms-swift es el framework que Alibaba usa y mantiene para el fine-tuning de sus propios modelos. Cuando sale un Qwen nuevo, el soporte llega primero ahí, en el repositorio modelscope/ms-swift. El 14 de agosto, el commit ab726e9d (“[model] qwen3.8”) añadió la familia completa: el 2.4T-A95B, el 27B denso y, entre las líneas de la tabla de modelos soportados, dos entradas para Qwen/Qwen3.8-35B-A3B y Qwen/Qwen3.8-35B-A3B-FP8, con enlaces a ModelScope y Hugging Face.

El 27B y el gigante se anunciaron. El 35B no apareció por ningún canal oficial.

Dos días después llegó la corrección. El diff de a45f1d4 es inequívoco: elimina las filas del 35B-A3B y del 35B-A3B-FP8 y escribe en su lugar las del Qwen/Qwen3.8-27B y su FP8, tanto en la documentación en chino como en inglés y en el registro de modelos del código (swift/model/models/qwen.py, dos líneas cambiadas). El mensaje del commit, “fix wrong model-ids”, lo trata como un error tipográfico. El commit posterior 4065c1d0 (“remove duplicate model-ids”) limpió el resto.

Por qué la comunidad no se lo cree del todo

Si fuera solo un id mal escrito, el asunto no habría llegado a 500 puntos en r/LocalLLaMA. Hay tres detalles que alimentan la otra lectura:

1. El 35B-A3B es una arquitectura plausible y con pedigrí. El MoE de 35B con 3B activos ya existe como Qwen3.6-35B-A3B, y las entradas borradas lo registraban con model_type: qwen3_8, no qwen3_5. Es decir, alguien había mapeado ese nombre a la familia nueva. Los errores tipográficos no suelen venir con taxonomía correcta.

2. El ecosistema ya está preparado para un 35B de la generación 3.8. A día de hoy hay repositorios en GitHub como birdup000/qwen3-8-35b-a3b que describen literalmente “Qwen3.8 intelligence on the Qwen3.6-35B-A3B MoE runtime”, y guías para correr el 3.6-35B en 12GB de VRAM. La demanda de esa franja (calidad cercana al grande, coste cercano al pequeño) existe y está documentada.

3. El patrón ya ha pasado. No es la primera vez que un repositorio de infraestructura filtra un lanzamiento antes de tiempo: ver un model-id desaparecer tras haber estado público es la firma clásica de “esto salía el mes que viene y alguien lo mezcló en el PR antes de tiempo”.

Contra eso, la explicación del typo también tiene armas: quien editó la tabla pudo copiar la fila del Qwen3.6-35B-A3B como plantilla y cambiar el 6 por un 8 sin darse cuenta. Dos caracteres mal en un archivo de documentación ocurren cada semana en repos grandes. El propio hecho de que el mapping apuntara a qwen3_8 es consistente con una copia-pega a medias.

Cómo se filtran los modelos en 2026 (y cómo leerlo tú mismo)

Lo aprovechable del episodio es la técnica. Si quieres saber qué va a lanzar un laboratorio antes del anuncio, los lugares donde se deja rastro son:

Repos de frameworks propios (ms-swift, vLLM, transformers): los model-ids nuevos aparecen en PRs de soporte días o semanas antes del lanzamiento. La API de GitHub permite vigilar un repo por autor o por mensaje de commit
Documentación de compatibilidad: las tablas de modelos soportados son donde se colaron estas entradas. Un git log -p sobre esos archivos es más informativo que cualquier filtración
Borrados silenciosos: un commit que quita un model-id es más señal que uno que lo añade. Añadir puede ser error; borrar tras añadir significa que alguien con autoridad decidió que no debía estar ahí
Community forks y cuantizaciones: si aparecen GGUF o forks de terceros de un modelo que “no existe”, casi siempre hay checkpoint filtrado o acceso anticipado detrás

El caso Qwen3.8-35B encaja en las cuatro: soporte añadido en el framework oficial, entradas en la tabla de modelos, borrado silencioso y forks comunitarios esperando el checkpoint.

Qué haría yo

Nada, todavía. Si el 35B-A3B de la generación 3.8 existe de verdad, Qwen lo publicará en las próximas semanas y las entradas volverán a ms-swift, esta vez para quedarse. Si no, habremos aprendido que hasta el laboratorio más disciplinado con su calendario escribe ids de más en sus PRs.

Lo que sí haría es dejar de tratar los commits de ms-swift como ruido de mantenimiento. Vigilar la tabla de modelos soportados de un framework es la forma más barata que existe hoy de adelantarse un ciclo de lanzamiento a la noticia. Y cuando un hilo de 500 puntos en r/LocalLLaMA señale un diff de dos líneas, merece la pena leer el diff antes que el titular.

Fuentes

Commit a45f1d4 en modelscope/ms-swift (16 de agosto de 2026): fix wrong model-ids — diff con la sustitución de Qwen3.8-35B-A3B por Qwen3.8-27B
Commit ab726e9d en modelscope/ms-swift (14 de agosto de 2026): “[model] qwen3.8”, que introdujo las entradas originales
Hilo de r/LocalLLaMA (16 de agosto de 2026): Newer commits removed the Qwen 35B — 504 puntos, 140 comentarios
Análisis del modelo real: Qwen3.8-27B: lo que los benchmarks dicen y lo que no