Autoalojar un modelo de pesos abiertos: el punto de equilibrio está más lejos de lo que crees

Alguien hace la cuenta en una pizarra. Una instancia con GPU cuesta tanto por hora, puede producir muchos tokens por segundo, luego el coste por millón de tokens es una fracción de lo que cobra la API. La conclusión parece obvia.

El defecto es el mismo que hace que el hierro propio parezca barato frente a la nube en general. La API cobra por los tokens que usaste de verdad. La GPU cobra por tiempo, esté la cola llena o vacía. A un cinco por ciento de utilización, que es lo que consigue una herramienta interna típica, el coste efectivo por token es veinte veces el número de la pizarra.

La utilización es la variable que decide esto, y casi nadie la estima antes de decidir.

La estructura de cada coste

El precio de API es por token de entrada y de salida, y la salida suele costar varias veces la entrada. Es estrictamente variable: sin tráfico, sin coste. La caché de prompts recorta de forma sustancial el coste de un prompt de sistema repetido o de un contexto documental estable, y los niveles por lotes o asíncronos lo recortan más para trabajo que puede esperar. Esos dos mecanismos se ignoran con frecuencia, y cambian la comparación más que la mayoría de las decisiones de arquitectura.

El autoalojamiento es por hora de GPU, más la ingeniería de operarlo. Fijo respecto al tráfico y continuo. Una instancia reservada o un compromiso baja la tarifa por hora y aumenta la parte fija, con lo que la utilización importa todavía más.

Así que la comparación honesta no es coste por token contra coste por token. Es tu gasto mensual en API contra el coste mensual de suficiente capacidad de GPU para servir tu pico, multiplicado por la redundancia que necesites, más una fracción de un ingeniero.

La utilización es el argumento entero

Calcula los tokens por segundo que necesitas de verdad en pico, y después en la mediana. La proporción entre ambos es tu problema.

Una carga por lotes que procesa una cola por la noche puede mantener una GPU con utilización alta, y es con diferencia el mejor caso para autoalojar. Un asistente interactivo usado por el personal en horario laboral de un solo huso está ocioso la mayor parte de la semana, y es casi el peor caso salvo que puedas escalar a cero, lo que en un modelo grande implica arranques en frío medidos en minutos porque hay que cargar los pesos.

De ahí se siguen dos cosas. Primera, las cargas mixtas ayudan: si puedes empujar trabajo por lotes al mismo hardware en las horas tranquilas, la economía cambia mucho. Segunda, la relación entre pico y mediana decide si puedes comprar capacidad reservada o tienes que pagar tarifa bajo demanda para los picos, y la disponibilidad de GPU bajo demanda no está garantizada en todas las regiones.

Qué determina de verdad el rendimiento

Servir de forma ingenua con un bucle de inferencia simple desperdicia casi todo el hardware. La diferencia entre un despliegue malo y uno bueno son varias veces el rendimiento sobre la misma GPU, lo que mueve el punto de equilibrio más que la elección de instancia.

El procesamiento por lotes continuo es el factor individual mayor. Un servidor de inferencia hecho para esto procesa muchas peticiones a la vez, añadiendo nuevas al lote según terminan otras, en vez de esperar a que un lote se complete. Sin él estás pagando una GPU que está ociosa la mayor parte del tiempo entre tokens.

La memoria determina todo lo demás. Los pesos ocupan memoria proporcional al número de parámetros y a la precisión. Lo que se olvida es la caché de atención, que crece con el número de peticiones concurrentes y con la longitud de cada contexto. Una carga de contexto largo con muchos usuarios simultáneos puede gastar más memoria en caché que en pesos, y cuando no cabe, el rendimiento se desploma.

La cuantización reduce la memoria de los pesos y aumenta el rendimiento a cambio de algo de calidad. Ocho bits es en general casi sin pérdida para la mayoría de tareas. Cuatro bits es usable y la degradación depende de la tarea, así que hay que medirla sobre tu propio conjunto de evaluación en vez de suponerla desde un banco de pruebas. La cuantización es a menudo lo que hace que un modelo quepa en una GPU en vez de en dos, que es un salto de coste y no un incremento.

El tamaño del modelo es la palanca mayor de todas. Un modelo pequeño que sea suficientemente bueno para tu tarea, posiblemente destilado de uno mayor, cambia la economía por completo. El razonamiento está en ajuste fino, RAG o un prompt mejor, y es la opción más desaprovechada de toda esta área.

Los costes de fuera de la instancia

• Redundancia. Una GPU es un punto único de fallo. Dos es el mínimo para cualquier cosa en producción, lo que duplica el coste fijo antes de servir una sola petición más.
• No producción. Un entorno de preproducción con GPU es dinero real, y compartirlo con desarrollo es el compromiso habitual.
• Almacenamiento y carga. Los pesos son grandes, y cada evento de escalado los lee. El tiempo de arranque en frío es una decisión de producto, no solo un detalle de operación.
• Tiempo de ingeniería. Alguien es dueño del servidor de inferencia, de las actualizaciones, de la planificación de capacidad y de los incidentes. Presupuesta una fracción de persona de forma permanente.
• Evaluación. Con una API heredas el trabajo de calidad del proveedor. Autoalojar significa que eres dueño del conjunto de evaluación y de las pruebas de regresión, como en evaluar una funcionalidad con LLM.
• Cuota y disponibilidad. La capacidad de GPU está limitada en muchas regiones, y una solicitud de cuota es un plazo de entrega, no un clic.

Las razones que no van de coste

Estas son las buenas razones, y justifican autoalojar aunque la aritmética no lo haga.

Residencia y control del dato. Si el dato no puede salir de tu frontera, o el cuestionario de un comprador lo exige, el modelo tiene que correr donde tú controlas. Es el motivo legítimo más común que vemos en proyectos europeos, y conecta directamente con dónde vive tu dato de verdad.

Estabilidad de versión. Un proveedor puede retirar o actualizar en silencio un modelo detrás de un extremo estable. Un modelo autoalojado es exactamente los pesos que desplegaste, lo que importa cuando tienes un sistema validado y un regulador preguntando cómo se controla su comportamiento.

Latencia y cercanía. Ejecutar junto a la carga elimina un viaje de red, lo que importa en uso interactivo o de alta frecuencia.

Personalización. Servir varios adaptadores ajustados sobre un mismo modelo base es sencillo cuando el servidor es tuyo, y a menudo no está disponible o es caro de otro modo.

Previsibilidad. Un coste mensual fijo vale a veces más para una dirección financiera que uno variable más bajo.

La forma que suele ganar

Para la mayoría de las organizaciones la respuesta no es ninguna de las dos opciones puras.

Usa una API para trabajo interactivo, irregular, de poco volumen y sensible a la calidad, con caché de prompts activada y un modelo pequeño para el subconjunto fácil de peticiones. Autoaloja para tareas de alto volumen, estables y estrechas: clasificación, extracción, embeddings, enriquecimiento por lotes. Los embeddings en particular son un caso fuerte de autoalojamiento, porque los modelos son pequeños, el trabajo suele ser por lotes y el volumen es alto.

Y después encamina por tarea en vez de elegir un proveedor para todo. La capa de encaminamiento es una pieza pequeña de ingeniería que se paga sola rápido, y mantiene la salida disponible en las dos direcciones.

Qué hacer esta semana

Coge la factura de API del mes pasado y divídela entre el coste por hora de la instancia con GPU que necesitarías para tu pico, por dos para la redundancia. Ese número es la fracción de mes que tendrías que correr a plena utilización para llegar al equilibrio. Después mira tu gráfica de tráfico y pregúntate con honestidad cuál sería tu utilización. En casi todos los entornos esa comparación resuelve la cuestión en una hora. La hacemos en la fase de costes de un proyecto de IA aplicada.