Guía de implementación de presupuestos de tokens

Los presupuestos de tokens son la capa operativa del control de costes de LLM. La atribución te dice adónde va el dinero; los presupuestos eviten que vaya a lugares que no deseas. Sin presupuestos, un bucle de agente mal configurado o un aumento en el tráfico de usuarios puede agotar una asignación mensual en horas. Esta guía cubre cómo implementar cuatro tipos de presupuestos de tokens en producción, con pseudocódigo para cada patrón.

Tipos de presupuesto

Tipo de presupuestoGranularidadAplicaciónCaso de uso
Por solicitudUna sola llamada APILímite duro vía parámetro max_tokensPrevenir finalizaciones descontroladas, acotar latencia
Cuota por equipoEquipo o proyecto durante un períodoLímite blando con alertas, límite duro en umbralAsignación de costes departamental, evitar que un equipo consuma presupuesto compartido
Por período de tiempoDiario, semanal o mensualLímite duro con período de graciaLímites de presupuesto mensual, gasto a nivel de sprint
Por flujo de trabajoUn solo pipeline o ejecución de agenteLímite duro por paso y totalAgentes multi-paso, pipelines de RAG, ejecuciones de evaluación

Límites por solicitud

El presupuesto más simple: limita cada solicitud con max_tokens. Esto no es opcional - cada solicitud de producción debe tener un límite explícito de tokens de salida. Sin él, una respuesta verbosa del modelo puede consumir tokens inesperados e inflar la latencia.

// Aplicación de presupuesto por solicitud
function llamarLLM(prompt, config):
    respuesta = proveedor.completar(
        prompt: prompt,
        modelo: config.modelo,
        max_tokens: config.max_tokens_salida,    // límite duro
        temperatura: config.temperatura
    )
    if respuesta.uso.tokens_totales > config.umbral_alerta:
        log.advertencia("Solicitud superó límite blando",
            tokens: respuesta.uso.tokens_totales,
            umbral: config.umbral_alerta
        )
    return respuesta

Cuotas por equipo

Las cuotas por equipo requieren un contador compartido que persista entre solicitudes. El patrón: verifica el presupuesto restante antes de cada llamada, rechaza o degrada si el presupuesto se agotó.

// Cuota de equipo con contador en Redis
function verificarPresupuestoEquipo(equipoId, tokensEstimados):
    clave = "presupuesto:" + equipoId + ":" + periodoActual()
    restante = redis.obtener(clave) or obtenerCuotaEquipo(equipoId)

    if restante < tokensEstimados:
        if restante < tokensEstimados * 0.1:
            return DENEGAR    // límite duro: rechazar solicitud
        else:
            return DEGRADAR   // límite blando: usar modelo más barato

    return PERMITIR

function registrarUso(equipoId, tokensReales):
    clave = "presupuesto:" + equipoId + ":" + periodoActual()
    redis.decrementar(clave, tokensReales)
    restante = redis.obtener(clave)
    if restante < obtenerCuotaEquipo(equipoId) * 0.2:
        alerta.cuotaBaja(equipoId, restante)

Presupuestos por período de tiempo

Los presupuestos por período de tiempo envuelven las cuotas de equipo con una ventana temporal. La diferencia clave: necesitas un mecanismo de período de gracia. Cuando un equipo alcanza el 80% de su presupuesto mensual, envía una alerta. Al 100%, permite un período de gracia configurable (por ejemplo, 24 horas) antes de que la aplicación dura entre en vigor. Esto evita que un equipo se bloquee a mitad de tarea el último día del mes.

// Presupuesto por período con período de gracia
function aplicarPresupuesto(equipoId):
    uso = obtenerUsoPeriodo(equipoId, mesActual())
    limite = obtenerLimiteMensualEquipo(equipoId)

    if uso < limite * 0.8:
        return PERMITIR

    if uso < limite * 1.0:
        alerta.avisoPresupuesto(equipoId, uso, limite)
        return PERMITIR   // zona de advertencia blanda

    if uso < limite * 1.1 and dentroPeriodoGracia(equipoId):
        alerta.presupuestoExcedido(equipoId, uso, limite)
        return PERMITIR   // período de gracia: permitir exceso

    return DENEGAR  // parada dura

Presupuestos por flujo de trabajo

Los agentes y pipelines multi-paso necesitan presupuestos en dos niveles: por paso (evita que un solo paso consuma demasiado) y por ejecución (evita que todo el pipeline exceda su asignación). Sigue ambos en el contexto del flujo de trabajo.

// Rastreador de presupuesto de flujo de trabajo
class PresupuestoFlujo:
    constructor(maxPorPaso, maxTotal):
        this.maxPorPaso = maxPorPaso
        this.maxTotal = maxTotal
        this.gastado = 0

    function ejecutarPaso(fnPaso, prompt):
        if this.gastado >= this.maxTotal:
            return respuestaReserva("Presupuesto excedido")

        respuesta = llamarLLM(prompt, {
            max_tokens: min(this.maxPorPaso,
                           this.maxTotal - this.gastado)
        })

        this.gastado += respuesta.uso.tokens_totales
        return respuesta

Degradación gradual cuando se excede el presupuesto

No devuelvas simplemente un error cuando se alcanza un presupuesto. Degrada con gracia. Cambia a un modelo más barato (GPT-4o-mini en lugar de GPT-4o), reduce el tamaño de la ventana de contexto, omite pasos de procesamiento opcionales o devuelve un resultado parcial con una nota de que el procesamiento completo requiere aprobación de presupuesto. La experiencia del usuario debe degradarse, no romperse.

// Cadena de degradación
function llamarConDegradacion(prompt, config):
    if verificarPresupuesto(config.equipoId, MODELO_COMPLETO):
        return llamarLLM(prompt, { modelo: config.modeloPrimario })

    if verificarPresupuesto(config.equipoId, MODELO_BARATO):
        log.info("Degradando modelo por presupuesto")
        return llamarLLM(prompt, { modelo: config.modeloReserva })

    if verificarPresupuesto(config.equipoId, TOKENS_MINIMOS):
        truncado = truncarContexto(prompt, 50%)
        return llamarLLM(truncado, {
            modelo: config.modeloReserva,
            max_tokens: 256
        })

    return cacheadoOFallback(prompt)

Monitorización de la salud del presupuesto

Sigue tres métricas: tasa de consumo (tokens consumidos por hora vs. presupuesto), previsión (al ritmo actual, cuándo se agotará el presupuesto) y recuento de anulaciones (cuántas veces se usó el período de gracia). Si el uso del período de gracia supera el 10% de las solicitudes totales, el presupuesto está demasiado bajo para la carga de trabajo.

Relacionado


¿Quieres esto aplicado a tu propio gasto en LLM? FinOps LLM ejecuta una auditoría gratuita de tus costes de IA y muestra dónde están los ahorros. Reserva auditoría gratuita →

Volver a investigación