16 puntos por GN⁺ 2026-03-06 | 2 comentarios | Compartir por WhatsApp
  • La familia de modelos Qwen3.5 (0.8B~122B) puede ajustarse con fine-tuning basado en texto y visión usando Unsloth, un framework open source para fine-tuning de LLM y aprendizaje por refuerzo
  • Unsloth ofrece una velocidad de entrenamiento 1.5 veces mayor que FlashAttention-2 y 50% menos uso de VRAM, lo que permite entrenamiento eficiente con configuración bf16 LoRA
  • A través de notebooks de Colab, se pueden probar gratis los modelos 0.8B, 2B y 4B, y también hay notebooks para entornos A100 con los modelos 27B y 35B
  • Los modelos MoE (35B, 122B, etc.) son compatibles con entrenamiento 12 veces más rápido, 35% menos VRAM y longitud de contexto 6 veces mayor gracias a kernels recientes
  • Después del entrenamiento, los modelos pueden exportarse a varios formatos de despliegue como GGUF, vLLM, Ollama, LM Studio y SGLang

Resumen del ajuste fino de Qwen3.5

  • La familia de modelos Qwen3.5 (0.8B, 2B, 4B, 9B, 27B, 35B‑A3B, 122B‑A10B) puede ajustarse con Unsloth
    • Compatible tanto con texto como con visión
    • Qwen3.5‑35B‑A3B bf16 LoRA funciona con 74GB de VRAM
  • Unsloth ofrece 1.5 veces más velocidad de entrenamiento y 50% menos uso de VRAM
    • Uso de VRAM: 0.8B(3GB), 2B(5GB), 4B(10GB), 9B(22GB), 27B(56GB)
  • Se pueden probar los modelos 0.8B, 2B y 4B con notebooks gratuitos de Google Colab
  • Para mantener la capacidad de razonamiento, se recomienda una composición de datos que incluya al menos 75% de ejemplos de reasoning
  • También es posible hacer Full Fine-Tuning (FFT), pero el uso de VRAM aumenta 4 veces

Entorno y configuración de entrenamiento

  • Qwen3.5 es un modelo multilingüe compatible con 201 idiomas
  • También admite Reinforcement Learning (RL) y Vision RL (VLM RL) mediante Unsloth
  • Hay notebooks de Colab con A100 para Qwen3.5‑27B y Qwen3.5‑35B‑A3B
  • Para entrenamiento local, es necesario actualizar a la versión más reciente
    • Comando: pip install --upgrade --force-reinstall --no-cache-dir unsloth unsloth_zoo
  • transformers v5 es obligatorio; las versiones anteriores no funcionan
  • El entrenamiento inicial puede ser lento por la compilación del kernel Mamba Triton (especialmente en GPU T4)
  • No se recomienda entrenamiento con QLoRA (4-bit)

Ajuste fino de modelos MoE (35B, 122B)

  • Compatibilidad con los modelos Qwen3.5‑35B‑A3B / 122B‑A10B / 397B‑A17B
    • 12 veces más rápido, 35% menos VRAM y longitud de contexto 6 veces mayor
  • Se recomienda bf16 LoRA o Full Fine-Tuning
  • MoE QLoRA 4-bit no se recomienda por limitaciones de BitsandBytes
  • El kernel MoE de Unsloth viene activado por defecto; se puede cambiar el backend con UNSLOTH_MOE_BACKEND
  • Router-layer fine-tuning viene desactivado por defecto por motivos de estabilidad
  • Qwen3.5‑122B‑A10B bf16 LoRA requiere 256GB de VRAM
    • Si se usan varias GPU, configurar device_map = "balanced" o consultar la guía de multiGPU

Quickstart

  • Se incluye un ejemplo de SFT solo para texto (ajuste fino supervisado)
  • Qwen3.5 tiene una arquitectura de Causal Language Model + Vision Encoder
    • Es necesario instalar dependencias de visión (torchvision, pillow)
  • Se recomienda usar la versión más reciente de Transformers
  • El entrenamiento con GRPO puede realizarse con inferencia de Unsloth tras desactivar fast vLLM
  • Si ocurre OOM (falta de memoria)
    • per_device_train_batch_size=1, reducir max_seq_length
    • Mantener gradient_checkpointing="unsloth" para ahorrar VRAM y ampliar el contexto
  • Se incluye un ejemplo de loader MoE bf16 LoRA

Ajuste fino de visión

  • Compatible con el ajuste fino de visión de los modelos multimodales Qwen3.5
    • Se pueden usar los notebooks de RL Qwen3-VL GRPO/GSPO (cambiando solo el nombre del modelo)
  • Se puede elegir entre entrenamiento solo de visión o solo de texto
    • Ajuste fino selectivo entre capas Vision, Language, Attention y MLP
    • El valor por defecto es todo activado
  • Para entrenamiento con múltiples imágenes, consultar la guía separada de multi-image vision

Guardado y despliegue de modelos

  • Compatible con varios métodos de despliegue como llama.cpp, vLLM, llama-server, Ollama, LM Studio y SGLang

Guardado en GGUF

  • Unsloth admite guardado directo en formato GGUF y subida a Hugging Face
  • Si el rendimiento empeora durante la inferencia, la causa principal suele ser el uso de una chat template o token EOS incorrectos

Guardado en vLLM

  • vLLM 0.16.0 no es compatible con Qwen3.5
    • Se requiere 0.170 o superior o la versión Nightly
  • Se puede guardar en 16-bit y guardar solo los adaptadores LoRA
  • Para más detalles, consultar la guía de inferencia de Unsloth

2 comentarios

 
hmmhmmhm 2026-03-06

La vez pasada, cuando probé a correr fine-tuning con un agente, parecía que el problema de sobreajuste ocurría con frecuencia según los datos; en este notebook me da curiosidad saber si será posible con la combinación de LoRA/QLoRA.

 
GN⁺ 2026-03-06
Comentarios en Hacker News
  • Probé ajustar fino modelos Qwen en hardware NVIDIA Jetson y el rendimiento fue sorprendentemente bueno.
    Desplegué varias variantes de 7B para casos de IA en el edge, y fueron especialmente útiles en entornos como inspección industrial o análisis de retail, donde la latencia importa más que la precisión.
    Gracias al ajuste fino con LoRA, el modelo se redujo lo suficiente como para encajar bien en memoria unificada, y la velocidad de inferencia en tiempo real también fue suficientemente rápida.
    Lo que más me sorprendió fue la eficiencia energética: Jetson Orin pudo ejecutar inferencia continua con menos de 15W, ahorrando mucha más energía que hacer ida y vuelta a la nube.

    • Este comentario parece generado por IA.
      Últimamente veo mucho este tipo de comentarios con formato de anécdota falsa en Twitter y Reddit. Parecen escritos por una persona real, pero da la impresión de que son historias inventadas.
    • Interesante. Me gustaría saber si podrías dar ejemplos de tareas industriales donde esté bien perder un poco de precisión.
    • Me da curiosidad conocer casos concretos de qué tareas hacen realmente con este tipo de modelos.
    • Es una pregunta sencilla, pero me hace pensar si para este tipo de usos no bastaría con una red neuronal tradicional.
    • Mencionaste correr un modelo de 7B a 15W; me da curiosidad saber cuál modelo de la serie Orin era.
      Si era Nano (40 TOPS), NX (100) o AGX (275), y si probaste modelos más grandes en Thor(2070).
  • Me interesan ejemplos reales de gente que ajusta fino modelos pequeños o medianos y los usa en producción.

    • Hay un hilo en X que resume este tema.
      Post relacionado
      Por ejemplo,
      1. Cursor mejoró la tasa de aceptación 28% con RL en línea (enlace)
      2. Vercel aplicó RFT a su modelo AutoFix (enlace)
      3. Perplexity Sonar es un modelo ajustado para Deep Research Reasoning (enlace)
      4. DoorDash construyó un modelo de extracción de atributos con LoRA/QLoRA (enlace)
      5. El modelo de detección de inundaciones de NASA (enlace)
      6. RL en línea para robótica
      7. Colección de casos de OpenAI RFT (enlace)
      8. Mejora del rendimiento de modelos de Mercor basada en datos de expertos (enlace)
    • Probé hacer benchmark de una tarea simple de clasificación de documentos con varios modelos.
      Comparé precisión y costo entre modelos como Llama-70B, Gemma-4B y Ministral-14B,
      y hasta los modelos de 4B mostraron un rendimiento bastante decente.
      Aun así, siento que se perdió la intuición sobre la relación entre “cantidad de datos y mejora de rendimiento”.
      Estoy pensando en intentar un ajuste fino por mi cuenta.
    • Estoy considerando hacer ajuste fino para mejorar la precisión del reconocimiento de mi escritura a mano.
      El modelo base funciona bien, pero por mi mala letra a veces hay errores de reconocimiento.
    • Como buen ejemplo, recomiendo la guía del blog de Atredis sobre entrenamiento de LLM.
  • Últimamente parece que la necesidad del ajuste fino en LLM está disminuyendo.
    Los modelos más recientes manejan tareas complejas bastante bien solo con few-shot learning.
    Modelos con ventanas de contexto grandes como Qwen3.5 pueden sustituirse suficientemente bien con un diseño de prompts potente.
    Sigue teniendo sentido en modelos de imagen o en LLM más antiguos, pero en los LLM de texto se está volviendo cada vez más ineficiente.

    • Si ajustas fino un modelo pequeño para producir una salida estructurada específica, puedes hacer inferencia a gran escala con bajo costo.
      Expandir el contexto en modelos grandes sale demasiado caro.
    • Los LLM siguen avanzando, pero todavía hay mucho potencial en áreas como el aprendizaje continuo en robots o el ajuste fino multimodal con LoRA.
      También es posible hacer ajuste fino de visión + texto como en la guía de Unsloth.
      En adelante, parece probable que el enrutamiento de modelos se vuelva común: usar modelos LoRA pequeños en local y mandar las tareas complejas a la nube.
      De hecho, DoorDash, Vercel, NASA y Cursor también están haciendo su propio ajuste fino.
    • Intenté ajustar un modelo para que coincidiera con mi estilo de escritura.
      Lo probé con Claude, Qwen, Llama y Gemma, pero la transferencia de estilo no salió bien.
      Incluso usando cientos de mis propios comentarios como datos de entrenamiento, el modelo Instruct ya estaba tan sobreajustado que casi no se podía seguir entrenando.
    • En una frase: por los datos para adultos.
      Qwen filtró ese tipo de datos durante el entrenamiento, así que solo se pueden recuperar mediante ajuste fino.
      Ejemplo relacionado: modelo LoRA de Qwen3 de chenrm
    • En servicios reales, el ajuste fino sigue siendo importante.
      La combinación de comportamiento determinista y auditable, reducción de alucinaciones y LoRA/QLoRA para bajar costos es útil.
      Si se usa junto con RAG y FAISS vector DB, se puede evitar que el contexto se dispare.
      A largo plazo, gestionar adaptadores pequeños será mucho más eficiente que seguir ajustando prompts.
  • Es una lástima que hayan reemplazado a algunos líderes del equipo de Qwen.
    Me preocupa que, al pasar a una nueva dirección más centrada en el negocio, se debilite el espíritu open source.

  • Con un enfoque RAG centrado en documentos parece suficiente, así que me pregunto si el ajuste fino realmente da mejores resultados.

    • Los modelos especializados sí superan claramente el SOTA.
      Ejemplo: FlashCheck
    • Antes el modelo tab-next-action de Cursor fue muy comentado, pero en realidad era una versión ajustada de un modelo 70B.
  • Este material parece tratar solo modelos MoE grandes.
    La mayoría de los usuarios probablemente apunten a modelos pequeños (por ejemplo, 9B),
    y como este modelo usa una arquitectura híbrida Mamba, parece que requerirá consideraciones aparte.