Los costos de infraestructura para IA en las empresas Global 1000 se proyectan que serán un 30% más altos que los presupuestos actuales para 2027, según IDC. Esa brecha revela una desalineación entre cómo se comportan las cargas de trabajo de IA en producción y cómo la TI empresarial ha planificado históricamente la capacidad. Este patrón se repite en múltiples industrias: un piloto valida un modelo en un conjunto de datos controlado y se crean presupuestos en torno a esa economía. Pero cuando el sistema pasa a producción, la factura suele superar con creces lo que se modeló originalmente.

La tendencia natural es señalar el tamaño del modelo o el costo de los tokens, pero ese no es el principal culpable. El gasto reside en la capa de datos, impulsado por la frecuencia de lectura, cuántos servicios se tocan y cuán continuamente operan esas acciones.

Qué no muestran los pilotos
Un piloto se ejecuta contra un conjunto de datos estrecho, con unos pocos usuarios concurrentes y una cadencia de solicitud-respuesta familiar para una aplicación web. La producción es muy distinta.

Pensemos en un agente de soporte al cliente de IA en producción. Una sola solicitud de usuario puede activar búsquedas simultáneas a través de actividad de sesión, registros CRM, sistemas de inventario, manuales recuperados y otras fuentes, antes de que el modelo genere una respuesta. Todo esto ocurre bajo presupuestos de latencia de sub-100 ms, y la búsqueda más lenta regula el resto. El problema operativo se convierte en la latencia en cola (tail latency) entre muchas búsquedas pequeñas en paralelo.

Luego se añaden flujos de trabajo agentivos. Una solicitud de usuario se descompone en un plan y luego en una serie de pasos que emiten sus propias búsquedas, escriben estados intermedios y los leen de nuevo. Lo que empieza como una inferencia se expande a decenas o cientos de accesos a datos, con la sesión y el estado de la memoria mantenidos a lo largo de todo el recorrido. El perfil de costos que emerge no se parece en nada a lo que se tasó en el piloto.

De dónde sale el 30% de sobrecosto
La sobrecarga proviene de una serie de decisiones defensivas tomadas ante la incertidumbre. Cuando los equipos no pueden ver cómo fluyen los datos en una única solicitud, sobreprovisionan para absorber picos. Cuando no pueden predecir el comportamiento de caché bajo contexto cambiante, duplican datos entre sistemas para reducir riesgos de dependencia.

Si un servicio downstream se ralentiza, se añade otro servicio para aislarlo. Cada decisión tiene sentido de forma local. En conjunto, se genera un sistema que cuesta un 30% más que la carga de trabajo real, y eso antes de añadir cualquier nuevo caso de uso.

Los problemas subyacentes suelen ser los mismos. El fan-out por solicitud no se mide de extremo a extremo. El contexto se fragmenta a través de tiendas de características, sesiones, sistemas de perfiles de usuarios, índices vectoriales y APIs de terceros. Las cachés KV y el reuso de prefijos quedan fuera de la cuenta porque la capa de inferencia no puede mantener o compartir estado entre llamadas. Las decisiones de replicación y jerarquía se toman por sistema, no por patrón de acceso. Todo ello no aparece en un piloto: aparece en la factura de producción.

Qué debe entregar la capa de datos de IA
La IA en producción es un sistema distribuido y continuo cuyo camino más activo es la construcción del contexto: muchos lectos pequeños por solicitud bajo presupuestos de baja latencia, combinados con escrituras que deben mantener representaciones múltiples del mismo ente consistentes. Estas arquitecturas requieren dos cosas al mismo tiempo: lecturas de baja latencia previsibles bajo alta concurrencia y escrituras consistentes a lo largo de la ruta de datos. La infraestructura subyacente tiene que dimensionarse y formarse en consecuencia.

Decisiones arquitectónicas que empujan el resultado
– Emparejar la capa de datos con el patrón de acceso: estados de sesión, memoria de agentes, búsquedas de características, contexto recuperado y reutilización de caché KV presentan diferentes patrones de lectura, requisitos de frescura y necesidades de durabilidad. Tomarlas como capas de datos diferentes o colocarlas sobre la misma base de datos sin considerar estos patrones es una fuente común de sobrecosto. La tienda de sesión y el sistema de registro difieren en demandas de acceso de la misma capa de datos.
– Diseñar para fan-out y latencia tail predecible: el rendimiento (throughput) no debe ser la métrica principal para una capa de datos de IA. La métrica adecuada es la predictibilidad de múltiples lecturas pequeñas disparadas por una única solicitud. Un lote de búsquedas en paralelo solo es tan rápido como su miembro más lento; una búsqueda lenta detiene toda la construcción del contexto.
– Tratar la consistencia de escrituras como un requisito de corrección: cuando las actualizaciones entre perfiles de usuario, embeddings, vectores de características y estado de sesión no están sincronizadas, las lecturas de contexto subsequentemente obtienen versiones mezcladas y el modelo genera salidas basadas en datos contradictorios. Esto provoca alucinaciones que no tienen que ver con muestreo o probabilidad de modelo, y no se corrigen con prompts más grandes.
– Reutilización de datos en tiempo de inferencia como infraestructura: reutilizar caché KV, compartir prefijos y persistencia de memoria de agente deben ser consideraciones de infraestructura de primer nivel. Las equipos que lo abordan temprano pueden ejecutar las mismas cargas de trabajo con menor utilización de GPU que quienes no lo hacen. Este es el mayor punto de apalancamiento que no suele aparecer en la mayoría de los modelos de costos de IA.

Cómo empezar
El paso más útil es trazar una única solicitud de producción de extremo a extremo: contar las lecturas, registrar las fuentes y medir las latencias en cola. Este ejercicio revela más que una revisión arquitectónica. Una vez que los equipos ven cómo se mueven los datos en una interacción, pueden categorizar los accesos a datos por capa y verificar que cada uno funcione sobre infraestructuras adecuadas a su patrón.

A partir de ahí, la pregunta siguiente es qué se está recomputando y podría reutilizarse, especialmente entre llamadas de inferencia y pasos agentivos. El fan-out por interacción debería convertirse en una métrica que se observe tan de cerca como la latencia p99, porque a escala impulsa el costo con la misma claridad.

El costo de IA en producción es una disciplina de diseño. Los equipos que abordan este tema temprano tienen mucho más control sobre el rendimiento y el gasto que los que esperan a que la factura obligue a actuar. En muchos casos, la brecha del 30% es el costo de aprender estas lecciones demasiado tarde.

Notas finales
– Este análisis subraya la importancia de tratar la capa de datos como la clave para gestionar costos y rendimiento en IA en producción.
– Las decisiones de diseño deben centrarse en patrones de acceso y en la coherencia de datos a lo largo de todo el flujo de trabajo, no solo en el rendimiento aislado de un modelo.
– Trazar y medir de extremo a extremo una interacción real se revela como la herramienta más poderosa para evitar sorpresas en la factura y para lograr una IA más eficiente y confiable en producción.

Este artículo forma parte de TechRadar Pro Perspectives, que reúne a las mentes más brillantes de la industria tecnológica para compartir ideas y experiencias relevantes.

from Latest from TechRadar https://ift.tt/Xl8wRyW
via IFTTT IA