• 6 min de lectura
Databricks redujo los costes de codificación con IA en un 70%
Databricks afirma que enrutar, usar modelos más baratos, cachear y controlar el gasto redujo sus costes de codificación con IA en un 70% sin imponer límites estrictos de uso.
Imagen: Hacker News
Databricks dice que redujo su gasto en codificación con IA en un 70% mientras seguía ofreciendo a los desarrolladores un acceso amplio a agentes de codificación. La explicación de la compañía apunta a una parte menos glamurosa pero cada vez más importante de la IA empresarial: enrutar solicitudes, controlar el crecimiento del contexto y hacer visibles los costes de los modelos sin simplemente cortar el acceso a los usuarios.
La empresa afirma que la codificación basada en agentes ha mejorado todas las métricas de velocidad que rastrean y ha producido aumentos de salida por órdenes de magnitud en algunos equipos. Pero el uso sin restricciones también creó una curva de coste insostenible. Databricks explica que su enfoque se moldeó por su propia experiencia y conversaciones con equipos de Stripe, Coinbase, Uber y Ramp.
Elegir modelos en una frontera de eficiencia
El argumento central de Databricks es que las empresas deberían optimizar para una frontera de eficiencia, no simplemente para el modelo más inteligente disponible. La pregunta relevante para la ingeniería de software rutinaria es qué modelo ofrece la calidad requerida al menor precio, no qué modelo lidera en problemas difíciles de matemáticas o ciberseguridad.
La compañía afirma que esta frontera avanza más rápido que la inteligencia máxima de los modelos, con nuevas versiones que llegan casi semanalmente y que ofrecen más inteligencia por unidad de coste. Evaluar y adoptar rápidamente esos modelos se describe como la palanca de coste más importante disponible.
Databricks sostiene que los benchmarks públicos no son suficientes para esa decisión, porque a menudo no representan la carga de trabajo real de desarrollo de una empresa. Por eso los equipos construyen evaluaciones internas. Databricks dice que una de esas evaluaciones mostró un rendimiento coste-efectivo competitivo de los modelos GLM, lo que impulsó un despliegue interno.
Recomendado
Rippling creó una herramienta para controlar su factura de IA desbocada
Las evaluaciones también pueden evitar actualizaciones costosas. Stripe descubrió que Opus 4.7 no mejoraba de forma significativa la calidad respecto a Opus 4.6 mientras aumentaba el coste, y rechazó ofrecer el modelo más nuevo internamente. Databricks reporta una regresión de coste similar al comparar Opus 5.0 con 4.8.
Meta-arneses y enrutamiento de modelos
Cambiar de modelos es difícil cuando los desarrolladores están ligados a un arnés de codificación particular. Databricks nombra a Claude Code, Codex y Cursor como ejemplos de herramientas entre las que los usuarios podrían necesitar cambiar. Esa fricción puede convertir el arnés en una forma de encierro en torno a una familia de modelos.
Un meta-arnés ofrece una interfaz común mientras despacha el trabajo a distintos arneses y modelos subyacentes. Databricks usa su meta-arnés Omnigent, de código abierto, como modo predeterminado para los desarrolladores que lo utilizan. La compañía también dice que otras organizaciones han construido sistemas internos similares.
Databricks describe tres patrones de enrutamiento:
- Enrutamiento a nivel de solicitud: Un proxy con estado envía cada petición de inferencia al modelo menos caro capaz de gestionarla, teniendo en cuenta el cacheo del lado del servidor y el alto coste de aciertos en cache frío con contextos grandes. Se citan ejemplos como Cursor Router, AutoRouter de OpenRouter, Router de Ramp y el Smart Routing de Databricks en Unity AI Gateway.
- Enrutamiento a nivel de tarea: Un meta-arnés clasifica una tarea completa—por ejemplo, un simple cambio de nombre frente a una investigación abierta sobre latencias—y la asigna a un arnés y modelo adecuados.
- Escalada o delegación: Un modelo gestiona el flujo de trabajo principal y recurre a un modelo más barato o más capaz cuando es necesario. Databricks cita la Advisor Tool de Claude y Devin Fusion de Cognition como ejemplos de versiones opuestas de este patrón.
Databricks afirma que los resultados internos muestran que su Smart Router reduce el coste medio por tarea en más del 30% mientras iguala aproximadamente la calidad del modelo más caro en su conjunto de trabajo.
Presupuestos sin cortar a los desarrolladores
Databricks sostiene que los límites rígidos mensuales de tokens son un mal valor por defecto. Cortar el acceso cuando un desarrollador alcanza un límite puede dañar la productividad, mientras que algunos usuarios con gasto elevado pueden estar generando también cantidades excepcionales de salida útil.
En su lugar, las empresas encuestadas usan controles escalonados:
- Visibilidad: Los desarrolladores reciben retroalimentación casi instantánea sobre el gasto en sus herramientas de IA, con frecuencia acompañada de orientación sobre el uso de modelos más baratos.
- Puertas de gasto: Los usuarios ven advertencias o deben obtener aprobación a medida que el gasto atraviesa umbrales definidos. Databricks dice que las puertas que se autoautorizan ayudan a prevenir picos accidentales.
- Degradación de servicio: Los usuarios que cruzan un umbral pueden ser trasladados a un modelo más barato en lugar de perder totalmente el acceso.
- Suspensión: La suspensión completa sigue disponible como último recurso temporal.
El contexto es un coste oculto importante
Una petición corta de un desarrollador puede disparar búsquedas extensas en la base de código, llamadas a herramientas, instrucciones del sistema y contexto acumulado. Databricks afirma que el prompt original del usuario a menudo representa solo una porción despreciable de los datos que se envían finalmente para inferencia.
La compañía lista varias maneras de reducir ese overhead: compactar el contexto activo con más frecuencia, usar arneses menos habladores, reducir la verbosidad en las herramientas y dividir grandes tareas en unidades más pequeñas. El cacheo de prompts también puede bajar el coste de contextos grandes repetidos, aunque las escrituras en caché siguen teniendo coste y los mejores ajustes dependen de la carga de trabajo.
Databricks afirma que simples cambios en el arnés y en el cacheo redujeron los tokens generados y los costes asociados en casi un 50%, sin observar degradación en la calidad del desarrollador.
La respuesta propuesta es un AI Gateway: una capa central para el acceso a modelos, gestión de capacidad, mezcla de modelos, seguimiento de presupuestos, aplicación de políticas y observación o compresión del contexto generado por herramientas. Databricks dice que ha publicado como código abierto o puesto a disposición de forma gratuita Omnigent y Unity AI Gateway.
El informe no establece el periodo de tiempo, el gasto base ni la metodología detrás de la reducción titular del 70%; las cifras de ahorro en la publicación se describen como indicativas, basadas en parte en una encuesta informal. Esa laguna importa, pero la posición subyacente es clara: para despliegues grandes de agentes de codificación, el control de costes tiene menos que ver con restringir el acceso y más con construir la infraestructura para mover el trabajo a modelos más baratos y eliminar el contexto desperdiciado.
Enterprise Editor
Marcus follows the money. He covers enterprise software, cloud architecture, and the tectonic shifts in Big Tech strategy. He translates dense earnings calls and complex M&A activity into actionable insights about where the industry is actually heading. If a tech giant makes a silent pivot, Marcus is usually the first to notice.
vía Hacker News
