El problema con la narrativa “open-source vs. propietario”
Durante 2023 y 2024, la conversación sobre modelos open-source se redujo a dos posiciones: los que decían que nunca estarían listos para producción y los que prometían que reemplazarían a OpenAI en seis meses. Ninguna resultó útil.
En 2026, la pregunta ya no es si los modelos open-source funcionan. Es cuáles funcionan para qué tarea, con qué infraestructura y a qué costo total. Eso es lo que cubre este artículo.
Qué significa “listo para producción” en un contexto B2B real
“Producción” no es un benchmark de Hugging Face. Es un sistema que procesa documentos de clientes reales, responde en menos de 3 segundos, no alucina datos críticos y puede mantenerse sin que un ingeniero senior lo revise cada semana.
Con ese criterio, estos son los cuatro ejes que importan:
- Calidad de salida para la tarea específica (no el ranking general)
- Latencia en el percentil 95, no el promedio
- Costo total de operación (infraestructura + tiempo de ingeniería)
- Soporte de español si el sistema interactúa con usuarios en LatAm
Un modelo que saca 85 en MMLU pero alucina números en facturas no está listo para un flujo de cuentas por pagar. Un modelo que responde en 800ms promedio pero tiene picos de 8 segundos no sirve para un chat de atención al cliente.
Los modelos que sí cumplen ese estándar hoy
Llama 3.3 70B
El más versátil del grupo. Meta lanzó la versión 3.3 con mejoras sustanciales en seguimiento de instrucciones y soporte multilingüe. En pruebas de extracción estructurada de documentos en español, rinde comparable a GPT-3.5-turbo en precisión y lo supera en costo.
Mejor para: extracción de datos de PDFs, clasificación de tickets, respuesta a preguntas sobre documentos internos.
Infraestructura mínima: una A100 80GB o equivalente. En Groq o Together AI, el costo ronda $0.59–$0.90 por millón de tokens de salida.
Mistral Small 3.1 (22B)
El modelo más eficiente por parámetro del mercado open-source actualmente. Corre en hardware más accesible y tiene latencias bajas incluso sin aceleración especializada. Su soporte de español es aceptable para tareas estructuradas.
Mejor para: agentes con muchas llamadas al modelo por sesión, clasificación en tiempo real, sistemas con restricciones de costo estrictas.
Limitación real: en razonamiento complejo o cadenas largas de pensamiento, se queda corto frente a Llama 3.3 70B.
Qwen 2.5 72B
El mejor soporte de español e idiomas no ingleses del grupo. Alibaba entrenó este modelo con un corpus multilingüe significativamente más amplio que la mayoría. Para empresas en México, Colombia o Argentina que procesan texto en español con jerga local, Qwen 2.5 tiene una ventaja medible.
Mejor para: clasificación de reseñas, análisis de contratos en español, chatbots de atención con vocabulario regional.
Gemma 3 27B
El modelo de Google DeepMind. Más pequeño que los anteriores, pero con una arquitectura optimizada para inferencia rápida. Útil cuando la latencia es más crítica que la capacidad máxima del modelo.
Mejor para: aplicaciones donde el tiempo de respuesta domina el diseño del sistema y la tarea no requiere razonamiento complejo.
Cuándo open-source no es la respuesta correcta
Este es el punto donde muchas evaluaciones técnicas fallan: asumen que open-source siempre gana si la calidad es “suficientemente buena”. No es así.
Open-source pierde en TCO cuando:
- El volumen de llamadas es bajo (menos de 500K tokens/día). A ese volumen, pagar por API de OpenAI o Anthropic es más barato que mantener infraestructura GPU.
- El equipo no tiene experiencia en MLOps. La diferencia entre “modelo corriendo en un notebook” y “modelo en producción con monitoreo, fallback y actualizaciones” es semanas de trabajo de ingeniería.
- La tarea requiere razonamiento multi-paso complejo. Para análisis legal profundo, planificación estratégica o código complejo, los modelos frontier siguen teniendo una brecha real.
Lo que estamos viendo en Eurema con clientes de manufactura y servicios profesionales es que el caso de uso determina el modelo, no al revés. Un sistema de clasificación de órdenes de compra puede correr perfectamente en Mistral Small. Un agente que negocia condiciones contractuales necesita algo más potente.
Infraestructura: las tres rutas reales
Ruta 1: Proveedor de inferencia administrada
Groq, Together AI, Fireworks AI y AWS Bedrock ofrecen acceso a modelos open-source sin gestionar GPUs. Es la opción más rápida para empezar y tiene costos predecibles.
Ventaja: sin overhead de infraestructura.
Desventaja: los datos salen de tu servidor. Para industrias con restricciones de privacidad (salud, finanzas), esto puede ser un bloqueador.
Ruta 2: GPU en nube con despliegue propio
Una instancia A100 en AWS, GCP o Azure con vLLM o TGI como servidor de inferencia. Da control total sobre los datos y permite optimizaciones (quantización, batching) que reducen costos adicionales.
Ventaja: privacidad de datos, personalización.
Desventaja: requiere ingeniería para mantener el sistema.
Ruta 3: Hardware on-premise
Para empresas con volúmenes muy altos o restricciones regulatorias estrictas. El criterio que usamos en Eurema para recomendar esta ruta es simple: si el costo mensual de nube supera el costo de amortización del hardware en 18 meses, vale la pena evaluar on-premise.
Cómo evaluar antes de comprometerte
Antes de elegir un modelo para producción, corre esta secuencia:
- Define la tarea exacta con 50–100 ejemplos reales de tu operación (no genéricos).
- Evalúa con métricas de negocio, no de benchmark: ¿cuántos errores son aceptables por hora? ¿cuál es el costo de un error?
- Mide latencia en el percentil 95, no el promedio. Los picos rompen la experiencia.
- Calcula el TCO a 12 meses: infraestructura + tiempo de ingeniería + costo de errores.
- Compara contra la alternativa propietaria con los mismos datos.
Si después de ese proceso el modelo open-source gana, tienes una decisión respaldada. Si pierde, también sabes por qué.
Para empresas que están evaluando esto por primera vez, el servicio de Agentes personalizados de Eurema incluye esta evaluación antes de comprometerse con una arquitectura específica.
El siguiente paso concreto
Si estás considerando migrar un flujo de trabajo a un modelo open-source, empieza con la tarea más acotada y de menor riesgo que tengas: clasificación de correos, extracción de campos de facturas, categorización de tickets. Eso te da datos reales sobre calidad y latencia antes de comprometer infraestructura.
Si necesitas ayuda estructurando esa evaluación, en Eurema trabajamos con el stack completo —desde la selección del modelo hasta el monitoreo en producción— para empresas B2B en México y LatAm. Puedes ver más en nuestra página de Análisis de datos o escribirnos directamente.