Ajuste fino de un modelo de 235B en cuatro GPUs: lecciones de un despliegue fallido
Vertexcover ajustó finamente Qwen3-235B en cuatro H100, logrando mayor precisión a menor costo, pero abandonó el proyecto debido a la complejidad de la inferencia y las rápidas mejoras del código abierto.
Traducido automáticamente del original en inglés.
Los ingenieros de Vertexcover lograron ajustar con éxito el modelo Qwen3 de 235 mil millones de parámetros en una sola máquina con cuatro GPUs H100, obteniendo ganancias significativas en precisión frente a los modelos de API de pago. A pesar del éxito técnico y la reducción del costo por token, el equipo decidió no implementar la solución después de que nuevos modelos de código abierto hicieran innecesaria la infraestructura compleja.
Qué sucedió
El equipo buscaba reemplazar los costosos modelos ajustados de OpenAI y Gemini utilizados para la clasificación de entidades en documentos de clientes. Seleccionaron Qwen3-235B-A22B-Thinking, un modelo Mixture of Experts (MoE), porque superó a otros modelos abiertos en las pruebas iniciales. El objetivo era mantener o mejorar la precisión mientras se controlaban los costos mediante hardware autoalojado.
Tras una época de entrenamiento con aproximadamente 3.600 ejemplos, el modelo ajustado mejoró la puntuación F1 promedio en 7,6 puntos entre todos los inquilinos. También redujo el costo por token a aproximadamente un tercio de las soluciones anteriores basadas en API. El proceso de entrenamiento tardó 26 horas en cuatro GPUs NVIDIA H100, cada una con 80 GB de memoria.
A pesar de estas métricas positivas, el proyecto fue archivado. El equipo descubrió que servir al modelo de pensamiento de 235B con baja latencia y costos operativos razonables representaba un desafío de ingeniería mayor que el propio ajuste fino. Simultáneamente, surgieron nuevos modelos de código abierto que manejaban muchas tareas de clasificación sin ningún ajuste fino, eliminando la necesidad de su infraestructura personalizada.
Cómo funciona
Qwen3-235B es un modelo MoE donde solo unos 22 mil millones de sus 235 mil millones de parámetros están activos para cualquier token dado. Cada capa contiene 128 pequeñas redes expertas, y un router dirige los tokens a los expertos más relevantes. Esta arquitectura mantiene la inferencia computacionalmente más barata que los modelos densos de tamaño similar, pero complica la gestión de memoria durante la carga y el entrenamiento.
El equipo utilizó QLoRA (Quantized Low-Rank Adaptation) para ajustar el modelo. Este método comprime el modelo base a una precisión de 4 bits, reduciendo su huella de memoria de 470 GB a aproximadamente 120 GB. Luego se entrenan pequeñas capas adaptadoras sobre los pesos base congelados. El desafío radica en coordinar las bibliotecas de compresión y fragmentación, que tienen requisitos contradictorios sobre cómo se almacenan y acceden los pesos del modelo en la memoria.
El entrenamiento exitoso requirió DeepSpeed ZeRO-3 con descarga a CPU. Esta configuración mantuvo copias completas del modelo comprimido de 120 GB en la RAM del sistema en lugar de la memoria GPU. Durante el entrenamiento, las capas se movían de la RAM a las GPUs según fuera necesario, permitiendo que las cuatro H100 manejaran la carga de trabajo a pesar de los límites individuales de memoria. Este enfoque intercambiaba velocidad por viabilidad, resultando en el tiempo de entrenamiento de 26 horas.
Detalles clave
- El modelo mejoró las puntuaciones F1 para cada inquilino, con ganancias que oscilaron entre +4,81 y +11,96 puntos.
- El entrenamiento utilizó 3.600 ejemplos incluyendo trazas de razonamiento, ya que Qwen3 es un modelo de "pensamiento".
- Se requerían cuatro GPUs H100 con 80 GB de memoria cada una y 960 GB de RAM del sistema.
- Las implementaciones de Axolotl, Unsloth y FSDP+QLoRA de Answer.AI fallaron debido a problemas de memoria o compatibilidad.
- LlamaFactory con FSDP estándar falló porque Transformers deshabilitó silenciosamente la configuración de ahorro de memoria durante la cuantización.
- La configuración final funcional utilizó LlamaFactory con DeepSpeed ZeRO-3 y descarga a CPU para gestionar la memoria.
Por qué importa
Este caso destaca la complejidad oculta del ajuste fino de modelos MoE masivos en hardware limitado. Los ingenieros a menudo asumen que la cuantización y la fragmentación encajarán perfectamente los modelos grandes en la memoria GPU disponible, pero las incompatibilidades de bibliotecas y los problemas de orden de memoria pueden impedir que comience el entrenamiento. Comprender estas restricciones de bajo nivel es crítico para planificar la infraestructura para modelos que superan los 100 mil millones de parámetros.
También sirve como recordatorio de que la capacidad técnica no siempre justifica el despliegue. El esfuerzo para optimizar la inferencia de un modelo de 235B puede superar los beneficios del ajuste fino, especialmente cuando el modelo base ya es fuerte. Los equipos deben evaluar el costo total de propiedad, incluyendo la latencia de servicio y los requisitos de hardware, no solo la precisión y el costo de entrenamiento.
Finalmente, el rápido ritmo del desarrollo de código abierto significa que el difícil problema de ingeniería de hoy podría resolverse con el lanzamiento de un modelo mañana. Invertir semanas en pipelines personalizados de ajuste fino conlleva el riesgo de costos hundidos si un modelo de propósito general mejora lo suficiente para manejar la tarea directamente. La paciencia estratégica a veces puede producir mejores resultados que la personalización inmediata.
Qué puedes hacer
- Realiza pruebas comparativas de múltiples modelos abiertos antes de comprometerte con el ajuste fino, ya que el rendimiento base varía significativamente.
- Verifica la compatibilidad de las bibliotecas para modelos MoE, especialmente en lo que respecta al orden de cuantización y fragmentación.
- Asegúrate de tener suficiente RAM del sistema para la descarga a CPU cuando la memoria GPU sea insuficiente para el modelo comprimido completo.
- Monitorea la configuración de Transformers para cambios silenciosos en la gestión de memoria durante los procesos de cuantización.
- Evalúa los costos de inferencia y los requisitos de latencia desde el principio, no solo la precisión y el costo de entrenamiento.
- Reevalúa periódicamente la necesidad de ajuste fino, ya que los nuevos modelos base pueden cerrar brechas de rendimiento sin personalización.



