La propuesta es convincente: alquila o compra aceleradores, sirve un modelo de pesos abiertos y reemplaza una factura variable de API. Pero los modelos no son automáticamente equivalentes, las GPU no se mantienen completamente utilizadas y la pila de servicio se convierte en tu responsabilidad de seguridad y fiabilidad.
Este artículo es una guía para modelar costes, no una prueba comparativa (benchmark). Revisa la documentación actual de vLLM, las guías de seguridad de vLLM, la documentación de SGLang y la documentación de Hugging Face TGI antes de seleccionar un servidor. Realiza pruebas comparativas (benchmarks) de las versiones compatibles en el hardware objetivo.
La realidad es más compleja. El autoalojamiento resulta rentable a determinadas escalas. En otras, el coste operativo supera con creces el ahorro en 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 condiciones operativas y los patrones que distinguen a los equipos que deberían autoalojar de los que no. Partimos de que estás evaluando seriamente esta opción y necesitas cifras concretas.
Cuándo tiene sentido el autoalojamiento
Algunas características que favorecen el autoalojamiento:
Escala y utilización. Una demanda sostenida y predecible puede amortizar la capacidad reservada. Utiliza la distribución de carga horaria medida; el gasto mensual en API por sí solo no es una prueba del punto de equilibrio.
Carga de trabajo predecible. Uso constante y predecible. El autoalojamiento requiere planificación de capacidad; las cargas con picos desperdician capacidad (subutilización) o fallan (sobresaturación).
Requisitos de privacidad / cumplimiento. Datos que no se pueden enviar a proveedores en la nube (industrias reguladas, ciertos contratos gubernamentales, datos solo internos).
Modelos personalizados. Ajustes finos (fine-tunes), arquitecturas personalizadas o variantes especializadas que los proveedores gestionados no ofrecen.
Control de latencia. Alojar más cerca de los usuarios y controlar el agrupamiento por lotes puede ayudar a la latencia, pero la red, la cola, el tamaño del modelo, la longitud del prompt y la carga siguen dominando. Realiza una prueba comparativa (benchmark) del percentil objetivo.
Coste por llamada por debajo del punto de equilibrio. Cuando los cálculos demuestran que el autoalojamiento resulta realmente más rentable.
Cuando se cumple la mayoría de estos criterios, conviene evaluar seriamente el autoalojamiento.
Cuándo no tiene sentido el autoalojamiento
El otro lado. Características que favorecen a las APIs gestionadas:
Escala baja o variable. La capacidad inactiva y la provisión para picos pueden eliminar los ahorros aparentes en el precio por token. La inferencia gestionada puede ajustarse mejor, pero calcula ambos modelos de costes.
Cargas de trabajo con picos. Grandes diferencias entre períodos pico y tranquilos pueden dejar la capacidad reservada inactiva o requerir una provisión costosa para picos.
Necesitas capacidades de modelo cerrado. Algunos modelos actuales, modalidades, sistemas de seguridad o herramientas alojadas están disponibles solo a través del servicio de un proveedor. Si la evaluación de una carga de trabajo requiere uno de ellos, incluye la ruta del proveedor y sus restricciones contractuales en lugar de sustituirlo por un modelo abierto no evaluado.
Equipo pequeño. La inferencia autoalojada requiere experiencia operativa. Sin capacidad dedicada, las cosas fallan.
Iteración rápida. Probar muchos modelos, configuraciones y proveedores distintos. Las APIs facilitan esto; el autoalojamiento convierte cada cambio en un despliegue.
Usuarios multi-región / globales. El autoalojamiento puede requerir capacidad regional, enrutamiento, transferencia de datos y recuperación. Las APIs gestionadas pueden reducir parte de la propiedad de infraestructura, pero la disponibilidad por región, la residencia, la conmutación por error (failover) y la latencia de red siguen requiriendo verificación.
Para estos casos, las APIs gestionadas pueden seguir siendo la opción de menor riesgo o menor responsabilidad incluso cuando su coste directo de uso es mayor.
El cálculo de costes, con cautela
Construye tres escenarios actuales con calidad equivalente: una API de modelo cerrado, un servicio gestionado con un modelo abierto y una opción autoalojada. No compares los modelos hasta que superen la misma evaluación de tareas.
Para cada escenario, calcula:
monthly total = metered inference or dedicated capacity + storage + network + observability + support + security/compliance + engineering + expected incident loss
Para las APIs con medición por uso, la inferencia proviene de la entrada sin caché facturada, las escrituras/lecturas de caché, tokens de salida/razonamiento, herramientas, lotes y reintentos. Para el autoalojamiento o capacidad dedicada gestionada, el grupo de costes del acelerador debe incluir capacidad utilizada, inactiva, de margen (headroom), de lanzamiento gradual (rollout) y de fallo/alternativa; no añadas un segundo cargo «de inferencia» a menos que el contrato tenga un contador separado y mutuamente excluyente. Utiliza las solicitudes por hora de acelerador medidas en pruebas comparativas (benchmarks) con la latencia y disponibilidad requeridas para asignar ese coste de capacidad a unidades de carga de trabajo, no al rendimiento máximo del proveedor.
Ejecuta un análisis de sensibilidad sobre el volumen, la relación pico-promedio, la calidad del modelo, el precio del acelerador, la utilización, el tiempo del personal y el coste de migración. El punto de equilibrio es donde los costes netos equivalentes en calidad se cruzan bajo un rango plausible de supuestos.
El coste operativo
Más allá del coste directo de la inferencia, ten en cuenta el coste operativo del autoalojamiento.
Configuración inicial:
- Elegir el servidor de inferencia adecuado (vLLM, TGI, SGLang).
- Configurar para tu modelo y hardware.
- Establecer infraestructura GPU (en la nube o propia).
- Red, seguridad y observabilidad.
- Cuantización y optimización.
Estima la entrega inicial a partir de un desglose acotado del trabajo, el plazo de entrega del hardware/proveedor, la revisión de seguridad, la matriz de benchmarks, el diseño de disponibilidad y el rendimiento observado del equipo. Este artículo no afirma un rango transferible de semanas de ingeniería.
Operaciones continuas:
- Monitorización (latencia, throughput, errores, utilización de GPU).
- Planificación de capacidad.
- Actualizaciones (nuevas versiones de modelos, actualizaciones del servidor de inferencia, parches de seguridad).
- Respuesta a incidentes (fallos de GPU, caídas por falta de memoria (OOM), errores de software).
- Escalado (más GPUs a medida que crece la carga).
Registra la propiedad real en plataforma, ML, seguridad y guardia activa. Un supuesto de fracción de FTE no es portable entre organizaciones.
Costes ocultos:
- Volatilidad del precio de las GPU.
- Costes de salida de datos (egress) de la nube si el despliegue es híbrido.
- Especialización requerida (CUDA, cuantización, optimización).
- Costes de sustitución/fallo del hardware propio.
Utiliza los costes laborales totales (con todos los cargos incluidos) y el coste de oportunidad de tu organización. Los ahorros en precio por token no son ahorros netos hasta que se incluye la propiedad operativa.
Los servidores de inferencia
Si vas a autoalojar el modelo, estas son las principales opciones:
vLLM. Un motor de servicio de código abierto con agrupamiento continuo (continuous batching) y un amplio soporte de modelos dependiente de la versión. Trata sus guías de seguridad como lectura obligatoria.
TGI (Text Generation Inference). El proyecto de servicio de Hugging Face. Verifica el estado actual del mantenimiento y el soporte de modelos en lugar de confiar en la instantánea que ofrece este artículo.
SGLang. Una pila de servicio y programación bajo desarrollo activo. Realiza pruebas comparativas (benchmarks) de los modelos requeridos, la ruta de salida estructurada y las herramientas operativas.
LMDeploy. Otro candidato con soporte dependiente de versión para modelos, cuantización y hardware; pruébalo bajo las mismas pruebas de aceptación.
llama.cpp / Ollama. Candidatos para cargas de trabajo locales y para algunas cargas de servidor. El hardware compatible, la concurrencia, el límite de seguridad, los controles operativos y la adecuación a producción deben probarse; ninguno de estos nombres garantiza un menor throughput o preparación para producción.
Endpoints dedicados gestionados. Hugging Face y otros proveedores ofrecen productos de endpoints gestionados cuyos motores, facturación, aislamiento y división operativa cambian con el tiempo. Verifica el servicio actual en lugar de asumir que ejecuta TGI o utiliza un modelo de facturación único.
Plataformas GPU o de inferencia gestionadas. Estas pueden reducir parte del trabajo de capacidad y servicio mientras retienen dependencias de integración, seguridad, evaluación y proveedor. Compara las cotizaciones actuales y responsabilidades; no asumas una relación fija de precios con la operación propia.
Preselecciona solo proyectos que admitan el modelo exacto, el acelerador, la cuantización, el contrato de API y los controles de seguridad. Una prueba de carga reproducible decide entre ellos.
Elecciones de hardware
La pregunta sobre las GPU:
Las generaciones de aceleradores, capacidades de memoria y precios de alquiler cambian rápidamente. Obtén cotizaciones actuales para la región requerida y el plazo de compromiso.
Compara capacidad de memoria y ancho de banda, formatos numéricos compatibles, interconexión, compatibilidad de software, cuota, disponibilidad regional, comportamiento ante fallos y precio. La capacidad spot o interrumpible (preemptible) solo entra en el modelo con gestión de interrupciones y una ruta de recuperación medida.
Cuantización
La cuantización es una opción de capacidad/rendimiento. Sus compensaciones dependen del modelo, formato, kernel, hardware y tarea:
Precisión de referencia clase FP16/BF16. A menudo se utiliza como línea base comparativa para modelos y hardware compatibles; no es automáticamente el formato original o «de máxima calidad» del modelo.
INT8 / FP8 (8-bit). Puede reducir la memoria de pesos o mejorar las rutas de ejecución compatibles; los efectos en calidad y velocidad varían.
INT4 (4-bit). Puede reducir aún más la memoria de pesos; mide la calidad y el rendimiento del kernel para el artefacto exacto.
AWQ, GPTQ, GGUF. Diferentes formatos de cuantización con diferentes compensaciones.
La aritmética basada solo en el número de parámetros proporciona únicamente una cota inferior; la memoria en tiempo de ejecución también incluye la caché KV, las activaciones, los espacios de trabajo, la fragmentación y las réplicas. Utiliza el perfilador del motor de servicio y una prueba de carga. Evalúa la calidad de la salida en la tarea de producción, no solo en una prueba comparativa general.
Throughput y planificación de capacidad
Una pregunta clave de planificación: ¿cuántos tokens/segundo necesitas?
Mide el tiempo hasta el primer token, la latencia entre tokens, la latencia de extremo a extremo, el throughput, el tiempo de cola, la tasa de errores y el margen de memoria para distintas longitudes de prompt/salida y niveles de concurrencia.
Para la planificación de capacidad:
- Estima las solicitudes concurrentes pico.
- Estima la longitud promedio de solicitud.
- Calcula los tokens/segundo totales necesarios.
- Añade margen derivado de requisitos de ráfaga, fallo y lanzamiento gradual (rollout).
Fiabilidad y alternativas
El autoalojamiento significa que la fiabilidad es responsabilidad tuya.
Comprobaciones de salud. Monitorización continuo del estado. Reinicia las instancias en mal estado.
Comportamiento ante sobrecarga. Utiliza colas acotadas, control de admisión, contrapresión (backpressure) y una política probada de degradación o rechazo. Permitir que las solicitudes esperen indefinidamente puede empeorar la sobrecarga e incumplir los objetivos de latencia.
Alternativa (fallback) hacia las APIs. Una alternativa gestionada puede absorber algunos fallos o picos, pero solo si la calidad del modelo, la política de datos, contratos, límites de tasa (rate limits), estado y comportamiento de conmutación por error son compatibles y están probados. Añade complejidad y puede fallar concurrentemente.
Capacidad ante fallos. Dimensiona la capacidad adicional o una ruta alternativa a partir del objetivo de disponibilidad y de los modos de fallo probados; cada acelerador puede fallar, pero el hardware inactivo dedicado no es el único diseño.
Multi-región. Para usuarios globales, replica. O utiliza APIs gestionadas para regiones distantes.
Estrategia de actualización. Nuevas versiones de modelos, actualizaciones del servidor. Despliegues azul-verde (blue-green) para evitar tiempos de inactividad.
Cada uno de estos es trabajo de ingeniería que las APIs gestionadas absorben por ti.
Dos registros de decisión a producir
No inventes un resultado anonimizado. Elabora registros de decisión auditables a partir de cotizaciones actuales y artefactos de pruebas comparativas.
Registro de la opción autoalojada:
- artefacto del modelo, revisión, licencia, cuantización, versión del servidor, acelerador, región y topología de despliegue,
- distribución de carga y evaluación de calidad frente a la línea base alojada actual,
- comando de prueba de carga, conjunto de datos, resultados de latencia/throughput, punto de saturación y comportamiento de recuperación,
- coste de capital o alquiler, utilización, esfuerzo de ingeniería, trabajo de seguridad y coste esperado de incidentes,
- rango de equilibrio con análisis de sensibilidad y criterio de salida.
Registro del candidato gestionado:
- proveedor, comportamiento del modelo/revisión, región, fecha de la hoja de precios, cuotas y términos contractuales,
- evidencia equivalente en calidad, latencia, límite de tasa (rate-limit), tiempo de inactividad y límites de datos,
- esfuerzo de migración y riesgo de concentración del proveedor,
- condiciones que desencadenarían otra evaluación de autoalojamiento.
Cuándo revisar la decisión
La decisión no es permanente. Revisa periódicamente:
Cambios en el volumen. Aumento significativo: hace más atractivo el autoalojamiento. Disminución significativa: menos atractivo.
Cambios en los precios. APIs cerradas más baratas o más caras. Modelos abiertos gestionados más baratos. Hardware más barato.
Mejoras de modelos. Nuevos candidatos de pesos abiertos o de código disponible (source-available) que cumplen el objetivo de la carga de trabajo, o nuevos modelos cerrados que cambian la comparación de calidad. Verifica licencias y disponibilidad real.
Capacidad operativa. El equipo creció o se redujo en capacidad ML/ops.
Cambios en privacidad / cumplimiento. Nuevos requisitos que obligan al autoalojamiento.
Establece una frecuencia de revisión basada en la volatilidad del contrato, precio, modelo, carga, seguridad y capacidad, y añade desencadenantes activados por eventos. Una revisión trimestral es un ejemplo, no un valor predeterminado universal.
Errores comunes
Patrones que vemos en las decisiones de autoalojamiento:
Error 1: Cálculo de costes sin el coste operativo. Se reportan ahorros en tokens o aceleradores mientras se omiten los costes de ingeniería, guardia activa (on-call), seguridad e incidentes.
Error 2: Autoalojamiento demasiado pronto. Gastar esfuerzo de ingeniería en autoalojar cuando la carga es pequeña. Optimización prematura.
Error 3: Comparar calidad no equivalente. Se selecciona un modelo de menor coste sin demostrar que cumple con los requisitos de calidad, seguridad y latencia de la carga.
Error 4: Sin plan de fallos. La infraestructura autoalojada se cae sin una ruta probada de degradación, cola, rechazo o alternativa (fallback). Las APIs gestionadas también pueden fallar; compara ambas arquitecturas frente al mismo objetivo de disponibilidad.
Error 5: Asumir que la primera configuración del servidor es eficiente. No se ejecuta un barrido reproducible a través de cuantización, agrupamiento por lotes (batching), concurrencia, longitudes de prompt y configuraciones del servidor, por lo que el modelo de capacidad descansa en una configuración no verificada.
Error 6: Ignorar la deriva de calidad. El modelo autoalojado se ha degradado frente al cerrado actual. Los clientes lo notan; el equipo no.
Error 7: No reconsiderar. Una vez que autoalojas, nunca vuelves a evaluar. La decisión podría haber sido correcta hace dos años y estar equivocada ahora.
Error 8: Spot/preemptible sin una gestión controlada. Se modela la capacidad con descuento sin frecuencia de interrupciones, tiempo de recuperación, trabajo duplicado o coste de alternativa (fallback).
Una lista de verificación para decisiones
Para tomar la decisión deliberadamente:
- ¿Se han realizado pruebas comparativas (benchmarks) a candidatos alojados y autoalojados equivalentes en calidad?
- ¿La carga es estable y predecible?
- ¿El equipo tiene o puede contratar experiencia en MLOps/inferencia?
- ¿Existe un candidato de pesos abiertos o de código disponible (source-available), con licencia adecuada, que cumpla el objetivo de calidad y seguridad de la carga de trabajo?
- ¿Los requisitos de latencia son compatibles con el autoalojamiento?
- ¿Has hecho el cálculo detallado de costes, incluidos los costes operativos?
- ¿Tienes un plan de alternativa (fallback)?
- ¿Los requisitos de cumplimiento/privacidad no obligan a una ruta específica?
- ¿Existe una frecuencia de revisión documentada y desencadenantes activados por eventos para cambios materiales en modelo, precio, contrato, carga, seguridad o capacidad?
No reduzcas esto a un recuento de casillas. La seguridad, la calidad del modelo o la propiedad operativa pueden ser un veto incluso cuando todas las variables financieras parecen favorables.
Patrones híbridos
No es todo o nada. Los patrones híbridos candidatos incluyen:
Autoalojado para el grueso del tráfico; APIs para los casos difíciles. Clasificación y generación simple en autoalojamiento; razonamiento complejo en APIs cerradas.
Autoalojado para carga estable; APIs para picos. El autoalojamiento atiende la carga base; las APIs absorben los picos.
Autoalojado para datos sensibles; APIs para lo general. Datos sensibles a través de autoalojamiento; consultas generales a través de APIs.
Autoalojado para ajustes finos (fine-tunes); APIs para el modelo base. Modelos personalizados ejecutados por ti mismo; modelos estándar (off-the-shelf) a través de APIs.
Un enfoque híbrido añade complejidad de enrutamiento, política de datos, evaluación, observabilidad, contrato y fallos. Adóptalo solo cuando las pruebas muestren que la división mejora un objetivo explícito.
Decide con la evidencia actual
El autoalojamiento es una arquitectura viable cuando un modelo compatible cumple el objetivo de calidad de la carga de trabajo y la organización puede responsabilizarse de todo el ciclo de vida del servicio.
El punto de equilibrio no es un gasto mensual universal. Cambia con la calidad del modelo, la forma de la demanda, la utilización, los precios de aceleradores y proveedores, disponibilidad, requisitos de límites de datos y coste del personal.
La evidencia que respalda una decisión de autoalojamiento debe mostrar:
- Haber hecho los cálculos con cuidado, incluidos los costes operativos.
- Tener o poder construir capacidad en MLOps.
- Operar a escala suficiente para justificar la inversión.
- Contar con cargas estables.
- No necesitar capacidades exclusivas de los modelos de vanguardia.
- Planificar fiabilidad, monitorización y actualizaciones.
La evidencia que favorece una decisión de servicio gestionado puede incluir:
- Escala menor.
- Cargas con picos.
- Necesidad de iteración rápida.
- Equipos pequeños sin capacidad de operaciones.
- Necesitar capacidades cerradas de vanguardia.
La respuesta correcta es específica de cada carga de trabajo. Ejecuta comparaciones de calidad, carga, fallos, seguridad y coste, y evalúa la capacidad operativa. Prefiere la opción con menor propiedad operativa que satisfaga los requisitos obligatorios; esa puede ser gestionada, autoalojada o híbrida.
Cuando se selecciona el autoalojamiento, registra el beneficio medido, supuestos, propietario, criterios de salida y próximo desencadenante de revisión. Haz lo mismo para la inferencia gestionada; ninguna ruta es correcta sin evidencia actual.
