Software personalizado
Lo que realmente cuesta ejecutar LLM en producción
Vincent Wahidi
Cuando los equipos presupuestan una función de AI, calculan el precio del modelo. Tokens de entrada, tokens de salida, una cifra por millar, y la hoja de cálculo parece tranquilizadora. Luego la cosa se lanza, y llegan los costes reales: los que nunca estuvieron en la calculadora de tokens. Ejecutar un modelo de lenguaje en producción no es lo mismo que llamarlo en un prototipo, y la brecha entre los dos es donde se rompen los presupuestos. Vale la pena saber qué hay realmente en esa brecha antes de comprometerse con la hoja de ruta.
El coste visible es el pequeño
El precio por token es de verdad la parte fácil de razonar, y para muchos productos ni siquiera es la partida más grande. Es visible, escala de forma predecible, y se abarata con el tiempo. Si la factura de la API fuera toda la historia, la mayoría de las funciones de AI serían triviales de ejecutar. No es toda la historia, y tratarla como tal es por lo que tantos pilotos parecen baratos y tantos sistemas en producción no lo son.
Los costes que realmente se acumulan
El peso está en todo lo que rodea al modelo. La infraestructura de recuperación para alimentarlo con sus datos, y el trabajo de mantener esos datos frescos e indexados. La evaluación y el monitoreo, porque un modelo que se degrada en silencio es peor que uno que falla de forma ruidosa, y solo sabe cuál tiene si está observando. Las barreras de seguridad y el segundo modelo que comprueba al primero. La revisión humana de los casos de los que el sistema no está seguro, que es un coste de personal, no de software. El mantenimiento de instrucciones y versiones a medida que los modelos cambian bajo usted. La ingeniería de latencia cuando "correcto en diez segundos" no es suficiente. Nada de esto aparece en un prototipo, y todo aparece en producción. Esta es la realidad poco glamorosa detrás de MLOps.
El coste que empequeñece a todos los demás
Hay un coste que puede superar a todos los demás juntos: un resultado erróneo que llega a un cliente o a una decisión. Una cifra alucinada en un informe, una mala respuesta a un cliente, una acción automatizada tomada sobre una premisa falsa. El precio de eso no se mide en tokens o cómputo; se mide en confianza, en repetir el trabajo, y a veces en responsabilidad legal. Un sistema diseñado para ser barato por llamada pero descuidado al equivocarse no es barato, simplemente ha movido su coste más grande fuera de la hoja de cálculo y hacia el negocio.
Por qué los prototipos mienten sobre el coste
Un prototipo se ejecuta con entradas limpias, lo juzga la persona que lo construyó, y nunca tiene que sobrevivir a un mal día. La producción se ejecuta con lo que llegue, la juzgan los clientes, y tiene que manejar las entradas que nadie anticipó. Esa es la misma razón por la que la mayoría de los pilotos de AI no llegan a producción: la versión barata y limpia nunca fue la versión difícil. Presupuestar a partir del prototipo es presupuestar para un sistema que no va a ejecutar.
¿Cómo presupuesta esto antes de construir?
Un método viable es presupuestar en tres capas en lugar de una sola partida. La primera capa es el modelo en sí: tokens, o cómputo si lo autoaloja, estimado a partir de volúmenes realistas y no de volúmenes de demostración. La segunda capa es la maquinaria a su alrededor: la recuperación y su canal de datos, las ejecuciones de evaluación, el monitoreo, las barreras de seguridad, y el tiempo de ingeniería para mantener las instrucciones y adaptarse cuando una versión del modelo cambia bajo usted. La tercera capa son las personas: quién revisa los casos de baja confianza, cuántos al día con su volumen, y qué cuesta eso en tiempo de personal. Si no puede rellenar la tercera capa, eso es el presupuesto diciéndole que el diseño no está terminado, porque todo sistema de LLM en producción tiene una ruta de excepción y alguien tiene que dotarla de personal.
Un ejemplo ilustrativo muestra por qué importan las capas. Un equipo planifica una función de resumen de documentos y la calcula en unos pocos centavos por documento desde la calculadora de tokens. Al volumen de producción, el índice de recuperación que mantiene los resúmenes fundamentados, las ejecuciones de evaluación semanales que detectan la deriva, y la hora diaria de un analista dedicada a revisar los resultados señalados, cada uno cuesta más que la factura de la API. Ninguna de esas partidas es un fallo. Son lo que cuesta "funcionar", y los equipos que las ven en la fase de presupuesto lanzan funciones que sobreviven, mientras que los equipos que las descubren después del lanzamiento suelen archivar la función en silencio.
Cómo es un buen presupuesto
Ponga precio al resultado, no a la llamada. La cifra que importa es el coste por resultado correcto y de confianza, e incluye la recuperación, la evaluación, las barreras de seguridad, la revisión humana, y el mantenimiento que mantiene todo el conjunto honesto. Un equipo que presupuesta así lanza AI que sobrevive al contacto con la realidad. Un equipo que presupuesta para tokens lanza una demostración y hereda una sorpresa. Si está planificando una función de AI y quiere una imagen realista de lo que cuesta ejecutarla en lugar de solo demostrarla, cuéntenos qué está construyendo, y vea cómo lo abordamos bajo software personalizado.

Vincent Wahidi
Autor
Vincent Wahidi is the director of Encelyte, a computer engineer who builds production AI, automation, and custom software for enterprises across Cyprus and the wider region. He writes the strategy, cost and decision-maker pieces himself; the practical how-to guides are curated under the five mission-cat bylines below.
Leer a continuación
Cuándo los agentes de AI de atención al cliente ayudan, y cuándo perjudican
¿Tienes un problema que valga la pena resolver?
Cuéntanos qué estás construyendo o arreglando. Te responderemos en un día laborable con un siguiente paso claro.
