OlmoEarth v1.1 es una señal, no una recomendación de producto
OlmoEarth v1.1 llegó a principios de 2025 con variantes de modelos más pequeños y costos de inferencia más bajos. No te diremos que cambies a él. Lo que sí diremos: el lanzamiento es una función forzada para hacer una pregunta que la mayoría de los equipos omiten completamente.
El patrón más amplio importa más que cualquier modelo individual. Llama 3.1 8B, Mistral Small, Claude 3.5 Haiku, Gemini 2.0 Flash — la brecha entre modelos frontera y pequeños se ha estrechado en los últimos 18 meses. Los modelos frontera siguen ganando en razonamiento multi-paso difícil y experiencia de dominio. Pero aquí está lo que hemos encontrado: la mayoría de los equipos no saben qué porcentaje de las llamadas de su agente realmente necesitan esa potencia.
Usas GPT-4o o Claude 3.5 Sonnet por defecto para cada decisión en el bucle porque es seguro, porque el proveedor lo envió primero, porque lo heredaste. No porque lo hayas medido.
La mayoría de los bucles de agente son 80% enrutamiento y 20% razonamiento
Recorre una ejecución típica de agente. El bucle generalmente se ve así: clasificar intención → seleccionar herramienta → formatear argumentos → llamar API externa → resumir resultado → decidir siguiente paso. Son seis llamadas LLM, la mayoría de ellas ligeras.
La clasificación de intención funciona bien en Haiku o Gemini Flash. La selección de herramientas con un esquema de salida JSON estructurado — lo mismo. El formateo de argumentos cuando tu esquema está definido — lo mismo. Resumir una respuesta de API que volvió como JSON — lo mismo. Solo el paso final — "¿tenemos suficiente para responder, o necesitamos otra herramienta?" — a veces necesita razonamiento real de cadena de pensamiento.
Hemos instrumentado agentes de soporte que hacen siete llamadas LLM por ticket. Una de esas llamadas es difícil: analizar un correo electrónico desordenado y extraer entidades cuando el cliente escribió tres párrafos en dos hilos separados. Las otras seis son decisiones de enrutamiento. Puedes servir las seis por $0,0005 cada una en Haiku y la llamada difícil por $0,01 en Sonnet. O puedes servir los siete en Sonnet y gastar diez veces el dinero haciendo algo más simple.
Las salidas estructuradas y el modo JSON comprimen el razonamiento que realmente necesitas. Cuando tu modelo se ve obligado a devolver JSON válido, deja de generar prosa. Cuando defines el esquema de antemano, has eliminado grados de libertad que el modelo no necesita. Eso reduce la brecha entre modelos pequeños y frontera para estas tareas.
Audita antes de optimizar: instrumenta el gasto de tokens por decisión
No puedes enrutar lo que no has medido. Comienza registrando cada llamada LLM: modelo, tokens de entrada, tokens de salida, latencia en milisegundos, el tipo de decisión (planificador, selección_herramienta, resumidor, juez), y si la acción posterior tuvo éxito.
Envía esos registros a Postgres o ClickHouse. O usa un almacén de trazas listo para usar como Langfuse, Helicone o Phoenix — están construidos exactamente para esto. Etiqueta cada llamada con el paso del bucle. Luego pregunta: ¿cuál es el costo por tarea exitosa, no por llamada? ¿Dónde la latencia p95 excede tres segundos? ¿Qué tipos de pasos generan regularmente más de dos mil tokens de salida?
La mayoría de los equipos tienen una cola larga. La llamada del planificador el lunes generalmente toma 400ms y 800 tokens. Pero el jueves por la mañana cuando la cola se llena y el modelo está estresado, la misma llamada toma 2,5 segundos y genera 3.500 tokens porque la ruta de razonamiento se ramifica. No lo ves sin instrumentación.
Ejecuta el patrón "evaluación en la sombra": reproduce el tráfico de la semana pasada a través de un modelo más barato, compara salidas con lo que tu modelo frontera generó, y mide la tasa de error. Hemos encontrado que para el 60-80% de las llamadas en un bucle de agente bien diseñado, las salidas del modelo más pequeño son idénticas o funcionalmente equivalentes al modelo frontera. El 20-40% restante difiere. No todas las diferencias son fallos — algunas son de estilo. Algunas son errores reales.
Enruta los casos difíciles hacia arriba, no todos los casos
El patrón en cascada es tu amigo. Comienza con un modelo pequeño. Si la salida pasa tu verificación de confianza, úsala. Si no, escala a un modelo más grande.
Las señales de confianza vienen en capas. Logprobs: si el token superior del modelo tenía solo un 60% de probabilidad, estás en territorio incierto. Autoconsistencia: genera la misma llamada tres veces en el modelo pequeño; si están de acuerdo, úsala; si no, escala. Validación de esquema: si el JSON está malformado, escala. Un veredicto del modelo juez: pasa la salida del modelo pequeño y el indicador a un modelo juez pequeño que responda sí/no en "¿es esta decisión de alta confianza?"; si no, escala.
Implementa esto con el SDK de Vercel AI streaming + salida estructurada, primitivas de enrutamiento de LangGraph, o ~200 líneas de lógica personalizada en tu marco favorito. Añade almacenamiento en caché con Redis en llamadas idénticas o casi idénticas — si ya has decidido "la intención del usuario es solicitud de reembolso" para este correo, no lo vuelvas a ejecutar en el siguiente cliente.
Establece protecciones duras. Si una llamada escala dos veces y aún falla, enrútala a una cola de letras muertas para revisión humana en lugar de reintentar para siempre. Una cola de letras muertas con un tiempo de espera es más barata que un tiempo de espera visible para el cliente.
Números reales: apunta a que el 60-80% de las llamadas se sirvan por un modelo pequeño, 20-40% escaladas a frontera, y reducción de costo total de 2-5x. También obtendrás ganancias de latencia — el tiempo de espera visible para el usuario p99 se reduce cuando la mayoría de las llamadas son 200ms en lugar de 1,5 segundos.
El impuesto oculto del sobreaprovisionamiento de modelos
Siete llamadas por ticket a dos segundos cada una en Sonnet son catorce segundos de tiempo de reloj de pared antes de que tu usuario vea una respuesta. Es lo suficientemente largo para que comiencen a redactar un correo de seguimiento o cambien a otra pestaña. No es solo lento — es lo suficientemente lento como para que las personas trabajen alrededor de tu sistema.
Las matemáticas de costo: Sonnet corre a $3 por millón de tokens de entrada y $15 por millón de tokens de salida. Haiku corre a $0,25 y $1,25. Una llamada de mil tokens cuesta aproximadamente $3 en Sonnet y $0,25 en Haiku. Haz eso siete veces y estás en $21 por ticket en Sonnet, $1,75 en Haiku, asumiendo conteos de tokens de salida similares. Y si Haiku genera menos tokens porque es más conciso — lo que a menudo es en tareas de enrutamiento — estás más cerca de $21 vs. $0,80.
También está el impuesto de límite de velocidad. Los modelos frontera están muy contendidos. Los modelos más pequeños tienen más espacio. Cuando tu agente golpea un 429 y reintenta, pierdes 2-5 segundos y regeneras tokens. Escapa de esa cola y eres más rápido y más barato.
El impuesto de operaciones es el que nadie presupuesta: un agente que es lo suficientemente lento se convierte en el proyecto secundario de alguien para optimizar "cuando tengamos tiempo". Ese tiempo nunca llega. Envías la optimización en Q3 como una emergencia, reescribes la mitad del bucle, y pierdes meses de otro trabajo. El costo oculto de las operaciones manuales se agrava cuando tu automatización es en sí misma lo suficientemente lenta para bloquear las operaciones humanas.
Una auditoría práctica que puedes ejecutar esta semana
Paso 1: Añade registro por llamada con modelo, paso, tokens y latencia. Esto toma dos horas. Usa un gancho antes/después en tu cliente LLM.
Paso 2: Elige un paso del bucle — el que se dispara más a menudo. Reproduce 100 trazas de producción a través de Haiku, Gemini Flash y Llama 3.1 8B en paralelo. Almacena salidas en una columna separada.
Paso 3: Usa tu modelo frontera como juez. Alimenta el indicador, la salida del modelo pequeño y la salida frontera, junto con una rúbrica ("¿es la salida del modelo pequeño funcionalmente correcta?"). Puntúa las 100 salidas. Si >85% son correctas, tienes un candidato para cascada.
Paso 4: Envía el modelo pequeño detrás de una bandera de característica para el 10% del tráfico. Monitorea tasas de error, latencia y métricas de éxito posteriores. Si la tasa de error se mantiene <1% por encima de tu línea base, despliegue al 50%. Automatiza la reversión en cualquier pico.
Paso 5: Establece una revisión trimestral. Los precios y capacidades de modelos cambian cada 8-12 semanas. Lo que es caro ahora podría ser barato en seis meses. Lo que es preciso ahora podría tener un nuevo competidor. La auditoría no es un proyecto único — es una factura recurrente que puedes controlar.
Elige un agente en producción esta semana, instrumenta su gasto de tokens por paso, y reproduce 100 trazas a través de un modelo 5x más barato antes de tu próxima planificación de sprint. Si prefieres ejecutar la auditoría con nosotros, hablemos.