LFM3-1.7B en vLLM: Nueve días después, el soporte nativo sigue siendo dos PRs abiertos

de Liquid AILFM3-1.7B se lanzó el 27 de octubre de 2026 con una ficha del modelo que imprime vllm serve "LiquidAI/LFM3-1.7B" como si fuera un comando normal. Nueve días después, el upstream de vLLM no tiene ninguna arquitectura Lfm3ForCausalLM con la que ejecutarlo. Lo que existe en su lugar es una solicitud de función abierta el 30 de octubre, una pull request de kernel sobre la que se apoya todo lo demás y seis PR abiertos de modelos —dos de los cuales implementan el mismo modelo de texto LFM3-1.7B de dos maneras distintas, y ninguno de los dos se ha fusionado.

Esa brecha es toda la historia aquí, y es estrecha. El modelo es real y se puede descargar; el soporte en tiempo de ejecución es una cola. Este es un artículo de lo que sabemos hasta ahora sobre la cola: qué está en curso, qué se ejecuta realmente hoy y qué tendría que concretarse antes de que «funciona con vLLM» en la ficha de un modelo se vuelva cierto en el sentido en que un plan de despliegue necesita que lo sea.

La tarjeta dice vLLM. La tabla de modelos compatibles dice LFM2.

La documentación de modelos compatibles del propio vLLM enumera tres arquitecturas de Liquid AI: Lfm2ForCausalLM, Lfm2MoeForCausalLM y Lfm2VlForConditionalGeneration. No hay ninguna entrada de LFM3. La tarjeta del LFM3-1.7B, por su parte, indica que el checkpoint "funciona con vLLM, SGLang y compilaciones de llama.cpp compatibles con LFM3" y proporciona un comando de servicio sin ningún flag adjunto.

La reconciliación está en la propia configuración del checkpoint. LFM3-1.7B incluye un auto_map que apunta a su modeling_lfm3.py empaquetado, así que el código del lado de Hugging Face existe y se clona a sí mismo en los cargadores que permiten código remoto. El issue de seguimiento de vLLM para el port, #64645 — «[Feature]: Support LiquidAI LFM3 models», abierto el 30 de octubre por abhijithneilabraham — es tajante sobre la consecuencia: «vLLM no tiene Lfm3ForCausalLM». La alternativa que enumera es la válvula de escape que la mayoría de la gente acabará usando este mes: «Ejecutar LFM3 mediante el código remoto del checkpoint con el backend de Transformers. Eso renuncia a la atención paginada y a la caché de estado de conv.»

Ese compromiso merece decirse sin rodeos, porque «se ejecuta en vLLM» y «se ejecuta en el backend de transformers de vLLM» son productos diferentes. La atención paginada es el mecanismo que permite a vLLM agrupar solicitudes de longitudes muy distintas sin desperdiciar memoria KV; la caché de estado de convolución es la misma idea aplicada a las capas de convolución corta de esta arquitectura. Quita ambas y tendrás un endpoint funcional que ha renunciado a las dos razones por las que existe vLLM. Para un modelo de 1.7B servido con baja concurrencia, eso puede ser un fin de semana aceptable, no una forma de producción aceptable.

¿Por qué un modelo de 1.7B necesita siquiera trabajo en kernels?

LFM3-1.7B no es un simple reajuste de la familia LFM2 que vLLM ya sirve. Es un híbrido de veinticuatro capas con tres tipos de capa en lugar de dos: 13 capas de convolución corta con compuerta, 5 capas de atención de ventana deslizante con una ventana de 256 tokens y 6 capas de atención completa. La configuración del checkpoint detalla la geometría —conv_L_cache: 7, sliding_window: 256, un vocabulario de 128K— y la propia lista de diferencias del issue de vLLM añade QK RMSNorm, una compuerta de salida de atención sigmoide por cabeza, normalización tipo sándwich y RoPE parcial (partial_rotary_factor: 0.5) en las capas de atención completa, dispuestas en la misma forma de cola cero que usa Gemma 4.

El número que rompió el port es el siete. La convolución corta de LFM2 tiene tres taps de ancho; LFM3 la amplió a siete. Los kernels Triton causal_conv1d de vLLM desenrollan un conjunto fijo de anchos y, como lo expresa el issue de seguimiento: "El kernel de prefill Triton causal_conv1d desenrolla anchos de 2 a 4 y el kernel de decode de 2 a 6, por lo que un modelo de ancho 7 no puede ejecutarse en CUDA hoy".

Así que el primer PR de la pila no es un modelo en absoluto. El #64647, «[Kernel] Soporte para conv1d causal de ancho 7», abierto el 30 de octubre por abhijithneilabraham, toca dos archivos y 186 líneas añadidas: extiende el kernel de prefill de anchos 2–4 a 2–7 y el kernel de decodificación de 2–6 a 2–7, y hace que ambos wrappers lancen ValueError para cualquier cosa fuera de ese rango. La propia descripción del PR explica por qué el rechazo importa tanto como la extensión: antes del cambio, «un peso más ancho se ejecutaba sin una rama correspondiente y devolvía valores incorrectos». La corrupción numérica silenciosa es un fallo peor que un rechazo, y es el tipo de cosa que solo aparece en el modelo que te tocó probar.

Una salvedad merece acompañar a ese PR. Su autor declara sin rodeos que no dispone de una máquina con CUDA: la ruta de referencia de CPU supera 96 pruebas, los kernels de Triton se verificaron mediante análisis estático sobre el AST del kernel y la validación en GPU queda en manos de CI. Se trata de una declaración honesta, no de un defecto, pero significa que el único cambio del que depende cada uno de los demás PR de LFM3 aún no se ha ejercitado en el hardware en el que la mayoría de los lectores lo ejecutarán.

Dos implementaciones del mismo modelo de texto

En seis días, dos grupos distintos escribieron soporte nativo de LFM3 para vLLM. No son variantes de un mismo parche; son diseños independientes que casualmente instalan el mismo nombre de arquitectura.

PR #64959, «[Model] Añadir LiquidAI LFM3 (Lfm3ForCausalLM)», abierto el 1 de noviembre por atmikshetty, es el conservador: siete archivos y, según su propia descripción, reutiliza ShortConv con ancho 7, Lfm2MLP, el mapeador de pesos de LFM2 y el RoPE proporcional existente, sin cambiar ningún componente central. Registra el modelo en el registro, lo añade al conjunto de pruebas de modelos híbridos y a la tabla de modelos compatibles y —de forma útil para cualquiera que consiga ponerlo en marcha— documenta las flags de servicio con las que lo validó: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. Su sección de validación informa de que pasan 324 pruebas de kernel en una A100-SXM4-40GB en BF16, de que pasan las pruebas de registro e inicialización y de una comparación de log-probabilidades frente a la referencia de código remoto de Hugging Face.

PR #65826, "[Model] Add LFM3-Text", abierto el 5 de noviembre por paulpak58 —de Liquid AI— es la versión propia del proveedor: diez archivos y 829 líneas añadidas, con su propia clase de configuración en transformers_utils/configs/lfm3.py y su propio módulo de pruebas. Se abrió como "[Model] Add LFM3" y se retituló ese mismo día cuando la familia se dividió en cuatro PR encadenados: #65826 para texto, #65827 para visión-lenguaje, #65828 para audio y #65829 para omni, cada uno construido sobre el anterior.

Los dos no están tanto en conflicto como en paralelo, y la discusión muestra claramente el entramado de dependencias. Sobre el PR del kernel, paulpak58 escribió el 4 de noviembre: «Tenemos nuestros propios PR internos para los modelos LFM3, pero esta es una adición limpia que podemos respaldar». Sobre el PR de texto de la comunidad, abhijithneilabraham sugirió que la fusión podría necesitar que primero se fusionara el trabajo de transformers de Liquid —«creo que la fusión de este PR requiere el PR de transformers de @paulpak58»—, a lo que atmikshetty respondió que Lfm3Config aún no está en una versión de transformers, así que la rama «carga la configuración mediante trust_remote_code desde el checkpoint, y la ejecución usa el modelo nativo de vLLM». Esa es la segunda puerta en la que la mayoría de los lectores no habrá pensado: incluso un PR de vLLM ya fusionado necesita una clase de configuración que se distribuya en algún lugar.

En el lado de transformers, la PR equivalente es la #50322, «[Model] LFM3 Family: LFM3-Text», abierta el 3 de noviembre y que sigue abierta, separada de una PR de familia más grande. Su propia nota sobre la convolución coincide con el problema de vLLM: la conv corta es «solo de torch en LFM3 (los kernels causal_conv1d del Hub admiten anchos de 2 a 4; LFM3 usa 7)».

La visión-lenguaje también se está duplicando. Además del #65827 de Liquid, un PR independiente de LFM3-VL (#65450, abierto el 3 de noviembre) sigue abierto y depende del PR de texto de la comunidad. Así que, a día de hoy, hay seis PR de LFM3 abiertos repartidos entre dos bandos y ninguno fusionado.

¿Qué se ejecuta realmente hoy?

Dejando a un lado las especulaciones, el panorama práctico del 5 de noviembre es el siguiente.

• vLLM, nativo — no es posible en una compilación estándar. No hay Lfm3ForCausalLM en el registro, no hay ninguna fila de LFM3 en la tabla de modelos compatibles, y el PR que añadiría una sigue sin fusionarse.

• vLLM, backend de transformers — la solución alternativa documentada, que usa el código remoto incluido en el checkpoint y trust_remote_code. Pierdes la atención paginada y la caché de estado de convolución; conservas el servidor compatible con OpenAI.

• SGLang — la ruta de servidor propia del proveedor. La publicación de lanzamiento de Liquid mide sus cifras de rendimiento en una única NVIDIA B300 en BF16 con SGLang, incluidos 3.600 millones de tokens por día con 1.024 solicitudes concurrentes. vLLM aparece en esa publicación solo como el entorno de ejecución en el que se servían los modelos de la competencia.

• llama.cpp — la ficha se refiere a «compilaciones de llama.cpp compatibles con LFM3», lo cual es una condición real y no una fórmula de relleno; las cifras de Liquid en el dispositivo corresponden a llama.cpp con Q4_0 y un contexto de 32K.

• MLX — las notas de la versión 0.33.0 del proyecto independiente vLLM-Metal enumeran los checkpoints de texto LFM3 MLX, detrás de --trust-remote-code. Ese es un código base diferente del vLLM upstream y no implica compatibilidad con CUDA.

• Alojado — API y playground propios de Liquid. La ficha no ofrece una lista de precios, así que el costo por token no es algo que puedas presupuestar con material público.

Dos cifras ponen en perspectiva el caso del autoalojamiento. Los pesos son lo bastante pequeños como para que la memoria no sea la limitación —Liquid afirma que alrededor de 1 GB a 4 bits— y el proveedor dice que un contexto de 128K tokens cuesta aproximadamente 1,6 GB de caché KV. La limitación es la pila de servicio, no la GPU.

¿Qué cambiaría esto, en orden?

La cadena de dependencias es inusualmente limpia, lo que hace que eso que merece la pena seguir sea inusualmente concreto. Primero, #64647 tiene que fusionarse, porque cualquier otro PR de LFM3 o incluye ese commit o está apilado sobre él. Después, uno de los dos PR de texto tiene que superar la revisión: el de la comunidad tiene el historial de validación más completo; el de Liquid cuenta con el autor que también está al frente del lado de transformers. Luego, Lfm3Config tiene que incluirse en una versión de transformers, o cada despliegue seguirá pasando trust_remote_code. Solo después de eso LFM3-VL-2B, LFM3-Audio-2B y LFM3-Omni-2B se vuelven realistas, y esos quedan detrás de más PR que asumen que el modelo de texto ya está incluido.

Nada de esto debería interpretarse como una crítica al ritmo. Nueve días desde un lanzamiento hasta una pila completa y probada de PR de kernel y modelo es rápido, y el hecho de que dos equipos independientes hayan producido implementaciones funcionales en menos de una semana dice más de lo cerca que está LFM3 de LFM2 que de cualquier retraso. Pero una tarjeta de modelo es una declaración de compatibilidad, y la lectura honesta de lo que LFM3-1.7B es hoy es «compatible con vLLM mediante el backend de transformers», no «con soporte de vLLM».

Si necesitas un modelo pequeño que llame a herramientas esta semana

LFM3-1.7B es una propuesta atractiva. Las cifras que reporta su proveedor son sólidas justo donde los modelos pequeños suelen fallar —71.39 en BFCL V4, 80.36 en ToolSandbox, 96.66 en IFEval, 43.40 en SWE-bench Verified— frente a una media general de 49.37 que Liquid sitúa por delante de su propio LFM2.5-2.6B, con 31.55. Son evaluaciones del propio proveedor, ejecutadas por la empresa que creó el modelo, sin reproducción independiente y sin ninguna entrada en Artificial Analysis que hayamos podido encontrar a día de hoy; conviene tratar el orden como una hipótesis y las cifras individuales como afirmaciones. La advertencia que acompaña viene de la misma fuente: la ficha del modelo desaconseja la programación agéntica y el razonamiento complejo de varios pasos, y los benchmarks de conocimiento coinciden con esa advertencia: 63.37 en GPQA Diamond y 65.56 en RULER a 128K no son las cifras de un generalista.

La decisión no se trata realmente del modelo. Se trata de si puedes permitirte construir sobre una ruta de servicio que actualmente es una pull request abierta. Si puedes ejecutar SGLang o llama.cpp, puedes usar LFM3-1.7B hoy y la cuestión de vLLM es académica. Si tu stack es vLLM por política, estás eligiendo entre la falta de atención paginada del backend de transformers y esperar.

Hay una tercera opción que vale la pena nombrar para las cargas de trabajo que no pueden esperar: enrutar otra cosa. OrcaRouter no incluye LFM3-1.7B — una consulta a nuestro catálogo hoy devuelve más de 200 IDs de modelos y ninguno de ellos es de Liquid —, así que esto no es una propuesta para llamarlo a través de nosotros. Es el punto más simple: un PR del kernel sin fusionar es un mal punto único de fallo para una ruta de producción. Poner un modelo alojado detrás de una sola API y con conmutación por error automática te cuesta un cambio de configuración, y te permite incorporar LFM3-1.7B el día que se fusione su soporte nativo en lugar del día en que termines de apostar por él. Si estás modificando el modelo en lugar de solo llamarlo, nuestro propio LFM3-1.7B-abliterated lanzamiento es una ablación de la dirección de rechazo del mismo checkpoint, y hereda exactamente esta situación de servicio.

La versión corta

LFM3-1.7B ya está disponible, es pequeño y resulta muy adecuado para las tareas de llamada a herramientas de un solo turno para las que fue entrenado. Su soporte para vLLM se está escribiendo ahora mismo, por dos equipos, sobre una extensión de kernel que aún no ha sido ejecutada en CUDA por la persona que la escribió. Sigue primero #64647: cuando se fusione la convolución de ancho 7, el resto del stack avanzará rápidamente, y «compatible con vLLM» en la tarjeta del modelo dejará de ser una afirmación sobre código remoto y pasará a ser una afirmación sobre atención paginada y procesamiento por lotes. Hasta entonces, cualquiera que cite «soporte de vLLM desde el primer día» para este modelo está citando algo que el repositorio todavía no contiene.