La propuesta es atractiva. Los modelos de código abierto son competitivos. Las GPUs están disponibles. Los servidores de inferencia como vLLM, TGI y SGLang están maduros. ¿Por qué pagar un margen de 5-10x a OpenAI o Anthropic cuando podrías alojar por tu cuenta un modelo equivalente?
La realidad es más compleja. El alojamiento propio resulta ventajoso a determinadas escalas; en otras, el coste operativo supera con creces el ahorro de inferencia. El punto de equilibrio varía según la carga de trabajo, el tamaño del modelo, los requisitos de latencia y la capacidad del equipo.
Este artículo profundiza en los cálculos, las exigencias operativas y los patrones que distinguen a los equipos que deberían alojar sus modelos de aquellos que no. Partimos de que estás evaluando seriamente la opción y necesitas cifras sinceras.
Cuándo tiene sentido el alojamiento propio
Algunas características que favorecen el alojamiento propio:
Escala. Un gran volumen de inferencia. En concreto, un gasto mensual de API superior a €5K-10K suele justificar que se valore el alojamiento propio.
Carga de trabajo predecible. Un uso estable y predecible. El alojamiento propio exige planificar la capacidad; las cargas con picos desperdician recursos por infrautilización o fallan por saturación.
Requisitos de privacidad / cumplimiento normativo. Datos que no se pueden enviar a proveedores en la nube (industrias reguladas, ciertos contratos gubernamentales, datos internos solamente).
Modelos personalizados. Ajustes finos, arquitecturas personalizadas o variantes especializadas que los proveedores gestionados no ofrecen.
Control de latencia. Para algunas aplicaciones, una latencia de primer token inferior a 100ms requiere ejecutar modelos en infraestructura que controlas tú.
Coste por llamada inferior al punto de equilibrio. Los cálculos confirman que el alojamiento propio resulta más barato.
Cuando se cumplen la mayoría de estas condiciones, el alojamiento propio merece una evaluación seria.
Cuándo no tiene sentido el alojamiento propio
El otro lado. Características que favorecen las APIs gestionadas:
Escala baja o variable. Con un gasto en inferencia inferior a €5K/mes, el ahorro no justifica el coste operativo.
Cargas de trabajo con picos. El uso varía 10x entre las horas punta y las tranquilas. El alojamiento propio desperdicia capacidad en los períodos de menor demanda.
Necesidad de capacidades de vanguardia. GPT-5.5, Claude Opus 4.8, las últimas capas de razonamiento — estas están cerradas y solo están disponibles a través de APIs. Si tu carga de trabajo realmente necesita calidad de vanguardia, estás pagando por APIs.
Equipo pequeño. La inferencia con alojamiento propio requiere experiencia operativa. Sin capacidad dedicada, los sistemas fallan.
Iteración rápida. Hay que probar muchos modelos, configuraciones y proveedores. Las APIs lo facilitan; con alojamiento propio, cada cambio exige un despliegue.
Usuarios multirregionales/globales. El alojamiento propio exige operar en cada región. Las APIs gestionadas resuelven esta necesidad.
En estos casos, las APIs gestionadas son la opción correcta aunque su coste sea considerable.
El cálculo de costes (con cuidado)
Hagamos los números reales para un caso representativo. Suposiciones:
- Carga de trabajo: 100 millones de tokens/mes de entrada, 30 millones de tokens/mes de salida.
- Objetivo de calidad: comparable a Claude Sonnet 5 o la actual capa GPT-5.x.
- Modelo de código abierto disponible: Llama 3.3 70B (la calidad es cercana a la cerrada para muchas tareas; tenga en cuenta que no existe un “Llama 4 70B” — Llama 4 se envía como los modelos MoE Scout/Maverick).
Opción A: API a modelo cerrado.
- API cerrada de primer nivel (Claude Sonnet 5, verificado 2026-07-07): $3/M de entrada × 100M = $300. $15/M de salida × 30M = $450. Total: ~$750/mes.
Este nivel de gasto no justifica el alojamiento propio.
Escala la carga de trabajo 10x:
- 1 mil millones de tokens de entrada, 300 millones de tokens de salida.
- API cerrada: $7,500/mes.
En este punto, el alojamiento propio empieza a resultar interesante.
Opción B: API a modelo abierto en proveedor de código abierto gestionado.
- Llama 3.3 70B en Together AI: $0.88/M de entrada y salida (precio de lista, verificado 2026-07-07).
- 1B de entrada × $0.88/M = $880. 300M de salida × $0.88/M = $264. Total: ~$1,144/mes.
Ahorro de ~85% frente a cerrado. Significativo.
Opción C: alojamiento propio en GPUs alquiladas.
- Un modelo cuantizado (INT8/FP8) de 70B cabe en una sola H100 80GB; prevé ~2 H100s para pesos FP16 o para disponer de margen de rendimiento por lotes. El cálculo siguiente presupone 2 para el rendimiento.
- GPUs alquiladas H100: $2-3/hora cada una.
- 2 H100s × $2.50/hora × 730 horas/mes = $3,650/mes solo por cálculo.
- Añade: almacenamiento, red, tiempo operativo.
Para esta carga, un modelo abierto en un proveedor gestionado supera al alojamiento propio en coste bruto. El alojamiento propio solo resulta ventajoso si además necesitas control —por privacidad o un modelo personalizado— o si tu rendimiento es muy superior.
Opción D: alojamiento propio con GPUs propias o reservadas a largo plazo.
- 2 H100s comprados o reservados a largo plazo: $1-2/hora efectivo.
- 2 H100s × $1.50/hora × 730 horas = $2,190/mes.
- Una mayor utilización permite repartir el coste: si estas GPUs atienden varias cargas de trabajo, el coste de cada una disminuye.
Ahora el coste compite con el de los proveedores gestionados de modelos abiertos, pero la carga operativa sigue siendo real.
La idea clave: a esta escala (~1.3B tokens/mes), el ahorro del alojamiento propio frente a proveedores gestionados de modelos abiertos es marginal. Frente a las APIs cerradas es enorme, pero los proveedores gestionados de modelos abiertos ya capturan la mayor parte.
Con una carga 10x mayor (~13B tokens/mes), el alojamiento propio comienza a resultar claramente ventajoso. Con una carga 10x menor, la inferencia gestionada es la respuesta.
El coste operativo
Además del coste bruto de inferencia, hay que contabilizar el coste operativo del alojamiento propio.
Configuración inicial:
- Elegir el servidor de inferencia adecuado (vLLM, TGI, SGLang).
- Configurar para tu modelo y hardware.
- Configurar infraestructura de GPU (nube o propia).
- Red, seguridad, observabilidad.
- Cuantización y optimización.
Lo habitual: 1-4 semanas de ingeniería para el primer despliegue.
Operaciones continuas:
- Monitorización (latencia, rendimiento, errores y utilización de GPU).
- Planificación de capacidad.
- Actualizaciones (nuevas versiones de modelos, actualizaciones del servidor de inferencia, parches de seguridad).
- Respuesta a incidentes (fallas de GPU, errores de OOM, errores de software).
- Escalado (más GPUs a medida que crece la carga).
Lo habitual: 0.25-1 FTE de ingeniería de forma continua, según la escala.
Costes ocultos:
- Volatilidad de precios de GPU.
- Costes de salida de datos de la nube en sistemas híbridos.
- Expertise especializado (CUDA, cuantización, optimización).
- Costes de sustitución y averías del hardware propio.
Con un coste laboral total de €100K-200K por profesional de ingeniería al año, incluso una dedicación parcial es significativa. Un ahorro de €5K/mes en inferencia desaparece ante €15K/mes de coste de ingeniería.
Aquí es donde los equipos subestiman el coste del alojamiento propio. El cálculo aislado de inferencia parece excelente, pero el coste total de propiedad es muy superior.
Los servidores de inferencia
Si eliges el alojamiento propio, estas son las principales opciones:
vLLM. De código abierto. Probablemente sea la opción más popular para servir LLM abiertos. Ofrece PagedAttention, procesamiento continuo por lotes y amplia compatibilidad con modelos. Es la opción por defecto.
TGI (Text Generation Inference). Servidor de Hugging Face maduro, con amplia compatibilidad y buen rendimiento. Últimamente incorpora funcionalidades nuevas con menos rapidez que vLLM.
SGLang. Más nuevo, muy alto rendimiento. Fuerte para generación estructurada. Desarrollo activo.
LMDeploy. De InternLM. Fuerte cuantización, rápido.
llama.cpp / Ollama. Para modelos pequeños y menor rendimiento. Funcionan bien con CPU y son aptos para producción en determinados casos.
Endpoints de inferencia TGI de Hugging Face. Alojamiento dedicado gestionado. Las instancias se pagan por hora y HF se encarga de operarlas. Es un punto intermedio entre el alojamiento propio y un servicio totalmente gestionado.
Modal, RunPod, Replicate. Servicios de funciones para inferencia. Exigen menos compromiso que el alojamiento propio completo, pero cuestan más que hacerlo por cuenta propia.
Para la mayoría de los equipos, vLLM o SGLang son las opciones adecuadas para producción con alojamiento propio. Ambos son maduros, rápidos y están bien documentados.
Elecciones de hardware
La pregunta de GPU:
NVIDIA H100. Tecnología de referencia actual para inferencia. Cuesta ~$2-3/hora de alquiler y ofrece 80GB de VRAM e inferencia rápida. Los modelos de 70B funcionan bien en una H100 con cuantización o en 2x sin ella.
NVIDIA H200. Sucesor de H100, más VRAM (141GB). Para modelos muy grandes.
NVIDIA L40S. Más accesible, ~$1-2/hora. Bueno para modelos de tamaño moderado (hasta ~30B con cuantización).
NVIDIA A100. Generación anterior, aún ampliamente disponible. ~$1-2/hora. Caballo de batalla para muchas implementaciones de producción.
AMD MI300X. Competitivo con H100 para algunas cargas de trabajo. Cada vez más disponible. Algunas inmadurez en software frente al stack de NVIDIA.
Apple M-series. Para modelos muy pequeños (menos de 8B), Mac Studio o Mac Pro con memoria unificada funciona. Caso de uso nicho.
Para la mayoría de los sistemas de producción con alojamiento propio en 2026: H100 o H200 para modelos grandes; L40S o A100 para tamaños moderados.
Proveedores de alquiler: AWS, GCP y Azure (generalistas), además de Lambda Labs, Runpod, Together y Vast.ai (especializados). Los precios varían. Las instancias spot o interrumpibles pueden ahorrar 50-70% si toleras las interrupciones.
Cuantización
La mayoría de las implantaciones de producción con alojamiento propio utilizan modelos cuantizados. Estos son los compromisos:
FP16 (16-bit). Precisión por defecto y calidad completa, con mayor consumo de memoria.
INT8 / FP8 (8-bit). Mitad de memoria, ligera pérdida de calidad. Elección común en producción.
INT4 (4-bit). Cuarto de memoria, pérdida de calidad más notable pero aún útil. Elección agresiva.
AWQ, GPTQ, GGUF. Diferentes formatos de cuantización con diferentes equilibrios.
Para un modelo de 70B:
- FP16: 140GB de VRAM.
- INT8: 70GB de VRAM.
- INT4: 35GB de VRAM.
La H100 tiene 80GB de VRAM. INT8 cabe con holgura; FP16 requiere 2 GPUs.
Impacto de calidad:
- INT8: normalmente <1% de degradación en benchmarks.
- INT4: 1-5% de degradación, varía por tarea.
Prueba en tu carga de trabajo antes de implementar. Algunas tareas (especialmente estructuradas/código) son más sensibles a la cuantización que otras.
Rendimiento y planificación de capacidad
Una pregunta clave de planificación: ¿cuántos tokens/segundo necesitas?
Rendimiento por solicitud individual.
- Modelo de 70B en H100, INT8: ~50-80 tokens/segundo para usuario único.
Rendimiento por lotes.
- Varias solicitudes concurrentes: 1000-3000 tokens/segundo en total (vLLM con un buen procesamiento por lotes).
Consideraciones de latencia.
- Latencia del primer token: 100-500ms típicamente.
- Latencia por token: 10-30ms.
Para la planificación de capacidad:
- Estima el número máximo de pedidos concurrentes.
- Estima la longitud promedio del pedido.
- Calcula el número total de tokens/segundo necesario.
- Añade un 50% de margen.
Un equipo que maneja 1M tokens/hora con 50 usuarios concurrentes pico típicamente necesita 2-4 H100s en buena utilización.
Fiabilidad y alternativa de respaldo
Con alojamiento propio, la fiabilidad es responsabilidad de tu equipo.
Comprobaciones de estado. Monitorización continua y reinicio de instancias que no estén en buen estado.
Degradación controlada. Cuando se sature la capacidad, prioriza respuestas lentas frente a fallos.
Respaldo mediante APIs. Muchos equipos atienden el tráfico principal con alojamiento propio y recurren a APIs gestionadas cuando se sobrecarga. Combina lo mejor de ambos enfoques, aunque añade complejidad.
Hardware de respaldo. Las GPUs fallan. Capacidad de respaldo lista.
Multirregión. Para usuarios globales, replicar. O usar APIs gestionadas para regiones distantes.
Estrategia de actualización. Nuevas versiones de modelos, actualizaciones del servidor. Implementaciones de tipo azul-verde para evitar tiempos de inactividad.
Cada una de estas es trabajo de ingeniería que las APIs gestionadas absorben para ti.
Ejemplo práctico: la decisión de un equipo sobre el alojamiento propio
Un ejemplo real: un equipo de SaaS con funcionalidades de IA y un coste mensual de inferencia de €18,000 en APIs gestionadas.
El cálculo:
- 80% de la inferencia es clasificación y extracción (podría ejecutarse en un modelo de código abierto más pequeño).
- 20% es generación compleja (requiere capacidad cerrada de vanguardia).
Plan:
- Alojar Llama 3.3 70B para el 80% de la carga de trabajo.
- Mantener API de Claude/GPT para el 20%.
- 3 H100s reservados en Lambda Labs: ~€4,500/mes.
- Configuración de ingeniería: 4 semanas, €25K una vez.
- Operaciones continuas: 0.25 FTE de ingeniería, ~€30K/año.
Resultado después de 6 meses:
- El coste de inferencia bajó de €18K/mes a €6K/mes (€4.5K de alojamiento propio + €1.5K de API cerrada para tareas difíciles).
- Ahorro neto frente al sistema anterior: €12K/mes = €144K/año.
- Menor inversión en ingeniería: €25K una vez + €30K/año ≈ €55K en el primer año (€30K/año después).
- Beneficio financiero neto:
€89K en el primer año (€114K/año después).
Complejidades ocultas:
- Una interrupción cuando una implementación tuvo un error de configuración. Degradación parcial de 2 horas.
- Varias semanas de ajustes continuos para alcanzar un rendimiento óptimo.
- La persona responsable del alojamiento propio habría preferido dedicar su tiempo a otras tareas.
Resultado: beneficio financiero positivo, pero una carga operativa mayor de lo previsto. El equipo mantiene el alojamiento propio; si el volumen disminuyera un 50%, volvería a las APIs gestionadas.
Este es el aspecto real de una decisión acertada de alojamiento propio: no hay magia, sino trabajo de ingeniería con un ROI medible.
Un ejemplo trabajado: la decisión de “volver a APIs” de un equipo
Un equipo diferente, punto de partida similar.
Configuración original: Llama 3 70B con alojamiento propio en GPUs alquiladas. Coste de inferencia: €3K/mes de alquiler, más ~€20K/año de ingeniería continua.
El cambio:
- El precio de código abierto en proveedor gestionado se redujo un 50% en 18 meses.
- Su equipo creció pero no contrató capacidad dedicada de MLOps.
- La configuración de alojamiento propio exigía mucho trabajo para mantenerse al día con los modelos nuevos.
La decisión:
- Abandonar el alojamiento propio.
- Migrar a Together AI para hospedaje de modelos abiertos.
- Coste: €2.5K/mes por el alojamiento gestionado del modelo abierto. Ahorro pequeño y menor complejidad.
- Liberar al ingeniero.
Resultado:
- Ahorro financiero modesto.
- Tiempo del ingeniero liberado para trabajo de producto.
- Menos estrés operativo.
Resultado: fue la decisión correcta para ese equipo. El alojamiento propio beneficia a algunos equipos, pero no a todos.
Cuando revisar la decisión
La decisión no es permanente. Revisar periódicamente:
Cambios de volumen. Un aumento considerable hace más atractivo el alojamiento propio; una reducción lo hace menos atractivo.
Cambios en precios. APIs cerradas más baratas o más caras. Proveedores gestionados abiertos más baratos. Hardware más barato.
Mejoras en modelos. Nuevos modelos de código abierto que coinciden con la calidad cerrada. Nuevos modelos cerrados que se alejan.
Capacidad operativa. El equipo creció o disminuyó en capacidad de ML/ops.
Cambios en privacidad/cumplimiento normativo. Requisitos nuevos que obligan a utilizar alojamiento propio.
Una revisión trimestral es razonable: no hace falta evaluar constantemente, pero tampoco tratarlo como una decisión definitiva.
Errores comunes
Patrones que observamos al decidir sobre el alojamiento propio:
Error 1: calcular el coste sin incluir las operaciones. “El alojamiento propio ahorra €10K/mes”, pero se ignoran €15K/mes de ingeniería. El ROI es negativo.
Error 2: adoptar el alojamiento propio demasiado pronto. Se invierte en ingeniería cuando la carga de trabajo todavía es pequeña. Es una optimización prematura.
Error 3: Autohospedación de calidad de vanguardia con modelos abiertos pequeños. “Podemos ahorrar dinero usando un modelo más pequeño” — pero la calidad disminuye, los usuarios se quejan. Caída a APIs.
Error 4: carecer de alternativa de respaldo. La infraestructura propia falla y no existe una degradación controlada, lo que provoca una interrupción que no sufrirían los clientes de API.
Error 5: Subinversión en optimización. Ejecutar un modelo de 70B en una sola GPU a 5 tokens/segundo cuando una configuración adecuada da 50. Perder la mayor parte del valor.
Error 6: ignorar la degradación de calidad. El modelo con alojamiento propio ha quedado rezagado frente al modelo cerrado actual. Los clientes lo perciben, pero el equipo no.
Error 7: no reconsiderar la decisión. Una vez adoptado el alojamiento propio, nunca se reevalúa. La decisión pudo ser correcta hace dos años y equivocada ahora.
Error 8: Spot/preemptible sin manejo suave. Ahorro del 60% en cálculo; interrupciones cada pocas horas cuando las instancias se reclaman.
Lista de verificación para la decisión
Para tomar la decisión deliberadamente:
- El gasto en API es al menos €5-10K/mes?
- La carga de trabajo es estable y predecible?
- El equipo tiene experiencia en MLOps/inferencia o puede contratarla?
- Existe un modelo de código abierto de calidad adecuada?
- Los requisitos de latencia son compatibles con el alojamiento propio?
- Se ha realizado un cálculo detallado del coste, incluidos los costes operativos?
- Existe un plan de respaldo?
- Los requisitos de cumplimiento/privacidad no exigen un camino específico?
- Revisarás trimestralmente?
Si la mayoría de las respuestas son afirmativas, merece la pena evaluar seriamente el alojamiento propio.
Patrones híbridos
No es todo o nada. Muchos equipos ejecutan híbridos:
Alojamiento propio para la mayor parte; APIs para los casos difíciles. Clasificación y generación sencilla con alojamiento propio; razonamiento complejo mediante APIs cerradas.
Alojamiento propio para la base; APIs para los picos. La infraestructura propia atiende la carga base y las APIs absorben los picos.
Alojamiento propio para datos sensibles; APIs para uso general. Los datos sensibles pasan por infraestructura propia y las consultas generales por APIs.
Alojamiento propio para ajustes finos; APIs para modelos base. Los modelos personalizados se ejecutan en infraestructura propia y los estándar mediante APIs.
El híbrido añade complejidad pero a menudo captura lo mejor de ambos. Para equipos a gran escala, el híbrido suele ser la respuesta correcta.
El mensaje clave
La inferencia LLM con alojamiento propio es realmente viable en 2026. Los modelos de código abierto son competitivos, los servidores de inferencia son maduros y el hardware está disponible.
Sin embargo, el coste operativo es real y fácil de subestimar. El punto de equilibrio frente a las APIs gestionadas ronda los €5-10K/mes de gasto en inferencia; por debajo, la inversión en ingeniería no compensa.
Los equipos que operan con éxito un alojamiento propio:
- Han hecho cálculos sinceros que incluyen los costes operativos.
- Tienen o pueden construir capacidad de MLOps.
- Operan a una escala suficiente para justificar la inversión.
- Tienen cargas de trabajo estables.
- No necesitan capacidades exclusivamente de vanguardia.
- Planifican la fiabilidad, la monitorización y las actualizaciones.
Los equipos que deberían permanecer en APIs:
- Escala baja.
- Cargas de trabajo con picos.
- Necesidad de iteración rápida.
- Equipos pequeños sin capacidad operativa.
- Necesidad de capacidades cerradas de vanguardia.
La respuesta correcta depende de tu situación. Calcula las cifras con cuidado, evalúa con honestidad tu capacidad operativa y elige APIs salvo que el alojamiento propio resulte claramente ventajoso.
Cuando el alojamiento propio resulta ventajoso, lo es tanto en términos económicos como arquitectónicos. Cuando no, se convierte en una forma cara de descubrir que las APIs gestionadas siempre fueron la decisión correcta.
