Gestión de costos de codificación con AI a escala

Las herramientas de codificación de AI aportan un valor inmenso: en Databricks, la codificación agéntica ha mejorado de forma medible cada métrica de velocidad que registramos y, en algunos equipos, ha generado un aumento de rendimiento de un orden de magnitud. Sin embargo, casi todas las empresas que implementan herramientas de AI a escala se han topado con el mismo obstáculo: costos que crecen de forma exponencial. Esa curva es insostenible: si no se controla, con el tiempo superará los ingresos. La explosión del gasto ha dejado a las empresas en una situación paradójica: por un lado, desean impulsar al máximo la transformación de la AI y poner herramientas potentes en manos de los empleados, y, por el otro, tienen que lidiar con un perfil de costos acumulados que amenaza con debilitar o incluso revertir las ganancias de eficiencia que proporciona la AI.

Afortunadamente, varios de los primeros adoptantes a gran escala han coincidido en un conjunto de enfoques que resuelven este dilema, logrando un “mandato doble”: (a) proporcionar un acceso amplio a las herramientas de AI, con la menor fricción posible, y (b) mantener los costos acumulados dentro de un límite aproximadamente fijo por usuario. Este artículo describe técnicas probadas de gestión de costos, basadas en nuestra experiencia en Databricks y en conversaciones con varias otras empresas nativas digitales, como Stripe, Coinbase, Uber y Ramp. La siguiente tabla resume las técnicas actuales y los ahorros asociados; las cifras son orientativas y se basan en una encuesta informal a equipos de desarrollo:

Algunas de estas técnicas se pueden implementar fácilmente con software que muchas empresas ya utilizan. Otras requieren una nueva infraestructura, en particular las técnicas que modifican los clientes de usuario final o desvían el tráfico entre modelos. En Databricks, hemos publicado como código abierto o puesto a disposición de forma gratuita nuestros componentes clave de infraestructura: un meta-harness de usuario final (Omnigent) y nuestro AI Gateway (Unity AI Gateway). Para que esté completo, este artículo también cubre el software utilizado por otras empresas con las que hablamos.

La “frontera de eficiencia” para los modelos de codificación

La mayor palanca de costos consiste en trasladar el gasto de codificación a modelos más eficientes a medida que se lanzan. Este punto merece cierta discusión, ya que la simple explicación de "modelos más baratos" oculta en realidad una relación llena de matices entre el costo y la calidad del modelo.

Coloquialmente, el término modelo de frontera significa “el modelo de mayor inteligencia”, y los laboratorios de frontera se centran principalmente en avanzar en la inteligencia máxima. Los modelos de frontera ahora pueden resolver problemas novedosos en matemáticas o ciberseguridad. Sin embargo, cuando la AI se implementa a escala, importa más otro tipo de frontera: la frontera de eficiencia. La frontera de eficiencia se define por el conjunto de modelos que tienen el mejor precio para un nivel de inteligencia determinado. La mayor parte de la codificación diaria no requiere demostraciones matemáticas ni conocimientos novedosos de seguridad, por lo que lo que importa en conjunto es el costo de los modelos que cumplen con el estándar de calidad para el trabajo típico de ingeniería de software. Esta "frontera de eficiencia" avanza mucho más rápido que la frontera de inteligencia, con nuevos modelos que se lanzan casi semanalmente y que presentan una mejor relación inteligencia-precio que los modelos anteriores.

Palanca de costos n.º 1: Migrar a modelos de código abierto y de menor costo

La adopción rápida de modelos más nuevos y eficientes ofrece la mayor reducción de costos de cualquier técnica. Pero para aprovechar esas ganancias, una empresa primero debe saber qué modelos superan realmente a los que ya utiliza. Esto puede ser difícil porque las evaluaciones de referencia públicas no reflejan bien el rendimiento en el mundo real en tareas de codificación. Para evaluar los nuevos modelos, muchas empresas han creado evaluaciones automatizadas que consideran más representativas de su combinación de desarrollo interno. Databricks publicó recientemente un ejemplo de dicha evaluación de referencia, en el que observamos una relación precio-rendimiento altamente competitiva para los modelos GLM. Esa evaluación de referencia nos llevó a implementar GLM para los desarrolladores de forma interna. A menudo, los nuevos modelos no avanzan en la frontera de eficiencia y las evaluaciones suelen producir resultados negativos: Stripe descubrió que Opus 4.7 no mejoraba significativamente la calidad con respecto a Opus 4.6, al tiempo que aumentaba el costo. Por lo tanto, optaron por no poner Opus 4.7 a disposición de sus empleados internamente. Databricks observó regresiones de costos similares al comparar Opus 5.0 con 4.8.

Flexibilidad de modelos y de harness

Dado que las mayores ventajas provienen del cambio a nuevos modelos, la adopción de herramientas de usuario final que permitan la flexibilidad de modelos se está convirtiendo en un componente crítico para mantener bajos los costos. La herramienta que se utiliza con más frecuencia en relación con un modelo específico se denomina harness. Los modelos de frontera patentados se co-diseñan cada vez más para funcionar bien con harnesses específicos, lo que significa que ciertos harnesses “funcionan mejor” con ciertos modelos. Si una empresa desea preservar la independencia del modelo, existen aproximadamente dos enfoques:

Pedir a los usuarios que cambien de harness. Un enfoque consiste en proporcionar a los desarrolladores un conjunto de harnesses (Claude Code, Codex o Cursor) y luego pedirles que cambien de uno a otro cuando la empresa desee migrar el gasto a modelos de menor costo. Esto permite a los usuarios trabajar en su harness preferido cuando sea posible, pero la desventaja de este enfoque es que los costos de cambio para un desarrollador individual pueden ser altos. Si los costos de cambio se vuelven demasiado altos, el propio harness se convierte de facto en una dependencia cautiva de una familia de modelos, lo que limita la capacidad de trasladar el gasto a modelos más competitivos.

Usar un meta-harness. Un enfoque nuevo y cada vez más popular consiste en utilizar un meta-harness que ofrezca una experiencia de usuario común a los desarrolladores mientras distribuye las solicitudes a los harnesses subyacentes (tanto patentados como de código abierto). En Databricks, este es el modo predeterminado para los desarrolladores que aprovechan Omnigent. Algunas empresas con las que hablamos han creado meta-harnesses internos personalizados que se integran con su cadena de herramientas de desarrollo.

Palanca de costos n.º 2: Enrutamiento dinámico de solicitudes y tareas

En lugar de pedir a los usuarios que elijan ellos mismos los modelos adecuados para cada tarea, un número creciente de investigaciones sugiere que la selección automática de modelos y herramientas puede mejorar aún más la eficiencia de los flujos de trabajo de codificación agéntica. Los enfoques de enrutamiento se dividen a grandes rasgos en tres categorías:

• Enrutamiento a nivel de solicitud: Un proxy con estado se sitúa entre un cliente (como un harness de codificación) y los modelos fundacionales subyacentes. El proxy intenta enrutar las solicitudes al modelo de menor costo capaz de responder a cada solicitud de inferencia. El enrutamiento para casos de uso agénticos también debe tener en cuenta el almacenamiento en caché del lado del servidor, ya que un acierto de caché en frío tiene un costo muy alto para cargas de trabajo con contextos grandes. Una nueva ola de productos está mostrando resultados iniciales prometedores para el enrutamiento. Algunos ejemplos son: Cursor Router, AutoRouter de OpenRouter, la función de enrutador de Ramp y la propia función Smart Routing de Databricks en Unity AI Gateway.
• Enrutamiento a nivel de tarea (Meta-Harness): Un proceso del lado del cliente distribuye las tareas del usuario a diferentes harnesses según la complejidad de la tarea. Una tarea de usuario podría ser “cambiar el nombre de este componente de X a Y” (una tarea sencilla) o una tarea abierta como “Explorar consideraciones de diseño que reducirían la latencia” (una tarea compleja). El distribuidor, a menudo llamado Meta-Harness, examina qué nivel de modelo subyacente se requiere para una tarea y luego delega toda esa tarea de extremo a extremo al modelo. Omnigent es un ejemplo de un Meta-Harness que admite este patrón.
• Patrones de escalación/delegación: Un solo harness empareja dos modelos (un modelo costoso de alta inteligencia y un modelo de trabajo económico). En algunos enfoques, como la herramienta Advisor Tool de Claude, el modelo más económico dirige el proceso y escala la tarea cuando considera que requiere más potencia. También existe el patrón inverso: en Devin Fusion de Cognition, el modelo de mayor costo es el bucle principal y subcontrata de forma selectiva el trabajo a un modelo más económico.
  Los resultados internos en Databricks sugieren que nuestro Smart Router de AI Gateway es capaz de reducir de manera constante el costo promedio de las tareas en más de un 30 %, al tiempo que iguala aproximadamente la calidad del modelo más costoso del conjunto de trabajo. Otras empresas con las que hablamos han obtenido resultados similares.

Palanca de costos n.º 3: Ofrecer visibilidad, alertas y presupuestos a los desarrolladores

Puede resultar sorprendente que todo este artículo no haya empezado y terminado con "Asigna a los usuarios un presupuesto mensual y listo". Los presupuestos estrictos, en los que el uso se interrumpe por completo al alcanzar un umbral de gasto específico, suelen utilizarse solo como último recurso en todas las empresas con las que hablamos. Hay dos razones por las que los presupuestos estrictos de tokens no son especialmente eficaces para la gestión del gasto en AI: En primer lugar, si un desarrollador alcanza su límite presupuestario, cortarle el acceso a las herramientas de AI afectaría gravemente a su productividad. Ni la empresa ni el empleado desean realmente ese resultado. En segundo lugar, al menos algunos de los usuarios con "gasto elevado" son, de hecho, aquellos que han logrado un aumento monumental de la eficiencia con la AI y están generando un rendimiento inmenso. Desincentivar a esos usuarios es contraproducente.

En lugar de un límite estricto de gasto por usuario, la mayoría de las empresas están adoptando un enfoque más matizado y progresivo que se centra en la visibilidad para los usuarios finales y en un aumento gradual de la fricción a medida que se incrementa el gasto.

1. Visibilidad: Todas las empresas con las que hablamos disponían de un mecanismo para ofrecer información casi instantánea a los usuarios sobre su gasto acumulado, y muchas de ellas también ofrecían consejos o recomendaciones específicas sobre cómo reducir el gasto utilizando modelos menos costosos. Es importante que los usuarios puedan ver su gasto en todas las herramientas, ya que es posible que deseen priorizar la elección de la herramienta con la que obtengan el mayor ROI.

   

   Un panel de desarrollador en Databricks que muestra el gasto activo

2. Controles de gasto: Se puede solicitar a los desarrolladores que realicen acciones o soliciten aprobaciones a medida que aumenten los niveles de gasto. La forma más sencilla de control de gasto es aquella que el propio usuario puede desbloquear por sí mismo y sirve como advertencia de que el ritmo de gasto está superando cierto umbral. En Databricks, hemos comprobado que los controles de autodesbloqueo son un mecanismo útil para evitar gastos accidentales o involuntarios. Se pueden introducir controles adicionales que requieran una aprobación presupuestaria explícita (a menudo a través de una cadena de gestión).
3. Reducción de nivel: Si un desarrollador ha alcanzado un control de gasto, se le puede transferir a un modelo de menor costo en lugar de suspender por completo su acceso a los tokens. Dado que los modelos de menor costo son drásticamente más económicos que los modelos de inteligencia de vanguardia, esta técnica permite a los desarrolladores seguir trabajando sin incurrir en un gasto continuo masivo.
4. Suspensión: En casos extremos, la mayoría de los sistemas conservan la capacidad de suspender por completo el acceso de los usuarios a todos los tokens. Como se mencionó anteriormente, esto suele ser solo una medida temporal y el punto de partida para una conversación sobre cómo aprovechar la AI de manera eficiente.

Palanca de costos n.º 4: Reducción del exceso de tokens

Cuando un usuario escribe una solicitud relativamente sencilla en un agente de codificación de AI (como "Investiga y corrige este error"), ese agente recopila posteriormente una cantidad enorme de contexto relevante, invoca una gran cantidad de herramientas, busca en la base de código e integra habilidades o información del sistema proporcionada por la empresa. Para cuando se produce la costosa inferencia del LLM, la declaración inicial del usuario representa solo una fracción insignificante de los datos introducidos en el sistema de AI, lo que significa que los costos están dominados por el contexto que el usuario no incluyó explícitamente. Las técnicas para reducir la saturación del contexto aún son nuevas, pero se están explorando varios enfoques prometedores, como:

• Forzar una compactación (compresión) más frecuente del contexto activo.
• Utilizar harnesses que sean "menos redundantes" (más eficientes en el uso de tokens) o ajustar los harnesses existentes para generar un menor exceso de tokens.
• Auditar las herramientas populares y disminuir su nivel de detalle (verbosidad).
• Animar a los desarrolladores a dividir las tareas en unidades de trabajo individuales más pequeñas, reduciendo el alcance del contexto.

Cuando los contextos se vuelven grandes, el almacenamiento en caché de prompts también desempeña un papel importante en el rendimiento general. Tanto los LLM propietarios como los de código abierto tienen configuraciones que permiten habilitar el almacenamiento en caché de prompts y ajustar cuánto tiempo se almacena la caché. Las escrituras en caché cuestan dinero, pero las lecturas almacenadas en caché pueden reducir drásticamente el costo por inferencia. Este equilibrio depende de la carga de trabajo específica de la empresa, por lo que el ajuste manual de la configuración de caché predeterminada para aumentar la tasa general de aciertos de caché puede aportar mejoras drásticas al costo total.

At Databricks, un ajuste relativamente sencillo de nuestra configuración de harness y almacenamiento en caché condujo a una reducción de casi el 50% en la cantidad de tokens generados y los costos asociados, sin que se observara una degradación de la calidad para los desarrolladores. Seguimos explorando técnicas en esta área y creemos que aún es posible realizar optimizaciones adicionales significativas.

Una reducción drástica de los tokens por sesión al eliminar llamadas de inferencia innecesarias y reducir las escrituras en caché.

El patrón de diseño AI Gateway

Las técnicas anteriores presentaban muchos requisitos técnicos implícitos: para aprovechar rápidamente los nuevos modelos, las empresas deben disponer de una ubicación centralizada donde se gestione el "menú de modelos", y los usuarios finales deben contar con una cadena de herramientas que admita la combinación de modelos. Para ofrecer visibilidad presupuestaria en múltiples herramientas de AI, debe existir una capacidad unificada de observabilidad de costos. Para gestionar la saturación del contexto, las empresas necesitan una forma de observar los resultados típicos de las llamadas a herramientas y aplicar la compresión o compactación. Estas necesidades se están resolviendo de forma colectiva mediante una nueva clase de software de infraestructura, que se describe mejor como un AI Gateway. Un AI gateway es una ubicación central donde ocurre todo lo siguiente:

1. Gestión de capacidad y proxy de acceso a los modelos subyacentes (tanto modelos propietarios como OSS).
2. Seguimiento y aplicación de presupuestos, incluidas políticas presupuestarias complejas, como niveles progresivos de fricción y reducción de nivel de los modelos.
3. Gestión de la configuración para las herramientas del usuario final, para aplicar listas de permitidos de modelos, ajustes de compactación y otros aspectos gestionados localmente.
4. Registro de trazas de sesiones de codificación para análisis de eficiencia y evaluaciones comparativas posteriores.

En Databricks, dependemos en gran medida de Unity AI Gateway para todas estas capacidades.

En resumen

El crecimiento exponencial de los costos de codificación con AI no es inevitable; es un problema de ingeniería y gobernanza que tiene solución. Las empresas que lo han controlado comparten una estrategia común: buscar incansablemente la frontera de la eficiencia en lugar de la frontera de la inteligencia, adoptar herramientas que preserven la flexibilidad de los modelos, dirigir el trabajo de forma inteligente al modelo capaz más económico, sustituir los presupuestos estrictos por visibilidad y fricción progresiva, y reducir el exceso de tokens que domina el gasto en el mundo real. Ninguna de estas técnicas requiere sacrificar los aumentos de productividad que hicieron que valiera la pena adoptar la AI en primer lugar; juntas, permiten a las organizaciones cumplir con el doble mandato de ofrecer un acceso amplio y con baja fricción dentro de un marco de costos predecible.

Está surgiendo un conjunto de nuevas abstracciones de infraestructura para ofrecer a las empresas las herramientas necesarias para gestionar sus costos. En Databricks, hemos lanzado los componentes clave de nuestra pila de gestión de costos como productos de código abierto o software libre: nuestro Unity AI Gateway para la gestión centralizada y Omnigent para herramientas de desarrollo. Miles de empresas utilizan estos componentes todos los días. Invitamos a más empresas a compartir sus hallazgos y comparar técnicas a medida que este panorama tecnológico evoluciona rápidamente.

Agradecimientos: Gracias a los líderes de infraestructura de Uber, Stripe, Coinbase y Ramp que aportaron comentarios y revisiones para este artículo. Gracias a Thrive Capital por sus comentarios sobre un borrador inicial de este artículo.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original