Hace seis meses, nuestra factura mensual por modelos de lenguaje alojados era de esas cifras que hacen que finanzas haga preguntas. Hoy es una décima parte de eso, y los modelos son más rápidos en nuestro hardware que nunca a través de internet público. No negociamos un descuento. No cambiamos a un plan más barato. Trajimos los modelos a casa.
El cambio empezó como un experimento y acabó convirtiéndose en un stack. Un conjunto pequeño y bien elegido de modelos de pesos abiertos que se ejecuta en una única máquina de consumo en el borde de nuestra red ahora gestiona la mayor parte de nuestro tráfico de inferencia. Los modelos en la nube siguen en juego, pero solo para los trabajos que realmente los necesitan. Todo lo demás se ejecuta localmente, y el ahorro va directamente al resultado final.
La primera lección fue que no siempre más grande es mejor para cada prompt. Un modelo de 70.000 millones de parámetros es impresionante, pero para resúmenes rutinarios, clasificación y extracción estructurada está desproporcionadamente sobredimensionado. Analizamos el tráfico real y descubrimos que aproximadamente siete de cada diez solicitudes eran rutinarias. Un modelo afinado de 7.000 millones de parámetros las gestionó con una fracción de la latencia y sin coste por token. La clave fue enrutar por tarea, no por costumbre.
La segunda lección tuvo que ver con el hardware. Habíamos asumido que necesitaríamos un rack de aceleradores. En la práctica, una sola GPU moderna con suficiente VRAM para alojar cómodamente dos o tres modelos cuantizados a la vez cubrió nuestra carga máxima. La cuantización a pesos de cuatro bits nos costó una caída medible, pero aceptable, en calidad y nos devolvió enormes cantidades de memoria y rendimiento. Para la larga cola de trabajos de baja prioridad, una alternativa solo con CPU y un modelo más pequeño mantuvo el sistema receptivo cuando la GPU estaba ocupada.
La tercera lección fue sobre el almacenamiento en caché. Los costes por token se acumulan cuando vuelves a evaluar la misma ventana de contexto una y otra vez. Añadimos una caché semántica delante de la capa de inferencia para que los prompts casi duplicados devuelvan una respuesta almacenada sin llegar a tocar el modelo. Combinado con plantillas de prompt que eliminan el historial innecesario, la tasa de aciertos de la caché superó el cuarenta por ciento en cuestión de semanas.
La cuarta lección fue la observabilidad. Sin paneles de latencia por modelo, coste por millón de tokens y comprobaciones puntuales de calidad, optimizar es adivinar. Instrumentamos cada llamada para poder ver exactamente qué rutas eran rentables y cuáles estaban quemando presupuesto en silencio.
Si estás mirando una factura de modelos que ya no encaja con el valor que obtienes de ella, el camino es sencillo. Analiza lo que realmente envías, dimensiona el modelo según la tarea, cuantiza de forma agresiva, cachea duplicados y mide sin descanso. La nube se queda para los casos difíciles. Todo lo demás puede ejecutarse en tu propio escritorio.
¿Tienes curiosidad por saber cómo se vería tu tráfico enrutado así? Responde con tus tres principales casos de uso de modelos y te compartiremos el desglose de enrutamiento con el que empezaríamos.