TL;DR
Genie tiene dos costos, y solo uno de ellos es fácil de controlar. Los presupuestos de Unity AI Gateway cubren el lado del uso del LLM. El cómputo que Genie dispara —SQL warehouses y jobs serverless— no tiene un control equivalente ni una etiqueta de Genie en tus datos de facturación. La solución no es un mejor reporte: es darles a los workloads de Genie su propio cómputo y etiquetarlo de forma consistente, para que la atribución venga integrada desde el inicio en lugar de reconstruirse cuando ya llegó la factura.
La optimización de costos de Databricks suele consistir en hacer right-sizing de los clústeres o ajustar las políticas de auto-terminación. Genie añade una complicación que esos playbooks no cubren: un workload que puede disparar cómputo real sin aparecer nunca como una línea que puedas buscar en la factura. En el primer post de esta serie presentamos las cuatro herramientas de Genie y en el segundo vimos cuánto cuesta Genie realmente, incluida una prueba real en la que el uso de IA era fácil de medir y el cómputo no. Este post trata de cerrar esa brecha antes de que te cueste más que un ejercicio de investigación.
Es poco probable que Databricks cierre esta brecha por su cuenta. La mayoría de las respuestas de Genie Agent y la mayoría de las sesiones de Genie Code generan SQL o código y luego lo ejecutan, y para eso existe el cómputo, pero no siempre: un Genie Agent a veces puede responder una pregunta general sin tocar una tabla, y Genie Code suele generar código sin ejecutarlo. Cuando la ejecución sí ocurre, el uso de IA que la generó recibe una etiqueta clara. La ejecución en sí, no. Esa división refleja cómo Databricks diseñó el producto, no un descuido, y significa que la solución también tiene que ser arquitectónica.
¿Por qué no basta con mirar tu factura para ver el costo de Genie?
Databricks etiqueta explícitamente el uso del LLM de Genie. Cada registro incluye billing_origin_product = 'GENIE', así que puedes filtrarlo, agruparlo y sumarlo sin adivinar. El cómputo que Genie dispara no recibe el mismo trato. La factura de un SQL warehouse dice que un warehouse ejecutó consultas; no dice si ese SQL lo escribió una persona o lo generó un Genie Agent.
Gartner predice que para 2027, el 40% de las empresas degradará o retirará a sus agentes autónomos de IA después de que las brechas de gobernanza salgan a la luz solo cuando algo ya falló en producción. La visibilidad de costos es parte de esa misma brecha de gobernanza. Esperar a resolver la atribución hasta que finanzas haga una pregunta que no puedes responder es la forma cara de aprender esta lección.
¿Qué cubre realmente controlar el lado del LLM?
Los presupuestos de Unity AI Gateway —con alcance de cuenta, workspace, grupo de usuarios o usuarios individuales, y etiquetados databricks-product: genie— te dan un control real sobre el gasto en LLM de Genie. Genie One, Agents y Code se miden a través del mismo mecanismo, así que un solo presupuesto cubre toda la familia. Las etiquetas son aditivas: agregar más no rompe el seguimiento, solo te da una vista más granular del mismo gasto de Genie.
Ese es un problema resuelto, y vale la pena decirlo sin rodeos: si solo configuras presupuestos para Genie y te quedas ahí, habrás cubierto quizás la mitad del riesgo. La mitad más grande sigue abierta.
¿Por qué el lado del cómputo es mucho más difícil?
Los Genie Agents ejecutan SQL contra el warehouse al que apuntan, normalmente el mismo que ya usa todo lo demás en el workspace. Genie Code inicia cómputo serverless para ejecutar el código que escribe. Ninguno de los dos recibe una etiqueta específica de Genie por defecto. Si intentas encontrar el costo de cómputo de Genie a posteriori, terminas correlacionando system.billing.usage con system.query.history y system.compute.warehouse_events, tratando de cuadrar timestamps y esperando que nada más estuviera corriendo en ese momento. Eso funciona para una prueba aislada. Se desmorona en cuanto más de un workload toca el mismo warehouse, es decir, en cualquier entorno real.
McKinsey encontró que el 93% de las organizaciones que ejecutan workloads de IA ya superó su presupuesto de IA, y el cómputo sin rastrear contribuye directamente a ese patrón. No se puede gestionar un número que solo se puede reconstruir a posteriori.
Este es exactamente el muro con el que chocamos al probar Genie nosotros mismos. Nuestro ebook, Databricks Genie Explained, recorre la prueba completa, incluida la consulta que usamos para extraer el uso real de DBU de Genie directamente de las tablas de facturación.
¿Cómo haces que el cómputo de Genie sea atribuible?
Dale a Genie su propio cómputo siempre que puedas, en lugar de compartir un warehouse con dashboards, SQL ad hoc y todo lo demás. Un SQL warehouse dedicado para los Genie Agents convierte una pregunta sin respuesta en una sencilla: el warehouse de Genie, multiplicado por su costo por DBU, es igual al costo de SQL relacionado con Genie. Sin correlaciones, sin cuadrar timestamps, sin adivinar.
Etiqueta ese cómputo igual que etiquetarías cualquier otra cosa que necesites rastrear: etiquetas de warehouse consistentes y etiquetas de políticas de presupuesto serverless, aplicadas antes de que el workload se ejecute, no reconstruidas después. La práctica de asignación de la FinOps Foundation trata el etiquetado y las convenciones de nombres a nivel de recurso como el mecanismo base para atribuir costos compartidos o ambiguos, y el cómputo de Genie es exactamente el tipo de costo ambiguo que esa práctica existe para resolver. El cómputo dedicado aísla el workload; las etiquetas lo identifican. Necesitas ambos, no uno en lugar del otro.
No todos los Agents necesitan su propio warehouse. Reserva eso para los de alto volumen o críticos para el negocio, donde la visibilidad de costos realmente importa, y deja que los Agents más pequeños y ocasionales compartan espacio hasta que se ganen un warehouse dedicado con su propio uso.
¿Y qué pasa específicamente con Genie Code?
Genie Code es más difícil de aislar que los Genie Agents, porque parte de su ejecución corre en cómputo serverless y no en un warehouse que tú aprovisionas y nombras. No puedes simplemente apuntarlo a un warehouse dedicado de la misma forma. Aquí pesan más la atribución por usuario, las políticas de presupuesto serverless y las etiquetas consistentes. Debes saber qué usuario o service principal está ejecutando Genie Code, aplicar una política de presupuesto con ese alcance y etiquetar los jobs serverless que inicia, para que aparezcan como cómputo de Genie y no como una línea anónima.
¿Cómo se ve todo esto una vez configurado?
Un warehouse dedicado para Genie, etiquetado y aislado, convierte una pregunta que antes requería una consulta de correlación en algo que respondes leyendo un dashboard. Esa es precisamente la idea. No se trata de construir un reporte más inteligente a posteriori, sino de cambiar dónde corre el workload para que la factura ya refleje la respuesta. En lugar de cruzar system.billing.usage con el historial de consultas y los eventos del warehouse cada vez que alguien pregunta cuánto cuesta Genie, filtras por una etiqueta de warehouse y lees el número directamente.
Lo mismo aplica para Genie Code: cuando los jobs serverless llevan una etiqueta consistente y un responsable conocido, "cuánto nos está costando Genie Code" deja de ser una pregunta de investigación y se convierte en un filtro. Ninguna de estas soluciones toca el lado del LLM, y justamente de eso se trata: los presupuestos de Genie ya lo tienen cubierto. El objetivo es únicamente que la otra mitad sea igual de fácil de ver.
Una plataforma como SELECT for Databricks está construida exactamente para este tipo de conciliación: cruza los cargos de DBU con el costo de la infraestructura de nube subyacente, para que el lado del cómputo de Genie no tenga que armarse manualmente cada vez que alguien pregunta por él.
¿Qué deberías hacer, y en qué orden?
Empieza por el presupuesto. Configura un presupuesto de Unity AI Gateway para el uso del LLM de Genie, etiquetado databricks-product: genie y nada más, con un umbral de alerta compartido y umbrales por usuario para quienes lo usen de forma inusualmente intensiva. Las alertas son mejores que un bloqueo duro: agotar un presupuesto compartido detiene Genie para todos los que están dentro del alcance, no solo para quien lo provocó.
Luego resuelve el lado del cómputo. Dale a tus Genie Agents de mayor volumen o más críticos para el negocio un SQL warehouse dedicado. Etiqueta ese warehouse y cualquier política de presupuesto serverless vinculada a Genie Code de forma consistente, antes de que el uso crezca más allá de un puñado de usuarios piloto. Vigila los service principals por separado: no reciben cuota gratuita en ningún producto de Genie y su uso escala de formas en que no lo hace una persona haciendo clic en una interfaz de chat.
Nada de esto es exclusivo de Genie. Es la misma disciplina que ya exige una buena optimización de costos de Databricks: cómputo con right-sizing, etiquetas consistentes y workloads que no se esconden unos dentro de otros. Genie solo añade una fuente más de demanda a la que apuntar esa disciplina.
¿Quieres el resto de la historia: qué es Genie realmente, cuánto cuesta una sesión real y cómo mantenerlo atribuible? Encuentra las tres respuestas en un solo lugar en nuestro ebook, Databricks Genie Explained.
Preguntas frecuentes
¿Qué es la optimización de costos de Databricks Genie?
Es la práctica de hacer visible y controlable el gasto de Genie —tanto su uso de LLM como el cómputo que dispara— en lugar de reconstruirlo después de que llegue la factura. Eso implica presupuestos de Unity AI Gateway para el uso del LLM y cómputo dedicado y etiquetado para el SQL y los jobs serverless que Genie inicia.
¿Los presupuestos de Genie controlan los costos de cómputo?
No. Los presupuestos de Unity AI Gateway, etiquetados databricks-product: genie, solo cubren el uso del LLM. El SQL warehouse y el cómputo serverless que Genie dispara se facturan por separado y necesitan su propio cómputo dedicado y etiquetado para seguir siendo atribuibles.
¿Por qué los Genie Agents deberían tener un SQL warehouse dedicado?
Porque un warehouse compartido mezcla las consultas de Genie con todo lo demás que corre en él, así que la factura no puede decirte qué parte vino de Genie. Un warehouse dedicado lo convierte en un cálculo directo: el costo en DBU del warehouse es el costo de Genie, sin nada que reconstruir.
¿Genie Code es más difícil de atribuir que los Genie Agents?
Sí. Genie Code corre en cómputo serverless y no en un warehouse que aprovisionas tú mismo, así que no se puede aislar de la misma manera. Para Genie Code pesan más la atribución por usuario, las políticas de presupuesto serverless y el etiquetado consistente que el cómputo dedicado.
¿Cómo ayuda SELECT for Databricks con la optimización de costos de Genie?
Concilia los cargos de DBU de Databricks con el costo de la infraestructura de nube subyacente en un solo lugar, lo que aborda el mismo problema que resuelven el cómputo dedicado y el etiquetado de Genie: hacer que un gasto normalmente invisible en los datos de facturación estándar sea atribuible al workload que lo causó.