Cuatro palancas que de verdad reducen la factura

La palanca más grande, y la primera que hay que accionar, porque no requiere hardware nuevo. La mayoría de los turnos de un chatbot no son difíciles. Buscar un precio, traer una factura, detectar una intención de sí/no: nada de eso necesita un modelo de frontera, pero lo recibe por defecto. Enrutar significa: clasificar la solicitud a bajo costo y luego enviarla al nivel más bajo que supere una vara de calidad medida.

Cómo medimos esa vara es todo el sentido de EyesInAI. Para DLR evaluamos 5 modelos candidatos en 11 acciones del chatbot: 33 tareas, 10 corridas cada una, 1,650 llamadas calificadas, cada respuesta puntuada contra la respuesta correcta conocida por un modelo juez. El resultado es una tabla de enrutamiento: el modelo menos costoso que todavía responde bien cada acción. El resultado medido fue un ahorro del 31.3% por turno con la misma precisión: cerca de $0.0062 → $0.0042 por turno. Esa es la diferencia entre una suposición (“Haiku probablemente sirve para eso”) y un número que puede defender ante finanzas.

El primer paso para cualquier equipo: tome su acción de mayor volumen, haga un benchmark de dos o tres modelos con sus datos reales y bájela de nivel si el más barato aprueba. La tabla de costo por tarea es la lista corta inicial; el caso de estudio de DLR es el método completo.

Dos arreglos estructurales y baratos que detienen las fugas más comunes, y que un equipo puede lanzar esta misma semana sin cambiar de modelo.

Caché de prompts. Un chatbot reenvía en cada turno un prompt de sistema largo y estático y las definiciones de sus herramientas. Con caché, ese texto se factura una vez y se vuelve a leer a bajo costo. En DLR cargamos las skills de forma selectiva (solo el puñado que necesita una sesión) precisamente porque la carga de creación del caché es la parte cara del primer turno; cargarlas todas le sumaría más de un dólar a un turno de Opus. Seguimos la proporción entre lecturas y creación de caché por turno, para ver que el caché de verdad está funcionando.

Topes estrictos. La historia de la factura desbocada siempre es un ciclo sin techo. El puente de DLR aplica un límite de respaldo de $1.50 por turno que se pasa directamente al ejecutor del modelo (para que una llamada a herramienta en ciclo no pueda rebasarlo) y un tope de gasto de $20/día por inquilino, con alertas en un umbral por solicitud, al 75% del tope y ante cualquier pico diario de más de 2× el promedio móvil. Pasado el tope, se rechazan los chats nuevos hasta que cambia el día. Nada de eso es exótico: es la diferencia entre un día de $20 y un titular.

El precio por token es barato con poco volumen y castiga con mucho volumen. El hardware propio es lo inverso: un costo mensual fijo y un costo marginal por llamada cercano a cero. Se cruzan en un volumen, no en una corazonada, y el punto de cruce depende del precio de la tarea de API que reemplazaría:

Reemplazar una tarea de API de ~$0.14/M tokens → equilibrio cerca de ~110M tokens/día
Reemplazar un nivel de ~$0.50/M tokens         → equilibrio cerca de ~30M tokens/día
Reemplazar un nivel premium de ~$1.50/M        → equilibrio cerca de ~10M tokens/día

Así que la pregunta nunca es “API o autoalojar” en abstracto: es si sus llamadas de alto volumen y baja complejidad (clasificación de intención, extracción corta, redacción con plantillas) siguen llegando a un endpoint de frontera facturado por consumo cuando un modelo local de pesos abiertos aprobaría por una fracción del costo. Ajuste el hardware al modelo que realmente necesita:

• Equipo con 128GB de memoria unificada (Mac Studio, o una mini PC con AMD Ryzen AI Max+ 395): ejecuta localmente un modelo de clase 70B; el caballo de batalla para un solo equipo que prioriza la privacidad. El ancho de banda, no la capacidad, fija la velocidad.
• Una sola GPU / estación de trabajo: para más throughput con modelos medianos cuando un solo equipo es el cuello de botella.
• Clúster: solo por encima de los volúmenes de equilibrio de arriba, donde el costo fijo de verdad se amortiza.

Los costos de armado actualizados y con fecha, el TCO, y qué modelos corren de verdad a una velocidad utilizable en cada nivel están en la pestaña de costo y TCO y en los perfiles de hardware. Y vea el análisis más profundo sobre la economía de la capa de aplicación y dónde cae la línea.

Dónde está DLR en esto: hoy el chatbot de DLR responde a través de la API de Claude; la Mac Mini aloja el puente, el servidor de benchmarks y el router, no el modelo. Esa configuración funciona bien con nuestro volumen actual de un solo equipo, que es exactamente por lo que autoalojar es la siguiente palanca para nosotros, no la primera. La secuencia honesta es: primero enrutar y poner topes (hecho), y luego pasar a un modelo local las acciones clasificadas de mayor volumen, una vez que el volumen justifique el equipo. Vamos en esa dirección, y publicaremos las cifras reales cuando crucemos la línea, igual que hicimos con el enrutamiento.

Y una advertencia deliberada sobre esta palanca: autoalojar es la más acotada de las cuatro, y la publicidad la exagera. A escala de un equipo, un solo equipo de cómputo por lo general no es ni más rápido ni más barato que una API en la nube una vez que se cuentan la concurrencia, la brecha de precisión y el valor real de la suscripción: gana en trabajos por lotes, en soberanía de datos y en una sola tarea acotada con alto volumen, no como reemplazo directo de un asistente compartido. Lea la realidad del autoalojamiento antes de comprar hardware: para la mayoría de los equipos, los ahorros duraderos están en el enrutamiento y el caché de arriba, no en el equipo.

Una tabla de enrutamiento se vuelve obsoleta en cuanto sale un modelo nuevo o cambian los precios. La palanca que conserva los ahorros es convertirla en un ciclo cerrado en lugar de un ajuste de una sola vez. En DLR ese ciclo ya funciona:

1. el benchmark mide los modelos candidatos en las acciones reales;
2. un paso de “Examine” propone cambiar de nivel cuando un modelo más barato ya aprueba;
3. una persona lo aprueba;
4. el chatbot lee la configuración de enrutamiento aprobada y cambia de nivel en vivo, sin volver a desplegar;
5. un reporte matutino muestra exactamente qué cambió.

Junto a él funciona un modo de comparación en sombra: cuando el router elegiría un modelo que no es Claude, el puente ejecuta en silencio esa sugerencia en segundo plano, la juzga contra la respuesta que el usuario ya recibió y registra el par. Así ganamos confianza en un cambio de enrutamiento antes de que toque una respuesta real: primero observar, después cambiar. Un paso de autorreparación desactiva cualquier modelo que empiece a fallar, así que el ciclo es seguro de dejar funcionando.

El patrón de plugin. La forma reutilizable de todo esto es un chatbot cuya elección de modelo depende de datos, no está fija en el código. Lo estamos construyendo sobre openclaw.ai, un gateway de agentes abierto y autoalojable cuya capa de proveedores ya abstrae muchos backends de modelos (incluidos endpoints locales de Ollama / LM Studio) y registra el costo de tokens por modelo. Un cliente de enrutamiento que consulta la tabla aprobada de EyesInAI, se conecta en ese espacio de proveedor y recurre a un nivel fijo en el código si no se puede acceder al servicio, se convierte en un bloque portátil de “chatbot + enrutamiento medido”: el mismo ciclo que ejecuta DLR, empaquetado para que el siguiente producto lo obtenga con configuración, no reconstruyéndolo.

Los efectos de estas palancas se potencian, pero las baratas van primero. Ponga topes y caché antes de tocar un modelo: son opciones de configuración y detienen la hemorragia. Luego enrute, porque medir sus tareas reales es donde vive el ahorro duradero de más del 30%. Luego autoaloje la cola de alto volumen una vez que alcance el punto de equilibrio. Luego cierre el ciclo para que nada de esto se vuelva obsoleto. Todo el recorrido cabe en una frase: deje de pagar por estructura que puede arreglar, y pague solo por la inteligencia que realmente necesita.

Este manual es el mapa; cada palanca tiene su propio análisis más profundo. Empiece aquí y luego profundice tanto como necesite:

• El impuesto de tokens— por qué una factura por consumo crece aunque el uso no crezca
• Herramientas que reducen tokens— MarkItDown + Graphify: encoger la entrada localmente, por $0
• Más herramientas que reducen tokens— compresión de prompts, memoria para agentes, observabilidad del costo
• El caso de estudio de DLR— la prueba medida: el método de enrutamiento completo