Filtración de Spark3: los modelos pequeños de 1.7B y 4B de iFLYTEK se están integrando en vLLM

Spark3 no tiene pesos públicos, no tiene model card, no tiene anuncio — y sin embargo, esta semana aterrizó un pull request en el motor de inferencia vLLM que describe dos modelos, Spark3-1.7B y Spark3-4B, con un nivel de detalle notable. El pull request #53373 en el repositorio de vLLM, "[Model] Add Spark3 Model," añade soporte de servido nativo para la arquitectura Spark3: atención de ventana deslizante, un presupuesto de razonamiento controlable con cuatro niveles, contexto nativo de un millón de tokens en ambos tamaños, y un ID de modelo que apunta a iFLYTEK. Nada de eso está confirmado por el proveedor, y no se ha publicado nada. Esta es una pieza de "lo que sabemos hasta ahora": el pull request es real, y todo lo que se dice que hacen los modelos no está verificado hasta que iFLYTEK — o quien sea que publique Spark3 — publique realmente los pesos.

La filtración: una pull request que se lee como una hoja de especificaciones.

La señal es un PR abierto de vLLM, enviado por un usuario de GitHub llamado KnightYao (un colaborador con base en Hefei que menciona la Universidad de Ciencia y Tecnología de China), y al 23 de agosto de 2026 no ha sido fusionado. Un mantenedor de vLLM solicitó cambios el 22 de agosto con la nota "hold for discussions". El PR es temprano y controvertido, lo cual es normal para este tipo de integración — y también es inusualmente detallado para un PR de framework sobre un modelo que nadie fuera del laboratorio puede descargar.

El diff toca ocho archivos. Añade una implementación de Spark3ForCausalLM en el ejecutor de modelos de vLLM, un Spark3Config nativo registrado en los registros de configuración y modelos de vLLM, soporte para atención de ventana deslizante y atención completa, además de un control de salida de atención por cabeza, carga de pesos paralela en tensor y pipeline, y un analizador XML de herramientas Spark3 para que las llamadas a herramientas del modelo puedan decodificarse de forma estructurada. También añade una fila a la documentación de modelos admitidos de vLLM que enumera el checkpoint como XHToken/Spark3-1.7B. La descripción incluso afirma que la integración fue evaluada: 500 solicitudes concurrentes, 100% de éxito, aproximadamente 106 solicitudes por segundo y 13.5 mil tokens de salida por segundo en la configuración de prueba del autor. Esas cifras son autoinformadas por la persona que escribió el PR, no un benchmark independiente, y deben leerse exactamente así.

Por qué iFLYTEK es la matriz obvia — pero no confirmada —

Nada en el PR nombra al proveedor. Pero el ID del checkpoint que registra, XHToken/Spark3-1.7B, se encuentra bajo la organización XHToken en Hugging Face, y esa organización es de iFLYTEK: la página de la organización la identifica como una empresa, enlaza a opensource.iflytek.com y actualmente muestra cero modelos públicos y cero conjuntos de datos públicos. "XH" es la abreviatura natural de 星火 (Xinghuo, "Spark"), la familia de modelos de iFLYTEK. Añade la ubicación del autor en Hefei — iFLYTEK tiene su sede en Hefei — y la inferencia es tan sólida como puede serlo antes de que el proveedor la confirme.

Encaja con el patrón reciente de iFLYTEK. El Spark X2 de la empresa, lanzado en febrero de 2026, estaba dirigido explícitamente a casos de uso educativos, médicos, automotrices y de agentes, y su línea SparkAuto-EMM de modelos on-device se distribuye en tamaños pequeños, desde 0.5B hasta 7B. Dos días antes de que este comunicado saliera a la luz, en su conferencia de resultados intermedios del 21 de agosto, iFLYTEK dijo que un nuevo modelo insignia de propósito general construido íntegramente con cómputo nacional estaba en camino, con una versión por fases prevista "para finales de agosto" y un lanzamiento completo en su 1024 Developer Day de octubre. Si Spark3-1.7B y Spark3-4B forman parte de ese lanzamiento por fases o de una línea separada centrada en el edge es una pregunta abierta que el comunicado no responde.

Lo que se dice que son los modelos

Las afirmaciones del PR, todas sin verificar:

• Dos tamaños. Spark3-1.7B y Spark3-4B. Ambos se describen como diseños que priorizan la eficiencia y utilizan atención de ventana deslizante en lugar de una disposición de atención completa y densa.

• Contexto nativo de 1M de tokens en ambos.No es una promesa de modo extendido: el PR dice que el contexto es nativo a la arquitectura, lo que pondría un millón de tokens en un modelo lo suficientemente pequeño como para ser plausible en una sola GPU.

• Un presupuesto de razonamiento de cuatro niveles. El razonamiento puede configurarse en ninguno, bajo, medio o alto, un diseño de razonamiento conmutable que permite a una aplicación intercambiar profundidad de razonamiento por latencia y costo por llamada.

• Más de 200 idiomas y dominio de los exámenes chinos. El comunicado de prensa afirma un sólido rendimiento en la respuesta a preguntas de K-12 y Gaokao — un sello distintivo de iFLYTEK, dado el negocio educativo de la empresa — y una cobertura multilingüe de más de 200 idiomas.

• Orientación a codificación y agentes. Afirma una fuerte generación de código, uso de herramientas, ejecución en varios pasos y razonamiento de contexto largo para su tamaño, respaldado por el analizador de herramientas XML incluido en el mismo PR.

El contexto nativo de 1M en un modelo de 1.7B es lo que vale la pena notar

La longitud de contexto es donde los modelos pequeños se han quedado estancados. En el panorama actual de pesos abiertos, un modelo de 1.7B–4B suele venir con una ventana nativa de 32K–256K: los checkpoints pequeños de Qwe​n3 tienen 32K nativos con 131K mediante rope scaling, e incluso la mejora de Qwen3.5 a 256K nativos en variantes pequeñas es un paso reciente. El contexto de un millón de tokens ha sido hasta ahora una característica de los modelos grandes: los checkpoints de G​LM con contexto de 1M tienen cientos de miles de millones de parámetros. Si Spark3 realmente ofrece una ventana nativa de 1M en un modelo de 4B, sería una especificación genuinamente inusual, y la arquitectura de atención de ventana deslizante es precisamente cómo se hace que sea económica en memoria. La advertencia que debe acompañar esto: una cifra titular de 1M nativo es fácil de escribir en un comunicado de prensa y difícil de hacer útil en la práctica. La calidad del contexto largo — ¿puede el modelo encontrar y usar realmente un dato a 700K tokens de distancia? — es una cuestión separada de cuántos tokens caben en la ventana, y todavía no existe ninguna evaluación independiente.

El presupuesto de pensamiento controlable importa por la misma razón. Cuatro niveles de razonamiento (ninguno / bajo / medio / alto) son un diseño de pensamiento conmutable en el espíritu del modo de pensamiento encendido/apagado de Qwe​n3, pero más rico: en lugar de una elección binaria, una aplicación puede elegir un nivel por solicitud — sin pensamiento para una traducción, alto para un turno de agente de múltiples pasos — y pagar solo por el razonamiento que necesita. Para una carga de trabajo agéntica o por lotes, ese es exactamente el control que convierte un modelo pequeño "capaz pero costoso" en uno con costos gestionados.

La receta de post-entrenamiento se ajusta a un patrón de 2026.

El PR dice que Spark3 fue post-entrenado con "Scaled Reinforcement Learning y MOPD". MOPD — Multi-Teacher On-Policy Distillation — es una técnica real y actual, descrita en un artículo de arXiv (2606.30406): entrenar maestros RL especializados por dominio en paralelo y luego destilarlos de vuelta en un solo estudiante usando los rollouts del propio estudiante, minimizando la KL inversa por token contra el maestro adecuado para cada prompt. Es la receta de 2026 que permite que un solo modelo herede habilidades matemáticas, de codificación y de agente sin que un entrenamiento RL luche contra otro, y se le ha atribuido públicamente el post-entrenamiento de modelos como MiMo Flash V2, DeepSeek V4 y Nemotron 3 Ultra. Que Spark3 cite la misma receta lo sitúa en esa generación — modelos pequeños, técnicas de post-entrenamiento de frontera. También significa que las "fuertes afirmaciones sobre codificación y agente" tienen un mecanismo plausible detrás. Plausible no es lo mismo que demostrado: las afirmaciones siguen siendo reportadas por el proveedor hasta que aparezcan los pesos y se ejecuten evaluaciones independientes.

Lo genuinamente desconocido

Casi todo lo que tiene un calendario:

• Fecha de lanzamiento. Sin pesos en Hugging Face, sin anuncio, sin cronograma. La organización XHToken está vacía hoy.

• Confirmación del proveedor. iFLYTEK no ha dicho nada sobre Spark3. El enlace de la organización XHToken es una prueba contundente, no una declaración oficial.

• Si se trata del buque insignia por fases. La versión por fases de "finales de agosto" del nuevo buque insignia de iFLYTEK podría ser esta — o no tener relación. El comunicado de prensa no da ninguna fecha.

• Precios y licencia. No se revela nada. La familia Spark de iFLYTEK históricamente se ha servido principalmente a través de API en lugar de pesos abiertos, por lo que queda abierta la cuestión de si Spark3-1.7B y Spark3-4B son checkpoints abiertos o un objetivo de servicio interno.

• Cada benchmark. Las cifras de rendimiento en el PR son la prueba de servicio del propio autor, no una evaluación independiente, y ningún leaderboard ha puntuado el modelo porque no existe ningún modelo públicamente.

Qué ver

La organización XHToken en Hugging Face es el canal de lanzamiento a tener en cuenta. Si el modelo es real, sus pesos — o al menos una tarjeta de modelo — deberían aparecer allí, y que la organización pase de cero a un repositorio público es la señal más importante. Algunas cosas que comprobar en cuanto eso ocurra:

• El número de contexto. ¿Es 1M nativo, o extendido con RoPE a costa de calidad? El PR dice que es nativo; las model cards son donde eso se resuelve.

• La API de presupuesto de razonamiento. Cómo se exponen los cuatro niveles de razonamiento — como parámetro de muestreo, campo de plantilla de chat o variante de modelo independiente — determina lo fácil que resulta usarlos realmente.

• La licencia.Los pesos abiertos convertirían a Spark3 en el primer modelo sub-5B con contexto nativo de 1M disponible para autoalojamiento; un lanzamiento solo con API lo convertiría en un tipo de producto diferente.

• El calendario de anuncios de iFLYTEK. Se promete el buque insignia por fases para finales de agosto y el lanzamiento completo en el 1024 Developer Day de octubre. Si Spark3 forma parte de cualquiera de los dos, la descripción oficial dirá lo que el comunicado de prensa deja abierto.

• Si el PR se fusiona. El soporte de vLLM importa como señal de calidad y como infraestructura: el primer runtime con soporte nativo de Spark3 hace que el modelo sea ejecutable en producción el mismo día en que se publiquen los pesos.

Lo que un desarrollador debería hacer ahora mismo.

Nada. No hay ningún modelo al que llamar, ningún peso que descargar, ninguna clave API que aprovisionar: cualquier herramienta que hoy afirme servir Spark3 está sirviendo otra cosa. Lo que sí puedes hacer es decidir cómo lo evaluarás el día que aparezca, porque es un modelo con una promesa muy comprobable: un 1.7B o 4B que lee un millón de tokens y razona a cuatro profundidades es o bien una categoría genuinamente nueva de modelos pequeños o bien una historia de ficha técnica, y la diferencia se puede medir en una tarde con tu propia carga de trabajo.

Ahí es también donde una capa de enrutamiento demuestra su valor. En OrcaRouter, un modelo no es un contrato al que te comprometes; es una entrada en un catálogo que invocas mediante una sola API, y los precios de lista del proveedor se trasladan sin margen alguno — así que cuando un nuevo modelo aparece en el catálogo de un proveedor, su precio real ya está disponible de nuestro lado ese mismo día, y probarlo no requiere una segunda integración ni renegociación. Para un modelo tan poco probado como Spark3, el patrón sensato es el mismo que usarías ante cualquier novedad prometedora: ponlo detrás de una conmutación por error automática en el DSL de enrutamiento, deja que una parte del tráfico llegue a él y mantén un modelo probado al otro lado de la regla, de modo que una mala evaluación, una sorpresa con la licencia o un resultado decepcionante de contexto largo sean un cambio de enrutamiento y no un incidente. Una clave, un endpoint, más de 200 modelos — y cuando Spark3-1.7B o Spark3-4B sean realmente ejecutables, el traslado de precios y la conmutación por error se le aplican igual que a cualquier otro modelo.

El resumen honesto es una oración, no un veredicto: un PR de framework escrito esta semana afirma que iFLYTEK tiene dos modelos pequeños con contexto nativo de un millón de tokens y un presupuesto de razonamiento de cuatro niveles, y no se ha publicado ninguna evidencia que respalde nada de eso. Vigila la organización XHToken, vigila la promesa de iFLYTEK de fin de agosto y, cuando los pesos sean reales, pásalos por una regla de enrutamiento con conmutación por error antes de apostar una ruta de producción por ellos. Ese es todo el manual para una filtración: cree en la infraestructura, verifica el modelo y mantén la salida barata.