Reduzca los gastos en LLM con un enrutador de tokens LiteLLM

LiteLLM es una pasarela de código abierto que utiliza el formato de solicitud de OpenAI para comunicarse con numerosos proveedores. Destaca en varias funciones; este texto se centra en la enrutación de modelos: enviar cada solicitud a un modelo lo suficientemente económico como para mantener el gasto en tokens bajo control.

Qué hace un enrutador de modelos

Un enrutador se sitúa entre tu aplicación y los proveedores. El cliente sigue autenticándose una vez ante la pasarela. Esta inspecciona cada solicitud y, mediante una política que definas, elige qué modelo interno debe responder. Considéralo como una capa de toma de decisiones ligera: las solicitudes sencillas no requieren el modelo más costoso.

Intuición sobre la enrutación basada en tokens

LiteLLM puede contar los tokens de entrada antes de reenviar la solicitud. Una heurística práctica:

• Tareas simples como “leer una página y resumirla” → Modelos de tipo Haiku
• Código en Python complejo que necesita razonamiento profundo → Modelos de tipo Opus

Todo lo que está en el medio → Modelos de clase Sonnet

Ese patrón se denomina enrutamiento basado en tokens. Las solicitudes cortas son económicas; las largas, de precio elevado. Los sistemas en producción suelen añadir clasificación de intención para mayor precisión, pero incluso la heurística de tokens por sí sola puede reducir los gastos en aproximadamente un treinta por ciento.

Sin enrutamiento

Cada solicitud llega a un único modelo costoso. Los costos aumentan de forma lineal con el volumen; no hay consideración alguna sobre la dificultad de la tarea.

Con enrutamiento

Ese mismo tráfico se clasifica y se distribuye entre diferentes niveles. Los ingenieros siguen utilizando una única URL de gateway; el proxy decide qué modelo facturable se ejecutará realmente.

Un mes simulado de tráfico de ingeniería

Puse a prueba ambos sistemas con LiteLLM. Al principio, todas las solicitudes fueron procesadas por Opus. Aproximadamente setecientas solicitudes generaron una factura cercana a 60 dólares.

Luego activé el router. Opus solo recibió solicitudes cuyos tokens de entrada superaban los 300. El registrador personalizado que implementa esa política se ve así:

from litellm.integrations.custom_logger import CustomLogger
import litellm
import random

class TokenRouter(CustomLogger):
    async def async_pre_call_hook(self, user_api_key_dict, cache, data, call_type):
        # Skip routing for mock models - simulation handles model selection
        if "mock" in data.get("model", ""):
            return data

        # SMART ROUTING based on token complexity
        messages = data.get("messages", [])
        token_count = litellm.token_counter(
            model="gpt-3.5-turbo",
            messages=messages
        )

        if token_count < 50:
            data["model"] = "haiku"
            tier = "HAIKU  (5%)"
        elif token_count < 300:
            data["model"] = "sonnet"
            tier = "SONNET (30%)"
        else:
            data["model"] = "opus"
            tier = "OPUS   (65%)"

        print(f"[ROUTER] Tokens: {token_count} → {tier}")
        return data

proxy_handler_instance = TokenRouter()

De 741 solicitudes, 494 (aproximadamente el 66%) llegaron aún a Opus. El resto se distribuyó entre Sonnet y Haiku, siendo Haiku el que recibió la menor cantidad. La factura por una carga de trabajo similar bajó a $43; no hubo cambios en la forma en que los desarrolladores redactan las solicitudes.

Conclusiones de las cifras

• 741 solicitudes — un uso mensual razonable por parte de los ingenieros
• $60 como referencia — Opus para todo
• $43 con enrutamiento — mismo trabajo, selección más inteligente
• Ahorro de ~28% — todo se logra en el proxy, invisible para los clientes

Los ahorros aumentan a medida que se añaden ingenieros, modelos más costosos y volúmenes mayores de tokens. No toda pregunta requiere el modelo más potente del catálogo.

El enrutador de LiteLLM se encarga de esto silenciosamente. Los ingenieros mantienen el mismo cliente con formato OpenAI; el departamento financiero recibe una factura más pequeña.

Los benchmarks utilizados aquí emplearon LiteLLM v1.98 localmente con sustitutos de Ollama y los precios listados por Anthropic para calcular los costos. Los ahorros reales dependen de cómo se distribuya la combinación de solicitudes según su nivel de dificultad.