Control de costos 101: mantener asequible una función de IA

Una función de IA tiene una propiedad inusual para ser software: cuesta dinero cada vez que alguien la usa. El código tradicional corre en servidores que ya pagaste, así que una llamada extra es casi gratis. Un modelo de lenguaje te factura por solicitud, y la factura escala con el uso. Eso cambia cómo construyes. Un prototipo que cuesta centavos al día puede convertirse silenciosamente en una función que cuesta más que el equipo que la construye, y la diferencia rara vez es un gran error: son cien pequeños hábitos que se acumulan. Este recorrido cubre las palancas duraderas para mantener asequible una función de IA, las que siguen funcionando sin importar qué modelo o proveedor uses.

Cómo te facturan realmente

No puedes controlar un costo que no entiendes, así que empieza por la unidad. Los modelos de lenguaje facturan por token: un trozo de texto, muy aproximadamente unos pocos caracteres o parte de una palabra. Cada solicitud se cobra por los tokens que entran (tu prompt: instrucciones, contexto, ejemplos, la entrada del usuario) y los tokens que salen (la respuesta del modelo). Ambas direcciones cuestan, y en muchos modelos los tokens de salida cuestan más por token que los de entrada.

De esto se desprenden dos consecuencias de inmediato. Primera, un prompt largo no es gratis ni siquiera antes de que el modelo diga una palabra: todo ese contexto es entrada que pagas en cada llamada. Segunda, una respuesta verbosa cuesta más que una concisa que dice lo mismo. Tu factura total es esencialmente tokens-por-solicitud multiplicado por solicitudes, y casi cada palanca de abajo es una forma de encoger uno de esos dos factores sin encoger la calidad.

Palanca 1: Dimensiona bien el modelo

La mayor decisión de costo es qué modelo usas, porque capacidad y precio se mueven juntos: los modelos más fuertes cuestan considerablemente más por token que los más pequeños y rápidos. El instinto es recurrir al modelo más capaz para todo. La disciplina es preguntar qué necesita realmente cada tarea.

Muchas tareas son fáciles: clasificar un mensaje, extraer un campo, una reescritura breve, una respuesta rutinaria. Un modelo más pequeño y barato suele manejarlas perfectamente bien, y usar un modelo insignia para ellas es pagar por capacidad que no estás usando. Reserva los modelos caros para el trabajo genuinamente difícil —razonamiento profundo, generación matizada— donde la diferencia de calidad se gana su precio. Un patrón potente es enrutar por dificultad: un modelo barato maneja la mayoría fácil, y solo los casos difíciles escalan al caro. La disciplina de evaluación de las pruebas de calidad aplica aquí directamente: mide si el modelo más barato es lo bastante bueno antes de suponer que no lo es.

Palanca 2: Gasta menos tokens por llamada

Una vez que el modelo está bien dimensionado, ataca los tokens. Del lado de la entrada, recorta el prompt a lo que la tarea necesita. Instrucciones infladas, ejemplos redundantes y contexto que el modelo no usa cuestan dinero en cada llamada, y a escala ese desperdicio es todo el problema. Esto es doblemente cierto en sistemas de recuperación y de agentes, donde es tentador meter contexto "por si acaso": cada pasaje no usado se paga para siempre.

Del lado de la salida, pide lo que necesitas y nada más. Si quieres tres viñetas, di tres viñetas; un modelo sin restricciones a menudo escribirá tres párrafos. Donde la tarea lo permita, pide un formato compacto. Nada de esto se trata de ser tacaño por serlo: se trata de no pagar por tokens que no aportan nada. Un prompt y una respuesta que cargan solo lo que la tarea requiere son a la vez más baratos y normalmente más claros.

Palanca 3: Deja de pagar dos veces por el mismo trabajo

Buena parte del costo de IA es pagar repetidamente por trabajo idéntico o casi idéntico, y hay dos formas limpias de detenerlo.

El caché significa reutilizar un resultado que ya tienes. Si muchas solicitudes comparten un trozo grande e invariable de contexto —el mismo system prompt largo, el mismo documento de referencia— el caché de prompts te permite evitar reprocesar esa porción fija cada vez, lo que puede recortar drásticamente el costo de entrada de las llamadas repetitivas. Por separado, si los usuarios preguntan con frecuencia exactamente lo mismo, puedes cachear la respuesta y servirla directamente sin llamar al modelo en absoluto. La llamada de modelo más barata es la que nunca haces.

La deduplicación y el procesamiento por lotes abordan el volumen. Si tu sistema dispararía la misma solicitud dos veces, dispárala una. Si tienes muchas solicitudes no urgentes —procesamiento nocturno, análisis masivo— manejarlas juntas suele ser más barato que una llamada frenética a la vez, y algunas plataformas tarifan el trabajo por lotes no urgente por debajo de las tarifas en tiempo real. El hilo común: el trabajo idéntico debería hacerse una vez, y el trabajo paciente no debería pagar el sobreprecio de la impaciencia.

Palanca 4: Pon tope a los desbocados

La mayoría de los desastres de costo no son un goteo constante; son un único componente que se desboca. Un agente atascado en un bucle, llamando al modelo una y otra vez. Un reintento que se dispara en cada fallo sin límite. Un usuario —o un script haciéndose pasar por uno— enviando miles de solicitudes por hora. El uso constante es fácil de presupuestar. Los desbocados son los que producen la factura que le hunde el estómago a alguien.

Así que pon techos en todas partes donde pueda formarse un bucle o una cola. Limita el número de pasos que un agente puede dar antes de detenerse e informar. Limita los reintentos. Limita cuántas solicitudes puede hacer un solo usuario en una ventana. Fija un máximo duro a la longitud de respuesta para que una solicitud patológica no genere una respuesta enorme y cara. Ninguno de estos topes debería morder durante el uso normal; existen precisamente para el caso anormal, y la única vez que te salvan se pagan a sí mismos muchas veces.

Palanca 5: Mide antes de optimizar

No puedes gestionar lo que no ves, y la mayoría de las sorpresas de costo son en realidad fallos de visibilidad: el gasto estaba ahí todo el tiempo, nadie miraba. Antes de optimizar nada, instrumenta la función para saber adónde se va el dinero: qué operaciones son las más caras, cómo se desglosa el costo entre entrada y salida, qué usuarios o tipos de solicitud dominan.

Esto importa porque el costo, como el rendimiento, sigue un sesgo: una pequeña fracción de las operaciones suele impulsar una gran fracción de la factura. Optimizar una ruta barata y rara se siente productivo y no ahorra nada. Encuentra primero la ruta cara y frecuente y arregla esa. Luego vigila la tendencia con el tiempo, porque el uso crece y una función que era asequible al lanzarse puede derivar hacia lo caro a medida que sube la adopción. Configura una alerta para cuando el gasto cruce un umbral que elegiste deliberadamente, para enterarte de un problema de costo por tu propio tablero en vez de por un correo de finanzas.

Equilibrar costo y calidad

Cada palanca aquí se contrapone a algo, y fingir lo contrario lleva a una función barata que nadie quiere usar. Un modelo más pequeño ahorra dinero y puede responder algo peor. Un prompt más corto ahorra tokens y puede dejar fuera un fragmento de contexto que importaba. Un caché agresivo ahorra llamadas y arriesga servir una respuesta obsoleta. El objetivo no es el menor costo posible: eso es una función sin usuarios. El objetivo es el menor costo que aún cumple tu umbral de calidad. Aquí es exactamente donde una evaluación se gana su sustento: te permite hacer un cambio de reducción de costo y comprobar, con números en vez de esperanzas, que la calidad se sostuvo. Recorta costo, mide calidad, conserva los recortes que la calidad sobrevive.

En resumen

Mantener asequible una función de IA se reduce a un puñado de hábitos duraderos: diseño consciente de la factura que entiende los tokens, dimensionar bien el modelo a cada tarea, gastar menos tokens por llamada, nunca pagar dos veces por el mismo trabajo, poner tope a los componentes que pueden desbocarse, y medirlo todo para optimizar la ruta que de verdad cuesta dinero. Nada de esto requiere un truco ingenioso, y todo sobrevive a los cambios de modelo y proveedor porque se desprende de cómo están tarifados estos sistemas. Acompaña cada recorte con una evaluación para que la calidad se mantenga honesta, y una función que podría haberse arruinado a sí misma sigue siendo una que puedes permitirte mantener en marcha.