Lance una función de IA y la primera factura del proveedor del modelo no le dice casi nada sobre lo que realmente cuesta servirla. El precio por token es la décima parte visible del iceberg. Debajo está la recuperación de contexto, la orquestación, los registros técnicos, la revisión humana para los casos en que el modelo se equivoca, y los tickets de soporte que la función genera cuando se equivoca con toda confianza. La mayoría de los equipos fija el precio de la función, o decide si la mantiene, usando solo la parte que puede ver.

En resumen

¿Cuánto cuesta realmente servir una función de IA?

La factura de la API del modelo es solo una línea del coste real. Una cifra completa suma la recuperación de contexto y el almacenamiento vectorial, la infraestructura de orquestación y registros, la revisión humana o moderación de una parte de las respuestas, y el coste de soporte de gestionar los errores. En la mayoría de las funciones de IA, estos costes alrededor son comparables, y a veces mayores, que la propia factura de inferencia - por eso tratar la factura de la API como el coste de servir la infravalora gravemente.

La factura que ve, y la que no ve

La factura de inferencia es fácil de seguir porque llega como una única factura desglosada: tokens de entrada, tokens de salida, un precio por millón. Esa visibilidad es exactamente la razón por la que se trata como el coste total. Todo lo demás que hace que la función funcione - el paso de recuperación que busca contexto antes de que el modelo siquiera se ejecute, la capa de orquestación que llama al modelo, comprueba la respuesta y a veces repite la llamada, los registros que le permiten depurar una respuesta mala seis semanas después - es gasto de infraestructura que aparece en la factura de la nube bajo una docena de partidas sin relación aparente, no en la factura del proveedor del modelo.

La recuperación y la orquestación no son gratis

Una función con recuperación aumentada hace una búsqueda antes de ejecutar un modelo: una llamada de embedding, una consulta a una base de datos vectorial, a veces un paso de reordenación. Cada una de ellas tiene su propio coste, escala con el uso igual que escala la llamada al modelo, y muy a menudo queda fuera de la economía unitaria por completo, porque vive en otra parte de la arquitectura, la factura otro proveedor y la sigue otro equipo. La orquestación añade reintentos, alternativas hacia un modelo más barato cuando el principal no está disponible, y el cómputo para las comprobaciones que deciden qué modelo llamar. Nada de esto es exótico. Todo esto es un coste real por petición que un modelo de coste de servir tiene que incluir.

El coste que nadie pone en la hoja de cálculo: equivocarse

Toda función de IA falla en una parte de sus respuestas, y las respuestas equivocadas tienen un coste real aunque nunca aparezca en una factura: un ticket de soporte, el tiempo de un revisor humano, un reembolso, un cliente que se va. Una función con una tasa de error del 3% y otra con una tasa del 15% pueden tener una factura de inferencia idéntica y un coste total completamente distinto, porque la segunda genera muchísimo más trabajo posterior. Tratar la factura de la API como el coste de la función hace que el modelo barato y poco fiable parezca la mejor opción, hasta que la cola de soporte dice lo contrario.

1
factura de la API, y es solo un componente del coste real de servir
4
capas de coste que necesita una cifra completa: inferencia, recuperación y orquestación, revisión y soporte
0
de esas capas extra aparecen automáticamente en la factura del proveedor del modelo

Construir un coste de servir real para una función de IA

El método no cambia solo porque el coste implique un modelo: defina la actividad - responder una consulta, redactar un documento, clasificar un ticket - y siga cada cost pool que consume una unidad de esa actividad. La inferencia es un driver. Las llamadas de recuperación son otro. Los minutos de revisión humana, cuando una parte de las respuestas los necesita, son un tercero, costeados igual que cualquier actividad intensiva en mano de obra se costea en un modelo TDABC. Súmelos por unidad de trabajo realmente realizado, no por euro de gasto en el modelo, y el margen real de la función - y si merece la pena mantenerla en su forma actual - se vuelve visible por primera vez.

La factura del proveedor del modelo es el coste de los tokens. No es el coste de la función.

Qué comprobar antes de confiar en la economía unitaria de una función de IA

Antes de indicar un coste por petición o un margen para una función de IA, confirme que la infraestructura de recuperación y orquestación se le ha asignado, y no se ha quedado dentro de un coste de plataforma compartida que nadie sigue hasta su origen. Confirme que se ha estimado una tasa de error realista y se ha incluido en el modelo, usando datos reales de revisión o soporte, no la precisión prometida en el benchmark de un proveedor. Y confirme que la comparación entre un modelo más barato y menos preciso y otro más caro y más preciso incluye el coste posterior de equivocarse, no solo las dos facturas una al lado de la otra.

Vea cómo es un modelo completo de coste de servir para IA.

Reserve una demostración en directo de CostCtrl y vea cómo los costes de inferencia, recuperación, revisión y soporte se juntan en un único número real por función.

Ver una demo en directo de CostCtrl

Lectura relacionada: coste de servir para funciones de IA y dónde se equivocan los LLM en la asignación de overhead.