Modelos de pesos abiertos en empresa: un año después

Actualizado: 2026-05-03

Hace poco más de un año, cuando muchos de nosotros empezamos a meter modelos de pesos abiertos en entornos empresariales reales, la conversación era cauta. Teníamos Llama 2 decente, Mistral 7B brillante en su tamaño, y un puñado de alternativas que quedaban lejos en calidad del GPT-4 de entonces. Un año después, la situación ha cambiado lo suficiente para merecer un balance honesto, porque algunas apuestas han salido bien, otras han fracasado, y la decisión de construir sobre pesos abiertos o sobre APIs cerradas se juega ya en otro terreno.

Puntos clave

• La paridad con modelos cerrados es por tareas, no global: clasificación, extracción y resúmenes bien acotados son difíciles de distinguir en ciego; razonamiento complejo y código largo todavía dan ventaja a las APIs cerradas.
• El coste real en producción es el de servir con latencias aceptables bajo concurrencia razonable; los gráficos de entrenamiento son engañosos.
• Los tres patrones que han cuajado: router multi-modelo, RAG con embeddings abiertos, y fine-tuning con LoRA solo para dominios cerrados.
• Los tres fracasos recurrentes: subestimar el coste operativo, siempre ir al modelo más grande, y anclarse a un modelo concreto sin abstracciones.
• Compensan claramente en: volumen alto y sostenido, datos regulados, edge/offline. En el resto, la API sigue siendo la opción racional por coste operativo total.

El salto de calidad fue real, pero desigual

Lo primero que conviene reconocer es que la distancia con los modelos cerrados se ha reducido claramente en casi todas las tareas donde importaba:

• Llama 3 y 3.1 405B: demostraron que un laboratorio abierto puede alcanzar niveles de GPT-4 Turbo en evaluaciones estándar.
• DeepSeek V3 y R1: trajeron rendimiento competitivo a precios de entrenamiento notablemente más bajos; R1 con razonamiento cadena-de-pensamiento explícito.
• Qwen 2.5: la opción más sólida para idiomas asiáticos y la más predecible en tareas de código.
• Mistral Large 2: alternativa europea con licencia comercial flexible.

El matiz importante es que la paridad es por tareas, no global. En redacción larga en inglés, los modelos cerrados siguen un punto por delante en consistencia. En código de proyectos reales con contexto grande, Claude 3.5 Sonnet mantenía una ventaja perceptible a finales de 2024 sobre cualquier pesos abiertos probado. En razonamiento matemático complejo, DeepSeek R1 dio la sorpresa.

Mi lectura es que para la gran parte del trabajo real empresarial (clasificar, extraer, resumir, reformular, traducir, responder sobre documentos) los pesos abiertos son ya suficientes. Para el escalón superior, todavía conviene comparar.

Lo que cuesta servirlos en serio

Aquí es donde el año ha traído más aprendizaje. El coste real en producción es el de servir con latencias aceptables bajo concurrencia razonable.

Un Llama 3.1 70B cuantizado a 4 bits cabe en una GPU H100 de 80 GB y da latencias buenas para un usuario a la vez. Lo difícil es escalarlo a decenas de peticiones concurrentes. Los sistemas que han funcionado son, en orden de preferencia: vLLM y TGI para Nvidia, y SGLang cuando se necesita paralelismo de secuencia agresivo. Para más detalle sobre el serving, ver nuestro análisis de vLLM en 2025.

El coste comparado con API cerrada depende mucho del volumen. Para un equipo que procesa decenas de millones de tokens al mes, alquilar GPU A100 o H100 y servir con vLLM sale a la mitad del coste de OpenAI o Anthropic, con gastos operativos no despreciables. Para volúmenes bajos, la API sigue ganando por simple ausencia de sobrecarga humana.

La GPU de entrada que ha cuajado como equilibrio es la A100 de 40 o 80 GB. Un servidor con dos A100 sirve un 70B cuantizado muy bien para uso interno. Para modelos más pequeños (8-13B) las RTX 4090 o L40S dan mucho por bastante poco dinero.

Dónde están encajando en arquitecturas reales

Los patrones que he visto asentarse son relativamente pocos:

El modelo de «router»: una capa delgada en la aplicación decide qué modelo toca cada petición según criterios objetivos (longitud de entrada, sensibilidad de datos, coste presupuestado, calidad requerida). Ejemplo concreto: peticiones cortas y de bajo riesgo a un Llama 3.1 8B auto-alojado, peticiones complejas a Claude 3.5 Sonnet vía API, peticiones sobre datos regulados a Mistral Large 2 auto-alojado con cumplimiento dentro del perímetro.

RAG con embeddings abiertos: los embeddings también han madurado. Modelos como BGE-M3, jina-embeddings-v3 y los de Nomic dan resultados comparables a los cerrados y se sirven con decenas de MB de RAM. Para muchos casos la pieza cara de un RAG ha dejado de ser el LLM y ha pasado a ser la canalización de indexación. Para el lado GraphRAG de esto, ver GraphRAG de Microsoft en empresa.

Fine-tuning para dominios específicos: un año de experiencia me convence de que el fine-tuning serio solo compensa cuando tienes un dominio cerrado con vocabulario propio y miles de ejemplos curados. En los demás casos, prompt engineering con RAG rinde mejor. El fine-tuning es tentador en reuniones y decepcionante en producción si no hay alguien dedicado a mantener la tubería de entrenamiento. Para el cómo técnico, ver evaluación de RLHF y DPO.

Los fracasos que conviene recordar

Varios equipos arrancaron iniciativas de modelos locales y terminaron volviendo a APIs. Los patrones de fracaso se repiten:

1. Subestimar el coste de operaciones. Un modelo auto-alojado necesita cuidados: monitorización, actualizaciones de software, gestión de GPU, reserva de capacidad, resiliencia frente a fallos de nodo. Los equipos sin experiencia previa en operaciones de GPU se sorprenden.
2. La tentación de ir siempre al modelo más grande. El 405B es impresionante, pero servirlo cuesta más y para la mayoría de casos empresariales no ofrece mejora perceptible frente al 70B bien cuantizado.
3. La rigidez ante la evolución. Los modelos mejoran cada dos o tres meses, y anclarse a uno concreto significa quedarse atrás. Los equipos que han sobrevivido bien han construido abstracciones para cambiar el modelo detrás y lo tratan como un componente intercambiable.

Cuándo compensan

Los pesos abiertos compensan claramente en tres situaciones:

1. Volumen alto y sostenido donde el coste por token domina el coste total.
2. Datos regulados o sensibles donde salir del perímetro es una fricción o un imposible.
3. Edge/offline: aplicaciones móviles privadas, despliegues industriales, escenarios sin conectividad.

En los demás casos (volumen bajo, datos no sensibles, latencia no crítica, equipos sin experiencia operativa en IA), las APIs siguen siendo la elección racional. No por calidad, que ya es equivalente, sino por coste operativo total.

El futuro próximo pasa por modelos más pequeños y especializados. Para equipos que están decidiendo hoy, la inversión en una capa de abstracción y en un conjunto de evaluaciones propio vale más que la decisión concreta de qué modelo usar este trimestre. Los modelos cambian, la ingeniería que los envuelve, no tanto.