Análisis: alojar por cuenta propia un modelo de pesos abiertos, la aritmética que determina si compensa y los costes que nadie presupuesta

El debate sobre el autoalojamiento es especialmente propenso a los malos argumentos en ambas direcciones. Un bando da por obvio que ser dueño de la propia infraestructura sale más barato, porque los pesos del modelo son gratuitos. El otro da por obvio que nadie debería operar sus propios aceleradores, porque los grandes proveedores en la nube tienen una utilización que uno nunca podrá igualar.

Ambos describen la misma curva desde extremos distintos. La inferencia alojada es un costo variable y el autoalojamiento es un costo fijo, y toda decisión real es, en el fondo, una pregunta sobre dónde se ubica una carga de trabajo concreta respecto al punto de cruce.

La forma de la comparación

Escribamos ambos lados en las mismas unidades.

Una API alojada cobra por token. Diez millones de tokens de entrada y dos millones de salida al día tienen un costo predecible, y la factura escala de forma lineal con el uso, tanto hacia abajo como hacia arriba. En un fin de semana tranquilo, baja.

El autoalojamiento cobra por hora de acelerador, llegue o no una solicitud. Los precios de alquiler de una GPU de centro de datos de última generación se ubican, en la mayoría de los proveedores, en un rango bajo de un solo dígito de dólares por hora y por tarjeta, con amplia variación según región, nivel de compromiso y proveedor. El hardware propio traduce eso en gasto de capital más energía, refrigeración y depreciación, que una vez amortizado suele situarse en un rango similar; lo relevante es que ambos esquemas se cobran por hora, no por token.

Así que la aritmética queda así:

La consecuencia que sorprende a los equipos está en la segunda fila. Un clúster dimensionado para el pico de carga y con una utilización promedio del 15% está pagando precios de capacidad máxima las veinticuatro horas por un tráfico que llega en ráfagas. La comparación de precio por token que parecía favorable a plena carga resulta seis veces más cara en el promedio real.

El rendimiento es una propiedad del software

El error analítico más común es tratar el rendimiento como algo determinado por el hardware. En realidad lo determina, al menos en igual medida, la pila de servicio.

El procesamiento por lotes domina el resultado. Atender una solicitud a la vez en un acelerador grande desaprovecha la mayor parte de su capacidad; el procesamiento por lotes continuo, en el que las solicitudes nuevas se suman a un lote en curso en lugar de esperar a que termine, puede multiplicar el rendimiento varias veces en la misma tarjeta. Un modelo de costos de autoalojamiento construido sobre pruebas de solicitud única estará equivocado por ese mismo factor.

La cuantización cambia lo que cabe en la memoria. Servir los pesos con precisión de 8 o 4 bits reduce sustancialmente los requisitos de memoria, lo que puede llevar un modelo de dos tarjetas a una sola, y una tarjeta no es un 50% más barata que dos: es un 50% más barata y además elimina toda una capa de complejidad de interconexión. Los métodos modernos de cuantización posterior al entrenamiento suelen ser casi sin pérdidas para muchas tareas, pero "suelen" y "muchas" son palabras clave: hay que comprobarlo con el propio conjunto de evaluación, porque la degradación depende de la tarea y un puntaje promedio puede ocultarla.

El tamaño del modelo es la palanca de mayor efecto. Buena parte del argumento económico a favor del autoalojamiento depende de usar un modelo lo bastante pequeño como para atender muchas solicitudes simultáneas por acelerador. La mejora constante del ecosistema de pesos abiertos en escalas pequeñas es precisamente lo que hizo viable el autoalojamiento para productos comunes; una tarea que de verdad requiere un modelo de vanguardia tiene una factura de hardware muy distinta y un argumento mucho más débil.

Las cuatro partidas que faltan en la primera estimación

Todas las estimaciones iniciales de autoalojamiento que he visto comparten las mismas omisiones.

Redundancia. Un solo nodo es una demostración. La producción necesita al menos dos, en dominios de fallo distintos, más margen para un reinicio progresivo. No es un ajuste del 10%; con frecuencia duplica la partida de hardware antes de que crezca siquiera el tráfico.

Tiempo de ingeniería. Alguien tiene que configurar la pila de servicio, ajustar los parámetros de los lotes, montar el autoescalado, escribir las verificaciones de salud, lidiar con la actualización de drivers que rompe el kernel y recibir la alerta cuando el rendimiento se desploma a las dos de la madrugada. Al costo real y cargado de esa persona, una fracción del año de un solo ingeniero suele superar toda la partida de GPU de una carga de trabajo mediana. Es la línea que más se olvida, y a menudo es la que decide.

Evaluación. Autoalojar suele implicar pasar a un modelo más pequeño. Eso es un cambio de calidad, y confirmar que resulta aceptable exige un conjunto de evaluación, una prueba comparativa y el criterio para interpretar el resultado. Es trabajo real, ocurre antes de que llegue cualquier ahorro y se repite en cada actualización de modelo.

La rueda de las actualizaciones. Las API alojadas mejoran por debajo de uno, sin esfuerzo propio. Una pila autoalojada mejora cuando alguien hace el trabajo: evaluar la nueva versión abierta, reajustar los parámetros de servicio, volver a correr el conjunto de evaluación, planificar la migración. Hay que presupuestarlo como un gasto recurrente, porque lo es.

Cuándo el autoalojamiento gana con claridad

Nada de esto es un argumento en contra. Existe un perfil específico en el que el autoalojamiento es sencillamente la opción correcta.

Volumen constante, alto y predecible. Clasificación por lotes, canalizaciones de procesamiento de documentos, generación de embeddings, colas de moderación: cargas de trabajo que se ejecutan de forma continua y mantienen ocupados a los aceleradores. Son los mejores candidatos al autoalojamiento que existen, y el hecho de que muchas de ellas usen modelos pequeños refuerza aún más el argumento.

Una tarea lo bastante acotada para un modelo pequeño. Clasificación, extracción, enrutamiento, etiquetado estructurado, traducción dentro de un dominio fijo. Si un modelo pequeño bien elegido cumple con la calidad requerida, la economía por solicitud frente a una API de vanguardia no tiene comparación.

Operación sin conexión o en redes aisladas. No hay ninguna API disponible a ningún precio. La decisión ya está tomada de antemano.

Las razones que no tienen que ver con el costo

Algunos de los argumentos más sólidos a favor del autoalojamiento son indiferentes a la aritmética.

Residencia de datos y restricciones regulatorias. Cuando los datos no pueden salir de una jurisdicción o de un límite de red, el autoalojamiento suele ser la única arquitectura conforme a la normativa, y sigue siendo correcta aunque cueste más.

Un piso duro de latencia. El viaje de ida y vuelta por red hasta un extremo alojado tiene un piso que la inferencia local no tiene. Para experiencias interactivas con márgenes muy ajustados —voz, asistencia en tiempo real, autocompletado dentro de un editor—, ese piso puede ser el requisito en sí mismo y no una simple optimización.

Estabilidad de comportamiento. Un modelo alojado puede cambiar sin previo aviso; un punto de control local fijo no. Para sistemas cuidadosamente ajustados al comportamiento específico de un modelo, esa estabilidad tiene un valor que no aparece en ninguna factura.

Independencia de la hoja de ruta de un proveedor. Los calendarios de descontinuación, los límites de tasa, la disponibilidad regional y los términos de servicio son decisiones que toma otra parte. Ser dueño de los pesos elimina esa dependencia, al costo de tener que hacerse cargo de todo lo demás.

La respuesta a la que llega la mayoría de los equipos

En la práctica, el desenlace más habitual en producción no es ninguno de los dos extremos. Es un esquema de enrutamiento: un modelo pequeño autoalojado atiende la porción del tráfico que es grande, bien entendida y de alto volumen, mientras que un modelo de vanguardia alojado se encarga de la cola difícil: los casos ambiguos, los documentos largos, las solicitudes donde la calidad pesa más que el costo.

Esto captura la mayor parte del ahorro, porque la porción de alto volumen es donde está el dinero, y a la vez mantiene un techo de calidad que el modelo pequeño no puede alcanzar por sí solo. También se degrada con elegancia: si el clúster local falla, el tráfico cae a la API a un costo mayor en lugar de caer a una interrupción total del servicio.

Lo único en lo que vale la pena insistir es en que la decisión se tome con cifras reales. Midan su propia curva de utilización, evalúen el rendimiento con el procesamiento por lotes activado, calculen la partida de ingeniería con un salario real e incluyan el trabajo de evaluación. Háganlo, y la respuesta suele volverse evidente. Sáltenselo, y terminarán defendiendo una postura que adoptaron antes de tener ningún dato.