La realidad del autoalojamiento: se trata de soberanía, no de velocidad ni de costo

La cifra de benchmark que todos citan es de un solo flujo. Una caja de 128GB que ejecuta un modelo de 235B a ~11 tokens por segundo es la experiencia de una sola persona, sin nadie más usándola. La generación de tokens es un recurso compartido: dos empleados usándola a la vez obtienen unos 5–6 tok/s cada uno; con diez, es inutilizable. El techo no se mueve mucho con el dinero que de verdad se puede gastar: incluso un clúster de 16× H100 ejecutando un modelo de 397B sostiene quizá 50–100 tok/s de rendimiento total, lo que repartido entre 20 usuarios simultáneos da 3–5 tok/s a cada uno.

Las API en la nube absorben cientos de solicitudes simultáneas a velocidad completa por usuario porque ejecutan miles de GPU detrás de un balanceador de carga: sus solicitudes se reparten en una flota, no hacen fila en una sola caja. Esa brecha es estructural, no algo que se arregle comprando mejor hardware a precios de pequeña y mediana empresa. Una sola caja es un camino de un carril; la nube es una autopista. Para una herramienta que comparten 50 personas durante la jornada, eso es decisivo.

Los modelos de pesos abiertos han cerrado buena parte de la brecha en los benchmarks, pero los benchmarks miden tareas acotadas y bien definidas. El trabajo empresarial real (razonamiento en varios pasos, instrucciones ambiguas, casos límite, contexto largo con recuperación) es donde los modelos cerrados de frontera todavía llevan una ventaja importante. La cifra de la clasificación y la experiencia vivida con tareas reales y desordenadas no son lo mismo.

Hacer ajuste fino de un modelo autoalojado con los datos de su dominio puede cerrar brechas específicas, a veces de forma contundente, en una tarea acotada; lo explicamos en cómo entrenar un modelo abierto. Pero eso requiere un equipo de ML, datos etiquetados y mantenimiento continuo a medida que cambian los modelos y las necesidades. La mayoría de las empresas no tiene eso, y la propuesta de venta del hardware depende en gran medida, sin decirlo, de la promesa de “le haremos ajuste fino”.

El cálculo viral de “$5,280 al año en suscripciones pagan la caja” suma herramientas individuales para desarrolladores (Claude Code, ChatGPT Pro, Cursor, Gemini) y supone que un solo modelo local las reemplaza a todas. No puede. Esas suscripciones compran acceso a modelos de frontera, integraciones con el IDE, garantías de disponibilidad y actualizaciones continuas de los modelos. Un modelo cuantizado y autoalojado a ~11 tok/s no reemplaza a un modelo de frontera en el trabajo diario de un desarrollador; en el mejor de los casos lo complementa para tareas específicas sin conexión. Cancelar las suscripciones y quedarse con la caja es un retroceso, no un empate.

Hay casos reales; solo que son más acotados de lo que dice el entusiasmo, y la concurrencia es la pista. El autoalojamiento gana donde la latencia por usuario bajo carga no importa:

• Cargas por lotes. Procesamiento de documentos, generación de embeddings, trabajos de clasificación nocturnos. La concurrencia es irrelevante; el costo por token lo es todo. Este es el argumento económico más sólido.
• Soberanía de los datos. Salud, servicios legales, defensa: casos en los que los datos físicamente no pueden salir del edificio. La concesión en rendimiento se acepta, no se prefiere.
• Tareas comunes de alto volumen. 1B o más de tokens al día en una tarea acotada y bien definida (extracción de entidades, un solo tipo de documento), donde un modelo más pequeño con ajuste fino iguala la calidad de frontera por una fracción del costo. Nuestras propias cuentas de punto de equilibrio de Costo y TCO ubican el cruce en torno a 0.75–1.6B de tokens al día frente a los precios de las API de frontera: mucho volumen en una sola tarea acotada.
• Ajuste fino con datos propios. Un modelo de 70B ajustado a su dominio puede superar a un modelo general de frontera en su tarea específica, si usted tiene la infraestructura de ML para construirlo y mantenerlo.

Note lo que tienen en común: lotes, soberanía, una sola tarea acotada a gran escala. Ninguno es “reemplazar el asistente de IA de uso general de la empresa con una caja”.

Para una empresa que evalúa una IA privada, el argumento del autoalojamiento es casi por completo de soberanía, no de economía ni de rendimiento. Elegir un despliegue privado en lugar de una oferta empresarial en la nube es comprar una sola garantía: sus datos nunca tocan un modelo de terceros. Es un argumento de cumplimiento normativo y de confianza, y uno sólido.

Si se vende como “más rápido y más barato que la nube”, se pierde la conversación casi siempre, porque a la escala empresarial típica no lo es. La propuesta que se sostiene es: la misma calidad que las API en la nube (por ejemplo, Claude a través de Bedrock), aislamiento de los datos garantizado en la capa de infraestructura y ningún proveedor de modelos viendo jamás sus prompts. Eso es un producto real y diferenciado. El ángulo del hardware local (una caja de $2K sobre un escritorio) es un mercado genuinamente distinto: desarrolladores e investigadores individuales, no empresas de 50 o más empleados que comparten la herramienta todo el día.

No: es una herramienta con una forma específica. El error está en el planteamiento, no en el hardware. Haga las cuentas para su caso real: ¿cuántas personas lo usan a la vez, qué tan difíciles son las tareas, y el verdadero motivo es el costo, el rendimiento por lotes o la residencia de los datos? Si la respuesta honesta es “un asistente compartido para todo el equipo, en trabajo difícil y variado, y lo queremos más rápido y más barato”, gana la nube, y las palancas de enrutamiento y caché son donde de verdad está su ahorro. Si es “un trabajo por lotes nocturno” o “datos regulados que no pueden salir”, autoaloje, con los ojos abiertos sobre las concesiones.