Aprende a configurar un spend cap en Cloud Billing Budgets, qué servicios cubre, cómo se reinicia cada mes y qué límites debes conocer antes de fiarte.
Google Cloud ha declarado disponibles de forma general los spend caps en Cloud Billing Budgets. La idea es sencilla: cuando el gasto estimado de un servicio en un proyecto alcanza el presupuesto mensual, se bloquean las peticiones nuevas, pero no se borra nada. Es una defensa pensada para bucles de agentes o modelos que se desbocan.
En esta guía repasamos cómo plantear el tope, qué cubre y qué no, y cómo automatizarlo. Nos apoyamos en la documentación oficial y en la cobertura de InfoQ. No hemos inventado ningún comando: donde conviene, remitimos a la referencia de la API.
Lo que necesitas
- Un proyecto de Google Cloud con facturación activa y permisos de administrador de facturación o propietario del proyecto.
- Un servicio compatible en ese proyecto: Gemini API, Gemini Enterprise Agent Platform, Cloud Run o Cloud Run functions.
- Una cifra mensual máxima, calculada a precio de lista, y un margen de seguridad por debajo de tu límite real.
- Opcional: acceso a la Budgets API si quieres crear topes al provisionar proyectos.

Configurar el tope paso a paso
- Abre la página de Presupuestos y alertas en la consola de Billing y crea un presupuesto para el proyecto y el servicio que quieres vigilar.
- Define el importe mensual. Recuerda que el cálculo usa precio de lista y no descuenta créditos ni descuentos, así que tu factura real puede ser menor que la estimación.
- Activa la aplicación del tope sobre ese presupuesto, de modo que al llegar al objetivo se pausen las peticiones nuevas.
- Comprueba que los administradores de facturación y propietarios del proyecto reciben las alertas al 50, 80 y 100 por ciento.
- Decide si prefieres el reinicio automático al inicio del mes siguiente o levantar el bloqueo a mano desde la consola, opción que sigue disponible.
- Si gestionas muchos proyectos, crea, levanta y elimina topes desde la API de presupuestos y engánchala a tu proceso de alta de proyectos.
Qué ocurre cuando se alcanza el límite
Al llegar al objetivo, las peticiones nuevas a ese servicio en ese proyecto se rechazan. Las que ya estaban en vuelo terminan y se cobran, los recursos persistentes siguen funcionando y no se elimina nada. El uso cubierto por descuentos por compromiso también se pausa, pero el Provisioned Throughput de modelos de IA nunca se detiene.
Para los servicios de IA, la aplicación usa costes estimados en vivo, visibles en los informes de costes, en lugar de datos de facturación liquidados que pueden tardar horas. Aun así, no es instantáneo: la documentación avisa de que los excesos durante el retraso se facturan con normalidad y recomienda fijar el tope algo por debajo de tu límite absoluto.
# Plantilla mental para dimensionar el tope (no es un comando)
limite_absoluto = 1000 # lo máximo que toleras pagar al mes
margen = 0.15 # colchón por el retraso de aplicación
tope = limite_absoluto * (1 - margen) # 850Límites que conviene conocer
Un tope cubre un único proyecto y un único servicio durante un mes natural. Quedan fuera carpetas, organizaciones, etiquetas, presupuestos multiservicio, cuentas de revendedores y cargos de suscripción como los asientos de Gemini Enterprise. Tampoco entran Compute Engine, Cloud Storage ni la red, así que una instancia con GPU olvidada no se detiene con esto.
La comunidad ya ha opinado: en un hilo de Hacker News alguien lo calificó de poco granular, y Simon Willison defiende que los servicios de pago por uso deberían traer topes duros por defecto. Para comparar, AWS ofrece un límite de gasto por proyecto en despliegue limitado, y el límite de Azure sigue restringido a cuentas gratuitas y suscripciones con créditos.

Fuente original: infoq.com
Artículo generado mediante AI.larebelion



Publicar un comentario