El stack vertical de SLM: GPU, entrenamiento y capa de aplicación para una IA de dominio específico en 2026

El 1 de julio de 2026, el consejero delegado de Palantir, Alex Karp, se sentó en el programa Squawk Box de CNBC y dijo algo que todos los compradores de IA empresarial pensaban pero que nadie con altavoz había dicho en voz alta: «Algo ha salido completamente mal en la forma en que se vende la IA». Su diagnóstico fue preciso. Las empresas pagan por tokens que no producen ningún valor operativo. Los pesos de los modelos entrenados con sus datos propios, la auténtica inteligencia competitiva, vuelven a los laboratorios. Y el modelo de precios está diseñado para mantenerte dependiente, no capaz.

La respuesta de Karp es la soberanía: controla tu cómputo, los pesos de tus modelos, tu stack de datos y tu ventaja. No es una postura filosófica. Es una decisión de arquitectura. Y la arquitectura a la que apunta tiene nombre: el stack vertical de SLM.

Este artículo explica cómo es ese stack, cómo construir cada capa y por qué un fundador con un caso de uso concreto puede superar a un modelo frontera de propósito general en su propio problema, por una fracción del coste.

Por qué se está rompiendo el modelo de pago por token

La economía de alquilar inteligencia a un laboratorio de frontera tenía sentido en 2023. Los modelos parecían magia, construir el tuyo propio era prohibitivo y las diferencias en benchmarks entre modelos grandes y pequeños eran enormes. Ninguna de esas tres condiciones se cumple en 2026.

Los modelos de pesos abiertos (Llama 3.2, Phi-4-mini, Gemma 3) son ya 16 veces más baratos por token que las API frontera y a menudo las igualan o las superan en tareas acotadas y bien definidas. La infraestructura de fine-tuning que hace dos años exigía un equipo de ingenieros de ML ahora funciona en una sola A100 en una tarde. Y la comunidad empresarial ha empezado a hacer cuentas. Los hilos de Reddit y los canales de Discord donde los ingenieros de ML hablan con franqueza cuentan la misma historia: para clasificación, extracción, resumen, generación de código dentro de un ámbito definido y salida estructurada (que cubren aproximadamente el 80% de las cargas de trabajo reales de IA empresarial), un modelo de 7B ajustado supera a un modelo de 70B con prompts en precisión, latencia y coste a la vez.

La diferencia de coste no es marginal. Es de un orden de magnitud. Y se acumula a medida que crece el volumen. Una startup que procesa 500,000 llamadas a la API al mes se enfrenta a $10,000–$40,000 en facturas de tokens, o a $300–$600 si autoaloja un SLM ajustado. Esa diferencia paga a dos ingenieros.

¿Qué es en realidad un modelo de lenguaje pequeño?

Los SLM son modelos de lenguaje en el rango de 1 a 15 mil millones de parámetros. Suena a distinción técnica, pero tiene consecuencias prácticas concretas: se ejecutan en una sola GPU (o incluso en CPU en algunas configuraciones), se ajustan en horas en lugar de semanas, caben en entornos de borde y en despliegues en tus propias instalaciones, y producen inferencia en 80–300 ms en lugar de segundos.

Los principales SLM de pesos abiertos en 2026 son:

• Phi-4-mini (3.8B, Microsoft): actualmente el líder en benchmarks de la clase de 3–4B. Funciona con ~3 GB de VRAM, tiene una ventana de contexto de 128K y lidera en MMLU y en razonamiento matemático. Excepcional para tareas de razonamiento estructurado con un tamaño reducido.
• Gemma 3 (2B / 7B, Google): licencia comercial sólida, optimizado para la nube y el borde. Especialmente adecuado para la comprensión de documentos y para seguir instrucciones en conversaciones de varios turnos.
• Llama 3.2 (1B / 3B, Meta): diseñado para desplegarse en el borde, en móviles y dispositivos embebidos. El modelo de 1B funciona en la CPU de un teléfono. Excelente para enrutamiento, clasificación y extracción ligera.
• Mistral 7B / Mixtral 8x7B: fuertes en generación de código y en seguir instrucciones. La arquitectura MoE dispersa de Mixtral le da una potencia muy superior a su número de parámetros activos.

La idea clave es que ninguno de estos modelos superará a GPT-5 en un benchmark general. No se trata de eso. Un modelo de 3.8B ajustado con 50,000 ejemplos de tu tarea concreta superará a GPT-5 en esa tarea, y lo hará con 1/30 del coste y una latencia 10 veces menor.

El stack vertical de tres capas

Construir una capacidad de IA de dominio específico que sea tuya de principio a fin significa tomar decisiones deliberadas en tres capas: cómputo, entrenamiento y aplicación. La mayoría de los fundadores que lo han intentado y han fracasado las trataron por separado. No lo son. Cada capa limita y habilita a las demás.

Capa 1: GPU (cómputo)

La capa de GPU es donde la mayoría de los fundadores o invierten de más o hacen la apuesta de arquitectura equivocada. La buena noticia es que los requisitos de hardware para el trabajo con SLM verticales en 2026 son muy inferiores a los de hace solo 18 meses.

Para hacer fine-tuning de un modelo de 7B con LoRA o QLoRA (el enfoque estándar), necesitas una sola A100 de 80GB o dos A6000. Coste en la nube: $2–$4/hora. Una ejecución completa de fine-tuning con 10,000 ejemplos tarda entre 2 y 6 horas. Total: menos de $25 por ejecución de entrenamiento. No es un gasto de capital: es un coste variable que pagas cuando reentrenas.

Para la inferencia, un modelo de 7B cuantizado (INT4/INT8) atiende entre 100 y 500 peticiones simultáneas en una sola A10G (24GB de VRAM, ~$1.50/hora). A esa escala, autoalojar es casi siempre más barato que las llamadas a la API en un plazo de 30 a 60 días desde el despliegue.

Para requisitos de borde o de instalaciones propias, habituales en sanidad, legal y administración pública, la clase de modelos de 1–3B funciona en tarjetas de consumo NVIDIA RTX 4090 (~$2,000) o en Apple Silicon M3 Ultra. Sin dependencia de la nube, sin salida de datos y sin exposición en materia de cumplimiento.

Guía para elegir el nivel de GPU

• Modelo de 1–3B, borde o instalaciones propias: RTX 4090, Apple M3 Ultra, NVIDIA Jetson
• Modelo de 7B, fine-tuning y servicio en la nube: A10G (inferencia), A100 (entrenamiento)
• Modelo de 13B: 2× A100 o H100 para entrenar; A100 para inferencia cuantizada
• Cargas por lotes / asíncronas: las instancias spot reducen el coste de entrenamiento entre un 60 y un 70%

Capa 2: entrenamiento (pipeline de fine-tuning)

Esta es la capa que aporta el auténtico foso competitivo. El modelo base es público. Cualquiera puede partir de Llama o Phi. Lo que no pueden replicar son tus datos de entrenamiento: los ejemplos de dominio, los casos límite y los formatos de salida que codifican tu conocimiento operativo en los pesos del modelo.

Alex Karp lo planteó en términos tajantes: los laboratorios de frontera están «robando los pesos y la ventaja» de las empresas que usan sus API, porque cada consulta y cada señal de corrección que aportas al usar una API en la nube contribuye, directa o indirectamente, a mejorar su modelo. Cuando el pipeline de fine-tuning es tuyo, esa señal sigue siendo tuya.

El flujo estándar de fine-tuning:

1. Selecciona un conjunto de datos específico de la tarea. Necesitas entre 1,000 y 50,000 pares instrucción–respuesta de alta calidad para la tarea concreta. La calidad gana a la cantidad. 2,000 ejemplos etiquetados por expertos superan de forma constante a 50,000 ruidosos. Empieza por tus resultados existentes (documentos, decisiones y datos estructurados del pasado) y usa un modelo frontera para generar datos de entrenamiento sintéticos con poco coste; después, valida una muestra a mano.
2. Aplica fine-tuning con LoRA / QLoRA. La adaptación de bajo rango (Low-Rank Adaptation) congela la mayoría de los pesos del modelo base y entrena solo un pequeño conjunto de matrices adaptadoras, normalmente entre el 0.1 y el 1% del total de parámetros. Así es como ajustas un modelo de 7B en una sola GPU sin quedarte sin memoria. Herramientas: la biblioteca PEFT de Hugging Face, Unsloth (entre 2 y 5 veces más rápido) y Axolotl para pipelines complejos.
3. Evalúa con rigor antes de lanzar. Construye un conjunto de evaluación reservado de 200–500 ejemplos con etiquetas de referencia. Mide la precisión en la tarea, la tasa de alucinaciones y el cumplimiento del formato. Un modelo con un 95% de precisión en tu conjunto de evaluación que falla en casos límite en producción es peor que un modelo del 90% con modos de fallo conocidos.
4. Establece una cadencia de reentrenamiento. El valor del modelo se multiplica cuando lo reentrenas con salidas y correcciones de producción. Un ciclo de reentrenamiento mensual o trimestral, alimentado con datos de uso real, crea un foso que se ensancha con el tiempo. Este es el núcleo de la ventaja vertical: cada ciclo hace que tu modelo sea mejor en tu tarea concreta mientras las API genéricas siguen siendo genéricas.

Capa 3: capa de aplicación

La capa de aplicación es donde tu modelo se conecta con los flujos de trabajo reales, y donde vive la mayoría de las decisiones de producto. Acertar en esta capa es lo que separa una demo que funciona de un sistema de producción en el que confían los usuarios.

Como tu SLM es acotado por diseño, la capa de aplicación tiene que gestionar el alcance con claridad. Un SLM de documentación clínica no debería intentar responder preguntas médicas generales. Un extractor de contratos no debería intentar dar asesoramiento jurídico. La capa de aplicación impone ese límite mediante la estructura del prompt, la validación de la salida y la lógica de enrutamiento.

• Infraestructura de servicio: vLLM y Ollama son los dos servidores de inferencia de código abierto dominantes en 2026. vLLM gestiona un servicio multiinquilino de alto rendimiento con PagedAttention. Ollama es más sencillo de operar y excelente para uso de un solo inquilino o de desarrolladores. Ambos admiten modelos cuantizados y API compatibles con OpenAI, así que el código existente que llama a OpenAI puede redirigirse a tu SLM autoalojado cambiando una sola línea con la URL.
• Imposición de salida estructurada: en tareas de dominio casi siempre quieres JSON o una salida estructurada. Usa decodificación restringida por gramática (Outlines, Guidance o la salida estructurada integrada de vLLM) para garantizar que el modelo devuelva una salida válida y conforme al esquema. Esto elimina la fuente más común de fallos aguas abajo.
• Aumento con recuperación: un stack de SLM + RAG suele ser más potente que un modelo grande por sí solo. El SLM se encarga del razonamiento y la generación; la capa de recuperación lo ancla en documentos actuales y propios. Esto es especialmente eficaz en contextos legales, financieros y sanitarios, donde la actualidad y la fidelidad a los documentos importan más que un conocimiento amplio del mundo.
• Capa de enrutamiento: en producción, la arquitectura más inteligente enruta las peticiones con criterio. Las tareas sencillas y de alto volumen van al SLM. Las complejas, ambiguas o poco frecuentes escalan a un modelo frontera a través de una API. Un clasificador de 1B puede tomar esta decisión de enrutamiento en menos de 10 ms. El resultado: entre el 70 y el 80% de las peticiones las atiende tu SLM barato y rápido, y el 20–30% restante se escala. Tu coste medio por consulta baja entre un 85 y un 90% mientras la calidad se mantiene alta.

Casos de uso verticales en los que este stack gana con claridad

El enfoque de SLM vertical no es mejor en todos los casos que un modelo frontera. Es muchísimo mejor para una clase concreta de problema: tareas de alto volumen, bien definidas y ricas en datos, en un dominio con conocimiento propio.

La soberanía de la IA no es ideología: es arquitectura

El manifiesto de nueve puntos sobre soberanía de la IA que publicó Palantir el día antes de la entrevista de Karp en CNBC se lee como una provocación. En realidad es un documento de arquitectura. Su argumento central es práctico: el «tokenmaxxing», el modelo de negocio que cobra por token por una inteligencia general, incentiva lo que no debe. Incentiva los scripts desechables frente a los sistemas robustos, la dependencia frente a la capacidad y el volumen de consumo frente a la calidad del resultado.

La alianza entre Palantir y Nvidia anunciada esa misma semana es la expresión comercial de esta tesis: un «sistema operativo de IA soberano» que da a las instituciones el control de su cómputo, sus modelos y su stack de datos como un producto integrado. Tanto si se lo compras a Palantir como si lo construyes tú, la dirección es la misma: sé dueño del stack.

Para los fundadores, la implicación es directa. Si la capacidad de IA de tu producto es una llamada a una API externa, no tienes foso. Cualquier competidor puede hacer la misma llamada. Si tu capacidad es un modelo ajustado, entrenado con datos propios y ejecutándose en una infraestructura que controlas, eso es un activo competitivo real, que se multiplica con cada ciclo de reentrenamiento y que es más difícil de replicar cuanto más tiempo lo mantienes en marcha.

Cuándo el stack vertical es la opción equivocada

El stack vertical de SLM no siempre es lo correcto. Exige una inversión inicial en curación de datos, infraestructura de entrenamiento y disciplina operativa que no todos los equipos están en condiciones de hacer. Tres situaciones en las que deberías quedarte con la API:

• Todavía estás buscando el encaje producto-mercado. Si la definición de tu tarea cambia de una semana a otra, el fine-tuning es esfuerzo desperdiciado. Construye con una API hasta que la tarea sea estable y se entienda bien. Después, construye el SLM.
• Todavía no tienes suficientes datos etiquetados. Hacer fine-tuning con menos de 500 ejemplos suele producir modelos inestables. Si no puedes reunir o generar más de 1,000 ejemplos de alta calidad, usa prompts few-shot con un modelo frontera e invierte en paralelo en recoger datos.
• Tu tarea requiere de verdad un conocimiento amplio del mundo. La síntesis de investigación, el trabajo creativo abierto y las tareas que exigen integrar un contexto variado del mundo real siguen favoreciendo a los grandes modelos frontera. El enfoque de SLM destaca en profundidad, no en amplitud.

Por dónde empezar

El punto de entrada práctico para la mayoría de los fundadores es un fine-tuning piloto en una sola tarea de alto volumen, una que puedas medir con precisión y que tenga criterios de éxito claros. Elige una tarea por la que ahora pagues entre $3,000 y $10,000 al mes en costes de API. Haz las cuentas con un SLM de 7B ajustado. Lo normal es que el caso de negocio resulte evidente desde el primer cálculo.

Las tres preguntas para saber si estás listo para un SLM vertical

• 1. ¿Tienes una única tarea bien definida que se ejecuta con alto volumen (más de 10,000 consultas al mes)?
• 2. ¿Tienes, o puedes generar, más de 2,000 ejemplos etiquetados de esa tarea?
• 3. ¿La soberanía de los datos, la latencia o el coste importan lo suficiente como para justificar entre 2 y 4 semanas de ingeniería?

Si has respondido que sí a las tres, estás listo para construir la primera capa de tu stack vertical. El resto se deriva de ahí.

La idea central de Karp, que algo ha salido completamente mal en la forma en que se vende la IA, es menos una crítica a OpenAI y Anthropic que la observación de un mercado en un punto de inflexión. La infraestructura para construir en vertical ya es accesible. Los modelos de pesos abiertos son lo bastante buenos. La economía es convincente. Lo único que falta es decidir construir algo que sea tuyo en lugar de alquilar algo de lo que dependes.

Related Posts

Por qué la IA es difícil: los problemas reales con los que chocan los fundadores cuando la demo ya funciona1 de julio de 2026

Claude Code en el desarrollo: la herramienta de programación con IA más potente de 202624 de junio de 2026

El comando /loop de Claude Code: cómo usarlo para flujos de programación más inteligentes en 20263 de julio de 2026