One-Command vLLM Is Table Stakes, Not a Strategy
HuggingFace Jobs hizo que la inferencia auto-alojada fuera sin fricción. Señalas una tarjeta de modelo, seleccionas un H100, eliges una cuantización e implementas. Dieciséis minutos después tienes un endpoint compatible con OpenAI sirviendo Llama 3.1 70B o Mistral Large. Eso es real. El batching continuo de vLLM y PagedAttention han hecho que la capa de servicio sea genuinamente buena—sin más construcción de pilas de inferencia personalizadas a partir de artefactos de contenedores de NVIDIA y depuración de errores OOM en producción.
Pero en el momento en que ese botón funciona, la decisión difícil ya estaba tomada. La fricción de despliegue nunca fue la restricción. La restricción es si deberías auto-alojar en absoluto.
El Break-Even es un cálculo de volumen de tokens, no una vibra
Aquí está la matemática que ejecutamos con clientes. Un H100 bajo demanda en HF Jobs cuesta $2–4 por hora dependiendo de la región y el compromiso. Un único H100 puede impulsar sosteniblemente aproximadamente 15,000–20,000 tokens por segundo (entrada + salida) con latencia razonable, asumiendo que realmente estás haciendo batching y no dejando que la GPU se siente medio vacía.
GPT-4o-mini cuesta $0.075 por 1M de tokens de entrada y $0.30 por 1M de tokens de salida. Claude 3.5 Haiku corre $0.80/$4.00 por 1M. Si tu carga de trabajo es principalmente razonamiento en contexto pequeño, estás mirando una tasa combinada efectiva alrededor de $0.15–0.25 por 1K tokens. Eso es $1.50–2.50 por mil millones de tokens. Un H100 auto-alojado a $3/hr puede servir aproximadamente 54–72M tokens por hora, lo que significa que estás pagando aproximadamente $0.04–0.06 por 1K tokens solo en el costo de GPU—si estás a utilización completa.
El break-even es agudo. Si estás ejecutando menos de 500M tokens por día, quedarse en la API es más barato, más simple, y no posees el buscapersonas de guardia. A 2B tokens por día con tráfico sostenido, auto-alojar el modelo abierto correcto (Llama 3.1 70B, Qwen2.5 72B) comienza a ganar en costo bruto. Pero eso asume que tu tráfico es predecible, tu utilización realmente se mantiene alta, y no estás quemando horas de ingeniería manteniendo la cosa funcionando.
La mayoría de los equipos subestiman la utilización. Una GPU sentada al 40% de utilización porque el tráfico llega en picos todavía cuesta $3/hr. Eso es $21.6K por mes para el 40% de un H100. La API absorbe tus picos. Los heredas.
Latencia: la historia p99 que la página de marketing no te dirá
El batching continuo de vLLM es real, y reduce el tiempo al primer token (TTFT) con carga mediana. La flota de inferencia de un proveedor de API se dimensiona para latencia p99 en miles de solicitudes concurrentes. Tu H100 bajo demanda en HF Jobs es un endpoint. Cuando obtienes tráfico de ráfaga—tu agente genera seis llamadas de herramienta paralelas, o un equipo de ventas de repente ejecuta 50 llamadas salientes—tu cola de GPU se llena y p99 TTFT sube a 500–800ms, donde el de la API se mantiene en 150–200ms.
Para agentes, esto es un multiplicador. Una única llamada de herramienta a 200ms de latencia de cola es molesta. Seis llamadas de herramienta en un bucle, cada una golpeando el modelo de razonamiento de un agente, significa 1.2 segundos de latencia que el usuario siente. Auto-alojar esa capa de razonamiento y tu p99 se duplica en días malos. Esa es la diferencia entre un agente responsivo y uno que se siente lento.
Si tu forma de tráfico es genuinamente plana y predecible—un trabajo por lotes que se ejecuta a las 11pm, rendimiento estable sin ráfagas—la historia de latencia de auto-alojamiento es buena. Si es un agente orientado al usuario o un producto que ve picos de tráfico, quedarse en la API te compra cobertura de cola de latencia que un H100 no te dará.
Modos de fallo que heredas en el momento en que auto-alojas
Una llamada a API fallando y reintentando es un problema resuelto. Posees retroceso exponencial, claves de idempotencia, colas de letras muertas. HuggingFace Jobs maneja el contenedor y el controlador de GPU, pero no manejan tu enrutamiento de solicitudes o tu monitoreo.
En el momento en que tienes un endpoint vLLM auto-alojado, posees: errores OOM en entradas de contexto largo (sin alternancia automática a una ventana de contexto más pequeña); bloqueos del controlador CUDA (suceden; hemos enviado ambos); versionado de pesos de modelo (¿qué revisión de HF estás ejecutando? ¿puedes revertir si una cuantización se rompe el martes?); observabilidad (Prometheus raspando tus métricas de vLLM, registros de solicitudes en Loki o CloudWatch, contabilidad de tokens para que sepas por qué tu utilización es más baja de lo planeado); rotaciones de guardia (alguien te llama a las 2am cuando el endpoint se queda en silencio); redundancia (un endpoint es un punto único de fallo—eventualmente necesitarás dos H100s, lo que borra la ventaja de costo).
Un sistema nativo de API es más simple. No es cero superficie operacional, pero es más pequeño.
El bloqueo de proveedor corta en ambos sentidos
El argumento "bloqueo a Anthropic/OpenAI" se saca a relucir cada vez que surge el auto-alojamiento. Es real—ajustarás tus indicaciones a los caprichos de un modelo y los costos de cambio son genuinos. Pero el auto-alojamiento no está libre de bloqueo. Te bloquea a la disponibilidad de H100 (la cadena de suministro para GPUs empresariales es realmente ajustada), a HF Jobs como tiempo de ejecución, y a los cambios de ruptura de vLLM (suceden; la capa de compatibilidad de API no está congelada).
El mejor patrón que hemos visto es híbrido. Usa una puerta de enlace compatible con OpenAI (vLLM expone una de forma nativa) frente a tu endpoint auto-alojado. Enruta tu tráfico estable, de alto volumen y predecible allí. Enruta razonamiento fronterizo—el 5% de consultas que necesitan GPT-4o o Claude para razonamiento de dominio que no puedes encajar en un modelo de 70B—a la API. De esa manera no estás bloqueado a ninguno de los dos. El costo es una capa de enrutamiento; el beneficio es opcionalidad.
Si estás en etapa temprana y todavía estás haciendo pruebas A/B de qué modelo funciona para tu dominio, quédate en la API. Cambiar modelos semana a semana en infraestructura auto-alojada es ruido sobre tu señal.
Una regla de decisión que realmente usamos con clientes
Aquí está la lista de verificación que traemos a reuniones de planificación. Primero: ¿cuál es tu forma de tráfico? ¿Es predecible y plana (trabajo por lotes, herramienta interna), o picos y dependiente del usuario (chatbot, agente)? El tráfico predecible justifica auto-alojar más temprano.
Segundo: ¿todavía estás iterando en modelos e indicaciones? Si estás haciendo pruebas A/B semanalmente, quédate en la API. La fricción de reimplementar un contenedor y re-ajustar la cuantización en HF Jobs es real. Una vez que te hayas establecido en un modelo, la estabilidad favorece el auto-alojamiento.
Tercero: cumplimiento o residencia de datos. Si tus datos no pueden salir de tu región o tu modelo de seguridad lo requiere, auto-aloja. Si no, es una conversación de costo.
Cuarto: si pasas la barra para auto-alojamiento, no cambies un interruptor. Implementa vLLM en paralelo a tu API durante dos semanas. Despliegue en la sombra: envía tráfico de producción a ambos, registra ambas respuestas, compara latencias y errores. Cuando el despliegue en la sombra se estabiliza, corta el tráfico. Si algo se rompe, tienes un interruptor de parada.
Hemos visto equipos saltarse ese paso. No aprenden de él, pero nosotros sí. Las dos semanas en la sombra son un seguro.
Quédate en la API hasta que estés quemando más de $5K–10K por mes en un único modelo estable con tráfico genuinamente predecible. Una vez que pasas esa barra, ejecuta un despliegue en la sombra de vLLM durante dos semanas antes de comprometerte. Si quieres que ejecutemos esa matemática contigo o construyamos esa infraestructura, estamos aquí.